VCD RoundTable

Speaker 1: Hello and welcome to
another episode of the VCD

Roundtable. After our last
episode, where we covered

everything new around VCD 10.5,
today's session is exclusively

around VCD and networking and
all the new good and fancy

features we get with version
10.5 and some of the features

which came before and which we
just wanted to recap a bit and

talk a bit about Before we get
started. A reminder VCD not VCD

VMware Explorer is just around
the corner, in a few weeks in

Las Vegas and then a couple of
months back in Barcelona. We'd

like to meet up with everybody,
so reach out to us on social

media and then we can see what
we can do at one of these

conferences to get together.
With that being said, who's on

the session today? Let me get
started with myself. I know

that's not how you should do it,
but it's the easiest way around

. My name is Steve Sanford. I'm
CEO of the Common Division Group

, one of the lead architects
around anything, service

provider and cloud director in
our team. I'm more focused on

the business side how we do
product packaging and a bunch of

other things, but also when it
comes to, let's say, the more

legacy designs. With that being
said, I'm handing over to Sascha

for his introduction for today
Hi my name is Sascha Schwung.

Speaker 2: I'm a partner and
cloud architect at Common

Division doing a lot of stuff
about architecture of cloud,

director environments,
Greenfield, V2T, migrations and

also the Tanzu stuff. So
container service extension and

so on. I will hand over to Tobi.

Speaker 3: My name is Tobi
Barschek. I'm a solution

architect and partner at Common
Division main focus on the whole

networking story. So Steven,
nsx, nsx-lb, but also, on the

other hand, the whole cloud
director story and I would like

to hand over to Matthias.

Speaker 4: Hi, I'm Matthias
partner, common Division cloud

architect, focusing on VCD, nsx
and the automation around those

products. I love that one legacy
architecture. If you believe

that VCD-1.5, I go to Inkvines.
Don't worry, joach, please

continue yeah.

Speaker 5: I'm not zero. Oh my
that old. I'm Joach Leib. I'm a

technical product manager at
VMware, covering cloud director

and all the different
integrations and extensions that

we have, and with that back to
you.

Speaker 1: Yves, good, yeah. So
VCD since version 1.0, I

remember the early, early, early
, early, early days. Back then

we thought it's the perfect tool
for enterprises and commercial.

Now we think it's the perfect
tool for the first providers and

we try to get away from the
other ones, but they'll still

think it's a mistake. But
anyways, nevertheless, let's

talk about the networking pieces
of NSX-10.5. And let me just

throw out one of the items which
we started to cover already in

the 10.5 what's New session the
NSX Federation piece and VDC

groups and everything else. So
who's going to pick up that

topic to be first? Because I
guess it's better that I'm not

talking about that one.

Speaker 3: Yeah, and I will
start. So we have now, finally,

the whole support for NSX
Federation. So what does this

mean? On one hand, we have now
the ability to import more than

one NSX manager into our VCD
environment, what is not really

100% true, because at the end,
we need to have the whole

Federation configured outside of
our cloud director environment

and then we need just to import
the global Federation manager

node to our VCD and VCD will now
be able to discover hey, okay,

this is a federated environment
and he can then utilize the NSX

Federation environment in his
data center groups. And this is

already one important part of
what we need. To be fair, we

need it mainly since NSX T or
now the final name is just NSX4

is there to be able to utilize
the distributed firewall and

stuff like this. So we need to
go with a clear data center

group, absolutely independent if
we just have one or VDC or if

we have multiple organization.
Virtual data centers. Federation

also is only supported If we
have the ability to utilize data

center groups and NSX
Federation. There is one

limitation that's called
limitation we can only have at

the moment. We can only have up
to four NSX manager instances in

a single virtual data center
group, which means more than

four locations with different
managed by dedicated NSX

environments, are currently not
supported inside Cloud Director.

I'm not really have the limit
out of my head what is supported

from an NSX team perspective,
but I have something in mind up

to eight, I think up to eight
environments are currently

supported in Federation from an
NSX point of view. From a Cloud

Director point of view, in a
single organization, we see we

can have up to four NSX manager
instances. So we have now a

clear possibility to really
support availability groups

fully separated, not what we
have done mainly in the past,

saying okay, we have our regions
and we have our availability

zones, but at the end we have
just a single NSX environment

stretched across the regions,
stretched across availability

zones. We can now really have
dedicated environments in each

region, each availability zone,
and then have the global NSX

Federation supported inside
Cloud Director. So that's the

starting point and, from my
perspective, one of the biggest

improvements regarding the whole
networking story in 10.5.

Sarsha, would you like to add
something?

