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.