|
|
< Free Open Study > |
|
Resource Reservation Protocol (RSVP)After a path is calculated with CSPF, that path needs to be signalled across the network for two reasons:
This signalling is accomplished using RSVP, along with RSVP extensions for MPLS TE. RSVP itself is specified in RFC 2205, with some pertinent extensions in RFC 2210. The MPLS TE extensions to RSVP are specified in RFC 3209. The RSVP discussion in this chapter is divided into four parts:
The two most important sections to understand are "RSVP Basics" and "RSVP in the Real World." The "RSVP Packets" and "RSVP Operation" sections are useful for understanding exactly how RSVP does what it does. RSVP BasicsRSVP is a signalling mechanism used to reserve resources throughout a network. It has its own protocol type (46), although it is possible to encapsulate RSVP in UDP. MPLS TE never encapsulates RSVP in UDP, so that isn't discussed further. RSVP is not a routing protocol. Any routing decisions are made by the IGP (including TE extensions) and CSPF. RSVP's only job is to signal and maintain resource reservations across a network. In MPLS TE, RSVP reserves bandwidth at the control-plane layer; there is no forwarding-plane policing of traffic. When used for other purposes (such as VoIP or DLSW+ reservations), RSVP can be used to reserve Weighted Fair Queuing (WFQ) space or build ATM SVCs. Those uses are not discussed here. RSVP has three basic functions:
RSVP is a soft-state protocol. This means that it needs to periodically refresh its reservations in the network by resignalling them. This is different from a hard-state protocol, which signals its request once and then assumes that the request is up until it is explicitly taken down. With RSVP, a request goes away either if it is explicitly removed from the network by RSVP or if the reservation times out. Table 4-20 lists the nine different defined RSVP message types.
These message types are explained in more detail in the upcoming section "RSVP Packets." Path Setup and MaintenanceAlthough path setup and maintenance are similar, they differ in a subtle way. Even though they use the same message formats do to what they do, it's worth explaining them separately the first time around. Path SetupAfter a tunnel headend completes its CSPF for a particular tunnel, it needs to signal this request to the network. The headend does this by sending a Path message to the next-hop node along the calculated path to the destination. The router that sent the Path message is called the upstream router, and the router that received the message is called the down-stream router. The upstream router is sometimes called the previous hop (phop). After a downstream router receives a Path message, it does a few things. It checks the message's format to make sure everything is OK, and then it checks the amount of bandwidth the received Path message is asking for. This process is known as admission control. If admission control is successful and the Path message is allowed to reserve the bandwidth it wants, the downstream router creates a new Path message and sends it to the next hop in the Explicit Route Object (ERO), which is covered later in this chapter. Path messages follow this chain until they reach the last node in the ERO—the MPLS TE tunnel tail. The tunnel tail performs admission control on the Path message, just like any other downstream router. When the tail realizes that it is the destination of the Path message, it replies with a Resv message. Think of the Resv message as an ACK back to the upstream router. The Resv message not only contains an acknowledgment that the reservation made it all the way to the tunnel tail, but it also contains the incoming label that the upstream router should use to send packets along the TE LSP to the tail. Figure 4-11 shows the exchange of RSVP path and Resv messages during LSP setup. Figure 4-11. RSVP Path and Resv Messages During LSP Setup
Figure 4-11 has 10 steps. The following is a walk-through of what happens with Path and Resv messages in those steps. Assume that R1 has done its CSPF already and knows that it wants to reserve bandwidth along the path R1
At this point, R1 is done. It has received a Resv message for the tunnel to R7 it set up, and it knows which outgoing label to use. The Tunnel interface on R1 now comes up/up (until this point, the Tunnel interface is up/down). Path MaintenanceAt first glance, path maintenance looks just like path setup. Every 30 seconds (give or take 50 percent—see "RSVP Operation" later in this chapter), a headend sends one Path message per tunnel to its downstream neighbors. If a router sends out four Path messages in a row and does not see a Resv during that time, it considers the reservation gone and sends a message upstream, indicating that the reservation is gone. However, there is one important thing to understand here. Path and Resv messages are both sent independently and asynchronously from one neighbor to another. Look again at Figure 4-11. Every 30 seconds, R1 sends a Path message for its one TE reservation to R2. And every 30 seconds, R2 sends a Resv message to R1 for that same reservation. The two messages, however, are not connected. A Resv message used to refresh an existing reservation is not sent in response to a Path message, as an ICMP Echo Reply would be sent in response to an ICMP Echo Request. Why are things done this way? Largely to accommodate the merging of flows in "classic" RSVP (VoIP, DSLW+, that sort of thing), and these messages don't really apply to TE. If this doesn't make sense to you, don't worry about it. Just remember this when you start troubleshooting a TE problem and you don't see ping/ACK behavior with Path and Resv messages. Path TeardownPath teardown is pretty straightforward. If a node (usually the headend) decides that a reservation is no longer necessary in the network, it sends a PathTear along the same path that the Path message followed and a ResvTear along the same path that the Resv message followed. PathTear messages are most commonly seen when the headend decides it no longer wants a reservation in the network (when a tunnel is shut down or reroutes off a certain path, for example). ResvTear messages are sent in response to PathTear messages to signal that the tunnel tail has removed the reservation from the network. Cisco IOS Software sends Resv messages and asks for confirmation that the reservation has been torn down; this results in a ResvTearConf message being sent back from the headend to the tail. PathTear and ResvTear messages can also be sent in response to an error condition in the middle of the network. You'll read more about this in the "RSVP Operation" section. Much like refresh messages, PathTear messages don't have to go all the way downstream before taking effect. In Figure 4-11, if R1 sends a PathTear to R2, R2 immediately replies with a ResvTear and then sends its own PathTear downstream. Error SignallingOccasionally, there can be errors in RSVP signalling. These errors are signalled by PathErr or ResvErr messages. An error detected in a Path message is responded to with a PathErr message, and an error detected in a Resv message is responded to with a ResvErr message. Error messages are sent upstream toward the source of the error; a PathErr is sent toward the upstream from a downstream node, and a ResvErr is sent downstream from an upstream node. You'll read more about this in the next section. RSVP PacketsThe RSVP packet format is pretty straightforward. Every RSVP message is composed of a common header, followed by one or more objects. The number of objects in a message depends on exactly what the message is trying to accomplish. RSVP Common HeaderFigure 4-12 shows the RSVP common header format. Figure 4-12. RSVP Common Header Format
Table 4-21 explains the fields in the RSVP common header.
RSVP Object Class FormatsRSVP objects all have the same basic format, as illustrated in Figure 4-13. Figure 4-13. RSVP Object Format
Table 4-22 describes the fields in the basic RSVP object format.
Twenty-three different object classes are defined. Not all of them are used in RSVP signalling for MPLS TE, but for the sake of completeness, they're all listed in Table 4-23.
Each class has its own C-Type number space. The C-Type numbers are unique within a class. For example, the SESSION class has four defined C-Types: IPv4, IPv6, LSP_TUNNEL_IPv4, and LSP_TUNNEL_IPv6. The numbers assigned to these C-Types are 1, 2, 7, and 8. LABEL_REQUEST has three C-Types defined: Without Label Range, With ATM Label Range, and With Frame Relay Label Range. The numbers assigned to these C-Types are 1, 2, and 3. You can see that a C-Type of 1 is not enough to uniquely identify a message's contents; you need to look at both the class and C-Type numbers. NOTE Yes, this is confusing. Think of RSVP classes and C-Types as any other type of hierarchical numbering scheme—such as phone numbers, for example. In RSVP, to identify exactly what's in the RSVP Message you received, you have to look at both the class and the C-Type of each object. It's like looking at a phone number—you need both the area code and the local number. Dialing 867-5309 isn't enough; you need to know that it's (701) 867-5309 to get through to the right person. An RSVP message contains one or more objects. Not all messages contain all objects. The objects a message contains depends on the message definition. Table 4-24 lists the classes and C-Types used in Cisco's implementation of RSVP-TE.
To give you the complete picture, the following sections look at all the object formats. They might not make much sense in isolation. It's probably best to scan this section, read the sections about the various message formats later in this chapter, and then come back here if you're a glutton for details and/or punishment. SESSION ClassFigure 4-14 shows the SESSION class object format. Figure 4-14. SESSION Class Format
The SESSION object is defined in RFC 2205. RFC 3209 defines C-Type 7 (LSP_TUNNEL_IPV4), which has the four fields described in Table 4-25.
TIME_VALUES ClassFigure 4-15 shows the TIME_VALUES class object format. Figure 4-15. TIME_VALUES Class Format
RFC 2205 defines the TIME_VALUES object as the refresh period (in milliseconds) used to send Path or Resv messages. ERROR_SPEC ClassFigure 4-16 shows the ERROR_SPEC class object format. Figure 4-16. ERROR_SPEC Class Format
RFC 2205 defines the ERROR_SPEC object and also defines error codes 00 through 23. RFC 3209 defines error code 24, which holds errors specific to MPLS TE. In MPLS TE, you're most likely to see error code 00 (Confirmation—sent in response to receiving a message with a CONFIRMATION object) or error code 24. When the error code is 00, the error value is also 00. When the error code is 24, there are 10 possible error values, as documented in Table 4-26. There's also an error code 25 that generally only shows up when using Fast Reroute, and which is covered in more detail in Chapter 7. Generally, the Flags field is 0 when you're using MPLS TE.
SCOPE ClassFigure 4-17 shows the SCOPE class object format. Figure 4-17. SCOPE Class Format
RFC 2205 defines the SCOPE class. The SCOPE class is not used in Cisco's MPLS TE implementation because it implies a wildcard reservation style, whereas MPLS TE uses Shared Explicit or Fixed Filter (see the "Shared Explicit Reservation Style" section). STYLE ClassFigure 4-18 shows the STYLE class object format. Figure 4-18. STYLE Class Format
The STYLE class specifies the reservation style. The three possible styles are
Cisco IOS Software uses Shared Explicit for MPLS TE reservations. The Flags field is unused. The Option Vector is always 0x12, indicating Shared Explicit style. See the "Shared Explicit Reservation Style" section for more details. FLOWSPEC ClassFigure 4-19 shows the FLOWSPEC class object format. Figure 4-19. FLOWSPEC Class Format
The FLOWSPEC class is defined in RFC 2210. Cisco IOS Software requests Controlled-Load service when reserving a TE tunnel. The FLOWSPEC format is complex and has many things in it that RSVP for MPLS TE doesn't use. The FLOWSPEC is used in Resv messages—Resv, ResvTear, ResvErr, ResvConf, ResvTearConf. Its only use in MPLS TE is to use the average rate section of the FLOWSPEC to specify the bandwidth desired, in bytes. Not bits. Bytes. So if you configure a tunnel with tunnel mpls traffic-eng 100000 to request 100 Mbps of bandwidth, this gets signalled as 12,500,000 bytes per second (100 Mb is 100,000 Kb is 100,000,000 bits, which is 12,500,000 bytes). FILTER_SPEC ClassFigure 4-20 shows the FILTER_SPEC class object format. Figure 4-20. FILTER_SPEC Class Format
The FILTER_SPEC class is defined in RFC 2205. RFC 3209 adds the C-Type 7, LSP Tunnel IPv4. The IPv4 Tunnel Sender Address field specifies the router ID of the TE tunnel headend, and the LSP ID field specifies the tunnel's LSP ID. The LSP ID changes when a tunnel's properties change (a bandwidth change or path change). See the "RSVP Operations" section for more information on how this is used. FILTER_SPEC is seen only in Resv and Resv-associated messages (ResvTear, ResvErr, and so on). SENDER_TEMPLATE ClassFigure 4-21 shows the SENDER_TEMPLATE class object format. Figure 4-21. SENDER_TEMPLATE Class Format
The SENDER_TEMPLATE is defined in RFC 2205, and RFC 3209 defines the C-Type 7, LSP Tunnel IPv4. It has the same format and purpose as the FILTER_SPEC class. Why does the same information have two different names, depending on direction? We have no idea. But it does. SENDER_TSPEC ClassFigure 4-22 shows the SENDER_TSPEC class object format. Figure 4-22. SENDER_TSPEC Class Format
The SENDER_TSPEC class is generally seen only in Path messages. It's the same thing as FLOWSPEC, except that SENDER_TSPEC is seen in Path messages. Just like FLOWSPEC, the only part of SENDER_TSPEC that MPLS TE cares about is the average rate section. ADSPEC ClassFigure 4-23 shows the ADSPEC class object format. Figure 4-23. ADSPEC Class Format
ADSPEC is another of those complicated formats, as defined in RFC 2210. Like SENDER_TSPEC, ADSPEC is seen only in Path messages. RESV_CONFIRM ClassFigure 4-24 shows the RESV_CONFIRM class object format. Figure 4-24. RESV_CONFIRM Class Format
RESV_CONFIRM is defined in RFC 2205. It signals a request for confirmation; it appears in the Resv and ResvTear messages. The RESV_CONFIRM class sometimes shows up as CONFIRM; it's the same thing. RSVP_LABEL ClassFigure 4-25 shows the RSVP_LABEL class object format. Figure 4-25. RSVP_LABEL Class Format
The RSVP_LABEL class (sometimes just called LABEL) is defined in RFC 3209. It is a 32-bit quantity, in part because all RSVP objects must be a multiple of 4 bytes, but in frame mode, it carries the 20-bit label that the phop should use for a particular tunnel. The RSVP_LABEL class is seen only in Resv messages. LABEL_REQUEST ClassFigure 4-26 shows the LABEL_REQUEST class object format. Figure 4-26. LABEL_REQUEST Class Format
The LABEL_REQUEST object requests a label. An RSVP_LABEL object responds to it. The LABEL_REQUEST object is seen only in Path messages. It contains, in the upper 16 bits, the Layer 3 Protocol Identifier (L3PID) that is carried in the label. Cisco IOS always signals 0x800 (IP); the existence of the L3PID is somewhat historical. The fact that the LABEL_REQUEST object exists is enough to tell the downstream node that it is expected to provide a label. EXPLICIT_ROUTE ClassFigure 4-27 shows the EXPLICIT_ROUTE class object format. Figure 4-27. EXPLICIT_ROUTE Class Format: IPv4 Subobject
The EXPLICIT_ROUTE object defines the path that an MPLS TE tunnel takes. Often called the ERO, it is defined in RFC 3209. The ERO is seen only in Path messages. The ERO is a collection of subobjects. The subobject is an 8-byte quantity pictured in Figure 4-27; the IPv4 Prefix subobject is the only one Cisco IOS currently supports. Table 4-27 shows the fields in the IPv4 subobject.
RECORD_ROUTE ClassFigure 4-28 shows the RECORD_ROUTE class object format. Figure 4-28. RECORD_ROUTE Class Format
The RECORD_ROUTE object is defined in RFC 3209. There are two different RECORD_ROUTE subobjects; one is used to record the IP addresses at every hop, and the other is used to record the label used at every hop. Route recording can be configured by using the tunnel interface command tunnel mpls traffic-eng record-route. RECORD_ROUTE allows you to do two things—record the IP address at each hop in the path, or record the label. The behavior is determined by the Label Recording bit in the SESSION_ATTRIBUTE flag string. Table 4-28 describes the items in the RECORD_ROUTE object.
HELLO ClassFigure 4-29 shows the HELLO class object format. Figure 4-29. HELLO Class Format
The HELLO class has two C-Types: Hello Request (Type 1) and Hello ACK (Type 2). They are both encoded the same. The Source Instance and Destination Instance are two counters used to track RSVP neighbor state; think of HELLO messages as RSVP-level keepalives. See RFC 3209 (particularly Section 5.3) for more details on HELLO messages. SESSION_ATTRIBUTE ClassFigure 4-30 shows the SESSION_ATTRIBUTE class object format. Figure 4-30. SESSION_ATTRIBUTE Class Format
The SESSION_ATTRIBUTE class is defined in RFC 3209. SESSION_ATTRIBUTE is seen only in Path messages. SESSION_ATTRIBUTE has two types—with and without resource affinity (RA). Currently, Cisco IOS supports only the LSP Tunnel C-Type without RA (C-Type 7). This object has five fields, as listed in Table 4-29.
RSVP Message FormatsThis section examines message formats, both in theory and in practice. The objects dissected are as follows:
All the debugs in this section were captured with debug ip rsvp path detail or debug ip rsvp resv detail. Figure 4-31 shows the basic topology used to gather all these debugs. Figure 4-31. Sample Network for Packet Examples
There is a single tunnel from gsr4 to gsr8. Its configuration is shown in Example 4-9. Example 4-9 gsr4 to gsr8 Tunnel Configurationinterface Tunnel8 ip unnumbered Loopback0 no ip directed-broadcast tunnel destination 192.168.1.8 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 7 7 tunnel mpls traffic-eng bandwidth 100000 tunnel mpls traffic-eng path-option 10 dynamic end Path MessageThe Path message is defined in RFC 3209, as shown in Example 4-10. Example 4-10 Path Message
<Path Message> : <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<SENDER_TEMPLATE>
<SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
Example 4-11 shows a Path message as captured in debug ip rsvp path detail. The debug was run on the tunnel headend, gsr4. NOTE A note on the debug output: As this book was being written, the Cisco IOS Software's debug output was in the process of being reformatted. The debugs you see on your routers might be different in format from those shown here. However, the content, and the explanations therein, are the same. Example 4-11 Decoded Path Message1. RSVP: version:1 flags:0000 type:PATH cksum:1049 ttl:254 reserved:0 length:200 2. SESSION type 7 length 16: 3. Destination 192.168.1.8, TunnelId 8, Source 192.168.1.4 4. HOP type 1 length 12: C0A80304 5. : 00000000 6. TIME_VALUES type 1 length 8 : 00007530 7. EXPLICIT_ROUTE type 1 length 36: 8. (#1) Strict IPv4 Prefix, 8 bytes, 192.168.3.5/32 9. (#2) Strict IPv4 Prefix, 8 bytes, 192.168.10.6/32 10. (#3) Strict IPv4 Prefix, 8 bytes, 192.168.9.8/32 11. (#4) Strict IPv4 Prefix, 8 bytes, 192.168.1.8/32 12. LABEL_REQUEST type 1 length 8 : 00000800 13. SESSION_ATTRIBUTE type 7 length 16: 14. setup_pri: 7, reservation_pri: 7 MAY REROUTE 15. SESSION_NAME:gsr4_t8 16. SENDER_TEMPLATE type 7 length 12: 17. Source 192.168.1.4, tunnel_id 1948 18. SENDER_TSPEC type 2 length 36: 19. version=0, length in words=7 20. service id=1, service length=6 21. parameter id=127, flags=0, parameter length=5 22. average rate=12500000 bytes/sec, burst depth=1000 bytes 23. peak rate = 12500000 bytes/sec 24. min unit=0 bytes, max unit=0 bytes 25. ADSPEC type 2 length 48: 26. version=0 length in words=10 27. General Parameters break bit=0 service length=8 28. IS Hops:1 29. Minimum Path Bandwidth (bytes/sec):19375000 30. Path Latency (microseconds):0 31. Path MTU:4470 32. Controlled Load Service break bit=0 service length=0 Table 4-30 analyzes, line by line, the output shown in Example 4-11.
Resv MessageA Resv message contains information similar to that shown in a Path message. Example 4-12 provides the Resv message definition. Example 4-12 Resv Message
<Resv Message> : <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE>
<FLOWSPEC>
<FILTER_SPEC>
<LABEL>
[ <RECORD_ROUTE> ]
Example 4-13 shows the message received on gsr4, as seen with debug ip rsvp resv detail. Example 4-13 Decoded Resv Message
1. RSVP: version:1 flags:0000 type:RESV cksum:0000 ttl:255 reserved:0
length:108
2. SESSION type 7 length 16:
3. Destination 192.168.1.8, TunnelId 8, Source 192.168.1.4
4. HOP type 1 length 12: C0A80305
5. : 00000000
6. TIME_VALUES type 1 length 8 : 00007530
7. STYLE type 1 length 8 :
8. RSVP_SE_OPTION
9. FLOWSPEC type 2 length 36:
10. version = 0 length in words = 7
11. service id = 5, service length = 6
12. tspec parameter id = 127, tspec flags = 0, tspec length = 5
13. average rate = 12500000 bytes/sec, burst depth = 1000 bytes
14. peak rate = 2147483647 bytes/sec
15. min unit = 0 bytes, max unit = 0 bytes
16. FILTER_SPEC type 7 length 12:
17. Source 192.168.1.4, tunnel_id 1955
18. LABEL type 1 length 8 : 00000017
As you can see, a Resv message looks much like a Path message. The major difference between the contents of a Resv message and the contents of a Path message is that Resv messages do not contain the following items found in a Path message:
The output in Example 4-13 also highlights some differences between Resv messages and Path messages, as documented in Table 4-31.
PathTear MessageThe PathTear message is composed of messages you've seen before, as shown in Example 4-14. Example 4-14 PathTear Definition
<PathTear Message> : <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<SENDER_TEMPLATE>
<SENDER_TSPEC>
[ <ADSPEC> ]
A PathTear message was captured on gsr5 when Tunnel8 on gsr4 was shut down. Example 4-15 shows the debug results. Example 4-15 PathTear Message
RSVP: version:1 flags:0000 type:PTEAR cksum:0000 ttl:254 reserved:0 length:132
SESSION type 7 length 16:
Destination 192.168.1.8, TunnelId 8, Source 192.168.1.4
HOP type 1 length 12: C0A80304
: 00000000
SENDER_TEMPLATE type 7 length 12:
Source 192.168.1.4, tunnel_id 1955
SENDER_TSPEC type 2 length 36:
version=0, length in words=7
service id=1, service length=6
parameter id=127, flags=0, parameter length=5
average rate=12500000 bytes/sec, burst depth=1000 bytes
peak rate =12500000 bytes/sec
min unit=0 bytes, max unit=0 bytes
ADSPEC type 2 length 48:
version=0 length in words=10
General Parameters break bit=0 service length=8
IS Hops:0
Minimum Path Bandwidth (bytes/sec):2147483647
Path Latency (microseconds):0
Path MTU:-1
Controlled Load Service break bit=0 service length=0
ResvTear MessageResvTear also contains objects that might be familiar by now; there's nothing new under the sun here. The message shown in Example 4-16 was captured on gsr4. The ResvTear in question was sent by gsr5 in response to gsr4's PathTear when gsr4's Tunnel8 was shut down. Example 4-16 ResvTear Definition
<ResvTear Message> : <Common Header> [<INTEGRITY>]
<SESSION>
<RSVP_HOP>
[ <SCOPE> ]
<STYLE>
<FLOWSPEC>
<FILTER_SPEC>
Example 4-17 shows the decode. Example 4-17 ResvTear Message
RSVP: version:1 flags:0000 type:RTEAR cksum:9E95 ttl:255 reserved:0 length:
100
SESSION type 7 length 16:
Destination 192.168.1.8, TunnelId 8, Source 192.168.1.4
HOP type 1 length 12: C0A80305
: 00000000
STYLE type 1 length 8 :
RSVP_SE_OPTION
FLOWSPEC type 2 length 36:
version = 0 length in words = 7
service id = 5, service length = 6
tspec parameter id = 127, tspec flags = 0, tspec length = 5
average rate = 12500000 bytes/sec, burst depth = 1000 bytes
peak rate = 2147483647 bytes/sec
min unit = 0 bytes, max unit = 0 bytes
FILTER_SPEC type 7 length 12:
Source 192.168.1.4, tunnel_id 1956
CONFIRM type 1 length 8 : C0A80305
About the only thing notable and new here is that this message contains a CONFIRM object. The CONFIRM object is a request for confirmation that the ResvTear actually took place. The node requesting the confirmation is 192.168.3.5, which is the interface address on gsr5 on the subnet between gsr4 and gsr5. A Cisco node responds to a ResvTear that contains a CONFIRM object by sending a ResvTearConfirm object. Interoperability with non-Cisco equipment isn't a problem; any device that doesn't understand what to do with a ResvTear with CONFIRM just ignores the CONFIRM message. For MPLS TE, not receiving a ResvTearConfirm won't hurt anything. PathErr MessageExample 4-18 shows the PathErr message definition. Example 4-18 PathErr Definition
<PathErr message> : <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC>
[ <POLICY_DATA> ...]
<SENDER_TEMPLATE>
<SENDER_TSPEC>
[ <ADSPEC> ]
This error message was captured on gsr4. A PathErr with a bogus hop in the ERO was sent to gsr5, which forwarded it to gsr6. This error message is gsr6 complaining about that bad hop. Example 4-19 decodes this error message. Example 4-19 PathErr Decode1. RSVP: version:1 flags:0000 type:PERR cksum:0000 ttl:255 reserved:0 length:132 2. SESSION type 7 length 16: 3. Destination 192.168.1.8, TunnelId 8, Source 192.168.1.4 4. ERROR_SPEC type 1 length 12: 5. Node 192.168.10.6 6. Code 24 7. Value 2 8. Flags 0x00 9. SENDER_TEMPLATE type 7 length 12: 10. Source 192.168.1.4, tunnel_id 8909 11. SENDER_TSPEC type 2 length 36: 12. version=0, length in words=7 13. Minimum Path Bandwidth (bytes/sec):2147483647 14. Path Latency (microseconds):0 15. Path MTU:-1 16. Controlled Load Service break bit=0 service length=0 ERROR_SPEC (lines 4 through 8) is a new object here. The Node field is the address of the node that detected the error—192.168.10.6 is gsr6's IP address on the subnet between gsr5 and gsr6. The Code of 24 indicates that this error is of type "Routing Problem," and the Value of 2 means that the specific routing problem is "Bad strict node." ResvErr MessageExample 4-20 provides the ResvErr message definition. Example 4-20 ResvErr Definition
<ResvErr Message> : <Common Header> [ <INTEGRITY> ]
<SESSION>
<RSVP_HOP>
<ERROR_SPEC>
[ <SCOPE> ]
[ <POLICY_DATA> ]
<STYLE>
<FLOWSPEC>
<FILTER_LIST>
Because of how RSVP signalling works, it's difficult to cause a ResvErr on purpose. Most errors that could be caught by a ResvErr would be caught first by a PathErr, so they'd never make it this far. A ResvErr looks a lot like a PathErr, though, so the decodes look similar. ResvConf MessageResvConf messages are sent in response to a Resv message containing a CONFIRM object. Currently, the Cisco IOS Software does not put the CONFIRM object in a ResvConf—at least, not for MPLS TE. Example 4-21 shows the message definition for a ResvConf. Example 4-21 ResvConf Definition
<ResvConf message> : <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC>
<RESV_CONFIRM>
<STYLE>
<FLOWSPEC>
<FILTER_LIST>
ResvTearConf MessageThe ResvTearConf message is used by Cisco to confirm that a ResvTear took place. It's proprietary, but is easily identifiable in debugs. ResvTearConf is sent in response to a Resv message that contains a CONFIRM object. Example 4-22 shows the message definition for the ResvTearConf message. Example 4-22 ResvTearConf Definition
<ResvTearConf Message> : <Common Header>
<SESSION>
<ERROR_SPEC>
<CONFIRM>
<STYLE>
<FLOWSPEC>
<FILTER_SPEC>
Example 4-23 shows the decode of a ResvTearConf message. Example 4-23 ResvTearConf DecodeRSVP: version:1 flags:0000 type:RTEAR-CONFIRM cksum:0000 ttl:255 reserved:0 length :100 SESSION type 7 length 16: Destination 192.168.1.8, TunnelId 8, Source 192.168.1.4 ERROR_SPEC type 1 length 12: Node 192.168.9.6 Code 0 Value 0 Flags 0x00 CONFIRM type 1 length 8 : C0A80908 STYLE type 1 length 8 : RSVP_SE_OPTION FLOWSPEC type 2 length 36: version = 0 length in words = 7 service id = 5, service length = 6 tspec parameter id = 127, tspec flags = 0, tspec length = 5 average rate = 12500000 bytes/sec, burst depth = 1000 bytes peak rate = 2147483647 bytes/sec min unit = 0 bytes, max unit = 0 bytes FILTER_SPEC type 7 length 12: Source 192.168.1.4, tunnel_id 3992 Two things stand out in this decode. One is that the ResvTearConf contains an ERROR_SPEC message. An ERROR_SPEC with a Code of 0x0 is in fact a confirmation; this is what's sent in response to receiving a message with a CONFIRM request in it. The Node address is the node that is sending the ResvTearConf; the CONFIRM object contains the address of the node that the ResvTearConf message is being sent to. The Node address is 192.168.9.6, and the CONFIRM object turns out to be 192.168.9.8. This decode was captured on gsr8. It shows the incoming ResvTearConf that came from gsr6. A ResvTearConf acts much like a ResvErr, in that it is sent hop-by-hop from the headend to the tail. Hello MessageThe Hello message format is pretty straightforward. The Hello message itself is shown in Example 4-24. Example 4-24 Hello Definition
<Hello Message> : <Common Header> [ <INTEGRITY> ]
<HELLO>
RSVP OperationBy now, you should have a pretty good grip on the RSVP components—at least as far as MPLS TE is concerned. A lot of RSVP stuff that doesn't apply to MPLS TE (more about the QoS specifications, flow merging, and so on) has been skipped over, but unless you run a non-TE RSVP network now, you'll never miss it. You might be wondering how some of the protocol mechanisms fit together. This section is designed to answer these questions:
What Is Make-Before-Break?Make-before-break is an RSVP-TE mechanism that allows you to change some characteristics of a TE tunnel (namely, bandwidth and the path a tunnel takes) with virtually no data loss and without double-booking bandwidth. Consider Figure 4-32. Figure 4-32. Sample Network for Make-Before-Break
The bandwidths indicated are before any bandwidth is reserved from the network. If R1 signals a 35 Mb request to the network, it goes over the top path, R1 What if, at some point in the future, R1 wants to increase its reservation size to 80 Mb? This bandwidth has to come from the bottom path, because there's no way to get an 80 Mb reservation across the R1 Sounds simple, right? It is. But there's a tricky piece to it. Look at Figure 4-33. Figure 4-33. The Need for Make-Before-Break
This looks like Figure 4-32, except that the link from R4 to R5 now goes from R4 to R2. R1 still makes its 35 Mb reservation across R1 Then what happens? R1 tries to make an 80 Mb reservation across R1 What to do now? R1 could tear down the R1 Shared Explicit Reservation StyleFortunately, there is a better way to do this. You might recall that RSVP has a facility called Shared Explicit (SE). SE is a reservation style that allows an existing LSP to share bandwidth with itself so that double booking doesn't happen. This avoids problems such as those shown in Figure 4-33, where, even if you allowed double booking, the second reservation would still never get established. So how does SE work? SE reservations have two components:
SE reservation style is requested by the tunnel headend using a flag in the SESSION_ATTRIBUTE object. The alternative to SE is something called Fixed Filter (FF), but it's never used by Cisco's MPLS TE implementation, so it's not discussed here. Suffice it to say, FF doesn't allow you to share bandwidth the way SE does, so an FF reservation would still leave you with the problem presented in Figure 4-33. But how do you identify two reservations as the same one so that they can share bandwidth? As it turns out, this is relatively easy. All RSVP reservations are uniquely identified with a five-tuple of {Sender Address, LSP ID, Endpoint Address, Tunnel ID, Extended Tunnel ID}. The first two items in this five-tuple are found in the SENDER_TEMPLATE (and FILTER_SPEC) objects; the last three are found in the SESSION object. If two Path message are seen in which all five of these are the same, they are considered two representatives of the same reservation. The Sender Address is the RID of the tunnel headend. The Endpoint Address is the RID of the tunnel tail. The Extended Tunnel ID is either all 0s or an IP address on the router; this is used in some protection schemes, but it doesn't matter for this discussion. And the Tunnel ID is the tunnel interface number at the headend. Those four are pretty simple. But that leaves the LSP ID. Think of the LSP ID as an "instantiation counter": Every time the tunnel changes either its bandwidth requirement or the path it takes, the LSP ID increments by 1. The rule of the SE reservation process for MPLS TE is that if two reservations are seen with the same five-tuple, except that they have different LSP IDs, the two reservations are for different LSPs, but they share bandwidth. Assume that in Figure 4-33, R1's RID is 1.1.1.1 and R5's is 5.5.5.5. Table 4-32 shows what R1 sends out and what R4 does with the information it receives.
In this way, both Res1 and Res2 are allowed to coexist until Res1 is removed from the network. The implication is that after Res2 starts to share the reservation with Res1, Res1 will shortly no longer be active and will never try to compete with Res2 for bandwidth. In other words, after Res2 has shared the bandwidth with Res1, the implicit assumption is that Res1 will no longer try to use the bandwidth at the same time as Res2. Wait a minute. Why does Res2 ask for 80 Mbps? Can't it just ask for 45 Mbps, leave the Res1 reservation in place, and get along just fine? Well, sure. Except for the major holes in that plan, it works fine. Here are the two big holes in that idea:
But other than that, no, there are no problems whatsoever with this approach. None. So that's make-before-break. SE reservation style is, as you can see, an integral part of the make-before-break strategy. How Do the Refresh Mechanisms Work?This can be confusing to most people. As you already know, RSVP is a soft-state protocol. As such, reservations are periodically refreshed. Reservations are sent using Path and Resv messages. There is no difference between the Path and Resv messages used to set up the LSP initially and the ones used to refresh it; the packet formats are the same. The way a router tells a new setup from a refresh is to see if it has an existing reservation with a five-tuple that matches the Path or Resv message in question. Two major points to understand when talking about refresh mechanisms are
Refresh Timers Are JitteredAs you know, Path and Resv messages are sent every 30 seconds. They're not really sent every 30 seconds, however; they're sent on a 30-second timer with 50 percent jitter. So a given reservation has a Path message sent to refresh it every 15 to 45 seconds. It's the same deal with the Resv message for that reservation—every 15 to 45 seconds. And so it is for every refresh message. The actual refresh formula is in RFC 2205, Section 3.7. The general idea is that a neighbor sends its refresh interval (R) to its neighbor in the TIME_VALUES object in its Path and Resv messages. Each router also knows how many messages it is willing to miss before declaring the reservation dead (call this K). The neighbor computes a holdtime L for this message with the formula
In the current IOS implementation, R is 30 seconds and K is 3. So L is at least 157.5 seconds. This means that a router can go just under 157.5 seconds with no refresh before tearing down a neighbor. This is enough time that a router can have three consecutive intervals of worst-case jitter (with all packets lost) on the refresh timer (45 seconds) before timing out. What this means is that, occasionally, you see something like Figure 4-34, in which the Path message refresh timer happened to fire at 00:00 and 00:45, and the Resv message refresh timer happened to fire at 00:15 and 00:30. Figure 4-34. Path and Resv Messages Are Sent Independently
This is perfectly normal. It's important to understand that Path and Resv messages are not sent in ping/ACK fashion, but are sent independently from one another. This brings us to the next point. Path and Resv Messages Are Sent IndependentlyTake a look at Figure 4-35. Figure 4-35. Sample Network for Path and Resv Messages
Assume that a single tunnel is set up from gsr4 to gsr8. In addition to Path and Resv messages being on separate timers, when used for refreshes, they're not propagated hop-by-hop from the head to the tail, but instead are sent independently by each node. One possible refresh scenario might look like Figure 4-36. Figure 4-36. Possible Timing of Path and Resv Messages
Figure 4-36 is a bit of an oversimplification; you won't see gsr4 send a Path message every 15 seconds five times in a row. Specifically, Rule 5 of section 3.7 of RFC 2205 limits the amount of time between any two consecutive refreshes. This figure, however, conveys the general idea. Path and Resv messages, when used for refresh, are independent of each other and are not propagated from head to tail. When, Where, and to Whom Are Messages Sent?As mentioned before, there are nine RSVP message types. Table 4-33 summarizes what messages are sent when and where. This table has five columns:
NOTE RFC 2113 introduced a new IP option called the Router Alert option. If this option is present in an IP header, it is a signal to every router it crosses that the router needs to take a close look at the packet. Router Alert is currently used in both IGMP and RSVP. It allows a router to examine certain packets that are in transit and gives a router the option of modifying that packet before passing it on. To help understand the terminology (upstream/downstream, tail versus next-hop destination address, and the existence of Router Alert), see Figure 4-37. Figure 4-37. RSVP Terminology
In Figure 4-37, gsr4 wants to signal an LSP from gsr4 to gsr8 along the path gsr4 After gsr4 computes the path it wants the tunnel to take, gsr4 sends a Path message out on the wire between gsr4 and gsr6. The Path message's contents are discussed in the next section. The destination IP address on the packet is gsr8's TE RID. This Path message has the Router Alert option. Because the Router Alert option is set in the packet, gsr6 examines it. gsr6 makes some modifications to the packet (see the EXPLICIT_ROUTE object explanation in Table 4-27) and sends it out its top link to gsr8. gsr8 also examines the packet, modifies it, and sends it to gsr8. At every hop in the path, the destination IP address on the Path message remains the same—gsr8. The Router Alert (RA) is always present in the Path message. When gsr8 sends the Resv message upstream, the destination address is gsr6 (specifically, gsr6's address on the link between gsr6 and gsr8). Also, the Router Alert option is never present in the packet. You might notice a pattern here:
Why are things done this way? Largely for reasons that don't exist in an MPLS network. Controlling which messages carry the Router Alert option and which messages have the next hop as their destination address allows routers to detect the presence of non-RSVP routers in the path. But you can't build a TE tunnel through a router that doesn't speak RSVP, because MPLS Traffic Engineering needs not only a bandwidth reservation, but also a label allocation. If you are interested, check out Section 2.9 of RFC 2205 for details on how this works. Strict Versus Loose ERO SubobjectThe discussion of the EXPLICIT_ROUTE object showed that an L (Loose) bit can be set on a hop in the ERO to indicate a Loose route. But what is a Loose route? The ERO is encoded as a series of subobjects called abstract nodes. An abstract node can be either an IPv4 address, an IPv6 address, or an autonomous system. Cisco IOS Software currently supports only IPv4 addresses in the ERO. Each subobject can be either a strict hop or a loose hop. Most of what Cisco IOS Software uses are strict hops, save some interarea traffic engineering uses and other specific cases. When a router processes a strict hop, the IPv4 address in the subobject must be directly connected to the router doing the processing, or there is an error in the ERO. Sometimes, though, the subobject is a loose hop. If a router processes an ERO subobject with a loose hop, it is the responsibility of that router to generate a set of strict hops to get this Path message to the destination and replace the single loose hop with the newly generated set of strict hops. Implicit Versus Explicit NullAs you know, a tunnel tail can signal two kinds of labels—implicit null and explicit null. Explicit null is signalled by using the value 0 in the Label field of the LABEL object. Implicit null is signalled by using the value 3 in the Label field of the LABEL object. By default, the tunnel tail node signals explicit null in its Resv message: LABEL type 1 length 8 : 00000000 However, if you look at the penultimate hop, as demonstrated in Example 4-25, you see that the explicit-null value is interpreted as implicit null, on both the tail (gsr8) and the penultimate hop (gsr6). Example 4-25 Explicit Null Interpreted as Implicit Nullgsr8#show mpls traffic-eng tunnels role tail LSP Tunnel gsr4_t8 is signalled, connection is up InLabel : POS0/1, implicit-null OutLabel : - gsr6#show mpls traffic-eng tunnels role middle LSP Tunnel gsr4_t8 is signalled, connection is up InLabel : POS3/2, 16 OutLabel : POS3/0, implicit-null How did we get into this state? It's a long story, and mostly historical. You can use a few knobs to control this behavior. On the tunnel tail, you can use the knob mpls traffic-eng signalling advertise implicit-null to make the tail advertise implicit null: LABEL type 1 length 8 : 00000003 But no matter what you do on the tail, the penultimate hop still interprets the advertised label as implicit null, as confirmed by the output shown in Example 4-26. Example 4-26 Confirming Implicit-Null Interpretation on the Penultimate Hop
gsr6#show mpls traffic-eng tunnels role middle
LSP Tunnel gsr4_t8 is signalled, connection is up
InLabel : POS3/2, 16
OutLabel : POS3/0, implicit-null
If you care about sending explicit null from the penultimate hop to the tail, you need to enable the hidden command mpls traffic-eng signalling interpret explicit-null verbatim on the penultimate hop. After that, things look the way you'd expect them to, as shown in Example 4-27. Example 4-27 Interpreting Explicit Null Properly on the Penultimate Hopgsr6#show run | include verbatim mpls traffic-eng signalling interpret explicit-null verbatim gsr6#show mpls traffic-eng tunnels role middle LSP Tunnel gsr4_t8 is signalled, connection is up InLabel : POS3/2, 12304 OutLabel : POS3/0, explicit-null When you think about it, how often do you care if it's implicit null or explicit null? It makes little or no difference almost all the time. But the knob's there if you need to use it. One place you might have a need for explicit rather than implicit null is with QoS. See Chapter 6, "Quality of Service with MPLS TE"—specifically, the section "Label Stack Treatment"—for more details. RSVP Message PacingWhen there is a disruption in the network (a link flap, a router reboot, and so on), this can result in a significant amount of signalling. If a link flaps, for example, a PathErr or ResvErr needs to be sent for every tunnel crossing that link. If there are 2000 TE tunnels across a link, that means 2000 PathErrs/ResvErrs. It is possible to send more messages out an interface than the next hop can handle. When RSVP messages are sent out, they are sent either hop-by-hop or with the router alert bit set. This means that every router along the path for these RSVP messages needs to pay attention to them. Operationally, this means that every RSVP message that comes in on an interface goes through that interface's input queue. The input queue has a default size of 75 packets, as you can see in Example 4-28. Example 4-28 Displaying the Input Queue Sizegsr5#show interfaces p5/0 POS5/0 is up, line protocol is up Hardware is Packet over SONET Internet address is 192.168.12.5/24 MTU 4470 bytes, BW 622000 Kbit, DLY 100 usec, rely 255/255, load 1/255 Encapsulation HDLC, crc 16, loopback not set Keepalive set (10 sec) Scramble disabled Last input 00:00:00, output 00:00:02, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 7000 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 11687 packets input, 10119458 bytes, 0 no buffer Received 0 broadcasts, 16 runts, 0 giants, 0 throttles 0 parity 622 input errors, 606 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 11674 packets output, 10141348 bytes, 0 underruns 0 output errors, 0 applique, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 1 carrier transitions After messages go into the input queue, they are processed by the application they're destined for; in this case, RSVP is the focus of attention. All other applications that terminate on a router take their packets from the input queue—BGP, SNMP, Telnet, and so forth. If there's enough signalling traffic in the network, it is possible for an interface to receive more packets for its input queue than it can hold. If a packet is received that is destined for the input queue, and the input queue for that interface is full, the packet is dropped. This has unfortunate side effects on RSVP. If an RSVP message is lost, the node that sent it will not send it again until it's time to refresh that message—30 seconds, plus or minus 50% jitter. One way to solve this problem is to make the input queue very large. You can adjust the input queue size with the command hold-queue size input. Making the input queue significantly bigger is a perfectly valid solution, especially on higher-end platforms that don't use the input queue to switch packets. However, no matter how much bigger you make the input queue, you run the risk of having a burst of signalling traffic that fills up the input queue, resulting in dropped packets and slower signalling convergence. The best solution to this problem is RSVP message pacing. Message pacing controls the rate at which RSVP messages are sent so that the input queue on the other end of the link is not overloaded. Message pacing is enabled with the global command ip rsvp msg-pacing, as demonstrated in Example 4-29. Example 4-29 Configuring RSVP Message Pacing
gsr5(config)#ip rsvp msg-pacing ?
burst Configure a max burst of rsvp msgs queued to an output interface
maxsize Configure max number of rsvp msgs queued to an output interface
period Configure a period in msecs
<cr>
Table 4-34 lists the three options available for the ip rsvp msg-pacing command.
With the defaults for burst, maxsize, and period, this means that up to 200 messages per second can be sent out a given interface, and up to 500 messages (so 2.5 seconds of messages) can be queued. Message pacing is disabled by default, but it's a good idea to enable it. If pacing doesn't kick in, nothing will be hurt, and it can only help if you end up generating a large burst of messages. RSVP in the Real WorldSo far, this section has covered a lot of RSVP theory, but not much in the way of hands-on stuff. Although there's not much to configuring RSVP, there are a fair number of useful show commands you should know about. All show commands in this section were captured on a router using the topology shown in Figure 4-38, which you should be familiar with by now. Figure 4-38. Sample Topology for RSVP in the Real World
The tunnel topology has changed a bit. There are 50 TE tunnels from gsr4 to gsr8, each reserving 2 Mbps of bandwidth, and 50 TE tunnels from gsr8 to gsr4, each reserving 1 Mbps of bandwidth. This section doesn't cover all the possible RSVP show commands (see the documentation for the relevant Cisco IOS Software release you're using, or just use ? and check for yourself), but it covers the four most useful ones:
show ip rsvp counters Commandshow ip rsvp counters shows you counts, either per-interface or across the entire box, of the RSVP message types that have happened since the router has been up. Example 4-30 demonstrates all the possible options with this command. Example 4-30 show ip rsvp counters Options
gsr5#show ip rsvp counters ?
interface RSVP statistics for interface
summary RSVP statistics summary
| Output modifiers
<cr>
Example 4-31 shows the basic output from this command (with most interfaces removed for readability). Example 4-31 show ip rsvp counters Example
gsr5#show ip rsvp counters
...
POS4/1 Recv Xmit Recv Xmit
Path 1956 1143 Resv 1137 1270
PathError 0 0 ResvError 0 0
PathTear 0 38 ResvTear 38 0
ResvConfirm 0 0 ResvTearConfirm 0 38
UnknownMsg 0 0 Errors 0 0
POS4/2 Recv Xmit Recv Xmit
Path 1164 1277 Resv 1294 1148
PathError 0 0 ResvError 0 0
PathTear 38 0 ResvTear 0 38
ResvConfirm 0 0 ResvTearConfirm 38 0
UnknownMsg 0 0 Errors 0 0
...
Non RSVP i/f's Recv Xmit Recv Xmit
Path 0 0 Resv 0 0
PathError 0 0 ResvError 0 0
PathTear 0 0 ResvTear 0 0
ResvConfirm 0 0 ResvTearConfirm 0 0
UnknownMsg 0 0 Errors 0 0
All Interfaces Recv Xmit Recv Xmit
Path 3120 2420 Resv 2431 2418
PathError 0 0 ResvError 0 0
PathTear 38 38 ResvTear 38 38
ResvConfirm 0 0 ResvTearConfirm 38 38
UnknownMsg 0 0 Errors 0 0
Using the interface or summary option gives you counters for the specified interface or gives you only the All Interfaces output, shown at the bottom of Example 4-31. show ip rsvp interface Commandshow ip rsvp interface lists which interfaces have RSVP configured on them, how much bandwidth is currently allocated (reserved), and the interface and flow maximum. Example 4-32 shows typical output from this command. Example 4-32 show ip rsvp interface Examplegsr5#show ip rsvp interface interface allocated i/f max flow max sub max PO0/0 0G 1866M 1866M 0G PO1/0 0G 0G 0G 0G PO3/0 0G 3169033K 3169033K 0G PO4/0 0G 116250K 116250K 0G PO4/1 50M 116250K 116250K 0G PO4/2 100M 116250K 116250K 0G PO5/0 0G 466500K 466500K 0G You might recall from Chapter 3 that the command ip rsvp bandwidth x y configures an interface's reservable bandwidth. x is the i/f max, and y is the flow max, which MPLS TE doesn't use. In this output, POS4/2 is the interface on gsr5 that faces gsr6. RSVP reservations are always made from the bandwidth pool on the outgoing interface. Note that 50 Mbps is reserved on POS4/1 (the interface facing gsr4) and 100 Mbps is reserved on POS4/2 (the interface facing gsr6). The 50 Mbps corresponds to the 50 1-Mbps tunnels from gsr8 to gsr4, and the 100 Mb corresponds to the 50 2-Mbps tunnels from gsr4 to gsr8. show ip rsvp neighbor CommandAs shown in Example 4-33, output from the show ip rsvp neighbor command is pretty easy to understand. Example 4-33 show ip rsvp neighbor Example
gsr5#show ip rsvp neighbor
Interface Neighbor Encapsulation
PO4/1 192.168.3.4 RSVP
PO4/2 192.168.10.6 RSVP
One thing to remember is that RSVP does not have an explicit neighbor discovery phase. This means that if you enable RSVP on two interfaces, they will not see each other as RSVP neighbors until they start seeing Path and Resv messages from one another. Just having the interface RSVP enabled isn't enough. The Encapsulation column can be either RSVP or UDP, but for MPLS TE it is always RSVP. You can specify an interface as an optional parameter to this command, but this doesn't result in anything more exciting than the output of show ip rsvp neighbor for only one interface. show ip rsvp reservation CommandThis command is interesting. It has two distinct versions of output, show ip rsvp reservation and show ip rsvp reservation detail. Example 4-34 shows typical output from this command without the detail option. Example 4-34 show ip rsvp reservation Output
gsr5#show ip rsvp reservation
To From Pro DPort Sport Next Hop I/F Fi Serv BPS Bytes
192.168.1.4 192.168.1.8 0 1 1 192.168.3.4 PO4/1 SE LOAD 1M 1K
192.168.1.4 192.168.1.8 0 2 1 192.168.3.4 PO4/1 SE LOAD 1M 1K
192.168.1.4 192.168.1.8 0 3 1 192.168.3.4 PO4/1 SE LOAD 1M 1K
192.168.1.4 192.168.1.8 0 4 1 192.168.3.4 PO4/1 SE LOAD 1M 1K
192.168.1.4 192.168.1.8 0 5 1 192.168.3.4 PO4/1 SE LOAD 1M 1K
192.168.1.4 192.168.1.8 0 6 1 192.168.3.4 PO4/1 SE LOAD 1M 1K
192.168.1.4 192.168.1.8 0 7 1 192.168.3.4 PO4/1 SE LOAD 1M 1K
192.168.1.4 192.168.1.8 0 8 1 192.168.3.4 PO4/1 SE LOAD 1M 1K
192.168.1.4 192.168.1.8 0 9 1 192.168.3.4 PO4/1 SE LOAD 1M 1K
192.168.1.4 192.168.1.8 0 10 1 192.168.3.4 PO4/1 SE LOAD 1M 1K
...
192.168.1.8 192.168.1.4 0 41 15 192.168.10.6 PO4/2 SE LOAD 2M 1K
192.168.1.8 192.168.1.4 0 42 15 192.168.10.6 PO4/2 SE LOAD 2M 1K
192.168.1.8 192.168.1.4 0 43 16 192.168.10.6 PO4/2 SE LOAD 2M 1K
192.168.1.8 192.168.1.4 0 44 15 192.168.10.6 PO4/2 SE LOAD 2M 1K
192.168.1.8 192.168.1.4 0 45 15 192.168.10.6 PO4/2 SE LOAD 2M 1K
192.168.1.8 192.168.1.4 0 46 15 192.168.10.6 PO4/2 SE LOAD 2M 1K
192.168.1.8 192.168.1.4 0 47 15 192.168.10.6 PO4/2 SE LOAD 2M 1K
192.168.1.8 192.168.1.4 0 48 15 192.168.10.6 PO4/2 SE LOAD 2M 1K
192.168.1.8 192.168.1.4 0 49 15 192.168.10.6 PO4/2 SE LOAD 2M 1K
192.168.1.8 192.168.1.4 0 50 15 192.168.10.6 PO4/2 SE LOAD 2M 1K
If the full output from show ip rsvp reservation were printed here, it would have 100 lines—50 reservations from gsr4 to gsr8 and 50 from gsr8 to gsr4. Example 4-32 shows the first ten tunnels from gsr8 to gsr4 (to 192.168.1.4 and from 192.168.1.8) and the last ten tunnels from gsr4 to gsr8 (to 192.168.1.8 and from 192.168.1.4). Table 4-35 documents the fields shown in Example 4-34.
show ip rsvp reservation also has a detail option. It provides information similar to the output shown in Example 4-35. Example 4-35 show ip rsvp reservation detail Outputgsr5#show ip rsvp reservation detail RSVP Reservation. Destination is 192.168.1.4, Source is 192.168.1.8, Protocol is 0 , Destination port is 1, Source port is 1 Next Hop is 192.168.3.4, Interface is POS4/1 Reservation Style is Shared-Explicit, QoS Service is Controlled-Load Average Bitrate is 1M bits/sec, Maximum Burst is 1K bytes Label is 0 Not only is this information easier to read, but it also contains the label that was received in the Resv for this tunnel. In this case, the label is 0 because this tunnel is destined for 192.168.1.4, and gsr5 is the penultimate hop. Look at a TE tunnel going from gsr4 to gsr8 in Example 4-36. Example 4-36 show ip rsvp reservation detail Outputgsr5#show ip rsvp reservation detail 192.168.1.8 RSVP Reservation. Destination is 192.168.1.8, Source is 192.168.1.4, Protocol is 0 , Destination port is 1, Source port is 16 Next Hop is 192.168.10.6, Interface is POS4/2 Reservation Style is Shared-Explicit, QoS Service is Controlled-Load Average Bitrate is 2M bits/sec, Maximum Burst is 1K bytes Label is 12311 In this case, you see that the learned label for this tunnel is 12311. This matches the output of show mpls traffic-eng tunnels in Example 4-37, as it should. Example 4-37 show mpls traffic-eng tunnels Outputgsr5#show mpls traffic-eng tunnels name gsr4_t1 LSP Tunnel gsr4_t1 is signalled, connection is up InLabel : POS4/1, 12342 OutLabel : POS4/2, 12311 RSVP signalling Info: Src 192.168.1.4, Dst 192.168.1.8, Tun_Id 1, Tun_Instance 16 RSVP Path Info: My Address: 192.168.3.5 Explicit Route: 192.168.10.6 192.168.9.8 192.168.1.8 Record Route: NONE Tspec: ave rate=2000 kbits, burst=1000 bytes, peak rate=2000 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=2000 kbits, burst=1000 bytes, peak rate=Inf show ip rsvp reservation gives you the option of an IP address or host name. Using that option shows you all tunnels destined for the specified router ID. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
< Free Open Study > |
|
R2
