If there are OSPF routers with the same router ID in a topology, then OSPF will simply not function correctly. OSPF routers with the same ID will not become neighbors, but you can still have duplicate router IDs in an active OSPF topology. Such a situation can have unpredictable results. There is no “normal” behaviour in such a situation, so any strange behaviour that you observed cannot really be evaluated as a bug.
You can find out more about the router ID and the consequences of it not being unique in a topology at the following lesson:
Here is my EVE diagram. I have my area 1 as totally NSSA area. R1 redistribute a static route on R1 to OSPF totally NSSA area. I have another static route redistribute on R9 in area 3 into OSPF. Then advertise 23.23.23.23 into EIGRP then redistribute into OSPF on R8.
My question is if I configure the redistribution metric type to 1 on R1, i see the ABR R3 routing table shows it prefer O N1 type, while the rest of the area 0 routers are using O E1.
So routers in the OSPF domain can use different path selection? In my case, R3 and R5 are using the different path selection.
The reason R3 use O N1 is it because it’s also part of the totally NSSA area, so N1 is more preferred? Since the rest of the routers are not in totally NSSA area, so no type 7 LSA, then there won’t be a O N1/ N2 route. They just use E1/E2 because type 7 LSA got translated to type 5. am I understand this correctly?
It’s not a matter of being in the same domain, it’s a matter of receiving two different types of routes to the same destination, and choosing one over the other. If an OSPF router receives an OSPF N1 type route and an OSPF E1 type route to the same destination, it will choose one over the other. Now the fact that R3 and R5 are each doing something different means that something else is going on. It can be one of the following:
As mentioned in the lesson, IOS releases 15.1(2)S and later prefer N routes over E routes, while earlier releases prefer E routes over N routes. Which IOS version are your routers using? Could it be that R5 is using an earlier version while R3 is using a later one?
How is R3 redistributing the 23.23.23.23 route learned from R1 into Area 0? What is R5 receiving from R3? Could it be that R3 is changing the type of route that is being advertised, thus making R5 choose E1 instead of N1? Use the show ip ospf database command to see what is being received by R5.
Hopefully, this will lead you in the right direction for your troubleshooting…
R5 and R3 are both using 15.2(2.15). R3 is a ABR between area 0 and totally NSSA area, so I think R3 will just translate type 7 LSA to type 5 LSA . When I do “show ip ospf database” on R5 then I can see it’s via type-5 LSA. Is this the reason why it’s using O E1 because it doesn’t have type 7 LSA?
Yes, R3 is receiving a type 7 LSA and thus is receiving both an O N1 route and an O E1 route to the same destination, and is thus choosing the O N1 route as per the order for your IOS version. Conversely, R5 is not receiving a type 7 LSA, but only a type 5 LSA, and is thus choosing the O E1 route for the destination.
Yes, that is exactly correct, because the type 7 LSA is contained within the totally NSSA are of Area 1, and never reaches R5.
Actually, the metric of type 1 and type 2 routes will be different. This is because of the way that the metric of each one is measured. Specifically, a type 1 route has a metric that is the sum of the internal OSPF cost and the external redistributed cost. A type 2 route has a metric equal only to the redistributed cost.
So in the particular case of the E1 and E2 routes, as well as the N1 and N2 routes, the Type 1 routes include the sum of the external route cost (20) and the internal OSPF cost (1) with a cost of 21. While the type 2 routes include only the cost external to the OSPF domain (20). More info on this can be found at the following Cisco documentation:
Yes, this is true. Routing is simply the decision-making process of a router to decide to which next-hop router a particular packet should be sent (outgoing). Routing protocols allow routers to learn about routes that other routers around them “know” about, thus giving them more information to more successfully route packets.
But routing configuration and protocols on any particular router will only affect outgoing traffic from that router. Any incoming traffic is simply accepted and processed, and cannot be directly influenced. This is true of any routing protocol, including EIGRP.
Now having said that, it is possible to indirectly affect incoming traffic, by advertising various metrics to particular destinations to neighboring routers, but this is beyond your original question…
The question of “affecting incoming traffic” has meaning at the network edge, where you have your routers that you have control over, but you don’t have control over the ISP routers to which they are connected. These routers talk to each other using BGP, and you affect incoming traffic in the ways mentioned in the post above.
In contrast, when you employ an IGP, you typically have control of all of the devices in the routing domain, so there is no reason to need to influence incoming traffic.
However, strictly speaking, if you wanted to achieve this how would you do it? You would have to find ways to modify the metric to a particular downstream destination, so that when you advertise that destination to an upstream router, the final metric they configure will be larger or smaller, thus affecting their routing decisions. In EIGRP, you would do this by increasing the bandwidth parameter on particular interfaces, and in OSPF you could increase the cost of specific interfaces. For more info on how to do this, take a look at the related EIGRP and OSPF lessons.
When this article was written, the prefered path order that IOS devices used, as written in the lesson, was indeed the following:
Intra-Area (O)
Inter-Area (O IA)
External Type 1 (E1)
NSSA Type 1 (N1)
External Type 2 (E2)
NSSA Type 2 (N2)
This order is based on RFC 1587, and the whole lesson is based on this order of preference, and for this reason, E1 comes before N1, and E2 before N2. Since then, RFC3101 has come out which changes the order. This order is mentioned in a small comment within the lesson.
IOS versions 15.1(2)S and later use the RFC3101 order, while earlier versions use the RFC1587 order.
The lesson uses an IOS version earlier than 15.1(2)S so the order is according to RFC1587.
What you are talking about here is how can we select the path to take among multiple intra-area routes, that is, within a particular area. Note that routing traffic within an OSPF area is different from the OSPF path selection explained in this lesson.
Within an area, whether routers are connected in a full mesh arrangement or not, you can affect the paths that OSPF routes traffic in several ways. One is to adjust the OSPF cost of particular interfaces. YOu can see how this can be done in the following lesson:
You can also do this by adjusting the bandwidth parameter on the router interfaces.
Hello, I have a question why R1 select go via R3, but not do ballancing?
R1#sh ip ospf database router 3.3.3.3
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 1)
LS age: 710
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 3.3.3.3
Advertising Router: 3.3.3.3
LS Seq Number: 8000000E
Checksum: 0x7FCA
Length: 60
AS Boundary Router
Number of Links: 3
Link connected to: a Stub Network
(Link ID) Network/subnet number: 22.22.22.2
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
R1#sh ip ospf database router 2.2.2.2
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
LS age: 683
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
LS Seq Number: 80000007
Checksum: 0x3B85
Length: 60
Number of Links: 3
Link connected to: a Stub Network
(Link ID) Network/subnet number: 22.22.22.2
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
22.0.0.0/32 is subnetted, 1 subnets
O 22.22.22.2 [110/2] via 192.168.13.3, 00:20:35, GigabitEthernet0/1
