WEBVTT

1
00:00.000 --> 00:04.830
But believe it or not, when we talk about routers and layer three devices, we

2
00:04.830 --> 00:06.080
're usually talking

3
00:06.080 --> 00:08.520
about them performing routing.

4
00:08.520 --> 00:10.640
And they do perform routing.

5
00:10.640 --> 00:14.000
That involves looking things up from a routing table perspective.

6
00:14.000 --> 00:18.380
But believe it or not, they also perform switching.

7
00:18.380 --> 00:22.160
Just why we often talk about the concept of layer three switching.

8
00:22.160 --> 00:26.730
And so when we're looking at things from simply a process perspective, it's

9
00:26.730 --> 00:27.560
going to be very

10
00:27.560 --> 00:33.560
important to understand how exactly packets get switched within a layer three
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:27.560 --> 00:33.560
important to understand how exactly packets get switched within a layer three

11
00:33.560 --> 00:34.640
device.

12
00:34.640 --> 00:38.800
So what we're talking about here is we have our layer three device and a packet

13
00:38.800 --> 00:39.280
has just

14
00:39.280 --> 00:40.520
arrived.

15
00:40.520 --> 00:47.230
Well the routing side of things is going to look at the rib and it's going to

16
00:47.230 --> 00:47.960
decide

17
00:47.960 --> 00:52.720
which interface to send it out as well as what that next top is.

18
00:52.720 --> 00:58.220
The process of switching it over and writing the new headers, this is the

19
00:58.220 --> 00:59.520
switching part

20
00:59.520 --> 01:00.600
of it.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

20
00:59.520 --> 01:00.600
of it.

21
01:00.600 --> 01:05.350
And so we want to be able to perform this switching, which again involves the

22
01:05.350 --> 01:06.080
interface

23
01:06.080 --> 01:11.400
and the new layer two header, want to perform this operation as fast as

24
01:11.400 --> 01:12.400
possible.

25
01:12.400 --> 01:16.080
And from start to finish here really, even the rib part, we really want to try

26
01:16.080 --> 01:16.560
to speed

27
01:16.560 --> 01:19.400
this up, however we can do it.

28
01:19.400 --> 01:22.680
So how exactly does this process work?

29
01:22.680 --> 01:26.280
Well at a fundamental level, we have the concept of process routing.

30
01:26.280 --> 01:34.420
This is how we're going to perform routing by involving the route processor or
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:26.280 --> 01:34.420
This is how we're going to perform routing by involving the route processor or

31
01:34.420 --> 01:35.640
the CPU.

32
01:35.640 --> 01:41.140
The router CPU is going to be involved with process routing and really this is

33
01:41.140 --> 01:41.840
the, again

34
01:41.840 --> 01:48.750
the foundational version of performing layer three switching because it can't

35
01:48.750 --> 01:49.880
get any simpler

36
01:49.880 --> 01:51.360
than this.

37
01:51.360 --> 01:56.890
What happens here is the packet arrives and the packet gets processed by the

38
01:56.890 --> 01:58.080
CPU itself.

39
01:58.080 --> 02:03.100
The CPU is going to check the rib and get all the information and then the CPU
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

39
01:58.080 --> 02:03.100
The CPU is going to check the rib and get all the information and then the CPU

40
02:03.100 --> 02:03.720
is also

41
02:03.720 --> 02:07.820
going to check the layer two information such as checking the art table and

42
02:07.820 --> 02:09.000
everything to

43
02:09.000 --> 02:13.190
build the new layer two header and then it's going to place it onto the new

44
02:13.190 --> 02:14.160
interface for

45
02:14.160 --> 02:15.600
us.

46
02:15.600 --> 02:19.200
This is an intensely slow process.

47
02:19.200 --> 02:24.480
For a couple of reasons, first of all the CPU is, yeah it's plenty fast but it

48
02:24.480 --> 02:25.280
's really

49
02:25.280 --> 02:29.270
not built to operate at the speed at which we're talking about here at least

50
02:29.270 --> 02:29.760
when we

51
02:29.760 --> 02:33.810
think about receiving gigabits per second of packets and having to do this that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

51
02:29.760 --> 02:33.810
think about receiving gigabits per second of packets and having to do this that

52
02:33.810 --> 02:34.120
many

53
02:34.120 --> 02:38.480
times per second, especially when it has other responsibilities.

54
02:38.480 --> 02:39.480
And that's just it.

55
02:39.480 --> 02:46.040
A CPU is going to perform operations in a list or sequential order.

56
02:46.040 --> 02:51.360
And so it might have lots of operations here and so operations like crazy.

57
02:51.360 --> 02:55.280
And so at some point we need to process the packet that just arrived.

58
02:55.280 --> 02:59.640
So it's going to wait for that process in order to perform it.

59
02:59.640 --> 03:04.730
So maybe finally here we can actually take a look at the packet and do
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
02:59.640 --> 03:04.730
So maybe finally here we can actually take a look at the packet and do

60
03:04.730 --> 03:05.960
everything that

61
03:05.960 --> 03:08.200
needs to and send that packet on.

62
03:08.200 --> 03:12.940
But then we're waiting until the next opportunity for the next packet to be

63
03:12.940 --> 03:13.560
sent.

64
03:13.560 --> 03:16.810
And meanwhile we're just waiting in here for the CPU to do all the other things

65
03:16.810 --> 03:17.120
that

66
03:17.120 --> 03:21.200
are responsible for on the platform.

67
03:21.200 --> 03:26.400
So that's number one why this whole process is very slow.

68
03:26.400 --> 03:31.240
There's a second reason however and that has to do with the rib itself.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

68
03:26.400 --> 03:31.240
There's a second reason however and that has to do with the rib itself.

69
03:31.240 --> 03:36.160
Rib lookups operate sequentially.

70
03:36.160 --> 03:42.800
Meaning that if I have to, if I have to look up a particular subnet, I have to

71
03:42.800 --> 03:43.520
look through

72
03:43.520 --> 03:50.450
all of the routes in order or more to the point, I have to look at every single

73
03:50.450 --> 03:51.120
route

74
03:51.120 --> 03:53.680
until I have found a match.

75
03:53.680 --> 03:59.560
So if I have 1000 routes, this might take 1000 different lookups.

76
03:59.560 --> 04:03.770
If it happens to be the very last route that I take a look at, it's going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

76
03:59.560 --> 04:03.770
If it happens to be the very last route that I take a look at, it's going to

77
04:03.770 --> 04:04.560
take a very

78
04:04.560 --> 04:08.160
long time to get through the rib.

79
04:08.160 --> 04:13.530
So if I have to do this with every single packet and when I think about the

80
04:13.530 --> 04:14.920
concept of waiting

81
04:14.920 --> 04:20.680
for the CPU to be available, plus how long it takes for the rib lookups to

82
04:20.680 --> 04:21.520
happen, this

83
04:21.520 --> 04:24.280
would be very, very slow.

84
04:24.280 --> 04:28.560
So we need to come up with methods for speeding this up.

85
04:28.560 --> 04:33.880
Now the first method that was developed was known as fast switching.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

85
04:28.560 --> 04:33.880
Now the first method that was developed was known as fast switching.

86
04:33.880 --> 04:37.830
Fast switching is not what we prefer to use today, but it was a step in the

87
04:37.830 --> 04:39.160
right direction.

88
04:39.160 --> 04:46.200
And the idea here was to, first of all, perform process switching one time.

89
04:46.200 --> 04:53.680
So we perform process switching on the first packet.

90
04:53.680 --> 04:57.000
That's going to a particular destination.

91
04:57.000 --> 05:00.770
Then what we're going to do is we're going to create a cache and we're going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

91
04:57.000 --> 05:00.770
Then what we're going to do is we're going to create a cache and we're going to

92
05:00.770 --> 05:01.120
cache

93
05:01.120 --> 05:05.320
that destination.

94
05:05.320 --> 05:09.490
So now when there's a new destination that comes in, it's going to have to go

95
05:09.490 --> 05:10.080
through

96
05:10.080 --> 05:15.640
the entire process routing process and then it will get forwarded on.

97
05:15.640 --> 05:17.200
No problem.

98
05:17.200 --> 05:22.600
When an old, we'll call it old here, maybe we should say it's a repeat.

99
05:22.600 --> 05:24.600
Let's use that word instead of old.

100
05:24.600 --> 05:29.980
When we have a repeat destination come in, well, instead of going through the

101
05:29.980 --> 05:30.640
process
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
05:29.980 --> 05:30.640
process

102
05:30.640 --> 05:36.880
routing process, we are going to check that cache.

103
05:36.880 --> 05:40.230
This cache is going to be a whole lot faster in terms of getting the

104
05:40.230 --> 05:41.360
information that I

105
05:41.360 --> 05:44.000
need so that I can send this out quickly.

106
05:44.000 --> 05:45.880
So this accomplishes two things.

107
05:45.880 --> 05:49.960
First of all, the cache is faster.

108
05:49.960 --> 05:55.760
So it's a faster lookup process, which is important compared to the rib being a

109
05:55.760 --> 05:56.000
slow

110
05:56.000 --> 05:57.800
process here.

111
05:57.800 --> 06:04.080
And second of all, we don't have to wait for the CPU's availability.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

111
05:57.800 --> 06:04.080
And second of all, we don't have to wait for the CPU's availability.

112
06:04.080 --> 06:06.640
And so fast switching actually lives up to its name.

113
06:06.640 --> 06:14.000
It's a much faster way for us to perform routing on a layer three device.

114
06:14.000 --> 06:18.490
However, we do still have some problems here and it really especially involves

115
06:18.490 --> 06:19.120
the fact

116
06:19.120 --> 06:22.080
that we're still relying on process switching.

117
06:22.080 --> 06:28.760
It's the first packet of every destination.

118
06:28.760 --> 06:31.880
And our cache is only, I mean, it's limited.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

118
06:28.760 --> 06:31.880
And our cache is only, I mean, it's limited.

119
06:31.880 --> 06:34.400
We're going to run out of space eventually.

120
06:34.400 --> 06:38.530
And so occasionally a repeat destination is still going to have to go back

121
06:38.530 --> 06:39.040
through the

122
06:39.040 --> 06:43.880
process routing process in order to repopulate the cache.

123
06:43.880 --> 06:46.840
And so those are some problems with fast switching.

124
06:46.840 --> 06:49.400
And fortunately we do have a solution to this.

125
06:49.400 --> 06:52.120
is known as Cisco Express Forwarding or SEF.

126
06:52.120 --> 07:02.120
[BLANK_AUDIO]