[c-nsp] MPLS Label propagation and/or MP-BGPand/orroute-reflecting, oh my.

Robert Crowe (rocrowe) rocrowe at cisco.com
Fri Jan 21 16:22:16 EST 2011


First two things that come to mind are to:

1. Change the new core AS number
2. Look into CsC

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jason Lixfeld
Sent: Friday, January 21, 2011 3:50 PM
To: Oliver Boehmer (oboehmer)
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] MPLS Label propagation and/or
MP-BGPand/orroute-reflecting, oh my.


On 2011-01-21, at 2:58 PM, Oliver Boehmer (oboehmer) wrote:

> [...]
>> I have a feeling that there's some fundamental concept of how this is
> all
>> supposed to work that I'm just not getting.  If anyone sees anything
> that
>> warrants a slap with the clue-bat, I'd be grateful.
> 
> Your PE1 and CE are in the same AS, and IOS does not support iBGP as 
> PE-CE routing protocol.. So this is a one problem. The issue with lack

> of iBGP PE-CE support is the fact that the vpnv4 next-hop is not 
> rewritten to the PE1's loopback, so the other PE's in the network will

> not find an LSP towards the unchanged nexthop, but you can somehow 
> make this work re-writing the vpnv4 nexthop before sending the vpnv4 
> update to the peers. Still unsupported, though.

Any method that would be more supported?

Basically we're bolting an MPLS-enabled network onto a non-MPLS enabled
network and need the two to interoperate.  We're taking the full
Internet BGP table and sticking it inside a VRF so we can hide layer 3
hops between CEs by turning off mpls forward ttl-progation.  This means
that the connection from the old network to the new network needs to be
inside a VRF so we don't have to completely rebuild the old network to
support L3VPN first.

This lab is designed to prove out the concept before rolling it out,
like a good little lab should :)

One thing to note - in the new network, PE1 and PE2 will be XR 4.0.x
boxes, so if there are any XR hooks that might make this easier...  And
in the current production network, the CE would be a 7600/SUP720.

> I don't know why PE3 doesn't see the prefixes learnt from your CE1, 
> would need to look at this in detail. But if PE2 sees the prefix, and
> PE3 also has a vpnv4 session to PE1, PE3 should see it. can you enable

> bgp debugs to check what's happening?

On PE1:

P1#show ip bgp vpnv4 all neighbors 1.1.1.1 advertised-routes  | i
100.0|200.0|$
*> 65.53.50.0/24    10.0.0.13                0             0 65535 i
*>i100.0.0.0/24     12.12.12.12              0    100      0 1 i
*>i200.0.0.0        13.13.13.13              0    100      0 2 i
P1#
!
! 1.1.1.1 being PE3
!

...
*Jan 21 15:23:26.362: BGP: TX VPNv4 Unicast Wkr global 9 Ref Net
21949:0:200.0.0.0/24 Formatted.
*Jan 21 15:23:26.362: BGP: TX VPNv4 Unicast Wkr global 9 Ref
Replicating.
*Jan 21 15:23:26.362: BGP: TX VPNv4 Unicast Wkr global 9 Ref Suspending
(attr change), processed 1 attr(s), 2/2 net(s).
*Jan 21 15:23:26.362: BGP: TX VPNv4 Unicast Wkr global 9 Ref Processing.
*Jan 21 15:23:26.362: BGP: TX VPNv4 Unicast Wkr global 9 Ref Attr change
from 0x0 to 0x66CAF810.
...
*Jan 21 15:23:26.366: BGP: TX VPNv4 Unicast Wkr global 9 Ref Net
21949:0:100.0.0.0/24 Formatted.
*Jan 21 15:23:26.366: BGP: TX VPNv4 Unicast Wkr global 9 Ref
Replicating.
*Jan 21 15:23:26.366: BGP: TX VPNv4 Unicast Wkr global 9 Ref Suspending
(attr change), processed 1 attr(s), 3/3 net(s).
*Jan 21 15:23:26.366: BGP: TX VPNv4 Unicast Wkr global 9 Ref Processing.
*Jan 21 15:23:26.366: BGP: TX VPNv4 Unicast Wkr global 9 Ref Attr change
from 0x0 to 0x66CAFB88.
...
*Jan 21 15:23:26.370: BGP: TX VPNv4 Unicast Wkr global 9 Ref Net
21949:0:65.53.50.0/24 Formatted.
*Jan 21 15:23:26.370: BGP: TX VPNv4 Unicast Wkr global 9 Ref Reached
marker with version 35.
*Jan 21 15:23:26.370: BGP: TX VPNv4 Unicast Wkr global 9 Ref Replicating
(pending member_pos processing).
...

On PE3, absolutely no reference of anything to do with 100.0.0.0 or
200.0.0.0, but for 65.53.50.0/24:

...
*Jan 21 15:23:25.250: BGP: net INTERNET:VPNv4 Unicast:base
21949:0:65.53.50.0/24 RIB-INSTALL Attempting to install.
*Jan 21 15:23:25.250: BGP: net INTERNET:VPNv4 Unicast:base
21949:0:65.53.50.0/24 RIB-INSTALL Built route type: 512, flags: 200000,
tag: FFFF, metric: 0 paths: 1.
*Jan 21 15:23:25.250: BGP: net INTERNET:VPNv4 Unicast:base
21949:0:65.53.50.0/24 RIB-INSTALL Path 1, type: DEF, gw: 3.3.3.3, idb:
N/A, topo_id: 0, src: 4.4.4.4, lbl: 29, flags: 40.
*Jan 21 15:23:25.250: BGP: net INTERNET:VPNv4 Unicast:base
21949:0:65.53.50.0/24 RIB-INSTALL Installing 1 paths, multipath limit 1
(from 1).
*Jan 21 15:23:25.250: BGP: net INTERNET:VPNv4 Unicast:base
21949:0:65.53.50.0/24 RIB-INSTALL Install successful.
*Jan 21 15:23:25.250: BGP: TX VPNv4 Unicast Net INTERNET
21949:0:65.53.50.0/24 RIB done.
...
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list