[FROG] VRRP setup with netplan on Ubuntu 20.04

[Quentin Young]

Glad you solved it.

Unfortunately the aforementioned policy exceptions to allow MAC spoofing
are necessary if you want to run a protocol whose core function is built
around MAC spoofing ;-)

Good reminder to document it.

On Fri, Jul 10, 2020, 3:44 PM Oliver O'Boyle <oliver.oboyle at gmail.com>
wrote:

> I believe I have resolved this issue for my particular environment,
> which is running on a pre vsphere 6.7 environment.
>
> It appears that Promiscuous mode, Mac Address Changes, and Forged
> Transmits needs to be set to Accept as Policy Exceptions on the
> virtual port group or above on the vsphere host.
>
> A related issue is being tracked here:
> https://github.com/FRRouting/frr/issues/5386
>
> I will agree with them that these policy exceptions reduce security on
> the host/network.
>
> I have yet to completely test this setup now but i'm receiving
> consistent echo replies from the VRRP addresses now. No more drops.
>
> Oliver
>
> On Fri, 10 Jul 2020 at 14:23, Oliver O'Boyle <oliver.oboyle at gmail.com>
> wrote:
> >
> > 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@>
>
>
>
> --
> :o@>
>
> _______________________________________________
> frog mailing list
> frog at lists.frrouting.org
> https://lists.frrouting.org/listinfo/frog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/frog/attachments/20200710/742f5e0e/attachment-0001.htm>