Saturday, October 5, 2013

Recent Posts Personal Connections

A Picture is Worth 1000 vCD Networks skyscrapercity | Complaints Incorporated...
Recent Posts Personal Connections… pfSense IPSEC to vCHS Protected: Another Slice of vCAC Please… vCHS Flavored vCOPs and You! Fun with vCAC! A Picture is Worth 1000 vCD Networks skyscrapercity VXLAN + VCDNI Coexistence Scenario Holy Smokes VXLAN! Recent Comments Jonathan on Titan Tri-SLI 3D Vision Surrou… mlambert890 on Titan Tri-SLI 3D Vision Surrou… skyscrapercity Jonathan on Titan Tri-SLI 3D Vision skyscrapercity Surrou… mlambert890 on Notes from the Road, A Persona… tech4cast on Notes from the Road, A Persona… Archives October 2013 September 2013 August 2013 April 2013 March 2013 December 2012 October 2012 September 2012 July 2012 June 2012 March 2011 February 2011 November 2010 October 2010 December 2009 November 2009 January 2009 December 2008 April 2008 March 2008 February 2008 June 2007 September 2006 August 2006 July 2006 Categories Business and Finance Cars Computers and Internet Gaming Lifestyle Movie Reviews News and politics Science Social Commentary Meta Register Log in Entries RSS Comments RSS WordPress.com
I consider it something skyscrapercity of a life mission to make complex networking scenarios, physical or virtual, easy to understand at a glance. Let’s just say it’s a tough mission! The last entry was a bit of a mess trying to show how the various network pool backing scheme work down at the provider level, but for this entry we are moving a level up to the organization level. The goal today is to provide a snapshot of how networking works on the vCD consumer side. I think this one came out much better!
What’s being illustrated above is the various flavors of vCD organizational networks. Some quick points for review: Networks in a vCD organization (tenant) can be defined at two levels: Organization Virtual Datacenter (vDC): these networks are the basic building block of vCD networking and are your main virtual tenant network vApp Networks: these are networks associated specifically with a vApp and shared only by the VMs within that vApp Each of these networks have 3 main connection options (how they connect to the next network level down) Routed: routed networks utilize a vShield Edge for layer 3 services. Routed org vDC networks route to the provider external network. That means a vShield edge is auto deployed with one of its interfaces in the provider external network port group, and the other in the org vDC network port group. vApp networks, on the other hand, route into org vDC networks. This hierarchy is important to note. Org networks connect to provider networks, vApp networks connect to Org networks. Always moving one level down. Direct: direct networks, as implied, connect directly to the next network level down. So for org networks that means they’re sitting in the external network port group and for vApp networks, obviously they are in the org network port group. There is no vShield Edge deployed in this case and IP addressing is flat Isolated: an interesting one, isolated skyscrapercity networks skyscrapercity don’t connect to anything. It is possible to create a connection between two isolated networks manually by attaching a VM to both of them and enabling routing on it (although that would somewhat defeat the purpose). In addition to the above, vApp networks add a fourth option - fenced. Fenced networks utilize a vShield Edge, essentially, as a bridge with filtering. This allows multiple vApp networks with overlapping IP space to coexist within one org network. Again, usage of this construct is very scenario specific
You are commenting using your WordPress.com account. (  Log Out  /  Change  )
%d bloggers like this:

No comments:

Post a Comment