My Geek Finds

One of the new features of vSphere is the vNetwork Distributed Switch (vDS). Basically vDS allows you to create, manage, and provision your virtual network across all of your vSphere hosts in vCenter. vDS is available under the Enterprise Plus license.

Here is how I set up my vDS. I basically used the 3 host configuration example in What’s New in VMware vSphere 4: Virtual Networking white paper as a guide.

First I created a new vNetwork Distributed Switch in Inventory->Networking.

I configured it for 8 dvUplink ports. Why 8? Well I have 8 NICs in each of my host, and I would like to be able to use and manage all eight of them across one vDS.

I added each of my host to the vDS but did not add any physical adapters yet.

After the new vDS is created I created my port groups. One port group for the Service Console, one for vmotion, and one for each of my production VLANs.

When creating these port groups I just used the defaults except for changing the VLANs where needed.

Now that I have my vDS set up, time to migrate the host networks to the new switch. In Inventory->Hosts and Clusters select the host Configuration tab then Networking and the Distributed Virtual Switch button.

First i migrated the Virtual Machine networks to the new vDS. I took one NIC out of the port channel on the physical switch and added that physical NICs to the vDS. I did this for each of my hosts.

Then I use the Migrate Virtual Machine Networking wizard to move all of my VMs from the vSwitch port groups to the new vDS.

After this is done I add the rest of the physical NICs associated with my VM network to the vDS and recreate the port channel on the physical switch.

Now on to the vmkernel ports. I used the Manage Virtual Adapters wizard to migrate my VMotion VMKernel adapter to the new vDS.

I then did the same to my service console. Before I started making changes to the Service Console I put the host in maintenance mode. I created a new service console with a new IP address on the same subnet on my management port group and made sure I had connectivitiy (OK I did not do this the first time, messed up and lost the Service Console connectivity to my host – had to go CLI to fix it, but that is a completely different multi-page post in itself – very thankful for the spare NIC I have in each host).

Since my vMotion vmkernel port and Service Console are now on the vDS I attached their physical NICs to the new vDS and then added them to the port channel on the physical switch.

vNetwork Distributed Switch Screenshot

The only issue I had was with the iSCSI vmkernel ports. I was not able to get them to work on the vDS so they are still configured on a vSwitch on each hosts.

Not sure why I could not get it to work, but I will tackle that another day.

After I verified everything works, I deleted the old Virtual Switches from each host.

Just a quick overview of how I set up my vDS. Hope you find it helpful.

TGIF!

HAVE A GREAT WEEKEND!!!

Configuration examples for setting up an Cisco ASA to allow Split Tunneling (Local LAN Access) to VPN Clients. http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080702999.shtml

Sets up routes to networks accessible over the tunnel while allow the default route to remain the local default.

Just doing a little reading on the possibilities of running Cisco Call Manager (Unified Communications), Unity, and CRS (UCCX) in a virtual environment.

Cisco actually supports running Unity as a virtual machine guest in ESX. The Desgin Guide is here http://www.cisco.com/en/US/docs/voice_ip_comm/unity/virtualization_design/guide/cuvirtualdg010.html

Cisco does not support Vmotion, HA, or iSCSI attached storage for a virtualized Unity box. They also do not support a physical to virtual conversion of a Unity server. Hopefully Cisco will support Vmotion and HA at some point.

I also found some interesting information on running an older Call Manager version (4.x) as a VM – http://www.blindhog.net/cisco-install-call-manager-4x-with-vmware/

Here is some info I found on UCCX – http://tannerezell.com/cisco/?p=85

Here is a script I put together some years ago to create a simple Iptables firewall on my linux webserver. Some of the code was borrowed from a linux security book but I do not remember which one. Anyway it is a pretty handy script to give you some control and protection.

First create three files in /usr/local/etc:

ipblack.lst – this file contains a list of ip addresses you want to blacklist. One ip or subnet per line.

Example:

94.178.222.17
87.0.0.0/8

ipwhite.lst – this file contains a list of ip addresses that you allow unrestricted access (Be careful with this). One ip or subnet per line. Make sure you add localhost to this file.

Example:

localhost
10.10.1.1 #Home IP Address

ports.lst – this file contains a list of ports you allow.

Example:

22 #SSH
25 #SMTP
53 #DNS/Domain
80 #HTTPD
443 #HTTPS

Add this iptables.sh script to /usr/local/sbin

#!/bin/sh

#Iptables for webserver

IPTABLES=/sbin/iptables
WHITELIST=/usr/local/etc/ipwhite.lst
BLACKLIST=/usr/local/etc/ipblack.lst
PORTSLIST=/usr/local/etc/ports.lst

#—-Flood Variables—–#

