[FROG] VRRP setup with netplan on Ubuntu 20.04

Sat Jul 11 01:01:13 UTC 2020

Yes, agreed. The issue is less that the VM needs these things and more
that it has to be done with such a broad stroke at the host level.
It's like using a sledge hammer to tap in a small nail into your wall
in order to hang your 8x10 picture. If you slip, you end up with a big
ugly hole in your wall...

Oliver

On Fri, 10 Jul 2020 at 17:38, Quentin Young <qlyoung at cumulusnetworks.com> wrote:
>
> 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

-- 
:o@>