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.


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


interface serial 1

 description ** interface to EuroBank San Francisco **

 ip vrf forwarding EuroBank 

 ip address


router bgp 1

 no bgp default ipv4-unicast

 neighbor remote-as 1

 neighbor update-source loopback0


address-family ipv4 vrf EuroBank

 neighbor remote-as 65002

 neighbor activate

 no auto-summary

 no synchronization



address-family ipv4 vrf FastFoods

 neighbor remote-as 65001

 neighbor activate

 no auto-summary

 no synchronization



address-family vpnv4

 neighbor activate

 neighbor send-community extended


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.


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, vrf EuroBank, remote AS 65002, external link

  BGP version 4, remote router ID

  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

    Part 2: MPLS-based Virtual Private Networks