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:

match nlri multicast           ! Matches only IPv4 multicast
match nlri multicast unicast   ! Matches both IPv4 unicast and multicast
match nlri unicast             ! Matches only IPv4 unicast
match nlri                     ! Unspecified; matches only IPv4 unicast

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
  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:

router bgp 109
  neighbor 1.1.1.1 remote-as 1
  neighbor 1.1.1.1 route-map filter-ucast in
!
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

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
34.239.148.106