WEBVTT

1
00:00.000 --> 00:04.310
So let's begin with a discussion of normal routing based on the routing tables

2
00:04.310 --> 00:04.880
on our routers.

3
00:04.880 --> 00:09.180
Let's presume that we have OSPF that's currently configured as shown in this

4
00:09.180 --> 00:09.920
topology.

5
00:09.920 --> 00:15.440
And as a result, if we send a packet from PC7, which is a 10-1-7-10, and we're

6
00:15.440 --> 00:16.000
trying to reach,

7
00:16.000 --> 00:21.280
for example, how about PC8 over here, that traffic based on the routing tables

8
00:21.280 --> 00:21.600
in the current

9
00:21.600 --> 00:25.680
topology would go this way to a Steve Olgateway, and then here, and then here,

10
00:25.680 --> 00:26.560
and then here,

11
00:26.560 --> 00:31.200
and then here, and here, and here, and finally to here, and the return path
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:26.560 --> 00:31.200
and then here, and here, and here, and finally to here, and the return path

12
00:31.200 --> 00:32.320
would take the reverse path.

13
00:32.320 --> 00:36.000
And that's based on normal routing. With each router using its own routing

14
00:36.000 --> 00:36.720
table to make that

15
00:36.720 --> 00:41.360
routing decision. In fact, let's just for a moment verify that's the path that

16
00:41.360 --> 00:42.800
PC7 packet would

17
00:42.800 --> 00:46.400
take as it goes through this existing topology. So here in the lab environment,

18
00:46.400 --> 00:48.080
we went to PC7,

19
00:48.080 --> 00:51.610
and we did a ping. Let's just verify we can ping 192. Let's bring up the top

20
00:51.610 --> 00:53.280
ology as well by

21
00:53.280 --> 00:59.620
looking at here once again. So the default gateway on PC7 is 10.1.7.7, and that

22
00:59.620 --> 01:00.240
's R7,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
00:59.620 --> 01:00.240
's R7,

23
01:00.240 --> 01:05.240
and I believe all the routes are in place. So if we do a ping over to PC8 at 19

24
01:05.240 --> 01:06.720
2.1.10,

25
01:06.720 --> 01:11.190
we can verify first of all connectivity. So we'll press Enter there, and that

26
01:11.190 --> 01:11.840
connectivity works.

27
01:11.840 --> 01:15.960
Let's also verify the path with a trace. We'll do a trace from this little

28
01:15.960 --> 01:16.960
virtual PC,

29
01:16.960 --> 01:21.160
and it's going to trace to the same address. So I'll copy paste it. And by

30
01:21.160 --> 01:22.000
default, this little

31
01:22.000 --> 01:26.320
PC is using UDP. If we want to change the protocol, we can go ahead instead of

32
01:26.320 --> 01:27.360
just using the default

33
01:27.360 --> 01:31.900
of UDP. We can go ahead and hit the upper key and do a dash capital P, and then
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:27.360 --> 01:31.900
of UDP. We can go ahead and hit the upper key and do a dash capital P, and then

34
01:31.900 --> 01:32.960
do protocol number

35
01:32.960 --> 01:37.130
one, which is ICMP. So this is using a trace and layer four, it's using ICMP

36
01:37.130 --> 01:38.240
protocol number one.

37
01:38.240 --> 01:43.900
And that verifies the path. So R7 is the first top, then R5, then R3, R1, R2, R

38
01:43.900 --> 01:45.040
4, and R8.

39
01:45.040 --> 01:49.250
So currently routing is in place. However, if we want to make exceptions for,

40
01:49.250 --> 01:49.840
for example, a

41
01:49.840 --> 01:53.800
specific host or a specific subnet, or based on the type of protocol it's being

42
01:53.800 --> 01:55.360
used, we want to override

43
01:55.360 --> 01:59.800
what's currently in the routing table. We can do that with policy-based routing

44
01:59.800 --> 02:00.480
. And the way
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

44
01:59.800 --> 02:00.480
. And the way

45
02:00.480 --> 02:03.580
policy-based routing works is we can apply a policy to an interface. For

46
02:03.580 --> 02:04.800
example, gig 00,

47
02:04.800 --> 02:08.690
and then any ingress or inbound traffic coming in on the interface, it's going

48
02:08.690 --> 02:09.440
to be analyzed by

49
02:09.440 --> 02:14.080
that policy. And then if there's a match based on our criteria for that policy,

50
02:14.080 --> 02:14.960
the router can

51
02:14.960 --> 02:18.610
override what's currently in the routing table. So we can make a policy here on

52
02:18.610 --> 02:19.120
R7. It says,

53
02:19.120 --> 02:22.470
you know, it based on a certain set of criteria. For example, this source

54
02:22.470 --> 02:23.680
address and a certain

55
02:23.680 --> 02:27.430
layer for protocol and based on a destination address. Instead of using the

56
02:27.430 --> 02:28.560
routing table, let's go

57
02:28.560 --> 02:32.010
ahead and simply forward that specific traffic based on the policy being
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

57
02:28.560 --> 02:32.010
ahead and simply forward that specific traffic based on the policy being

58
02:32.010 --> 02:33.360
matched directly over here

59
02:33.360 --> 02:38.680
to R8 over this link 107800. And the next top over here is .8. So a couple of

60
02:38.680 --> 02:39.520
rules of the role

61
02:39.520 --> 02:43.360
regarding policy-based routing. Once we set it up and configure it, in fact,

62
02:43.360 --> 02:44.080
let's talk about how we

63
02:44.080 --> 02:47.120
would configure it. We're going to use an access control list to identify the

64
02:47.120 --> 02:48.080
traffic that could be a

65
02:48.080 --> 02:51.950
standard access control list, just looking at the source IP information, or we

66
02:51.950 --> 02:52.720
're using extended

67
02:52.720 --> 02:57.370
ACL, including the source and or destination, as well as layer for protocols

68
02:57.370 --> 02:58.400
and ports if we wanted

69
02:58.400 --> 03:02.210
to. And then we're going to use that access list to identify the traffic inside
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

69
02:58.400 --> 03:02.210
to. And then we're going to use that access list to identify the traffic inside

70
03:02.210 --> 03:03.040
of a route map.

71
03:03.040 --> 03:05.600
And in that route map, we're going to call upon that access control list for

72
03:05.600 --> 03:06.240
identifying the

73
03:06.240 --> 03:10.260
traffic. And if it matches, we can then say, please set the next top two and we

74
03:10.260 --> 03:11.040
can refer to the

75
03:11.040 --> 03:14.480
next top address of the router we want to forward that packet to. Or if it's

76
03:14.480 --> 03:15.680
serialing, we could also

77
03:15.680 --> 03:19.120
point to the actual interface as the egress interface. And then the last step

78
03:19.120 --> 03:20.160
to make this work is we'd

79
03:20.160 --> 03:24.050
apply the policy to an interface. In this example, here we'd apply it to

80
03:24.050 --> 03:25.520
interface gig 00. So any

81
03:25.520 --> 03:29.730
traffic coming in on gig 00 would be amized by the policy. And if it matched

82
03:29.730 --> 03:31.120
the policy, it would go
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

82
03:29.730 --> 03:31.120
the policy, it would go

83
03:31.120 --> 03:34.880
ahead and use the next top in this example going over to R8. Or if it didn't

84
03:34.880 --> 03:35.840
match the policy,

85
03:35.840 --> 03:40.060
it would simply be routed based on the normal routing table on R7. So based on

86
03:40.060 --> 03:40.880
the access control

87
03:40.880 --> 03:45.150
list, we set up to match certain types of traffic. We could base it on source

88
03:45.150 --> 03:46.880
IP address and or destination

89
03:46.880 --> 03:51.220
address and or layer four protocol involved or any combination of those. And

90
03:51.220 --> 03:52.160
one thing to remember

91
03:52.160 --> 03:56.520
is that when we set up policy based routing, it's only applicable for incoming

92
03:56.520 --> 03:57.680
or inbound traffic

93
03:57.680 --> 04:01.380
as it comes into the interface. And so at that point, the policy is analyzed.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

93
03:57.680 --> 04:01.380
as it comes into the interface. And so at that point, the policy is analyzed.

94
04:01.380 --> 04:02.240
And if it matches,

95
04:02.240 --> 04:05.910
it takes the action that's specified in the policy. For example, sitting the

96
04:05.910 --> 04:06.560
next top over here

97
04:06.560 --> 04:10.220
to R8 instead of forwarding it normally up here to R5. One other thing to be

98
04:10.220 --> 04:10.480
aware of,

99
04:10.480 --> 04:14.310
regarding policy based routing is that it applies to transit traffic, meaning

100
04:14.310 --> 04:15.120
traffic that the

101
04:15.120 --> 04:19.610
router is routing on behalf of other devices. For example, from PC7, is that

102
04:19.610 --> 04:20.560
traffic comes in or from

103
04:20.560 --> 04:24.070
other devices on this network as it comes in on gig 00 if that's where the

104
04:24.070 --> 04:25.120
policy is applied.

105
04:25.120 --> 04:29.560
However, it does not apply by default to traffic generated by the router itself

106
04:29.560 --> 04:31.680
. So if we're in R7
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
04:29.560 --> 04:31.680
. So if we're in R7

107
04:31.680 --> 04:37.430
and we did a ping for example of the IP address over here at PC 10, that

108
04:37.430 --> 04:38.320
traffic even if we

109
04:38.320 --> 04:42.400
sourced it from gig 00 where we have the policy applied, it doesn't apply to

110
04:42.400 --> 04:43.680
traffic sourced by the

111
04:43.680 --> 04:48.770
router itself. But we can, if we want to enable a local policy option. And with

112
04:48.770 --> 04:49.680
the option of setting

113
04:49.680 --> 04:54.130
up a local policy for policy based routing, that does indeed apply to traffic

114
04:54.130 --> 04:54.880
generated by the

115
04:54.880 --> 04:58.680
router itself. So by default, if we apply it to an interface, it's for traffic

116
04:58.680 --> 04:59.440
coming in on that

117
04:59.440 --> 05:03.180
interface. And if we want to go ahead and set up policy based routing for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

117
04:59.440 --> 05:03.180
interface. And if we want to go ahead and set up policy based routing for

118
05:03.180 --> 05:03.840
locally generated

119
05:03.840 --> 05:06.590
traffic by the router itself, there's a command we can do that can implement

120
05:06.590 --> 05:07.520
that policy as local

121
05:07.520 --> 05:11.020
policy. And then we don't have to tie it specifically to an interface because

122
05:11.020 --> 05:12.160
any traffic matching the

123
05:12.160 --> 05:15.990
access control list and we apply it as a local policy and the router generates

124
05:15.990 --> 05:17.360
traffic, it'll be applied

125
05:17.360 --> 05:21.150
to that router generated traffic. Because if we set up a local policy and there

126
05:21.150 --> 05:22.080
's a match regarding

127
05:22.080 --> 05:24.980
the access control list for guarantee traffic that the router is generating,

128
05:24.980 --> 05:25.760
then regardless of which

129
05:25.760 --> 05:28.970
interface we're using the source of traffic, it'll go ahead and if there's a

130
05:28.970 --> 05:29.840
policy match, it'll

131
05:29.840 --> 05:34.370
set the next top appropriately and apply the policy based routing. And if there
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

131
05:29.840 --> 05:34.370
set the next top appropriately and apply the policy based routing. And if there

132
05:34.370 --> 05:35.360
's traffic that when

133
05:35.360 --> 05:38.960
that traffic comes into the router and it doesn't match the policy based

134
05:38.960 --> 05:40.320
routing rules, it doesn't mean

135
05:40.320 --> 05:43.070
the traffic is being dropped, it just means the traffic is going to be routed

136
05:43.070 --> 05:44.240
as normal. And we also have

137
05:44.240 --> 05:48.650
some debugging we can do to see exactly when it's doing policy based routing

138
05:48.650 --> 05:50.080
and when it's forwarding

139
05:50.080 --> 05:53.760
based on its normal IP routing table. So that's a high level overview regarding

140
05:53.760 --> 05:54.880
the idea behind

141
05:54.880 --> 05:58.180
policy based routing. And in the next video, I'll walk through an example of

142
05:58.180 --> 05:59.200
putting it to work.

143
05:59.200 --> 06:01.120
So I'll see you there in just a moment.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

143
05:59.200 --> 06:01.120
So I'll see you there in just a moment.