Adspec Object (13) Flags: [reject if unknown], Class-Type: IntServ (2), length: 48 Msg-Version: 0, length: 40 Service Type: Default/Global Information (1), break bit not set, Service length: 32 Parameter ID: IS hop cnt (4), length: 4, Flags: [0x00] IS hop cnt: 1 Parameter ID: Path b/w estimate (6), length: 4, Flags: [0x00] Path b/w estimate: 0 Mbps Parameter ID: Minimum path latency (8), length: 4, Flags: [0x00] Minimum path latency: don’t care Parameter ID: Composed MTU (10), length: 4, Flags: [0x00] Composed MTU: 1500 bytes Service Type: Controlled Load (5), break bit not set, Service length: 0 ERO Object (20) Flags: [reject if unknown], Class-Type: IPv4 (1), length: 28 Subobject Type: IPv4 prefix, Strict, 10.154.1.5/32, Flags: [none] Subobject Type: IPv4 prefix, Strict, 10.154.6.1/32, Flags: [none] Subobject Type: IPv4 prefix, Strict, 10.254.1.45/32, Flags: [none] Label Request Object (19) Flags: [reject if unknown], Class- Type: without label range (1), length: 8 L3 Protocol ID IPv4 RRO Object (21) Flags: [reject if unknown], Class-Type: IPv4 (1), length: 12 Subobject Type: IPv4 prefix, Strict, 10.154.1.6/32, Flags: [none] This is the response to the previous Label Setup Message. Note that the Session object contents need to match in order for the router to match the RSVP message to a certain session. 12:35:51.199611 IP (tos 0xc0, ttl 255, id 6344, offset 0, flags [none], length: 164) 10.154.1.5 > 10.154.1.6: RSVP v: 1, msg-type: Resv, length: 144, ttl: 255, checksum: 0x2efc Session Object (1) Flags: [reject if unknown], Class-Type: Tunnel IPv4 (7), length: 16 IPv4 Tunnel EndPoint: 209.211.134.10, Tunnel ID: 0x0013, Extended Tunnel ID: 209.211.134.9 RSVP Hop Object (3) Flags: [reject if unknown], Class-Type: IPv4 (1), length: 12 Previous/Next Interface: 10.154.1.5, Logical Interface Handle: 0x0853f4c8 Time Values Object (5) Flags: [reject if unknown], Class-Type: 1 (1), length: 8 Refresh Period: 30000ms Style Object (8) Flags: [reject if unknown], Class-Type: 1 (1), length: 8 Reservation Style: Fixed Filter, Flags: [0x00] Flowspec Object (9) Flags: [reject if unknown], Class-Type: IntServ (2), length: 36 Msg-Version: 0, length: 28 Service Type: Controlled Load (5), break bit not set, Service length: 24 Parameter ID: Token Bucket TSpec (127), length: 20, Flags: [0x00] Token Bucket Rate: 0 Mbps Token Bucket Size: 0 bytes Peak Data Rate: inf Mbps Minimum Policed Unit: 20 bytes Maximum Packet Size: 1500 bytes MPLS Signalling Protocols 411 FilterSpec Object (10) Flags: [reject if unknown], Class-Type: Tunnel IPv4 (7), length: 12 Source Address: 209.211.134.9, LSP-ID: 0x0005 Label Object (16) Flags: [reject if unknown], Class-Type: Label (1), length: 8 Label 12324 RRO Object (21) Flags: [reject if unknown], Class-Type: IPv4 (1), length: 36 Subobject Type: IPv4 prefix, Strict, 10.154.1.5/32, Flags: [none] Subobject Type: IPv4 prefix, Strict, 10.154.6.1/32, Flags: [none] Subobject Type: IPv4 prefix, Strict, 10.254.1.45/32, Flags: [none] Subobject Type: IPv4 prefix, Strict, 10.254.1.2/32, Flags: [none] The Label Request Object is embedded in a RSVP-TE PATH message and gives RSVP- TE the ability to request a label and subsequently return a label using the Label Object in a RSVP-TE RESV message. The Explicit Route Object (ERO) allows RSVP-TE to spec- ify a set of nodes that an RSVP-TE message has to traverse. Figure 14.12 shows sample EROs modelled using the Loose and Strict (L/S) path constraint. A Strict hop indicates that the next hop must be directly connected to the previous hop. The first example of Figure 14.12 shows a set of strict hops that specify a path. A sequence of strict hops is often used to nail down a path – that is, when the network administrator wants to enforce a certain path. A Loose hop means that the node has to be present in the path before the next hop, but does not have to be the next-hop. The second example of Figure 14.12 shows that only a subset of the nodes is listed in the ERO. With the Loose attribute, this means that there is some room for re-routing this path. The path could potentially run directly from Washington via Frankfurt to Pennsauken. In practice, the Loose option causes more problems than it solves. The network is not in full control of the traffic path anymore and in more complex topologies this may lead to strange results with long delay paths. The third example in Figure 14.12 shows a mix between loose and strict hops. The semantics of the ERO Objects allows for the combination of loose and strict hops in an arbitrary fashion. There are two general ways to create an ERO. The first is a manual specification and the second, more sophisticated way, is automated computation. The manual configur- ation will be discussed first. You can configure a label switched path using an ERO in similar ways on IOS and JUNOS. First you need to specify the ERO and next you need to link the ERO to a label switched path. IOS configuration In IOS you can specify an ERO manually using the ip explicit-path statement. The next-address specifies the next-element in the ERO. By default all hops in the ERO are strict except when you supply the loose keyword. ip explicit-path identifier name via-Penssauken enable next-address 192.168.1.1 next-address loose 192.168.2.1 […] ! 412 14. Traffic Engineering and MPLS MPLS Signalling Protocols 413 Area 49.0001 Level 2-only ERO Paris strict; Frankfurt strict; London strict; Pennsauken strict; Area 49.0001 Level 2-only ERO Frankfurt loose; Pennsauken loose; Area 49.0001 Level 2-only ERO Frankfurt strict; Pennsauken loose; Pennsauken Frankfurt London Washington New York Paris Pennsauken Frankfurt London Washington New York Paris Pennsauken Frankfurt London Washington New York Paris FIGURE 14.12. The ERO consists of a mix and match list of Strict and/or Loose Hops After defining the ERO you need to link it to an existing tunnel using the path- option explicit argument to the tunnel mpls traffic-eng command. IOS configuration In order to switch from dynamic computation to an explicit execution use the tunnel mpls traffic-eng path-option 5 explicit command. interface Tunnel0 description TE Tunnel to Washington via Penssauken ip unnumbered Loopback0 tag-switching ip tunnel destination 192.168.20.1 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng path-option 5 explicit name via-Penssauken ! In JUNOS the configuration is very similar – first you specify the ERO. JUNOS configuration In JUNOS you configure manual EROs under the protocols mpls path {} configura- tion branch. protocols { mpls { path via-Penssauken { 192.168.1.1 strict; 192.168.2.1 loose; } } } Next you link the ERO into an existing label switched path. You need to declare the path as a primary or secondary path. JUNOS configuration The tunnel is configured under the protocols mpls label-switched-path {} state- ment. JUNOS has the notion of a primary/secondary path where you can specify a backup path that is immediately used if the primary path fails. protocols { mpls { label-switched-path “TE Tunnel to Washington via Pennsauken” { to 192.168.20.1; primary via-Pennsauken; } } } 414 14. Traffic Engineering and MPLS After you have configured your tunnels, you need to verify if the TE tunnel is up and if the tunnel is following the desired path. Because awkward combination of the Loose and Strict Hop option can cause unexpected results – the Record Route Object (RRO) pro- vides better visibility for troubleshooting purposes. The Record Route Object is embed- ded in the RSVP-TE RESV messages. During its journey from the egress router to the ingress router all IP addresses are recorded and stored at the ingress router. On IOS, you have to explicitly turn on generation to the RRO object using a Tunnel Interface path option, in JUNOS it is automatic. IOS configuration In IOS the Record Route Object (RRO) is not automatically generated for a TE tunnel. It needs to get configured explicitly using the tunnel mpls traffic-eng record-route command. interface Tunnel0 [… ] tunnel mpls traffic-eng record-route ! The contents of the RRO Object can be displayed using the show mpls traffic- eng tunnels command in IOS. IOS output The show mpls traffic-eng tunnels command contains all the information around a tunnel. The configured ERO, the tunnel’s bandwidth, outgoing labels and more of interest is included in the Route Record Object (RRO). London#show mpls traffic-eng tunnels Name: TE Tunnel to Washington via Pennsauken (Tunnel0) Destination: 192.168.20.1 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type explicit via-Pennsauken (Basis for Setup,path weight 10) Config Parameters: Bandwidth: 1 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 1 bw-based auto-bw: disabled InLabel : - OutLabel : POS4/1, 100016 MPLS Signalling Protocols 415 RSVP Signalling Info: Src 192.168.1.2, Dst 192.168.20.1, Tun_Id 0, Tun_Instance 511 RSVP Path Info: My Address: 192.168.1.2 Explicit Route: 192.168.1.1 192.168.168.3 Record Route: Tspec: ave rateϭ1 kbits, burstϭ1000 bytes, peak rateϭ1 kbits RSVP Resv Info: Record Route: 172.16.33.1 172.16.38.1 Fspec: ave rateϭ1 kbits, burstϭ1000 bytes, peak rateϭ1 kbits History: Tunnel: Time since created: 12 days, 17 hours, 39 minutes Time since path change: 1 minutes, 13 seconds Current LSP: Uptime: 1 minutes, 13 seconds Most often you will notice a difference between the configured ERO and the recorded PATH. It is common practice to use a router’s loopback ID as the address for a loose hop. However, the route recorder in the PATH message thinks entirely in terms of link addresses. So even if we used in our example the 192.168/16 addresses, the ones actually reported back in the RRO are from the link-address space 172.16/16. In JUNOS you can also display the recorded path using the show mpls lsp ingress detail command. JUNOS output hannes@Frankfurt> show mpls lsp ingress detail Ingress LSP: 1 sessions 192.168.1.1 From: 192.168.1.2, State: Up, ActiveRoute: 0, LSPname: to-Washington ActivePath: (primary) LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 192.168.1.1 192.168.168.3 S Received RRO (ProtectionFlag 1ϭAvailable 2ϭInUse 4ϭB/W 8ϭNode): 172.16.33.1 172.16.38.1 Total 1 displayed, Up 1, Down 0 JUNOS behaves similarly to IOS, where the Route Path Recording is done using link addresses. If you want to achieve any-to-any MPLS connectivity between all routers in your network, then the consequence is to deploy a full-mesh of RSVP-TE tunnels. However, there are severe scaling implications with that approach. To overcome these scaling limitations a more lightweight MPLS label setup protocol called the Label Distribution Protocol (LDP) is used. 416 14. Traffic Engineering and MPLS 14.4.3 LDP LDP is defined in RFC 3036 and it describes a lean, lightweight protocol that brings up a full-mesh of connectivity to all LDP speakers in the network. Generally, the term full- mesh raises warning flags in every network engineer’s head due to the perceived scaling problems. However, LDP uses a technique called label-merging which is very conserva- tive with label allocation. Consider the right-hand side of Figure 14.13. There are five drawings inside the figure, one for each possible egress router. The egress router is marked with an E, and the metric on each link is 4. MPLS Signalling Protocols 417 Frankfurt Pa LDP label allocation 6 4 4 4 4 4 6 4 4 4 4 4 6 4 4 4 4 4 6 4 4 4 4 4 6 4 4 4 4 4 RSVP label allocation 6 4 4 4 4 4 6 4 4 4 4 4 6 4 4 4 4 4 6 4 4 4 4 4 6 4 4 4 4 4 Frankfurt London Washington NewYork Paris E E Frankfurt London Washington New York Paris Frankfurt London Washington NewYork Paris Frankfurt London Washington NewYork Paris Frankfurt London Washington New York Paris Frankfurt London Washington New York Paris Frankfurt London Washington NewYork Paris Frankfurt London Washington NewYork Paris Frankfurt London Washington New York Paris Frankfurt London Washington NewYork Paris E E E E E E E E FIGURE 14.13. LDP consumes less forwarding state per link than RSVP does The figure describes the LSPs and the necessary forwarding state to set up full-mesh connectivity between all five routers in the core network. Using RSVP-TE, we would need at least N * (N – 1)/2 ϭ 10 explicitly configured tunnels. Because LDP supports label merging, some labels can be re-used by other label switched paths. Unlike RSVP-TE, LDP signals its label using a mode called downstream unsolicited, which means that the labels are signalled from the egress router to the ingress router. Each LDP speaker advertises prefixes according to the egress policy. In JUNOS, the default egress policy is just to advertise the loopback IP address. The IOS default egress policy is to advertise both the loopback and all the directly connected interfaces. Upstream nodes create MPLS SWAP states and pass on the label-mapping message to their upstream nodes, which cre- ate again MPLS SWAP states, and pass them on to further upstream nodes, and so on. The resulting shape of the merged tree is called a sink tree. (In datacom speech the egress or destination point is sometimes called the sink.) And because the root of the tree is at the egress router, it is therefore a sink tree. Figure 14.14 shows the number of forwarding entries (FE) that the sum of all label switched paths generates. Even in the small topology, LDP behaves better than RSVP-TE. LDP has an average of 3 FEs per link versus RSVP-TE, which consumes an average of 4.33 FEs per link. LDP is therefore the protocol of choice for edge systems like VPN and/or customer access routers, due to LDP’s ability to supply a full-mesh con- nectivity to all the other LDP speakers with no setup complexity at all. The configuration of LDP is a simple one: just enable it on a per-interface basis. An LDP configuration for router London on IOS could look like the following: IOS configuration In IOS two configuration lines are necessary for running LDP. First turn on MPLS pro- cessing on an interface plus the necessary Layer-2 Supporting Protocols like MPLSCP over PPP using the tag-switching ip keyword. The mpls label protocol ldp key- word tells the system to run LDP rather than TDP (Cisco’s proprietary predecessor to LDP). London#sh running-config [… ] ! interface POS4/1 ip address 172.17.0.5 255.255.255.252 ip router isis encapsulation ppp mpls label protocol ldp tag-switching ip ! Shortly after configuration, a remote LDP neighbour should be detected and an LDP session is then set up automatically. You can verify the neighbour state using the show mpls ldp neighbor operational level command. 418 14. Traffic Engineering and MPLS 419 Forwarding state/LDP label allocation Forwarding state/RSVP label allocation 8 FE 4 FE 4 FE 4 FE 3 FE 3 FE 4 FE 2 FE 3 FE 3 FE 3 FE 3 FE avg. 3 FE/LINK avg. 4.33 FE/LINK Frankfurt London Washington New York Paris Frankfurt London Washington New York Paris F IGURE 14.14. The sum of all forwarding states show that LDP is more frugal than RSVP IOS output Under the show mpls ldp <*> hierarchy several commands are available to verify neigh- bour state and timers. London#show mpls ldp neighbor Peer LDP Ident: 192.168.0.1:0; Local LDP Ident 192.168.13.8:0 TCP connection: 192.168.0.1.646 - 192.168.13.8.11000 State: Oper; Msgs sent/rcvd: 207/179; Downstream Up time: 00:28:43 LDP discovery sources: POS4/0, Src IP addr: 172.16.0.2 Addresses bound to peer LDP Ident: 172.16.0.2 The display output shows whether the session is up and what IP addresses are being used. LDP uses link IP addresses for discovery and loopback IP addresses for session setup. If a session does not come up due to addressing conflicts the output of this com- mand is providing valuable information for troubleshooting. In JUNOS we need to make sure that family mpls is configured under the logical interface branch. In addition we add a list of interfaces where we want to speak LDP under the protocols ldp stanza. JUNOS configuration In JUNOS you need to specify the interface where you want to run LDP both under the protocols mpls {} and protocols ldp {} stanza. Alternatively you can set the mpls interface list to all which allows allocation of labels on all interfaces. In addition every logical interface needs to have the family mpls configured. hannes@Frankfurt# show [… ] interface ge-0/0/0 { unit 0 { family mpls; } } protocols { mpls { interface all; } ldp { interface so-0/1/2.0; } } [… ] It remains unknown why mpls interface all {} is not the default option, since this does not break anything by being turned on. On the other hand, it does break 420 14. Traffic Engineering and MPLS . datacom speech the egress or destination point is sometimes called the sink.) And because the root of the tree is at the egress router, it is therefore a sink tree. Figure 14.14 shows the number. Figure 14.12 shows that only a subset of the nodes is listed in the ERO. With the Loose attribute, this means that there is some room for re -routing this path. The path could potentially run directly. our example the 192.168/16 addresses, the ones actually reported back in the RRO are from the link-address space 172.16/16. In JUNOS you can also display the recorded path using the show mpls