[c-nsp] finding unicast flooding in Wireshark sniff

[John Gill]

Rogelio,
Are you just the tunnel provider or do you have access to the LAN 
segments on either side?  The easiest way would be to grab a trunk on 
the LAN and just look for non broadcast traffic of course...

If you have some administrative control of the source, you could check 
dst mac against the mac address table pointing into the tunnel.

If you have a list of known addresses and want to check it against the 
trace, that would be more than I have done with wireshark, but I'm sure 
some tshark with command line options / scripting could help.

Regards,
John Gill
cisco


On 7/18/11 8:51 AM, Rogelio wrote:
> I've got several L2TP tunnels hitting a Cisco 7201 and am trying to
> use Wireshark to determine what inside my tunnel responsible  queue
> drops on one of interface responsible for the L2TP termination. I
> inserted a Wireshark laptop in a hub between  the LAC and the LNS, and
> I got a good 24 hour sniff of L2TP traffic.
>
> (A broadcast filter is on the router, so I strongly suspect unicast
> garbage is flooding my L2TP tunnels. I am trying to make a case for a
> good carrier grade switch that supports the UUFB feature)
>
> I'm relatively new to Wireshark and could use some suggestions on how
> to determine what is responsible for the traffic spikes in the IO
> graph.  I sorted the traffic by protocol hierarchy and found 99% of it
> inside the Ethernet / IP section is TCP, so I know that it's
> application level traffic.  I'm hoping to narrow this down a bit more
> and  find the smoking gun.
>
> Any ideas where to start?  I feel like I'm poking around here and
> could use any pointers or suggestions others might have.  Ideally, I
> could make one "find unidentified unicast" filter and scan a big file
> for that characteristic.
>