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.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
