Securing Our Switches: The Many Details Of SPAN, VACL + Intro To DHCP Snooping

By default, traffic being received and transmitted will be mirrored, but this can be changed to received traffic only and transmitted traffic only as shown above.

SPAN works fine if the source and destination ports are on the same switch, but realistically, that’s not always going to happen. What if the traffic to be monitored is on one switch, but the only vacant port available is on another switch?

Remote SPAN (RSPAN) is the solution. Both switches will need to be configured for RSPAN, since the switch connected to the PCs will need to send mirrored frames across the trunk. A separate VLAN will be created that will carry only the mirrored frames.

RSPAN configuration is simple, but there are some factors you need to consider when configuring RSPAN:

  • If there were intermediate switches between the two shown in the above example, they would all need to be RSPAN-capable.
  • VTP treats the RSPAN VLAN like any other VLAN. It will be propagated throughout the VTP domain if configured on a VTP server. Otherwise, it’s got to be manually configured on every switch along the intermediate path. VTP Pruning will also prune the RSPAN VLAN under the same circumstances that it would prune a “normal” VLAN.
  • MAC address learning is disabled for the RSPAN VLAN.
  • The source and destination must be defined on both the switch with the source port and the switch connected to the network analyzer, but the commands are not the same on each.

After all that, the configuration is simple! Create the VLAN first, and identify it as the RSPAN VLAN with the remote-span command.

SW2(config)#vlan 30


SW2 is the source switch, and the traffic from ports 0/1 – 0/5 will be monitored and frames mirrored to SW1 via RSPAN VLAN 30.

SW2(config)#monitor session 1 source interface fast 0/1 – 5

SW2(config)#monitor session 1 destination remote ?

vlan Remote SPAN destination RSPAN VLAN

SW2(config)#monitor session 1 destination remote vlan 30 % Incomplete command.

SW2(config)#monitor session 1 destination remote vlan 30 ? reflector-port Remote SPAN reflector port

As you see, naming the RSPAN VLAN here doesn’t finish the job. We now have to define the reflector port, the port that will be copying the SPAN traffic onto the VLAN.

SW2(config)#monitor session 1 desti remote vlan 30 reflector-port fast 0/12

SW1 will receive the mirrored traffic and will send it to a network analyzer on port 0/10.

SW1(config)#monitor session 1 source remote vlan 30

SW1(config)#monitor session 1 destination interface fast 0/10

Source port notes:

  • A source port can be monitored in multiple, simultaneous SPAN sessions.
  • A source port can be part of an Etherchannel.
  • A source port cannot be configured as a destination port.
  • A source port can be any port type – Ethernet, FastEthernet, etc.

Destination port notes:

  • A destination port can be any port type.
  • A destination port can participate in only one SPAN session.
  • A destination port cannot be a source port.
  • A destination port cannot be part of an Etherchannel.
  • A destination port doesn’t participate in STP, CDP, VTP, PaGP, LACP, or DTP.


Even though a VACL will do the actual filtering, an ACL has to be written as well. The ACL will be used to as the match criterion within the VACL.

For example, let’s say we have the subnet /24’s addresses configured on hosts in VLAN 100. The hosts – 3 are not to be allowed to communicate with any other hosts on the VLAN, including each other. An ACL will be written to identify these hosts.

SW2(config)#ip access-list extended NO_123_CONTACT

SW2(config-ext-nacl)#permit ip

Notice that even though the three source addresses named in the ACL are the ones that will not be allowed to communicate with other hosts in the VLAN, the ACL statement is permit, not deny. The deny part is coming!

Now the VLAN access-map will be written, with any traffic matching the ACL to be dropped and all other traffic to be forwarded.

Note that the second access-map clause has no match clause, meaning that any traffic that isn’t affect by clause 10 will be forwarded. That is the VACL equivalent of ending an ACL with “permit any”. If you configure a VACL without a final “action forward” clause as shown below, all traffic that does not match a specific clause in the VACL will be dropped.

SW2(config)# vlan access-map NO_123 10

SW2(config-access-map)# match ip address NO_123_CONTACT

SW2(config-access-map)# action drop

SW2(config-access-map)# vlan access-map NO_123 20

SW2(config-access-map)# action forward

Finally, we’ve got to apply the VACL. We’re not applying it to a specific interface – instead, apply the VACL in global configuration mode. The VLAN to be filtered is specified at the end of the command with the vlanlist option.

SW2(config)# vlan filter NO_123 vlan-list 100

A routing ACL can be applied to a SVI to filter inbound and/or outbound traffic just as you would apply one to a physical interface, but VACLs are not applied in that way – they’re applied in global configuration mode.

On L3 switches, you may run into a situation where there’s a VACL configured, and a “normal” ACL affecting incoming traffic is applied to a routed port that belongs to that same VLAN. In this case, packets entering that VLAN will be matched against the VACL first; if the traffic is allowed to proceed, it will then be matched against the inbound ACL on that port.

DHCP Snooping

DHCP messages received on untrusted interfaces be dropped by the switch, the interface itself will be placed into err-disabled state.