VRF Lite - Route leaking between global and vrf

[Mauro Dante Doppioni]

Hi everybody.

I have a multiVRF CE with 1 additional VRFs configured.

My need is to permit the connectivity to the local loopback (that must be on the global routing table) from to the networks coming from the additional vrf

The configuration is something like:

ip vrf red

rd 101:101

interface Loopback10

ip address 1.1.1.1 255.255.255.255

interface Loopback100

ip vrf forwarding red

ip address 2.2.2.2 255.255.255.255

interface Serial1/0

mtu 1500

no ip address

encapsulation frame-relay IETF

!

interface Serial1/0.101 point-to-point

ip unnumbered Loopback10

no cdp enable

frame-relay interface-dlci 10

!

interface Serial1/0.102 point-to-point

ip vrf forwarding red

ip unnumbered Loopback100

no cdp enable

frame-relay interface-dlci 100

!

What I need is also the looback 10 visible from the vrf red, Serial1/0.102

Thanks in advance

Mauro

[Peter Paluch]

Hello Mauro,

The simplest solution would be to simply create yet another loopback with the same IP address as the Loopback10, and assign it to the red VRF. Regardless of which loopback would an IP station talk to, it would always talk to your router, as all addresses on all interfaces in arbitrary VRFs still belong to your router. Would this solve your requirement?

It is possible to either inject routes from global routing table into your red VRF, or install a static route into your red VRF to point to the loopback IP address in the global routing table. However, this would also require that the global routing table is populated with networks from the red VRF so that if someone from the red VRF talks to the "global" loopback, the router is capable of responding. This would complicate the setup, and if the VRFs and global routing table used overlapping networks, this would be very hard, if not impossible to solve. My previous suggestion avoids this hassle.

Think about this and let us know.

Best regards,

peter

[Mauro Dante Doppioni]

Peter,

thanks for your reply.

The problem is that I must use the "original" looback under the global, as it is used as h323 gateway.

So, the second solution seem to me the only one viable, but how can I set a static route from the vrf to the global? I do not have a next hop, as it is directly connected.

I also tried the "import ipv4 unicast map" command under the vrf red. I was able ping the loopback from outside (red vrf) but I was not able ping anything outside from the global, even if I add a static route on the global pointing the subinterface under the vrf.

regards

Mauro

[Peter Paluch]

Hello Mauro,

Alright, I understand.

Probably the easiest way to accomplish what you need is to use the import map - however, in order to do this, you must run a BGP process because this import is performed by the BGP process. You do not need to define any neighbors whatsoever, you just need to run a BGP process locally.

Your configuration should look as follows:

ip vrf red
 rd 101:101
 import ipv4 unicast map Global2VRF
!
ip prefix-list G2V permit 1.1.1.1/32
!
route-map Global2VRF permit 10
 match ip address prefix-list G2V
!
router bgp 65535
 redistribute connected route-map Global2VRF
 ! Or alternatively: network 1.1.1.1 mask 255.255.255.255
!
ip route X.X.X.X 255.255.255.255 Serial1/0.102

Here, I assume running a BGP process in the AS 65535 and using it to import the 1.1.1.1/32 prefix into the VRF red. In order for this to happen, the prefix must first be injected into BGP. You can either redistribute it (I am using the same route-map to filter the redistributed networks and to allow their import into VRF red) or you may directly inject it via the network command.

The VRF red is configured with a simple reference to the route-map Global2VRF that references the prefix-list G2V to filter the appropriate networks to be imported into the VRF red. You may need up to 1 minute for the import to take place (remember, the BGP route table scanner is run every 60 seconds by default).

The ip route X.X.X.X 255.255.255.255 command is used to install a static route towards the neighboring router in the VRF red into the global routing table. Replace the X.X.X.X with the appropriate IP address of the neighbor reachable via S1/0.102.

Give this a try and let me know if it worked. I've replicated this setup in dynagen and it worked for me nicely.

Best regards,

Peter

[Mauro Dante Doppioni]

Hi Peter.

I've tried this approach.

I was able to make the loopback visible from the red but not to reach it.

I think the problem is that in our standard config, to save public IP addresses all the serial sub interfaces are IP unnumbered loopbackx and the ip address of the loopback is the same for all the vrf, global included.

So if I set the static route you suggested, I loose the connectivity from the global to the PE (of course also the ip address of the neighbour is the same for all the vrfs).

Anyway, I will try to set up a specific looback for the red,  test the solutio an let you know.

Mauro

[Mauro Dante Doppioni]

Hi again.

I tried and ...:

1) I can see the route on bgp both on the red vrf of the CE and outside.

2) the "ping vrf red x.x.x.x source loopback 10" (x.x.x.x is an address of the red vrf outside the CE) does work.

3) the "reverse" ping to the 1.1.1.1 from the x.x.x.x address doesn't work

4) the "ping x.x.x.x source loopback 10" doesn't work

It seems to me that the static route doesn't work as expected.

Ciao

Mauro

[Peter Paluch]

Mauro,

