[j-nsp] Junos labeled-unicast announces unusable routes, certainly this is a bug

[Alex Arseniev]

Probably not what you want to hear at the moment but it "is working as 
designed".
There is nothing in BGP RFCs which mandate that BGP-LU _must_ consult 
LDP/RSVP/LFIB etc before announcing routes.
To "force" BGP-LU to consult LDP/RSVP and automatically advertise/withdraw 
routes matching LSP endpoints, use combination of:
1/ "mpls traffic-engineering bgp-igp-both-ribs" (installs LDP/RSVP routes in 
inet.0 and in inet.3)
2/ BGP-LU export policy which exports LDP/RSVP routes as well as own 
loopback (all of them are in inet.0 as a result of [1] above)
3/ "resolve-vpn" under BGP LU family which causes received BGP-LU routes to 
install in both inet.0 and inet.3, for inet-vpn NH resolution
HTH
Thanks
Alex



----- Original Message ----- 
From: "Jeff Wheeler" <jsw at inconcepts.biz>
To: "juniper-nsp" <juniper-nsp at puck.nether.net>
Sent: Monday, January 21, 2013 12:25 AM
Subject: [j-nsp] Junos labeled-unicast announces unusable routes,certainly 
this is a bug


> Dear List,
>
> The process of raising a PR with JTAC generally makes me want to scream, 
> so
> I thought I would post first, and perhaps some kind Juniper person can
> input a PR# without me having to reproduce the problem again and jump
> through twenty hoops to later be told "working as designed."
>
> When configuring BGP labeled-unicast on Junos, you might think (like I
> hoped) that you could use LDP to create FECs and allocate labels, and then
> use those labels in your MP-BGP session.  Unfortunately this does not 
> work,
> and the basic reason is Junos BGP wants to allocate its own labels, and
> won't consult the LDP FEC table to see if any already exist for a given
> protocol next-hop which is being announced to the neighbor.  Fine, so it
> wants to allocate its own labels.
>
> However, trying to avoid this behavior, I found it's pretty easy to get
> Junos to announce broken labeled-unicast routes that can never work, even
> though the receiving BGP speaker has no idea they are invalid.  The
> receiver will just install the routes, forward traffic, and the traffic
> will get blackholed.
>
> This happens because Junos is trying to announce NLRI with no allocated
> labels (because layer-3 next-hop is not "self") and it can't announce them
> when labeled-unicast is configured, because the documentation is wrong, 
> and
> you canNOT actually configure both AFI=1 SAFI=1 and AFI=1 SAFI=4 on the
> same BGP session.  It simply does not work, and the Juniper documentation
> on this subject is incorrect.
>
> So what happens is, the announcing router knows it wants to announce a
> prefix, but it has no label stack for it, won't allocate one, and instead
> it just puts in label 1048575, or 2^20-1.  This label is not in the LFIB,
> so when that router receives packets with that label, it doesn't pop the
> label and do a layer-3 look-up.  Instead, it just discards the packets.
>
> Worse than that, the announcing router's `show route advertising-protocol
> bgp <neighbor>` output is incorrect.  It shows no label, even though it
> really is sending a label stack with 2^20-1.  You have to go over to the
> receiving router to find this out.
>
> So this combination of documentation bugs and ridiculous Junos ability to
> announce labeled BGP routes that it knows for sure are invalid, is quite
> foolish, to say nothing of the fact that it won't just use FECs you 
> already
> created using LDP. :/
>
> Anyway, if you ever get labeled BGP routes with label 2^20-1, this might 
> be
> why.  Hopefully some kind Juniper folks will be willing to file some bugs
> on this for me, because I don't have a week to fight with JTAC about it. 
> It
> is, however, very easy to reproduce the problem. :-)
>
> Thanks
> -- 
> Jeff S Wheeler <jsw at inconcepts.biz>
> Sr Network Operator  /  Innovative Network Concepts
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>