No, I don't. And I don't think, this could be the problem, because I am running on this exactly same infrastructure (no QoS, Cat65k, Aironet c1131, c1232, c1121) standalone APs with no problems.

The only difference is that:

In standalone, data flows from AP through trunk link (5 SSID - 5 VLANs) to Cat65k and there are routed.

And in centralized - data flows through LWAPP tunnel to WiSM blade (in the same Cat65k) and then through LAG and are routed.

I am testing this on environment, where I have only one lightweight AP connected to WiSM and with only one wireless client, so there cannot be such congestion to produce such delays and jitter. (?)

IMHO the problem could be somewhere in the WiSM controller.

Any ideas?

Verify the etherchannel load-balancing:

show etherchannel load-balance

Make sure it is set to source destination ip or else issue the

port-channel load-balance src-dst-ip

What I would cheek also is the make sure the ports are indeed bundled

show etherchannel

Also make sure the service interface ip address is not routable in your network and is different from the other wlc in the wism.

>Verify the etherchannel load-balancing:

src-dst-ip

mpls label-ip

>What I would cheek also is the make sure the ports are indeed bundled

Yes, I can see two Port channel groups (for two WLC in WiSM blade) each with four ports bundled. Both Port channels are used (SU flag) and each port in channel has P flag. - so, seems correct here

>Also make sure the service interface ip address is not routable in your network and is different from the other wlc in the wism.

it's not routable

I keep playing with various options and now I have another piece of knowledge, maybe useful:

Let's see delays and jitter when pinging Wireless G IP phone (Linksys WIP330, QoS for WLAN is best effort):

--> PHONE IS IN STANDBY (NO CALL)- high delay and jitter

160 bytes from x.x.x.x: icmp_seq=2 ttl=127 time=263 ms

160 bytes from x.x.x.x: icmp_seq=3 ttl=127 time=86.5 ms

160 bytes from x.x.x.x: icmp_seq=4 ttl=127 time=107 ms

160 bytes from x.x.x.x: icmp_seq=5 ttl=127 time=235 ms

160 bytes from x.x.x.x: icmp_seq=6 ttl=127 time=155 ms

160 bytes from x.x.x.x: icmp_seq=7 ttl=127 time=281 ms

160 bytes from x.x.x.x: icmp_seq=8 ttl=127 time=100 ms

160 bytes from x.x.x.x: icmp_seq=9 ttl=127 time=226 ms

160 bytes from x.x.x.x: icmp_seq=10 ttl=127 time=46.6 ms

160 bytes from x.x.x.x: icmp_seq=11 ttl=127 time=172 ms

160 bytes from x.x.x.x: icmp_seq=12 ttl=127 time=197 ms

160 bytes from x.x.x.x: icmp_seq=13 ttl=127 time=16.0 ms

160 bytes from x.x.x.x: icmp_seq=14 ttl=127 time=142 ms

160 bytes from x.x.x.x: icmp_seq=15 ttl=127 time=3.59 ms

160 bytes from x.x.x.x: icmp_seq=16 ttl=127 time=86.7 ms

160 bytes from x.x.x.x: icmp_seq=17 ttl=127 time=7.20 ms

--> HERE I PICKED UP THE PHONE AND STARTED TALKING - delay and jitter seems to be perfect

160 bytes from x.x.x.x: icmp_seq=23 ttl=127 time=4.10 ms

160 bytes from x.x.x.x: icmp_seq=24 ttl=127 time=3.92 ms

160 bytes from x.x.x.x: icmp_seq=25 ttl=127 time=4.20 ms

160 bytes from x.x.x.x: icmp_seq=26 ttl=127 time=3.94 ms

160 bytes from x.x.x.x: icmp_seq=27 ttl=127 time=4.02 ms

160 bytes from x.x.x.x: icmp_seq=28 ttl=127 time=4.23 ms

160 bytes from x.x.x.x: icmp_seq=29 ttl=127 time=4.14 ms

160 bytes from x.x.x.x: icmp_seq=30 ttl=127 time=4.24 ms

160 bytes from x.x.x.x: icmp_seq=31 ttl=127 time=4.43 ms

160 bytes from x.x.x.x: icmp_seq=32 ttl=127 time=4.12 ms

160 bytes from x.x.x.x: icmp_seq=33 ttl=127 time=5.55 ms

160 bytes from x.x.x.x: icmp_seq=34 ttl=127 time=5.67 ms

160 bytes from x.x.x.x: icmp_seq=35 ttl=127 time=4.50 ms

160 bytes from x.x.x.x: icmp_seq=36 ttl=127 time=4.27 ms

160 bytes from x.x.x.x: icmp_seq=37 ttl=127 time=4.02 ms

160 bytes from x.x.x.x: icmp_seq=38 ttl=127 time=4.22 ms

160 bytes from x.x.x.x: icmp_seq=39 ttl=127 time=4.15 ms

--> NOW I END THE CALL - delay and jitter are back on high values

160 bytes from x.x.x.x: icmp_seq=40 ttl=127 time=47.3 ms

160 bytes from x.x.x.x: icmp_seq=41 ttl=127 time=173 ms

160 bytes from x.x.x.x: icmp_seq=42 ttl=127 time=300 ms

160 bytes from x.x.x.x: icmp_seq=43 ttl=127 time=119 ms

160 bytes from x.x.x.x: icmp_seq=44 ttl=127 time=245 ms

160 bytes from x.x.x.x: icmp_seq=45 ttl=127 time=64.8 ms

160 bytes from x.x.x.x: icmp_seq=46 ttl=127 time=191 ms

160 bytes from x.x.x.x: icmp_seq=47 ttl=127 time=10.4 ms

160 bytes from x.x.x.x: icmp_seq=48 ttl=127 time=136 ms

160 bytes from x.x.x.x: icmp_seq=49 ttl=127 time=263 ms

160 bytes from x.x.x.x: icmp_seq=50 ttl=127 time=82.7 ms

160 bytes from x.x.x.x: icmp_seq=51 ttl=127 time=208 ms

160 bytes from x.x.x.x: icmp_seq=52 ttl=127 time=28.1 ms

160 bytes from x.x.x.x: icmp_seq=53 ttl=127 time=154 ms

160 bytes from x.x.x.x: icmp_seq=54 ttl=127 time=281 ms

160 bytes from x.x.x.x: icmp_seq=55 ttl=127 time=100 ms

Keeping in mind, that changing QoS class for WLAN had no effect on jitter and delay when only pinging wireless device.

How are your ping times with laptop to laptop on wireless. If they ping times look normal there, then there is an issue with configuration of the radio... compatibility with the Linksys phone.

Ping times between laptop (on wireless) and wired client behave exactly the same. If the laptop is idle, delay and jitter are high. When I started download on laptop, delay goes immediately under 10ms. After stopping download, delays goes back up. If I ping between wireless laptops, delay and jitter are total sum, so over 200ms.

When I connected Linksys IP phone to standalone AP, ping is about 5 to 10 ms.

Radio configuration on WiSM are on their default values.

This is in a lab, correct? Remove the mpls label-ip. if this doesn't help, post your show run-config so we can verify the configuration.

Unfortunately, this is a real environment. So I don't have access rights to copy startup-config.

I'll do some other measurement and post results here.

Hi, Pavel,

is your issue resolved? we have same issue