VRF - Exporting and Importing

[grichardson661]

Hi Folks,

I’m working with MP-BGP. I am trying to import and export routes to and from 3 vrf's within the same Cisco 4948 switch.

Essentially i have 3 vrf's : UAT-VRF , GLOBAL-VRF and INFRA-VRF

Route leaking is configured between the following: UAT-VRF-> GLOBAL-VRF <-INFRA-VRF

I also have filter lists which permit certain routes into UAT and INFRA.

ip vrf INFRA-VRF

rd 65201:3

import IPv4 Unicast map INFRA-VRF-IMPORT

route-target export 65201:3

route-target import 65201:1

route-target import 65201:3

!

ip vrf GLOBAL-VRF

rd 65201:1

route-target export 65201:1

route-target import 65201:3

route-target import 65201:1

route-target import 65201:6

!

ip vrf UAT-VRF

rd 65201:6

import IPv4 Unicast map UAT-VRF-IMPORT

route-target export 65201:6

route-target import 65201:6

route-target import 65201:1

!

Note - the import filters are based around prefix lists which do match the exact route's required.

interface Vlan1130

ip vrf forwarding UAT-VRF

ip address 10.11.130.253 255.255.255.0

standby 130 ip 10.11.130.254

standby 130 priority 150

standby 130 preempt

standby 130 authentication md5 key-string

interface Vlan1067

ip vrf forwarding INFRA-VRF

ip address 10.11.67.253 255.255.255.0

standby 67 ip 10.11.67.254

standby 67 priority 150

standby 67 preempt

standby 67 authentication md5 key-string

interface Vlan2508

ip vrf forwarding GLOBAL-VRF

ip address 10.31.8.253 255.255.255.0

standby 8 ip 10.31.8.254

standby 8 priority 150

standby 8 preempt

standby 8 authentication md5 key-string

router bgp 65201

address-family ipv4 vrf UAT-VRF

  redistribute connected

no synchronization

exit-address-family

address-family ipv4 vrf GLOBAL-VRF

  neighbor 10.31.8.252 remote-as 65201

  neighbor 10.31.8.252 activate

  neighbor 10.31.8.252 send-community both

  no synchronization

exit-address-family

address-family ipv4 vrf INFRA-VRF

  redistribute connected

  no synchronization

exit-address-family

!

Network 10.11.130.0/24 originated in BGP from the UAT VRF (UAT-VRF) with a redistribute connected (as shown above in the BGP configuration). As you can see below the GLOBAL-VRF VRF has the imported route successfully. Now we need to leak the best route out into the INFRA-VRF VRF.

SWITCH#sh ip bgp vpnv4 vrf GLOBAL-VRF 10.11.130.0

BGP routing table entry for 65201:1:10.11.130.0/24, version 1485372

Paths: (2 available, best #2, table GLOBAL-VRF)

Advertised to update-groups:

     1         2         3         4

Local

   10.31.8.252 from 10.31.8.252 (10.21.101.248)

     Origin incomplete, metric 0, localpref 100, valid, internal

     Extended Community: RT:65201:1

Local, imported path from 65201:6:10.11.130.0/24, imported path from 65201:6:10.11.130.0/24

   0.0.0.0 from 0.0.0.0 (10.21.101.249)

     Origin incomplete, metric 0, localpref 100, weight 32768, valid, external, best

     Extended Community: RT:65201:6

     mpls labels in/out nolabel/nolabel(GLOBAL-VRF)

Is this technically possible? Or is this not working as expected due to a loop prevention mechanism?

It seems we cannot export an already imported prefix.

Any comments would be appreciated.

Thanks,

[Muhammad Thanveer]

Hello,

I am not sure to ask this but, may I know how are your vpnv4 routes are getting carried from the global switch to vrfs in the switch.

I mean is there any vpnv4 connectivity or are there any vpnv4 aware tunnels?

What is your protocol for vrfs UAT-VRF to the otherside connected interface and  INFRA-VRF to the connected other interface?

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

[grichardson661]

Hi,

Sorry i'm not sure what you mean.

The route 10.11.130.0/24 is a locally connected interface which is being redistributed into the UAT VRF on the local switch.

This route is then being successfully route leaked into the global VRF on the local switch.

Now we need to leak the same route from the global VRF into the INFRA VRF on the same switch.

The local switch is the same 4948 switch.

Cheers,

Garry

[Muhammad Thanveer]

Hello,

Sorry to confuse you, I understood that for the locally connecets interfaces which are in vrf in the same device there is no necessity of vpnv4 connectivity.

Can you also test this.

ip vrf INFRA-VRF

rd 65201:3

import IPv4 Unicast map INFRA-VRF-IMPORT

route-target export 65201:3

route-target import 65201:1

route-target import 65201:3

route-target import 65201:6

before doing that are the locally originated routes for global vrf are leaked in to infra vrf....??

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

[grichardson661]

Hi, yes that would work but thats not what we are trying to acheive.

We need to route leak from UAT into GLOBAL which works, then leak the same route from GLOBAL into INFRA. As i said in my original post, is it possible to route leak an already imported route into another VRF.

Cheers,

Garry

[Muhammad Thanveer · Accepted solution]

I think its not possible because by the command route-target export you are only exporting the routes which are locally originated.

Not the one whicha re imported from other vrfs. If it is possible with otut leaking the rt at the needed vrf, then it can be a security issue also...

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

[Giuseppe Larosa · Accepted solution]

Hello Garry,

>> Is this technically possible? Or is this not working as expected due to a loop prevention mechanism?

it is not possible and what you see is expected, you need to leak from the VRF that is the real originator of the prefix.

And yes this can be seen as a loop prevention sanity check.

Hope to help

Giuseppe

[grichardson661]

Thanks Giuseppe and thanks Muhammad! Much appreciated.

Back to the drawing board.