Injecting a Default Route into BGP via Redistribution

Default routes can be injected into BGP in one of 3 ways.

1. By network command

2. By redistribute command + default-information originate command

3. By neighbor <neighbor-id> default-originate sub command

This post is about the redistribution method. There are couple of things to remember when you are doing it.

Unlike other redistribution configurations, injecting a default route through redistribution requires an additional configuration command default-information originate. The default route must exist in the IP routing table anyway in order to be redistributed..

Following is the simple configuration to redistribute a static default route into BGP. Even from other protocols it is like this with exception of static keyword.

R1(config)#router bgp 65001
R1(config-router)#neighbor 192.168.12.2 remote-as 65002
R1(config-router)#redistribute static
R1(config-router)#default-information originate

Conditional Default Route Injection in BGP

Default routes can be injected into BGP in one of 3 ways.

1. By network command

2. By redistribute command + default-information originate command

3. By neighbor <neighbor-id> default-originate sub command

From all the above 3 methods, the last one does not add a default route to the local BGP table. Instead it will advertise a default route to a neighbor even without having a default route in it's IP routing table and when it is configured with a route-map, we can advertise the default route with a condition such as an availability of a particular route in the IP routing table.

We can check for the availability of a directly connected link via this method and advertise a default route to a neighbor until the route is in IP routing table. In this post I am checking for the availability of the default route in IP routing table and advertise a default to a neighbor. Here is how to do that..

Create a prefix list to match the default route;

R(config)#ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0

Create a route map with the prefix list;

R(config)#route-map CHECK-DEFAULT permit 10

R(config-route-map)#match ip address prefix-list DEFAULT

Configure neighbor with default-originate & route map

R(config)#router bgp 65001

R(config-router)#bgp log-neighbor-changes

R(config-router)#neighbor 192.168.12.2 remote-as 65002

R(config-router)#neighbor 192.168.12.2 default-originate route-map CHECK-DEFAULT

Note that if you are going to use an access-list to achieve the above result, following simple ACL can be used..

R(config)#ip access-list standard DEFAULT

R(config)#permit any

A Simple Way to Manually Sumamrize BGP Routes

First the router will be configured with a static route, typically with destination Null 0. Then prefix/length can be matched with a network command to inject the summary. Note that this will not filter any component subnets but for simple route sumarization can be achieved.

Let's see the routing table and the BGP config of the aggregating (summarizing) router..

network 11.0.0.0 mask 255.255.0.0 is inserted into the BGP configuration.

RIB of the aggregating router shows the summary route. But you can see the component routes are not suppressed. So You will have to remove advertising commands of component routes in R1. But to do so, you will have to make sure they are reachable from the aggregating router. In the above case, it is not a problem because the routes are originated from this router..

Route Summarization using Aggregate Address Command in BGP

BGP manual summarization with the aggregate address command can summarize based on any routes in the BGP table creating a summary of any prefix length. It does not always suppress the component subnets although it can be configured to do so.

Let's see the routing table of R1 which I am going to take as the aggregation point.

BGP configuration of R1;

BGP RIBs of all 3 routers;

Let's add a simple aggregate-address command to BGP configuration of R1;

aggregate-address 11.0.0.0 255.0.0.0

As you can see a new NLRI of 11.0.0.0/8 has been injected to the table along with its component subnets in R1 and it is advertised to both iBGP and eBGP neighbors.

Let's extend the command bit.

aggregate-address 11.0.0.0 255.0.0.0 summary-only

Now only the summary is advertised and in aggregation router, it shows subnets are suppressed.

Now let's configure R4 to advertise 11.40.0.0/24 subnet to BGP.. It will be shown in R1 as the following..

Let's see how it is advertised to R3 (It's iBGP neighbor)

You can see the AS path is only set up to the aggregation point even though one component subnet has a different AS path. In order to change this behavior of hiding the  AS path of component subnets, let's extend the command in R1 a little bit further..

 aggregate-address 11.0.0.0 255.0.0.0 summary-only as-set

Now in R3, AS path is shown with the AS path of the component subnet which has has learned from a different AS path.

Now let's configure R2 to advertise 11.200.0.0/24 subnet to BGP.. It will be shown in R1 as the following..

Let's see the output of R3 RIB now..

As you can see, it is showing ASes in a bracket with all the AS paths of component subnets because there are several different AS paths. It is really an unordered list of all ASes from all the component subnets which helps BGP loop prevention mechanism to function.

As a conclusion; while as-set is configured,
if all the component prefixes have same AS_PATH, it will be advertised
if at-least one component prefix is learned from a different AS, it's AS_PATH will be advertised
if more than one prefixes have different AS_PATHs, all will be advertised in a bracket unordered..

Impact of Auto Summary on Injected Routes by Network Command in BGP

Auto-summary is disabled by default in 12.3 and later Cisco IOS versions. Let's see the behavior of the router when it is enabled. Looks like it is breaking some general rules of BGP route injection.

Unlike IGPs, the BGP auto-summary router sub command causes BGP to summarize only those routes injected because of redistribution on that router. When it is configured, it does not look for the classful network boundaries in the topology nor routes already in the BGP table (as it does normally), it simply looks for the routes injected into BGP because of the redistribute and the network command on the same router.

Redistribute command: If any subnets of a classful network would be redistributed, do not redistribute subnets, but instead redistribute a route for the classful network..

Network command: If a network command lists a classful network, and there is atleast one route in IP routing table to a subnet of it, inject a route to the classful network..

In this post, let's experience the behavior with network command..

If following is the routing table,

& if following is the BGP configuration,

Following will be the result;

With auto-summary command;

There will be nothing changed..

Let's add a network command like network 1.1.0.0

Nothing will happen in the BGP table..

Now let's remove that command and add the real classful summary with the command..

Ah now there is something changed to see..

You can see the classful NLRI is injected along with the specific NLRI, & even if you removed network 1.1.1.1 mask 255.255.255.255 the classful NLRI will be advertised.

What is really happening here is that the router is only looking at it's routing table, not the BGP configuration to match a subnet route. Because the IP routing table has 1 directly connected route to it's loopback interface for the subnet of 1.1.1.1/32, it is advertising the 1.0.0.0 in BGP. If we change the IP of the loopback to a something else, ex:- 2.2.2.2/32, the BGP table will be shown empty.

Impact of Auto Summary on Injected Routes by Redistribution in BGP

Auto-summary is disabled by default in 12.3 and later Cisco IOS versions. Let's see the behavior of the router when it is enabled. Looks like it is breaking some general rules of BGP route injection.

Unlike IGPs, the BGP auto-summary router sub command causes BGP to summarize only those routes injected because of redistribution on that router. When it is configured, it does not look for the classful network boundaries in the topology nor routes already in the BGP table (as it does normally), it simply looks for the routes injected into BGP because of the redistribute and the network command on the same router.

Redistribute command: If any subnets of a classful network would be redistributed, do not redistribute subnets, but instead redistribute a route for the classful network..

Network command: If a network command lists a classful network, and there is atleast one route in IP routing table to a subnet of it, inject a route to the classful network..

In this post, let's experience the behavior with redistribution..

If following is the routing table,

& if following is the BGP configuration,

Following routes will be injected via the redistribute connected command..

When auto-summary is configured,

You can see, 1.1.1.1/32 is removed and 1.0.0.0 is placed..

Constructing BGP Peer Group Templates

Following example shows how to use BGP peer group templates to reduce configuration commands and apply configurations as a bulk to a group of neighbors. But the neighbors within a group must be in one autonomous system. You cannot group members from different autonomous systems.
You can apply specific policies per member if you want too.

BGP builds one set of UPDATE messages for a peer group, applying routing policies for the entire group, rather than one router at a time, thereby reducing some BGP processing and memory overhead.

Starting from BGP AS config command;
R1(config)#router bgp 65000

Creating peer group and assigning AS for the group;
R1(config-router)#neighbor MY-GROUP peer-group
R1(config-router)#neighbor MY-GROUP remote-as 65000

Defining the members of the group;
R1(config-router)#neighbor 2.2.2.2 peer-group MY-GROUP
R1(config-router)#neighbor 3.3.3.3 peer-group MY-GROUP
R1(config-router)#neighbor 4.4.4.4 peer-group MY-GROUP

Applying group wise polices;
R1(config-router)#neighbor MY-GROUP update-source Loopback0

Applying neighbor specific polices;
R1(config-router)#neighbor 2.2.2.2 password cisco123

Note that for different address families, you need to configure the peer groups separately within those address families..

Local Significancy of OSPF Process IDs

Can 2 routers become neighbors and exchange routing information even though they are running different OSPF process ids? Because the OSPF process IDs are locally significant They should, right? Let's find out..

Following are the configuration of 2 routers which are connected over a direct link of 192.168.12.0/24 subnet. Note that the process id is different..

Yes, they form the neighborship and works fine like they have the same process id..

Analyzing OSPF Neighbor Establishing Packets

Let's just take 2 routers and configure very basic OSPF and take a look at how the packets are exchanged to form the neighbor relationship.

Following configuration is configured in the devices.

Download the packet capture from here.

Hard Reset vs Soft Re-Convergence of BGP Neighbors

Here I am going to analyze the packet flow between 2 BGP neighbors for 2 types of commands.

clear ip bgp *
clear ip bgp * [in|out]

1st one is used to hard reset the BGP neighbors & the 2nd one is called a soft re-convergence. Let's find out why it is said so using a packet capture.

Packet flow of clear ip bgp *

Now let's try a soft re-convergence hitting clear ip bgp * in

clear ip bgp * out

clear ip bgp * in means asking the neighbor to resend the NLRIs and clear ip bgp* out means to resend NLRIs to neighbor.

As you can see, TCP session will be re-established when you hit clear ip bgp * but only the routing updates will be re-transmitted in soft re-convergence method. So a soft re-convergence can be used in production environments without causing a network interruption.

Note that for some configurations like changing BGP timers may need to use the hard reset command in order to be applied.

Download the packet capture from here.

Analyzing BGP Neighbor Establishing Packets

Let's just take 2 routers and configure very basic BGP and take a look at how the packets are exchanged to form the neighbor relationship.

For iBGP

Forming iBGP neighbors using the following configuration..

Download the packet capture file from here.

You can see the TCP connection establishing packets and then the OPEN sent messages and then the KEEP ALIVES.

As you can see in the capture, router 2.2.2.2 is sending the 1st TCP SYN to initiate the connection from its random source port 47655 to the destination source port 179.

You can see who initiated the connection from the following command in IOS..

In the above output, the router with the random port is always the initiator..

As you can see in the config of R1, there is an NLRI configured to advertise. It is going through an UPDATE message which is not showing in the above screenshot. The contents of that message is like the following.. (click on the image to view in full size)

For eBGP

Forming eBGP neighbors using the following configuration..

Download the packet capture file from here.

Looks like there is nothing much different in iBGP & eBGP packet flow..