The Border Gateway Protocol (BGP) was originally designed only to carry unicast IPv4 routes, and as such provided no mechanism to carry network layer reachability information (NLRI) for any other protocol. As the Internet grew, RFC 2858 (obsoleted by RFC 4760) added multiprotocol extensions to BGP so that it could carry additional protocols like IPv4 multicast and IPv6. This enhancement to the protocol necessitated an evolution in the way BGP is configured on the Cisco IOS CLI.
Below is a basic example of legacy BGP configuration syntax:
router bgp 65001 no synchronization bgp router-id 22.214.171.124 bgp log-neighbor-changes network 172.16.0.0 mask 255.255.255.0 network 172.16.1.0 mask 255.255.255.0 network 172.16.2.0 mask 255.255.255.0 neighbor 10.0.0.2 remote-as 65002 neighbor 10.0.0.2 password FooBar neighbor 10.0.0.2 ttl-security hops 2 no auto-summary
This configuration syntax is limited in that it can only support IPv4; it provides no mechanism for defining additional address families.
To support multiprotocol BGP, Cisco introduced the "hybrid" BGP CLI syntax, which provides a distinct configuration subsection for each address family enabled. For example, all IPv4-specific parameters are configured under the subsection
address-family ipv4, while all IPv6 parameters are configured under
address-family ipv6. Parameters that are not specific to a particular address family are configured directly under the BGP process configuration as they were in the legacy syntax.
Now, you might assume that converting from the legacy syntax to the newer multiprotocol syntax is quite a chore, particularly on a large provider infrastructure with hundreds or thousands of BGP routers. Fortunately, IOS provides a feature to automate the transition in the form of a simple command: bgp upgrade-cli. We can issue this command under BGP process configuration to automatically convert our legacy syntax above.
R1(config)# router bgp 65001 R1(config-router)# bgp upgrade-cli You are about to upgrade to the AFI syntax of bgp commands Are you sure ? [yes]: y R1(config-router)# ^Z R1# show running-config | section bgp router bgp 65001 bgp router-id 126.96.36.199 bgp log-neighbor-changes neighbor 10.0.0.2 remote-as 65002 neighbor 10.0.0.2 ttl-security hops 2 neighbor 10.0.0.2 password FooBar ! address-family ipv4 neighbor 10.0.0.2 activate no auto-summary no synchronization network 172.16.0.0 mask 255.255.255.0 network 172.16.1.0 mask 255.255.255.0 network 172.16.2.0 mask 255.255.255.0 exit-address-family
Notice that we now have an IPv4 address family, under which all IPv4-specific BGP configurations have been relocated. We also see the addition of a line,
neighbor 10.0.0.2 activate, which enables the IPv4 protocol for that neighbor. The command
bgp upgrade-cli does not disrupt active adjacencies, and the multiprotocol extensions are backward compatible so that the configurations on individual routers can be upgraded independently.
After converting to the multiprotocol configuration syntax, we can create additional address families:
router bgp 65001 bgp router-id 188.8.131.52 bgp log-neighbor-changes neighbor 10.0.0.2 remote-as 65002 neighbor 10.0.0.2 ttl-security hops 2 neighbor 10.0.0.2 password FooBar neighbor 2001:DB8::2 remote-as 65002 ! address-family ipv4 neighbor 10.0.0.2 activate no neighbor 2001:DB8::2 activate no auto-summary no synchronization network 172.16.0.0 mask 255.255.255.0 network 172.16.1.0 mask 255.255.255.0 network 172.16.2.0 mask 255.255.255.0 exit-address-family ! address-family ipv6 neighbor 2001:DB8::2 activate network 2001:DB8:1::/64 network 2001:DB8:1:1::/64 network 2001:DB8:1:2::/64 exit-address-family
Finally, for illustration, check out the packet capture BGP_MP_NLRI.cap. The BGP update messages therein shows how unicast IPv4 routes are carried as legacy NLRI data, whereas our IPv6 routes are contained by the MP_REACH_NLRI attribute.