Tracing RSVP Operations

Problem

You want to keep a running log of RSVP events that occur on the router in case any problems arise and you need to debug problems with RSVP or your LSPs.

Solution

When performing ongoing monitoring of RSVP operations, set up tracing options to track RSVP events that occur on the router:

[edit protocols rsvp] aviva@R1# set traceoptions file rsvp-trace-log world-readable aviva@R1# set traceoptions flag packets detail

Discussion

Its a good practice to trace high-level RSVP operations on an ongoing basis so that if a problem occurs, you can examine the logs as part of your troubleshooting process. Then you can enable more detailed traceoptions flags to help pinpoint the causes.

This recipe sets up tracing of RSVP packets that are sent and received by the router, saving them to the file rsvp-trace-log. The world-readable option allows anyone logged in to the router to read the file. This file is created on the routers hard disk in the directories /var/log (on M-series and T-series routers) and /cf/var/log (on J-series routers). The detail option provides additional information about the packets. Heres what the file contains when existing RSVP sessions are cleared and then restarted:

aviva@R1> clear log rsvp-trace-log aviva@R1> clear rsvp sessions aviva@R1> show log rsvp-trace-log Nov 4 16:47:41 R1 clear-log[22684]: logfile cleared Nov 4 16:47:47 RSVP send PathErr 10.1.13.1->10.1.13.2 Len=188 so-0/0/2.0 Nov 4 16:47:47 Integty Len 36 flag 0x0 key 0x0000010d010a seq 0x2c016c435db8 0b00 digest 0x53682741 0x68419a28 0x340b7b1d 0x8bdc0112 Nov 4 16:47:47 Session7 Len 16 10.0.0.1(port/tunnel ID 51620 Ext-ID 10.0.0.6) Proto 0 Nov 4 16:47:47 Error Len 12 Session preempted flag 0 by 10.1.13.1 Nov 4 16:47:47 Sender7 Len 12 10.0.0.6(port/lsp ID 1) Nov 4 16:47:47 Tspec Len 36 rate 0bps size 0bps peak Infbps m 20 M 1500 Nov 4 16:47:47 ADspec Len 48 MTU 1500 Nov 4 16:47:47 RecRoute Len 20 10.1.13.2 10.1.36.2 Nov 4 16:47:47 RSVP send ResvTear 10.1.13.1->10.1.13.2 Len=92 so-0/0/2.0 Nov 4 16:47:47 Integty Len 36 flag 0x0 key 0x0000010d010a seq 0x33016c434b6b 0200 digest 0x3c6b90bf 0x3d4bc125 0x5cb3da5d 0x42518ffc Nov 4 16:47:47 Session7 Len 16 10.0.0.1(port/tunnel ID 51620 Ext-ID 10.0.0.6) Proto 0 Nov 4 16:47:47 Hop Len 12 10.1.13.1/0x0869a660 Nov 4 16:47:47 Style Len 8 FF Nov 4 16:47:47 Filter7 Len 12 10.0.0.6(port/lsp ID 1) Nov 4 16:47:47 RSVP send PathTear 10.0.0.1->10.0.0.6 Len=120 so-0/0/2.0 Nov 4 16:47:47 Integty Len 36 flag 0x0 key 0x0000010d010a seq 0x33016c43456d 0200 digest 0x582dab2c 0x3801d98c 0x7dbf2854 0x8f8ea32e Nov 4 16:47:47 Session7 Len 16 10.0.0.6(port/tunnel ID 39357 Ext-ID 10.0.0.1) Proto 0 Nov 4 16:47:47 Hop Len 12 10.1.13.1/0x086dd770 Nov 4 16:47:47 Sender7 Len 12 10.0.0.1(port/lsp ID 2) Nov 4 16:47:47 Tspec Len 36 rate 0bps size 0bps peak Infbps m 20 M 1500 Nov 4 16:47:47 RSVP recv Path 10.0.0.6->10.0.0.1 Len=244 so-0/0/2.0 Nov 4 16:47:47 Integty Len 36 flag 0x0 key 0x0000020d010a seq 0xbbfe6b43793e 0800 digest 0x1a36b6f1 0xf3d0cd4d 0x0c3ffc31 0x6f587cf9 Nov 4 16:47:47 Session7 Len 16 10.0.0.1(port/tunnel ID 51620 Ext-ID 10.0.0.6) Proto 0 Nov 4 16:47:47 Hop Len 12 10.1.13.2/0x0869a660 Nov 4 16:47:47 Time Len 8 30000 ms Nov 4 16:47:47 SrcRoute Len 12 10.1.13.1 S Nov 4 16:47:47 LabelRequest Len 8 EtherType 0x800 Nov 4 16:47:47 Properties Len 12 Primary path Nov 4 16:47:47 SessionAttribute Len 16 Prio (7,0) flag 0x0 "R6-to-R1" Nov 4 16:47:47 Sender7 Len 12 10.0.0.6(port/lsp ID 1) Nov 4 16:47:47 Tspec Len 36 rate 0bps size 0bps peak Infbps m 20 M 1500 Nov 4 16:47:47 ADspec Len 48 MTU 1500 Nov 4 16:47:47 RecRoute Len 20 10.1.13.2 10.1.36.2 Nov 4 16:47:47 RSVP send Resv 10.1.13.1->10.1.13.2 Len=156 so-0/0/2.0 Nov 4 16:47:47 Integty Len 36 flag 0x0 key 0x0000010d010a seq 0x33016c43e07d 0200 digest 0x976571f8 0x06983f40 0x7a9bb90d 0xfdf51c42 Nov 4 16:47:47 Session7 Len 16 10.0.0.1(port/tunnel ID 51620 Ext-ID 10.0.0.6) Proto 0 Nov 4 16:47:47 Hop Len 12 10.1.13.1/0x0869a660 Nov 4 16:47:47 Time Len 8 30000 ms Nov 4 16:47:47 Style Len 8 FF Nov 4 16:47:47 Flow Len 36 rate 0bps size 0bps peak Infbps m 20 M 1500 Nov 4 16:47:47 Filter7 Len 12 10.0.0.6(port/lsp ID 1) Nov 4 16:47:47 Label Len 8 3 Nov 4 16:47:47 RecRoute Len 12 10.1.13.1 Nov 4 16:47:49 RSVP recv Hello New 10.1.13.2->10.1.13.1 Len=68 so-0/0/2.0 Nov 4 16:47:49 Integty Len 36 flag 0x0 key 0x0000020d010a seq 0xbbfe6b43793e 0800 digest 0x0a523b8a 0x89b1162e 0x18a9feab 0x901053f2 Nov 4 16:47:49 HelloReq Len 12 Nov 4 16:47:49 RestartCap Len 12 restart time 0, recovery time 0 Nov 4 16:47:49 RSVP send Hello New 10.1.13.1->10.1.13.2 Len=68 so-0/0/2.0 Nov 4 16:47:49 Integty Len 36 flag 0x0 key 0x0000010d010a seq 0x35016c43dd51 0c00 digest 0xfc4c9304 0xe69e24ee 0xd219ef33 0x6a5f31e5 Nov 4 16:47:49 HelloRply Len 12 Nov 4 16:47:49 RestartCap Len 12 restart time 0, recovery time 0

