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

[CSCO11020330]

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.

[smitesh kharecha]

Hi,

Can you please share the configs please.

Regards,

Smitesh

[Vaibhava Varma]

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

[CSCO11020330]

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

[Vaibhava Varma]

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

[CSCO11020330]

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

[CSCO11020330]

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

[CSCO11020330]

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...)

[Vaibhava Varma]

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

[CSCO11020330]

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

[Vaibhava Varma]

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

[Kishore Chennupati]

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

[Vaibhava Varma]

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

[Kishore Chennupati]

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

[CSCO11020330]

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