Hi,

We're in the process of updating our boxes from 10.1 to 10.3. This has gone OK for the simpler cases - but I seem to have found a couple of issues with the way 10.3 handles both configuring VLANs and actual traffic on VLANs.


On our box to be upgraded, our /etc/rc.conf has:

cloned_interfaces="lagg0 lagg1 lagg1.30 lagg1.35"
ifconfig_bge0="up"
ifconfig_bge1="up"
ifconfig_lagg0="laggproto failover laggport bge0 laggport bge1 172.16.50.1 netmask 255.255.255.0"

ifconfig_em3="mtu 1504 up"
ifconfig_em0="mtu 1504 up"
ifconfig_lagg1="laggproto failover laggport em3 laggport em0 192.168.0.2 netmask 255.255.255.0 mtu 1504"
ifconfig_lagg1_30="inet 192.168.200.2 netmask 255.255.255.0 mtu 1500"
ifconfig_lagg1_35="inet 192.168.210.2 netmask 255.255.255.0 mtu 1500"


The mtu 'hackery' is needed to avoid MTU issues with VLAN interfaces. The above worked fine under 10.1 - but the same config under 10.3:

- Creates lagg0 correctly, and assigns the 172.16.50.1 IP to it
- Creates lagg1 - and it's VLAN's
- Does not assign 192.168.0.2 to lagg1 (it silently fails to - i.e. no errors logged / shown)

So when the system has finished booting you end up with:

 lagg0    = 172.16.50.1
 lagg1    = no IP assigned
 lagg1.30 = 192.168.200.2
 lagg1.35 = 192.168.210.2

The other thing I've found is, once the box is up:

#ping 192.168.200.1
PING 192.168.200.1 (192.168.200.1): 56 data bytes
ping: sendto: Host is down
^C
--- 192.168.200.1 ping statistics ---
6 packets transmitted, 0 packets received, 100.0% packet loss

Hmm, not good. 192.168.200.1 is a host on the VLAN 30 network (and is up - I'm logged into it on another session). Same happens for the 192.168.210.0/24 network.


Running tcpdump on 192.168.200.1 I see lots of:

11:31:52.956094 ARP, Request who-has 192.168.200.1 tell 192.168.200.2, length 46
11:31:52.956102 ARP, Reply 192.168.200.1 is-at x:x:x:x:x:x, length 28
11:31:53.969140 ARP, Request who-has 192.168.200.1 tell 192.168.200.2, length 46
11:31:53.969148 ARP, Reply 192.168.200.1 is-at x:x:x:x:x:x, length 28

Ok, so the other box can see the ARP requests from the 10.3 box - and issues a reply, but the 10.3 box can't "ping" it.


This gets increasingly weird if I run tcpdump on the 10.3 box. The act of running 'tcpdump -i lagg1.30 -n' actually fixes the problem:


#ping 192.168.200.1
PING 192.168.100.1 (192.168.200.1): 56 data bytes
64 bytes from 192.168.200.1: icmp_seq=0 ttl=64 time=0.257 ms
64 bytes from 192.168.200.1: icmp_seq=1 ttl=64 time=0.168 ms
64 bytes from 192.168.200.1: icmp_seq=2 ttl=64 time=0.320 ms

If I ctrl-c the tcpdump on the 10.3 box at this point - pings stop dead. Restart the tcpdump - pings resume.


Restoring 10.1 on the box fixes this - but I'd obviously rather be using 10.3 now.

Any ideas?

Thanks,

-Karl


_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reply via email to