cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7767
Views
10
Helpful
30
Replies

OSPF E2 vs N2

Kelvin Willacey
Level 4
Level 4

I have a problem or I'm just missing something which is the most likely scenario. I know that E2 routes should be preferred over N2 routes, unless the forward metric is lower for the N2 route. Is this correct?

I have two routers R1 and R2 that have a connection to each other via area 0 and area 10, area 10 is a totally NSSA. On R2 I redistribute a static route and expected that R1 would learn this route via area 0 as an E2 route instead it learns it as a N2 route via area 10. I need this traffic to flow over the area 0 link.

The area 0 link on both routers is 100 Mbps, the area 10 link is 1 Gbps, the link through which the static route points is also 100 Mbps and the reference bandwidth is 10 Gbps.

The N2 route has a metric of 20 in the routing table and when I look at the forward metric for this redistributed route it has a metric of 10 (1 gig link cost). When I fail the area 10 link, the E2 route appears in the routing table with a metric of 20 and when I look at the forward metric via area 0 it has a metric of 200 (100 meg area 0 link cost plus cost of exit interface for static route).

I understand the forward metric for the E2 route but why does the N2 route only consider the cost for the exit interace of the 1 Gbps link? Can anyone explain this? Is my only option to modify the cost to force it to use the area 0 link?

30 Replies 30

Could auto-cost reference bandwidth cause an issue with costs?  Are you absolutely sure it should be 100?  Also, is the forwarding address the same for both routes?

Nick Bonifacio CCIE #38473

I don't think so however I did not configure the bandwidth on the area 90 interface to be 1 Gbps, so the cost to get to the ASBR should be 10 and not 100. I fixed that and now the cost for the N2 route is 10. The bandwidth for the area 0 link is 100 Mbps so the cost to get to the ASBR should be 100 for the E2 route, but instead it is 200.

I still think this is wrong somehow or I have a misconfiguration somewhere I am not seeing. The E2 route just like the N2 route should have the cost to the ASBR as its forward metric, that is 10 for the N2 and 100 for the E2.

So I tested two things 1.) I shutdown the area 90 interface and I changed the cost on the area 0 link to 1 (the green line) on DC1-WAN and the forward metric for the redistributed route that DC1-WAN learns from DC2-WAN changed to 101. Which to me means that it is also factoring in the exit interface for the static route when calculating the cost. 2.) I then changed the cost on the exit interface for the static route on DC2-WAN (the dark blue line) and the forward metric was changed to 2.

I assume I will have to manipulate the cost to have the E2 route win over the N2 route, as I did above. Unless there is a better way to do this? Why is the E2 route adding an additional cost when all it should consider is the cost to the ASBR?

Let me ask about the static routes again, just to make sure I am clear.  On the outgoing interface for the static routes, what is the bandwidth/ospf cost?

For example,

ip route 10.0.80.0 255.255.255.0 192.168.4.1

or

ip route 10.0.80.0 255.255.255.0 fa0/0

fa0/0

ip ospf cost 300

//or

bandwidth 1000

Nick Bonifacio CCIE #38473

Hello KWillacey,

>> Why is the E2 route adding an additional cost when all it should consider is the cost to the ASBR?

The reason is visible in the link state database: the LSA type 5 has a forwarding address set.

The LSA type 7 has forwarding address not set (set to 0.0.0.0) meaning the ASBR itself.

LSA type 7:

>>Forward Address: 0.0.0.0

LSA Type 5:

>>Forward Address: 10.130.99.3

From previous show ospf database output in post #5.

Regarding what route should be preferred RFC 3101 section 2.5 describes how the best route is chosen.

The destination address of LSAs is named N.

The seed metric of the LSA is named Y  ( metric value within the LSA data structure)

The forwarding metric to ASBR/forwarding address is named X.

When choicing the best route all external LSAs either O E1, O E2, O N1, O N2 are considered.

If present type 1 external routes are preferred ( O E1 or O N1) with the LSA with the lowest X+Y metric preferred.

If all LSAs are of type 2, the lowest seed metric Y is preferred.

If the seed metric is the same, the lowest forwarding metric X is preferred ( this is your case as you noted)

Last at the end if multiple LSAs have same destination N, same seed metric, same forwarding metric ( for type2) the LSA type plays a role

RFC 3101 section 2.5

http://tools.ietf.org/html/rfc3101#section-2.5