If you have done this on a lab topology, can you perhaps send me the configs so I can replicate this? I am starting to get somewhat lost in who can/can't ping whom.

Anyway, to your previous post:

So if I set the static route you suggested, I loose the connectivity  from the global to the PE (of course also the ip address of the  neighbour is the same for all the vrfs).

If you are suggesting that the neighbor IP addresses are identical (which they can safely be if they are placed into various VRFs) then your proposed setup is not going to work. The problem is that for the backward direction from the global routing table to the VRF, you would need to install multiple identical networks into the global routing table, pointing out through different interfaces in different VRFs. Note that from the viewpoint of the global routing table, it would be impossible to distinguish the originating VRF when sending a reply - the route with multiple egress iterfaces would simply appear as a equal-cost multipath route in the routing table.

Best regards,

Peter

[Mauro Dante Doppioni]

Peter, this is the basic config of one of my CEs.

ip vrf green

rd 60000:1

route-target export 60000:101

route-target import 60000:101

!

ip vrf blue

rd 60000:2

route-target export 60000:201

route-target import 60000:201

!

ip vrf red

rd 60000:3

import ipv4 unicast map Global_to_red_map

route-target export 60000:301

route-target import 60000:301

!

!

interface Loopback1

ip address 10.0.0.1 255.255.255.255

!

interface Loopback100

ip address 1.1.1.1 255.255.255.255

!

interface Loopback101

ip vrf forwarding green

ip address 10.0.0.1 255.255.255.255

!

interface Loopback201

ip vrf forwarding blue

ip address 10.0.0.1 255.255.255.255

!

interface Loopback301

ip vrf forwarding red

ip address 10.0.0.1 255.255.255.255

!

!

interface MFR990

no ip address

encapsulation frame-relay IETF

frame-relay multilink bandwidth-class c 1

frame-relay lmi-type ansi

!

interface MFR990.101 point-to-point

ip unnumbered Loopback1

no cdp enable

frame-relay interface-dlci 101 IETF  

!

interface MFR990.102 point-to-point

ip vrf forwarding green

ip unnumbered Loopback101

no cdp enable

frame-relay interface-dlci 102 IETF  

!

interface MFR990.103 point-to-point

ip vrf forwarding blue

ip unnumbered Loopback201

no cdp enable

frame-relay interface-dlci 103 IETF  

!

interface MFR990.104 point-to-point

ip vrf forwarding red

ip unnumbered Loopback301

no cdp enable

frame-relay interface-dlci 104 IETF  

!

!

interface GigabitEthernet0/0

description LAN

ip vrf forwarding red

ip address 172.16.0.1 255.255.255.0

duplex full

speed 100

!

interface Serial0/0/0:0

no ip address

encapsulation frame-relay MFR990

tx-ring-limit 2

tx-queue-limit 2

no arp frame-relay

!

interface Serial0/0/1:0

no ip address

encapsulation frame-relay MFR990

tx-ring-limit 2

tx-queue-limit 2

no arp frame-relay

!

interface Serial0/1/0:0

no ip address

encapsulation frame-relay MFR990

tx-ring-limit 2

tx-queue-limit 2

no arp frame-relay

!

interface Serial0/1/1:0

no ip address

encapsulation frame-relay MFR990

tx-ring-limit 2

tx-queue-limit 2

no arp frame-relay

!

router bgp 65000

no synchronization

bgp log-neighbor-changes

redistribute connected route-map Global_to_red_map

network 10.0.0.1 mask 255.255.255.255

neighbor 10.1.1.1 remote-as 60000

neighbor 10.1.1.1 ebgp-multihop 2

neighbor 10.1.1.1 update-source Loopback1

neighbor 10.1.1.1 activate

no auto-summary

!

address-family ipv4 vrf red

  redistribute connected

  neighbor 10.1.1.1 remote-as 60000

  neighbor 10.1.1.1 ebgp-multihop 2

  neighbor 10.1.1.1 update-source Loopback301

  neighbor 10.1.1.1 activate

  neighbor 10.1.1.1 send-community

  no synchronization

exit-address-family

!

address-family ipv4 vrf blue

  redistribute connected

  neighbor 10.1.1.1 remote-as 60000

  neighbor 10.1.1.1 ebgp-multihop 2

  neighbor 10.1.1.1 update-source Loopback201

  neighbor 10.1.1.1 activate

  neighbor 10.1.1.1 send-community

  no synchronization

exit-address-family

!

address-family ipv4 vrf green

  redistribute connected

  neighbor 10.1.1.1 remote-as 60000

  neighbor 10.1.1.1 ebgp-multihop 2

  neighbor 10.1.1.1 update-source Loopback101

  neighbor 10.1.1.1 activate

  neighbor 10.1.1.1 send-community

  no synchronization

exit-address-family

!

ip route 10.1.1.1 255.255.255.255 MFR990.101

ip route vrf DIGITPA_0002_01004851 10.1.1.1 255.255.255.255 MFR990.102

