Defining the Router ID and Loopback interface
The Router ID (when thinking about OSPF Domains) is used to identify any given Router in the Link State Advertisements (LSAs) in an OSPF Database. A given Router on a network requires an ID (Router ID) to participate in an OSPF Domain. The Router ID can be assigned/set in one of two fashions:
- By the administrator (manually assigned)
- Left to the discretion of the router (automatically assigned by the automatic election process)
In most configurations the Router ID is set by the administrator as this makes it easier to track events, internal documentation, and system-administration remotely or even on the router itself.
Setting the Router ID
The Router ID as discussed previously must be present for a Router to participate in an OSPF Domain. This Router ID can be set in one of two methods:
Setting the Router ID – Method One (Less Preferred)
The OSPF Router ID can be defined using the router-id (background link) command found in IOS.
Using the Router-ID command isn’t always the best idea when combining BGP and OSPF as both technologies employ the same method in electing a Router ID. So manually setting a Router ID (using the Router-id command) for OSPF could cause BGPs Router ID to differ from BGP which causes administration problems as well as could cause other problems at a later stage when combining the two technologies.
Should you still want to change the Router ID using this method anyway the command is:
Dissecting the above when the Router ID has been chosen/assigned using the router-id command, the Router ID is kind of stable and may possibly change (barring a power cycle or a OSPF process reset). This is an important factor because changing the Router ID post (after) configuration could possibly break some OSPF configurations, such as virtual links (which as the name implies don’t exist, and could take some thinking to logically get working again).
Setting the Router ID – Method Two (Preferred)
Should the router-id command not be present/available on the router IOS you are using, and you want a more reliable method (sticky) that spans, the Router ID is automatically elected via:
- The highest IP Address of a manually created loopback interface.
- If there is no configured Loopback interface then the Router ID will be the highest IP Address of the first active (on boot-up) physical interface.
I inherently look for the easier easier solution to a problem that will work long term, more work once off doesn’t matter (first off config) the solution must stick and continue working through power outages, reboots and the CEO trying his hand at “setting up” his own hardware, voice being a good example i.e. putting each end point into it’s own vlan thus ensuring QoS while the organization grows (there are limitations in the number of vlans, but I have yet to reach them).
Looking at the top the better method to control the Router ID (using automatic means) is through the use of the Loopback interface IP address. A loopback interface is a virtual interface (duh) that will always be active (cannot flap) and will be the first active interface (*shrug* logic dictates as it becomes the Router-ID, comments as I haven’t tested this out?).
The command to use a loopback is as follows (CCNA topic):
Router(config)#interface loopback inerface-number
Router(config-if)#ip address ip-address subnet-mask
Consider assigning loopbacks a /32 mask 255.255.255.255 (1 end point) to minimize the ip space usage of the virtual interface(s) on the network (use it dont use it). I have come across some places that say that loopbacks wont work with the /32 mask (cant find source again), I will verify once I setup my kit again. In that case use the smallest (/31 or /30).
What I want to take away from this is should the Router ID be chosen/assigned using the loopback interface, the Router ID is stable and wont change. What’s important here is that a Loopback interfaces is NOT a physical interface thus cannot go up and down (flap) and therefore is not as unstable element in the network (i.e. loopback is stable) and thus is more desirable. Even in the event of a power cycle the loopback will once again be the Router ID.
Think about including the Loopback interface in the general network commands even if you aren’t configuring OSPF. This gives you an easy point to ping to should there be a need to troubleshoot (can I reach point A from point B) this should tell you alot about Layer 1 if the interface is un-shut and it has an ip-address.
Changing the COST
The COST metric on a Cisco is calculated as 100,000,000 bps divided by the bandwidth of the interface in bits per seconds. Sometimes when using a fast interface type (FE and GE) or when dealing with inter-vendor situations (Cisco / 3COM / HP) changing the default cost metric becomes a requirement (this is due to (1) faster link speeds not calculating correctly (2) or the metric equations being different between inter-vendor kit).
The command to change default cost:
Router(config-if)#ip ospf cost cost
The cost variable is a 16-bit value (0 to 65,535). The lower values being the more preferred costs while higher being less preferred (shown below).
As you can see in the above table Fast Ethernet is the “drop off point” (where all things being 1) for the “fast” links (Fast Ethernet and Gigabit Ethernet both equal 1). In this case it would be better to manipulate the default cost so that the Gigabit Ethernet link is preferred over the Fast Ethernet Link. This would mean changing the cost per interface.
Another way to deal with high-bandwidth paths is to change the way a Cisco calculates cost (mess with the equation). We adjust the numerator in the automatic calculation (the Cisco automatic formula) to make some things happen in this case. To do this use the ospf auto-cost reference-bandwidth command on IOS, the default is 100 (Fast Ethernet) adjust it to 1000 (Gigabit Ethernet) and you will “fix” the equation.
Router(config-router)#ospf auto-cost reference-bandwidth reference bandwidth
Two very important NOTES (1) ospf auto-cost reference-bandwidth should be applied to all routers in an area if it is applied at all and the command (2) ip ospf cost overrides the calculated cost calculated by auto-cost reference-bandwidth
The hello field includes a priority field (if you can still remember) thus providing a mechanism by which designated router (DR) and backup designated Router (BDR) gets elected.
To be eligible for election, the priority must be a positive integer between 1 and 255 (if the priority is 0 (zero) the router cannot participate in the election process).
The highest priority wins (Cisco Router Default is 1) the election process.
Because the default is 1, to break all ties the Cisco Router ID is used as the deciding factor in the election process (ergo why hard coding the Router ID is a bad idea). The command to adjust priority (interface-by-interface mind you):
Router(config-if)#ip ospf priority number
Notes and Notices: This is a part of my personal BSCI notes and research to assist myself in learning and understanding the concepts and theory for the BSCI exam. I learn by making notes reading and writing things down and wish to file them where I cannot lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BSCI Certification.
If I added some value to your Cisco Experience with this post please add some value to my studies and leave a comment, question, suggestion, note of thanks or encouragement for me to hurry up and complete my certifications. My reasoning for wanting some interaction is that the last Recruiter said I need CCNP, Juniper and a Specialization track. The LOOOOONG Road to Cisco Indeed. Thanks Deon