>>> (d) If the new AS external path is still indistinguishable

              from the current paths in N's routing table entry, select

              the preferred path based on a least cost comparison.  Type

              1 external paths are compared by looking at the sum of the

              distance to the ASBR/forwarding addresses and the

              advertised type 1 metric (X+Y).  Type 2 external paths

              advertising equal type 2 metrics are compared by looking

              at the distance to the ASBR/forwarding addresses.

              ~[OSPF]

(e) If the current LSA is functionally the same as an

              installed LSA (i.e., same destination, cost and non-zero

              forwarding address) then apply the following priorities in

              deciding which LSA is preferred:

                 1. A Type-7 LSA with the P-bit set.

                 2. A Type-5 LSA.

                 3. The LSA with the higher router ID.

                [NSSA]

So the exact type O E2 or O N2 is looked at only at the last point to break a tie.

If my understanding is correct, you can play with the link metrics including the link to the forwarding address to achieve the desired behaviour.

You need to implement the following

Area 0 link to ABR/ASBR + area 90 link to FA  < area 90 link to ASBR

However, because you are going to reduce the link cost of a backbone link the effect/impact may be greater then what you would like to achieve

for example using

98 in area 0  and 1 as IP OSPF cost in area 90 for the FA

This choice should provide the lowest changes in the backbone area as the cost of the link changed from 100 to 98 and should not attract other traffic.

Being a leaf in area 90 the link to the FA can use a metric as low as 1 as it is not going to be used for other traffic then that destinated to the IP subnet or to external destinations with a FA in that IP subnet.

Or even better you could make the cost in area 90 link to ASBR 102, cost to FA in area 90 1 and you could leave the OSPF area 0 link to 100.

Hope to help

Giuseppe

Hi Nick the link is 100 Mbps so it has a cost of 100 and the route points to the next hop address and not the interface.

Thanks for the response Giuseppe, it gave me a much better understanding. I will make the changes and let you know which one worked out best. Thanks again.

Hello KWillacey,

I'm interested in your test results, because some time after having written my post I have a doubt:

if the competition between different LSA is solved looking at the metric of the forwarding path to ASBR/forwarding address also the type of OSPF route to reach the ASBR/forwarding address might play a role ( in a sort of recursion) and in your case the comparison is between an intra-area route in area 90 to reach the NSSA ASBR (LSA type 7) and an inter-area route via area 0 and then in area 90 to reach the forwarding address of the LSA type 5.

If the type of route to the ASBR/forwarding address counts there will not be any way with metric changes to make the LSA 5 with forwarding address set (to an area 90 route) preferred over the LSA type 7 with a , by definition, intra area route to NSSA ASBR.

Hope to help

Giuseppe

Hello Kwillacey,

I have made some tests in a similar setup with GNS3:

in my case the forwarding address is set on both the LSA type 5 and the LSA type 7.

The LSA type 5 is preferred over the LSA type 7, but full recursion is used for resolving the forwarding address so traffic takes the intra-area  ( in NSSA ) path even if the O E2 route is selected.

I tried to play with metric but the intra area path is preferred over the inter area path using the link in area 0, this as said before means that recursion of forwarding address is complete and O route to forwarding address wins over O IA route.

Hope to help

Giuseppe

Thanks for your effort and help Giueseppe. I have quite a hard time to get this to work, no matter what I did my N2 routes forwarding address always has 0.0.0.0 and my E2 has the forwarding address that will send it across the area 0 link.

I am not sure if the issue was having my ABR also act as an ASBR so I tried moving the ASBR functionality to another device which is the core switch. They only aggregate traffic while the firewall has all the gateways so I created a separate link between the core and router and put that in area 0. I then point the static routes to the firewall but this time I did this on the core switch and redistributed that.

The core switches have the routes as E2 and so do the routers and this was what I was hoping to achieve, to ensure that traffic between the data centers traverse this backbone link. I understand why this woks but I am still confused as to why redistributing on the routers was an issue.

If the ABR is also the ASBR doing the redistribution then type7>type5 conversion will not happen, basically the P bit will not be set. This is a loop prevention mechanism to make sure that the route you redistribute into the NSSA does not get translated by an ABR to type 5 and then gets back to the ASBR who is doing the redistribution. The ASBR who is doing the redistribution will generate a type 5 LSA for the redistributed route into the non-stub areas and will generate a type 7 LSA into the NSSA. So the ASBR should always route using the type 5 LSA, the type 7 LSA should be used only by the routers internal to NSSA.

