WEBVTT

0:00:02.160000 --> 0:00:07.940000
 In this video, I'm going to introduce
 you to WCCP, the web cache control

0:00:07.940000 --> 0:00:14.340000
 protocol. So things we're going to
 cover briefly here are what is WCP,

0:00:14.340000 --> 0:00:17.700000
 WCCP, and why would you use it?

0:00:17.700000 --> 0:00:23.760000
 How WCCP interacts with a Cisco
 web security appliance?

0:00:23.760000 --> 0:00:30.460000
 Basic server configuration of WCCP and
 basic client configuration of WCCP,

0:00:30.460000 --> 0:00:35.320000
 specifically using a Cisco
 WSA as the client.

0:00:35.320000 --> 0:00:40.580000
 All right, so let's talk about what the
 web cache communications protocol

0:00:40.580000 --> 0:00:46.060000
 is, WCCP, that's a mouthful, web
 cache communications protocol.

0:00:46.060000 --> 0:00:51.120000
 So in the context of this video, what
 we're talking about is web traffic,

0:00:51.120000 --> 0:00:56.300000
 and let's just start out with basic
 HTTP, which is TCP port 80.

0:00:56.300000 --> 0:00:59.040000
 Web traffic comes into a
 router in the network.

0:00:59.040000 --> 0:01:03.260000
 Normally, that router would just route
 the traffic out to the destination

0:01:03.260000 --> 0:01:06.140000
 web server. Now, maybe
 you don't want that.

0:01:06.140000 --> 0:01:10.380000
 Maybe you have something like a content
 engine, or in this particular

0:01:10.380000 --> 0:01:13.560000
 case, a web security appliance where
 you want to take that web traffic

0:01:13.560000 --> 0:01:18.960000
 and redirect it away from its original
 destination and forward it instead

0:01:18.960000 --> 0:01:23.840000
 to another device within your
 network, like the Cisco WSA.

0:01:23.840000 --> 0:01:27.680000
 That is where WCCP could
 be useful for you.

0:01:27.680000 --> 0:01:34.380000
 So it basically takes in your HTTP packets,
 encapsulates them inside of

0:01:34.380000 --> 0:01:40.500000
 a GRE header, puts, so it creates a
 new IP header with the Cisco router

0:01:40.500000 --> 0:01:46.760000
 that received the HTTP as the source,
 and the Cisco WSA or content engine

0:01:46.760000 --> 0:01:49.360000
 as the destination IP address.

0:01:49.360000 --> 0:01:53.700000
 Behind that, we have a GRE header because
 this is being tunneled here.

0:01:53.700000 --> 0:01:59.360000
 Behind that, we have the WCCP header,
 and then behind that, we have the

0:01:59.360000 --> 0:02:02.620000
 actual original HTTP packet.

0:02:02.620000 --> 0:02:07.480000
 So it's redirecting it to a
 destination of your choice.

0:02:07.480000 --> 0:02:13.800000
 So originally, what WCCP was designed
 for was that maybe you had a really

0:02:13.800000 --> 0:02:15.740000
 slow LAN connection.

0:02:15.740000 --> 0:02:16.800000
 You said, you know what?

0:02:16.800000 --> 0:02:21.520000
 I'd like to take a, you know, my users,
 my employees are frequently accessing

0:02:21.520000 --> 0:02:24.720000
 the same sets of websites.

0:02:24.720000 --> 0:02:29.220000
 Maybe they're, maybe we're talking about
 employees at a remote location,

0:02:29.220000 --> 0:02:32.720000
 right, a remote office, and they're
 typically trying to get to several

0:02:32.720000 --> 0:02:36.740000
 different websites that are hosted at
 the central office, like our payroll

0:02:36.740000 --> 0:02:42.360000
 website, maybe a scheduling website,
 maybe an HR or a sales website, all

0:02:42.360000 --> 0:02:44.460000
 of which are hosted at
 the corporate office.

0:02:44.460000 --> 0:02:49.560000
 The problem is we have a very slow WAN
 link from the remote office leading

0:02:49.560000 --> 0:02:51.120000
 into the corporate office.

0:02:51.120000 --> 0:02:55.520000
 Wouldn't it be nice if we could take those
 websites and cache their information

0:02:55.520000 --> 0:03:01.100000
 locally on something like a content engine,
 cache it locally at the remote

0:03:01.100000 --> 0:03:07.480000
 office? And now when those HTTP packets
 come into the router, before the

0:03:07.480000 --> 0:03:12.160000
 router just routes them across the WAN,
 the router can then instead encapsulate

0:03:12.160000 --> 0:03:18.140000
 them inside GRE and redirect them to
 this content engine so the users

0:03:18.140000 --> 0:03:19.480000
 can get their website.

0:03:19.480000 --> 0:03:23.900000
 They can get it much more quickly and
 it never has to traverse our WAN

0:03:23.900000 --> 0:03:25.100000
 connection at all.

0:03:25.100000 --> 0:03:28.600000
 That was the idea
 behind using WCCP.

0:03:28.600000 --> 0:03:32.160000
 Now with web security appliances and
 other things, there's a lot of other

0:03:32.160000 --> 0:03:35.920000
 reasons why you might want to redirect
 that web traffic to some other

0:03:35.920000 --> 0:03:39.620000
 device for inspection first before
 we actually let it out to the wide

0:03:39.620000 --> 0:03:44.100000
 world. It is a Cisco proprietary
 protocol, so be aware of that.

0:03:44.100000 --> 0:03:47.000000
 It only works on Cisco devices.

0:03:47.000000 --> 0:03:52.000000
 And there are two versions of WCCP,
 versions one and version two.

0:03:52.000000 --> 0:03:56.160000
 Nowadays, version two is the default,
 so when you enable it, that is the

0:03:56.160000 --> 0:03:59.800000
 default, you'd have to actually manually
 go backwards to version one if

0:03:59.800000 --> 0:04:01.120000
 you wanted that.

0:04:01.120000 --> 0:04:05.420000
 You can see here a lot of big reasons
 why you would want to stick with

0:04:05.420000 --> 0:04:07.300000
 WCCP version two.

0:04:07.300000 --> 0:04:10.420000
 Supports multiple protocols
 other than HTTP.

0:04:10.420000 --> 0:04:17.340000
 For example, nowadays more and more websites
 are using secure HTTP, right?

0:04:17.340000 --> 0:04:22.720000
 TCP port 443. So that would be a
 good reason to use version two.

0:04:22.720000 --> 0:04:27.060000
 If you want to redirect FTP traffic
 or other types of things, you could

0:04:27.060000 --> 0:04:29.980000
 use WCCP version two to do that.

0:04:29.980000 --> 0:04:34.140000
 It also adds MD5 security, so there's
 a password that you can implement

0:04:34.140000 --> 0:04:38.760000
 between the router and the content engine,
 or between the router and the

0:04:38.760000 --> 0:04:40.720000
 web security appliance.

0:04:40.720000 --> 0:04:45.280000
 That password can now
 be hashed using MD5.

0:04:45.280000 --> 0:04:48.660000
 And also allows for
 low distribution.

0:04:48.660000 --> 0:04:52.400000
 Another nice feature is that now as
 the world is moving more and more

0:04:52.400000 --> 0:04:59.720000
 towards native IPv6, well, WCCP version
 one did not support IPv6.

0:04:59.720000 --> 0:05:03.020000
 WCCP version two, it does.

0:05:03.020000 --> 0:05:07.540000
 Now one other thing to note about WCCP
 before I leave here is I've been

0:05:07.540000 --> 0:05:11.440000
 describing it as a mechanism that takes
 in your web browsing packets and

0:05:11.440000 --> 0:05:15.040000
 encapsulates them inside of a GRE header,
 what we call putting them inside

0:05:15.040000 --> 0:05:20.600000
 of a GRE tunnel, and then tunnels them
 via GRE to the content engine,

0:05:20.600000 --> 0:05:22.900000
 or to the web security appliance.

0:05:22.900000 --> 0:05:26.120000
 That is definitely true, and that's
 a very popular way of doing it.

0:05:26.120000 --> 0:05:30.700000
 However, if your web security appliance
 or content engine is actually

0:05:30.700000 --> 0:05:35.060000
 on the exact same local subnet as the
 router itself, let's say they're

0:05:35.060000 --> 0:05:38.900000
 both connected to the same layer two
 switch, they both share an IP subnet

0:05:38.900000 --> 0:05:42.460000
 address. Then you can do something which
 is called layer two forwarding,

0:05:42.460000 --> 0:05:46.000000
 where when the web traffic comes into
 the router, all it does is simply

0:05:46.000000 --> 0:05:47.720000
 changes the layer two header.

0:05:47.720000 --> 0:05:50.740000
 It doesn't apply GRE, it doesn't do
 all that stuff, it just changes the

0:05:50.740000 --> 0:05:55.160000
 layer two header and redirects it at layer
 two to the web security appliance

