[cisco-voip] 8831 registration problems with 9.1.1a

Ryan Ratliff (rratliff) rratliff at cisco.com
Thu Sep 5 10:26:44 EDT 2013


Thanks for the good info Erick.

I just added those commands to my switch here and will let you know if I hit the same problem.

What was the switch bug you found?

-Ryan

On Sep 5, 2013, at 4:14 AM, Erick B. <erickbee at gmail.com<mailto:erickbee at gmail.com>>
 wrote:

Some updates on this....

This is combination of having port-security and spanning-tree guard root enabled on the port it looks like. I did find a switch IOS bug the other day where both could cause a problem. I can get the phone back up and registered again if I tinker with the switchport settings (shutdown port, remove port-security, remove guard root, throw port into another vlan then back into voice vlan, leave port shutdown for 2-3 minutes then bring it back up). The command variation slightly varies and sometimes need to do it 1-2 times.

I'm trying to get them to move this 8831 to another switch with newer IOS until we get window to update the IOS on one it is on, plus if it's moved to other switch and this doesn't happen when it is unplugged or port shutdown I can point toward the switch IOS more.


On Sat, Aug 31, 2013 at 12:38 AM, Erick B. <erickbee at gmail.com<mailto:erickbee at gmail.com>> wrote:
Yes, a MAC address is learned on the interface and another device on same VLAN gets the MAC via ARP response fine.
Can't ping however.

I narrowed it down even further playing with it some more this evening, I reverted port back to the way all ports are setup.

interface Gigabit0/3
 switchport mode access
 switchport voice vlan 100
 switchport port-security maximum 3
 switchport port-security
 srr-queue bandwidth share 10 10 60 20
 srr-queue bandwidth shape 10 0 0 0
 priority-queue out
 mls qos trust device cisco-phone
 mls qos trust cos
 auto qos voip cisco-phone
 spanning-tree portfast
 spanning-tree guard root
 service-policy input AutoQoS-Police-CiscoPhone

If I remove the "spanning-tree guard root" command, the phone comes back fine. I tested it a half dozen times.
Spanning tree on the port was in forwarding state when it wasn't working.

Haven't been able to have someone move the phone to another switch yet, I'll see if they can unplug it a few times to see if it comes back fine that way. It's at another site.

Thanks.



On Fri, Aug 30, 2013 at 8:28 AM, Ryan Ratliff (rratliff) <rratliff at cisco.com<mailto:rratliff at cisco.com>> wrote:
When the phone is in this state does the mac address-table on the switch get updated?  If so can another device on the vlan get an ARP response?

This could still be a phone problem.  It has to send a packet to build the mac address-table on the switch (I'd guess this is happening if it got an IP from DHCP).  Then the phone has to respond to ARPs, and then for ICMP to work it has to respond to those packets.  There are a few places in this process that the endpoint can break things.

For comparison I've got an 8831 on 9-3-3-3 that's been up for a month or more registered to 9.1(1) the whole time.  It's been daisy-chained a few times but I don't recall messing with the switchport at all.  It's connected to a 3750 running 122-55.

-Ryan

On Aug 30, 2013, at 2:31 AM, Erick B. <erickbee at gmail.com<mailto:erickbee at gmail.com>> wrote:

Thanks for the pointers, however I tried the new search tool with build # and right product and various keywords and nothing comes up.

Anyway...

I tinkered with the phone some more and this looks to be a IOS issue on a switch. I broke it a few times and fixed it the same way each time and the time port is down doesn't matter. If the phone is unplugged or port is shutdown, the phone doesn't come back with a good LAN connection. I see the phone via CDP neighbor, it gets a IP address eventually but I can not ping it from the same VLAN at all no matter how long I wait.

To fix it I shutdown the switchport, set the switchport vlan to another vlan then back to the voice vlan then re-enable the switchport.

Once the phone is registered, I can reset it from CUCM and it comes up fine again. It only has the problem if unplugged or loses power/port shutdown.

The switch is a 3560 with IOS version c3560-ipbase-mz.122-35.SE5.bin.  I'm going to have them plug phone into a newer switch and see if things are better and look into updating the 3560.

Erick


On Thu, Aug 29, 2013 at 10:19 PM, Ryan Ratliff (rratliff) <rratliff at cisco.com<mailto:rratliff at cisco.com>> wrote:
There's a big difference in not registering at all and losing registration intermittently.  The first is almost always a config or devicepack issue. The second mostly network or a bug, though the SIP profile can come into play.

For open bugs you'll find BST much more accurate for CUCM bugs than phones.  The phone bugs are there it's just a challenge sometimes to get the fixed-in version to be something that makes sense to anyone other than a developer and this obviously wreaks havoc with searches.
Here's the search I whipped up for all bugs fixed with a version of "9.1(2.10000".  I left of the last digits to get bugs fixed in earlier builds than 28.
https://tools.cisco.com/bugsearch/search?kw=&pf=prdNm&pfVal=268439621&rls=9.1%282.10000&sb=fr&srtBy=byRel&bt=custV


-Ryan

On Aug 29, 2013, at 6:51 PM, Erick B. <erickbee at gmail.com<mailto:erickbee at gmail.com>> wrote:

Ok. Interesting. The time on the 8831 on initial power on is 7pm on 12-31-99 it looks like then it is right once registered so...

The phone's been up and fine now for almost 6 hours since I shutdown the switchport for roughly 2 minutes before bringing the port back up.

Is there a list of bugs fixed in CUCM 9.1.2 anywhere in a document? The 9.1.2 release notes say to use bug toolkit. I dislike release notes not listing resolved caveats as bug toolkit might not pull up everything that was fixed and it is up to us to find what was fixed. For example, the release notes for the 8831 9.3.3 firmware list a handful of open caveats but resolved section says to use bug toolkit. You go search for bugs on the 8831 phone model and only one comes up with 1 hit. I would expect to see the open caveats listed in the release notes and a few others.

I'll work on getting a packet capture. This is in a remote location so I'll have to see if I can get my hands on a 8831 one myself hopefully with 9.3.3.3.
9.3.3.5 is the only firmware on the cisco.com<http://cisco.com/> page.
I can throw new firmware on it but was trying to figure this out also.

There are a couple posts on cisco support forums about this, and a few have upgraded to CUCM 9.1.2 to solve this but no details/bugs/etc provided.
https://supportforums.cisco.com/message/4019981#4019981



On Thu, Aug 29, 2013 at 3:34 PM, Wes Sisk (wsisk) <wsisk at cisco.com<mailto:wsisk at cisco.com>> wrote:
great find Brian. one bit of clarification - "cm_closed_tcp" mesa the phone received TCP RST or FIN from the _network_ that did not necessarily originate from CUCM.

-Wes

On Aug 29, 2013, at 3:17 PM, Brian Meade (brmeade) <brmeade at cisco.com<mailto:brmeade at cisco.com>> wrote:

Eric,

I didn’t find the initial time the phone went into this state but the phone does print a list of reasons why the phone last unregistered when it boots up:

0918 NOT 00:00:57.357542 CVM-System P7-display MQThread|cip.sipcc.SipEnhancedAlarmInfo:getLastUnregistrationTimeReason - TimeStamp=1377753202845946685028372,946684857457,1377753927440,946685018334,946685040399946685046997,946684934872,946684857026; Reasons =14,14,14

Here, you can see the last 3 unregister reasons have cause 14 which corresponds to CM_CLOSED_TCP so CallManager closing the TCP socket.

We don’t have any engineering specials posted for the 8831 but a quick bug search didn’t show anything.  Can you get a packet capture of it in the broken state?

Thanks,
Brian Meade


From: Erick B. [mailto:erickbee@<mailto:erickbee@>gmail.com<http://gmail.com/>]
Sent: Thursday, August 29, 2013 3:42 PM
To: Brian Meade (brmeade)
Cc: voip puck
Subject: Re: [cisco-voip] 8831 registration problems with 9.1.1a

Brian, I sent you the console logs. Thanks.

On Thu, Aug 29, 2013 at 1:12 PM, Erick B. <erickbee at gmail.com<mailto:erickbee at gmail.com>> wrote:
Yea, let me do that.

It seems if I shutdown the switchport for 2-3 minutes then bring it back up it stays up, if a quick shut/no shut is done then it doesn't come up or may register for a minute then go back unregistered.

On Thu, Aug 29, 2013 at 1:02 PM, Brian Meade (brmeade) <brmeade at cisco.com<mailto:brmeade at cisco.com>> wrote:
Eric,

Can you collect console logs covering the time period of it going from working to nonworking?

Thanks,
Brian Meade

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>] On Behalf Of Erick B.
Sent: Thursday, August 29, 2013 1:24 PM
To: voip puck
Subject: [cisco-voip] 8831 registration problems with 9.1.1a

Does anyone know if there are issues with sip8831.9-3-3-3
 firmware on 8831 model phone and network/VLAN connection?

Had a 8831 working for a month or so fine with 9.1.1a (9.1.1.20000-5) and now it won't register reliably. If I shutdown the switchport and such a few times it registers again, sometimes for 1-2 minutes or might stay up and work fine until it is unplugged or reset again.

I set the switchport access vlan to be in voice vlan directly to (removed switchport voice vlan) and that seemed to help but same thing happened the next day.

Not finding any release notes for the 9.3.3.5 firmware and there is a cisco support forum post suggesting a upgrade to 9.1.2 call manager fixes this issue.

Device Pack 9.1.1.21017-2 used to add support for this.

Thanks


_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip


_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130905/9744df48/attachment.html>


More information about the cisco-voip mailing list