CCIEZone.com

If you read back on my post Implementing Source-Specific Multicast (SSM) on Cisco IOS…, the example diagram showed the use of Anycast-RPs, along with MSDP. Well, there are a couple of caveats that I didn’t cover in that article, that were specific to this configuration and I thought should be addressed.

I chose to use OSPF (my IGP of preference) for the IGP in this example network. Well, in an OSPF network, you must have unique Router-IDs. According to Jeff Doyle’s Routing TCP/IP Volume I, the router-id for the OSPF process is determined as follows:

1. If the router-id command is configured, use the ID specified.
2. If loopback interfaces exist, use the numerically highest IP address assigned to any of the loopback interfaces
3. If no loopback interfaces exist, use the numerically highest IP address assigned to any other physical interface. The assumption here on my part is that the interface must be active to use its IP address. Additionally, Jeff states in his book that the interface doesn’t have to be running OSPF to use the address. I’m also making an assumption that secondary addresses aren’t used. The two assumptions I made need to be verified in a lab to determine if I’m right or not — so far, I haven’t done that yet.

So, to summarize, the router-id is chosen as follows: configured router-id value (if it exists), highest loopback address (if it exists), highest IP address assigned to an interface.

In our example, no previous loopback interfaces were created. To implement Anycast-RP, I created a loopback on both R2 and R3 that shared the identical IP address. After that, I setup the OSPF routing processes on the different routers such as (example below is what would work on R2):

router ospf 1
network 10.0.0.0 0.255.255.255 area 0
network 192.168.1.0 0.0.0.255 area 0
network 172.16.32.3 0.0.0.0 area 0

That should work, right? Well, yes and no. When OSPF came up on the R2 router, it used the Loopback0 address (which happens to be the same address as R3’s Loopback0 interface) as the router-id. The same occurred on R3 (same Loopback0 address as R2 and therefore the same OSPF router-id as R2). When R2 and R3 attempted to become adjacent to R1, R1 saw two duplicate router-ids.

I didn’t catch this at first. All that I saw is that one router’s LSAs were in R1’s routing table, but the other router was missing. What was happening? Well, using the debug ip ospf adjacency command R1 helped me find why things weren’t working properly. It listed a duplicate router-id. So, it appeared to take the first router that it became adjacent to and keep the adjacency, but the second router to attempt adjacency with the same router-id was discarded (ignored). It saw the duplicate router-id and wouldn’t take it!

Best-practices when configuring OSPF

Manually define the router-id

It’s my preferred best-practices to set the router-id right upon creation of the OSPF process. By setting the router-id before any adjacencies are formed eliminates the necessity of clearing the OSPF process on the router (which is required for the change to take effect after you change the router-id).

Here’s an example:

router ospf 1
router-id 1.1.1.1    ! NOTICE THAT THE ROUTER-ID WAS SET BEFORE ADDING ANY NETWORK STATEMENTS OR MANUALLY JOINING ANY INTERFACES TO ANY AREA
! CONTINUE ON WITH YOUR TYPICAL OSPF CONFIGURATION FROM HERE ON

One could argue that as long as Loopback0 has an IP address that is set to the desired OSPF router-id, any other loopback interface can be created for other purposes (such as Anycast-RP, etc.). The downside to this is that there’s no guarantee that another person might come along and create a loopback interface with a higher IP address. If this should occur, this will change the OSPF router-id, thereby negating the usefulness of the Loopback0 interface (at least in terms of defining the router-id). Remember, the actual loopback interface number has nothing to do with determining the router-id — it’s the actual defined IP address. Therefore, if Lo5 has IP address 192.168.1.1/32 and Lo0 has IP 10.1.3.5/32, the router-id selection process will use Lo5’s IP address over Lo0’s, because Lo5 had the higher IP address.

Another advantage to manually defining the router-id is the ability to convey configuration information within the router-id. Let’s say a large, worldwide company has several subsidiaries which are located around the world. Each subsidiary might have different sites. If the parent company were using OSPF within the internal networks of each subsidiary organization and wished to have each site accessible from the parent organization, the following router-id numbering scheme could be used:

