L3VPN

Layer 3 Virtual Private Network

3.1.b PE-P routing (Not on blueprint)

Provider Edge (Router)

Provider (Core) (Router)

General information on “MPLS PE-P routing”:

• Also called MPLS core
• Several components needed:
  1. Loopback interfaces on all PE/P routers
  2. Links configured between all PE/P routers
  3. IGP configured between all PE/P routers (most commonly OSPF or IS-IS)
  4. LDP configured on all PE/P routers
  5. MPLS enabled between all PE/P routers
  6. MP-BGP VPNv4/v6 configured between PE routers only

“MPLS PE-P routing” CLI configuration commands:

## Configuring the MPLS core using OSPF with MPLS LDP autoconfig on its OSPF-enabled interfaces
Router(config)# router ospf <pid>
Router(config-router)# network <network> <mask> area <area-id>
Router(config-router)# mpls ldp autoconfig

## Disabling/Enabling MPLS on interfaces manually
Router(config)# interface <if>
Router(config-if)# [no] mpls ip

• Important: More information about detailed LDP/MP-BGP VPN configuration can be found at 3.1.a MPLS Operations and on this page below!

3.1.b i PE-CE routing

Provider Edge (Router)

Customer Edge (Router)

General information on “MPLS PE-CE routing”:

• Used to exchange routes between customer site and provider network
• Every PE interface connected to a CE router needs to be put in the appropriate VRF
• Normally no specific VRF configuration needed on CE routers!

Routing between PE and CE can be done with…:

• Static Routes
• BGP:
  • If two sites of the same customer have the same ASN, they don’t receive their routes
  • This is due to the BGP loop prevention mechanism (if the own AS is in the AS_Path, then routes don’t get installed)
  • This can be fixed with either allowas-in on the CE side site or as-override on the PE side
• EIGRP:
  • Routes between two sites over MPLS are considered as internal EIGRP routes
  • EIGRP vector values get encoded into the packets as MP-BGP extended communities
• OSPF:
  • PE router always count as ABRs
  • MPLS Core = Superbackbone Area = above area 0
  • If multiple areas are used at a site, area 0 must be between the PE and CE or else a virtual-link between the PE and the nearest ABR of area 0 is needed
• OSPF with backdoor link:
  • Even if both sides are in the same OSPF area, routes from one side will never be “O” (Intra-Area) on the other side
  • If the OSPF domain-id does match on both PE routers, routes get considered as LSA type 3 (“O IA”, inter-area)
  • If the OSPF domain-id doesn’t match on both PE Routers, routes get considered as LSA type 5 (“E2”, External 2)
  • The domain-id (inherited from the OSPF PID) can also be set manually so that it is independent from the OSPF PID
  • This can lead to suboptimal routing when a backdoor link exists since the routes propagated across the backdoor link will be considered as “O” (Intra-Area)
  • To overcome the issue of routes over MPLS never become “O” (Intra-Area), a “sham-link” can be created over the MPLS L3 VPN
  • A Sham-Link is an OSPF tunnel between the PE routers over the already existing MPLS tunnel, which extends the flooding domain
  • The Sham-Link is built on-top/over MP-BGP
  • After a Sham-Link is established, the routes between neighbors will be “O” (Intra-Area) since routes don’t get converted but rather will preserve their type
  • Sham-Link configuration (on PE router):
    1. Create a loopback interface within the customer VRF on each PE router
    2. Advertise the loopback interface with BGP under the address-family ipv4 vrf with the network statement
    3. Deny the Sham-Links from redistributing to the CE routers when redistributing from BGP to OSPF (eg. with route-map)
    4. Configure the sham-link under the OSPF VRF process between the PE routers
  • Important: When using OSPF w/ VRFs on CE routers, the capability vrf-lite command must be entered or else the CE router will block all incoming routes (because the DOWN-bit is set)!

Redistribution requirements:

• eBGP (CE/PE) = No redistribution on PEs needed
• Everything else (CE/PE) = Redistribution from/to iBGP on PEs needed

“MPLS PE-CE routing” CLI configuration commands:

## =========================
##  PE-CE routing with EIGRP
##  ========================

## CE configuration with EIGRP classic mode
Router(config)# router eigrp <asn>
Router(config-router)# network <network> <mask>

## CE configuration with EIGRP named mode
Router(config)# router eigrp <WORD>
Router(config-router)# address-family ipv4 autonomous-system <asn>
Router(config-router-af)# network <network> <mask>

## PE configuration with EIGRP classic mode
Router(config)# router eigrp <asn>
Router(config-router)# address-family ipv4 vrf <vrf> autonomous-system <asn>
Router(config-router-af)# network <network> <mask>
Router(config-router-af)# topology base
Router(config-router-af-topology)# redistribute bgp <asn>

## PE configuration with EIGRP named mode
Router(config)# router eigrp <WORD>
Router(config-router)# address-family ipv4 vrf <vrf> autonomous-system <asn>
Router(config-router-af)# network <network> <mask>
Router(config-router-af)# topology base
Router(config-router-af-topology)# redistribute bgp <asn>

