[FROG] VRF Configuration

[Dan White]

Thank you for your detailed and considered response Donald. I will lab this
up.

On 02/10/18 12:22 -0500, Donald Sharp wrote:
>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.