cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1063
Views
0
Helpful
3
Replies

Using labeled-unicast in a multivendor environment.

Andrew WEISS
Level 1
Level 1

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

 

 

  

 

3 Replies 3

Peter Paluch
Cisco Employee
Cisco Employee

Andrew,

I have responded to your query in the MPLS forum:

https://supportforums.cisco.com/discussion/12390691/labeled-unicast-problems#comment-10181261

I have no immediate solution - I am trying to understand what is going on.

Best regards,
Peter

paul mebale
Level 1
Level 1

Hi all

I am presently facing an issue alike while processing iBGP between cisco and juniper device.

The "dont−capability−negotiate" doesn't solve the issue. VPNV4 prefixes are not exchanged with the juniper peer.
The only way to establish the bgp session is to delete the "family inet-vpn unicast"
command from the juniper side whereas it is used to set the vpnv4 AF.

From the cisco' side i have

Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Address family VPNv4 Unicast: advertised

From the juniper side i have
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast inet-vpn-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)

Is there a way to solve this interoperability issue?

Regards

Hi @paul mebale ,

You posted this question in another conversation. I will try to help in this other conversation.

Regards,

Regards,
Harold Ritter, CCIE #4168 (EI, SP)