[c-nsp] IOS JUNOS MPLS-TE interoperability

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Fri Jun 6 01:51:19 EDT 2008


Jeff,

it comes down to a different interpretation of RFC4090 where a JunOS
midpoint acting as a PLR expects the "node protection desired (0x10)"
bit in SESSION_ATTRIBUTE flags in the PATH message of the
to-be-protected tunnel to build a NNHOP tunnel, while IOS only sets (and
interprets) "Local protection desired (0x01)" bit, if local protection
(to whether it be nhop/nnhop tunnel) is needed. 
Hence the additional knob "node-protect" to set the appropriate bit on
the IOS headend. If this bit is not set, a Juniper will only try to
build a NHOP backup tunnel.

Hope this is clear..

	oli

Jeff Tantsura <mailto:jeff.nsp at gmail.com> wrote on Thursday, June 05,
2008 12:05 PM:

> Hi Oliver,
> 
> Could you please elaborate more on the interop issue?
> 
> Thanks,
> Jeff
> 
>> -----Original Message-----
>> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
>> bounces at puck.nether.net] On Behalf Of Oliver Boehmer (oboehmer)
>> Sent: donderdag 5 juni 2008 9:11
>> To: Rubens Kuhl Jr.; cisco-nsp at puck.nether.net; juniper-
>> nsp at puck.nether.net Subject: Re: [c-nsp] IOS JUNOS MPLS-TE
>> interoperability 
>> 
>> Rubens Kuhl Jr. <> wrote on Thursday, June 05, 2008 2:41 AM:
>> 
>>> Hi,
>>> 
>>> Does anyone has experience with MPLS-TE interoperability between IOS
>>> (specifically ME6500, but it's probably like any other 12.2SX IOS)
>>> and JUNOS (recent/stable/good-for-service-providers version) ?
>>> 
>>> I was wondering about 2 cenarios in particular:
>>> 1) JUNOS as head-end or tail-end, but not middle-point
>>> 2) JUNOS as head-end, tail-end and middel-point
>>> 
>>> All routers would be in the same OSPF area 0, within the same AS #;
>>> TE is done by explicit naming of both primary, secondary paths, and
>>> a dynamic backup path. AUTOBW is desired. On IOS, traffic is
>>> injected on the tunnel using static route to the loopback address;
>>> OSPF contains only link states and loopbacks, directly-connected,
>>> customer static routes or customer dynamic routes are propagated
>>> via IBGP. 
>> 
>> The main Interop issue I'm aware of is TE-FRR protection where IOS
>> acting as a headend needs to be configured with the "node-protect"
>> option ("tunnel mpls traffic-eng fast-reroute node-protect") in order
>> for JunOS midpoints/PLR to be able to protect this tunnel using a
>> NNHOP backup (without this knob, only link protection is achieved).
>> Stuff like auto-bw or methods to steer traffic down the tunnel are
>> all local to the headend. 
>> 
>> So if you're not using TE-FRR (and I'm not sure if you do reading
>> the above), you should be fine. 
>> 
>> 	oli
>> _______________________________________________
>> 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