Re: [FROG] VRRP setup with netplan on Ubuntu 20.04
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@ntrv.dk> wrote: Dear Oliver, On Tue, 7 Jul 2020 at 22:04, Oliver O'Boyle <oliver.oboyle@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@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
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@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@ntrv.dk> wrote:
Dear Oliver,
On Tue, 7 Jul 2020 at 22:04, Oliver O'Boyle <oliver.oboyle@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@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
-- :o@>
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@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@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@ntrv.dk> wrote:
Dear Oliver,
On Tue, 7 Jul 2020 at 22:04, Oliver O'Boyle <oliver.oboyle@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@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
-- :o@>
-- :o@>
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@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@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@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@ntrv.dk> wrote:
Dear Oliver,
On Tue, 7 Jul 2020 at 22:04, Oliver O'Boyle <oliver.oboyle@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@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
-- :o@>
-- :o@>
-- :o@>
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@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@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@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@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@ntrv.dk> wrote:
Dear Oliver,
On Tue, 7 Jul 2020 at 22:04, Oliver O'Boyle <oliver.oboyle@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@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
-- :o@>
-- :o@>
-- :o@>
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
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@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@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@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@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@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@ntrv.dk> wrote:
Dear Oliver,
On Tue, 7 Jul 2020 at 22:04, Oliver O'Boyle <oliver.oboyle@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@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
-- :o@>
-- :o@>
-- :o@>
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
-- :o@>
participants (2)
-
Oliver O'Boyle -
Quentin Young