Solved: why is ospf forward address not 0.0.0.0 in this case?

jleszewski · ‎09-20-2013

Hi,

I have a two N7k switches configured as ASBRs.

Problem with one of them is that it sets forward address on default route it distributes into the nssa area to the ip address of it's connection in this area.

This causes the default gateway loop further in this nssa area, because this path is selected by second asbr connecting this area to the backbone.

Topology look more or less like this:

core-router

| \

| area 0 \

| \

asbr1------asbr2

| |

| nssa |

r1------------r2

Now asbr1 installs default route via r1, because it sees the forward address pointing to the connection r2-asbr2.

And of course r1 installs default route via asbr1, because asbr1 has 'default information originate" configured for this area.

ps

I have another pair of N7k configured the same way (at least it looks the same) in another site, and there is no such problem there.

Both asbrs redistribute default route with forward address set to 0.0.0.0

Can anyone point me to a solution of this problem?

regards

Kuba

Rolf Fischer · ‎09-26-2013

Perhaps we've focused to much on the non-zero FA, which is in fact strange but not the main problem I believe.

From RFC 3101 (The OSPF NSSA Option):

The Type-7 default LSA originated by an NSSA border router must have the P-bit clear. An NSSA ASBR that is not an NSSA border router may originate a Type-7 default LSA with the P-bit set. A Type-7 default LSA may be installed by NSSA border routers if and only if its P-bit is set.

ASBR2 is a NSSA BR
it seems to originate a Type-7 LSA for the default-route with the P-bit set (should be clear):

show ip ospf database nssa-external 0.0.0.0 adv-router 10.2.1.5 detail

Options: 0x8 (No TOS-capability, Type 7/5 translation, No DC)

that's the reason why ASBR1 installs this default route into the routing-table, it wouldn't if the P-bit was clear (as it should)

Do you think you could clear the OSPF process on ASBR2 (maybe at the weekend)?

View solution in original post

Rolf Fischer · ‎09-20-2013

Hi,

is the network of the default route's next-hop in the LSDB?

Link: The Effects of the Forwarding Address on Type 5 LSA Path Selection

Are all of the routers Nexus platforms? I'm asking because the default path selection is different in IOS and NX-OS and the recommendation is not to mix the modes in order to avoid loops.

https://supportforums.cisco.com/message/4040466#4040466

HTH

Rolf

Rolf Fischer · ‎09-20-2013

I have to apologize, the document I linked deals with Type-5 LSAs but the default-routes injected into the NSSA are of course Type-7.

Not sure if that helps, but the only way I could make a router generate Type-7 LSAs for the default-route with an non-zero forward address was to configure it as an ASBR but without beeing a (NSS)ABR at the same time.

jleszewski · ‎09-20-2013

I think I made a mistake in this diagram. Routers I called asbrs are not asbrs. Sorry for that.

These routers connect nssa area and backbone area, so are just abrs. So maybe your way to generate type-7 lsa for the default route with a non-zero forward address would help? This is exactly this case.

Rolf Fischer · ‎09-21-2013

I think it's correct to call them ASBRs, they inject external routing information (although unconditionally) and in show ip opsf border-routers they are stated as ASBRs as well.

Not sure if that helps, but the only way I could make a router generate Type-7 LSAs for the default-route with an non-zero forward address was to configure it as an ASBR but without beeing a (NSS)ABR at the same time.

Actually I could achieve it on a NSSA BR as well in the meantime, I had to use a multicaccess-interface (instead point-to-point) for the next-hop ip-address of a static default-route [*]. But this doesn't explain at all why asrb1 would prefer the Type-7 LSA originated by asbr2 over the one it originates itself (hope my understanding of your original post is correct).

Could you please post the output of

show ip ospf border-routers
show ip ospf database nssa-external 0.0.0.0

form asbr1 and

show ip route 0.0.0.0

from both asbr1 and arbr2? (I hope the commands are the same in NX-OS)

