RSPAN capture with VACL redirect

This is a "new" instrumentation techinque on IOS that combines RSPAN and VACL, with the "redirect" feature coming into play.

! Create an extended ACL to match traffic that needs analysis
ip access-list extended traffic_to_analyze
permit tcp any any eq telnet
permit tcp any eq telnet any
!
! Create new RSPAN VLAN to copy traffic before we filter and capture
vlan 901
remote-span
!
! Define traditional SPAN monitor sessions to mirror all traffic to RSPAN VLAN
Monitor session 3 source interface vlan 100 both
Monitor session 3 destination remote vlan 901
!
! specify SPAN session details - Gi1/24 here goes to an analyzer
monitor session 4 source vlan 901
monitor session 4 destination interface Gi1/24
!
! Define VLAN access map with action redirect which bypasses traditional L2 forwarding
vlan access-map filter1 10
match ip address traffic_to_analyze
action redirect Gi1/24
!
! Apply VACL to RSPAN VLAN
vlan filter filter1 vlan-list 901
!

That's it! You can take a deep breath and relax knowing fully well that all the action is occurring on a copy of the traffic (in VLAN 901 here).

Note that although that this feature is supported generally with 12.2SX releases, this example was tested under 12.2(33)SXH2a

OTV in a nutshell

OTV edge devices (7018s) have two interfaces:
1. Internal facing L2 that functions exactly like any traditional switch with (mac, i/f) mappings in the table.
2. Core facing "join-interface" which connects to the "overlay-network"

Each site has an AED (active edge device) that is responsible for advertising (mac, join-interface-IP) into the overlay-network. All this happens over an multicast control-group (say, 239.1.1.1) that all the AED's join (core-facing, therefore the need for ASM capable core, which we have and support). IS-IS is the underlying link-state protocol which allows the AEDs to advertise their local mac-addresses that they learn from the "internal-facing" L2 segments.

Packet forwarding proceed thusly:

1. If dst mac is local to site, traditional switching with (mac, i/f) path is taken.
2. if dst mac is remote, OTV encapsulates complete L2 header (w/ 802.1q tag but strips off preamble and FCS) into an IP/UDP packet with dst-IP being the remote-AED that advertised the mac. The source is local-AED join-interface IP, and UDP dest port is 8472.
3. Multicast traffic handling is more sophisticated with (DS, DG) where (S,G) is mapped to (DS, DG) and fired off into core network. DS = Delivery Source, DG = Delivery Group. S = Source, G = Group.

VM vMotion:

1. When a VM moves, the mac moves with it.
2. The AED at the new site detects the presence of a mac on the outside (mac, remote-AED-IP) AND now on the inside (mac, i/f)
3. This triggers the AED to advertise the mac into the overlay with metric 0
4. The original site, upon noting this advertisement immediately withdraws its own (mac, join-interface-IP) with a rapid IS-IS LSP on the control-plane.