Hi I've got a problem in the network with a duplicate OSPF router-id. We tipically use the loopback ip address as the router-id, but I'm afraid that someone in the network don't care about that.
I wanted to know if there is a simple way to get this information. By now I'm writting a perl script to get the information via snmp to list all the router-id in the network.
How to find a duplicate router-id ospf in the network
ospf
Related Solutions
A Tale of Three Stubs...
When using Cisco equipment, OSPF calls several things a "stub"... it gets a bit confusing....
- Stub Host
- Stub Network
- Stub Area
The meanings are very different for each term; even more confusing is the reality that you can potentially apply multiple stub terms to a single OSPF interface. I'll elaborate more below.
Background
Let's clear up some terminology... The question starts off asking about what Cisco is calling a "Stub Host"... OSPF automatically assigns Loopback interfaces to this category...
CORE01.PUB.DAL02#sh ip ospf interface lo0
Loopback0 is up, line protocol is up
Internet Address 128.66.62.5/32, Area 0.0.0.0
Process ID 100, Router ID 128.66.62.5, Network Type LOOPBACK, Cost: 1
Loopback interface is treated as a stub Host
^^^^^^^^^
CORE01.PUB.DAL02#
All this is not to be confused with what OSPF refers to as "Stub Network"... which merely means a network without an OSPF neighbor
CORE01.PUB.DAL02#sh ip ospf data router internal
...
Link connected to: a Transit Network <------- Broadcast Intf w/ Neighbor
(Link ID) Designated Router address: 128.66.62.75 <-------
(Link Data) Router Interface address: 128.66.62.75
Number of TOS metrics: 0
TOS 0 Metrics: 10
...
Link connected to: a Stub Network <------ Broadcast Intf w/o Neighbor
(Link ID) Network/subnet number: 128.66.62.32 <------
(Link Data) Network Mask: 255.255.255.248
Number of TOS metrics: 0
TOS 0 Metrics: 1
Link connected to: a Stub Network <------ Loopback interface
(Link ID) Network/subnet number: 128.66.62.5
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1
Then, of course, we have an OSPF Stub Area. Let's consider where all this comes from...
OSPF Stub Network vs OSPF Transit Network
Transit and Stub networks are discussed in RFC 2328: OSPFv2 - Section 2.1:
2. The Link-state Database: organization and calculations
The following subsections describe the organization of OSPF's link-
state database, and the routing calculations that are performed on
the database in order to produce a router's routing table.
2.1. Representation of routers and networks ... Networks can be either transit or stub networks. Transit networks are those capable of carrying
data traffic that is neither locally originated nor locally
destined. A transit network is represented by a graph vertex
having both incoming and outgoing edges. A stub network's vertex
has only incoming edges.
The whole point of this distinction between Transit Network and Stub Network is to save resources in the router.
- Transit Networks must maintain additional memory for neighbor information
- Stub Networks save memory on the router because no neighbors need to be assigned
When we start scaling to potentially thousands of LSAs, even small memory savings are important. Note that OSPF hellos are still sent on a stub networks, and they are capable of forming neighbors / transitioning to a transit network unless the interface has been administratively marked as a passive interface.
OSPF Host Routes - Cisco's "Stub Host"
So now we still have the original discussion about the Stub Host, which also happens to be an OSPF Stub Network. This concept comes from RFC 2328: OSPFv2 - Section 9.1, where it discusses various interface states...
9.1. Interface states The various states that router interfaces may attain is
documented in this section.
Down
...
Loopback
... For this reason, IP packets may
still be addressed to an interface in Loopback state. To
facilitate this, such interfaces are advertised in router-
LSAs as single host routes, whose destination is the IP
interface address.[4]
...
Waiting
...
Point-to-point
...
The RFC requires Loopback network types to be advertised as a /32 host route. What Cisco calls a Stub Host in show ip ospf interface
output is really just the Loopback interface type, which OSPF allocates automatically as a /32 host route within OSPF.
OSPF Stub Area
Stub areas are covered in RFC 2328: OSPFv2 - Section 3.6. There are several categories of OSPF stub areas...
- Stub Area: No Type-5 External LSAs are allowed in this area, which means no route redistribution inside the area. A Type-3 Network LSA is originated at the ABR so no connectivity is lost from Type 5 LSAs which are blocked by the stub feature. OSPF has a E-bit field in Hello packets (E-bit =
ExternalRoutingCapability
), which is cleared when an area is configured as a Stub Area - Totally Stubby Area: No Type-5 External LSAs, and only the Type-3 Network LSA default route is permitted. This is a vendor-specific feature, which is not covered in RFC 2328.
- Not So Stubby Area: No Type-5 External LSAs are allowed, but redistribution is permitted via a special Type-7 LSA.
Summary
In summary, we talked about...
- Stub Host: A loopback network-type, which is always advertised as a /32 host route; Cisco calls this a stub host.
- Stub Network: An OSPF network, which does not have a neighbor attached to it
- Stub Area: An OSPF area, which does not permit Type-5 External LSAs.
If you really want to wrap your mind around all this, consider an OSPF router, which has a loopback interface; this router is completely contained in a single OSPF stub area. Technically, you could apply all three of the OSPF "stub" terms to this Loopback (Stub Host, Stub Network, Stub Area).
The loopback interface is useful because it is an interface with an IP address which never goes down. OSPF, without a specifically defined Router ID, will pick a Router ID on its own. It chooses the Router ID from the IP addresses of the configured and enabled interfaces. A loopback is a good choice since the loopback interface is always up unless someone specifically shuts it down. Other interfaces may go down if there is a problem on the link.
Best Answer
If you have access to config repositories, the best way to do this is to search through them all to find duplicate entries. Assuming you're on a *NIX host, you could do something like:
You want to look for anything that has a '2' in the first column. You can then find the offender and grep for the IP to find the routers that it's configured on. This would likely be the simplest way. You're already on the right track with a Perl script to poll the devices via SNMP to get at the
router-id
IP addresses, but I will say that SNMP code can be a little "hairier" than just simply usingNet::SSH::Expect
orNet::Appliance::Session
to just log into the devices and dump the running configs to filehandles (at which point you can use the technique above).Assuming you're running Cisco, there's also a fairly comprehensive troubleshooting guide that covers this topic if you're interested.