MPLS offers functionality that works in unison with, rather than replacing, the existing infrastructure. MPLS can also be used for VPNs, intradomain routing, and interdomain routing. Before launching into a technical discussion of the intricacies of MPLS, it is necessary to explain the basic functionality of the protocol, as well as to introduce the reader to the terminology that will be used throughout the rest of this chapter. The following section offers a functional overview of MPLS and includes an introduction to common MPLS terminology. 12.3.1 Functional OverviewAn MPLS-enabled network gives the network engineer precise control over how traffic flows from source to destination. To provide this control, MPLS allows packets to move independently of the IGP routing algorithms native to the network being crossed. To accomplish this, MPLS relies on predefined paths, known as LSPs. LSPs are composed of connections between MPLS-enabled routers. A router that is running MPLS is known as a label-switching router (LSR). LSRs tag each packet passing through the LSP with a label. This label accomplishes several things, the most important of which is distinguishing the MPLS packet from a regular IP packet, thereby entitling the packet to continue crossing each LSR along the LSP without being subjected to Layer 3 scrutiny. The packet's label is changed by the LSR at every hop, hence the name label-switching router. JUNOS uses MPLS as the foundation for two types of services: traffic engineering and RFC 2547bis (BGP/MPLS) VPNs. For a detailed explanation of VPNs, see Chapter 13. 12.3.1.1 LabelsLabels are a way of marking packets destined for a specific address. Packets are assigned labels by LSRs. Once they are assigned labels, they can be forwarded through the network to the next LSR along a preconfigured path . When the packet arrives at an LSR, the label distinguishes this packet from other IP traffic and allows it to be handled by the MPLS protocol. This form of packet distinction permits the MPLS protocol to function on the same interfaces as the native IGP without interfering with the IGP's routing calculations or processes. Figure 12-6 illustrates the MPLS label format, as well as the location of the MPLS label with regard to the Layer 2 and Layer 3 headers. The following list defines the label fields shown in Figure 12-6.
Figure 12-6. MPLS Label Format
Figure 12-6 also shows the positioning of the MPLS label with regard to a typical IP packet. The diagram shows that the label resides between the Layer 2 frame and Layer 3 packet. Table 12-1 lists details about the label value ranges and use and introduces two previously unmentioned terms, penultimate hop popping (PHP) and ultimate hop popping (UHP). These terms are covered in Section 12.5 and Case Study 1 at the end of this chapter. Table 12-1. JUNOS MPLS Label Values
The combination of label number and inbound interface is cross-referenced against a table to determine the outbound interface and label. Once these have been determined, three common operations can be performed by LSRs on labels:
12.3.1.2 LSPsMPLS is based on the creation of LSPs. These LSPs are used to forward packets from a source to a destination. LSPs are engineered on top of an already existing IP-based core network. The LSPs themselves are created in a unidirectional manner. Traffic engineering controls data flows; thus, each given direction of a bidirectional flow may be engineered to meet specific requirements. This allows finer control of path engineering. Usually, the return path is engineered across the same set of hops, although this is not a necessity. MPLS does not, however, guarantee the delivery of the packet. This must still occur at higher layers , such as the transport layer or the application level. MPLS LSPs can be formed either statically or dynamically. In static configuration, the network administrative team must define which label number to use and the next-hop information. In dynamic configuration, protocols like RSVP are used to signal label information between the ingress LSR and the egress LSR. This eliminates the need for administrators to define which label values and next-hops to use, however, there is the capability to use administrative constraints within JUNOS to further control LSP negotiation and setup. For a detailed description of constraints, see Sections 12.3.2.2 and 12.3.2.3. The MPLS signaling protocol RSVP provides the ability to configure constraints (path requirements) along the LSP. By employing these constraints the engineer is able to define specific LSRs along the LSP as being either strict hops or loose hops. A strict hop is a requirement that the path be formed through a specific interface to an immediately connected LSR. A loose hop is a requirement that an LSP pass through a specific LSR. However, with loose hops there is no requirement that a specific interface be used. To form the LSP, Constrained Shortest Path First (CSPF) relies on specific pieces of information that are stored in a traffic-engineering database (TED) created based on information carried by the IGP, be it IS-IS or OSPF. Manually configuring and defining the swapping of labels at each hop creates static LSPs. Static LSP creation is useful when implementing MPLS across small networks, or in situations where there is simply not enough bandwidth to support a signaling protocol. See Section 12.5 for an example of creating a minimal configuration for static LSPs. 12.3.1.3 LSRsAn LSP is built across the following component LSRs:
A single router is capable of filling multiple roles for different LSPs. A transit router for one LSP could also be the ingress router for another LSP. The egress router for one LSP could be a transit router for another LSP. There are no mandatory hardware differences between ingress routers and transit or egress routers. Figure 12-7 illustrates the flow of a packet through these router types. MPLS packets travel across an LSP and are assigned labels based on the configuration present in the LSR. In this case the packets travelling between Santiago and Rio are given a label value of 0. Label value 0 represents an explicit NULL label; therefore, this figure represents a network scenario that uses UHP. Figure 12-7. LSP Router Types
An LSR possesses the following the major characteristics of MPLS forwarding:
Any given LSR must also be capable of performing several key functions for MPLS:
The ingress router, also known as the head-end router, marks the entry point of an LSP. The ingress router will take an incoming packet and look at the destination IP address. If an LSP exists to that address, it will assign the packet a label and forward it to the next LSR ”either a transit LSR or the egress point ”along the LSP. If an LSP to the destination address does not exist, then the router will use other routing table entries to resolve the next-hop. When a transit router receives a packet with an MPLS label, it will then treat the packet as an MPLS packet, and no Layer 3 decisions will be applied. This router will compare the incoming interface and label of the packet to an MPLS table to determine the outbound interface and label. If this router is the penultimate router, then it will either tell the egress router what to do with the packet or pop the label and forward the unlabelled packet to the ultimate router (PHP). The egress router will typically receive a label value of 0, unless PHP has been configured. In that case the egress router receives from the penultimate router an IP packet with no MPLS encapsulation. If, however, PHP has not been configured, and the egress router receives a packet with a label, it will pop the label and forward the packet based upon its original characteristics. There is a case where the label received by the egress router is different from those listed here. If this is the case, it is usually on a statically defined LSP, and specific configuration statements are included to tell the router to pop the label and forward accordingly . 12.3.2 Establishing an LSPAs was mentioned previously in Section 12.3.1.2, there are several ways of creating an LSP. These methods include LDP, RSVP, and CSPF and are explored in detail in the following sections. 12.3.2.1 LDPLDP is used to create dynamic LSPs in an MPLS network. Defined in RFC 3037, LDP is typically used in nonexplicit and non-traffic-engineered scenarios. LDP typically establishes LSPs based upon the already running IGP's routes. In addition to typical hop-by-hop LSP establishment, LDP can tunnel through RSVP-created LSPs. This one of several methods used for construction of MPLS-based VPNs. More details on VPNs can be found in Chapter 13. LDP operations are quite simple and based on a set of four different messages. The bibliography at the end of this chapter lists additional documentation to refer to for detailed explanations of LDP, as well as MPLS and RSVP. LDP works on a peer-to-neighbor relationship. As with all LSPs, an LDP LSP can be a single hop from one router to another or across the entire network. The four message types outlined by RFC 3036 used in LDP are as follows :
These messages each play a specific role in the creation of LDP-based LSPs. Discovery messages are used to create a neighbor or peer adjacency. LDP will send hello messages out an LDP-enabled interface. Hello messages are sent on UDP port 646. When a neighbor answers this hello message, an adjacency is formed. Further communication is then sent via a TCP session. Session messages are used to maintain each LDP session with each LDP peer. Session messages are responsible for handling the following:
Advertisement messages are responsible for the following functions relating to the FEC table in each LSR:
When a label is created in the local system, it will send an advertisement message to the associated peer advising of the creation. If the IGP path for the LDP-based LSP goes away, then advertisement messages are used to delete the label associated for the path between the two peers. Notification messages come in two forms:
12.3.2.2 RSVPRSVP was designed to signal bandwidth requirements on a per-flow basis. Juniper Networks has implemented an extended version of RSVP [RSVP with traffic-engineering extensions (RSVP-TE)]. RSVP within the JUNOS implementations is for use in support of MPLS LSPs. The Juniper Networks implementation of RSVP will continue to be referred to as RSVP in this text as this is how it is referenced in the JUNOS software. RSVP is used to reserve resources in a given path for either multicast or unicast traffic. It uses its own messaging system within the protocol to make these reservations . RSVP also allows a given path to be established (reserved) with specific QoS parameters. Juniper Networks' implementation of traffic engineering takes advantage of the characteristics of RSVP and uses the protocol to establish dynamic LSPs. These LSPs can contain strict or loose hops in their definition. RSVP uses a messaging system to create LSPs. The message types are as follows:
The JUNOS implementation of RSVP also contains extensions that provide traffic-engineering enhancements. These enhancements include the following:
There are many configurable attributes within the RSVP structure, including timers for path reservations and bandwidth settings per interface, session, and traffic flow. These are all configurable with the RSVP/MPLS configuration parameters. See Case Study 2 at the end of this chapter for a look at some of the options available when configuring RSVP. 12.3.2.3 CSPFCSPF, or Constrained Shortest Path First, is used in JUNOS to compute LSPs with constraints. CSPF is used to add variables to the TED. These variables are then used in conjunction with the TED and the SPF algorithm to create the most efficient LSP for the network. In CSPF, several attributes must be considered . These are classified in two distinct families: LSP attributes and link attributes. The LSP attributes consist of the following:
The link attributes consist of the following:
12.3.3 Prefix Mapping and Routing Table IntegrationThis section looks at two interrelated topics: prefix mapping and routing table integration. Prefix mapping refers to the ability to set up the equivalent of a static route to force packets destined for a prefix to use a specific, pre-established LSP. This feature is useful when establishing a connection to a distant network that is not advertised through BGP or IGP. With MPLS enabled, the local system is told to use a specific LSP to forward traffic to a given prefix. This can be beneficial when it becomes necessary to provide connectivity to a group of networks that may be open , but not reachable by the rest of the network resources. Routing table integration describes the concept of relying on multiple tables when resolving the next-hop. Each of the different routing tables is populated by specific protocols. However, depending on the configuration of the LSR, it is possible to have information from one routing table carried over into other tables. Chapter 8 describes routing tables used within JUNOS. Each of these routing tables has a specific function. When referring to MPLS and traffic engineering, the following routing tables are relevant:
The following example shows the output of the show route table inet.3 command. Here there is a route to address 192.168.24.1 . This is because the RSVP LSP configuration points to the loopback address of the remote router. lab@Chicago> show route table inet.3 inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.24.1/32 *[RSVP/7] 00:12:04, metric 30, metric2 0 > to 10.0.15.1 via ge-3/0/0.0, label-switched-path 1 The next example shows the mpls.0 table from a router running RSVP. Notice the label number 251042 . This is the label used in the router for the LSP created by RSVP. lab@Chicago> show route table mpls.0 mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0 *[MPLS/0] 6d 05:43:22, metric 1 Receive 1 *[MPLS/0] 6d 05:43:22, metric 1 Receive 251042 *[RSVP/7] 00:15:16, metric 1 > to 10.0.13.2 via ge-1/1/1.0, label-switched-path 1 Recall from Chapter 9 that BGP will prefer routes in inet.3 over routes in inet.0 . The example below shows this. The show route protocol bgp command has been issued. The route for the 192.168.24.0 network is not the typical route that was there before. This route exists because it was chosen from the inet.3 table. lab@Chicago> show route protocol bgp inet.0: 26 destinations, 26 routes (25 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 192.168.24.0/24 *[BGP/170] 5d 23:02:50, MED 0, localpref 100, from 192.168.24.1 AS path: I > to 10.0.15.1 via ge-3/0/0.0, label-switched-path 1 These commands are invaluable when troubleshooting MPLS- related issues. For more troubleshooting tactics, see Chapter 15. This section illustrated the contents of the routing tables that can be involved in MPLS traffic engineering. Further examples of routing table contents can be found in the case studies at the end of this chapter. 12.3.4 Traffic ProtectionTraffic protection typically refers to a network's resiliency against outage . This section shows how Juniper Networks routers provide this capability in a traffic-engineered network. In a typical IGP scenario, when a link goes down, the IGP will recalculate the best path to the destination address so long as it is still reachable. In MPLS, traffic protection occurs in a similar manner. Keepalive messages are periodically sent between LSRs by way of the signaling protocol (RSVP). When there is an outage, the LSR upstream of the outage uses RSVP to signal the ingress LSR that there is a failure. The ingress LSR then recalculates a new path to the destination and builds a new LSP. A potential problem is the time required to recalculate a new route for the LSP. RSVP relies on the native underlying network IGP; therefore, the underlying IGP must reconverge following link failure before the RSVP protocol is capable of starting the process of establishing a new LSP. To combat this issue, JUNOS implements two key features: secondary paths and fast reroute . With secondary paths, JUNOS can define a secondary LSP to use in the event there is a failure of the primary LSP. Caution should be used when engineering the secondary path. For the sake of true redundancy and the elimination of single points of failure, it is best to create a secondary path that uses different routers and circuits than the primary. Fast reroute is a method employed to patch a link failure prior to creating a new LSP. Figure 12-8 illustrates this. There are six routers involved in this network. Chicago is the ingress router, and London is the egress router. The active LSP from Chicago to London traverses through routers San Francisco and New York. Figure 12-8. MPLS ”Traffic Protection Fast Reroute
Let's assume there is a failure of the link between San Francisco and New York. In Figure 12-8, San Francisco, having fast reroute enabled, would attempt to rebuild the LSP from its point of failure. In this case, San Francisco would signal the repaired portion of the path from San Francisco to Brussels to Amsterdam to New York. This gets the LSP up in the least amount of time. In addition to this repairing of the LSP, San Francisco would then signal to Chicago to establish a new end-to-end LSP with London. In a scenario where maximum protection is necessary, it is possible to employ both standby secondary path and fast reroute. In this scenario the LSP failure due to link failure could immediately be repaired with fast reroute, while at the same time, the upstream router from the failure would signal the ingress router of the failure and request use of the secondary path. With both methods being deployed, the ingress router would switch to the pre-engineered secondary path. When using standby secondary path or fast reroute, it is important to understand potential bottlenecks in the physical topology. If the physical infrastructure is not completely understood , then the potential exists to have configured and assumed operability of traffic protection without actually having the protection. Testing such scenarios is suggested to set a minimal level of expectation. This section covered the operational theory behind the methods of establishing an LSP. This included the signaling protocols RSVP and LDP and the use of CSPF and the TED. This section also described routing table integration issues and the theory behind configuring secondary LSPs and fast rerouting as methods of protecting traffic. The following sections demonstrate how to build functional configurations that employ MPLS, RSVP, and LDP. |