Filter connected routes from being learned ?
Hello, I am trying to prevent FRR from picking up a route - let’s call it “mgmt”. These are Ubuntu 16.04 hosts, so I’m using /etc/network/interfaces. I’m using some manual post-up commands to take one of my NICs and put it into the “mgmt” table (already added to /etc/iproute2/rt_tables). This is working as intended. The issue is that FRR is still picking this up as a connected route. I don’t know enough about the innards of FRR, but I’m guessing it’s picking it up from the interface structure in the kernel - as my route table commands have expunged it from the global/default table. So on with my real question - is there a way I can filter this ? I had thought/hoped it would be this: http://docs.frrouting.org/en/latest/zebra.html#zebra-route-filtering Either that doesn’t do what I had hoped - or I’m configuring it wrong. My thought process was to make a PL with a permit matching my mgmt route (10.255.0.0/16) - and a route-map with a deny matching on the PL. Then I would ‘ip protocol connected route-map DENY-MGMT’. I’ve tried this, and restarted FRR, but no matter what - this route keeps finding it’s way back in as “connected”. Any pointers would be greatly appreciated. Thanks. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible."
Brandon - Sounds like you really want vrf's. Configure a vrf interface and enslave the appropriate interfaces donald On Fri, Jun 29, 2018 at 12:04 AM, Brandon Applegate <brandon@burn.net> wrote:
Hello,
I am trying to prevent FRR from picking up a route - let’s call it “mgmt”. These are Ubuntu 16.04 hosts, so I’m using /etc/network/interfaces. I’m using some manual post-up commands to take one of my NICs and put it into the “mgmt” table (already added to /etc/iproute2/rt_tables). This is working as intended.
The issue is that FRR is still picking this up as a connected route. I don’t know enough about the innards of FRR, but I’m guessing it’s picking it up from the interface structure in the kernel - as my route table commands have expunged it from the global/default table.
So on with my real question - is there a way I can filter this ? I had thought/hoped it would be this:
http://docs.frrouting.org/en/latest/zebra.html#zebra-route-filtering
Either that doesn’t do what I had hoped - or I’m configuring it wrong. My thought process was to make a PL with a permit matching my mgmt route (10.255.0.0/16) - and a route-map with a deny matching on the PL. Then I would ‘ip protocol connected route-map DENY-MGMT’. I’ve tried this, and restarted FRR, but no matter what - this route keeps finding it’s way back in as “connected”.
Any pointers would be greatly appreciated. Thanks.
-- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible."
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
* Apologies to Donald for getting it twice. I didn’t cc: the list the first time around.
On Jun 29, 2018, at 6:41 AM, Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Brandon -
Sounds like you really want vrf's. Configure a vrf interface and enslave the appropriate interfaces
donald
Hey Donald, Thanks for the pointer. After I posted this I did try to play around with vrf functionality. Seems like I’m missing some minimal config to make the vrf active. In the Cisco IOS world on some platforms, this bit of config is the RD (even if you aren’t doing BGP or using the RD). The vrf won’t “come alive” until it has this. Is there something similar in FRR ? As you might be able to tell - my use case is very minimal - just trying to “hide” an interface/route. Here’s what I get: -- student1-r1(config)# vrf mgmt student1-r1(config-vrf)# exit student1-r1(config)# int ens160 vrf NAME The VRF name mgmt student1-r1(config)# int ens160 vrf mgmt % VRF mgmt not active -- -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible."
Brandon - You'll want to read this: https://www.netdevconf.org/1.1/proceedings/slides/ahern-vrf-tutorial.pdf FRR does not create VRF's. There are other subsystems which do it better than FRR. donald On Fri, Jun 29, 2018 at 10:10 AM, Brandon Applegate <brandon@burn.net> wrote:
* Apologies to Donald for getting it twice. I didn’t cc: the list the first time around.
On Jun 29, 2018, at 6:41 AM, Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Brandon -
Sounds like you really want vrf's. Configure a vrf interface and enslave the appropriate interfaces
donald
Hey Donald,
Thanks for the pointer. After I posted this I did try to play around with vrf functionality. Seems like I’m missing some minimal config to make the vrf active. In the Cisco IOS world on some platforms, this bit of config is the RD (even if you aren’t doing BGP or using the RD). The vrf won’t “come alive” until it has this.
Is there something similar in FRR ? As you might be able to tell - my use case is very minimal - just trying to “hide” an interface/route. Here’s what I get:
-- student1-r1(config)# vrf mgmt student1-r1(config-vrf)# exit student1-r1(config)# int ens160 vrf NAME The VRF name mgmt student1-r1(config)# int ens160 vrf mgmt % VRF mgmt not active --
-- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible."
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
On Jun 29, 2018, at 11:04 AM, Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Brandon -
You'll want to read this:
https://www.netdevconf.org/1.1/proceedings/slides/ahern-vrf-tutorial.pdf
FRR does not create VRF's. There are other subsystems which do it better than FRR.
Thanks again. I wasn’t aware of the VRF specific work that had been done from Cumulus and in the kernel. In my head I (naively) thought that rt_tables were “VRFs”. Very enlightening. I got the basic VRF interface enslavement working, but getting things to bind to it (i.e. sshd) is entirely another trick. Digging there I see ‘ip vrf exec’, but from it’s notes: — This command requires the system to be booted with cgroup v2 (e.g. with systemd, add systemd.unified_cgroup_hierarchy=1 to the kernel command line). — I think this rabbit hole might be a bit too deep for me at the moment, but at least (I think) I see the bits and pieces required to put it all together. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible."
participants (2)
-
Brandon Applegate -
Donald Sharp