Capture VLAN tags on Wireshark

Only with certain NIC you can capture VLAN ID and 802.1q information, in the following post I will show the necessary steps, on Microsoft Windows, to allow capture this information using Intel NIC.

The tagging frames get stripped out by the driver, however making a registry change can be done in order to see the tags. 

The registry key value depends on the NIC driver:

Adapter Driver	Registry Value
e1g, e1e, e1y	MonitorModeEnabled
e1c, e1d, e1k, e1q, e1r, ixe, ixn, ixt	MonitorMode

My NIC model is: 82567LM Gigabit card, in order to find the adapter driver go to:

Start->Control Panel->Network and Sharing Center

Click on Change adapter settings on the left

Right click on the relevant NIC and choose properties

Click Configure

Choose the Driver tab

Click on Driver Details

In the following window you can see that my NIC type is e1y, so for this NIC I will have to use MonitorModeEnabled registry key.

Now open the registry editor (Start->Run->regedit) and go to:

HKEY_LOCAL_MACHINE

SYSTEM

ControlSet001

Control

Class

{4D36E972-E325-11CE-BFC1-08002BR10318}

Find you NIC folder by looking on the DriverDesc:

Here in my case it was 007, right click on this folder and choose New->DWORD (32-bit) value:

Value name: MonitorModeEnabled

Value data: 1 (Hexadecimal)

The value can be either:

0 - Disabled (Do not store bad packets, Do not store CRCs, Strip 802.1Q vlan tags) 

1 - Enabled (Store bad packets. Store CRCs. Do not strip 802.1Q vlan tags)

Now reboot your machine in order the changes to take effect, start Wireshark and start capture tags!

Resources:
http://www.intel.com/support/network/sb/CS-005897.htm
http://dot1x.blogspot.co.il/2010/03/sniffing-dot1q-tags-with-wireshark.html
 

Fortigate packet capture to pcap file

In Fortinet Fortigate firewall appliance series we can use diagnose sniffer packet command to capture traffic in very similar way to tcpdump.

One of the things that are missing is the option to save or export the data into a file for future investigation; Fortinet has made a workaround for this issue by converting the console output into pcap file using small utility. 

In the following post I will explain how to capture, export and convert traffic from Fortigate FW to pcap file for Wireshark to process:

      1.       Login into the FGT appliance using terminal client (PuTTY or SecureCRT)

      

      2.       If the applicant configured with VDOMs enter the appropriate VDOM where you want to capture the traffic.

FGT# config vdom

FGT(vdom)#edit <VDOM_NAME>

      

      3.       Start logging the current session

3.1   In SecureCRT click File->Log Session, type a name and choose a place to save  the file:

3.2   In PuTTY, on the configuration screen, choose the following:

     4.       Back to the FGT appliance, run the command:

# diagnose sniffer packet <interface> <'filter'> <verbose> <count> a

For example:

# diagnose sniffer packet internal ‘host 192.168.10.1’ 4

Interface - any interface on the appliance or just use ‘any’ for all interfaces

Filter - much the same as with tcpdump/wireshark (see examples)

Verbose -verbose levels in detail:

1: print header of packets
2: print header and data from IP of packets
3: print header and data from Ethernet of packets
4: print header of packets with interface name
5: print header and data from IP of packets with interface name
6: print header and data from Ethernet of packets with interface name

Note that a pcap file need at least verbose level 3

Count – the number of packets to collect before stop capture. This is optional and the capture can be always stopped with CTRL+C

A – This option displays absolute time stamps

Examples:

# diagnose sniffer packet any 'src host 192.168.10.1 and dst host  

  192.168.10.254' 4

# diagnose sniffer packet any 'icmp' 1

# diagnose sniffer packet any 'host 192.168.10.1 and tcp port 80' 6

Match TTL = 1
# diagnose sniffer packet port2 "ip[8:1] = 0x01"

Match Source IP address = 192.168.1.2:
# diagnose sniffer packet internal "(ether[26:4]=0xc0a80102)"

Match Source MAC = 00:09:0f:89:10:ea
# diagnose sniffer packet internal "(ether[6:4]=0x00090f89) and (ether[10:2]=0x10ea)"

Match Destination MAC = 00:09:0f:89:10:ea
# diagnose sniffer packet internal "(ether[0:4]=0x00090f89) and (ether[4:2]=0x10ea)"

Match ARP packets only
# diagnose sniffer packet internal "ether proto 0x0806"

TCP or UDP flags can be addressed using the following:

Match packets with RST flag set:
# diagnose sniffer packet internal "tcp[13] & 4 != 0"

Match packets with SYN flag set:
# diagnose sniffer packet internal "tcp[13] & 2 != 0"

Match packets with SYN-ACK flag set:
# diagnose sniffer packet internal "tcp[13] = 18"

      5.       Stop the logging session (SecureCRT or PuTTY)

      6.       Go to Fortinet site at URL: http://kb.fortinet.com/kb/documentLink.do?externalID=11186&languageId=

And download fgt2eth.pl or fgt2eth.zip utility according to your OS.

      7.       Extract the file fgt2eth.zip 

      8.       Copy the text file, captured using the logging session, into the folder where fgt2eth.exe file  has extracted to.

      9.       Open CMD and go to the folder and run the following command:

Fgt2eth.exe –in <LOG_FILE_NAME> -out <FILENAME.pcap>

      10.   After finishing you will have the pcap file in the utility folder.

Capture the burst in traffic

here is a story about a customer with symmetric 30Mbps MPLS link, which on it he transmit all kind of traffic including voice and video.
After few days the customer starts to complain about packet loss in his voice/video application, with no specific time or event, on the receive direction.
taking a look in the customer's router interface didn't show almost nothing:

GigabitEthernet0/1 is up, line protocol is up
  Hardware is iGbE, address is 4022.22ff.2220 (bia 4022.22ff.2220)
  Internet address is 10.0.0.201/24
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 65/255, rxload 18/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full Duplex, 1Gbps, media type is SX
  output flow-control is unsupported, input flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 1w0d
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 25981268
  Queueing strategy: Class-based queueing
  Output queue: 0/1000/0 (size/max total/drops)
  30 second input rate 7158000 bits/sec, 2225 packets/sec
  30 second output rate 25707000 bits/sec, 2524 packets/sec
     926151472 packets input, 4244873795 bytes, 0 no buffer
     Received 101822 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 100176 multicast, 0 pause input
     1387944109 packets output, 363334323 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     89711 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

beside the fact that there are output drops....
but if the input/output rate is not exceeding the CIR from where does these output drops coming from???

Now the router allows us to define the minimum interface statistics interval to 30 seconds,  we calculate the CIR in megabits per second and the router itself thinks in milliseconds, so we will need to find a way to calculate and to "see" the same way the router sees.

Using Wireshark and SPAN i have done packet capture for few minutes on the receive direction for this interface, after that i ran statistics->IO graphs for analyzing the traffic and at first glance it's seems that now packet loss should occur, all traffic didn't reach over 12Mbps:

note that the tick interval is set to 1 second, now changing it to 0.001msec show a complete different picture...

note how does the Y Axis scale has changed automatically to max of 100Mbps, the spike in the middle shows clearly a traffic burst of more the 70Mbps!!! keep searching along the graph shows a few more spikes like that.

Network devices, using policing/shaping or rate limiting, can't handle these kinds of spikes for that super short period of time and that's the reason i was able to see these spikes on my capture. In order to a police/shape/rate-limit to work the burst should exists for a duration of more then 100msec.

Anyway this was the cause of the packet loss and implementing MQC, on the customer routers, with reservation for video and voice traffic pretty end this  problem.