Noticed that as we scale the number of containers on invaders, ping between dummy interfaces of leaf to leaf & Spine to Spine fails to work via OSPF routes configured on the respective containers.
Goes build checksum- 5046b7c2cdea8604d331dd7e5dd2fb9c85fa21ff
Test case description:
In this test case we create 80 containers per invader.
Create 2 VLAN interfaces per interface
Move those vlan interface on respective containers
Create dummy interfaces on the containers
Configure OSPF routes on containers
Verify If dummy interface between leaf to leaf containers can ping
Problem statement
Noticed that ping fails to work between the dummy interfaces of leaf to leaf containers.
Noticed that as soon as we scale the number containers per invader, there is an inconsistency observed in the arp entries getting created for its directly connected interface which causes ping between dummy interfaces to fail.
Also noticed that fib entry is unreachable for the route through which ping packet needs to be processed.
Arp entry details of container in i-29
root@T161:/# arp -an
? (1.1.0.32) at 50:18:4c:00:04:14 [ether] on xeth1.10
root@T161:/# arp -an
root@T161:/#
root@invader29:/home/sandeep# goes vnet show ip fib |grep 192.168.16.1
18148 192.168.16.1/32 unreachable via 1.17.0.31
18148 192.168.16.1/32 unreachable via 17.9.0.32
Arp entry details of container in i-31
root@T81:/# arp -an
? (17.25.0.30) at 50:18:4c:00:0b:5c [ether] on xeth17.250
? (1.17.0.29) at 50:18:4c:00:05:a0 [ether] on xeth1.170
root@T81:/# arp -an
root@T81:/#
root@invader31:/home/sandeep# goes vnet show ip fib |grep 192.168.0.1
16262 192.168.0.1/32 unreachable via 17.25.0.30
16262 192.168.0.1/32 unreachable via 1.17.0.29
Arp entry details of container in i-32
root@T1:/# arp -an
? (17.9.0.29) at 50:18:4c:00:05:b0 [ether] on xeth17.90
? (1.1.0.30) at 50:18:4c:00:0b:4c [ether] on xeth1.10
root@T1:/# arp -an
? (17.9.0.29) at 50:18:4c:00:05:b0 [ether] on xeth17.90
root@T1:/# arp -an
root@T1:/#
root@invader31:/home/sandeep# goes vnet show ip fib |grep 192.168.0.1
16262 192.168.0.1/32 unreachable via 17.25.0.30
16262 192.168.0.1/32 unreachable via 1.17.0.29
Arp entry details of container in i-30
root@T161:/# arp -an
? (1.1.0.32) at 50:18:4c:00:04:14 [ether] on xeth1.10
root@T161:/# arp -an
root@T161:/# arp -an
root@T161:/#
root@invader30:/home/sandeep# goes vnet show ip fib |grep 192.168.24.1
12174 192.168.24.1/32 unreachable via 1.1.0.32
12174 192.168.24.1/32 unreachable via 17.25.0.31
When a ping request packet is initiated back, the route entries under fib start to show as up & than ping starts work between spine to spine & leaf to leaf.
Noticed that as we scale the number of containers on invaders, ping between dummy interfaces of leaf to leaf & Spine to Spine fails to work via OSPF routes configured on the respective containers.
Goes version details
root@invader29:/home/sandeep# goes version v1.1.1 root@invader29:/home/sandeep# goes vnetd -version fe1: v1.1.3 fe1a: v1.1.0 vnet-platina-mk1: v1.0.0
Goes build checksum- 5046b7c2cdea8604d331dd7e5dd2fb9c85fa21ff Test case description:
Problem statement
Noticed that as soon as we scale the number containers per invader, there is an inconsistency observed in the arp entries getting created for its directly connected interface which causes ping between dummy interfaces to fail.
Also noticed that fib entry is unreachable for the route through which ping packet needs to be processed.
Arp entry details of container in i-29 root@T161:/# arp -an ? (1.1.0.32) at 50:18:4c:00:04:14 [ether] on xeth1.10 root@T161:/# arp -an root@T161:/#
root@invader29:/home/sandeep# goes vnet show ip fib |grep 192.168.16.1 18148 192.168.16.1/32 unreachable via 1.17.0.31 18148 192.168.16.1/32 unreachable via 17.9.0.32
Arp entry details of container in i-31
root@T81:/# arp -an ? (17.25.0.30) at 50:18:4c:00:0b:5c [ether] on xeth17.250 ? (1.17.0.29) at 50:18:4c:00:05:a0 [ether] on xeth1.170 root@T81:/# arp -an root@T81:/#
root@invader31:/home/sandeep# goes vnet show ip fib |grep 192.168.0.1 16262 192.168.0.1/32 unreachable via 17.25.0.30 16262 192.168.0.1/32 unreachable via 1.17.0.29
Arp entry details of container in i-32
root@T1:/# arp -an ? (17.9.0.29) at 50:18:4c:00:05:b0 [ether] on xeth17.90 ? (1.1.0.30) at 50:18:4c:00:0b:4c [ether] on xeth1.10 root@T1:/# arp -an ? (17.9.0.29) at 50:18:4c:00:05:b0 [ether] on xeth17.90 root@T1:/# arp -an root@T1:/#
root@invader31:/home/sandeep# goes vnet show ip fib |grep 192.168.0.1 16262 192.168.0.1/32 unreachable via 17.25.0.30 16262 192.168.0.1/32 unreachable via 1.17.0.29
Arp entry details of container in i-30
root@T161:/# arp -an ? (1.1.0.32) at 50:18:4c:00:04:14 [ether] on xeth1.10 root@T161:/# arp -an root@T161:/# arp -an root@T161:/#
root@invader30:/home/sandeep# goes vnet show ip fib |grep 192.168.24.1 12174 192.168.24.1/32 unreachable via 1.1.0.32 12174 192.168.24.1/32 unreachable via 17.25.0.31
When a ping request packet is initiated back, the route entries under fib start to show as up & than ping starts work between spine to spine & leaf to leaf.
Attached is the network diagram for the scenario.