This is because you have an WCCP L3 GRE connected device. Recent IOS exposes the actual GRE tunnels that are used, previous releases hid them. This is useful for troubleshooting but a little disconcerning if you are not used to it. This stumped me for awhile, TAC had no idea. You can get rid of them, however. The same IOS version you are running allows WCCP L2 redirection, which is *much* lower CPU overhead on both the WAE and the router. Just change the WAE configuration to use WCCP L2 for both ingress and egress and the tunnels will go away. Obviously, the WAE has to be L2 adjacent to an interface on the router. Let me know if I'm on track here or if you are experiencing a completely different issue. /Rick ... View more

Do you have the clock set on the controller? Are you using NTP on the controller? I'm assuming you have firewall policy/ACLs to permit the CAPWAP protocol vs LWAPP. The last item to check is when you say DSL and WAN link, what does that mean? Is this a VPN link over the Internet? Are you using a VPN tunnel? What is an "IP-tunnel" you refer to? GRE/IP? IPSEC? What is the config of the DSL? ATM or PPPoE? This may be an IP MTU issue. Try the 'ip tcp mss-adjust 1380' command on the *inside* LAN interface on both ends of the connection. ... View more

You need to set the 'bgp router-id' for each vrf address-family to something unique for each vrf, otherwise the router is trying to use the same bgp router-id, which won't work. ... View more

This is not yet supported on IOS 12.2SX but is stated to be available in 12.2SXI. Track bug id CSCsh99774 for more info. ... View more

'ip flow-export destination vrf ' is not supported in IOS 12.SXH at this time. Look for 12.2SXI (within 90 days) for this feature. If you 'debug ip flow export' you will see that the first flow packet works correctly, with a correct source address (this is the RP first flow as the hardware is programmed). All additional flow export packets will be sent with a source address of 0.0.0.0, which will never work (these are the mls NDE exported flows). According to Cisco, this is not yet a supported feature. Moving the flow export to the global routing table may work, but you may not receive all flows from all VRFs. Track bug id CSCsh99774 for more info... ... View more

The answer may be the MCS7816-H3 server when Cisco announces the HP equivalent part number. For now, the Cisco /swonly doc clearly states the special HP part #'s that were created for the supported DL380 servers. There are no DL320G5 servers available that are supported at this time. According to Cisco, this will be resolved shortly after the UC7.0 launch this week... ... View more

You have 2 drives installed? Unity Connection requires 2 hard drives. Also, according to the Cisco docs, the DL320 G5 server that is supported requires the 'Intel Dual-Core Xeon 3050 2.13 GHz processor with an 1066-MHz front side bus (FSB) and 2 MB of Layer 2 cache', see the following URL: http://www.cisco.com/en/US/prod/collateral/voicesw/ps6789/ps5745/ps6509/product_data_sheet0900aecd80372879.html ... View more

debug client ... View more

Are you running GRE inside an IPSEC tunnel? Your configurations posted so far do not reflect this. That would be an entirely different scenerio. If not, and you are simply running a GRE tunnel between these two endpoints, and the end-to-end ip mtu OUTSIDE the tunnel is 1500 bytes (the tunnel's ip path) then you do not (and must not) change the ip mtu under the tunnel interface. The document you reference only mentions changing the default ip mtu on the tunnel in two scenerios: 1) the path mtu of the tunnel is less than 1500 bytes (ipsec, pppoe, etc.) or 2) the entire network supports large frames and can accept GRE packets of 1500 bytes (and therefore GRE/IP frames of 1524 bytes. In either case, this should be deterministic and incorporated into your design so should be hard set and not rely on path-mtu discovery, which rarely works outside the gre tunnel. You do, however, need to use tcp adjust-mss on the ingress interface of this router, using this command on the tunnel does not always work depending on IOS version. I use a value of 1380 but values up to 1460 should work. This is why certain tcp transactions will fail across the tunnel, udp packets are rarely larger than 1200 bytes and work by default. Regarding the inbound hold-queue size, you will not find *any* document on Cisco's web site that lists an inbound hold-queue of anything greater than 100, particularly if using CBWFQ. Ignore any documents that are more than 4 years old or refer to modems, isdn, etc. Usually, you will set the hold-queue or CBWFQ queue-limit *SMALLER* to more aggressively tail-drop traffic in the default class so that tcp makes the right decision about bandwidth. Remember, the input hold-queue does not drain at all unless the output interface tx-limit and tx queue are nearly empty. IOS puts back-pressure on the input interface when the output interface is saturated and you want the input interface to tail-drop, not buffer a bunch of packets unrealistically. ... View more

What type of linecard is this that has the output drops? Send a show mod. ... View more

What is the type of linecard that is reporting the output drops? Send a show mod from the switch. ... View more

Several problems here. First, you don't want to adjust the ip mtu at all, particularly on a GRE tunnel. You should only be changing the ip tcp adjust-mss to 1460 or 1380. By changing both the ip mtu and adjust-mss to the same value, you broke tcp across this link because you rendered useless the benefit of tcp adjust-mss on this interface. Also, depending on IOS version and hardware platform, you may need the tcp adjust-mss statement on the ingress interface of the router, not the tunnel. Second, never set the queue-limit to anything greater than 100 packets, particularly as a part of a service-policy. Remember, every class has a 64 packet queue-limit, so the total hold-queue for the interface will be the sum of all the class queue-limits. By making this number crazy high, you are essentially allowing duplicate packets to get into the hold-queue. In other words, by the time the tcp sender timed out and resent the packet, the first packet may not have been sent! This is bad, the tcp mss-adjust misconfiguration only made it worse. ... View more

Good point, albeit a few corrections in the context of ipv4 routing. Note that a Sup720 (PFC3,PFC3A,PFC3B) will only support 239,000 routes, not 256,000 as you mention, and this is *NOT* the default behavior. The default FIB TCAM resources permit 192,000 ipv4 unicast AND MPLS routes; and 32,000 ipv6 unicast and ipv4 multicast routes. The maximum amount of routes you can re-configure the ipv4 unicast and MPLS hardware TCAM FIB resources is 239,000 (depending on IOS version). The supervisor will not allow you to use all the TCAM FIB resources for ipv4 routes because it is shared with MPLS and EoM, and must leave resources for ipv4 multicast and ipv6 unicast. The Internet BGP4 prefixes have crossed 226,000 for well over a year now. Use the following command to see what the current TCAM FIB utilization is: show platform hardware capacity forwarding show tcam counts ip Use the following command to reconfigure the TCAM FIB resources (a reload is required): mls cef maximum-routes Cisco has been *screaming* for nearly two years now that you need a Sup720 with a PFC-3BXL or PFC-3CXL (and appropriate DFCs if installed) in order to support the full Internet BGP4 routing table in a 6500/7600 switch. If not, things will *mostly* work, but the switch will drop a significant amount of traffic destined to the ipv4 route prefixes that were not able to be installed in hardware and need to be processed switched. The Sup720 (all versions) by default has a rate-limiter configured that will prevent the switch cpu from being overburdened by these forwarding requests, hence drop rates for traffic destined to those prefixes of 25% to 100%. ... View more

A few points: 1. Do you have Microsoft KB917021 or XP SP3 installed? 2. Are you sure that WEP with 802.1x with PEAP is even supported on the WLC? I can't find any docs that list that as a supported option. 3. Try WPA1/TKIP and/or WPA2/AES with 802.1x. Just because the gui lets you configure something, doesn't mean it works or is supported. For example, WPA1/AES and WPA2/TKIP can be configured but don't work as they are unsupported and invalid. I suspect this is what you are running up against. Nobody else is configuring the WLC the way you are. ... View more

Are you using SNMPv2 or SNMPv3 for the WCS polling of the WLC? ... View more