Solved: Importing a BGP route from a VRF which isnt the best path

neil grant · ‎03-27-2013

Hello Chaps

Ok so we are in the middle of designing our new service provider network to offer IPVPN's and leased line internet, now i have a problem which im hoping you might be able to help out with. In summary importing multiple default routes into a premium leased line internet VRF and Buget DSL internet with the DSL internet using the "budget" internet transit carrier.

So we are recieving 2 default routes from our IP Transit:

PE1:

show ip bgp vpnv4 vrf IP_Transit

BGP table version is 7, local router ID is 169.254.0.0

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 4445:2001 (default for vrf IP_Transit)

* i 0.0.0.0 169.254.0.1 0 100 0 1 i

*> Primary Inet Peer 0 2 i

PE2

show ip bgp vpnv4 vrf IP_Transit

BGP table version is 8, local router ID is 169.254.0.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 4445:2001 (default for vrf IP_Transit)

* i 0.0.0.0 169.254.0.0 0 100 0 2 i

*> 1.1.1.1 0 1 i

When importing a default between IP_Transit vrf and DIA (direct internet access) import map removed for the moment. Also one way importing for the moment.

PE1

ip vrf DIA

rd 4445:2000

route-target export 4445:2000

route-target import 4445:2000

route-target import 4445:2001

ip vrf IP_Transit

rd 4445:2001

route-target export 4445:2001

route-target import 4445:2001

PE2

ip vrf DIA

rd 4445:2000

route-target export 4445:2000

route-target import 4445:2000

route-target import 4445:2001

ip vrf IP_Transit

rd 4445:2001

route-target export 4445:2001

route-target import 4445:2001

I only get the best path being imported:

PE1

show ip bgp vpnv4 vrf DIA

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 4445:2000 (default for vrf DIA)

*> 0.0.0.0 Primary Inet Peer 0 2 i

PE2

show ip bgp vpnv4 vrf DIA

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 4445:2000 (default for vrf DIA)

*> 0.0.0.0 1.1.1.1 0 1 i

^--- Is there a reason why i wouldnt see both routes since PE1&2 are importing there best paths within this vrf?----^

So what I actually want for this VRF (DIA) is for PE2 to use PE1 for 0.0.0.0/0 rather than its EBGP neighbor, but we dont have that in the BGP table for me to apply a route-map to.

I would just apply a route-map statement to the IP_Transit VRF to set local preference to 0.0.0.0/0 on PE1 however will face the same issue when I create a Budget DSL Internet VRF which would use the economy provider with backup to PE1

For reference a Customers bgp table (Global) connecting the PE1 (10.173.100.0) & 2 (10.173.100.2)

show ip bgp

BGP table version is 34, local router ID is 192.168.1.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

* 0.0.0.0 10.173.100.2 200 0 4445 1 i

*> 10.173.100.0 100 0 4445 2 i

attached diagram should help

Thanks in advance Neil

Regards Neil http://uk.linkedin.com/pub/neil-grant/20/5b0/267

Giuseppe Larosa · ‎04-02-2013

Hello Neil,

the use of different route distinguisher on different PE nodes is quite common.

>> do you know if there is a logical reason why when you import a route between vrfs (IP_Transit -> DIA) on PE1 the route doesn't appear on PE2 requiring you to import the routes on PE2 as well?

This is to be expected the imported route in vrf DIA is not re-advertised in vpnv4 address-family so each device has to perform the necessary import action.

Importing is an action that has local node scope.

The reason for this is routing loop avoidance.

PE2 should import the best path from VRF IP_transit to VRF DIA, if the direct eBGP session with AS2 fails it should be able to pick up the route learned by PE1 and propagated in vpnv4 to PE2.

You should test what happens in case of this type of failure to validate your design.

Hope to help

Giuseppe

View solution in original post

Muhammad Thanveer · ‎03-27-2013

Need to follow this post.

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

neil grant · ‎03-28-2013

Ok so i now have this working by (for the moment have yet to do full testing) i have had to create a iBGP between the VPNV4 neighbors within the DIA vrf

PE1 PE2

mBGP<----------------------------------->mBGP

I I

v v

Best DFR get imported from each IP_Transit Vrf to DIA

I I

v v

iBGP<---------------DIA-Vrf------------->iBGP

PE1:

show ip bgp vpnv4 vrf DIA

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 4445:2000 (default for vrf DIA)

* i 0.0.0.0 1.1.1.1 0 100 0 1 i

*> Primary Inet Peer 0 2 i

PE2:

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 4445:2000 (default for vrf DIA)

* i 0.0.0.0 Primary Inet Peer 0 100 0 2 i

*> 1.1.1.1 0 1 i

I will now be able to manipulate the routes as required, yay.... however is it?, i have never seen any documenation doing this, i have no idea if this is bad practice, if it will cause me further issues down the line? - however i cannot see any other way of getting this done.

I have managed to keep my communities:

BGP routing table entry for 4445:2000:0.0.0.0/0, version 6

Paths: (2 available, best #2, table DIA)

Advertised to update-groups:

7 9

Refresh Epoch 1

1

1.1.1.1 from 10.173.100.255 (169.254.0.1)

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

Extended Community: RT:4445:2000 RT:4445:2001

rx pathid: 0, tx pathid: 0

Refresh Epoch 1

174, imported path from 4445:2001:0.0.0.0/0 (IP_Transit)

149.6.147.125 (via IP_Transit) from Primary Inet Peer

Origin IGP, localpref 100, valid, external, best

Community: 4445:1

Extended Community: RT:4445:2001

rx pathid: 0, tx pathid: 0x0

PS also adding:

show run | sec ipv4 vrf DIA

address-family ipv4 vrf DIA

neighbor 10.173.100.1 remote-as 65535

neighbor 10.173.100.1 activate

neighbor 10.173.100.1 route-map Set-Primary out

neighbor 10.173.100.255 remote-as 4445

neighbor 10.173.100.255 activate

default-information originate <-- did not cause 0.0.0.0/0 to appear in the PE2's DIA Vrf

Hopefully someone will pop along to tell me this is an acceptable/Best practice way to do this, or offer a better solution (come on CCIE's, let see those brain muscles flex), but for the moment i happy that i haven't had to rely on PBR or route leaking trickery.

Neil

Regards Neil http://uk.linkedin.com/pub/neil-grant/20/5b0/267

Giuseppe Larosa · ‎03-29-2013

Hello Neil,

I couldn't examine all the details that you have provided in this thread.

So I just want to make some consideration

The behaviuor you see in importing routes from one VRF to another VRF is similar to what happens when you for example redistribute from BGP to another routing protocol.

Only the best path is redistributed, but this is enough for routing purposes as there is no additional benefit in providing also a backup route that is not used in normal conditions.

The process of importing routes from a VRF to another one, like redistribution, is a dynamic process. If the primary route fails the backup route is installed in the origin VRF and it should get imported into the target VRF.

So the fact you don't see the secondary path does not mean that there is no redundancy at all, just that in case of failure of the primary route it takes some time to perform the steps described above.

So all you did with your creative effort can provide some benefits in terms of speed of convergence as the backup route is already there in the target VRF.

>> i have had to create a iBGP between the VPNV4 neighbors within the DIA vrf

>>

>>show run | sec ipv4 vrf DIA

>>address-family ipv4 vrf DIA

>> neighbor 10.173.100.1 remote-as 65535

>>neighbor 10.173.100.1 activate

>>neighbor 10.173.100.1 route-map Set-Primary out

>>neighbor 10.173.100.255 remote-as 4445

>>neighbor 10.173.100.255 activate

>> default-information originate <-- did not cause 0.0.0.0/0 to appear in the PE2's DIA Vrf

so you have done an iBGP session between the PE nodes in af vrf DIA?

This is not something expected in MPLS L3 VPN architecture.

A direct vpnv4 session between PE nodes instead of going through RR servers can be reasonable in some cases.

But as you have noted seeing a BGP session in af vrf DIA between PE nodes is not usual at all.

Each PE will see the other one as an additional CE node in vrf DIA. But there are or better there were limitations for iBGP as PE-CE protocol if I correctly remember.

For example you have noted the following:

>> default-information originate <-- did not cause 0.0.0.0/0 to appear in the PE2's DIA Vrf

The BGP router-id of the other PE node will appear from backbone in vpnv4 and as a CE in af vrf DIA this should alert the local PE node that something strange is happening. Or it takes a VRF mapped address as BGP router-id for the session in VRF?

In addition you are seeing route targets on a session that should be unicast ipv4 only

>>

BGP routing table entry for 4445:2000:0.0.0.0/0, version 6

Paths: (2 available, best #2, table DIA)

Advertised to update-groups:

7 9

Refresh Epoch 1

1

1.1.1.1 from 10.173.100.255 (169.254.0.1)

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

<<<<< Extended Community: RT:4445:2000 RT:4445:2001 >>>>>>>

rx pathid: 0, tx pathid: 0

the extended communities should be exchanged only on vpnv4 af.

What you see may be implementation dependent and so the behaviour may change in the future with newer IOS versions

I would test the capability of failover of the import process without all these tricks and with these tricks, unless you see a noticeable gain in performance I would not go in production with the tricks.

the More I look at your trick the more I don't like it.

Edit:

looking again at the whole picture I think that all you need is to use two different route distinguisher in VRF IP_transit in PE1 and PE2 so that from vpnv4 point of view the two default routes are not comparable (as RD is prepended to form the vpnv4 NLRI) and you will be able later to import both default routes from VRF IP_transit in target VRF DIA.

This should be the classic solution to this kind of issues.

Hope to help

Giuseppe

neil grant · ‎04-01-2013

Hello Giuseppe,

Firstly I would like to thank you for taking the time have a look through this thread.

“The process of importing routes from a VRF to another one, like redistribution, is a dynamic process. If the primary route fails the backup route is installed in the origin VRF and it should get imported into the target VRF.

So the fact you don't see the secondary path does not mean that there is no redundancy at all, just that in case of failure of the primary route it takes some time to perform the steps described above.

So all you did with your creative effort can provide some benefits in terms of speed of convergence as the backup route is already there in the target VRF.”

Getting all the routes into the correct vrf and being able to apply route-maps on communities etc. if we go back to the original problem I was trying to overcome. Firstly my last thread and configuration was quickly scrapped, due to seeing some usual behaviour (2 paths same device different logical interfaces) as well as me finding it unclean / not precise. No iBGP relationships exist between the mBGP neighbours:

PE1:

router bgp 4445

no synchronization

bgp log-neighbor-changes

neighbor 10.173.10.1 remote-as 4445

neighbor 10.173.10.1 send-community both

no auto-summary

!

address-family vpnv4

neighbor 10.173.10.1 activate

neighbor 10.173.10.1 send-community both

exit-address-family

!

address-family ipv4 vrf IP_Transit

neighbor 12.0.0.1 remote-as 1

neighbor 12.0.0.1 activate

neighbor 12.0.0.1 route-map Primary_Transit in

no synchronization

exit-address-family

!

address-family ipv4 vrf DSL_DIA

no synchronization

exit-address-family

!

address-family ipv4 vrf DIA

neighbor 10.173.100.1 remote-as 65535

neighbor 10.173.100.1 activate

neighbor 10.173.100.1 as-override

no synchronization

exit-address-family

PE2:

router bgp 4445

no synchronization

bgp log-neighbor-changes

neighbor 10.173.10.0 remote-as 4445

neighbor 10.173.10.0 send-community both

no auto-summary

!

address-family vpnv4

neighbor 10.173.10.0 activate

neighbor 10.173.10.0 send-community both

exit-address-family

!

address-family ipv4 vrf IP_Transit

neighbor 13.0.0.1 remote-as 2

neighbor 13.0.0.1 activate

neighbor 13.0.0.1 route-map Secondary_Transit in

no synchronization

exit-address-family

!

address-family ipv4 vrf DSL_DIA

no synchronization

exit-address-family

!

address-family ipv4 vrf DIA

neighbor 10.173.100.3 remote-as 65535

neighbor 10.173.100.3 activate

neighbor 10.173.100.3 as-override

no synchronization

exit-address-family

The root cause of my issue is that PE2 (DIA vrf) has no visibility of the Primary_Transit DFR (I now have this labbed in a GNS environment) PE2 (DIA) needs to use PE1 (local preference 200) as its best path

PE1#show ip bgp vpnv4 all

BGP table version is 10, local router ID is 10.173.10.0

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 4445:2000 (default for vrf IP_Transit)

* i0.0.0.0 10.173.10.1 0 100 0 2 i

*> 12.0.0.1 0 0 1 i

Route Distinguisher: 4445:2001 (default for vrf DIA)

*> 0.0.0.0 12.0.0.1 0 200 0 1 i

PE1#

PE2#show ip bgp vpnv4 all

BGP table version is 3, local router ID is 10.173.10.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 4445:2000 (default for vrf IP_Transit)

*> 0.0.0.0 13.0.0.1 0 0 2 i

* i 10.173.10.0 0 100 0 1 i

Route Distinguisher: 4445:2001 (default for vrf DIA)

*> 0.0.0.0 13.0.0.1 0 0 2 i

PE2#

Please see Diagram

I'm at a loss as to why PE2 cannot see the 0.0.0.0/0 route from PE1 in the DIA Vrf?

Again thanks for the input,

Neil

Regards Neil http://uk.linkedin.com/pub/neil-grant/20/5b0/267

neil grant · ‎04-01-2013

Edit:


looking  again at the whole picture I think that all you need is to use two  different route distinguisher in VRF IP_transit in PE1 and PE2 so that  from vpnv4 point of view the two default routes are not comparable (as  RD is prepended to form the vpnv4 NLRI) and you will be able later to  import both default routes from VRF IP_transit in target VRF DIA.
This should be the classic solution to this kind of issues.
Hope to help
Giuseppe

So Primary_Transit VRF 0.0.0.0/0 <-> IP_Transit VRF & DIA <-> Secondary_Transit 0.0.0.0/0

(Public Range)

Umm interesting i will begin testing Fingers crossed :-) is this a commonish problem?

Neil

Regards Neil http://uk.linkedin.com/pub/neil-grant/20/5b0/267

neil grant · ‎04-02-2013

Hello Giuseppe

Thank you for the above I partially labbed this up last night with promising results,

However (Back to the old solution) do you know if there is a logical reason why when you import a route between vrfs (IP_Transit -> DIA) on PE1 the route doesn't appear on PE2 requiring you to import the routes on PE2 as well?

PE1#show ip bgp vpnv4 vrf IP_Transit

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 4445:2001 (default for vrf IP_Transit)

*> 0.0.0.0 Primary_Transit 0 17 i

s> x 10.173.100.1 0 0 65535 i

* i x 169.254.0.1 0 100 0 i

*> 0.0.0.0 32768 i

PE1#show ip bgp vpnv4 vrf DIA

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 4445:2000 (default for vrf DIA)

*> 0.0.0.0 Primary_Transit 200 0 17 i

*> x 10.173.100.1 0 0 65535 i

PE2#show ip bgp vpnv4 vrf IP_Transit

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 4445:2001 (default for vrf IP_Transit)

*> 0.0.0.0 1.1.1.1 0 1 i

* i 169.254.0.0 0 100 0 xi

s>i x 169.254.0.0 0 100 0 65535 i

*> x 0.0.0.0 32768 i

* i 169.254.0.0 0 100 0 i

PE2#show ip bgp vpnv4 vrf DIA

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 4445:2000 (default for vrf DIA)

*> 0.0.0.0 1.1.1.1 0 1 i

Regards Neil

Regards Neil http://uk.linkedin.com/pub/neil-grant/20/5b0/267

Giuseppe Larosa · ‎04-02-2013

Hello Neil,

the use of different route distinguisher on different PE nodes is quite common.

>> do you know if there is a logical reason why when you import a route between vrfs (IP_Transit -> DIA) on PE1 the route doesn't appear on PE2 requiring you to import the routes on PE2 as well?

This is to be expected the imported route in vrf DIA is not re-advertised in vpnv4 address-family so each device has to perform the necessary import action.

Importing is an action that has local node scope.

The reason for this is routing loop avoidance.

PE2 should import the best path from VRF IP_transit to VRF DIA, if the direct eBGP session with AS2 fails it should be able to pick up the route learned by PE1 and propagated in vpnv4 to PE2.

You should test what happens in case of this type of failure to validate your design.

Hope to help

Giuseppe

neil grant · ‎04-04-2013

Hello Giusepp,

Thank you very much for you help this seems to be working correctly, I will post the configuration when complete.

Although I have read MPLS Fundamentals: Luc De Ghein, I don't think it goes into the detail I need, can you recommend a good book, I was thinking of reading MPLS and VPN Architectures.

Regards Neil

Regards Neil http://uk.linkedin.com/pub/neil-grant/20/5b0/267

Muhammad Thanveer · ‎04-04-2013

Hello Neil,

I found to be very good

http://www.ciscopress.com/store/mpls-configuration-on-cisco-ios-software-9781587051999

and for XR

http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r2.0/mpls/configuration/guide/gcbook.pdf

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