FIB Scale Test Plan

#Test name

#SONiC Test Plan

Related documents

N/A

##Overview

The purpose of this test is to test addition of IPV4 and IPV6 routes in a quantity required by Azure, and verify that each route is working properly by forwarding packets according to each route. The test assumes all routes are set prior by BGP, so no configuration is required to be done by the test itself. The test receives the route configuration via a text file to be parsed by the test. The validation to the routes is done by sending traffic on each of the created routes. If the test fails, it is the test responsibility to provide all the debug information which can be retrieved in order to shade more light to the failure for offline debug as much as possible.

###Scope

The scope if this test plan is only the PTF test. Router info text file generation and setting up the BGP sessions and router is out of the scope of this document. Thus no configuration is required by the test as well as changing the exist configuration.

###Scale / Performance

The Setup will be configured to have 6K IPV4/26 and 6K IPV6/64 routes. For each route a simple traffic class will be issued using the ping functionality.

For ECMP validation we'll use TCP packet, then for each ECMP route, we send n packets, then verify them to be received at any of ports in the ECMP group only.

As ECMP routes are to be set we should run few ping packets for each route.In additional each route can be verified independently thus test might take more than few minutes to cover all 12K route by few consecutive ping requests.

There will be 1 or 2 next hop groups per route.

###Related DUT CLI commands

No CLI commands will be needed for this test.

###Related DUT configuration files

No DUT configuration test files are needed on the test switch.

###Related SAI APIs

The test is targeting a running SONIC system with fully functioning configuration. The purpose of the test is not to test specific SAI API, but functional testing of routes, making sure that routes pre-configured on SONIC start-up function properly.

##Test structure

###Setup configuration

The setup tests assumes to have single SONiC (DUT) connected to a switch connected to a server running 32 Arista VMs.

There will be 32 BGP peers connected to the switch. Each peer will have 2 BGP sessions open with the switch: single IPV4 connection and singke IPV6 connection. The peers will advertise routes that switch needs to become aware of.

PTF host needs to be connected to a port through which it will send packets to the switch, and needs to have connection via ports through which the switch will send forward received packet back to the host for validation.

###Configuration scripts

The peers and SONIC (DUT) will be deployed by an Ansible script. As part of deployment the script will generate the routes. For test preparation the same script will also generate a text file, route_info.txt, which will contain rows of following format:

dst_prefix,port:port...

This information will be used to:

1. Create packet with proper destination prefix
2. During validation expect packet from the list of ports

An example of content for route_info.txt:

192.168.0.0/32,ARISTA01T2:ARISTA02T2:ARISTA03T2

20C0:A8C7:0:F1::/64,ARISTA01T2:ARISTA02T2

Test cases

The test assumes there is a mechanism to validate logs on the DUT where we should be able to analyze /var/log/syslog for error and warning messages related to the current test. In case such messages are detected, test is considered failed.

The test should have standardized summary section in the following format:

TEST SUMMARY:

TEST: OK/FAIL

LOGS: OK/FAIL

Test case #1

Test objective

The objective is to validate that each route has been added to the switch and is functioning properly.

Test description

1. Read information from route_info.txt for each route
2. For each route in the route_info.textConstruct packet with proper destination address
   • Send 10 ping requests to the switch
   • Validate that 10 ping reply arrived on the port specified in route_info.txt for given destination address
   • If not all packets arrived, debug info extract from the switch will be printed to test log. Failure to be reported
3. Test case summary to be printed in test log: number of routes to be sent, number of routes validated and found OK