IPv4 Decapsulation test

Related documents

N/A

##Overview

This test case is aimed at testing the DUTs ability to do de-capsulation of IP encapsulated packets, and verify that each decapsulated packet is with the right properties in each field, and forward with the corresponding underlay destination IP to the correct route. The test assumes all routes and decapsulation are set prior by to test, so no configuration is required to be done by the test itself, and the test will correspond only to the right IPs that is configured in the test.

The validation to the routes and the decapsulation is done by sending packets with the corresponding IPs both, in the overlay and underlay. 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 debugging as much as possible.

###Scope

The scope if this test plan is only the PTF test.

###Scale / Performance

The Setup will be configured to have IPv4 routes and decapsulation commands

###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 assume 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 single 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 a 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 the deployment, the script will generate the routes and decapsulation commands.

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, the 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 decapsulation ability and each route has been added to the switch and is functioning properly with the decapsulated packet.

Test configurations

• IP decap IPv4: 1.1.1.1
• IP Route IPv4: 2.2.2.0/32 -> dst_port

Test description

1. From the PTF docker, craft and sent through the source port a double encapsulated IP packet as follows:

• outer IP header [S:2.2.2.0,D:1.1.1.1]
• inner IP header [S:1.1.1.1,D:2.2.2.0]
• ECN and DSCP will be randomized, for the overlay and the underlay.
• all other fields will be PTF default

2. Verify the Sonic does not see the encapsulated packet. the IP-in-IP packet should not go to CPU, the packet should not be seen on the DUT.

3. Confirm that the packet that comes back to PTF Docker decapsulated from the destination port. and the L3 header fields will look like this :

• IP header [S:1.1.1.1,D:2.2.2.0]
• TTL = TTL_outer - 1
• ECN = ECN_outer
• DSCP = DSCP_outer

Test case #2

Test objective

The objective is to validate decapsulation ability and each route has been added to the switch and is functioning properly with the decapsulated packet with different fields from case 1.

Test configurations

• IP decap IPv4: 3.3.3.3
• IP Route IPv4: 2.2.2.0/32 -> dst_port

####Test description

1. From the PTF docker, craft and sent through the source port a double encapsulated IP packet as follows:

• outer IP header [S:2.2.2.0,D:3.3.3.3]
• inner IP header [S:3.3.3.3,D:2.2.2.0]
• ECN and DSCP will be randomized, for the overlay and the underlay.
• ECN_outer != ECN_inner
• DSCP_outer != DSCP_inner
• TTL_outer != TTL_inner
• all other fields will be PTF default for simple_tcp_packet function

2. Verify the Sonic does not see the encapsulated packet. the IP-in-IP packet should not go to CPU, the packet should not be seen on the DUT.

3. Confirm that the packet that comes back to PTF Docker decapsulated from the destination port. and the L3 header fields will look like this :

• IP header [S:3.3.3.3,D:2.2.2.0]
• TTL = TTL_outer - 1
• ECN = ECN_outer
• DSCP = DSCP_outer

Test case #3

####Test objective

The objective is to validate decapsulation ability with triple encapsulated packet and each route has been added to the switch and is functioning properly with the decapsulated packet.

Test configurations

• IP decap IPv4: 1.1.1.1
• IP Route IPv4: 2.2.2.0/32 -> dst_port

####Test description

1. From the PTF docker, craft a triple encapsulated IP packet as follows: Repeat steps 1 through 3 with a triple IP encapsulated packet, like this:

• outer IP header [S:2.2.2.0,D:1.1.1.1]
• inner1 IP header [S:1.1.1.1,D:2.2.2.0]
• inner2 IP header [S:4.4.4.4,D:4.4.4.3]
• ECN and DSCP will be randomized, for the overlay and the underlay.
• ECN_outer != ECN_inner1
• DSCP_outer != DSCP_inner1
• TTL_outer != TTL_inner1
• all other fields will be PTF default for simple_tcp_packet function

2. Verify the Sonic does not see the encapsulated packet. the IP-in-IP packet should not go to CPU, the packet should not be seen on the DUT.

3. Confirm that the packet that comes back to PTF Docker decapsulated from the destination port. and the L3 header fields will look like this :

• outer IP headers
  • IPs [S:1.1.1.1,D:2.2.2.0]
  • TTL = TTL_outer - 1
  • ECN = ECN_outer
  • DSCP = DSCP_outer
• inner IP headers
  • IPs [S:4.4.4.4,D:4.4.4.3]
  • TTL = TTL_inner2
  • ECN = ECN_inner2
  • DSCP = DSCP_inner2