Sunday 13 February 2011

Virtualization Still Calls Data-Center Tune

As the latest VMworld begins its transformation from current event to memory, now probably is as good a time as any to reflect on what it all means, if anything, for the future of data centers, the IT industry, and various big-name vendors.
There has been a lot of talk about public, private, and hybrid clouds at VMworld, but I think that’s something of a side issue. Yes, certain enterprises and organizations will partake of cloud services, and, yes, many enterprises will adopt a philosophy of IT as service within their data centers. They’ll make data-center management and automation decisions accordingly.
Even so, at a practical level, it is virtualization that continues to drive meaningful change. The  robust growth of virtualization has introduced problems (optimists would call them opportunities), too. How do you automate it, how do you manage it, how do you control it so that it remains a business asset rather than a potential liability?
Reciprocal Choking
At a fundamental level, that’s the big problem that data centers, whether within enterprises or service providers, must solve. The ultimate solution might involve data- center convergence — the integration and logical unification of servers, storage, networking, and orchestration — but it’s not clear whether that is the only option, or whether the price of vendor lock-in is worth the presumed benefit. Most enterprise customers, for the time being, will resist the urge to have one throat to choke, if only because they fear the choking might be reciprocal.
Indeed, as the vendor community has reacted to the popular appeal of data-center virtualization, the spectacle has been fascinating to watch. Who will gain control?
It’s not a simple question to answer, because the vendors themselves won’t have the final say; nor will the industry’s intelligentsia and punditry, formidable as they may be. No, the final arbiters are those who own, run, and manage the data centers that are being increasingly virtualized. Will network managers, or at least those with a strong networking sensibility, reign supreme? Will the leadership emerge from the server, application, or storage side of the house? What sorts of relationships will  these customers have with the vendor community, and which companies will serve as trusted counsel?
Ownership of Key Customer Relationships
As virtualization, by necessity, breaks down walls and silos, entirely new customer relationships will develop and new conversations will occur. Which vendors will be best positioned to cultivate or further develop those relationships and lead those conversations?
Meanwhile, vendors are placing their bets on technologies, and on corporate structures and strategic priorities. HP is an interesting case. Its Enterprise Servers Storage and Networks (ESSN) seems increasingly titled toward storage and servers, with networking — though not an insignificant consideration — relegated increasingly to a commoditized, supporting role. Just look at the executive management at the top of ESSN, both at HP headquarters and worldwide. You’ll notice an increasingly pronounced storage orientation, from Dave Donatelli on down.
Cisco, meanwhile, remains a networking company. It will try to imbue as much intelligence (and account control) as possible into the network infrastructure, even though it might be packaged under the Unified Computing Systems (UCS) moniker. That might not be a bad bet, but Cisco really doesn’t have a choice. It doesn’t own storage, is a relative neophyte in servers, and doesn’t have Oracle’s database or application pedigree.
Dell’s Move
IBM and Dell will be interesting to watch. Dell clearly places a lot of emphasis on owning its own storage technology. It has its own storage offerings right up through the midrange of the market, and it tried hard to buy 3PAR before being denied by a determined HP, which had its own reasons for winning that duel.
Questions remain over the importance Dell attaches to networking. We should learn soon enough whether Dell will continue to partner, with Juniper and Brocade, or whether it will buy its way into the market. To the extent that Dell continues to maintain its networking partnerships, the company effectively will be saying that it deems networking a secondary priority in its data-center strategy. IBM already seems to have made that determination, though there’s always a possibility it will revisit its earlier decision.
This puts Juniper in an interesting position. It needs to continue to push toward its Project Stratus intelligent flat network, thereby enhancing its value to customers and its importance to Dell and IBM as a partner. Brocade faces a similar challenge in storage networking, though it still seems to have a lot of work ahead of it in repositioning the Ethernet-switching portfolio it obtained through its acquisition of Foundry Networks.
Microsoft Pays for Inattentiveness
I have not mentioned Microsoft. VMware threw down a gauntlet of sorts earlier this week when it suggested that the importance of Windows as an operating system had been undercut severely by the rise of virtualization. For the most part, I agree with that assessment. Microsoft has some big challenges ahead of it, and it has been attempting to distract us from its shortcomings by talking a lot about its cloud vision. But a vision, no matter how compelling, is thin gruel if it is not supported by follow through and execution. In virtualization, Microsoft was caught flat-footed, its gaze averted by commotion outside the data center and the enterprise, and it is paying a steep price for that inattentiveness now.
Even though marketing hype has pivoted and tilted toward the cloud, virtualization continues to recast the data center.

Companies slow to adopt NAC technology

Companies are showing little interest in expanding their interest in network access control even though many are interested in such technology.
According to a new report from Forrester, only 10 percent of organisations plan to implement the technology in the coming year. The research company said that security professionals were struggling to deliver business cases to justify the use of the technology
Those companies that are going down the NAC path are overwhelmingly opting for client-side technology. According to Forrester 27 percent of respondents report adoption of a client-side NAC technology. Report author, Usman Sindhu, claimed there were several reasons for this. "Client-side NAC technology is software-based, so IT and security professionals can more easily integrate and manageit," he wrote, adding that during the past 18 months, many security vendors have bundled NAC technology into their client security suite products, thus accelerating its adoption. We're seeing vendors like McAfee and Symantec using NAC as a feature in a suite or a bundled client security offering,"
Conversely, server-side NAC is less popular, only 17 percent of the respondents in the Forrester survey are interested in going down this route. These products include NAC technology integrated into routing and switching infrastructure or operating as separate NAC appliances. Security professionals struggle to make a business case for these devices because of the capital cost involved.
Sindhu makes four predictions for 2011. Firstly greater interest in NAC integrated into broader security offerings will flourish. He said that this had gone beyond security vendors themselves." For instance, Cisco and Juniper are keen on making NAC one feature in the infrastructure security stack. This trend is here to stay and will push other players to abandon the standalone NAC approach"
The second of Sindhu's predictions is that network access control will shift to the layered access control model. "Access control will encompass not only the network but also applications and mobile devices. The term "NAC" will not go away, but it will refer to network, application, and device access control. NAC solution vendors will work with partners to provide a layered access control where the focus is the user, not the device."
Sindhu's third prediction is that hybrid deployment modes will continue to be popular. "Security organisations don't have a clear preference for hardware-based versus software-based NAC deployments," he wrote, preferring to use a combination of deployments. He said that this trend would continue into 2011.
Finally, Sindhu said that in 2011, compliance-driven features will dominate the market. He said that companies would expand their compliance needs by taking on board employee-owned devices such as smartphones and tablets.

A new look at SAN Fabric Switching: Performance, Flexibility and VALUE

In the past, SAN Fabric switches filled a particular niche, offering stripped-down functionality to serve basic connectivity needs, while only director-class products offered greater performance and flexibility. Pure connectivity solutions, without scalability and performance options, are not acceptable in those environments any more. 


 With the introduction of Cisco MDS 9148 Fabric Switch, we’ve raised the bar for SAN Fabric solutions by providing a feature-rich, high performance (8-Gbps line rate) switch which scales non-disruptively in eight-port increments from 16 to 48 ports, all at an entry-level price point.  
The MDS 9148 offers similar value to director-class switches with enterprise features including VSANs, security, non-disruptive firmware updates, and NPV, providing mid-market customers with the versatility and capability needed to grow their businesses. 
Most importantly, not only does the “pay-as-you-grow” model reduce the initial investment, all advanced features continue to be delivered as part of Cisco’s standard SAN package, not as upgrades or separate licenses which add significant incremental costs to competitive solutions. 
To clarify, this Cisco solution is not only for mid-market customers.  Due to its redundancy (including dual power and dual fans), scalability and line rate performance, the MDS 9148 switch is an ideal candidate for deployment in top-of-rack architectures and departmental SANs at larger organizations as well.  The MDS 9148 is powered by NX-OS, a common OS that spans the MDS, Nexus and UCS 6100 families of products. Having a common OS among both storage and Ethernet switches decreases IT’s learning curve and enables greater staff flexibility in large IT organizations.

ESG tested our switch and validates our claims; the ESG Lab found that “the MDS 9148 is a rock-solid, feature-rich, 8-Gbps multilayer fabric switch that cost effectively delivers the benefits of SAN-attached connectivity to small- and medium-size businesses and enterprises looking for affordably powerful edge connectivity.” You can read their report here.
One of our partners in Europe, MTI, tested the MDS 9148 and found that that the VM optimization features in the MDS 9148 makes this an ideal platform of choice for Virtual Machine environments and is very easy to setup and manage. You can read the MTI test report here.

Bit Torrent Killed My Router


Adam's VOIP Setup

I'm a long time Vonage customer and I have a very old Vonage Motorola VT1005 VOIP Router that they gave me when I signed up way back in 2003. It turns out that this box can't handle all the action that Bit Torrent sends its way; something about a limited size of the NAT table not working with the large number of connections opened by Bit Torrent. Typically it needs to be reset at least once a day when any sort of Bit Torrent activity is going on.

Airport Extreme DMZ Setting

The solution is to keep the poor VT1005 out of the way of all that traffic. Instead of using it as your main router, stick it behind something more up to the task, like an Apple Airport Extreme. Of course the VOIP functionality works best if there is no firewall between it and the network at large. The solution to this is to put the VT1005 in the DMZ of your main router. To do this you first need to make sure the VT1005 has a static IP address. You can set this on using the web interface of the VT1005. After that, go to the admin interface for your main router and set this new IP address as the DMZ IP address. On the Airport Extreme this setting is called Enable Default Host, as you can see in the image above.

There are a few other issues to be aware of when dealing with the VT1005. It has an advanced setting so you can disable NAT and put it in bridge mode. This seems like a good idea since it ought to avoid the NAT table explosion, but that solution seems to have the same daily reset issue. Also, it's a bit tricky to get back to the web interface of the VT1005 if you've put it into bridge mode. There is no way to get to the device after that! The trick is to directly connect your computer to the VT1005's PC port and set the IP address of your computer statically to 192.168.102.2 with the gateway set to 192.168.102.1. Then point your browser to http://192.168.102.1/ and you'll be able to change the NAT settings again. Finally, make sure you have the VT1005 set to use the factory MAC address. I was trying to fake out my ISP and set the MAC address to the same number as my Airport Extreme. This will work if you ISP gives you more than one IP address and you're in bridge mode (NAT disabled). But it won't work if the Vonage box is setup in your DMZ. Your router and the computer in the DMZ can't have the same MAC address or things just won't work.

Configuring the Cisco WVC80N on Sensr

I recently found the Cisco WVC80N for sale at Best Buy. I was visiting my relatives in the Midwest and hoping to buy a camera that I could configure for them with sensr.net. To use network cameras with Sensr, you need one that supports FTP. I was disappointed to find that FTP was not listed on the side of the box. Since this was the only network camera they had, and the store was closing in 10 minutes, I did a quick search from my iPhone and found this FAQ, indicating that indeed the camera will support FTP.

I went ahead and bought the camera. It was a bit pricey at $150 but I figured that if it didn't work, I could return it the next day. Best Buy has a pretty decent return policy. In this case that worked in their favor, as I'm sure it does many times.

As with many of these network cameras, the setup software only works on Windows. If you have a Mac or Linux, you'll have to forgo the software install, which in my opinion is probably a good thing. There is no reason you should need to install software on your PC to setup or use a network camera.

So a couple of things I learned. First, by default, the camera will grab an IP address over the ethernet using DHCP. This is pretty standard. The trick with these cameras is to find the IP address that your router gives out. The above mentioned FAQ also says the default IP is 192.168.1.100. This is NOT the case if your network has DHCP, which is probably the case. I found the IP address by looking at the clients table on the home network's router.

The second thing I learned was that the camera doesn't support timed FTP. This means you can't simply have the camera FTP images every second, which is the way I like to setup cameras on sensr.net. As a work around, I turned on Motion Detection for the camera and told it to FTP the images to sensr.net. I then set the motion detection level as sensitive as possible. Unfortunately to set the overall sensitivity, you need to use Internet Explorer, since that configuration is set using an Active X control. Yuck!

The advantage of having Sensr, rather than the camera, do the motion detection, is that the live views are much more interesting. If your camera only sends images to Sensr when there is motion, the Live Preview links from the sensr.net site won't be very interesting.

Sensr does support camera based motion detection. Basically this means motion detection on the sensr.net site is turned off, and we'll assume every image coming from your camera should be saved. (We still have limits on the number of images we'll save, currently 600 per hour.)

Overall I would not recommend the WVC80N. My main gripes are:
  • Lack of timed FTP uploads
  • Active X is required for the web configuration
  • Too expensive
You would be better off buying the Dlink DCS-920 which works well with Sensr and is considerably cheaper.

Learn to configure Cisco IOS NAT on a stick

“NAT on a stick” is not a common Cisco router configuration, but it is a tool that you will want to understand in case you ever have a situation that calls for it.
A well known NAT configuration is called “NAT on a stick.” Besides having a funny name, NAT on a stick can be very useful to network administrators. In this article, learn what NAT on a stick is and how it can help you.

What is Network Address Translation?

Network Address Translation (NAT) is used to translate IP addresses from one network into IP addresses for another network. NAT is performed by a router and is commonly used to translate private IP addresses used in homes and businesses into the public IP addresses that are used on the Internet.
When configuring NAT, there are a number of terms and concepts you need to know. For example: the difference between inside local, inside global, outside local, outside global, NAT vs. PAT, and “NAT overload.”
I don’t recommend that you configure NAT on a stick until you have a good understanding of NAT. I recommend that you try one of the easier NAT configurations prior to NAT on a stick.

What is NAT on a stick?

First, the “stick” is just a single router interface. As NAT is typically performed between two router interfaces, NAT on a stick is used to describe a NAT configuration where a single router interface is used and NAT is performed. Thus, we are really talking about NAT on a single-router interface (but that’s not as catchy, is it?).
For NAT to work, a packet has to be sent from an inside NAT interface to an outside NAT interface. This is still true with NAT on a stick, but we are able to get around having only a single interface because we use a virtual interface to accomplish the same task. You use a policy-based route (PBR) to route and NAT the traffic between the virtual interface, which is a Cisco IOS loopback interface, and the physical interface.
Prior to configuring NAT on a stick, you should make sure that your Cisco IOS supports this feature.
How can NAT on a stick help you?
NAT on a stick is not what I would consider a common configuration. However, I have seen it listed on Cisco certification exam objectives; I have heard Cisco instructors talk about it; and I have had readers ask me questions about it. So, even though you won’t find NAT on a stick in use on most enterprise networks, I think that it is important that you know what it is, how it can help you, and that it is yet another tool available to you, should you need it.
While there are a number of options for using NAT on a stick, here is a scenario in which I’ve seen it in use. (I have selected this scenario because it is based on the official Cisco documentation on this topic where you can go to find more information.)
You have a LAN with a number of computers, a single Cisco router with one Ethernet interface, and a cable DSL modem. Your ISP has given you a single IP address plus a block of two other IP addresses on a different network. Usually, you would get around this by using NAT (actually PAT or NAT overload) with a home/SMB router such as Linksys, Netgear, D-Link, or Belkin. But let’s say that you want to use a Cisco router only, and unfortunately, all you have is a 2501 (single Ethernet and Serial interface). The DSL modem is just a bridge (not a router) and the Cisco router cannot be connected directly to the cable modem because the router only has one LAN interface. You put a small hub in between the DSL modem and the 2501 Cisco router.
While this might sound like a wild scenario to some, and we all agree that you just need to buy more hardware — I don’t want to leave out any possible option that you could consider for using the Cisco IOS to solve a problem. Should this configuration be used on the Internet in production? No. Is it valuable to know how to configure NAT on a stick? Absolutely!

How do you configure NAT on a stick?

The sample configuration below for NAT on a stick is based on the following details: The local LAN is the 192.168.1.0 network. You are given one useable IP address on this network from the ISP, plus a block of two IP addresses on the 192.168.2.0 network. This network has access to the DSL modem. The 10.0.0.0 network is the LAN where you will have as many devices as you want and the devices on that LAN will rely on NAT on a stick.
Remember — the Cisco IOS loopback interface is the virtual interface that helps us get around the “one interface only” issue. Here is what you need to do:

Configure Interfaces with NAT statements and IP policy routing

interface Loopback0
 ip address 10.0.1.1 255.255.255.252
 ip nat outside
interface Ethernet0
 ip address 192.168.1.2 255.255.255.0 secondary
 ip address 10.0.0.2 255.255.255.0
 ip nat inside
 ip policy route-map nat-loop

Configure your NAT pools

ip nat pool external 192.168.2.2 192.168.2.3 prefix-length 29
ip nat inside source list 10 pool external overload

Ensure that you have IP Routes

ip route 0.0.0.0 0.0.0.0 192.168.1.1
ip route 192.168.2.0 255.255.255.0 Ethernet0

Create ACLs for NAT and the Policy Routing

access-list 10 permit 10.0.0.0 0.0.0.255
access-list 102 permit ip any 192.168.2.0 0.0.0.255
access-list 102 permit ip 10.0.0.0 0.0.0.255 any

Create the Route Map that is applied to the Ethernet interface

route-map Nat-loop permit 10
 match ip address 102
 set interface loopback0
 
With this configuration, the PC clients, assigned with 10.0.0.x network IP addresses will be NATed when their traffic arrives on the Ethernet0 interface. That NATing will use the 192.168.2.x pool.
You should note that you will have to configure the router’s primary Ethernet IP as the default gateway for all PCs in the NAT network. Also, you will also have to do ONE of the following:
1. Have the ISP or any other router on the other side of the NAT network create a static route for your 192.168.2.0/29, pointing to your router’s 192.168.1.2 IP address
2. Have your router advertise that network (in #1) via a dynamic routing protocol like RIP, OSPF, or EIGRP
This configuration is based on the example provided in Cisco’s official Network Address Translation on a Stick documentation. Please review it if you have questions on this example as it has a diagram and debug steps.

In Conclusion

NAT on a Stick is one of the many tools that a network admin may need to employ in certain situations. If nothing else, it is a configuration that you should recognize by name if you are asked about it on certification exams or by colleagues. For some admins, it is an irreplaceable tool.