The first RSVP packet sent is a PathErr, which indicates that some type of error has occurred on the LSP. When RSVP clears the sessions, it sends two PathTear messages to tear down the session, one message to the interface link between 10.1.13.1 and 10.1.13.2, and the second message to the link between the loopback addresses of the ingress router (10.0.0.1) and the egress router (10.0.0.6). As RSVP re-establishes the LSP, it exchanges Path and Resv messages. Once the RSVP session is set up again, RSVP exchanges periodic Hello messages. The information logged for the RSVP Path packets is similar to the show rsvp session detail command output:

aviva@R1> show rsvp session detail Ingress RSVP: 1 sessions 10.0.0.6 From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1 LSPname: R1-to-R6, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 100128 Resv style: 1 FF, Label in: -, Label out: 100128 Time left: -, Since: Fri Nov 4 16:52:15 2005 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 4 receiver 39357 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.1.13.2 (so-0/0/2.0) 4 pkts RESV rcvfrom: 10.1.13.2 (so-0/0/2.0) 4 pkts Explct route: 10.1.13.2 10.1.36.2 Record route: 10.1.13.2 10.1.36.2 Total 1 displayed, Up 1, Down 0 Egress RSVP: 1 sessions 10.0.0.1 From: 10.0.0.6, LSPstate: Up, ActiveRoute: 0 LSPname: R6-to-R1, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: - Resv style: 1 FF, Label in: 3, Label out: - Time left: 146, Since: Fri Nov 4 16:51:45 2005 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 51620 protocol 0 PATH rcvfrom: 10.1.13.2 (so-0/0/2.0) 5 pkts Adspec: received MTU 1500 PATH sentto: localclient RESV rcvfrom: localclient Record route: 10.1.36.2 10.1.13.2 Total 1 displayed, Up 1, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0

The configuration in this recipe creates 10 logfiles (the default) and uses the default trace file size of 10 MB, which is generally a useful size for logging events over a long period of time. If the router is the ingress or egress point for a large number of LSPs, you might want to increase the file size so that you have time to review or archive the logfiles before the files start overwriting each other:

[edit protocols rsvp] aviva@RouterF# set traceoptions file size 100M

When debugging BGP, you can set one or more of the following trace flags to monitor BGP information:

[edit protocols rsvp] aviva@R1# set traceoptions flag ? Possible completions: all Trace everything error Trace error conditions event Trace RSVP related events lmp Trace RSVP-LMP related interactions packets Trace all RSVP packets path Trace RSVP path messages pathtear Trace RSVP PathTear messages resv Trace RSVP Resv messages resvtear Trace RSVP ResvTear messages route Trace routing information state Trace state transitions

If you are receiving signaling errors when setting up or running RSVP, use the flag error flag to log erroneous conditions.

See Also

Recipe 5.10

Категории