[FROG] VRF Configuration

Donald Sharp sharpd at cumulusnetworks.com
Sat Feb 10 12:22:50 EST 2018


Dan -

To be clear, the purpose of the default unreachable route in Linux
vrf's is to prevent route lookup from leaving the vrf table itself.
Furthermore we create it with a very large metric so that when FRR
reads this route, it is interpreted with a high admin distance and
high metric.  This allows FRR to install it's own default route for
the vrf and since we'll have a better admin distance FRR will consider
it to win so it will install it into the kernel.

Linux has this feature that if a route lookup in a table does not find
a match that it follows the `ip rule` classification on the system to
know
what table to look into next.  Suppose we have this setup:

sharpd at robot ~/frr2> ip rule show
0: from all lookup local
1000: from all lookup [l3mdev-table]
32766: from all lookup main
32767: from all lookup default

sharpd at robot ~/frr2> sudo vtysh -c "show ip route vrf DONNA"
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, P - PIM, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       > - selected route, * - FIB route


VRF DONNA:
K * 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:00:12
C>* 10.0.4.0/24 is directly connected, dummy4, 00:01:08
C>* 10.0.5.0/24 is directly connected, dummy5, 00:01:36

Suppose a packet comes in with a destination of 4.3.2.1 on dummy4.
The linux kernel knows that dummy4's master is vrf DONNA, so it looks
in DONNA's route table and finds the default unreachable route and
blackholes the packet.  If that default unreachable was not there, due
to the ip rules selection we would use the main table next (the
default vrf) to find a place to shove the packet.  That would be very
undesirable behavior for a vrf in my opinion :).

Now onto route leaking.  The linux kernel allows routes with a nexthop
in any vrf.  What I mean by this is that we need to specifically
specify the outgoing interface.  You can also specify a address and
interface if you want.  So to leak the connected dummy3's(vrf EVA)
interface into DONNA, I would do this(right now):

robot.cumulusnetworks.com# show ip route vrf EVA
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, P - PIM, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       > - selected route, * - FIB route
VRF EVA:
K * 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:20:27
C>* 10.0.1.0/24 is directly connected, dummy1, 00:21:10
C>* 10.0.2.0/24 is directly connected, dummy2, 00:21:16
C>* 10.0.3.0/24 is directly connected, dummy3, 00:21:21   <---- This is in EVA
robot.cumulusnetworks.com#

robot.cumulusnetworks.com# conf t
robot.cumulusnetworks.com(config)# vrf DONNA
robot.cumulusnetworks.com(config-vrf)# ip route 10.0.3.0/24 dummy3
nexthop-vrf EVA
robot.cumulusnetworks.com(config-vrf)# end
robot.cumulusnetworks.com# show ip route vrf DONNA
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, P - PIM, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       > - selected route, * - FIB route
VRF DONNA:
K * 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:24:21
S>* 4.3.2.1/32 [1/0] via 10.0.2.10, dummy2(vrf EVA), 00:11:37
S>* 5.4.3.2/32 [1/0] via 10.0.2.10, dummy2(vrf EVA), 00:08:40
S>* 10.0.3.0/24 [1/0] is directly connected, dummy3(vrf EVA), 00:00:04
  <----- Connected Route leaked.
C>* 10.0.4.0/24 is directly connected, dummy4, 00:25:17
C>* 10.0.5.0/24 is directly connected, dummy5, 00:25:45

So if a route came in to vrf DONNA destined to 10.0.3.0/24 it would be
shoved out dummy3.

Does this answer your question?

I am not sure of a plan to have vpnv4 do the connected route leaking
for you automagically at this point in time.  Maybe Lou might have a
better answer here for you?  I know he is looking at this area much
more closely than I am at this point in time.

donald

On Sat, Feb 10, 2018 at 10:30 AM, Dan White <dwhite at olp.net> wrote:
> On 02/09/18 14:42 -0500, Donald Sharp wrote:
>>
>> Since properly configuring a VRF has become a point of contention,
>> I've started a wiki on how to properly configure VRF's so that you can
>> use them properly with FRRouting:
>>
>>
>> https://github.com/FRRouting/frr/wiki/Configuring-a-VRF-to-work-properly-for-FRR
>
>
> Thank you Donald. This is very useful.
>
> My background is with Netiron, IOS, and JunOS and I have a couple of
> comments
> on VRF leaking, which is not discussed in the above that I that I've seen,
> but is in discussion on dev.
>
> The Tutorial suggests installing a default route with low priority in your
> VRF as a basic step. In a route leaking context this can and will lead to
> disaster in a production environment. I can recall an uncomfortable
> discussion with a bank after leaking a default route into their mpls vrf,
> from within another common (voice) vrf I was configuring. I generally stay
> away from static routes altogether. You can mitigate that risk with
> import/export lists.
>
> Some implementations do leaking much better than others, and the primary
> area of issue that I have is how do you leak connected routes - that is how
> do you leak a local interface/subnet, such as 'int ve 1000', into another
> local vrf, that is not learned through a dynamic routing protocol. Cisco
> does this the moment you configure:
>
> ip bgp vpnv4 <vrf>
>
> and Netiron requires requires ugly route_maps to accomplish the same thing.



More information about the frog mailing list