7921 stuck at Configuring IP

Unanswered Question
Nov 21st, 2008

I have 3 7921 phones. fw 1.1.1

CCM 4.2.3 (Option 150 set)

1100 AP 12.3(8)JEA3 x 1

1242 AP 12.4(10b)JA x 1

1231 AP 12.3(8)JA2 x 2

WEP 128-bit key1

MAC Auth Local list on AP

Occationally the phones will get stuck at 'Configuring IP' and show DHCP timeout. If I statically assign IP phone works fine. If I static assign IP, let it register, then enable DHCP, sometimes it will reregister fine, other times not.

I had two side-by-side and one registered fine, the other is stuck at Config IP.

I can't leave it statically assigned as we have two locations that users travel between and are on different subnets.

I've tried fw 1.2.1 but then phones that do register fine on DHCP fail totally. Seems 1.1.1 is the only on that works.

Also have 9 7920 units that work no problem.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
migilles Mon, 11/24/2008 - 21:27

Seems like you may have put in the wrong encryption key then either on this one phone or one of the aps? Would suggest to test open to ensure everything else is working, then work your way up from there. Would recommend to use fw 1.2(1) for the 7921G.

benharned Tue, 11/25/2008 - 06:01

If the wrong key was entered wouldn't the phone not work either way (DHCP or not)?

migilles Sun, 11/30/2008 - 18:58

Can associate to the ap with open + wep regardless of the keys matching as long as the ssid matches.

Also having 3 different AP versions deployed maybe ok, but definitely 3 different fw versions is not a supported deployment.

Since you have autononmous APs it may be very easy to have just 1 of the aps configured with the wrong wep key. I would start to gather data to see if this occurs in certain areas, associated to certain aps.

benharned Mon, 12/01/2008 - 05:46

I suspect it has to do with the 1241 ap. I know the APs have the right WEP key, it's the same one we've used for 4 years.

The fw versions are the highest available for the ap version. Should I downgrade the higher versions to match the lower? I wouldn't that that would be wise.

I will try and verify the fault with the 1241.

benharned Mon, 12/01/2008 - 12:43

> For the 7921G, need to have at least 12.3(8)JEA. The latest version is 12.3(8)JEC2.

I'm confused about this statement. Does 12.3(8)JEA translate to a firmware number? Did you mean 1242G (AIR-AP1242AG-A-K9)?

According to the web-access system info page, my 1100 series is a AIR-AP1121G-A-K9.

My other APs are AIR-AP1231G-A-K9

migilles Thu, 12/04/2008 - 23:10

Yes 12.3(8)JEC2 is a firmware version not the AP model number.

benharned Fri, 12/05/2008 - 05:44

Sorry, I guess what I meant was in your previous comment you asked if 12.3(8)JEC2 was on my 7921. I was asking if that was a typo and you meant to ask if that version was on my 1242.

migilles Fri, 12/05/2008 - 16:31

Yes 12.3(8)JEC2 is an AP firmware version.

The latest version for the 7921G is 1.2(1).

benharned Mon, 12/08/2008 - 08:29

Upgraded my 1242AG to 12.4(10b)JDA

Upgraded my 1121G to 12.3(8)JEC2

Upgraded my 7921 to 1.2.1

(These are the two APs that I'm in range of where I'm troubleshooting this)

Statically assigned IP, phone works fine.

If I change the phone to DHCP enabled, it will work.

If I reset the phone, I will get a DHCP error, but it will then configure and work.

If then, I release the DHCP and reset the phone it will get a DHCP error and stop at 'Configuring IP'.

I can see the device associated with the AP, so it's not a WAP issue.

migilles Tue, 12/09/2008 - 12:11

Again associated doesn't mean that authenticated. Can still associate to an AP with open + WEP, where there is a WEP mismatch. Also as stated before, should not use a potluck of firmware versions in your WLAN. Ensure they are all running the same code.

benharned Tue, 12/09/2008 - 12:44

> Ensure they are all running the same code.

You don't mean downgrade the 1242 to 12.3? I wouldn't think so. 12.4 isn't available for the 1231/1120 though.

I guess I'm confused what you mean by the same code.

migilles Wed, 12/10/2008 - 11:01

Yeah each AP should run the same firmware. 1242 shouldn't run 12.4 and 1100/1200 run 12.3. Needs to be the same ap firmware version on all aps even if they are different models.

setonhnet Mon, 12/22/2008 - 08:22

Do you have arp caching enabled on your AP? If so try turning it off.

migilles Mon, 12/22/2008 - 19:54

If autonomous will want to enable dot11 arp-cache optional, where the ap will forward over the air if the mac is not known. This is enabled by default on the Cisco Unified WLAN Controller, where arpunicast is disabled (proxy arp enabled).

setonhnet Tue, 12/23/2008 - 13:09

I know it might not be the suggested thing to do, but I can tell you from our experience that "dot11 arp-cache optional" actually caused the problems just like the original post describes with one of our autonomous locations.

So again I would suggest turning it off just to test and see if the problem goes away.

benharned Tue, 12/23/2008 - 13:31

ARP Caching is enabled per deployment guides I've followed. I will however try with it disabled. I am on vacation this week so I will attempt next week or after.

Thanks for the help and suggestions!

migilles Thu, 12/25/2008 - 08:30

Just fyi, if you disable arp caching you will get only 50% of potential idle battery life for the 7921/7925, but if disabled it will wake up at dtim to check for incoming packets so quality will not be effected. This is also covered in the 7921/7925 Deployment Guides as well.

If using the 7920 it does not wake up on dtim, but uses sccp to determine incoming calls and to stay awake for a brief period to answer the arp request.

torleif Mon, 01/05/2009 - 03:58

We have the same problem with a 7921. We use Aironet 1131AG. Enabling/disabling arp caching does not change anything. Enabling/disabling "Forward ARP Requests To Radio Interfaces When Not All Client IP Addresses Are Known" does not help. Static IP works fine. 7920 phones work OK.

migilles Mon, 01/05/2009 - 15:24

Ensure you are using 1.2(1) on the 7921G and we recommend 12.4(3g)JA1 or later for the 1130. I would capture a wlan sniffer trace to ensure that the AP is responding. The phone shouldn't get into "Configuring IP" state unless it can't reach the CM due to keepalive timeout or if just powered on. Ensure that you have the ap switchports set for trunk mode if vlans are enabled as well.

benharned Mon, 01/05/2009 - 19:58

I have opened a TAC case and that was the suggestion, to capture sniffer packets. I was unsure I had the capability to do that but the tech gave me a link to a free sniffer software.

I will perform this diagnosis early this week.

benharned Wed, 01/07/2009 - 07:36

I am using MS DHCP. It's on my CM server (done that way by who installed it).

I put my laptop on the voice network and got an IP from that DHCP. I was able to get some data with the sniffer and it shows the phone doing a "DHCP Discover" and the server doing a "DHCP Offer".

Not sure what that means, or if the whole transaction is being captured. I have a filter for only udp port 67 and 68 packets.

m_zabetian Wed, 01/07/2009 - 11:34

if you use MS DHCP delete all lease IP addresses and change lease time to 18 hours and reconcile your DHCP database on voice scope maybe it is help :)

benharned Tue, 02/03/2009 - 05:46

This was the last response from TAC:

***

Please send me the unfiltered capture at the WLC port and at the DHCP server concurrently so we can see if all the packets make from one end to the other. Also capture the output of the following debugs at the same time.

debug client (Clients mac address)

debug dhcp message enable

debug aaa all enable

***

I'm not totally sure how to get the captures at the specific locations he requests.

WLC = Wireless LAN Controller? Don't have one, unless he means the AP.

Not sure where to put the debug commands... tried to see if they would work on the AP and I think only one was valid.

I had a different project the past week and a half that kept me from working on this. Plus, the TAC keeps talking above me (e.g. told him I don't have a WLC) and when I try to convey my understanding he just comes back with more techno-talk.

torleif Fri, 03/20/2009 - 04:33

I have tested the commands on a 2100 Wireless Lan Controller. The commands gave output, so I suggest You contact TAC and explain that you don't have w WLC.

c.yeo Tue, 03/31/2009 - 08:46

We aren't using the exact APs, but we had a terrible problem when using 7921s and 7920 phones in the same WLAN.

Once we turned off all 802.11b speeds the problem seemed to go away entirely. I think the 7921s must have some difficulty switching between 802.11b and 802.11g. Now we have to upgrade all our 7920 phones to 7921. (the 7920s will be used at a different site without mixing the phones).

Jacob Fussell Thu, 04/02/2009 - 18:37

What happens if you disable WMM on the radio interface of the AP when the issue is happening? This effectively disables the U-APSD power save mechanism which could potentially be at play here. To disable this, go into the radio interface config and do "no dot11 qos mode".

migilles Sun, 04/05/2009 - 22:25

There are no issues of the 7921 downshifting from 802.11g (OFDM) to 802.11b rates (CCK). But when 802.11b rates are enabled, then the 7921 must send a CTS packet to protect an 802.11g transmission. We do recommend to disable 802.11b if possible.

rmaitra76 Fri, 04/24/2009 - 11:37

I have had the same issue at our autonomous sites. We had several phones 'randomly' getting stuck on configuring IP. We even that the issue that phone would have a valid ip and was connected, but 'lost' it. Contacted TAC and they recommended that we do the following:

*********************

Add Commands:

Dot11 igmp snooping-helper

Dot11 priority-map avvid

Remove Command:

No dot11 arp-cache optional

(We have seen connectivity issues with 7921 if you have this in the configuration).

*******************

I did inform the TAC engineer that the design guide states to ENABLE 'dot11 arp-cach' but I was informed that on our newer firmware on the phone we did not need this option. Once I disabled 'dot11 arp-cahce' the problem stopped occurring. (at least no reports of it :) )

I am aware of the battery consequences, however, it is trade off between having the phones working or not.

If you want to reference a case number it is : SR 610514755

1242 : 12.3.11JA1

7921 : 1.2.1

migilles Fri, 04/24/2009 - 12:43

Yes it is advised to enable proxy ARP. On autonomous, it is suggested to enable "dot11 arp-cache optional", which allows the AP to forward any ARPs over the air if the client MAC is not known. If you don't enable "optional", other clients that don't transmit periodically can get stuck w/o connectivity as the ARP entry gets aged out. However, no issues with the 7921 as it transmits periodically (SCCP keepalive every 30 seconds). If using 1.2(1) firmware and the autonomous SSID, ensure you have "admit-traffic" added to the SSID regardless of having ACM enabled for voice.

torleif Tue, 04/28/2009 - 01:28

Problem solved!

We had the same problem with our 7921. It would not get DHCP.

We have some older 2924 switches wich default uses VLAN1 as the management VLAN. We have been using VLAN1 for the phone traffic as well. It seems that the 7921 does not accept DHCP adresses given to VLAN1/management VLAN. When we changed the SSID so it uses another VLAN the phone gets DHCP address without problems.

I hope this solves your problem as well. :-)

benharned Tue, 04/28/2009 - 04:52

I appreciate the effort but unfortunately my situation isn't the same. My voice is on VLAN200 and running over 3524 switches.

I haven't heard from the TAC tech lately but the status of my case is "Awaiting lab recreation". Whatever that means.

benharned Thu, 04/30/2009 - 10:35

Well still nothing from TAC, but I did change ARP cacheing from 'arp-cache' to 'arp-cache optional' and it seemed to work. My 7921 went from configuring to being registered.

Well I then took it offsite and when I came back it didn't register and failed with the DHCP Timeout.

Today I disabled ARP cacheing and when I came back from being offsite my phone registered no problems.

I'm going to leave it at that and see what happens, and hope it doesn't affect my 7920 phones.

benharned Wed, 05/06/2009 - 05:08

'arp-cache optional' seemed to work at first, but then taking the phone off-site and coming back on produced the DHCP errors again.

I now have arp-cache totally disabled and everything has been working great so far. I have seen no ill effects either with my 7920 phones haveing arp disabled, so we'll see.

I updated my TAC case with this info, so I'll wait to see what the tech says about it.

migilles Sat, 05/02/2009 - 13:22

Is outlined in the 7921G Deployment Guide recommending not to place APs into VLAN1 and definitely not phone traffic.

See page 49.

http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7921g/6_0/english/deployment/guide/7921dply.pdf

The reason is there is typically more broadcast and multicast traffic present there. The autonomous APs use IAPP to communicate to each other which is a multicast protocol, so need to ensure those messages reach their destination successfully.

There is no VLAN tag over the air, so 7921 wouldn't know the difference between DHCP sourced from VLAN 1 or something different.

benharned Wed, 05/06/2009 - 08:38

The subnet is .1-.254, only for phones and i only have 45-50 phones.

I thought it was worth checking. I cured mine by checking into this.

Although we have a /24 subnet we limit the range amount in the scope settings. It was set from .1 to .10. 13 different phones were competing for those 10 IP addresses. They all register now because we increased the range from .1 to .20.

Good luck

B

benharned Wed, 05/06/2009 - 11:05

Thanks for the idea. I did not setup our system, but it dedicates an entire subnet to phone IPs. I guess they wanted to be safe?

It seems though that disabling arp-cacheing has done the trick.

krahmani323 Tue, 05/12/2009 - 10:10

Hi,

Thanks for all this relevant information in this topic.

In fact one of my customers has been facing approximately the same issue.

The architecture looks to be similar:

CCM 4.2.3sr2b (dhcp option 150/ tftp).

AIR-AP1242AG-E-K9 (x 32) => 31 AP in the IOS version 12.4(3g)JA1 and one in the 12.4(3g)JA !

7921 FW => 1.0.4

7920 => Does not encounter the problem.

We have the command 'dot11 arp-cache' in all the APs.

All the 7921 phones of the company need to transit via the main site in order to be configured with the correct profile parameters (Wireless authentification; encryption etc..).

But when DHCP was set to yes with no other information in the network configuration profile, the phone was not able to register stucking in 'Configuring IP' with 'DHCP Timeout' in the Status / Status messages.

When sniffing between the AP and the switch we could see just like you a 'DHCP Discover message ' answered by a 'DCHP Offer' from the server but no 'DHCP Request' coming from the phone.

The only solution found to allow the phone registering was to manually change 'Alternate TFTP' to yes in the Network profile configuration and specify the 'TFTP Server 1' address (DHCP still configured to yes).

After some tests it appeared that when I was in the older FW version the issue occurred, but not at all with the latest 7921 load (1.3.2). Maybe it could allow you to fix the issue without having to disable arp-caching.

Thank you.

Karim

Telindus FRANCE.

Actions

This Discussion