ā11-27-2013 11:59 AM
VLAN marking of mirrored traffic - Edge only
set vlan create<
mirror VLAN ID>
set mirror vlan<
mirror VLAN ID>
set port mirroring create<
source port a> <
monitor port to consolidator>
set port mirroring create<
source port b> <
same monitor port>
set port mirroring create<
source port c> <
same monitor port>
set port mirroring create<
source port d> <
same monitor port>
set port mirroring create<
source port e> <
same monitor port>
set port mirroring create<
source port f> <
same monitor port>
set port mirroring create<
source port g> <
same monitor port>
set port mirroring create<
source port h> <
same monitor port>
set vlan egress<
mirror VLAN ID> <
same monitor port>
tagged
clear vlan egress<
any other egressing VLANs> <
same monitor port>
set port ingress-filter<
same monitor port>
enable
set vlan interface<
mirror VLAN ID>
create
set port mirror create vtap.0.<
mirror VLAN ID> <
monitor port>
rx
set vlan egress<
mirror VLAN ID> <
same monitor port>
tagged
clear vlan egress<
any other egressing VLANs> <
same monitor port>
set port ingress-filter<
source port>
enable
clear vlan egress<
all egressing VLANs> <
source port>
set policy profile 86 name "Drop Mirror VLAN"
set policy rule 86 vlantag<
mirror VLAN ID>
drop
set policy port<
source port>
86
set gvrp vlan<
mirror VLAN ID>
restricted enable
set port lacp port<
source port>
disable
set spantree portadmin<
source port>
disable
set vlan create...') and then instantiated ('
set mirror vlan...') before the port mirror operation is created/enabled ('
set port mirroring create...'). Release notes state, in the 'Known Restrictions and Limitations / Known Issues' section:
VLAN marking of mirrored traffic - Edge only
Traffic mirrored to a VLAN may contain protocol control traffic, which may be interpreted by a downstream neighbor as legal control frames. Users should disable any protocols (e.g. Spanning Tree) on ISLs that might be affected by this.This is true, and is accommodated in steps II.8-II.9. Release notes state, in the 'Known Restrictions and Limitations / Known Issues' section:
VLAN marking of mirrored traffic - Edge only
MAC addresses will be learned for packets tagged with the mirror VLAN ID. This will prevent the ability to snoop traffic across multiple hops.This is true, and is a key (but not the only) reason why a G/C/B-Series cannot readily be used as a "consolidation switch". The Configuration Guide - at least as of March 2013 - overstates the capabilities of Remote Port Mirroring, concluding with this bullet item:
With the introduction of remote port mirroring; on switches where the mirror VLAN has been configured, any traffic on that VLAN will be flooded on the VLAN. It will never be unicast, even if the source address of the traffic has been learned on the switch.This is untrue, conflicting with the Release Notes item cited above. The functional description is expected to be reworded to better reflect feature operation, though no specific release date for that change has been announced. The Configuration Guide states, in the Remote Port Mirroring section:
With the introduction of remote port mirroring; configured mirror destination ports will NOT lose their switching or routing properties.This is true. With the I/G/D/C/B/A-Series products, typically a mirror monitor port loses its switching and routing properties, making the traffic flow on the monitor port egress-only, so it cannot be simultaneously used to propagate (unmirrored) switched/routed traffic. That is not the case while the '
set mirror VLAN...' command is active. Though a potentially very useful behavior (for example, facilitating remote operation of a network sniffer), for simplicity of explanation in this document it is specifically suppressed (steps I.5-I.6).