Internet Routing Architectures, Second Edition

AF Style

In this style, the presence of the address-family submode obviates the need for the nlri keyword. To advertise a network over IPv4, the network command has to be specified under BGP router mode. In order for the network to be advertised as multicast NLRI, the network command needs to be specified under the ipv4 multicast AF submode.

The following commands advertise a network to all the neighbors in the IPv4 address family:

Router(config-router)#network 1.1.0.0 mask 255.255.0.0

Router(config-router)#network 2.2.2.0 mask 255.255.255.0

To advertise a network in the IPv4 multicast AF, you need to define the network under the IPv4 multicast AF mode:

Router(config-router)#address-family ipv4 multicast Router(config-router-af)#network 1.1.0.0 mask 255.255.0.0 Router(config-router-af)#network 2.2.2.0 mask 255.255.255.0

This way, networks can be independently advertised as IPv4 unicast, multicast, or unicast and multicast NLRI.

Peer Groups

Peer groups can now be configured under specific AFs, providing a considerable amount of flexibility over the old style of configuring peer groups. This section discusses both the old and new methods of configuring peer groups.

Old Style

A peer group was defined in the BGP router configuration mode. The nlri keyword was used to allow the peer group to exchange multicast prefixes. Using the nlri keyword, you could specify unicast and/or multicast. If the nlri keyword was not specified, it implied only IPv4 unicast.

The peer group members automatically inherited the unicast and/or multicast capability of the peer group. The following command syntax shows the old method of configuring peer groups:

Router(config-router)#router bgp 10

Router(config-router)#neighbor external peer-group nlri unicast multicast Router(config-router)#neighbor 1.2.3.4 remote-as 20 Router(config-router)#neighbor 1.2.3.4 peer-group external

page 403

Internet Routing Architectures, Second Edition

AF Style

The peer group (or its members) is (are) defined under the BGP router mode. However, because we have AF submodes, the need for the nlri keyword is obviated. The peer group needs to be activated in the IPv4 multicast AF to enable the exchange of IPv4 multicast prefixes. As with the neighbor command, a peer group and its members are activated by default for IPv4 unicast. This behavior can be overridden using the no form of the activate command. The following command syntax shows how to configure peer groups using the new AF-style CLI:

Router(config)#router bgp 10

Router(config-router)#neighbor external peer-group Router(config-router)#neighbor 1.2.3.4 remote-as 20 Router(config-router)#neighbor 1.2.3.4 peer-group external

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

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

Router(config-router-af)#neighbor 1.2.3.4 peer-group external

Route Maps

The old method of configuring route maps required that all AF policies be contained within a single route map. With the new AF style of configuring route maps, an individual route map can be specified for each AF. This section discusses both the old and new methods of using route maps with multiple AFs.

Old Style

In the old style, a single route map was used to specify policies for all AFs. This route map was then applied as either inbound or outbound for the peer or peer group. Routing policies relating to the two AFs that could be carried in the BGP session (IPv4 unicast and IPv4 multicast) were represented using a single route map by specifying the match nlri clause in the route map sequence. The match nlri clause in a route map used the following semantics:

The following example shows how to configure BGP so that any multicast routes from neighbor 1.1.1.1 will be accepted if they match access-list number 1:

router bgp 109

neighbor 1.1.1.1 remote-as 1 nlri unicast multicast neighbor 1.1.1.1 route-map filter-mcast in

!

route-map filter-mcast permit 10

page 404

Internet Routing Architectures, Second Edition

match nlri multicast match ip address 1

AF Style

One of the important reasons for migrating customer configurations from the old style to the AF style is that routing policies expressed using the match nlri keyword in the sequences of a route map soon becomes unmanageable, especially when complicated and differing policies are used for different AFs. Because new IOS supports more than two AFs, it was quickly realized that a more scalable solution was required. A single route map for expressing all policies was seen as overly complex.

The introduction of a new parser mode for each AF facilitated the introduction of a new way of configuring policies on a per-AF basis (that is, a separate route map for each AF associated with a neighbor). Not only can route maps be specified on a per-AF basis, but they can also provide AF-specific filtering rules such as prefix lists, distribution lists, AS_PATH access lists, and so on. With the new style of configuring policies, the keyword nlri would no longer be required, and the parser would reject the occurrence of the match nlri clause in a route map sequence.

The policy can then be expressed in AF style as follows:

!

address-family ipv4 multicast neighbor 1.1.1.1 activate

neighbor 1.1.1.1 route-map filter-mcast in

!

route-map filter-ucast permit 10 match ip address 1

!

route-map filter-mcast permit 10 match ip address 2

Redistribution

Redistribution is the process of importing routes from one routing protocol to another. When routes are redistributed into BGP using the redistribute command, you have to specify the BGP table (Adj-RIB-In, as specified in BGP) into which the routes are to be imported. This BGP table can be either the unicast BGP table or the multicast BGP table.

Old Style

The old style of specifying the table into which a route had to go used the set nlri clause in the redistribution route map. The set nlri clause in the redistribution route map has the following semantics:

page 405

Internet Routing Architectures, Second Edition

•set nlri multicast—

Redistributes the matching prefix to the multicast table.

•set nlri unicast multicast—

Redistributes the matching prefix to both unicast and multicast tables.

•set nlri unicast—

Redistributes the matching prefix to the unicast table only.

•set nlri—

Unspecified results in unicast behavior only.

The following example demonstrates redistribution into BGP so that all "connected" prefixes matching access list 1 in the routing table are imported as multicast NLRI:

router bgp 109

redistribute connected route-map mbgp-source-map

!

route-map mbgp-source-map match ip address 1

set nlri multicast

AF Style

With the introduction of AF mode, the AF under which the redistribute command is specified determines the table into which the redistributed prefixes are injected. For example, if the redistribute statement resides under address-family ipv4 multicast mode, the redistributed prefixes are injected as multicast IPv4 NLRI. Hence, the preceding old-style redistribution configuration translates into the following in AF style:

router bgp 109

!

address-family ipv4 multicast

redistribute connected route-map mbgp-source-map

!

route-map mbgp-source-map match ip address 1

Note that with the introduction of the redistribute statement within AF mode, the clause set nlri is not required, and the parser would reject the presence of set nlri in the route map paragraph.

page 406