Welcome back in this video, we're going to take a look at the GM and the elem interfaces.
I'm going to show you the differences and I'll make call outs specific to things that we've already
been talking about in the previous lessons.
I hope you're ready because this is the stuff I love, so let's get into it.
The first thing I want to show you is just a very basic set up of how things are connected.
This is again very high level.
I'm not going into a ton of detail because we will be deploying federation, so don't worry if we're
not quite at the level of detail you want to be.
Again, I just want to lay a good foundation here.
So for this lesson, what you need to know is we have our two data centers, which we will be using
for the remainder of the course.
We have our San Francisco data center and our Los Angeles data center.
And within each of those data centers, we have an LM deployed and typically you would have a cluster
of these.
Keep that in mind.
But in our case, we have one elm here.
We have one elm here and we have a global manager deployed as well.
And that global manager has registered both of these elms to itself.
So let's flip over to the lab, and let's start taking a look at what this actually looks like in the
user interface.
All right, so here we are inside of the San Francisco local manager, and we can see in the URL, says
S.F. Dash NSX.
So that's how we know we're in the right place.
Now let's head over to system, and let's take a look at this one.
First, let's see how it's set up.
So if we go to host transport nodes, we'll go ahead and click that.
We see that we have the same setup we would normally have for NSX.
We have some clusters.
We have a couple of transport nodes here S.F. Compute one, S.F. Compute two, and they're both prep
for NSX.
Now I want to pause here.
Think about it.
Who prepped these hosts?
Was it a global manager or a local manager?
If you said it was this local manager?
Yes, you're absolutely correct.
That hasn't changed, even though we're in a federation design.
Now let's take a look at the edge nodes, so we'll go ahead and click on edge transport nodes.
And there we go.
OK, we see Ajogun one, edge two.
We have a couple of edge nodes.
Again, that looks like regular NSX.
And by the way, when those were deployed, even though we will be going over this, there's nothing
special about those edges.
For the most part, there's one minor thing which will be called an AATIP that will be going over,
but that is really it.
Other than that, everything is exactly the same with these edges.
So it's safe to say at this point that you might look at this a team manager and think, well, this
doesn't even look like it's in federation.
But if you click on Location Manager, that's where it will give us our details around this federation
implementation.
Even though we're on the local manager, we're going to see three different categories of things here.
First, we're going to see our local details.
We can see our site name is San Francisco.
We can see the members in our cluster and our elm cluster.
In this case, it's just one we can see that we are registered to a global manager, which the site
name there is or the global manager name is main GM and we have one member in that cluster and that
is active.
So we would also see a standby cluster as well if we had one.
If we go down, we see remote sites.
This is our other location, Los Angeles.
We can see that the elm there, there's only one elm at that site.
And of course, it's on the same version we're running here.
So at this point, we see that San Francisco's configuration is basically regular and A60.
And if we go over to Los Angeles, I won't bore you on the details too much, but we're here.
You can see L.A. Dash and A60, so this is a different elm.
If we go down and look at the edges there, for example, we see we have separate edges.
These are again deployed completely without knowledge of the San Francisco Elm, so we could actually
have the same names here.
The reason I have ajogun in and two in San Francisco over here and Edge 03 and Edge 04 in Los Angeles
here is primarily for packet walks.
So when we do packet walks, we'll be able to easily differentiate kind of where we're at logging into
because things get kind of confusing when you have a bunch of edge nodes.
So that's why it's named that way.
But the takeaway here is that the configuration is independent for each of these sites.
We were able to propose that each of these sites we can set up compute managers at each of these sites.
That is all independent of federation.
Now all of that said, what you really came here for was to learn federation.
So let's go take a look at our global manager.
In this case, we can see the name is NSC's Dash GmbH.
And the first thing you probably notice is right here we have the name main GM and it says role as global
manager.
Now if we click that, we see that we have our other sites and we see the elms show up as on Prem.
So actually, it's kind of interesting.
If you click San Francisco, it drops me into managing that elm.
You'll see here to host transport nodes.
If I click that, let's go ahead and do that.
There we go.
We have everyone in or two, which is right for San Francisco, if we go down and we change it to Los
Angeles, we should see that now when we go to our edges and we'll do the same thing.
Edge transport nodes.
And there we have it, we see we have Edge 03 and 04.
So the point is I'm able to log into this global manager, but I can still manage these sites independently
if I wanted to.
Now you remember, we talked about global objects versus local objects.
If I create an object in one of my limbs, it's local.
If I create one inside of my global manager, it would be a global object.
So let's go ahead and hop into the global manager.
Now, in this case, we're not going to be doing any configuration.
I just want to give you a brief tour of this.
So if we start here, let's go to system right off the bat.
The first thing will notice is everything looks a little different than the local managers.
We see our overview of our global manager cluster.
We can see our different locations.
We have Los Angeles here.
We go down further.
We have San Francisco that looks good.
We can manage all of our global manager appliances.
So if we want to deploy additional global managers, we could do that from here.
We also have our location manager just like we saw from our elms.
And you'll see here it's even telling us that, hey, you don't have a standby global manager cluster,
you might want to go ahead and add one.
The last thing I'll show you here is if you go to fabric, we see we only have one option, we have
compute managers.
We don't have an option to prep, host or deploy edge nodes or anything like that.
We just have one option compute managers.
So what about other options let's go to or what about other sections?
What if we go to security?
Oh, that's interesting.
That looks a lot different than what we're used to seeing.
So we only have really a couple options here.
We have our distributed firewall for East-West and our gateway firewall, which is north south, coming
in and out of necessity.
So why is that?
Well, if we go to, let's go to one of our elms and let's go to security.
Wow, look at that.
We have a lot of options.
The reason is that those features many of these features here are simply not supported in federation
as of this recording.
So I'm sure you'll start to see this change.
When we go to the global manager again, we go to security.
We'll start to see this grow out over time.
But this is what's currently supported if we create a global object.
So that's all I have for you in this lesson.
I hope this was helpful in trying to just get you exposed to the whole GM versus elm thing.
And don't worry, there's a lot of stuff here to cover, and the good news is we're still very early
in this course.
So I'll see in the next lesson.