Re: OSPF E2 vs N2

Kelvin Willacey · ‎10-16-2012

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?

Peter Paluch · ‎10-17-2012

Hello,

I know that E2 routes should be preferred over N2 routes, unless the forward metric is lower for the N2 route. Is this correct?

This behavior is correct if the NSSA implementation conforms to RFC 1587. This RFC is considered obsolete now and is superseded by RFC 3101 which prefers N2 routes over E2 routes if available. What IOS version do you run?

Best regards,

Peter

Alessio Andreoli · ‎10-17-2012

 I know that E2 routes should be preferred over N2 routes, unless the forward metric is lower for the N2 route. Is this correct?

No , it is not correct. Regardless the metric OSPF will always prefer intra-area over inter-area over external routes. And among the external routes there will always be E1 over E2 over N1 over N2. In your case, being area 10 a totally NSSA, it is natural to get N2 routes once redistributed.

Hope this helps

Alessio

Kelvin Willacey · ‎10-17-2012

Thanks Peter, I am running Advanced Enterprise 15.01.M3. I will look into that RFC.

Alessio I expected N2 routes I just never expected them to be preferred over the E2 routes and I still don't get why the forward metric does not consider the exit interface for the static route. I still believe forward metric decides which routes to put in the table when it comes to external routes but not inter area over intra area.

nickbonifacio · ‎10-17-2012

Hi K,

Can you do "show ip ospf data nssa-ext x.x.x.x" for one of the routes in question and paste the results here?

Thanks!

Nick

Nick Bonifacio CCIE #38473

Kelvin Willacey · ‎10-17-2012

Hi Nick, please see below:

DC#sh ip ospf database nssa-external

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

Type-7 AS External Link States (Area 90)

Routing Bit Set on this LSA in topology Base with MTID 0

LS age: 169

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

LS Type: AS External Link

Link State ID: 192.168.50.0 (External Network Number )

Advertising Router: 10.50.1.252

LS Seq Number: 80000001

Checksum: 0x11B7

Length: 36

Network Mask: /24

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

MTID: 0

Metric: 20

Forward Address: 0.0.0.0

External Route Tag: 0

DC#sh ip ospf database external

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

Type-5 AS External Link States

LS age: 181

Options: (No TOS-capability, DC)

LS Type: AS External Link

Link State ID: 192.168.50.0 (External Network Number )

Advertising Router: 10.50.1.252

LS Seq Number: 80000001

Checksum: 0xEFE7

Length: 36

Network Mask: /24

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

MTID: 0

Metric: 20

Forward Address: 10.130.99.3

External Route Tag: 0

Route with area 90 (10 was a mistake) link up:

DC#sh ip route 192.168.50.0

Routing entry for 192.168.50.0/24

Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 100

Last update from 10.145.98.2 on FastEthernet0/0, 00:01:22 ago

Routing Descriptor Blocks:

* 10.145.98.2, from 10.50.1.252, 00:01:22 ago, via FastEthernet0/0

Route metric is 20, traffic share count is 1

Route with area 90 link down:

DC#sh ip route 192.168.50.0

Routing entry for 192.168.50.0/24

Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 200

Last update from 10.144.91.3 on FastEthernet0/1, 00:00:04 ago

Routing Descriptor Blocks:

* 10.144.91.3, from 10.50.1.252, 00:00:04 ago, via FastEthernet0/1

Route metric is 20, traffic share count is 1

nickbonifacio · ‎10-17-2012

Hi K,

So what if we translate LSA Type7s to Type 5s ?

area 90 nssa translate type7

Is this production or a lab environment?

Thanks!

Nick

Nick Bonifacio CCIE #38473

Kelvin Willacey · ‎10-17-2012

Hi Nick, it's a lab environment based on the production environment so I can try it but that may not work for me. Area 90 is for the remote locations and I need them to learn the routes too, so if I translate it to type 5 then those routers that are only in area 90 will not learn them since it's a totally nssa? I just want the two DCs to talk over area 0 and unfortunately the routes that I need to advertise between the DCs have to be redistributed static routes.

nickbonifacio · ‎10-17-2012

Hi K,

I might be misunderstanding the diagram/topology. This is definitely something I want to help you with. Can you do a quick diagram to show how things are connected, IPs, ospf config, etc? I can try to recreate the topo and dig in there.

Thanks!

Nick

Nick Bonifacio CCIE #38473

Kelvin Willacey · ‎10-17-2012

OK thanks will upload it in a bit.

Kelvin Willacey · ‎10-17-2012

Here it is. The green and dark blue lines are in area 0 and the others are in area 90. The green line is a dedicated link between both data centres. The firewalls don't do routing and so any route that I have to advertise will have to be a redistributed static route. This does not affect the remote sites really in that they have a default route to the DC WAN router and the DC WAN router defaults to the core and the core defaults to the firewall.

My real issue is that I want traffic between the data centres to use the green link and not the area 90 links. Which would be fine if I could just advertise intra area routes for area 0 if the firewall did routing.

DC1

crypto isakmp policy 90

encr aes 256

authentication pre-share

group 5

lifetime 60

crypto isakmp key cisco address 0.0.0.0 0.0.0.0

!

crypto ipsec security-association lifetime kilobytes 460800

!

crypto gdoi group BRANCH_GETVPN

identity number 43218

server address ipv4 10.50.1.248

!

crypto map BRANCH_VPN_GDOI_MAP local-address Loopback0

crypto map BRANCH_VPN_GDOI_MAP 1 gdoi

