Comware

 View Only
  • 1.  Mirror port not seeing internally sourced outbound traffic

    Posted Mar 13, 2008 09:50 AM
    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?


  • 2.  RE: Mirror port not seeing internally sourced outbound traffic

    Posted Mar 13, 2008 03:09 PM
    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. :)


  • 3.  RE: Mirror port not seeing internally sourced outbound traffic

    Posted Mar 13, 2008 03:53 PM
    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


  • 4.  RE: Mirror port not seeing internally sourced outbound traffic

    Posted Mar 13, 2008 09:28 PM
    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