Moving Cisco UCS to 10G Interfaces

We initially implemented our Cisco UCS chassis and FI’s with 4 port channels each with 2x1Gb interfaces connected to our Cisco Core Switches. Now we are in the process of moving from a dual Cisco Core to a Juniper Virtual Chassis Core, more on that later in another post. Part of getting the new core was finally getting 10G for our network. We had been surviving just fine with our current network connectivity, but figured it wouldn’t hurt to get 10G and connect whatever we could to it.

What I could not find searching around the internet was how the UCS FI’s were going to handle the additional links and how the traffic would move over. I was afraid it would do some sort of Spanning Tree blocking and not allow them to pass traffic. However I realized after checking the existing links that I had two from each FI and both of them were actively passing traffic and neither was in a blocking state.

I then went ahead and started to plan the turnup of the links. For us the majority of our servers are sitting in the UCS environment from bare metal linux and windows machines, to our 500 Guest VMfarm. With so much crucial infrastructure we wanted to make sure we didn’t have any downtime or lose any traffic during the transition. So as part of the planning I built out a python script that would ping a list of known addresses to ensure they were all up and on the network as each part of the plan was completed. I wanted it be useful across any platform so that the code was reusable, so I made some allowances for the different versions and the unique requirements of each OS. The only requirement is a file called hosts.txt with your ip addresses in it you want to ping. Its multi threaded so it will run a lot of the pings at the same time and complete it as soon as possible. Then you just need to go through the output and look for anything that is failing.

 

 

[codesyntax lang=”python”]

#!/usr/bin/python

import sys
import os
import platform
import subprocess
import threading

plat = platform.system()
scriptDir = sys.path[0]
hosts = os.path.join(scriptDir, ‘hosts.txt’)
hostsFile = open(hosts, “r”)
lines = hostsFile.readlines()

def ping(ip):
if plat == “Windows”:
ping = subprocess.Popen(
[“ping”, “-n”, “1”, “-l”, “1”, “-w”, “100”, ip],
stdout = subprocess.PIPE,
stderr = subprocess.PIPE
)

if plat == “Linux”:
ping = subprocess.Popen(
[“ping”, “-c”, “1”, “-l”, “1”, “-s”, “1”, “-W”, “1”, ip],
stdout = subprocess.PIPE,
stderr = subprocess.PIPE
)
if plat == “Darwin”:
ping = subprocess.Popen(
#[“ping”, “-c”, “1”, “-l”, “1”, “-s”, “1”, “-W”, “1”, ip],
[“ping”, “-c”, “1”, “-s”, “1”, “-W”, “1”, ip],
stdout = subprocess.PIPE,
stderr = subprocess.PIPE
)

out, error = ping.communicate()
print out
print error

for ip in lines:
threading.Thread(target=ping, args=(ip,)).run()
[/codesyntax]

For the migration we took the subordinate FI and brought up the 10G interface as we watched traffic flow over it we then ran the ping script a couple of times. We then started to shutdown the trunk interfaces each time running the ping script looking for issues. After we had the Subordinate FI moved over to the 10G and new core we then then did the same with the Primary FI. I was happy to find that at no time did we lost any connectivity to our hosts/guests and that everything went smoothly.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.