Cisco Notepad

Enable webcaching, and securing only WCCP server from certain IP

access-list 99 remark Web-cache server
access-list 99 permit 129.1.3.33

access-list 100 remark Host on the subnet to bypass web-caching
access-list 100 deny   tcp host 129.1.3.100 any eq www
access-list 100 permit ip any any

ip wccp web-cache group-list 99 redirect-list 100

! Alternatively if we just want to enable web-caching without specifying ACL
ip wccp web-cache

interface FastEthernet 0/0
ip wccp web-cache redirect in

! The following to exclude an interface from webcaching.

interface FastEthernet 0/1
 ip wccp redirect exclude in

! Excluding an interface from webcasing should be used
! when we specify an interface e.g. S0/0 for redirecting
! traffic going out of that interface, comming from any interfaces

interface Serial0/0
 ip wccp web-cache redirect out

WCCP Outbound ACL Check

The following configuration example shows that the access list prevents traffic from network 10.0.0.0 leaving Fast Ethernet interface 0/0. Because the outbound ACL check is enabled, WCCP does not redirect that traffic. WCCP checks packets against the ACL before they are redirected.

ip wccp web-cache

ip wccp check acl outbound

interface fastethernet0/0

ip access-group 10 out

exit

ip wccp web-cache redirect-list redirect-out

access-list 10 deny 10.0.0.0 0.255.255.255

access-list 10 permit any

If the outbound ACL check is disabled, the HTTP packets from network 10.0.0.0 would be redirected to a web cache. Users with that network address could retrieve web pages even though the network administrator wanted to prevent it.

Doc CD Navigation

• Cisco IOS IP Application Services Configuration Guide, Release 12.4

• Configuring WCCP

• Configuration Examples for WCCP

Rack1R3(config)#ip tcp ?
  async-mobility      Configure async-mobility
  chunk-size          TCP chunk size (to change max of characters that
                      TCP reads from the input queue for Telnet and rlogin)
  ecn                 Enable Explicit Congestion Notification
  intercept           Enable TCP intercepting
  mss                 TCP initial maximum segment size
  path-mtu-discovery  Enable path-MTU discovery on new TCP connections
  queuemax            Maximum queue of outgoing TCP packets
  selective-ack       Enable TCP selective-ACK
  synwait-time        Set time to wait on new TCP connections
  timestamp           Enable TCP timestamp option
  window-size         TCP window size

Doc CD Navigation

• Cisco IOS IP Application Services Configuration Guide, Release 12.4
• Configuring TCP

To use reliable transport services, TCP hosts must establish a connection-oriented session with one another. Connection establishment is performed by using a “three-way handshake” mechanism.

A three-way handshake synchronizes both ends of a connection by allowing both sides to agree upon initial sequence numbers. This mechanism also guarantees that both sides are ready to transmit data and know that the other side is ready to transmit as well. The three-way handshake is necessary so that packets are not transmitted or retransmitted during session establishment or after session termination.

Each host randomly chooses a sequence number used to track bytes within the stream it is sending. Then, the three-way handshake proceeds in the following manner:

•The first host (Host A) initiates a connection by sending a packet with the initial sequence number (X) and synchronize/start (SYN) bit set to indicate a connection request.

•The second host (Host B) receives the SYN, records the sequence number X, and replies by acknowledging the SYN (with an ACK = X + 1). Host B includes its own initial sequence number (SEQ = Y). An ACK = 20 means the host has received bytes 0 through 19 and expects byte 20 next. This technique is called forward acknowledgment.

•Host A acknowledges all bytes Host B sent with a forward acknowledgment indicating the next byte Host A expects to receive (ACK = Y + 1). Data transfer then can begin.

Doc CD Navigation

• Cisco IOS IP Application Services Configuration Guide, Release 12.4

• Configuring TCP

• Information About TCP

• TCP Connection Establishment

When the WAN interface are virtual one, such as Dialer, Tunnel, the interface does not go down even if the WAN status actually inactive (i.e. physical interface down, or PPP session is down).

In this case, we should use object tracking instead of interface tracking, to track not only the line protocol status (up/down), but also whether routing can be done via that interface (i.e should there be a connected route via that interface when we do “show ip route connected”). For a more accurate reachability status via that interface, we can do IP SLA to track ping reachibility to backbone.

In a specific scenario of SHDSL and ADSL using PPP over dialer interface, tracking ip routing is good enough. Here’s the sample config (need to replace Serial interface with Dialer)

Configuration

R1#

interface Serial1/1
ip address negotiated
encapsulation ppp

track 100 interface Serial1/1 ip routing

interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
standby 1 ip 10.1.1.254
standby 1 priority 105
standby 1 preempt
standby 1 track 100

standby 2 ip 10.1.1.253
standby 2 preempt
standby 2 track 100

R2#

interface Serial1/1
ip address 23.0.0.2 255.255.255.0
encapsulation ppp

track 100 interface Serial1/1 ip routing

interface FastEthernet0/0
ip address 10.1.1.2 255.255.255.0
standby 1 ip 10.1.1.254
standby 1 preempt
standby 1 track 100

standby 2 ip 10.1.1.253
standby 2 priority 105
standby 2 preempt
standby 2 track 100

R3#

interface Serial1/2
ip address 13.0.0.3 255.255.255.0
encapsulation ppp
! to assign IP address to PPP peer dynamically
peer default ip address 13.0.0.1

interface Serial1/3
ip address 23.0.0.3 255.255.255.0
encapsulation ppp

Verification:

We simulate PPP negotiation failure, by removing WAN IP dynamically via PPP. Note that the interface is still up, but object tracking already kicks in! Interface tracking will not overcome this situation

R1#sh ip int brief | ex unass
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            10.1.1.1        YES manual up                    up
R1#sh ip int brief | in up
FastEthernet0/0            10.1.1.1        YES manual up                    up
Serial1/1                  unassigned      YES IPCP   up                    up

R1#show track 100
Track 100
Interface Serial1/1 ip routing
IP routing is Down (no ip addr)
4 changes, last change 00:16:06
Tracked by:
HSRP FastEthernet0/0 1
HSRP FastEthernet0/0 2

R1#show standby
FastEthernet0/0 – Group 1
State is Standby
6 state changes, last state change 00:16:14
Virtual IP address is 10.1.1.254
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.604 secs
Preemption enabled
Active router is 10.1.1.2, priority 100 (expires in 9.440 sec)
Standby router is local
Priority 95 (configured 105)
Track interface Serial1/1 state Up decrement 10
Track object 100 state Down decrement 10
IP redundancy name is “hsrp-Fa0/0-1″ (default)
FastEthernet0/0 – Group 2
State is Standby
4 state changes, last state change 00:23:06
Virtual IP address is 10.1.1.253
Active virtual MAC address is 0000.0c07.ac02
Local virtual MAC address is 0000.0c07.ac02 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.516 secs
Preemption enabled
Active router is 10.1.1.2, priority 105 (expires in 7.968 sec)
Standby router is local
Priority 90 (default 100)
Track object 100 state Down decrement 10
IP redundancy name is “hsrp-Fa0/0-2″ (default)