I am stuck on AT&T DSL (service has been mostly stable) and have no access to Verizon or Comcast in my area so I am still stuck with tunnels using brokers and the performance pain that goes along with that.

I want real IPv6 connectivity from my ISP and I want it now, if not, before then.  Doing Netflix over a broker connection sucks.

C’mon AT&T, get your crap together and offer your subscribers IPv6 access…even as a pilot.

There is nothing interesting in this post except for me whining.

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

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

I will see you there,

Shannon

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  

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

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.

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).

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.

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

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

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:

The Global IPv6 and Link-Local address can been seen in the vSwitch port properties for the Service Console:

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.

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:

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:

Open a connection to the vSphere vCenter box:

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

Stuff that does not work at this point:

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

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):

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:

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

Ask Iain: Virtualization

-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:

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.