Posts from ‘IGP’
OSPF Fast Convergence
This goal of this post is breif 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.
Tags: CCDE, ccie, fast convergence, ospf, sub-second convergence, timer tuning
The purpose of event dampening is reducing the effect of oscillations on routing systems. In general, periodic process that affect the routing system as a whole should have the period no shorter than the system convergence time (relaxation time). Otherwise, the system will never stabilize and will be constantly updating its state. In reality, complex system have multiple periodic processes running at the same time, which results is in harmonic process interference and complex process spectrum. Considering such behavior is outside the scope of this paper. What we want to do, is finding optimal settings to filter high-frequency events from the routing system. In our particular case, events are interface flaps, occurring periodically. We want to make sure that oscillations with period T or less are not reported to the routing system. Here T is found empirically, based on observed/estimated convergence time as suggested above.
Event dampening uses exponential back-off algorithm to suppress event reporting to the upper level protocols. Effectively, every time an interface flaps (goes down, to be accurate) a penalty value of P is added to the interface penalty counter. If at some point the accumulated penalty exceeds the “suppress” value of S, the interface is placed in the suppress state and further link events are not reported to the upper protocol modules. At all time, the interface penalty counter follows exponential decay process based on the formula P(t)=P(0)*2^(-t/H) where H is half-life time setting for the process. As soon as accumulated penalty reaches the lower boundary of R – the reuse value, interface is unsuppressed, and further changes are again reported to the upper level protocols.
Tags: bgp, event dampening, exponential backoff, ip event dampening, optimal values
Probably one of the most confusing topics for people studying BGP/MPLS VPNs are EIGRP SoO and Cost communities. Not the concepts themselves, but rather their purpose. Lack of clear documentation makes it hard to understand why and how the specific features are implemented. In this blog post we discuss the BGP Cost community and EIGRP SoO attribute. First, a brief overview of MP-BGP is given along with general concepts of route redistribution in MPLS/BGP VPNs. Next, the problems that arise when using EIGRP in multihomed VPN environment are demonstrated. Lastly, the two specific EIGRP features are described and their use demonstrated. As usual, a reader is assumed to have basic understanding of fundamental L3 VPNs and PE-CE routing concepts. You may download the post in PDF format at the following link: Understanding EIGRP SoO and BGP Cost Community
Tags: bgp cost community, ccie, eigrp soo community, mpls vpn
Overview
In this short blog post we are going to present a simple procedure for IPv4 prefix summarization. The procedure is based on the one found in “Optimal Routing Design” book by Russ White, Don Slice and Alvaro Retana, but differs in some respects. The process is three step, and require the use of Windows calculator for ease of computation. No binary breakdowns are involved, just some basic arithmetic. For the sake of simplicity, we skip all proofs, as those are trivial. The same approach could be adopted for use with IPv6 prefixes, provided that decimal arithmetic is replaced with hexadecimal.
Scenario
We are going to use an example to demonstrate the method. Here is the task: find the optimal (longest prefix length) summary prefix for the following set of subnets:
192.168.100.0/22 192.168.101.0/24 192.168.99.0/24 192.168.102.0/24 192.168.105.0/24 192.168.98.0/23
This example is taken from the wikipedia article: http://en.wikipedia.org/wiki/Supernet that illustrates the use of binary breakdown for the purpose of address summarization.
Continue Reading
In this blog post we are going to discuss some OSPF features related to convergence and scalability. Specifically, we are going to discuss Incremental SPF (iSPF), LSA group pacing, and LSA generation/SPF throttling. Before we begin, let’s define convergence as the process of restoring the stable view of network after a change, and scalability as the property of the routing protocol to remain stable and well-behaving as the network grows. In general, these two properties are reciprocal, i.e. faster convergence generally means less stable and scalable network and vice versa. The reason for that is that faster convergence means that the routing protocol is “more sensitive” to oscillating or “noisy” processes, which in turn makes it less stable.
Incremental SPF
Tags: ccie, incremental spf, ispf, lsa group pacing, lsa throttling, ospf, spf throttling
Every once in a while I come across a tip that is so exciting I want to share it with the world. I was recently going through one of the many posts I read, and saw the answer to a question that I have been wondering about for many years. Awesome job to Steve Shaw who came up with this. Here is the scenario. Continue Reading
Tags: ccie, ccie2.0, cisco, core, eigrp, exam, strategy, troubleshooting
OSPF FA Overview
This post is dedicated to one “esoteric” OSPF external route filtering method based on hiding OSPF Forwarding Address. Recall the meaning of OSPF FA. This is a special field used on OSPF type 5 and 7 LSAs to convey the information of the “external route source”. The purpose of FA is to optimize forwarding in situations where the external route source is connected to a shared segment. Here is an example:
Tags: ccie, ospf fa, ospf filtering, ospf forwarding address
This is the follow up discussion for the post titled, “Have you seen my Router ID?”
The underlying issue here was trying to get OSPF to bypass the usual selection process for Router ID. The normal selection order is:
Manual router ID configured under ospf process
Highest IP address of a loopback in the up state in the respective routing table
Highest IP address of an interface of an up state in the respective routing table
If there are no up interfaces and you have not manually configured a router ID, you will get an error when you try to configure an OSPF process.
In general, most solutions focused around either using the OSPF selection process to one’s advantage, or trying to “hide” the loopback from OSPF, so that it would select something else.
In yesterday’s post, titled “Have you seen my Router ID?”, a challenge section was provided. This post will focus on scrutinizing the section itself, from a strategy / analysis point of view.
From a high level overview, we have two devices peering OSPF over a FastEthernet link, with some loopback networks advertised by one side, and received on the other router. If that was all that the section was asking for, then it should be a task that anyone at CCNA level could complete. When looking at the higher levels of certification, to some point you’re still configuring some of the same items, but you are expected to know more and more about the underlying technologies, theories, and interactions.
Just like other practice lab sections, we are provided with a list of bullet points. In order to get full credit for the section, we need to make sure that we are meeting ALL of the stated requirements. In the event that you don’t know how to complete ALL the items, you are usually better off skipping the section, unless it is needed for core connectivity. When you’re in the studying phase, it’s also a good idea to play “what if”, and ask yourself how you would achieve the task if the section were worded slightly differently.
Make sure that you take the time to read carefully, rather than just diving into a configuration. Make sure that you are carefully taking the time to understand exactly what is being asked.
Taking a look at the individual bullet points:
There is more than one possible solution for this challenge. Feel free to post your proposed answer in the comments section. We will try to keep comments hidden from public view, so that the fun isn’t spoiled for others. Also, don’t feel bad if the answer(s) aren’t immediately apparent. A number of very bright people have been puzzled by this scenario. Answers will be posted on Friday, September 18th.
Scenario:
R1 and R2 are configured with their FastEthernet interfaces on the same subnet. R1 will be forming an OSPF neighbor adjacency to R2 over the FastEthernet interface, and will also be advertising some loopback networks into OSPF.
R1’s Relevant Configuration:
interface Loopback1 ip address 1.1.1.1 255.255.255.255 interface Loopback11 ip address 11.11.11.11 255.255.255.255 interface Loopback111 ip address 111.111.111.111 255.255.255.255 interface FastEthernet0/0 ip address 150.10.12.1 255.255.255.0 no shut
R2’s Relevant Configuration:
interface FastEthernet0/0 ip address 150.10.12.2 255.255.255.0 no shut router ospf 1 network 150.10.12.0 0.0.0.255 area 0
Challenge:
Your task is to configure R1 while meeting all of the following criteria for requirements and restrictions:
- R2 should see the networks 1.1.1.1/32, 11.11.11.11/32, and 111.111.111.111/32 as OSPF routes in R2’s routing table, but they should not appear as IA, E2, or E1.
- The output of “show ip ospf neighbor” on R2 should show 11.11.11.11 as the Neighbor ID for the adjacency to R1, even if R1 is reloaded. No other Neighbor IDs should show up on R2.
- You are not allowed to use the “router-id” command on R1.
- You are not permitted to shut down any interfaces on R1, or remove any of the existing configuration on R1.
- No additional configuration may be added to R2, all configuration for this challenge is done on R1.
Loading ...
