Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

Too much unicasting going on

Got a cool network analyser and plugged into the closest switch to check it out. I am seeing the expected broadcasts, multicasts, and traffic addressed to the nic in the analyser.

But . . .

I am also seeing bursts of unicast traffic between two devices that should not be on the port. These are usually 5, 10, 12 packets that are very close together - no other packets arrive between the burst. Many times it is a file transfer between a server and client. No port monitoring is turned on. All switch ports are in vlan 1.

I understand switches will flood packets that they don't know where to send. I was not expecting a string of unicasts to be flooded, just the first packet and the response.

Some have suggested this is a symptom of a broke switch.

Any ideas?

8 REPLIES
Community Member

Re: Too much unicasting going on

I have seen problems like that in environments with dual homed servers, or router with secondary ip addressing. Does any of this meet your circumstances?

Anonymous
N/A

Re: Too much unicasting going on

No dual homed servers and no secondary ip addresses. Actually I have a very simple stub network with a static route to my ISP. I have 250 PC's all connected to dedicated L2 switch ports.

Still trying to figure this one out.

Green

Re: Too much unicasting going on

If I understand correctly, you are seeing bursts of traffic between two devices / hosts that do exist on your network, just not connected to the port in which you are seeing their traffic, right?

I have seen on occasion where a loaded switch (operating at or near capacity) will go into "hub mode" and pass all traffic out all ports.

Another possibility: since the traffic is ending up in VLAN 1 / the Native VLAN), which is where traffic will be placed when the switch doesn't know which protocol / VLAN the traffic belongs (it is untagged traffic), perhaps you are seeing traffic from a source that is not defined to the switch or a port that is not defined as part of another VLAN. For example, can you do Dot1q with a Novell-Ether frame type?

What you may be seeing is a print server that is configured to accept Novell print jobs .... something like that.

Are the source and destination MAC addresses in the same VLAN (and usually work OK, but occasionally show up in VLAN 1), or are they on different VLANs connected through a router?

Do the 5, 10, 12 frame bursts constitute a complete transmission (like a print job)?

Does your analyzer identify the frame and packet type? Can you get the associated IP addresses?

What kind of VLAN encaps are you using?

What model of switch is it?

Any additional light you can shed may be helpful.

FWIW

Scott

Community Member

Re: Too much unicasting going on

Do you have asymmetric traffic flow? That is, is traffic to and from a device in question following the same path? If the answer is no, then you will see unicast flooding. The reason is as follows. A switch populates its bridging table by looking at source addresses in frames. If the switch is only used to send the traffic to a device but never sees any traffic from that device, it won't have the in the bridging table, causing it to flood out to all ports. Its rather common in HSRP environments. If you address asymmetric routing, you won't see very many flooeded unicast frames.

Anonymous
N/A

Re: Too much unicasting going on

I have a fairly simple LAN - there is only one path from each device to another. No redundant routes. I am in a stub network with no other locations to connect to. I have one static route to my ISP.

I do have a few links between 4006 and 4003 switches that I have an Etherchannel configured. STP does not have to worry about redundant paths except at the 2 port gig etherchannels.

I have been pretty successful at keeping the peer to peer stuff out of the network. So, traffic should be between clients to servers and back to clients along one possible path.

Please let me know if I misunderstood your question.

Anonymous
N/A

Re: Too much unicasting going on

Your summary is correct.

All traffic is on Vlan1. I am using dot1q to trunk vlans between a few switches that need traffic isolated for security reasons. No routing between vlans. All traffic is 802.2 - no other Novell or Mac frame types.

Switch loading - my most heavly used switch (cat4006) is showing 19% cpu utilization over the last 5 minutes. The switch I am connected to (3500xl) shows 37% cpu utilization over 5 minutes. Will look again at loading when I can catch the problem.

The traffic looks like it is between a Novell server and a client PC. I can identify the server IP address, and the other address is from a DHCP range. All printers have static IP addresses. All servers and clients are pure IP. I catch and stomp out the occasional IPX or DLC frame when someone forgets to turn them off at a print server. I have one vertical application Windows 2000 server box that spews out OSPF advertisements, but no one is ever going to answer.

All vlan encapsulation is dot1q.

I am connected to a 3500xl which is connected to a cat4006. All switches are L2 only. The 4006 has a supervisor engine 2 installed.

This switch is trunking vlans to it. I monitor and work on the different vlans by connecting to different ports.

I am well isolated from the Internet and my users are not very technical. Don't think there is any mac address attacks going on.

Thanks for your suggestions. I'll look a little deeper into the suspect packets to see what they are actually doing.

Community Member

Re: Too much unicasting going on

Hello,

Check the switch cam. If the cam is full, the switch will act as a hub and food packet to all ports.

Regards,

Nadine.

Community Member

Re: Too much unicasting going on

On your router where your VLAN1 lives, make sure IP CEF is turned on and then add this command to the VLAN1 interface (probably FA0/0 or FA0/1 where your gateway is at)

ip verify unicast reverse-path

This feature checks each packet that is routed into the router. If the source IP address does not have a route in the CEF tables that points back to the same interface on which the packet arrived, the router drops the packet. This helps flooding, smurf attacks and other problems....

116
Views
0
Helpful
8
Replies
CreatePlease to create content