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.
I'm somewhat fearful that what I've exposed above will remained unanswered, since there are very few people that use/need labeled-unicast. Labeled-unicast is used mostly by "non-profit" ISPs that wish to provide carrier-to-carrier VPN services.
Kind regards,
Andrew
