Configuring OSPF on Cisco IOS is done the following way. To start OSPFv2 which is for IPv4, we do 'router ospf' and then a process ID. The process ID can be any number. That number is unique to the router it's not shared with other neighbors. To start OSPFv3, which is for IPv6 only, we do 'ipv6 router ospf' and then again the process ID. Some network operators will configure the process ID to be the same as the BGP Autonomous System Number, but indeed any number will do. To add interfaces in OSPF we need to look at how we configure OSPF defaults. We start the OSPF process and we mark all interfaces as ' passive' by default. This will prevent OSPF from automatically trying to find a neighbor on every single interface. The ISP best practice is to then, activate OSPF on specific interfaces we want to find adjacencies. The last thing we want to do is establish OSPF with an external peer or upstream provider or worse with one of our customers. Now in Cisco IOS enabling OSPF on an interface does two things. First off, it enables the Hello protocol to form neighbor relationships and adjacencies with other routers connected to that interface. And it also announces the interface subnet into OSPF. We need to be careful, we really have to avoid enabling Hello protocol on untrusted networks. In other words those outside of your Autonomous System. This is industry best practice but it's a frequent error made by many network operators. and in many cases on public infrastructure we see network operators leaking the internal OSPF, or even trying to find OSPF adjacencies with other infrastructure outside of their network. The I in IGP means interior and it's really important to remember this in the case of deploying OSPF. Forming neighbor relationships is done by starting the router OSPF process, setting the process ID, marking all interfaces as 'passive', doing 'no passive' for the interface we want to find the adjacency on, and then going to the interface and activating OSPF on it by using the using the 'ip ospf' process ID command and specifying which area the interface will sit in. This is the modern configuration syntax. On much older versions of IOS, Cisco used to configure OSPF by running on the subnet. We don't do this anymore, we run OSPF on the actual physical interface. For OSPFv3 the CLI is exactly the same as the slide shows. This time we're just using 'ipv6 router ospf' and to activate on the interface we do 'ipv6 ospf' and the process ID and then specifying which area the interface should be sitting on Cisco IOS sets the interface cost automatically. Unlike other interior protocols, the cost is calculated based on the interface bandwidth. The formula IOS uses is: 100,000,000/interface bandwidth in bits per second. So this is fine for interfaces up to 100Mbps, which was perfect when OSPF was developed in the early 90s. The fastest interface back then, was FDDI with 100Mbps. But nowadays we see 100 Gigabit Ethernet, 400 Gigabit Ethernet being developed, this automatic cost generation really does not make any sense. And in fact many operators today, now develop their own interface cost strategy as they do for interior protocols like IS-IS. To do that it's a simple interface command 'ip ospf cost' and a value which will set the metric on that interface to be this value. Care is needed to make sure that the sum of cost ensures the best path through the network. OSPF chooses the lowest cost path through the network, and will load balance over paths with equal cost to the same destination. In this example, we see two paths between the user and the content they are viewing. One path has a cost of 70, the other path has a cost of 60 and OSPF will choose the lowest cost path, 60. The other example, we have equal cost paths, both of them are 70. So the routers will load balance over the two paths between the content and the end-user who is viewing it. Even though from the user's perspective, one upstream link is 10Mbps and the other upstream link is 2Mbps.
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.