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.

Cisco IOS Easy VPN

Cisco IOS Easy VPN De-mystified

At first, there seems to be nothing “easy” about configuring “Easy VPN” for IOS! But, don’t be alarmed, tenacious technician!

The critical thing to grasp is that this method requires IKE “group2” Diffie-Hellman exchange for a 1024bit modulus. Your VPN server has to have a IKE policy with this enabled.

Also, on the EZ client side, you’ll notice that the ISAKMP policies starting with priority 65515 are used from the client’s perspective. The first one specifies AES, SHA, and Group2. I recommend that you specify a matching policy on the server side first.

The server side configuration is classic remote access VPN type.

You will begin with a “crypto isakmp client configuration group ” and work your way to “crypto isakmp profile” and “crypto ipsec profile” where all the elements are tied together, so that they can be applied to the dynamic map or virtual-template.

Consider:

crypto isakmp client configuration group iosvpn
key cisco50
pool iosvpnpool
acl 144
banner ^CWelcome to R6 IOS remote access VPN ^C

crypto isakmp profile iosvpn
match identity group iosvpn
client authentication list LOCO
isakmp authorization list LOCO
client configuration address respond
virtual-template 20

crypto ipsec transform-set ccie esp-3des esp-sha-hmac

crypto ipsec profile iosvpn
set transform-set ccie
set reverse-route tag 23501
set isakmp-profile iosvpn

aaa new-model
aaa authentication login LOCO local
aaa authorization network LOCO local

ip local pool iosvpnpool 192.168.99.1 192.168.99.10

DMVPN through firewalls in virtual multi-context mode

When you have an ASA running in multi-context mode, you have to pay extra attention to the flow classifier.

Consider:

ccie-asa1/india# packet-tracer input out icmp 192.168.70.1 8 0 10.7.1.2
Result:input-interface: outinput-status: upinput-line-status: upAction: dropDrop-reason: (ifc-classify) Virtual firewall classification failed

Let's work backwards. Here, we are dealing with an external network 192.168.70.0 /24 trying t reach a internal network 10.7.1.0/24 in a "no nat-control" setup. The multi-context ASA here has multiple contexts sharing an outside interface (common in SP and hosting environments).

Here is the challenge:
When a packet arrives at the outside interface destined for a destination inside one of the contexts, how does the firewall know which one to forward to? Without unique mac-addresses, the layer 2 address does not give any clues. The firewall relies on NAT configuration to determine the context.

For example:
In the "ccie-asa1/india" context
static (inside,out) 10.7.1.1 10.7.1.1 netmask 255.255.255.255

Now, the classifier has information to act on the packet is sent to the "india" context.

This behavior is critical to grasp when it comes to configuring DMVPN through the firewall. Here, we have a need to allow IP/47 (GRE) traffic to the 10.7.1.1 address, or IP/50 (ESP) or IP/51 (AH). You can be very specific and allow just the protocol you are using. Don't forget udp/500 and if necessary, udp/4500 for IKE.

ASA - Active/Standby with IPSec

With a pair of ASA appliances, you can configure an active/standby pair with full IPSec support, including remote access VPN failover.

Proceed with configuring the active unit first. Specify the failover addresses for each interface and don't forget to include the "management-only" interface! This is crucial to allow remote access VPN connections to fail over (it took me a while to finally solve this issue, and it is not documented anywhere!)

interface GigabitEthernet 0/1
nameif inside
ip address 10.35.0.1 255.255.255.0 standby 10.35.0.2



failover lan unit primary
failover lan interface failcheck GigabitEthernet1/0
failover key *****
failover replication http
failover link failcheck GigabitEthernet1/0
failover interface ip failcheck 10.10.10.1 255.255.255.0 standby 10.10.10.2
failover

If you wish, you can dedicate an interface to failover "link" for stateful failover purposes. It will need its own IP addressing of course.

On the backup appliance, you need only configure the failover interface(s) and addressing and enable failover.

Cisco IPS - VLAN Groups

With VLAN groups, you can assign specific policies to different sets of VLANs. Here is a practical example. Note that the "group" mode work best when used in-line between two switches.

Switch A (dot1q) <----> Gi0/0 IPS Gi0/1 <----> (dot1q) Switch B

Let's say your trunk carries vlans 600 to 609. You can configure an "interface pair" on the IPS and call it "outside_pair" for example.

Then, proceed to configure VLAN groups -> create a group, specify subinterface "1" and select VLANs 600 to 604. Next, specify subinterface "2" and specify VLANs 605 to 609.

You can apply separate policies to outside_pair.1 (to handle the first 5 VLANs) and outside_pair.2 for the last 5 VLANs.