cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6625
Views
14
Helpful
21
Replies

Why one RT is exported successful, another isn't?

CSCO11020330
Level 1
Level 1

Hi all

Does anyone here have an idea to why i couldn't export one network prefix from  VRF A to VRF B, but I could successfully export a prefix from VRF B into VRF A?

I have attached the stats and config here.

Any advices are welcome and appreciated for your help.

2 Accepted Solutions

Accepted Solutions

Hi Guys,

My 10 cents here.

Robo,

After I read all sorts of articles relating to VRF lite, VRF route leaks are not easily perform by export map with additive keyword. it can accept the RT exchange between VRFs via the first RT or original RT. 

As it is a form of VRF-lite, the extended communities are not exchanged by MPLS Core ( it is lack of "neighb xxxx send-community extended/both" under AF vpnv4 pointing towards core), the 2nd additive extended community RT should not be exported successfully. However, I have my half "successful" example there..... why....?

This is not true. whether its a VRF-Lite or a full blown L3 MPLS VPN, the way the communites work in BGP are the same. Allow me to explain a bit here.

With VRF-Lite although you dont have VPNV4 peering with another BGP speaker the route-targets still end up in the sAFI table(vpnv4) as these RT's are extended communities and must be available in MP-BGP to be picked up by other VRF's by using import option.

You would use the "neighb xxxx send-community" only when you have vpnv4 bgp peers . but in this since we are talking about VRF-Lite this is not needed unless these prefixes need to be transported to a another router elsewhere.

I have labbed this for you to show what  I mean and pasting it here

R1#sh run

hostname R1

ip cef

ip vrf A

rd 100:1

route-target export 100:1

route-target import 100:1

route-target import 300:3

!

ip vrf B

rd 200:1

export map B-to-A

route-target export 200:1

route-target import 200:1

!

interface Loopback1

ip address 1.1.1.1 255.255.255.255

!

interface Loopback22

ip vrf forwarding B

ip address 22.22.22.22 255.255.255.255

!

interface GigabitEthernet2/0.10

encapsulation dot1Q 10

ip vrf forwarding A

ip address 10.1.1.1 255.255.255.0

!

interface GigabitEthernet2/0.20

encapsulation dot1Q 20

ip vrf forwarding B

ip address 20.1.1.1 255.255.255.0

!

router bgp 6500

no synchronization

bgp log-neighbor-changes

no auto-summary

!

address-family ipv4 vrf B

  redistribute connected

  no synchronization

exit-address-family

!

address-family ipv4 vrf A

  redistribute connected

  no synchronization

exit-address-family

access-list 10 permit 22.22.22.22

route-map B-to-A permit 10

match ip address 10

set extcommunity rt  300:3 additive

!

end

R1# sh ip bgp vpnv4 vrf B 22.22.22.22

BGP routing table entry for 200:1:22.22.22.22/32, version 8

