Cisco Solutions for VMware View 4 – Design Guide

By Shannon McFarland - Last updated: Thursday, February 4, 2010

Hey folks,

Yes, I have fallen off the planet.  I have been so engulfed in lab work, architecture specifications and speaking engagements that I have had zero time for anything else.  I almost forgot I had a blog. :-)

I recently posted a Cisco Validated Design (CVD) for VMware View 4.  This is a comprehensive guide for what Cisco can offer to those who are planning, deploying or have deployed a VMware View 4.o environment.

This effort is what I call a “phase 1″ effort.  Which is a focus on immediately offering a better user experience via WAN optimization via Cisco WAAS and WAAS Mobile, server load balancing (SLB) and SSL offload via Cisco ACE, basic perimeter protection via Cisco ASA, virtualized network access via Cisco Nexus 1000v and finally, basic QoS.

Phase 2 and beyond will include all kinds of stuff to include more comprehensive security for the View Agent, View Client and network security.  Other stuff will be included over time.

Take a look at the guide.  It is viewable online and via PDF (far right hand side).

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/vmware/cisco_VMwareView.html

Let me know your thoughts.

Shannon

Filed in Networking, Virtualization • Tags: , , , , , , , , , ,

Texas IPv6 Task Force – Houston

By Shannon McFarland - Last updated: Tuesday, November 3, 2009

There is still time to attend the 2-day Texas IPv6 Task Force event in Houston.  If you are local to Houston then you may want to show up.

November 3-4, 2009 The Planet
9AM to 4PM 315 Capitol Street, Suite 205
Houston, Texas 77002

http://www.txv6tf.org/?page_id=3

I will see you there,

Shannon

Filed in IPv6 • Tags: ,

Yes kids, the Cisco IOS IPv6 General-Prefix feature is cool

By Shannon McFarland - Last updated: Monday, August 24, 2009

The Cisco IOS IPv6 General-Prefix feature has been around for awhile and has not been that widely used until lately.  I have met with several customers who deployed the feature during their pilot deployments of IPv6 when they were using an RFC4193 Unique Local Address (ULA) or some temporary IPv6 prefix such as the RFC3849 IPv6 documentation prefix.  They started out with one of these address prefixes until they were ready to use a provider-assigned or provider-independent prefix for production use to the outside world.

First off what is it?  IPv6 General-Prefix is a feature developed by Cisco that allows you to associate a friendly/user-defined name to an IPv6 prefix.  This friendly or user-defined name is then used on the interfaces of a switch or router in replacement of a fully defined prefix string.  An example:

6k-agg-1(config)#ipv6 general-prefix ESE-DC-1 2001:DB8:CAFE::/48

The global configuration string above states that we are defining a friendly name of “ESE-DC-1″ and associating this with the IPv6 prefix of “2001:DB8:CAFE::/48.  Now we can use this name on our interfaces instead of identifying the entire prefix by hand each time:

6k-agg-1(config-if)#ipv6 address ESE-DC-1 ::10:0:0:F1A1:6500/64

We can see the full details of the address using normal show commands:

6k-agg-1#show ipv6 interface vlan 10

Vlan10 is up, line protocol is up

  IPv6 is enabled, link-local address is FE80::211:BCFF:FEC0:C800

  Description: VLAN-SERVERFARM-WEB

  Global unicast address(es):

    2001:DB8:CAFE:10::F1A1:6500, subnet is 2001:DB8:CAFE:10::/64  

Ok great, I can save myself some typing by using this friendly name business.  What does this really do for me.  Well, this allows you to very rapidly change, add or remove entire prefixes from a switch or router using a single command.  For instance I know many accounts who were using ULA prefixes before connecting to the Internet over IPv6.  When they needed to add or change to something like a Provider-Independent prefix they simply edited their general-prefix name (in the global configuration) and all of the subordinate addresses interfaces associated with that prefix change to the new prefix.  Pretty cool huh?

Limitations:

-General-prefix is locally significant to each switch or router

-It does not work with ACLs or other policies that could or do use names (it would be super cool to have this feature work so that you could conditionally change the general-prefix and have it also change the prefixes of all ACLs using the same name as the general-prefix name…hmm, potential roadmap item. :-) )

Other considerations:

-You can use pretty much any prefix length (both on the general-prefix command and the subordinate interfaces)

-You can have multiple general-prefixes defined (just so they do not have the exact same name or exact same prefix).

More info can be found at the Cisco IOS documentation site:

http://bit.ly/jSJ96

Shannon




Filed in IPv6 • Tags: ,

Dual-stack is Abandoned?

By Shannon McFarland - Last updated: Monday, August 3, 2009

I am way, way behind on my entries and I am sorry about that.  I am trying to catch up on IPv6 stuff as I have been blasting away at various Microsoft, VMware and Cloud projects.

On vacation last week I tried to get caught up on some reading and watched some archives of the recent NANOG meeting (NANOG 46 in June 2009 http://www.nanog.org/presentations/archive/index.php) – yes sadly enough I do this on vacation.  I viewed Dave Ward’s interestingly titled talk “It’s The End Of The World As We Know It (aka “The New Internet Architecture”)” – http://bit.ly/QOAVg.  Dave had many good observations and I agree with many of his comments except one – “Dual-stack transition to IPv6 abandoned”.  As someone who works with enterprise customers each and every week for IPv6 design and deployment I can safely say that dual-stack is alive and well and IS the most “pure” way of IPv6 deployment that we have today.  Yes, there are operational and even security and performance challenges with running two stacks simultaneously but until something better comes along, dual-stack is all we have that gets us away from tunnels.

I know Dave is not arguing one way or the other but simply stating his views on where things are and where they may go and that is cool but I feel it is a bit radical to state that the number one methodology for IPv4/IPv6 co-existence is abandoned.

What are your thoughts on various co-existence mechanisms TODAY vs. what is being proposed by the IETF for the future?

Shannon

Filed in IPv6 • Tags: , , , ,

Login VSI 1.0 Issues with VMware View 3.1

By Shannon McFarland - Last updated: Wednesday, June 17, 2009

I have used Login Consultants Login VSI 1.0 tool for a number of desktop virtualization research projects and I recently fired it up again for some VMware View 3.1 RDP over HTTP/HTTPs traffic profiling for QoS and Cisco WAAS/WAAS Mobile.

Login VSI does not natively support/use the VMware View client (it launches an RDP/ICA session directly from the launcher application).  For my purposes all I needed was a few clients to run the Login VSI test scripts via the VMware View client.  I did not really need the launcher for my purposes other than to create the required profiles on the VMware View Agent VM.

I used the VMware View client application to setup a session (via the VMware Connection Server) to a VM that had the Login VSI target deployment configured.  Once my test user logged in the test script ran perfectly right up until the script tried to print a MS Word document to PDF.  View redirected the Microsoft Office XPS Writer installed on the VMware View client machine to the View session running on the VM and hosed to whole thing.

Here you see the status of the test run and the pop-up is pushing the print job to the local View client using the XPS writer vs. the PDF writer installed on the VM.

vsi-error1

The script selected the XPS writer as it seemed to think the redirected printer was more important than that actual default printer setup on the VM (Login VSI sets up a PDF writer and makes it the default).

vsi-error2

After a little poking around I realized that the ThinPrint installation that comes with VMware View was the culprit and that it is not so easy to keep ThinPrint from taking over printer redirection for these sessions.  I combined through a variety of documentation and support sites  (very very poor info on ThinPrint and VMware View configuration) and found a few registry hacks but none of them really worked, at least not for me.

To get this testing done I simply went into the MS Vista machine that I was using as the VMware View client and deleted the XPS printer (the only printer installed on that client).  All is now good in the world.

Here you can see that the PDF writer installed by the Login VSI target installer is selected and the script continues to work.

vsi-error3

The test runs to full completion using Login VSI 1.0 with a VMware View 3.1 Client.

If any of you find a real good way to go in via GPO, the registry via TPautoconnect (I have tried a boatload of switches and set the “ConnectToClient” to DISABLE and all of that stuff) or something else that might work better, please fire over a comment.

Also, if anyone from Login Consultants reads this – I love the tool but please make an uninstall option so I can back the agent and launcher stuff out. :-)

Shannon

Filed in Virtualization • Tags: , , , ,

VMware vSphere With IPv6 – First Look

By Shannon McFarland - Last updated: Monday, June 15, 2009

My team lives in the world of Cisco, VMware and Microsoft.  In addition to those vendors I focus on all things Enterprise IPv6.  Based on that I am always looking for applications, tools, services, blah, blah that can leverage IPv6.

I have captured a few screenshots for the initial setup of VMware vSphere 4.0 over IPv6.  This is not a comprehensive review of all features, capabilities and issues but just a few items I discovered in the initial setup.

First, the VMware documentation for IPv6 is sad.  There is little information about what is supported/not supported and any caveats around IPv6 usage.
You can enable IPv6 on the ESX host in couple of two ways:
-During the installation screens
-Via the ESX host network configuration screen

blog1

Once you enable IPv6 on the host (via the network configuration screen) you will need to reboot the host in order to get IPv6 to function properly.

ifconfig on the ESX 4.0 host:
vswif0    Link encap:Ethernet  HWaddr 00:50:56:4D:C3:5C
inet addr:10.121.11.16  Bcast:10.121.11.255  Mask:255.255.255.0
inet6 addr: 2001:db8:cafe:11::16/64 Scope:Global
inet6 addr: fe80::250:56ff:fe4d:c35c/64 Scope:Link

UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:820739 errors:0 dropped:0 overruns:0 frame:0
TX packets:543688 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:118940957 (113.4 MiB)  TX bytes:483159883 (460.7 MiB)

We need to provide an IPv6 address for the Service Console.  I did this via the Service Console Properties > IP Settings screen.  You have the option to obtain IPv6 addressing via DHCP, Router Advertisements or Static address:

blog2

The Global IPv6 and Link-Local address can been seen in the vSwitch port properties for the Service Console:
blog3
The ESX host will receive an RA (Router Advertisement) from the local default gateway (if IPv6 is enabled) and the host will be able to get off-link.  It is a best practice, however, to use a static definition for your gateway.  I am using the LL address from my upstream HSRPv6 virtual LL address on two Cisco Catalyst switches.

blog4

We can ping off-link (pinging a Cisco ASA Firewall):
[root@esx-64-vm3 ~]# ping6 -I vswif0 2001:DB8:CAFE:10::DA61
PING 2001:DB8:CAFE:10::DA61(2001:db8:cafe:10::da61) from 2001:db8:cafe:11::16 vswif0: 56 data bytes
64 bytes from 2001:db8:cafe:10::da61: icmp_seq=0 ttl=64 time=2.30 ms
64 bytes from 2001:db8:cafe:10::da61: icmp_seq=1 ttl=64 time=0.416 ms
64 bytes from 2001:db8:cafe:10::da61: icmp_seq=2 ttl=64 time=0.370 ms
From the VMware vSphere Client we will try to connect to the ESX 4.0 host over IPv6.  You can do this via the DNS name (using an AAAA record) or via the IPv6 address directly:

blog5

You will certainly want to do this via DNS for the sake of operational ease but also due to the fact that your console will show the IP address instead of its name:

blog6

Open a connection to the vSphere vCenter box:

blog7

A netstat on the box running the vSphere Client shows server TCPv6 sessions to the vSphere vCenter box:

blog8

Stuff that does not work at this point:

The vSphere client configuration does not have a place to enter DNS over IPv6 information:

blog9

Also, the iSCSI configuration properties do not have an input check that screams at you when you enter an IPv6 address in literal format.  It should as you normally state the iSCSI port behind the IP address.  Here you see that I have an IPv6 address and the vSphere client adds the default port number behind it.  There is no way for the system to know what is the address (separated by colons) from the TCP port number (also separated by a colon):
blog9-1

VMware should add support for some kind of input checker to ensure you are not allowed to do this and they should also add support for bracket-style addressing such as [2001::1].  If you try this in the client you get this error:

blog10

So, you can add IPv6 addresses and gateways on Service Consoles, certain VMkernel configurations and actually use the vSphere Client to access the host over IPv6.

Stay tuned as I find out more stuff like vMotion and other VMware doodads with IPv6.

Shannon

Filed in IPv6 • Tags: , , , , ,

Microsoft WS08 R2 Hyper-V Feature Summary

By Shannon McFarland - Last updated: Friday, June 5, 2009

A little dated but this gives a video update of the summary features coming with WS08 R2 Hyper-V. In my book they still have a ways to go but I like the direction they are headed


Ask Iain: Virtualization

Filed in Microsoft Stuff, Virtualization • Tags: , , ,

IPv6 support in VMware vSphere

By Shannon McFarland - Last updated: Thursday, June 4, 2009

Our team is doing a boatload of testing with various Microsoft OS/Apps on vSphere and we will be enabling the new IPv6 functionality to see what is there and what is missing. Stay tuned as I report the goodness and not-so-goodness of VMware’s support for IPv6.

Filed in IPv6 • Tags: , , ,

Part 1 – IPv6 drivers for the enterprise

By Shannon McFarland - Last updated: Wednesday, June 3, 2009

I have been helping SP and enterprise customers with their IPv6 planning and deployment since about 2003.  These customers have been from all over the world so I have gathered a variety of drivers based on geography as well as market segment.   I have had more customer engagements in the last year than all previous years combined.  MANY enterprise customers from around the world are in research, planning, pilot or full deployment modes and they have a wide range of reasons for doing so.  Let’s talk about a few of the many that I see.

-Expansion into emerging markets

-OS upgrades that have IPv6 enabled by default

-Mergers/Acquisitions that force NAT overlap

Expansion into emerging markets

Enterprise business expansion into emerging markets is one area that has become a driver for IPv6.  I have worked with many customers who are either expanding for the first time into an emerging market or expanding their existing operation in those markets.  The challenge many businesses face in some markets is access to routable IPv4 address space.  I have a few customers that are expanding existing operations in China and they cannot get additional IPv4 address space but IPv6 is available.  So they are trying to figure out how to manage IPv6-only connections in China and allow those sites to establish connections into the main sites in the US (more on this in another blog).  Recently I worked with a customer who could not get a single IPv4 address to use for their IPsec VPN service.  IPv6 technically solves this issue with little issue but many US customers still struggle with getting IPv6 access from even the largest SPs to complete the connection.

OS upgrades that have IPv6 enabled by default

Microsoft Windows Vista, Server 2008/R2 and Windows 7 come with IPv6 enabled by default.  If the conditions are right IPv6 will be preferred over IPv4 and the customer has to make a decision to either kill IPv6 or embrace it.  Most are killing it until they get a handle on what it is and what they can do with it but some are embracing it.  Those that are killing it are doing so for the right reasons – lack of education, time, budget and quite frankly their IT staff is loaded with priorities and little time and budget to meet those priorities so adding something with no obvious advantage is just plain stupid.  Those customers who are embracing IPv6 are doing so with caution, in depth education, planning and pilots.  In the end I have not seen one that yanked out their IPv6 deployment.  Once they figure out how the network, OS and application environment operate in an IPv6 deployment they stick with it.  In fact most want to get rid of IPv4 to deal with the operational and capital cost of running two protocols.

One example of the lack of knowledge about OS IPv6 capabilities is when I got a call from an account that had upgraded most of their data center from Windows Server 2003 to Windows Server 2008 and realized that their apps still worked but their network instrumentation that monitored IPv4 had reported a severe drop off in traffic.  They were perplexed as the servers were running the same load but server-to-server traffic seemed to have vanished.  After some research it was discovered that all of the servers within the same VLANS were using IPv6 link-local addresses to communicate with each other and had stopped using IPv4 all together.  The good thing is that operations did not stop but they lost complete visibility into what was happening due to the fact that they had IPv6 disabled in their management systems.  Luckily they enabled IPv6 monitoring and left most of the IPv6 deployment intact but this does go to show you that you cannot assume that one OS will work the same even between upgrades.

Mergers/Acquisitions that force NAT overlap

M&A can force IT shops to come up with some creative ways to deal with the IPv4 address collisions that occur when you join to entities that use RFC 1918 addressing.  Some will fully readdress the acquired site (horrifically painful) and others will try to buy some time by using NAT overlap pools.  They NAT overlap pools are pools of IPv4 address that fall into a scope that is not used by either entity or at least they are a scope that is outside of the colliding space.  This allows the sites to NAT into and out of this pool for the purpose of accessing resources until they can readdress.  One account I worked with had 9000 static NAT entries on their gateway routers to account for NAT entries for servers, printers, etc…  IPv6 can help solve this issue as you can deploy an IPv6 overlay deployment that is fresh (no collision) and well thoughtout.  This overlay model can consist of tunnels or a fully functional dual stack (IPv4 and IPv6 runnint simultaneously) implementation.  The figure below shows what this might look like:

m-a-nat

You can see that all three sites use the RFC 1918 10.0.0.0 address space.  So the short-term (could be long-term) solution is the create a NAT overlap pool and static entries on their edge gateways.  Using IPv6 they can deploy an IPv6 overlay model where they can leverage a combination of tunnels and dual stack to connect the network, server and application components between sites.  For those applications or OSes that cannot support IPv6, they simply run the IPv4 NAT overlap pool (albeit a much smaller pool now) to support those legacy systems.

Filed in IPv6 • Tags: , , , , , ,

IPv6 Deployment – Goals/Disclaimer

By Shannon McFarland - Last updated: Tuesday, May 19, 2009

This is my goal and disclaimer for a multi-part series focused on deploying IPv6.  I am an enterprise guy so the things I care about are related to IPv6 deployment in the campus, branch/WAN, remote access, internet edge and data center.  We will walk through some of the top careabouts related this these ‘places in the network’ (PINs) and how you can implement IPv6 in them today.

Please understand that my view of the world comes through Cisco-colored glasses but I do have intimate understanding of other environments such as Microsoft, VMware, Oracle, Citrix and many others.  I will offer IPv6-specific details on environments I am familiar with, but I will also try to link you to resources that can help with other areas.

My goal is to provide you chewable, bite-sized chunks of technical information related to deploying IPv6 in an enterprise using Cisco gear as well as other stuff associated with a Cisco implementation of IPv6.

Disclaimer: I will most certainly leave important stuff out such as DNS with IPv6, network management (I hate this topic) and probably even important stuff related to security (hey, I can’t know everything).  Bare with me and provide feedback on stuff you are interested in knowing.

Hold on  – the fun begins with the next post labeled “Part 1 – IPv6 drivers for the enterprise”

Shannon

Filed in IPv6 • Tags: , ,