On 10/11/17(Fri) 20:22, Peter J. Philipp wrote: > Hi, > > I have an etherip(4) interface in down state, yet I still receive carp's > through it. I don't know how that's possible... > > beta# ifconfig etherip0 > etherip0: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> mtu 1500 > lladdr fe:e1:ba:db:a8:15 > index 35 priority 0 llprio 3 > groups: etherip > media: Ethernet autoselect > status: active > tunnel: inet 10.100.100.1 -> 10.100.100.4 > beta# tcpdump -v -n -i etherip0 -e > tcpdump: listening on etherip0, link-type EN10MB > 20:13:49.199695 00:00:5e:00:01:01 01:00:5e:00:00:12 0800 70: carp 172.16.65.6 > > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=0 demote=0 (DF) > [tos 0x10] (ttl 255, id 43499, len 56) > 20:13:49.199707 00:00:5e:00:01:01 01:00:5e:00:00:12 0800 70: carp 172.16.65.6 > > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=0 demote=0 (DF) > [tos 0x10] (ttl 255, id 43499, len 56) > ^C > 2 packets received by filter > 0 packets dropped by kernel > > The MAC addresses seem wrong they are usually fe:e1:ba:d... something. > > My setup is 2 vmm's having etherip(4)'s to the main host, which is bridged > to a vether(4) with an IP. It looks a little like a tuning fork: > > (carptest1 vmm)----------\ > )-bridge--------(vether if) > (carptest2 vmm)----------/ > > The reason that I can't get a preempt or MASTER->BACKUP to take place is > because somehow these CARP advertisings make it through even though the > int is in down state. > > It looks wrong to me. Can someone concurr?
It looks like an incomplete bug report to me. Creating frustration on both the reporter side and the developer side. Dmesg, full ifconfig output and an mail to bugs@.
