Core Network Replacement Part 1

Core Network Replacement

I read a timely post by Tom Hollingsworth @NetworkingNerd about writing. I've realized that I have not written anything on my blog in quite sometime. I could write down a list of excuses but what is the point in that? Most others have the same or similar. And when did I actually get this posted?

I decided to capture some of the thought processes and steps that have and are going into the network core replacement at the $DayJob.

History:

Last Core network replacement was in was in 2007. Link to the vendor press release: http://www.thefreelibrary.com/Indiana+Tech+Builds+High+Performance+Campus+Network+With+Force10...-a0168505385

That update brought 10 gig between serveral buildings on campus and a push to 1 gb to the computer labs on campus. This also moved us away from a very Cisco centric network. It was new and different. The design contained Force10 E300 as well as a handful of S50 "classic" switches. 3 line cards in the E300, 8 port 10gig card, 24 port 1 gb SFP card, and a 48 port 1 gb copper card. At the time this seemed reasonable with room for growth. The 8 ports of 10 gig was not completely populated at first, but moving from 1 gb between buildings to 10 gig seemed like a huge jump. The 1 gig connections were not being used up, so 10 gig was a super highway.
After a couple of years a few flaws showed up. 1. My S50's didn't make the cut for running FTOS and continue to run STOS. 2. Some vlan troubles between STOS devices and no Force10 gear. 3. End of Sale / Dell purchase 4. Account forgotten.

In the pursuing years I found HP Procurve switch gear to be suitable and cost effective for use in my campus and branch offices. The last few building projects I used HP 5400 series switches either standalone or in a VRRP pair. I thought through whenever the next core upgrade came around, that maybe a good starting point. Possibly the 8200 series (Due to multiple "supervisors").

With the last building built Brocade offered a solution with their ICX 6610 and 6450 switches. I was intrigued with the performance in the 1 RU form factor. Being able to stack the switches across 10gig Ethernet links was very useful as the closets changed around from 3 to 4 due to design changes to the building. I had to compromise on the redundancy of each closet due to the change in cable paths and overloaded a closet from initial design. Since I wasn't stuck with fixed chassis I was able to shift one switch to the other closet. The use of high performance 1 ru switches showed value.

Current Selection:

So the ICX 6610 seemed to offer a redundant scalable cost effective solution to network core. Stack multiple to expand available 10gig ports. I was a bit concerned about having to stack multiple switches just to scale the 10gig ports without using the other ports on the switch.


Enter ICX 7750, 6 40gig Ports and 48 10gig port put that in a redundant pair. That is a lot of 10gig ports in 2U of switches. Which maybe more than I need at this point but the nice thing about SFP+ ports is the use of 1gig SFP's in them. So this is the direction that I went.


Next post will be a quick step through of the process that I used to swap them out.

Tallac Networks - Wireless SDN

A week or so ago I received a briefing on Tallac Networks wireless SDN solution. I have been interested in what Tallac was doing in this space since they started. Matthew Davy gave me the briefing. And yes that is the same Matthew Davy from Packet Pushers Episode 40. I was fortunate enough to have an introduction to openflow around the same time as that podcast, maybe sooner, by Matt when he was at IU. Matt had given a talk about a week or so before to members of the state higher edu network, I was unable to attend due to work schedule, there was a stream which didn't work for me. But it was a good thing since Matt spent most of the time doing a basic SDN intro. The room was not very familiar with it.

On to the meat of it. 

Tallac Networks has two major focus:

• Wireless SDN
• SDN Training

They are a major provider of SDN training materials. The training is what provides the cash for the wireless SDN work. Instead of going after major VC funding and then just burning through it.

Their target market is a Managed Service Provider. They have a AWS-Cloud based portal which can be customized for the MSP, then down to the MSP clients. Currently the AP model is a pretty high end 3x3 (I believe) model white box unit. They do have plans for other models. But currently it is a dual radio 3 stream unit. What runs on the ap is what makes the solution:

That is right, the Tallac SDM agent has two components, SDM Cloud Service and an OpenFlow Agent. 

• SDM Cloud Service is the management piece that talks to the cloud service. This is the "traditional" management agent, which ssid, traffic info, radio control etc is sent back and forth from the cloud management instance. 
• OpenFlow Agent, does that mean?? Yes it does. You can attached the AP to an OpenFlow controller (OpenDayLight,Floodlight,etc) and push OpenFlow rules down onto the hardware. I am told that the Openflow controller is/can be separate from the SDM Cloud Service. But what if I'm not ready to use the OpenFlow component? That is ok, too.

