Fundamentals of Border Gateway Protocol (BGP) - Part 3

ccie r/s ccna r/s ccnp r/s Apr 08, 2019

This post is the 3rd in a series of Border Gateway Protocol (BGP) posts. If you missed either of the first two, here are the links:

Now, in this post, you'll learn about how BGP neighborships are formed, within an autonomous system, between autonomous systems, and even between routers that are not directly connected. Also, we'll check out BGP authentication.

eBGP Peerings

Given that BGP is an AS-to-AS routing protocol, it would make good sense that external BGP (i.e. eBGP) is a key ingredient in its operations. The very first thing that we need to keep in mind with eBGP is that the standards are built so that there is a requirement for a direct connection. This is something that we can work around (of course), but this point is worth consideration. Because a direct connection is assumed, the BGP protocol does two things:

  • It's going to check for a time-to-live (TTL) value, and that the...
Continue Reading...

Fundamentals of Border Gateway Protocol (BGP) - Part 2

ccie r/s ccna r/s ccnp r/s Mar 12, 2019

Part 1 of our blog series on Border Gateway Protocol (BGP) gave you an overview of  BGP and then delved into BGP message types and neighbor states. Now, in this post, you'll learn about one of the most challenging aspects of BGP, how it makes its path selection decision. While routing protocols such as RIP, OSPF, and EIGRP each have their own metrics used to pick the "best" path to a destination network, BGP uses a collection of path attributes (PAs).

BGP Path Attributes

When your BGP speaker receives a BGP prefix, there are going to be many path attributes tagged to it, and we know that these are going to be critical when it comes to BGP doing things like choosing a very best path to a destination. Interestingly, not all of these path attributes are created equal.

All BGP path attributes fall into one of four main categories. Note that this list also provides example attributes in each category. Do not be too concerned with these specific attribute values now, as you will...

Continue Reading...

Fundamentals of Border Gateway Protocol (BGP) - Part 1

ccie r/s ccna r/s ccnp r/s Jan 29, 2019

One of the most intimidating topics for Cisco certification candidates in the Route/Switch track is Border Gateway Protocol (BGP). To help remove the FUD (Fear, Uncertainty, and Doubt) surrounding BGP, I'll be sharing a series of blog posts with you to help demystify this routing protocol. In this first post of the series, you'll be introduced to the very basics of BGP and learn about its various message types and states.

An Overview of BGP

Let’s face it - Border Gateway Protocol is just incredibly unique, especially when we compare it to other routing protocols. The very first thing that makes BGP so unique, is what it does for us. It is our only Exterior Gateway Protocol (EGP) in major use today. We know we have our Interior Gateway Protocols (IGPs), and that would be like OSPF running inside of an autonomous system. But BGP is an EGP, which means that it is (usually) going to take prefixes that are inside an autonomous system and send those to other autonomous systems....

Continue Reading...

Route Redistribution- Part 4

ccie r/s ccnp r/s Nov 29, 2018

This post is the fourth in a series of posts on route redistribution. If you haven't yet read the first three, here are the links:

Up until now in this series, we’ve seen the need for route redistribution, looked at a basic configuration, saw how we could filter specific routes from being redistributed, and learned how to prevent a routing loop by tagging redistributed routes. In this final route redistribution post, we want to check out route redistribution with IPv6, and how that configuration varies a bit from what we’ve done previously with IPv4 networks.

Consideration #1 - The Redistribution of Connected Networks

First, consider a router running a routing protocol; let’s say it’s OSPF in this instance. Also, let’s say that router has several interfaces that are participating in the OSPF routing protocol. On that same router, imagine we’re running...

Continue Reading...

Route Redistribution- Part 3

ccie r/s ccnp r/s Nov 06, 2018


This post is the third in a series of posts on Route Redistribution. If you didn’t yet read the first two, here are the links:

So far in this series, the route redistribution examples we’ve worked through used a single router to do all of the redistribution between our autonomous systems. However, from a design perspective, we might look at that one router and realize that it's potential single point of failure.

