Importing routes from VRF to Global Routing Table

[Dfulgencio]

Hi,

My problem is that i need to import routes from the Global Table Routing to VRF Table.  The is a document from cisco that says how to configure this.

I've already done it, but still not working.

Here is part of the configuration:

ip vrf TEST

  rd 101:1010

  import ipv4 unicast map IMPORT-FROM-GRT

ip prefix-list IMPORT-GRT seq 10 permit 172.16.2.0/24

Route-map IMPORT-FROM-GRT permit 10

   match  ip address IMPORT-GRT

After putting this commands on my router, i can see the route 172.16.2.0/24 in my VRF routing table, but i can't ping it.

There are some others commands that are use int the documentation but are optionals and my router doesn't support it. For example:

interface X/x

   Ip vrf unicast vrf TEST permit....

I don't really know if the ip vrf unicast vrf xxx permit command is mandatory for get this up to work.

Can someone tell me why this is no working?

thanks..

[Amit Aneja]

Do you have the reverse route in the global table for the prefix that is being used as the source in VRF table?

[Amit Aneja · Accepted solution]

Could you also try it using the following doc?

http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml

[Dfulgencio]

Hi ,

Thanks for your response.

How do I have this. Configuring a static routing ?

Can you tell me how?

[boss.silva]

Hello,

Do you have the bgp configured for the vrf using the address-family?    

Regards,

Bruno Silva.

[Dfulgencio]

Hi Silva,

I don’t get you. This is the scenario:

I have configure VRF-LITE on a router. I did this because in the CE I have to different customers. One of the customer is in the global routing table,

The other one in the VRF.. There is a Server in the VRF Table which is going to be used for Help-Desk Remote Desktop Access. A support Team will

Use this server to gain access to Computers connected in the Global Routing Table.

This is the reason I need to leak routes from GRT-VRF and from VRF-GRT.

When you say: Do you have the bgp sessions established between the global routing table to the vrf?

I don’t understand what you mean. I have a bgp session stablished between the CE-PE for both: GRT and VRF. Here is part of the configuration:

PE-SITE:

Router bpg 2245

Address-family ipv4 vrf XXXX

Neighbor 10.20.0.2 remote-as 65000

Neighbor 10.20.0.2 active

Neighbor 10.20.0.2 as-override

Neighbor 10.30.0.2 description GRT PEER

Router bpg 2245

Address-family ipv4 vrf YYYY

Neighbor 10.30.0.2 remote-as 65000

Neighbor 10.30.0.2 active

Neighbor 10.30.0.2 as-override

Neighbor 10.30.0.2 description VRF-LITE PEER

CE-GRT:

=======

Interface fa0/0

Ip add 10.20.0.2 255.255.255.252

Description CONNECT TO PE vrf XXXXX

• all other commands no presented ****

Interface lo 172

Ip add 172.16.1.1 255.255.255.0

Description for TESTING GRT-VRF IMPORT

Router bgp 65000

Neighbor 10.20.0.1 remote-as 2245

Neighbor 10.20.0.1 description GRT PEER

Network 172.16.1.0 mask 255.255.255.0

Address-family ipv4 vrf VRF-LITE

Neighbor 10.30.0.1 remote-as 2245

Neighbor 10.30.0.1 active

Neighbor 10.30.0.1 as-override

Neighbor 10.30.0.1 description VRF-LITE PEER

Ip vrf VRF-LITE

Rd 100:1010

import ipv4 unicast map GRT2VRF

ip prefix-list IMPORT seq 10 permit 172.16.1.0/24

route-map GRT2VRF permit 10

match ip address IMPORT

Interface fa0/1

Ip vrf forwarding VRF-LITE

Ip add 10.30.0.2 255.255.255.252

The configuration is something like this. Some commands are not included, but this are the most importante.

Thanks

[boss.silva · Accepted solution]

Hello,

Sorry for not being specific.

Please add the "redistribute connected" to the address-family configuration of the CE router. So far that's the only thing i see that is missing to be added on your configuration.

If the problem persists, please run a debug ip packet to see what the router is doing with the ping packets (make sure to run on both PE and CE routers).

Regards,

Bruno Silva.

[Vincent La Bua]

May be something assumed but are you specifying the vrf in the ping syntax?

Sent from Cisco Technical Support iPhone App

[Dfulgencio]

Hi,

Yes I specify the vrf when I ping.

[Amit Aneja]

I just tried the same setup. The problem is the same as I guessed earlier that the VRF sees the route as it has been leaked from global to VRf using "import", but, global table does't know about the source that you take to ping 172.16.1.0/24, so, you don't see the replies coming.

When you ping that route from VRF, s=10.30.0.2, d=172.16.1.1

Reply from global should be s=172.16.1.1, d =10.30.0.2

What we are suppose to tell the global routing table is that where the destination (10.30.0.2)

I tried multiple ways like adding a static route for 10.30.0.2 in global pointing towards fa0/1 & played with ARP as well....didn't work for me. I guess this is because the hack doesn't work on a single router.

Can you try the following route on your setup?

ip route 10.30.0.0 0.0.0.3 fa0/1

In your case, since fa0/0 is part of global, that makes it difficult to leak back from VRF->global.

Had it been in any vrf, it would have been easier.

address-family ipv4 vrf VRF-LITE1    <<<

redistribute connected

address-family ipv4 vrf VRF-LITE

redistribute connected

So, I don't think it is going to work this way from the same router. If anyone has done it , feel free to share.

I have a working example where it works perfectly. It is as follows

                     VRF A
10.1.1.0--R1---------Fa0/0--R2--Fa0/1---------R3--20.1.1.0
             1.1.1.x                  2.2.2.x
      


----

ip vrf a
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
!
interface FastEthernet0/0
 ip vrf forwarding a
 ip address 1.1.1.2 255.255.255.0
 duplex auto
 speed auto
!
!
interface FastEthernet0/1
 ip address 2.2.2.2 255.255.255.0
 duplex auto
 speed auto
!
!
ip route 1.1.1.0 255.255.255.0 FastEthernet0/0
ip route 10.1.1.0 255.255.255.0 1.1.1.1
ip route vrf a 2.2.2.0 255.255.255.0 FastEthernet0/1 2.2.2.3 global
ip route vrf a 20.1.1.0 255.255.255.0 FastEthernet0/1 2.2.2.3 global

[Dfulgencio]

Hi,

Thanks all for your help.

The problem was solved with a combination of static routes from GRT-VRF and VRF-GRT and redistributing the

connected interfaces in VRF.

Again thanks all for your support.

[boss.silva]

Please post the final config

Regards,

Bruno Silva.