Using MPLS

Kentik support for MPLS is covered in the following topics:

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

 

About MPLS

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

 

MPLS Ingest

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.

 

Applying MPLS in Kentik

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 Support for 6PE

In addition to parsing MPLS NetFlow records, Kentik supports querying standard NetFlow fields issued from IPv6 Provider Edge Routers (PE) in networks configured to tunnel IPv6 traffic over MPLS cores (6PE). Kentik receives IPv6 routes from these edge routers and is able to ascertain and annotate IPv6 flow records with the correct egress site, device, and interface using Ultimate Exit Dimensions. A label-switched path (LSP) that carries this traffic throughout the core is treated like any other LSP in an MPLS core and can be analyzed in Kentik using the MPLS Label dimensions (see MPLS Dimensions).

Kentik requires the following for 6PE support:

  • The routers must embed IPv4 next hop interface IP addresses within an IPv6 next hop as documented in section 2.1 of RFC4798 (https://datatracker.ietf.org/doc/html/rfc4798).
  • The embedded IPv4 addresses must correspond to the configured interface addresses retrieved by Kentik via SNMP or uploaded via the interface calls in Kentik’s Device API.

Note: IPv6 labeled-unicast next hops are not supported at this time.

© 2014- Kentik

In this article: