Networking stuff | findings from experience…

Single post

Build a working « snake » setup for data plane testing on a Nexus switch

If you are interested in data-plane performance testing, you might have heard about the famous « snake config » that forces an IP flow to go across all ports in a linecard.

It may be a useful thing, particularly when your testing setup is far from Miercom’s one …

The idea is simple and straightforward: your network simulator sends bidirectional flows on both interfaces, each of them follows the entire « snake », going across all ports, and then you can use this leverage to test your hardware under heavy load conditions.

however, when you try to configure this nice setup, you might be disappointed figuring out that, for some obscure reason, your snake just does not work !

This post describes the config that you can use with NX-OS, but it might be easily cutomized to work an any other piece of equipment, given that it supports the configuration of IP addresses, OSPF and VRFs (or equivalent).

setup snake f348

VRFs:

vrf context 1
 address-family ipv4 unicast
vrf context 2
 address-family ipv4 unicast
vrf context 3
 address-family ipv4 unicast
!
!! and so on until:
!
vrf context 24
 address-family ipv4 unicast

IP addressing:

interface et1/1
 no shut
 vrf member 1
 ip add 192.168.101.1/24
 !
 interface et1/2
 no shut
 vrf member 1
 ip add 10.0.0.0/31
 !
 interface et1/3
 no shut
 vrf member 2
 ip add 10.0.0.1/31
 !
 interface et1/4
 no shut
 vrf member 2
 ip add 10.0.0.2/31
 !
 interface et1/5
 no shut
 vrf member 3
 ip add 10.0.0.3/31
 !
 interface et1/6
 no shut
 vrf member 3
 ip add 10.0.0.0/31
 !
 interface et1/7
 no shut
 vrf member 4
 ip add 10.0.0.1/31
 !
 !! and so on until:
 !
 interface et1/48
 no shut
 vrf member 24
 ip add 192.168.201.1/24

Routing:

feature ospf
 !
 router ospf 100
 vrf 1
 vrf 2
 vrf 3
 !
 !! and so on...
 !
 !

But that still does not work…
Let’s consider the sticking points: 

Physical layer:

Are all the ports ‘up’ ?
If not, are you sure you are using the right cabling/fibering ?

MAC addresses:

The ports are up but no traffic, and you can’t even ping an adjacent port.
However, the strange thing is that you see yourself as an LLDP/CDP neighbor on each port…
Please take a look at mac addresses : when you configure an L3 port on a switch, mac addresses are often the same on all ports.
Force use the BIA on each port could be a good idea, at least you need to change MAC addresses to avoid two times the same address on one interconnection.

Router Ids:

At this point you have working connections between all ports, but still no routing.
Remember that your single OSPF process has picked one router-id, and you cannot become adjacent with a node having a duplicated router-id !
Now you have to customize ospf router-id in each VRF.
For example :

router ospf 100
 vrf 1
 router-id 100.0.0.1
 vrf 2
 router-id 100.0.0.2
 vrf 3
 router-id 100.0.0.3
 !
 !! and so on...
 !
 !

OSPF interfaces:

No need for DR/BDR on each segment, so you can optimize the setup :

 interface et1/1
 ip ospf network point-to-point
 ip router ospf 100 area 0
 !
 !! you don't have to try to establish an adjacency with your network simulator
 ip ospf passive-interface
 !
 interface et1/2
 ip ospf network point-to-point
 ip router ospf 100 area 0
 !
 interface et1/3
 ip ospf network point-to-point
 ip router ospf 100 area 0
 !
 !! and so on...
 !

At least, restart OSPF and check your neighbors.
When they all reach the ‘FULL’ state, you can verify that the setup is working end to end :

ping 192.168.201.2 vrf 1
ping 192.168.101.2 vrf 24

16 Mai 2016

There are no comments for Build a working « snake » setup for data plane testing on a Nexus switch

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

  • Google add

  • Commentaires récents

    • Latest Tweets

    • Archives