iBGP and eBGP Fundamentals – Advertising Routes with Border Gateway Protocol

When advertising routes with BGP, a BGP speaker will only advertise or receive updates from a peer only when the local BGP speaker and the peer relationship is in the established state. If the peer relationship is in any other state, no routes will be advertised or received. Additionally, when in the established state, it is important to remember that, by default, a BGP speaker will only advertise the best path in the BGP RIB to its peer(s). In other words, the prefix must exist and be installed into the routing table before BGP will advertise it to any other peers.

As was stated earlier in this chapter, Border Gateway Protocol is a Path Vector protocol. A Path Vector protocols is a variant of a Distance Vector protocol and employs techniques similar to those used by Distance Vector protocols. BGP uses a split-horizon-like behavior when advertising prefixes and will not re-advertise a prefix learned from a peer back to that neighbor if that prefix is the best path to the specified destination network.

In Cisco IOS software, there are three ways that can be used to advertise networks when using Border Gateway Protocol. These three ways or methods are:

• Using the network command
• Using the aggregate-address command
• Using the redistribute command

The network command is the recommended method for advertising network when running BGP. This command, when used with BGP does not enable BGP for the specified network, as would be the case if it was used when configuring an IGP, for example.

Instead, the network command is used to flag the network as being local to the autonomous system as well as to instruct BGP to advertise the specified network. The complete syntax for this command is network [network] [mask <mask>] [route-map <name>]

The [network] specifies the network that BGP should advertise. The specified network must be present in the routing table before it will be advertised by BGP. The [mask <mask>] keyword is optional and is required only when BGP is required to advertise either subnets or supernets. For example, to advertise the 10.0.0.0/30 subnet, the mask would be required. Excluding the mask and simply entering the network 10.0.0.0 command would not result in this subnet being advertised. However, the mask would not be required to advertise the 10.0.0.0/8 network, as long as there was a matching route for this prefix in the routing table.

The [route-map <name>] keyword allows the configuration applied in the named route-map to be referenced for the specified network. This route map could be used to manipulate BGP attributes, such as the MED, or metric, for that specific network. BGP path attribute manipulation is a core ROUTE exam requirement and is described in the following chapter.

The aggregate-address command is used to summarize BGP routes. Before this command can be used, the subnets being summarized must exist in the routing table. Additionally, when this command is issued, a route pointing to the Null0 interface is generated by the router. Summarization for BGP is described in detail in the following chapter. The options that are available with this command are also described in the same chapter.

And finally, the redistribute command is used to inject external routes into BGP. These may be static, connected, or dynamically learned routes. As is the case with route summarization, route redistribution between BGP and the different IGPs is described in the following chapter.

Advertising Routes Using the network Command

As previously stated, the network command is the recommended and preferred method for advertising networks when running BGP. The following example shows how to advertise a directly connected network using this command:

To verify that the network has been installed into the BGP RIB, you should use the show ip bgp command should be used as illustrated in the following output:

In regards to the output above, the asterisk (*) indicates that the path is valid, i.e. the path has a valid next hop. The caret (>) indicates that this is the best path to the destination network. If there are multiple entries in the BGP RIB, the path selection is used to select the best path. Only this path will have the caret symbol assigned to it. All other valid paths will simply have the asterisk beside them, indicating that they can be used in the event that the current best path is removed or withdrawn from the BGP table.

For directly connected subnets, the next hop address will always be 0.0.0.0, indicating that the next hop is the local BGP speaker. Additionally, the route metric of the prefix will also be shown. Because connected routes have a metric of 0, the same metric will be used by BGP. By default, the prefix will be assigned a default LOCAL_PREF of 100. By default, the prefix is assigned a WEIGHT value of 32,768. And finally, because the network was injected into BGP using the network command, the ORIGIN code of I is used. Detailed information on the network can be viewed using the show ip bgp [prefix] command as illustrated below:

One additional important observation from the output above is the section stating Advertised to update-groups: followed by the number 1 directly below it. Cisco IOS software uses the BGP Update Group dynamically creates Update Groups which contain BGP neighbors that can share UPDATE messages. No explicit administrator configuration is required as members are dynamically added to the Update Group based on shared outbound policies. In other words, all members are neighbors that have similar outbound BGP policies. The show ip bgp update-group command can be used to view the members assigned to each Update Group. This command prints the following output when issued on R1:

From the output above, Update Group 1 is for peers that are external to the local autonomous system configured on R1. The second bolded section shows that a single NLRI has been advertised to the member(s) within this Update Group. And finally, the last bolded section shows that this Update Group contains only a single member, which is router 2.2.2.2. Subsequent peers that share the same outbound policies as this peer will be included in the same Update Group.

If internal peers, i.e. iBGP peers were also configured, a separate Update Group for those types of peers, assuming they share the same outbound policies, would be dynamically created. This feature allows for optimal UPDATE message generation.

If a prefix is advertising using the network command and the prefix is known via an IGP, then BGP will use the next hop IP address of the IGP versus a next hop address of 0.0.0.0. For example, R2 is receiving the 150.254.0.0/16 prefix from OSPF as illustrated in the output below:

The prefix is then injected into BGP using the network statement as follows:

NOTE: The mask is not required in this case because this is a Classful network and the same Classful network exists in the routing table.  Remember, the mask is only required for advertising either subnets or supernets. It is not required for advertising Classful networks.

In addition to the next hop address, BGP also assigns the prefix the same metric that is used by the IGP, which is 65 in this example. The WEIGHT, LOCAL_PREF and ORIGIN attributes, however, do not change and all remain the same.