Solved: Gratuitous TCP Traffic

drhague · ‎01-30-2008

I have a 6500 with WS-X6K-SUP2-2GE and MSFC2, IOS v12.1(27b)E3. I have numerous VLANs subnetted in the 10.20.0.0/16 range. The lowest numbered subnet is 10.20.2.0/24 (VLAN2). VLAN1 is shut down. The 6500 is connected to an ABR for WAN connectivity. All routing is OSPF. All my devices are in Area 2.

The problem is, when I put a sniffer on the MAN to WAN interface, I see continuous TCP traffic with a source of 10.20.1.0 and destination addresses that are in my allocated IP address range, but are not configured. The MAC address of 10.20.1.0 is my 6500, and seeing as how the destination addressess do not exist, are sent to the MAC address of the ABR. The capture also shows a TCP header length of 0 bytes (bogus, must be at least 20).

Attached is a single packet.

What's going on here? Any help is appreciated.

Richard Burts · ‎01-30-2008

Dave

You note that the TCP header length is 0. I am not sure that I see that in what you have posted.

You say that the lowest numbered subnet is 12.20.2.0/24 but the source address of the packet is 10.20.1.0 which is lower and would seem to be invalid.

You comment on the source MAC address being your 6500 and the destination MAC being the ABR. If the capture was done on the link between the 6500 and the ABR that would be correct and appropriate.

Your post indicates that the destination address is an address that has not been assigned, so sending IP packets to that address would seem to be invalid. Also the capture shows that the destination port is 0 which would be invalid.

the capture indicates a VLAN ID of 891. Would that be the VLAN of the link between the 6500 and the ABR or would that perhaps be a clue to the VLAN from which this packet originated?

My interpretation is that some host in your network is generating invalid packets. Sometimes behavior like this is a sign that the host is infected with some virus.

HTH

Rick

HTH

Rick

View solution in original post

Richard Burts · ‎01-30-2008

Dave

You note that the TCP header length is 0. I am not sure that I see that in what you have posted.

You say that the lowest numbered subnet is 12.20.2.0/24 but the source address of the packet is 10.20.1.0 which is lower and would seem to be invalid.

You comment on the source MAC address being your 6500 and the destination MAC being the ABR. If the capture was done on the link between the 6500 and the ABR that would be correct and appropriate.

Your post indicates that the destination address is an address that has not been assigned, so sending IP packets to that address would seem to be invalid. Also the capture shows that the destination port is 0 which would be invalid.

the capture indicates a VLAN ID of 891. Would that be the VLAN of the link between the 6500 and the ABR or would that perhaps be a clue to the VLAN from which this packet originated?

My interpretation is that some host in your network is generating invalid packets. Sometimes behavior like this is a sign that the host is infected with some virus.

HTH

Rick

HTH

Rick

paolo bevilacqua · ‎01-31-2008

I concur with Rick, and add that you should be able to see from where the packet are sent with "show mac-address-table address ".

drhague · ‎01-31-2008

I was thinking this must be a rogue host, but the source mac address (00:18:74:1D:05:BC) of every packet is the 6500.

If I do a "sh arp | include 0018.741d.05bc" in the MSFC, it resolves to all 64 layer3 VLAN interfaces I have configured on the MSFC.

If I do a "sh cam 00-18-74-1d-05-bc" on the switch, it points to destination 15/1 (the MSFC), as shown in the snippet below.

VLAN Dest MAC/Route Des [CoS] Destination

---- ------------------ ----- -----------

2 00-18-74-1d-05-bc R# 15/1

5 00-18-74-1d-05-bc R# 15/1

6 00-18-74-1d-05-bc R# 15/1

7 00-18-74-1d-05-bc R# 15/1

BTW: VLAN ID 891 is valid; it is the layer3 link from the 6500 to the ABR.

paolo bevilacqua · ‎01-31-2008

Hi, nothing prevent a virus-driven PC to send packets with source mac of another host, in fact they may do so in the attempt of redirecting traffic from someone else to them.

Now I think the switch prevents the rogue mac to be CAM-addressed to anything else, unfortunately I'm not very good at the switch to tell you which command could help identify where's the zombie, but it should be possibly a security command.

Of course if we're wrong and turn out the switch is actually sourcing this traffic I will stand corrected and apologize for the confusion.

Richard Burts · ‎01-31-2008

Paolo (and Dave)

I believe that there is a different and better explanation of the MAC address. In the original post there is this explanation of where the capture was done:

when I put a sniffer on the MAN to WAN interface,

If the 6500 is forwarding IP packets to the WAN/ABR it will have done a layer 2 header rewrite and the source MAC will be the switch/MSFC. To find the MAC of the real source it will be necessary to find which VLAN on the switch is receiving the packets from the host.

HTH

Rick

HTH

Rick

paolo bevilacqua · ‎01-31-2008

Amen.