IP Header TTL field supports two featuers
- method to identify looping packets – TTL decrements to 0 and gets discarded
- method for traceroute to find the IP address on a network path
MPLS requires a TTL field that ignores the IP header, and only decrements the MPLS TTL as opposed to the IP TTL.
The following describes how TTL from the IP header is translated to the MPLS TTL and transported across the network, this is called MPLS TTL Propagation:
Ingress Edge Label Switch Routers (E-LSR) decrements the IP TTL field and then pushes an MPLS label onto the packet copying the the IP TTL into the MPLS TTL field.
Label Switch Router – When the frames is passed through other MPLs routers, the MPLS TTL field is decremented, the IP TTL field is ignored.
Egress E-LSR – After egress LSR decrements the MPLS TTL field, it pops the MPLS label and copies the TTL field to the IP TTL field.
Routers can be configured to disable MPLS TTL propagation, this causes the ingress E-LSR to set the MPLS header TTL field to 255, and the IPv4 TTL is unchanged, this results in the MPLS network from being seen on traceroutes.
Route Targets are applied or exported to prefixes and then injected into MP-BGP as an additional Path Attribute. This allows other PE routers participating in the same VRF to import the specific routes out of BGP by defining the Route Target in the VRF import configuration.
This also allows for overlapping MPLS VPN routes where some complex VPN configurations import route targets from OTHER VRFs in order to learn routes.
Each VRF needs to import/export at least one RT, typically for a single customer a single RT value is shared among all PEs participating in that customers VRF, this allows for only routes injected into BGP with the appropriate RT to be pulled from BGP into the appropriate VRF at all other sites.
The act of importing routes from other customer VRFs is referred to as route leaking prefixes between VRFs.
Originally BGP on its own was not capable of dealing with multiple customer routes and overlapping prefixes. MPLS deals with this issue by employing a BGP RFC 4760 and instead using MP-BGP with allows for the use of address families. This allows for an additional variable length number to be added in front of the BGP NLRI/prefix.
MPLS defined this new address family as Route Distinguishers (RD)
RD’s allow for BGP to distinguish which routes belong to which customer VRF table. By adding another number (the RD) in front of the IP prefix, it allows the customer route to remain unique on a device that has other customers with the same route.
The New MP-BGP NLRI format consists of a 64 bit Rd and a 32 bit IPv4 prefix. The RD has formatting conventions, the first 2 bytes identify which of the three formats is followed. Since IOS can determine which of the three formats is used based on the value, the IOS rd VRF subcommand only requires you to put in integer values for the last 6 bytes of the RD.
The RD can be configured in the following three methods:
To support multiple customer routing tables each routing instance is placed into a concept of a virtual router. This is called the VRF table feature, VRFs store customer routes separately on different customer VPNs, this allows all sites in the same VPN to communicate and share routes while keeping other customer routing instances separate.
Typically each customer gets their own VRF routing instance in an MPLS aware router, some complex designs for a single customer may require multiple VRFs, for varying reasons. (ie route advertisements, internet routing, etc..)
Each VRf has three components:
- IP routing table (RIB)
- CEF FIB populated from VRF RIB
- Seperate instance of routing protocol used to exchange routes with CEs that need to be supported by the VRF
Customer Edge or CE router – this device has no knowledge of MPLS protocol and does not send any labeld packets but is directly connected to an LSR (PE) on the MPLS VPN.
Provider Edge or PE router – A LSP that shares a link with at least one CE router, providing MPLS functions at the edge of the MPLS VPN, includes functions such as iBGP and VRF tables. PE routers also learn all customer routes and keep different customer routing tables separate. PEs must also impose MPLS headers on non MPLs packets they receive.
Provider or P router – a LSR that does not have a direct link to a CE router, this device simply forwards label switched packets only, and allows the LSR to ignore customer VPN routes.
P and PE routers run LDP and an IGP to support unicast routing, the IGP though only advertises routes for subnets on the MPLS network, NOT routes from the customer network. instead customer routes are put into separate customer routing tables called VRFs, then PEs use iBGP to exchange these customer routes with other PEs, never advertising routes to the P routers.
MPLS headers added to ingress packets include:
- Outer MPLS header (Sbit = 0) with label value that causes the packet to be label switched to the egress PE
- Inner MPLS header (Sbit = 1) label identifies the egress VRF on which to base the forwarding decision.
MPLS VPN is a feature of MPLS that allows Service Providers or large enterprises the ability to utilize layer 3 VPNs. These can be used to replace older Layer 2 VPNs such as frame relay or ATM.
MPLS VPNs are great because they are aware of the customers routes and when traversing an MPLS network remain private.
MPLS provides solutions for the following problems in a large scale shared environment:
Duplicate/Overlapping Customer Address ranges:
Having multiple customers connected to the same service provider network can introduce potential routing issues using simple IP unicast routing when all customer utilize the same IP address space on their networks.
MPLS VPNs address this issue by utilizing virtual routing tables or Virtual Routing and Forwarding (VRF) tables, which separate customer routes for each customer forwarding instance.
LDP uses Hello messages to determine neighbors and maintain up status with neighbors. LDP multicasts to 126.96.36.199 using UDP port 646 for LDP. Older TDP uses UDP port 711.
Hellos contain a 32 bit dot decimal number and 2 byte label space number referred to as a LSR LDP ID (LID)
LSRs can optionally send a transport address in the Hello messages to allow neighbors to send any TCP communications to work. If a transport address is not used, hosts will use the IP address in the first 4 bytes of the LDP ID for TCP connections
Once neighbors are found they establish a TCP connection using TCP 646 (or older TCP 711 for TDP). Once a connection is up each router advertises its list of local labels and prefix bindings.
Labels are stored in a Label Information Base (LIB) this database holds all label and forwarding information needed to forward packets. FIB and LFIB only contains labels for best path to a prefix, LIB contains all labels regardless if they’re used or not.
To choose what label to apply the router depends on the routing protocols decision about the best route. Relying on the routing protocol allows for the LIB to take advantage of its loop prevention mechanisms to get to the destination.
LSRs make the following decision during convergence of routes:
for each route in the routing table, find the corresponding label information in the LIB, and based on the outgoing interface and next hop the LSR adds the label to the FIB and LFIB.
For unicast routing, LDP advertises labels for each prefix in the IP routing table. LSRs use LDP to send messages to neighbors advertising the prefix and label assigned to it.
Advertisements are triggered when new routes are injected into the IPv4 RIB. The local label applied to the prefix by the router. Basically the router is saying to reach this prefix across the mpls, label your traffic with the corresponding label thats being advertised with that network.
A Label Switched Path is the complete set of labels at each LSR used to get to an MPLS destination.
LSPs are unidirectional.
LSRs in the MPLS cloud need to use the same IP routing protocol to exchange routes and ultimately apply labels to routes that are learned from each other.
MPLs relies on control plane protocols to learn what MPLS labels to use to reach each destination subnet. Once it has this information it populates both the FIB and LFIB with correct labels.
MPLS supports multipls control plane protocols, however MPLS VPNs typically use LDP and MP-BGP
MPLS Unitcast IP Forwarding requires at least one IGP and LDP.