Advertise routes between VRFs

[babakip]

Hi,

This is the main question: How a VRF can advertise a route which is learned through iBGP to another VRF

But let me elaborate it little more.

First, explanation:

I have created three VRFs under one router and one BGP instance. They are named L-VRF, M-VRF, and R-VRF. Their connection is like this:

L-VRF <-> M-VRF <-> R-VRF

L-VRF & M-VRF can import/exports their routes. M-VRF & R-VRF also have their own import/export to exchange their route.

In this case M-VRF learned routes from both L-VRF and R-VRF thorough BGP, but L-VRF doesn't have route from R-VRF and vice versa.

Second, question:

How can I force M-VRF to advertise its BGP learned route from L-VRF to R-VRF and from R-VRF to L-VRF ?

There is no IGP between them and because M-VRF learned the routes from BGP it doesn't advertise it.

Third, config:

ip vrf L-VRF

 rd 123:1

 route-target export 123:5

 route-target import 123:20

!

ip vrf M-VRF

 rd 123:2

 route-target export 123:20

 route-target import 123:5

 route-target import 123:30

!

ip vrf R-VRF

 rd 123:3

 route-target export 123:30

 route-target import 123:20

interface Ethernet1/1

 ip vrf forwarding L-VRF

 ip address 5.5.5.5 255.255.255.0

!

interface Loopback20

 ip vrf forwarding M-VRF

 ip address 20.20.20.20 255.255.255.0

!

interface Loopback30

 ip vrf forwarding R-VRF

 ip address 30.30.30.30 255.255.255.0

!

router bgp 123

 bgp log-neighbor-changes

 redistribute connected

 redistribute static

 !

 address-family ipv4 vrf L-VRF

  redistribute connected

 exit-address-family

 !

 address-family ipv4 vrf M-VRF

  redistribute connected

 exit-address-family

 !

 address-family ipv4 vrf L-VRF

  redistribute connected

 exit-address-family

I would appreciate your answer and your time in advance.

Bob

[Giuseppe Larosa]

Hello Bob,

what you see is a wanted behaviour:

a VRF cannot export a route if the route has been previously imported (coming from backbone on address-family VPNv4). This is a consistency check that cannot be bypassed it would defeat route control in L3 VPN.

You have built an HUB and Spoke topology with M-VRF acting as HUB and the other two VRFs are Spoke that can talk only with HUB.

HUB can talk with both Spokes.

All you can do is to advertise a default route from M-VRF in this way communication between Spokes is possible going through the HUB site, but not directly.

If you add import statements on L-VRF and R-VRF you can import the respective routes directly from VPNv4 address space, but communication between L-VRF and R-VRF would become direct without going through HUB VRF site M-VRF.

Hope to help

Giuseppe

[babakip]

Hi Giuseppe,

Thanks for your answer. My explanation is part of a design case that traffic from L-VRF to R-VRF must pass through M-VRF. That's why I'm looking for a solution that L-VRF can learn R-VRF's route from M-VRF.

You are right that the BGP's learned route will not advertise but I was hope to do a trick to make it possible.

Br,

Bob

[Giuseppe Larosa]

Hello Bob,

all you need to do is to advertise a default route from M-VRF to have an HUB and Spoke topology with Spoke to Spoke communication going via the HUB vrf site.

This is what is actually done and that was even done before in Frame-Relay hub and spoke overlay networks.

Edit:

if the traffic at HUB site has to be sent out to an external device like a firewall to be processed you need a modified design called Central Site: actually the HUB site will use two different VRFs in order to make the traffic from Spoke to Spoke to be processed by the external device (typically a firewall or other security appliance)

Relaxing the consistency check would provide chance for routing loops and incorrect routing information.

Hope to help

Giuseppe

[babakip]

Thanks Giuseppe,

Your solution would work if L-VRF and R-VRF haven't had their own default route to somewhere else. Generally it is something like this:

Left-gateway-router <----   L-VRF <-> M-VRF <-> R-VRF  ---->   Right-gateway-router

So if I advertised a default route from M-VRF it destroys the default route on L&R VRFs.

I though to create a specific static route on L-VRF to reach R-VRF through M-VRF but it seems it is not possible to have a static route destined to an loop back. This is the error when I try to create a static route:

