VMware vSphere Configuration

Configuration I designed some years back running VMware, EMC and DataDomain with some good old Cisco networking.  Pretty nice setup, if i don’t say so myself.

Screen Shot 2015-01-05 at 7.35.17 pm


Cisco switch config supporting 802.3ad and 802.1q.

Basic Tunnel Configuration

The below shows a basic configuration for a tunnel between the routers Jazz and Jules. In this instance router owen does not see the communication between jazz and jules.

Basic Tunnel

NBAR2 Protocol Packs

Verify Cisco AVC licensing is active

router#show license

Verify current NBAR information

router# show ip nbar protocol-pack active

Verify the version of NBAR

router#sh ip nbar version | include software

Installing a new protocol pack

router#ip nbar protocol-pack flash0:/pp-adv-isrg2-152-4.M1-13-5.1.0.pack

View NBAR traffic on an interface

router#sh ip nbar protocol-discovery [interface]

That’s about it.


Basic GRE Tunnel Config

GRE Tunnel Configuration

Generic Routing Encapsulation, or GRE, is a tunneling protocol that allows the encapsulation of many different network layer protocols between two endpoints. Packets are sent through a virtual tunnel on a point-to-point link.

It is important to understand that GRE tunnels do not encrypt traffic in any way; they are simply encapsulated within an additional GRE and IP header. If a secure tunnel is required, IPSec can be used with GRE to provide data confidentiality.

Also keep in mind that GRE over IPSec tunnels are different from stand-alone IPSec VPN tunnels. GRE over IPSec tunnels support multicast IP traffic, which strict IPSec VPNs do not. This is important when routing protocols need to send routing information across the tunnel since they use multicast for their control information. If your network requires a routing protocol like EIGRP or OSPF, then GRE over IPSec can provide secure transport for those services.

GRE-Tunnel Config - Basic

Step 1: Create the tunnel interface on the VPN router.

A GRE tunnel uses a virtual tunnel interface, configured with an IP address where packets are encapsulated/decapsulated as they enter and exit the GRE tunnel.

The IP address must be in the same subnet on both router’s tunnel interfaces.

interface  Tunnel0

ip address

It is common practice to also reduce the maximum transmission unit (MTU) to 1400 bytes to avoid any fragmentation problems over the transport networks. Remember that GRE adds an additional 20-byte IP header as well as a 4-byte GRE header to each packet in the tunnel.

Because most devices have an MTU of 1500 bytes, reducing the GRE tunnel MTU will account for the added overhead and help prevent unnecessary packet fragmentation.

interface  Tunnel0

ip address

ip mtu 1400

Step 2: Define the tunnel source and destination under each tunnel interface.

The router uses its local interface that connects to the internet as its tunnel source. The tunnel destination corresponds to the remote router’s publicly routable IP address.

interface  Tunnel0

ip address

ip mtu 1400

tunnel source FastEthernet0/0

tunnel destination

Note that the tunnel source and destination can both be IP addresses. For example, “tunnel source″ could have been used instead of “tunnel source FastEthernet0/0″.

Step 3: Testing Connectivity

The configuration above is from the perspective of RouterA. The same configuration template would need to be applied to RouterB for the tunnel to begin passing traffic (with source/destination IPs swapped of course).

Now that both endpoint routers have been configured, they should be reachable via pings.


Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:


Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Step 4: Add Routes to Remote Networks

This confirms that we can pass traffic inside the GRE tunnel, but hosts on the Branch LAN networks will not be able to send packets to each other without some routes added. We can use a simple static route for this purpose.

RouterA(config)# ip route

RouterB(config)# ip route

