odd problem with etherip(4)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

odd problem with etherip(4)

Peter J. Philipp-3
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?

Regards,
-peter

Reply | Threaded
Open this post in threaded view
|

Re: odd problem with etherip(4)

Martin Pieuchot
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@.