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.