OSPF is a popular protocol, and even in the CCNA you can get up and running with it. In fact, you can set up a working solution in minutes. However, getting Ospf right may take some time, specially if you want to follow the best practices. Once you do follow them, you will create a network which is easy to maintain, troubleshoot, and scale. In this article we will walk you through an by the book Cisco OSPF configuration.

To get the most out of this article, you should roughly know OSPF. If you don’t, you can check out this OSPF explanation first. The content you find here is CCNP-level, and can help you with the certification as well.

Cisco OSPF Configuration with a lab

This article contains all the guidelines to do a Cisco OSPF configuration. In fact, if you just want to consult them, scroll down. However, for those of you experimenting, we included a GNS3 lab you can download clicking on the link below.

This lab includes the project you are going to work with, and a copy of the finished project. For both, we extracted the configurations from GNS3 so that you can try the lab on real hardware if you want to.

The topology

Below, the layer 3 topology for this lab. If you open the GNS3 file, you will find the same structure.

Before we dive into the configuration, take a moment to understand the topology. Despite having only three routers, this is not a simple triangle. In fact, each Router has some loopback interfaces to emulate some LANs connected to it. On top of that, we imagine that the two router on the left are at the main site, and the router on the right is in a separate building. You will find similar configurations several times in your career.

Since the topology is small, both from a logical and geographical term (two close buildings), using just Area 0 is enough. We don’t need to add complexity by separating the two buildings in two areas, as we don’t know yet possible future changes. So, we should keep things simple for now.

For this lab, we start with no routing configuration on the routers. We pre-configured the routers interfaces and IP addresses for you, but nothing more than that. You will need to implement OSPF from scratch.

Cisco OSPF Configuration Best Practices

All the best practices (TL;DR)

If you just want to know the best practices, we have the list for you. However, we won’t present the configuration commands here. You can find them in the section dedicated to each point, right after this list.

• Always set a router ID
• Precise network definition
• Default passive interface
• Use a different OSPF authentication for each neighbor
• Always redistribute with route maps, even static routes
• Keep areas to a bare minimum, and never use virtual links (unless you know what you are doing)

Alright, now we can start facing each of these topics. For the lab, we are going to use OSPF PID 1, so create the OSPF instance on all the routers with the following command.

router ospf 1

Always set a Router ID

OSPF heavily rely on the Router ID (RID). This is a 32-bit numeric identifier of the router, that looks like an IP address (but isn’t). Since it is the same size of an IP address, if you don’t specify one the Cisco router will do on its own. Specifically, the router will take an IP address from an interface and use it as router ID. While doing so, it prefers the highest IP address among loopback interfaces. If no loopback interface exists, it will prefer the highest IP address among physical interfaces.

Chances are, you have at least one IP address on your router, so Cisco will generate the RID for you. Thus, it won’t show any error, and many engineer thinks it is okay this way. It isn’t. No two routers can have the same router ID, and you want to know which router has which ID.

So, configure a router ID that you can actually associate with the router. This will make the Cisco OSPF configuration more predictable, and ease the troubleshooting. Configuring the RID is as simple as using the router-id command. So, this is what you need to do on R1…

router ospf 1
 router-id  1.1.1.1

This is for R2…

router ospf 1
 router-id 2.2.2.2

And  this is R3…

router ospf 1
 router-id 3.3.3.3

Use precise network statements

As we know, OSPF speaks and listens only on interfaces that are parts of the specified network. The quick approach here would be “talk on any network”. This, in turns, means that the router is willing to form adjacencies with any other router. Of course, this is a potential vulnerability in terms of security, and we should avoid it. On top of that, OSPF may end up leaking routing information we don’t want to propagate. This, at best, translates into a bad configuration. At worst, it translates into the network going down because of routing loops.

So, enable OSPF only where you know OSPF must be enabled. That is, only on the networks where you have neighbors. We don’t even use it on loopback interfaces, as we will redistribute them instead. We do that because we will never need to form OSPF adjacencies on a loopback interface.

According to what we said, we can configure the networks in the following way. On R1, do this…

network 10.80.0.0 0.0.0.3 area 0
network 10.80.0.8 0.0.0.3 area 0

Instead, do this on R2…

network 10.80.0.0 0.0.0.3 area 0
network 10.80.0.4 0.0.0.3 area 0

And this on R3…

network 10.80.0.4 0.0.0.3 area 0
network 10.80.0.8 0.0.0.3 area 0

Use default passive interface

Probably, this is the most important part of the entire Cisco OSPF configuration. Yet, not all engineers do that. This powerful tool tells the router to not form any OSPF adjacency. The administrator must specify manually what are the interfaces on which to allow an adjacency. This adds additional security and predictability to the configuration.

In fact, after the configuration of the previous section, routers have formed adjacencies. You don’t want that, you want to form adjacencies only when everything is ready. In the lab, we did it just to show this problem, don’t do it in production. So, first think, use passive-interface default. This tells the router to not form adjacencies. Then, use the no passive-interface for specific interfaces. This, instead, tells the router what are the interfaces allowed to form adjacencies. So, this is what we want to do on R1…

passive-interface default
no passive-interface FastEthernet0/0
no passive-interface FastEthernet1/0

These are teh commands for R2…

passive-interface default
no passive-interface FastEthernet0/0
no passive-interface FastEthernet0/1

And these are the commands for R3…

passive-interface default
no passive-interface FastEthernet0/1
no passive-interface FastEthernet1/0

Use OSPF Authentication

This is another important step in our Cisco OSPF Configuration. According to the best practices, you must know what neighbor to expect on a given interface. In other words, if I move a valid neighbor from a non-passive interface to another, it should not form an adjacency. Instead, adjacencies should only happen where we want them, with the neighbors we expect.

This makes the network more predictable, ad avoids weird setups where routes come from the wrong neighbor. This is particularly common in case of LANs and shared broadcast segments. Thus, you need to enable the authentication for the area with area 0 authentication first. Then, configure the authentication key on the interface. That key must match on both neighbors.

So, here we have the commands for R1…

router ospf 1
 area 0 authentication
 exit

interface FastEthernet 0/0
 ip ospf authenticaton-key R1R2
 exit

interface FastEthernet 1/0
 ip ospf authentication-key R1R3
 exit

These are the commands for R2…

router ospf 1
 area 0 authentication
 exit

interface FastEthernet 0/0
 ip ospf authenticaton-key R1R2
 exit

interface FastEthernet 0/1
 ip ospf authentication-key R2R3
 exit

And, finally, the commands for R3…

router ospf 1
 area 0 authentication
 exit

interface FastEthernet 0/1
 ip ospf authentication-key R2R3
 exit

interface FastEthernet 1/0
 ip ospf authentication-key R1R3
 exit

Redistribute with route maps

When redistributing routes, you need to have control on what you are redistributing. What better solution of route maps? Basically, you manually specify the list of routes that are allowed in redistribution. This is a complex topic, we covered it in two articles: one about redistribution, and another about route maps.

In short, create an access list to define the exact routes allowed in the redistribution. Then, create a route map to define that the routes from the ACL may be redistributed. Finally, apply the route map to the redistribution process. Here are the commands for R1.

ip access-list standard CONNECTED-NETWORKS
 permit 10.1.1.0 0.0.0.255
 permit 10.1.2.0 0.0.0.255
 permit 10.1.3.0 0.0.0.255
 permit 10.1.4.0 0.0.0.255

route-map REDISTRIBUTE-CONNECTED permit 10
 match ip address CONNECTED-NETWORKS

router ospf 1
 redistribute connected subnets route-map REDISTRIBUTE-CONNECTED

The commands for R2…

ip access-list standard CONNECTED-NETWORKS
 permit 10.2.1.0 0.0.0.255
 permit 10.2.2.0 0.0.0.255
 permit 10.2.3.0 0.0.0.255
 permit 10.2.4.0 0.0.0.255

route-map REDISTRIBUTE-CONNECTED permit 10
 match ip address CONNECTED-NETWORKS

router ospf 1
 redistribute connected subnets route-map REDISTRIBUTE-CONNECTED

And the commands for R3…

ip access-list standard CONNECTED-NETWORKS
 permit 10.3.1.0 0.0.0.255
 permit 10.3.2.0 0.0.0.255
 permit 10.3.3.0 0.0.0.255
 permit 10.3.4.0 0.0.0.255

route-map REDISTRIBUTE-CONNECTED permit 10
 match ip address CONNECTED-NETWORKS

router ospf 1
 redistribute connected subnets route-map REDISTRIBUTE-CONNECTED

Keep things simple!

This is more a general recommendation, but we can consider it a best practice. Don’t make things more complex than they actually are. If you have just a few routers, and no plan for huge expansion in the future, put everything in area 0. If you use multiple areas, you will have to deal with inter-area updates, which are different from what you see within an area. In this setup, we could have used a separate area for the router on the right, as it represent a different building. Still, creating a different area for just a router/building does not make sense.

Another CCNP-level feature of OSPF is the virtual link. This allows you to deploy a divided area 0, and connect the parts with logical links. Never do that. Areas should be contiguous, always. Virtual links are a feature you may need when migrating two separate OSPF deployment into a single, bigger one. Even there, if you can avoid the virtual link, avoid it. Using it is your last chance, and only if you know what you are doing.

Wrapping it up

At this point, you have all the skills to create a great and scalable OSPF topology. If you followed the lab and did things right, everything can be reached from any other point. If you are looking for a TL;DR on the commands, here we have a quick table.

What do you think about these practices? Did you use to implement OSPF in this way, or followed a different approach? Let me know your thoughts in the comments!

The post Cisco OSPF Configuration according to best practices appeared first on ICTShore.com.