Good Morning Web World!

I found myself with a little bit of time this morning and I thought I’d share a bit of my latest tinkering.

Those of you that have followed this blog for a while may remember my first post where I talked about pointing a CUBE through an ASA out to my ITSP, Flowroute. That post is located here for your reading pleasure.

While the software/hardware has changed with my setup the idea is basically the same. I still have a CUCM system (now 11.x) running with a phone (I’ve felt like being different lately so currently I’m using a retro 7985G as my endpoint (G in this case does not mean Gigabit)). I also have a firewall, a Cisco 5506-X (it was time for an upgrade from the 5505) and I do still have a CUBE. My previous CUBE was a 3825 and it worked wonderfully but the 3825 has long since outlived its relevance in today’s enterprise environments. In my stack of possibilities I also have a 2921 and while it is still a very powerful and valid router, it just seems too easy.

Simple and straight forward is great but only until you’ve done simple and straight forward, then it becomes time to mix it up.

To that end, my replacement CUBE is virtual. Yes, I said virtual. If you follow Cisco and their products, you may already know about the Cloud Services Router, the CSR1000V. The CSR1000V is a virtual router that runs on a VMWare ESXi host. It runs IOS XE though there is some Linux/Unix on the backend that makes it tick.


Virtual CUBE Show Commands

When I first heard that it was possible to turn a CSR1000V into a CUBE, I was skeptical. As I have worked through the configurations and witnessed it work, I must say I am impressed.  The configuration is the same as with any other IOS XE router with exception of the interface naming conventions. There are three (3) Gigabit Ethernet interfaces and they are named Gigabit Ethernet 1, Gigabit Ethernet 2 and Gigabit Ethernet 3.  The configuration in ESXi is shown below.

CSR1000V Interfaces Config

In my case, I created three (3) separate interfaces on my vSwitch and pointed them at three (3) separate VLANs in my infrastructure. You could bond/Port Channel these interfaces if you wanted too but you will still be limited by the throughput of your host’s uplink(s).

A few important things to note…

  • When you deploy the OVA file in ESXi you are given a choice of multiple router “sizes” i.e. memory and processor. I am using the smallest size which is one vCPU and 4GB of vRAM. Some of the larger installations require an additional license.
  • Keep in mind that I am testing this configuration in a controlled lab environment. I am not sure of scale-ability and if you read Cisco’s CUBE configuration guide, located here, you’ll see that the virtual CUBE does have several restrictions that may make it impractical for some organizations.
  • In my previous post, my 3825 CUBE was running 12.4 IOS which did not include Toll Fraud Prevention, starting in 15.x and moving through IOS XE you need to be mindful of TFP and what it means when you are trying to make/receive calls on a Cisco H.323 or SIP Gateway.

Let’s talk for a moment on Toll Fraud Prevention. As stated above, all modern IOS and IOS XE versions include Toll Fraud Prevention mechanisms and if you use a router, physical or virtual, for voice you need to be aware of them.

Voice Service Config

If you look at the configuration snippet above, you’ll see that in the voice service configuration there is a trusted IP Address list. That list contains the IPs of my ITSP and my CUCM. If I remove those IPs from the list, calls fail. If you are linking your CUBE or gateway to multiple CUCMs or other systems you’ll want to have those IPs in that list as well. What this list does is let the good/known IPs in to complete transactions/calls on the gateway/CUBE and keeps the unknown/bad IPs out to prevent them from placing calls on the system. If you’ve ever set up an IP PBX on internet, you know that Toll Fraud is a real and serious threat. If you don’t want or need this feature you can also turn it off by entering “no ip address trusted authenticate” in your voice service configuration. This is not a recommended configuration but in your environment the TFP mechanisms may do more harm than good.

Thanks for reading, I hope this has been informative.


When Good VTP Goes Bad

Just a quickie tonight folks…

I am expanding my network and relocating my servers and other “noisy” hardware to my basement. The cooling value of the dry subterranean environment is great but in all honesty I’m trying to keep my better half happy and my office is not a great place for network gear and servers apparently.

With this relocation I am expanding my switching infrastructure from my core 3560G to include a 2960G as well. The addition of this switch gives me the opportunity to play with VTP or the VLAN Trunking Protocol.

VTP is a Layer 2 protocol that allows you to configure all of your VLANs on the “server” and then feed them down to the “clients”. VTP is a proprietary Cisco protocol and for large, diverse networks it may not be the best option but for me it works, at least it was supposed to.

I say supposed to, because I configured it, using version 2 and nothing happened. Below are my configurations…

CORE-3560G-01(config-vlan)#do show vtp status VTP Version capable  : 1 to 3 VTP version running  : 2 VTP Domain Name  : SPRNET VTP Pruning Mode  : Disabled VTP Traps Generation  : Disabled Device ID  : 000a.b8d3.0400 Configuration last modified by at 8-22-16 01:52:57 Local updater ID is on interface Vl1 (lowest numbered VLAN interface found) Preferred interface name is gig0/49 Feature VLAN: -------------- VTP Operating Mode  : Server Maximum VLANs supported locally  : 1005 Number of existing VLANs  : 23 Configuration Revision  : 0 MD5 digest  : 0x85 0x94 0x36 0x46 0xC1 0xCE 0xE0 0xD0                    0x87 0x0A 0xF2 0xD4 0x24 0xD0 0xF8 0xD2
BASEMENT-2960G-01#show vtp sta VTP Version capable  : 1 to 3 VTP version running  : 2 VTP Domain Name  : SPRNET VTP Pruning Mode  : Disabled VTP Traps Generation  : Disabled Device ID  : 0017.594c.b180 Configuration last modified by at 3-15-93 06:29:46 Feature VLAN: -------------- VTP Operating Mode  : Client Maximum VLANs supported locally  : 255 Number of existing VLANs  : 5 Configuration Revision  : 0 MD5 digest  : 0x7D 0x73 0xB1 0x19 0x35 0xDC 0xE2 0xA8   0x3A 0x07 0xE0 0xBF 0x92 0xFA 0x53 0x2A

As you can see everything looks like it should work. My passwords match and my domain matches but still no joy. After banging my head on my desk to figure this out, I see the below error message at the bottom of my client’s VTP status.

*** MD5 digest checksum mismatch on trunk: Gi0/21 ***

What is this error? What does it mean?

What it means is that the key exchange between the VTP server and client is incorrect and thus no one talks. What it also means is that I am hitting a long running bug. See the Cisco forum post here

If you read that post, you’ll find the fix, but here it is for your reference.

Basically, you need to make your server regenerate its MD5 Checksum value. Once that value is regenerated, VTP messages are exchanged between the server and client(s) and VLAN joy is had by all. To regenerate this value, simply create a new Layer 2 Vlan.  A simple fix for a complex problem. For those of you that want to upgrade code to solve the problem, good luck, Cisco hasn’t fixed this bug in over 20 revisions of IOS software.

I hope this has helped someone, thank you for reading.