The hierarchical network model covers the entire network from every one of our
sites
where our users are to our data centers to our remote locations to the internet
block
and everything in between.
And so what we want to do here now is to zoom in a little bit.
The hierarchical network model great for a big picture.
But now we need to zoom in and look at those three key layers that we often
talk about
the core layer, the distribution layer, and the access layer.
In a single site, we can expect to have a distribution layer and an access WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In a single site, we can expect to have a distribution layer and an access
layer.
And if we have lots of sites, like we talked about in the last skill, then we
'll have lots
of distribution and lots of access layers.
But we're still going to have a single core layer throughout all of that.
So if we have a campus environment with 15 buildings, we might have 15
distribution
blocks, but only a single core block.
And yes, every now and again, we'll use block and layer interchangeably when we
're talking
about the campus model.
So let's go ahead and drill in first of all to this core block. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's go ahead and drill in first of all to this core block.
So when we're talking about the core, as we might imagine, this is arguably the
most critical
component in the entire network.
This is that the center or the hub of the hierarchical network model.
So it's going to connect to all other network blocks.
This makes it very critical.
If the core goes down, then all of the other blocks are going to be unable to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If the core goes down, then all of the other blocks are going to be unable to
communicate
with one another.
And so we need to make sure that the core is highly resilient and highly robust
.
Ultimately, it needs to stay online.
So uptime is going to be a big conversation when it comes to our core.
But because of how critical our core network is, we might expect that the core
is going
to be very high in features.
We probably want a very expensive switch with lots of features, spare no WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We probably want a very expensive switch with lots of features, spare no
expense for the
core switch, right?
Except we are going to find that this is not the case.
We don't actually care about features when it comes to the core.
And when we're talking about features, we're talking about all kinds of maybe
special
capabilities that a lot of edge switches might have.
And that's because when we're talking about the core of the network, we don't
care necessarily
about being able to power up phones, for example. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
about being able to power up phones, for example.
I mean, do we need power over ethernet on our core switch?
And we'd probably say, no, you know what?
We don't actually need power over ethernet at the core.
We shouldn't be connecting phones or access points to the core switch.
And so these are the types of features that we can probably do without when it
comes
to speccing out a core switch that we want to deploy.
So aside from up time, what do we care most about when it comes to the core?
Well, first of all, we're going to care about our interconnections. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, first of all, we're going to care about our interconnections.
We just said that we're going to connect all of the other network blocks.
And so that's probably going to require some amount of concern around how we're
going
to connect to all of the other network switches that are out there that need to
form connections
to the core.
The other thing that we're going to care heavily about is how fast we can
switch among those
blocks.
So this is going to involve fast switching, but not just fast switching in
general, specifically WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
general, specifically
fast layer three switching.
Now we talk about layer three, sometimes our focus is on the routing concept.
But when we're talking about a switch, we can very quickly switch packets via
hardware
mechanisms.
That's what we're talking about with fast layer three switching.
Having all of the routes already updated, hopefully in a stable environment,
will allow us
to bring a packet in and very quickly, very, very quickly from a time WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to bring a packet in and very quickly, very, very quickly from a time
perspective.
That's a clock in there.
If you couldn't tell with all the hour and then a hand, little, okay, yeah, it
's a clock.
Either way, the packet comes in, went to very quickly, switch this out from the
incoming
interface or ingress to the outgoing interface or the egress.
So let's drill into these in a little bit more detail.
Let's start with the interconnections.
Now, again, the core is going to connect to all of our other blocks, but when
we think about
it from a block to block perspective, it's easy to see that, yeah, we just have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it from a block to block perspective, it's easy to see that, yeah, we just have
a single
connection here.
That's great from a logical perspective, but not so great from a physical
perspective.
So instead, what we do is we have two switches here at the core and let's say
we're connecting
to a distribution layer.
So we're going to have a pair of switches over here at the distribution layer
and we want
to connect these all together.
So what we do is we connect through that line that we drew and maybe we create WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So what we do is we connect through that line that we drew and maybe we create
a full
mesh of connectivity.
Now depending on the fiber connections, we might be limited.
We might only be able to do a pair of these connections, get rid of that line
in the middle.
And so now we just have two connections going between the two, but we do
absolutely want
to be redundant here.
And so what we care a lot about here is making sure that we have the proper
port count.
Because it's not just this one distribution block, we might have several
distribution blocks.
And so now we need to make sure that we have two or maybe even four connections WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so now we need to make sure that we have two or maybe even four connections
going
out to each one of these.
And as we can see, just from this basic drawing, we're going to run out of
ports very quickly
if we under spec our switches.
Now the other thing to consider is the port type.
Now we might have a lot of distribution switches if we're on a campus.
And at that point, we have to care about is this multi-mode fiber?
Is it single mode fiber?
For the most part, if we're going outside of our building, it's probably going WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
For the most part, if we're going outside of our building, it's probably going
to be single
mode fiber.
But in general, it doesn't actually matter a whole lot more speaking out our
switches,
because these are going to be the optics or the transceivers that we install
into a modular
switch.
What matters most is do we have enough SFP slots?
And for that matter, do we have enough Q SFP slots?
Now at the time of this video, we're talking about usually SFP 28 slots and Q
SFP 28 slots, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
SFP 28 slots,
and we are already seeing Q SFP and SFP 56 slots coming out.
And essentially what that translates into is the speed.
So do we need our 10 and our 25 and our 50 gig ports?
And this would be the SFP form factor.
Or do we want to go with 40 gig and 100 and 200 and beyond?
Well at that point, we need the Q SFP form factor.
So back in the day, a long time ago, we had SFP plus and Q SFP plus in this map WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So back in the day, a long time ago, we had SFP plus and Q SFP plus in this map
to 10 gig
and 40 gig respectively.
But we'll pass those days.
We can use these same form factors to gear up and have again up to 50 gig on a
single SFP
slot.
But again, that's not SFP plus anymore.
That would be our SFP 56 and our Q SFP 56.
And for that matter, we might even see Q SFP DDs in here and so on and so forth
.
So we have a lot of different port types and between making sure we have the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we have a lot of different port types and between making sure we have the
right types
and the right port count.
That's going to be a big part of our conversation when we're speccing out a
core switch.
Now I've been in various roles in the industry throughout my entire career, a
significant part
of my career was spent doing network designs.
And so anytime we had a network core or even if it was a collapsed core type of
environment,
but either way, if we were speccing out core switches, this is primarily what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but either way, if we were speccing out core switches, this is primarily what
we cared
about.
We wanted to make sure that we had a switch that had enough ports.
And again, it might be a little bit of a surprise for somebody just first
learning about network
designs like, well, the core switch, we really just care about port count.
We don't care about, again, all these features and capabilities and all of that
.
And unless we're talking about how I can connect to my other network blocks or
unless we're
talking about how fast we can switch packets, then for the most part, no, we're
not worried
as much about those other features. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as much about those other features.
We just need to make sure that number one, we have enough ports for today and
number
two, we have enough ports for future growth.
And it's not just a matter of having enough SFP ports.
What if one day I want to migrate and have 200 gig on these interfaces?
At that point, I couldn't do that on SFP anymore.
I would need QSFP to do it.
And so lots of conversations, potentially around the different options.
We could look at modular chassis switches to future proofs as well.
Lots of things there. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Lots of things there.
The key takeaway to this conversation up to this point is that we're really
looking at
here as far as the core is concerned is carrying greatly about the port type
and the port
count.
Now, I did mention there that there is something else we care about, which is
right here, our
Fast Layer 3 switching.
We can't just grab any switch that has these ports and call it a core switch.
Yes, that's an important step, but we have to have the next step, which is to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Yes, that's an important step, but we have to have the next step, which is to
zero in on
performance.
Now, performance can be measured in a lot of different ways when it comes to
different
switch hardware types.
So we need to really take a look at things from a data plane perspective
because that's
the switching part.
And this can be broken up into two facets.
First of all, we want to make sure we have what's known as non-blocking back
planes.
And this ties to bandwidth. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this ties to bandwidth.
So we just said that we might want 200 gig, for example, on a switch.
So let's say that I have a switch here and I have a 200 gig port on this side
and a 200
port gig port on this other side.
So what if I am sending in 200 gig of traffic and that is getting sent out over
here at the
same time that 200 gig traffic is getting sent back? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
same time that 200 gig traffic is getting sent back?
Well, that is a total of 400 gig of throughput that's happening here on this
switch.
And when we drill into switch architecture, there is a back plane that is
handling all of
that traffic for us.
So the question is, can this back plane handle 400 gig?
And for that matter, most back planes today could handle at least that much
traffic.
But what if I have a bunch more 200 gig ports?
Well at this point, we might start to hit a limit to the back plane. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well at this point, we might start to hit a limit to the back plane.
And so if we can have a non-blocking back plane, what that's saying is if every
port is firing
inbound and outbound traffic at the max data rate that the back plane won't be
overrun.
And so this basically is saying that we're not going to use any over
subscription on the
back plane itself.
This is an important concept when it comes to our core switches because we need
to make
sure that once again, we can do this fast layer 3 switching to bring traffic in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
sure that once again, we can do this fast layer 3 switching to bring traffic in
from one network
block and forward it out to the next network block.
The entire purpose of the core is to perform these interconnections and then
switch traffic
between them.
And so that's the first thing that we need to do.
Number one, we need to make sure that as much as possible, we're in a non-block
ing state,
or at a minimum that the back plane can handle the amount of bandwidth that we
expect to be
throwing at it.
But there is a second component to this and this has to do with the number of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But there is a second component to this and this has to do with the number of
packets that
can be processed per second.
So packets per second that the switch can process.
This is something that can get overlooked when we're talking about speccing out
a core
switch.
And the reason for that is because we tend to focus on bandwidth.
And I'm as guilty of that as anybody.
I mean, it's really fun to talk about 50 gig and 200 gig and even 408, 100 gig
pipes and
all of these different amounts of throughput that we might be throwing at our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
all of these different amounts of throughput that we might be throwing at our
core switch.
That is really easy to grasp and easy to expect.
We know what a 200 gig a bit per second pipe looks like.
The challenge is how many packets will we be sending in there?
Because if we're sending 1500 byte packets at 200 gig.
Well that's a whole lot fewer packets than if we're sending 100 byte packets at
200 gig.
This is a very low packet count. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is a very low packet count.
This is a very high packet count.
There's going to be 15 times the number of packets being sent if they are only
100 bytes
in size and we still have the same bandwidth.
So the amount of packets that can be processed per second is a spec on every
network switch.
We need to be paying attention to the packets per second to make sure that we
're not putting
a switch in place that has all the right port counts and port types even WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a switch in place that has all the right port counts and port types even
supporting the
right amount of bandwidth.
But the overall performance from a packet's perspective, packets per second
perspective is
not enough.
Now from a practical perspective, we might say, well, okay, but how many
packets per second
is enough?
That's very difficult to evaluate.
But here's the good news.
When we go to Cisco's website, we're often going to be faced with a series of
switches.
So traditionally, Cisco used to have, let's say, 3650 and 3850 switches. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So traditionally, Cisco used to have, let's say, 3650 and 3850 switches.
In the modern era, we have lots of catalysts, 9K.
So 9300, 9400s, and so on and so forth.
Well if we go out to Cisco's website, Cisco's going to tell us which of those
switches is designed
to be a network core.
Now could I take a catalyst 9300 and turn it into a network core for a small
organization?
Absolutely.
Sure I could.
But Cisco will say, hey, but that's an access layer switch.
So why can I get away with that?
Well, because for a small network, if we have the right amount of port counts WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, because for a small network, if we have the right amount of port counts
and port types
in the packets per second, the performance of that switch is going to be enough
for the
smaller organization.
But if I take it at 9300, plug it into the core for a global organization, they
're not going
to hold up very well because they can't keep up with the amount of packets that
is trying
to process at once.
And furthermore, we might have issues with backplane over subscription.
So instead, we can look at Cisco's website and say, okay, what do you recommend
Cisco WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Cisco
as a core network switch?
Maybe that's a catalyst, 9500 or 9600 or whatever it ends up being by the time
that you're
going out to that website and taking a look at it because Cisco's portfolio is
constantly
evolving.
When Cisco says it's a core switch, we can go out and look at the packets per
second in
the over subscription ratio.
But we can expect that it's going to be good news because Cisco wouldn't be
saying that
they are creating a switch to be a core switch if it didn't have the proper
performance metrics
in order to serve in that role. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in order to serve in that role.