Squid WCCP
From Internetworkpro
A Squid transparent proxy configuration with Cisco IOS can be a little confusing on the linux side given all the variables that can be in an average setup. Below I hope to explain how to build a WCCP2 transparent proxy, with router and proxy in different parts of the network, not connected directly.
Some problems that can occur during setup are primarily correctly classifying your traffic to proxy - you don't want to inadvertantly proxy your internal corporate lan, and the IP address used for the WCCP engine on the Cisco router. Squid can be very sensitive to which IP address comes in.
Use the nearest IP address on the router to the Squid proxy for wccp2_router in squid.conf, not the WCCP router ID in show ip wccp
Contents |
[edit] Configuration
[edit] SQUID
[edit] squid.conf
A nice, simple configuration based on CentOS 5.4 defaults. The key here is to create an http port on 3128 and enable wccp2 routers.
[root@centos netfilter]# egrep -v "^#|^$" /etc/squid/squid.conf acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl to_localhost dst 127.0.0.0/8 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT acl lan src 172.16.0.0/16 http_access allow manager localhost http_access allow lan http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access deny all icp_access allow all http_port 3128 transparent hierarchy_stoplist cgi-bin ? access_log /var/log/squid/access.log squid acl QUERY urlpath_regex cgi-bin \? cache deny QUERY refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern . 0 20% 4320 acl apache rep_header Server ^Apache broken_vary_encoding allow apache wccp2_router 172.16.59.32 wccp2_forwarding_method 1 wccp2_return_method 1 wccp2_service standard 0 coredump_dir /var/spool/squid
[edit] iptools (gre)
We need to create the GRE interface that the router will send packets to. The router will send all packets to squid using the highest local IP address on the device, using the nearest source interface to squid. The IP address of the GRE tunnel doesn't matter since it's not routed. I used some 127/8 loopback IP addresses on my system.
modprobe ip_gre ip tunnel add wccp_R1_2 mode gre remote 172.16.100.32 local 172.16.60.65 dev eth0 ifconfig wccp_R1_2 127.0.1.1 netmask 255.255.255.255 up
[edit] iptables
There are a few options for getting 'data' to squid. The easiest way is to just redirect all transparent http proxy to squid's http_port 3128. Without this iptables entry, linux will just route the traffic through linux as if it was a simple IP router. The other option is ip_tproxy support, which strips off gre data for 'wccp' aware packets. Since I didn't want to spend time compiling a new kernel, I just intercepted all TCP coming in on the GRE/WCCP interface and send it to squids transparent proxy running on port 3128.
iptables -t nat -A PREROUTING -i wccp_R1_2 -d 0/0 -p tcp -j DNAT --to-destination 172.16.60.65:3128
[edit] sysctl/proc
sysctl -w net.ipv4.conf.all.rp_filter=0 sysctl -w net.ipv4.conf.wccp_R1_2.forwarding=1
(or) echo 0 >/proc/net/ipv4/conf/all/rp_filter echo 1 >/proc/net/ipv4/conf/wccp_R1_2/forwarding
[edit] Cisco IOS router configuration
The Cisco IOS side of configuration is easy, but a showstopper is that the automatic WCCP Router ID that Squid sends data packets to is automatically chosen to be the highest local IP address on your router. This might not be optimal, for instance if your LAN allocation is 10.0.0.0/8 but your ISP connection is 204.112.0.0/24. Cisco will encapsulate the GRE messages using the source IP address nearest to the WCCP server IP received in the registration message. I attempted to override this with local policy routing but it seems to be non modifiable behavior. Just remember your GRE tunnel should terminate on the highest IP'd interface on the router, in this case 172.16.100.32
[edit] WCCP Redirect list ACL
While we could drill down on multiple WCCP servers (ftp, https, citrix, etc) we'll focus on simple web-cache for port 80. The below ACL and configuration will instruct IOS to only proxy traffic from 172.16.0.0/16 out to the internet.
ip access-list extended WCCP deny ip 172.16.0.0 0.0.255.255 172.16.0.0 0.0.255.255 permit ip 172.16.0.0 0.0.255.255 any ip wccp web-cache redirect-list WCCP
[edit] Redirecting web traffic
You can apply a redirect either "in" an interface that clients are coming from, or "out" one they are leaving. In this case we are just applying them to the inbound direction.
interface FastEthernet1/0 description VLAN7 ip address 172.16.57.32 255.255.255.0
[edit] WCCP Router ID
WCCP automatically chooses the highest IP address for your router ID. Keep this in mind for the rest of your configuration.
interface Loopback0
ip address 172.16.100.32 255.255.255.255
R1#show ip wccp
Global WCCP information:
Router information:
Router Identifier: 172.16.100.32
Protocol Version: 2.0
Service Identifier: web-cache
Number of Service Group Clients: 1
Number of Service Group Routers: 1
Total Packets s/w Redirected: 4783
Process: 0
Fast: 0
CEF: 4783
Redirect access-list: WCCP
Total Packets Denied Redirect: 0
Total Packets Unassigned: 0
Group access-list: -none-
Total Messages Denied to Group: 0
Total Authentication failures: 0
Total Bypassed Packets Received: 0
[edit] Troubleshooting
[edit] To capture WCCP 'here i am' messages
tcpdump -pni eth0 port 2048
[root@centos netfilter]# tcpdump -pni eth0 port 2048 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 16:57:40.916187 IP 172.16.60.65.dls-monitor > 172.16.59.32.dls-monitor: UDP, length 144 16:57:40.948061 IP 172.16.59.32.dls-monitor > 172.16.60.65.dls-monitor: UDP, length 140
[edit] Watching the WCCP here I am and registration messages
We can use debugs to validate a proper WCCP registration.
debug ip wccp packet debug ip wccp event *Mar 1 02:22:33.263: %WCCP-5-SERVICEFOUND: Service web-cache acquired on WCCP client 172.16.60.65 *Mar 1 02:22:33.263: WCCP-PKT:S00: Received valid Here_I_Am packet from 172.16.60.65 w/rcv_id 00000341 *Mar 1 02:22:33.263: WCCP-EVNT:S00: Assignment wait timer started *Mar 1 02:22:33.263: WCCP-EVNT:S00: Built new router view: 1 routers, 1 usable WCCP clients, change # 0000000A *Mar 1 02:22:33.263: WCCP-PKT:S00: Sending I_See_You packet to 172.16.60.65 w/ rcv_id 00000342 *Mar 1 02:22:33.263: UDP src=2048, dst=2048 *Mar 1 02:22:42.923: UDP src=2048, dst=2048 *Mar 1 02:22:42.927: WCCP-PKT:S00: Received valid Here_I_Am packet from 172.16.60.65 w/rcv_id 00000342 *Mar 1 02:22:42.927: WCCP-PKT:S00: Sending I_See_You packet to 172.16.60.65 w/ rcv_id 00000343 *Mar 1 02:22:42.927: UDP src=2048, dst=2048
[edit] To capture GRE graffic hitting eth0
tcpdump -pni eth0 proto gre
[root@centos netfilter]# tcpdump -pni eth0 proto gre tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 16:58:25.251557 IP 172.16.100.32 > 172.16.60.65: GREv0, length 56: gre-proto-0x883e 16:58:25.255937 IP 172.16.100.32 > 172.16.60.65: GREv0, length 48: gre-proto-0x883e 16:58:25.265328 IP 172.16.100.32 > 172.16.60.65: GREv0, length 523: gre-proto-0x883e 16:58:25.487064 IP 172.16.100.32 > 172.16.60.65: GREv0, length 56: gre-proto-0x883e 16:58:25.492581 IP 172.16.100.32 > 172.16.60.65: GREv0, length 48: gre-proto-0x883e 16:58:25.496877 IP 172.16.100.32 > 172.16.60.65: GREv0, length 911: gre-proto-0x
[edit] To debug traffic correctly GRE encapsulated from the router
To capture the "Raw" http traffic inside the GRE tunnel. This traffic represents exactly what the client puts on the wire. If you have captures up to this stage, you've verified that A) WCCPv2 is established between Squid and your Router, B) The GRE tunnel works and is correctly routing. This troubleshooting will verify all WCCP configuration and any further errors will be SQUID related. tcpdump -pni wccp_R1_2
[root@centos netfilter]# tcpdump -pni wccp_R1_2 tcpdump: WARNING: arptype 778 not supported by libpcap - falling back to cooked socket tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wccp_R1_2, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 16:54:32.750918 IP 172.16.57.70.csdmbase > 24.244.3.65.http: P 807884949:807885425(476) ack 2378158067 win 64240 16:54:32.978050 IP 172.16.57.70.csdm > 74.125.127.154.http: P 4055926010:4055926872(862) ack 2386146409 win 64240 16:54:33.006427 IP 172.16.57.70.aal-lm > 74.125.127.113.http: P 3283386954:3283387629(675) ack 2382561092 win 63210 16:54:33.046243 IP 172.16.57.70.csdmbase > 24.244.3.65.http: . ack 965 win 63276 16:54:33.126688 IP 172.16.57.70.csdm > 74.125.127.154.http: . ack 2215 win 64240 16:54:33.306725 IP 172.16.57.70.aal-lm > 74.125.127.113.http: . ack 516 win 64240 16:54:33.308080 IP 172.16.57.70.1471 > 67.202.66.204.http: P 3531040290:3531040644(354) ack 2379111662 win 63154 16:54:33.541617 IP 172.16.57.70.1471 > 67.202.66.204.http: . ack 544 win 64240
[edit] To verify cache operation
Verifying cache operation is important to ensure you're able to see the client hitting your logs. At this point everything is 'perfect' for you.
tail -f /var/log/squid/* ==> /var/log/squid/access.log <== 1276642394.171 226 172.16.57.70 TCP_MISS/200 964 GET http://as.casalemedia.com/s? - DIRECT/24.244.3.59 text/plain 1276642394.452 77 172.16.57.70 TCP_MISS/200 515 GET http://www.google-analytics.com/__utm.gif? - DIRECT/74.125.127.102 image/gif 1276642394.493 111 172.16.57.70 TCP_MISS/304 507 GET http://tcr.tynt.com/javascripts/Tracer.js? - DIRECT/72.21.91.19 text/javascript 1276642394.496 175 172.16.57.70 TCP_MISS/200 2204 GET http://googleads.g.doubleclick.net/pagead/ads? - DIRECT/74.125.127.157 text/html ==> /var/log/squid/store.log <== 1276642394.171 RELEASE -1 FFFFFFFF E48FDBEF465120EBD98F97A2DD38A656 200 1276642246 -1 1276642246 text/plain 0/0 GET http://as.casalemedia.com/s? 1276642394.452 RELEASE -1 FFFFFFFF E8667BFC78E17D62D52B671233966BD4 200 1276628895 1074714690 956144580 image/gif 35/35 GET http://www.google-analytics.com/__utm.gif? 1276642394.493 RELEASE -1 FFFFFFFF 73AFFD3ECD9B47947AC904155C223261 304 1276642246 1275083785 1276644046 text/javascript -1/0 GET http://tcr.tynt.com/javascripts/Tracer.js? 1276642394.496 RELEASE -1 FFFFFFFF E41B87B74420E49885E3A406A451A366 200 1276642246 -1 -1 text/html 1592/1592 GET http://googleads.g.doubleclick.net/pagead/ads? ==> /var/log/squid/access.log <== 1276642394.171 226 172.16.57.70 TCP_MISS/200 964 GET http://as.casalemedia.com/s? - DIRECT/24.244.3.59 text/plain 1276642394.452 77 172.16.57.70 TCP_MISS/200 515 GET http://www.google-analytics.com/__utm.gif? - DIRECT/74.125.127.102 image/gif 1276642394.493 111 172.16.57.70 TCP_MISS/304 507 GET http://tcr.tynt.com/javascripts/Tracer.js? - DIRECT/72.21.91.19 text/javascript 1276642394.496 175 172.16.57.70 TCP_MISS/200 2204 GET http://googleads.g.doubleclick.net/pagead/ads? - DIRECT/74.125.127.157 text/html 1276642394.747 107 172.16.57.70 TCP_MISS/200 543 GET http://p.ic.tynt.com/b/p? - DIRECT/67.202.66.204 image/gif ==> /var/log/squid/store.log <== 1276642394.171 RELEASE -1 FFFFFFFF E48FDBEF465120EBD98F97A2DD38A656 200 1276642246 -1 1276642246 text/plain 0/0 GET http://as.casalemedia.com/s? 1276642394.452 RELEASE -1 FFFFFFFF E8667BFC78E17D62D52B671233966BD4 200 1276628895 1074714690 956144580 image/gif 35/35 GET http://www.google-analytics.com/__utm.gif? 1276642394.493 RELEASE -1 FFFFFFFF 73AFFD3ECD9B47947AC904155C223261 304 1276642246 1275083785 1276644046 text/javascript -1/0 GET http://tcr.tynt.com/javascripts/Tracer.js? 1276642394.496 RELEASE -1 FFFFFFFF E41B87B74420E49885E3A406A451A366 200 1276642246 -1 -1 text/html 1592/1592 GET http://googleads.g.doubleclick.net/pagead/ads? 1276642394.747 RELEASE -1 FFFFFFFF 5494102B2A19E8E6DDA89302D90F9095 200 1276642246 1271432300 869893200 image/gif 35/35 GET http://p.ic.tynt.com/b/p? ==> /var/log/squid/access.log <== 1276642394.747 107 172.16.57.70 TCP_MISS/200 543 GET http://p.ic.tynt.com/b/p? - DIRECT/67.202.66.204 image/gif ==> /var/log/squid/store.log <== 1276642394.747 RELEASE -1 FFFFFFFF 5494102B2A19E8E6DDA89302D90F9095 200 1276642246 1271432300 869893200 image/gif 35/35 GET http://p.ic.tynt.com/b/p?
[edit] Verify outside proxy access
I'm a little bit lazy here, so I just visit http://whatismyip.com and rely on the forwarded attribute. I suppose you could packet capture on your outside internet interface.
Your IP Address Is: 203.0.113.4 Possible Proxy Detected: 1.1 centos.local.mistrust.ca:3128 (squid/2.6.STABLE21) Read more: http://whatismyip.com/#inorite
[edit] Error messages
[edit] ioctl: No such device
[root@centos netfilter]# ip tunnel add wccp_R1_2 mode gre remote 172.16.100.32 local 172.16.60.65 dev eth0 '''ioctl: No such device'''
You need to add ip_gre support to your kernel - try insmod or modprobe, it's probably already included in your distro.
[root@centos netfilter]# lsmod | grep ip_gre [root@centos netfilter]# modprobe ip_gre [root@centos netfilter]# lsmod | grep gre ip_gre 47585 0 [root@centos netfilter]# ip tunnel add wccp_R1_2 mode gre remote 172.16.100.32 local 172.16.60.65 dev eth0 [root@centos netfilter]#
[edit] Error: The requested URL could not be retrieved - Invalid request
This is a helpful error message as it lets you know the client is actually making it to the proxy. We can clearly see the proxy name at the bottom of the error page, and we can clearly see the URL resource that is being retrieved.
I include a lot of information below for brevities sake. This error message basically means that the proxy cannot process the request as formatted. Note carefully the first line, "GET / HTTP/1.1" implies that the client itself is not proxy aware. If this request was "GET http://www.whatismyip.com HTTP/1.1" that would imply it knows it works through a proxy.
Squids default configuration is not able to handle a transparent request. Simply ensuring that /etc/squid.conf's http_port feature includes the key word 'transparent' will resolve this situation.
Before: # Squid normally listens to port 3128 http_port 3128 /etc/init.d/squid reload After: # Squid normally listens to port 3128 http_port 3128 /etc/init.d/squid reload
This will give you a valid configuration and is hopefully your last step to transparent proxy access!
While trying to process the request: GET / HTTP/1.1 Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, */* Accept-Language: en-us User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0) Accept-Encoding: gzip, deflate Host: whatismyip.com Connection: Keep-Alive The following error was encountered: •Invalid Request Some aspect of the HTTP Request is invalid. Possible problems: •Missing or unknown request method •Missing URL •Missing HTTP Identifier (HTTP/1.0) •Request is too large •Content-Length missing for POST or PUT requests •Illegal character in hostname; underscores are not allowed Your cache administrator is root. -------------------------------------------------------------------------------- Generated Tue, 15 Jun 2010 23:24:25 GMT by centos.local.mistrust.ca (squid/2.6.STABLE21)
[edit] Here_I_Am packet w/bad rcv_id
This error message is tricky. The IOS router is receiving a packet with the wrong IP address -- one that it is not expecting. The router is replying to the WCCP Registration message from 172.16.60.65, but the registration message is pointing to the highest IP address on the interface. This is not the interface that the router would choose to route to WCCP. There's some sort of RPF check going on that is very difficult to troubleshoot.
R1#debug ip wccp packet
WCCP packet info debugging is on
R1#debug ip wccp event
WCCP events debugging is on
R1#
*Mar 1 02:13:58.827: WCCP-EVNT:S00: Here_I_Am packet from 172.16.60.65 w/bad rcv_id 00000000
*Mar 1 02:13:58.831: WCCP-PKT:S00: Sending I_See_You packet to 172.16.60.65 w/ rcv_id 00000303
R1#show ip wccp
Global WCCP information:
Router information:
Router Identifier: 172.16.100.32
Protocol Version: 2.0
Service Identifier: web-cache
Number of Service Group Clients: 0
Number of Service Group Routers: 0
Total Packets s/w Redirected: 4793
Process: 0
Fast: 0
CEF: 4793
Redirect access-list: WCCP
Total Packets Denied Redirect: 0
Total Packets Unassigned: 0
Group access-list: -none-
Total Messages Denied to Group: 0
Total Authentication failures: 0
Total Bypassed Packets Received: 0
Some debug ip packet detail here shows a packet coming in on FastEthernet0/0, with the destination IP address of loopback0 (Remember wccp2_router in squid.conf?). The router is replying to the I see you packet to 172.16.60.65 using the closest IP interface to the WCCP registration message which in this case is FastEthernet0/0 with the IP address 172.16.59.32. This source IP address 172.16.59.32, the Fa0/0 IP of R1, is not what squid wants so GRE fails and the web-cache never comes up.
*Mar 1 02:17:51.607: IP: tableid=0, s=172.16.60.65 (FastEthernet0/0), d=172.16.100.32 (Loopback0), routed via RIB *Mar 1 02:17:51.611: IP: s=172.16.60.65 (FastEthernet0/0), d=172.16.100.32, len 172, rcvd 4 *Mar 1 02:17:51.615: UDP src=2048, dst=2048 *Mar 1 02:17:51.619: WCCP-EVNT:S00: Here_I_Am packet from 172.16.60.65 w/bad rcv_id 00000000 *Mar 1 02:17:51.619: WCCP-PKT:S00: Sending I_See_You packet to 172.16.60.65 w/ rcv_id 00000321 *Mar 1 02:17:51.623: IP: tableid=0, s=172.16.59.32 (local), d=172.16.60.65 (FastEthernet0/0), routed via FIB *Mar 1 02:17:51.627: IP: s=172.16.59.32 (local), d=172.16.60.65 (FastEthernet0/0), len 120, sending R1# *Mar 1 02:17:51.627: UDP src=2048, dst=2048 *Mar 1 02:17:51.631: IP: tableid=0, s=172.16.60.65 (FastEthernet0/0), d=172.16.59.32 (FastEthernet0/0), routed via RIB *Mar 1 02:17:51.631: IP: s=172.16.60.65 (FastEthernet0/0), d=172.16.59.32 (FastEthernet0/0), len 148, rcvd 3 *Mar 1 02:17:51.631: ICMP type=3, code=3
The fix here is to modify the wccp2_router IP address in squid.conf to point to the IP address that your router replies to the WCCP registration messages on. To find this just do a quick rpf-like check:
R1#show ip route 172.16.60.65
Routing entry for 172.16.60.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 172.16.59.1 on FastEthernet0/0, 00:00:09 ago
Routing Descriptor Blocks:
172.16.59.17, from 172.16.59.17, 00:00:23 ago, via FastEthernet0/0
Route metric is 1, traffic share count is 1
* 172.16.59.1, from 172.16.59.1, 00:00:09 ago, via FastEthernet0/0
Route metric is 1, traffic share count is 1
R1# show run int FastEthernet0/0 interface FastEthernet0/0
description VLAN9 ip address 172.16.59.32 255.255.255.0 duplex auto speed auto
end </pre>
Once we set 'wccp_router 172.16.59.32 and reload squid we should see a successful registration:
(Notice here that explicitly the destination IP address is 172.16.59.32 and that the Here_I_Am packet is valid!)
R1# *Mar 1 02:22:23.279: IP: tableid=0, s=172.16.60.65 (FastEthernet0/0), d=172.16.59.32 (FastEthernet0/0), routed via RIB *Mar 1 02:22:23.283: IP: s=172.16.60.65 (FastEthernet0/0), d=172.16.59.32 (FastEthernet0/0), len 172, rcvd 3 *Mar 1 02:22:23.287: UDP src=2048, dst=2048 *Mar 1 02:22:23.291: WCCP-PKT:S00: Sending I_See_You packet to 172.16.60.65 w/ rcv_id 00000341 *Mar 1 02:22:23.291: IP: tableid=0, s=172.16.59.32 (local), d=172.16.60.65 (FastEthernet0/0), routed via FIB *Mar 1 02:22:23.291: IP: s=172.16.59.32 (local), d=172.16.60.65 (FastEthernet0/0), len 120, sending *Mar 1 02:22:23.291: UDP src=2048, dst=2048 R1# *Mar 1 02:22:33.247: IP: tableid=0, s=172.16.60.65 (FastEthernet0/0), d=172.16.59.32 (FastEthernet0/0), routed via RIB *Mar 1 02:22:33.251: IP: s=172.16.60.65 (FastEthernet0/0), d=172.16.59.32 (FastEthernet0/0), len 172, rcvd 3 *Mar 1 02:22:33.255: UDP src=2048, dst=2048 *Mar 1 02:22:33.263: %WCCP-5-SERVICEFOUND: Service web-cache acquired on WCCP client 172.16.60.65 R1# *Mar 1 02:22:33.263: WCCP-PKT:S00: Received valid Here_I_Am packet from 172.16.60.65 w/rcv_id 00000341 *Mar 1 02:22:33.263: WCCP-EVNT:S00: Assignment wait timer started *Mar 1 02:22:33.263: WCCP-EVNT:S00: Built new router view: 1 routers, 1 usable WCCP clients, change # 0000000A *Mar 1 02:22:33.263: WCCP-PKT:S00: Sending I_See_You packet to 172.16.60.65 w/ rcv_id 00000342 *Mar 1 02:22:33.263: IP: tableid=0, s=172.16.59.32 (local), d=172.16.60.65 (FastEthernet0/0), routed via FIB *Mar 1 02:22:33.263: IP: s=172.16.59.32 (local), d=172.16.60.65 (FastEthernet0/0), len 168, sending *Mar 1 02:22:33.263: UDP src=2048, dst=2048
We can quickly verify that the web-cache client is successfully registered.
R1#show ip wccp
Global WCCP information:
Router information:
Router Identifier: 172.16.100.32
Protocol Version: 2.0
Service Identifier: web-cache
Number of Service Group Clients: 1
Number of Service Group Routers: 1
Total Packets s/w Redirected: 4793
Process: 0
Fast: 0
CEF: 4793
Redirect access-list: WCCP
Total Packets Denied Redirect: 0
Total Packets Unassigned: 0
Group access-list: -none-
Total Messages Denied to Group: 0
Total Authentication failures: 0
Total Bypassed Packets Received: 0