ip route vrf DIGITPA_0003_01004851 10.1.1.1 255.255.255.255 MFR990.103

ip route vrf DIGITPA_0005_01004851 10.1.1.1 255.255.255.255 MFR990.104

!

ip prefix-list Global_to_red_list seq 10 permit 1.1.1.1/32

!

route-map Global_to_red_map permit 10

match ip address prefix-list Global_to_red_list

!

the PE interface is also unnumbered loopback, the IP address is, obviously, 10.1.1.1

On the red vrf, I have a second CE, connected to another PE, which have the LAN address 172.16.11.0/24.

testCE#sh ip route vrf red 172.16.11.1

Routing entry for 172.16.11.0/24

  Known via "bgp 65000", distance 20, metric 0

  Tag 60000, type external

  Last update from 10.1.1.1, 02:46:07 ago

  Routing Descriptor Blocks:

  * 10.1.1.1, from 10.2.1.1, 02:46:07 ago

      Route metric is 0, traffic share count is 1

      AS Hops 2

      Route tag 60000

testCE#

Now, in this situation, I can see the 1.1.1.1 on the "red" bgp, aslo outside this CE.

testCE#sh ip route vrf red 1.1.1.1   

Routing entry for 1.1.1.1/32

  Known via "bgp 65000", distance 20, metric 0 (connected, via interface), type external

  Routing Descriptor Blocks:

  * directly connected, via Loopback100

      Route metric is 0, traffic share count is 1

      AS Hops 0

testCE#

and I can ping, on the vrf red, the outside address from the loopback100

testCE#ping vrf red 172.16.11.1 source loopback 100

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.11.1, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/21/24 ms

testCE#

now, I have the problem we discussed, as the neighbourind addresses are the same.

I made the following:

1) I shutted down the interface MFR990.101 (the one in global)

2) I removed the related bgp peer

3) I replaced the static "ip route 10.1.1.1 255.255.255.255 MFR990.101" with the static "ip route 10.1.1.1 255.255.255.255 MFR990.104"

but I can't ping the loopback 100 from outside and I can't ping from the global

testCE2#ping vrf red 1.1.1.1 source 172.16.11.1       

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 172.16.11.1

.....

Success rate is 0 percent (0/5)

testCE2#

testCE#ping 172.16.11.1 source loopback 100

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.11.1, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

.....

Success rate is 0 percent (0/5)

testCE#

Then I tried adding the following static routes, without any success:

1) ip route 172.16.11.0 255.255.255.0 MFR990.104

2) ip route 172.16.11.0 255.255.255.0 MFR990.104 10.1.1.1

3) ip route 172.16.11.0 255.255.255.0 10.1.1.1

Regards

Mauro

[Jeremiah Lew Dalumpines]

Hi Peter,

I also want to accomplish this kind of setup but in my setup I want the SVIs from the Global Table to be leaked to the VRF CLIENT_A Routing Table... Is it also possible to this via dynamic routing protocols instead of static route?

Here's my post to the learningnetwork if you have an account:

https://learningnetwork.cisco.com/thread/83763

[Daniel Freitas]

Mauro/Peter,

I was working on some labs about a similar issue. In my scenario I need to perform the redistribution between global OSPF and VRF BGP and found this solution:

(OSPF)-----------------(OSPF| BGP VRF)----------------------(iBGP)

   R1                                     R2                                           R3

All configs were made on R2.

1st - created 2 loopbacks;

2nd - created 2 interface tunnel (each one with source in one loopback and destination to the other loopback);

3rd - The tunnel 1 have the tunnel IP in the GRT and tunnel 2 IP is on the VRF;

4th - created an OSPF process in the VRF and announced the tunnel 2 interface IP on it;

5th - on the global OSPF, announced the tunnel 1 IP;

6th - made the mutual redistribution between VRF OSPF and BGP;

My main concern about this solution is that this GRE tunnel have a smaller MTU on it. In my case, since the real implementation will be on a 6509, I will increase the MTU on it.

Another concern, if you are doing this on a smaller platform could be about CPU utilization for tunnel encapsulation/decapsulation(once I´ve fried a 3750X CPU with a GRE encaps/decaps)

HTH

Dan

[fereis]

Hello,

I have a 6880-X and I used this config with ipv4 and all worked well but I'm trying with ipv6 and I can't do it because there is no import ipv6 unicast map GLOBALRMv6 command only this one this one import map GLOBALRMv6 that doesn't do the same.

I can see the vrf ipv6 routes on the GRT but I can't see the global ipv6 routes on the VRF.

vrf definition PSC
 rd 65000:2
 !
 address-family ipv4
  import ipv4 unicast map GLOBALRMv4
  export ipv4 unicast map GLOBALRMv4
  route-target export 65000:2
  route-target import 65000:2
 exit-address-family
 !
 address-family ipv6
  import map GLOBALRMv6
  export ipv6 unicast map GLOBALRMv6
  route-target export 65000:2
  route-target import 65000:2
 exit-address-family

Can you give me an alternative?

Regards

Fernando