Re: [j-nsp] ISIS Routing Problem
> -Original Message- > From: Felix Schueren [mailto:felix.schue...@hosteurope.de] > Sent: Wednesday, June 16, 2010 10:16 PM > To: Eric Van Tol > Cc: juniper-nsp > Subject: Re: [j-nsp] ISIS Routing Problem > > Eric, > > IS-IS always prefers routes reachable via L1 over those reachable via > L2, and in this case the IS-IS route selection will only ever export the > L1 version of the route to the main junos kernel, and _after_ the IS-IS > decision (use L1 over L2) was made junos will apply the global route > preference mapping, then put the IS-IS route into it's routing tables. > > Kind regards, > > Felix Thanks, that clears it up for me. Just tried the static route solution and now it looks like I'll be headed over to cisco-nsp because neither my route-maps for ISIS or BGP are working properly on the 6509s. -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ISIS Routing Problem
On Thursday 17 June 2010 07:28:10 am Eric Van Tol wrote: > Due to IOS's inability to do MD5 > authentication at level 2,... This isn't true. IOS supports MD5 Authentication at both L1 and L2. We have it running with no dramas: key chain some-name-l2 key 1 key-string password ! int gi0/1 isis authentication mode md5 isis authentication key-chain some-name-l2 ! router isis 1 authentication mode md5 authentication key-chain some-name-l2 level-2 Not defining the level on the interface defaults the authentication (and its mode) to L2, however, you can further define it in case you're also running authentication for L1 on the same interface. This is IOS 12.2(33)SRC or later, although I can't think of any reason why it wouldn't be supported in other trains. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ISIS Routing Problem
On Thursday 17 June 2010 09:43:36 am Eric Van Tol wrote: > I should have specified...I'm running 12.1 on Sup2 > MSFC2s. It's not supported in this version. That makes a lot of difference, especially for the archives :-). Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ISIS Routing Problem
Eric, Check out section 3.10.2 of RFC 1195 as I believe it answers your question on why L1 routes are always preferred to L2 routes. There's also additional information in RFC 5302 Section 3. On Wed, Jun 16, 2010 at 9:56 PM, Eric Van Tol wrote: > I do need L2 enabled, as they are the two core routers, and as such, are > the backbone of the network. It's a good suggestion, though. I'll probably > end up just going the static route way, at least until I can swap these out > with two almost-out-of-service Sup720s that can run some decent code. > > As for the L1 route preference, that's what I don't understand. If R1/R2 > are getting each other's loopbacks through L2 with a preference of 18, but > then I swap the L1/L2 preferences so that L2 now has a pref of 15, why would > the L1 route always get preferred? > > -evt > > From: Dan Evans [mailto:pzdev...@gmail.com] > Sent: Wednesday, June 16, 2010 9:05 PM > To: Eric Van Tol > Cc: juniper-nsp > Subject: Re: [j-nsp] ISIS Routing Problem > > Eric, > > Since R1 and R2 are L1/L2 routers they'll each always prefer the L1 route > over the L2 route due to default route preference. It's an interesting > situation for sure. Removing the loopback from L1 isolates R1 and R2 from > advertising their loopbacks to R3 and R4, but with the loopback enabled for > Level 1 you'll always get the long path for R1 to R2 traffic. > > Do you require R1 and R2 to have L2 enabled on the R1--R2 link? You could > turn off L2 on that link and it should give you the result I think you're > expecting. R1 and R2 and still be L1/L2 or L2 only with any other upstream > routers to keep L2 continuity with any routers not in your original > topology. > > > On Wed, Jun 16, 2010 at 7:28 PM, Eric Van Tol e...@atlantech.net>> wrote: > Hi all, > I'm scratching my head over this one and I'm sure the answer is very > simple. I have four routers: > > R1 --- R2 > | | > | | > R3 --- R4 > > R1 and R2 are L1/L2 routers. R3 and R4 are L1-only routers. Due to IOS's > inability to do MD5 authentication at level 2, I cannot make R3 and R4 L1/L2 > routers. R1 and R2 are running 9.6R3.8. Now the problem... > > I have 'interface lo0.0 passive' configured on both R1 and R2. The > loopback is being injected into the L1 level, then being re-injected back > into the L2 level when it's seen from R3 and R4. I've tried messing with > the preference values for level 2 on R1 and R2, but the loopbacks are always > being preferred through the L1 level. If I configure 'interface lo0.0 level > 1 disable' on R1 and R2, the loopbacks disappear, but then I end up with BGP > recursive route lookups from R3 and R4. I'd prefer not to configure static > routes for the R1 and R2 loopbacks on R3 and R4, but that seems to be my > only recourse at this point. > > Am I missing something simple here or am I just going to have to do the > static routes on R3 and R4, redistribute those between R3 and R4, but deny > their redistribution up to level 2? > > Thanks, > evt > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net> > https://puck.nether.net/mailman/listinfo/juniper-nsp > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ISIS Routing Problem
Eric, As for the L1 route preference, that's what I don't understand. If R1/R2 are getting each other's loopbacks through L2 with a preference of 18, but then I swap the L1/L2 preferences so that L2 now has a pref of 15, why would the L1 route always get preferred? IS-IS always prefers routes reachable via L1 over those reachable via L2, and in this case the IS-IS route selection will only ever export the L1 version of the route to the main junos kernel, and _after_ the IS-IS decision (use L1 over L2) was made junos will apply the global route preference mapping, then put the IS-IS route into it's routing tables. Kind regards, Felix -- Felix Schüren Head of Network --- Host Europe GmbH - http://www.hosteurope.de Welserstraße 14 - 51149 Köln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678 Geschäftsführer: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ISIS Routing Problem
I do need L2 enabled, as they are the two core routers, and as such, are the backbone of the network. It's a good suggestion, though. I'll probably end up just going the static route way, at least until I can swap these out with two almost-out-of-service Sup720s that can run some decent code. As for the L1 route preference, that's what I don't understand. If R1/R2 are getting each other's loopbacks through L2 with a preference of 18, but then I swap the L1/L2 preferences so that L2 now has a pref of 15, why would the L1 route always get preferred? -evt From: Dan Evans [mailto:pzdev...@gmail.com] Sent: Wednesday, June 16, 2010 9:05 PM To: Eric Van Tol Cc: juniper-nsp Subject: Re: [j-nsp] ISIS Routing Problem Eric, Since R1 and R2 are L1/L2 routers they'll each always prefer the L1 route over the L2 route due to default route preference. It's an interesting situation for sure. Removing the loopback from L1 isolates R1 and R2 from advertising their loopbacks to R3 and R4, but with the loopback enabled for Level 1 you'll always get the long path for R1 to R2 traffic. Do you require R1 and R2 to have L2 enabled on the R1--R2 link? You could turn off L2 on that link and it should give you the result I think you're expecting. R1 and R2 and still be L1/L2 or L2 only with any other upstream routers to keep L2 continuity with any routers not in your original topology. On Wed, Jun 16, 2010 at 7:28 PM, Eric Van Tol mailto:e...@atlantech.net>> wrote: Hi all, I'm scratching my head over this one and I'm sure the answer is very simple. I have four routers: R1 --- R2 | | | | R3 --- R4 R1 and R2 are L1/L2 routers. R3 and R4 are L1-only routers. Due to IOS's inability to do MD5 authentication at level 2, I cannot make R3 and R4 L1/L2 routers. R1 and R2 are running 9.6R3.8. Now the problem... I have 'interface lo0.0 passive' configured on both R1 and R2. The loopback is being injected into the L1 level, then being re-injected back into the L2 level when it's seen from R3 and R4. I've tried messing with the preference values for level 2 on R1 and R2, but the loopbacks are always being preferred through the L1 level. If I configure 'interface lo0.0 level 1 disable' on R1 and R2, the loopbacks disappear, but then I end up with BGP recursive route lookups from R3 and R4. I'd prefer not to configure static routes for the R1 and R2 loopbacks on R3 and R4, but that seems to be my only recourse at this point. Am I missing something simple here or am I just going to have to do the static routes on R3 and R4, redistribute those between R3 and R4, but deny their redistribution up to level 2? Thanks, evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net> https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ISIS Routing Problem
> -Original Message- > From: Mark Tinka [mailto:mti...@globaltransit.net] > Sent: Wednesday, June 16, 2010 9:37 PM > To: juniper-nsp@puck.nether.net > Cc: Eric Van Tol > Subject: Re: [j-nsp] ISIS Routing Problem > > On Thursday 17 June 2010 07:28:10 am Eric Van Tol wrote: > > > Due to IOS's inability to do MD5 > > authentication at level 2,... > > This isn't true. I should have specified...I'm running 12.1 on Sup2 MSFC2s. It's not supported in this version. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ISIS Routing Problem
Eric, Since R1 and R2 are L1/L2 routers they'll each always prefer the L1 route over the L2 route due to default route preference. It's an interesting situation for sure. Removing the loopback from L1 isolates R1 and R2 from advertising their loopbacks to R3 and R4, but with the loopback enabled for Level 1 you'll always get the long path for R1 to R2 traffic. Do you require R1 and R2 to have L2 enabled on the R1--R2 link? You could turn off L2 on that link and it should give you the result I think you're expecting. R1 and R2 and still be L1/L2 or L2 only with any other upstream routers to keep L2 continuity with any routers not in your original topology. On Wed, Jun 16, 2010 at 7:28 PM, Eric Van Tol wrote: > Hi all, > I'm scratching my head over this one and I'm sure the answer is very > simple. I have four routers: > > R1 --- R2 > | | > | | > R3 --- R4 > > R1 and R2 are L1/L2 routers. R3 and R4 are L1-only routers. Due to IOS's > inability to do MD5 authentication at level 2, I cannot make R3 and R4 L1/L2 > routers. R1 and R2 are running 9.6R3.8. Now the problem... > > I have 'interface lo0.0 passive' configured on both R1 and R2. The > loopback is being injected into the L1 level, then being re-injected back > into the L2 level when it's seen from R3 and R4. I've tried messing with > the preference values for level 2 on R1 and R2, but the loopbacks are always > being preferred through the L1 level. If I configure 'interface lo0.0 level > 1 disable' on R1 and R2, the loopbacks disappear, but then I end up with BGP > recursive route lookups from R3 and R4. I'd prefer not to configure static > routes for the R1 and R2 loopbacks on R3 and R4, but that seems to be my > only recourse at this point. > > Am I missing something simple here or am I just going to have to do the > static routes on R3 and R4, redistribute those between R3 and R4, but deny > their redistribution up to level 2? > > Thanks, > evt > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ISIS Routing Problem
Hi all, I'm scratching my head over this one and I'm sure the answer is very simple. I have four routers: R1 --- R2 | | | | R3 --- R4 R1 and R2 are L1/L2 routers. R3 and R4 are L1-only routers. Due to IOS's inability to do MD5 authentication at level 2, I cannot make R3 and R4 L1/L2 routers. R1 and R2 are running 9.6R3.8. Now the problem... I have 'interface lo0.0 passive' configured on both R1 and R2. The loopback is being injected into the L1 level, then being re-injected back into the L2 level when it's seen from R3 and R4. I've tried messing with the preference values for level 2 on R1 and R2, but the loopbacks are always being preferred through the L1 level. If I configure 'interface lo0.0 level 1 disable' on R1 and R2, the loopbacks disappear, but then I end up with BGP recursive route lookups from R3 and R4. I'd prefer not to configure static routes for the R1 and R2 loopbacks on R3 and R4, but that seems to be my only recourse at this point. Am I missing something simple here or am I just going to have to do the static routes on R3 and R4, redistribute those between R3 and R4, but deny their redistribution up to level 2? Thanks, evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
