Posts from ‘BGP’
In our R&S CCIE Mock Lab 2 there is a BGP task that relates to having a particular router prefer an iBGP route as the preferred path to exit its local AS over an eBGP learned path. This seems like a very simple task and it is if you are very thorough with your verification but it ends up being the most commonly missed task in this particular mock lab. Lets start by going over the task and the solution most commonly implemented by students.
In the lab R1, R2 and SW2 are in AS 300. R1 and R2 each have an eBGP peering session with R3. The task states that AS 300 should use the T1 link between R1 and R3 to reach paths originating in AS 54 (BB3). R3 (sub-AS 65003) appears as AS 100 but is actually in a confederation with R4 (sub-AS 65004) and R5 (sub-AS 65005). This doesn’t have any bearing on the task but needs to be mentioned for clarification when looking at the diagram and the output of the show commands. Below is the full task and the diagram (click the image to enlarge).
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.
BGP (see ) is the de-facto protocol used for Inter-AS connectivity nowadays. Even though it is commonly accepted that BGP protocol design is far from being ideal and there have been attempts to develop a better replacement for BGP, none of them has been successful. To further add to BGP’s widespread adoption, MP-BGP extension allows BGP transporting almost any kind of control-plane information, e.g. to providing auto-discovery functions or control-plane interworking for MPLS/BGP VPNs. However, despite BGP’s success, the problems with the protocol design did not disappear. One of them is slow convergence, which is a serious limiting factor for many modern applications. In this publication, we are going to discuss some techniques that could be used to improve BGP convergence for Intra-AS deployments.
BGP-Only Convergence Process
Tuning BGP Transport
BGP Fast Peering Session Deactivation
BGP and IGP Interaction
BGP PIC and Multiple-Path Propagation
Practical Scenario: BGP PIC + BGP NHT
Considerations for Implementing BGP PIC
Appendix: Practical Scenario Baseline Configuration
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
Can you solve this puzzle?
R2, R3 and R4 create the service provider network, with MPLS on all three routers, and iBGP at the PE routers. R1 and R5 are the CE routers.
R2, prefers the BGP next hop of 126.96.36.199 for network 188.8.131.52 (R5 loopback). R4, at 184.108.40.206 is an iBGP neighbor.
R2#show ip route vrf v | inc 220.127.116.11 B 18.104.22.168 [200/409600] via 22.214.171.124, 00:06:47
Is R2 preferring an iBGP learned route, which has an AD of 200, over a EIGRP route, which would have an AD of 90?
Can you identify why the routing for 126.96.36.199 on the VRF of R2 is using BGP instead of EIGRP?
Below are the relevant portions of the configuration, which also can serve as a great review of how to configure MPLS VPNs. Continue Reading
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 188.8.131.52 and 184.108.40.206 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)
One of our students in the INE RS bootcamp today, asked about an OSPF sham-link. I thought it would make a beneficial addition to our blog, and here it is. Thanks for the request Christian!
Reader’s Digest version: MPLS networks aren’t free. If a customers is using OSPF to peer between the CE and PE routers, and also has an OSPF CE to CE neighborship, the CE’s will prefer the Intra-Area CE to CE routes (sometimes called the “backdoor” route in this situation), instead of using the Inter-Area CE to PE learned routes that use the MPLS network as a transit path. OSPF sham-links correct this behavior.
This blog post walks through the problem and the solution, including the configuration steps to create and verify a sham-link.
To begin, MPLS is set up in the network as shown with R2 and R4 acting as Provider Edge (PE) routers, and MPLS is enabled throughout R2-R3-R4.
R1 and R5 are Customer Edge (CE) routers, and the Serial0/1.15 interfaces of R1 and R5 are temporarily shut down, (this means the backdoor route isn’t in place yet, and at the moment, there is no problem).
Currently, R1 and R5 see the routes to each others local networks through the VPNv4 MPLS network, and the routes show up as Inter-Area OSPF routes with the PE routers as the next hop. Continue Reading
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
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.