Re: [j-nsp] Routing loop with OSPFv3 NSSA and external routes

2013-02-22 Thread Tore Anderson 
* Chuck Anderson

> What does the inet6.0 RIB look like for 2001:db8::1/128 ?

This is the output on R2:

inet6.0: 12118 destinations, 28874 routes (12117 active, 0 holddown, 1 hidden)
2001:db8::1/128 (1 entry, 1 announced)
TSI:
KRT in-kernel 2001:db8::1/128 -> {fe80::[R1 ae0.0]}
*OSPF3  Preference: 150
Next hop type: Router, Next hop index: 625
Address: 0xb97ee60
Next-hop reference count: 26
Next hop: fe80::[R1 ae0.0] via ae0.0, selected
Session Id: 0xf3
State: 
Local AS: 39029 
Age: 1:51   Metric: 3 
Validation State: unverified 
Tag: 0 
Task: OSPF3
Announcement bits (4): 0-KRT 3-RT 8-Resolve tree 1 9-Resolve 
tree 2 
AS path: I
AS path: Recorded

In any case I've opened a case on the issue now, hopefully
JTAC can understand what's going on here.

Best regards,
-- 
Tore Anderson
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Routing loop with OSPFv3 NSSA and external routes

2013-02-22 Thread Chuck Anderson 
What does the inet6.0 RIB look like for 2001:db8::1/128 ?

On Fri, Feb 22, 2013 at 10:41:47AM +0100, Tore Anderson wrote:
> At this point, both R1 and R2 see SW1's NSSA LSA:
> 
> R1> show ospf3 database advertising-router 192.0.2.40 lsa-id 0.0.0.2 extensive
> 
> Area 10.0.0.0
>  Type   ID   Adv Rtr   Seq Age  Cksum  Len
> NSSA0.0.0.2  192.0.2.40   0x8060  1237  0x7dfa  44
>   Prefix 2001:db8::1/128
>   Prefix-options 0x8, Metric 2, Type 1,
>   Aging timer 00:39:22
>   Installed 00:00:09 ago, expires in 00:39:23
>   Last changed 00:00:09 ago, Change count: 1
> 
> R2> show ospf3 database advertising-router 192.0.2.40 lsa-id 0.0.0.2 extensive
> 
> Area 10.0.0.0
>  Type   ID   Adv Rtr   Seq Age  Cksum  Len
> NSSA0.0.0.2  192.0.2.40   0x8060  1241  0x7dfa  44
>   Prefix 2001:db8::1/128
>   Prefix-options 0x8, Metric 2, Type 1,
>   Aging timer 00:39:19
>   Installed 00:20:38 ago, expires in 00:39:19, sent 00:00:14 ago
>   Last changed 00:57:45 ago, Change count: 2
> 
> R1 has now become an ABR, so it translats the type-7 into type-5:
> 
> R1> show ospf3 database advertising-router self lsa-id 0.0.0.7 external 
> extensive
> OSPF3 AS SCOPE link state database
>  Type   ID   Adv Rtr   Seq Age  Cksum  Len
> Extern *0.0.0.7  192.0.2.50x8001   108  0x6314  44
>   Prefix 2001:db8::1/128
>   Prefix-options 0x0, Metric 2, Type 1,
>   Gen timer 00:44:46
>   Aging timer 00:58:11
>   Installed 00:01:48 ago, expires in 00:58:12, sent 00:01:48 ago
>   Last changed 00:01:48 ago, Change count: 1, Ours
> 
> Note that R2 does *not* translate the type-7 into type-5 anymore even
> though it is still an ABR, only R1 does. This is expected as R1 has a
> higher router ID.
> 
> R2 also sees R1's translated type-5 LSA:
> 
> R2> show ospf3 database advertising-router 192.0.2.5 lsa-id 0.0.0.7 external 
> extensive
> OSPF3 AS SCOPE link state database
>  Type   ID   Adv Rtr   Seq Age  Cksum  Len
> Extern  0.0.0.7  192.0.2.50x8001   188  0x6314  44
>   Prefix 2001:db8::1/128
>   Prefix-options 0x0, Metric 2, Type 1,
>   Aging timer 00:56:52
>   Installed 00:03:07 ago, expires in 00:56:52, sent 00:03:07 ago
>   Last changed 00:03:07 ago, Change count: 1
> 
> R1 uses the type-7 intra-area LSA when selecting the best route, which I
> think is fine:
> 
> R1> show ospf3 route 2001:db8::1/128 extensive
> Prefix   Path  Route  NH   Metric
>  Type  Type   Type
> 2001:db8::1/128  Ext1  NetworkIP   4
>   NH-interface ae0.0, NH-addr fe80::[R2 ae0.0]
>   Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium
> 
> ...while R2 uses the translated type-5 LSA originated by R1 as the best
> route:
> 
> R2> show ospf3 route 2001:db8::1/128 extensive
> Prefix   Path  Route  NH   Metric
>  Type  Type   Type
> 2001:db8::1/128  Ext1  NetworkIP   3
>   NH-interface ae0.0, NH-addr fe80::[R1 ae0.0]
>   Area 0.0.0.0, Origin 192.0.2.5, Fwd NZ, Priority medium
> 
> I think that the fault lies with R2 here. If R2 had ignored the
> translated type-5 LSA originated by R1, and instead preferred the
> intra-area type-7 LSA originated by SW1 when selecting the best path,
> I think everything would have worked just fine. Agreed?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Routing loop with OSPFv3 NSSA and external routes

