Posts from ‘BGP’
Riddle me this BGP man…
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 4.4.4.4 for network 5.5.5.5 (R5 loopback). R4, at 4.4.4.4 is an iBGP neighbor.
R2#show ip route vrf v | inc 5.5.5.0 B 5.5.5.0 [200/409600] via 4.4.4.4, 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 5.5.5.0 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 1.1.1.1 and 3.3.3.3 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) Continue Reading
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
Introduction
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.
Tags: anomalies, bgp, ccie, CCNP, routing loops
In this post, we are going to continue troubleshooting with the Trouble Ticket from Part 1 of this series. If you want to check out Part 1, just click here.
When we finished last time, we had discovered and corrected an issue with the attempt at prefix aggregation on Transylvania.
Tags: ccie, practice, strategy, troubleshooting
Things sure can get spooky in the Troubleshooting section of the new Version 4 Blueprint! Cisco can present a pretty vague issue; give you a very lame diagram; and then really press you for time to solve the Trouble Ticket. In this blog post, I will walk you through this graveyard and attempt to provide some ideas on an efficient and effective approach. For much more detail and practice, our premier products for this exam section are the Volume 4 workbook (currently being edited and improved upon), and the brand new 5-Day Troubleshooting Bootcamp.
Are you ready to find prefixes that go bump in the night? Here is the sample Trouble Ticket we will attack, and the appropriate portion of the Cisco diagram. You will want to have some scratch paper handy (just like in the actual exam). Diagramming can prove to be more important here then in any exam section. You should practice a diagram now based on the show output that follows.
Tags: ccie, practice, strategy, troubleshooting
Hi Everyone,
we’ve just posted the remaining labs in the BGP sections and the content should be available to all subscribed accounts. There are now 61 feature-focused labs in total, listed below. From now on, we will focus on the new blueprint topics for CCIE R&S track, as outlined in New CCIE R&S Reload. The updates for VOL1 and VOL2 will go in parallel. Anyone preparing to the new lab according to the new blueprint could safely use the current labs for their practice and practice the new material as it being posted.
Happy studying!
The list of BGP topics follows:
Establishing iBGP Peerings
Establishing EBGP Peerings
BGP Update Source Modification
Multihop EBGP Peerings
Neighbor Disable-Connected-Check
Authenticating BGP Peerings
iBGP Route Reflection
Large Scale iBGP Route Reflection with Clusters
iBGP Confederation
BGP Next-Hop Processing – Next-Hop-Self
BGP Next-Hop Processing – Manual Modification
iBGP Synchronization
BGP over GRE
BGP Redistribute Internal
BGP Peer Groups
BGP Network Statement
BGP Auto-Summary
BGP Bestpath Selection – Weight
BGP Bestpath Selection – Local Preference
BGP Bestpath Selection – AS-Path Prepending
BGP Bestpath Selection – Origin
BGP Bestpath Selection – MED
BGP Bestpath Selection – Always Compare MED
BGP Bestpath Selection – AS-Path Ignore
BGP Bestpath Selection – Router-IDs
BGP Bestpath Selection – DMZ Link Bandwidth
BGP Bestpath Selection – Maximum AS Limit
BGP Backdoor
BGP Aggregation
BGP Aggregation – Summary Only
BGP Aggregation – Suppress Map
BGP Aggregation – Unsuppress Map
BGP Aggregation – AS-Set
BGP Aggregation – Attribute-Map
BGP Aggregation – Advertise Map
Continue Reading
Loading ...
