harry at juniper
Aug 16, 2012, 11:46 AM
Post #9 of 11
A redistributed static may behave differently than the aut-generated default. Can't recall but good point.
From: Paul Zugnoni [mailto:paul.zugnoni [at] jivesoftware]
Sent: Thursday, August 16, 2012 11:39 AM
To: Harry Reynolds
Cc: ryanL; juniper-nsp [at] puck
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)
On Aug 16, 2012, at 11:35, "Harry Reynolds" <harry [at] juniper> 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?
> -----Original Message-----
> From: ryanL [mailto:ryan.landry [at] gmail]
> Sent: Thursday, August 16, 2012 11:22 AM
> To: Harry Reynolds
> Cc: juniper-nsp [at] puck
> 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 184.108.40.206 128 39
> 10.254.1.4 ae2.0 Full 220.127.116.11 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.
> On Thu, Aug 16, 2012 at 11:10 AM, Harry Reynolds <harry [at] juniper> 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:
>> 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
juniper-nsp mailing list juniper-nsp [at] puck