Now when RouterA receives a packet destined for the East Branch LAN (, it knows it’s next-hop interface is the tunnel endpoint, so it will forward the packet through the GRE tunnel.

That’s it for the GRE tunnel configuration. Now onto adding IPSec.

IPSec Encryption for the GRE Tunnel

As we mentioned, GRE provides no form of payload confidentiality or encryption. If the packet are sniffed over the public transit networks, their contents are in plain-text.

IPSec solves the security concerns by encrypting part or all of the GRE packets. There are two IPSec tunnel modes – tunnel and transport. This configuration example will show the default, tunnel-mode IPSec encryption which protects they entire GRE header and payload.

Step 1: Create an Access list to define the traffic to encrypt.

The ACL should match traffic from the outside interface of the local router to the outside interface of the remote router.

access-list 101 permit gre host host

Step 2: Configure an isakmp policy.

Note: The ISAKMP policy, key, and IPSec transform set must match on both sides of a single tunnel.

crypto isakmp policy 1

  authentication pre-share

Step 3: Configure pre-shared keys.

The key P@ssword will be configured to be used for authentication with RouterA’s peer The address at the end of the statement refers to the public IP address of the peer router (RouterB).

crypto isakmp key P@ssword address

Step 4: Configure the transform set.

crypto ipsec transform-set strong esp-3des esp-md5-hmac

The full ISAKMP configuration:

crypto isakmp policy 1

  authentication pre-share

crypto isakmp key P@ssword address


crypto ipsec transform-set strong esp-3des esp-md5-hmac

Step 5: Configure a crypto map and bind the transform set and the traffic ACL to the crypto map. Define peer IP address below crypto map.

crypto map S2SVPN 10 ipsec-isakmp

set peer

set transform-set strong

match address 101

Step 6: Apply the crypto map to the physical, outside interface.

If you are running a version of IOS Software Release earlier than 12.2.15 then the crypto map must be applied to the tunnel interface as well as the physical interface.

interface FastEthernet0/0

  crypto map S2SVPN

interface Tunnel0

  crypto map S2SVPN

Now configure the remote router using the same IPSec configuration template. Make sure to change the local and remote IPs as necessary.

Verify GRE over IPSec Tunnel Connectivity

Now that the GRE over IPSec tunnel configuration is complete, we can verify end-to-end IPSec tunnel connectivity. By simply sending pings to the remote networks, the IPSec VPN will come up and begin encrypting/decrypting traffic.

RouterA# ping

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:


Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

The show crypto session command can be used to verify that the IPSec VPN encryption is operational.

RouterA# show crypto session

Crypto session current status

Interface: Tunnel0

Session status: UP-ACTIVE

Peer: port 500

IKE SA: local remote Active

IPSEC FLOW: permit 47 host host

Active SAs: 2, origin: crypto map

QoS – Cisco, Riverbed & Polycom

After many hours trying to sort this one out it would appear that a Riverbed Steelhead can’t easily optimise VC Traffic, as this traffic is already optimised by the Polycom device itself.  Sorry, that’s not to say I can’t, but i’d rather not enable the QoS on the Steelhead to solve this problem.

The environment:

H.323 protocol matched in the VC Class of traffic, in this case af41 (34). Packets tagged, no packets being dropped

Running 6CoS on Telstra Links (GWIP) which is really just IPMAN.

Host specific (/32) in-path optimisation rules on the Steelheads to ensure traffic to and from the VC units is bypassed.

Under normal circumstances traffic is passed through the Steelhead and the the size of packet increases, as riverbed encapsulates video packets, so i have decided to bypass video traffic on the steelhead, so that the encapsulation and other overheads can be avoided.

Fingers crossed….but i’m pretty happy it will work!

Those Useful Commands

A short listing of handy commands used on a regular basis:

#show ip interface brief

Shows status of the interfaces on the device, including up/down and ip information.

#show ip protocol summary

Will show you all the routing protocols running on the router

#show log

Will display the configured log settings and buffered log messages

#show interfaces status

Shows Port, Status, VLAN, Duplex, Speed and Type for all interfaces.

#show interfaces summary

Live traffic stats on the interfaces.

#show ip arp

Displays the IP to MAC Address resolution for all the IP’s on the device, and from the interfaces it was learned.

#show mac address-table

Shows the MAC  table entry and interface it is being seen on.

#show policy-map [interface]

Displays the QoS Policy information

#show interfaces link

Will display how long the interface has been disconnected

#show version

Displays information about the device. It gives you details such as; IOS version, System Uptime, Image filename, Type of Processor, Amount of RAM, Number of Ports, Flash Memory, MAC Address and Serial Number

#show clock

Displays the clock status

#show version | include uptime

Shows the uptime of the device

#show processes cpu

Displays the CPU utilisation stats

#show processes cpu history

Displays a one minute output, and so on……

#show history

Lists the commands the user has entered in the session

#show inventory

Displays all the inventory information about the device

#show line

Lines connected on the router’s physical ports, such as serial connected.

#show cdp neighbour

Shows the directly connected devices with local and remote interfaces, via Cisco’s Discovery Protocol

Disabling useless Logs on an ASA

While reviewing the ASA logs in relation to a large wireless metering project in WA, i came across a number of log entries that were just there (hundreds of thousands of them), so here’s how to disable them:

%ASA-6-302013: Built inbound TCP connection……
%ASA-6-302013: Built inbound TCP connection…..
%ASA-6-302015: Built outbound UDP connection…..
%ASA-6-302014: Teardown TCP connection…….
%ASA-6-302013: Built inbound TCP connection ………
%ASA-6-302020: Built outbound ICMP connection………
%ASA-6-302013: Built inbound TCP connection……

To exclude these types of log messages from being recorded. Simply login to the CLI and type the following:

ASA#config t
ASA(config)#no logging message 302016

Each log message has a syslog-id which is the 6 digit number. If there are additional types of logs you want to block, simply repeat the command above for each syslog-id. Link to the massive list of syslog-id messages and their descriptions:

And the command reference:

AVC Deployment Guide


AVC provides application-aware control on a wireless network and enhances manageability and productivity. AVC is already supported on ASR and ISR G2 platforms. The support of AVC embedded within the WLAN infrastructure extends as this as an end-to-end solution, which gives a complete visibility of applications in the network and allows the administrator to take some action on the same.

Rouge Management in a Unified Wireless Network

A useful read around Cisco APs and Rouge Management.

Wireless networks extend wired networks and increase worker productivity and access to information. However, an unauthorized wireless network presents an additional layer of security concern. Less thought is put into port security on wired networks, and wireless networks are an easy extension to wired networks.

Click to access 112045-handling-rogue-cuwn-00.pdf