You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
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:
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.
The text was updated successfully, but these errors were encountered: