[c-nsp] ldp: label not assigned for eBGP-learned route..

Alexandre Snarskii snar at paranoia.ru
Sat Jun 9 13:21:55 EDT 2007


On Sat, Jun 09, 2007 at 12:12:53PM -0400, Harold Ritter (hritter) wrote:
> Alexander,
> 
> This behavior is normally seen when ipv4 + label is not configured on
> the iBGP peer(s). Can you confirm whether send-label is configured for
> the iBGP peer and do a "show bgp ipv4 unicast neighbor x.x.x.x" for the
> iBGP peer to confirm that ipv4 + label is both advertised and received.

Thanks for idea. 

That's changed situation a bit, however, picture is still not
what I'm achieving. 
On ASBR local label is still not assigned, however, this route
announced to IBGP peer with label of EBGP peer, meaning that
ASBR will accept labeled packets for this route and decapsulate
them in PHP manner, but not just swap label with external one...  

Details: 
At ASBR I have: 
RouterASBR#show mpls forwarding-table  AA.AAA.AA.5 
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop    
Label  Label or VC   or Tunnel Id      Switched      interface              
None   101824        AA.AAA.AA.5/32    0             Vl99       EBGP.AD.DR 

At IBGP peer (ipv4 MPLS Label capability: advertised and received): 
RouterIBGP#show mpls forwarding-table AA.AAA.AA.5
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop    
Label  Label or VC   or Tunnel Id      Switched      interface              
None   16            AA.AAA.AA.5/32    0             Vl69       ASBR.IP.ADD  

pointing to ASBR, and on ASBR 
RouterASBR#show mpls forwarding-table labels 16
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop    
Label  Label or VC   or Tunnel Id      Switched      interface              
16     Pop Label     EBGP.AD.DR/32     64379         Vl99       EBGP.AD.DR 

so, it's PHP behaviour, not label swap one. 

PS: another interesting feature: 
ibgp peer with send-label enabled, add 'set mpls-label' to outbound
route-map. Got
RouterIBGP#show mpls forwarding-table AA.AAA.AA.5
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop    
Label  Label or VC   or Tunnel Id      Switched      interface              
None   101824        AA.AAA.AA.5/32    0             Vl69       ASBR.IP.ADD  

Label 101824 is the label ASBR getting from EBGP peer, not allocated
locally: 
RouterASBR#show mpls forwarding-table labels 101824
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop    
Label  Label or VC   or Tunnel Id      Switched      interface              
RouterASBR#

As far as I assumed, traffic for AA.AAA.AA.5 should be dropped at
ASBR (because label is not known), but simple traceroute test 
shows that traffic was forwarded towards destination... 

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Alexandre
> Snarskii
> Sent: Saturday, June 09, 2007 11:07 AM
> To: Cisco-NSP Mailing List
> Subject: [c-nsp] ldp: label not assigned for eBGP-learned route..
> 
> 
> Hi!
> 
> While testing interAS mpls connectivity, I found interesting
> feature: router does not assign local label to route, learned via eBGP,
> even in case when got it with label...
> 
> A bit more detailed description: 
> I'm getting route with label, 
> 
> BGP routing table entry for AA.AAA.AA.5/32, version 5022
>     BB.BBB.B.49 from BB.BBB.B.49 (BB.BBB.B.6)
>       Origin IGP, metric 0, localpref 100, valid, external, best
>       Community: no-export
>       mpls labels in/out nolabel/101824
> 
> and it's installed into mpls forwarding table with outgoing label: 
> 
> Router>show mpls forwarding-table AA.AAA.AA.5
> Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
> 
> Label  Label or VC   or Tunnel Id      Switched      interface
> 
> None   101824        AA.AAA.AA.5/32    0             Vl99
> BB.BBB.B.49 
> 
> But, as you can see, Local Label is not assigned to this route, so, even
> if that route redistributed with iBGP over my backbone, label for this
> route is not assigned at the edge, so, all other routers will not be
> able to establish LSP to remote side... 
> 
> Well, one workaround to this is to redistribute this route to ospf (this
> route get label assigned right after enabling bgp->ospf redistribution),
> but that workaround is potentially dangerous[1].
> 
> Are there any way to force local label assignment to eBGP-learned route
> without redistribution ? 
> 
> PS: IOS version is 12.2(33)SRA3, if it matters. 
> 
> [1]: Some years ago I saw a network meltdown caused by 'no redistribute
> bgp NNNN route-map BLAH', which removed not 'redistribute' command, but
> just 'route-map', thus allowing full-view leak into ospf.. With modern
> IOS behaviour (disable dCEF when there are not enough memory) such leaks
> are even more dangerous...
> 
> _______________________________________________
> 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