[Contents] [Prev] [Next] [Index] [Report an Error]


Examining the Path Message

Purpose

Each sender host transmits Path messages downstream along the routes provided by the unicast and multicast routing protocols. Path messages follow the exact paths of application data, creating path states in the routers along the way, and enabling routers to learn the previous-hop and next-hop node for the session. Path messages are sent periodically to refresh path states.

Figure 11 shows an RSVP Path message that flows downstream from ingress router R1 to egress router R5, and transits routers R3 and R6. The originating router (R1) sets the IP router-alert option so that intermediate routers look at the contents of the Path message.


Figure 11: RSVP Path Message

A Path message can contain the following objects: Adspec, Detour, Explicit route, FastReroute, Hop, Integrity, LabelRequest, Policy data, Properties, record route (RecRoute), Sender, Session, SessionAttribute, source route (SrcRoute), Time, and Tspec. For more information on RSVP message objects, see RSVP Objects.

To ensure that Path messages are displayed in the output, include the path flag at the [edit protocols rsvp traceoptions] hierarchy level.

Action

To examine the Path message, enter the following JUNOS command-line interface (CLI) command:

user@R1> monitor start filename

Sample Output 1

[edit protocols rsvp]
user@R1# show 
traceoptions {
    file rsvp-log;
    flag packets detail;
    flag path detail;
}
interface so-0/0/2.0;
interface fxp0.0 {
    disable;
}

Sample Output 2

user@R1> clear log rsvp-log 

user@R1> monitor start rsvp-log 

user@R1>
*** rsvp-log ***
Jun 16 18:36:48 RSVP send Path 10.0.0.1->10.0.0.5 Len=216 so-0/0/2.0
Jun 16 18:36:48   Session7 Len 16 10.0.0.5(port/tunnel ID 26619) Proto 0
Jun 16 18:36:48   Hop      Len 12 10.1.13.1/0x08678198 
Jun 16 18:36:48   Time     Len  8 30000 ms
Jun 16 18:36:48   SrcRoute Len 28  10.1.13.2 S 10.1.36.2 S 10.1.56.1 S
Jun 16 18:36:48   LabelRequest Len  8 EtherType 0x800
Jun 16 18:36:48   Properties Len 12 Primary path 
Jun 16 18:36:48   SessionAttribute Len 16 Prio (7,0) flag 0x0 "R1-to-R5"
Jun 16 18:36:48   Sender7  Len 12 10.0.0.1(port/lsp ID  4)
Jun 16 18:36:48   Tspec    Len 36 rate 0bps size 0bps peak Infbps m 20 M 1500
Jun 16 18:36:48   ADspec   Len 48 MTU 1500
Jun 16 18:36:48   RecRoute Len 12  10.1.13.1
monitor stop 

What It Means

Sample Output 1 shows the configuration of RSVP tracing on ingress router R1. The packets and path flags are included at the [edit protocols rsvp traceoptions] hierarchy level to provide slightly different information about RSVP traffic. For more information about RSVP tracing flags, see Table 17. The detail option is included to show granular details about the configured flags.

Sample Output 2 shows clear commands, the output for the rsvp-log file, and that monitoring was started and then stopped.

The first line of the rsvp-log output indicates that this is a Path message. The source address of the IP packet is 10.0.0.1 (R1). The IP destination address is 10.0.0.5 (R5). The outgoing interface on this router is so-0/0/2.0.

All subsequent lines of sample output indicate object values for this Path message and are indented in the output. To facilitate this discussion, each line of output for each object is displayed before the corresponding explanation.

The Session object (Session7) indicates that this is C-Type 7 for LSP tunnel IPv4, defined in RFC 3209. The RSVP session is defined by three values: the destination IP address (10.0.0.5), a 16-bit field that indicates the tunnel ID (26619) and is unique for the length of the RSVP session, and the protocol number (Proto 0).

The Hop object indicates the IP address of the interface (10.1.13.1) on the router (R1) sending the Path message. At the next node, the Hop object contains the previous hop IP address.

The Time object indicates how long before RSVP must refresh the session state (30000 ms). By default, the value is recorded in milliseconds. RFC 3209 states that a router can refresh the state within plus or minus 50 percent of the time. In this case, RFC 3209 allows a router to refresh the state between 15 and 45 seconds.

The source route (SrcRoute) object is the list of addresses in the Explicit Route Object (ERO). The S indicates a strict next hop, as shown in the example. An L indicates a loose next hop.

The LabelRequest object indicates, to the next downstream node, that a label assignment is requested. Ethertype 0x800 indicates that a label for an IP packet is required.

The Properties object is a Juniper Networks proprietary object used to carry information about the label-switched path (LSP). In this case, the object indicates that the Path message is signaling a primary physical path.

The SessionAttribute object indicates a variety of parameters:

Table 19 shows the SessionAttribute object flags.


Table 19: Session Attribute Object Flags
Flag
Description

Bit 0 (value 0x1)

Local protection requested—Permits transit routers to use a local repair mechanism which may result in violation of the ERO. When a fault is detected on an adjacent downstream link or node, a transit router can reroute traffic for fast service restoration.

Bit 1 (value 0x2)

Label recording requested—Indicates that label information is included with a route record.

Bit 2 (value 0x4)

Shared explicit (SE) style requested—Indicates that the ingress node may reroute this tunnel without tearing it down. A tunnel egress node should use the SE style when responding with an Resv message.

Bit 3 (value 0x08)

Bandwidth protection requested—Indicates to the point of local repair (PLR) along the protected LSP path that a backup path with a bandwidth guarantee is requested. If no fast reroute object is included in the Path message, the bandwidth guaranteed is that of the protected LSP. If a fast reroute object is in the Path message, then the bandwidth specified must be guaranteed.

Bit 4 (value 0x10)

Node protection requested—Indicates to the PLRs along a protected LSP path that a backup path is requested. The backup path must bypass at least the next node of the protected LSP.

Bit 5 (value 0x20)

ERO expansion—Indicates that a new ERO expansion is requested.

Bit 6 (value 0x40)

Soft preemption requested—Indicates that soft preemption is used if the LSP is preempted.

Bit 7 (value 0x80)

Undefined.


The Sender object defines the source of session 10.0.0.1 (R1). The number (7) after sender indicates that this is C-Type 7 for IPv4, defined in RFC 3209. The sender is defined by the source IP address (10.0.0.1) and the LSP ID (4). The LSP ID changes, depending on the signaling path.

The traffic specification (Tspec) object indicates the allocated bandwidth. This RSVP session uses the default of 0, no bandwidth is reserved. The Tspec object includes two different types of RSVP bandwidth allocations: controlled load and guaranteed delivery.

The ADspec object carries a summary of available services, delay and bandwidth estimates, and operating parameters (MTU 1500) used by specific quality-of-service (QoS) control services.

The record route object (RecRoute) indicates the list of addresses that this Path message has transited, in this case, 10.1.13.1.

For information on objects that can appear in the Path message but do not appear in the sample output, such as Detour, Explicit route, FastReroute, and Integrity, see Table 15.


[Contents] [Prev] [Next] [Index] [Report an Error]