2013-02-22 Thread Tore Anderson 
* Alex Arseniev

> Looks like R2 has 2 equal-cost Ext routes, both with metric-type 2.

If you're referring to the routes via xe-1/2/0.6 and ae0.0, then perhaps
so but they both go to R1 which is wrong. In any case, the xe-1/2/0.6
link is some old legacy crap that was due for removal anyway, so now I
got rid of it. That simplifies things, but it didn't help. So now the
topology is as follows:

  2001:db8::1/128
| (RIPng-advertised)
~
|
  [SW1 - ID 192.0.2.40]
| vlan.5
|
| (NSSA area 10.0.0.0)
|
| xe-1/2/0.5
  [R2 - ID 192.0.2.4]
| ae0.0
|
| (area 0)
|
| ae0.0
  [R1 - ID 192.0.2.5]

> What happens if you redistribute on SW1 with metric-type 1?

No change in behaviour, traffic still starts looping between R1 and R2,
as soon as I include R1 in area 10.0.0.0 by adding ae0.0 as a secondary
interface.

> Also, what do your link metrics look like? Are they BW-related or just 1
> for any link (LAG or single 1/10GE)?

R1/R2 ae0.0 is 20G and R2 xe-1/2/0.5 is 10G. I use reference-bandwidth
10g so all three have a cost of 1.

> Lastly, what happens if R1 has "no-nssa-abr" configured?

I already had that knob set, tried to remove it, no change.

So anyway. The relevant config on SW1 now is as follows:

SW1# show policy-options policy-statement ripng-routes  
term 1 {
from protocol ripng;
then {
external {
type 1;
}
accept;
}
}
SW1# show protocols ospf3  
export ripng-routes;
reference-bandwidth 10g;
no-rfc-1583;
area 10.0.0.0 {
nssa;
interface lo0.0 {
passive;
}
interface vlan.5;
}

The LS1 originated by SW1 looks as follows:

SW1> show ospf3 database lsa-id 0.0.0.2 advertising-router self extensive 

OSPF3 database, Area 10.0.0.0
 Type   ID   Adv Rtr   Seq Age  Cksum  Len 
NSSA   *0.0.0.2  192.0.2.40   0x805f  1202  0x7ff9  44 
  Prefix 2001:db8::1/128
  Prefix-options 0x8, Metric 2, Type 1,
  Gen timer 00:17:03
  Aging timer 00:39:58
  Installed 00:20:02 ago, expires in 00:39:58, sent 00:20:02 ago
  Last changed 00:20:02 ago, Change count: 2, Ours

SW1 behaves nice and dandy even when R1 and R2 are looping traffic, no
change in the output above.

Config on R1 when everything works:

R2# show protocols ospf3
reference-bandwidth 10g;
no-rfc-1583;
no-nssa-abr;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface ae0.0;
}
area 10.0.0.0 {
nssa {
default-lsa default-metric 10;
no-summaries;
}
interface xe-1/2/0.5;
}

R2 receives SW1's LSA just fine:

R2> show ospf3 database advertising-router 192.0.2.40 lsa-id 0.0.0.2 extensive

Area 10.0.0.0
 Type   ID   Adv Rtr   Seq Age  Cksum  Len
NSSA0.0.0.2  192.0.2.40   0x805f  2147  0x7ff9  44
  Prefix 2001:db8::1/128
  Prefix-options 0x8, Metric 2, Type 1,
  Aging timer 00:24:13
  Installed 00:35:46 ago, expires in 00:24:13, sent 00:13:06 ago
  Last changed 00:35:46 ago, Change count: 2

