When routers are connected to the same broadcast segment (I.O.W. several routers are in the same VLAN, on the same switch you getting the idea). One router is assigned the duty to maintain adjacencies with all other routers on the segment. This is the designated router (DR) and the DR router is selected using information in the Hello messages. For redundancy purposes a backup designated router (BDR) is also elected (There is a reason for this, read on).
DRs are created on multi-access links because the number of adjacencies grows at a quadratic rate. For a network of n routers, the number of adjacencies required would be:
Two (2) routers require the following adjacencies:
Four (4) routers require the following adjacencies:
Ten (10) Routers require the following adjacencies:
Maintaining a OSPF segment consumes more bandwidth and requires more processing resources (CPU and memory) as more routers are added onto a OSPF network (Due to keeping the tables updated and probability of changes occuring more frequently etc).
The DR and maintaining relationships
The purpose of a DR is to be the “one router” (sounds like the matrix) to which all other routers are adjacent (the router that has all the routes on the network). Using a DR reduces the number of adjacencies that consume bandwidth and processing to n – 1 (Larger networks will however still require more processing even if you are using a DR). With a DR the adjacencies scale more effectively and efficiently with the network (as one can see in the below figure and table).
To show this in a graphic way one can see how this “adjacency” relationship works without a DR, with a DR, and with a DR and BDR with a small example network using 5 routers.
Taking this a step further and plotting out the exponential growth requirements of OSPF adjacencies the table below shows the number of adjacencies needed for 1 – 10 routers (imagine the CPU and Memory requirements, not to mention the bandwidth consumption). Plan accordingly when implementing OSPF (at this point you generally use OSPF because you have a non-homogenous network environment and need the open standard because of this fact, I dont really see a point otherwise cause its such a resource hog and mission to setup).
The job of the DR
The role of the DR is to receive updates and distribute these updates to each segment router, making sure that each router acknowledges receipt and has a synchronized copy of the Link-State Database (LSDB).
Routers advertise changes to the “AllDRs” multicast address of 224.0.0.6 where the DR then advertise the Link-State advertisements (LSAs) using the “AllSPF” multicast address 224.0.0.5 where each router then ack receipt.
The BDR listens passively to this exchange and maintains a relationship with all the routers.
If the DR stops producing hellos, the BDR promotes itself and assumes the role of DR.
NB. DRs and BDRs are only useful on multi-access links because they reduce adjacencies. The concept of a DR is not used nor usefull on point-to-point links because there can only be one adjacency.
DRs are still however elected on Point-to-Point Ethernet links (most common type of links in networking these days) which is a rather pointless and resource waste/hog (as a DR is not really needed) which is why you will find that many design guides recommend changing Ethernet links to Point-to-Point mode to stop this from happening.
If a DR fails, the BDR is pomoted. The BDR is elected on the basis of highest OSPF priority, ties in OSPF priority are broken in favour of the highest IP ADDRESS.
The default priority is 1 and a priority of 0 (zero) prevents a router from being elected to the DR or BDR role.
Priority can be set from 0-255 (manually) to change the priority from default from the interface,
Router(config-if)#ip ospf priority number
DRs are inherently seen as stable entities once elected into the position, even if a Router joins a network with a “greater” priority the DR will not change.
To give an example of this an OSPF Segment with 5 Routers ( A – E, with different priorities 0 – 3). Taking what has been discussed previously A would be the DR, B the BDR, and E would never be elected. However this neglects the following set of circumstances:
Imagine the following sequence of events in this small segment,
- Router C starts first.
- Router C sends out Hellos and waits the dead time for a response from other routers.
- Receiving no Response, Router C conducts an Election and becomes the BDR.
- As there is no DR on this network, Router C then promotes itself to DR.
- Router E starts (priority= 0)
- Router E will not become the BDR due to its priority setting
- Router B starts and becomes the BDR.
- Router A starts
- Router D starts
In the above scenario the startup sequence of the routers caused the election of the DR and BDR (namely Router C is DR and Router B is BDR) which is not what would have been expected. This is because designated routers do not preempt, the elected DR/BDR serves in its role until reboot/failure (DR and BDR are stable entities on the network once elected).
In this network as it stands now If Router C restarts, Router B promotes itself to DR and Router A is elected BDR while C is down. If Router B goes down, Router A promotes itself and elects Router C or Router D (whichever has the highest IP Address). Finally when the BDR is rebooted, Router B wins the election for BDR.
NOTE: In addition to rebooting, clearing the OSPS process using the the command clear ip ospf process * on the DR will force the DR and BDR election.
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 can’t 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.
elete the vlan.dat file
Open Shortest Path First – OSPF Fundamentals – Configuring Options On an Internal Router
To allow you to tune OSPF on an Internal Router you have the following options available at your disposal:
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:
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:
Router(config)#router ospfRouter(config-if)#router-id ip-address
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:
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-numberRouter(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 costThe 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 bandwidthTwo 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
Determining the DR with the Priority Command
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 numberNotes 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