## PE redistribution from EIGRP to BGP
Router(config)# router bgp <asn>
Router(config-router)# address-family ipv4 vrf <vrf>
Router(config-router-af)# redistribute eigrp <asn>


## ========================
##  PE-CE routing with OSPF
## ========================

## CE configuration with OSPF
Router(config)# router ospf <pid>
Router(config-router)# network <network> <mask>

## PE configuration with OSPF
Router(config)# router ospf <pid> vrf <vrf
Router(config-router)# network <network> <mask>
Router(config-router)# redistribute bgp <asn>

## PE redistribution from OSPF to BGP
Router(config)# router bgp <asn>
Router(config-router)# address-family ipv4 vrf <vrf>
Router(config-router-af)# redistribute ospf <pid>


## =======================
##  PE-CE routing with BGP
## =======================

## CE configuration with BGP
Router(config)# router bgp <asn>
Router(config-router)# neighbor <ip> remote-as <asn>
Router(config-router)# redistribute [OPTIONS]

## PE configuration with BGP
Router(config)# router bgp <asn>
Router(config-router)# address-family ipv4 vrf <vrf>
Router(config-router-af)# neighbor <ip> remote-as <asn>

3.1.b ii MP-BGP VPNv4/VPNv6

General information on “MP-BGP”:

• MP-BGP (Multiprotocol BGP) is an extension of the BGP protocol
• Allows the parallel distribution of different protocols under a single BGP process
• While “normal” BGP only supports IPv4 unicast, MP-BGP also supports IPv6 and multicast
• With MP-BGP, everything is configured under the corresponding address-family option

General information on “MP-BGP VPNv4/VPNv6”:

• VPNv4 and VPNv6 are configured between PE’s under the address-family option
• VPNv4 and VPNv6 are used for exchange of VPN labels within a MPLS L3 VPN
• VPNv4 = Used for IPv4 over IPv4-based MPLS core
• VPNv6 = Used for IPv6 over IPv4-based MPLS core
• Important: Although VPNv6 implies using the IPv6 address of a neighbor, VPNv6 relies on an IPv4-based MPLS core! Building an IPv6-only MPLS core is not yet implemented in Cisco IOS!

“MPLS MP-BGP VPNv4/VPNv6” CLI configuration commands:

## Configuring MP-BGP VPNv4/VPNv6
Router(config)# router bgp <asn>
Router(config-router)# no bgp default ipv4-unicast
Router(config-router)# neighbor <ip> remote-as <asn>
Router(config-router)# neighbor <ip> update-source <if-or-ip>
Router(config-router)# address-family [vpnv4 | vpnv6]
Router(config-router-af)# neighbor <ip> activate
Router(config-router-af)# neighbor <ip> send-community extended

3.1.b iii Extranet (route leaking)

General information on “MPLS Extranet (route leaking)":

• Route leaking is pushing routes from one VRF to another VRF where they originally didn’t belong to
• This allows for inter-VRF routing
• Route leaking is done via the route-target import/export configuration
• Example: Several customers use VRF and two customers want to share routes between each other

“MPLS Extranet (route leaking)” CLI configuration commands:

## Configuring MPLS route leaking using route-targets
Router(config)# vrf definition <vrf-name>
Router(config-vrf)# route-target [import | export | both] <rt>

3.1.b QoS for MPLS (not on blueprint)

General information on “QoS for MPLS”:

• Rule 1: By default, the precedence bits/first three bits of the DSCP field in the IP header will be copied into the EXP field of the MPLS header at the ingress LSR (where the label push happens).
• Rule 2: By default, the EXP field bits of the incoming top label are copied to the swapped outgoing label and to any label pushed on top of it.
• Rule 3: By default, the EXP field bits of the incoming top label are not copied to the labels below when the top label is popped.
• Rule 4: By default, the EXP field bits of the incoming top label are not copied to the IP header when the label stack is removed.
• Rule 5: When manually modifying the EXP Bits, this only affects the top label.
• These rules result in two things:
  • The QoS parameters of the IP header can be preserved end-to-end through the MPLS network/the LSP
  • The QoS parameters of the IP header and MPLS header can be different
• When applying QoS parameters to the IP header of the packet, it will be preserved end-to-end bidirectional (= precedence/dscp value is valid from the source to the destination and back unless it gets modified in between)
• When applying QoS parameters to the MPLS header of the packet, it will be preserved end-to-end unidirectional (= EXP value is only valid from the ingress PE to the egress PE and additionally only unless it gets modified in between)

Configuration considerations:

• The topmost keyword only affects the current topmost MPLS label at the current point of the interface (ingress/egress)
• The imposition keyword affects all MPLS label at the current point of the interface (ingress/egress)

“QoS for MPLS” CLI configuration commands:

## Modifying the MPLS imposition/topmost label
Router(config)# policy-map [NAME]
Router(config-pmap)# class [CLASS-MAP-NAME]
Router(config-pmap-c)# set mpls experimental [imposition | topmost] <value>