-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Comments
@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? |
Hi, My setup is pretty simple: 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. Regards, |
#1607 is the start of the correct handling of this in side of FRR. |
Issue was fixed meanwhile. I will close the ticket. |
1 similar comment
Issue was fixed meanwhile. I will close the ticket. |
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
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
I think is just a fine tuning in VRFs detection and master interfaces.
Kind regards,
Adrian
The text was updated successfully, but these errors were encountered: