Switches, Hubs, and Modems
1753970 Members
7343 Online
108811 Solutions
New Discussion юеВ

Mirror port not seeing internally sourced outbound traffic

 
yazik
New Member

Mirror port not seeing internally sourced outbound traffic

On our ProCurve 8212, we've setup mirroring of another port on the same switch. The mirror port is used by a Snort-based IDS. The IDS is seeing all inbound traffic fine. The problem is that the IDS is not seeing outbound traffic sourced internal to our network. (aside from a group of servers using ports on the same 8212)

Here is the way our config is setup for this:

--
mirror 1 port L3
interface L1 monitor all both mirror 1
--

From what I've read, this should be doing the trick, but maybe I am missing something.

Has anyone else seen anything like this? Any hints/tips?
3 REPLIES 3
yazik
New Member

Re: Mirror port not seeing internally sourced outbound traffic

I need to clarify - we have multiple VLANs hosted on this 8200 that are trunked out to multiple 5400's.

We're going to try mirroring from the 5400's to the snort box on the 8212. This should be fun. :)
Matt Hobbs
Honored Contributor

Re: Mirror port not seeing internally sourced outbound traffic

The only thing I can think of is the 5400/8200's add a tag to any mirrored traffic. So depending on your host OS / NIC driver on your IDS box, it may be discarding these frames.

To verify that the mirror is working properly, I would use another machine with Wireshark and make the appropriate registry changes if necessary: http://wiki.wireshark.org/CaptureSetup/VLAN
Case Van Horsen
Frequent Advisor

Re: Mirror port not seeing internally sourced outbound traffic

I've seen the following behavior on a 5412zl:

When doing a monitor, the switch makes a copy of the packet as it enters the switch. So any packet that is tagged when it enters the switch, is still tagged when it is sent out the mirror port.

I don't know if Snort can be told to untag the packet but it probably can be.

Wireshark automatically looks inside tagged packets so it decodes the traffic properly. If you look carefully at a packet decode, it will identify the packets with an 802.1q header.

I've reported it to HP but I have no idea if a fix is planned/possible.

casevh