For redundancy, let’s think about adding a second router to redistribute between a couple of autonomous systems. What we probably don’t want is for a route to be advertised from, let’s say, AS1 into AS2, and then have AS2 advertise that same route back into AS1, as shown in the figure. 

The good news is, with default settings, that probably won’t be an issue. For example, in the above graphic, router BB2 would learn two ways to get to Network A. One way would...

Continue Reading...

Route Redistribution- Part 2

ccie r/s ccnp r/s Oct 30, 2018

In a previous post, we considered the need for route redistribution, and we also took a look at some configuration examples. This posts builds on that previous configuration and discusses how we can filter routes using route maps.

Specifically, the previous example performed mutual route redistribution between EIGRP and OSPF, where all routes were redistributed between the two autonomous systems. However, some design scenarios might want us to prevent the redistribution of every single route. One way to do that filtering is to use a route map.

For your reference, here’s the topology we’re working with:

Screen Shot 2018-09-14 at 1.14.46 PM.png

Also, with our current route redistribution configuration, the IP routing table on router R1 looks like this:

Let’s say, for some reason, we don’t want the /24 network redistributed from EIGRP into OSPF. One way to do that filtering is to use a route map that references an access control list (ACL).

First, let’s go to router R2 and...

Continue Reading...

Route Redistribution - Part 1

ccie r/s ccnp r/s Sep 25, 2018

Introduction to Route Redistribution 

Until there is one routing protocol to rule them all, there is a need to have multiple routing protocols peacefully coexist on the same network. Perhaps Company A runs OSPF, and Company B runs EIGRP, and the two companies merge. Until the newly combined IT staff agrees on a standard routing protocol to use (if they ever do), routes known to OSPF need to be advertised into the portion of the network running EIGRP, and vice versa.

Such a scenario is possible thanks to route redistribution, and that’s the focus of this blog post. Other reasons you might need to perform route redistribution include: different parts of your own company’s network are under different administrative control; you want to advertise routes to your service provider via BGP; or perhaps you want to connect with the network of a business partner. Consider the following basic topology.


In the simple topology show above, we’re wanting OSPF and...

Continue Reading...

Interview with Anthony Sequeira

In this post, I'm excited to share with you my latest podcast episode, where I'm interviewing my good friend and world-renowned Cisco trainer Anthony Sequeira.

In this episode, Anthony discusses:

  • Tips for the Troubleshooting Section of the CCIE R/S Lab
  • Amazon Web Services (AWS)
  • Anthony's New CCIE R&S Prep Club
  • What Anthony has Learned from Tony Robbins
  • What Anthony is Working on Now
  • And More...


Also, you can check out some of Anthony's resources below:

Finally, if you're not yet subscribed to my podcast, The Broadcast Storm, you can listen on iTunes or Spotify:

Happy listening!

Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945

Continue Reading...

Save Time in Your CCIE Lab with "Router Preconfigs"

On any CCIE lab, time is your most precious commodity. Opinions vary about the best time saving strategies. Some people would have you spend the first 30 minutes of your lab carefully reading through the lab tasks you’ve been given. However, I’m in the group of people that suggests doing a much quicker read-through, noting important features that are going to need configuring, with the belief that you’ll not remember enough detail to justify spending half an hour reading the tasks.

For years, I’ve been promoting my modified device-based approach for tackling the CCIE Collaboration lab, where I have you make a set of boxes on your scratch paper, one box for each device in your topology. Then, as you do your initial read-through, you put task numbers in boxes representing the device on which the task needs to be configured. Then, you can visit each device a minimal amount of times to meet all your lab requirements. If you want to watch a video I did...

Continue Reading...

Fundamentals of QoS


Last week (on Cyber Monday), I did a webinar covering the theory and configuration of multiple QoS mechanisms. Here's what you'll learn in this replay of that webinar:

  • Learn QoS Mechanisms
  • Understand QoS Markings
  • Demystify Weighted RED
  • Select Appropriate Queuing
  • Explain the "Token Bucket"
  • Configure QoS Using MQC

Enjoy the webinar replay!

Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945

Continue Reading...
1 2 3 4

50% Complete

Two Step

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.