Octet 1: organization (1 = parent organization, 2+ = child organizations)
Octet 2: site id (would have to be defined and be organization-specific)
Octet 3: building-id or other useful identifier
Octet 4: actual router designation

Using the above example, the router-id 1.2.1.10 could signify that the router is within the parent organization, located at the second site (the number to site mapping would have to be defined by the organization), is within the site’s first data center and that the router is the 10th (or this might be the last octet of the administrative loopback interface, etc.).

Ensure that logging is turned on

Since the log-adjacency-changes command is automatically enabled by default on most newer IOSs, you needn’t enable it (checking to ensure it’s there doesn’t hurt, as it’s really valuable for trouble-shooting).

Know and manage what interfaces are sending/receiving OSPF routing updates

In the real world (a non-lab environment), best practices dictate use of the passive-interface default command, using the no passive-interface <interface-id> command to allow OSPF to send/receive routing updates on the desired interface(s). This can also increase the security posture as a generic network statement allowing entire networks (like my example above) can be disastrous as if an additional interface is configured within one of these broad networks, OSPF will automatically run on this interface, whether you realize it or not — want it or not, here’s OSPF!

Manually defining only the IP address of the interfaces you’d like OSPF to send/receive routing updates on is another way to increase security (might be considered redundant if used with the above recommendation, but this will allow for another layer of security for the paranoid). Rather than using wildcard bits in your network statement, use only the address and no wildcard bits (ie. network 10.0.0.6 0.0.0.0 area 0 would enable OSPF to send/receive routing updates on Serial2/0 on R2 in the example).

Ensure that the OSPF priorities are correct and reflect your desired configuration

Set the OSPF priorities to reflect their role. The default priority is 1. Using a priority of 0 will always prevent a router of becoming the DR/BDR. You should set the DR to the highest priority (255), then set the desired router for the BDR to be priority 254. In reality, without using encryption (discussed below), anyone can start an OSPF process on your network (assuming that ACLs aren’t defined for your internal network) and could hijack the DR and/or BDR roles within your network. At least defining the priorities to a high value can attempt to prevent this form of hijacking.

Protect your OSPF infrastructure — use MD5 encryption

Lastly: use encryption. Without this, you’re susceptible to anyone who can run an OSPF process on your network. Don’t use cleartext authentication. This is really worthless, considering that anyone smart enough to setup an OSPF process probably is adept with a packet sniffer and can easily determine the cleartext password by a packet capture. Therefore, use MD5 authentication — it’s available and relatively secure. Use it!

Conclusion from the above example

I failed to follow my own best-practices when configuring OSPF in the examples above. I didn’t manually set the router-id before doing anything else, which messed things up.

R2 was forming an adjacency with R1 and R1 was becoming adjacent to R3. R1 could only allow one of the duplicate router-ids to become adjacent, leading to the problem I experienced. This resulted in loss of connectivity in the example network. Should this have occurred in a live environment, the results could’ve been catastrophic.

Moral of the story: always manually define your router-ids, along with the other items mentioned above…

Related posts:

1. Implementing Source-Specific Multicast (SSM) on Cisco IOS… I read over RFC 3569 (overview of SSM) and decided...
2. NVRAM errors when saving configuration I was working on a client switch (VSS, modular IOS...
3. BI-DIR PIM Designated Forwarder (DF) equal-metric tie-breaker on Cisco IOS After reading the RFC for BI-DIR PIM (RFC 5015), I...
4. RIP Intricacies In studying for my CCIE R&S lab, I’ve decided to...

Related posts brought to you by Yet Another Related Posts Plugin.

Tags: cisco, cisco ios, highest ip address, IGP, ios, loopback, open shortest path first, ospf, router-id

This entry was posted on Monday, November 12th, 2007 at 8:30 am and is filed under Networking, OSPF. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.