In that case ping after clear ARP cache on host should work. 

Regards
-Harshad


> On Jun 19, 2015, at 10:22 PM, Praveen K V <kvprav...@juniper.net> wrote:
> 
> 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>
> Date: Saturday, June 20, 2015 at 10:05 AM
> To: Harshad Nakil <hna...@gmail.com>
> Cc: "dev@lists.opencontrail.org" <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: 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

Reply via email to