[*] : I configured a static default-route on asbr2 with a next-hop reachalbe over a FastEthernet interface and included the network of that Fa-interface in the NSSA. Generally, setting the FA to a non-zero next-hop in Type-7-LSAs serves the same purpose as in Type-5 LSAs: Advertising a "3rd party next-hop" in order to avoid a suboptimal extra-hop through the ASBR as descriped in the linked document for Type-5 LSAs.

jleszewski · ‎09-25-2013

fischer.rolf napisano:

I think it's correct to call them ASBRs, they inject external routing information (although unconditionally) and in show ip opsf border-routers they are stated as ASBRs as well.

Not sure if that helps, but the only way I could make a router generate Type-7 LSAs for the default-route with an non-zero forward address was to configure it as an ASBR but without beeing a (NSS)ABR at the same time.

Actually I could achieve it on a NSSA BR as well in the meantime, I had to use a multicaccess-interface (instead point-to-point) for the next-hop ip-address of a static default-route [*]. But this doesn't explain at all why asrb1 would prefer the Type-7 LSA originated by asbr2 over the one it originates itself (hope my understanding of your original post is correct).

Could you please post the output of

show ip ospf border-routers
show ip ospf database nssa-external 0.0.0.0

form asbr1 and

show ip route 0.0.0.0

from both asbr1 and arbr2? (I hope the commands are the same in NX-OS)

here it is:

--------------------------------------------------------------------------------------

show ip ospf border-routers from asbr1

OSPF Process ID 10 VRF default, Internal Routing Table

Codes: i - Intra-area route, I - Inter-area route

intra 10.2.1.5 [3], ASBR, ABR, Area 0.0.0.60, SPF 51191

via 10.20.2.154, Eth1/19

intra 10.20.1.34 [1], ASBR, Area 0.0.0.60, SPF 51191

via 10.20.2.154, Eth1/19

intra 10.20.1.35 [2], ASBR, Area 0.0.0.60, SPF 51191

via 10.20.2.154, Eth1/19

intra 10.0.251.11 [10], ASBR, Area 0.0.0.80, SPF 51191

via 10.20.2.186, Eth9/36

intra 10.2.1.5 [20], ASBR, ABR, Area 0.0.0.80, SPF 51191

via 10.20.2.186, Eth9/36

--------------------------------------------------------------------------------------

show ip ospf database nssa-external 0.0.0.0

OSPF Router with ID (10.2.1.1) (Process ID 10 VRF default)

Type-7 AS External Link States (Area 0.0.0.60)

Link ID ADV Router Age Seq# Checksum Tag

0.0.0.0 10.2.1.1 1468 0x800023d3 0x6865 0

0.0.0.0 10.2.1.5 17 0x800023d8 0xe519 0

--------------------------------------------------------------------------------------

what is more interesting is this:

show ip ospf database nssa-external 0.0.0.0 adv-router 10.2.1.5 detail

OSPF Router with ID (10.2.1.1) (Process ID 10 VRF default)

Type-7 AS External Link States (Area 0.0.0.60)

LS age: 108

Options: 0x8 (No TOS-capability, Type 7/5 translation, No DC)

LS Type: Type-7 AS-External

Link State ID: 0.0.0.0 (Network address)

Advertising Router: 10.2.1.5

LS Seq Number: 0x800023d8

Checksum: 0xe519

Length: 36

Network Mask: /0

Metric Type: 2 (Larger than any link state path)

TOS: 0

Metric: 1

Forward Address: 10.20.2.157

External Route Tag: 0

only this 0.0.0.0 lsa contains FA

--------------------------------------------------------------------------------------

show ip route 10.20.2.157

10.20.2.156/30, ubest/mbest: 1/0

*via 10.20.2.154, Eth1/19, [110/3], 18w4d, ospf-10, intra

show ip route 0.0.0.0/0

0.0.0.0/0, ubest/mbest: 1/0

*via 10.20.2.154, Eth1/19, [110/1], 2w2d, ospf-10, nssa type-2