Part of the Tallac API/Cloud service is once a site is setup in the portal, meaning Address/Billing info. The hardware can/is ordered through the portal and then is shipped direct from the factory (White box hardware manufacturer) to the site. The AP comes with the Agent loaded and it's identifiers are attached to the site in the portal. This means when the unit is plugged in and talks to the cloud service, it gets attached to the site without user intervention. 

Another feature is an on-demand  network push. Where a SSID & network policy get instantiated based on demand for that network. So if I have a unit at my house which I have configured a corp SSID with a ssl vpn back to the office, when I leave the SSID and ssl vpn get removed from the unit, after the timeout. So corp SSID is not broadcasting at my house when not corporate devices are there. When a device returns and "probes" for that SSID , the policy comes back onto the device. This could be applied inside an enterprise as well.

A list of their features is here: http://www.tallac.com/key-features

A bigger look at the solution stack is here:

The Orchestration API is what brings the pieces together. This allows the multi-tenancy, customization of the end-user interface, etc. Information from other systems can be pulled into the orchestration api to drive policy. The API is used to drive the vNET Manager and NFV components.

This is a basic overview of how Tallac is creating SDN Wireless. Why this is cool is that this solution can function like any other wireless solution out in the market. But they have the added bonus including in the api's and openflow feature that can be used/experimented with will little impact to the operation of the network.

One last note, Matt mention the possibility of a SDN starter kit that they are working on. I think that it is an excellent idea, one that I hope they do release here shortly. I believe in the coming months we will hear more about the work that Tallac is doing in this space.

OpenDaylight on Windows - Hydrogen

A couple weeks ago OpenDaylight released Hydrogen, which is the first production release of code. This is a pretty significant milestone as it wasn't that long ago that ODL started.

Now I have detailed getting the controller up and running on windows in a previous post, that was actual building from source.

After a bit of try and fail of running the controller on x86 32-bit windows, I remembered that the Java seemed to run better on x64 version of Windows.

My test system:

Dell 2850 - 4 gig of ram running Windows Server 2008 R2

Installation:

Install Java SE 1.7.0_51

Set JAVA_HOME Environment Variable on system.

 ** Important note ** Use the 8.3 path name  This comes into play when starting the controller from the batch file.

Download pre-built zip file from http://www.opendaylight.org/software/downloads

Unzip into a directory

Open a Command Prompt as Administrator

Change to opendaylight directory in the folder extracted from the zip file.

Type run -start  to start the controller in the background. It takes a little bit before it is ready. If you are impatient like I am, run netstat -a in another command window. When you see localhost is listening on port 8080 you are ready to go.

Then point a web browser to http://localhost:8080

Login as on previous builds:

OpenDaylight SDN on Windows

So following the tutorial from @networkstatic found here: http://networkstatic.net/opendaylight-openflow-tutorial/ I was able to easily modify the steps and install/build OpenDaylight on Windows.

I used Windows Server 2008 R2 as my base system.
Components added:

• Git for Windows : http://code.google.com/p/msysgit/downloads/list
• Apache Maven: http://maven.apache.org/download.cgi
• Java JDK/JRE: http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html

Install Git for Windows, I selected the option during install to use the windows command shell for git.

Extract Apache Maven from the zip file. Add the path of the extracted files to the system path so you can call maven from anywhere. Makes life a little easier when you get to the directory inside of the clone source.

Install the JDK/JRE and add an environmental variable: JAVA_HOME and the path to the JDK. Things don't go without it.

Once you have the prerequisites done you can pull down the source from git.opendaylight.org

From a command prompt:

git clone http://git.opendaylight.org/gerrit/p/controller.git
Next change directories into: controller\opendaylight\distribution\opendaylight\




Run the following command:

mvn clean install

If your path is correct Maven should start going. This is the long part. If you read through Brent's tutorial you can see this step is long and will be a possible trip up. It is possible that something doesn't build right, this is active code being changed by many all the time. 

Once built you can change directories to: target\distribution.opendaylight-0.1.0-SNAPSHOT-osgipackage\

As you can see the path is pretty long, but there is a run.bat. Call that file and you can then browse to: http://localhost:8080 , on the machine in which you just built the project.

You can login using username: admin password: admin

And there you have it. 

From there it is up to you. I am still working down this journey as are lots of us. Thanks for following along.