R1(config)#ip route vrf L-VRF 30.30.30.0 255.255.255.0 loopback 20
% For VPN or topology routes, must specify a next hop IP address if not a point-to-point interface

R1(config)#ip route vrf L-VRF 30.30.30.0 255.255.255.0 loopback 20 20.20.20.20
%Invalid next hop address (it's this router)

Do you have any suggestion to how create such a static route?

Br,

Bob

[omz]

Hi Bob

"You can not configure two static routes to advertise each prefix between the VRFs, because this method is not supported—packets will not be routed by the router. To achieve route leaking between VRFs, you must use the import functionality of route-target and enable Border Gateway Protocol (BGP) on the router. No BGP neighbor is required."

https://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/multiprotocol-label-switching-vpns-mpls-vpns/47807-routeleaking.html

[Giuseppe Larosa]

Hello Bob,

if you cannot send a simple default route from the HUB VRF you should think of using aggregate routes.

I mean for example that if L-VRF has the IP subnet 10.10.1.0/24 and the R-VRF has IP subnet 10.20.1.0/24

You can use subinterfaces or SVI (interface vlan ) as VRF access links

like

interface gi0/0.100

enc doto1q 100

vrf forwarding L-VRF

ip address 10.10.1.1 255.255.255.0

the same for the HUB VRF

interface gi0/0.300

enc dot1q 300

vrf forwarding M-VRF

ip address 10.30.10.1 255.255.255.0

!

ip route vrf M-VRF 10.10.0.0 255.255.240.0 10.30.10.2

ip route vrf M-VRF 10.20.0.0 255.255.240.0 10.30.10.2

! to create a static ARP entry in VRF for the next-hop

! syntax to be checked : edit verified should be the following:

arp vrf M-VRF 10.30.10.2 0001.0001.0001 encapsulation ARPA

Note: the interface gi0/0 has to be connected to a switch port so that it can become up/up as well as subig gi0/0.300.

router bgp

address-family ipv4 vrf M-VRF

red connected

red static

!

If your IP addressing plane for L-VRF and R-VRF has no overlapping subnets you can create less specific routes like in the example above in M-VRF and then  you can advertise to the other spoke.

It is important that the new routes are less specific to avoid problems with the real subnets in L-VRF and R-VRF.

You can even use an export-map to set different route targets for the aggregate static routes.

Let me know if this approach can work for you

Hope to help

Giuseppe

[babakip]

Thanks for your detail explanation. The limitation to implement it "in my case" is M-VRF and R-VRF have to be as loopback not SVI or physical interface.

 As conclusion on my case:

 * There is no way to advertise a route from M-VRF to R-VRF if that route is already learned by MP-BGP and has placed into M-VRF routing table. Am I right ?

Something else also came to my mind as a solution but result is not as I expected! Do you have any comment here why network 8.8.8.0/24 is not advertise from M-VRF to R-VRF?! This network is in M-VRF routing table (not learned by MP-BGP. I put it statically) and I put it under the M-VRF address-family in order to advertise !

router bgp 123

 !--- Lines omitted

 !

 address-family ipv4 vrf M-VRF

  network 8.8.8.0 mask 255.255.255.0

  redistribute connected

 exit-address-family

 ip route vrf M-VRF 8.8.8.0 255.255.255.0 Ethernet1/1 5.5.5.1

R1#sh ip route vrf M-VRF

Gateway of last resort is not set

       5.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

B        5.5.5.0/24 is directly connected (L-VRF), 00:10:35, Ethernet1/1

L        5.5.5.5/32 is directly connected, Ethernet1/1

      8.0.0.0/24 is subnetted, 1 subnets

S        8.8.8.0 [1/0] via 5.5.5.1, Ethernet1/1

      20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C        20.20.20.0/24 is directly connected, Loopback20

L        20.20.20.20/32 is directly connected, Loopback20

      30.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

B        30.30.30.0/24 is directly connected (R-VRF), 00:10:35, Loopback30

L        30.30.30.30/32 is directly connected, Loopback30

R1#sh ip route vrf R-VRF

Gateway of last resort is not set

       20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

B        20.20.20.0/24 is directly connected (M-VRF), 00:11:29, Loopback20

L        20.20.20.20/32 is directly connected, Loopback20

      30.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C        30.30.30.0/24 is directly connected, Loopback30

L        30.30.30.30/32 is directly connected, Loopback30

Br,

Bob 

[Giuseppe Larosa]

Hello Bob,

in real world you need to have access links in VRFs to make something useful.

A)

