Archive for the ‘networking’ Category

Providing DHCP to multiple VLANs from one server

Wednesday, June 17th, 2009

Suppose you have a network with multiple VLANs, each with its own subnet, and you want your DHCP server(s) to serve addresses and configuration to all subnets (or at least more than one of them). The problem normally is that broadcast traffic (such as DHCP requests from clients) cannot traverse broadcast domains, which is exactly what VLAN separation does: limit broadcast domains.

There’s basically three solutions: the first is to provide a single DHCP server with a network interface in each VLAN. This will work fine for a very limited number of VLANs, but is not very effective for larger numbers of VLANs and it’s also not very flexible. Every new VLAN requires an extra NIC, cabling, etc.

The second solution is to provide each VLAN with its own DHCP server. This is not very flexible either and eats lots of resources per VLAN and adds a lot of management complexity.

The third solution adds flexibility, ease of management and does not require a major investment in separate servers. What you do need however is a Layer3 switch in stead of a Layer2 model. The reason for this is that the switch has to be capable to route, or more accurately: re-route IP packets.

To enable a single DHCP server to serve multiple subnets, one per VLAN, you can configure your switch (both Cisco and HP Layer3 switches can do this, and probably most other brands as well) with an ‘IP helper’. An IP helper address tells the switch to forward certain types of broadcasts (like DHCP requests, TFTP requests and DNS requests) via unicast to the IP address(es) configured. An example:

Here the DHCP server is using address 10.0.1.5 in VLAN 1, on subnet 10.0.1.0 /24. The two clients are on separate VLANs 2 and 3 with subnets 10.0.2.0 /24 and 10.0.3.0 /24 respectively. In this case, we need the switch that receives the DHCP requests broadcast from the clients to forward the requests to the DHCP server. To do this, we add the IP address of the server to the different VLAN interfaces as the IP helper:

interface vlan 1
ip address 10.0.1.1 255.255.255.0

interface vlan 2
ip address 10.0.2.1 255.255.255.0
ip helper-address 10.0.1.5

interface vlan 3
ip address 10.0.3.1 255.255.255.0
ip helper-address 10.0.1.5

 

The switch will now forward the request broadcasts to the DHCP server. If the DHCP server has been configured with separate ranges for each subnet, the right answer will be sent back by it to the switch and then forwarded to the client.

Book tip: “Security in a Web 2.0+ World: A Standards-Based Approach” by Carlos Solari

Monday, June 15th, 2009

I went to hear Carlos Solari speak here in The Netherlands last week, and his message makes a lot of sense: to create truly secure infrastructures, devices and services, all components must be built using the ‘SBD’ or Security By Design principles.

Solari and his team put forth the view that to create a fully secure chain of trust (because trust is as important as security, if not more) the IT industry needs a verifiable, certifiable standard method of testing the eight factors they propose to enable manufacturers and developers to create truly secure products.

Aside from the solid message, Solari is a great speaker with an impressive career: the armed forces, then the FBI, followed by a couple of years as CIO for the Executive Office of the President at the White House. Now with Alcatel-Lucent’s Bell Labs as VP of security solutions, Carlos Solari is spreading the word on security, trust and reliability as inherent parts of any solution.

The book is “Security in a Web 2.0+ World: A Standards-Based Approach” and I recommend it. Amazon link here.

Cisco Nexus 1000V – a true switch for Vmware

Wednesday, February 25th, 2009

The Cisco Nexus 1000V has been available for a while but I just realised I hadn’t raved about it yet, so here goes: it’s quite possibly one of the best examples of ‘technology A meets technology B and creates a beautiful baby’ I’ve seen in the past year.

The ‘normal’ Cisco Nexus series of switches are datacenter switches that can bully all lesser switches into handing over their lunch money, especially the flagship Nexus 7000 Series, whereas most VMware admins and engineers know that the basic vSwitches that are used inside VMware are cute but very limited, basically Corkies used to link the outside world to the VM world somewhat intelligently but with no real control.

Now Cisco has addressed this issue by giving us the Nexus 1000V: a fully functional virtual switch (read: vSwitch replacement) that provides the same flexibility and manageability we network geeks are used to from the Nexus and Catalyst model switches. Almost 100% the same command line, configuration options and tweakability that you’re used to, but geared completely to seamless integration with your VMware infrastructure. It’s a sweet package and a very well-deserved winner of the Best of VMware 2008 award in the “New Technologies” category. All that and it’s Vmotion-aware and -integrated as well.

As a both a (Cisco fanboy) network engineer but also a VMware engineer and admin I see this marriage as the start of something beautiful. Let’s hope Brocade is working on a fully functional Fibre Channel virtual switch to really get the party started!

