[j-nsp] ISIS L1 and L2 adjacency

[Saku Ytti]

To OP. I hope this is to brush up towards exam or something. I don't
think there is use case for areas in ISIS or multi-level ISIS. If you
need scale, have separate L2 segments, combine them with BGP for
seamless MPLS.

On 18 July 2017 at 15:11, Dave Bell <me at geordish.org> wrote:
> For an adjacency in L1 to come up, the area ID must match. This is not the
> case for L2.
>
> http://www.cisco.com/c/en/us/support/docs/ip/integrated-intermediate-system-to-intermediate-system-is-is/200293-IS-IS-Adjacency-and-Area-Types.html
>
> On 18 July 2017 at 13:02, Aaron Gould <aaron1 at gvtc.com> wrote:
>
>> https://www.juniper.net/assets/us/en/local/pdf/study-
>> guide/study-guide-jncip
>> .pdf
>>
>>
>>
>> page 279 of 708 - shows the topology
>>
>>
>>
>> page 295 and 296 of 708 - begins to speak of a problem with r5 not being
>> able to become adjacent with r6 and r7 because the NET's area ID portion is
>> different at Level 1 with r6 and r7.  once changed to 0002 to match r6 and
>> r7 level 1, everything works.
>>
>>
>>
>> Question, why doesn't this then create an issue with r5 now not having a
>> matching NET area ID 0001 with r3 and r4 and thus creating the same issue
>> that we previously saw with r6 and r7, but now with r3 and r4 ?
>>
>>
>>
>> in other words, if the adjaceny problem from r5 to r6 and r7 was because of
>> a mismatched area ID, then why after changing r5's area ID to 0002 to match
>> r6 and r7, why didn't this break the adjacencies with r3 and r4 since now
>> r5
>> deosn't match r3 and r4 area id of 0001 ?
>>
>>
>>
>> -Aaron Gould
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
  ++ytti