In this and upcoming posts we’ll discuss the Cisco Web Security Appliance. This is the blog agenda for the upcoming weeks:
Part 1: Introduction
Part 2: Installing
Part 3: Deploying Proxy Services
Part 4: Policies
Part 5: Acceptable use & HTTPS Inspection
Part 6: Authentication
Part 7: Defending malware
In this blog we’ll talk about the product introduction.
The Cisco Web Security Appliance (WSA) is an appliance for securing http, https and ftp traffic from (and to) the internet.
The WSA replaces all, or most of these devices in your network:
As you can see, it’s more than just a regular proxy server.
The internet provides a lot of websites, good websites and bad websites. There are a lot of websites which are not work related for a lot of companies. If you want to limit or block those websites for users, the WSA is the product for you. Limitation can be time based, bandwidth based, user based or category based (79 categories). Road warriors (remote users) can be protected too by Anyconnect security or Web cloud Security, also known as Scansafe.
In previous posts we talked about implementing OTV with ASR routers. OTV is a overlay network to get end-to-end layer 2 connections over a layer 3 (WAN) network. In most implementations is FHRP (First Hop Redundancy Protocol, like HSRP/VRRP) filtering needed. These filters are needed to keep routing in the same datacenter where the traffic originates.
Let’s take another look at the high level design:
When FHRP filtering is active, the Virtual IP (aka.. default gateway for clients) is active in both datacenters. Which means: a packetflow from a server in DC1 is routed on the core switch/router in DC1. If you move (vMotion/ live migrate) that server to DC2, the packetflow is routed on the switch/router in DC2.
If you think this through, the datacenter outgoing trafficflows are efficient: routing will be done on the most nearby router. But… incoming traffic from branch offices is still not efficient: the WAN network does not know where the VM is hosted, so the packets are routed by the normal routing protocols. This could result in inefficient routing: if the IP range is routed to DC1 on the WAN and the VM is hosted in DC2, the Datacenter-Interconnect (OTV) will be used to get the packets to the VM.
We configured a OTV DCI in my previous post and it was working as expected and by design. But during testing of all the VLANs I discovered a problem with HSRP over OTV, but only for 1 specific VLAN. The test results:
A ping from a host in DC1 in VLAN 10 to the HSRP address gives random drops
A ping from a host in DC1 in any VLAN to the HSRP address pings without any problems
Shutdown the SVI of VLAN 10 in DC2, A ping from a host in DC1 in VLAN 10 to the HSRP address without any problems
VLAN 10 is still disabled in DC2, but a host can ping the HSRP address from DC2 to DC1. This should be impossible because of the FHRP filtering
Changing the standby group number (they are the same in DC1 and DC2 to keep the same MAC address) partially solved the problem, but some hosts in DC1 got the HSRP MAC of DC2 in the ARP table. This is not what we want.
Moving the SVI from a 6500 switch to a 3750 switch in DC1, none of the above problems
I still have no idea why this problem only exists for VLAN 10, all other VLANs work as expected but I’ve found a good workaround for this in the configuration guide:
During a project I’ve been working on, we needed to configure OTV on a Cisco ASR. I did write a blog for configuring OTV on a Nexus 7000 before (click here) but the configuration on a Cisco ASR router is a bit different. The used technologies and basic configuration steps are equal, but the syntax is different for a few configuration steps .
Unfortunately, the documentation is not as good as for the Nexus 7000. I’ve found one good configuration guide (here) but this guide isn’t covering all. So, it’s a good reason to write a blog post about the basic OTV configuration on a Cisco ASR router.
As you can see in the diagram, the ASR routers are back-to-back connected. There is no guideline how to connect these routers, as long as there is IP connectivity between them with multicast capabilities and a MTU of atleast 1542 btyes.