So we just got done talking about this concept of an anchor controller and a
foreign controller. The idea here is that even though I'm attached currently,
here's my wireless station, my laptop, I'm attached to a access point that is
then attached to the foreign wireless LAN controller and even though I'm here
on
the right, I am part of a subnet, let's say 10.10.5.x once again. I'm part of
a subnet that lives over here where this other wireless LAN controller lives. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a subnet that lives over here where this other wireless LAN controller lives.
So
this is going to have a trunked connection down to some kind of multi-layer
switch
and maybe there's an SVI here for the 10.10.5 subnet. So if we think about it
from
a routing perspective, if for example I've got a core switch here in the middle
and
so this is doing multi-layer functionality and it gets a packet in
that's destined for 10.10.5.x whatever this host is, then we're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's destined for 10.10.5.x whatever this host is, then we're going to
forward it
to this layer three device which would mean that it can be delivered to what
appears to be the wrong wireless LAN controller. But because we have this
relationship between anchor and foreign controller, now when the packet gets
sent
through the layer three network, so this is part of the layer three world now,
it's
going to get delivered to the anchor side and then it will get forwarded to the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to get delivered to the anchor side and then it will get forwarded to the
foreign controller and then to where it belongs. It's a little bit of a, well I
wouldn't say the most efficient path thing in the world but it does make
something give us an interesting architecture, something that we might be
able to do a little bit more with this than we were doing before. Because
before
what we were doing was saying, "Hey I've got an access point over here, I start
here, I roam over here through this layer three boundary and I use the anchor WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here, I roam over here through this layer three boundary and I use the anchor
and
foreign controller in order to stay on my old subnet." That's cool. But what if
I
use this as my starting point? So I start on the right, I call that my foreign
controller and now I define my anchor controller somewhere else. What does
this accomplish? What it accomplishes is it places my wireless stations point
of
presence over here where the anchor controller is. Because remember the first WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
presence over here where the anchor controller is. Because remember the first
time the network truly sees traffic from this station, my underlying got a
little out of control there, but the first time it sees a packet from this
wireless station, it's here. Coming from the anchor wireless lane controller as
it
arrives on whatever upstream layer two network exists and eventually probably
gets routed to the layer three world. So why would I want a wireless device to
show up, have a point of presence, in a location where it isn't? It's not in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
show up, have a point of presence, in a location where it isn't? It's not in
that
location, it's over here where we've now said that it's starting out attached
to
the foreign controller. Well a great application for this would be guest
access. And the idea here is we can create a guest anchor controller and this
is
going to assist us with our security and specifically with the isolation of our
guest network. So our guests, our wireless stations are showing up in our space WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
guest network. So our guests, our wireless stations are showing up in our space
,
let's say we're a hospital or maybe we're a library or something like that. And
we're offering Wi-Fi not only to our guests but also to our employees. So now
I have an internal device here, maybe this is a doctor's laptop or the
librarian's laptop, and it's communicating with the exact same access point as
this
here, this is just my happy user that's trying to use the Wi-Fi. Well where WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here, this is just my happy user that's trying to use the Wi-Fi. Well where
exactly would we want this user to be? We don't necessarily love the fact that
the user that's logging in here is part of the same network as my internal
users.
In fact if we think about it, what our guests really want in most cases and
really all we're offering them is access to none other than the internet. I don
't
need to give them access to the servers and the resources that exist here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
need to give them access to the servers and the resources that exist here
wherever I am, my headquarters location or again my hospital or whatever the
situation is. They don't need access to those internal resources. Normally I
would
just use VLANs to isolate them but now I can go a step further. I can use the
guest
anchor. What this now allows me to do, let's just draw this over here now, let
's
say that my guest anchor is out in this space and where would I want it to be?
Well where I can put it is on the other side of my firewall. In fact I can use WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well where I can put it is on the other side of my firewall. In fact I can use
the firewall to effectively allow my guest users to be transported to the guest
anchor controller and then pass the traffic through the firewall to get out
to the internet. Now what I've done is I've created an isolated guest network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to the internet. Now what I've done is I've created an isolated guest network
using an anchor controller that lives in the DMZ. The DMZ is that funny space
where it's not on the internet. I didn't say put the wireless lane controller
outside the firewall down here. That would be bad for our users or at least
we're not really taking good care of our guests because we're just placing them
right onto the internet and we're not firewalling any of that traffic. But
instead I can place it adjacent to the firewall so it's not on my internal
network here but it's also not directly on the internet instead it's part of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
network here but it's also not directly on the internet instead it's part of
that DMZ. So the guest anchor architecture is a great way to leverage this
anchor
and foreign concept to transport my guests so that their point of presence
is in the DMZ. I still offer some basic protections with the firewall to allow
for outgoing traffic flows without allowing them to just have face the
full waves of what comes in from the internet. And so I'm doing right by them
there and at this point I don't need to worry about my guests either being WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
there and at this point I don't need to worry about my guests either being
nefarious or otherwise unwittingly potentially serving as launch points
for attacks in my internal network.