Configuration of MP-iBGP on BGP Route Reflectors

During the initial MPLS migration of the TransitNet backbone that we reviewed in Chapter 6, all relevant route reflectors were put into place. The MP-iBGP session configuration should follow the standard BGP session configuration, in which each of the PE-routers is peered with two route reflectors for redundancy. Separate route reflectors specific to MP-iBGP may be deployed, depending on the measured overhead of having both IPv4 and VPN-IPv4 addresses reflected on the same set of route reflectors. Either configuration is possible, and if the same set of route reflectors is used, only one BGP session is required to carry both IPv4 and VPN-IPv4 routes. Because the TransitNet BGP sessions will carry only VPN-IPv4 routes and the default route after the migration, the use of one set of route reflectors that can process both IPv4 and VPN-IPv4 routes will be adopted.

Because peer groups have been used within the TransitNet BGP configuration, all MP-iBGP neighbors should be associated with a VPN-IPv4 peer group to ease the configuration and also to lower the burden of the route reflector in terms of the number of updates that it must build. The following steps are necessary on the route reflectors:

Configuration of the VPN-IPv4 BGP peer group? Within the BGP configuration, a peer-group must be defined to include all neighbors that will receive MP-iBGP updates from the route reflector. Because the TransitNet service provider has deployed route reflectors, this configuration is necessary only on the route reflector, not on all PE-routers. An example configuration can be seen in Example 15- 3.
Configuration of no bgp default ipv4-unicast? This configuration command is necessary under the BGP configuration so that any new BGP sessions that are configured do not immediately become active as standard BGP-4 sessions. If this command is not configured, then the default behavior is to attempt to establish a BGP-4 session (which will carry IPv4 prefixes) with the specified neighbor. This is not really an issue because a VPN-IPv4 session can also be established, but it means that an IPv4 session will exist even though it is not necessary.
Configuration of the VPNv4 address family? Within the BGP configuration of the route reflector, it is necessary to define an address family that will carry MP-iBGP updates. As part of this configuration, each neighbor must be activated using the neighbor neighbor-address activate command before the association with the peer group. This configuration (with fictitious neighbor addresses) can be viewed in Example 15-4.

Example 15-3 TransitNet Route Reflector Peer Group Configuration


router bgp 1234

 neighbor VPNv4 peer-group

 neighbor VPNv4 remote-as 1234

 neighbor VPNv4 update-source Loopback0

Example 15-4 TransitNet Route Reflector Address Family Configuration


router bgp 1234

!

 address-family vpnv4

  neighbor VPNv4 activate

  neighbor VPNv4 route-reflector-client

  neighbor VPNv4 send-community extended

  neighbor 194.27.1.1 peer-group VPNv4

  neighbor 194.27.1.2 peer-group VPNv4

  neighbor 194.27.1.3 peer-group VPNv4

 exit-address-family

None of the newly created MP-iBGP sessions will become active at this point because the other end of the MP-iBGP sessions will not have been configured.