Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Leak the default route and private routes to the default VRF of firewalls #30

Open
mwindower opened this issue Sep 24, 2020 · 1 comment
Assignees

Comments

@mwindower
Copy link
Contributor

mwindower commented Sep 24, 2020

Idea would be to import the private tenant VRF and the internet VRF to the default VRF.
Therewith we get out of the default VRF.

The backwards routes are problematic: Cumulus has a list of constraints for route leaking: https://docs.cumulusnetworks.com/cumulus-linux-37/Layer-3/Virtual-Routing-and-Forwarding-VRF/#vrf-route-leaking

One of those is:

VRF route leaking is not supported between the tenant VRF and the default VRF with onlink next hops (BGP unnumbered).

This is exactly the case what we need for the backward routes.

One of the ideas to solve this is to get the routes to the default VRF with a dedicated pair of route export and route import statements.

@mwindower mwindower self-assigned this Sep 24, 2020
@mwindower mwindower changed the title Leak the default route to the default VRF of firewalls Leak the default route and private routes to the default VRF of firewalls Sep 25, 2020
@mwindower
Copy link
Contributor Author

One of the maintainers of FRR reported, that the aforementioned restriction was lifted "some time ago"; so "import vrf default" is in fact allowed (with vtysh and conf t we get autocompletion for it!).

And in fact we see all necessary routes and TCP sessions start to initiate:

  • the route that gets imported from the tenant VRF to the default VRF looks like this: 10.130.10.2 via dev vlanXYZ src 10.130.10.1 (.1 is the firewall, .2 a worker machine)
  • packets initiated from a user space program in the default VRF with target 10.130.10.2 would get 10.130.10.1 as source IP (which is the IP of the SVI that is enslaved to the tenant VRF)
  • backwards the packets get only to the tenant SVI because it holds the IP 10.130.10.1 in the tenant VRF
  • the use space program in the default VRF does not see the backward package

/cc @majst01

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant