Hi Don, Which version are you using?
Looks like MAC addresses have been aged out and unknown unicast is not flooded in your case resulting in this behavior. Praveen From: Dan Houtz <dho...@gmail.com<mailto:dho...@gmail.com>> Date: Saturday, June 20, 2015 at 10:05 AM To: Harshad Nakil <hna...@gmail.com<mailto:hna...@gmail.com>> Cc: "dev@lists.opencontrail.org<mailto:dev@lists.opencontrail.org>" <dev@lists.opencontrail.org<mailto:dev@lists.opencontrail.org>> Subject: Re: [opencontrail-dev] BMS / Unknown Unicast issues 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<http://192.168.1.3>: icmp_seq=1 ttl=64 time=0.329 ms 64 bytes from 192.168.1.3<http://192.168.1.3>: icmp_seq=2 ttl=64 time=0.374 ms 64 bytes from 192.168.1.3<http://192.168.1.3>: icmp_seq=3 ttl=64 time=0.359 ms 64 bytes from 192.168.1.3<http://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