It's being selected as the active route:

R2> show ospf3 route 2001:db8::1 extensive
Prefix   Path  Route  NH   Metric
 Type  Type   Type
2001:db8::1/128  Ext1  NetworkIP   3
  NH-interface xe-1/2/0.5, NH-addr fe80::[SW1 vlan.5]
  Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium

Being the only ABR, R2 also translates the NSSA (type-7) to an external
(type-5) LSA:

R2> show ospf3 database advertising-router self lsa-id 0.0.0.8 external 
extensive
OSPF3 AS SCOPE link state database
 Type   ID   Adv Rtr   Seq Age  Cksum  Len
Extern *0.0.0.8  192.0.2.40x8001   764  0x5f18  44
  Prefix 2001:db8::1/128
  Prefix-options 0x0, Metric 2, Type 1,
  Gen timer 00:25:09
  Aging timer 00:47:16
  Installed 00:12:44 ago, expires in 00:47:16, sent 00:12:44 ago
  Last changed 00:12:44 ago, Change count: 1, Ours

On R1, relevant config is as follows:

R1> show configuration protocols ospf3
reference-bandwidth 10g;
no-rfc-1583;
no-nssa-abr;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface ae0.0;
}

R1 receives R2's translated type-5 LSA and uses it:

R1> show ospf3 database advertising-router 192.0.2.4 lsa-id 0.0.0.8 external 
extensive
OSPF3 AS SCOPE link state database
 Type   ID   Adv Rtr   Seq Age  Cksum  Len
Extern  0.0.0.8  192.0.2.40x8001   992  0x5f18  44
  Prefix 2001:db8::1/128
  Prefix-options 0x0, Metric 2, Type 1,
  Aging timer 00:43:27
  Installed 00:16:31 ago, expires in 00:43:28, sent 00:16:31 ago
  Last changed 00:16:31 ago, Change count: 1

R1> show ospf3 route 2001:db8::1 extensive
Prefix   Path  Route  NH   Metric
 Type  Type   Type
200

Re: [j-nsp] Routing loop with OSPFv3 NSSA and external routes

2013-02-21 Thread Alex Arseniev 

Looks like R2 has 2 equal-cost Ext routes, both with metric-type 2.
What happens if you redistribute on SW1 with metric-type 1?
Also, what do your link metrics look like? Are they BW-related or just 1 for 
any link (LAG or single 1/10GE)?

Lastly, what happens if R1 has "no-nssa-abr" configured?
Thanks
Alex

- Original Message - 
From: "Tore Anderson" 

To: "Juniper List" 
Sent: Thursday, February 21, 2013 11:55 AM
Subject: [j-nsp] Routing loop with OSPFv3 NSSA and external routes



Hi list,

I'm scratching my head over an OSPFv3 routing loop to an external NSSA
destination that happens when extending the area to another router in
the backbone.

This is (hopefully) all the relevant parts of the currently (working)
setup. The two routers R1 and R2 are MX-es running JUNOS 12.2R3,
SW1 is an EX4200 VC running 10.4R6.

2001:db8::1/128 gets advertised to SW1 by a host using RIPng, and SW1
exports this route into OSPFv3.

 2001:db8::1/128
   | (RIPng-advertised)
   ~
   |
 [SW1 - ID 192.0.2.40]
   |
   | (NSSA area 10.0.0.0)
   |
   | xe-1/2/0.5
 [R2 - ID 192.0.2.4]
   | ae0.0 | xe-1/2/0.6
   |   |
   | (area 0)  | (area 0)
   |   |
   | ae0.0 | xe-1/2/0.6
 [R1 - ID 192.0.2.5]


On R2 I can see the external NSSA route appear fine:

R2> show ospf3 route 2001:db8::1 extensive
Prefix   Path  Route  NH   Metric
Type  Type   Type
2001:db8::1/128  Ext2  NetworkIP   2
 NH-interface xe-1/2/0.5, NH-addr fe80::3
 Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium

...and on R1 I can see that the ABR R2 translated it into a normal
external route and advertised it into area 0:

R1> show ospf3 route 2001:db8::1 extensive
Prefix   Path  Route  NH   Metric
Type  Type   Type
2001:db8::1/128  Ext2  NetworkIP   2
 NH-interface ae0.0, NH-addr fe80::2
 NH-interface xe-1/2/0.6, NH-addr fe80::62:2
 Area 0.0.0.0, Origin 192.0.2.4, Fwd NZ, Priority medium

