Best practice for transport zones

[boomchke]

While playing with NSX in the lab, I initially thought that transport zones were a means to separate different tenants.  AKA, if I wanted to do have overlapping IP space etc, I would use different transport zones.  After more reading and plying around, it appears that each logical switch is its own VXLAN segment (different segment IDs).  And it appears the only means to route between segments is through the distributed router.  That being said, it looks like the logical switch is the real VXLAN separation at a tenant level.  That is, different distributed routers and logical switches are a sufficient means to isolate tenants.  If thats the case, then are transport zones just a means to further isolate VXLAN traffic?  Was this more relevant in multicast mode rather than unicast mode?

[admin]

Hello,

Transport zones determine the "scope" of Logical Switches tied to them.

When a Logical Switch is created, it is tied 1:1 to a Transport Zone.

A Logical Switch will only be available on hosts in those clusters that are members of the Transport Zone that this Logical Switch is tied to.

For example:

- Say you have four clusters, C1, C2, C3, and C4.

- You then create a Transport Zone TZ1, with clusters C1 and C2; and TZ2 with clusters C3 and C4.

- Then you create a Logical switch LS1 in TZ1, and LS2 in TZ2.

In this configuration, you won't be able to attach LS1 and LS2 to neither a distributed router, nor an Edge Gateway, because LS1 will only exists on hosts in C1 and C2, and LS2 on hosts in C3 and C4. This is an extreme example, but it may be useful as an additional security measure (it won't be possible to even "fat finger" configuration that would allow communications between LS1 and LS2).

Hope this helps.

[boomchke]

Thanks for the response.  Im aware of how the Transport Zone fits into NSX model as you described.  Im just wondering what the VMware best practice for using them is.  Should I have one transport zone per tenant?  Thats not required for tenant isolation since the VXLAN segments are applied per logical switch.  Seems like there should be a prescribed use case for them, just seems like Im missing something here....

[admin]

Transport zones is a tool that can be used based on your requirements. Since NSX is much more of a "toolbox" than a "directly consumable product", use and applicability of its features would depend on what you're trying to achieve.

In cases when there is no need for constraining scope of logical switches, it is normally perfectly fine to have a single TZ for the whole NSX domain, and all its tenants.

There are cases when people wanted to have an extra layer of assurance for inter-"zone" isolation, which they achieved using multiple TZ in a fashion similar to what I've described above.

[boomchke]

Sounds like the bottom line is its a mean to further containerize logical switches even though they are ,by definition, separate segments.  Is there any practical limitation to them?  A max configurable amount etc?

[admin]

From what I know, there is no configured hard limit for the number of Transport Zones. Keep in mind the following behaviour, though:

- Say you have one DVS spanning three clusters, C1, C2 and C3.

- You create a new Transport Zone TZ1 with clusters C2 and C3

As dvPortgroups for logical switches are created at DVS scope, C1 will still see (and will be able to use) all LS you create against TZ1. To work around this, create multiple DVS.

The behaviour is much more strict when it comes to Distributed Logical Router, though. An individual DLR will only allow you to attach logical switches of the same TZ, even if you have a different TZ that covers the same set of clusters.

[boomchke]

Interesting.  So let me get this straight...

-Clusters are associated with transport zones

-Transport zones contain logical switches

-Local distributed routers are used to connect logical switches

So since a single DVS can be backing up all of the above, any cluster on the DVS can see port-groups for logical switches?  Even if that cluster is not in the same transport zone?  I thought I had this for a moment but now that doesnt make any sense at all. The distributed router restriction makes total sense and thats how I expected the port-groups to work as well.  Is it because the port-group is shared across the DVS and really just a means to get to the logical switch that all of the clusters on the DVS can see the port-groups?  That makes technical sense I suppose.....

[admin]

> Is it because the port-group is shared across the DVS and really just a means to get to the logical switch that all of the clusters on the DVS can see the port-groups?

Yes. Logical Switch == a "special" dvPortgroup, which can "extend" to more than one DVS, but can't really exist in some clusters members of a DVS and not others.

I can see how the described behaviour is confusing, but VXLAN is closely tied to DVS (much more so than DLR), which doesn't have a concept of TZ. I'm guessing this is one of them "watch this space" things, where we can expect some improvements in future.

[boomchke]

Gotcha, thanks for the clarification!