set group BRANCH_GETVPN

!

interface Loopback0

ip address 10.50.1.254 255.255.255.255

ip ospf 1 area 0

!

interface FastEthernet0/0

ip address 10.145.98.1 255.255.255.0

ip ospf priority 254

ip ospf 1 area 90

duplex auto

speed auto

crypto map BRANCH_VPN_GDOI_MAP

!

interface FastEthernet0/1

ip address 10.144.91.1 255.255.255.248

ip ospf priority 254

ip ospf 1 area 0

duplex auto

speed auto

crypto map BRANCH_VPN_GDOI_MAP

!

interface FastEthernet1/0

ip address 10.144.92.1 255.255.255.248

ip ospf priority 254

ip ospf 1 area 0

duplex auto

speed auto

!

interface FastEthernet1/1

no ip address

shutdown

duplex auto

speed auto

!

router ospf 1

router-id 10.50.1.254

ispf

log-adjacency-changes

auto-cost reference-bandwidth 10000

area 90 nssa no-summary

timers throttle spf 10 100 5000

timers throttle lsa 10 100 5000

timers lsa arrival 80

passive-interface default

no passive-interface FastEthernet0/0

no passive-interface FastEthernet0/1

no passive-interface FastEthernet1/0

!

DC2

crypto isakmp policy 90

encr aes 256

authentication pre-share

group 5

lifetime 60

crypto isakmp key cisco address 0.0.0.0 0.0.0.0

!

crypto ipsec security-association lifetime kilobytes 460800

!

crypto gdoi group BRANCH_GETVPN

identity number 43218

server address ipv4 10.50.1.248

!

crypto map BRANCH_VPN_GDOI_MAP local-address Loopback0

crypto map BRANCH_VPN_GDOI_MAP 1 gdoi

set group BRANCH_GETVPN

!

interface Loopback0

ip address 10.50.1.252 255.255.255.255

ip ospf 1 area 0

!

interface FastEthernet0/0

ip address 10.145.98.2 255.255.255.0

ip nat outside

ip virtual-reassembly

ip ospf priority 253

ip ospf 1 area 90

duplex auto

speed auto

crypto map BRANCH_VPN_GDOI_MAP

!

interface FastEthernet0/1

ip address 10.144.91.3 255.255.255.248

ip ospf priority 253

ip ospf 1 area 0

duplex auto

speed auto

crypto map BRANCH_VPN_GDOI_MAP

!

interface FastEthernet1/0

ip address 10.130.99.1 255.255.255.248

ip nat inside

ip virtual-reassembly

ip ospf priority 254

ip ospf 1 area 0

duplex auto

speed auto

!

interface FastEthernet1/1

no ip address

shutdown

duplex auto

speed auto

!

router ospf 1

router-id 10.50.1.252

ispf

log-adjacency-changes

auto-cost reference-bandwidth 10000

area 90 nssa no-summary

area 90 default-cost 30

timers throttle spf 10 100 5000

timers throttle lsa 10 100 5000

timers lsa arrival 80

redistribute static subnets route-map STATIC_TO_OSPF

passive-interface default

no passive-interface FastEthernet0/0

no passive-interface FastEthernet0/1

no passive-interface FastEthernet1/0

!

ip forward-protocol nd

no ip http server

no ip http secure-server

!

ip nat inside source static 10.130.99.2 10.144.92.4 route-map APP-FAILOVER-TRAFFIC

ip route 192.168.50.0 255.255.255.0 10.130.99.3

!

ip access-list standard STATIC_ROUTES

permit 10.144.92.4

permit 192.168.50.0 0.0.0.255

deny any

!

ip access-list extended APP-NAT

permit ip 10.148.10.0 0.0.0.63 host 10.144.92.4

!

route-map STATIC_TO_OSPF permit 10

match ip address STATIC_ROUTES

!

route-map STATIC_TO_OSPF deny 15

!

route-map APP-FAILOVER-TRAFFIC permit 10

match ip address APP-NAT

nickbonifacio · ‎10-17-2012

K,

I found this in another thread:

1. N1 & E1 are preferred over N2 & E2 for the same route

2. When N1 & E1 have the same route to the destination, The one that have lower cost / Metric will win and get into the route table

3. If both N1 & E1 have the same cost, P-bit in N1 will be used to break the tie.

4. If P-bit is 0, then E1 & N1 will be both install into the routing table.

source:

https://learningnetwork.cisco.com/thread/6038

Now I am asking myself does #2 and #3 apply to E2 vs N2? Maybe you could use a route map to change them to type 1 and force the behavior you want?

I am going to lab this up asap and then get back to you.

Thanks!

Nick

Nick Bonifacio CCIE #38473

Kelvin Willacey · ‎10-17-2012

I think I am hitting #2 which would mean all I would need to do is modify the metric for my area 0 link to be less than my area 90 link in order for the E2 route to win. This is what I thought I would have to do but what is bothering me is that the forward metric for the area 90 route only seems to consider one hop to calculate the metric and not both hops to get a forward metric of 100 when the E2 route considers both hops to get its forward metric of 200.

nickbonifacio · ‎10-17-2012

It would have to be External Type 1 to take every hop (entire path cost) into account when calculating the metric.

Type 2 takes into account only the cost of the ASBR to the final destination.

Nick Bonifacio CCIE #38473

Kelvin Willacey · ‎10-17-2012

Yes that's right but now why is the E2 forward metric 200 and not 100. The N2 route forward metric is correct the cost to the ASBR is 100 so why is the E2 200. What am I missing now?