WEBVTT

1
00:00.000 --> 00:02.980
In this video, I'd like to walk through an example of using policy-based

2
00:02.980 --> 00:04.080
routing, but this time,

3
00:04.080 --> 00:08.240
including a specific layer for protocol. So because we're using an access

4
00:08.240 --> 00:09.280
control list,

5
00:09.280 --> 00:13.520
we want to be using an extended ACL that can match on things such as layer for

6
00:13.520 --> 00:14.080
protocols

7
00:14.080 --> 00:17.930
in addition to source and/or destination. And then include that once again in a

8
00:17.930 --> 00:18.640
route map.

9
00:18.640 --> 00:23.010
And then apply that route map as a policy on a given interface. So the a

10
00:23.010 --> 00:23.840
traffic going into

11
00:23.840 --> 00:27.780
the interface is going to consider the ACL. See if there's a match. And if so,

12
00:27.780 --> 00:28.320
take the action

13
00:28.320 --> 00:31.150
specified in the route map. So we'll put a polite interface as the last step
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

13
00:28.320 --> 00:31.150
specified in the route map. So we'll put a polite interface as the last step

14
00:31.150 --> 00:32.560
there. Now as far as

15
00:32.560 --> 00:36.540
what we want to do in this demonstration with layer for protocols, let's do the

16
00:36.540 --> 00:38.000
following. Let's

17
00:38.000 --> 00:43.500
match on TCP traffic. And focus on just the TCP. Let's go ahead and say from

18
00:43.500 --> 00:45.120
anywhere to anywhere.

19
00:45.120 --> 00:49.030
So effectively, if there's TCP at layer four, it's going to go ahead and be a

20
00:49.030 --> 00:50.320
match in the ACL.

21
00:50.320 --> 00:54.900
So let's create ACL 103 that matches on that. Let's also apply this one to

22
00:54.900 --> 00:56.000
router 3. And let's

23
00:56.000 --> 01:01.090
apply this traffic inbound right here on F a 4/1. So if any traffic coming in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
00:56.000 --> 01:01.090
apply this traffic inbound right here on F a 4/1. So if any traffic coming in

24
01:01.090 --> 01:03.040
on interface F a 4/1,

25
01:03.040 --> 01:06.000
instead of forwarding normally based on the routing table, which would be going

26
01:06.000 --> 01:06.800
up to R1,

27
01:06.800 --> 01:11.000
that'd be the next hop in the path based on this routing table for IP packets.

28
01:11.000 --> 01:11.440
Instead of that,

29
01:11.440 --> 01:18.500
let's go ahead and have PBR use the next top of R4 at 10.0.34.4. So let me go a

30
01:18.500 --> 01:19.120
little note there

31
01:19.120 --> 01:23.400
next top for TCP based traffic will be our fours address on its F a 4/1

32
01:23.400 --> 01:25.920
interface, which is 10.0.34.4.

33
01:25.920 --> 01:30.020
And then everything else would be normally routed. So I propose that to test
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:25.920 --> 01:30.020
And then everything else would be normally routed. So I propose that to test

34
01:30.020 --> 01:31.280
this before we implement

35
01:31.280 --> 01:35.830
the policy based routing here, let's go down to PC7. Let's just verify that PC7

36
01:35.830 --> 01:36.800
traffic, which goes

37
01:36.800 --> 01:41.770
to the default gateway here R7 and goes this way and this way. Let's verify

38
01:41.770 --> 01:42.640
that that traffic is

39
01:42.640 --> 01:47.690
TCP by default is being routed up through R1, then to R2 and then down this way

40
01:47.690 --> 01:48.960
. And for the target,

41
01:48.960 --> 01:53.580
let's go ahead and use the target of this address 6.6.6.6, which is the loop

42
01:53.580 --> 01:55.360
back address here on R6.

43
01:55.360 --> 01:59.760
So as a confirmation of the current path before we implement the policy based

44
01:59.760 --> 02:00.800
routing here on R3,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

44
01:59.760 --> 02:00.800
routing here on R3,

45
02:00.800 --> 02:05.570
let's once again just verify with a trace using TCP the path that's currently

46
02:05.570 --> 02:06.640
being taken.

47
02:06.640 --> 02:13.030
So if we go to PC7 and let's go ahead and do a ping to 6.6.6.6, it's to verify

48
02:13.030 --> 02:13.600
connectivity,

49
02:13.600 --> 02:19.840
fantastic, and then we'll do a trace. And then let's do a trace to 6.6.6.6. And

50
02:19.840 --> 02:20.800
I also want to do a

51
02:20.800 --> 02:25.320
dash p space 6. And what that's going to do is going to use protocol number 6,

52
02:25.320 --> 02:27.360
aka TCP. So let's go

53
02:27.360 --> 02:31.610
ahead and verify that first. So there's our path through the network from PC7
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
02:27.360 --> 02:31.610
ahead and verify that first. So there's our path through the network from PC7

