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.
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
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.
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
184.108.40.206/32 0.0.0.0 46/aggregate(EuroBank)
220.127.116.11/32 10.2.1.25 51/notag
18.104.22.168/32 10.2.1.25 52/notag
New York# show ip bgp neighbor 22.214.171.124 BGP neighbor is 126.96.36.199, remote AS 1, internal link BGP version 4, remote router ID 188.8.131.52 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
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.
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).
San Jose(config)# router bgp 1 San Jose(config-router)# neighbor 184.108.40.206 remote-as 1 San Jose(config-router)# neighbor 220.127.116.11 update-source loopback0 San Jose(config-router)# neighbor 18.104.22.168 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.
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 22.214.171.124 activate
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.
San Jose(config-router)#neighbor 126.96.36.199 send-community ? both Send Standard and Extended Community attributes extended Send Extended Community attribute standard Send Standard Community attribute <cr>
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 188.8.131.52 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.
hostname San Jose
ip vrf Eurobank
route-target export 100:27
route-target import 100:27
ip vrf FastFoods
route-target export 100:26
route-target import 100:26
ip address 184.108.40.206 255.255.255.255
description ** interface to Eurobank San Francisco**
ip vrf forwarding EuroBank
ip address 10.2.1.5 255.255.255.252
description ** interface to FastFoods San Jose**
ip vrf forwarding FastFoods
ip address 220.127.116.11 255.255.255.252
address-family ipv4 vrf EuroBank
redistribute bgp 1 metric 1
address-family ipv4 vrf FastFoods
redistribute bgp 1 metric 1
router bgp 1
no bgp default ipv4-unicast
neighbor 18.104.22.168 remote-as 1
neighbor 22.214.171.124 update-source loopback0
neighbor 126.96.36.199 activate
neighbor 188.8.131.52 remote-as 1
neighbor 184.108.40.206 update-source loopback0
address-family ipv4 vrf EuroBank
redistribute rip metric 1
address-family ipv4 vrf FastFoods
redistribute rip metric 1
neighbor 220.127.116.11 activate
neighbor 18.104.22.168 send-community extended
neighbor 22.214.171.124 activate
neighbor 126.96.36.199 send-community extended
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 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.
San Jose# show ip bgp vpnv4 all BGP table version is 31, local router ID is 188.8.131.52 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) *>i184.108.40.206/32 220.127.116.11 0 100 0 ? Route Distinguisher: 1:28 *>i18.104.22.168/32 22.214.171.124 0 100 0 ? San Jose# show ip bgp vpnv4 all 126.96.36.199 BGP routing table entry for 1:27:188.8.131.52/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:184.108.40.206/32 220.127.116.11 (metric 10) from 18.104.22.168 (22.214.171.124) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:100:27 BGP routing table entry for 1:28:126.96.36.199/32, version 30 Paths: (1 available, best #1, table NULL) Not advertised to any peer Local 188.8.131.52 (metric 10) from 184.108.40.206 (220.127.116.11) 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.