Update (26-Feb): As noted in the comment from Cisco below: “availability is tied to the next upgrade to ESX from VMware. Our target is first half of 2009″. So, still some waiting to do…damn ;-)   Thanks for the heads-up, Omar!

Network performance on VMware

Monday, December 8th, 2008

For the past month or so I’ve been working on a problem a client has with his VMware farm(s).
They’re using Vizioncore vReplicator to replicate VMs from their production farm (containing three VMware ESX 3.5 servers connected to an HP EVA fibre SAN) to their backup facility (two VMware ESX 3.5 servers with a similar HP EVA SAN). All ESX servers use multiple 1 Gbit/sec network links to an HP ProCurve switch, which is connected to its siblings by 10 Gbit/sec fibre links.

What I’ve found so far is:

  • VM performance is OK, average is 400 Mbit/sec, which is not optimal but acceptable on a Gbit link.
  • Service Console performance is quite sub-par: the average is about 120 Mbit/sec, which is quite slow, especially because vReplicator uses the SC port(s) to access the VMs and perform the replication.
  • The speed of the SC port(s) is limited by the maximum capacity of a single CPU core. This is by design and cannot be altered. As soon as we start a large file transfer over an SC port the CPU0 core shoots up to around 100% and stays there for the duration of the copy.

So far we haven’t been able to find a fitting solution for this problem, but I thought I’d share my findings here because there is not a whole lot of information out there on these performance issues. The support engineers at Vizioncore and VMware have been quite good and very helpful, but it seems that we’re running into set boundaries within the VMWare ESX Server. The Service Console is basically a VM itself, but with a fixed upper limit of CPU power available of 100% of the first CPU core. Add to that that vReplicator can only use SC ports, and you have our problem right there.

I do like working with VMware and also quite like using vReplicator, but these limits are something to keep an eye on when you’re planning to run large replications, especially if you want them to run within a certain time frame.

I’ll update here if and when we find a cure for this problem…

Stacking Cisco switches with StackWise

Sunday, August 3rd, 2008

If your switching infrastructure needs something bigger than a standalone LAN switch but not quite as big (and expensive) as a modular chassis, you might want to consider stacking your switches. Cisco offers their StackWise feature on the Cisco Catalyst 3750 series switches, and StackWise Plus on Catalyst 3750-E series.

What StackWise basically does is build one big switch by intelligently joining several individual switches together (with a maximum of nice switches total). The switches are united into a single logical unit using special stack interconnect cables that create a bidirectional closed-loop path. The bidirectional path acts as a switch fabric for all the connected switches, where network topology and routing information is updated continuously through the stack. All stack members have full access to the stack interconnect bandwidth (32 Gb).

The stack is managed as a single unit by a master switch, which is elected from one of the stack member switches. Any stack member switch can become master, and election is done my one of these methods:

  1. User priority-The network manager can select a switch to be master.
  2. Hardware and software priority-This will default to the unit with the most extensive feature set.
  3. Default configuration-If a switch has preexisting configuration information, it will take precedence over switches that have not been configured.
  4. Uptime-The switch that has been running the longest is selected.
  5. MAC address-Each switch reports its MAC address to all its neighbors for comparison. The switch with the lowest MAC address is selected.

When one master switch becomes inactive and while a new master is elected, the stack continues to function.

To build StackWise connections you need (at least two) of either of these cables:

  • CAB-STACK-50CM= (0.5-meter cable)
  • CAB-STACK-1M= (1-meter cable)
  • CAB-STACK-3M= (3-meter cable)

The reason you need at least two cables (or more precisely: X + 1, where X is the number of switches in the stack) is that the stacking cables must form a ring, as the connections are bidirectional, and without the ring a failure of one of the cables would break the stack with all manner of nasty things happening to your network. In a correct configuration a stack cable failure will halve the capacity but the stack continues functioning, while after the failed cable starts functioning again full capacity is automatically restored.

The main differences between StackWise (supported on 3750 and 3750-E series) and StackWise plus (only supported on 3750-E series) are:

  • StackWise plus performs destination stripping, where StackWise only supports source stripping. What this means is that with source stripping a unicast packet that is sent on the stack ring goes around the whole ring and is removed (i.e.: stripped) by the sender of the packet (i.e.: the source switch). With destination stripping the target switch of the packet removes it from the ring, freeing up bandwidth on the ring sooner.
  • StackWise Plus supports local switching, where StackWise doesn’t, forcing all packets on the stack ring. On a StackWise Plus stack any traffic destined for a node connected to the same member switch stays within that member switch, and doesn’t use the stack ring at all.
  • StackWise Plus will support up to 2 line rate 10 Gb Ethernet ports per switch.

You can build a stack consisting of a mix of 3750 and 3750-E switches, in that case only StackWise features are available with the exception of the local switching, the 3750-E’s will still do that.

All in all the StackWise feature is quite nice. Just as with RAID arrays you can build a resilient and easy to manage system by using relatively inexpensive devices. Management is almost as easy as managing a single switch, and most of the features that make StackWise worthwhile and in some respects even great are automatic and do their thing quietly and without fuss. Good stuff.

Cisco TelePresence is pretty cool, actually

Thursday, July 24th, 2008

Yes, this is a glitzy marketing video, and yes, the product itself will probably cost an arm, a leg and selling your soul to the devil, but still I’d quite like to have this and work with it. Of course, that would mean I’d need to shave more often before going to work…

You need to a flashplayer enabled browser to view this YouTube video

Full product info here @ Cisco.

Using EtherChannel for high availability on Cisco switches

Monday, July 21st, 2008

When building high availability networks or systems the three golden rules are:

  1. No single points of failure
  2. All failovers are automatic and swift
  3. Use non-proprietary technologies where possible

When coupling server to the network I myself quite like using EtherChannel. EtherChannel allows multiple physical Ethernet links to combine into one logical channel, which allows the links in the channel to share traffic load, as well as redundancy in the event that one or more links in the channel fail. So you have at least two cables linking a server to a switch, and with some intelligence in setting up the link you both double the bandwidth available to that server and make sure that a dead cable doesn’t leave your server dead in the water and you racing to the data center.

Equipment used

As a big friend of Cisco equipment I’ll use a Cisco switch to show the configuration at the switch end, although many other managed switches from other brands do support the EtherChannel standards as well. Of course the server (or in fact the network card) also needs to support the configuration, I’ll be using an HP ProLiant server today with an HP Dual Port ProLiant Network Adapter (again, other brands of course also support this configuration).
Another note: All commands used below are Cisco IOS commands. if you’re using a switch running CatOS please scroll to the end of this article for a short recap of the used commands for CatOS.

First you’ll need to check if your switch supports EtherChannel by using the show command on one of the ports you’d like to use, and look for the ‘Channel’ key word:

asp-lsw-01#show interface Gi1/5 capabilities
GigabitEthernet1/5
Model: WS-C4948-RJ-45
Type: 10/100/1000-TX
Speed: 10,100,1000,auto
Duplex: half,full,auto
Auto-MDIX: no
Trunk encap. type: 802.1Q,ISL
Trunk mode: on,off,desirable,nonegotiate
Channel: yes
Broadcast suppression: percentage(0-100), hw
Flowcontrol: rx-(off,on,desired),tx-(off,on,desired)
VLAN Membership: static, dynamic
Fast Start: yes
CoS rewrite: yes
ToS rewrite: yes
Inline power: no
SPAN: source/destination
UDLD: yes
Link Debounce: no
Link Debounce Time: no
Port Security: yes
Dot1x: yes
Maximum MTU: 9198 bytes (Jumbo Frames)
Multiple Media Types: no
Diagnostic Monitoring: N/A
Queuing: rx-(N/A), tx-(1p3q1t, Sharing/Shaping)
asp-lsw-01#

Hooray, my switch understands EtherChannels. To check the capabilities of your network card you’ll have to refer to the manufacturer’s information I’m afraid.

Cabling

As Cisco puts it:

The EtherChannel should start on a single device and end on another single device. The device can be a switch, a switch stack, a workstation, or a server.

  • Within a single switch chassis, the EtherChannel can start or end on different modules. This setup is applicable for Cisco Catalyst 4000/4500/6000/6500 switches.
  • Within a single switch stack, the EtherChannel can start or end on different stack members.

Do note that CatOS-based Cisco switches do have stricter requirements on EtherChannels, basically you can only create EtherChannels on adjoining odd/even pairs, otherwise the switch will not accept your port selections.

Rule of thumb on cabling: never ever connect a cable to a port on your network without configuring it first! Especially connecting multiple cables to the same end device can produce some very unexpected and nasty results on your network as for example STP goes haywire on ill-configured ports and disables entire trees of switches on your LAN. Connect the cables only after finishing your configuration.

Understanding EtherChannel negotiation and port mode

EtherChannel ports can use two protocols for EtherChannel negotiation: either the Cisco-proprietary PAgP or LACP (IEEE 802.3ad). I generally prefer using accepted cross-brand standards (see HA golden rule 3 above) , so we’ll use LACP here as well. When setting an EtherChannel mode in a Cisco switch, your choices are ‘on’, ‘off’, ‘active’, ‘passive’, ‘desirable’ or ‘auto’. Each mode setting forces a particular negotiation protocol and behaviour as such:

Mode Negotiation Operation
on None Enables EtherChannel, does not negotiate
off None Disables EtherChannel
active LACP Initiates negotiation to enable EtherChannel
passive LACP Responds to received negotiation requests
desirable PAgP Initiates negotiation to enable EtherChannel
auto PAgP Responds to received negotiation requests

I shall not bore you with the pros and cons of using negotiation vs. fixed configuration, you will have to decide for yourself here whether you’ll use on or active mode. In this example I’ll be using active mode.

Configuring the switch

As an EtherChannel uses multiple ports, you will have to repeat these steps for all ports you wish to couple in this channel.

1. Set the port to switchport mode (optional, only necessary on L2/L3 switches):

asp-lsw-01(config)#int Gi1/5
asp-lsw-01(config-if)#switchport

2. If you’re using VLANs, set the port to access mode for the correct VLAN (I’m using VLAN 2 in this example):

asp-lsw-01(config-if)#switchport access vlan 2
asp-lsw-01(config-if)#switchport mode access

3. As this ports connects to a server directly (as opposed to a part of the network infrastructure such as another switch) you can enable portfast, thus shortening the time the port takes to become active. Never ever enable portfast on ports connected to other switches etc.

asp-lsw-01(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to
a single host. Connecting hubs, concentrators, switches, bridges,
etc... to this interface  when portfast is enabled, can cause
temporary bridging loops. Use with CAUTION
%Portfast has been configured on GigabitEthernet1/5 but will
only have effect when the interface is in a non-trunking mode.

4. Configure the port for EtherChannel using the mode you chose earlier. Make sure you use an unused channel group number.

asp-lsw-01(config-if)#channel-group 1 mode active
Creating a port-channel interface Port-channel 1

This concludes the configuration of the switch port (don’t forget to perform these steps on all ports that have to be linked in the EtherChannel!).

Configuring the server

As we’re using an HP ProLiant server we can configure the EtherChannel using the HP Network Configuration Utility. Other brands and types will have their own drivers and software to get this done. One thing to keep in mind is that the NIC software may not call the setup “EtherChannel” but may use other terms like “Teaming” (which is what HP calls it).

1. Start the HP Network Configuration Utility (from the task bar of the Start menu):

2. Select both listed NICs and click the ‘Team’ button. This will immediately create the team:

3. Select the team and click the ‘Properties’ button:

4. Pick the appropriate Team Type Selection, in our case “802.3ad” (which is the IEEE standard number for LACP):

5. Choose the Transmit Load Balancing Method from the next drop-down list, and click ‘Ok’ after you’ve made your selection.

6. Apply the configuration, after which the server will want to reboot. After the reboot, go back to the HP Network Configuration Utility to check that the Teaming is functioning as expected (i.e.: showing a green icon).

If all went well you should now have a new network adapter in your Windows network configuration. This is the adapter you will use to configure the network from now on (i.e.: IP address, file and printer sharing, etc.).

More, more, more…

Now that you have an EtherChannel link to your switch, ponder in this: what if the switch fails? You would in fact still lose connectivity to the server. Yowsa. Remember HA golden rule number 1: No single points of failure. You could actually create two EtherChannels (so using four network cables in total), each to a separate but interconnected switch, thus ensuring that even a switch failure wouldn’t kill the traffic to your server. If both switches are configured properly STP (Spanning Tree Protocol) will disable one of the EtherChannels while the primary is active, but will fail over to the second link if the first one dies.
How far are you willing to go for HA?

CatOS: a slightly different approach

If your Cisco switch happens to be running CatOS, the EtherChannel modes and the commands to configure the switch ports are somewhat different. The modes are:

Mode Operation
on Enables EtherChannel, does not negotiate
off Disables EtherChannel
desirable Initiates negotiation to enable EtherChannel
auto Responds to received negotiation requests

Using the same example as before the commands on CatOS would be:

1. assign the ports to the correct VLAN (VLAN 2 in this example, being set on ports 5/1 and 5/2 (as CatOS works with port sets)):

old-sw-01 (enable)set vlan 2 5/1-2
old-sw-01 (enable)set trunk 5/1-2 off

2. Enable portfast (optional):

old-sw-01 (enable)set spantree portfast 5/1-2 enable

3. Enable EtherChannel on the port set:

old-sw-01 (enable)set port channel 5/1-2 mode on

4. Set the load distribution method:

old-sw-01 (enable)set port channel all distribution mac source

This concludes the configuration of the switch ports, as you can see you don’t need to repeat these steps on CatOS as you’ve just configured both ports in the set in one go.