Paths: (1 available, best #1, table B)

  Not advertised to any peer

  Local

    0.0.0.0 from 0.0.0.0 (1.1.1.1)

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

      Extended Community: RT:200:1 RT:300:3      <<< Has the additive RT added

      mpls labels in/out 18/nolabel(B)

R1#

R1#sh ip route vrf A

Routing Table: A

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     22.0.0.0/32 is subnetted, 1 subnets

B       22.22.22.22 is directly connected, 00:12:58, Loopback22          << imported here

     10.0.0.0/24 is subnetted, 1 subnets

C       10.1.1.0 is directly connected, GigabitEthernet2/0.10

R1#

R1#sh ip route vrf B

Routing Table: B

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     20.0.0.0/24 is subnetted, 1 subnets

C       20.1.1.0 is directly connected, GigabitEthernet2/0.20

     22.0.0.0/32 is subnetted, 1 subnets

C       22.22.22.22 is directly connected, Loopback22      <<<< Exporting this prefix

R1#

R1#sh route-map

route-map B-to-A, permit, sequence 10

  Match clauses:

    ip address (access-lists): 10

  Set clauses:

    extended community RT:300:3 additive     <<< Additive keyword for exporting this to vpnv4 table

  Policy routing matches: 0 packets, 0 bytes

R1#sh ip access-lists

Standard IP access list 10

    10 permit 22.22.22.22 (2 matches)

R1#

BTW: Robo , I am just going thru your config now.

HTH

Kishore

View solution in original post

Hi Kishore

Yes even that what surprises me too..I also labbed it and everything works cool..My earlier explaination in the start of the post was on a different context I was thikning off which did not hold good here

Hi Robo

The alternative solution which you are thinking is a lot more same as the current setup except for instead of using additivie extcommunity we want to use just replace the community value . Well we can try it for sure but I think its better to find out why the additive community was not being applied to the eBGP route in the first place..

Also I was thinking why don't we use an import-map with two terms-one to select the local VRF's targetted RTs and other to select the other VRF's RT with selective prefix list..It will solve our purpose with ease and also get us rid from the export-map config under VRFs

E.G

ip vrf CEA

rd 6413:1

import map CEA_IN

route-target export 64513:100

route-target import 64513:100

route-target import 64513:200

!

ip vrf CEB

rd 64513:2

import map CEB_IN

route-target export 64513:200

route-target import 64513:200

route-target import 64513:100

!

route-map CEA_IN permit 10

match extcommunity CEA

!

route-map CEA_IN permit 20

match ip address prefix-list 100

match extcommunity CEB

!

route-map CEB_IN permit 10

match extcommunity CEB

!

route-map CEB_IN permit 20

match ip address prefix-list 200

match extcommunity CEA

ip extcommunity-list standard CEA permit rt 64513:100

ip extcommunity-list standard CEB permit rt 64513:200

!

ip prefix-list 100 seq 5 permit 10.0.201.1/32

!

ip prefix-list 200 seq 5 permit 10.0.101.1/32

R2#sh ip route vrf CEA

Routing Table: CEA

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks

C       10.0.10.0/30 is directly connected, FastEthernet0/0

C       10.0.111.1/32 is directly connected, Loopback10

B       10.0.101.1/32 [20/0] via 10.0.10.2, 00:04:49

S       10.0.151.1/32 [1/0] via 10.0.10.2

B       10.0.201.1/32 [20/0] via 10.0.20.2 (CEB), 00:04:34

R2#sh ip route vrf CEB

Routing Table: CEB

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

C       10.0.20.0/30 is directly connected, FastEthernet0/1

B       10.0.101.1/32 [20/0] via 10.0.10.2 (CEA), 00:04:52

B       10.0.201.1/32 [20/0] via 10.0.20.2, 00:04:37

S       10.0.251.1/32 [1/0] via 10.0.20.2

R2#

As shown above this helps to get the eBGP routes learnt in another VRF to be imported in separate VRF woth ease..

Hope this helps to provide more clarity on this issue. Please let me know for any clarifications.

Regards

Varma

View solution in original post

21 Replies 21

Hi,

Can you please share the configs please.

Regards,

Smitesh

Hi CSCO11020330

With regards to your issue of the route 10.130.100.0 not being imported into VRF I9003:Mgmt below is my finding:

The Route 10.130.100.0 has a VPN Memebership to VRF V1010:LLL via RT 17669:1010 and received as an EBGP route across MPLS VPN Cloud and hence imported into VRF V1010:LLL  and not into VRF I9003:Mgmt

ip vrf V1010:LLL

rd 17669:1010

export map V1010:LLLtoI9003:Mgmt

route-target export 17669:1010

route-target import 17669:1010

route-target import 17669:900311

PRSIN2MPLSR01#sh ip bgp vpnv4 vrf V1010:LLL  10.130.100.0

BGP routing table entry for 17669:1010:10.130.100.0/24, version 5908

Paths: (1 available, best #1, table V1010:LLL)

  Not advertised to any peer

  65504 65500 65001 4445 4445 65500 65501

    10.130.253.1 from 10.130.253.1 (10.255.48.17)

      Origin IGP, localpref 200, valid, external, best

      Extended Community: RT:17669:1010

The Export Route-Map which is being applied under the two VRF configs only applies to exported routes from the local MPLS PE and the route in question is being imported across MPLS-VPN cloud and that's why the export-map does not works..

However it works for Prefix 10.8.0.0 as its a local Static Route which is being redistributed into VRF I9003:Mgmt and gets tagged with the RT 17669:900311 which is allowed under the Export-Map I9003:MgmttoV1010:LLL and further imported into VRF V1010:LLL via the import RT configuration under VRF

ip route vrf I9003:Mgmt 10.8.0.0 255.255.0.0 10.8.63.4

To fix this issue please include below under VRF I9003:Mgmt

route-target import 17669:1010

Hope this helps to solve your issue. Please let me know for any more clarifications.

Regards

Varma

Thanks for your quick reply Varma.

I disagree. Actually I noticed that the successful export map entry is local static route being redistributed into bgp. Then I went to another PE router which has many inter-VRF leaks configured.  I've seen that router does export some EBGP route prefixes from one VRF to the other. ( I Very carefully verified via ' sh ip bgp vpnv4 vrf x.x.x.x' on that router against the specific export prefixes. )

Another Fact which had made me a heart attack, I also tried import all Rt 17669:1010 into I9003:Mgmt. This action made the entire remote DC down for 10mins, until i hopped on a terminal server and deleted the import all 178669:1010. fortunately it's not a production site. Otherwise I am screwed.

Any other idea?

Thanks

Robo

Hi Robo

I agree that the successful export map entry is the one which is locally present and we can apply outbound communities to locally exported routes only and the same was my reasoning above that it will work for local routes only.

As mentioned above the unsuccsessful export map entry is the one for the external EBGP route learnt across MPLS VPN Cloud as we are importing that route onto the local MPLS-PE and and not re-exporting it and hence the export map does not apply to it.

I do not see any reason for the import of RT Rt 17669:1010 into the VRF I9003:Mgmt not working when same is working for VRF V1010:LLL

Can you please proivde the relevant configuration and show outputs on another working PE which has the same configuration as used on this local PE under question ?

Regards

Varma

I don't mean the route import wasn't successful. It was so successful that it messed around the Mgmt VRF routing table ( I could see all those foreign LLL routes appearing when I consoled access to it).

I indeed have the entire config for the other router tonight after dinner with family. But I may not be able to give you some stats other than config itself (it's my last day in the company). Bet you can tell if the export prefixes are outside or local.

Thanks again Mr. Varma

Hi Varma, I just uploaded the config of the other router. Please see the enclosed file "SYD MPLS Edge#1.txt".

You may see there are a few export maps exporting non local IGP routes.

e.g. 

ip vrf I9003:Mgmt

rd 17669:900301

export map I9003:Ipx-International-to-LH

under that export router map, the there are 3 prefixes are selected-

10.5.16.0/24; 10.6.16.0/24;10.3.16.0/24

none of them is local IGP routes

I had "show ip bgp vpnv4 vrf I9003:Mgmt 10.5.16.0" this morning (or maybe another prefix in these 3), the AS numbers appending it are more than 5. Sorry I can't give you exact stats. But I am 100% sure I saw more than 5 ASN attach to it. That's why I confirmed  "only local routes can be exported or leaked" isn't correct.

Let me know what you think

Thanks!

Robo

I just reviewed the whole config again on the problemed router and found that router is configed as VRF-Lite rather than MP-BGP... it doesn't have address family vpnv4 configured to point back to MPLS core... the name convention of device itself fooled me (xxxMPLSxxx)...

If it is the case, might be better to create another new VRF to collect the prefixes which I wish them to talk to each other.

here might be the solution.

http://www.netcraftsmen.net/resources/blogs/using-bgp-with-vrf-lite-for-shared-service-support.html

What do you think? (I didn't sleep well last night and trying to find a solution even in dream...)

Hi Robo

Sorry got held up yesterday with work so could not reply timely..

I did take a look at the link provided and it also mentions the same logic of only exporting local routes on the Local PE ( MPLS PE or VRF-Lite does not matters as a fact). The point here I am making is that if we receive and external route then we can not re-export it to other VRFs which are locally configured or as a matter of fact back to the backbone. This is what is the issue here for the prefix 10.130.100.0 not being imported into VRF I9003:Mgmt.

Now one solution was to directly import this external route into the VRF using Import RT but you have mentioned that it caused unwanted routing updates..We can try an import-map there to control the desired prefix but not sure if this scales for your topology.

The option  to create a separate VRF and directly import the route using import RT has the same issue as above for receiving unwanted routing updates..So I would suggest to use import-map under the existing VRF and import the required RT 17669:1010 with other desired prefixes.

Hope this helps to answer your question.

Regards

Varma

Thanks Varma, I am trying to find the document online to quote on what you explained. No solid result returns back saying PE can not export external routes but can export local only. Could you show me some Cisco docs?

Don't know if you have verified the 2nd config file I uploaded called 'SYD MPLS EDGE#1' on the original post. Some export map literally export the ebgp prefixes with no joke.(Plz see what i pointed at the post 4:41am 9th Dec)

So many thanks for your time Varma. I hope I can understand it really soon after your great helps. :)

Robo

Hi Robo

I did look at your latest files and it has only running config and no show outputs which would illustrate re-exporting an external route which is learnt across BGP.

But actually now I understand there is a difference in what context I was saying no re-export of external BGP routes and whats the setup here . I was thinking on the grounds of the iBGP split horizon rule for not re-exporting any iBGP routes to another iBGP peer but that does not holds good here..

So coming back to this issue of an eBGP route being learnt in one VRF and not exported to another VRF on same PE based on the addtional RT value this is quite strange . The issue which is seen looking at the logs attached in your first post I can see that the additive RT value of  17669:101011 is not being applied to the route  10.130.100.0 and missing which is obstructing the import of this route to I9003:Mgmt VRF.Not sure why at this moment but am still thinking for it.

PRSIN2MPLSR01#sh ip bgp vpnv4 vrf V1010:LLL  10.130.100.0

BGP routing table entry for 17669:1010:10.130.100.0/24, version 5908

Paths: (1 available, best #1, table V1010:LLL)

  Not advertised to any peer

  65504 65500 65001 4445 4445 65500 65501

    10.130.253.1 from 10.130.253.1 (10.255.48.17)

      Origin IGP, localpref 200, valid, external, best

      Extended Community: RT:17669:1010 "Additive Community Missing Here"

Regards

Varma

welcome back Vaibhava? how u been long time no see Hope you well

Hey Kishore

Yes quite busy in the last few days Hey what do you think might be happening on this issue if you got time to go through it

Regards

Varma

Hey Varma,

Nice to hear from you. In regards to the export map , AFAIK the prefix doesn't have to be to be local to the router. As long as its in the vrf RIB you can muck around with it. Please see below

R1#sh ip bgp vpnv4 vrf B 50.50.50.50

BGP routing table entry for 200:1:50.50.50.50/32, version 26

Paths: (1 available, best #1, table B)

Flag: 0x820

  Not advertised to any peer

  Local

    20.1.1.2 from 0.0.0.0 (1.1.1.1)

      Origin incomplete, metric 1, localpref 100, weight 32768, valid, sourced, best

      Extended Community: RT:200:1 RT:300:3

      mpls labels in/out 20/nolabel

R1#sh ip route vrf B 50.50.50.50

Routing entry for 50.50.50.50/32

  Known via "rip", distance 120, metric 1

  Redistributing via bgp 6500, rip

  Advertised by bgp 6500

  Last update from 20.1.1.2 on GigabitEthernet2/0.20, 00:00:20 ago

  Routing Descriptor Blocks:

  * 20.1.1.2, from 20.1.1.2, 00:00:20 ago, via GigabitEthernet2/0.20

      Route metric is 1, traffic share count is 1

R1#sh route-map

route-map B-to-A, permit, sequence 10

  Match clauses:

    ip address (access-lists): 10 20

  Set clauses:

    extended community RT:300:3 additive

  Policy routing matches: 0 packets, 0 bytes

R1#sh ip access-lists

Standard IP access list 10

    10 permit 22.22.22.22 (11 matches)

Standard IP access list 20

    10 permit 50.50.50.50 (3 matches)

R1#sh run | be vrf

ip vrf A

rd 100:1

route-target export 100:1

route-target import 100:1

route-target import 300:3

!

ip vrf B

rd 200:1

export map B-to-A

route-target export 200:1

route-target import 200:1

HTH

Regards,

Kishore

Mr. V.

That's exact what I have been confused by...

After I read all sorts of articles relating to VRF lite, VRF route leaks are not easily perform by export map with additive keyword. it can accept the RT exchange between VRFs via the first RT or original RT.

As it is a form of VRF-lite, the extended communities are not exchanged by MPLS Core ( it is lack of "neighb xxxx send-community extended/both" under AF vpnv4 pointing towards core), the 2nd additive extended community RT should not be exported successfully. However, I have my half "successful" example there..... why....?

if I have a change to touch that router again, I would do the following to exchange RT between VRFs.

1. create a new VRF AAA

2. Import 17669:1010 and 17669:9003 into it

3. export map match 10.130.100.0/24 and set a new RT 17669:xxxx "without additive";

and match 10.8.0.0/24 then set a new RT 17669:yyyy "without additive" too

5. go to VRF Mgmt and import new RT 17669:xxxx and go to VRF LLL and import RT 17669:yyyy

This should eliminate the issue of 2nd additive extended RT can't not be attched. I hope.

Do you agree Mr. V?

Heaps thanks so far mate, your very helpful and knowledgable.

Robo

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: