BGP-4 Between Service Provider and Customer Networks
A certain number of customers that attach to the MPLS/VPN backbone will want to run BGP-4 with the service provider and exchange VPN routes across these BGP-4 sessions. Later in this chapter, we will see a sample network deployment in which this type of connectivity may be attractive, or even necessary, for the customer. With this option, all the routes that are learned from the customer CE-router will be advertised across the MPLS/VPN backbone using any existing MP-iBGP sessions between service provider PE-routers (or route reflectors). Figure 10-2 provides an illustration of this type of connectivity.
Figure 10-2. BGP-4 Between CE- and PE-routers
As can be seen in Figure 10-2, both the FastFoods and EuroBank customers attach to the SuperCom MPLS/VPN backbone using BGP-4. With this configuration, any routes learned across the session with the EuroBank CE-routers will be placed into the VRF associated with this customer. Likewise, any routes learned across the session with the FastFoods CE-routers will be placed into these customers' respective VRF.
From the standpoint of the VPN customer, this is just a standard exterior BGP-4 session with which the exchange of IPv4 prefixes can be achieved. However, from the PE-router's perspective, although the session is a standard exterior BGP-4 session, it must understand which VPN customer the session belongs to and into which VRF the routes should be placed when received from the BGP neighbor. As with the static and RIP Version 2 examples that we saw in the previous chapter, this is achieved through the use of a routing context that is represented through an address family under the BGP process configuration.
There are two main requirements for BGP configuration in an MPLS/VPN environment. The first is the configuration of MP-iBGP sessions between PE-routers; the second is the configuration of BGP between PE- and CE-routers. To achieve this second objective, the address family must be configured under the BGP process for each VRF that will receive routes from a VPN customer using BGP-4.
Note
A separate address family entry is used per VRF, and each address family entry could have multiple BGP neighbors (customer CE-routers) within the VRF.
Using the address assignments from Table 10-1 for the VPN customers FastFoods and EuroBank, we can see in Figure 10-3 the necessary BGP sessions between the SuperCom San Jose and Paris PE-routers, and each of the VPN customers.
Figure 10-3. BGP-4 Address Assignment Between PE- and CE-routers
Given the address assignments within Figure 10-3, the PE-router configuration, similar to the one in Example 10-1, can be used to configure BGP routing on the SuperCom San Jose PE-router. Notice within this configuration the use of address families under the BGP process for each VPN customer, and the relevant BGP session configurations for each customer under the address-family.
Example 10-1 PE-to-CE BGP-4 Configuration Example
hostname San Jose ! interface serial0 description ** interface to FastFoods San Jose ** ip vrf forwarding FastFoods ip address 195.12.2.6 255.255.255.252 ! interface serial 1 description ** interface to EuroBank San Francisco ** ip vrf forwarding EuroBank ip address 10.2.1.6 255.255.255.252 ! router bgp 1 no bgp default ipv4-unicast neighbor 194.22.15.1 remote-as 1 neighbor 194.22.15.1 update-source loopback0 ! address-family ipv4 vrf EuroBank neighbor 10.2.1.5 remote-as 65002 neighbor 10.2.1.5 activate no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf FastFoods neighbor 195.12.2.5 remote-as 65001 neighbor 195.12.2.5 activate no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor 194.22.15.1 activate neighbor 194.22.15.1 send-community extended exit-address-family
As can be seen from Example 10-1, the SuperCom San Jose PE-router has an eBGP session with the EuroBank San Francisco CE-router. Any routes learned over this session will be placed into the EuroBank VRF. A further eBGP session exists with the FastFoods San Jose CE-router, and any routes learned across this session will be placed into the FastFoods VRF.
Note
The BGP-4 session between the PE- and CE-routers must be directly connected. BGP multihop is not currently supported on BGP sessions between PE- and CE-routers.
Example 10-2 provides confirmation that the BGP-4 session between the PE- and CE-router (for the EuroBank VRF) is established and that IPv4 routes will be placed into the relevant VRF.
Example 10-2 show ip bgp neighbor Confirmation of PE-to-CE BGP-4 Session
San Jose# show ip bgp neighbor BGP neighbor is 10.2.1.5, vrf EuroBank, remote AS 65002, external link BGP version 4, remote router ID 10.2.1.5 BGP state = Established, up for 00:00:38 Last read 00:00:37,hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received Address family IPv4 Unicast: advertised and received Received 4 messages, 0 notifications, 0 in queue Sent 3 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Minimum time between advertisement runs is 30 seconds For address family: VPNv4 Unicast Translates address family IPv4 Unicast for VRF EuroBank BGP table version 3, neighbor version 3 Index 1, Offset 0, Mask 0x2 1 accepted prefixes consume 60 bytes Prefix advertised 0, suppressed 0, withdrawn 0 Connections established 1; dropped 0 Last reset never
