I also decided to take some debug output for future reference:
Commands you'll use on the router:
show ip wccp web-cache detail
show ip wccp web-cache view
debug ip wccp events - display WCCP events
debug ip wccp packets - display WCCP packet information
Here's how wccp works with squid:
Once squid is started with the wccp option, the router sees this and sends an I see you message as follows (I had always assumed the here I am message comes first - I was obviously wrong:
Jan 9 08:57:51.584 NAIROBI: WCCP-PKT:S00: Sending I_See_You packet to 196.201.xx.xx w/ rcv_id 00006C9C
and you get this log below on the router - this is not a debug output.
Jan 9 08:58:01.593 NAIROBI: %WCCP-5-SERVICEFOUND: Service web-cache acquired on WCCP client 196.201.xx.xx
Squid then sends back HERE_I_AM packets, and carries on a conversation with the router.
Jan 9 08:58:01.593 NAIROBI: WCCP-PKT:S00: Received valid Here_I_Am packet from 196.201.xx.xx w/rcv_id 00006C9C
If you were also debugging events, you get the following:
Jan 9 08:58:01.593 NAIROBI: WCCP-EVNT:S00: Assignment wait timer started
Jan 9 08:58:01.593 NAIROBI: WCCP-EVNT:S00: Built new router view: 1 routers, 1 usable WCCP clients, change # 0000004D
From then on traffic gets redirected to squid.
and if you disconnect you get the following event/log:
Jan 9 08:57:37.279 NAIROBI: WCCP-EVNT:S00: Assignment wait timer started
Jan 9 08:57:37.279 NAIROBI: WCCP-EVNT:S00: Built new router view: 0 routers, 1 usable WCCP clients, change # 0000004B
Jan 9 08:57:37.279 NAIROBI: WCCP-EVNT:S00: Router 196.201.xxx.xxx removed.
Jan 9 08:57:37.279 NAIROBI: WCCP-EVNT:S00: Assignment wait timer started
Jan 9 08:57:37.279 NAIROBI: WCCP-EVNT:S00: Built new router view: 0 routers, 0 usable WCCP clients, change # 0000004C
Jan 9 08:57:37.279 NAIROBI: %WCCP-1-SERVICELOST: Service web-cache lost on WCCP client 196.201.xx.xx
On the router, the basic config is widely available on the internet....create an access-list for traffic to redirect, enable wccp etc etc...
This conversation (between router and squid) is totally separate from the ip_wccp or ip_gre module --these packets never go through those channels. For so long as the router is receiving WCCP HERE_I_AM packets (with the proper ID), the router will send traffic to the cache IP, encapsulated in a GRE packet, and there in lies the problem or the gotcha as ccie candidates like saying. In a production if you do this without confirming the tunnels, all your redirected traffic will be blackholed by squid.
The GRE decapsulation is a separate process from squid. Squid doesn't talk to the gre/ip_wccp module, The gre decapsulation occurs at the network layer in your kernel, and then the packets enter the normal routing table - on bsd/linux it involves iptables/chains
to hijack any packets destined for port 80 on the internet - In my case thats traffic coming from the router in GRE packets and passes it over to the cache engine's port.
I wonder what happens if I let squid listen on port 80....do you still need something to 'jack' the packets? I'll try that in a while and let you know....
So now with that understanding, you'd think I fix this on solaris pretty fast yes??? nope, nada, my cluelessness gets in the way....AGAIN!!
So again back to google, I can't get an ip_wccp for solaris module but Im sure I will get gre and the ip redirect working...and get more CLUEFUL overall then we can go back to regular work, If you stumble upon this and have a clue...bail me out:-)pleasee....I still have about 5 bgp, 5 ospf LABS to get through before Sunday....
Posts
