Harshad,

In another thread (
http://lists.opencontrail.org/pipermail/dev_lists.opencontrail.org/2014-July/001211.html)
you mention that if the VN is created as L2 then ARP requests will be
forwarded instead of handled via proxy ARP. As mentioned above, we are
running into a UI bug that causes all VNs to be created as "L2 Server" even
when "L2 Gateway" so it sounds like this may be the cause of my problems.
Can you confirm? If so, Is it possible to work around this?

Thanks for all your help!
Dan


On Fri, Jun 19, 2015 at 11:35 PM, Dan Houtz <[email protected]> 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
[email protected]
http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org

Reply via email to