Speaker 2: No, I think yeah,
federation use that, all about

it and it will become very
interesting for most of the

customers. I want to add the
parts that NSX Advanced Load

Balancer. So now with 10.5, we
have the self-service HTTP

policies so that tenants or
customers can manage their own

policies. So with the starting
of NSX ALB we had it still as a

provider managed service so the
provider can configure all the

HTTP policies, but now with 10.5
, all tenants are able to

configure their own HTTP
policies over Cloud Director and

I think that is a very
important part in the first step

to really use the load balancer
with more features than only

load balancing. Though that was
a big question in the last

months from customers and
service providers, because many

service providers said I don't
want to manage this for the

customers or I'm not able to
manage all of this for the

customers, and now we have it
that the customer can do it by

self-service and from my
perspective, that is the first

step in the right direction to
give the customers more options

to configure their load
balancers and I hope there will

become more features added to
the self-service over Cloud

Director from NSX ALB.

Speaker 4: Yes, maybe coming
back a little bit on this

exploration, because what Toby
mentioned is the whole story

about availability zones and if
you have a federated

infrastructure, from my
perspective the combination with

VCDA enables customers or
tenants to build a new product.

I can build my own self-service
asynchronous replication from

one availability zone to another
without re-IPing my systems if

I need to start to fail over and
stuff. I think that's an

interesting new approach,
especially for service providers

, and repackage or provide new
products to their customers. So

I think that kind of business
thinking will change products we

will see provided by SAPs in
the future. Yeah, in terms of

additional features in the
networking space, I would like

to go the firewall part, because
what many tenants or what

service providers told me what
many tenants are asking for? How

can I add an IP address into a
firewall rule as a source or

destination? So in the good old
days it was not possible because

you just had to add the IP
address into a group and so on

and so forth. Now with TEN5 and
the new UI, we have the ability

to add individual IP addresses
as a source and or destination

into a firewall rule and I think
that's a really nice

improvement enabling tenants
creating more granular firewall

rules to improve their security.
I think that adds a lot of

easier management of firewall
rules sets.

Speaker 5: Yeah, there are some
additional improvements in the

firewall UI. That's something
where we get a lot of feedback,

of course, from partners,
service provider partners and

their customers. So, for example
, it's easier to order specific

rules in the firewall UI now,
and just that handling gets

better and better and there's
also one pretty huge improvement

for when it comes to the
firewall rules. So from a VCD

product perspective, we are of
course working very closely with

the NSX team to in future adopt
the tenancy capabilities or the

NSX projects concept to map
them to tenants in Cloud

Director, but that will take
another couple of versions to be

released. So until then in past
it was very hard to create some

specific logging mechanisms or
dashboards for, especially for

the firewall. Now, with VCD 10.5
, we introduced some logging ID

for a firewall rule that maps to
the rule ID in NSX and that now

allows to really have some
tenant specific information in

each log message that comes from
the firewall and with that you

can use your favorite logging
analyzer tool that you want to

create some filters or
dashboards to really to create

some log lists just for firewall
rules of a specific tenant

Really powerful and very, very
often requested feature.

Speaker 4: The last step would
be having a multi-tenant locking

infrastructure. That would be
awesome, but you can still have

one instance per tenant. That
works perfectly fine.

Speaker 1: Good IP spaces. Who
wants to cover IP spaces and the

news around that one?

Speaker 4: Yes. So the news
around IP spaces is mainly the

migration UI wizard enabling the
service provider to migrate the

provider gateway, configured IP
ranges or assigned IP addresses

into the new IP space mechanism
. So that's the enhancement in

10.5. Again, ip spaces. What is
possible to do with IP spaces?

Pretty short, the service
provider configures IP ranges

which can be requested by
tenants as floating IP addresses

for their needs. Like I would
like to instantiate a new

service, I need a new public IP
address. I can just request one

floating IP address or I can
just subnet certain ranges and

enable customers to request IP
ranges within their own cloud

directory UI. In the past, if a
tenant needed a new IP address

or a new IP range like it's
either public or private I

always had to discuss with my
service provider please assign

an IP address or please assign
an IP range, which costs. Like

you need to open a ticket
additional work, someone has to

do it, work on the ticket. So it
was a pretty lengthy process.

And now, if the tenant needs an
additional IP address, just

click request new and use it.
And, as Fabian would like to say

, kachin, right, with the usage
meter. You just charge for the

public IP address or even an IP
range. I think that's pretty

cool. That's the whole story
around IP spaces. I can just say

please use it. They are an
awesome feature from my

perspective. And now with 10.5,
just use the UI wizard and

migrate over your legacy stuff
or your legacy IP management

