Posts from ‘IP Routing’
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.
This goal of this post is brief discussion of main factors controlling fast convergence in OSPF-based networks. Network convergence is a term that is sometimes used under various interpretations. Before we discuss the optimization procedures for OSPF, we define network convergence as the process of synchronizing network forwarding tables after a topology change. Network is said to be converged when none of forwarding tables are changing for “some reasonable” amount of time. This “some” amount of time could be defined as some interval, based on the expected maximum time to stabilize after a single topology change. Network convergence based on native IGP mechanisms is also known as network restoration, since it heals the lost connections. Network mechanisms for traffic protection such as ECMP, MPLS FRR or IP FRR offering different approach to failure handling are outside the scope of this article. We are further taking multicast routing fast recovery out of the scope as well, even though this process is tied to IGP re-convergence.
It is interesting to notice that IGP-based “restoration” techniques have one (more or less) important problem. During the time of re-convergence, temporary micro-loops may exist in the topology due to inconsistency of FIB (forwarding) tables of different routers. This behavior is fundamental to link-state algorithms, as routers closer to failure tend to update their forwarding database before the other routers. The only popular routing protocol that lacks this property is EIGRP, which is loop-free at any moment during re-convergence, thanks to the explicit termination of the diffusing computations. For the link state-protocols, there are some enhancements to the FIB update procedures that allow avoiding such micro-loops with link-state routing, described in the document [ORDERED-FIB].
Even though we are mainly concerned with OSPF, ISIS will be mentioned in the discussion as well. It should be noted that compared to IS-IS, OSPF provides less “knobs” for convergence optimization. The main reason is probably the fact that ISIS is being developed and supported by a separate team of developers, more geared towards the ISPs where fast convergence is a critical competitive factor. The common optimization principles, however, are the same for both protocols, and during the conversation will point out at the features that OSPF lacks while IS-IS has for tuning. Finally, we start our discussion with a formula, which is further explained in the text:
Convergence = Failure_Detection_Time + Event_Propagation_Time + SPF_Run_Time + RIB_FIB_Update_Time
The formula reflects the fact that convergence time for a link-state protocol is sum of the following components:
- Time to detect the network failure, e.g. interface down condition.
- Time to propagate the event, i.e. flood the LSA across the topology.
- Time to perform SPF calculations on all routers upon reception of the new information.
- Time to update the forwarding tables for all routers in the area.
It isn’t my fault, they configured it that way before I got here! That was the entry level technician’s story Monday morning, and he was sticking to it.
Here is the rest of the story. Over the weekend, some testing had been done regarding a proposed BGP configuration. The objective was simple, R1 and R3 needed to ping each others loobacks at 22.214.171.124 and 126.96.36.199 respectively, with those 2 networks, being carried by BGP. R2 is performing NAT. The topology diagram looks like this:
The ping between loopbacks didn’t work, but R1 and R3 had these console messages:
R1# %TCP-6-BADAUTH: No MD5 digest from 10.0.0.3(179) to 10.0.0.1(28556) (RST)
Having a blast in Chicago with the RS bootcamp students. Thanks for all the hard work you are doing this week!
A student from a past Reno class, named Michal, asked if I would create a blog post regarding BGP proportional load balancing based on the bandwidth of the links to EBGP peers. It has been on my list of things to do, and here it is. Thanks for the request Michal.
The secret to this trick is to pay attention to the links between directly connected external BGP neighbors, (in this case between R6-R5 and R2-R3), and send the link bandwidth extended community attribute to iBGP peer R1. It is enabled by entering the bgp dmzlink-bw command and using extended communities to share the information. To summarize: routes learned from directly connected external neighbor are advertised to IBGP peers including the bandwidth of the external link where the routes were learned, and then the IBGP router (R1) can proportionally load balance between the two paths.
Here is the diagram we will use.
We’ll use loobpacks for our IBGP connections, so let’s verify that we have connectivity between loopbacks in AS 123. Continue Reading
If you are interested in Part 1 of this blog series – click here.
Question 2 of 105
Given the topology and configurations shown in the exhibits. Which devices will receive EIGRP Query packets if R1 loses its route information for the 10.10.10.0/24 prefix?
a) None of the devices
b) R2, R3, R4, R5, R6, R7
c) R2, R3, R6, R7
d) R2, R3, R4, R5
e) R2, R3
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 188.8.131.52/24 is subnetted, 1 subnets C 184.108.40.206 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 220.127.116.11/24 is subnetted, 1 subnets C 18.104.22.168 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: