Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

why is ospf forward address not 0.0.0.0 in this case?

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

Everyone's tags (1)
1 ACCEPTED SOLUTION

Accepted Solutions

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

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

17 REPLIES

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

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

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

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.

New Member

why is ospf forward address not 0.0.0.0 in this case?

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.

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

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.

New Member

why is ospf forward address not 0.0.0.0 in this case?

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

why is ospf forward address not 0.0.0.0 in this case?

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.

New Member

why is ospf forward address not 0.0.0.0 in this case?

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.



why is ospf forward address not 0.0.0.0 in this case?

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?

New Member

why is ospf forward address not 0.0.0.0 in this case?

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

why is ospf forward address not 0.0.0.0 in this case?

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?

New Member

why is ospf forward address not 0.0.0.0 in this case?

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

why is ospf forward address not 0.0.0.0 in this case?

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.

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

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

New Member

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

  • 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... ?

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

Seems like a bug... ?

I suppose so too. In any case a very strange malfunction which to my best knowledge cannot be caused by misconfiguration.

If the problem remains after a clearing (or reboot), I'd recommend to contact TAC.

Please keep us up-to-date!

New Member

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

Clearing ip ospf neighbour didn't help

But it helped when i removed interface to r2 on asbr2 from ospf, and put it again into ospf.

Everything looks good now.

show ip ospf database nssa-external 0.0.0.0  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: 914

   Options: 0 (No TOS-capability, No 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.1

   LS Seq Number: 0x8000242f

   Checksum: 0xaec2

   Length: 36

   Network Mask: /0

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

         TOS: 0

         Metric: 1

         Forward Address: 0.0.0.0

         External Route Tag: 0

   LS age: 653

   Options: 0 (No TOS-capability, No 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: 0x80002434

   Checksum: 0x8cdb

   Length: 36

   Network Mask: /0

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

         TOS: 0

         Metric: 1

         Forward Address: 0.0.0.0

         External Route Tag: 0

Thanks for Your help :-)

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

A very good approach since this was the link advertised as the FA.

Thanks for the feedback!

1348
Views
5
Helpful
17
Replies