Posts Tagged ‘bgp’
This weekend while working on content updates for CCIE R&S Version 5, I ran into an interesting problem. In order to test some nuances of routing protocol updates and packet fragmentation, I was trying to generate BGP UPDATE messages that would exceed the transit MTU. To do this I manually created a bunch of Loopback interfaces and did a redistribute connected into BGP. When I looked at the packet capture details, I started to realize how many routes I’d actually need in order to fill up the packet sizes. After wasting about 30 minutes copying and pasting new Loopbacks over and over, I decided to come up with a better automated solution instead. I thought, “why not just have the router generate its own random Loopback addresses and then advertise them into BGP?” Well surprisingly I actually got it to work, despite my amateur at best coding skills.
The following TCL script is used to generate a given number of Loopback interfaces with random IPv4 and IPv6 addresses. To use it simply start the tclsh from the IOS CLI, paste the procedure in, then invoke it with generate_loopbacks X, where “X” is the number of routes you want to generate.
Note that I didn’t add any error checking for overlapping addresses or invalid address and mask combinations. If someone wants to update the script to account for this, please feel free to do so and I’ll throw 100 rack rental tokens your way for the trouble. Edit: Special thanks to Jason Cook for adding the error checking for me.
A quick demo of the script in action can be found after the jump.
Five hours of new videos have been added to INE’s CCIE Service Provider Version 3.0 Advanced Technologies Class which cover Multicast VPN and QoS support for Layer 3 MPLS VPNs. Specifically these videos cover Multicast VPN & QoS theory, configuration, verification, and troubleshooting on both regular IOS and IOS XR, including PIM Sparse Mode, PIM Source Specific Multicast, VRF Aware PIM, Multicast Distribution Trees, BGP MDT exchange, and SP QoS Classification, Marking, Scheduling, and Admission Control. For the remainder of the month of February these Multicast videos are free for all users to view. The links can be found below, or from your INE members site download or streaming links for the class.
- Multicast VPN Overview
- Multicast VPN Configuration
- Multicast VPN Verification
- Multicast VPN Optimization
- MPLS QoS Overview
- MPLS QoS Configuration
One of our most anticipated products of the year – INE’s CCIE Service Provider v3.0 Advanced Technologies Class – is now complete! The videos from class are in the final stages of post production and will be available for streaming and download access later this week. Download access can be purchased here for $299. Streaming access is available for All Access Pass subscribers for as low as $65/month! AAP members can additionally upgrade to the download version for $149.
At roughly 40 hours, the CCIE SPv3 ATC covers the newly released CCIE Service Provider version 3 blueprint, which includes the addition of IOS XR hardware. This class includes both technology lectures and hands on configuration, verification, and troubleshooting on both regular IOS and IOS XR. Class topics include Catalyst ME3400 switching, IS-IS, OSPF, BGP, MPLS Layer 3 VPNs (L3VPN), Inter-AS MPLS L3VPNs, IPv6 over MPLS with 6PE and 6VPE, AToM and VPLS based MPLS Layer 2 VPNs (L2VPN), MPLS Traffic Engineering, Service Provider Multicast, and Service Provider QoS.
Below you can see a sample video from the class, which covers IS-IS Route Leaking, and its implementation on IOS XR with the Routing Policy Language (RPL)
The BGP MED attribute, commonly referred to as the BGP metric, provides a means to convey to a neighboring Autonomous System (AS) a preferred entry point into the local AS. BGP MED is a non-transitive optional attribute and thus the receiving AS cannot propagate it across its AS borders. However, the receiving AS may reset the metric value upon receipt, if it so desires.
Previous versions of BGP (v2 and v3) defined this attribute as the inter-AS metric (INTER_AS_METRIC) but in BGPv4 it is defined as the multi-exit discriminator (MULTI_EXIT_DISC). The MED is an unsigned 32bit integer. The MED value can be any from 0 to 4,294,967,295 (2^32-1) with a lower value being preferred. Certain implementations of BGP will treat a path with a MED value of 4,294,967,295 as infinite and hence the path would be deemed unusable so the MED value will be reset to 4,294,967,294. This rewriting of the MED value could lead to inconsistencies, unintended path selections or even churn. I’ll do a follow up article on how BGP MED can possibly cause an endless convergence loop in certain topologies.
This publication briefly covers the use of 3rd party next-hops in OSPF, RIP, EIGRP and BGP routing protocols. Common concepts are introduced and protocol-specific implementations are discussed. Basic understanding of the routing protocol function is required before reading this blog post.
Third-party next-hop concept appears only to distance vector protocol, or in the parts of the link-state protocols that exhibit distance-vector behavior. The idea is that a distance-vector update carries explicit next-hop value, which is used by receiving side, as opposed to the “implicit” next-hop calculated as the sending router’s address – the source address in the IP header carrying the routing update. Such “explicit” next-hop is called “third-party” next-hop IP address, allowing for pointing to a different next-hop, other than advertising router. Intitively, this is only possible if the advertising and receiving router are on a shared segment, but the “shared segment” concept could be generalized and abstracted. Every popular distance-vector protocols support third party next-hop – RIPv2, EIGRP, OSPF and BGP all carry explicit next-hop value. Look at the figure below – it illustrates the situation where two different distance-vector protocols are running on the shared segment, but none of them runs on all routers attached to the segment. The protocols “overlap” at a “pivotal” router and redistribution is used to provide inter-protocol route exchange.
Our BGP class is coming up! This class is for learners who are pursuing the CCIP track, or simply want to really master BGP. I have been working through the slides, examples and demos that we’ll use in class, and it is going to be excellent. If you can’t make the live event, we are recording it, so it will be available as a class on demand, after the live event. More information, can be found by clicking here.
One of the common questions that comes up is “Why does the router choose THAT route?
We all know, (or at least after reading the list below, we will know), that BGP uses the following order, to determine the “best” path.
So now for the question. Take a look at the partial output of the show command below: Continue Reading
Last week we wrapped up the MPLS bootcamp, and it was a blast! A big shout out to all the students who attended, as well as to many of the INE staff who stopped by (you know who you are ). Thank you all.
Here is the topology we used for the class, as we built the network, step by step.
The class was organized and delivered in 30 specific lessons. Here is the “overview” slide from class: Continue Reading
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.
In this series of posts, we are going to review some interesting topics illustrating unexpected behavior of the BGP routing protocol. It may seem that BGP is a robust and stable protocol, however the way it was designed inherently presents some anomalies in optimal route selection. The main reason for this is the fact that BGP is a path-vector protocol, much like a distance-vector protocol with optimal route selection based on policies, rather than simple additive metrics.
The fact that BGP is mainly used for Inter-AS routing results in different routing policies used inside every AS. When those different policies come to interact, the resulting behavior might not be the same as expected by individual policy developers. For example, prepending the AS_PATH attribute may not result in proper global path manipulation if an upstream AS performs additional prepending.
In addition to that, BGP was designed for inter-AS loop detection based on the AS_PATH attribute and therefore cannot detect intra-AS routing loops. Optimally, intra-AS routing loops could be prevented by ensuring a full mesh of BGP peering between all routers in the AS. However, implementing full-mesh is not possible for a large number of BGP routers. Known solutions to this problem – Route Reflectors and BGP Confederations – prevent all BGP speakers from having full information on all potential AS exit points due to the best-path selection process. This unavoidable loss of additional information may result in suboptimal routing or routing loops, as illustrated below.
Inter-AS Multicast VPN solution introduces some challenges in cases where peering systems implement BGP-free core. This post illustrates a known solution to this problem, implemented in Cisco IOS software. The solution involves the use of special MP-BGP and PIM extensions. The reader is assumed to have understanding of basic Cisco’s mVPN implementation, PIM-protocol and Multi-Protocol BGP extensions.
mVPN – Multicast VPN
MSDP – Multicast Source Discovery Protocol
PE – Provider Edge
CE – Customer Edge
RPF – Reverse Path Forwarding
MP-BGP – Multi-Protocol BGP
PIM – Protocol Independent Multicast
PIM SM – PIM Sparse Mode
PIM SSM – PIM Source Specific Multicast
LDP – Label Distribution Protocol
MDT – Multicast Distribution Tree
P-PIM – Provider Facing PIM Instance
C-PIM – Customer Facing PIM Instance
NLRI – Network Layer Rechability Information