Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Example: Distribution of Routes and Labels with BGP

    The extensions to BGP include enhancements to update messages that enable them to carry the route distinguishers, route-target extended-community information, and MPLS labels required for BGP/MPLS VPNs.

    Consider the simple example shown in Figure 1. The customer edge devices are connected with their associated provider edge routers by external BGP sessions (CE 1—;PE 1 and CE 3—PE 2). PE 1 and PE 2 are BGP peers by an internal BGP session across the service provider core in AS 777.

    In this example, the PE routers run EBGP to the CE routers to do the following:

    • Learn the prefixes of the networks in the local customer site.
    • Advertise routes to networks and remote customer sites.

      Figure 1: Route and Label Distribution

      Route and Label Distribution

    Rather than running EBGP between the PE routers and the CE routers, you can do either of the following:

    • Run an IGP (such as IS-IS, OSPF, or RIP) between the CE router and the PE router.
    • Configure static routes on the CE and PE routers (on the CE router this would typically be a default route).

    In this example the two customer sites use different AS numbers, which simplifies configuration. Alternatively, the same AS numbers can be used.

    Customer site 1 has two networks that need to be reachable from customer site 3—10.3.0.0/16 and 10.12.0.0/16—and uses BGP to announce these prefixes to PE;1. CE 1 uses a standard BGP update message as shown in Figure 2 to carry this and additional information. CE 1 is withdrawing prefix 10.1.0.0/16. CE 1 specifies its own address as the next hop; 10.4.1.1 is from the private address space of VPN A.

    PE 1 passes the advertisement along the backbone through an IBGP session, but uses MP-BGP rather than standard BGP-4. Consequently, PE 1 uses an extended BGP update message, which is different in format from the standard message, as shown in Figure 2.

    The extended update uses different attributes for some of the advertised information. For example it carries the advertised prefixes in the MP-Reach-NLRI attribute instead of the NLRI attribute. Similarly, it uses the MP-Unreach-NLRI attribute for withdrawn routes rather than the withdrawn-routes attribute.

    PE 1 advertises the customer site addresses by prepending information to the addresses as advertised by CE 1, thus creating labeled VPN-IPv4 prefixes. The prepended information consists of a route distinguisher and an MPLS label.

    Because the CE router uses IPv4 addresses from the VPN’s private address space, these addresses can be duplicated in other VPNs to which PE 1 is attached. PE 1 associates a route distinguisher with each IPv4 address to create a globally unique address. In this example, the RD consists of the AS that PE 1 belongs to and a number that PE 1 assigns. The RD is prepended immediately before the IPv4 address.

    PE routers assign MPLS labels to each VRF. In this example, the label for the VRF associated with customer site 1 is 16. The MPLS label is prepended immediately before the route distinguisher.

    Note: The explicit null label is prepended only to routes that are being withdrawn in the MP-REACH-NLRI attribute.

    Some non–E Series implementations allocate a separate label for each prefix. By default, the E Series router generates one label for all BGP routes advertised by the VRF, thus reducing the number of stacked labels to be managed. The ip mpls forwarding-mode label-switched command enables you to have the router generate a label for each different FEC pointed to by a BGP route in a given VRF. However, some routes always receive a per-VRF label; see Understanding Labels Creation per FEC for more information.

    Figure 2: Standard and Extended BGP Update Messages

    Standard and Extended BGP Update Messages

    Using the next-hop-self option on PE 1 causes PE 1 to set the next-hop attribute to its own address, 172.32.12.1. Doing so is necessary because the next hop provided by CE 1 is from VPN A’s private address space and has no meaning in the service provider core. In addition, PE 2 must have PE 1’s address so that it can establish an LSP back to PE 1. The next-hop address must also be carried in the MP-Reach-NLRI attribute, according to MP-BGP.

    The extended update also has the extended-communities attribute, which identifies the VPN to which the routes are advertised. In this example, the route target is 777:1001, identifying VPN A.

    Published: 2014-08-18