↓Skip to main content
Hugo’s IT journal

24 - Setup MPLS VPN

ccie notes
Hugo
Author
Hugo
DevOps Engineer based in London
Table of Contents

MPLS
#

Label-based forwarding:

  • Labels are used for packet transfer across the network
  • This allows for more efficient packet switching and enables advanced services.

Routing vs. Forwarding:

  • The routing table determines the path, but LDP (Label Distribution Protocol) creates the label-switched path.
  • This separation allows for flexible network designs where direct IP reachability isn’t necessary between all hops.

Label assignment:

  • Each router independently assigns labels to routes/prefixes.
  • These labels are local to the router.

Routing process:

  • (add) Label: The first MPLS-enabled router (ingress) adds a label to the packet.
  • (swap) Label: Each intermediate router swaps the incoming label with an outgoing label.
  • (pop) Label: When PHP(an optimization) is enabled, the second-to-last route removes the label before sending to the last hop, converting it back into a normal IP packet.

Example:

  • The route 192.168.1.0/24 on R1 uses label 500.
  • The same route 192.168.1.0/24 on R2 uses label 501.
  • R0 sends a packet destined for 192.168.1.1 to R1, adding label 500, so the packet becomes 500 192.168.1.1.
  • R1 receives 500 192.168.1.1. When forwarding to R2, R1 swaps the label from 500 to 501, resulting in 501 192.168.1.1.
  • If R2 is the last hop, R1 will find that R2’s label is implicit-null, meaning R1 will pop the label. The packet then becomes a regular IP packet 192.168.1.1 before reaching R2.

MPLS with NFS
#

Route representation:

  • In VRF-aware MPLS networks, routes are represented as RD+IP.
  • The RD ensures uniqueness of routes across VRFs.
  • eg: VRF A and VRF B on R1 both use 192.168.1.1/24 - but having different RD
  • Basically, unique RD per customer site.

Label table entries:

  • Entries become RD+IP,Label instead of just IP,Label.
  • This allows for proper segregation and forwarding of VRF traffic.

VPNv4
#

  • VPNv4 is a BGP address family specifically designed for MPLS VPNs.
  • It extends the IPv4 address family to include additional information needed for VPN routing.
  • VPNv4 is needed because it can carry the RD + Prefix, similar to how trunking carries the traffic with VLAN tags. This allows multiple VPNs to be supported on the same network.
  • VPNv4 aggregates the BGP routes from all VRFs and advertises them across the MPLS network.
  • While VPNv4 is used for route advertisement, standard IPv4 BGP sessions are still needed between PE routers for establishing the BGP peering.

Route Flow: CE to PE1: CE routes are redistributed into BGP IPv4 VRF on PE1. PE1 to PE2: BGP VPNv4 advertises the route (RD+Prefix) from PE1 to PE2. (includes the RT, RD) PE2 Processing: PE2 receives the VPNv4 route and installs it into the appropriate VRF based on the RD and RT. PE2 to CE: PE2 redistributes the BGP route into the IGP (e.g., OSPF) used with the CE.

Route Tables
#

Global Tables:

  • BGP Session (PE - PE):
    • IPv4 address family: Establish the BGP session between PEs.
    • VPNv4: Advertise routes for multiple VRFs acorss the backbone.

VRF:

  • BGP IPV4 (no direct neighbor):
    • Holds CE routes that will be advertised to the peer PE.
  • IGP Protocol (I used OSPF): Exchanges routes between PE and CE.

Redistribution Process
#

Sending routes to peer PE:

  • Redistribute OSPF routes into BGP IPv4 VRF.
  • CE routes enter the BGP process and are then advertised as VPNv4 routes to the peer PE.

Receiving routes from peer PE:

  • Redistribute BGP IPv4 VRF routes into OSPF VRF.
  • Routes received from the peer PE (via VPNv4) are inserted into the CE’s routing protocol.

Sham Link#

  • A Sham Link is a virtual OSPF link created between two PE routers across an MPLS VPN backbone.
  • It allows OSPF to establish a direct adjacency over the MPLS network, even when there’s no direct Layer 2 connectivity.
  • Normally, OSPF establishes adjacencies only over directly connected networks.
  • Sham Links overcome this limitation in MPLS VPN environments.

Purpose of Sham Link

  • When OSPF routes are redistributed into BGP, key OSPF attributes are preserved in BGP extended communities:
    • Route ID
    • Domain ID
    • Area ID
  • When these routes are redistributed back from BGP to OSPF on another PE:
    • The OSPF process examines the domain ID in the BGP extended community.
    • If the domain ID matches its own, the route is treated as an inter-area route (Type 3 LSA).
    • If it doesn’t match, the route is considered an external route (Type 5 LSA).
  • If a Sham Link exists and its area matches the original route’s area:
    • The route can be treated as an intra-area route (Type 1 or 2 LSA). This preserves the original OSPF route type and metrics across the MPLS VPN.
  • Sham Link Loopback need to be advistised from BGP

BGP
#

Routing tables:

  • Protocol-specific routing tables: Each routing protocol maintains its own table.
  • Global Routing Table (also called RIB)
  • FIB: Contains only the best routes used for packet forwarding

VRFs:

  • Allow multiple independent routing/forwarding tables on a single router
  • Each VRF has its own RIB and FIB

BGP vs OSPF:

  • OSPF: Multiple instances possible, each with its own LSDB and neighbors
  • BGP: Single instance maintaining a global view of routes across all VRFs

BGP and Route Leaking:

  • BGP maintains a single instance on a router, with a global view of routes across all VRFs and the global table.
  • This unified view allows BGP to easily manipulate and transfer routes between different routing contexts.

Route Leaking Mechanisms:

  • import vrf and import global commands: Cloning routes and adjusting their attributes to fit the target routing table
  • Redistribute with route-maps to modify route attributes: Modifying RD, RT, and next-hop information

My Mistakes
#

After setting this up, I was

  • Unable to ping from PC2 (endpoint device) or reach CE2 route from PE1.
  • PE1 could ping PE2, indicating core connectivity was intact.

Initially, I

  • Assumed the issue was related to next-hop not being in the VRF table.
  • Focused on route leaking between global and VRF tables.

The Actual root causes:

  • The endpoint device didn’t have the default gateway set, leading to connectivity issues.
  • When pinging from the PE, it’s necessary to not only specify the VRF but also set the source IP within the VRF. The correct command should be: ping vrf <VRF> <IP> source <IP_IN_VRF>.
  • I forgot to redistribute the BGP route back into the PE’s OSPF, which is essential for proper route propagation.
  • In MPLS, packet switching in PE-PE is label-based, not IP-based. IP routing occurs at the destination PE which understands the next-hop.