[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