Well, as mentioned, wireless stations are able to roam between our wireless
lane controllers
if access points are connected to different ones.
But in order for us to support this, the wireless lane controllers must be in
the same mobility
group.
The mobility group is a configuration that we're going to place onto the
wireless lane
controllers and it's going to alert them to other wireless lane controllers
that are
responsible for access points that will allow roaming. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
responsible for access points that will allow roaming.
Now we have to evaluate our wireless network and decide which access points we
want to
support roaming between.
For example, if we have a headquarters location, we probably want all of the
access points,
regardless of their wireless lane controller attachment, to allow for roaming
because people
can walk from one access point to the other.
But if this is a campus environment and maybe we've got buildings throughout,
yeah, these
are buildings from above here, buildings throughout the campus, are we going to
want people to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
want people to
be able to roam from one building to another?
And for that matter, is there enough wireless signal to make it from one
building to another?
And so if all the access points here are attached to one wireless lane
controller, all
the access points over here are attached to a different one, do we want these
wireless
lane controllers to be part of the same mobility group?
That's part of our wireless design, it's a little bit outside the scope of an
exam and
a course such as this, but we do need to be aware of what we're configuring
when we do WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
when we do
configure the mobility group.
Now the mobility group is going to consist of certain parameters that we're
going to
have to configure.
For example, we're going to have to give it a name.
And this name is going to have to be consistent among the different wireless
lane controllers
as we might imagine.
We can also, by the way, have up to, let's see, it says 24 wireless lane
controllers in a
single mobility group.
So that's per group.
That feels like a whole lot of wireless lane controllers.
I'm going to guess that we're not going to hit this limit anytime soon, because WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm going to guess that we're not going to hit this limit anytime soon, because
by the
time we're talking about that many wireless lane controllers, we're probably
talking about
access points that there's really no physical way to roam between the two.
So we're naturally talking about a very large set of wireless lane controllers
at that point.
They are also going to have to know the IPs and the MAC addresses of the other
wireless
lane controllers.
We're going to have to get in there and let the wireless lane controllers know WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're going to have to get in there and let the wireless lane controllers know
where the
other controllers are so they can begin their communications.
And furthermore, an interesting part of all of this is as we've said, Cisco has
two different
types of wireless lane controllers.
They have the AOS, legacy type of controllers.
They also have the iOS XE, catalyst 9800 wireless lane controllers.
These are the modern ones.
And both of these can be in the same mobility group.
Cisco has done as much as possible to make the migration from the older WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Cisco has done as much as possible to make the migration from the older
platform to the
modern platform as seamless as possible.
And one of the ways they did this is by including both of them from a
capabilities perspective
within a mobility group.
Now something we'll have to consider from a configuration perspective is by
default as
these communications happen, it's going to default to unicast communications.
So if we have three, four, five, six wireless lane controllers, we should know
that it's
going to just use unicast. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to just use unicast.
We don't need to worry about a multicast infrastructure supporting the mobility
group
configuration.
But as that number increases, we're going to see that we're going to switch to
multicast.
And so at this point, we will need a multicast architecture, which makes sense.
We don't want a full mesh of communications happening leveraging unicast.
It's going to be very inefficient.
So keep in mind from the previous video, what it is we're trying to accomplish
here.
We have these three different types of roams. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We have these three different types of roams.
And the first one is that intra controller layer two Rome.
This happens within a wireless lane controller, meaning that we've got two
access points
here and we're roaming between the two.
We might argue that we don't need to let anybody else know about this.
And yet Cisco has it in the architecture such that I'm going to alert all of
the other
wireless lane controllers in my mobility group that this Rome occurred.
So we're all tracking where all of the stations are. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we're all tracking where all of the stations are.
That way, if we do Rome to another one of these wireless lane controllers and
perform
an inter layer three Rome, well, at that point, we can make that happen.
And the mobility group wireless lane controllers already know a little bit
about that station.
Now we do have those other two as well.
And the other two are going to come with different implications.
The inter layer three, as we said, this is when we go from one wireless lane
controller
to the other.
We're going to need to establish the anchor controller. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're going to need to establish the anchor controller.
So that's the first one.
And then the foreign controller is the second one.
And that's going to be a little bit arguably the more complex situation.
But the idea is simply that we have layer three segmentation between the
wireless lane
controllers.
Very likely they're in different locations and different buildings.
Or we simply have the inter layer two, which is a little simpler.
It usually means that they're in the same building because they're on the same
layer
two network.
And at this point, this is a simple handoff between wireless lane controllers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And at this point, this is a simple handoff between wireless lane controllers.
But again, those communications have to happen and in all of these scenarios,
we are going
to require mobility group configuration.
Now lastly, we have one interesting topic of conversation, which is the
mobility domain.
Embrability domain is going to be a set of wireless lane controllers in which
we have
up to three mobility groups.
Now we might think that the way this works is we configure a mobility domain. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now we might think that the way this works is we configure a mobility domain.
And hierarchically speaking, we create the domain and then we create the three
different
groups within it and we can manage this.
But this isn't exactly how it comes together.
It's kind of interesting how this gets configured.
We're doing mostly as we're relaxing requirements around mobility group
configuration.
Because what happens is when I log into one wireless lane controller and I let
it know
about another wireless lane controller's IP and MAC address, I'm going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
about another wireless lane controller's IP and MAC address, I'm going to
specify the
group that it's a part of.
Now this group is in most cases going to be the same group.
Maybe this is group CBT and so I'm going to specify this as group CBT.
But Cisco does allow me to specify up to two other mobility groups as part of
this.
And this collection of configurations as I add them together, this is the
mobility domain.
It's interesting because I never actually define the domain.
I never name the domain. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I never name the domain.
It's a strange methodology relative to what we might expect with having a
little more
concrete architecture.
But it does come together in such a way that we can support multiple mobility
groups on
wireless lane controllers.
Now as we might imagine needing to support this many mobility groups, we can
already
support up to 24 wireless lane controllers per group would pretty well imply
that we're
talking about very large deployments.
And at the same time, it's just something to be aware of, especially around the
concept
of how many mobility groups can be configured per mobility domain. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of how many mobility groups can be configured per mobility domain.
And that's going to more or less map out to large organizations across multiple
locations.