BGP - Troubleshooting Lab 2

Objective

• R3 and R4 must have 5.5.5.5/32 and 6.6.6.6/32 in their BGP/routing table. 

Sounds simple..? Well how about you figure it out then :) .. Here is the topology. 

Restrictions

• Static routes should not be added anywhere!! In other words, get BGP to work properly. 

You should be able to figure out the issues with the following show commands below.  

BGP - Troubleshooting Lab

In this blogtorial, I will be posting configs of the routers and a few commands. Please leave me comments on what you think the issue maybe.

Consider this topology below. 

Objective: 

• 11.11.11.11/32 should be pingable from R4. 
• Static routes or artificial routes cannot be installed anywhere!! 

Hint -- There are three issues.

The entire config can be downloaded here so you can lab it up in GNS3.

BGP - inject-map - Conditional Route Injection

In my recently published posts we discussed how to aggregate addresses in BGP and the various optional parameters associated with the "aggregate-address" command. However, there could be instances where we may want to do just the opposite -- un-aggregate the addresses. In this blogtorial we will see how we can achieve this. Consider a very simple topology below and we'll dive right in.

BGP - aggregate-address suppress-map

In my previous blogtorial we utilized the aggregate-address command to summarize routes in BGP. In this blogtorial we will take a look at one of the optional parameters we can use with the aggregate-address command to manipulate routes. As you noticed the "aggregate-address <network> <netmask>" command actually advertised the aggregate route and the more specific routes.

 R2(config-router)#aggregate-address 11.11.11.0 255.255.255.0 ?  
  advertise-map Set condition to advertise attribute  
  as-set     Generate AS set path information  

  attribute-map Set attributes of aggregate  
  nlri      Nlri aggregate applies to  
  route-map   Set parameters of aggregate  
  summary-only  Filter more specific routes from updates  
  suppress-map  Conditionally filter more specific routes from updates  
  <cr>  

You could presumably use summary-only to filter all the more specific routes, however what if you wanted to suppress only a selected few of the more specific routes and advertise the rest of the specific routes along with the aggregate? This is where "suppress-map" or "advertise-map" comes to the rescue  If you only had a few specific routes to advertise but a lot of specific routes to suppress out of an aggregate then you would use the "advertise-map" to advertise just what you want. However, if you only had a few specific routes to suppress but more specific prefixes to advertise then you would use a "suppress-map" to suppress what you want and advertise the rest. See below for "suppress-map" in action.

BGP - aggregate-address as-set

In my previous blogtorial we utilized the aggregate-address command to summarize routes in BGP. In this blogtorial we will take a look at one of the optional parameters we can use with the aggregate-address command to manipulate routes.

 R2(config-router)#aggregate-address 11.11.11.0 255.255.255.0 ?  
  advertise-map Set condition to advertise attribute  
  as-set     Generate AS set path information  
  attribute-map Set attributes of aggregate  
  nlri      Nlri aggregate applies to  
  route-map   Set parameters of aggregate  
  summary-only  Filter more specific routes from updates  
  suppress-map  Conditionally filter more specific routes from updates  
  <cr>  

The optional parameter we will look at in this blogtorial is the as-set option. In my previous post we talked about "atomic-aggregate" and how the aggregate routes clears the AS_PATH information along with other attributes of the route such as no-export community. For example, let's take a look at the R3.

BGP - aggregate-address summary-only

In my previous blogtorial we utilized the aggregate-address command to summarize routes in BGP. In this blogtorial we will take a look at one of the optional parameters we can use with the aggregate-address command to manipulate routes.

 R2(config-router)#aggregate-address 11.11.11.0 255.255.255.0 ?  
  advertise-map Set condition to advertise attribute  
  as-set     Generate AS set path information  
  attribute-map Set attributes of aggregate  
  nlri      Nlri aggregate applies to  
  route-map   Set parameters of aggregate  
  summary-only  Filter more specific routes from updates  
  suppress-map  Conditionally filter more specific routes from updates  
  <cr>  




The optional parameter we will look at in this blogtorial is the summary-only option. In my previous post we saw that the aggregate-address command advertised the aggregate route along with the more specific prefixes. What if we wanted to suppress those more specific prefixes and advertise only the summary? summary-only command suppresses all of the more specific prefixes and advertises only the aggregate route to the neighbors.

BGP - Aggregation - aggregate-address

BGP Routing table of the Internet is enormous and its over 400K routes which puts a considerable amount of stress on the edge devices anytime there is a flap or a change in routing topology. Although there are mechanism in place to minimize the impact it is still in our best interest to keep the BGP routing table as small as possible. "aggregate-address" command is one of the ways in which we can combat the issues created by large BGP tables.

In this blogtorial we will look at the "aggregate-address" command and its options (in subsequent posts) to see how we can aggregate routes in BGP. Consider this simple 3 router topology. 

Complete configs can be downloaded here.

