Port mirror on 6125G not working

[PieterLauwers]

I'm trying to setup a port mirror on a HP 6125G blade switch, but without much success

I followed the guidelines in

R21xx-HP 6125G & 6125G/XG Network Management and Monitoring Command Reference

I tried the local port mirror and the remote port mirror.

display mirroring-group all
mirroring-group 1:
    type: local
    status: active
    mirroring port:
        GigabitEthernet1/0/5  both
    monitor port: GigabitEthernet1/0/16

From the guide I learned it's a good idea to disable stp and mac learning on the monitor port, so I did:

interface GigabitEthernet1/0/16
 stp disable
 mac-address mac-learning disable

The only traffic that I managed to mirror, was the inbound untagged traffic on a switchport and only when using a local port mirror. The outbound traffic or any VLAN traffic was never seen on the device connected to Gig1/0/16.

Am I doing something wrong?

I noticed there is also a feature called "traffic mirror" that uses the QoS framework to configure (fine grained) packet mirroring. We do have QoS implemented and applied globally (qos apply policy LOCAL_PRIORITY global inbound). Could that interfer with the port mirror feature?

<...>display version
HPE Comware Platform Software
Comware Software, Version 5.20.99, Release 2112P04
Copyright (c) 2010-2016 Hewlett Packard Enterprise Development LP
HPE 6125G Blade Switch uptime is 4 weeks, 2 days, 1 hour, 6 minutes

[Vince-Whirlwind]

Is your Wireshark in promiscuous mode?

[PieterLauwers]

Thanks Vince, your suggestion brought me to the solution. I had to disable SR-IOV.

The server used to monitor the traffic was configured with SR-IOV, a hardware assisted network virtualisation technique. But it looks like capturing with SR-IOV enabled isn't all that easy. I explicitely enabled promiscus mode (ip link set dev eth0 promisc on) and I created a vlan interface for all vlans where I expect traffic (for vlan in 101 201 301 401; do ip link add link eth0 name eth0.$vlan type vlan id $vlan; done). And still a tcpdump wouldn't show the packets.

From the switch counters on the monitor port I could see that packets were actually sent towards the server, so it must be the server who is not reporting the packets.

I disabled SR-IOV and tried again. This time no problems. Maybe it is possible to capture with SR-IOV enabled, but I haven't found out yet.