>> * There is no way to advertise a route from M-VRF to R-VRF if that route is already learned by MP-BGP and has placed into M-VRF routing table. Am I right ?

This is correct a VRF is not allowed to re-export in VPNv4 a route that was previously imported from VPNv4 address space.

B) about your attempt to advertise network 8.8.8.0/24 from VRF M-VRF to VRF R-VRF the following considerations apply:

Your configuration violates the principle explained in previous point A because the static next-hop belongs to a network learned from L-VRF.

>> ip route vrf M-VRF 8.8.8.0 255.255.255.0 Ethernet1/1 5.5.5.1

This looks like correct by itself but the specified next-hop is NOT out of eth1/1 because

L        5.5.5.5/32 is directly connected, Ethernet1/1

And

B        5.5.5.0/24 is directly connected (L-VRF), 00:10:35, Ethernet1/1 ! means eth1/1 is associated to L-VRF not to M-VRF

So the static next-hop belongs to a network 5.5.5.0/24 learned by L-VRF in M-VRF.

This allows installation of the static route locally on VRF M-VRF, but it prevents the capability to advertise 8.8.8.0/24 to R-VRF.

S        8.8.8.0 [1/0] via 5.5.5.1, Ethernet1/1

You need to use a LAN interface in M-VRF to be able to advertise a static route pointing to it, as I have explained in my previous post.

Hope to help

Giuseppe

[babakip]

Thanks Giuseppe,

You pointed to something intersting which I didn't attention:

So the static next-hop belongs to a network 5.5.5.0/24 learned by L-VRF in M-VRF.

This allows installation of the static route locally on VRF M-VRF, but it prevents the capability to advertise 8.8.8.0/24 to R-VRF.

By considering this I changed the route-target imp/exp for M-VRF to not import network 5.5.5.0/24 from L-VRF (below output). Now as you  can see there is no BGP leraning for 5.5.5.0/24 on M-VRF but still network 8.8.8.0/24 is not advertised to R-VRF by M-VRF:

address-family ipv4 vrf M-VRF
network 8.8.8.0 mask 255.255.255.0
redistribute connected

R1#sh ip route vrf M-VRF

Gateway of last resort is not set

8.0.0.0/24 is subnetted, 1 subnets
S 8.8.8.0 [1/0] via 5.5.5.1, Ethernet1/1
20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 20.20.20.0/24 is directly connected, Loopback20
L 20.20.20.20/32 is directly connected, Loopback20
30.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 30.30.30.0/24 is directly connected (R-VRF), 00:14:19, Loopback30
L 30.30.30.30/32 is directly connected, Loopback30

R1#sh ip route vrf R-VRF

Gateway of last resort is not set

20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 20.20.20.0/24 is directly connected (M-VRF), 00:14:09, Loopback20
L 20.20.20.20/32 is directly connected, Loopback20
30.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 30.30.30.0/24 is directly connected, Loopback30
L 30.30.30.30/32 is directly connected, Loopback30

What can be the problem now ?!

Br,

Bob

[babakip]

Deleted.\

[omz]

I think .. you are talking about Half-Duplex VRF ..

https://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/hdvrfdyn.html#wp1096844

is that right?

[babakip]

Hi OMZ,
Well Half-Duplex VRF which you mentioned is quite new to me so I'm not if it is really related to my request. By the way thanks for that I should look at that long document maybe it helps.
Br,
Bob

[omz]

Hi Bob

You mentioned - "My explanation is part of a design case that traffic from L-VRF to R-VRF must pass through M-VRF. That's why I'm looking for a solution that L-VRF can learn R-VRF's route from M-VRF."

This feature uses two unidirectional VRFs to forward IP traffic between the spokes and the hub PE router:

The upstream VRF forwards IP traffic from the spokes toward the hub PE router. 

The downstream VRF forwards traffic from the hub PE router back to the spokes.

You can use this feature if you don't want to allow direct spoke-to-spoke traffic and want everything to go via hub site.