[j-nsp] nssa default route

[Harry Reynolds]

A redistributed static may behave differently than the aut-generated default. Can't recall but good point.

Regards



-----Original Message-----
From: Paul Zugnoni [mailto:paul.zugnoni at jivesoftware.com] 
Sent: Thursday, August 16, 2012 11:39 AM
To: Harry Reynolds
Cc: ryanL; juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] nssa default route

Wait, what disable statement? My workaround for putting a default in an otherwise stub area where I don't have an active Ospf area 0 adjacency ( Srx cluster with only BGP on the other side) has been to make it a NSSA with redistributed static 0/0 ( on juniper, anyway)

Paul Z

(thumbs)

On Aug 16, 2012, at 11:35, "Harry Reynolds" <harry at juniper.net> wrote:

> Does the "remaining" mx have an active area 0 adjacency, or just an area 0 interface? IIRC, you need the former. In theory, if there is no area 0 adjacency, then when send the default? Where will the resulting inter-area traffic go? Routers in the nssa should not need the default just to get to the abr, it's needed to get to the best abr that can then shunt you over or into area 0, but that requires an area 0 adjacency.
> 
> Have you tried the disable statement and if so, any change?
> 
> Regards
> 
> 
> 
> 
> -----Original Message-----
> From: ryanL [mailto:ryan.landry at gmail.com]
> Sent: Thursday, August 16, 2012 11:22 AM
> To: Harry Reynolds
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] nssa default route
> 
> but it shouldn't lose connectivity to area 0, as my ex's have links to both area 0 routers, and ospf neighbor adjacencies with them.
> 
>> show ospf neighbor
> Address          Interface              State     ID               Pri  Dead
> 10.254.1.1       ae0.0                  Full      10.255.1.2       128    35
> 10.254.1.2       ae1.0                  Full      1.1.1.1     128    39
> 10.254.1.4       ae2.0                  Full      1.1.1.2     128    39
> 
> when i kill mx2, i lose ospf on ae2.0 which is accurate.
> 
> and, the abr being the remaining mx which already lives in area 0, that seems silly that it would think that it has lost connectivity to area 0, no? or am i misunderstanding.
> 
> thanks!
> 
> On Thu, Aug 16, 2012 at 11:10 AM, Harry Reynolds <harry at juniper.net> wrote:
>> Sounds like a case of "active backbone detection". A feature where if the abr loses its area 0 adjacency it ceases to adv the default.
>> 
>> There is a hidden (unsupported) command to disable:
>> 
>> set protocols ospf no-active-backbone
>> 
>> started with 7.2, IIRC:
>> 
>> http://www.juniper.net/techpubs/software/junos/junos72/rn-sw-72/rn-ne
>> w
>> -features.html#rn-new-features
>> 
>> 
>> 
>> 
>> OSPF active backbone detection-The JUNOS software now supports active 
>> backbone detection. There are two changes in Open Shortest Path First 
>> (OSPF) default behavior associated with active backbone detection, 
>> but there are no new configuration statements. First, if an Area 
>> Border Router (ABR) loses its OSPF adjacency to backbone area 0, then 
>> the router no longer announces the default into connected stub areas 
>> or not-so-stubby areas (NSSAs) via the configuration under the nssa 
>> or stub default-metric statements at the [edit protocols ospf] 
>> hierarchy level. This makes it possible to reroute traffic through 
>> another ABR that has an active adjacency to backbone area 0. Second, 
>> an ABR with no active backbone area 0 adjacency now considers 
>> inter-area traffic destined to areas that are not directly connected 
>> to that ABR. This change does not obviate the need for virtual links 
>> in the case of a partitioned area. [Routing Protocols]
>> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp