Vlan on Aaron's Worthless Words

Migrating CSM Serverfarms to Other Server VLANs

Mon, 25 Jan 2010 00:00:00 +0000

A coworker brought an interesting problem to me the other day. He wanted to move a serverfarm from one server VLAN to another without taking an outage. Since I didn’t want to have to come into the office late at night to do work, I decided to see what we could do.

It turned out to be pretty easy. We tend to think of CSM VLANs as pairs – you have the client VLAN for the web servers where the vserver sits and the server VLAN where the serverfarm sits. The CSM doesn’t know about these relationships; all it cares about is whether the servers are in a server VLAN, and we can use that to our advantage here.

An Interesting Problem with Multiple DCs on a Stick

Tue, 24 Mar 2009 00:00:00 +0000

We talked about running multiple data centers on a stick back in August, which is where you have multiple logical pairs of client and server VLANs on a single CSM for different tiers or functions. The big point of the article was that you had to do some fancy forwarding to get a server-initiated connection from one server VLAN to appear out the appropriate client VLAN. Well, we ran into an interesting issue with the given solution.

RSPANs on Cisco Switches

Wed, 18 Mar 2009 00:00:00 +0000

We discussed SPANs earlier, but let’s talk about RSPANs for a bit.

Can anyone guess what the “R” means? You guessed it – “Remote”. An RSPAN is a way to get traffic from a SPAN source on one switch to a SPAN destination on another switch that’s connected via a trunk.

The basic premise is that a special VLAN is created on all the switches and allowed to traverse the trunks. You then set up a SPAN session that copies your traffic to this special VLAN. This VLAN then gets the traffic to the other switches through some voodoo magic to be used as source for a SPAN on another switch.

VLANs on Linux

Thu, 19 Feb 2009 00:00:00 +0000

My home network has a Linux box running IPTables as it’s center point, and, since there are four networks, it has 4 NICs and 4 cables into the switch. I kept running into problems with the NICs (they would reorder depending on what flavor of Linux was installed), so I wanted to consolidate the NICs down to 2 – one for the Internet link and one for the LAN segments with 802.1q tagging.

VTP and You

Wed, 16 Apr 2008 00:00:00 +0000

VLAN Trunk Protocol (VTP) is a little gem on Cisco switches that allows you configure VLANs in one place and have them appear on all of your switches. This is great for large enterprises with 8457839 switches all trunked together because who wants to configure the new VLAN for that one-off application on all 8457839 switches?

VTP works by having designated VTP servers (not real servers like your Linux box, but a switch) tell the rest of the switches in the network with what VLANs they should be configured. All the designated VTP clients say “OK” and configure themselves with those VLANs. When you take a VLAN out of the server, all the clients take it out; when you add a new VLAN, all the clients add it as well. The server and client designation is known as the VTP mode, and there’s one more to mention. When a switch is in VTP transparent mode, he will see VTP from the servers but will ignore them and pass them on to the next switch as if nothing ever happened.

Setting Up VLANs on an ASA 5505

Tue, 01 Apr 2008 00:00:00 +0000

I’ve had my ASA 5505 in place at home on my Comcast cable for a few weeks now, and, let me tell you, this thing rocks. I did, however, have a few problems finding a clear answer on how I could set up my VLANs. It turns out that the base license on the ASA 5505 comes with a few restrictions with regards to VLANning – in particular the number of VLANs and the number of trunks.

Ideas That Seems Good At the Time

Wed, 12 Sep 2007 00:00:00 +0000

When I started in IT, I tried to get my gear as standardized as possible to impress everyone. I worked at it and worked at it until I realized that there were a handful of things that sound good but just won’t work. If you’re just getting started in the field, you may not agree, but come back in 5 years and see how right I am. Heh.

Assigning switchports to VLANs in chunks just doesn’t work. This seems like a great idea. You can put client A on port 1 through 12 and client B on ports 13 through 24. Then client A winds up with 13 servers, and B only has 3, so your whole scheme is in pieces on the floor. It’s just easier to plug servers into the next available port and forget physically organizing the ports. The switches don’t care if the ports are in order by VLAN. Just keep it simple.
Color-coding cables only works for a while. Let’s cable web servers with green cables and application boxes with blue cables and the database servers with pink and the mail servers with aubergine. I promise you, though, that you will run out of cables of one color or another and wind up having a database server in green. Then you’ll have something else wrong. It won’t be long before the color standard only applies on paper.
Labeling switchports by name only works if you buy servers all the time. If you’re in an environment where servers change roles and names, I guarantee you that your ports are mislabeled. The only time that labeling really works is if you’re lucky enough to work for a company with enough money to buy new stuff for every project. I’ve actually resorted to labeling ports with serial numbers instead of names since those won’t change.
Complicated naming schemes don’t work. They may sound cool, but simpler names are almost always better. Name your router “r1” or something. Don’t try “rtr001prod1” or something as ludicrous. I once made up this awesome naming scheme, and it worked until the business took on other projects that didn’t fall into the standard, so I was screwed. Save yourself some problems and keep it simple.