Expected behavior is that asbr1 prefers default route via 10.20.2.186 and interface e9/36

--------------------------------------------------------------------------------------

and from asbr2

show ip route 0.0.0.0/0

0.0.0.0/0, ubest/mbest: 1/0

*via 10.20.2.190, Eth9/36, [110/1], 2w2d, ospf-10, type-2, tag 10

--------------------------------------------------------------------------------------

I guess asbr1 prefers type7 lsa, because it's the only one that contains FA. But I don't understand why asbr2 sets FA address (which is it's own addres) on this LSA. 10.20.2.157 is asbr2 address on it's connection to r2

Rolf Fischer · ‎09-25-2013

Thanks! I'll take a closer look at the output later on, the last question I can try to anwer quickly:

But I don't understand why asbr2 sets FA address (which is it's own addres) on this LSA.

Generally, a non-zero FA is set in external LSAs (Type-5 and Type-7 as well) in order to prevent a potential unnecessary extra-hop through the ASBR when a shorter path exist. Conditions: The network of the next-hop has to be in the LSDB and the local interface has to be multi-access. This is the announcing of a "3rd-party next-hop".

However, this should't have preference over the local injection of a default-route.

jleszewski · ‎09-26-2013

However, this should't have preference over the local injection of a default-route.

But in my case the cost to reach FA from asbr1 is lower then cost to reach other routers advertising default route. This is because connections in nssa area are 10-gig, while connections in backbone are 1-gig.

Rolf Fischer · ‎09-26-2013

This is interesting:

intra 10.2.1.5 [3], ASBR, ABR, Area 0.0.0.60, SPF 51191 via 10.20.2.154, Eth1/19

intra 10.20.1.34 [1], ASBR, Area 0.0.0.60, SPF 51191 via 10.20.2.154, Eth1/19

intra 10.20.1.35 [2], ASBR, Area 0.0.0.60, SPF 51191 via 10.20.2.154, Eth1/19

I assume 10.20.1.34 and .35 are R1 and R2? So ASBR1 (10.2.1.1) and ASBR2 (10.2.1.5) aren't OSPF neighbors in Area 60?

One more question:

and from asbr2

show ip route 0.0.0.0/0

0.0.0.0/0, ubest/mbest: 1/0

*via 10.20.2.190, Eth9/36, [110/1], 2w2d, ospf-10, type-2, tag 10

Where does the default-route's next-hop 10.20.2.190 belong to?

jleszewski · ‎09-26-2013

fischer.rolf napisano:
This is interesting:
intra 10.2.1.5 [3], ASBR, ABR, Area 0.0.0.60, SPF 51191 via 10.20.2.154, Eth1/19
intra 10.20.1.34 [1], ASBR, Area 0.0.0.60, SPF 51191 via 10.20.2.154, Eth1/19
intra 10.20.1.35 [2], ASBR, Area 0.0.0.60, SPF 51191 via 10.20.2.154, Eth1/19
I assume  10.20.1.34 and .35 are R1 and R2? So ASBR1 (10.2.1.1) and ASBR2 (10.2.1.5) aren't OSPF neighbors in Area 60?

Connection between asbr1 and asbr2 belongs to area0

But anyway, here is more output from show ip ospf border-routers on asbr1

show ip ospf border-routers | i 10.2.1.5

intra 10.2.1.5 [1], ASBR, ABR, Area 0.0.0.0, SPF 51245

intra 10.2.1.5 [20], ASBR, ABR, Area 0.0.0.40, SPF 51245

intra 10.2.1.5 [3], ASBR, ABR, Area 0.0.0.60, SPF 51245

intra 10.2.1.5 [20], ASBR, ABR, Area 0.0.0.80, SPF 51245

One more question:

and from asbr2

show ip route 0.0.0.0/0

0.0.0.0/0, ubest/mbest: 1/0

*via 10.20.2.190, Eth9/36, [110/1], 2w2d, ospf-10, type-2, tag 10

Where does the default-route's next-hop 10.20.2.190 belong to?

it is core-router's address on it's connection to asbr2

so this is correct. it is supposed to be this way

i want asbr1 to set it's default route to 10.20.2.186, which is core's address on it's connection to asbr1

Rolf Fischer · ‎09-26-2013

I'm starting to believe that the problem is caused by the OSPF path selection preference rule mentioned in my first posting.

So on ASBR1 you're learning a default-route in the Backbone-Area with 10.20.2.186 as the next-hop, is that correct?

jleszewski · ‎09-26-2013

fischer.rolf napisano:

I'm starting to believe that the problem is caused by the OSPF path selection preference rule mentioned in my first posting.

I'm not sure about it. If FA would not be set, then asbr1 would reach default gateway via 10.2.1.5 (as advertising router of this LSA in area 60), which is best reachable via direct connection asbr1-asbr2. R1 nad R2 do not originate LSA for 0.0.0.0.

Or am I wrong? Sorry if I write something not cleartly enough. English is not my native language.

So on ASBR1 you're learning a default-route in the Backbone-Area with 10.20.2.186 as the next-hop, is that correct?

Yes:

show ip ospf database 0.0.0.0

OSPF Router with ID (10.2.1.1) (Process ID 10 VRF default)

Type-7 AS External Link States (Area 0.0.0.60)

Link ID ADV Router Age Seq# Checksum Tag

0.0.0.0 10.2.1.1 249 0x800023ea 0x3a7c 0

0.0.0.0 10.2.1.5 619 0x800023ee 0xb92f 0

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag

0.0.0.0 10.0.251.11 37 0x8000103d 0xb497 10

0.0.0.0 10.4.251.11 359 0x80001e9a 0xaf2d 10

show ip route 10.0.251.11

10.0.251.0/25, ubest/mbest: 1/0

*via 10.20.2.186, Eth9/36, [110/20], 1w5d, ospf-10, type-2

Rolf Fischer · ‎09-26-2013

If FA would not be set, then asbr1 would reach default gateway via 10.2.1.5 (as advertising router of this LSA in area 60), which is best reachable via direct connection asbr1-asbr2. R1 nad R2 do not originate LSA for 0.0.0.0.

Or am I wrong?

I guess you're right.

What I don't understand at all is why ASBR2 sets the FA to a non-zero value when the next-hop link belongs to Area 0.

ASBR2 has the higher RID so it's responsible for the Type-7/Type-5 translation but I don't see a connection to the non-zero FA yet. I'll have to do some more reading I guess.

Rolf Fischer · ‎09-26-2013

Perhaps we've focused to much on the non-zero FA, which is in fact strange but not the main problem I believe.

From RFC 3101 (The OSPF NSSA Option):

The Type-7 default LSA originated by an NSSA border router must have the P-bit clear. An NSSA ASBR that is not an NSSA border router may originate a Type-7 default LSA with the P-bit set. A Type-7 default LSA may be installed by NSSA border routers if and only if its P-bit is set.

ASBR2 is a NSSA BR
it seems to originate a Type-7 LSA for the default-route with the P-bit set (should be clear):

show ip ospf database nssa-external 0.0.0.0 adv-router 10.2.1.5 detail

Options: 0x8 (No TOS-capability, Type 7/5 translation, No DC)

that's the reason why ASBR1 installs this default route into the routing-table, it wouldn't if the P-bit was clear (as it should)

Do you think you could clear the OSPF process on ASBR2 (maybe at the weekend)?

jleszewski · ‎09-26-2013

it seems to originate a Type-7 LSA for the default-route with the P-bit set (should be clear): 
show ip ospf database nssa-external 0.0.0.0 adv-router 10.2.1.5 detail
 Options: 0x8 (No TOS-capability, Type 7/5 translation, No DC)

Yes, I noticed this as well, but didn't quite understand it ...


Do you think you could clear the OSPF process on ASBR2 (maybe at the weekend)?

We are thinking about it. I'll let You know if it helps.

Seems like a bug... ?