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

VRF master interface not visible in main table #1516

Closed
EasyNetDev opened this issue Dec 4, 2017 · 5 comments
Closed

VRF master interface not visible in main table #1516

EasyNetDev opened this issue Dec 4, 2017 · 5 comments
Assignees

Comments

@EasyNetDev
Copy link
Contributor

Hi,
Today I've installed first 2 routers with FRR. Very nice job was done with some VRF features. I have to check if the old bugs regarding BGP IPv6 and OSPF route distribution is preferred via a none-backbone area, but is another story.
First test which I've did it it on one router where I have a vrf master interface called vrf-be.
To route-leak some routes I'm using iproute with this command:
ip route add 192.168.2.0/24 dev vrf-be
Unfortunately in FRR is not working because the main VRF is not seeing the vrf-be master interface.
My question is: the master interface shouldn't be visible in all VRFs? In this way it will permit to add routes between VRFs.

Some outputs:
root@sr-Belgium-1:/etc/frr# ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.225 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.181 ms
To check that is working:

sr-Belgium-1# sh ip route 192.168.2.0/24
Routing entry for 192.168.2.0/24
Known via "kernel", distance 0, metric 0

  • directly connected, unknown inactive

sr-Belgium-1#
As you can see FRR is not seeing the vrf-be interface.
sr-Belgium-1# show ip route vrf vrf-be
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, N - NHRP, T - Table,
v - VNC, V - VNC-Direct,
> - selected route, * - FIB route

K * 0.0.0.0/0 is directly connected, unknown inactive
K * 192.168.1.0/24 is directly connected, unknown inactive
C>* 192.168.2.0/24 is directly connected, br0.10

Also from VRF vrf-be. 0.0.0.0/0 is default route on enp4s0 interface in main table and 192.168.1.0/24 direct connected on br0:

sr-Belgium-1# show ip route 192.168.1.0/24
Routing entry for 192.168.1.0/24
Known via "connected", distance 0, metric 0, best

  • directly connected, br0

I think is just a fine tuning in VRFs detection and master interfaces.

Kind regards,
Adrian

@donaldsharp
Copy link
Member

@adrianban -> VRF route leaking has not been implemented yet in FRR. You can do this in the linux kernel currently but the support for it in FRR needs to be added. There needs to be a decent amount of work to get this right. I could put some hacks into place to get the display of 'show ip route' and it's ilk right, but I'm afraid that things like NHT and individual routing daemons doing the right thing here is compromised.

What is your use case here?

@donaldsharp donaldsharp self-assigned this Dec 5, 2017
@EasyNetDev
Copy link
Contributor Author

EasyNetDev commented Dec 6, 2017

Hi,

My setup is pretty simple:
Main VRF to be used towards a IPIP/VPN tunnel and route the traffic of the devices (LAN+WiFi specific SSID) and a secondary VRF which I'm using a separate SSID with a VLAN 10 and that interface is slaved under vrf-be interface.
All traffic which are connected to that SSID on VLAN 10 is directly forwarded towards the local internet.
The other SSID is forwarded via the VPN. I need this setup to separate the 2 networks.
But from vrf vrf-be I've added a static route into the specific table with the 0.0.0.0/0 via local internet ISP with dev enp4s0.
Becasue I'm using different routes in the main table, I couldn't forward the specific traffic only via the local ISP. In this way I've isolated that SSID to use only local ISP.

Of course I can use for the moment iproute static route to route-leak the traffic, but I was curious if the frr will support the route-leak. What I've notice is that the master interface should be visible to the daemons in all VRF, not only in the specific table of the VRF.
In this way zebra should know to add the route between VRFs.

Regards,
Adrian

@donaldsharp
Copy link
Member

#1607 is the start of the correct handling of this in side of FRR.

@EasyNetDev
Copy link
Contributor Author

Issue was fixed meanwhile.

I will close the ticket.

1 similar comment
@EasyNetDev
Copy link
Contributor Author

Issue was fixed meanwhile.

I will close the ticket.

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

2 participants