[FROG] VRRP setup with netplan on Ubuntu 20.04

[Oliver O'Boyle]

So the router is returning BOTH macs in the ARP reply. Is that expected?

18:20:52.325688 ARP, Reply lab-migw is-at 00:50:56:bd:d5:0f (oui
Unknown), length 28
18:20:52.325777 ARP, Reply lab-migw is-at 00:00:5e:00:01:01 (oui
IANA), length 28

Oliver

On Fri, 10 Jul 2020 at 12:13, Oliver O'Boyle <oliver.oboyle at gmail.com> wrote:
>
> Hi,
>
> So I'm running into some issues with this setup. The configuration
> applies without any issue and I get my macvlan interfaces etc... . A
> 'show vrrp' in vtysh provides 100% good results.
>
> But the devices on the segment where I configured the vrrp address get
> mixed results. Some see the virtual macs assigned to the macvlan
> devices and some see the mac assigned to the parent vlan2049
> interface, even after flushing arp tables etc.... Pings to the macvlan
> vrrp IP from devices that do see the virtual mac mostly don't get a
> response, though one occasionally does come through. Pings to the vrrp
> IP from devices that don't see the virtual mac are, predictably, not
> getting any response at all.
>
> Device example 1 - cumulus switch eth0 port - DOES NOT see the virtual
> mac of the router's vrrp macvlan:
>
> ? (192.168.145.193) at 00:50:56:bd:d5:0f [ether] on eth0
>
> Device example 2 - windows vm - DOES see the virtual mac of the
> router's vrrp macvlan:
>
> 192.168.145.193       00:00:5e:00:01:01       dynamic
>
> Am I missing something important or is there a bug somewhere?
>
> Oliver
>
>
> On Tue, 7 Jul 2020 at 20:22, Oliver O'Boyle <oliver.oboyle at gmail.com> wrote:
> >
> > Not really, no. This was simple enough and I prefer to keep as close to netplan as possible as I suspect macvlan will eventually be supported.
> >
> > I could be swayed with the right argument, I suppose...
> >
> > O.
> >
> > On July 7, 2020, at 4:19 PM, Chriztoffer Hansen <ch at ntrv.dk> wrote:
> >
> > Dear Oliver,
> >
> > On Tue, 7 Jul 2020 at 22:04, Oliver O'Boyle <oliver.oboyle at gmail.com> wrote:
> > > To close the loop:
> > >
> > > I ended up going down the /etc/networkd-dispatcher route. I put:
> > >
> > > [ -e /etc/network/if-up.d ] && /bin/run-parts /etc/network/if-up.d
> > > exit 0
> > >
> > > into a script in that directory, then:
> > >
> > > if ip link show vlan2049 | grep -sq 'state UP'; then
> > >     ip link add vlan2049-4 link vlan2049 addrgenmode random type
> > > macvlan mode bridge
> > >     ip link set dev vlan2049-4 address 00:00:5e:00:01:01
> > >     ip addr add 192.168.145.194/26 dev vlan2049-4
> > >     ip link set dev vlan2049-4 up
> > >
> > >     ip link add vlan2049-6 link vlan2049 addrgenmode random type
> > > macvlan mode bridge
> > >     ip link set dev vlan2049-6 address 00:00:5e:00:02:01
> > >     ip addr add 2610:139:c001:3f:1801:f20a::5/64 dev vlan2049-6
> > >     ip link set dev vlan2049-6 up
> > > fi
> > > exit 0
> > >
> > > into /etc/network/if-ip.d/
> > >
> > > I figured this would allow someone not familiar with the workaround to
> > > perhaps more easily figure out what was happening.
> > >
> > > It works well enough, but it's ugly AF... I'll probably make it a bit
> > > smarter now, but it works.
> >
> > You never considered going down the system-networkd route?
> >
> > --
> >
> > Cheers,
> > CHRIZTOFFER
> >
> > _______________________________________________
> > frog mailing list
> > frog at lists.frrouting.org
> > https://lists.frrouting.org/listinfo/frog
>
>
>
> --
> :o@>



-- 
:o@>