Mailing List Archive: nsp: juniper

nssa default route

Index | Next | Previous | View Threaded

ryan.landry at gmail

Aug 16, 2012, 10:47 AM

Post #1 of 11 (634 views)
Permalink

nssa default route

tl;dr - when i kill one of my mx's, the default route disappears on my
ex's. and, the remaining ospf database entry is for the router that
died, not the router that remains active.

i might be a little slow on the uptick here, but this seems pretty
straight forward to me. i can't figure out what's up. i'm pretty new
to junos, so bear with me.

m = mx
e = ex
standard physical full mesh

mx1 lo0 = 1.1.1.1
mx2 lo0 = 1.1.1.2

m - m
| x |
e - e

my mx are ospf area 0 and area 1 nssa. the ex are area 1 nssa only.
mx's inject default into nssa.

config on mx:

//
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface ae0.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
}
area 0.0.0.1 {
nssa {
default-lsa default-metric 10;
no-summaries;
}
interface ae1.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
interface ae2.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
}
//

config on ex:

//
area 0.0.0.1 {
nssa;
interface lo0.0 {
passive;
}
interface ae1.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
interface ae2.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
interface ae0.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
}
//

routes before killing mx2:
>show route 0.0.0.0

inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[OSPF/10] 00:08:40, metric 15
> to 10.254.1.2 via ae1.0
to 10.254.1.4 via ae2.0

ospf database before killing mx2:
> show ospf database

OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.255.1.1 10.255.1.1 0x8000048e 2283 0x20 0x7c36 168
Router 10.255.1.2 10.255.1.2 0x80000486 2284 0x20 0x1e89 168
Router 1.1.1.1 1.1.1.2 0x800003e2 513 0x20 0x7006 72
Router 1.1.1.2 1.1.1.2 0x800003e8 1082 0x20 0x7bf2 72
Summary 0.0.0.0 1.1.1.1 0x80000001 513 0x20 0xeaa8 28
Summary 0.0.0.0 1.1.1.2 0x800000b4 1082 0x20 0x7d61 28

routes after killing mx2:
> show route 0.0.0.0
#<----nothing here
{master:0}

ex ospf database after killing mx2:
> show ospf database

OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.255.1.1 10.255.1.1 0x80000490 41 0x20 0x286f 144
Router 10.255.1.2 10.255.1.2 0x80000488 42 0x20 0x6030 144
Router 1.1.1.1 1.1.1.2 0x800003e2 612 0x20 0x7006 72
Router 1.1.1.2 1.1.1.2 0x800003e8 1181 0x20 0x7bf2 72
Summary 0.0.0.0 1.1.1.2 0x800000b4 1181 0x20 0x7d61
28 #<---dead router!

so, what happened to my remaining router's ospf database entry, and
that secondary default route?

thanks for any insight. i'm going to open a case with jtac as well.

ryanL
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

harry at juniper

Aug 16, 2012, 11:10 AM

Post #2 of 11 (630 views)
Permalink

Re: nssa default route [In reply to]

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-new-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]

-----Original Message-----
From: juniper-nsp-bounces [at] puck [mailto:juniper-nsp-bounces [at] puck] On Behalf Of ryanL
Sent: Thursday, August 16, 2012 10:48 AM
To: juniper-nsp [at] puck
Subject: [j-nsp] nssa default route

tl;dr - when i kill one of my mx's, the default route disappears on my ex's. and, the remaining ospf database entry is for the router that died, not the router that remains active.

i might be a little slow on the uptick here, but this seems pretty straight forward to me. i can't figure out what's up. i'm pretty new to junos, so bear with me.

m = mx
e = ex
standard physical full mesh

mx1 lo0 = 1.1.1.1
mx2 lo0 = 1.1.1.2

m - m
| x |
e - e

my mx are ospf area 0 and area 1 nssa. the ex are area 1 nssa only.
mx's inject default into nssa.

config on mx:

//
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface ae0.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
}
area 0.0.0.1 {
nssa {
default-lsa default-metric 10;
no-summaries;
}
interface ae1.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
interface ae2.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
}
//

config on ex:

//
area 0.0.0.1 {
nssa;
interface lo0.0 {
passive;
}
interface ae1.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
interface ae2.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
interface ae0.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
}
//

routes before killing mx2:
>show route 0.0.0.0

inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[OSPF/10] 00:08:40, metric 15
> to 10.254.1.2 via ae1.0
to 10.254.1.4 via ae2.0

ospf database before killing mx2:
> show ospf database

OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.255.1.1 10.255.1.1 0x8000048e 2283 0x20 0x7c36 168
Router 10.255.1.2 10.255.1.2 0x80000486 2284 0x20 0x1e89 168
Router 1.1.1.1 1.1.1.2 0x800003e2 513 0x20 0x7006 72
Router 1.1.1.2 1.1.1.2 0x800003e8 1082 0x20 0x7bf2 72
Summary 0.0.0.0 1.1.1.1 0x80000001 513 0x20 0xeaa8 28
Summary 0.0.0.0 1.1.1.2 0x800000b4 1082 0x20 0x7d61 28

routes after killing mx2:
> show route 0.0.0.0
#<----nothing here
{master:0}

ex ospf database after killing mx2:
> show ospf database

OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.255.1.1 10.255.1.1 0x80000490 41 0x20 0x286f 144
Router 10.255.1.2 10.255.1.2 0x80000488 42 0x20 0x6030 144
Router 1.1.1.1 1.1.1.2 0x800003e2 612 0x20 0x7006 72
Router 1.1.1.2 1.1.1.2 0x800003e8 1181 0x20 0x7bf2 72
Summary 0.0.0.0 1.1.1.2 0x800000b4 1181 0x20 0x7d61
28 #<---dead router!

so, what happened to my remaining router's ospf database entry, and that secondary default route?

thanks for any insight. i'm going to open a case with jtac as well.

ryanL
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

devinkennedy415 at hotmail

Aug 16, 2012, 11:15 AM

Post #3 of 11 (617 views)
Permalink

Re: nssa default route [In reply to]

Hi Ryan:

Have you already tried adding the 'type-7' knob to the NSSA area?

[edit]
Devin [at] MX10-# set protocols ospf area 1 nssa default-lsa ?
Possible completions:
<[Enter]> Execute this command
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
default-metric Metric for the default route in this area
(1..16777215)
metric-type External metric type for the default type 7 LSA
(1..2)
type-7 Flood type 7 default LSA if no-summaries is
configured <<<<<<<<<<<<<<<<<< This knob
| Pipe through a command

Since you are configuring 'no-summaries' and the default route comes through
as such I believe you need to allow it as a type-7 instead.

-----Original Message-----
From: juniper-nsp-bounces [at] puck
[mailto:juniper-nsp-bounces [at] puck] On Behalf Of ryanL
Sent: Thursday, August 16, 2012 1:48 PM
To: juniper-nsp [at] puck
Subject: [j-nsp] nssa default route

tl;dr - when i kill one of my mx's, the default route disappears on my ex's.
and, the remaining ospf database entry is for the router that died, not the
router that remains active.

i might be a little slow on the uptick here, but this seems pretty straight
forward to me. i can't figure out what's up. i'm pretty new to junos, so
bear with me.

m = mx
e = ex
standard physical full mesh

mx1 lo0 = 1.1.1.1
mx2 lo0 = 1.1.1.2

m - m
| x |
e - e

my mx are ospf area 0 and area 1 nssa. the ex are area 1 nssa only.
mx's inject default into nssa.

config on mx:

//
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface ae0.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
}
area 0.0.0.1 {
nssa {
default-lsa default-metric 10;
no-summaries;
}
interface ae1.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
interface ae2.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
}
//

config on ex:

//
area 0.0.0.1 {
nssa;
interface lo0.0 {
passive;
}
interface ae1.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
interface ae2.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
interface ae0.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
}
//

routes before killing mx2:
>show route 0.0.0.0

inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[OSPF/10] 00:08:40, metric 15
> to 10.254.1.2 via ae1.0
to 10.254.1.4 via ae2.0

ospf database before killing mx2:
> show ospf database

OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.255.1.1 10.255.1.1 0x8000048e 2283 0x20 0x7c36 168
Router 10.255.1.2 10.255.1.2 0x80000486 2284 0x20 0x1e89 168
Router 1.1.1.1 1.1.1.2 0x800003e2 513 0x20 0x7006 72
Router 1.1.1.2 1.1.1.2 0x800003e8 1082 0x20 0x7bf2 72
Summary 0.0.0.0 1.1.1.1 0x80000001 513 0x20 0xeaa8 28
Summary 0.0.0.0 1.1.1.2 0x800000b4 1082 0x20 0x7d61 28

routes after killing mx2:
> show route 0.0.0.0
#<----nothing here
{master:0}

ex ospf database after killing mx2:
> show ospf database

OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.255.1.1 10.255.1.1 0x80000490 41 0x20 0x286f 144
Router 10.255.1.2 10.255.1.2 0x80000488 42 0x20 0x6030 144
Router 1.1.1.1 1.1.1.2 0x800003e2 612 0x20 0x7006 72
Router 1.1.1.2 1.1.1.2 0x800003e8 1181 0x20 0x7bf2 72
Summary 0.0.0.0 1.1.1.2 0x800000b4 1181 0x20 0x7d61
28 #<---dead router!

