Multiprotocol BGP Usage and Deployment

You have seen already that you use MP-BGP, which is an extension of the existing BGP-4 protocol, to advertise customer VPN routes between PE-routers that were learned from connected CE-routers. These customer routes might be learned through standard BGP-4, RIP Version 2, static routes, or OSPF. Future versions of Cisco IOS might support additional CE-PE routing protocols.

MP-BGP is required only within the service provider backbone. Therefore, all MP-BGP sessions are internal BGP sessions, internal because the session is between two routers that belong to the same autonomous system.

MP-iBGP is required within the MPLS/VPN architecture because the BGP update needs to carry more information than just an IPv4 address. You have seen already that an MP-iBGP update contains a VPN-IPv4 address, MPLS label information, extended BGP communities, and possibly standard BGP communities.

Note

Multiprotocol BGP extensions to the existing BGP-4 protocol (RFC 1771) are defined within RFC 2283. You can find more information on the use of MP-BGP within an MPLS environment in draft-ietf-bgp4-mpls, which discusses using BGP-4 to carry MPLS label information.

Certain extensions to the BGP protocol that provide additional capabilities are necessary to allow BGP to carry more information than just the IPv4 address (and standard BGP attributes). When a BGP session is established between two peers, an OPEN message exchanges initial BGP parameters, such as the autonomous system number used by the BGP neighbors. This OPEN message can contain optional parameters, one of which is the Capabilities parameter that describes which optional capabilities the peer can understand and execute. One of these capabilities is multiprotocol extensions. These multiprotocol extensions provide BGP with the capability to carry addresses other than standard IPv4 addresses.

Two new optional, non-transitive attributes are introduced to BGP when the multiprotocol extensions capability is used. One of these attributes (Multiprotocol Reachable NLRI or MP_REACH_NLRI) announces new multiprotocol routes. The other attribute (Multiprotocol Unreachable NLRI or MP_UNREACH_NLRI) revokes the routes previously announced by MP_REACH_NLRI.

The first attribute (MP_REACH_NLRI) carries a set of reachable destinations together with the next hop information to be used for forwarding to these destinations. The second attribute (MP_UNREACH_NLRI) carries the set of unreachable destinations. Both of these attributes are optional and non-transitive. For two BGP speakers to exchange multiprotocol data, they must agree on this capability during their capabilities exchange.

When a PE-router sends an MP-iBGP update to other PE-routers, and this update contains MPLS/VPN information as previously described, the MP_REACH_NLRI attribute contains one or more triples that consist of the following:

Address Family Information
Next-hop Information
NLRI (Network Layer Reachability Information)

The address-family information identifies the Network layer protocol that is being carried within the update. This is set to AFI=1 and sub-AFI=128 in the case of MPLS/VPN. You can find currently used values in RFC 1700, "Assigned Numbers."

The next-hop information is the next-hop address information of the next router on the path to the destination. In the case of MPLS/VPN, this is the advertising PE-router. The next-hop address must be of the same address family as the NLRI. To satisfy this requirement, the route distinguisher field of the next-hop is set to all zeros.

The NLRIs are encoded as one or more triples with the following format for MPLS:

Length: Total length of the label plus the prefix (RD included).

Label: (24 bits) Carries one or more labels in a stack, although a BGP update has only one label. This field carries the following parts of the MPLS shim header (described in Chapter 2, "Frame-mode MPLS Operation"):

Label Value??20 Bits

Experimental bits?3 Bits

Bottom of stack bit?1 bit

Prefix: Route distinguisher (64 bits) plus IPv4 prefix (32 bits).

Example 9-14 shows the command that identifies which labels are assigned to the particular VPN routes, and Example 9-15 shows the command to determine whether the PE-router is exchanging VPN-IPv4 address information with a neighbor.

Example 9-14 show ip bgp vpnv4 all tags Command Usage


New York# show ip bgp vpnv4 all tags

   Network          Next Hop      In tag/Out tag

Route Distinguisher: 1:27 (EuroBank)

   0.0.0.0          10.2.1.25       50/notag

   2.2.2.2/32       0.0.0.0         46/aggregate(EuroBank)

   8.8.8.8/32       10.2.1.25       51/notag

   9.9.9.9/32       10.2.1.25       52/notag

Example 9-15 show ip bgp neighbor Command Usage


New York# show ip bgp neighbor 194.22.15.4

BGP neighbor is 194.22.15.4,  remote AS 1, internal link

  BGP version 4, remote router ID 197.1.1.1

  BGP state = Established, up for 01:00:55

  Last read 00:00:56, hold time is 180, keepalive interval is 60

  seconds

  Neighbor capabilities:

    Route refresh: advertised and received

    Address family IPv4 Unicast: advertised and received

    Address family VPNv4 Unicast: advertised and received

  Received 13002 messages, 0 notifications, 0 in queue

  Sent 13089 messages, 0 notifications, 0 in queue

  Route refresh request: received 1, sent 2

  Minimum time between advertisement runs is 5 seconds



 For address family: IPv4 Unicast

  BGP table version 5, neighbor version 5

  Index 1, Offset 0, Mask 0x2

  4 accepted prefixes consume 144 bytes

  Prefix advertised 10, suppressed 0, withdrawn 6



 For address family: VPNv4 Unicast

  BGP table version 20, neighbor version 20

  Index 2, Offset 0, Mask 0x4

  0 accepted prefixes consume 0 bytes

  Prefix advertised 174, suppressed 0, withdrawn 25

Configuration of Multiprotocol BGP

The configuration of BGP requires several steps, and various configuration commands. It has to be configured for any PE-to-PE MP-iBGP sessions across the MPLS/VPN backbone, and for any PE-to-CE eBGP sessions for customers that want to run BGP with the service provider. Chapter 10 covers the configuration of these PE-to-CE eBGP sessions.

You saw earlier in this chapter that as part of the MP-BGP specification (RFC 2283), an address-family is created to allow BGP to carry protocols other than IPv4. Within the MPLS/VPN architecture, this address-family is the VPN-IPv4 address and BGP must be told that this type of address-family is carried by one of its sessions.

The default behavior when a BGP session is configured on a Cisco router is to activate the session to carry IPv4 unicast prefixes. This might represent a problem in a pure MPLS/VPN environment, where BGP is used solely to carry VPN-IPv4. Therefore, a new command is introduced to reverse this behavior so that the activation of any BGP sessions, whether IPv4 or VPN-IPv4, does not occur by default. Example 9-16 shows the syntax of this command.

Example 9-16 BGP Default IPv4-unicast Command Usage


San Jose(config)# router bgp 1

San Jose(config-router)# no bgp default ipv4-unicast

The next step in the configuration of MP-iBGP is to define and activate the BGP sessions between PE-routers. Some of these sessions carry VPN-IPv4 routes, some only IPv4 routes, and others carry VPN-IPv4 and IPv4 routes. The type of BGP session and the specification of which routes (VPN-IPv4 or IPv4) the session will carry are controlled through the use of address families within the BGP configuration for routes that are injected into and out of BGP, into and out of VRFs, and through the normal BGP configuration process for routes that belong to the global routing table. The address-family is synonymous with the routing context.

You must configure a BGP address-family for each VRF configured on the PE-router and a separate address-family to carry VPN-IPv4 routes between PE-routers. All non-VPN BGP neighbors (other PE-routers and other global BGP peers) have to be defined under the router bgp configuration mode. All VPN BGP neighbors (for example, a CE router exchanging routes with a PE-router through BGP) are defined under its associated address-family. The BGP process (with no address-family specified) is the default address-family where any sessions are configured that either are not associated with a VRF or are used to carry IPv4 routes from the global routing table.

The configuration of the BGP sessions that carry IPv4 routes from the global routing table is exactly the same as the standard BGP configuration, with the exception that the session needs to be activated. The neighbor command controls the activation of the session, as shown in Example 9-17. This example also shows all the relevant commands used to establish an IPv4 BGP session between the SuperCom San Jose PE-router and the New York PE-router (this example assumes that the New York router is configured already).

Example 9-17 Activation of Standard IPv4 BGP Sessions


San Jose(config)# router bgp 1

San Jose(config-router)# neighbor 194.22.15.3 remote-as 1

San Jose(config-router)# neighbor 194.22.15.3 update-source loopback0

San Jose(config-router)# neighbor 194.22.15.3 activate

The BGP process activates the MP-iBGP session that carries VPN-IPv4 prefixes through the use of the BGP's own address-family. This configuration creates a routing context for exchanging VPN-IPv4 prefixes. Example 9-18 shows the syntax of this command and the relevant command to configure the MP-iBGP session between the SuperCom San Jose and New York routers in the case study.

Example 9-18 Address-Family Configuration for VPN-IPv4 Route Exchange


San Jose(config)#router bgp 1

San Jose(config-router)#address-family ?

  ipv4   Address family

  vpnv4  Address family



San Jose(config-router)#address-family vpnv4

San Jose(config-router)#neighbor 194.22.15.3 activate

Note

In Example 9-18, notice that the VPNv4 address-family configuration needs only one command. This is because the BGP neighbor must be configured under the global BGP process, and therefore needs to be activated to carry only VPN-IPv4 prefixes.

The configuration of the vpnv4 address-family also adds a further command to the BGP configuration. This command is neighbor x.x.x.x send-community extended. This command is added by default and is necessary because it instructs BGP to advertise the extended community attribute discussed earlier in this chapter. Example 9-19 provides the syntax of this command.

Example 9-19 Advertisement of Extended Community Attribute


San Jose(config-router)#neighbor 194.22.15.3 send-community ?

  both      Send Standard and Extended Community attributes

  extended  Send Extended Community attribute

  standard  Send Standard Community attribute

  <cr>

Note

The default behavior is to send only the extended community attribute. If the network design requires the standard community attribute to be attached to VPN routes, change the default configuration using the command neighbor 194.22.15.3 send-community both.

As you already know, after the VRF is populated with any customer routes, these routes need to be advertised across the MPLS/VPN backbone. MP-iBGP performs this job by carrying these routes as VPN-IPv4 prefixes across the MP-iBGP sessions between PE-routers. To allow this to happen, the routing context needs to be configured within the BGP process to tell BGP which VRF routes to advertise.

Again, you achieve this using the address-family configuration under the BGP process, using the ipv4 option of the address-family command used in Example 9-18. Each VRF that injects routes into BGP needs to be configured under the BGP process using its own address-family. Also, any routes that belong to VRFs associated with these address-families must be redistributed into BGP if they are to be advertised across the PE-router's MP-iBGP sessions to other PE-routers.

Putting this all together, you can see the final configuration for the SuperCom San Jose PE-router in Example 9-20.

Example 9-20 Final Configuration for the SuperCom San Jose PE-router


hostname San Jose

!

ip vrf Eurobank

 rd 1:27

 route-target export 100:27

 route-target import 100:27

!

ip vrf FastFoods

 rd 1:26

 route-target export 100:26

 route-target import 100:26

!

interface loopback0

 ip address 194.22.15.2 255.255.255.255

!

interface serial0

 description ** interface to Eurobank San Francisco**

 ip vrf forwarding EuroBank

 ip address 10.2.1.5 255.255.255.252

!

interface serial1

 description ** interface to FastFoods San Jose**

 ip vrf forwarding FastFoods

 ip address 195.12.2.5 255.255.255.252

!

router rip

 version 2

 !

address-family ipv4 vrf EuroBank

 version 2

 redistribute bgp 1 metric 1

 network 10.0.0.0

 no auto-summary

exit-address-family

!

address-family ipv4 vrf FastFoods

 version 2

 redistribute bgp 1 metric 1

 network 195.12.2.0

 no auto-summary

exit-address-family

!

