fvalcho

tcpdump from the diag shell

Discussion created by fvalcho on Oct 7, 2016
Latest reply on Apr 4, 2018 by fvalcho

     Did you know a super user can capture and view some traffic on a Ciena device? It's true. Though the user won't be able to capture all types of traffic, most frames can be see. I had issues with OAM, there are reasons for this though.  To capture the OAM packets, mirror the port and attach the sniffer.The tcpdump rules are quite extensive, and they work very well in the diag shell.

     The user can either capture the files to a local file (the file is saved to DIR the user is presently logged into; PWD!), or the traffic can be used 'real time'. Watch out for this, because they are situations where the CPU will become over whelmed, so user be ware! The local file format looks like this: "root tcpdump -s 1514 -i 1  -w something.pcap". This file then can be transferred to the local machine and viewed in Wireshark. I use WinSCP to transfer my files, but the user can use anything method they prefer. Here, selected were the1515 max frame size and Interface "1", while "w" is Write".

   HINT: log into the user device in 2 windows (say from SecureCRT) Ue the first window to capture or display you traces, and use the second window to issue commands, such as PING! to captureany ARPs.

     Some rules to follow for using tcpdump - a) you must have diag shell access as a user (the CLI command "diag shell command <string>; EXAMPLE: "diag shell command "root tcpdump -D"  may be used. b) you must proceed the 'tcpdump' command with the 'root' keyword "root tcpdump" etc). c) you can select the Interface to capture data from (to view the I/Fs: "root tcpdump -D") by default it uses ETH0; if ETH0 is not present it will use 'remote'. In either case, when the command is run, the interface is reported to the user screen. d) all the tcpdump rules apply (as far I have been able to apply) so the user can be very selective!

These are some of the switches that can be utilized:

    -i any : Listen on all interfaces just to see if you're seeing any traffic.

    -n : Don't resolve hostnames.

    -nn : Don't resolve hostnames or port names.

    -X : Show the packet's contents in both hex and ASCII.

    -XX : Same as -X, but also shows the ethernet header.

    -v, -vv, -vvv : Increase the amount of packet information you get back.

    -c : Only get x number of packets and then stop.

    -s : Define the snaplength (size) of the capture in bytes. Use -s0 to get everything, unless you are intentionally capturing less.

    -S : Print absolute sequence numbers.

    -e : Get the ethernet header as well.

    -q : Show less protocol information.

    -E : Decrypt IPSEC traffic by providing an encryption key.

 

Here are some examples:

root tcpdump -i 1 - captures EVERYTHING!

root tcpdump -i 6 - capture via Interface 6 (-D) (from the CLI "interface show' and map the I/F with the -D tcpdump switch)

root tcpdump -i 5 -vvv -X -e  - captures with Verbose "v" and Ethernet headers

tcpdump -nnvXSs 0 -c2 icmp

tcpdump host 1.2.3.4

tcpdump net 1.2.3.0/24

tcpdump port 3389 (Ports can be found via the shell command "netstat -l' for example)

root tcpdump -i eth0 -vvv -X -e

root tcpdump -T snmp -i 4 -vvvXe

root tcpdump -i eth0 -vvv -X -e -n icmp6

root tcpdump -i remote -vvv -X -e -n ip6

root tcpdump -vvv dst 10.10.121.73 - (w/ 'ps -ef | grep ntp' diag shell cmd); this IP is the NTP DST server IP.

root tcpdump -v ip and 'ip[8]<2' - bootp/dhcp

root tcpdump -i 4 ether proto 0x806 - ARPs on an I/F from a PING (see HINT)

root tcpdump -i eth0 port 1812 -vvv -X -e - capture Radius pkts perhaps

root tcpdump -i eth0 dst 10.10.121.24 -vvv -XXe -s 1514 - or the Radius DST

 

Outcomes