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.
Similar Messages
-
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 -
i have a cisco access point like air-1230b-a-k9
in this ap ios was curropted.when i tried it was successfully load the ios via xmodem. but when i boot it from flash it showing that firmware for dot11radio 0 is not found.image 5001 is not found. what i have to do with this problemsYou can view a list of the contents of a file system before manipulating its contents.
For example, before copying a new configuration file to Flash memory, you might want to verify
that the file system you can use this command
show file system - display Display more information about each of the files on a file system -
Aironet 1300 radio keeps on shutting down
Hi,
I have a problem with the wireless bridge connection using aironet 1300. It work fine before.no changes were done. The problem is that the radio keeps on shutting down.in the web interface radio is enabled but down. i have to manually diable it then enable it back to resolve the issue. Problem is random and this is happening on both aironet. Below is the log.
on the first aironet:
1 Mar 31 02:20:59.444 Error Interface Dot11Radio0, changed state to up
2 Mar 31 02:20:59.443 Warning Interface Dot11Radio0, Associated To AP UPAdminBridge 001e.4a05.b820 [None]
3 Mar 31 02:20:59.389 Error Interface Dot11Radio0, changed state to down
4 Mar 31 02:20:59.339 Warning Interface Dot11Radio0, parent lost: Received deauthenticate (2) not valid
5 Mar 31 01:24:51.062 Error Interface Dot11Radio0, changed state to up
6 Mar 31 01:24:51.061 Warning Interface Dot11Radio0, Associated To AP UPAdminBridge 001e.4a05.b820 [None]
on the second aironet:
1 Mar 17 09:30:42.107 Information Interface Dot11Radio0, Station UP-ASBridge 001e.f7f1.abc0 Reassociated KEY_MGMT[NONE]
2 Mar 17 09:30:41.971 Information Interface Dot11Radio0, Deauthenticating Station 001e.f7f1.abc0 Reason: Previous authentication no longer valid
3 Mar 17 09:30:41.971 Warning Packet to client 001e.f7f1.abc0 reached max retries, removing the client
regards,
ChristianVerify that when the radio interface is shutdown, the workstations can connect to the server immediately. Also ping from the AP to server and workstations to verify if there is any difference seen to the results seen prior to the radio interface being shut down.
-
CAP1602i Dot11 radio status stuck on reset.
Hello all,
I'm using a 7500 wlc running 7.4.100.60 with cisco CAP1602i and the show ip int brief is as follows:
BVI1 192.168.26.111 YES DHCP up up
Dot11Radio0 unassigned NO unset reset down
Dot11Radio0.1 unassigned YES unset reset down
Dot11Radio0.2 unassigned YES unset reset down
Dot11Radio0.17 unassigned YES unset reset down
Dot11Radio0.18 unassigned YES unset reset down
Dot11Radio1 unassigned NO unset reset down
Dot11Radio1.1 unassigned YES unset reset down
Dot11Radio1.2 unassigned YES unset reset down
Dot11Radio1.17 unassigned YES unset reset down
Dot11Radio1.18 unassigned YES unset reset down
GigabitEthernet0 unassigned NO unset up up
GigabitEthernet0.1 unassigned YES unset up up
Log for the AP is as follows:
*Mar 1 00:00:12.011: %SOAP_FIPS-2-SELF_TEST_IOS_SUCCESS: IOS crypto FIPS self test passed
*Mar 1 00:00:14.435: %SOAP_FIPS-2-SELF_TEST_RAD_SUCCESS: RADIO crypto FIPS self test passed on interface Dot11Radio 0
*Mar 1 00:00:14.559: %LINK-6-UPDOWN: Interface GigabitEthernet0, changed state to up
*Mar 1 00:00:15.551: %SOAP_FIPS-2-SELF_TEST_RAD_SUCCESS: RADIO crypto FIPS self test passed on interface Dot11Radio 1
*Mar 1 00:00:18.291: %SYS-5-RESTART: System restarted --
Cisco IOS Software, C1600 Software (AP1G2-K9W8-M), Version 15.2(2)JB1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Tue 07-May-13 09:37 by prod_rel_team
*Mar 1 00:00:18.291: %SNMP-5-COLDSTART: SNMP agent on host CFMLAP0102 is undergoing a cold start
*Mar 1 00:00:18.331: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
*Mar 1 00:00:18.331: %LINK-5-CHANGED: Interface Dot11Radio1, changed state to reset
*Mar 1 00:00:18.419: Starting Ethernet promiscuous mode
*Mar 1 00:00:18.627: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0, changed state to up
*Mar 1 00:00:19.451: %LINEPROTO-5-UPDOWN: Line protocol on Interface BVI1, changed state to up
*Mar 1 00:00:21.715: %SSH-5-ENABLED: SSH 2.0 has been enabledlwapp_crypto_init: MIC Present and Parsed Successfully
*Mar 1 00:00:47.115: Logging LWAPP message to 255.255.255.255.
*Mar 1 00:00:53.899: %LWAPP-3-LWAPP_INTERFACE_GOT_IP_ADDRESS: Interface BVI1 obtained IP from DHCP...
*Mar 1 00:00:54.019: %DHCP-6-ADDRESS_ASSIGN: Interface BVI1 assigned DHCP address 192.168.26.111, mask 255.255.255.0, hostname CFMLAP0102
*Mar 1 00:00:54.019: %LWAPP-3-LWAPP_INTERFACE_GOT_IP_ADDRESS: Interface BVI1 obtained IP from DHCP...
*Mar 1 00:01:03.899: %CAPWAP-5-DHCP_OPTION_43: Controller address 192.189.37.130 obtained through DHCP
*Mar 1 00:01:03.899: %CAPWAP-3-ERRORLOG: Did not get log server settings from DHCP.
*Mar 1 00:01:03.927: %CAPWAP-3-ERRORLOG: Could Not resolve CISCO-CAPWAP-CONTROLLER
*Mar 1 00:01:13.927: %CAPWAP-3-ERRORLOG: Go join a capwap controller
*Apr 17 23:11:35.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 192.189.37.130 peer_port: 5246
*Apr 17 23:11:35.323: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 192.189.37.130 peer_port: 5246
*Apr 17 23:11:35.327: %CAPWAP-5-SENDJOIN: sending Join Request to 192.189.37.130
*Apr 17 23:11:40.323: %CAPWAP-5-SENDJOIN: sending Join Request to 192.189.37.130
*Apr 17 23:11:40.423: Starting Ethernet promiscuous mode
*Apr 17 23:11:42.443: ac_first_hop_mac - IP:192.168.26.3 Hop IP:192.168.26.3 IDB:BVI1
*Apr 17 23:11:42.443: Setting AC first hop MAC: ccef.48fa.7a14
*Apr 17 23:11:42.959: %LWAPP-4-CLIENTEVENTLOG: OfficeExtend Localssid saved in AP flash
*Apr 17 23:11:43.459: %CAPWAP-5-JOINEDCONTROLLER: AP has joined controller Burnaby-WifiController0
*Apr 17 23:11:43.503: %LWAPP-4-CLIENTEVENTLOG: No Flex ACL map configuration file to load. Connect to controller to get configuration file
*Apr 17 23:11:43.503: %LWAPP-4-CLIENTEVENTLOG: No Flex ACL map configuration file to load. Connect to controller to get configuration file
*Apr 17 23:11:43.503: %LWAPP-4-CLIENTEVENTLOG: No LS Flex ACL map configuration file to load. Connect to controller to get configuration file
*Apr 17 23:11:43.503: %LWAPP-4-CLIENTEVENTLOG: No Central Dhcp map configuration file to load. Connect to controller to get configuration file
*Apr 17 23:11:45.147: %WIDS-6-ENABLED: IDS Signature is loaded and enabled
I can't seem to figure out why the lines that appear on other APs arent showing up on this particular one. Normally the AP after the IDS signature it'll show the following :
*Apr 17 22:09:43.043: %CDP_PD-4-POWER_OK: Full power - NON_CISCO-NO_CDP_RECEIVED inline power source
*Apr 17 22:09:44.115: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to up
*Apr 17 22:09:45.115: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up
*Apr 17 22:09:45.171: %DOT11-6-DFS_SCAN_START: DFS: Scanning frequency 5280 MHz for 60 seconds.
*Apr 17 22:09:45.175: %LINK-6-UPDOWN: Interface Dot11Radio1, changed state to up
*Apr 17 22:09:45.183: %LINK-6-UPDOWN: Interface Dot11Radio1, changed state to down
*Apr 17 22:09:45.191: %LINK-5-CHANGED: Interface Dot11Radio1, changed state to reset
*Apr 17 22:09:46.223: %DOT11-6-DFS_SCAN_START: DFS: Scanning frequency 5280 MHz for 60 seconds.
*Apr 17 22:09:46.227: %LINK-6-UPDOWN: Interface Dot11Radio1, changed state to up
*Apr 17 22:09:47.227: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio1, changed state to up
*Apr 17 22:10:46.283: %DOT11-6-DFS_SCAN_COMPLETE: DFS scan complete on frequency 5280 MHzI changed the role in the network to Root node on this brodge and the radio interfaces came up, but this device stopped talking to other network.
There is similar 1310 bridge set up in such a dierction so that it can talk to this bridge, but this is not pinging from the rest of the network.
One Small ESW-520-8P switch is connected to this 1310 bridge but the switch can be pinged from the bridge.
Does that mean it is faulty or antenna problem...
Regards,
Rachna -
Autonomous 1142 AP shuts down 2.4 radio interface
As we transition buildings to our lightweight infrastructure we're installing new autonomous 1142 APs to fill in gaps and swapping out older 1242s with autonomous 1142s. What we're seeing is that some of these APs, running the latest IOS code available, are shutting down their 2.4 GHz radios. The only thing in the logs is:
%LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
%LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
The only residual elements that are found (most times) is on the client association page where we'll see what amounts to stale client sessions. There are two flavors of such stale sessions. Associations to open networks show clients with IP addresses of 0.0.0.0, the MAC addresses are still listed, and the state is "Associated". For 802.1x based associations clients show their assigned IP addresses, MAC addresses, and the state appears as "EAP-Associated".
I was looking at some of the open caveats with IOS release 12.4(21a)JY to see if anything matched up with the problem I’m seeing. In the bug toolkit, bug CSCtg09159 (might be related to our problem?) is stated as being “Fixed-in” release 12.4(21a)JHB.
Anyone seen the problem we're seeing? Anyone know when 12.4(21a)JHB is scheduled for release?I'm glad to see that I'm not going crazy.
%LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
I have had what seems to be the same issue with my 1142N (autonomous; no controller). It will work for a day or so and then all of a sudden the radio(s) will go down (e.g., be disabled). For example, when I came back to the site Radio0-802.11N2.4GHz was disabled while Radio1-802.11N5GHz was enabled. Devices were able to connect to the AP an hour earlier can now no longer find the AP. When this happens the LED on the AP will usually remain light blue which implies, I believe, a connection which is odd considering there are none when this occurs.
I won't be able to reconnect to the 1142N until I reset the AP. Usually I have to pull the power (POE through Cisco injector) to achieve this as issuing a reset from the web management page does not always work.
Product/Model Number:
AIR-LAP1142N-A-K9
System Software Filename:
c1140-k9w7-tar.124-21a.JY
System Software Version:
12.4(21a)JY
Bootloader Version:
12.4(18a)JA3
Note: "channel least-congested" was enabled by default and is currently enabled.
I've read that the AP can shut down radio(s) based on power but I don't see any power messages in the log. Under System Power Settings of the web management page it reports NON_CISCO-NO_CDP_RECEIVED but the radio(s) work fine for at least a day when the AP is reset. I'm currently using a Cisco AIR-PWRINJ4 injector and I've also tried using the POE port on a Cisco ASA5505. Same issue.
I've had a pending SR with Cisco TAC for over a month and have made it no where fast. I've sent them logs with show controllers d0, show controllers d1, show log and show tech per their request. Having to manually reset my AP every other day is ridiculous! -
Cisco 1142AP Autonomous - Radio interface constantly reset and provides crash file
Hello All,
We have 10 Cisco 1142 Access Points currently configured as Autonomous and I'm experiecing very unusual behavior with the 2.4GHz radio interfaces on each of them. The IOS firmware is 15.2.2JB and they're connected to Cisco 2960 PoE switches. I'm not sure what could be causing this problem however it is service impacting and looks bad on me since I don't have a solution for it. One potential fix could be to upgrade the firmware to 15.2.4 but I'm sure if it is a firmware problem. Any advice would help. Here's an excerpt from the AP log:
Aug 18 14:40:16: Writing driver stats to flash:/ap_log_r0_0.log..
Aug 18 14:40:21:
Aug 18 14:40:21: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
Aug 18 14:40:22: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
Aug 18 14:40:23: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to up
Aug 18 14:40:23: %LINK-6-UPDOWN: Interface Dot11Radio0, changed state to down
Thanks,
Ali IbrahimYou should be able to go in and view teh R0_0.log file.
there might be something in there that you can do a bug search for.
HTH,
Steve -
Cisco Wireless AP radio interface shutdown/Operation Status Down
Hi,
I am trying to troubleshoot the cause of the wireless AP 1142 radio shutdown; I was wondering where may be a good place to start on it/possibility of the radio shutting down. Once the radio is shown as down; I would just need to re-enable (disable/enable) it and the status changes to up status. I have attached a screen catpure of the radio interface showning down.
The AP radios shutting down is intermittent; some APs has their "A/N" radio interface shutdown while others has their "G/N" radio interface shutdown. Not too sure what may most likely be causing it to shutdown?
Any input is appreciated.
Thanks.Do you have controller ?? if yes then posts out put of sh sysinfo commad.
Paste the output of sh version command from AP.
Also check:
1. Choose Wireless > 802.11a/n or 802.11b/g/n > Network
Select the 802.11a (or 802.11b/g) Network Status check box to enable the 802.11a or 802.11b/g band.
2. Wireless > Access Points > All APs then click on specific AP and make sure admin status is enable.
Reagrds -
Spotify Now Playing out of sync with Radio Interface / Unable to Thumbs Up-Down current song
So this is probably happened 10 or more times and I finally got annoyed enough to record my screen to show it happening. What happens is I will be listening to a song on a spotify radio station (I pay for premium) and decide I don't like it and open up the Spotify UI to thumbs it down. However when I click on the "Radio" sidebar option it won't show the song that is playing even though I KNOW it's playing from the radio. Even worse if I try to advance the track the track it says it's playing in the Radio interface DOES NOT match "Now Playing" in the bottom corner of the UI OR the OS X Notifications. This video only shows the notifications because I didn't want to have to expose more friends names or more private playlists (and radio station) names but the Now Playing matches the OS X Notification. VIDEO PS: Clicking "New Message" while logged out gives you some crypitc message about not having your email verified? WTF? VIDEO PPS: The "Autosaved at XX:XX XX" message above this text box I'm typing in that pops in and out very often is VERY **bleep**ING ANNOYING. Do it below, off to the side, or silently.. good god... VIDEO PPPS: Ok, **bleep** you spotify https://s.joshstrange.com/DoId.png I'll post dropbox links... Way to wait until after uploading them to do any checking...
This is a deeper issue than just that. Queueing songs remotely doesn't work right, just try itRunning radio remotely doesn't allow you to thumbs up tracks because it always displays an off-by-one track (I have to VNC to my mac, where the actual playback is happening)Different parts of the interface (when connected remotely) sometimes display the right information, but none of it is actionable (for example, I'd like to thumbs-up tracks, and thumbs-down tracks from my phone or spotify client on my laptop). This kind of makes creating a good radio station using connect impossible.Connect isn't ready for prime time. It's nice to have, but if I have to connect to the screen of the actual player, it defeats the entire purpose. I don't want a VNC connection open all the time.
-
Aironet C1140 - Radio Interface Keeps in Reset State
Hello,
Recently we noticed that one of our C1142 access points has a radio interface (actually is only happening with the one working in BG, so its dot11radio 0) which is entering in reset state and doesn't leave that state. I've seen an older thread about similar (or equal?) issue but was on a different AP model (C1240 if I remember correctly).
The radio interface controller information displays in the end a reset code:
Last radio reset code: 06
Radio resets - total:1 retries:0 failed:0
Code/Count: 06/00001
Although I was not able to find any information about this reset code in Cisco documents (maybe someone knows where I find it?).
If I try to restart the interface via "shutdown" configuration command it doesn't fix the problem, the workaround that I know of is only by "reload"ing the whole accesspoint.
Of course while in reset state no client can associate to this interface....
Did anyone had similar problem? is there any documented BUG related to this?
Thanks for your time,
Jean-François Mousinho
PS: firmware version is 12.4(21a)JA1.version information:
Cisco IOS Software, C1140 Software (C1140-K9W7-M), Version 12.4(21a)JA1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Wed 16-Sep-09 18:09 by prod_rel_team
ROM: Bootstrap program is C1140 boot loader
BOOTLDR: C1140 Boot Loader (C1140-BOOT-M) Version 12.4(18a)JA3, RELEASE SOFTWARE (fc1)
TS_Piso8_SulEsq uptime is 3 days, 1 hour, 16 minutes
System returned to ROM by reload
System restarted at 10:47:38 Z Tue Sep 14 2010
System image file is "flash:/c1140-k9w7-mx.124-21a.JA1/c1140-k9w7-mx.124-21a.JA1"
This product contains cryptographic features and is subject to United...
cisco AIR-AP1142N-E-K9 (PowerPC405ex) processor (revision B0) with 98294K/32768K bytes of memory.
Processor board ID FCZ1426W04V
PowerPC405ex CPU at 586Mhz, revision number 0x147E
Last reset from reload
1 Gigabit Ethernet interface
2 802.11 Radio(s)
32K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address: C8:4C:75:AE:8A:CC
Part Number : 73-11451-08
PCA Assembly Number : 800-30554-06
PCA Revision Number : A0
PCB Serial Number : FOC14233KEB
Top Assembly Part Number : 800-31273-04
Top Assembly Serial Number : FCZ1426W04V
Top Revision Number : A0
Product/Model Number : AIR-AP1142N-E-K9
Configuration register is 0xF
TS_Piso8_SulEsq#sh inventory
NAME: "AP1140", DESCR: "Cisco Aironet 1140 Series (IEEE 802.11n) Access Point"
PID: AIR-AP1142N-E-K9 , VID: V03, SN: FCZ1426W04V
Country is Portugal.
Thanks for your time.
Jean-François Mousinho -
Intermittant radio interface down on 1130 APs
I am having unified wireless installation, with WiSM on 6500 at central site and around 90 nos of 1130 APs located at remote locations ( over WAN) as well as some APs locate in the same location.
The APs are configured in WCS, using default AP template.
Alsomot all APs are showing minor alarms saying " radio interface threshold violated".
In addition, a major alarm posted frequently on WCS saying "radion interface down".
Cleints are complaining that they are loosing connectkion momentarily but connected again automatically wo WLAN. But they will have to log in to application programs in such cases.
a.Does anybody have similar experience, and
b. What are the best settings for 1130 APs trhat we have to do explicitly in setting up the WCS template ?
Thanks ,Might be due to interference and the fact that RRM is enalbled and the ap's are changing channels causing the radios to shut down temporarily. Either set the channel or try to change the threshold.
Here is the error info:
http://www.cisco.com/en/US/docs/wireless/wcs/4.2/configuration/guide/wcsevent.html#wp1139158 -
WLC 5508 APs showing Line Protocol Down
I have a WLC 5508 (software version 7.5.102.0) and it has 175 APS (mixture of 1131, 1142, 1602, 2602). Recently I've noticed that
about 40 of those APs don't work on the 2.4G Dot11Radio0. sh int dot11 0 shows me:
Dot11Radio0 is up, line protocol is down
Hardware is 802.11N 2.4GHz Radio, address is 1833.9d0c.2180 (bia 1833.9d0c.2180)
MTU 1500 bytes, BW 54000 Kbit/sec, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/9355/42086/0 (size/max/drops/flushes); Total output drops: 3769399
Queueing strategy: fifo
Output queue: 0/30 (size/max)
5 minute input rate 11000 bits/sec, 13 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
150800958 packets input, 597188558 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 input packets with dribble condition detected
217132697 packets output, 1132963042 bytes, 0 underruns
55238 output errors, 0 collisions, 8 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
I've tried restarting the interface,to no avail, but rebooting the whole AP does bring it back up, but I expect that's a solution to the symptom, not the problem.Hi Sean,
There are certain related bugs of this version. You may need to check whether you are hitting one these. I would suggest staying in 7.4.121.0 code would be a good idea unless you require new features available in 7.5 or 7.6.
CSCui66891:Marvell-based radio goes down due to stuck multicast packets in driverSymptom:AP's radio interface goes down and does not recover on its own without an AP reboot.Conditions:With releases 7.2.103.0 - 7.2.115.2, 7.3.101.0 - 7.3.112.0, and 7.4.100.0 - 7.4.110.0, this bug applies to all Marvell-based 802.11n Cisco Aironet access points *except* the 1140, 1040, and certain mesh APs.With releases 7.5.90.0 - 7.5.102.0, this bug applies to *all* Marvell-based 802.11n Cisco Aironet access points.Workaround:None. Reboot the AP.
Known Affected Releases(6)7.6(1.52)7.6(1.50)7.5(102.0)7.6(1.226)7.6(1.95)15.2(4)JA
Known Fixed Releases(10)10.1(0.74)7.6(1.55)7.5(102.8)10.1(100.0)15.2(4)JN7.6(1.103)10.1(11.5)7.4(111.7)15.2(4)JB7.4(121.0)
CSCum14069: AP1600/2600 radio down with 7.5.102.0 release Symptom:[AIR-CAP1602I-Q-K9 (AC power supply) ]---------[Catalyst switch]------------[AIR-CT5508-K9 (7.5.102.0)][AIR-CAP1602I-Q-K9 (PoE) ]----[AIR-PWRINJ5=]-----[ Catalyst switch]------------[AIR-CT5508-K9 (7.5.102.0)][AIR-CAP1602I-Q-K9 (AC power supply) ]---------[non-Cisco non-PoE switch]------------[AIR-CT5508-K9 (7.5.102.0)]AP1600/2600 radios never go UP on above topology if the Catalyst switch was running older IOS such as c3750-ipservices-mz.122-25.SEB4
Conditions:WLC release 7.5.102.0 specific issue.AP1600/2600 specific issue.Older Catalyst IOS software (e.g. 12.2(25)SEB4)non-Cisco 3rd party switch
Workaround:Enable "Pre-standard 802.3af switches" option on AP from WLC GUI;WIRELESS => Access Points => All APs => target AP name => Advanced tab => Power Over Ethernet SettingsThis option is required to workaround this problem even if you don't have Pre-standard 802.3af switch nor you're using AC adapter/Power Injector.
Known Affected Releases:(1)7.5(102.0)Known Fixed Releases:(1)7.5(102.18)
HTH
Rasika
**** Pls rate all useful responses ***** -
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 = 3Hi 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 -
Nexus 5000 - Odd Ethernet interface behavior (link down inactive)
Hi Guys,
This would sound really trivial but it is very odd behavior.
- We have a server connected to a 2, Nexus 5000s (for resiliancy)
- When there is no config on the ethernet interfaces whatsoever, the ethernet interface is UP / UP, there is minimal amount of traffic on the link etc. E.g.
Ethernet1/16 is up
Hardware: 1000/10000 Ethernet, address: 000d.ece7.85d7 (bia 000d.ece7.85d7)
Description: shipley-p1.its RK14/A13
MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
Port mode is access
full-duplex, 10 Gb/s, media type is 1/10g
Beacon is turned off
Input flow-control is off, output flow-control is off
Rate mode is dedicated
Switchport monitor is off
Last link flapped 00:00:07
Last clearing of "show interface" counters 05:42:32
30 seconds input rate 0 bits/sec, 0 packets/sec
30 seconds output rate 96 bits/sec, 0 packets/sec
Load-Interval #2: 5 minute (300 seconds)
input rate 0 bps, 0 pps; output rate 8 bps, 0 pps
RX
0 unicast packets 0 multicast packets 0 broadcast packets
0 input packets 0 bytes
0 jumbo packets 0 storm suppression packets
0 runts 0 giants 0 CRC 0 no buffer
0 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
TX
0 unicast packets 163 multicast packets 0 broadcast packets
163 output packets 15883 bytes
0 jumbo packets
0 output errors 0 collision 0 deferred 0 late collision
0 lost carrier 0 no carrier 0 babble
0 Tx pause
1 interface resets
- As soon as I configure the link to be an access port, the link goes down, flagging "inactivity" E.g.
sh int e1/16
Ethernet1/16 is down (inactive)
Hardware: 1000/10000 Ethernet, address: 000d.ece7.85d7 (bia 000d.ece7.85d7)
Description: shipley-p1.its RK14/A13
MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA
Port mode is access
auto-duplex, 10 Gb/s, media type is 1/10g
Beacon is turned off
Input flow-control is off, output flow-control is off
Rate mode is dedicated
Switchport monitor is off
Last link flapped 05:38:03
Last clearing of "show interface" counters 05:41:33
30 seconds input rate 0 bits/sec, 0 packets/sec
30 seconds output rate 0 bits/sec, 0 packets/sec
Load-Interval #2: 5 minute (300 seconds)
input rate 0 bps, 0 pps; output rate 0 bps, 0 pps
RX
0 unicast packets 0 multicast packets 0 broadcast packets
0 input packets 0 bytes
0 jumbo packets 0 storm suppression packets
0 runts 0 giants 0 CRC 0 no buffer
0 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 0 input discard
0 Rx pause
TX
0 unicast packets 146 multicast packets 0 broadcast packets
146 output packets 13083 bytes
0 jumbo packets
0 output errors 0 collision 0 deferred 0 late collision
0 lost carrier 0 no carrier 0 babble
0 Tx pause
0 interface resets
- This behavior is seen on both 5Ks
- I've tried using a different set of ports, changed SFPs, and fibre cabling to no avail
- I can't seem to understand this behavior?! In that, why would configuring the port cause the link to go down?
- If anyone has experience this before, or could shed some light on this behavior, it would be appreciated.
sh ver
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2010, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
Software
BIOS: version 1.2.0
loader: version N/A
kickstart: version 4.2(1)N1(1)
system: version 4.2(1)N1(1)
power-seq: version v1.2
BIOS compile time: 06/19/08
kickstart image file is: bootflash:/n5000-uk9-kickstart.4.2.1.N1.1.bin
kickstart compile time: 4/29/2010 19:00:00 [04/30/2010 02:38:04]
system image file is: bootflash:/n5000-uk9.4.2.1.N1.1.bin
system compile time: 4/29/2010 19:00:00 [04/30/2010 03:51:47]
thanks
SheldonI had identical issue
Two interfaces on two different FEXes were INACTIVE. I have two Nexus 5596 in vPC and A/A FEXes.
I also use config-sync feature.
Very same configuration was applied to other ports on other FEXes and they were working with no problems.
interface Ethernet119/1/1
inherit port-profile PP-Exchange2003
I checked VLAN status associated with this profile and it was active (of course it was, other ports were ok).
I solved it by removing port profile from this port and re-applied it... voila, port changed state to up!
Very very strange.
Maybe you are looking for
-
Iscsi support in solaris express 03/05
Hi To whom it may concern .. # uname -a SunOS tinkywinky 5.10.1 snv_07 sun4u sparc SUNW,Sun-Blade-100 # iscsiadm Usage: iscsiadm -?,-V Usage: iscsiadm add [-?] <OBJECT> [-?] [<OPERAND>] Usage: iscsiadm list [-?] <OBJECT> [-?] [<OPERAND>] Usage: iscsi
-
Timer not expired while running process
Dear All I'm using timer to blink the text message in 6i forms.Its working fine. But the problem is while running process timer not expired. If there is any solution to expire timer while running process, please let me know Thanking you
-
Page layouts for books in i photo 11
I'm making a book in i photo 11. I chose a page layout but when I drop in photos it automatically switches to a different layout and/or number of photos per page. I've made several other books and don't remember this happeneing. Does anyone know wh
-
Blackberry z10 shutting down at 80% !
Hi , I bought a Z10 device 2 days ago , and i updated it to lastest os , but the phone shutting down automatically at 80% , and it like the problem another guys says on this froum , I did all of solution i saw in the froum but still have the problem
-
explain step by step procedure for uplodig master data through lsmw (batch input recording) method. please explain settings for auto field mapping in 5th step