router bgp 1

 no bgp default ipv4-unicast

 neighbor 194.22.15.3 remote-as 1

 neighbor 194.22.15.3 update-source loopback0

 neighbor 194.22.15.3 activate

 neighbor 194.22.15.1 remote-as 1

 neighbor 194.22.15.1 update-source loopback0

!

address-family ipv4 vrf EuroBank

 redistribute rip metric 1

 no auto-summary

 no synchronization

exit-address-family

!

address-family ipv4 vrf FastFoods

 redistribute rip metric 1

 no auto-summary

 no synchronization

exit-address-family

!

address-family vpnv4

 neighbor 194.22.15.3 activate

 neighbor 194.22.15.3 send-community extended

 neighbor 194.22.15.1 activate

 neighbor 194.22.15.1 send-community extended

exit-address-family

!

Enhanced BGP Decision Process for VPN-IPv4 Prefixes

The route target BGP extended community and the route distinguisher control the VPN-IPv4 route selection. This process occurs after routes are learned from other PE-routers across MP-iBGP sessions but before these routes are imported into any VRFs.

The first step of the BGP decision process is to group all relevant routes so they can be compared. Before the PE-router can select routes, it has to know which VPN routes exist and which of these routes should be comparable with each other by the BGP selection process. When the PE-router is provisioned for VPN service, each VRF is configured with statements that tell the PE-router which routes should be imported into the VRF. You already know that the route target BGP extended community controls this import process. Armed with this information, the PE-router does the following:

Takes all routes with the same route target as any of the import statements within the VRF.
Considers all routes that have the same route distinguisher as the one assigned to the VRF being processed.
Creates new BGP paths with a Route Distinguisher that is equal to the Route Distinguisher configured for the VRF that is being processed.

All the routes are now comparable and, at this point, the BGP selection process is executed.

It is important to understand that this process can influence the amount of memory required to hold VPN routes on the PE-router. If each PE-router uses a different route distinguisher for each VRF of a particular VPN, the amount of memory needed to store all the VPN routes increases. Figure 9-8 provides an example of how the route distinguisher can influence the memory requirements of the PE-router.

Figure 9-8. Increased PE Memory Requirement with Different Route Distinguisher

graphics/09fig08.gif

Figure 9-8 shows that the SuperCom San Jose router receives an MP-iBGP update from the Paris PE-router, and this update contains a route target of 100:27 and a route distinguisher of 1:28. The San Jose PE-router is configured to import any routes with a route target of 100:27 into the EuroBank VRF, and this it does. However, the BGP table contains two paths, one with a route distinguisher of 1:28 (the original one received) and another with a route distinguisher of 1:27, which is the route distinguisher for the EuroBank VRF on this PE-router. See Example 9-21.

Example 9-21 Increased PE Memory with Different Route Distinguishers


San Jose# show ip bgp vpnv4 all

BGP table version is 31, local router ID is 194.22.15.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete



   Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:27 (default for vrf EuroBank)

*>i197.1.1.1/32     194.22.15.1                  0    100      0 ?

Route Distinguisher: 1:28

*>i197.1.1.1/32     194.22.15.1                  0    100      0 ?



San Jose# show ip bgp vpnv4 all 197.1.1.1

BGP routing table entry for 1:27:197.1.1.1/32, version 31

Paths: (1 available, best #1, table EuroBank)

  Advertised to non peer-group peers:

  10.2.1.25

  Local, imported path from 1:28:197.1.1.1/32

    194.22.15.1 (metric 10) from 194.22.15.1 (197.1.1.1)

      Origin incomplete, metric 0, localpref 100, valid, internal, best

      Extended Community: RT:100:27



BGP routing table entry for 1:28:197.1.1.1/32, version 30

Paths: (1 available, best #1, table NULL)

  Not advertised to any peer

  Local

    194.22.15.1 (metric 10) from 194.22.15.1 (197.1.1.1)

      Origin incomplete, metric 0, localpref 100, valid, internal, best

      Extended Community: RT:100:27

After the best routes are selected, the import process begins. This involves the process of importing routes into all VRFs and filtering any unwanted routing information from particular VRFs.