Looks like there is some bug. Can you check with L2 server mode?
Regards -Harshad > On Jun 19, 2015, at 9:35 PM, Dan Houtz <dho...@gmail.com> wrote: > > So still trying to solve my ARP problems. Currently doing a bit of testing > and seeing the following between two hosts on separate QFX switches. From > what I can tell ARP broadcasts are NOT being flooded or perhaps something is > wrong with my TSN. Is it possible ARP behaves differently depending on the > Logical Interface Type that is choose when configuring a TOR interface in a > virtual network? In my case I always choose L2 but, due to what Juniper told > me was a bug, they are always created as "L2 Server" intercaces which have > MAC/IP mappings associated with them. > > > My testing results: > ------------------------- > > Performing ping from host2 (192.168.1.2) to host3 (192.168.1.3): > > dhoutz@host2:~$ ping 192.168.1.3 > PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data. > From 192.168.1.2 icmp_seq=1 Destination Host Unreachable > From 192.168.1.2 icmp_seq=2 Destination Host Unreachable > From 192.168.1.2 icmp_seq=3 Destination Host Unreachable > From 192.168.1.2 icmp_seq=4 Destination Host Unreachable > From 192.168.1.2 icmp_seq=5 Destination Host Unreachable > From 192.168.1.2 icmp_seq=6 Destination Host Unreachable > From 192.168.1.2 icmp_seq=7 Destination Host Unreachable > From 192.168.1.2 icmp_seq=8 Destination Host Unreachable > From 192.168.1.2 icmp_seq=9 Destination Host Unreachable > From 192.168.1.2 icmp_seq=10 Destination Host Unreachable > From 192.168.1.2 icmp_seq=11 Destination Host Unreachable > From 192.168.1.2 icmp_seq=12 Destination Host Unreachable > From 192.168.1.2 icmp_seq=13 Destination Host Unreachable > From 192.168.1.2 icmp_seq=14 Destination Host Unreachable > From 192.168.1.2 icmp_seq=15 Destination Host Unreachable > From 192.168.1.2 icmp_seq=16 Destination Host Unreachable > From 192.168.1.2 icmp_seq=17 Destination Host Unreachable > From 192.168.1.2 icmp_seq=18 Destination Host Unreachable > ^C > --- 192.168.1.3 ping statistics --- > 20 packets transmitted, 0 received, +18 errors, 100% packet loss, time 19103ms > > > While running the above ping, tcpdump on host3 shows no arp or icmp reaching > it: > > dhoutz@host3:~$ sudo tcpdump -i em1 arp or icmp > [sudo] password for dhoutz: > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes > ^C > 0 packets captured > 0 packets received by filter > 0 packets dropped by kernel > > If I check mac tables on switches during this: > > leaf2 which host2 is connected to: > > root@leaf2z0> show ovsdb mac > Logical Switch Name: Contrail-fbedebc0-4ed8-4f18-8309-33c71d9de71c > Mac IP Encapsulation Vtep > Address Address Address > ff:ff:ff:ff:ff:ff 0.0.0.0 Vxlan over Ipv4 10.10.10.66 > 54:9f:35:05:fa:2e 0.0.0.0 Vxlan over Ipv4 10.10.10.66 > ff:ff:ff:ff:ff:ff 0.0.0.0 Vxlan over Ipv4 10.10.10.53 > > leaf3 which host3 is connected to: > > root@leaf3z0> show ovsdb mac > Logical Switch Name: Contrail-fbedebc0-4ed8-4f18-8309-33c71d9de71c > Mac IP Encapsulation Vtep > Address Address Address > ff:ff:ff:ff:ff:ff 0.0.0.0 Vxlan over Ipv4 10.10.10.67 > 54:9f:35:05:fa:2e 0.0.0.0 Vxlan over Ipv4 10.10.10.66 > ff:ff:ff:ff:ff:ff 0.0.0.0 Vxlan over Ipv4 10.10.10.53 > > > So at this point leaf3 isn't aware of host3 that is directly connected so > let's force it by pinging non-existent IP on subnet: > > dhoutz@host3:~$ ping 192.168.1.250 > PING 192.168.1.250 (192.168.1.250) 56(84) bytes of data. > From 192.168.1.3 icmp_seq=1 Destination Host Unreachable > From 192.168.1.3 icmp_seq=2 Destination Host Unreachable > From 192.168.1.3 icmp_seq=3 Destination Host Unreachable > ^C > --- 192.168.1.250 ping statistics --- > 4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3014ms > > > Now leaf3 sees host3's MAC: > > root@leaf3z0> show ovsdb mac > Logical Switch Name: Contrail-fbedebc0-4ed8-4f18-8309-33c71d9de71c > Mac IP Encapsulation Vtep > Address Address Address > ff:ff:ff:ff:ff:ff 0.0.0.0 Vxlan over Ipv4 10.10.10.67 > 54:9f:35:06:04:9c 0.0.0.0 Vxlan over Ipv4 10.10.10.67 > 54:9f:35:05:fa:2e 0.0.0.0 Vxlan over Ipv4 10.10.10.66 > ff:ff:ff:ff:ff:ff 0.0.0.0 Vxlan over Ipv4 10.10.10.53 > > And now pings from host2 are working as expected: > > dhoutz@host2:~$ ping 192.168.1.3 > PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data. > 64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.329 ms > 64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.374 ms > 64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.359 ms > 64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.364 ms > ^C > --- 192.168.1.3 ping statistics --- > 4 packets transmitted, 4 received, 0% packet loss, time 3000ms > rtt min/avg/max/mdev = 0.329/0.356/0.374/0.025 ms > dhoutz@host2:~$ arp -n | grep 192.168 > 192.168.1.3 ether 54:9f:35:06:04:9c C em1
_______________________________________________ Dev mailing list Dev@lists.opencontrail.org http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
