Update scaling test TE-14.1 #3556
Conversation
Pull Request Functional Test Report for #3556 / 571adaaVirtual Devices
Hardware Devices
|
Pull Request Test Coverage Report for Build 12636765117Details
💛 - Coveralls |
|
@nflath do you plan to also update the test code to match? |
| * <VRF1> | ||
| * Install 9000 IPv4Entries. Each points to a NextHopGroup from E). | ||
| * <VRF2> | ||
| * Install 9000 IPv4Entries (Same IPAddress as VRF1). Each points to a NextHopGroup from F). |
There was a problem hiding this comment.
if we are using same IP address as VRF1 means , are we not planning to same destination ip as received in encapped packet?
There was a problem hiding this comment.
Updated the VRF procedure - there should be different bheaviour based on the SRC ip. Let me know if this is unclear.
There was a problem hiding this comment.
sure that is correct if we directly hit VRF2 through PBF match . but if we want to validate VRF1 backup path and make sure that really dst_ip and src_ip has been updated as per encap then we need to have different prefixes in VRF2.
There was a problem hiding this comment.
In this test I don't think we want to validate the repaired path; we have more-specific tests for that.
| * C) Install 200 IPv4 Entries, each pointing at a unique NHG (1:1) from B. | ||
| * D) Install 200 NextHops. Each will redirect to an IP from C). | ||
| * E) Install 100 NextHopGroups. Each will contain 2 NextHops from D). The backup next_hop_group will be to redirect to VRF2. | ||
| * F) Install 100 NextHopGroups. Each will contain 2 NextHops from D). The backup next_hop_group will be to decap and redirect to DEFAULT vrf. |
There was a problem hiding this comment.
if we are using same final NHs ( in this case it will resolve to A) then how are we planning to switch to backup path in VRF1 and validate the traffic with backup path.
There was a problem hiding this comment.
I think for now this is fine; we test backup path actuation, this is to ensure the scale is proper. If we need to later, we can split B) into two groups.
Not in this PR. I'll. discuss who can do this work. |
| * B) Install 200 NextHopGroups. Each points at 8 NextHops from the first 200 entries of A) with equal weight. | ||
| * C) Install 200 IPv4 Entries, each pointing at a unique NHG (1:1) from B. | ||
| * D) Install 200 NextHops. Each will redirect to an IP from C). | ||
| * E) Install 100 NextHopGroups. Each will contain 2 NextHops from D) with weights 1:31. The backup next_hop_group will be to redirect to VRF3. |
There was a problem hiding this comment.
How are we going to validate the weight distribution ? finally all packets goes out of same physical interface . May be it is good to have different egress interface for second half of B) NHGs and use that for second half of C) prefixes . Build E with one NH from first half D) and 1NH from second half of D).
There was a problem hiding this comment.
Yes, that seems reasonable. Updated.
| * Install IPiniP decap-then-encap to 500 first /32 from <IPBlockVRF1> | ||
| to 500 NextHopGroups containing 1 NextHop each | ||
| * Validate that the entries are installed as FIB_PROGRAMMED | ||
| * <Default VRF> |
There was a problem hiding this comment.
The bullet format/indent seems messed up (see preview).
fix typo and add a TODO link
* Update scaling test * Add separation to validate traffic splits --------- Co-authored-by: nflath <nflath@google.com> Co-authored-by: Xiao Wang <39514181+xw-g@users.noreply.github.com>
* Update scaling test * Add separation to validate traffic splits --------- Co-authored-by: nflath <nflath@google.com> Co-authored-by: Xiao Wang <39514181+xw-g@users.noreply.github.com>
Updates the scaling test on TE-14.1 on current projections.