FRRouting / frr

The FRRouting Protocol Suite
https://frrouting.org/
Other
3.35k stars 1.26k forks source link

VRF master interface not visible in main table #1516

Closed EasyNetDev closed 5 years ago

EasyNetDev commented 6 years ago

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

donaldsharp commented 6 years ago

@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?

EasyNetDev commented 6 years ago

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 commented 6 years ago

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

EasyNetDev commented 5 years ago

Issue was fixed meanwhile.

I will close the ticket.

EasyNetDev commented 5 years ago

Issue was fixed meanwhile.

I will close the ticket.