Phoenixwing SRv6 traffic test and convergence test using TRex #15221
Conversation
There was a problem hiding this comment.
Is there a significance for the black and purple connection lines? If so, can you add some legends for more clarity?
There was a problem hiding this comment.
Thanks you udhay, actually they are same lines, I will update the image.
|
|
||
| ### SRv6 VPN | ||
|
|
||
| #### SRv6 VPN for single homing |
There was a problem hiding this comment.
Can't directly rely on packet counters because of the control packets. Increasing packet size will help. Sonic interface tracks count for different bytes.
There was a problem hiding this comment.
yes, we will take control packets into account, the control packets is limited, compared to user traffic. so we can reserve some buffer when calculate traffic loss. The sonic interface counters may not work in vSonic case.
| #### SRv6 VPN for single homing | ||
| Publish VRF routes from PE1 to PE3, and run TRex traffic from PE3. | ||
|
|
||
| - no packet loss: for example run trex for 10s and check {"ptf_tot_rx": 10000, "ptf_tot_tx": 10000} |
There was a problem hiding this comment.
Can you add check to validate TTL is not decremented when crossing tunnel ?
There was a problem hiding this comment.
good suggestion, TTL validation added
| - if send a single stream to PE3, the packet can only be found on a single path | ||
|
|
||
| #### Dual homing - IGP local failure case | ||
| Start trex stream and wait 5 seconds; Shut down port between P2 and PE3; wait 5 seconds and Stop Trex stream. |
There was a problem hiding this comment.
Please mention traffic end points for the test cases to visualize traffic load balancing in failure cases .
There was a problem hiding this comment.
Hi, All traffic end points are on PEs. Ingress PE3 is always to encap srv6 packets, and Egress PE1/PE2 is to decap srv6 packets.
There was a problem hiding this comment.
added more images to show traffic load balancing
There was a problem hiding this comment.
@forrestchu - can this be presented on the next sonic-mgmt subgroup meeting?
There was a problem hiding this comment.
@forrestchu - can this be presented on the next sonic-mgmt subgroup meeting?
that would be great, roy @roy-sror . But currently I don't get a meeting invitation, or should I schedule an appointment with the meeting owner?
forrestchu
force-pushed
the
phoenix_ptf_testplan_forrest
branch
from
f91fd4f
to
57fa118
Compare
Description of PR
Summary:
PhoenixWing SRv6 traffic test and convergence test by using TRex.
Type of change
Back port request
Approach
What is the motivation for this PR?
The PhoenixWing Initiative aims to incorporate SRv6 features and some infrastructure level enhancements into the SONiC community code base. This test plan will cover the traffic test and convergence test of SRv6 cases in PhoenixWing, by using software traffic generator TRex.
How did you do it?
To observe the traffics on all SRv6 paths, we replace all the device connections in the testbed with OVS links. This allows us to get a traffic copy for each link in PTF, Trex can calculate the traffic on each link.
How did you verify/test it?
From Trex, we can get traffic statistics on all link, we will check whether the the packet counter is as expected, also we will check the packet SRv6 encapsulation with PTF framework.
Any platform specific information?
no
Supported testbed topology if it's a new test case?
Documentation