Using MPLS

Kentik support for MPLS is covered in the following topics:

• About MPLS
• MPLS Ingest
• Applying MPLS in Kentik

Note: For a list of MPLS-derived filtering and group-by dimensions, see MPLS Dimensions.

Multiprotocol Label Switching (MPLS) is a routing scheme for network data that was designed as an alternative to IP routing. MPLS is intended to be more efficient because it bypasses the need for each router in a path to look in its own routing table for the route to the destination of each incoming packet.

As shown in the diagram above (from Munkhbayar09 via Wikimedia Commons), MPLS enables a network operator to define a label-switched path (LSP) across a set of label-switch routers (LSRs), which are routers that support MPLS. The LSP encompasses an ingress router and egress router with a set of transit (interior) routers in between.

The first MPLS router encountered by a packet (the ingress router) looks at the destination IP of the packet (and possibly, depending on the router maker, some other packet properties) and determines a "forwarding equivalence class" (FEC) that indicates the destination — at the end of the LSP — to which the packet should ultimately be forwarded. The router inserts an MPLS header near the start of the packet (after the Level 2 header and before Level 3) that includes a "stack" of one or more labels, each of which includes a 20-bit value representing an FEC. The subsequent MPLS routers in the LSP need only consult the top-most label in the stack to get the switching information needed to forward the packet to the next router in the path. The last router in the LSP (the egress router) strips out the MPLS header and forwards the packet to the next-hop IP.

By eliminating the need for each router in an LSP to figure out the path individually, MPLS reduces the resources and time required to move a given packet from point to point. MPLS labels also support additional bits that can be used to assign QoS levels to different types of data (e.g. higher priority to video than to text).

MPLS is implemented differently by the various router vendors that support it. In general, however, a device in an MPLS path will consult its Label Forwarding Information Base (LFIB) and supersede the label received from the previous router with the label expected by the next router in the path, which becomes the top label in the stack. At the same time, if NetFlow is configured on the device the flow record in the flow cache will be updated to reflect the new label.

Note: Additional information about various aspects of MPLS is available from the following sources:
- TechTarget article
- Cisco FAQ
- Network World article

Standard NetFlow fields, including source and destination IP address, are typically among the core data types stored in the Kentik Data Engine (KDE) when flow records are ingested into Kentik. Flow records from MPLS routers, however, may not include IP information, particularly if one of the following is true:

• A transit router inside of an LSP is forwarding Layer 2 traffic or using other non-IP technologies such as ATM or Frame Relay.
• Flow being forwarded by a router contains IP information but the router is not configured with a template or templates that support both MPLS label information and IP information.

When an MPLS-enabled router is configured to collect both IPv4/IPv6 and MPLS details on an interface, the specific fields in the resulting flow records will vary depending on vendor, traffic conditions, and router configuration. At ingest Kentik normalizes these MPLS-related records into a single set of supported fields; see MPLS Dimensions.

As noted above, the routers inside of an LSP may not necessarily create NetFlow, or may create records without specifying source/destination IP. It follows that without MPLS support in KDE a Kentik customer wouldn't necessarily have visibility into traffic routed via MPLS. This could cause a significant discrepancy between NetFlow-reported traffic volume and SNMP-reported volume on a given interface.

Beyond gaining overall visibility into MPLS routers, Kentik users can also query the MPLS label information in KDE to better understand the traffic with a given MPLS label. This can involve querying on "reserved" label values, which are designated by the MPLS specification (IETF RFC7274) for purposes other than passing an FEC, to find where policies were imposed on MPLS traffic:

• Filter for traffic leaving MPLS: MPLS reserves two label values for "explicit null": 0 for IPv4 Explicit NULL Label and 2 for IPv6 Explicit NULL Label. These labels typically indicate the end of the LSP, at which point further packet forwarding will be based on the IPv4 header. Filtering for these values on the dimension MPLS Label 1 will identify traffic that is leaving an MPLS domain as it is forwarded into an IP domain.
• Filter for traffic delivered to local software: An MPLS label value of 1 is defined as the Router Alert Label. When the top-most label in a packet has this value it is delivered to a local software module for processing. As shown below, filtering for this value on the dimension MPLS Label 1 will identify traffic where the routing policies may have pushed the packet outside of the MPLS domain, dropped the packet, or reinserted the packet into the MPLS forwarding domain.

Another MPLS use case in Kentik is to identify MPLS traffic that should be subject to a certain class or quality of service policy. In IP forwarding, this function — alerting routers along a data path that certain traffic should be treated differently — is handled by the Differentiated Services Code Point (DSCP) field in the IP header. Since MPLS doesn't directly support DSCP, the EXP (experimental) bits in the MPLS header are frequently used to preserve DSCP settings as IP packets traverse an MPLS domain. By filtering in Kentik on the MPLS Label 1 EXP and MPLS Label 2 EXP dimensions you can look for areas within an MPLS forwarding domain where the service policies are not being correctly applied.

Kentik supports IPv6 Provider Edge (6PE) technology and the BGP IPv6 Labeled-Unicast address family, which means that flow records originating from a 6PE device can be enriched at ingest into the Kentik Data Engine (KDE) like flow records from any other Kentik-supported source.

To ingest flow records into Kentik from a 6PE device:

• In the Kentik portal, go to the Settings » Network Devices page and open the Device dialog for the device (see About Device Dialogs). On the BGP tab, set the BGP Route Selection drop-down to "VPN table, fallback to Labeled-Unicast table, fallback to Unicast table."
• Establish a BGP session with IPv6 Labeled-unicast AF between the 6PE device and Kentik.

Based on the received IPv6 LU routes, the Kentik ingest layer will populate all “standard BGP” dimensions in KDE, including:

• Next Hop IP/CIDR: Populated with the next-hop IPv4-mapped IPv6 address from the received route, which is in the form of ::FFFF:<IPv4-address>
• Ultimate Exit: The Ultimate Exit Device dimension is based on the IPv4-mapped address, which is used to identify the next-hop 6PE router. The values of other Ultimate Exit Dimensions are derived from the value of the Ultimate Exit Device dimension.