Internet Routing Architectures, Second Edition

Appendix D. Multiprotocol BGP (MBGP)

With the support of BGP Capabilities (BGPCAP)[], Multiprotocol BGP (MBGP)[] defines backward-compatible extensions to BGP-4[] that allow it to carry routing information for multiple network layer protocols (for example, IPv6, IPX, and so on). Individual network layer protocols are identified by an Address Family (AF), as defined in RFC 1700[]. These extensions allow a set of BGP peers to exchange reachability information for multiple AFs (for example IPv4, IPv6, IPX) and sub-AFs (for example, unicast or multicast).

NOTE

The complete transition plan from the old-style CLI to the new AF-style CLI still has not been completely decided upon within Cisco. For that reason, if you encounter inconsistencies, consult Cisco support personnel or documentation associated with your specific version of IOS.

The Motivation Behind the New Command-Line Interface

With multiple address families, it was quickly realized that the AF topologies would frequently be noncongruent. Also, policies associated with a given session might vary depending on specific AFs. The initial CLI design focused on accommodating only a single AF (IPv4) and its associated sub-AFs (unicast and multicast). Utilizing this design to provide support for additional AFs introduced unnecessary management and policy expression complexities.

It was therefore decided that a new approach would be used—an approach that cleanly separates general session-related parameters from AF-specific parameters. Beyond management aspects alone, this new approach provides several advantages:

•Inbound and outbound policy can be different for each AF.

•A BGP router can be configured as a route reflector for a single AF or multiple AFs.

•No new configuration is required to support "vanilla" BGP (IPv4-unicast).

•Prefixes can be sourced (via redistribution, aggregate-address statements, and network statements) within any AF independently.

•Peer group functionality will be maintained within the associated AF, because it is relevant for UPDATE generation.

This new model is much more flexible when using multiple AFs. Based on the preceding advantages, the router bgp subcommands were divided into three command groups:

1.Global BGP commands—

These commands affect the operation of BGP global to the router. Examples include bgp deterministic-med and bgp cluster-id.

page 398

Internet Routing Architectures, Second Edition

2.Commands to identify the neighbors/peer groups—

These commands define the neighbor or peer group that is accessible from the default routing table by specifying session parameters. Examples include neighbor 1.2.3.4 remote-as as and neighbor 1.2.3.4 ebgp-multihop ttl.

3.Commands per-address family—

Two sets of commands can be per-AF:

oGlobal to per-AF—

These commands are neighbor-independent and modify the behavior of BGP for a specific AF. Prefixes to be sourced (using redistribution, network, or aggregate-address statements) under this AF fall into this category. Examples include network 1.2.0.0 mask 255.255.0.0, redistribute dvmrp, and bgp scan-time.

oAF-specific per-neighbor/peer group—

These commands configure policy for the neighbor(s) or peer groups with distribute lists, prefix lists, or route maps. The neighbors can also be configured as clients of a route reflector, or added as members of a peer group. The neighbor must be explicitly "activated" in order to enable the exchange of Multiprotocol BGP prefixes. Examples include neighbor 1.2.3.4 filter-list in, neighbor peergroup1 route-map foo in, and neighbor 1.2.3.4 activate.

Organizing Command Groups in the New Configuration

There is no ambiguity present for command group 1, so they appear as global BGP configuration parameters. These commands appear only once in the configuration.

There is no ambiguity for command group 2, so they follow command group 1 under the global BGP parameters. BGP neighbors, with an exception to a case in VPN, are defined once in the configuration.

A new submode was introduced under router bgp autonomous-system configuration mode to define the per-AF commands.

The following output demonstrates the general configuration guidelines when using the new AF-style CLI:

router bgp autonomous-system address-family afi [sub-afi]

redistribute protocol neighbor 1.2.3.4 activate

…

exit-address-family exit

page 399

Internet Routing Architectures, Second Edition

A neighbor can have different policies applied to a single peer (for example, route-map or prefix-list statements), one per AF.

For configuring IPv4-unicast BGP (vanilla BGP) policy for neighbors, it is possible to configure them entirely under the command group 2. This is very similar to what we have today (old CLI). The address-family ipv4 unicast is implicit, although explicit configuration is recommended.

It is also possible to configure the IPv4-unicast BGP policy using the address-family BGP submode. In the show running-config output, address-family ipv4 unicast is shown, and IPv4-unicast global (global to per-AF) and policy (AF-specific per-neighbor/peer group) commands are listed within the mode.

Under the address-family submode, the commands of the global to per-AF group appear first. These are commands that are global to the AF.

Following the global to per-AF commands are the AF-specific per-neighbor/peer group commands. These commands implement the policy to the neighbors for that AF.

Before any policy is defined for a neighbor under an AF, the neighbor should be "activated" for that AF. The command syntax required to activate a neighbor under a specific AF is as follows:

router bgp autonomous-system address-family afi [sub-afi]

neighbor 1.2.3.4 activate

…

exit-address-family exit

The new configuration structure looks like this:

page 400

The following sections provide more information on commands.Each section addresses two configuration styles:

•Old style—

The current 12.0S way of configuring BGP.

•AF style—

The new way of configuring BGP, using address-family submode.

The following sections cover configuration guidelines associated with activating a peer, advertising a network, peer groups, route maps, route redistribution, route reflection, and aggregation.

activate

The activate command is new to IOS BGP configuration as part of the AF CLI enhancements. It's used to enable (or activate) support of the specified AF for a neighbor. This section discusses the old method used to enable an AF for a neighbor and then provides guidelines for using the new method.

page 401

Internet Routing Architectures, Second Edition

Old Style

The activate command was not available in 12.0S. The neighbor was activated for IPv4 BGP automatically. However, if MBGP was enabled, the nlri keyword in the neighbor command was required:

Router(config-router)#neighbor 1.2.3.4 remote-as 10 nlri unicast multicast

If the nlri keyword was not specified, the router would exchange IPv4 prefixes only. If the nlri keyword was specified with the multicast option only, only the IPv4 multicast NLRI would be exchanged. This way you could activate only unicast, or only multicast, or both.

AF Style

To enable an AF for the neighbor, the activate command is used in BGP router or addressfamily configuration submode. The neighbors that are defined under the BGP router submode are automatically activated for IPv4. For all other AFs, the neighbors must be explicitly activated. To deactivate a neighbor for an AF, use the no form of the command. The following command syntax demonstrates how to enable neighbor 1.2.3.4 to support IPv4 multicast:

Router(config-router)#address-family ipv4 multicast

Router(config-router-af)# neighbor 1.2.3.4 activate

network

The network command can now be specified under a specific AF in order to announce the network under that AF. This section discusses the old and new styles of configuring the network command.

Old Style

The old style used the network command to advertise a network over BGP. The command used an nlri extension to specify if the network was to be advertised as unicast, multicast, or both. The absence of the nlri keyword implied IPv4 unicast only. For example:

Router(config)#router bgp 10

Router(config-router)#network 2.2.2.0 mask 255.255.255.0 Router(config-router)#network 3.0.0.0 mask 255.0.0.0 nlri multicast Router(config-router)#network 1.1.0.0 mask 255.255.0.0 nlri unicast multicast

page 402