54
02:31.610 --> 02:33.280
to R7 and then based

55
02:33.280 --> 02:38.830
on that last octet to R5, then to R3, then to R1, R2, then to R4 and then the

56
02:38.830 --> 02:40.400
loop back on R6.

57
02:40.400 --> 02:44.270
And then R6 response. If we did it again, we used a different protocol like for

58
02:44.270 --> 02:44.800
example,

59
02:44.800 --> 02:50.090
protocol 1, which is ICMP, we're going to have the same path. So R7, R5, R3, R1

60
02:50.090 --> 02:51.440
, R2, R4,

61
02:51.440 --> 02:55.350
and finding hits, R6. So in the future, once we have a policy based routing set

62
02:55.350 --> 02:56.240
up on R3,

63
02:56.240 --> 03:00.400
we should be skipping R1 and R2. It should be setting the traffic directly over
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

63
02:56.240 --> 03:00.400
we should be skipping R1 and R2. It should be setting the traffic directly over

64
03:00.400 --> 03:01.680
to R4.

65
03:01.680 --> 03:07.110
So we should be able to verify that by these two sets of traces, one with TCP

66
03:07.110 --> 03:07.680
and one with

67
03:07.680 --> 03:12.510
ICMP so we can see the differences. So let's head over to R3 and R3. Let's go

68
03:12.510 --> 03:13.520
ahead and verify if we

69
03:13.520 --> 03:17.100
have access lists yet. So we'll do a show, access lists and let's do a show

70
03:17.100 --> 03:18.800
route map and no access list,

71
03:18.800 --> 03:21.750
no route maps. Great. Let's go ahead and begin. So let's create an access

72
03:21.750 --> 03:23.120
control list. So let's create

73
03:23.120 --> 03:27.300
access list. Let's use one and zero three. I'll say permit TCP from anywhere to

74
03:27.300 --> 03:28.960
anywhere. Fantastic.

75
03:28.960 --> 03:32.720
So next, let's create a route map that's looking to match based on that access
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:28.960 --> 03:32.720
So next, let's create a route map that's looking to match based on that access

76
03:32.720 --> 03:33.680
control list. So we'll

77
03:33.680 --> 03:38.450
type in route map space and let's call this pbr-tcp because that's effectively

78
03:38.450 --> 03:39.680
what's going to be doing.

79
03:39.680 --> 03:42.680
And then we'll say permit and then we can press enter or if you want to give

80
03:42.680 --> 03:43.600
the sequence number,

81
03:43.600 --> 03:47.550
for example, like nine, if that's where you want to start it, you can. Then if

82
03:47.550 --> 03:48.880
you do show route map,

83
03:48.880 --> 03:52.980
we have sequence number nine. Otherwise, it would auto sequence for us. So for

84
03:52.980 --> 03:54.000
this first sequence of

85
03:54.000 --> 03:58.270
nine, we're going to go ahead and match on IP address and it's going to be

86
03:58.270 --> 04:00.320
access list 103. So
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

86
03:58.270 --> 04:00.320
access list 103. So

87
04:00.320 --> 04:03.930
traffic if it's TCP traffic layer four, that's going to match regardless of

88
04:03.930 --> 04:05.120
source or destination.

89
04:05.120 --> 04:09.170
And if there's a match, we want to set the next hop to you 10.0.34.4. Let's

90
04:09.170 --> 04:09.840
take a look at our

91
04:09.840 --> 04:14.730
topology real quick and 10 0 34.4 is indeed the next top address there at our

92
04:14.730 --> 04:15.680
four. We can verify

93
04:15.680 --> 04:19.600
that by going to our four and doing a show IP interface brief. And right there,

94
04:19.600 --> 04:20.240
it's confirming its

95
04:20.240 --> 04:26.550
IP address of 10.0.34.4 on its fast Ethernet 4/1, which matches up with our top

96
04:26.550 --> 04:27.840
ology. Fantastic. So

97
04:27.840 --> 04:30.990
let's go back to our three. So we'll set the next hop and then we're going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
04:27.840 --> 04:30.990
let's go back to our three. So we'll set the next hop and then we're going to

98
04:30.990 --> 04:31.760
go ahead and apply

99
04:31.760 --> 04:36.010
this policy to the interface. So if we look at our topology, the interface, the

100
04:36.010 --> 04:36.880
inbound interface,

101
04:36.880 --> 04:42.160
for traffic coming from PC7 for our test, would be fast Ethernet 4/1. Now if we

102
04:42.160 --> 04:42.400
get thought

103
04:42.400 --> 04:47.600
traffic would also be coming in from gig 1 0 or 0 3/2, we could also apply that

104
04:47.600 --> 04:48.400
policy to those

105
04:48.400 --> 04:53.390
interfaces as well. But for the demo, we want to apply this to just FA 4/1. So

106
04:53.390 --> 04:54.160
on our three, we'll go

107
04:54.160 --> 04:58.300
into interface config for FA 4/1. And here in interface configuration mode, we

108
04:58.300 --> 04:58.880
use the command

109
04:58.880 --> 05:03.350
IP policy and then the keyword route map and then the name of our route map,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
04:58.880 --> 05:03.350
IP policy and then the keyword route map and then the name of our route map,

110
05:03.350 --> 05:04.240
which is called

111
05:04.240 --> 05:08.790
PBR-TCP. So I'm going to copy paste that so I don't have a typo and press enter

112
05:08.790 --> 05:09.360
and it's done.

113
05:09.360 --> 05:13.110
Now to verify our work, we can do a show access list. So there's our ACL. So

114
05:13.110 --> 05:14.000
there's our route map.

115
05:14.000 --> 05:17.830
Fantastic. And we can do a show IP policy to verify where that route map is

116
05:17.830 --> 05:19.040
applied. So our route

117
05:19.040 --> 05:25.560
map called PBR-TCP is applied to FA 4/1. So any traffic coming inbound or ing

118
05:25.560 --> 05:26.880
ress on that interface

119
05:26.880 --> 05:30.470
is going to be considered against that policy. And if it matches, it's going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

119
05:26.880 --> 05:30.470
is going to be considered against that policy. And if it matches, it's going to

120
05:30.470 --> 05:31.040
be policy-based

121
05:31.040 --> 05:35.880
routed using the next top of 10.0.34.4. Here we can also do a debug of IP

122
05:35.880 --> 05:37.360
policy and press enter

123
05:37.360 --> 05:40.920
and that will show us in the output whether or not packets are being policy-

124
05:40.920 --> 05:42.240
based routed or if they're

125
05:42.240 --> 05:44.620
missing that policy and they're just being forwarded based on the normal

126
05:44.620 --> 05:45.840
routing table. So let's go

127
05:45.840 --> 05:51.770
back to PC7 and let's go ahead and do our first trace to 6666 with protocol

128
05:51.770 --> 05:52.960
number 1, which is

129
05:52.960 --> 05:56.500
ICMP. So this one should take the normal path because it's not being policy-

130
05:56.500 --> 05:57.360
based routed.

131
05:57.360 --> 06:04.510
If we go back to R3, here we can see from the debug output that it is normal
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

131
05:57.360 --> 06:04.510
If we go back to R3, here we can see from the debug output that it is normal

132
06:04.510 --> 06:04.960
forwarding because

133
06:04.960 --> 06:09.330
it didn't match the policy. So let's go back to PC7, hit the upper key a couple

134
06:09.330 --> 06:10.160
times and let's go

135
06:10.160 --> 06:14.850
ahead and do the trace once again with this time with protocol 6, which is TCP

136
06:14.850 --> 06:15.600
and this should be

137
06:15.600 --> 06:20.570
policy-based routed. So R1 and R2 should be completely avoided and the packet

138
06:20.570 --> 06:21.840
should go from R3

139
06:21.840 --> 06:26.640
directly over to R4. So let's go ahead and test that and sure enough from R7 to

140
06:26.640 --> 06:28.640
R5 and then to R3

141
06:28.640 --> 06:33.120
and then directly over to R4 until it went to R6. And then if we go back to R3
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

141
06:28.640 --> 06:33.120
and then directly over to R4 until it went to R6. And then if we go back to R3

142
06:33.120 --> 06:33.840
and look at the output

143
06:33.840 --> 06:38.100
for the debug, notice that we have policy-based routing indicated here in the

144
06:38.100 --> 06:38.960
debug output.

145
06:38.960 --> 06:43.110
It's showing us we have that policy applied to FA4/1 so we'll go to interface

146
06:43.110 --> 06:45.280
for interface FA4/1.

147
06:45.280 --> 06:48.730
And then we'll say no and then I'll go ahead and still be removed that and that

148
06:48.730 --> 06:49.200
way we can have our

149
06:49.200 --> 06:53.620
normal routing table restored. So if we go back to PC7 and we hit the upper key

150
06:53.620 --> 06:54.080
and do that same

151
06:54.080 --> 06:58.520
trace again, now once again it's going through R1 and R2 before it's being sent

152
06:58.520 --> 06:59.920
over to R4 and that's

153
06:59.920 --> 07:03.400
based on the normal routing tables of all the routers in our topology. And in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

153
06:59.920 --> 07:03.400
based on the normal routing tables of all the routers in our topology. And in

154
07:03.400 --> 07:03.920
the next video,

155
07:03.920 --> 07:08.400
I'd like to walk into an example, not just one, next top is being set based on

156
07:08.400 --> 07:09.120
a set of conditions,

157
07:09.120 --> 07:12.820
but two. And we'll also include source and destination as well as layer four

158
07:12.820 --> 07:14.080
protocol in that decision

159
07:14.080 --> 07:16.800
process. So I'll see you in the next video in just a moment.