As we’ve seen, BGP is very different from the IGPs that are traditionally used for next hop forwarding. One of the most significant differences between BGP and other routing protocols is how you advertise prefixes into BGP.
BGP requires (by default) that the prefix you are attempting to advertise is learned through some other means first. AKA, before you see the prefix in the BGP table it has to be in the routers main IP routing table. There are 2 main ways you can originate a BGP prefix. The redistribute command and the network command. We’ll be discussing the redistribute command in a later post, so for now I’d like to focus on the network command.
The network command can be implemented in two fashions. The most common way it is used is in this form…
network 172.64.32.0 mask 255.255.255.0
In this way, you are specifying an exact prefix you wish BGP to put into it’s BGP table. In order for the above command to work we’d expect to see a entry in the routers main IP routing table for 172.64.32.0 /24 which it learned through some other means.
The second way in which the network command can be used is like this…
network 172.64.0.0
Using the network command with this syntax requires a little more thought. Let’s take a look at a quick lab setup to see the difference between the two…
Let’s assume that router1 and router2 have an iBGP peering already configured between their loopbacks. Let’s also assume that router1 has the following prefixes in it’s main IP routing table through the use of static routes pointed at null0…
ip route 192.1.1.0 255.255.255.0 null0
ip route 192.2.2.0 255.255.255.0 null0
ip route 192.3.3.0 255.255.255.0 null0
ip route 172.64.1.0 255.255.255.0 null0
ip route 172.64.2.0 255.255.255.0 null0
ip route 172.64.3.0 255.255.255.0 null0
ip route 10.1.1.0 255.255.255.0 null0
ip route 10.2.0.0 255.255.0.0 null0
Let’s use the network command without the mask to advertise these prefixes to router2. Thinking about specifying a network without a mask, we have to assume that the router is making an assumption about the network. That is, the router must be using some sort of predetermined specification to determine what network it will advertise as well as what subnet mask that prefix will have.
This is where classful networks come into the picture. If you’re struggling to recall what a classful network is, that’s OK (you should know what they are though) here’s a quick refresher…
Classful networks
Class A – Has a /8 subnet mask. First octet between 1 and 126.
Class B – Has a /16 subnet mask. First octet between 128 and 191.
Class C – Has a /24 subnet mask. First octet between 192 and 223.
There are of course class D and E as well but those don’t fall into the scope of this discussion.
So now that we know what the classful networks are, let’s talk about the rules of using the network statement in BGP without a mask. There are two ways for this to work. Let’s work through them one at a time…
Without auto-summarization
As stated above, the router’s BGP process will assume the subnet mask of prefixes based on their classful network definition. That being said, the router will make the following assumptions…
ip route 192.1.1.0 255.255.255.0 null0 – A /24 mask
ip route 192.2.2.0 255.255.255.0 null0 – A /24 mask
ip route 192.3.3.0 255.255.255.0 null0 – A /24 mask
ip route 172.64.1.0 255.255.255.0 null0 – A /16 mask
ip route 172.64.2.0 255.255.255.0 null0 – A /16 mask
ip route 172.64.3.0 255.255.255.0 null0 – A /16 mask
ip route 10.1.1.0 255.255.255.0 null0 – A /8 mask
ip route 10.2.0.0 255.255.0.0 null0 – A /8 mask
If you notice, the only routes we wish to advertise that have a mask that matches their classful network mask definition are the 192 routes. Let’s see what happens when we define all of these networks in BGP…
As expected, the only routes that entered the BGP table were the routes that had a subnet mask matching their classful network definition.
So how do we get the other routes into the BGP table? Can we define the classful network for the 172 and 10 prefixes to get them in there?
The answer is no. In order to get these other prefixes into the table using the network command without a mask we’ll have to use the second method…
With auto-summarization
The second method is to enable the BGP auto-summarization command. Doing this tells the BGP process to look for prefixes that are greater than or equal to the network defined. Let’s look at an example so you can see what I mean. I’ll start by removing any of the previous BGP network statements…
Once I enabled auto-summary, I reinserted the ‘network 10.0.0.0’ command under the BGP process. Looking at the BGP table, I see that I am now originating a prefix for 10.0.0.0/8. However, looking at the main IP routing table I can see that I don’t have a prefix for 10.0.0.0/8…
So it appears that the BGP auto-summary command summarizes the prefixes on the classful boundary and puts the major network in the BGP table. That being said, how would we go about advertising the 192 and 172 prefixes into the BGP table?
For the 172 prefixes the interesting octet for all three prefixes falls into the third octet. This being the case, we can summarize all three networks into the classful network of 172.64.0.0. However, the 192 prefixes will require three network statements since the interesting octet falls in the third octet. The third octet on a class C classful network is still part of the network ID (octets 1,2, and 3 for class C networks) so we need a network definition for all 3 networks. Once we put those in we now have BGP advertisements that cover all 8 of our static routes.
As I said above, it is more common to specify the mask but you should be aware of how the network statement works with or without the optional mask argument.