BGP Conditional Advertisements - IF Statements in BGP

I was chatting with a colleague of mine and I stated "I wish we could remember everything we read..." and he responded "If we could remember everything, then we wouldn't need to 'write it down' - thus depriving others of the opportunity to learn from our experience." - Mike O. Very well said Mike!! So back to my blogtorial -- How to do "if statements" with BGP? Or better known as "BGP Conditional Route Advertisement". The scenario is described in the topology below.

There are two different scenarios we will take a look at in this blogtorial.

• If 5.5.5.0/25 exists in the BGP table then advertise the aggregate address 5.5.5.0/24 to both ISPs. 
• or the opposite: only If 5.5.5.0/25 does not exist in the BGP table then advertise the aggregate address 5.5.5.0/24 to both ISPs.

Complete configs can be downloaded here.

Understanding IP Fragmentation

Can you imagine eating a whole steak in one bite? Probably not. You have to cut it in pieces and take it little at a time. How about a big project? You can't successfully complete it unless you split it up into multiple little projects and have deadlines for each one. Same goes for TCP segments. When Layer 4 TCP sends a big segment the Network Layer (Layer 3) Fra - gme - nts (fragments) the segments into smaller packets dictated by the MTU (Maximum Transmission Unit) of the outgoing interface. This brings up an interesting issue, how does the receiver know that the packets being received are a smaller chunk of a bigger datagram? How does the receiver know where to place these fragments? What happens if the fragments arrive out of order? Well in this blogtorial we will try and answer all of these questions and take a look at the fragmentation process and how the receiver puts it all together.

Consider this simple topology and let's get started.

Troubleshooting OSPF - Why routes are not in the routing table?

I was checking something out today in one of our core routers and came up on an issue that got me going around in circles for a while. So I decided it would be useful to post about it. I have studied the CCNP material and I can assure you that this is NOT covered in the CCNP material. However, if you are going for your CCIE then you should know this. 

Basic setup of the routers is as follows. 

Now the issue was R2 wouldn't learn the route 4.4.4.4/32 from R1 as I would have expected. Why?? Well it took me a while and I started to tear apart the OSPF database, cost, filtering, etc but nothing seemed out of the ordinary. So let's walk through the troubleshooting process and see how I got my answer.

BGP Community - No-export

I am continuing from my previous post on BGP communities. Since the topology is the same we will skip the interface and BGP configurations and dive right into what is no-export community, how to configure it and see how it affects routing updates.

Same topology as my previous blogtorial BGP Communities No-Advertise 

Complete configs can be downloaded here.

BGP Community No-Advertise

Much like a community in real life -- a group of "people" (usually) with common beliefs, A BGP community "is a group of destinations which share some common attribute" - RFC 1997.

There are numerous BGP communities, but basically it is translated and interpreted as a 32bit value. BGP communities are optional transitive attributes meaning they are not required and they can be passed on to other AS only if the router(s) decides to do so. 

These are the well-known communities. More being suggested and drafted in other RFCs.

INTERNET - By default all destinations are assigned this community. 

NO_EXPORT - Do not send the route to any eBGP neighbors. 

NO_EXPORT_SUBCONFED - Do not send the route to any sub-confederations. 

NO_ADVERTISE - Do not send the route to any neighbors (iBGP or eBGP).

LOCAL-AS - Do not send to anyone other than your LOCAL-AS (So this will prevent the router from sending to sub-confederations). 

ip multicast helper-map - Converting Broadcast and Multicast

If you work in the financial industry you are bound to encounter a situation where you will have an application that publishes udp data as broadcast and you will need to convert it to multicast -- maybe even back to broadcast if needed. This is very similar to the "ip helper address" because "ip helper-address" converts DHCP (udp) to unicast packets and sends it to the DHCP server.

Couple of very important roles of the routers in this setup are FHR and LHR. First-hop router that is connected directly to the source which is broadcasting the data and the Last-hop router that is connected to the destination subnet which can convert the multicast back to broadcast. 

Consider this simple topology and let's get started. 

Complete configs can be found here.

Understanding TCP SLOW START

In my opinion, TCP Slow Start is a rudimentary concept that should be mastered by any Network Engineer. It maybe a good idea to read through my previous post about Window Size and Scaling before continuing. To understand TCP Slow Start there are a few terms that we must be familiar with. 

TCP Slow Start - Congestion control mechanism which controls the growth of the sending rate.  

IW - Initial Window 

CWND - Congestion Window (The send window of the sender)

RWND - Receive Window (The window size of the receiver) 

SMSS - Sender Maximum Segment Size (Maximum amount of bytes that can be stuffed into a packet on the sender side) 

ISST - Initial Slow Start Threshold

SST - Slow Start Threshold

FlightSize - Amount of unacknowledged data that can be on the wire. This is usually set to the CWND however the actual formula is min(cwnd, rwnd). In most cases the CWND will be smaller than the RWND.