So, in this scenario, we have a packet arriving on Switch1 towards a particular
destination,
and we need to know what exactly SD Access does with this packet and how
exactly it knows
where to send it and if it doesn't know where to send it, what does it do with
it?
So, looking through these questions, what type of message is first sent by
Switch1?
Well, it's going to send a request to the control plane node because, again, we
need
to pull down the information.
We need to fix this pull-based methodology we really need to start to get used WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We need to fix this pull-based methodology we really need to start to get used
to because
we're no longer pushing routes everywhere.
Furthermore, when we talk about routes, we are talking about those endpoint
identifiers
that LISP manages.
Now, we might think of those as routes like going to a /24, but in the case of
SDA, we're
talking about individual /32s.
We need to know where this specific host lives because the subnet is everywhere
.
I mean, we've probably got a host over here that's 10.100.1.51. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I mean, we've probably got a host over here that's 10.100.1.51.
I mean, they could be adjacent from an IP address perspective, so it doesn't do
me any good
to know where the subnet lives because the subnet kind of lives everywhere.
I need to know where this specific host lives, and so that's the responsibility
of the control
plane node.
As soon as Switch2 sees a packet from this host, we're going to register that
with the
control plane node.
And now, when we go and we make a request of the control plane node, we're
going to pull WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to pull
that information down.
Yeah, we could push this information everywhere, and then everybody knows where
every single
host in the network is.
It doesn't scale particularly well, and keep in mind also that we can cache
this information.
I don't have to do this every single time.
I can know that, hey, .50 goes to Switch2, and I can remember this over the
course of
time.
And yeah, eventually I'll clear that out if traffic stops, but as long as
traffic is
flowing to that host, I'm going to keep this information in the cache, and I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
flowing to that host, I'm going to keep this information in the cache, and I
don't have
to go all the way up to the control plane node in order to get that information
again.
So that's how we go about doing this.
The first step is to send that request up to the control plane node, and then
what happens
if it has an entry?
Well, we respond.
We send a response back to Switch1, and it encapsulates this into VXLAN and
sends it
across to Switch2.
And we use VXLAN because it maintains the entirety of the Layer 2 frame,
including the
original Ethernet headers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
original Ethernet headers.
And this allows us to, I really like drawing out, make the dotted line
connection here so
that if we have VLAN 100 on one side, we can have that same Layer 2 VLAN over
on the other
side, despite the fact that our fabric is built on Layer 3 for the sake of
scaling and
an eliminating spanning tree protocol.
It's a beautiful thing.
So, what happens if the control plane node doesn't have an entry though?
What if it says, "Hey, I don't know where .50 is."
In fact, let's just change the scenario here ever so slightly. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In fact, let's just change the scenario here ever so slightly.
Now let's say a new packet arrives and it's destined for .65.
And so we send our pull request and we don't know where .65 is.
Maybe it's part of a completely different subnet.
Either way, we're going to let Switch1 know we don't know this, and therefore
Switch1
is going to do the only thing it knows to do, which is to send it in VXLAN over
to the
border node.
The border node is going to have to decide what to do with this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The border node is going to have to decide what to do with this.
And maybe it has a route and it knows to go out towards the core of the network
.
But the reality is that if we don't know where it is, it's probably just going
to follow
the default route, which ultimately takes us towards the internet.
And that's the goal here because we do still need to have a default route path
in the fabric,
and that would be handled by the border node.
Remember that there are internal border nodes, right up here.
There's internal border nodes that handle internal connections. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There's internal border nodes that handle internal connections.
There's external border nodes that handle internet connections, and they can
certainly
have both roles on a single device.
Now lastly, how is the packet encapsulated and where is it sent?
We kind of answered that throughout this whole process.
The big thing is it's going to use VXLAN in order to maintain the layer two
information.
So that brings us to the end of this review on the software defined access and
software
defined when lots of information to unpack.
As a set of the very start, a lot of review like this to help you identify your WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
As a set of the very start, a lot of review like this to help you identify your
areas
of weakness.
If you have anything or identified any particular concerns, then go back and
watch those videos
in those skills in order to make sure we've got it all down before moving on.
Otherwise, I hope this has been informative for you, and I'd like to thank you
for viewing.