within VCD to the new IP spaces
environment.

Speaker 5: Also be aware that
the latest version of the

Terraform provider now supports
IP spaces, so that you can

automate them through the
Terraform infrastructure as code

concept.

Speaker 4: Yeah, thanks for that
.

Speaker 1: Good, so BGP is
another topic. We wanted to

cover some of the BGP changes.

Speaker 4: Yeah, so BGP? The big
enhancements from my

perspective in BGP is just the
ability to manage route maps and

community lists from the VCD UI
. In the past those BGP features

provided by the ZX were
consumed as a managed service.

That's the nice term, for the
service provider configures the

stuff, or as Eve refers to it,
as fully featured API

integration. Now we can use
those two additional tabs to

consume or to configure route
maps and community lists from

the Cloud Director UI. Do we
have anything to add on that?

Speaker 3: Yes, just a small
limitation at the moment,

because we should really have
this in mind. What Matthias

mentioned absolutely correctly,
but please have in mind, only on

provider managed gatevisper. At
the moment this IP spaces, as

mentioned before, ip as a
service. We should change to IP

spaces. Then we have now the
capability inside Cloud Director

, on a provider managed gateway,
that or on a provider gateway,

not on a provider managed
gateway on a provider gateway

with BGP enabled, that we can
configure all of the enhanced

BGP stuff directly in the Cloud
Director UI.

Speaker 4: You mean a dedicated
gateway? Yes, all right. I think

that's mainly covering the BGP
part. If you have a dedicated

provider gateway or dedicated T0
, you have the BGP enabled

within the VCD UI. With 10.5,
you have two additional tabs One

is a community list and the
other one is a roadmap.

Speaker 1: Good what I still
have on my list. I mean, I know

you covered already quite a bit
of the firewall rules, Matthias,

and you also already have not
one of us to ensure the

auto-configured nut rules.

Speaker 4: So I haven't
mentioned those. So what is

about the auto rules? You can,
if you enable it, and of course

you need to have to use IP
spaces, otherwise it's not

working. You can enable the
automated rule configuration for

NAT rules like source and
destination NAT on edge gateways

and provider gateways within
the environment. That's the

whole idea with it, because you
can enable those rules to

automatically configure NATing
based on external and internal

scopes. That's the idea behind
that. In the past you had to do

it manually, especially the no
NAT rules, the no NAT rules,

yeah.

Speaker 2: If you mentioned the
part with the firewall rules UI

that we can now add source and
destination IP ranges directly

in the firewall rules and don't
need to specify IP sets before.

So, yeah, many times we created
firewall rules and need to go

back to create an IP space for
that. So that's a really good

improvement of the firewall
rules UI in 10.05 from my

perspective.

Speaker 1: The other thing which
I had on my list for today's

session, and again, I'm not sure
if we want to cover all the

networking pieces, but someone
added to the list stateless T0.

Why and how?

Speaker 3: I think it was Sasha
and myself. So, sasha, it's now

your part.

Speaker 2: You can talk better
about that. We have another part

. Later on we will talk about
V2T migration. What have you

said?

Speaker 3: What's the idea
behind? So in the past, it was

always only possible if you go
with the T0 active standby

configuration to utilize NAT
configuration on your T0 gateway

. This is since the release of
NSX4, which is the new name of

NSXT or the final name of NSXT,
whatever you would like to call

it we have now the possibility
to utilize or to configure

stateful and stateless NAT
directly on our T0 gateway, also

in an active-active manner. So
we don't need to reconfigure our

T0 gateway to an active standby
. We can leave it in a negative

configuration but still have the
capability of utilizing NAT on

one hand and on the other hand
and that's from my perspective,

the more or the better
improvement is also that we have

now the capability of utilizing
proxy app and this is what

Sasha will cover from the
migration perspective that we

now can also utilize proxy app
on an active-active

configuration. So this is the
improvement from an NSX

perspective and before I hand
over to Sasha, I would like to

add a big limitation I
discovered last week and this is

also not 100%, not related to
Cloud Director, because this is,

from my perspective and big
issue and I would already call

it a bug inside NSX if you
create a NAT rule. I'm really

talking now about the NAT rule
because it is possible in the

firewall rules, but it is not
possible in a NAT rule. If you

would like to configure NAT rule
, let's, for example, go with

passive FTP or passive FTP and
you would like to open a port

range in your NAT rule, saying,
hey, I would like to have from

50,000 up to 51,000, all of the
ports open and I would like to

create a single NAT rule, which
is possible in, or was possible

in, nsxv. This is not possible
at the moment in NSXT. So if you

would like to open, for example
, 1000 ports for your passive

FTP, at the moment you need to
create 1000 NAT rules not an

ideal solution. So now I'm
finished. I would like to hand

over to Sasha.

Speaker 4: Just one thing behind
that headline, because on top

in NSXV I have the ability to
migrate a stateful T0 into a

stateless T0, which enables
certain features within NSX,

like also firewall and stuff
like this. Guys, you need to be

careful because the T0 is always
provider managed, keep that in

mind. And the stateless T0
always requires stateless T1. So

the question is, and we need to
figure out, what if I import a

stateless T0 into VCD and then
create an edge gateway, because

that's a T1 behind the T0. So
it's not pretty clear within the

release notes and, just being
honest, we don't know what the

real behavior will be. Maybe
Yerke has a few insights, maybe

yes, maybe no. So be careful
with the whole stateless T0

story. If you want to use
stateless T0 and all these

features, you need to have a
stateless T1 behind that. So

currently we suggest please
import the segments as external

networks and provide those to
the customer. The whole network

stack needs to be consumed as a
managed service from a tenant

perspective. Be careful with
those configurations. And last

but not least, stateless T0 is a
one-way ticket to help. If you

migrate a stateful T0 into a
stateless, it remains a

stateless. There is no way back
except of delete stuff, but if

you use Terraform that's pretty
fastly done. Remove and rebuild

objects. All right, sachin,
that's your turn.

Speaker 2: Yeah. So I want to
say, with the proxy app, that's

very important for the NSX V2T
migrations, so we don't have to

go with an active, passive T0.
And that is a big benefit now

for the upcoming NSX V2T
migrations though, that we can

work with active, active T0s
there. And, yeah, we are still

doing a lot of V2T migrations.
And I think, yeah, we have the

migration tool. We currently
have support with the migration

tool. We heard that there is
something with the migration

tool in the future that will
become out of support, so that

we have no longer support for
the migration tool. So I want to

say it's very important to
start latest now to do your NSX

V2T migration. That is a very
important part that we can do

the migration with the full
support of VMware, with the

migration tool.

Speaker 4: So the proxy app
Sacha just to add a bit more

precision to the phrasing proxy
app is available on an active

active state for T0. T0, yeah.
So because we now need to be

very precisely on the phrasing,
because that not anybody thinks

like, oh, I need to use a T0
stateless for proxy app, which

might not be ideal because it's
again a one-by-tick to hell.

Speaker 3: And also one last
thing, because this was

something Sacha and I discussed
last time. Yes, you can

reconfigure an active standby T0
gateway to an active active T0.

But please have in mind that
you need to disconnect all of

your tier one gateways, so this
is nothing which can be done

quickly in place. So you need to
have a maintenance window where

all of the tier one gateways
gets disconnected. Then you can

reconfigure your tier zero and
reattach your tier one gateways.

Speaker 4: But that's just a
minor impact. All right, cool. I

think that's a bit summing up
the whole networking space. A

lot of cool features, especially
in terms of new stuff in

security, logging, monitoring,
ip spaces. But again, we added a

lot of topics to the how do we
call it? A managed service

consumption of certain
networking features. So again,

always keep in mind what can be
done from a tenant perspective,

what needs to be consumed as a
fully managed service and create

new product packaging using the
new NSX Federation and create

availability so that they will
customers to migrate workloads

and create their own HA
solutions within your own SP

space. So, summing up, I assume
famous last words, some closing

statements. Maybe, europe, you
want to start.

Speaker 5: Yeah, very happy
about the finally improvements

in the firewall UI because that
has been a lot of feedback that

we got over the last couple of
months, so happy to get that in,

toby.

Speaker 3: Yeah, also thanks for
your attention and, on the

other hand, more than happy that
more and more of the networking

story becomes now part of Cloud
Director or inside the Cloud

Director UI. So let's see what
will come in the future. Sosha.

Speaker 2: Yeah, thank you for
joining us and we'll be happy to

join you or meet you in Las
Vegas. Reach out to us and let's

have a meeting in Vegas.

Speaker 1: Was. That being said,
I think nothing else for me to

add. Again, would love to
welcome most of you in Vegas for

individual sessions, meetings,
et cetera. I think we covered

quite a bit on the networking
piece. Just to give you a bit of

a heads up, in one of our next
episodes Sosha is going to cover

a lot more around CSE, tanzu
and those integrations, and we

will also do a little special
special with Alain from our team

who is going to cover more on
Showbag, chargebag, aria

operations, integration and a
lot of these different things,

and so we have already quite a
few topics lined up for some of

the next sessions. Looking
forward to it and, with that

being said, goodbye and hope to
see you all in Vegas in a few

days.