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:
- Unicast mode
- Multicast mode
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.
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 3th blog in the series about the proxy configuration.
There are a two proxy modes:
- Explicit Forward Mode
- Transparent Mode
In Explicit Forward Mode the client does have an Proxy configuration. There is no configuration needed on the network infrastructure (routers/switches). Authentication is easy and there are three methods for providing the proxy information:
- Automatic Proxy script
- Enter the proxy server IP address
- Automatic detect settings using WPAD protocol
In transparent mode, there is no configuration needed on the clients. The network infrastructure redirects the traffic (WCCP). Authentication could be an issue.
Redirection options are:
- Web Cache control protocol (WCCP, used in Cisco ASA, ASR and Catalyst switches)
- Policy based routing
- Layer 4 switch
- Layer 7 switch (like a Citrix Netscaler)
WCCP is the most used redirection option for transparant proxies. For more information about WCCP and the configuration, check this link.
PAC files are used in Explicit Forward Mode. The PAC file link is configured on the clients’ proxy settings. If you need help with creating PAC files, check this link.
You can host the PAC file on any webserver, but hosting on the WSA is possible too. Click Security Services > PAC File Hosting and upload your PAC file. It’s recommended to host the PAC file on a seperate web server.
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.
For more information about OTV, check this website.
First, the network layout for this OTV network.
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.