MPLS VPN Implementation

Layer 3 VPN: Terms and Concepts (1 of 2) Layer 3 VPNs Includes CE devices Reside on the customer premises Includes PE devices Maintains VPN-specific forwarding tables Exchanges VPN routing information with other PE routers using BGP Uses MPLS LSPs to forward VPN traffic Can include P devices Forward VPN data transparently over established LSPs Do not maintain VPN specific routing information

Layer 3 VPN: Terms and Concepts (2 of 2) Sites and tables VPN sites Collection of devices that communicate with each other without using the service provider backbone Each site is mapped to a PE device interface VRF table Populated with routes received from directly connected CEs, and routes received from other PE routers with MP-BGP attributes Packets from a given site are only matched against the routes in a site’s corresponding VRF table

PE to PE Exchanges MPLS LSPs core Layer 3 VPN NLRI MP-BGP next-hop attribute Must resolve in inet.3 routing table Label swap operation Layer 3 VPN NLRI PE to PE exchanges require the VPN-IPv4 NLRI Mask, MPLS label, route distinguisher, and IPv4 prefix Ingress PE router prepends route distinguisher to IPv4 prefix of routes received from each CE device VPN-IPv4 routes are exchanged between PE routers using MP-BGP Egress PE router converts VPN-IPv4 routes into IPv4 routes before inserting into site’s routing (VRF) table

VRF Tables Separate customer routing tables Route distinguisher Local and directly connected routes Customer learned routes Routes received from other PE sites Route distinguisher Maintain unique routing information Two values are defined for type field: 0 and 1 Type 0: adm field = 2 bytes, AN field = 4 bytes Type 1: adm field = 4 bytes, AN field = 2 bytes Route target information Extended BGP community Import and export target

VRF Routing Policy Can create VRF import and export policies Controls the routes that are sent and accepted in a VPN Compares incoming routes against the target community Adds the target community to routes before they are advertised Can apply the vrf-target option Automatically creates an import and export policy based on the target community specified Routing instance auto-export Allows communication between VRF tables on the same PE router by automatically sharing routes RIB groups Allows communication between VRF tables on the same PE router by manually sharing routes

PE to CE Routing Protocols Static routing PE and CE routers configured with static routes BGP routing External BGP peering as-override origin community Internal BGP peering independent-domain OSPF routing Carries OSPF routes across backbone as BGP routes Two methods to advertise OSPF routes between sites sham-link domain-identifier RIP routing

PE to CE Policies and Firewalls Import and export policies can be applied to VRF instances for the PE to CE routing protocols BGP and RIP allow both import and export policies OSPF allows export policies and limits import policies that set priority or filter OSPF external routes Reject action is ignored if applied to a non-external route on an import policy Affects routes being sent and received over the PE-CE link Firewall filters can be applied to logical interfaces

VPN Considerations (1 of 2) Hub-and-spoke Reduces the number of BGP sessions and LSPs needed Spoke to spoke communication must transit the hub site Requires two VRF instances on the hub site Requires two interfaces from PE to CE Can be logical interfaces on the same physical interface IPv6 VPNs PE to CE interfaces can be configured for IPv6 Must enable inet6-vpn family for the MP-BGP session Must configure BGP, OSPF version 3, or static routes for PE to CE routing Can operate in conjunction with IPv4 routing in the same VPN

VPN Considerations (2 of 2) vrf-table-label option Uses LSP sub-interface abstract Creates an LSI that maps to each VRF table Supported core-facing interfaces map reserved MPLS labels to each VRF LSI Caveats: Only supported on limited interface types Not supported for MP-BGP-labeled routes (interprovider and carrier-of-carrier VPNs) VPN tunnel interface Requires a tunnel services PIC Causes Internet Processor II lookups on the Egress PE Rather than forward the packet directly out the physical VRF interface, the resulting IP packet from the first lookup is sent to the tunnel service interface (next hop equals the vt-x/y/z interface)

VPN Scalability Route reflection Route target filtering Reduces the number of MP-BGP sessions Typically configured on a P router Requires the NLRI families be configured within the cluster The bgp.l3vpn.inet.0 table requires PE reachability through inet.3 LDP or RSVP unidirectional full mesh Static default route Route target filtering PE sends a list of route targets locally configured to the route reflector The route-target NLRI must be enabled on MP-BGP sessions Route reflector only sends routes with the specified route targets to PE router

Providing VPN Internet Access Distributed Internet access Option 1: Two separate logical circuits One circuit configured in VRF One circuit configured for Internet Option 2: Two separate logical circuits VPN and inbound Internet traffic Separate circuit for outbound Internet Option 3: Single logical circuit All VPN Internet traffic on same interface

Layer 3 VPN Pitfalls Common VPN mistakes Route target mismatches VPN routes received are compared against the local route target in the import policy MP-BGP IPv4 families Configuring family inet-vpn overrides the default IPv4 NLRI (family inet) Scalability issues Route reflectors Route target filters MPLS LSPs VPN routes must resolve to inet.3

Layer 3 VPN Time-Savers Plan out your Layer 3 VPN strategy Identify the PE routers and verify that the necessary IBGP neighborships are established Verify that MPLS and LSPs are signaled throughout the core Build the VRF routing instance CE interface configuration Route distinguisher and route target information CE to PE routing protocol

Interprovider VPN VPN requires two different AS networks Customer requires connectivity between two different ISPs Several options available: Option A: Unlabeled VPN-IPv4 Option B: Labeled VPN-IPv4 Option C: Multihop MP-BGP

Interprovider VPN: Option A and B Unlabeled VPN-IPv4 (Option A) Requires a separate VRF table for each VPN Each VPN requires a separate routing instance PE must carry all customer VPN routes Does not scale Labeled VPN-IPv4 (Option B) Does not require a separate VRF table for each VPN Limited scalability Requires the ASBRs carry VPN routes and state for transit MPLS sessions

Interprovider VPN: Option C Multihop MP-BGP (Option C) ASBR only carries internal routes PE loopback addresses are leaked between ASBRs ASBRs use labeled-unicast family to assign labels ASBRs do not have a VRF table Require a BGP session between PE routers EBGP sessions require multihop

Carrier-of-Carrier VPNs Generally connects two provider sites within the same AS through another carrier AS Carrier PE routers maintain the provider’s internal routes Carrier PE routers do not maintain customer external routes Provider routers maintain internal routes as well as external customer routes

Interprovider Layer 3 VPNs Pitfalls VPN routes must resolve to inet.3 Route target mismatches VPN routes received are compared against the local route target in the import policy Time-savers Identify correct solution Ensure reachability through inet.3 routes Build VRF routing instance PE to CE interfaces and protocols Route target information

Layer 2 Over MPLS-Based Core Layer 2 VPNs Layer 2 VPN using BGP signaling (Kompella) Automatically assigns new circuit IDs and labels Can use either RSVP or LDP to signal LSPs Layer 2 circuit using LDP signaling (Martini) Requires manual circuit provisioning LDP sessions can be adjacent or extended (ldp-tunneling) VPLS VPLS using BGP signaling Automatic provisioning Can use either RSVP or LDP to signal VPLS using LDP signaling Must configure a full mesh of LDP session between PE routers

Layer 2 VPN and VPLS Concepts Layer 2 VPNs and Layer 2 circuits offer point-to-point Ethernet, frame relay, ATM, PPP, or Cisco-HDLC services Administrator of PE router maps local circuit IDs to remote sites VPLS Offers Ethernet-based point-to-multipoint VPNs To the customer in a VPLS environment, the provider’s network appears to function as a single LAN segment Acts similarly to a learning bridge No need to map local circuit IDs to remote sites PE device learns MAC address from received Layer 2 frames MAC addresses are dynamically mapped to outbound MPLS LSPs, interfaces, or both

BGP Signaled Layer 2 VPNs BGP signaling is used to exchange circuit information MP-BGP support using family l2vpn Site ID, label range, label base Import and export target community Bidirectional LSPs must be pre-established between PEs Can be RSVP or LDP sessions VRF table Provisioned for each customer site including the site ID, sub-interface list, encapsulation, and label base Uses RFC 4448 encapsulation

LDP Signaled Layer 2 Circuit LDP signaling for peering sessions Does not support traffic engineering Manually provisioned at both ends of a circuit Supports label stacking No auto-provisioning of Layer 2 circuits No VRF tables Configured under protocols l2circuit hierarchy BGP is not required Uses RFC 4448 encapsulation

BGP Signaled VPLS VPLS with BGP signaling BGP signaling is used to exchange circuit information MP-BGP support using family l2vpn Site ID, label range, label base Import and export target community Bidirectional LSPs must be pre-established between PEs Can be RSVP or LDP sessions VRF table Provisioned for each customer site including the site ID, sub-interface list, encapsulation, and label base Uses RFC 4448 encapsulation

LDP Signaled VPLS VPLS with LDP signaling PE router distributes VPLS to label mapping information using LDP Supports FEC 128, Control bit 0, and Ethernet pseudowire For each VPLS, you must configure a full mesh of LDP LSPs PE-1 advertises labels to PE-2; PE-2 uses these labels as the inner labels when forwarding traffic to PE-1 BGP is not required Uses RFC 4448 encapsulation

Layer 2 Interface Configuration Layer 2 VPN and Layer 2 circuit Interfaces require either CCC or TCC encapsulation Physical encapsulation and logical encapsulation VLAN interfaces must be in the range of 512 through 4094 Can use extended-vlan encapsulation on the physical interface to allow the use of VLAN IDs from 1 through 4094 VPLS Interfaces require vpls encapsulation Can use extended-vlan-vpls encapsulation on the physical interface to allow the use of VLAN IDs from 1 through 4094 Add family vpls to the interface

Multihome VPLS (1 of 2) Single CE multihomed to multiple PEs BGP VPLS solution Assign same site ID Assign the unique route-distinguisher Configure multihoming Assign a site-preference (higher is more preferred) LDP VPLS solution Multihoming is not supported using LDP Can create redundant pseudowires to PE routers connected to the same CE site. Use backup-neighbor statement to create secondary neighborship

Multihome VPLS (2 of 2) Multiple connections between a single PE and CE To prevent loops, you must configure one of the following: Primary/backup interfaces (BGP only) Link aggregation Ethernet ring protection A spanning tree protocol

Point-to-Multipoint LSPs for VPLS Point-to-multipoint LSPs can be used instead of unicast LSPs to forward broadcast, unicast, and multicast traffic Ingress PE no longer has to perform all of the replication of broadcast, unicast, and multicast traffic Can be used in BGP VPLS scenario only Point-to-multipoint LSP to VPLS mapping is performed with the readvertisement of an ingress PE’s label blocks with the PMSI Tunnel attribute

Layer 2 Pitfalls Interface configuration Route targets Physical and logical interfaces Protocol family configured Route targets VRF import and export policies BGP and MPLS configuration BGP uses family l2vpn Remote PE addresses in inet.3

Layer 2 Time-Savers Plan ahead MPLS transport Use topology maps to define PE routers Draw out VPNs using different colors MPLS transport RSVP or LDP Configure each VPN router by router Use the show | display set command to copy and paste routing instances and route target policies

Task and Topology Task: Core MPLS Network C3-1 C2-1 C1-1 R7 R9 R3 C1-2 C2-2 C3-2 Customer 1 2 3 R2 R5 R8 R6 R4 R1 AS 65100 AS 3895077211 Loopbacks R1 – 192.168.1.1 R2 – 192.168.1.2 R3 – 192.168.1.3 R4 – 192.168.1.4 R5 – 192.168.1.5 R6 – 192.168.1.6 R7 – 192.168.1.7 R8 – 192.168.1.8 R9 – 192.168.1.9 .2 .1 65.1.0.0/30 .1 .2 65.1.5.0/30 AS 65100 Task: Create a Layer 3 VPN named customer-1, connecting the C1-1 and C1-2 sites together. The C1-1 and C1-2 are using EBGP to peer to your PE router. Ensure that the CE routers can communicate with the remote, directly connected PE-CE links.

What Now? What are the required components? Connectivity IGP route to egress router’s loopback BGP neighborship between PE routers MPLS LSPs established between the PE loopbacks VPN NLRI enabled on IBGP session Layer 3 routing instance configuration on both PE routers route-distinguisher route-target or VRF import and export policies PE to CE routing protocols

Task Completion (1 of 6) Step 1: Initial verification on R1 OSPF and MPLS BGP lab@R1> show route 192.168.1.9 inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.9/32 *[OSPF/10] 02:23:48, metric 2 > to 172.27.0.13 via ge-0/0/6.0 inet.3: 4 destinations, 5 routes (4 active, 0 holddown, 0 hidden) 192.168.1.9/32 *[RSVP/7/1] 02:17:49, metric 2 > to 172.27.0.9 via ae0.0, label-switched-path r1-to-r9 lab@R1> show bgp summary Groups: 1 Peers: 8 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... ... 192.168.1.9 3895077211 9 11 0 0 4:10 0/0/0/0 0/0/0/0

Task Completion (2 of 6) Step 2: Initial verification on R9 OSPF and MPLS BGP lab@R9> show route 192.168.1.1 inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.1/32 *[OSPF/10] 02:29:47, metric 2 > to 172.27.0.26 via ge-0/0/1.0 inet.3: 9 destinations, 15 routes (4 active, 0 holddown, 9 hidden) 192.168.1.1/32 *[RSVP/7/1] 02:22:33, metric 2 > to 172.27.0.26 via ge-0/0/1.0, label-switched-path r9-to-r1 [LDP/9] 02:22:33, metric 1 lab@R9> show bgp summary Groups: 1 Peers: 8 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.168.1.1 3895077211 2 2 0 1 2 0/0/0/0 0/0/0/0 ...

Task Completion (3 of 6) Step 3: NLRI configuration on R1 [edit protocols bgp group internal] lab@R1# show type internal; local-address 192.168.1.1; family inet { unicast; } family inet-vpn { export nhs; neighbor 192.168.1.2; neighbor 192.168.1.3; neighbor 192.168.1.4; neighbor 192.168.1.5; neighbor 192.168.1.6; neighbor 192.168.1.7; neighbor 192.168.1.8; neighbor 192.168.1.9;

Task Completion (4 of 6) Step 4: NLRI configuration on R9 [edit protocols bgp group internal] lab@R9# show type internal; local-address 192.168.1.9; family inet { unicast; } family inet-vpn { export nhs; neighbor 192.168.1.1; neighbor 192.168.1.2; neighbor 192.168.1.3; neighbor 192.168.1.4; neighbor 192.168.1.5; neighbor 192.168.1.6; neighbor 192.168.1.7; neighbor 192.168.1.8;

Task Completion (5 of 6) Step 5: VRF instance configuration R1 [edit] lab@R1# show routing-instances customer-1 instance-type vrf; interface ge-0/0/2.0; route-distinguisher 192.168.1.1:1; vrf-target target:65100:1; protocols { bgp { group customer-1 { type external; as-override; neighbor 65.1.0.2 { peer-as 65100; }

Task Completion (6 of 6) Step 6: VRF instance configuration R9 [edit] lab@R9# show routing-instances customer-1 instance-type vrf; interface ge-0/0/4.0; route-distinguisher 192.168.1.9:1; vrf-target target:65100:1; protocols { bgp { group customer-1 { type external; as-override; neighbor 65.1.5.2 { peer-as 65100; }

Task Verification (1 of 5) PE to CE routing protocol verification R1 R9 lab@R1> show bgp summary instance customer-1 Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending custo.inet.0 14 13 0 0 0 0 custom.mdt.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 65.1.0.2 65100 2678 2674 0 0 20:16:56 Establ customer-1.inet.0: 6/7/7/0 lab@R9> show bgp summary instance customer-1 Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending custo.inet.0 14 13 0 0 0 0 custom.mdt.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 65.1.5.2 65100 2693 2688 0 0 20:23:03 Establ customer-1.inet.0: 6/7/7/0

Task Verification (2 of 5) VRF table verification on R1 lab@R1> show route table customer-1.inet.0 customer-1.inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both ... 65.1.5.0/24 *[BGP/170] 20:23:05, localpref 100, from 192.168.1.9 AS path: 65100 I > to 172.27.0.9 via ae0.0, label-switched-path r1-to-r9 65.1.5.0/30 *[BGP/170] 20:23:05, localpref 100, from 192.168.1.9 AS path: I 65.1.6.0/24 *[BGP/170] 20:23:05, localpref 100, from 192.168.1.9 65.1.7.0/24 *[BGP/170] 20:23:05, localpref 100, from 192.168.1.9 65.1.8.0/24 *[BGP/170] 20:23:05, localpref 100, from 192.168.1.9 65.1.9.0/24 *[BGP/170] 20:23:05, localpref 100, from 192.168.1.9

Task Verification (3 of 5) VRF table verification on R9 lab@R5> show route table customer-1.inet.0 customer-1.inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 65.1.0.0/24 *[BGP/170] 20:27:55, localpref 100, from 192.168.1.1 AS path: 65100 I > to 172.27.0.26 via ge-0/0/1.0, label-switched-path r9-to-r1 65.1.0.0/30 *[BGP/170] 20:27:55, localpref 100, from 192.168.1.1 AS path: I 65.1.1.0/24 *[BGP/170] 20:27:55, localpref 100, from 192.168.1.1 65.1.2.0/24 *[BGP/170] 20:27:55, localpref 100, from 192.168.1.1 65.1.3.0/24 *[BGP/170] 20:27:55, localpref 100, from 192.168.1.1 65.1.4.0/24 *[BGP/170] 20:27:55, localpref 100, from 192.168.1.1 ...

Task Verification (4 of 5) Verify route-distinguisher values R1 lab@R1> show route table bgp.l3vpn.0 bgp.l3vpn.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.9:1:65.1.5.0/24 *[BGP/170] 20:30:17, localpref 100, from 192.168.1.9 AS path: 65100 I > to 172.27.0.9 via ae0.0, label-switched-path r1-to-r9 192.168.1.9:1:65.1.5.0/30 AS path: I 192.168.1.9:1:65.1.6.0/24 192.168.1.9:1:65.1.7.0/24 192.168.1.9:1:65.1.8.0/24 192.168.1.9:1:65.1.9.0/24 192.168.1.9:1:65.1.255.2/32 *[BGP/170] 20:27:12, localpref 100, from 192.168.1.9

Task Verification (5 of 5) Verify route-distinguisher values R9 lab@R9> show route table bgp.l3vpn.0 bgp.l3vpn.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.1:1:65.1.0.0/24 *[BGP/170] 20:39:20, localpref 100, from 192.168.1.1 AS path: 65100 I > to 172.27.0.26 via ge-0/0/1.0, label-switched-path r9-to-r1 192.168.1.1:1:65.1.0.0/30 AS path: I 192.168.1.1:1:65.1.1.0/24 192.168.1.1:1:65.1.2.0/24 192.168.1.1:1:65.1.3.0/24 192.168.1.1:1:65.1.4.0/24 192.168.1.1:1:65.1.255.1/32 *[BGP/170] 20:36:15, localpref 100, from 192.168.1.1