Labeled-unicast problems

[Andrew WEISS]

Hi all,

We're run into an interoperability problem between Cisco and Juniper that seems insurmountable at this time which I'm hoping that someone else has encountered and, potentially, identified a workaround for.  

In short, we have 4 route-reflectors: 2 x Cisco and 2 x Juniper.  Each of our PE have a BGP session to all 4 RR.  We run all address-families (IPV4/IPV6 unicast/multicast/vpnv4/6).  On 5 of our PE, labeled-unicast in used in conjunction to all the other address-families. 

What we've discovered on the 5 PE configured with labeled-unicast is that if a new unicast prefix is learnt, the prefix is advertised to the router's route-reflector as an AFI1/SAFI1 route and the RR installs the route into the appropriate routing table (if applicable - inet.0 in the case of Juniper) who in turn advertise this route out to the other PE routers on the network.  This works perfectly.

However, when said prefix is withdrawn, the PE sends an MP_UNREACH_NLRI message type 4 (SAFI4 or labeled-unicast) withdraw message out to the route-reflectors which doesn't result in the route being flushed on the Juniper route-reflectors since the prefix does not exist in the Juniper's inet.3 table, rather in the inet.0.  On the Cisco route-reflectors the route is withdrawn correctly.  See attached trace for more details.

When the prefix in question is labelized, the insertion and the removal of the route works perfectly on both Juniper and Cisco, since the Cisco withdraw message correctly targets the correct routing table on the Juniper (inet.3).  

In order to resolve this interoperability problem, it would seem that Cisco would need to send an MP_UNREACH_NLRI containing both an SAFI1 and SAFI4 withdraw message as Juniper seems to do, even though this is not openly recommended in RFC 3107 or in RFC 2858.  I assume this to be the case, since Juniper-Juniper labeled-unicast works flawlessly.

Any ideas?

Kind regards,

Andrew

[Peter Paluch]

Andrew,

I am not sure if I will be able to help as this is most probably an implementation issue in respective operating systems but I would like to at least understand the problem in greater detail.

What puzzles me is this: You are saying that a PE configured with labeled-unicast still advertises this prefix with AFI/SAFI equal to 1/1. I find this curious because it means that the prefix is, despite the configuration, advertised as unlabeled. I did a quick and dirty test with Cisco routers - once they are configured with neighbor send-label, all prefixes are always advertised and withdrawn as labeled with AFI/SAFI equal to 1/4.

In addition, why would a prefix that was previously advertised as unlabeled (1/1) be withdrawn as if it was labeled (1/4)?

I simply do not understand these two discrepancies. Do you have any explanation for them?

Would it be possible to capture the BGP session between two Juniper routers configured for labeled-unicast, starting with opening the BGP session, through advertising and withdrawing a sample prefix? I would like to compare the way Juniper routers communicate with Cisco routers.

Best regards,
Peter

[Andrew WEISS · Accepted solution]

Peter, 

Thanks for your reply.  Please see CSCui82452 for more details.  The only workaround that currently exits is to use 2 different loopbacks to establish two different BGP sessions BGP sessions to each of the RR -- one that does labeled-unicast only (send-label AND a route-map to set mpls-label on the appropriate prefixes) and the second one for all the other IPv4 address families.  It's certainly not pretty especially if you have a 3rd BGP session for IPv6, but it's the only workaround that exists.   

P.S.  I spoke with Cisco today regarding the following problem who told me that "it’s a difficult and risky fix & that’s why Development team kept it this way. So, I assume that if this behavior is to change, it won’t happen any time soon."

Kind regards,

Andrew

[Peter Paluch]

Andrew,

Thank you for updating this issue and keeping us informed.

The workaround is interesting... and quite logical, to be honest, even though it is neither pretty nor scalable. I wonder, though, what part of the fix is considered by Cisco to be "difficult and risky", and why. It's kind of sad that this bug is not going to be fixed soon.

Best regards,
Peter