10-16-2012 02:39 PM - edited 03-04-2019 05:52 PM
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?
10-17-2012 01:47 AM
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
10-17-2012 06:51 AM
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
10-17-2012 07:00 AM
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.
10-17-2012 07:12 AM
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
10-17-2012 07:42 AM
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
10-17-2012 07:59 AM
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
10-17-2012 08:13 AM
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.
10-17-2012 09:17 AM
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
10-17-2012 09:26 AM
OK thanks will upload it in a bit.
10-17-2012 10:12 AM
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
10-17-2012 10:34 AM
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
10-17-2012 10:45 AM
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.
10-17-2012 10:49 AM
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.
10-17-2012 11:03 AM
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?
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