ā09-20-2013 07:15 AM - edited ā03-05-2019 06:51 AM
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
Solved! Go to Solution.
ā09-26-2013 01:16 PM
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.
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)
Do you think you could clear the OSPF process on ASBR2 (maybe at the weekend)?
ā09-20-2013 07:50 AM
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
ā09-20-2013 11:27 AM
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.
ā09-20-2013 02:04 PM
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.
ā09-21-2013 12:28 AM
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
form asbr1 and
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.
ā09-25-2013 03:45 PM
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
form asbr1 and
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
ā09-25-2013 10:16 PM
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.
ā09-26-2013 01:01 AM
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.
ā09-26-2013 02:03 AM
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?
ā09-26-2013 02:16 AM
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
ā09-26-2013 02:26 AM
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?
ā09-26-2013 02:51 AM
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
ā09-26-2013 04:31 AM
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.
ā09-26-2013 01:16 PM
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.
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)
Do you think you could clear the OSPF process on ASBR2 (maybe at the weekend)?
ā09-26-2013 01:44 PM
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... ?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide