Netdr

Netdr is a tool available on the Catalyst 6500 with a 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

Cat6500#debug netdr capture ?
 acl                     (11) Capture packets matching an acl
 and-filter              (3) Apply filters in an and function: all must match
 continuous              (1) Capture packets continuously: cyclic overwrite
 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
 <cr>

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

OPTIONS:

• 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#1 option#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.

EXAMPLES:

For the examples below I have a catalyst 6509 running IOS 12.2(18)SXF9 whose interface G1/1 is connected to a catalyst 3550. Interface G1/1 of the 6509 is configured as a L3 interface with IP address 10.10.10.1/24. Let’s start with the tx option and just set it to capture all Tx packets.

Cat6500#debug netdr capture tx

Now I ping the 3550 connected to interface G1/1 with 3000 packets.

Cat6500#ping 10.10.10.2 repeat 3000

Type escape sequence to abort.
Sending 3000, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<snip>
Success rate is 100 percent (3000/3000), round-trip min/avg/max = 1/1/4 ms

Now we display the captured packets.

Cat6500#show netdr capture
A total of 3005 packets have been captured
The capture buffer wrapped 0 times
Total capture capacity: 4096 packets

------- dump of outgoing inband packet -------
interface NULL, routine draco2_fastsend
dbus info: src_vlan 0x3F1(1009), src_indx 0x102(258), len 0x40(64)
  bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x387(903)
  00020000 03F16800 01020000 40000000 00117F00 00157F00 00100000 03870000
mistral hdr: req_token 0x0(0), src_index 0x102(258), rx_offset 0x74(116)
  requeue 0, obl_pkt 0, vlan 0x3F1(1009)
destmac 00.11.21.B9.B0.C0, srcmac 00.00.00.00.AA.AA, protocol 0800
protocol ip: version 0x04, hlen 0x05, tos 0x00, totlen 46, identifier 8207
  df 0, mf 0, fo 0, ttl 32, src 127.0.0.16, dst 127.0.0.21
    udp src 68, dst 67 len 26 checksum 0xB8BC 

------- dump of outgoing inband packet -------
interface Gi1/1, routine draco2_ibc_soutput
dbus info: src_vlan 0x3FB(1019), src_indx 0x380(896), len 0x76(118)
  bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x0(0)
  00020000 03FB2800 03800000 76000000 00000000 00000000 00000000 00000000
mistral hdr: req_token 0x0(0), src_index 0x380(896), rx_offset 0x30(48)
  requeue 0, obl_pkt 0, vlan 0x0(0)
destmac 00.0C.85.80.D2.80, srcmac 00.D0.04.C5.08.00, protocol 0800
layer 3 data: 45000064 04150000 FF018F6D 0A0A0A01 0A0A0A02 080057B7
              002C0000 00000000 94269240 ABCDABCD ABCDABCD ABCDABCD
              ABCDABCD ABCDABCD 000003FB 00000101 000043FA 0804

Note that 3005 packets were captured indicating packets other than the ICMP echos are captured. This is to be expected since the tx option specifies all packets transmitted by the MSFC. I have shown only two of the 3005 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. We would see something similar using the rx option.

Let’s try to filter out those other packets in the previous capture by specifying the source IP address with the source-ip-address option. Let’s use the address of the 3550 as the source IP address so that we capture the echo replies coming back from the 3550.

Cat6500#debug netdr capture source-ip-address 10.10.10.2

Now I ping the 3550′s address with two echos only.

Cat6500#ping 10.10.10.2 repeat 2

Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 1/1/1 ms

Cat6500#show netdr capture
A total of 2 packets have been captured
The capture buffer wrapped 0 times
Total capture capacity: 4096 packets  

------- dump of incoming inband packet -------
interface Gi1/1, routine draco2_process_rx_packet_inline
dbus info: src_vlan 0x3FB(1019), src_indx 0x0(0), len 0x76(118)
  bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x380(896)
  C0000400 03FB0000 00000000 76000000 00010A0A 0A010A0A 0A020000 03800000
mistral hdr: req_token 0x0(0), src_index 0x0(0), rx_offset 0x76(118)
  requeue 0, obl_pkt 0, vlan 0x3FB(1019)
destmac 00.D0.04.C5.08.00, srcmac 00.0C.85.80.D2.80, protocol 0800
protocol ip: version 0x04, hlen 0x05, tos 0x00, totlen 100, identifier 4045
  df 0, mf 0, fo 0, ttl 255, src 10.10.10.2, dst 10.10.10.1
    icmp type 0, code 0 

------- dump of incoming inband packet -------
interface Gi1/1, routine draco2_process_rx_packet_inline
dbus info: src_vlan 0x3FB(1019), src_indx 0x0(0), len 0x76(118)
  bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x380(896)
  D0000400 03FB0000 00000000 76000000 00010A0A 0A010A0A 0A020000 03800000
mistral hdr: req_token 0x0(0), src_index 0x0(0), rx_offset 0x76(118)
  requeue 0, obl_pkt 0, vlan 0x3FB(1019)
destmac 00.D0.04.C5.08.00, srcmac 00.0C.85.80.D2.80, protocol 0800
protocol ip: version 0x04, hlen 0x05, tos 0x00, totlen 100, identifier 4046
  df 0, mf 0, fo 0, ttl 255, src 10.10.10.2, dst 10.10.10.1
    icmp type 0, code 0

Now we see only two packets captured, both from 10.10.10.2 going to 10.10.10.1 as expected. Note also that the packets are ICMP packets with type 0; ICMP echo reply. We could have used the rx option to capture these echo replies, but again we would have captured other packets as well.

What if you wanted to capture both the echo request and the echo reply for this IP source and destination pair. There are a few different ways you could do this. You could use the source-ip-address and the destination-ip-address options with an or-filter

debug netdr capture or-filter source-ip-address 10.10.10.1 destination-ip-address 10.10.10.1

Unfortunately, the parser does does not allow you to use the same option twice on a given filter. For example, you cannot specify source-ip-address [source1] source-ip-address [source2] following the or-filter. Also note that the default filter is an or-filter so the same capture above could have been achieved using

debug netdr capture source-ip-address 10.10.10.1 destination-ip-address 10.10.10.1

Another way to capture the bidirectional echoes between the same two host is to use the source and destination ltl index of the ingress interface G1/1. The ltl index for G1/1 is 0×0 but is just specified as 0 in the syntax of the debug netdr capture command.

debug netdr capture or-filter srcindex 0 dstindex 0

Again the or-filter could be left off in this scenario.

Another way to do this is to specify the VLAN for the echoes. In this example the ingress interface is a L3 interface, so you have to use the internal VLAN associated with the L3 interface. Use ‘show vlan internal usage’ to determine the VLAN assigned to the interface.

Cat6500#sh vlan internal usage | include Gig
1018 GigabitEthernet5/2
1019 GigabitEthernet1/1

In this case the VLAN for G1/1 is 1019

Cat6500#debug netdr capture vlan 1019       

Cat6500#ping 10.10.10.2 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms

Cat6500#sh netdr cap
A total of 2 packets have been captured
The capture buffer wrapped 0 times
Total capture capacity: 4096 packets

------- dump of outgoing inband packet -------
interface Gi1/1, routine draco2_ibc_soutput
dbus info: src_vlan 0x3FB(1019), src_indx 0x380(896), len 0x76(118)
  bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x0(0)
  00020000 03FB2800 03800000 76000000 00000000 00000000 00000000 00000000
mistral hdr: req_token 0x0(0), src_index 0x380(896), rx_offset 0x30(48)
  requeue 0, obl_pkt 0, vlan 0x0(0)
destmac 00.0C.85.80.D2.80, srcmac 00.D0.04.C5.08.00, protocol 0800
layer 3 data: 45000064 0FCF0000 FF0183B3 0A0A0A01 0A0A0A02 080036AF
              002E0000 00000000 9494B2D8 ABCDABCD ABCDABCD ABCDABCD
              ABCDABCD ABCDABCD 000003FB 00000101 000043FA 0802 

------- dump of incoming inband packet -------
interface Gi1/1, routine draco2_process_rx_packet_inline
dbus info: src_vlan 0x3FB(1019), src_indx 0x0(0), len 0x76(118)
  bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x380(896)
  50000400 03FB0000 00000000 76000000 00010A0A 0A010A0A 0A020000 03800000
mistral hdr: req_token 0x0(0), src_index 0x0(0), rx_offset 0x76(118)
  requeue 0, obl_pkt 0, vlan 0x3FB(1019)
destmac 00.D0.04.C5.08.00, srcmac 00.0C.85.80.D2.80, protocol 0800
protocol ip: version 0x04, hlen 0x05, tos 0x00, totlen 100, identifier 4047
  df 0, mf 0, fo 0, ttl 255, src 10.10.10.2, dst 10.10.10.1
    icmp type 0, code 0

Now we see both the echo request and the reply as expected. I’ll leave it to the reader to come up with other ways to capture this bidirectional traffic.

Each of the filters used above will also capture other traffic, more or less, depending on the filter. For example, if you use the LTL index of G1/1 you will capture all traffic received or transmitted by G1/1, not just echoes between the two host.

NOTES:

1. The acl option appears to be completely broken. If you configure access-list 100 permit ip host 10.10.10.1 host 10.10.10.2 and then use the netdr command debug netdr capture acl 100, it will not just capture packets from 10.10.10.1 to 10.10.10.2. It appears that the filter is wide open and is capturing all packets on the RP inband. In other words, it looks the same as if you configure debug netdr capture.
2. Netdr will capture packets that are bridged to the MSFC when an SVI is configured as part of a bridge-group.