[c-nsp] How to effect a totally stubby area in IS-IS

Vitkovsky, Adam avitkovsky at emea.att.com
Sat Jun 25 09:03:31 EDT 2011 

Oh crap I ran into the same issue when I tried to reproduce the old lab
I have used the 122-33.SRE on 7200s and got the same error:

%CLNS: Duplicate system ID configured in ip vrf <default> with router isis 1

It's working though on the ancient 124-24 (old lab from which I took the config)

If the same sys-id can't be configured on different isis instances than to me it appears the multi-area feature is not supported

This would be a question for the Cisco folks whether the feature has been depreciated form the new ios-es

adam

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jared Gillis
Sent: Friday, June 24, 2011 11:35 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] How to effect a totally stubby area in IS-IS

On 06/24/2011 12:05 AM, Vitkovsky, Adam wrote:
> Hi there,
> I believe what you are looking for is the isis multi-area feature:

I've been playing with the IS-IS multiarea feature, and it's not quite working for me. What the end result I get is that the POP routers do only receive default information from the BB routers, and the BB routers do receive prefixes from the POPs, but the BB does not redistribute the routes from the POPs in the BB IS-IS area, so there's really no reachability to those prefixes.

Is the config you posted below from production? If so, on what platform and code release? I am trying to reproduce it in my lab and certain statements aren't being accepted by my BB router (7600 on 12.2SR). I'll comment on specifics below as appropriate.

> 
> =============================================================
> Router in the core:
> router isis 
>  net 49.0000.0000.0000.0001.00  
>  net 49.9999.0000.0000.0001.00
>  is-type level-2-only
>  log-adjacency-changes
>  passive-interface Loopback1
> 

Our design has no "core", the BBs are the core of the network.

> 
> =============================================================
> BB1
> interface Serial1/0
>  ip address 12.0.0.2 255.255.255.0
>  ip router isis AREA-0
>  serial restart-delay 0
>  clns router isis AREA-0

We're only running IP ISIS, so we don't have any interfaces set "clns router isis"

> !
> interface Serial1/1
>  ip address 24.0.0.2 255.255.255.0
>  ip router isis AREA-1
>  serial restart-delay 0
> !
> interface Serial1/2
>  ip address 25.0.0.2 255.255.255.0
>  ip router isis AREA-2
>  serial restart-delay 0
> 

> ----------------------------------------------------------
> -if BB can't see the core it'll stop adv LSPs with ATT bit
> -thus POP will not install default towards that BB router
> 
> clns filter-set nonexist permit 49.9999
> 
> route-map nonexist permit 10
>  match clns address nonsexist
> -----------------------------------------------------------
> 

Since the BBs are the top of the network, I don't think the above is necessary.

> router isis AREA-0	         <-L12 by default
>  net 49.0000.0000.0000.0002.00
>  log-adjacency-changes
>  partition avoidance
> !
> router isis AREA-1
>  net 49.0001.0000.0000.0002.00
>  is-type level-1
>  set-attached-bit route-map nonexist
>  log-adjacency-changes
>  partition avoidance
> !
> router isis AREA-2
>  net 49.0002.0000.0000.0002.00
>  is-type level-1
>  set-attached-bit route-map nonexist
>  log-adjacency-changes
>  partition avoidance

When I tried to configure 2 areas on my BB router with NET addresses as you have above, I get the following error:
%CLNS: Duplicate system ID configured in ip vrf <default> with router isis bb
The only way I can get the system to accept it is to use a different system ID.

> (redistribution between L1 and L12 processes is automatic)

That's what my understanding was, but I'm not seeing it happen. The BBs are L12 with each other, and L1 to the POPs, the POPs announce the prefix to the BB, but it does not get propagated to the BB area. I've tried manually putting redistribute commands ('redistribute isis <pop area tag> ip' and 'redistribute isis ip level-1 into level-2' ) in the BB area, with no effect.

> =============================================================
> BB2
> interface Serial1/0
>  ip address 13.0.0.3 255.255.255.0
>  ip router isis AREA-0
>  serial restart-delay 0
>  clns router isis AREA-0
> !
> interface Serial1/1
>  ip address 34.0.0.3 255.255.255.0
>  ip router isis AREA-1
>  serial restart-delay 0
> !
> interface Serial1/2
>  ip address 35.0.0.3 255.255.255.0
>  ip router isis AREA-2
>  serial restart-delay 0
> 
> 
> clns filter-set nonexist permit 49.9999
> 
> route-map nonexist permit 10
>  match clns address nonsexist
> 
> router isis AREA-0
>  net 49.0000.0000.0000.0003.00
>  log-adjacency-changes
>  partition avoidance
> !
> router isis AREA-1
>  net 49.0001.0000.0000.0003.00
>  is-type level-1
>  set-attached-bit route-map nonexist
>  log-adjacency-changes
>  partition avoidance
> !
> router isis AREA-2
>  net 49.0002.0000.0000.0003.00
>  is-type level-1
>  set-attached-bit route-map nonexist
>  log-adjacency-changes
>  partition avoidance
> !
> 
> =============================================================
> POP1
> router isis 
>  net 49.0001.0000.0000.0004.00
>  is-type level-1
>  passive-interface Loopback1
> 
> =============================================================
> POP2
> router isis 
>  net 49.0002.0000.0000.0005.00
>  is-type level-1
>  passive-interface Loopback1
> 
> 
> adam
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Barak
> Sent: Friday, June 24, 2011 3:29 AM
> To: cisco-nsp at puck.nether.net; Jared Gillis
> Subject: Re: [c-nsp] How to effect a totally stubby area in IS-IS
> 
> --- On Thu, 6/23/11, Jared Gillis <jared.a.gillis at gmail.com> wrote:
> 
>> Okay, I see what this is doing. I set this up in the lab,
>> and it worked as you described, however, if I have two POPs
>> connected to one BB router, both POP routers see each
>> other's L1 announcements (I assume because they are in the
>> same area). This config should limit the "leaked" routes to
>> only other POPs directly connected to the same BB, but we
>> really need to get the POPs to only ever receive default, as
>> we've got upwards of 30 POPs connecting to each BB router.
>> Also, to throw another monkey wrench in the works, each POP
>> is redundantly homed off two BBs, so it would learn double
>> the number of prefixes learned by the POP.
>>
>> Here's a quick diagram of what the network needs to look
>> like:
>> BB1---BB2
>> |\     /|
>> | \   / |
>> \  POP1 /
>>  \     /
>>   \   /
>>    POP2
>>
>> The BBs should be learn all routes in the network (L2), and
>> the POPs can be whatever level, but they should only learn
>> default, ever.
>>
> 
> That type of topology will be problematic in this context - if BB1 and BB2 are in different areas, then POP1 and POP2 would both be single-homed.  If they're in the same area, then POP1 will see POP2's routes.  If the POPs are L1/L2, they'll definitely see each other's routes.  Would it work to use ISIS for just the loopbacks and interfaces, and then carry all of the other routes in BGP?
> 
> Alternatively, you could add more routers to the topology so that they could stay dual-homed in a single area, but that can be expensive depending on the platform.
> 
> David Barak
> Need Geek Rock?  Try The Franchise: 
> http://www.listentothefranchise.com
> 
> _______________________________________________
> 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/

_______________________________________________
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