Posts from ‘IP Routing – NA Level’
One of the most important technical protocols on the planet is Open Shortest Path First (OSPF). This highly tunable and very scalable Interior Gateway Protocol (IGP) was designed as the replacement technology for the very problematic Routing Information Protocol (RIP). As such, it has become the IGP chosen by many corporate enterprises.
OSPF’s design, operation, implementation and maintenance can be extremely complex. The 3-Day INE bootcamp dedicated to this protocol will be the most in-depth coverage in the history of INE videos.
This course will be developed by Brian McGahan, and Petr Lapukhov. It will be delivered online in a Self-Paced format. The course will be available for purchase soon for $295.
Here is a preliminary outline:
Day 1 OSPF Operations
● Dijkstra Algorithm
● Neighbors and Adjacencies
○ OSPF Packet Formats
○ OSPF Authentication
○ Link-State information Flooding
About the Protocol
- The algorithm used for this advanced Distance Vector protocol is the Diffusing Update Algorithm.
- As we discussed at length in this post, the metric is based upon Bandwidth and Delay values.
- For updates, EIGRP uses Update and Query packets that are sent to a multicast address.
- Split horizon and DUAL form the basis of loop prevention for EIGRP.
- EIGRP is a classless routing protocol that is capable of Variable Length Subnet Masking.
- Automatic summarization is on by default, but summarization and filtering can be accomplished anywhere inside the network.
EIGRP forms “neighbor relationships” as a key part of its operation. Hello packets are used to help maintain the relationship. A hold time dictates the assumption that a neighbor is no longer accessible and causes the removal of topology information learned from that neighbor. This hold timer value is reset when any packet is received from the neighbor, not just a Hello packet.
To start my reading from Petr’s excellent CCDE reading list for his upcoming LIVE and ONLINE CCDE Bootcamps, I decided to start with:
EIGRP for IP: Basic Operation and Configuration by Russ White and Alvaro Retana
I was able to grab an Amazon Kindle version for about $9, and EIGRP has always been one of my favorite protocols.
The text dives right in to none other than the composite metric of EIGRP and it brought a smile to my face as I thought about all of the misconceptions I had regarding this topic from early on in my Cisco studies. Let us review some key points regarding this metric and hopefully put some of your own misconceptions to rest.
- While we are taught since CCNA days that the EIGRP metric consists of 5 possible components – BW, Delay, Load, Reliability, and MTU; we realize when we look at the actual formula for the metric computation, MTU is actually not part of the metric. Why have we been taught this then? Cisco indicates that MTU is used as a tie-breaker in a situation that might require it. To review the actual formula that is used to compute the metric, click here.
- Notice from the formula that the K (constant values) impact which components of the metric are actually considered. By default K1 is set to 1 and K3 is set to 1 to ensure that Bandwidth and Delay are utilized in the calculation. If you wanted to make Bandwidth twice as significant in the calculation, you could set K1 to 2, as an example. The metric weights command is used for this manipulation. Note that it starts with a TOS parameter that should always be set to 0. Cisco never did fully implement this functionality.
- The Bandwidth that effects the metric is taken from the bandwidth command used in interface configuration mode. Obviously, if you do not provide this value – the Cisco router will select a default based on the interface type.
- The Delay value that effects the metric is taken from the delay command used in interface configuration mode. This value depends on the interface hardware type, e.g. it is lower for Ethernet but higher for Serial interfaces. Note how the Delay parameter allows you to influence EIGRP pathing decisions without the manipulation of the Bandwidth value. This is nice since other mechanisms could be relying heavily on the bandwidth setting, e.g. EIGRP bandwidth pacing or absolute QoS reservation values for CBWFQ.
- The actual metric value for a prefix is derived from the SUM of the delay values in the path, and the LOWEST bandwidth value along the path. This is yet another reason to use more predictive Delay manipulations to change EIGRP path preference.
In the next post on the EIGRP metric, we will examine this at the actual command line, and discuss EIGRP load balancing options. Thanks for reading!
CCNA students can typically rattle off the fact that EIGRP uses Bandwidth and Delay in its composite metric calculation by default. In fact, they tend to know this as well as their own last name. But I often notice they might have some pretty big misconceptions about how this metric is really calculated, and how they can manipulate it.
Here are some very important “Core Knowledge” facts that we need to keep in mind about the EIGRP metric: Continue Reading
As a former English Major at the University of Massachusetts, Amherst, I really loved the oxymoron. You remember those…”sharply dull” or “cruel kindness”. Well, the OSPF protocol has one whopper of an oxymoron in its special areas – The Totally, Not-So-Stubby area!
When we last left our Area 11 in Part 4 of this blog series, it was a Not-So-Stubby Area, with the default-information-originate command used on the Area Border Router (ABR) in order to ensure a default route existed in the area. Here is the topology, and a look at the existing routing table on R3:
R3#show ip route Gateway of last resort is 192.168.1.2 to network 0.0.0.0 18.104.22.168/24 is subnetted, 1 subnets C 22.214.171.124 is directly connected, Loopback33 172.16.0.0/24 is subnetted, 1 subnets O IA 172.16.10.0 [110/21] via 192.168.1.2, 00:00:14, FastEthernet0/0 10.0.0.0/24 is subnetted, 1 subnets O IA 10.10.10.0 [110/20] via 192.168.1.2, 00:00:14, FastEthernet0/0 C 192.168.1.0/24 is directly connected, FastEthernet0/0 126.96.36.199/24 is subnetted, 1 subnets C 188.8.131.52 is directly connected, Loopback44 O*N2 0.0.0.0/0 [110/1] via 192.168.1.2, 00:00:09, FastEthernet0/0 R3#
Now it is time for us to examine yet another OSPF special area type – the Not-So-Stubby Area. I am sure you recall out topology from the previous parts, but here it is again:
In this part of our blog series on OSPF area types, our Area 11 is going to undergo a major flashback! The area is going to be reintroduced to an early 1980′s American stereotype called Valley Girls and their Valspeak. The area is no longer going to be Stubby, but it is going to be like. . .like Totally Stubby! Lets review how we left Area 11 and how things looked when it was just a Stub area:
Welcome back to our series on OSPF areas. Click here for Part 1 of the series. It is time to focus on normal areas and stub areas in this post. Recall our topology:
Thanks to one of our brilliant CCIE R/S Written students, Nish, for his request of this series of INE blog posts. Nish is still struggling a bit with the different OSPF area types and how exactly they impact Link State Advertisements (LSAs). In this series, we will tackle each of the different OSPF areas in great detail, confirming our Level 1 knowledge at the command line as we progress.
Here is the network we will use in this first post. Notice this simple network can be constructed easily in Dynamips, or with three pretty basic Cisco routers capable of OSPF version 2.