Figure 1. Chassis as MPLS-CE Connected to PE

The system in this scenario uses static/dynamic MPLS labels for ingress and egress traffic. For configuration information on static label, refer to the Configuring BGP/​MPLS VPN with Static Labels section and refer to Configuring BGP/​MPLS VPN with Static Labels for dynamic label configuration.

The system is in a separate autonomous system (AS) from the Provider Edge (PE). It communicates with the PE and all VPN routes are exchanged over MP-BGP. Routes belonging to different VPNs are logically separated, using separate virtual route forwarding tables (VRFs).

Routes for each VPN are advertised as VPN-IPv4 routes, where route distinguishers are prepended to regular IPv4 routes to allow them to be unique within the routing table. Route targets added to the BGP extended community attributes identify different VPN address spaces. The particular upstream BGP peer routing domain (VPN), from which a route is to be imported by the downstream peer into an appropriate VRF, is identified with an extended community in the advertised NLRI.

A unique label is also received or advertised for every VPN route.

The Customer Edge (CE) also advertises routes to the PE using NLRIs that include route distinguishers to differentiate VPNs, an extended community to identify VRFs, and a MPLS-label, which will later be used to forward data traffic.

There is a single MPLS-capable link between the CE and the PE. MP-BGP communicates across this link as a TCP session over IP. Data packets are sent bidirectionally as MPLS encapsulated packets.

This solution does not use any MPLS protocols. The MPLS label corresponding to the immediate upstream neighbor can be statically configured on the downstream router, and similarly in the reverse direction.

When forwarding subscriber packets in the upstream direction to the PE, the CE encapsulates packets with MPLS headers that identify the upstream VRF (the label sent with the NLRI) and the immediate next hop. When the PE receives a packet it swaps the label and forward.

The CE does not run any MPLS protocol (LDP or RSVP-TE).

When receiving data packets in the downstream direction from the PE, the label is checked to identify the destination VRF. Then the packet is de-encapsulated into an IP packet and sent to the session subsystem for processing.

Figure 2. Chassis as MPLS-CE Connected to ASBR

The system in this scenario uses static/dynamic MPLS labels for ingress and egress traffic. For configuration information on static label, refer to Configuring BGP/​MPLS VPN with Static Labels and refer to Configuring BGP/​MPLS VPN with Dynamic Labels for dynamic label configuration.

This scenario differs from the MPLS-CE with PE scenario in terms of peer functionality even though MPLS-CE functionality does not change. Like the MPLS-CE with PE scenario, MPLS-CE system maintains VRF routes in various VRFs and exchanges route information with peer over MP-eBGP session.

The peer in this scenario is not a PE router but an Autonomous System Border Router (ASBR). The ASBR does not need to maintain any VRF configuration. The PE routers use IBGP to redistribute labeled VPN-IPv4 routes either to an ASBR or to a route reflector (of which the ASBR is a client). The ASBR then uses the eBGP to redistribute those labeled VPN-IPv4 routes to an MPLS-CE in another AS. Because of the eBGP connection, the ASBR changes the next-hop and labels the routes learned from the iBGP peers before advertising to the MPLS-CE. The MPLS-CE is directly connected to the eBGP peering and uses only the MP-eBGP to advertise and learn routes. The MPLS-CE pushes/pops a single label to/from the ASBR, which is learned over the MP-eBGP connection. This scenario avoids the configuration of VRFs on the PE, which have already been configured on the MPLS-CE.

Use this example to first create a VRF on the router and assign a VRF name. The second ip vrf command creates the route-distinguisher and route-target.

configure
   context <context_name> -noconfirm
      ip vrf <vrf_name>
         router bgp <as_number>
            ip vrf <vrf_name>
               route-distinguisher {<as_value> | <ip_address>} <rt_value>
               route-target export {<as_value> | <ip_address>} <rt_value>
               end

Use this example to set the neighbors and address family to exchange VPNv4 routing information with a peer router.

configure
   context <context_name> 
      router bgp <as_number>
         neighbor <ip_address> remote-as <AS_num>
         address-family vpnv4
         neighbor <ip_address> activate
         neighbor <ip_address> send-community both
         exit
      interface <bind_intfc_name>
         ip address <ip_addr_mask_combo>
         end

Use this example to first create a VRF on the router and assign a VRF name. The second ip vrf command creates the route-distinguisher and route-target.

configure
   context <context_name> -noconfirm
      ip vrf <vrf_name>
      router bgp <as_number>
         ip vrf <vrf_name>
            route-distinguisher {<as_value> | <ip_address>} <rt_value>
            route-target export {<as_value> | <ip_address>} <rt_value>
            route-target import {<as_value> | <ip_address>} <rt_value>
            end

Use this example to set the neighbors and address family to exchange VPNv4 routing information with a peer router.

configure
   context <context_name> 
      mpls bgp forwarding
      router bgp <as_number>
         neighbor <ip_address> remote-as <AS_num>
         address-family vpnv4
         neighbor <ip_address> activate
         neighbor <ip_address> send-community both
         exit
      interface <bind_intfc_name>
         ip address <ip_addr_mask_combo>
         end

Use this example to modify the configured IP VRF to support QoS mapping.

configure
   context <context_name>
      ip vrf <vrf_name>
         mpls map-dscp-to-exp dscp <dscp_bit_value> exp <exp_bit_value>
         mpls map-exp-to-dscp exp <exp_bit_value> dscp <dscp_bit_value>
         end