so, what happened to my remaining router's ospf database entry, and that
secondary default route?

thanks for any insight. i'm going to open a case with jtac as well.

ryanL
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

ryan.landry at gmail

Aug 16, 2012, 11:22 AM

Post #4 of 11 (614 views)
Permalink

Re: nssa default route [In reply to]

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> 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-new-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
https://puck.nether.net/mailman/listinfo/juniper-nsp

ryan.landry at gmail

Aug 16, 2012, 11:23 AM

Post #5 of 11 (615 views)
Permalink

Re: nssa default route [In reply to]

i have tried the type-7 trick, to no avail.

On Thu, Aug 16, 2012 at 11:15 AM, Devin Kennedy
<devinkennedy415 [at] hotmail> wrote:
> Hi Ryan:
>
> Have you already tried adding the 'type-7' knob to the NSSA area?
>
> [edit]
> Devin [at] MX10-# set protocols ospf area 1 nssa default-lsa ?
> Possible completions:
> <[Enter]> Execute this command
> + apply-groups Groups from which to inherit configuration data
> + apply-groups-except Don't inherit configuration data from these groups
> default-metric Metric for the default route in this area
> (1..16777215)
> metric-type External metric type for the default type 7 LSA
> (1..2)
> type-7 Flood type 7 default LSA if no-summaries is
> configured <<<<<<<<<<<<<<<<<< This knob
> | Pipe through a command
>
> Since you are configuring 'no-summaries' and the default route comes through
> as such I believe you need to allow it as a type-7 instead.
>
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

harry at juniper

Aug 16, 2012, 11:28 AM

Post #6 of 11 (616 views)
Permalink

Re: nssa default route [In reply to]

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]
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 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> 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-new
> -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
https://puck.nether.net/mailman/listinfo/juniper-nsp

paul.zugnoni at jivesoftware

Aug 16, 2012, 11:39 AM

Post #7 of 11 (614 views)
Permalink

Re: nssa default route [In reply to]

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> 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]
> 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 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> 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-new
>> -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
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

ryan.landry at gmail

Aug 16, 2012, 11:42 AM

Post #8 of 11 (616 views)
Permalink

Re: nssa default route [In reply to]

i will give that a shot, harry. thank you. this triggers a question,
however. is it better to redist a static discard default route so it
shows up as NSSA on my area 1 routers, instead of as a summary? this
would negate the need for this mystery command, yes?

On Thu, Aug 16, 2012 at 11:28 AM, 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?
>
> Regards
>

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

harry at juniper

Aug 16, 2012, 11:46 AM

Post #9 of 11 (615 views)
Permalink

Re: nssa default route [In reply to]

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]
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)

Paul Z

(thumbs)

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?
>
> Regards
>
>
>
>
> -----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 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> 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
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

ryan.landry at gmail

Aug 16, 2012, 11:55 AM

Post #10 of 11 (614 views)
Permalink

Re: nssa default route [In reply to]

just wanted to point out that this hidden command solved my issue
entirely. still not sure what the better option is though, to redist
or to use the command.

harry, big thanks.

On Thu, Aug 16, 2012 at 11:46 AM, Harry Reynolds <harry [at] juniper> wrote:
> 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]
> 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)
>
> Paul Z
>
> (thumbs)

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

harry at juniper

Aug 16, 2012, 11:56 AM

Post #11 of 11 (619 views)
Permalink

Re: nssa default route [In reply to]

If the static redistribution works, and you insist on attracting traffic to a abr on a stick, so to speak, then I suppose using redistribution as opposed to the hidden command would be best. But seems that such an export would make the abr into an asbr, and also result in the injection the default into the backbone as a type 5, where it would flood into other non-stub areas. Would want to think that out.

But then again, we enter this discussion because there is no backbone adjacency (I believe), making above moot, but perhaps an issue down the road when the network grows and gains area 0 adjacencies.

Regards

-----Original Message-----
From: ryanL [mailto:ryan.landry [at] gmail]
Sent: Thursday, August 16, 2012 11:42 AM
To: Harry Reynolds
Cc: juniper-nsp [at] puck
Subject: Re: [j-nsp] nssa default route

i will give that a shot, harry. thank you. this triggers a question, however. is it better to redist a static discard default route so it shows up as NSSA on my area 1 routers, instead of as a summary? this would negate the need for this mystery command, yes?

On Thu, Aug 16, 2012 at 11:28 AM, 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?
>
> Regards
>

_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads