Netdr is a tool available on a RSP720, Sup720 or Sup32 that allows one to capture packets on the RP or SP inband. The netdr command can be used to capture both Tx and Rx packets in the software switching path. This is not a substitute for ELAM as netdr does not capture packets handled in the hardware forwarding path.
To capture packets on the RP inband, the syntax for the command is
#debug netdr capture ?
acl (11) Capture packets matching an acl
and-filter (3) Apply filters in an and function: all must match
destination-ip-address (10) Capture all packets matching ip dst address
dstindex (7) Capture all packets matching destination index
ethertype (8) Capture all packets matching ethertype
interface (4) Capture packets related to this interface
or-filter (3) Apply filters in an or function: only one must match
rx (2) Capture incoming packets only
source-ip-address (9) Capture all packets matching ip src address
srcindex (6) Capture all packets matching source index
tx (2) Capture outgoing packets only
vlan (5) Capture packets matching this vlan number
Note: To capture packets on the SP inband you would run all the commands from the SP.
Note that several options are available and the numbers in parentheses to the right of each option indicate the order in which the options must be specified. Once the packets are captured they can be displayed with the command
show netdr capture
Using the continuous option, the switch will capture packets on the RP-inband continuously fill the entire capture buffer (4096 packets) and then start to overwrite the buffer in a FIFO fashion.
The tx and rx options will capture packets coming from the MSFC and going to the MSFC respectively.
The and-filter and the or-filter specify that an and or an or will be applied respectively to all of the options that follow. For example, if you use the syntax below, then both option #1 and option #2 must match for the packet to be captured. Similarly, if the or-filter is used either option #1 or option #2 or both must match for the packet to be captuered.
debug netdr and-filter option#1option#2
The interface option is used to capture packets to or from the specified interface. The interface can be either an SVI or a L3 interface on the switch.
The vlan option is used to capture all packets in the specified VLAN. The VLAN specified can also be one of the internal VLANs associated with a L3 interface.
The srcindex and dstindex options are used to capture all packets matching the source ltl and destination ltl indices respectively. Note that the interface option above only allows the capture of packets to or from a L3 interface (SVI or physical). Using the srcindex or dstindex options allows the capture of Tx or Rx packets on a given L2 interface. The srcindex and dstindex options work with either L2 or L3 interface indices.
The ethertype option allows the capture of all packets matching the specified ethertype.
The source-ip-address and destination-ip-address options allow the capture of all packets matching the specified source or destination IP address respectively.
The acl option allows the specification of a numbered ACL in which packets can be matched at L3 or L4.
#debug netdr capture tx
#ping 10.10.10.2 repeat 100
(Ping was successful)
#show netdr capture A total of 105 packets have been captured The capture buffer wrapped 0 times Total capture capacity: 4096 packets
Note that 105 packets were captured indicating packets other than the ICMP echos are captured. This is to be expected since the tx option specifiesall packets transmitted by the MSFC. I have shown only two of the 105 packets captured. The second packet shown can be identified as one of the echo requests from 10.10.10.1 to 10.10.10.2. You can see the source and destination IP addresses in the eight-byte sequence 0A0A0A01 0A0A0A02.
Hi Guys, Any of you had any experience using AMP with the SD-WAN Solution? I've recently been entitled with a Threat Grid Account and since then I'm not able to configure any device that has the security policy with AMP configured. The erro...
Dear Cisco Community, We had troubles with the network connections of some of our users (very low bandwidth when accessing internal resources). After investigation, we've found out that the root cause was the speed (100) and duplex (full duplex) sett...
Hi, I am new here so please ignore my rookie questions and un-orthodox manner.My question is that i am applying a policy on main interface, would it affect the sub-interface as well? There is only one sub-interface under the main interface. conf...
Good day all, May someone please assist with IPSec Tunnels and Routing. Here's the scenario: We have 2 RV110W routers on separate networks. They have separate modems providing internet access so essentially in separate locations. We have created...
We have two remote sites that have servers connecting with them,Both sites are connected through routers (2800,4300) site A subnet is 192.168.10.0/24 and site B subnet is also same 192.168.10.0/24 and site A server Ip is 192.168.10.1/24 and site B server ...