Re: [c-nsp] Strange problem with Cat6500 freeze
Not exactly the same but we had an 'automatic' reboot on a Sup720 and Sup32
during a broadcast storm after upgrading tot SXI4a. Before the upgrade the
machine kept running (unresponsive but running) until the cause of the
broadcast storm was removed.
Something seems to have changed in SXI4a
Wim Holemans
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jens S Andersen
Sent: maandag 13 december 2010 19:49
To: Robert Hass
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Strange problem with Cat6500 freeze
Hi
We har the exact same problem with 2 6503E/Sup32 routers after upgrading to
SXI4a.
We downgraded to SXI3, and the problem went away.
Maybe it's a SXI4a 'feature'.
-Jens
Hi
I have network where core-devices are Cisco Catalyst 6506-E with
Sup32/PFC3B. I last month We had two times problem. One time first 6500
'freezes' and second time second 6500 'freezes' Freezes means machine was
powered up, alarm was present (diode on supervisor), console wasn't
responding at all, freeze 6500 created a lot of loops on all VLANs inside
network (%SW_MATM-4-MACFLAP_NOTIF: Host .. in vlan XX is
flapping between port XX and port XX), all ports connected to 'freeze' 6500
was UP, LACP for PortChannels went down. Hard reboot (power off + power on)
helps both times. There wasn.t any crashdump in
flash/bootflash/sup-bootdisk/disk. Most problem was caused by loop created
by freeze 6500 - as all network was overloaded. How I could prevent these
issue in future ? Maybe storm-control for broadcasts ? Did anybody
occurred similar problem with 6500 ? After investigate both freezes was
probably caused by radom disabled/enabled NetFlow ('ip flow ingress') on few
SVIs.
Some facts more about both 6500 configurations:
- Both running 12.2(33)SXI4a IOS. Upgrade was done 1 month ago.
- Before machines was running 12.2(33)SXH4 never occurred similar problem
- eBGP (230k prefixes), 3-4 full table BGP peers + iBGP (20 peers rr-clients)
- IS-IS
- A little MLS QOS (policing) - 1-2 service-polcies on SVIs
- Control Plane Policing implemented
- Sometimes netflow v5 exporting from SVI
- Load around 40% (show catalyst6000) + 1.5Mpps (sh platf hardw capa pfc)
- Dual PSs
- Only ports GE on Sup-32 heavy used
- WS-X6408A-GBIC linecards but used only 1-2 ports with a little load
(~50-200Mb)
- ~300 VLANs
- ~50 SVIs
Robert
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Jens S Andersen Email: j...@adm.aau.dk
Aalborg University Telf: 9940 9464
Selma Lagerlöfs Vej 300, 4.2.59 Fax:9940 7593
9220 Aalborg
Denmark
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] ES support in SXJ [was: Script to track memory leaks?]
On 14 December 2010 00:00, Andriy Bilous andriy.bil...@gmail.com wrote: Don't get all excited, it's 10G only. :/ Starting a new thread because we're going well OT. Andy, if you mean up to 10G ports, then that's okay by me. I'm waiting for some more info from my friendly SE. -- Daniel Holme On Mon, Dec 13, 2010 at 10:14 PM, Daniel Holme dan.ho...@gmail.com wrote: On 13 Dec 2010, at 16:31, Phil Mayers p.may...@imperial.ac.uk wrote: On 13/12/10 16:23, Gert Doering wrote: Hi, On Mon, Dec 13, 2010 at 01:25:29PM +0200, Ziv Leyes wrote: http://blog.ioshints.info/2009/10/ssh-rsa-authentication-works-in-ios.html Great to see this implemented. Does one of you know whether this is on the roadmap for SX* and SR* IOS? Pfft. Given I was told BGP selective address tracking is roadmapped in SX* for 2012 (!) the other day, despite having been in SR* since 2007, I conclude that *nothing* is on the roadmap for SX* until post-sup2T. Well I've heard rumblings about ES support in SXJ, in Q1/Q2 2011. --Daniel Holme ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ES support in SXJ [was: Script to track memory leaks?]
On 12/14/2010 09:32 AM, Daniel Holme wrote: On 14 December 2010 00:00, Andriy Bilousandriy.bil...@gmail.com wrote: Don't get all excited, it's 10G only. :/ Starting a new thread because we're going well OT. Andy, if you mean up to 10G ports, then that's okay by me. Yes, joy of joys, a more expensive, lower-density 10gig option for the 6500 ;o) ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ES support in SXJ [was: Script to track memory leaks?]
On 14 December 2010 09:34, Phil Mayers p.may...@imperial.ac.uk wrote: On 12/14/2010 09:32 AM, Daniel Holme wrote: On 14 December 2010 00:00, Andriy Bilousandriy.bil...@gmail.com wrote: Don't get all excited, it's 10G only. :/ Starting a new thread because we're going well OT. Andy, if you mean up to 10G ports, then that's okay by me. Yes, joy of joys, a more expensive, lower-density 10gig option for the 6500 ;o) It should work out more cost effective than say a SIP-400 with 1-port 10G SPA for VPLS services (which I'm told will actually only do up to 4.4G). I do find it odd that they're going to introduce the support in the first place however, it seems to me that they're just decreasing the divide between 6500 and 7600 that they created in the first place by splitting the products software. But hey, let's not go there! -- Daniel Holme ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Strange problem with Cat6500 freeze
On Tue, Dec 14, 2010 at 9:34 AM, Holemans Wim wim.holem...@ua.ac.be wrote: Not exactly the same but we had an 'automatic' reboot on a Sup720 and Sup32 during a broadcast storm after upgrading tot SXI4a. Before the upgrade the machine kept running (unresponsive but running) until the cause of the broadcast storm was removed. Something seems to have changed in SXI4a We decided to go back to SXH release. But I'm sure that SXH4 is pretty stable in my experience. But good choice will be if we go to SXH8 release as some bugs was resolved from SXH4 release time. Can anyone confirm stability Sup32 config with SXH8 IOS ? Robert ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] IOS on 4503
Hi all, I am looking for advice on the best IOS to run on my Catalyst 4503. I am going to use it as a PE on a still small MPLS network. cisco WS-C4503 (MPC8245) processor (revision 4) with 524288K bytes of memory. Processor board ID FOX112813TS MPC8245 CPU at 400Mhz, Supervisor V Last reset from Reload 62 Virtual Ethernet/IEEE 802.3 interface(s) 98 Gigabit Ethernet/IEEE 802.3 interface(s) 511K bytes of non-volatile configuration memory. -- cheers Richard ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Catalyst 4500 E-Series
I'm trying to understand the differences between the WS-C4507-E and the WS-C4507+E but I'm confused: 1) 4503-E, 4506-E, 4507R+E, and 4510R+E chassis are extremely flexible and support either 6 Gbps, 24 Gbps, or 48Gbps per line-card slot. 4507R-E and 4510R-E chassis are limited to 6 Gbps and 24 Gbps per line-card slot. - So the +E seems better. 2) Part Number Max Rated Power (W) Rated MTBF (Hours) WS-C4507R+E 135 248,630 WS-C4507R-E 135 365,896 - Now the -E seems better 3) WS-C4507R-E 10K GPL WS-C4507R+E 7K GPL The +E looks much better :) What is the logic behind all this ? http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps4324/product_da ta_sheet0900aecd801792b1.html Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Backup Interface IPv6 - why is Cisco sleeping?
rant Having just installed a set of nice ASR1k boxes with rather new IOS, I noticed Cisco has still (after many years and many IOS releases) not managed to get Backup Interfaces IPv6 to work with each other ... or I'm missing something ... but while IPv4 addresses on backup interfaces work just fine, IPv6 config will lead to the backup interface to no come up due to the IP address overlapping with the IP address of the primary interface (what a surprise - it's the BACKUP INTERFACE, for crying out loud ...) With Cisco presenting themselves and their hardware oh so v6-ready (which they are for most parts I guess - all other features at least we require for production use seem perfectly fine), I'm really starting to wonder whether we're the only ones on this earth still using a dual switch config for our routers for redundancy purposes ... /rant -garry ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Legitimate Access to IOS for Legacy/EOL devices
It seems this will be effective in January 2011: http://www.cisco.com/web/services/resources/newsletter/europe_nov_10.html#7 Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ziv Leyes Sent: segunda-feira, 13 de Dezembro de 2010 14:00 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Legitimate Access to IOS for Legacy/EOL devices He said after maybe try again tomorrow and see if there are any changes... ;-) -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Antonio Soares Sent: Monday, December 13, 2010 2:19 PM To: 'Seth Mattinen'; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Legitimate Access to IOS for Legacy/EOL devices Today is the day ? I've just downloaded one 7200 image and I didn't notice any difference in the process. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Seth Mattinen Sent: sexta-feira, 19 de Novembro de 2010 22:53 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Legitimate Access to IOS for Legacy/EOL devices On 11/19/2010 14:07, Brian Raaen wrote: I was wondering if there was any legitimate way to get access to IOS for legacy devices. I have a 2611, 3725 and pair of 2950's in my home lab that I would like to test some things on. Thanks Right now any valid service contract will get you access to the ancient stuff as well, but my gut feeling is that after Dec. 13 anything EOL will be locked away for good. ~Seth ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. The information contained in this e-mail message and its attachments is confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender, and then delete the message from your computer. Thank you! This mail was sent via Mail-SeCure System. This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Backup Interface IPv6 - why is Cisco sleeping?
On 12/14/10 6:54 AM, Garry wrote: rant Having just installed a set of nice ASR1k boxes with rather new IOS, I noticed Cisco has still (after many years and many IOS releases) not managed to get Backup Interfaces IPv6 to work with each other ... or I'm missing something ... but while IPv4 addresses on backup interfaces work just fine, IPv6 config will lead to the backup interface to no come up due to the IP address overlapping with the IP address of the primary interface (what a surprise - it's the BACKUP INTERFACE, for crying out loud ...) With Cisco presenting themselves and their hardware oh so v6-ready (which they are for most parts I guess - all other features at least we require for production use seem perfectly fine), I'm really starting to wonder whether we're the only ones on this earth still using a dual switch config for our routers for redundancy purposes ... /rant Have you tried: ipv6 address 2001:0DB8:107:400::1/64 anycast This will suppress duplicate address detection. ~Seth ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Legitimate Access to IOS for Legacy/EOL devices
Hi, On Tue, Dec 14, 2010 at 03:58:15PM -, Antonio Soares wrote: It seems this will be effective in January 2011: http://www.cisco.com/web/services/resources/newsletter/europe_nov_10.html#7 Haha, Software Download Centre... improved to protect your investment. 'nuff said. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpyuyQkFAbA5.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 4500 E-Series
The +E chassis has new mux-buffers to support 48G/slot in the redundant chassis. The higher speed mux-buffers result in the lower rated MTBF. We priced lower to encourage transition. Going forward, I recommend R+E chassis purchases only. Sachin On 12/14/10 6:06 AM, Antonio Soares amsoa...@netcabo.pt wrote: I'm trying to understand the differences between the WS-C4507-E and the WS-C4507+E but I'm confused: 1) 4503-E, 4506-E, 4507R+E, and 4510R+E chassis are extremely flexible and support either 6 Gbps, 24 Gbps, or 48Gbps per line-card slot. 4507R-E and 4510R-E chassis are limited to 6 Gbps and 24 Gbps per line-card slot. - So the +E seems better. 2) Part Number Max Rated Power (W) Rated MTBF (Hours) WS-C4507R+E 135 248,630 WS-C4507R-E 135 365,896 - Now the -E seems better 3) WS-C4507R-E 10K GPL WS-C4507R+E 7K GPL The +E looks much better :) What is the logic behind all this ? http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps4324/product_da ta_sheet0900aecd801792b1.html Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Sachin Gupta | Dir, Marketing | Catalyst 4500 4900 Series ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Write queue size of XXX exceeded limit of 100 messages
Trying to work through an issue with an upstream where we're seeing intermittent BGP session flapping. Once or twice a day we're seeing our BGP session with that provider drop, then flap for anywhere between 5 minutes and the better part of an hour. During the flapping if we enable debugging on that session, we get messages like: *Sep 4 21:10:48.727: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:48.827: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:48.927: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:49.027: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:49.127: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:49.227: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:49.327: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:49.427: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:49.527: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:49.627: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages Those messages come as fast as the router can spit them out and continue until the session goes idle again. Google hasn't been a whole lot of help with that particular message -- I've found a few mentions that seem to indicate a memory problem but it's not clear whether that would be with the router displaying the error or the remote router. In this case I have no visibility into the remote router, but the router on this side of the connection shouldn't be having memory issues. It looks to me like the error is actually being sent by the remote router (1.2.3.4) but I'm not even certain about that. Here's how things look when everything is working normally: This side is a 7204 VXR NPE-G1 with 1GB RAM. router#sh proc mem Total: 922997376, Used: 324146356, Free: 598851020 router#sh ip bgp summ BGP router identifier 1.1.1.1, local AS number 1 BGP table version is 40446332, main routing table version 40446332 383853 network entries using 38769153 bytes of memory 658504 path entries using 31608192 bytes of memory 108261 BGP path attribute entries using 6497640 bytes of memory 97819 BGP AS-PATH entries using 2529712 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 79404697 total bytes of memory BGP activity 4995866/4612013 prefixes, 30926762/30268258 paths, scan interval 60 secs NeighborVAS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 1.2.3.4 4 123 7062260 11841061 4044628500 1d09h 331684 1.1.1.1 4 1 8191283 5916235 4044633200 5w6d 276144 2.2.2.2 4 1 583483 7077668 4044633200 12w0d 50654 3.3.3.3 4 1 6876244 4191128000 2w0d Idle (Admin) The connection to AS 123 is the upstream connection, AS 1 are iBGP connections to other devices on the local network. Those BGP sessions stay nailed up throughout the problems with the upstream session. While the BGP session is flapping, the session will go active, the OutQ will spike up to 400-600 and PfxRcd is usually either at 0 or only a few hundred. It will stay that way for anywhere from about 30 seconds to 4 or 5 minutes before dropping back to idle and starting over again. Debugging issues a timeout error when the session drops and returns to idle. Since this has been an ongoing issue for awhile now we've aimed some additional monitoring at the BGP session and the circuit carrying that traffic and have noticed that most (though not every) time this happens, the initial BGP session drop is preceded by a brief burst of packet-loss on the circuit. The packet-loss lasts no more than a minute or two and is generally less than 5%. We're running a more or less continual ping -f across the circuit which is the only way we're even able to detect the small loss. The packet-loss seems to correlate with the BGP drop often enough that it doesn't seem coincidental, but doesn't seem to always happen. In the cases where packet-loss precedes the BGP drop, it always disappears as soon as BGP drops and does not return at any time during the subsequent flapping. Upstream seems to be taking the position that if it isn't happening right when they get around to looking at it, there is no problem, so I'm hoping someone here can perhaps shed some more light on the write queue error. Thanks! Andrew ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 2951 memory upgrade to 2GB/Boot loader
Just a side note so I can vent, just talked to TAC and the lady suggested to boot with the old RAM and swap it while the router was powered on On Mon, Dec 13, 2010 at 11:38 PM, Jay Nakamura zeusda...@gmail.com wrote: I was having problems upgrading memory in a ISR G2 2951 from two 512M DIMMs to one 2GB DIMM. Neither of the DIMM I had worked so I started to think I may need to upgrade ROMMON/boot loader. But for the life of me, I could not find any release notes on cisco.com for it anywhere. There is newer release of boot loader than what's on the router but could not find any release notes. Anyone know where I could find it or if a new boot loader is required for 2GB DIMM? With the new RAM, the router keeps repeating this Check stop condition detected, resetting the system System Bootstrap, Version 15.0(1r)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 2009 by cisco Systems, Inc. It's possible both DIMMs were bad but it seems unlikely. It's also possible the vendor sent me the wrong type. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 2951 memory upgrade to 2GB/Boot loader
On 12/14/10 10:09 AM, Jay Nakamura wrote: Just a side note so I can vent, just talked to TAC and the lady suggested to boot with the old RAM and swap it while the router was powered on I hope you didn't pay too much on the smartnet for that suggestion. The only time I've seen the problem you're describing is when the DIMM speed doesn't precisely match the specs the router is expecting. ~Seth ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 2951 memory upgrade to 2GB/Boot loader
This might help you: The default Cisco 2951 has a unique memory configuration, whereby a 512 MB DIMM is installed in one of the two memory slots on the Cisco 2951. Memory upgrades on the Cisco 2951 can involve the increase in the density of that single DIMM or a combination of DIMMs with BOTH slots populated. The Cisco 2951 allows the use of asymmetric densities of DRAM in both slots. http://www.cisco.com/en/US/prod/collateral/modules/ps10598/ordering_guide_c07_557736_ps10537_Products_Data_Sheet.html It looks like both slots need to be populated. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of David Rothera Sent: Tuesday, December 14, 2010 12:26 PM To: Jay Nakamura Cc: cisco-nsp Subject: Re: [c-nsp] 2951 memory upgrade to 2GB/Boot loader Hope you got her name to use when you have to raise a case for a dead 2951 :P On 14 Dec 2010, at 18:09, Jay Nakamura wrote: Just a side note so I can vent, just talked to TAC and the lady suggested to boot with the old RAM and swap it while the router was powered on On Mon, Dec 13, 2010 at 11:38 PM, Jay Nakamura zeusda...@gmail.com wrote: I was having problems upgrading memory in a ISR G2 2951 from two 512M DIMMs to one 2GB DIMM. Neither of the DIMM I had worked so I started to think I may need to upgrade ROMMON/boot loader. But for the life of me, I could not find any release notes on cisco.com for it anywhere. There is newer release of boot loader than what's on the router but could not find any release notes. Anyone know where I could find it or if a new boot loader is required for 2GB DIMM? With the new RAM, the router keeps repeating this Check stop condition detected, resetting the system System Bootstrap, Version 15.0(1r)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 2009 by cisco Systems, Inc. It's possible both DIMMs were bad but it seems unlikely. It's also possible the vendor sent me the wrong type. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Strange problem with Cat6500 freeze
On 14 December 2010 11:45, Robert Hass robh...@gmail.com wrote: We decided to go back to SXH release. But I'm sure that SXH4 is pretty stable in my experience. But good choice will be if we go to SXH8 release as some bugs was resolved from SXH4 release time. Can anyone confirm stability Sup32 config with SXH8 IOS ? Not quite, but for what it's worth, I can confirm SXH8 has been rock solid for us on both 3B/3BXL. I decided to chose it over SXI because we didn't need the VSS/SPA/6716 support which is mostly where SXI differs from SXH hardware-wise. -- Daniel Holme ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 2951 memory upgrade to 2GB/Boot loader
Just wanted to mention that someone at Cisco saw my post and gotten it taken care of pretty quickly. Conclusion, - One 2GB DIMM in slot 0 is supported on 2951. - ROMMON upgrade is not necessary. Which leaves me with bad batch of DIMM. Thanks! On Tue, Dec 14, 2010 at 1:59 PM, Jaquish, Bret bret.jaqu...@navistar.com wrote: This might help you: The default Cisco 2951 has a unique memory configuration, whereby a 512 MB DIMM is installed in one of the two memory slots on the Cisco 2951. Memory upgrades on the Cisco 2951 can involve the increase in the density of that single DIMM or a combination of DIMMs with BOTH slots populated. The Cisco 2951 allows the use of asymmetric densities of DRAM in both slots. http://www.cisco.com/en/US/prod/collateral/modules/ps10598/ordering_guide_c07_557736_ps10537_Products_Data_Sheet.html It looks like both slots need to be populated. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of David Rothera Sent: Tuesday, December 14, 2010 12:26 PM To: Jay Nakamura Cc: cisco-nsp Subject: Re: [c-nsp] 2951 memory upgrade to 2GB/Boot loader Hope you got her name to use when you have to raise a case for a dead 2951 :P On 14 Dec 2010, at 18:09, Jay Nakamura wrote: Just a side note so I can vent, just talked to TAC and the lady suggested to boot with the old RAM and swap it while the router was powered on On Mon, Dec 13, 2010 at 11:38 PM, Jay Nakamura zeusda...@gmail.com wrote: I was having problems upgrading memory in a ISR G2 2951 from two 512M DIMMs to one 2GB DIMM. Neither of the DIMM I had worked so I started to think I may need to upgrade ROMMON/boot loader. But for the life of me, I could not find any release notes on cisco.com for it anywhere. There is newer release of boot loader than what's on the router but could not find any release notes. Anyone know where I could find it or if a new boot loader is required for 2GB DIMM? With the new RAM, the router keeps repeating this Check stop condition detected, resetting the system System Bootstrap, Version 15.0(1r)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 2009 by cisco Systems, Inc. It's possible both DIMMs were bad but it seems unlikely. It's also possible the vendor sent me the wrong type. ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Backup Interface IPv6 - why is Cisco sleeping?
On 14.12.2010 17:47, Seth Mattinen wrote: ipv6 address 2001:0DB8:107:400::1/64 anycast This will suppress duplicate address detection. Nope, doesn't work either ... used the anycast option on both interfaces, still get the warning on the standby interface, or error when using it on it when in backup mode active ... -garry ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Legitimate Access to IOS for Legacy/EOL devices
On 14/12/2010 15:58, Antonio Soares wrote: It seems this will be effective in January 2011: http://www.cisco.com/web/services/resources/newsletter/europe_nov_10.html#7 Software Download Centre Entitlement controls improved to protect your investment ? I think they misspelled our. Silly Cisco - there's nothing even remotely customer centric about this move. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Write queue size of XXX exceeded limit of 100 messages
The message you are seeing has to do with sending updates to the peer. If they aren't getting ACK'd fast enough we start to queue. Once the queue fills we fill up and can eventually exceed that sending BGP queue. If you have access to the far side, check TCP, input queues, interfaces, ect. This is most likely a problem on the far side of the link. HTH, Pete On Tue, Dec 14, 2010 at 12:07 PM, andr...@one.net wrote: Trying to work through an issue with an upstream where we're seeing intermittent BGP session flapping. Once or twice a day we're seeing our BGP session with that provider drop, then flap for anywhere between 5 minutes and the better part of an hour. During the flapping if we enable debugging on that session, we get messages like: *Sep 4 21:10:48.727: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:48.827: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:48.927: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:49.027: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:49.127: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:49.227: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:49.327: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:49.427: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:49.527: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages *Sep 4 21:10:49.627: BGP(0): 1.2.3.4 write queue size of 471 exceeded limit of 100 messages Those messages come as fast as the router can spit them out and continue until the session goes idle again. Google hasn't been a whole lot of help with that particular message -- I've found a few mentions that seem to indicate a memory problem but it's not clear whether that would be with the router displaying the error or the remote router. In this case I have no visibility into the remote router, but the router on this side of the connection shouldn't be having memory issues. It looks to me like the error is actually being sent by the remote router (1.2.3.4) but I'm not even certain about that. Here's how things look when everything is working normally: This side is a 7204 VXR NPE-G1 with 1GB RAM. router#sh proc mem Total: 922997376, Used: 324146356, Free: 598851020 router#sh ip bgp summ BGP router identifier 1.1.1.1, local AS number 1 BGP table version is 40446332, main routing table version 40446332 383853 network entries using 38769153 bytes of memory 658504 path entries using 31608192 bytes of memory 108261 BGP path attribute entries using 6497640 bytes of memory 97819 BGP AS-PATH entries using 2529712 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 79404697 total bytes of memory BGP activity 4995866/4612013 prefixes, 30926762/30268258 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 1.2.3.4 4 123 7062260 11841061 40446285 0 0 1d09h 331684 1.1.1.1 4 1 8191283 5916235 40446332 0 0 5w6d 276144 2.2.2.2 4 1 583483 7077668 40446332 0 0 12w0d 50654 3.3.3.3 4 1 6876244 4191128 0 0 0 2w0d Idle (Admin) The connection to AS 123 is the upstream connection, AS 1 are iBGP connections to other devices on the local network. Those BGP sessions stay nailed up throughout the problems with the upstream session. While the BGP session is flapping, the session will go active, the OutQ will spike up to 400-600 and PfxRcd is usually either at 0 or only a few hundred. It will stay that way for anywhere from about 30 seconds to 4 or 5 minutes before dropping back to idle and starting over again. Debugging issues a timeout error when the session drops and returns to idle. Since this has been an ongoing issue for awhile now we've aimed some additional monitoring at the BGP session and the circuit carrying that traffic and have noticed that most (though not every) time this happens, the initial BGP session drop is preceded by a brief burst of packet-loss on the circuit. The packet-loss lasts no more than a minute or two and is generally less than 5%. We're running a more or less continual ping -f across the circuit which is the only way we're even able to detect the small loss. The packet-loss seems to correlate with the BGP drop often enough that it doesn't seem coincidental, but doesn't seem to always happen. In the cases where packet-loss precedes the BGP drop, it always disappears as soon as BGP drops and does not return at any time during the subsequent flapping. Upstream seems to be taking the position that if it isn't
[c-nsp] Question about LLQ
Hello I'm bit confused about bandwidth assigned for priority queue when using LLQ , if the assigned amount of BW for PQ is high percentage from interface bandwidth say 50% and the offered priority traffic rate don't consume that much my question is about unused amount for BW can be assigned to other non-priority classes i read couple of papers in Cisco and some said YES the total amount of unused BW is proportional shared between classes according to the configured bandwidth and some considers the concept of total available bandwidth which is the maximum amount of interface bandwidth can be used by non-priority classes and this amount = total interface bw - [ Reserved BW ( Def is 25% of interface bw) + priority classes BW] I need to know if both are correct ? is it depends on interface types ? Thanks Ibrahim Abo Zaid , CCIE#27707 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Question about LLQ
Yes, any bandwidth not being used by the LLQ will be used by the other queues. The LLQ defines a ceiling for bandwidth usage, not a bandwidth reservation. -Pete On Tue, Dec 14, 2010 at 9:36 PM, Ibrahim Abo Zaid ibrahim.aboz...@gmail.com wrote: Hello I'm bit confused about bandwidth assigned for priority queue when using LLQ , if the assigned amount of BW for PQ is high percentage from interface bandwidth say 50% and the offered priority traffic rate don't consume that much my question is about unused amount for BW can be assigned to other non-priority classes i read couple of papers in Cisco and some said YES the total amount of unused BW is proportional shared between classes according to the configured bandwidth and some considers the concept of total available bandwidth which is the maximum amount of interface bandwidth can be used by non-priority classes and this amount = total interface bw - [ Reserved BW ( Def is 25% of interface bw) + priority classes BW] I need to know if both are correct ? is it depends on interface types ? Thanks Ibrahim Abo Zaid , CCIE#27707 ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Backup Interface IPv6 - why is Cisco sleeping?
Garry, It could be related to CSCth59072 Backup interface up instead of standby which affects the ASR1K. The latest 15.0(1)S version (03.01.02.S.150-1.S2) should have the fix... What software were you testing with? Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Garry Sent: Tuesday, December 14, 2010 16:55 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Backup Interface IPv6 - why is Cisco sleeping? rant Having just installed a set of nice ASR1k boxes with rather new IOS, I noticed Cisco has still (after many years and many IOS releases) not managed to get Backup Interfaces IPv6 to work with each other ... or I'm missing something ... but while IPv4 addresses on backup interfaces work just fine, IPv6 config will lead to the backup interface to no come up due to the IP address overlapping with the IP address of the primary interface (what a surprise - it's the BACKUP INTERFACE, for crying out loud ...) With Cisco presenting themselves and their hardware oh so v6-ready (which they are for most parts I guess - all other features at least we require for production use seem perfectly fine), I'm really starting to wonder whether we're the only ones on this earth still using a dual switch config for our routers for redundancy purposes ... /rant -garry ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
