-
Cisco IOS Debug Command Reference
-
Introduction
-
Using Debug Commands
-
Conditionally Triggered Debugging
-
debug aaa accounting through debug auto-config
-
debug backhaul-session-manager session through debug channel packets
-
debug clns esis events through debug dbconn tcp
-
debug decnet adj through debug events
-
debug fax dmsp through debug gvrp
-
debug h225 asn1 through debug ip ftp
-
debug ip http all through debug ip rsvp
-
debug ip rtp header-compression through debug ipv6 icmp
-
debug ipv6 inspect through debug local-ack state
-
debug management event through debug mpls ldp bindings
-
debug mpls ldp checkpoint through debug mwi relay events
-
debug ncia circuit through debug pxf tbridge
-
debug qllc error through debug snmp sync
-
debug sntp adjust through debug tag-switching xtagatm vc
-
debug tag-template event through debug voip application vxml
-
debug voip avlist through debug vpm signaling
-
debug vpm spi through voice call debug
-
X.25 Cause and Diagnostic Codes
-
ISDN Switch Types, Codes, and Values
-
Table Of Contents
debug ip inspect L2-transparent
debug ip ospf database-timer rate-limit
debug ip ospf mpls traffic-eng advertisements
debug ip rsvp high-availability
debug ip http all
To enable debugging output for all HTTP processes on the system, use the debug ip http all command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip http all
no debug ip http all
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
Use this command to enable debugging messages for all HTTP processes and activity. Issuing this command is equivalent to issuing the following commands:
•
debug ip http authentication
•
•
•
•
•
Examples
For sample output and field descriptions of this command, see the documentation of the commands listed in the "Usage Guidelines" section.
Related Commands
debug ip http authentication
To troubleshoot HTTP authentication problems, use the debug ip http authentication command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip http authentication
no debug ip http authentication
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
Use this command to display the authentication method the router attempted and authentication-specific status messages.
Examples
The following is sample output from the debug ip http authentication command:
Router# debug ip http authenticationAuthentication for url `/' `/' level 15 privless `/'Authentication username = `local15' priv-level = 15 auth-type = localTable 134 describes the significant fields shown in the display.
Related Commands
debug ip http client
To enable debugging output for the HTTP client, use the debug ip http client command in privileged EXEC mode. To disable debugging output for the HTTP client, use the no or undebug form of this command.
debug ip http client {all | api | cache | error | main | msg | socket}
no debug ip http client {all | api | cache | error | main | msg | socket}
undebug ip http client {all | api | cache | error | main | msg | socket}
Syntax Description
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
Use this command to display transactional information for the HTTP client for debugging purposes.
Examples
The following example shows sample debugging output for a failed copy transfer operation when the host name resolution fails:
Router# debug ip http client all2w4d: Cache ager calledRouter# copy http://www.example.com/index.html flash:index.htmlDestination filename [index.html]?Erase flash: before copying? [confirm] noTranslating "www.example.com"% Bad IP address for host www.example.com%Error opening http://www.example.com/index.html (I/O error)Router#2w4d: http_client_request:2w4d: httpc_setup_request:2w4d: http_client_process_request:2w4d: HTTPC: Host name resolution failed for www.example.com2w4d: http_transaction_free:2w4d: http_transaction_free: freed httpc_transaction_t
The following example shows sample debugging output for a failed copy transfer operation when the source file is not available:
Router# copy http://example.com/hi/file.html flash:/file.htmlDestination filename [file.html]?%Error opening http://example.com/hi/file.html (No such file or directory)Router#2w4d: http_client_request:2w4d: httpc_setup_request:2w4d: http_client_process_request:2w4d: httpc_request:Dont have the credentialsThu, 17 Jul 2003 07:05:25 GMT http://209.168.200.225/hi/file.html okProtocol = HTTP/1.1Content-Type = text/html; charset=iso-8859-1Date = Thu, 17 Jul 2003 14:24:29 GMT2w4d: http_transaction_free:2w4d: http_transaction_free:freed httpc_transaction_t2w4d: http_client_abort_request:2w4d: http_client_abort_request:Bad Transaction IdRouter#Table 135 describes the significant fields shown in the display.
Related Commands
debug ip http client cookie
To debug the HTTP client cookie, use the debug ip http client cookie command in privileged EXEC mode. To disable this debugging activity, use the no form of this command.
debug ip http client cookie
no debug ip http client cookie
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Examples
The following is sample output from the debug ip http client cookie command:
Device# debug ip http client cookieClientCookie: Receiving Set-Cookie cookie1=1 domain=172.16.0.2 path=/cwmp-1-0/testacs flags=264 expire=Mon,30-Jun-2008 05:51:27 GMT now=48686D74ClientCookie2: Receiving Set-Cookie2 cookie1= 1 domain=172.16.0.2 path=/cwmp-1-0/ flags=256 expire=60 port=0 now=48686E1A comment= commentURL=debug ip http ezsetup
To display the configuration changes that occur during the EZ Setup process, use the debug ip http ezsetup command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip http ezsetup
no debug ip http ezsetup
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use this command to verify the EZ Setup actions without changing the configuration of the router.
EZ Setup is a form you fill out to perform basic router configuration from most HTML browsers.
Examples
The following sample output from the debug ip http ezsetup command shows the configuration changes for the router when the EZ Setup form has been submitted:
Router# debug ip http ezsetupservice timestamps debugservice timestamps logservice password-encryption!hostname router-name!enable secret router-pwline vty 0 4password router-pw!interface ethernet 0ip address 172.69.52.9 255.255.255.0no shutdownip helper-address 172.31.2.132ip name-server 172.31.2.132isdn switch-type basic-5essusername Remote-name password Remote-chapinterface bri 0ip unnumbered ethernet 0encapsulation pppno shutdowndialer map ip 192.168.254.254 speed 56 name Remote-name Remote-numberisdn spid1 spid1isdn spid2 spid2ppp authentication chap callindialer-group 1!ip classlessaccess-list 101 deny udp any any eq snmpaccess-list 101 deny udp any any eq ntpaccess-list 101 permit ip any anydialer-list 1 list 101ip route 0.0.0.0 0.0.0.0 192.168.254.254ip route 192.168.254.254 255.255.255.255 bri 0logging bufferedsnmp-server community public ROip http serverip classlessip subnet-zero!endRelated Commands
debug ip http secure-all
To generate the following output, use the debug ip http secure-all command in privileged EXEC mode:
•
•
•
To disable this debugging, use the no form of this command.
debug ip http secure-all
no debug ip http secure-all
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command generates the following:
•
•
•
Examples
The following example generates the following output:
•
•
•
Router# debug ip http secure-allRelated Commands
debug ip http secure-session
To generate debugging information about each new secure HTTPS session when it is created, use the debug ip http secure-session command in privileged EXEC mode. To disable this debugging, use the no form of this command.
debug ip http secure-session
no debug ip http secure-session
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command generates debugging information about each new HTTPS session when it is created. When a new HTTPS session is created, debugging information is generated in the following format:
HTTPS SSL Session Established/Handshake done - Peer 10.0.0.1state = SSL negotiation finished successfullySessionInfo: Digest=RC4-MD5 SSLVer=SSLv3 KeyEx=RSA Auth=RSA Cipher=RC4(128) Mac=MD5The SessionInfo fields provide the following information about the session:
•
•
•
•
•
•
Examples
The following example generates debugging information about each new HTTPS session when it is created:
debug ip http secure-sessionRelated Commands
debug ip http secure-state
To generate debugging output each time the Secure HTTP (HTTPS) feature changes state, use the debug ip http secure-state command in privileged EXEC mode. To disable this debugging, use the no form of this command.
debug ip http secure-state
no debug ip http secure-state
Syntax Description
This command has no keywords or arguments.
Defaults
Disabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command generates debugging information each time the Secure HTTP (HTTPS) feature changes state. When the Secure HTTP (HTTPS) feature changes state, debugging information is generated in the following format:
HTTPS SSL State Change - Peer 10.0.0.1Old State = SSLv3 read finished A, New State = SSL negotiation finished successfullyExamples
The following example generates debugging information each time the Secure HTTP (HTTPS) feature changes state:
debug ip http secure-stateRelated Commands
debug ip http ssi
To display information about the HTML SSI EXEC command or HTML SSI ECHO command, use the debug ip http ssi command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip http ssi
no debug ip http ssi
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug ip http ssi command:
Router# debug ip http ssiHTML: filtered command `exec cmd="show users"'HTML: SSI command `exec'HTML: SSI tag `cmd' = "show users"HTML: Executing CLI `show users' in mode `exec' doneThe following line shows the contents of the SSI EXEC command:
HTML: filtered command `exec cmd="show users"'The following line indicates the type of SSI command that was requested:
HTML: SSI command `exec'The following line shows the show users argument assigned to the tag command:
HTML: SSI tag 'cmd' = "show users"The following line indicates that the show users command is being executed in EXEC mode:
HTML: Executing CLI `show users' in mode `exec' doneRelated Commands
debug ip http ssl error
To enable debugging messages for the secure HTTP (HTTPS) web server and client, use the debug ip http ssl error command in privileged EXEC mode. To disable debugging messages for the HTTPS web server and client, use the no form of this command.
debug ip http ssl error
no debug ip http ssl error
Syntax Description
This command has no arguments or keywords.
Command Default
Debugging message output is disabled.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command displays output for debugging purposes related to the HTTPS server and HTTPS client. HTTPS services use the Secure Socket Layer (SSL) protocol, version 3.0, for encryption.
Examples
The following is sample debugging output from the debug ip http ssl error command:
Router# 000030:00:08:01:%HTTPS:Key pair generation failedRouter# 000030:00:08:10:%HTTPS:Failed to generate self-signed certRouter# 000030:00:08:15:%HTTPS:SSL handshake failRouter# 000030:00:08:21:%HTTPS:SSL read fail, uninitialized hndshk ctxtRouter# 000030:00:08:25:%HTTPS:SSL write fail, uninitialized hndshk ctxtTable 136describes the debug messages shown above.
Related Commands
debug ip http token
To display individual tokens parsed by the HTTP server, use the debug ip http token command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip http token
no debug ip http token
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug ip http token command to display low-level HTTP server parsings. To display high-level HTTP server parsings, use the debug ip http transaction command.
Examples
The following is part of sample output from the debug ip http token command. In this example, the browser accessed the router's home page http://router-name/. The output gives the token parsed by the HTTP server and its length.
Router# debug ip http tokenHTTP: token len 3: 'GET'HTTP: token len 1: ' 'HTTP: token len 1: '/'HTTP: token len 1: ' 'HTTP: token len 4: 'HTTP'HTTP: token len 1: '/'HTTP: token len 1: '1'HTTP: token len 1: '.'HTTP: token len 1: '0'HTTP: token len 2: '\15\12'HTTP: token len 7: 'Referer'HTTP: token len 1: ':'HTTP: token len 1: ' 'HTTP: token len 4: 'http'HTTP: token len 1: ':'HTTP: token len 1: '/'HTTP: token len 1: '/'HTTP: token len 3: 'www'HTTP: token len 1: '.'HTTP: token len 3: 'thesite'HTTP: token len 1: '.'HTTP: token len 3: 'com'HTTP: token len 1: '/'HTTP: token len 2: '\15\12'HTTP: token len 10: 'Connection'HTTP: token len 1: ':'HTTP: token len 1: ' 'HTTP: token len 4: 'Keep'HTTP: token len 1: '-'HTTP: token len 5: 'Alive'HTTP: token len 2: '\15\12'HTTP: token len 4: 'User'HTTP: token len 1: '-'HTTP: token len 5: 'Agent'HTTP: token len 1: ':'HTTP: token len 1: ' 'HTTP: token len 7: 'Mozilla'HTTP: token len 1: '/'HTTP: token len 1: '2'HTTP: token len 1: '.'...Related Commands
debug ip http transaction
To display HTTP server transaction processing, use the debug ip http transaction command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip http transaction
no debug ip http transaction
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug ip http transaction command to display what the HTTP server is parsing at a high level. To display what the HTTP server is parsing at a low level, use the debug ip http token command.
Examples
The following is sample output from the debug ip http transaction command. In this example, the browser accessed the router's home page http://router-name/.
Router# debug ip http transactionHTTP: parsed uri '/'HTTP: client version 1.1HTTP: parsed extension RefererHTTP: parsed line http://www.company.com/HTTP: parsed extension ConnectionHTTP: parsed line Keep-AliveHTTP: parsed extension User-AgentHTTP: parsed line Mozilla/2.01 (X11; I; FreeBSD 2.1.0-RELEASE i386)HTTP: parsed extension HostHTTP: parsed line router-nameHTTP: parsed extension AcceptHTTP: parsed line image/gif, image/x-xbitmap, image/jpeg, image/HTTP: parsed extension AuthorizationHTTP: parsed authorization type BasicHTTP: received GET ''Table 137 describes the significant fields shown in the display.
Related Commands
debug ip http url
To show the URLs accessed from the router, use the debug ip http url command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip http url
no debug ip http url
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug ip http url command to keep track of the URLs that are accessed and to determine from which hosts the URLs are accessed.
Examples
The following is sample output from the debug ip http url command. In this example, the HTTP server accessed the URLs and /exec. The output shows the URL being requested and the IP address of the host requesting the URL.
Router# debug ip http urlHTTP: processing URL '/' from host 172.31.2.141HTTP: processing URL '/exec' from host 172.31.2.141Related Commands
debug ip icmp
To display information on Internal Control Message Protocol (ICMP) transactions, use the debug ip icmp command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip icmp
no debug ip icmp
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
This command helps you determine whether the router is sending or receiving ICMP messages. Use it, for example, when you are troubleshooting an end-to-end connection problem.
Note
Examples
The following is sample output from the debug ip icmp command:
Router# debug ip icmpICMP: rcvd type 3, code 1, from 10.95.192.4ICMP: src 10.56.0.202, dst 172.69.16.1, echo replyICMP: dst (10.120.1.0) port unreachable rcv from 10.120.1.15ICMP: src 172.69.12.35, dst 172.69.20.7, echo replyICMP: dst (255.255.255.255) protocol unreachable rcv from 10.31.7.21ICMP: dst (10.120.1.0) port unreachable rcv from 10.120.1.15ICMP: dst (255.255.255.255) protocol unreachable rcv from 10.31.7.21ICMP: dst (10.120.1.0) port unreachable rcv from 10.120.1.15ICMP: src 10.56.0.202, dst 172.69.16.1, echo replyICMP: dst (10.120.1.0) port unreachable rcv from 10.120.1.15ICMP: dst (255.255.255.255) protocol unreachable rcv from 10.31.7.21ICMP: dst (10.120.1.0) port unreachable rcv from 10.120.1.15Table 138 describes the significant fields shown in the display.
Table 139 describes the significant fields shown in the second line of the display.
Other messages that the debug ip icmp command can generate follow.
When an IP router or host sends out an ICMP mask request, the following message is generated when the router sends a mask reply:
ICMP: sending mask reply (255.255.255.0) to 172.69.80.23 via Ethernet0The following two lines are examples of the two forms of this message. The first form is generated when a mask reply comes in after the router sends out a mask request. The second form occurs when the router receives a mask reply with a nonmatching sequence and ID. Refer to Appendix I of RFC 950, Internet Standard Subnetting Procedures, for details.
ICMP: mask reply 255.255.255.0 from 172.69.80.31ICMP: unexpected mask reply 255.255.255.0 from 172.69.80.32The following output indicates that the router sent a redirect packet to the host at address 172.69.80.31, instructing that host to use the gateway at address 172.69.80.23 in order to reach the host at destination address 172.69.1.111:
ICMP: redirect sent to 172.69.80.31 for dest 172.69.1.111 use gw 172.69.80.23The following message indicates that the router received a redirect packet from the host at address 172.69.80.23, instructing the router to use the gateway at address 172.69.80.28 in order to reach the host at destination address 172.69.81.34:
ICMP: redirect rcvd from 172.69.80.23 -- for 172.69.81.34 use gw 172.69.80.28The following message is displayed when the router sends an ICMP packet to the source address (172.69.94.31 in this case), indicating that the destination address (172.69.13.33 in this case) is unreachable:
ICMP: dst (172.69.13.33) host unreachable sent to 172.69.94.31The following message is displayed when the router receives an ICMP packet from an intermediate address (172.69.98.32 in this case), indicating that the destination address (172.69.13.33 in this case) is unreachable:
ICMP: dst (172.69.13.33) host unreachable rcv from 172.69.98.32Depending on the code received (as Table 123 describes), any of the unreachable messages can have any of the following "strings" instead of the "host" string in the message:
netprotocolportfrag. needed and DF setsource route failedprohibitedThe following message is displayed when the TTL in the IP header reaches zero and a time exceed ICMP message is sent. The fields are self-explanatory.
ICMP: time exceeded (time to live) send to 10.95.1.4 (dest was 172.69.1.111)The following message is generated when parameters in the IP header are corrupted in some way and the parameter problem ICMP message is sent. The fields are self-explanatory.
ICMP: parameter problem sent to 128.121.1.50 (dest was 172.69.1.111)Based on the preceding information, the remaining output can be easily understood:
ICMP: parameter problem rcvd 172.69.80.32ICMP: source quench rcvd 172.69.80.32ICMP: source quench sent to 128.121.1.50 (dest was 172.69.1.111)ICMP: sending time stamp reply to 172.69.80.45ICMP: sending info reply to 172.69.80.12ICMP: rdp advert rcvd type 9, code 0, from 172.69.80.23ICMP: rdp solicit rcvd type 10, code 0, from 172.69.80.43debug ip igmp
To display Internet Group Management Protocol (IGMP) packets received and sent, and IGMP-host related events, use the debug ip igmp command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip igmp [vrf vrf-name] [group-address]
no debug ip igmp [vrf vrf-name] [group-address]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command helps discover whether the IGMP processes are functioning. In general, if IGMP is not working, the router process never discovers that another host is on the network that is configured to receive multicast packets. In dense mode, this situation will result in packets being delivered intermittently (a few every 3 minutes). In sparse mode, packets will never be delivered.
Use this command in conjunction with the debug ip pim and debug ip mrouting commands to observe additional multicast activity and to learn the status of the multicast routing process, or why packets are forwarded out of particular interfaces.
When SSM mapping is enabled, a debug message is displayed to indicate that the router is converting an IGMP version 2 report from the group (G) into an IGMP version 3 join. After SSM mapping has generated the appropriate IGMP version 3 report, any debug output that follows is seen as if the router had received the same IGMP version 3 report directly.
Examples
The following is sample output from the debug ip igmp command:
Router# debug ip igmpIGMP: Received Host-Query from 172.16.37.33 (Ethernet1)IGMP: Received Host-Report from 172.16.37.192 (Ethernet1) for 224.0.255.1IGMP: Received Host-Report from 172.16.37.57 (Ethernet1) for 224.2.127.255IGMP: Received Host-Report from 172.16.37.33 (Ethernet1) for 225.2.2.2The messages displayed by the debug ip igmp command show query and report activity received from other routers and multicast group addresses.
The following is sample output from the debug ip igmp command when SSM is enabled. Because IGMP version 3 lite (IGMPv3lite) requires the host to send IGMP version 2 (IGMPv2) packets, IGMPv2 host reports also will be displayed in response to the router IGMPv2 queries. If SSM is disabled, the word "ignored" will be displayed in the debug ip igmp command output.
IGMP:Received v3-lite Report from 10.0.119.142 (Ethernet3/3), group count 1IGMP:Received v3 Group Record from 10.0.119.142 (Ethernet3/3) for 232.10.10.10IGMP:Update source 224.1.1.1IGMP:Send v2 Query on Ethernet3/3 to 224.0.0.1IGMP:Received v2 Report from 10.0.119.142 (Ethernet3/3) for 232.10.10.10IGMP:Update source 224.1.1.1The following is sample output from the debug ip igmp command when SSM static mapping is enabled. The following output indicates that the router is converting an IGMP version 2 join for group (G) into an IGMP version 3 join:
IGMP(0): Convert IGMPv2 report (*,232.1.2.3) to IGMPv3 with 2 source(s) using STATIC.The following is sample output from the debug ip igmp command when SSM DNS-based mapping is enabled. The following output indicates that a DNS lookup has succeeded:
IGMP(0): Convert IGMPv2 report (*,232.1.2.3) to IGMPv3 with 2 source(s) using DNS.The following is sample output from the debug ip igmp command when SSM DNS-based mapping is enabled and a DNS lookup has failed:
IGMP(0): DNS source lookup failed for (*, 232.1.2.3), IGMPv2 report failedRelated Commands
debug ip igmp snooping
To display debugging messages about Internet Group Management Protocol (IGMP) snooping services, use the debug ip igmp snooping command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip igmp snooping {group | management | router | timer}
no debug ip igmp snooping {group | management | router | timer}
Syntax Description
Defaults
Debugging is disabled.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows debugging messages for the IGMP snooping services being displayed:
Router# debug ip igmp snoopingIGMP snooping enabledRelated Commands
debug ip igrp events
To display summary information on Interior Gateway Routing Protocol (IGRP) routing messages that indicate the source and destination of each update, and the number of routes in each update, use the debug ip igrp events command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip igrp events [ip-address]
no debug ip igrp events [ip-address]
Syntax Description
Command Modes
Privileged EXEC
Usage Guidelines
If the IP address of an IGRP neighbor is specified, the resulting debug ip igrp events output includes messages describing updates from that neighbor and updates that the router broadcasts toward that neighbor. Messages are not generated for each route.
This command is particularly useful when there are many networks in your routing table. In this case, using debug ip igrp transactions could flood the console and make the router unusable. Use debug ip igrp events instead to display summary routing information.
Examples
The following is sample output from the debug ip igrp events command:
This shows that the router has sent two updates to the broadcast address 255.255.255.255. The router also received two updates. Three lines of output describe each of these updates.
The first line indicates whether the router sent or received the update packet, the source or destination address, and the interface through which the update was sent or received. If the update was sent, the IP address assigned to this interface is shown (in parentheses).
IGRP: sending update to 255.255.255.255 via Ethernet1 (160.89.33.8)The second line summarizes the number and types of routes described in the update:
IGRP: Update contains 26 interior, 40 system, and 3 exterior routes.The third line indicates the total number of routes described in the update:
IGRP: Total routes in update: 69debug ip igrp transactions
To display transaction information on Interior Gateway Routing Protocol (IGRP) routing transactions, use the debug ip igrp transactions command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip igrp transactions [ip-address]
no debug ip igrp transactions [ip-address]
Syntax Description
Command Modes
Privileged EXEC
Usage Guidelines
If the IP address of an IGRP neighbor is specified, the resulting debug ip igrp transactions output includes messages describing updates from that neighbor and updates that the router broadcasts toward that neighbor.
When many networks are in your routing table, the debug ip igrp transactions command can flood the console and make the router unusable. In this case, use the debug ip igrp events command instead to display summary routing information.
Examples
The following is sample output from the debug ip igrp transactions command:
The output shows that the router being debugged has received updates from two other routers on the network. The router at source address 160.89.80.240 sent information about ten destinations in the update; the router at source address 160.89.80.28 sent information about three destinations in its update. The router being debugged also sent updates—in both cases to the broadcast address 255.255.255.255 as the destination address.
On the second line the first field refers to the type of destination information: "subnet" (interior), "network" (system), or "exterior" (exterior). The second field is the Internet address of the destination network. The third field is the metric stored in the routing table and the metric advertised by the neighbor sending the information. "Metric... inaccessible" usually means that the neighbor router has put the destination in a hold down state.
The entries show that the router is sending updates that are similar, except that the numbers in parentheses are the source addresses used in the IP header. A metric of 16777215 is inaccessible.
Other examples of output that the debug ip igrp transactions command can produce follow.
The following entry indicates that the routing table was updated and shows the new edition number (97 in this case) to be used in the next IGRP update:
IGRP: edition is now 97Entries such as the following occur on startup or when some event occurs such as an interface making a transition or a user manually clearing the routing table:
IGRP: broadcasting request on Ethernet0IGRP: broadcasting request on Ethernet1The following type of entry can result when routing updates become corrupted between sending and receiving routers:
IGRP: bad checksum from 172.69.64.43An entry such as the following should never appear. If it does, the receiving router has a bug in the software or a problem with the hardware. In either case, contact your technical support representative.
IGRP: system 45 from 172.69.64.234, should be system 109debug ip inspect
Note
To display messages about Cisco IOS Firewall events, use the debug ip inspect command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip inspect {function-trace | object-creation | object-deletion | events | timers | protocol | detailed | update}
Firewall MIB Statistics Syntax
debug ip inspect mib {object-creation | object-deletion | events | retrieval | update}
no debug ip inspect
Syntax Description
mib
(Optional) Displays messages about MIB functionality.
function-trace
Displays messages about software functions called by the Cisco IOS Firewall.
object-creation
Displays messages about software objects being created by the Cisco IOS Firewall. Object creation corresponds to the beginning of Cisco IOS Firewall-inspected sessions.
object-deletion
Displays messages about software objects being deleted by the Cisco IOS Firewall. Object deletion corresponds to the closing of Cisco IOS Firewall-inspected sessions.
events
Displays messages about Cisco IOS Firewall software events, including information about Cisco IOS Firewall packet processing or MIB special events.
timers
Displays messages about Cisco IOS Firewall timer events such as when the Cisco IOS Firewall idle timeout is reached.
protocol
Displays messages about Cisco IOS Firewall-inspected protocol events, including details about the packets of the protocol. Table 140 provides a list of protocol keywords.
detailed
Displays detailed information to be displayed for all the other enabled Cisco IOS Firewall debugging. Use this form of the command in conjunction with other Cisco IOS Firewall debug commands.
retrieval
Displays messages of statistics requested via Simple Network Management Protocol (SNMP) or command-line interface (CLI).
update
Displays messages about Cisco IOS Firewall software updates or updates to MIB counters.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug ip inspect function-trace command:
Router# debug ip inspect function-trace*Mar 2 01:16:16: CBAC FUNC: insp_inspection*Mar 2 01:16:16: CBAC FUNC: insp_pre_process_sync*Mar 2 01:16:16: CBAC FUNC: insp_find_tcp_host_entry addr 40.0.0.1 bucket 41*Mar 2 01:16:16: CBAC FUNC: insp_find_pregen_session*Mar 2 01:16:16: CBAC FUNC: insp_get_idbsb*Mar 2 01:16:16: CBAC FUNC: insp_get_idbsb*Mar 2 01:16:16: CBAC FUNC: insp_get_irc_of_idb*Mar 2 01:16:16: CBAC FUNC: insp_get_idbsb*Mar 2 01:16:16: CBAC FUNC: insp_create_sis*Mar 2 01:16:16: CBAC FUNC: insp_inc_halfopen_sis*Mar 2 01:16:16: CBAC FUNC: insp_link_session_to_hash_table*Mar 2 01:16:16: CBAC FUNC: insp_inspect_pak*Mar 2 01:16:16: CBAC FUNC: insp_l4_inspection*Mar 2 01:16:16: CBAC FUNC: insp_process_tcp_seg*Mar 2 01:16:16: CBAC FUNC: insp_listen_state*Mar 2 01:16:16: CBAC FUNC: insp_ensure_return_traffic*Mar 2 01:16:16: CBAC FUNC: insp_add_acl_item*Mar 2 01:16:16: CBAC FUNC: insp_ensure_return_traffic*Mar 2 01:16:16: CBAC FUNC: insp_add_acl_item*Mar 2 01:16:16: CBAC FUNC: insp_process_syn_packet*Mar 2 01:16:16: CBAC FUNC: insp_find_tcp_host_entry addr 40.0.0.1 bucket 41*Mar 2 01:16:16: CBAC FUNC: insp_create_tcp_host_entry*Mar 2 01:16:16: CBAC* FUNC: insp_fast_inspection*Mar 2 01:16:16: CBAC* FUNC: insp_inspect_pak*Mar 2 01:16:16: CBAC* FUNC: insp_l4_inspection*Mar 2 01:16:16: CBAC* FUNC: insp_process_tcp_seg*Mar 2 01:16:16: CBAC* FUNC: insp_synrcvd_state*Mar 2 01:16:16: CBAC* FUNC: insp_fast_inspection*Mar 2 01:16:16: CBAC* FUNC: insp_inspect_pak*Mar 2 01:16:16: CBAC* FUNC: insp_l4_inspection*Mar 2 01:16:16: CBAC* FUNC: insp_process_tcp_seg*Mar 2 01:16:16: CBAC* FUNC: insp_synrcvd_state*Mar 2 01:16:16: CBAC FUNC: insp_dec_halfopen_sis*Mar 2 01:16:16: CBAC FUNC: insp_remove_sis_from_host_entry*Mar 2 01:16:16: CBAC FUNC: insp_find_tcp_host_entry addr 40.0.0.1 bucket 41This output shows the functions called by the Cisco IOS Firewall as a session is inspected. Entries with an asterisk (*) after the word "CBAC" are entries when the fast path is used; otherwise, the process path is used.
The following is sample output from the debug ip inspect object-creation and debug ip inspect object-deletion commands:
Router# debug ip inspect object-creationRouter# debug ip inspect object-deletion*Mar 2 01:18:30: CBAC OBJ_CREATE: create pre-gen sis 25A3574*Mar 2 01:18:30: CBAC OBJ_CREATE: create acl wrapper 25A36FC -- acl item 25A3634*Mar 2 01:18:30: CBAC OBJ_CREATE: create sis 25C1CC4*Mar 2 01:18:30: CBAC OBJ_DELETE: delete pre-gen sis 25A3574*Mar 2 01:18:30: CBAC OBJ_CREATE: create host entry 25A3574 addr 10.0.0.1 bucket 31*Mar 2 01:18:30: CBAC OBJ_DELETE: delete sis 25C1CC4*Mar 2 01:18:30: CBAC OBJ_DELETE: delete create acl wrapper 25A36FC -- acl item 25A3634*Mar 2 01:18:31: CBAC OBJ_DELETE: delete host entry 25A3574 addr 10.0.0.1The following is sample output from the debug ip inspect object-creation, debug ip inspect object-deletion, and debug ip inspect events commands:
Router# debug ip inspect object-creationRouter# debug ip inspect object-deletionRouter# debug ip inspect events*Mar 2 01:18:51: CBAC OBJ_CREATE: create pre-gen sis 25A3574*Mar 2 01:18:51: CBAC OBJ_CREATE: create acl wrapper 25A36FC -- acl item 25A3634*Mar 2 01:18:51: CBAC Src 10.1.0.1 Port [1:65535]*Mar 2 01:18:51: CBAC Dst 10.0.0.1 Port [46406:46406]*Mar 2 01:18:51: CBAC Pre-gen sis 25A3574 created: 10.1.0.1[1:65535] 30.0.0.1[46406:46406]*Mar 2 01:18:51: CBAC OBJ_CREATE: create sis 25C1CC4*Mar 2 01:18:51: CBAC sis 25C1CC4 initiator_addr (10.1.0.1:20) responder_addr (30.0.0.1:46406) initiator_alt_addr (40.0.0.1:20) responder_alt_addr (10.0.0.1:46406)*Mar 2 01:18:51: CBAC OBJ_DELETE: delete pre-gen sis 25A3574*Mar 2 01:18:51: CBAC OBJ_CREATE: create host entry 25A3574 addr 10.0.0.1 bucket 31*Mar 2 01:18:51: CBAC OBJ_DELETE: delete sis 25C1CC4*Mar 2 01:18:51: CBAC OBJ_DELETE: delete create acl wrapper 25A36FC -- acl item 25A3634*Mar 2 01:18:51: CBAC OBJ_DELETE: delete host entry 25A3574 addr 10.0.0.1The following is sample output from the debug ip inspect timers command:
Router# debug ip inspect timers*Mar 2 01:19:15: CBAC Timer Init Leaf: Pre-gen sis 25A3574*Mar 2 01:19:15: CBAC Timer Start: Pre-gen sis 25A3574 Timer: 25A35D8 Time: 30000 milisecs*Mar 2 01:19:15: CBAC Timer Init Leaf: sis 25C1CC4*Mar 2 01:19:15: CBAC Timer Stop: Pre-gen sis 25A3574 Timer: 25A35D8*Mar 2 01:19:15: CBAC Timer Start: sis 25C1CC4 Timer: 25C1D5C Time: 30000 milisecs*Mar 2 01:19:15: CBAC Timer Start: sis 25C1CC4 Timer: 25C1D5C Time: 3600000 milisecs*Mar 2 01:19:15: CBAC Timer Start: sis 25C1CC4 Timer: 25C1D5C Time: 5000 milisecs*Mar 2 01:19:15: CBAC Timer Stop: sis 25C1CC4 Timer: 25C1D5CThe following is sample output from the debug ip inspect tcp command:
Router# debug ip inspect tcp*Mar 2 01:20:43: CBAC* sis 25A3604 pak 2541C58 TCP P ack 4223720032 seq 4200176225(22) (10.0.0.1:46409) => (10.1.0.1:21)*Mar 2 01:20:43: CBAC* sis 25A3604 ftp L7 inspect result: PROCESS-SWITCH packet*Mar 2 01:20:43: CBAC sis 25A3604 pak 2541C58 TCP P ack 4223720032 seq 4200176225(22) (10.0.0.1:46409) => (10.1.0.1:21)*Mar 2 01:20:43: CBAC sis 25A3604 ftp L7 inspect result: PASS packet*Mar 2 01:20:43: CBAC* sis 25A3604 pak 2544374 TCP P ack 4200176247 seq 4223720032(30) (10.0.0. 1:46409) <= (10.1.0.1:21)*Mar 2 01:20:43: CBAC* sis 25A3604 ftp L7 inspect result: PASS packet*Mar 2 01:20:43: CBAC* sis 25A3604 pak 25412F8 TCP P ack 4223720062 seq 4200176247(15) (10.0.0. 1:46409) => (10.1.0.1:21)*Mar 2 01:20:43: CBAC* sis 25A3604 ftp L7 inspect result: PASS packet*Mar 2 01:20:43: CBAC sis 25C1CC4 pak 2544734 TCP S seq 4226992037(0) (10.1.0.1:20) => (10.0.0.1:46411)*Mar 2 01:20:43: CBAC* sis 25C1CC4 pak 2541E38 TCP S ack 4226992038 seq 4203405054(0) (10.1.0.1:20) <= (10.0.0.1:46411)This sample shows TCP packets being processed and lists the corresponding acknowledge (ACK) packet numbers and sequence (SEQ) numbers. The number of data bytes in the TCP packet is shown in parentheses—for example, (22). For each packet shown, the addresses and port numbers are shown separated by a colon. For example, (10.1.0.1:21) indicates an IP address of 10.1.0.1 and a TCP port number of 21.
Entries with an asterisk (*) after the word "CBAC" are entries when the fast path is used; otherwise, the process path is used.
The following is sample output from the debug ip inspect tcp and debug ip inspect detailed commands:
Router# debug ip inspect tcpRouter# debug ip inspect detailed*Mar 2 01:20:58: CBAC* Pak 2541E38 Find session for (30.0.0.1:46409) (40.0.0.1:21) tcp*Mar 2 01:20:58: P ack 4223720160 seq 4200176262(22)*Mar 2 01:20:58: CBAC* Pak 2541E38 Addr:port pairs to match: (30.0.0.1:46409) (40.0.0.1:21)*Mar 2 01:20:58: CBAC* sis 25A3604 SIS_OPEN*Mar 2 01:20:58: CBAC* Pak 2541E38 IP: s=30.0.0.1 (Ethernet0), d=40.0.0.1 (Ethernet1), len 76,proto=6*Mar 2 01:20:58: CBAC sis 25A3604 Saving State: SIS_OPEN/ESTAB iisn 4200176160 i_rcvnxt 4223720160 i_sndnxt 4200176262 i_rcvwnd 8760 risn 4223719771 r_rcvnxt 4200176262 r_sndnxt 4223720160 r_rcvwnd 8760*Mar 2 01:20:58: CBAC* sis 25A3604 pak 2541E38 TCP P ack 4223720160 seq 4200176262(22) (30.0.0.1:46409) => (40.0.0.1:21)*Mar 2 01:20:58: CBAC* sis 25A3604 pak 2541E38 SIS_OPEN/ESTAB TCP seq 4200176262(22) Flags: ACK 4223720160 PSH*Mar 2 01:20:58: CBAC* sis 25A3604 pak 2541E38 --> SIS_OPEN/ESTAB iisn 4200176160 i_rcvnxt 4223720160 i_sndnxt 4200176284 i_rcvwnd 8760 risn 4223719771 r_rcvnxt 4200176262 r_sndnxt 4223720160 r_rcvwnd 8760*Mar 2 01:20:58: CBAC* sis 25A3604 L4 inspect result: PASS packet 2541E38 (30.0.0.1:46409) (40.0.0.1:21) bytes 22 ftp*Mar 2 01:20:58: CBAC sis 25A3604 Restoring State: SIS_OPEN/ESTAB iisn 4200176160 i_rcvnxt 4223720160 i_sndnxt 4200176262 i_rcvwnd 8760 risn 4223719771 r_rcvnxt 4200176262 r_sndnxt 4223720160 r_rcvwnd 8760*Mar 2 01:20:58: CBAC* sis 25A3604 ftp L7 inspect result: PROCESS-SWITCH packet*Mar 2 01:20:58: CBAC* sis 25A3604 ftp L7 inspect result: PROCESS-SWITCH packet*Mar 2 01:20:58: CBAC* Bump up: inspection requires the packet in the process path(30.0.0.1) (40.0.0.1)*Mar 2 01:20:58: CBAC Pak 2541E38 Find session for (30.0.0.1:46409) (40.0.0.1:21) tcp*Mar 2 01:20:58: P ack 4223720160 seq 4200176262(22)*Mar 2 01:20:58: CBAC Pak 2541E38 Addr:port pairs to match: (30.0.0.1:46409) (40.0.0.1:21)*Mar 2 01:20:58: CBAC sis 25A3604 SIS_OPEN*Mar 2 01:20:58: CBAC Pak 2541E38 IP: s=30.0.0.1 (Ethernet0), d=40.0.0.1 (Ethernet1), len 76, proto=6The following is sample output from the debug ip inspect icmp and debug ip inspect detailed commands:
Router# debug ip inspect icmpRouter# debug ip inspect detailed1w6d:CBAC sis 81073F0C SIS_CLOSED1w6d:CBAC Pak 80D2E9EC IP:s=192.168.133.3 (Ethernet1), d=0.0.0.0 (Ethernet0), len 98, proto=11w6d:CBAC ICMP:sis 81073F0C pak 80D2E9EC SIS_CLOSED ICMP packet (192.168.133.3:0) => (0.0.0.0:0) datalen 561w6d:CBAC ICMP:start session from 192.168.133.31w6d:CBAC sis 81073F0C --> SIS_OPENING (192.168.133.3:0) (0.0.0.0:0)1w6d:CBAC sis 81073F0C L4 inspect result:PASS packet 80D2E9EC (192.168.133.3:0) (0.0.0.0:0) bytes 56 icmp1w6d:CBAC sis 81073F0C SIS_OPENING1w6d:CBAC Pak 80E72BFC IP:s=0.0.0.0 (Ethernet0), d=192.168.133.3 (Ethernet1), len 98, proto=11w6d:CBAC ICMP:sis 81073F0C pak 80E72BFC SIS_OPENING ICMP packet (192.168.133.3:0) <= (0.0.0.0:0) datalen 561w6d:CBAC sis 81073F0C --> SIS_OPEN (192.168.133.3:0) (0.0.0.0:0)1w6d:CBAC sis 81073F0C L4 inspect result:PASS packet 80E72BFC (0.0.0.0:0) (192.168.133.3:0) bytes 56 icmp1w6d:CBAC* sis 81073F0C SIS_OPEN1w6d:CBAC* Pak 80D2F2C8 IP:s=192.168.133.3 (Ethernet1), d=0.0.0.0 (Ethernet0), len 98, proto=11w6d:CBAC* ICMP:sis 81073F0C pak 80D2F2C8 SIS_OPEN ICMP packet (192.168.133.3:0) => (0.0.0.0:0) datalen 561w6d:CBAC* sis 81073F0C --> SIS_OPEN (192.168.133.3:0) (0.0.0.0:0)1w6d:CBAC* sis 81073F0C L4 inspect result:PASS packet 80D2F2C8 (192.168.133.3:0) (0.0.0.0:0) bytes 56 icmp1w6d:CBAC* sis 81073F0C SIS_OPEN1w6d:CBAC* Pak 80E737CC IP:s=0.0.0.0 (Ethernet0), d=192.168.133.3 (Ethernet1), len 98, proto=11w6d:CBAC* ICMP:sis 81073F0C pak 80E737CC SIS_OPEN ICMP packet (192.168.133.3:0) <= (0.0.0.0:0) datalen 561w6d:CBAC* sis 81073F0C --> SIS_OPEN (192.168.133.3:0) (0.0.0.0:0)1w6d:CBAC* sis 81073F0C L4 inspect result:PASS packet 80E737CC (0.0.0.0:0) (192.168.133.3:0) bytes 56 icmp1w6d:CBAC* sis 81073F0C SIS_OPEN1w6d:CBAC* Pak 80F554F0 IP:s=192.168.133.3 (Ethernet1), d=0.0.0.0 (Ethernet0), len 98, proto=11w6d:CBAC* ICMP:sis 81073F0C pak 80F554F0 SIS_OPEN ICMP packet (192.168.133.3:0) => (0.0.0.0:0) datalen 561w6d:CBAC* sis 81073F0C --> SIS_OPEN (192.168.133.3:0) (0.0.0.0:0)1w6d:CBAC* sis 81073F0C L4 inspect result:PASS packet 80F554F0 (192.168.133.3:0) (0.0.0.0:0) bytes 56 icmp1w6d:CBAC* sis 81073F0C SIS_OPEN1w6d:CBAC* Pak 80E73AC0 IP:s=0.0.0.0 (Ethernet0), d=192.168.133.3 (Ethernet1), len 98, proto=11w6d:CBAC* ICMP:sis 81073F0C pak 80E73AC0 SIS_OPEN ICMP packet (192.168.133.3:0) <= (0.0.0.0:0) datalen 561w6d:CBAC* sis 81073F0C --> SIS_OPEN (192.168.133.3:0) (0.0.0.0:0)1w6d:CBAC* sis 81073F0C L4 inspect result:PASS packet 80E73AC0 (0.0.0.0:0) (192.168.133.3:0) bytes 56 icmpdebug ip inspect ha
To display messages about Cisco IOS stateful failover high availability (HA) events, use the debug ip inspect ha command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip inspect ha [manager | packet | update]
no debug ip inspect ha [manager | packet | update]
Syntax Description
Command Modes
Privileged EXEC (#)
Command History
Examples
The following is sample output from the debug ip inspect ha command. This example shows an add session message and a delete session message received by the the active and standby devices:
Router# debug ip inspect haActive debugs -*Apr 13 17:15:20.795: FW-HA:Send add session msg for session 2C6B820*Apr 13 17:15:36.919: FW-HA:Send delete session msg for session 2C6B820Standby debugs -*Apr 13 17:19:00.471: FW-HA:Received add session message (10.0.0.10:56733:0)=>(11.0.0.10:23:0)*Apr 13 17:19:12.051: FW-HA:Received delete session message (10.0.0.10:56733:0)=>(11.0.0.10:23:0)The following is sample output from the debug ip inspect ha manager command. Using the manager keyword provides a more detailed debug analysis:
Router# debug ip inspect ha manager*Apr 13 17:23:28.995: HA Message 0:flags=0x01 len=727 FW_HA_MSG_INSERT_SESSION (1)*Apr 13 17:23:28.995: ID: grp1*Apr 13 17:23:28.995: attr FW_HA_ATT_INITIATOR_ADDR (1) len 4*Apr 13 17:23:28.995: 0A 00 00 0A*Apr 13 17:23:28.995: attr FW_HA_ATT_RESPONDER_ADDR (2) len 4*Apr 13 17:23:28.995: 0B 00 00 0A*Apr 13 17:23:28.995: attr FW_HA_ATT_INITIATOR_PORT (3) len 2*Apr 13 17:23:28.995: BF 1C*Apr 13 17:23:28.995: attr FW_HA_ATT_RESPONDER_PORT (4) len 2*Apr 13 17:23:28.995: 00 17*Apr 13 17:23:28.995: attr FW_HA_ATT_L4_PROTOCOL (5) len 4*Apr 13 17:23:28.995: 00 00 00 01*Apr 13 17:23:28.995: attr FW_HA_ATT_SRC_TABLEID (6) len 1*Apr 13 17:23:28.995: 00*Apr 13 17:23:28.995: attr FW_HA_ATT_DST_TABLEID (7) len 1*Apr 13 17:23:28.995: 00*Apr 13 17:23:28.995: attr FW_HA_ATT_R_RCVNXT (20) len 4*Apr 13 17:23:28.995: 79 EA E2 9A*Apr 13 17:23:28.995: attr FW_HA_ATT_R_SNDNXT (21) len 4*Apr 13 17:23:28.995: 6C 7D E4 04*Apr 13 17:23:28.995: attr FW_HA_ATT_R_RCVWND (22) len 4*Apr 13 17:23:28.995: 00 00 10 20*Apr 13 17:23:28.995: attr FW_HA_ATT_R_LAST_SEQ_TO_SND (23) len 4*Apr 13 17:23:28.995: 00 00 00 00*Apr 13 17:23:28.995: attr FW_HA_ATT_I_RCVNXT (24) len 4*Apr 13 17:23:28.995: 6C 7D E4 04*Apr 13 17:23:28.995: attr FW_HA_ATT_I_SNDNXT (25) len 4*Apr 13 17:23:28.995: 79 EA E2 9A*Apr 13 17:23:28.995: attr FW_HA_ATT_I_RCVWND (26) len 4*Apr 13 17:23:28.995: 00 00 10 20*Apr 13 17:23:28.995: attr FW_HA_ATT_I_LAST_SEQ_TO_SND (27) len 4*Apr 13 17:23:28.995: 00 00 00 00*Apr 13 17:23:28.995: attr FW_HA_ATT_TCP_STATE (28) len 4*Apr 13 17:23:28.995: 00 00 00 04*Apr 13 17:23:28.995: attr FW_HA_ATT_INITIATOR_ALT_ADDR (8) len 4*Apr 13 17:23:28.995: 0A 00 00 0A*Apr 13 17:23:28.995: attr FW_HA_ATT_RESPONDER_ALT_ADDR (9) len 4*Apr 13 17:23:28.995: 0B 00 00 0A*Apr 13 17:23:28.995: attr FW_HA_ATT_INITIATOR_ALT_PORT (10) len 2*Apr 13 17:23:28.995: BF 1C*Apr 13 17:23:28.995: attr FW_HA_ATT_RESPONDER_ALT_PORT (11) len 2*Apr 13 17:23:28.995: 00 00*Apr 13 17:23:28.995: attr FW_HA_ATT_L7_PROTOCOL (12) len 4*Apr 13 17:23:28.995: 00 00 00 05*Apr 13 17:23:28.995: attr FW_HA_ATT_INSP_DIR (13) len 4*Apr 13 17:23:28.995: 00 00 00 01*Apr 13 17:23:28.995: attr FW_HA_ATT_I_ISN (29) len 4*Apr 13 17:23:28.995: 79 EA E2 99*Apr 13 17:23:28.995: attr FW_HA_ATT_R_ISN (30) len 4*Apr 13 17:23:28.995: 6C 7D E4 03*Apr 13 17:23:28.995: attr FW_HA_ATT_APPL_INSP_FLAGS (15) len 2*Apr 13 17:23:28.995: 00 10*Apr 13 17:23:28.995: attr FW_HA_ATT_TERM_FLAGS (16) len 1*Apr 13 17:23:28.995: 00*Apr 13 17:23:28.995: attr FW_HA_ATT_IS_LOCAL_TRAFFIC (17) len 1*Apr 13 17:23:28.995: 00*Apr 13 17:23:28.995: attr FW_HA_ATT_DATA_DIR (18) len 4*Apr 13 17:23:28.995: 00 00 00 00*Apr 13 17:23:28.995: attr FW_HA_ATT_SESSION_LIMITING_DONE (19) len 1*Apr 13 17:23:28.995: 00*Apr 13 17:23:28.995: attr FW_HA_ATT_INSPECT_RULE (14) len 256*Apr 13 17:23:28.995: 74 65 73 74 00 00 00 00debug ip inspect L2-transparent
To enable debugging messages for transparent firewall events, use the debug ip inspect L2-transparent command in privileged EXEC mode. To disable debugging messages, use the no form of this command.
debug ip inspect L2-transparent {packet | dhcp-passthrough}
no debug ip inspect L2-transparent {packet | dhcp-passthrough}
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug ip inspect L2-transparent command can be used to help verify and troubleshoot transparent firewall-related configurations, such as a Telnet connection from the client to the server with inspection configured.
Examples
The following example shows how the transparent firewall debug command works in a basic transparent firewall configuration. (Note that each debug message is preceded by an asterisk (*).)
! Enable debug commands.Router# debug ip inspect L2-transparent packetINSPECT L2 firewall debugging is onRouter# debug ip inspect object-creationINSPECT Object Creations debugging is onRouter# debug ip inspect object-deletionINSPECT Object Deletions debugging is on! Start the transparent firewall configuration processRouter# config terminalEnter configuration commands, one per line. End with CNTL/Z.! Configure bridgingRouter(config)# bridge 1 protocol ieeeRouter(config)# bridge irbRouter(config)# bridge 1 route ipRouter(config)# interface bvi1*Mar 1 00:06:42.511:%LINK-3-UPDOWN:Interface BVI1, changed state to down.Router(config-if)# ip address 209.165.200.225 255.255.255.254! Configure inspectionRouter(config)# ip inspect name test tcp! Following debugs show the memory allocated for CBAC rules.*Mar 1 00:07:21.127:CBAC OBJ_CREATE:create irc 817F04F0 (test)*Mar 1 00:07:21.127:CBAC OBJ_CREATE:create irt 818AED20 Protocol:tcp Inactivity time:0 testRouter(config)# ip inspect name test icmpRouter(config)#*Mar 1 00:07:39.211:CBAC OBJ_CREATE:create irt 818AEDCC Protocol:icmp Inactivity time:0! Configure Bridging on ethernet0 interfaceRouter(config)# interface ethernet0Router(config-if)# bridge-group 1*Mar 1 00:07:49.071:%LINK-3-UPDOWN:Interface BVI1, changed state to up*Mar 1 00:07:50.071:%LINEPROTO-5-UPDOWN:Line protocol on Interface BVI1, changed state to up! Configure inspection on ethernet0 interfaceRouter(config-if)# ip inspect test inRouter(config-if)#*Mar 1 00:07:57.543:CBAC OBJ_CREATE:create idbsb 8189CBFC (Ethernet0)! Incremented the number of bridging interfaces configured for inspection */*Mar 1 00:07:57.543:L2FW:Incrementing L2FW i/f countRouter(config-if)# interface ethernet1! Configure bridging and ACL on interface ethernet1Router(config-if)# bridge-group 1Router(config-if)# ip access-group 101 in*Mar 1 00:08:26.711:%LINEPROTO-5-UPDOWN:Line protocol on Interface Ethernet1, changed state to upRouter(config-if)# endRelated Commands
ip inspect L2-transparent dhcp-passthrough
Allows a transparent firewall to forward DHCP pass-through traffic.
debug ip ips
To enable debugging messages for Cisco IOS Intrusion Prevention System (IPS), use the debug ip ips command in privileged EXEC mode. To disable debugging messages, use the no form of this command.
debug ip ips [engine] [detailed] [service-msrpc] [service-sm]
no debug ip ips [engine] [detailed]
Syntax Description
Command Modes
Privileged EXEC
Command History
Examples
The following example shows how to enable debugging messages for the Cisco IOS IPS:
Router# debug ip ipsdebug ip mbgp dampening
To log route flap dampening activity related to multiprotocol Border Gateway Protocol (BGP), use the debug ip mbgp dampening command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mbgp dampening [access-list-number]
no debug ip mbgp dampening [access-list-number]
Syntax Description
access-list-number
(Optional) The number of an access list in the range from 1 to 99. If an access list number is specified, debugging occurs only for the routes permitted by the access list.
Defaults
Logging for route flap dampening activity is not enabled.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug ip mbgp dampening command:
Router# debug ip mbgp dampeningBGP: charge penalty for 173.19.0.0/16 path 49 with halflife-time 15 reuse/suppress 750/2000BGP: flapped 1 times since 00:00:00. New penalty is 1000BGP: charge penalty for 173.19.0.0/16 path 19 49 with halflife-time 15 reuse/suppress 750/2000BGP: flapped 1 times since 00:00:00. New penalty is 1000debug ip mbgp updates
To log multiprotocol Border Gateway Protocol (BGP)-related information passed in BGP update messages, use the debug ip mbgp updates command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mbgp updates
no debug ip mbgp updates
Syntax Description
This command has no arguments or keywords.
Defaults
Logging for multiprotocol BGP-related information in BGP update messages is not enabled.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug ip mbgp updates command:
Router# debug ip mbgp updatesBGP: NEXT_HOP part 1 net 200.10.200.0/24, neigh 171.69.233.49, next 171.69.233.34BGP: 171.69.233.49 send UPDATE 200.10.200.0/24, next 171.69.233.34, metric 0, path 33 34 19 49 109 65000 297 3561 6503BGP: NEXT_HOP part 1 net 200.10.202.0/24, neigh 171.69.233.49, next 171.69.233.34BGP: 171.69.233.49 send UPDATE 200.10.202.0/24, next 171.69.233.34, metric 0, path 33 34 19 49 109 65000 297 1239 1800 3597BGP: NEXT_HOP part 1 net 200.10.228.0/22, neigh 171.69.233.49, next 171.69.233.34BGP: 171.69.233.49 rcv UPDATE about 222.2.2.0/24, next hop 171.69.233.49, path 49 109 metric 0BGP: 171.69.233.49 rcv UPDATE about 131.103.0.0/16, next hop 171.69.233.49, path 49 109 metric 0BGP: 171.69.233.49 rcv UPDATE about 206.205.242.0/24, next hop 171.69.233.49, path 49 109 metric 0BGP: 171.69.233.49 rcv UPDATE about 1.0.0.0/8, next hop 171.69.233.49, path 49 19 metric 0BGP: 171.69.233.49 rcv UPDATE about 198.1.2.0/24, next hop 171.69.233.49, path 49 19 metric 0BGP: 171.69.233.49 rcv UPDATE about 171.69.0.0/16, next hop 171.69.233.49, path 49 metric 0BGP: 171.69.233.49 rcv UPDATE about 172.19.0.0/16, next hop 171.69.233.49, path 49 metric 0BGP: nettable_walker 172.19.0.0/255.255.0.0 calling revise_routeBGP: revise route installing 172.19.0.0/255.255.0.0 -> 171.69.233.49BGP: 171.69.233.19 computing updates, neighbor version 267099, table version 267100, starting at 0.0.0.0BGP: NEXT_HOP part 1 net 172.19.0.0/16, neigh 171.69.233.19, next 171.69.233.49BGP: 171.69.233.19 send UPDATE 172.19.0.0/16, next 171.69.233.49, metric 0, path 33 49BGP: 1 updates (average = 46, maximum = 46)BGP: 171.69.233.19 updates replicated for neighbors : 171.69.233.34, 171.69.233.49, 171.69.233.56BGP: 171.69.233.19 1 updates enqueued (average=46, maximum=46)BGP: 171.69.233.19 update run completed, ran for 0ms, neighbor version 267099, start version 267100, throttled to 267100, check point net 0.0.0.0debug ip mcache
To display IP multicast fast-switching events, use the debug ip mcache command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mcache [vrf vrf-name] [hostname | group-address]
no debug ip mcache [vrf vrf-name] [hostname | group-address]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use this command when multicast fast switching appears not to be functioning.
Examples
The following is sample output from the debug ip mcache command when an IP multicast route is cleared:
Router# debug ip mcacheIP multicast fast-switching debugging is onRouter# clear ip mroute *MRC: Build MAC header for (172.31.60.185/32, 224.2.231.173), Ethernet0MRC: Fast-switch flag for (172.31.60.185/32, 224.2.231.173), off -> on, caller ip_mroute_replicate-1MRC: Build MAC header for (172.31.191.10/32, 224.2.127.255), Ethernet0MRC: Build MAC header for (172.31.60.152/32, 224.2.231.173), Ethernet0Table 141 describes the significant fields shown in the display.
Related Commands
debug ip mds ipc
To debug multicast distributed switching (MDS) interprocessor communication, that is, synchronization between the Multicast Forwarding Information Base (MFIB) on the line card and the multicast routing table in the Route Processor (RP), use the debug ip mds ipc command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mds ipc {event | packet}
no debug ip mds ipc {event | packet}
Syntax Description
Command Modes
Privileged EXEC
Usage Guidelines
Use this command on the line card or RP.
Examples
The following is sample output from the debug ip mds ipc packet command:
Router# debug ip mds ipc packetMDFS ipc packet debugging is onRouter#MDFS: LC sending statistics message to RP with code 0 of size 36MDFS: LC sending statistics message to RP with code 1 of size 680MDFS: LC sending statistics message to RP with code 2 of size 200MDFS: LC sending statistics message to RP with code 3 of size 152MDFS: LC sending window message to RP with code 36261 of size 8MDFS: LC received IPC packet of size 60 sequence 36212The following is sample output from the debug ip mds ipc event command:
Router# debug ip mds ipc eventMDFS: LC received invalid sequence 21 while expecting 20debug ip mds mevent
To debug Multicast Forwarding Information Base (MFIB) route creation, route updates, and so on, use the debug ip mds mevent command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mds mevent
no debug ip mds mevent
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
Use this command on the line card.
Examples
The following is sample output from the debug ip mds mevent command:
Router# debug ip mds meventMDFS mroute event debugging is onRouter#clear ip mdfs for *Router#MDFS: Create (*, 239.255.255.255)MDFS: Create (192.168.1.1/32, 239.255.255.255), RPF POS2/0/0MDFS: Add OIF for mroute (192.168.1.1/239.255.255.255) on Fddi0/0/0MDFS: Create (*, 224.2.127.254)MDFS: Create (192.168.1.1/32, 224.2.127.254), RPF POS2/0/0MDFS: Add OIF for mroute (192.168.1.1/224.2.127.254) on Fddi0/0/0MDFS: Create (128.9.160.67/32, 224.2.127.254), RPF POS2/0/0debug ip mds mpacket
To debug multicast distributed switching (MDS) events such as packet drops, interface drops, and switching failures, use the debug ip mds mpacket command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mds mpacket
no debug ip mds mpacket
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
Use this command on the line card.
debug ip mds process
To debug line card process level events, use the debug ip mds process command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mds process
no debug ip mds process
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
Use this command on the line card or Route Processor (RP).
Examples
The following is sample output from the debug ip mds process command:
Router# debug ip mds processMDFS process debugging is onMar 19 16:15:47.448: MDFS: RP queueing mdb message for (210.115.194.5, 224.2.127.254) to all linecardsMar 19 16:15:47.448: MDFS: RP queueing midb message for (210.115.194.5, 224.2.127.254) to all linecardsMar 19 16:15:47.628: MDFS: RP servicing low queue for LC in slot 0Mar 19 16:15:47.628: MDFS: RP servicing low queue for LC in slot 2Mar 19 16:15:48.229: MDFS: RP queueing mdb message for (171.68.224.10, 224.2.127.254) to all linecardsMar 19 16:15:48.229: MDFS: RP queueing mdb message for (171.68.224.10, 224.2.127.254) to all linecardsMar 19 16:15:48.229: MDFS: RP queueing mdb message for (171.69.67.106, 224.2.127.254) to all linecardsMar 19 16:15:48.229: MDFS: RP queueing mdb message for (171.69.67.106, 224.2.127.254) to all linecardsMar 19 16:15:48.229: MDFS: RP queueing mdb message for (206.14.154.181, 224.2.127.254) to all linecardsMar 19 16:15:48.229: MDFS: RP queueing mdb message for (206.14.154.181, 224.2.127.254) to all linecardsMar 19 16:15:48.233: MDFS: RP queueing mdb message for (210.115.194.5, 224.2.127.254) to all linecardsdebug ip mhbeat
To monitor the action of the heartbeat trap, use the debug ip mhbeat command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mhbeat
no debug ip mhbeat
Syntax Description
This command has no arguments or keywords.
Defaults
Debugging is not enabled.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug ip mhbeat command.
Router# debug ip mhbeatIP multicast heartbeat debugging is onRouter debug snmp packetsSNMP packet debugging is on!Router(config)# ip multicast heartbeat intervals-of 10Dec 23 13:34:21.132: MHBEAT: ip multicast-heartbeat group 224.0.1.53 port 0source 0.0.0.0 0.0.0.0 at-least 3 in 5 intervals-of 10 secondsdRouter#Dec 23 13:34:23: %SYS-5-CONFIG_I: Configured from console by consoleDec 23 13:34:31.136: MHBEAT: timer ticked, t=1,i=1,c=0Dec 23 13:34:41.136: MHBEAT: timer ticked, t=2,i=2,c=0Dec 23 13:34:51.136: MHBEAT: timer ticked, t=3,i=3,c=0Dec 23 13:35:01.136: MHBEAT: timer ticked, t=4,i=4,c=0Dec 23 13:35:11.136: MHBEAT: timer ticked, t=5,i=0,c=0Dec 23 13:35:21.135: Send SNMP Trap for missing heartbeatDec 23 13:35:21.135: SNMP: Queuing packet to 171.69.55.12Dec 23 13:35:21.135: SNMP: V1 Trap, ent ciscoExperiment.2.3.1, addr 4.4.4.4, gentrap 6, spectrap 1ciscoIpMRouteHeartBeat.1.0 = 224.0.1.53ciscoIpMRouteHeartBeat.2.0 = 0.0.0.0ciscoIpMRouteHeartBeat.3.0 = 10ciscoIpMRouteHeartBeat.4.0 = 5ciscoIpMRouteHeartBeat.5.0 = 0ciscoIpMRouteHeartBeat.6.0 = 3Related Commands
ip multicast heartbeat
Monitors the health of multicast delivery, and alerts when the delivery fails to meet certain parameters.
debug ip mobile
To display IP mobility activities, use the debug ip mobile command in privileged EXEC mode.
debug ip mobile [advertise | host [access-list-number] | local-area | redundancy | udp-tunneling]
Syntax Description
Defaults
No default behavior or values.
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
Use the debug ip mobile redundancy command to troubleshoot redundancy problems.
No per-user debugging output is shown for mobile nodes using the network access identifier (NAI) for the debug ip mobile host command. Debugging of specific mobile nodes using an IP address is possible through the access list.
Examples
The following is sample output from the debug ip mobile command when foreign agent reverse tunneling is enabled:
MobileIP:MN 14.0.0.30 deleted from ReverseTunnelTable of Ethernet2/1(Entries 0)The following is sample output from the debug ip mobile advertise command:
Router# debug ip mobile advertiseMobileIP: Agent advertisement sent out Ethernet1/2: type=16, len=10, seq=1, lifetime=36000,flags=0x1400(rbhFmGv-rsv-),Care-of address: 68.0.0.31Prefix Length ext: len=1 (8 )FA Challenge value:769C808DTable 142 describes the significant fields shown in the display.
The following is sample output from the debug ip mobile host command:
Router# debug ip mobile hostMobileIP: HA received registration for MN 20.0.0.6 on interface Ethernet1 using COA68.0.0.31 HA 66.0.0.5 lifetime 30000 options sbdmgvTMobileIP: Authenticated FA 68.0.0.31 using SPI 110 (MN 20.0.0.6)MobileIP: Authenticated MN 20.0.0.6 using SPI 300MobileIP: HA accepts registration from MN 20.0.0.6MobileIP: Mobility binding for MN 20.0.0.6 updatedMobileIP: Roam timer started for MN 20.0.0.6, lifetime 30000MobileIP: MH auth ext added (SPI 300) in reply to MN 20.0.0.6MobileIP: HF auth ext added (SPI 220) in reply to MN 20.0.0.6MobileIP: HA sent reply to MN 20.0.0.6The following is sample output from the debug ip mobile redundancy command. In this example, the active home agent receives a registration request from mobile node 20.0.0.2 and sends a binding update to peer home agent 1.0.0.2:
MobileIP:MN 20.0.0.2 - sent BindUpd to HA 1.0.0.2 HAA 20.0.0.1MobileIP:HA standby maint started - cnt 1MobileIP:MN 20.0.0.2 - sent BindUpd id 3780410816 cnt 0 elapsed 0adjust -0 to HA 1.0.0.2 in grp 1.0.0.10 HAA 20.0.0.1In this example, the standby home agent receives a binding update for mobile node 20.0.0.2 sent by the active home agent:
MobileIP:MN 20.0.0.2 - HA rcv BindUpd from 1.0.0.3 HAA 20.0.0.1The following is sample output from the debug ip mobile udp-tunneling command and displays the registration, authentication, and establishment of UDP tunneling of a mobile node (MN) with a foreign agent (FA):
Dec 31 12:34:25.707: UDP: rcvd src=10.10.10.10(434),dst=10.30.30.1(434), length=54Dec 31 12:34:25.707: MobileIP: ParseRegExt type MHAE(32) addr 2000FEEC end 2000FF02Dec 31 12:34:25.707: MobileIP: ParseRegExt skipping 10 to nextDec 31 12:34:25.707: MobileIP: FA rcv registration for MN 10.10.10.10 on Ethernet2/2 using COA 10.30.30.1 HA 10.10.10.100 lifetime 65535 options sbdmg-T-identification C1BC0D4FB01AC0D8Dec 31 12:34:25.707: MobileIP: Ethernet2/2 glean 10.10.10.10 acceptedDec 31 12:34:25.707: MobileIP: Registration request byte count = 74Dec 31 12:34:25.707: MobileIP: FA queued MN 10.10.10.10 in register tableDec 31 12:34:25.707: MobileIP: Visitor registration timer started for MN 10.10.10.10, lifetime 120Dec 31 12:34:25.707: MobileIP: Adding UDP Tunnel req extensionDec 31 12:34:25.707: MobileIP: Authentication algorithm MD5 and 16 byte keyDec 31 12:34:25.707: MobileIP: MN 10.10.10.10 FHAE added to HA 10.10.10.100 using SPI 1000Dec 31 12:34:25.707: MobileIP: FA forwarded registration for MN 10.10.10.10 to HA 10.10.10.100Dec 31 12:34:25.715: UDP: rcvd src=10.10.10.100(434), dst=10.30.30.1(434), length=94Dec 31 12:34:25.715: MobileIP: ParseRegExt type NVSE(134) addr 20010B28 end 20010B6ADec 31 12:34:25.715: MobileIP: ParseRegExt type MN-config NVSE(14) subtype 1 (MN prefix length) prefix length (24)Dec 31 12:34:25.715: MobileIP: ParseRegExt skipping 12 to nextDec 31 12:34:25.715: MobileIP: ParseRegExt type MHAE(32) addr 20010B36 end 20010B6ADec 31 12:34:25.715: MobileIP: ParseRegExt skipping 10 to nextDec 31 12:34:25.715: MobileIP: ParseRegExt type UDPTUNREPE(44) addr 20010B4C end 20010B6ADec 31 12:34:25.715: Parsing UDP Tunnel Reply Extension - length 6Dec 31 12:34:25.715: MobileIP: ParseRegExt skipping 6 to nextDec 31 12:34:25.715: MobileIP: ParseRegExt type FHAE(34) addr 20010B54 end 20010B6ADec 31 12:34:25.715: MobileIP: ParseRegExt skipping 20 to nextDec 31 12:34:25.715: MobileIP: FA rcv accept (0) reply for MN 10.10.10.10 on Ethernet2/3 using HA 10.10.10.100 lifetime 65535Dec 31 12:34:25.719: MobileIP: Authenticating HA 10.10.10.100 using SPI 1000Dec 31 12:34:25.719: MobileIP: Authentication algorithm MD5 and 16 byte keyDec 31 12:34:25.719: MobileIP: Authenticated HA 10.10.10.100 using SPI 1000 and 16 byte keyDec 31 12:34:25.719: MobileIP: HA accepts UDP TunnelingDec 31 12:34:25.719: MobileIP: Update visitor table for MN 10.10.10.10Dec 31 12:34:25.719: MobileIP: Enabling UDP TunnelingDec 31 12:34:25.719: MobileIP: Tunnel0 (MIPUDP/IP) created with src 10.30.30.1 dst 10.10.10.100Dec 31 12:34:25.719: MobileIP: Setting up UDP Keep-Alive Timer for tunnel 10.30.30.1:0 - 10.10.10.100:0 with keep-alive 30Dec 31 12:34:25.719: MobileIP: Starting the tunnel keep-alive timerDec 31 12:34:25.719: MobileIP: ARP entry for MN 10.10.10.10 using 10.10.10.10 inserted on Ethernet2/2Dec 31 12:34:25.719: MobileIP: FA route add 10.10.10.10 successful. Code = 0Dec 31 12:34:25.719: MobileIP: MN 10.10.10.10 added to ReverseTunnelTable of Ethernet2/2 (Entries 1)Dec 31 12:34:25.719: MobileIP: FA dequeued MN 10.10.10.10 from register tableDec 31 12:34:25.719: MobileIP: MN 10.10.10.10 using 10.10.10.10 visiting on Ethernet2/2 Dec 31 12:34:25.719: MobileIP: Reply in for MN 10.10.10.10 using 10.10.10.10, acceptedDec 31 12:34:25.719: MobileIP: registration reply byte count = 84Dec 31 12:34:25.719: MobileIP: FA forwarding reply to MN 10.10.10.10 (10.10.10.10 mac 0060.70ca.f021)Dec 31 12:34:26.095: MobileIP: agent advertisement byte count = 48Dec 31 12:34:26.095: MobileIP: Agent advertisement sent out Ethernet2/2: type=16, len=10, seq=55, lifetime=65535, flags=0x1580(rbhFmG-TU),Dec 31 12:34:26.095: Care-of address: 10.30.30.1Dec 31 12:34:26.719: MobileIP: swif coming up Tunnel0!Dec 31 12:34:35.719: UDP: sent src=10.30.30.1(434), dst=10.10.10.100(434)Dec 31 12:34:35.719: UDP: rcvd src=10.10.10.100(434), dst=10.30.30.1(434), length=32d0The following is sample output from the debug ip mobile udp-tunneling command and displays the registration, authentication, and establishment of UDP tunneling of a MN with a home agent (HA):
Dec 31 12:34:26.167: MobileIP: ParseRegExt skipping 20 to nextDec 31 12:34:26.167: MobileIP: ParseRegExt type UDPTUNREQE(144) addr 2001E762 end 2001E780Dec 31 12:34:26.167: MobileIP: Parsing UDP Tunnel Request Extension - length 6Dec 31 12:34:26.167: MobileIP: ParseRegExt skipping 6 to nextDec 31 12:34:26.167: MobileIP: ParseRegExt type FHAE(34) addr 2001E76A end 2001E780Dec 31 12:34:26.167: MobileIP: ParseRegExt skipping 20 to nextDec 31 12:34:26.167: MobileIP: HA 167 rcv registration for MN 10.10.10.10 on Ethernet2/1 using HomeAddr 10.10.10.10 COA 10.30.30.1 HA 10.10.10.100 lifetime 65535 options sbdmg-T-identification C1BC0D4FB01AC0D8Dec 31 12:34:26.167: MobileIP: NAT detected SRC:10.10.10.50 COA: 10.30.30.1Dec 31 12:34:26.167: MobileIP: UDP Tunnel Request accepted 10.10.10.50:434Dec 31 12:34:26.167: MobileIP: Authenticating FA 10.30.30.1 using SPI 1000Dec 31 12:34:26.167: MobileIP: Authentication algorithm MD5 and 16 byte keyDec 31 12:34:26.167: MobileIP: Authentication algorithm MD5 and truncated keyDec 31 12:34:26.167: MobileIP: Authentication algorithm MD5 and 16 byte keyDec 31 12:34:26.167: MobileIP: Authenticated FA 10.30.30.1 using SPI 1000 and 16 byte keyDec 31 12:34:26.167: MobileIP: Authenticating MN 10.10.10.10 using SPI 1000Dec 31 12:34:26.167: MobileIP: Authentication algorithm MD5 and 16 byte keyDec 31 12:34:26.167: MobileIP: Authentication algorithm MD5 and truncated keyDec 31 12:34:26.167: MobileIP: Authentication algorithm MD5 and 16 byte keyDec 31 12:34:26.167: MobileIP: Authenticated MN 10.10.10.10 using SPI 1000 and 16 byte keyDec 31 12:34:26.167: MobileIP: Mobility binding for MN 10.10.10.10 createdDec 31 12:34:26.167: MobileIP: NAT detected for MN 10.10.10.10. Terminating tunnel on 10.10.10.50Dec 31 12:34:26.167: MobileIP: Tunnel0 (MIPUDP/IP) created with src 10.10.10.100 dst 10.10.10.50Dec 31 12:34:26.167: MobileIP: Setting up UDP Keep-Alive Timer for tunnel 10.10.10.100:0 - 10.10.10.50:0 with keep-alive 30Dec 31 12:34:26.167: MobileIP: Starting the tunnel keep-alive timerDec 31 12:34:26.167: MobileIP: MN 10.10.10.10 Insert route for 10.10.10.10/255.255.255.255 via gateway 10.10.10.50 on Tunnel0Dec 31 12:34:26.167: MobileIP: MN 10.10.10.10 is now roamingDec 31 12:34:26.171: MobileIP: Gratuitous ARPs sent for MN 10.10.10.10 MAC 0002.fca5.bc39Dec 31 12:34:26.171: MobileIP: Mask for address is 24Dec 31 12:34:26.171: MobileIP: HA accepts registration from MN 10.10.10.10Dec 31 12:34:26.171: MobileIP: Dynamic and Static Network Extension Length 0 - 0Dec 31 12:34:26.171: MobileIP: Composed mobile network extension length:0Dec 31 12:34:26.171: MobileIP: Added prefix length vse in replyDec 31 12:34:26.171: MobileIP: Authentication algorithm MD5 and 16 byte keyDec 31 12:34:26.171: MobileIP: MN 10.10.10.10 MHAE added to MN 10.10.10.10 using SPI 1000Dec 31 12:34:26.171: MobileIP: Authentication algorithm MD5 and 16 byte keyDec 31 12:34:26.171: MobileIP: MN 10.10.10.10 FHAE added to FA 10.10.10.50 using SPI 1000Dec 31 12:34:26.171: MobileIP: MN 10.10.10.10 - HA sent reply to 10.10.10.50Dec 31 12:34:26.171: MobileIP: Authentication algorithm MD5 and 16 byte keyDec 31 12:34:26.171: MobileIP: MN 10.10.10.10 HHAE added to HA 10.10.10.3 using SPI 1000Dec 31 12:34:26.175: MobileIP: ParseRegExt type CVSE(38) addr 2000128C end 200012AEDec 31 12:34:26.175: MobileIP: ParseRegExt type HA red. version CVSE(6)Dec 31 12:34:26.175: MobileIP: ParseRegExt skipping 8 to nextDec 31 12:34:26.175: MobileIP: ParseRegExt type HHAE(35) addr 20001298 end 200012AEDec 31 12:34:26.175: MobileIP: ParseRegExt skipping 20 to nextDec 31 12:34:26.175: MobileIP: Authenticating HA 10.10.10.3 using SPI 1000Dec 31 12:34:26.175: MobileIP: Authentication algorithm MD5 and 16 byte keyDec 31 12:34:26.175: MobileIP: Authentication algorithm MD5 and truncated keyDec 31 12:34:26.175: MobileIP: Authentication algorithm MD5 and 16 byte keyDec 31 12:34:26.175: MobileIP: Authenticated HA 10.10.10.3 using SPI 1000 and 16 byte keyDec 31 12:34:27.167: MobileIP: swif coming up Tunnel0d0debug ip mobile advertise
The debug ip mobile advertise command was consolidated with the debug ip mobile command. See the description of the debug ip mobile command in the "Debug Commands" chapter for more information.
To display advertisement information, use the debug ip mobile advertise EXEC command .
debug ip mobile advertise
no debug ip mobile advertise
Syntax Description
This command has no arguments or keywords.
Defaults
No default values.
Command Modes
EXEC mode
Command History
Examples
The following is sample output from the debug ip mobile advertise command. Table 143 describes significant fields shown in the display.
Router# debug ip mobile advertiseMobileIP: Agent advertisement sent out Ethernet1/2: type=16, len=10, seq=1,lifetime=36000,flags=0x1400(rbhFmGv-rsv-),Care-of address: 14.0.0.31Prefix Length ext: len=1 (8 )
debug ip mobile dyn-pbr
To display debugging messages for the mobile IP (MIP) dynamic policy based routing (PBR) mobile router, use the debug ip mobile dyn-pbr command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mobile dyn-pbr
no debug ip mobile dyn-pbr
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Examples
The following sample output from the debug ip mobile dyn-pbr command:
Router# debug ip mobile dyn-pbr*Jan 12 19:50:16.271: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up *Jan 12 19:50:16.271: Looking for path WIFI in rmap MPATH_2 10 *Jan 12 19:50:16.271: Found link_type WIFI, ACL template is VIDEO *Jan 12 19:50:16.271: Set int for link_type WIFI to Tunnel2 *Jan 12 19:50:16.271: MIP-PBR: ACL handle VIDEO-to-192.0.2.0/24 created *Jan 12 19:50:16.271: MIP-PBR: Retrieving ACL forVIDEO-to-192.0.2.0/24*Jan 12 19:50:16.271: template->tos_value = 16 *Jan 12 19:50:16.271: Creating new rmap entry_hdl 104835472 *Jan 12 19:50:16.271: new dyn rmap info added to map_entry->dyn_rmaps*Jan 12 19:50:16.271: map_entry->dyn_rmaps =*Jan 12 19:50:16.271: 104835472, VIDEO-to-192.0.2.0/24*Jan 12 19:50:16.271: MIP-PBR: added route-map entry forVIDEO-to-192.0.2.0/24 via Tunnel2*Jan 12 19:50:16.271: MIP-PBR: Dyn route-map entry added OK on HA *Jan 12 19:50:16.271: MIP-PBR: ACL handle VIDEO-to-192.0.2.32/20 created *Jan 12 19:50:16.271: MIP-PBR: Retrieving ACL forVIDEO-to-192.0.2.32/20*Jan 12 19:50:16.271: template->tos_value = 16 *Jan 12 19:50:16.271: Creating new rmap entry_hdl 84396264 *Jan 12 19:50:16.271: new dyn rmap info added to map_entry->dyn_rmaps*Jan 12 19:50:16.271: map_entry->dyn_rmaps =*Jan 12 19:50:16.271: 104835472, VIDEO-to-192.0.2.0/24*Jan 12 19:50:16.271: 84396264, VIDEO-to-192.0.2.32/20*Jan 12 19:50:16.271: MIP-PBR: added route-map entry forVIDEO-to-192.0.2.32/20 via Tunnel2*Jan 12 19:50:16.271: MIP-PBR: Dyn route-map entry added for home address 192.0.2.32 on HA *Jan 12 19:50:16.271: Looking for path WIFI in rmap MPATH_2 20 *Jan 12 19:50:16.271: Looking for path WIFI in rmap MPATH_2 30 *Jan 12 19:50:16.271: MIP-PBR: MIP-01/12/09-19:46:39.495-1-MP-HA assoc with Ethernet2/0 *Jan 12 19:50:16.271: *Jan 12 19:50:16.271: *Jan 12 19:50:16.271: Looking for path WIFI in rmap MPATH_1 10 *Jan 12 19:50:16.271: Found link_type WIFI, ACL template is VIDEO *Jan 12 19:50:16.271: Set int for link_type WIFI to Tunnel2 *Jan 12 19:50:16.271: MIP-PBR: Using existing dyn acl hdlVIDEO-to-192.0.2.0/24*Jan 12 19:50:16.271: MIP-PBR: After api bind, ACLVIDEO-to-192.0.2.0/24, user_count 3*Jan 12 19:50:16.271: MIP-PBR: current map_entry->dyn_rmaps = 0*Jan 12 19:50:16.271: MIP-PBR: found rmap_info =VIDEO-to-192.0.2.0/24*Jan 12 19:50:16.271: MIP-PBR: Using existing dyn rmap entry104835472*Jan 12 19:50:16.271: MIP-PBR: added route-map entry forVIDEO-to-192.0.2.0/24 via Tunnel2*Jan 12 19:50:16.271: MIP-PBR: Dyn route-map entry added OK on HA *Jan 12 19:50:16.271: MIP-PBR: Using existing dyn acl hdlVIDEO-to-192.0.2.32/20*Jan 12 19:50:16.271: MIP-PBR: After api bind, ACLVIDEO-to-192.0.2.32/20, user_count 3*Jan 12 19:50:16.271: MIP-PBR: current map_entry->dyn_rmaps =63A5320*Jan 12 19:50:16.271: MIP-PBR: found rmap_info =VIDEO-to-192.0.2.32/20*Jan 12 19:50:16.271: MIP-PBR: Using existing dyn rmap entry84396264*Jan 12 19:50:16.271: MIP-PBR: added route-map entry forVIDEO-to-192.0.2.32/20 via Tunnel2*Jan 12 19:50:16.271: MIP-PBR: Dyn route-map entry added for home address 192.0.2.32 on HA *Jan 12 19:50:16.271: Looking for path WIFI in rmap MPATH_1 20 *Jan 12 19:50:16.271: Looking for path WIFI in rmap MPATH_1 30 *Jan 12 19:50:16.271: MIP-PBR: MIP-01/12/09-19:46:39.495-1-MP-HA assoc with Ethernet2/0 *Jan 12 19:50:16.271: *Jan 12 19:50:16.271: *Jan 12 19:50:16.271: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel3, changed state to up *Jan 12 19:50:16.271: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel4, changed state to up *Jan 12 19:50:16.271: Looking for path UMTS in rmap MPATH_2 10 *Jan 12 19:50:16.271: Looking for path UMTS in rmap MPATH_2 20 *Jan 12 19:50:16.271: Found link_type UMTS, ACL template is VOICE *Jan 12 19:50:16.271: Set int for link_type UMTS to Tunnel4 *Jan 12 19:50:16.271: MIP-PBR: ACL handle VOICE-to-192.0.2.0/24 created *Jan 12 19:50:16.271: MIP-PBR: Using existing dyn acl hdlVOICE-to-192.0.2.0/24*Jan 12 19:50:16.271: MIP-PBR: After api bind, ACLVOICE-to-192.0.2.0/24, user_count 3*Jan 12 19:50:16.271: MIP-PBR: current map_entry->dyn_rmaps = 0*Jan 12 19:50:16.271: MIP-PBR: found rmap_info =VOICE-to-192.0.2.0/24*Jan 12 19:50:16.271: MIP-PBR: Using existing dyn rmap entry 84365440 *Jan 12 19:50:16.271: MIP-PBR: added route-map entry forVOICE-to-192.0.2.0/24 via Tunnel4*Jan 12 19:50:16.271: MIP-PBR: Dyn route-map entry added OK on HA *Jan 12 19:50:16.271: MIP-PBR: Using existing dyn acl hdlVOICE-to-192.0.2.32/20*Jan 12 19:50:16.271: MIP-PBR: After api bind, ACLVOICE-to-192.0.2.32/20, user_count 3*Jan 12 19:50:16.271: MIP-PBR: current map_entry->dyn_rmaps =63A4390*Jan 12 19:50:16.271: MIP-PBR: found rmap_info =VOICE-to-192.0.2.32/20*Jan 12 19:50:16.271: MIP-PBR: Using existing dyn rmap entry99337152*Jan 12 19:50:16.271: MIP-PBR: added route-map entry forVOICE-to-192.0.2.32/20 via Tunnel4*Jan 12 19:50:16.271: MIP-PBR: Dyn route-map entry added for home address 192.0.2.32 on HA *Jan 12 19:50:16.271: Looking for path UMTS in rmap MPATH_1 30 *Jan 12 19:50:16.271: MIP-PBR: MIP-01/12/09-19:46:39.495-1-MP-HA assoc with Ethernet2/0 *Jan 12 19:50:16.271: *Jan 12 19:50:16.271:*Jan 12 19:50:16.291: DELETING dyn_rmaps for reg_ptr 6436320:*Jan 12 19:50:16.291: Looking at reg_info: Tunnel2 MPATH_1 10*Jan 12 19:50:16.291: Looking at reg_info: Tunnel2 MPATH_2 10*Jan 12 19:50:16.291: Looking at reg_info: Tunnel2 MPATH_1 10*Jan 12 19:50:16.291: Looking at reg_info: Tunnel2 MPATH_2 10*Jan 12 19:50:16.291: Looking at reg_info: Tunnel4 MPATH_1 20*Jan 12 19:50:16.291: Looking at reg_info: Tunnel4 MPATH_2 20*Jan 12 19:50:16.291: Looking at reg_info: Tunnel4 MPATH_1 20*Jan 12 19:50:16.291: Looking at reg_info: Tunnel4 MPATH_2 20*Jan 12 19:50:16.291: Looking at reg_info: Tunnel2 MPATH_1 10*Jan 12 19:50:16.291: Looking at reg_info: Tunnel2 MPATH_2 10*Jan 12 19:50:16.291: Looking at reg_info: Tunnel2 MPATH_1 10*Jan 12 19:50:16.291: Looking at reg_info: Tunnel2 MPATH_2 10debug ip mobile host
The debug ip mobile host command was consolidated with the debug ip mobile command. See the description of the debug ip mobile command in the "Debug Commands" chapter for more information.
Use the debug ip mobile host EXEC command to display IP mobility events.
debug ip mobile host [[access-list-number]|[nai {NAI username | username@realm}]
no debug ip mobile host [[access-list-number]|[nai {NAI username | username@realm}]
Syntax Description
[access-list-number]
(Optional) The mobile node host.
nai {NAI username | username@realm}
(Optional) Mobile host identified by NAI.
Defaults
No default values.
Command History
Examples
The following is sample output from the debug ip mobile host command:
Router# debug ip mobile hostMobileIP: HA received registration for MN 10.0.0.6 on interface Ethernet1 using COA14.0.0.31 HA 15.0.0.5 lifetime 30000 options sbdmgvTMobileIP: Authenticated FA 15.0.0.31 using SPI 110 (MN 20.0.0.6)MobileIP: Authenticated MN 11.0.0.6 using SPI 300MobileIP: HA accepts registration from MN 11.0.0.6MobileIP: Mobility binding for MN 11.0.0.6 updatedMobileIP: Roam timer started for MN 11.0.0.6, lifetime 30000MobileIP: MH auth ext added (SPI 300) in reply to MN 11.0.0.6MobileIP: HF auth ext added (SPI 220) in reply to MN 11.0.0.6MobileIP: HA sent reply to MN 11.0.0.6debug ip mobile mib
To display debugging messages for mobile networks, use the debug ip mobile mib command in privileged EXEC mode. To disable, use the no form of this command.
debug ip mobile mib
no debug ip mobile mib
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command is useful for customers deploying mobile networks functionality that need to monitor and debug mobile router information via the Simple Network Management Protocol (SNMP).
Set operations (performed from a Network Management System) are supported for mobile network services. While setting the values for MIBs, a set operation may fail. The debug ip mobile mib command allows error messages explaining the failure to be displayed on the console of the home agent .
Examples
The following mobile networks deployment MIB debug messages are displayed only on certain conditions or when a certain condition fails.
Router# debug ip mobile mib! Mobile router is not enabledMIPMIB: Mobile Router is not enabled! Care-of-interface can be set as transmit-only only if its a Serial interfaceMIPMIB: Serial interfaces can only be set as transmit-only! The Care of address can be configured only if foreign agent is runningMIPMIB: FA cannot be started! Check if home agent is activeMIPMIB: HA is not enabled! For mobile router configuration, host configuration must have been done alreadyMIPMIB: MN <address> is not configured! Mobile Network does not match the existing mobile networkMIPMIB: Conflict with existing mobile networks <name>! Mobile router presentMIPMIB: MR <address> is not configured! Static mobile networks can be configured only for single member mobilenetgroupsMIPMIB: MR is part of group <name>, network cannot be configured! If a binding exists for this mobile router, then delete the route for this unconfigured ! mobile networkMIBMIB: Delete static mobile net for MR! Check if its a dynamically registered mobile networknMIPMIB: Mobile network <address mask> is dynamically registered, cannot be removed! Check if the mobile network has already been configured for another groupnMIPMIB: Mobile network already configured for MR! Check if the network has been dynamically registerednMIPMIB: Deleted dynamic mobnet <address mask> for MR <name>! Check if the redundancy group existsMIPMIB: Redundancy group <name> does not exist! CCOA configuration, use primary interface address as the CCoAMIPMIB: No IP address on this interface! CCOA configuration, CCoA address shouldn't be the same as the Home AddressnMIPMIB: Collocated CoA is the same as the Home Address, registrations will fail
debug ip mobile redundancy
The debug ip mobile redundancy command was consolidated with the debug ip mobile command. See the description of the debug ip mobile command in the "Debug Commands" chapter for more information.
Use the debug ip mobile redundancy EXEC command to display IP mobility events.
debug ip mobile redundancy
no debug ip mobile redundancy
Syntax Description
This command has no keywords or arguments.
Defaults
No default values.
Command History
Examples
The following is sample output from the debug ip mobile redundancy command:
Router# debug ip mobile redundancy00:19:21: MobileIP: Adding MN service flags to bindupdate00:19:21: MobileIP: Adding MN service flags 0 init registration flags 100:19:21: MobileIP: Adding a hared version cvse - bindupdate00:19:21: MobileIP: HARelayBindUpdate version number 2MobileIP: MN 14.0.0.20 - sent BindUpd to HA 11.0.0.3 HAA 11.0.0.400:19:21: MobileIP: HA standby maint started - cnt 100:19:21: MobileIP: MN 14.0.0.20 - HA rcv BindUpdAck accept from 11.0.0.3 HAA 11.0.0.400:19:22: MobileIP: HA standby maint started - cnt 1debug ip mobile router
To display debugging messages for the mobile router, use the debug ip mobile router command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mobile router [detail]
no debug ip mobile router [detail]
Syntax Description
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The mobile router operations can be debugged. The following conditions trigger debugging messages:
•
•
•
•
•
Debugging messages are prefixed with "MobRtr" and detail messages are prefixed with "MobRtrX".
Examples
The following is sample output from the debug ip mobile router command:
Router# debug ip mobile routerMobileRouter: New FA 27.0.0.12 coa 27.0.0.12 int Ethernet0/1 MAC 0050.50c1.c8552w2d: MobileRouter: Register reason: isolated2w2d: MobileRouter: Snd reg request agent 27.0.0.12 coa 27.0.0.12 home 9.0.0.1 ha 29.0.0.4 lifetime 36000 int Ethernet0/1 flag sbdmgvt cnt 0 id B496B69C.55E779742w2d: MobileRouter: Status Isolated -> PendingThe following is sample output from the debug ip mobile router detail command:
Router# debug ip mobile router detail1d09h: MobRtr: New agent 20.0.0.2 coa 30.0.0.2 int Ethernet3/1 MAC 00b0.8e35.a0551d09h: MobRtr: Register reason: left home1d09h: MobRtrX: Extsize 18 add 1 delete 01d09h: MobRtrX: Add network 20.0.0.0/8MobileIP: MH auth ext added (SPI 100) to HA 100.0.0.31d09h: MobRtr: Register to fa 20.0.0.2 coa 30.0.0.2 home 100.0.0.1 ha 100.0.0.3 life 120 int Ethernet3/1 flag sbdmgvt cnt 0 id BE804340.447F50A41d09h: MobRtr: Status Isolated -> Pending1d09h: MobRtr: MN rcv accept (0) reply on Ethernet3/1 from 20.0.0.2 lifetime 120MobileIP: MN 100.0.0.3 - authenticating HA 100.0.0.3 using SPI 100MobileIP: MN 100.0.0.3 - authenticated HA 100.0.0.3 using SPI 1001d09h: MobRtr: Status Pending -> Registered1d09h: MobRtr: Add default gateway 20.0.0.2 (Ethernet3/1)1d09h: MobRtr: Add default route via 20.0.0.2 (Ethernet3/1)Related Commands
debug ip mpacket
To display IP multicast packets received and sent, use the debug ip mpacket command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mpacket [vrf vrf-name] [detail | fastswitch] [access-list] [group]
no debug ip mpacket [vrf vrf-name] [detail | fastswitch] [access-list] [group]
Syntax Description
Defaults
The debug ip mpacket command displays all IP multicast packets switched at the process level.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command displays information for multicast IP packets that are forwarded from this router. Use the access-list or group argument to limit the display to multicast packets from sources described by the access list or a specific multicast group.
Use this command with the debug ip packet command to display additional packet information.
Note
Examples
The following is sample output from the debug ip mpacket command:
Router# debug ip mpacket 224.2.0.1IP: s=10.188.34.54 (Ethernet1), d=224.2.0.1 (Tunnel0), len 88, mforwardIP: s=10.188.34.54 (Ethernet1), d=224.2.0.1 (Tunnel0), len 88, mforwardIP: s=10.188.34.54 (Ethernet1), d=224.2.0.1 (Tunnel0), len 88, mforwardIP: s=10.162.3.27 (Ethernet1), d=224.2.0.1 (Tunnel0), len 68, mforwardTable 144 describes the significant fields shown in the display.
Related Commands
debug ip mrm
To display Multicast Routing Monitor (MRM) control packet activity, use the debug ip mrm command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mrm
no debug ip mrm
Syntax Description
This command has no arguments or keywords.
Defaults
Debugging for MRM is not enabled.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug ip mrm command on the different devices:
On Manager
*Feb 28 16:25:44.009: MRM: Send Beacon for group 239.1.1.1, holdtime 86100 seconds*Feb 28 16:26:01.095: MRM: Receive Status Report from 10.1.4.2 on Ethernet0*Feb 28 16:26:01.099: MRM: Send Status Report Ack to 10.1.4.2 for group 239.1.1.1On Test-Sender
MRM: Receive Test-Sender Request/Local trigger from 1.1.1.1 on Ethernet0MRM: Send TS request Ack to 1.1.1.1 for group 239.1.2.3MRM: Send test packet src:2.2.2.2 dst:239.1.2.3 manager:1.1.1.1On Test-Receiver
MRM: Receive Test-Receiver Request/Monitor from 1.1.1.1 on Ethernet0MRM: Send TR request Ack to 1.1.1.1 for group 239.1.2.3MRM: Receive Beacon from 1.1.1.1 on Ethernet0MRM: Send Status Report to 1.1.1.1 for group 239.1.2.3MRM: Receive Status Report Ack from 1.1.1.1 on Ethernet0debug ip mrouting
To display information about activity in the multicast route (mroute) table, use the debug ip mrouting command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mrouting [vrf vrf-name] [rpf-events | timers] [group-address]
no debug ip mrouting [vrf vrf-name] [rpf-events | timers] [group-address]
Command Syntax in Cisco IOS 12.2(33)SXH and Subsequent 12.2SX Releases
debug ip mrouting [vrf vrf-name] [high-availability | rpf-events [group-address] | timers group-address]
no debug ip mrouting [vrf vrf-name] [high-availability | rpf-events [group-address] | timers group-address]
Syntax Description
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
This command indicates when the router has made changes to the mroute table. Use the debug ip pim and debug ip mrouting commands consecutively to obtain additional multicast routing information. In addition, use the debug ip igmp command to learn why an mroute message is being displayed.
This command generates a substantial amount of output. Use the optional group-address argument to limit the output to a single multicast group.
In Cisco IOS 12.2(33)SXH and subsequent 12.2SX releases, the high-availability keyword was added in support of the PIM Triggered Joins feature to monitor HA events in the event of a supervisor engine switchover on a Catalyst 6500 series switch. The PIM Triggered Joins feature is an HA multicast enhancement that improves the reconvergence of mroutes after a supervisor engine switchover on a Catalyst 6500 series switch. After a service engine switchover, all instances of PIM running on the newly active supervisor engine will modify the value of the Generation ID (GenID) that is included in PIM hello messages sent to adjacent PIM neighbors. When an adjacent PIM neighbor receives a PIM hello message on an interface with a new GenID, the PIM neighbor will interpret the modified GenID as an indication that all mroutes states on that interface have been lost. A modified GenID, thus, is utilized as a mechanism to alert all adjacent PIM neighbors that PIM forwarding on that interface has been lost, which then triggers adjacent PIM neighbors to send PIM joins for all (*, G) and (S, G) mroute states that use that interface as an RPF interface.
Examples
The following is sample output from the debug ip mrouting command:
Router# debug ip mrouting 224.2.0.1MRT: Delete (10.0.0.0/8, 224.2.0.1)MRT: Delete (10.4.0.0/16, 224.2.0.1)MRT: Delete (10.6.0.0/16, 224.2.0.1)MRT: Delete (10.9.0.0/16, 224.2.0.1)MRT: Delete (10.16.0.0/16, 224.2.0.1)MRT: Create (*, 224.2.0.1), if_input NULLMRT: Create (224.69.15.0/24, 225.2.2.4), if_input Ethernet0, RPF nbr 224.69.61.15MRT: Create (224.69.39.0/24, 225.2.2.4), if_input Ethernet1, RPF nbr 0.0.0.0MRT: Create (10.0.0.0/8, 224.2.0.1), if_input Ethernet1, RPF nbr 224.0.0.0MRT: Create (10.4.0.0/16, 224.2.0.1), if_input Ethernet1, RPF nbr 224.0.0.0MRT: Create (10.6.0.0/16, 224.2.0.1), if_input Ethernet1, RPF nbr 224.0.0.0MRT: Create (10.9.0.0/16, 224.2.0.1), if_input Ethernet1, RPF nbr 224.0.0.0MRT: Create (10.16.0.0/16, 224.2.0.1), if_input Ethernet1, RPF nbr 224.0.0.0The following lines show that multicast IP routes were deleted from the routing table:
MRT: Delete (10.0.0.0/8, 224.2.0.1)MRT: Delete (10.4.0.0/16, 224.2.0.1)MRT: Delete (10.6.0.0/16, 224.2.0.1)The (*, G) entries are generally created by receipt of an Internet Group Management Protocol (IGMP) host report from a group member on the directly connected LAN or by a Protocol Independent Multicast (PIM) join message (in sparse mode) that this router receives from a router that is sending joins toward the Route Processor (RP). This router will in turn send a join toward the RP that creates the shared tree (or RP tree).
MRT: Create (*, 224.2.0.1), if_input NULLThe following lines are an example of creating an (S, G) entry that shows that an IP multicast packet (mpacket) was received on Ethernet interface 0. The second line shows a route being created for a source that is on a directly connected LAN. The RPF means "Reverse Path Forwarding," whereby the router looks up the source address of the multicast packet in the unicast routing table and determines which interface will be used to send a packet to that source.
MRT: Create (224.69.15.0/24, 225.2.2.4), if_input Ethernet0, RPF nbr 224.69.61.15MRT: Create (224.69.39.0/24, 225.2.2.4), if_input Ethernet1, RPF nbr 0.0.0.0The following lines show that multicast IP routes were added to the routing table. Note the 224.0.0.0 as the RPF, which means the route was created by a source that is directly connected to this router.
MRT: Create (10.9.0.0/16, 224.2.0.1), if_input Ethernet1, RPF nbr 224.0.0.0MRT: Create (10.16.0.0/16, 224.2.0.1), if_input Ethernet1, RPF nbr 224.0.0.0If the source is not directly connected, the neighbor address shown in these lines will be the address of the router that forwarded the packet to this router.
The shortest path tree state maintained in routers consists of source (S), multicast address (G), outgoing interface (OIF), and incoming interface (IIF). The forwarding information is referred to as the multicast forwarding entry for (S, G).
An entry for a shared tree can match packets from any source for its associated group if the packets come through the proper incoming interface as determined by the RPF lookup. Such an entry is denoted as
(*, G). A (*, G) entry keeps the same information a (S, G) entry keeps, except that it saves the rendezvous point address in place of the source address in sparse mode or as 24.0.0.0 in dense mode.Table 145 describes the significant fields shown in the display.
Table 145 debug ip mrouting Field Descriptions
MRT
Multicast route table.
RPF
Reverse Path Forwarding.
nbr
Neighbor.
Related Commands
debug ip mrouting limits
To display debugging information about configured per interface mroute state limiters and bandwidth-based multicast Call Admission Control (CAC) policies, use the debug ip mrouting limits command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip mrouting [vrf vrf-name] limits [group-address]
no debug ip mrouting [vrf vrf-name] limits [group-address]
Syntax Description
.
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
This command may generate a substantial amount of output. Use the optional group-address argument to restrict the output to display only per interface mroute state limiter and bandwidth-based multicast CAC policy events related to a particular multicast group.
Examples
The following output is from the debug ip mrouting limits command. The output displays the following events:
•
•
•
•
•
Router# debug ip mrouting limitsMRL(0): incr-ed acl `rpf-list' to (13 < max 32), [n:0,p:0], (main) GigabitEthernet0/0, (10.41.0.41, 225.30.200.60)MRL(0): decr-ed acl `out-list' to (10 < max 32), [n:0,p:0], (main) GigabitEthernet0/0, (*, 225.40.202.60)MRL(0): Add mroute (10.43.0.43, 225.30.200.60) denied for GigabitEthernet0/2, acl std-list, (16 = max 16)MRL(0): incr-ed limit-acl `rpf-list' to (12 < max 32), cost-acl 'cost-list' cost 2, [n:0,p:0], (main) GigabitEthernet0/0, (10.41.0.41, 225.30.200.60)MRL(0): decr-ed limit-acl `out-list' to (8 < max 32), cost-acl 'cost-list'' cost 2, [n:0,p:0], (main) GigabitEthernet0/0, (*, 225.40.202.60)Related Commands
debug ip msdp
To debug Multicast Source Discovery Protocol (MSDP) activity, use the debug ip msdp command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip msdp [vrf vrf-name] [peer-address | name] [detail] [routes]
no debug ip msdp [vrf vrf-name] [peer-address | name] [detail] [routes]
Syntax Description
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug ip msdp command:
Router# debug ip msdpMSDP debugging is onRouter#MSDP: 224.150.44.254: Received 1388-byte message from peerMSDP: 224.150.44.254: SA TLV, len: 1388, ec: 115, RP: 172.31.3.92MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.92, used EMBGP peerMSDP: 224.150.44.250: Forward 1388-byte SA to peerMSDP: 224.150.44.254: Received 1028-byte message from peerMSDP: 224.150.44.254: SA TLV, len: 1028, ec: 85, RP: 172.31.3.92MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.92, used EMBGP peerMSDP: 224.150.44.250: Forward 1028-byte SA to peerMSDP: 224.150.44.254: Received 1388-byte message from peerMSDP: 224.150.44.254: SA TLV, len: 1388, ec: 115, RP: 172.31.3.111MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.111, used EMBGP peerMSDP: 224.150.44.250: Forward 1388-byte SA to peerMSDP: 224.150.44.250: Received 56-byte message from peerMSDP: 224.150.44.250: SA TLV, len: 56, ec: 4, RP: 205.167.76.241MSDP: 224.150.44.250: Peer RPF check passed for 205.167.76.241, used EMBGP peerMSDP: 224.150.44.254: Forward 56-byte SA to peerMSDP: 224.150.44.254: Received 116-byte message from peerMSDP: 224.150.44.254: SA TLV, len: 116, ec: 9, RP: 172.31.3.111MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.111, used EMBGP peerMSDP: 224.150.44.250: Forward 116-byte SA to peerMSDP: 224.150.44.254: Received 32-byte message from peerMSDP: 224.150.44.254: SA TLV, len: 32, ec: 2, RP: 172.31.3.78MSDP: 224.150.44.254: Peer RPF check passed for 172.31.3.78, used EMBGP peerMSDP: 224.150.44.250: Forward 32-byte SA to peerTable 146 describes the significant fields shown in the display.
Table 146 debug ip msdp Field Descriptions
MSDP
Protocol being debugged.
224.150.44.254:
IP address of the MSDP peer.
Received 1388-byte message from peer
MSDP event.
debug ip msdp resets
To debug Multicast Source Discovery Protocol (MSDP) peer reset reasons, use the debug ip msdp resets command in privileged EXEC mode.
debug ip msdp [vrf vrf-name] resets
Syntax Description
vrf
(Optional) Supports the Multicast Virtual Private Network (VPN) routing and forwarding (VRF) instance.
vrf-name
(Optional) Name assigned to the VRF.
Defaults
No default behavior or values.
Command Modes
Privileged EXEC
Command History
debug ip multicast redundancy
To display information about IP multicast redundancy events, use the debug ip multicast redundancy command in privileged EXEC mode. To disable debugging output for IP multicast redundancy events, use the no form of this command.
debug ip multicast [default-vrf | vrf vrf-name] [group group-address] redundancy [verbose]
no debug ip multicast [default-vrf | vrf vrf-name] [group group-address] redundancy [verbose]
Syntax Description
Command Default
IP multicast events related to all multicast groups and all MVRFs are displayed. Logging events enabled with the verbose keyword are not displayed.
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
Use this command to display IP multicast redundancy events.
This command logs events that are important in verifying nonstop forwarding (NSF) with stateful switchover (SSO) operation for IP multicast. The classes of events logged by debug ip multicast redundancy command include stateful switchover events during a Route Processor (RP) switchover and dynamic synchronization events that occur during steady state operation.
Use the optional verbose keyword to log events that may occur very frequently during normal operation, but which may be useful for tracking in short intervals.
Examples
The following output is from the debug ip multicast redundancy command. The output shows the initial logging messages that display when the system detects an RP switchover.
00:10:33: %REDUNDANCY-3-SWITCHOVER: RP switchover (PEER_DOWN_INTERRUPT)00:10:33: %REDUNDANCY-5-PEER_MONITOR_EVENT: Standby received a switchover (raw-event=PEER_DOWN_INTERRUPT(11))*Aug 7 02:31:28.051: MCAST-HA: Received cf status CHKPT_STATUS_PEER_NOT_READY*Aug 7 02:31:28.063: MCAST-HA: Received cf status CHKPT_STATUS_PEER_NOT_READY*Aug 7 02:31:28.063: MCAST-HA-RF: Status event: status=RF_STATUS_PEER_COMM Op=0 RFState=STANDBY HOT*Aug 7 02:31:28.063: MCAST-HA-RF: Status event: status=RF_STATUS_OPER_REDUNDANCY_MODE_CHANGE Op=0 RFState=STANDBY HOT*Aug 7 02:31:28.063: MCAST-HA-RF: Status event: status=RF_STATUS_REDUNDANCY_MODE_CHANGE Op=0 RFState=STANDBY HOT*Aug 7 02:31:28.063: MCAST-HA-RF: Status event: status=RF_STATUS_PEER_PRESENCE Op=0 RFState=STANDBY HOT*Aug 7 02:31:28.063: MCAST-HA-RF: Status event: status=RF_STATUS_MAINTENANCE_ENABLE Op=0 RFState=ACTIVE-FAST*Aug 7 02:31:28.063: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_ACTIVE_FAST RFState=ACTIVE-FAST*Aug 7 02:31:28.091: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_ACTIVE_DRAIN RFState=ACTIVE-DRAIN*Aug 7 02:31:28.091: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_ACTIVE_PRECONFIG RFState=ACTIVE_PRECONFIG*Aug 7 02:31:28.091: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_ACTIVE_POSTCONFIG RFState=ACTIVE_POSTCONFIG*Aug 7 02:31:28.103: MCAST-HA: Received cf status CHKPT_STATUS_IPC_FLOW_ON*Aug 7 02:31:28.103: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_ACTIVE RFState=ACTIVEThe following output is from the debug ip multicast redundancy command. As interfaces come up on the new active RP, unicast convergence occurs in parallel with multicast route refresh from Protocol Independent Multicast (PIM) neighbors. Unicast convergence is followed by Reverse Path Forwarding (RPF) adjustments to the refreshed mroute information.
*Aug 7 02:31:28.107: MCAST-HA: Triggering unicast convergence notification process handling for MVRF IPv4 default*Aug 7 02:31:28.107: MCAST-HA: Triggering unicast convergence notification process handling for MVRF blue*Aug 7 02:31:28.107: MCAST-HA: Triggering unicast convergence notification process handling for MVRF green*Aug 7 02:31:28.107: MCAST-HA: Triggering unicast convergence notification process handling for MVRF red*Aug 7 02:31:28.107: MCAST-HA: Triggering unicast convergence notification process handling for all MVRFs*Aug 7 02:31:28.111: MCAST-HA: Beginning unicast convergence notification process handling.*Aug 7 02:31:28.111: MCAST-HA: Unicast convergence completed for MVRF IPv4 default: Triggering RPF updates*Aug 7 02:31:28.111: MCAST-HA: Beginning unicast convergence notification process handling.*Aug 7 02:31:28.111: MCAST-HA: Unicast convergence completed for MVRF blue: Triggering RPF updates*Aug 7 02:31:28.111: MCAST-HA: Beginning unicast convergence notification process handling.*Aug 7 02:31:28.111: MCAST-HA: Unicast convergence completed for MVRF green: Triggering RPF updates*Aug 7 02:31:28.111: MCAST-HA: Beginning unicast convergence notification process handling.*Aug 7 02:31:28.111: MCAST-HA: Unicast convergence completed for MVRF red: Triggering RPF updates*Aug 7 02:31:28.111: MCAST-HA: Unicast convergence notification has been received for the only unconverged VRF.Stopping the unicast routing convergence failsafe timer.*Aug 7 02:31:28.111: MCAST-HA: Beginning unicast convergence notification process handling.*Aug 7 02:31:28.111: MCAST-HA: Unicast convergence notification received for the wildcard tableid (all VRFs).Triggering RPF updates for all MVRFs and stopping the unicast IGP convergence failsafe timer.00:10:34: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 172.16.1.1 on interface Loopback000:10:34: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 172.31.10.1 on interface Loopback100:10:35: %PIM-5-DRCHG: VRF green: DR change from neighbor 0.0.0.0 to 172.16.1.1 on interface Tunnel100:10:35: %PIM-5-DRCHG: VRF red: DR change from neighbor 0.0.0.0 to 172.16.1.1 on interface Tunnel200:10:35: %LINK-3-UPDOWN: Interface Null0, changed state to up00:10:35: %LINK-3-UPDOWN: Interface Loopback0, changed state to up00:10:35: %LINK-3-UPDOWN: Interface Loopback1, changed state to up00:10:35: %LINK-3-UPDOWN: Interface Tunnel0, changed state to up00:10:35: %LINK-3-UPDOWN: Interface Tunnel1, changed state to up00:10:35: %LINK-3-UPDOWN: Interface Tunnel2, changed state to up00:10:35: %LINK-5-CHANGED: Interface Ethernet0/0, changed state to administratively down00:10:35: %LINK-5-CHANGED: Interface Ethernet0/1, changed state to administratively down00:10:35: %LINK-5-CHANGED: Interface Ethernet0/2, changed state to administratively down00:10:35: %LINK-5-CHANGED: Interface Ethernet0/3, changed state to administratively down00:10:35: %LINK-5-CHANGED: Interface Ethernet1/0, changed state to administratively down00:10:35: %LINK-5-CHANGED: Interface Ethernet1/1, changed state to administratively down00:10:35: %LINK-5-CHANGED: Interface Ethernet1/2, changed state to administratively down00:10:35: %LINK-5-CHANGED: Interface Ethernet1/3, changed state to administratively down00:10:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Null0, changed state to up00:10:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up00:10:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to up00:10:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up00:10:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up00:10:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up00:10:38: %PIM-5-DRCHG: VRF blue: DR change from neighbor 0.0.0.0 to 172.16.1.1 on interface Tunnel0The following output is from the debug ip multicast redundancy command. After the processing of unicast and multicast route convergence, time is allowed for Internet Group Management Protocol (IGMP) reporting. After this processing completes, the control plane waits for the NSF holdoff time period to terminate. The refreshed multicast control plane information is then downloaded to the forwarding plane; once completed, the stale multicast forwarding plane information is subsequently flushed.
*Aug 7 02:31:43.651: MCAST-HA: IGMP response timer expired. Ready for DDE replay for MVRF red*Aug 7 02:31:43.651: MCAST-HA: Sending DDE replay request for MVRF red.*Aug 7 02:31:43.651: MCAST-HA: MFIB DDE replay completed for mvrf red*Aug 7 02:31:43.651: MCAST-HA: No NSF Holdoff extension requested for mvrf red at completion of DDE replay.*Aug 7 02:31:43.651: MCAST-HA: Terminating multicast NSF holdoff for MVRF red*Aug 7 02:31:43.651: MCAST-HA: Still awaiting MFIB DDE replay for mvrf greenDDE replay: NOT COMPLETED, MRIB update: NOT PENDING*Aug 7 02:31:43.651: MCAST-HA: IGMP response timer expired. Ready for DDE replay for MVRF green*Aug 7 02:31:43.651: MCAST-HA: Sending DDE replay request for MVRF green.*Aug 7 02:31:43.651: MCAST-HA: MFIB DDE replay completed for mvrf green*Aug 7 02:31:43.651: MCAST-HA: No NSF Holdoff extension requested for mvrf green at completion of DDE replay.*Aug 7 02:31:43.651: MCAST-HA: Terminating multicast NSF holdoff for MVRF green*Aug 7 02:31:43.651: MCAST-HA: Still awaiting MFIB DDE replay for mvrf blueDDE replay: NOT COMPLETED, MRIB update: NOT PENDING*Aug 7 02:31:43.651: MCAST-HA: IGMP response timer expired. Ready for DDE replay for MVRF blue*Aug 7 02:31:43.651: MCAST-HA: Sending DDE replay request for MVRF blue.*Aug 7 02:31:43.651: MCAST-HA: MFIB DDE replay completed for mvrf blue*Aug 7 02:31:43.651: MCAST-HA: No NSF Holdoff extension requested for mvrf blue at completion of DDE replay.*Aug 7 02:31:43.651: MCAST-HA: Terminating multicast NSF holdoff for MVRF blue*Aug 7 02:31:43.651: MCAST-HA: Still awaiting MFIB DDE replay for mvrf IPv4 defaultDDE replay: NOT COMPLETED, MRIB update: NOT PENDING*Aug 7 02:31:43.651: MCAST-HA: IGMP response timer expired. Ready for DDE replay for MVRF IPv4 default*Aug 7 02:31:43.651: MCAST-HA: Sending DDE replay request for MVRF IPv4 default.*Aug 7 02:31:43.651: MCAST-HA: MFIB DDE replay completed for mvrf IPv4 default*Aug 7 02:31:43.651: MCAST-HA: No NSF Holdoff extension requested for mvrf IPv4 default at completion of DDE replay.*Aug 7 02:31:43.651: MCAST-HA: Terminating multicast NSF holdoff for MVRF IPv4 default*Aug 7 02:31:43.651: MCAST-HA: MFIB DDE replay completed for all MVRFs.*Aug 7 02:31:43.651: MCAST-HA: Stopping the MFIB DDE replay failsafe timer.*Aug 7 02:32:13.651: MCAST-HA: Flush timer expired. Starting final RPF check for MVRF IPv4 default*Aug 7 02:32:13.651: MCAST-HA: Flush timer expired. Starting final RPF check for MVRF blue*Aug 7 02:32:13.651: MCAST-HA: Flush timer expired. Starting final RPF check for MVRF green*Aug 7 02:32:13.651: MCAST-HA: Flush timer expired. Starting final RPF check for MVRF red*Aug 7 02:32:14.151: MCAST-HA: Flushing stale mcast state. RP failover processing complete for MVRF IPv4 default.*Aug 7 02:32:14.151: MCAST-HA: Flushing stale mcast state. RP failover processing complete for MVRF blue.*Aug 7 02:32:14.151: MCAST-HA: Flushing stale mcast state. RP failover processing complete for MVRF green.*Aug 7 02:32:14.151: MCAST-HA: Flushing stale mcast state. RP failover processing complete for MVRF red.*Aug 7 02:32:14.151: MCAST-HA: RP failover processing complete for all MVRFs.The following is sample output from the debug ip multicast redundancy command. This output shows the events related to the reloading of the standby RP, in particular, ISSU negotiation between the active and standby RP and synchronization of dynamic multicast forwarding information from the active RP to the standby RP. Synchronization events are also logged in steady state for events that occur which affect dynamic group-to-RP mapping information or dynamic tunnel state.
00:11:50: %HA-6-MODE: Operating RP redundancy mode is SSO*Aug 7 02:32:45.435: MCAST-HA-RF: Status event: status=RF_STATUS_OPER_REDUNDANCY_MODE_CHANGE Op=7 RFState=ACTIVE*Aug 7 02:32:45.435: MCAST-HA-RF: Status event: status=RF_STATUS_REDUNDANCY_MODE_CHANGE Op=7 RFState=ACTIVE*Aug 7 02:32:45.435: MCAST-HA-RF: Status event: status=RF_STATUS_PEER_PRESENCE Op=1 RFState=ACTIVE*Aug 7 02:32:45.463: MCAST-HA-RF: Status event: status=RF_STATUS_PEER_COMM Op=1 RFState=ACTIVE*Aug 7 02:32:45.563: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_ISSU_NEGOTIATION RFState=ACTIVE*Aug 7 02:32:46.039: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_PLATFORM_SYNC RFState=ACTIVE*Aug 7 02:32:46.979: MCAST-HA: Received cf status CHKPT_STATUS_PEER_READY*Aug 7 02:32:46.979: MCAST-ISSU Handling communication up transition for PIM HA transport type 0, RF comm = TRUE, renegotiation NOT PENDING*Aug 7 02:32:46.979: MCAST-HA: Received cf status CHKPT_STATUS_IPC_FLOW_ON*Aug 7 02:32:47.043: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_STANDBY_ISSU_NEGOTIATION_LATE RFState=ACTIVE*Aug 7 02:32:50.943: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_STANDBY_CONFIG RFState=ACTIVE*Aug 7 02:32:50.947: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.947: MCAST-HA-RF: Started PIM ISSU negotiation on the primary RP.*Aug 7 02:32:50.947: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.947: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.951: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.951: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.951: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.951: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.955: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.955: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.955: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.955: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.959: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.959: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.959: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.959: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.959: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.963: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.963: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.963: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.963: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.967: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.967: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.967: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.967: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.967: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.971: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.971: MCAST-ISSU Negotiation message sent from primary, rc = 0*Aug 7 02:32:50.971: MCAST-ISSU Negotiation completed for PIM Checkpoint Facility client, negotation rc = 4, negotiation result = COMPATIBLE*Aug 7 02:32:59.927: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_STANDBY_FILESYS RFState=ACTIVE*Aug 7 02:32:59.963: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_STANDBY_BULK RFState=ACTIVE*Aug 7 02:32:59.963: MCAST-HA-RF: Starting Bulk Sync.*Aug 7 02:32:59.963: MCAST-HA: Successfully created the bulk sync process*Aug 7 02:32:59.963: MCAST-HA: Starting Bulk sync*Aug 7 02:32:59.963: MCAST HA Executing RP mapping bulk sync.*Aug 7 02:32:59.963: MCAST HA Executing Bidir RP route bulk sync.*Aug 7 02:32:59.963: MCAST HA Executing BSR cache bulk sync.*Aug 7 02:32:59.963: MCAST-HA BSR cache sync request received for mvrf IPv4 default*Aug 7 02:32:59.963: MCAST-HA: Creating Bootstrap cache sync request chunk size=112 max=585 align=8*Aug 7 02:32:59.963: MCAST-HA: Allocating Bootstrap cache sync request sync request*Aug 7 02:32:59.963: MCAST-HA Formatting BSR cache sync message:search for mvrf IPv4 default result is 0 mvrf at 0x4A21680*Aug 7 02:32:59.971: MCAST-HA BSR cache sync request received for mvrf blue*Aug 7 02:32:59.971: MCAST-HA: Allocating Bootstrap cache sync request sync request*Aug 7 02:32:59.971: MCAST-HA Formatting BSR cache sync message:search for mvrf blue result is 0 mvrf at 0x50EE660*Aug 7 02:32:59.983: MCAST-HA BSR cache sync request received for mvrf green*Aug 7 02:32:59.983: MCAST-HA: Allocating Bootstrap cache sync request sync request*Aug 7 02:32:59.983: MCAST-HA Formatting BSR cache sync message:search for mvrf green result is 0 mvrf at 0x5103300*Aug 7 02:32:59.991: MCAST-HA BSR cache sync request received for mvrf red*Aug 7 02:32:59.991: MCAST-HA: Allocating Bootstrap cache sync request sync request*Aug 7 02:32:59.991: MCAST-HA Formatting BSR cache sync message:search for mvrf red result is 0 mvrf at 0x5135FE0*Aug 7 02:33:00.003: MCAST HA Executing AutoRP discovery IDB bulk sync.*Aug 7 02:33:00.003: MCAST-HA AutoRP discovery IDB sync request received formvrf IPv4 default*Aug 7 02:33:00.003: MCAST-HA: Creating Autorp discovery IDB sync request chunk size=112 max=585 align=8*Aug 7 02:33:00.003: MCAST-HA: Allocating Autorp discovery IDB sync request sync request*Aug 7 02:33:00.003: MCAST-HA Formatting AutoRP discovery IDB sync message:search for mvrf IPv4 default result is 0 mvrf at 0x4A21680*Aug 7 02:33:00.011: MCAST-HA AutoRP discovery IDB sync request received formvrf blue*Aug 7 02:33:00.011: MCAST-HA: Allocating Autorp discovery IDB sync request sync request*Aug 7 02:33:00.011: MCAST-HA Formatting AutoRP discovery IDB sync message:search for mvrf blue result is 0 mvrf at 0x50EE660*Aug 7 02:33:00.023: MCAST-HA AutoRP discovery IDB sync request received formvrf green*Aug 7 02:33:00.023: MCAST-HA: Allocating Autorp discovery IDB sync request sync request*Aug 7 02:33:00.023: MCAST-HA Formatting AutoRP discovery IDB sync message:search for mvrf green result is 0 mvrf at 0x5103300*Aug 7 02:33:00.031: MCAST-HA AutoRP discovery IDB sync request received formvrf red*Aug 7 02:33:00.031: MCAST-HA: Allocating Autorp discovery IDB sync request sync request*Aug 7 02:33:00.031: MCAST-HA Formatting AutoRP discovery IDB sync message:search for mvrf red result is 0 mvrf at 0x5135FE0*Aug 7 02:33:00.043: MCAST HA Executing dummy bulk sync function.*Aug 7 02:33:00.043: MCAST HA Executing dummy bulk sync function.*Aug 7 02:33:00.043: MCAST HA Executing dummy bulk sync function.*Aug 7 02:33:00.043: MCAST HA Executing MDT tunnel bulk sync.*Aug 7 02:33:00.043: MCAST-HA MDT tunnel sync request received for mvrf blue*Aug 7 02:33:00.043: MCAST-HA: Creating MDT tunnel sync request chunk size=112 max=585 align=8*Aug 7 02:33:00.043: MCAST-HA: Allocating MDT tunnel sync request sync request*Aug 7 02:33:00.043: MCAST-HA Formatting MDT tunnel sync message:search for mvrf blue result is 0 mvrf at 0x50EE660*Aug 7 02:33:00.051: MCAST-HA MDT tunnel sync request received for mvrf green*Aug 7 02:33:00.051: MCAST-HA: Allocating MDT tunnel sync request sync request*Aug 7 02:33:00.051: MCAST-HA Formatting MDT tunnel sync message:search for mvrf green result is 0 mvrf at 0x5103300*Aug 7 02:33:00.063: MCAST-HA MDT tunnel sync request received for mvrf red*Aug 7 02:33:00.063: MCAST-HA: Allocating MDT tunnel sync request sync request*Aug 7 02:33:00.063: MCAST-HA Formatting MDT tunnel sync message:search for mvrf red result is 0 mvrf at 0x5135FE0*Aug 7 02:33:00.071: MCAST HA Executing Bidir RP DF bulk sync.*Aug 7 02:33:00.071: MCAST HA Executing register tunnel bulk sync.*Aug 7 02:33:00.071: MCAST-HA: Completed enqueuing of bulk sync messages.*Aug 7 02:33:00.071: MCAST-HA: Bulk sync message queue has drained.*Aug 7 02:33:00.071: MCAST-HA: Received acknowledgement from standby for all bulk sync messages.*Aug 7 02:33:00.071: MCAST-HA Creating bulk sync completion message for peer.*Aug 7 02:33:00.071: MCAST-HA: Primary has notified standby of bulk sync completion. Waiting for final bulk sync ACK from stby.*Aug 7 02:33:00.075: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK*Aug 7 02:33:00.075: MCAST-HA: Sent message type is 2*Aug 7 02:33:00.075: MCAST-HA Searching for sync request corresponding to the successfully received message.*Aug 7 02:33:00.075: MCAST-HA Transmission from primary and reception by standby confirmed for sync type 2. Cleanup is complete.*Aug 7 02:33:00.075: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK*Aug 7 02:33:00.075: MCAST-HA: Sent message type is 2*Aug 7 02:33:00.075: MCAST-HA Searching for sync request corresponding to the successfully received message.*Aug 7 02:33:00.075: MCAST-HA Transmission from primary and reception by standby confirmed for sync type 2. Cleanup is complete.*Aug 7 02:33:00.075: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK*Aug 7 02:33:00.075: MCAST-HA: Sent message type is 2*Aug 7 02:33:00.075: MCAST-HA Searching for sync request corresponding to the successfully received message.*Aug 7 02:33:00.075: MCAST-HA Transmission from primary and reception by standby confirmed for sync type 2. Cleanup is complete.*Aug 7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK*Aug 7 02:33:00.087: MCAST-HA: Sent message type is 2*Aug 7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the successfully received message.*Aug 7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby confirmed for sync type 2. Cleanup is complete.*Aug 7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK*Aug 7 02:33:00.087: MCAST-HA: Sent message type is 3*Aug 7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the successfully received message.*Aug 7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby confirmed for sync type 3. Cleanup is complete.*Aug 7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK*Aug 7 02:33:00.087: MCAST-HA: Sent message type is 3*Aug 7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the successfully received message.*Aug 7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby confirmed for sync type 3. Cleanup is complete.*Aug 7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK*Aug 7 02:33:00.087: MCAST-HA: Sent message type is 3*Aug 7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the successfully received message.*Aug 7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby confirmed for sync type 3. Cleanup is complete.*Aug 7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK*Aug 7 02:33:00.087: MCAST-HA: Sent message type is 3*Aug 7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the successfully received message.*Aug 7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby confirmed for sync type 3. Cleanup is complete.*Aug 7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK*Aug 7 02:33:00.087: MCAST-HA: Sent message type is 8*Aug 7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the successfully received message.*Aug 7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby confirmed for sync type 8. Cleanup is complete.*Aug 7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK*Aug 7 02:33:00.087: MCAST-HA: Sent message type is 8*Aug 7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the successfully received message.*Aug 7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby confirmed for sync type 8. Cleanup is complete.*Aug 7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK*Aug 7 02:33:00.087: MCAST-HA: Sent message type is 8*Aug 7 02:33:00.087: MCAST-HA Searching for sync request corresponding to the successfully received message.*Aug 7 02:33:00.087: MCAST-HA Transmission from primary and reception by standby confirmed for sync type 8. Cleanup is complete.*Aug 7 02:33:00.087: MCAST-HA: Received cf status CHKPT_STATUS_SEND_OK*Aug 7 02:33:00.087: MCAST-HA: Sent message type is 11*Aug 7 02:33:00.087: MCAST-HA Process: Primary RP received standby ACK for reception of bulk sync completion message.*Aug 7 02:33:00.087: MCAST-HA Notifying RF to continue progression.*Aug 7 02:33:00.087: MCAST-HA: Wakeup received for bulk sync completion.major = 4, minor = 2.*Aug 7 02:33:00.091: MCAST-HA Process: Primary RP received bulk sync completion confirmation from standby.*Aug 7 02:33:00.091: MCAST-HA RF notification previously sent.*Aug 7 02:33:00.455: MCAST-HA-RF: Progression event: RF_Event=RF_PROG_STANDBY_HOT RFState=ACTIVE00:12:05: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED: Bulk Sync succeeded00:12:05: %HA-6-STANDBY_READY: Standby RP in slot 7 is operational in SSO mode00:12:05: %RF-5-RF_TERMINAL_STATE: Terminal state reached for (SSO)debug ip nat
To display information about IP packets translated by the IP Network Address Translation (NAT) feature, use the debug ip nat command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip nat [access-list | detailed | h323 | ipsec | port | pptp | route | sip | skinny | vrf | wlan-nat | multipart]
no debug ip nat [access-list | detailed | h323 | ipsec | port | pptp | route | sip | skinny | vrf | wlan-nat | multipart]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The NAT feature reduces the need for unique, registered IP addresses. It can also save private network administrators from needing to renumber hosts and routers that do not conform to global IP addressing.
Use the debug ip nat command to verify the operation of the NAT feature by displaying information about each packet that the router translates. The debug ip nat detailed command generates a description of each packet considered for translation. This command also displays information about certain errors or exception conditions, such as the failure to allocate a global address. To display messages related to the processing of H.225 signaling and H.245 messages, use the debug ip nat h323 command. To display messages related to the processing of SIP messages, use the debug ip nat sip command. To display messages related to the processing of VRF messages, use the debug ip nat vrf command. To display messages related to the processing of SIP multipart messages, use the debug ip nat vrf command.
Caution
Examples
The following is sample output from the debug ip nat command. In this example, the first two lines show the Domain Name System (DNS) request and reply debugging output. The remaining lines show debugging output from a Telnet connection from a host on the inside of the network to a host on the outside of the network. All Telnet packets, except for the first packet, were translated in the fast path, as indicated by the asterisk (*).
Router# debug ip natNAT: s=192.168.1.95->172.31.233.209, d=172.31.2.132 [6825]NAT: s=172.31.2.132, d=172.31.233.209->192.168.1.95 [21852]NAT: s=192.168.1.95->172.31.233.209, d=172.31.1.161 [6826]NAT*: s=172.31.1.161, d=172.31.233.209->192.168.1.95 [23311]NAT*: s=192.168.1.95->172.31.233.209, d=172.31.1.161 [6827]NAT*: s=192.168.1.95->172.31.233.209, d=172.31.1.161 [6828]NAT*: s=172.31.1.161, d=172.31.233.209->192.168.1.95 [23313]NAT*: s=172.31.1.161, d=172.31.233.209->192.168.1.95 [23325]Table 147 describes the significant fields shown in the display.
The following is sample output from the debug ip nat detailed command. In this example, the first two lines show the debugging output produced by a DNS request and reply. The remaining lines show the debugging output from a Telnet connection from a host on the inside of the network to a host on the outside of the network. In this example, the inside host 192.168.1.95 was assigned the global address 172.31.233.193.
Router# debug ip nat detailedNAT: i: udp (192.168.1.95, 1493) -> (172.31.2.132, 53) [22399]NAT: o: udp (172.31.2.132, 53) -> (172.31.233.193, 1493) [63671]NAT*: i: tcp (192.168.1.95, 1135) -> (172.31.2.75, 23) [22400]NAT*: o: tcp (172.31.2.75, 23) -> (172.31.233.193, 1135) [22002]NAT*: i: tcp (192.168.1.95, 1135) -> (172.31.2.75, 23) [22401]NAT*: i: tcp (192.168.1.95, 1135) -> (172.31.2.75, 23) [22402]NAT*: o: tcp (172.31.2.75, 23) -> (172.31.233.193, 1135) [22060]NAT*: o: tcp (172.31.2.75, 23) -> (172.31.233.193, 1135) [22071]The following is sample output from the debug ip nat h323 command. In this example, an H.323 call is established between two hosts, one host on the inside and the other host on the outside. The debugging output displays the H.323 message names that NAT recognizes and the embedded IP addresses contained in those messages.
Router# debug ip nat h323NAT:H225:[0] processing a Setup messageNAT:H225:[0] found Setup sourceCallSignallingNAT:H225:[0] fix transportAddress addr=192.168.122.50 port=11140NAT:H225:[0] found Setup fastStartNAT:H225:[0] Setup fastStart PDU length:18NAT:H245:[0] processing OpenLogicalChannel message, forward channelnumber 1NAT:H245:[0] found OLC forward mediaControlChannelNAT:H245:[0] fix TransportAddress addr=192.168.122.50 port=16517NAT:H225:[0] Setup fastStart PDU length:29NAT:H245:[0] Processing OpenLogicalChannel message, forward channelnumber 1NAT:H245:[0] found OLC reverse mediaChannelNAT:H245:[0] fix Transportaddress addr=192.168.122.50 port=16516NAT:H245:[0] found OLC reverse mediaControlChannelNAT:H245:[0] fix TransportAddress addr=192.168.122.50 port=16517NAT:H225:[1] processing an Alerting messageNAT:H225:[1] found Alerting fastStartNAT:H225:[1] Alerting fastStart PDU length:25NAT:H245:[1] processing OpenLogicalChannel message, forward channelnumber 1NAT:H323:[0] received pak, payload_len=46NAT:H323:[0] processed up to new_payload_len 4NAT:H323:[0] expecting data len=42--payload_len left 42NAT:H323:[0] try to process tpkt with len 42, payload_len left 42NAT:H225:processing a Facility messageNAT:H225:pdu_len :31 msg_IE:28NAT:H323:choice-value:9NAT:H225:[0] found h245TunnelingNAT:H225:[0] found h245ControlNAT:H225:[0] h245control PDU length:20NAT:H245:[0] processing OpenLogicalChannel message, forward channelnumber 2NAT:H245:[0] found OLC forward mediaControlChannelNAT:H245:[0] fix TransportAddress addr=192.168.122.50 port=51001NAT:H245:[0] TransportAddress addr changed 192.168.122.50->135.25.30.129NAT:H245:[0] message changed, encoding backNAT:H245:exit process tpkt with new_len 20NAT:H225:message changed, encoding backNAT:H323:[0] processed up to new_payload_len 46NAT:H323:[0] new pak payload len is 46Table 148 describes the significant fields shown in the display.
The following is sample output from the debug ip nat ipsec command:
Router# debug ip nat ipsec5d21h:NAT:new IKE going In->Out, source addr 192.168.122.35, destination addr 192.168.22.20, initiator cookie0x9C42065D5d21h:NAT:IPSec:created In->Out ESP translation IL=192.168.122.35 SPI=0xAAE32A0A, IG=192.168.22.40, OL=192.168.22.20,OG=192.168.22.205d21h:NAT:IPSec:created Out->In ESP translation OG=192.168.22.20 SPI=0xA64B5BB6, OL=192.168.22.20, IG=192.168.22.40,IL=192.168.122.355d21h:NAT:new IKE going In->Out, source addr 192.168.122.20, destination addr 192.168.22.20, initiator cookie0xC91738FF5d21h:NAT:IPSec:created In->Out ESP translation IL=192.168.122.20 SPI=0x3E2E1B92, IG=192.168.22.40, OL=192.168.22.20,OG=192.168.22.205d21h:NAT:IPSec:Inside host (IL=192.168.122.20) trying to open an ESP connection to Outside host (OG=192.168.22.20),wait for Out->In reply5d21h:NAT:IPSec:created Out->In ESP translation OG=192.168.22.20 SPI=0x1B201366, OL=192.168.22.20, IG=192.168.22.40,IL=192.168.122.20The following is sample output from the debug ip nat sip command. In this example, one IP phone registers with a Cisco SIP proxy and then calls another IP phone. The debugging output displays the SIP messages that NAT recognizes and the embedded IP addresses contained in those messages.
Router# debug ip nat sipNAT:SIP:[0] processing REGISTER messageNAT:SIP:[0] translated embedded address192.168.122.3->2.2.2.2NAT:SIP:[0] translated embedded address192.168.122.3->2.2.2.2NAT:SIP:[0] message body foundNAT:SIP:[0] found address/port in SDP body:192.168.122.2020332NAT:SIP:[1] processing SIP/2.0 100 Trying reply messageNAT:SIP:[1] translated embedded address2.2.2.2->192.168.122.3NAT:SIP:[1] processing SIP/2.0 200 OK reply messageNAT:SIP:[1] translated embedded address2.2.2.2->192.168.122.3NAT:SIP:[1] translated embedded address2.2.2.2->192.168.122.3NAT:SIP:[1] processing INVITE messageNAT:SIP:[1] translated embedded address2.2.2.2->192.168.122.3NAT:SIP:[1] message body foundNAT:SIP:[1] found address/port in SDP body:192.168.22.20Table 149 describes the significant fields shown in the display.
The following is sample output from the debug ip nat vrf command:
Router# debug ip nat vrf6d00h:NAT:address not stolen for 192.168.121.113, proto 1 port 72246d00h:NAT:creating portlist proto 1 globaladdr 2.2.2.106d00h:NAT:Allocated Port for 192.168.121.113 -> 2.2.2.10:wanted 7224 got 72246d00h:NAT:i:icmp (192.168.121.113, 7224) -> (168.58.88.2, 7224) [2460]6d00h:NAT:s=192.168.121.113->2.2.2.10, d=168.58.88.2 [2460] vrf=> shop6d00h:NAT*:o:icmp (168.58.88.2, 7224) -> (2.2.2.10, 7224) [2460] vrf=> shop6d00h:NAT*:s=168.58.88.2, d=2.2.2.10->192.168.121.113 [2460] vrf=> shop6d00h:NAT:Allocated Port for 192.168.121.113 -> 2.2.2.10:wanted 7225 got 72256d00h:NAT:i:icmp (192.168.121.113, 7225) -> (168.58.88.2, 7225) [2461]6d00h:NAT:s=192.168.121.113->2.2.2.10, d=168.58.88.2 [2461] vrf=> shop6d00h:NAT*:o:icmp (168.58.88.2, 7225) -> (2.2.2.10, 7225) [2461] vrf=> shop6d00h:NAT*:s=168.58.88.2, d=2.2.2.10->192.168.121.113 [2461] vrf=> shop6d00h:NAT:Allocated Port for 192.168.121.113 -> 2.2.2.10:wanted 7226 got 72266d00h:NAT:i:icmp (192.168.121.113, 7226) -> (168.58.88.2, 7226) [2462]6d00h:NAT:s=192.168.121.113->2.2.2.10, d=168.58.88.2 [2462] vrf=> shopTable 150 describes the significant fields shown in the display.
The following is sample output from the debug ip nat wlan-nat command:
Router# debug ip nat wlan-natWLAN-NAT: Creating secure ARP entry (10.1.1.1,0010.7bc2.9ff6)WLAN-NAT: Triggered Acct Start for (171.1.1.10,0010.7bc2.9ff6)WLAN-NAT: Extracting addr:171.1.1.10,input_idb:Ethernet1/2 from pakWLAN-NAT: Saving address:171.1.1.10,input_idb:Ethernet1/2 in pakAfter the WLAN-entry times out, the following debugs will be seen:
Router# debug ip nat wlan-natWLAN-NAT: Removing secure arp entry (10.1.1.1,0010.7bc2.9ff6)WLAN-NAT: triggered Acct Stop for (171.1.1.10,0010.7bc2.9ff6)Table 151 describes the significant fields shown in the display.
Table 151 debug ip nat wlan-nat Field Descriptions
WLAN
Indicates that a wireless LAN is being translated.
NAT
Indicates that the packet is being translated using NAT.
Related Commands
debug ip ospf adj
To display information on adjacency events related to Open Shortest Path First (OSPF), such as packets being dropped due to TTL security check, use the debug ip ospf adj command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip ospf adj
no debug ip ospf adj
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC (#)
Command History
Examples
The following is sample output from the debug ip ospf adj command:
Router# debug ip ospf adjJan 31 00:13:05.175: OSPF: Drop packet on Serial2/0 from 10.1.1.1 with TTL: 1Mar 27 23:15:03.175: OSPF Drop packet on OSPF_VL0 from 10.1.1.100 with TTL: 253Information in the output includes the day and time the packet was dropped, protocol name, interface on which the packet was dropped, neighbor address, and TTL hop count.
Related Commands
debug ip ospf events
Displays information on OSPF-related events, such as adjacencies, flooding information, designated router selection, and SPF calculation.
debug ip ospf database-timer rate-limit
To display when link-state advertisement (LSA) rate-limiting timers will expire, use the debug ip ospf database-timer rate-limit command in privileged EXEC mode.
debug ip ospf database-timer rate-limit [access-list-number]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use this command if you need to see when the timers will expire per LSA. Use an access list if you want to limit the output.
Examples
The following is sample output from the debug ip ospf database-timer rate-limit command for an example configuration that includes the timers throttle lsa all 100 10000 45000 command. Comments are inserted to explain the preceding output.
Router# debug ip ospf database-timer rate-limitOSPF rate limit timer events debugging is on*Mar 12 20:18:20.383:OSPF:Starting rate limit timer for 10.10.24.410.10.24.4 1 with 100ms delayThe interface is shut down, which causes OSPF to generate a new router LSA. The system starts a timer for 100 milliseconds.
*Mar 12 20:18:20.495:OSPF:Rate limit timer is expired for 10.10.24.410.10.24.4 1The rate limit timer is expired after 100 milliseconds (a small delta is added to the timer).
*Mar 12 20:18:20.495:OSPF:For next LSA generation - wait :10000ms next:20000ms*Mar 12 20:18:20.495:OSPF:Build router LSA for area 24, router ID10.10.24.4, seq 0x80000003The system will generate update a router LSA after the timer expires.
debug ip ospf events
To display information on Open Shortest Path First (OSPF)-related events, such as adjacencies, flooding information, designated router selection, and shortest path first (SPF) calculation, use the debug ip ospf events command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip ospf events
no debug ip ospf events
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is sample output from the debug ip ospf events command:
Router# debug ip ospf eventsOSPF:hello with invalid timers on interface Ethernet0hello interval received 10 configured 10net mask received 255.255.255.0 configured 255.255.255.0dead interval received 40 configured 30The debug ip ospf events output shown might appear if any of the following situations occurs:
•
•