0:05:55.160000 --> 0:05:56.860000
 or the content engine.

0:05:56.860000 --> 0:06:02.020000
 So that's called layer
 two forwarding in WCCP.

0:06:02.020000 --> 0:06:07.440000
 All right, so in the case of WCCP,
 we're talking about a client server

0:06:07.440000 --> 0:06:12.340000
 protocol, and you might think, okay,
 well, the router is the client and

0:06:12.340000 --> 0:06:14.700000
 the WSA is the server.

0:06:14.700000 --> 0:06:17.380000
 Nope, it's exactly the
 other way around.

0:06:17.380000 --> 0:06:21.500000
 So the WSA, as you can see here in this
 picture, is actually the client,

0:06:21.500000 --> 0:06:23.740000
 and the router is the server.

0:06:23.740000 --> 0:06:27.440000
 So what does this actually mean from
 a configuration perspective?

0:06:27.440000 --> 0:06:31.940000
 What this means is that on the router,
 you don't actually tell it the

0:06:31.940000 --> 0:06:36.520000
 IP address of the WSA,
 or the content engine.

0:06:36.520000 --> 0:06:40.980000
 The router will dynamically learn of
 the clients, in this case the WSA

0:06:40.980000 --> 0:06:44.400000
 via a hello protocol
 that takes place.

0:06:44.400000 --> 0:06:49.320000
 So the Cisco WSA will actually send
 some registration announcements to

0:06:49.320000 --> 0:06:51.100000
 the server every ten seconds.

0:06:51.100000 --> 0:06:55.720000
 And when the server, the router in this
 case, receives those registration

0:06:55.720000 --> 0:06:59.980000
 announcements, that's how the server
 knows, oh, okay, here's somebody

0:06:59.980000 --> 0:07:02.660000
 I can redirect my HTTP packets to.


0:07:02.660000 --> 0:07:06.680000
 I've just learned
 of his IP address.

0:07:06.680000 --> 0:07:10.500000
 And the WCCP hold time
 is 30 seconds.

0:07:10.500000 --> 0:07:14.080000
 So that's typical, right, in a lot of
 protocols, when you've got a certain

0:07:14.080000 --> 0:07:18.120000
 interval of like a hello time, most
 of the time the dead interval, or

0:07:18.120000 --> 0:07:21.740000
 the hold time is three times
 the hello interval.

0:07:21.740000 --> 0:07:24.880000
 And that's what we have here, the hello
 interval for the registration

0:07:24.880000 --> 0:07:29.040000
 announcements is ten seconds, three
 times that gives us 30 seconds for

0:07:29.040000 --> 0:07:36.420000
 the hold time. One other thing to note
 about that, let me just go back

0:07:36.420000 --> 0:07:37.720000
 to that real quickly.

0:07:37.720000 --> 0:07:41.640000
 If there is some sort of a firewall or
 something in between these devices

0:07:41.640000 --> 0:07:44.920000
 that have access lists or something
 implemented, you want to be aware

0:07:44.920000 --> 0:07:51.460000
 that these WCCP registration messages
 going back and forth are UDP based.

0:07:51.460000 --> 0:07:56.080000
 They actually use UDP port 2048.

0:07:56.080000 --> 0:07:58.840000
 Let me just write that
 down right here.

0:07:58.840000 --> 0:08:04.740000
 So UDP port 2048.

0:08:04.740000 --> 0:08:09.480000
 So you'll definitely want to make sure
 that that UDP port number is allowed

0:08:09.480000 --> 0:08:13.880000
 in your firewall or
 your access lists.

0:08:13.880000 --> 0:08:22.280000
 So lastly, just real quickly here.


0:08:22.280000 --> 0:08:25.980000
 Now this video is just meant to be a real
 high-level overview and introduction

0:08:25.980000 --> 0:08:30.720000
 of WCCP. So I'm not going to get into
 the gory details of configuring

0:08:30.720000 --> 0:08:32.480000
 or troubleshooting WCCP.

0:08:32.480000 --> 0:08:37.160000
 WCCP. But you can see here, here's
 what the server configuration looks

0:08:37.160000 --> 0:08:39.520000
 like. So this would
 be on your router.

0:08:39.520000 --> 0:08:46.440000
 So on your router, WCC version two is
 the default, but at minimum at the

0:08:46.440000 --> 0:08:48.560000
 global configuration level,
 you have to turn it on.

0:08:48.560000 --> 0:08:54.280000
 You have to enable the service with
 the IP, WCCP, web dash cache, and

0:08:54.280000 --> 0:08:55.740000
 then you can supply a password.

0:08:55.740000 --> 0:09:00.140000
 This is a password that's going to be
 a joint password that's shared between

0:09:00.140000 --> 0:09:05.740000
 the server, which is your router, and
 your client, which in my examples

0:09:05.740000 --> 0:09:08.560000
 has been a web security appliance.


0:09:08.560000 --> 0:09:11.500000
 Then you're going to pick
 one or more interfaces.

0:09:11.500000 --> 0:09:16.560000
 And on your interfaces, for example, here
 we have IP, WCCP, web dash cache,

0:09:16.560000 --> 0:09:22.460000
 redirect out. So this
 could also be in.

0:09:22.460000 --> 0:09:24.220000
 So it's your choice.

0:09:24.220000 --> 0:09:31.980000
 If you have your clients right here,
 and let's say they're all connected

0:09:31.980000 --> 0:09:38.460000
 to a switch, and then your switch is
 connected to the router right here.

0:09:38.460000 --> 0:09:44.640000
 So this is your WCCP server.

0:09:44.640000 --> 0:09:52.320000
 And let's say this interface right here
 is fast ethernet one slash one.

0:09:52.320000 --> 0:09:57.360000
 Well, then I can configure WCCP on this
 interface, but in this case, after

0:09:57.360000 --> 0:10:01.640000
 redirect, I would say in, because this
 is my inbound interface is going

0:10:01.640000 --> 0:10:03.620000
 to be receiving inbound HTTP.

0:10:03.620000 --> 0:10:09.340000
 In this case here, we have another fast
 ethernet interface, which is going

0:10:09.340000 --> 0:10:11.360000
 across some sort of cloud.

0:10:11.360000 --> 0:10:19.260000
 And over here is the WSA,
 which is my WCCP client.

0:10:19.260000 --> 0:10:25.740000
 And this interface right here is
 fast ethernet zero slash zero.

0:10:25.740000 --> 0:10:29.500000
 So instead of doing it on the inbound
 interface, in this case, we're seeing

0:10:29.500000 --> 0:10:32.940000
 an example of doing it in
 the outbound interface.

0:10:32.940000 --> 0:10:35.780000
 So it's your choice where you'd
 want to have that done.

0:10:35.780000 --> 0:10:41.020000
 And you can also see here on the slide
 some, the show IP, WCCP, web dash

0:10:41.020000 --> 0:10:45.340000
 cache command, which gives you a little
 bit more visibility into what's

0:10:45.340000 --> 0:10:47.940000
 going on behind the scenes.

0:10:47.940000 --> 0:10:50.200000
 And lastly, just a quick
 screenshot here.

0:10:50.200000 --> 0:10:53.520000
 This is sort of how you would configure
 the client in this place of the

0:10:53.520000 --> 0:10:55.860000
 client being a web
 security appliance.

0:10:55.860000 --> 0:10:58.980000
 Now what you're seeing here is
 on the initial setup wizard.

0:10:58.980000 --> 0:11:03.180000
 So when you go through the initial setup
 wizard of the WSA, configuring

0:11:03.180000 --> 0:11:07.780000
 basic security and IP parameters at
 one point, you get to this network

0:11:07.780000 --> 0:11:12.200000
 tab. And by clicking on the network tab,
 it gives you the ability to configure

0:11:12.200000 --> 0:11:15.380000
 basic options to enable WCCP.

0:11:15.380000 --> 0:11:22.340000
 And here we see in this last picture here,
 where we can configure something

0:11:22.340000 --> 0:11:25.720000
 called a WCCP service group.

0:11:25.720000 --> 0:11:34.360000
 You see by default, WCCP only redirects
 TCP port 80, normal plain text

0:11:34.360000 --> 0:11:40.040000
 HTTP messages. If you want to redirect
 anything other than that, you have

0:11:40.040000 --> 0:11:42.040000
 to configure a service group.

0:11:42.040000 --> 0:11:45.660000
 And here's an example of where, once
 again, within the setup wizard, we

0:11:45.660000 --> 0:11:47.760000
 can start configuring
 those service groups.

0:11:47.760000 --> 0:11:52.260000
 We can put in the IP address of the
 router, which is our WCCP server.

0:11:52.260000 --> 0:11:56.060000
 We can also type in our password
 that's going to be used.

0:11:56.060000 --> 0:12:01.340000
 So that concludes this
 introduction to WCCP.

0:12:01.340000 --> 0:12:03.820000
 I hope you found this
 video to be helpful.