The command requirements for configuring OSPF in a single area is relatively (compared to say other routing protocols) few in number and simple; the implications of the commands are somewhat complicated but need to be understood.
Required Commands for Configuring OSPF WITHIN a Single Area
We are going to configure an OSPF internal router. An Internal router being one with all interfaces that lie within a single area. The sole OSPF function on an internal router is to route within an area.
The Router needs to understand how to participate in the OSPF network:
- OSPF Process – Declare an OSPF process.
- Participating interfaces – Identify the interfaces to be used by OSPF.
- Area – Definitions are done per interface. This discussion assumes that all active interfaces are in the same area.
- Router ID – A unique 32-bit ID, usually drawn from an interface IP Address.
Enabling the OSPF Routing Protocol
Router(config)#router ospf process-number
In the above the process-number is not globally significant. It is possible to have more than one process running on a router (although that would be an unusual configuration, but not unheard of) and two OSPF processes could route for different parts of the network. The process number does not have to be the same on every router in the area.
The OSPF Network Command
Once OSPF is turned on (the above command), you must define the interfaces that are to participate in OSPF and the area that they reside in:
Router(config-router)#network network-number wilcard-mask area area-number
NB.Take note of the above command. Many errors occur in configuration with this command, normally due to misapplication of the wildcard-mask parameter, either including too many or too few interfaces in a particular OSPF area.
Similar to other routing protocols like RIP, the network command identifies the interface on which the OSPF process is to be active. Unlike RIP however this command has a wilcard mask that allows it to be very specific. All interfaces that match the network wildcard mask will be active within the given area.
One can apply the network command in different ways, each method will yield different yet similar results.
- FE 0/0 : 192.168.0.1 / 24
- FE 0/1 : 192.168.1.1 / 24
- FE 0/2 : 192.168.2.1 / 24
- FE 0/3 : 192.168.3.1 / 24
- S o/1 : 10.10.1.1 / 30
- s 1/1 : 10.10.2.1 / 30
We can enable OSPF area 0 (zero) on all interfaces with the following command:
Router(config-router)#network 0.0.0.0 255.255.255.255 area 0
When using this approach you may include interfaces inadvertently that you may not want to include (as this is a sweeping statement config line).
The second method would be to break the network into the 10 network and the 192 network, as follows:
Router(config-router)#network 10.0.0.0 0.255.255.255 area 0
Router(config-router)#network 192.168.0.0 0.0.3.255 area 0
This approach gives a little more control over the two different networks (192.x.x.x and 10.x.x.x) splitting them into two config lines.
Another method would be to separately enable OSPF on each interface;
Router(config-router)#network 192.168.0.1 0.0.0.0 area 0
Router(config-router)#network 192.168.1.1 0.0.0.0 area 0
Router(config-router)#network 192.168.2.1 0.0.0.0 area 0
Router(config-router)#network 192.168.3.1 0.0.0.0 area 0
Router(config-router)#network 10.10.1.1 0.0.0.0 area 0
Router(config-router)#network 10.10.2.1 0.0.0.0 area 0
This option is more time consuming to deploy but gives much more control over what interface specifically is included and not included in area 0 (zero) which will enable much more control over the routing process.
All the above achieve the same thing (six interfaces places in area 0 (zero) begin to process OSPF traffic).
The technique that is used should be functional, effective and efficient given the topology and application on the network while still maintaining the ability to be documented thoroughly (Keep It Simple Stupid KISS or as simple as possible, because you might not be the one to always maintain the network).
NB.Be intimately familiar (CCNA) with wildcard masks and the network command to enable OSPF on router interfaces
The area parameter puts the designated interface into an area. A router can have different interfaces in different areas (as mentioned earlier thus making the router an Area Border Routers (ABR)). The area-number is a 32-bit field and format can either be a simple decimal (0, 1, 2, 3, 4) or dotted decimal( 0.0.0.1, 0.0.0.2, 0.0.03, 0.0.0.4). Some implementations of OSPF might only understand one of the formats (keep in mind that some vendors throw the dotted decimal around 0.0.0.1 will become 1.0.0.0), Cisco understands both formats.
After identifying the interfaces on the router that are participating in the OSPF domain, hellos are exchanged, LSAs are sent, and the router inserts itself into the network.
NB.If there are stub networks connected to a OSPF router, it is useful to issue the command redistribute connected subnets. This command includes the connected subnets in OSPF advertisements without actually running OSPF on these routers. A route-map is often used with this command to exclude interfaces that are explicitly configured with OSPF
Next up Internal Router Config in more detail….
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.
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