It is easy to find design and configuration guides about OTV implementations on Nexus 7000 switches, ASR and CSR routers. But it is much harder to find some information about the requirements for your WAN.
Please read my previous blog posts about OTV here, here, here and here. I’ll cover the OTV device configurations in those posts. But for now, lets start with the DCI WAN for OTV.
First of all, there are two OTV deployment options:
The WAN requirements in unicast mode are simple: deliver unicast connectivity between the join interfaces of all OTV edge devices. This is just a simple straight forward configuration, I will not cover this in this blog post.
The multicast deployment is a bit harder to configure and requirements are less easier to find. This blog post will cover the required WAN configuration in a multicast deployment. In this particular scenario, we use dark fiber / DWDM connections as DCI to get a more clear understanding about the requirements and configuration.
First, a drawing to get a view on this deployment scenario:
OTV WAN multicast layout
This blog will provide you with the most easiest way to get your OTV multicast deployment up and running. There are some more finetune options available, but that will not be covered in this blog.
That’s my first word if someone asks me about my trip to Cisco Live Milan 2015 last week. It was my first Cisco Live ever and I really should have been there years and years ago! All those great sessions, a lot of awesome people to have great conversations, meeting a lot of people you know from the community… Cisco Live is the place to be for every Cisco engineer / consultant.
This edition of Cisco Live Europe was in MiCo, Milano. I was really impressed by the size of the event: a lot of people recommend to bring your best walking shoes and I can only confirm this. There are 30 minutes in between sessions and if you’re unlucky, you really need these 30 minutes to find, walk and locate the room of your next session. Another very good impression was the amount of attandees and everything Cisco is doing to make the event as much as comfortable for everyone. You will find Cisco employees on every floor, on every corner to help you with all your questions: where is room x? At what time is lunch? Where is lunch?
In this and other posts we’ll discuss the Cisco Web Security Appliance. This is the blog agenda:
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
This is the 5th part of the series
How can you enforce the Acceptable use?
Acceptable use is mostly defined by Application Visibility Control (AVC). Websites are classified by a URL lookup in the cisco database, based on the URL itself, or a dynamic scan of the website.
To configure this, click Security Services > Acceptable Use Controls
AVC is enabled by default.
HTTPS Inspection (HTTPS Proxy)
It’s getting more important to decrypt HTTPS sessions to check against your policies. You can receive a lot of nasty stuff inside your HTTPS session. But there is one major drawback: the WSA shows the user a SSL certificate of the WSA appliance. In almost all circumstances this certificate wouldn’t match all requirements, so the users receive SSL certificate errors. Make sure your users are familiar with your HTTPS inspection!
How does it works? It’s pretty simple: the WSA creates the HTTPS session to the webserver and creates a new HTTPS session to the user. The responses from the webserver are checked and scanned and deliverd over the new HTTPS session to the user.