# Overall Limit for TCP-SYN-Flood detection
TCPSYNLIMIT=”5/s”
# Burst Limit for TCP-SYN-Flood detection
TCPSYNLIMITBURST=”10″

# Overall Limit for Loggging in Logging-Chains
LOGLIMIT=”2/s”
# Burst Limit for Logging in Logging-Chains
LOGLIMITBURST=”10″

# Overall Limit for Ping-Flood-Detection
PINGLIMIT=”5/s”

# Burst Limit for Ping-Flood-Detection
PINGLIMITBURST=”10″

#Clear any current filters
$IPTABLES -F

#Process Whitelist
for x in `grep -v ^# $WHITELIST | awk ‘{print $1}’`; do
echo “Permitting $x…”
$IPTABLES -A INPUT -t filter -s $x -j ACCEPT
done

#Process Blacklist
for x in `grep -v ^# $BLACKLIST | awk ‘{print $1}’`; do
echo “Blocking $x…”
#$IPTABLES -A INPUT -t filter -s $x -j LOG
$IPTABLES -A INPUT -t filter -s $x -j DROP
done

#Allow Ports list
for port in `grep -v ^# $PORTSLIST | awk ‘{print $1}’`; do
echo “Accepting port $port…”
$IPTABLES -A INPUT -t filter -p tcp –dport $port -j ACCEPT
done

$IPTABLES -A INPUT -t filter -p tcp –syn -j DROP

#ICMP TIMESTAMP REQUEST AND REPLY
$IPTABLES -A INPUT -p icmp –icmp-type timestamp-request -j DROP
$IPTABLES -A FORWARD -p icmp –icmp-type timestamp-request -j DROP

#Logging of possible TCP-SYN-Floods
$IPTABLES -N LSYNFLOOD
$IPTABLES -A LSYNFLOOD -m limit –limit $LOGLIMIT –limit-burst $LOGLIMITBURST -j LOG –log-prefix “fp=SYNFLOOD:1 a=DROP ”
$IPTABLES -A LSYNFLOOD -j DROP

#INVALID SYN packets
$IPTABLES -A INPUT -i eth0 -p tcp –tcp-flags ALL ACK,RST,SYN,FIN -j DROP
$IPTABLES -A INPUT -i eth0 -p tcp –tcp-flags SYN,FIN SYN,FIN -j DROP
$IPTABLES -A INPUT -i eth0 -p tcp –tcp-flags SYN,RST SYN,RST -j DROP

#Logging of possible Ping-Floods
$IPTABLES -N LPINGFLOOD
$IPTABLES -A LPINGFLOOD -m limit –limit $LOGLIMIT –limit-burst $LOGLIMITBURST -j LOG –log-prefix “fp=PINGFLOOD:1 a=DROP ”
$IPTABLES -A LPINGFLOOD -j DROP

Add /usr/local/sbin/iptables.sh to rc.local so that it runs when the machine starts up.

Anytime you make changes to the ipblack.lst, ipwhite.lst, or ports.lst files rerun the iptables.sh script to apply the rules.

The script also applies iptable rules to help protect against ping floods, SYN flood, and invalid SYN packets.

Wireshark is a FREE network protocol analyzer. A must have tool for tracking down network traffic issues. The VoIP analysis has saved me tons of time tracking down phone issues.

Download it here http://www.wireshark.org/

We recently increased our Internet bandwidth from a single 1.54Mbps T1 to what Verizon calls 3Mbps Bonded Service.  This takes two 1.54Mbps T1s and puts them in a ppp multilink group to double your bandwidth.

Here is the quick and dirty configuration for bonding two Serial (T1) PPP links on a Cisco 1841 router.

interface Mulitlink1
ip address xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx
ppp multilink
ppp multilink group 1

interface Serial 0/0
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1

interface Serial 0/1
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1

The two serial interfaces then look like one – the Multilink1 interface.  The PPP ip address for this end will be the ip address of the Multilink1 interface. You can still check the status of each serial interface using “show interface serial 0/x” .  This will also show you what Multilink group the serial interface is a member of

Link is a member of Multilink bundle Multilink1

You can also check the status of the Multilink interface by using “show interface Multilink1″.  The command “show ppp multilink interface multilink1″ will display what interfaces belong to the multilink group (useful if you are on a larger router with multiple multilink ppp groups).

I have set up these multilink interfaces in the past, but I can say I am not sure what happens if just one of the T1s fail.  I would guess that the PPP would not like this and bring the whole interface down.

Does losing one T1 bring the whole Multilink interface down or will it the protocol stay up? Is there a better way to do this that will keep the interface up if one of the T1s fail?

Going to have to test this when I get a chance.