Monday, June 21, 2010

You know when you do something and you think to yourself "Oi, I should really document this"? And then you go "Nahhh, this is easy peasy lemon squeezy - I won't forget" and a month later you have to repeat the task and wonder of wonders, you did forget. Well Goddammit - never will I have to wonder again how to create a LUN on a HP EVA 4400 SAN and use said LUN (or Vdisk in vHP's vVirtual vSpeak vWhere vEverything vStarts vWith a vStupid vV). vWhere...er I mean where was I. Ahh yes, lets create a vDisk...

Create a vDisk on the EVA SAN

Log into Command View (what a cool name, sounds like you can bomb some backwater country into the Stone Age with a mere misplaced mouse-click)

Expand your Virtual Disks Folder

Click Create vDisk

Name your disk, then give it a size and RAID level

Click Create vDisk

Present the vDisk to your Hosts

Navigate to your newly created vDisk and click the Presentation tab

Click Present and select all hosts to present the vDisk to. For some obscure reason every 4400 I've worked on would only allow me to present to four hosts / HBA's at a time, anything more and it errors out

Initialise and format the vDisk

Open the Disk Management MMC on one of your SAN-connected Hyper-V hosts

Right-click the Disk Management node and click Rescan on the context menu

Right-click on the newly appeared unallocated disk and select Bring Online

Friday, June 4, 2010

I find myself having to explain the concepts behind VLAN's a lot, so I've decided to do a blog post about it.

The Wikipedia article defines a VLAN as: "a group of hosts with a common set of requirements that communicate as if they were attached to the same broadcast domain, regardless of their physical location. A VLAN has the same attributes as a physical LAN, but it allows for end stations to be grouped together even if they are not located on the same network switch. Network reconfiguration can be done through software instead of physically relocating devices".

PROTOCOL CONCEPTS

We have regular "untagged" Ethernet frames. ("Frame" is the data-link (layer 2) term for what some protocols calls a "packet" or "datagram".) These are the same Ethernet frames from before VLANs were invented.

Then we have "tagged" frames. These take a regular Ethernet frame and add a marker -- the "tag". The tag itself contains the VLAN number (along with a priority code). Thus, a tagged frame is associated with a particular VLAN number.

Inside the frame, the tag is basically just a reserved Ethernet frame type, followed by the tag information, followed by the rest of the original frame (complete with its original frame type). So to network nodes which are *not* VLAN aware, a tagged frame looks just like a regular Ethernet frame, but with an "unknown" frame type.

For computers, a VLAN-aware network stack will usually turn each VLAN into a separate network interface, as if each VLAN was a different network card with a different cable. The "stock" network stack included with Win 2000/XP does *not* include VLAN capability, so they can only handle untagged frames. Tagged frames will generally be silently ignored. Third-party software (often included with high-end network cards) can add VLAN capability. I'm not sure about 2003/Vista/2008.

Switches which are not VLAN-aware, along with any repeaters, will treat tagged frames exactly like they do any other frame.

SWITCH CONCEPTS

Switches which are VLAN-aware generally let you control which ports are associated with which VLAN(s). The terminology, commands, etc., will vary with manufacturer. I'm most familiar with the HP ProCurve managed witches, so I'll speak mostly to that. The concepts should carry over to other manufacturers.

With HP, you can tell the switch that each VLAN is tagged, untagged, or not available for each port. Internally, frames are *always* associated a VLAN number. The configuration just tells the switch which VLANs go with which ports, and which VLAN number to use for untagged frames.

When the switch receives an untagged frame, it needs to know what VLAN to associate it with. If the port has an untagged VLAN associated it, the fame will go to that VLAN. If there is no untagged VLAN associated with the port, the frame is dropped. This is why a port can have (at most) one untagged VLAN associated with it -- how could the switch know which one to use otherwise?

When the switch receives a tagged frame, it simply checks to see if that VLAN is associated with the port. If so, it accepts it; if not, it drops it. This is basically just an access control mechanism

When the switch has a frame to *transmit*, it only considers ports which are associated with the frame's VLAN. If a port is configured as tagged for the frame's VLAN, it transmits the frame with the VLAN tag. If a port is configured as untagged for the VLAN, the frame is transmitted on that port without a VLAN tag.

Real-World Implementations

Okay, enough conceptual stuff, how do we use it? Below I'll describe a implementation I had to do for a client recently.

VLAN's were numbered and split up as follows -

1 – Reserved

2 – Main company private network

3 – Guest network

4 – ISP uplink

5 – IP telephony

I used separate VLANs for security, manageability, and robustness. I don't want guests to be able to probe/sniff/screw-up the corporate network. I didn't want the cable modem link (which is full of garbage traffic from other subscribers) on the main LAN. I want the phones to have higher priority over regular data, and to have their own DHCP server, so if the "data side" of the house goes down, they still have phones.

I don't, as a rule, use VLAN 1 because that's the default on most things. This also avoids confusion.

VLAN 2 is where most traffic is in this scenario. Most ports are configured as untagged for VLAN 2. The computers, printers, etc., plugged into those ports aren't even aware they are on a VLAN. All the employee workstations are like this, as are most servers. The syntax to configure this is easy. For example, if I want port 1 to be untagged for VLAN 2 like this:

vlan 2 untagged 1

VLAN 3 is for guests (visitors). For obvious reasons, I don't let them plug in to the main network. They get a separate IP subnet, a separate DHCP server, and bypass much of the network filtering. Again, all untagged, and connected nodes are not aware of the VLAN.

VLAN 4 was created because the client has a ADSL Internet feed they use for employee web browsing. Circumstances meant the modem had to go in a different building from the main server/network room. So the cable modem plugs into a particular switch port, which uses VLAN 4 to carry it to the firewall in a different building. Again, untagged, unaware.

VLAN 5 is for premises voice-over-IP. The phones include a built-in switch for "daisy chain", and are VLAN-aware. Switch ports connected to phones are tagged for VLAN 5 and untagged for VLAN 2, so you can plug a PC (not VLAN aware) into the phone. Traffic is kept separate, and voice traffic is given priority. The central phone equipment has an Ethernet port which we connect to one of the core switches, with that switch port untagged for VLAN 5. So the central equipment just thinks it is talking to a regular LAN.

For example, suppose port 20 was the central phone equipment, and port 7 had a VoIP phone. We would do:

vlan 2 untagged 7

vlan 5 tagged 7

vlan 5 untagged 20

For links between switches, each VLAN is configured as *tagged* for those ports, with *no* untagged VLAN. Those ports are only used to carry traffic between VLAN-aware switches. (Cisco would call this a "trunk port", IIRC.) The HP syntax for (e.g.) port 24 as a switch link would be:

vlan 2 tagged 24

vlan 3 tagged 24

vlan 4 tagged 24

vlan 5 tagged 24

Finally, our firewall, which *is* VLAN-aware, is configured as tagged for all VLANs on its port, with no untagged VLAN. Virtual network interfaces are configured in the firewall OS, and all the IP configuration and filtering rules are done with those virtual interfaces, not the physical interface. This also means our firewall only has one network cable plugged into it. Configures the same as a switch link, really.

About Me

About This Blog

This blog serves 2 purposes. Firstly, I want to share information with other IT pros about the technologies we work with and how to solve problems we often face. I work with technologies from the desktop to the data center, Active Directory, System Center, Exchange, Hyper-V, VMware, Networking and Storage.

Less altruistically, I use my blog as a reference. There's so much to learn and remember in our field that it's impossible to keep up. By blogging, I have a notebook that I can access from anywhere. It has made me look much smarter than I probably am on many occasions.