The problem occurs when I attempt to include R1 into area 10.0.0.0.
This I do by adding ae0.0 on R1 and R2 into the area in secondary
mode. My problem is that as soon as I do so, traffic to
2001:db8::1/128 starts to loop between R1 and R2.

As expected, R1 now sees the type-7 LSA generated by SW1 (and
readvertises it into area 0 since it's now an ABR):

R1> run show ospf3 route 2001:db8::1 extensive
Prefix   Path  Route  NH   Metric
Type  Type   Type
2001:db8::1/128  Ext2  NetworkIP   2
 NH-interface ae0.0, NH-addr fe80::2
 Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium

R2, on the other hand, for seam prefers the area 0 external route that
was generated by R1 over the NSSA route generated by SW1:

R2> run show ospf3 route 2001:db8::1 extensive
Prefix   Path  Route  NH   Metric
Type  Type   Type
2001:db8::1/128  Ext2  NetworkIP   2
 NH-interface ae0.0, NH-addr fe80::1
 NH-interface xe-1/2/0.6, NH-addr fe80::62:1
 Area 0.0.0.0, Origin 192.0.2.5, Fwd NZ, Priority medium

I have the exact same topology set up for IPv4/OSPFv3/RIPv2, and then
R2 prefers the route it learned from SW1's Type-7 LSA within area
10.0.0.0, instead of the normal external route received from R1. I would
have expected the same to happen with OSPFv3, but for some reason the
priorities are the other way around.

Anyone have an idea as to whether this is a bug or if I'm doing
something wrong here?

BR,
--
Tore Anderson
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Routing loop with OSPFv3 NSSA and external routes

2013-02-21 Thread Krasimir Avramski 
Hi,

Section 4.8.5 .
 (Calculating AS External and NSSA Routes from OSPFv3) reference section
2.5 from NSSA  with the
assumption RFC1583Compatibility is disabled.
Seems like bug for me.

Best Regards,
Krasi


On Thu, Feb 21, 2013 at 1:55 PM, Tore Anderson  wrote:

> Hi list,
>
> I'm scratching my head over an OSPFv3 routing loop to an external NSSA
> destination that happens when extending the area to another router in
> the backbone.
>
> This is (hopefully) all the relevant parts of the currently (working)
> setup. The two routers R1 and R2 are MX-es running JUNOS 12.2R3,
> SW1 is an EX4200 VC running 10.4R6.
>
> 2001:db8::1/128 gets advertised to SW1 by a host using RIPng, and SW1
> exports this route into OSPFv3.
>
>   2001:db8::1/128
> | (RIPng-advertised)
> ~
> |
>   [SW1 - ID 192.0.2.40]
> |
> | (NSSA area 10.0.0.0)
> |
> | xe-1/2/0.5
>   [R2 - ID 192.0.2.4]
> | ae0.0 | xe-1/2/0.6
> |   |
> | (area 0)  | (area 0)
> |   |
> | ae0.0 | xe-1/2/0.6
>   [R1 - ID 192.0.2.5]
>
>
> On R2 I can see the external NSSA route appear fine:
>
> R2> show ospf3 route 2001:db8::1 extensive
> Prefix   Path  Route  NH   Metric
>  Type  Type   Type
> 2001:db8::1/128  Ext2  NetworkIP   2
>   NH-interface xe-1/2/0.5, NH-addr fe80::3
>   Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium
>
> ...and on R1 I can see that the ABR R2 translated it into a normal
> external route and advertised it into area 0:
>
> R1> show ospf3 route 2001:db8::1 extensive
> Prefix   Path  Route  NH   Metric
>  Type  Type   Type
> 2001:db8::1/128  Ext2  NetworkIP   2
>   NH-interface ae0.0, NH-addr fe80::2
>   NH-interface xe-1/2/0.6, NH-addr fe80::62:2
>   Area 0.0.0.0, Origin 192.0.2.4, Fwd NZ, Priority medium
>
> The problem occurs when I attempt to include R1 into area 10.0.0.0.
> This I do by adding ae0.0 on R1 and R2 into the area in secondary
> mode. My problem is that as soon as I do so, traffic to
> 2001:db8::1/128 starts to loop between R1 and R2.
>
> As expected, R1 now sees the type-7 LSA generated by SW1 (and
> readvertises it into area 0 since it's now an ABR):
>
> R1> run show ospf3 route 2001:db8::1 extensive
> Prefix   Path  Route  NH   Metric
>  Type  Type   Type
> 2001:db8::1/128  Ext2  NetworkIP   2
>   NH-interface ae0.0, NH-addr fe80::2
>   Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium
>
> R2, on the other hand, for seam prefers the area 0 external route that
> was generated by R1 over the NSSA route generated by SW1:
>
> R2> run show ospf3 route 2001:db8::1 extensive
> Prefix   Path  Route  NH   Metric
>  Type  Type   Type
> 2001:db8::1/128  Ext2  NetworkIP   2
>   NH-interface ae0.0, NH-addr fe80::1
>   NH-interface xe-1/2/0.6, NH-addr fe80::62:1
>   Area 0.0.0.0, Origin 192.0.2.5, Fwd NZ, Priority medium
>
> I have the exact same topology set up for IPv4/OSPFv3/RIPv2, and then
> R2 prefers the route it learned from SW1's Type-7 LSA within area
> 10.0.0.0, instead of the normal external route received from R1. I would
> have expected the same to happen with OSPFv3, but for some reason the
> priorities are the other way around.
>
> Anyone have an idea as to whether this is a bug or if I'm doing
> something wrong here?
>
> BR,
> --
> Tore Anderson
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Routing loop with OSPFv3 NSSA and external routes

2013-02-21 Thread Tore Anderson 
Hi list,

I'm scratching my head over an OSPFv3 routing loop to an external NSSA
destination that happens when extending the area to another router in
the backbone.

This is (hopefully) all the relevant parts of the currently (working)
setup. The two routers R1 and R2 are MX-es running JUNOS 12.2R3,
SW1 is an EX4200 VC running 10.4R6.

2001:db8::1/128 gets advertised to SW1 by a host using RIPng, and SW1
exports this route into OSPFv3.

  2001:db8::1/128
| (RIPng-advertised)
~
|
  [SW1 - ID 192.0.2.40]
|
| (NSSA area 10.0.0.0)
|
| xe-1/2/0.5
  [R2 - ID 192.0.2.4]
| ae0.0 | xe-1/2/0.6
|   |
| (area 0)  | (area 0)
|   |
| ae0.0 | xe-1/2/0.6
  [R1 - ID 192.0.2.5]


On R2 I can see the external NSSA route appear fine:

R2> show ospf3 route 2001:db8::1 extensive
Prefix   Path  Route  NH   Metric
 Type  Type   Type
2001:db8::1/128  Ext2  NetworkIP   2
  NH-interface xe-1/2/0.5, NH-addr fe80::3
  Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium

...and on R1 I can see that the ABR R2 translated it into a normal
external route and advertised it into area 0:

R1> show ospf3 route 2001:db8::1 extensive
Prefix   Path  Route  NH   Metric
 Type  Type   Type
2001:db8::1/128  Ext2  NetworkIP   2
  NH-interface ae0.0, NH-addr fe80::2
  NH-interface xe-1/2/0.6, NH-addr fe80::62:2
  Area 0.0.0.0, Origin 192.0.2.4, Fwd NZ, Priority medium
 
The problem occurs when I attempt to include R1 into area 10.0.0.0.
This I do by adding ae0.0 on R1 and R2 into the area in secondary
mode. My problem is that as soon as I do so, traffic to
2001:db8::1/128 starts to loop between R1 and R2. 

As expected, R1 now sees the type-7 LSA generated by SW1 (and
readvertises it into area 0 since it's now an ABR):

R1> run show ospf3 route 2001:db8::1 extensive
Prefix   Path  Route  NH   Metric
 Type  Type   Type
2001:db8::1/128  Ext2  NetworkIP   2
  NH-interface ae0.0, NH-addr fe80::2
  Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium

R2, on the other hand, for seam prefers the area 0 external route that
was generated by R1 over the NSSA route generated by SW1:

R2> run show ospf3 route 2001:db8::1 extensive
Prefix   Path  Route  NH   Metric
 Type  Type   Type
2001:db8::1/128  Ext2  NetworkIP   2
  NH-interface ae0.0, NH-addr fe80::1
  NH-interface xe-1/2/0.6, NH-addr fe80::62:1
  Area 0.0.0.0, Origin 192.0.2.5, Fwd NZ, Priority medium

I have the exact same topology set up for IPv4/OSPFv3/RIPv2, and then
R2 prefers the route it learned from SW1's Type-7 LSA within area
10.0.0.0, instead of the normal external route received from R1. I would
have expected the same to happen with OSPFv3, but for some reason the
priorities are the other way around.

Anyone have an idea as to whether this is a bug or if I'm doing
something wrong here?

BR,
-- 
Tore Anderson
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp