SFE2000P - Interface reset on DHCP renew?

As anyone experienced this problem:
Im running POE for Cisco 504G phones with a PC attached to the LAN switch port on the phone. DHCP is being served through a Cisco 1800 series router.
It seems that the interface will shutdown and come right back on at DHCP renewal obviously resetting the phone and causing the PC client to disconnect. The only reason I noticed this is because it is right at the same time the lease is expiring. Both the phone and the PC are on the same VLAN.
Thanks
Domenick

Hi Domenick,
The question in my mind, is how would a lease renewal on a phone going to cause the port to go down. I'm not sure what you mean by .16, but if it is port number 16 no, should be no problem, it's not a special port.
I'm guessing that the SFE2000P is not in stacking mode or Layer 3 mode (checked via telnet or console).
By the sound of the error log when the link goes down and up again, sure sounds like the phone is going down and up.
You have an option to see what the phone is doing by sysloging information from the phone to a syslog server, such as the kiwi-syslog daemon.
Sure sounds like the phone is dropping and not the switch port, I may be wrong, a syslog of what's happening with the spa504G might be useful.
I have attached the admin guide that shows how to set up the unit for local or remote syslog server and sending debug messages to the syslog server. This might be informative, but it sure sounds like you should open a call with the Small Business Support center as well.
http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html
regards Dave

Similar Messages

ISE CWA DHCP renew/release

Does a user needs Admin right on his Windows laptop for the Central WebAuth DHCP Renew / Release to work?
Thanks.

Thank you Tariq for your prompt reply.
I'm don't understand how CoA fix the problem of the workstation. CoA tells the swtich to assign a new VLAN, but it's not CoA per se that tells the workstation to reset the IP address, since CoA is between ISE and the switch only. It must be ISE then that send a DHCP release / renew command to the workstation. I presume that for a Guest user that is done in the browser by Activex. So maybe the problem is that the web browser is not accepting ActiveX coding? If you have any other information on the DHCP release / renew process wiith CWA, it would be appreciated.
Thank you again for all the great posts you are contributing to this forum.
Catherine

How to Force Client's DHCP Renew on Mobility Event?

Hi All,
I have a (single) client (it is a cisco IOS router) behind a wireless workgroup bridge (cisco1242).
The client's IP address is obtained via DHCP from the wired network.
Now, when roaming occurs, the Client will never have knowledge about this event,
and hence will not renew its IP address until lease expiers.
This is not a problem of course when Layer 2 roam occurs, but with Layer 3
roam it will interrupt the traffic.
The cisco's IP Mobile implementation does have this issue addressed in DCCoA
scenario: the WGB is configured to send an SNMP trap on its dotradio state change;
the cisco mobile router is configured with snmp-server manager to process this trap
and start DHCP renew on the Down/Up event. Unfortunately, this works in Mobile IP
scenario only because I cannot make it work without the mobile router registered
with a home agent.
I wonder if someone could come up with an idea on how to force DHCP renew
on a client (cisco IOS router) in such a situation - event scripting, SLA, or ...?
alex
============================

Yes, George, I've looked at this.
The problem with dynamic anchoring with static IP address is how
the (new) WLC detects the IP address of the client. Remember that
my client is cisco router with network(s) behind it. Snooping the
ARP request will not work since ARP timeout in IOS is 4 hours.
Orphan packet handling (I understand it is intercepting the IP
packet from client without reply(?)) will most probably give erroneous
result as this packet can be a packet from a network behind the router.
alex
====================================

Radio Interface Reset and Shutdown Frequently

As recently new office from end-Sept, we have found that the radio interface reset very frequently which has been happening about over 15 times within 8 weeks for one AP on average. Some of those (3 AP so far) got the radio interface down eventually and we need to reload the AP to make it up again.
the AP model is AIR-LAP1142N-N-K9 and the IOS version is
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:表格內文;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";
mso-ansi-language:#0400;
mso-fareast-language:#0400;
mso-bidi-language:#0400;}
st1\:*{behavior:url(#ieooui) }
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:表格內文;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";
mso-ansi-language:#0400;
mso-fareast-language:#0400;
mso-bidi-language:#0400;}
c1140-k9w7-mx.124-21a.JA1. Power supply is made from the PoE switch c2960s. Is there any issue related to IOS? or some other factors may cause the issue happen? Any debug command can show the status of AP? Please advice.

Hi Surendra,
Other than IOS, will this radio interface reset and shutdown issue affect by the nearby AP which is not belongs to the same office.
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";
mso-ansi-language:#0400;
mso-fareast-language:#0400;
mso-bidi-language:#0400;}
Scenario:
The new office gets 2 floors. One is 5/F which has installed 9 APs with different channels and another one is 6/F which has installed 6 APs with different channels as well. We found that there are many events “%DOT11-4-MAXRETRIES: Packet to client reached max retries, removing the client” logged on 5/F and 6/F AP.
We also found that the radio interface reset very frequently which has been happening about over 15 times within 8 weeks for one AP on average. Some of those (3 AP so far) got the radio interface down eventually and we need to reload the AP to make it up again.
Is/ are there any possibility caused by otherenvironmental factors? Please advise.
Best regards,
Bell

WAN Side DHCP Renewal

My existing router (not the Actiontec) allows me to view all activity going on with my network. I just noticed that the WAN DHCP renews every hour. When I look at the lease time it shows the next renewal is coming up at 12:17pm.
Why is Verizon doing this?

jumpin68ny wrote:
fortigate 3.0. The WAN side is connected to the Ethernet Port of Verizon Fios service.
Since this is FIOS, directly to the ONT (optical network terminal)?
Google Image search for fios ont
Because if not: that first router that is handling the public IP, is giving you a one hour lease.
^^
In Verizon DHCP areas, I hear/read that the lease time is two hours.
If you are the original poster (OP) and your issue is solved, please remember to click the "Solution?" button so that others can more easily find it. If anyone has been helpful to you, please show your appreciation by clicking the "Kudos" button.

Dot11 radio interface reset protocol down

I have a cisco 1400 that that show interface show int dott1 radio interface reset protocol down. I had a surge in the area and had the problem after. I copied the config over to a new Ap and power injector and the problem persists. The bridge is the non root bridge. I had read a caveat cscea75989 but it said take no action. Take no action is not fixing my problem at this time. Any suggestions would be appreciated. Thanks.

There are a number of known issues on this. One which sounds similar is CSCea45031. Check if you are hitting the same.

3G interface resets but signal looks good

Hi All,
can anyone explain what this means.I have enabled the following debugs. everytime I look at it there is no issue with the signal. But my guess is the router interface is resetting due to the signal. Can anyone explain if its due to 3G signalling
Router 881G
CELLULAR:
DATA debugging is on
DM debugging is on
ASYNC debugging is on
RDM debugging is on
CALLBACK debugging is on
PPP:
PPP authentication debugging is on
PPP protocol errors debugging is on
PPP protocol negotiation debugging is on
BAP:
BAP negotiation debugging is on
BAP error debugging is on
3688676: Mar 29 08:48:33.641 BRU: Ce0 PPP: Outbound ip packet dropped, line protocol not up
3688677: Mar 29 08:48:33.641 BRU: Ce0 PPP: Outbound ip packet dropped, line protocol not up
3688678: Mar 29 08:48:33.641 BRU: Ce0 PPP: Outbound ip packet dropped, line protocol not up
3688679: Mar 29 08:48:33.641 BRU: Ce0 PPP: Outbound ip packet dropped,
3688700: Mar 29 08:48:36.749 BRU: new DSR value received, 1
3688701: Mar 29 08:48:36.749 BRU: old value: handshakes->DSR= 1
3688702: Mar 29 08:48:38.741 BRU: %LINK-3-UPDOWN: Interface Cellular0, changed state to down
3688703: Mar 29 08:48:38.741 BRU: Ce0 PPP: Sending cstate DOWN notification
3688704: Mar 29 08:48:38.745 BRU: Ce0 PPP: Processing CstateDown message
3688705: Mar 29 08:48:49.326 BRU: new DSR value received, 1
3688706: Mar 29 08:48:49.326 BRU: old value: handshakes->DSR= 1
3688707: Mar 29 08:48:49.758 BRU: new DSR value received, 1
3688708: Mar 29 08:48:49.758 BRU: old value: handshakes->DSR= 1
3688709: Mar 29 08:48:56.582 BRU: %LINK-3-UPDOWN: Interface Cellular0, changed state to up
3688710: Mar 29 08:48:56.590 BRU: %DIALER-6-BIND: Interface Ce0 bound to profile Di1
3688711: Mar 29 08:48:56.590 BRU: Ce0 PPP: Sending cstate UP notification
3688712: Mar 29 08:48:56.594 BRU: Ce0 PPP: Processing CstateUp message
Cellular0 is up, line protocol is up
Hardware is 3G Modem-HSPA/UMTS/EDGE/GPRS-850/900/1800/1900/2100MHz / Global
Description: [cewan-phy]
MTU 1500 bytes, BW 5760 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open
Open: IPCP, loopback not set
Keepalive not supported
Interface is bound to Di1 (Encapsulation PPP)
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 2d03h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/1000/0 (size/max total/drops)
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
     53671 packets input, 15696493 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     62119 packets output, 13733542 bytes, 0 underruns
     0 output errors, 0 collisions, 5 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up DSR=up DTR=up RTS=up CTS=up
Hardware Information
====================
Modem Firmware Version = K2_0_7_19AP C:/WS/F
Modem Firmware built = 10/26/09
Hardware Version = 1.0
International Mobile Subscriber Identity (IMSI) = 206012210378433
International Mobile Equipment Identity (IMEI) = 359109030082750
Integrated Circuit Card ID (ICCID) = 8932002100084586363
Mobile Subscriber International Subscriber
IDentity Number (MSISDN) =
Factory Serial Number (FSN) = D57138003301002
Modem Status = Online
Current Modem Temperature = 46 deg C, State = Normal
PRI SKU ID = 9993165, SKU Rev. = 1.0
Profile Information
====================
Profile password Encryption level: 7
Profile 1 = ACTIVE*
PDP Type = IPv4
PDP address = <ip address masked>
Access Point Name (APN) = internet.proximus.be
Authentication = None
Username: , Password: 02
* - Default profile
Data Connection Information
===========================
Data Transmitted = 10775742 bytes, Received = 12294276 bytes
Profile 1, Packet Session Status = ACTIVE
        IP address = <ip address masked>
Profile 2, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Profile 3, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Profile 4, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Profile 5, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Profile 6, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Profile 7, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Profile 8, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Profile 9, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Profile 10, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Profile 11, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Profile 12, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Profile 13, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Profile 14, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Profile 15, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Profile 16, Packet Session Status = INACTIVE
        Inactivity Reason = Normal inactivate state
Network Information
===================
Current Service Status = Normal, Service Error = None
Current Service = Combined
Packet Service = HSPA (Attached)
Packet Session Status = Active
Current Roaming Status = Home
Network Selection Mode = Automatic
Country = BEL, Network = PROXI
Mobile Country Code (MCC) = 206
Mobile Network Code (MNC) = 1
Location Area Code (LAC) = 2603
Routing Area Code (RAC) = 208
Cell ID = 20324
Primary Scrambling Code = 466
PLMN Selection = Automatic
Registered PLMN = BEL PROXIMUS , Abbreviated = PROXI
Service Provider =
Radio Information
=================
Radio power mode = ON
Current Band = WCDMA 2100, Channel Number = 10588
Current RSSI = -84 dBm
Band Selected = Auto
Number of nearby cells = 1
Cell 1
        Primary Scrambling Code = 0x1D2
        RSCP = -84 dBm, ECIO = -2 dBm
Modem Security Information
==========================
Card Holder Verification (CHV1) = Disabled
SIM Status = OK
SIM User Operation Required = None
Number of Retries remaining = 3

Hi Marco,
    Connection goes down intermittently and it stays up for very long time, more than a day some time or some time certain no of hours. I am not running any ping. I am not sure about the timing it takes between IPCP is completed ("IPCP: State is Open") and the link is closed ("I TERMREQ").
IOS c880data-universalk9-mz.151-1.T1.bin
Model 881G
One of my friend said there is a bug on 881G router IOS not sure about it though, but he hasnt seen my debug output.
This is the bug he was saying but I am not sure if mine is related to that as my CHAT script dont seem to be time out.
Problem Code: Error Messages, Logs, Debugs Software Version: C880DATA-universalk9-mz.151-2. Problem Details: Customer is running traffic over the 3card in a 881G. It fails however I can see from "show cell 0 all" that the modem has 3G coverage and a good signal as the RSSI is good. However the chat script continues to timeout. The configuration has not changed and it has worked and fails intermi
Thanks in Advance for your help
I have attached the debug of the CHAT script when the link goes down and come back.
3706575: Apr 1 08:51:03.995 BRU: Ce0 PPP: Outbound ip packet dropped, line protocol not up
3706576: Apr 1 08:51:03.995 BRU: Ce0 PPP: Outbound ip packet dropped, line protocol not up
3706577: Apr 1 08:51:03.995 BRU: Ce0 PPP: Outbound ip packet dropped, line protocol not up
3706578: Apr 1 08:51:03.995 BRU: Ce0 PPP: Outbound ip packet dropped, line protocol not up
3706579: Apr 1 08:51:03.999 BRU: Ce0 PPP: No remote authentication for call-out
3706580: Apr 1 08:51:03.999 BRU: Ce0 LCP: Event[Timeout-] State[Closing to Closed]
3706581: Apr 1 08:51:03.999 BRU: Ce0 LCP: Event[DOWN] State[Closed to Initial]
3706582: Apr 1 08:51:03.999 BRU: Ce0 PPP: Phase is DOWN
3706583: Apr 1 08:51:04.007 BRU: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0, changed state to down
3706584: Apr 1 08:51:06.007 BRU: %LINK-5-CHANGED: Interface Cellular0, changed state to reset
3706585: Apr 1 08:51:06.011 BRU: Ce0 DDR: has total 0 call(s), dial_out 0, dial_in 0
3706586: Apr 1 08:51:06.011 BRU: %DIALER-6-UNBIND: Interface Ce0 unbound from profile Di1
3706587: Apr 1 08:51:06.011 BRU: Ce0 PPP: Sending cstate DOWN notification
3706588: Apr 1 08:51:06.011 BRU: Ce0 PPP: Processing CstateDown message
3706589: Apr 1 08:51:06.015 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706590: Apr 1 08:51:07.015 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706591: Apr 1 08:51:08.015 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706592: Apr 1 08:51:09.083 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706593: Apr 1 08:51:10.083 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706594: Apr 1 08:51:11.083 BRU: %LINK-3-UPDOWN: Interface Cellular0, changed state to down
3706595: Apr 1 08:51:11.083 BRU: Ce0 PPP: Sending cstate DOWN notification
3706596: Apr 1 08:51:11.083 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706597: Apr 1 08:51:11.087 BRU: Ce0 PPP: Processing CstateDown message
3706598: Apr 1 08:51:12.083 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706599: Apr 1 08:51:13.083 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706600: Apr 1 08:51:14.083 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706601: Apr 1 08:51:15.083 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706602: Apr 1 08:51:16.083 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706603: Apr 1 08:51:17.083 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706604: Apr 1 08:51:18.083 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706605: Apr 1 08:51:19.083 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706606: Apr 1 08:51:20.083 BRU: Di1 DDR: No free dialer - starting fast idle timer
3706607: Apr 1 08:51:21.011 BRU: Ce0 DDR: re-enable timeout
3706608: Apr 1 08:51:21.083 BRU: Ce0 DDR: rotor dialout [best] least recent failure is also most recent failure
3706609: Apr 1 08:51:21.083 BRU: Ce0 DDR: rotor dialout [best] also has most recent failure
3706610: Apr 1 08:51:21.083 BRU: Ce0 DDR: rotor dialout [best]
3706611: Apr 1 08:51:21.083 BRU: Di1 DDR: Nailing up the Dialer profile [attempt 16]
3706612: Apr 1 08:51:21.083 BRU: Di1 DDR: Dialer dialing - persistent dialer profile
3706613: Apr 1 08:51:21.083 BRU: Ce0 DDR: Dialing cause Persistent Dialer Profile
3706614: Apr 1 08:51:21.083 BRU: Ce0 DDR: Attempting to dial cellprofile1
3706615: Apr 1 08:51:21.083 BRU: CHAT3: Attempting async line dialer script
3706616: Apr 1 08:51:21.083 BRU: CHAT3: Dialing using Modem script: cellprofile1 & System script: none
3706617: Apr 1 08:51:21.083 BRU: CHAT3: process started
3706618: Apr 1 08:51:21.083 BRU: CHAT3: Asserting DTR
3706619: Apr 1 08:51:21.087 BRU: CHAT3: Chat script cellprofile1 started
3706620: Apr 1 08:51:21.087 BRU: CHAT3: Sending string: ATDT*99***1#
3706621: Apr 1 08:51:21.087 BRU: CHAT3: Expecting string: CONNECT
3706622: Apr 1 08:51:21.091 BRU: CHAT3: Completed match for expect: CONNECT
3706623: Apr 1 08:51:21.091 BRU: CHAT3: Chat script cellprofile1 finished, status = Success
3706624: Apr 1 08:51:23.171 BRU: %LINK-3-UPDOWN: Interface Cellular0, changed state to up
3706625: Apr 1 08:51:23.171 BRU: Ce0 DDR: Dialer statechange to up
3706626: Apr 1 08:51:23.175 BRU: %DIALER-6-BIND: Interface Ce0 bound to profile Di1
3706627: Apr 1 08:51:23.175 BRU: Ce0 DDR: Dialer call has been placed
3706628: Apr 1 08:51:23.175 BRU: Ce0 PPP: Sending cstate UP notification
3706629: Apr 1 08:51:23.179 BRU: Ce0 PPP: Processing CstateUp message
3706630: Apr 1 08:51:23.183 BRU: PPP: Alloc Context [852C2C68]
3706631: Apr 1 08:51:23.183 BRU: ppp23 PPP: Phase is ESTABLISHING
3706632: Apr 1 08:51:23.183 BRU: Ce0 PPP: Using dialer call direction
3706633: Apr 1 08:51:23.183 BRU: Ce0 PPP: Treating connection as a callout
3706634: Apr 1 08:51:23.183 BRU: Ce0 PPP: Session handle[AE000017] Session id[23]
3706635: Apr 1 08:51:23.183 BRU: Ce0 LCP: Event[OPEN] State[Initial to Starting]
3706636: Apr 1 08:51:23.183 BRU: Ce0 PPP: No remote authentication for call-out
3706637: Apr 1 08:51:23.183 BRU: Ce0 LCP: O CONFREQ [Starting] id 1 len 20
3706638: Apr 1 08:51:23.183 BRU: Ce0 LCP:    ACCM 0x000A0000 (0x0206000A0000)
3706639: Apr 1 08:51:23.183 BRU: Ce0 LCP:    MagicNumber 0xE74DCDE6 (0x0506E74DCDE6)
3706640: Apr 1 08:51:23.183 BRU: Ce0 LCP:    PFC (0x0702)
3706641: Apr 1 08:51:23.183 BRU: Ce0 LCP:    ACFC (0x0802)
3706642: Apr 1 08:51:23.183 BRU: Ce0 LCP: Event[UP] State[Starting to REQsent]
3706643: Apr 1 08:51:23.191 BRU: Ce0 LCP: I CONFREQ [REQsent] id 7 len 25
3706644: Apr 1 08:51:23.191 BRU: Ce0 LCP:    ACCM 0x00000000 (0x020600000000)
3706645: Apr 1 08:51:23.191 BRU: Ce0 LCP:    AuthProto CHAP (0x0305C22305)
3706646: Apr 1 08:51:23.191 BRU: Ce0 LCP:    MagicNumber 0x813CA39C (0x0506813CA39C)
3706647: Apr 1 08:51:23.191 BRU: Ce0 LCP:    PFC (0x0702)
3706648: Apr 1 08:51:23.191 BRU: Ce0 LCP:    ACFC (0x0802)
3706649: Apr 1 08:51:23.191 BRU: Ce0 LCP: O CONFACK [REQsent] id 7 len 25
3706650: Apr 1 08:51:23.191 BRU: Ce0 LCP:    ACCM 0x00000000 (0x020600000000)
3706651: Apr 1 08:51:23.191 BRU: Ce0 LCP:    AuthProto CHAP (0x0305C22305)
3706652: Apr 1 08:51:23.191 BRU: Ce0 LCP:    MagicNumber 0x813CA39C (0x0506813CA39C)
3706653: Apr 1 08:51:23.191 BRU: Ce0 LCP:    PFC (0x0702)
3706654: Apr 1 08:51:23.191 BRU: Ce0 LCP:    ACFC (0x0802)
3706655: Apr 1 08:51:23.191 BRU: Ce0 LCP: Event[Receive ConfReq+] State[REQsent to ACKsent]
3706656: Apr 1 08:51:23.191 BRU: Ce0 LCP: I CONFACK [ACKsent] id 1 len 20
3706657: Apr 1 08:51:23.191 BRU: Ce0 LCP:    ACCM 0x000A0000 (0x0206000A0000)
3706658: Apr 1 08:51:23.191 BRU: Ce0 LCP:    MagicNumber 0xE74DCDE6 (0x0506E74DCDE6)
3706659: Apr 1 08:51:23.191 BRU: Ce0 LCP:    PFC (0x0702)
3706660: Apr 1 08:51:23.191 BRU: Ce0 LCP:    ACFC (0x0802)
3706661: Apr 1 08:51:23.191 BRU: Ce0 LCP: Event[Receive ConfAck] State[ACKsent to Open]
3706662: Apr 1 08:51:23.199 BRU: Ce0 PPP: Queue CHAP code[1] id[1]
3706663: Apr 1 08:51:23.211 BRU: Ce0 PPP: Phase is AUTHENTICATING, by the peer
3706664: Apr 1 08:51:23.211 BRU: Ce0 CHAP: Redirect packet to Ce0
3706665: Apr 1 08:51:23.211 BRU: Ce0 CHAP: I CHALLENGE id 1 len 35 from "UMTS_CHAP_SRVR"
3706666: Apr 1 08:51:23.211 BRU: Ce0 PPP: Sent CHAP SENDAUTH Request
3706667: Apr 1 08:51:23.211 BRU: Ce0 LCP: State is Open
3706668: Apr 1 08:51:23.211 BRU: Ce0 PPP: Received SENDAUTH Response FAIL
3706669: Apr 1 08:51:23.211 BRU: Ce0 CHAP: Using hostname from interface CHAP
3706670: Apr 1 08:51:23.211 BRU: Ce0 CHAP: Using password from interface CHAP
3706671: Apr 1 08:51:23.211 BRU: Ce0 CHAP: O RESPONSE id 1 len 41 from
3706672: Apr 1 08:51:23.219 BRU: Ce0 CHAP: I SUCCESS id 1 len 4
3706673: Apr 1 08:51:23.219 BRU: Ce0 PPP: Phase is FORWARDING, Attempting Forward
3706674: Apr 1 08:51:23.223 BRU: Ce0 PPP: Phase is ESTABLISHING, Finish LCP
3706675: Apr 1 08:51:23.223 BRU: Ce0 PPP: Phase is UP
3706676: Apr 1 08:51:23.223 BRU: Ce0 IPCP: Protocol configured, start CP. state[Initial]
3706677: Apr 1 08:51:23.223 BRU: Ce0 IPCP: Event[OPEN] State[Initial to Starting]
3706678: Apr 1 08:51:23.223 BRU: Ce0 IPCP: O CONFREQ [Starting] id 1 len 22
3706679: Apr 1 08:51:23.223 BRU: Ce0 IPCP:    Address 0.0.0.0 (0x030600000000)
3706680: Apr 1 08:51:23.223 BRU: Ce0 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
3706681: Apr 1 08:51:23.223 BRU: Ce0 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
3706682: Apr 1 08:51:23.223 BRU: Ce0 IPCP: Event[UP] State[Starting to REQsent]
3706683: Apr 1 08:51:23.227 BRU: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0, changed state to up
3706684: Apr 1 08:51:24.223 BRU: Ce0 IPCP: I CONFNAK [REQsent] id 1 len 16
3706685: Apr 1 08:51:24.223 BRU: Ce0 IPCP:    PrimaryDNS (0x81060A0B0C0D)
3706686: Apr 1 08:51:24.223 BRU: Ce0 IPCP:    SecondaryDNS (0x83060A0B0C0E)
3706687: Apr 1 08:51:24.223 BRU: Ce0 IPCP: O CONFREQ [REQsent] id 2 len 22
3706688: Apr 1 08:51:24.223 BRU: Ce0 IPCP:    Address 0.0.0.0 (0x030600000000)
3706689: Apr 1 08:51:24.227 BRU: Ce0 IPCP:    PrimaryDNS (0x81060A0B0C0D)
3706690: Apr 1 08:51:24.227 BRU: Ce0 IPCP:    SecondaryDNS (0x83060A0B0C0E)
3706691: Apr 1 08:51:24.227 BRU: Ce0 IPCP: Event[Receive ConfNak/Rej] State[REQsent to REQsent]
3706692: Apr 1 08:51:25.231 BRU: Ce0 IPCP: I CONFNAK [REQsent] id 2 len 16
3706693: Apr 1 08:51:25.231 BRU: Ce0 IPCP:    PrimaryDNS (0x81060A0B0C0D)
3706694: Apr 1 08:51:25.231 BRU: Ce0 IPCP:    SecondaryDNS (0x83060A0B0C0E)
3706695: Apr 1 08:51:25.231 BRU: Ce0 IPCP: O CONFREQ [REQsent] id 3 len 22
3706696: Apr 1 08:51:25.231 BRU: Ce0 IPCP:    Address 0.0.0.0 (0x030600000000)
3706697: Apr 1 08:51:25.231 BRU: Ce0 IPCP:    PrimaryDNS (0x81060A0B0C0D)
3706698: Apr 1 08:51:25.231 BRU: Ce0 IPCP:    SecondaryDNS (0x83060A0B0C0E)
3706699: Apr 1 08:51:25.231 BRU: Ce0 IPCP: Event[Receive ConfNak/Rej] State[REQsent to REQsent]
3706700: Apr 1 08:51:25.423 BRU: Ce0 IPCP: I CONFREQ [REQsent] id 2 len 4
3706701: Apr 1 08:51:25.423 BRU: Ce0 IPCP AUTHOR: Done. Her address 0.0.0.0, we want 0.0.0.0
3706702: Apr 1 08:51:25.423 BRU: Ce0 IPCP: O CONFACK [REQsent] id 2 len 4
3706703: Apr 1 08:51:25.427 BRU: Ce0 IPCP: Event[Receive ConfReq+] State[REQsent to ACKsent]
3706704: Apr 1 08:51:25.427 BRU: Ce0 IPCP: I CONFNAK [ACKsent] id 3 len 22
3706705: Apr 1 08:51:25.427 BRU: Ce0 IPCP:    Address (0x0306B2904FF3)
3706706: Apr 1 08:51:25.427 BRU: Ce0 IPCP:    PrimaryDNS (0x810651A93C6B)
3706707: Apr 1 08:51:25.427 BRU: Ce0 IPCP:    SecondaryDNS (0x830651A93C6B)
3706708: Apr 1 08:51:25.427 BRU: Ce0 IPCP: O CONFREQ [ACKsent] id 4 len 22
3706709: Apr 1 08:51:25.427 BRU: Ce0 IPCP:    Address (0x0306B2904FF3)
3706710: Apr 1 08:51:25.427 BRU: Ce0 IPCP:    PrimaryDNS (0x810651A93C6B)
3706711: Apr 1 08:51:25.427 BRU: Ce0 IPCP:    SecondaryDNS (0x830651A93C6B)
3706712: Apr 1 08:51:25.427 BRU: Ce0 IPCP: Event[Receive ConfNak/Rej] State[ACKsent to ACKsent]
3706713: Apr 1 08:51:25.443 BRU: Ce0 IPCP: I CONFACK [ACKsent] id 4 len 22
3706714: Apr 1 08:51:25.475 BRU: Ce0 IPCP:    Address (0x0306B2904FF3)
3706715: Apr 1 08:51:25.475 BRU: Ce0 IPCP:    PrimaryDNS (0x810651A93C6B)
3706716: Apr 1 08:51:25.475 BRU: Ce0 IPCP:    SecondaryDNS (0x830651A93C6B)
3706717: Apr 1 08:51:25.475 BRU: Ce0 IPCP: Event[Receive ConfAck] State[ACKsent to Open]
3706718: Apr 1 08:51:25.475 BRU: Ce0 IPCP: State is Open
3706719: Apr 1 08:51:25.475 BRU: Di1 IPCP: Install negotiated IP interface address
3706720: Apr 1 08:51:25.479 BRU: Ce0 DDR: dialer protocol up
3706721: Apr 1 08:51:25.479 BRU: Di1 DDR: Persistent Dialer Profile nailed up successfully
Cheers
Raj

Output errors and interface resets.

hi Netpros,
Any idea as to what could be causing output errors and interfece resets on the radio interfaces .. The output interpreter from Cisco does not show any information about the radio interfaces
please see this output after clearing the counters
Dot11Radio0 is up, line protocol is up
Hardware is 802.11G Radio, address is 0015.c7a8.3d90 (bia 0015.c7a8.3d90)
MTU 1500 bytes, BW 54000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:07, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/962/0 (size/max/drops/flushes); Total output drops: 181678
Queueing strategy: fifo
Output queue: 0/30 (size/max)
5 minute input rate 4000 bits/sec, 6 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
39213813 packets input, 3905641263 bytes, 0 no buffer
Received 53803 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
21236022 packets output, 3766719027 bytes, 0 underruns
11617 output errors, 0 collisions, 25 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Any input is much appreciated.

Let's take a look at what you're worried about: 11,617 output errors divided by 21,236,022 packets output = 0.05% loss. Not really much to worry about there.
As for the 25 interface resets, that's one reset for every 849,441 output packets. Again, nothing really to worry about, but one does wonder why those numbers are not zero.
So how about taking a closer look at the following line you reported:
Input queue: 0/75/962/0 (size/max/drops/flushes); Total output drops: 181678
Notice in particular the "Input queue drops = 962" and more importantly, the "Total output drops = 181,678". You can find detailed troubleshooting information about these problems at: http://www.cisco.com/warp/public/63/queue_drops.html to help you figure out what the actual problem is and whether or not it can be rectified by fine tuning your parameters.
FYI: Here is a standard definition of Output related errors: (taken from http://www-commeng.cso.uiuc.edu/uiucnet/reports/glossary.html )
Output Errors
- Output errors are the sum of all the output errors that occur on an interface.
Out Success With Retry Errors
- Out Success With Retry errors are output errors which indicate that a frame successfully transmitted after one or more collisions. Out Success With Retry Errors are the number of frames that experienced a a collision and retransmit before success. The total collisions divided by the number of Out Success With Retry errors will provide the average number of collisions per packet transmitted with collisions.
Out of Window Collisions Errors
- Out of Window Collisions are a type of output error. Out of window collision errors occur when a frame in the process of being transmitted collides with another frame. This error usually occurs either when some interface on the network fails to defer or the network has too many stations. (See Late Collisions.)
Output Discard Errors
- Output Discards are output errors that occur when the router has to throw a packet out instead of queuing it for transmission on the Ethernet. Output discard errors usually indicate that the network has more traffic than it can handle. They may also indicate a software discard such as no route to destination.
Output FIFO Overrun Errors
- FIFO Overruns are a type of output error. Output FIFO Overruns occur when the output queue in the adapter underflowed while putting a frame on the wire. This problem occurs when the interface is not receiving bits of the frame fast enough.
Walt

Can not connect with dhcp - renew dhcp lease will switch directly to manuel

If have the following problem
I us apple Airport extreme to connect to internet.
I have 5 Macs, all connecting with airport . They work fine with DHCP. Since 2 weeks I have a problem that one computer – a mac book pro with 10.5.6 will not connect.
When I switch to dhcp and select renew dhcp lease it switch directly back to manuell. I have no chance to connect with dhcp.
Has anyone a suggestion?
Thanks

Wonder why Apple hasn't chimed in on this one...
Whenever you have an issue like this where it's fine, then DHCP stops working for any reason.... Reset the PRAM.
How to:
Apple Logo -> Restart.
After the screen goes black -> Hold down all 4 keys until you hear the third Bong.
"Option"+[Apple Logo OR key to the left of the space bar]"P""R"
After the third BONG or Apple Chime whatever you want to call it. The system's Parameter Ram or to the PC Crowd the CMOS has been reset. This resets your clock, brightness, volume, etc.... So things will get reset along the way but it also resets the IRQ and DMA stats on the logic board. Ala, reseting your Airport's Connection to the logic board, Controllers, etc.

Cable Sub-Interface in VRF - DHCP Intermittent Problem

I've configured multiple VRF's to support third party access to our cable infrastructure.
Of the 15 CMTS' I have configured, all of them work fine except for one which happens to be a UBR10K running 12.2.15.BC1b. The other CMTS' (7200's and 7100's) are running fine with an older IOS revision but I need the latest IOS on the 10K to support VLAN sub-interfaces.
The problem is occasionally, DHCP clients will obtain an IP address/netmask from within the proper VRF subnet, but the client is unreachable from the CMTS.
If we disable the IP address in question from CNR and have the client renew their IP, service is restored.
This is a big problem. Even though this only happens occasionally, when you have 8000+ users on a CMTS, 'occasionally' still works out to quite a few problem calls.
Sub-interfaces set up to use static IP addressing on the client experience no problems.
Any advice would be appreciated.
= K

More information may be require to understand the problem, mean while you can go through link :
http://www.cisco.com/en/US/netsol/ns341/ns396/ns172/ns126/networking_solutions_design_guide_chapter09186a00800eeee8.html

DHCP Renew Issue with Road Runner

I have had Road Runner for 6 weeks, the first four weeks everything was running smoothly. However, for the last two weeks the connection has been sporadic and I am constantly losing my connection.
My computer is connected directly to the modem with an ethernet cable; there is no router, there are no other computers. I'm simply trying to stay online with my little computer.
My network settings are for built-in ethernet, using DHCP, with the addresses provided by my ISP (Road Runner) and I've added two DNS server addresses for Road Runner (because several other discussions, posts, etc. recommended using those to help stay connected). I've tried turning my IPv6 off, I've tried manually configuring my DHCP connection, I've scoured the internet for help. All to no avail. Most topics deal with networking with PC's or airports and I have neither attached to this computer. I've created new locations to try and "erase" any default settings and I've kicked the modem a few times (accidentally I assure you ).
From what I can tell, (keep in mind I sell trees and know nothing about this) the DHCP lease does not renew when it's supposed to. I am disconnected every half hour or so, or I have to press "renew" to be able to stay online (highly annoying).
When I first subscribed to Road Runner the connection was fine and I was able to stay online indefinitely. Two weeks ago that changed, even though I did nothing (intentionally) to change network settings. This means I downloaded nothing that would affect my network configuration, I didn't poke around in network configurations, I did not change any settings. I've spoken with their online "tech" support four times. I've spoken to three people on the phone and I've had a tech come out to replace my modem and ethernet cable. When the problem persisted I contacted them again and was told the problem was with Apple <gasp>.
I believe I need help in finding a way to have my mac recognize changes in DHCP and to renew the lease automatically, for all I know it could be that the moon isn't aligned with Saturn <shrug>...preferably in vernacular I can understand. Thank you in advance for any help!
Lori

Hi Lori,
You're not really in the right forum for your problem (this area is for Apple-server) but I'll give it a go...
First, short explanation on DHCP. This process is pretty straightforward for the client's function so I'm suspicious of the "blame the mac" conclusion from Road Runner (although does not exclude possibility). When the mac starts up, it issues a 'Discovery' broadcast, looking for a DHCP server. The server responds with an 'Offer' of an IP address. The client then responds with a 'Request' to the server for the same IP address and the server then sends an 'Acknowledgement' that it may use this address, along with other information including the 'Lease Time' - how long the client may continue to use that info.
The lease time is important. After 50% of this time has gone, the client will attempt to renew it from the same server by issuing another Request and awaiting another Acknowledgement. Should there be no Acknowledgement, the client will continue to issue Requests up until the expiry of the original lease time at which point it will drop all the info which it received from the server and then issue another Offer broadcast, looking for a new server (which may or may not be available).
So, first thing, lets see what lease time you are getting from Road Runner and see if this corresponds with the 30 minutes you seem to get from a session...
Ensure you have a cable connection to your router, restart computer. In Applications-> Utilities, start up Terminal. Enter the following line, ending with normal 'return' key (new line)...
ipconfig getpacket en0
That's a zero at the end.
Look for the line similar to this, "lease_time (uint32): 0x1bd8", and post back the string of chars you get at the end of your line (corresponding to the "0x1bd8" part). Quit the Terminal utility.
Can you also confirm what computer model you use, and the system version?
-david
Server 10.4.8

Auto DHCP renew when tracking change state

I looking to find a way to do a shut and no shut until the tracking change state. For spoke router using a DHCP connection to the Internet. When there is a problem with the connection, the modem will give a private ip adresse and by just doing a shut and then a no shut it fix the issue but I would like to do it automaticaly. I have already tried with a event manager applet but when the tracking change state it will execute only the commands only once but I would like it to do it every 10 minutes until the tracking change state again. Maybe with tcl script but don't realy know where to start.

You can do what you want using three applets (two top-level applets, and one nested applet).
event manager environment quote "event manager applet track-down event track 1 state down action 001 cli command "enable" action 002 cli command "config t" action 003 cli command "event manager applet track-timer" action 004 cli command "event timer watchdog time 180 name track_timer" action 005 cli command "action 1.0 cli command enable" action 006 cli command "action 2.0 cli command $quote config t$quote" action 007 cli command "action 3.0 cli command $quote interface Fa0/0$quote" action 008 cli command "action 4.0 cli command shut" action 009 cli command "action 5.0 cli command $quote no shut$quote" action 010 cli command "action 6.0 cli command end"event manager applet track-up event track 1 state up action 1.0 cli command "enable" action 2.0 cli command "config t" action 3.0 cli command "no event manager applet track-timer" action 4.0 cli command "end"
The above config will periodically shut/no shut interface Fa0/0 every three minutes until the tracked object comes back up.

Default interface reset issue after ISE configuration

Hi,
We're testing VOIP phones with ISE. ISE detects the phones by MAB and places them in our Voice VLAN with a DACL for security, this works fine.
After the tests I configured the port to a non ISE port (default interface) and added the normal working configuration.
Result is that the IP phone doesn't get an IP address. If I plug the same phone on a different interface on the same switch it's working again.
I have no idea why this strange behavior occurs, maybe someone can help me out.
Thanks, Michael

A reboot solves the problem temporary, so it looks like the running switch holds back some old configuration until a reboot

Interfaces reset when disable signature.

Hi Guys.
When i ingress the next script in order to disable signature, the interfaces of the Ips cisco 4240 are restart, someone have any clue is so extrange just for disabling an signature?
config term
service signature-definition sig0
signatures 9202 0
status
enabled false
exit
exit
Aug 13 23:59:35.229: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/25, changed state to up
Aug 13 23:59:35.280: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/26, changed state to up
GigabitEthernet1/0/25 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is e8b7.4843.b099 (bia e8b7.4843.b099)
Description: **** IPS-A ****
GigabitEthernet1/0/26 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is e8b7.4843.b09a (bia e8b7.4843.b09a)
Description: **** IPS-B ****
Tahnk you.

Hi.
At this moment i just try to do that to disable the signature.
! Current configuration last modified Tue Aug 13 18:02:59 2013
! Version 7.0(5a)
! Host:
!     Realm Keys          key1.0
! Signature Definition:
!     Signature Update    S609.0   2011-11-11
service interface
physical-interfaces GigabitEthernet0/0
admin-state enabled
duplex full
speed 1000
subinterface-type inline-vlan-pair
subinterface 1
vlan1 10
vlan2 11
exit
exit
exit
physical-interfaces GigabitEthernet0/1
admin-state enabled
duplex full
speed 1000
subinterface-type inline-vlan-pair
subinterface 1
vlan1 10
vlan2 11
exit
exit
exit
bypass-mode off
exit

802.11b/g interface reset periodically on same AP

Hi;
We use wlc4404 with 1242ag AP series.
Only on two AP which located remote site, (we have dedicated 20 mbit metro ethernet line between main site and remote site) periodically we get these logs. meanwhile clients is reconnect of course
'802.11b/g' interface of AP 'IST_TEM_3' associated to controller 'WLC4404-1 (10.50.1.4)' is down. Reason: Radio channel set.
'802.11b/g' interface of AP 'IST_TEM_3' associated to controller 'WLC4404-1 (10.50.1.4)' is up. Reason: Radio channel set.
'802.11b/g' interface of AP 'IST_TEM_3' associated to controller 'WLC4404-1 (10.50.1.4)' is down. Reason: Rogue Location Discovery Protocol start.
'802.11b/g' interface of AP 'IST_TEM_3' associated to controller 'WLC4404-1 (10.50.1.4)' is up. Reason: Rogue Location Discovery Protocol stop.
what do you suggest to solve this issue ?
Best regards
Umut

7.0.250.0
AP ios : 12.4(23c)JA8

SFE2000P - Interface reset on DHCP renew?

Similar Messages

Maybe you are looking for