The forwarding address is chosen as R2's gig interface in the NSSA area. Think of it like this, since R2 is ASBR doing the redistribution into the nssa and it is the one generating the type 7 Lsa, the forwarding address will always be selected as R2's gig interface in the nssa. Be aware that the forwarding address is not a node identifier, it is the actual interface address of the asbr doing the redistribution into the nssa and hence the forwarding metric is only taking into account the cost of the gig link in the nssa and not of the static route. Hope this helps you. 

asofrani
Cisco Employee
Cisco Employee

The following document might shed some light on external path preference in OSPF

 

OSPF External path selection: External Type-2 (E2) VS NSSA Type-2 (N2):

Link: https://supportforums.cisco.com/t5/network-infrastructure-documents/ospf-external-path-selection-external-type-2-e2-vs-nssa-type-2/ta-p/3199001

 

Hope it helps

Thank you so much asofrani, the tie breaker makes perfect sense now. I notice one thing different in the LSA outputs though. The "routing bit set" field is not mentioned in the LSA output anymore but the route is still being installed in the RIB. Could you please clarify why this is the case? Also how would one know if the neighbor router is having some problems because earlier you could tell by looking at the routing bit set, if not set then route will not be in the RIB and hence there is some big issue. I have asked this question on the learning network and here is the link:

https://learningnetwork.cisco.com/message/651661#651661

I would be real grateful to you sir if you could help me understand this. Thank you.

Dear prashant1990,

 

Thanks for the feedback on the article. Regarding your concern towards seeing the routing bit set. This bit is not specified in RFC hence it is not mandatory to implement. I am not sure if it has been deprecated in newer version of IOS, although i can say that if this is in-fact the case it should not impact pushing routes down towards RIB if the route is indeed valid.

 

The routing bit was confirmation that we could indeed build the shortest path tree using SPF algorithm towards that specific node in the graph or as we call it the network. Now what i have observed is that when we do have issues calculating a path towards a node via SPF we have the following

 

R1#show ip ospf da router 4.4.4.4

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Router Link States (Area 0)

  Adv Router is not-reachable in topology Base with MTID 0  
  LS age: 91
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 4.4.4.4
  Advertising Router: 4.4.4.4
  LS Seq Number: 80000002
  Checksum: 0x1BEF
  Length: 48
  Number of Links: 2

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 1.1.1.1
     (Link Data) Router Interface address: 192.168.14.4
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

 

In the above output you can clearly see it is stated that Adv Router is not-reachable in topology, hence we are having issues calculating the path towards that node.

 

Although when we do not have any issues this message is cleared

 

R1#show ip ospf da  router 4.4.4.4

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Router Link States (Area 0)

  LS age: 19
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 4.4.4.4
  Advertising Router: 4.4.4.4
  LS Seq Number: 80000002
  Checksum: 0x1BEF
  Length: 48
  Number of Links: 2

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 1.1.1.1
     (Link Data) Router Interface address: 192.168.14.4
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

 

Hope this helps, of course if you see any behavior which seems incorrect open a TAC case and we will investigate this further.

 

Kind regards

Aleksandar Sofranic

 

Hello asofrani,

>> Adv Router is not-reachable in topology Base with MTID 0
this is new indeed looks like multi topology capabilities in OSPFv3 with realms

>> R1#show ip ospf da router 4.4.4.4

OSPF Router with ID (1.1.1.1) (Process ID 1)

Router Link States (Area 0)

LS age: 19
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 4.4.4.4
Advertising Router: 4.4.4.4
LS Seq Number: 80000002
Checksum: 0x1BEF
Length: 48
Number of Links: 2

Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 1.1.1.1
(Link Data) Router Interface address: 192.168.14.4
Number of MTID metrics: 0
TOS 0 Metrics: 1

>> Number of MTID metrics: 0
whar does it mean ? does it mean that multi topologies capabilities might be enabled on the device, but only topology base (the default ) is enabled?

Thanks in advance
Best Regards
Giuseppe Larosa

Dear Giuseppe,

 

Thanks for the reply on this topic. You are spot on regarding MTID, this seems like it is the default topology for IPV4.

 

There is a document which describes how to configure multiple topologies in OSPFV2, take note this has been implemented on 3.11S IOS-XE

Link:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/xe-16/iro-xe-16-book/iro-ospfv2-ospf-live.html

 

Kind regards

Aleksandar Sofranic

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco