Re: [c-nsp] Insufficient memory to boot image on 827?
On Sun, Mar 21, 2010 at 4:10 PM, Billy Guthrie b...@billyguthrie.com wrote: Steve unless some odd memory allocation is occurring and based on what you provided, then you do not have enough memory to load the image. One thing to take in consideration is that the images are compressed, so during the boot process the router will decompress the image and if you do not have enough memory, it will obviously fail to boot. You say that you are running the 12.4(5C), but what feature set (IP/FW, IP Plus, IP)? Take note, that if you are trying to boot the IP PUS image this is what is more than likely causing your issue. This image requires at least 32MB of RAM to boot. What is the file name that you copied to flash? When the image is booting, it uncompresses OK. The insufficient memory error does not appear until later in the boot process.I am trying to use the IP feature set. As you say, the other images require more memory than this 827 has. The file name was c820-y6-mz.124-5c.bin. Thanks for the reply Steve ___ 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] Insufficient memory to boot image on 827?
On Sun, Mar 21, 2010 at 7:23 PM, Nigel Roy ni...@theroys.me.uk wrote: Hi Steve, I had a similar thing with an 1801 - there was a memory command in the config allocating some of the Ram to IO. Can't remember exactly what the command was but worth checking! Regards Nigel Off list I had memory-size iomem suggested to me which may be what you are thinking of. That command unfortunately does not appear to exist on my 827. Thank you for the suggestion Steve ___ 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 Image for Voice GateKeeper
Hello, Please which is the lowest IOS image packages (and licenses if any) that would support the following functionalities on my Cisco 2800 series routers - Voice Gateway - Voice Gatekeeper Thanks in advance for your replies. Felix ___ 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] 6500 nvram contents changing
John, It looks like Jared was correct, we had another instance of rancid running on another box a roughly the same time, I shifted the the cron job forward 30 minutes, and the diffs have stopped. Kind Regards, Ben Cooper Support and Infrastructure Manager Hub Network Services Ltd Phone: 0117 9200045 Fax:0127 5394292 For system or network support, please email supp...@hns.net On 19/03/2010 17:18, john heasley wrote: Fri, Mar 19, 2010 at 10:40:20AM -0400, Jared Mauch: This typically happens if someone is viewing the startup-config (eg: show conf) as it is locked. afaict, reading nor writing locks the nvram fsys in such a way that dir /all nvram:, the command rancid uses, fails. it seems to wait as you'd expect the locking to work, though not in a fifo manner. at least, i can't reproduce this on 12.2.18SXF16. if it did fail, i'd expect that it the cli would return an error, which rancid may not recognize. in cases where the fsys is locked, like for one being squeezed, the cli normally produces errors like Open device \S+ failed Error opening \S+: which rancid does recognize. it may be that write memory removes all the nvram files, then writes the new ones and you're just lucky. other ideas? - Jared On Mar 19, 2010, at 7:58 AM, Ben Cooper wrote: Hi, We use rancid to retrieve configs from our cisco kit, recently one of our 6500s (s72033_rp-ADVENTERPRISEK9_WAN-M Version 12.2(33)SXH3) has started reporting nvram content changes sporadically throughout the day, eg: !Flash: nvram: Directory of nvram:/ !Flash: nvram: 1918 -rw- 26788no date startup-config !Flash: nvram: 1919 24no date private-config !Flash: nvram: 1920 -rw- 26788no date underlying-config - !Flash: nvram: 1 4no date rf_cold_starts - !Flash: nvram: 2 48no date persistent-data - !Flash: nvram: 3 -rw-4887no date ifIndex-table !Flash: nvram: 1964024 bytes total (1929992 bytes free) !Flash: nvram: Directory of nvram:/ - !Flash: nvram: No files in directory + !Flash: nvram: 1918 -rw- 26788no date startup-config + !Flash: nvram: 1919 24no date private-config + !Flash: nvram: 1920 -rw- 26788no date underlying-config + !Flash: nvram: 1 4no date rf_cold_starts + !Flash: nvram: 2 48no date persistent-data + !Flash: nvram: 3 -rw-4887no date ifIndex-table !Flash: nvram: 1964024 bytes total (1929992 bytes free) Has anyone experienced this behaviour before? Thanks, Ben ___ 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/ ___ 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] c6509 booting in ROMMON
Hello list, I have tried to debug this for a long time but I'm stuck. Here is the situation. I have a SUP720-3BXL (MSFC3) running on s72033-advipservicesk9_wan-mz.122-33.SXH2a.bin that went crazy just before X-mas eve, after two years of loyal services ! After some log reading, I found out I was affected by bug CSCsc33990 : Causes and Resolutions: * If there is any corruption in the TCAM entries, the *SPRPInbandPing test can fail*. If the test, ran as part of Cisco Generic Online Diagnostics (GOLD), fails 10 times consecutively, then the supervisor engine can crash. In order to resolve the issue, upgrade the Cisco IOS software to a release not affected by Cisco bug ID CSCsc33990 ( registered customers only) . * If health-monitoring is enabled on the device and complete diagnostics is configured during the startup, then the supervisor can crash at the time of the boot process. Health-monitoring and complete diagnostics conflict with each other for some tests. As a workaround, disable either of them, which depends on your requirement. I have taken back the faulty card back to my office where I have a spare chassi (comes in handy sometimes ;-) and now the sup720 boots in ROMMON. I thought maybe my bootdisk (sup-bootflash or sup-bootdisk) whas corrupted because It was old. I tried this : - boot on disk0 with the same IOS === OK - format bootdisk then copy IOS from disk0: to bootdisk: === OK - Reload with my bootvar pointing to the image on bootdisk: === NOK - from ROMMON, boot using the image on bootdisk: === OK (look below for output) BB1.IX1#reload Proceed with reload? [confirm] *Mar 22 10:23:37.587: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command. Mar 22 10:23:41.836: %SYS-SP-3-LOGGER_FLUSHING: System pausing to ensure console debugging output. Mar 22 10:23:41.836: %OIR-SP-6-CONSOLE: Changing console ownership to switch processor Mar 22 10:23:42.040: %SYS-SP-3-LOGGER_FLUSHED: System was paused for 00:00:00 to ensure console debugging output. Mar 22 10:23:44.615: %SYS-SP-3-LOGGER_FLUSHING: System pausing to ensure console debugging output. *** *** --- SHUTDOWN NOW --- *** Mar 22 10:23:44.615: %SYS-SP-5-RELOAD: Reload requested Mar 22 10:23:44.615: %OIR-SP-6-CONSOLE: Changing console ownership to switch processor Mar 22 10:23:44.923: %SYS-SP-3-LOGGER_FLUSHED: System was paused for 00:00:00 to ensure console debugging output. System Bootstrap, Version 8.4(2) Release Copyright (c) 1994-2005 by cisco Systems, Inc. Cat6k-Sup720/SP processor with 1048576 Kbytes of main memory rommon 1 rommon 1 rommon 1 dev Devices in device table: id name bootdisk: boot disk disk0: PCMCIA Disk 0 disk1: PCMCIA Disk 1 eprom: eprom rommon 2 dir bootdisk: Initializing ATA monitor library... Directory of bootdisk: 2 78203396 -rw- s72033-advipservicesk9_wan-mz.122-33.SXH2a.bin 308433554432 -rw- sea_log.dat rommon 3 rommon 3 rommon 3 boot bootdisk:s72033-advipservicesk9_wan-mz.122-33.SXH2a.bin Loading image, please wait ... Initializing ATA monitor library... I Decided then to change th CF on the SUP720 with a brand new one, no change. I am still experiencing the same symptoms. Any ideas what might cause this ? Would you recommend an upgrade in order to solve this ? Is my SUP720 dead ? Thanks for your feedback. Best regards. Y. -- Youssef BENGELLOUN-ZAHR .. Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr ...www.720.fr ___ 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] Odd problem with bgp resets on SRD3
Hello all,
We have faced the same problem when we have tried to update to version
SRD4.
Our hardware is Cisco 7600 with RSP720-3CXL-GE with 2GB RAM and
WS-X6704-10GE.
We have observed the bgp notification in logging such as neighbor
1xx.x.x.x 3/1 (update malformed).
The all sessions get down after that with message Down No memory
Who was faced with such problem also? How to solve it?
We had the following errors log occur:
%BGP-5-ADJCHANGE: neighbor 1xx.x.x.x Down BGP Notification sent
%BGP-3-NOTIFICATION: sent to neighbor 1xx.x.x.x 3/1 (update malformed) 0
bytes
%BGP-4-MSGDUMP: unsupported or mal-formatted message received from
1xx.x.x.x: 004F 0200 3440
0101 0040 0208 0203 00AE 04D7 8F11 4003 0495 068D A980 0404 0001 4C26
4006 00C0 0706 8F11 D018 1489 C008 0800 AE52 0800 AE55 FD18 C029 A2
%BGP-5-ADJCHANGE: neighbor 10.x.x.x vpn vrf XX Down No memory
%BGP_SESSION-5-ADJCHANGE: neighbor 10.x.x.x IPv4 Unicast vpn vrf IT
topology base removed from session No memory
%BGP-5-ADJCHANGE: neighbor 6x.x.x.x Down No memory
%BGP_SESSION-5-ADJCHANGE: neighbor 6x.x.x.x IPv4 Unicast topology base
removed from session No memory ...
Mack McBride пишет:
I am looking at 2 - 7600s with RSP720-3CXLs w/ 4GB of RAM and 6708-3CXL cards
running SRD3.
These are not currently production equipment but are connected to upstreams
as well as route-reflectors but are not advertising routes as we have
advertisements blocked
with a deny-all prefix list. We THINK the dumped BGP packet is correctly
formatted and
the packet dumped is actually the packet before the bad packet. Has anyone
else
seen similar issues? Does anyone else know if this is a known bug that
exists in this code or
early versions of the SRD train? I know there are entirely too many caveats
in SRC5.
Mack McBride
Network Architect
ViaWest, Inc.
We had the following errors occur:
Log from 7600-01:
Nov 24 02:41:59.696 MST: %BGP-5-ADJCHANGE: neighbor 207.xx.xx.xx Down BGP
Notification sent
Nov 24 02:41:59.696 MST: %BGP-3-NOTIFICATION: sent to neighbor 207.xx.xx.xx
3/1 (update malformed) 0 bytes
Nov 24 02:41:59.696 MST: %BGP-4-MSGDUMP: unsupported or mal-formatted message
received from 207.xx.xx.xx:
0064 0200 4940 0101 0040 0208
0203
10E3 00AE 0865 4003 04CF FA73 1540 0600 C007 0608 659A 3604 36C0 0824 10E3
0033
10E3 01F5 10E3 03F7 10E3 09C7 10E3 C350 FE4D 03F7 FE4E 0004 FE4F 0001 FE50
012D
18C0 2104
Nov 24 02:41:59.748 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx1 Down No
memory
Nov 24 02:41:59.748 MST: %BGP_SESSION-5-ADJCHANGE: neighbor 74.xx.xx.xx1 IPv4
Unicast topology base removed from session No memory
Nov 24 02:41:59.748 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx2 Down No
memory
Nov 24 02:41:59.748 MST: %BGP_SESSION-5-ADJCHANGE: neighbor 74.xx.xx.xx2 IPv4
Unicast topology base removed from session No memory
Nov 24 02:41:59.748 MST: %BGP_SESSION-5-ADJCHANGE: neighbor 207.xx.xx.xx IPv4
Unicast topology base removed from session BGP Notification sent
Nov 24 02:42:06.384 MST: %BGP-5-ADJCHANGE: neighbor 207.xx.xx.xx Up
Nov 24 02:42:12.640 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx2 Up
Nov 24 02:42:12.672 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx1 Up
Nov 24 02:42:31.436 MST: %BGP-5-ADJCHANGE: neighbor 207.xx.xx.xx Down BGP
Notification sent
Nov 24 02:42:31.436 MST: %BGP-3-NOTIFICATION: sent to neighbor 207.xx.xx.xx
3/1 (update malformed) 0 bytes
Nov 24 02:42:31.440 MST: %BGP-4-MSGDUMP: unsupported or mal-formatted message
received from 207.xx.xx.xx:
0064 0200 4940 0101 0040 0208
0203
10E3 00AE 0865 4003 04CF FA73 1540 0600 C007 0608 659A 3604 42C0 0824 10E3
0033
10E3 01F5 10E3 03F7 10E3 09C7 10E3 C350 FE4D 03F7 FE4E 0004 FE4F 0001 FE50
012D
18C0 2104
Nov 24 02:42:31.504 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx1 Down No
memory
Nov 24 02:42:31.504 MST: %BGP_SESSION-5-ADJCHANGE: neighbor 74.xx.xx.xx1 IPv4
Unicast topology base removed from session No memory
Nov 24 02:42:31.504 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx2 Down No
memory
Nov 24 02:42:31.504 MST: %BGP_SESSION-5-ADJCHANGE: neighbor 74.xx.xx.xx2 IPv4
Unicast topology base removed from session No memory
Nov 24 02:42:31.504 MST: %BGP_SESSION-5-ADJCHANGE: neighbor 207.xx.xx.xx IPv4
Unicast topology base removed from session BGP Notification sent
Nov 24 02:42:38.620 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx2 Up
Nov 24 02:42:38.620 MST: %BGP-5-ADJCHANGE: neighbor 207.xx.xx.xx Up
Nov 24 02:42:42.928 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx1 Up
7600-02:
Nov 24 02:42:16.343 MST: %BGP-5-ADJCHANGE: neighbor 4.xx.xx.xx Down BGP
Notification sent
Nov 24 02:42:16.343 MST: %BGP-3-NOTIFICATION: sent to neighbor 4.xx.xx.xx 3/1
(update malformed) 0 bytes
Nov 24 02:42:16.343 MST: %BGP-4-MSGDUMP: unsupported or mal-formatted message
received from 4.xx.xx.xx:
Re: [c-nsp] c6509 booting in ROMMON
Hello, My bootvar / confreg looks correct to me, doesn't it ? BB1.IX1#sh bootvar BOOT variable = sup-bootdisk:s72033-advipservicesk9_wan-mz.122-33.SXH2a.bin,1; CONFIG_FILE variable = BOOTLDR variable = Configuration register is 0x2102 Y. 2010/3/22 William McCall william.mcc...@gmail.com Check the conf reg for the sp. IIRC, it also resets the confreg in its stupidity. I ran into this same bug in production and recall having to set it again. On 3/22/10, Youssef Bengelloun-Zahr yous...@720.fr wrote: Hello list, I have tried to debug this for a long time but I'm stuck. Here is the situation. I have a SUP720-3BXL (MSFC3) running on s72033-advipservicesk9_wan-mz.122-33.SXH2a.bin that went crazy just before X-mas eve, after two years of loyal services ! After some log reading, I found out I was affected by bug CSCsc33990 : Causes and Resolutions: * If there is any corruption in the TCAM entries, the *SPRPInbandPing test can fail*. If the test, ran as part of Cisco Generic Online Diagnostics (GOLD), fails 10 times consecutively, then the supervisor engine can crash. In order to resolve the issue, upgrade the Cisco IOS software to a release not affected by Cisco bug ID CSCsc33990 ( registered customers only) . * If health-monitoring is enabled on the device and complete diagnostics is configured during the startup, then the supervisor can crash at the time of the boot process. Health-monitoring and complete diagnostics conflict with each other for some tests. As a workaround, disable either of them, which depends on your requirement. I have taken back the faulty card back to my office where I have a spare chassi (comes in handy sometimes ;-) and now the sup720 boots in ROMMON. I thought maybe my bootdisk (sup-bootflash or sup-bootdisk) whas corrupted because It was old. I tried this : - boot on disk0 with the same IOS === OK - format bootdisk then copy IOS from disk0: to bootdisk: === OK - Reload with my bootvar pointing to the image on bootdisk: === NOK - from ROMMON, boot using the image on bootdisk: === OK (look below for output) BB1.IX1#reload Proceed with reload? [confirm] *Mar 22 10:23:37.587: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command. Mar 22 10:23:41.836: %SYS-SP-3-LOGGER_FLUSHING: System pausing to ensure console debugging output. Mar 22 10:23:41.836: %OIR-SP-6-CONSOLE: Changing console ownership to switch processor Mar 22 10:23:42.040: %SYS-SP-3-LOGGER_FLUSHED: System was paused for 00:00:00 to ensure console debugging output. Mar 22 10:23:44.615: %SYS-SP-3-LOGGER_FLUSHING: System pausing to ensure console debugging output. *** *** --- SHUTDOWN NOW --- *** Mar 22 10:23:44.615: %SYS-SP-5-RELOAD: Reload requested Mar 22 10:23:44.615: %OIR-SP-6-CONSOLE: Changing console ownership to switch processor Mar 22 10:23:44.923: %SYS-SP-3-LOGGER_FLUSHED: System was paused for 00:00:00 to ensure console debugging output. System Bootstrap, Version 8.4(2) Release Copyright (c) 1994-2005 by cisco Systems, Inc. Cat6k-Sup720/SP processor with 1048576 Kbytes of main memory rommon 1 rommon 1 rommon 1 dev Devices in device table: id name bootdisk: boot disk disk0: PCMCIA Disk 0 disk1: PCMCIA Disk 1 eprom: eprom rommon 2 dir bootdisk: Initializing ATA monitor library... Directory of bootdisk: 2 78203396 -rw- s72033-advipservicesk9_wan-mz.122-33.SXH2a.bin 308433554432 -rw- sea_log.dat rommon 3 rommon 3 rommon 3 boot bootdisk:s72033-advipservicesk9_wan-mz.122-33.SXH2a.bin Loading image, please wait ... Initializing ATA monitor library... I Decided then to change th CF on the SUP720 with a brand new one, no change. I am still experiencing the same symptoms. Any ideas what might cause this ? Would you recommend an upgrade in order to solve this ? Is my SUP720 dead ? Thanks for your feedback. Best regards. Y. -- Youssef BENGELLOUN-ZAHR .. Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr ... www.720.fr ___ 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/ -- Sent from my mobile device William McCall, CCIE #25044 -- Youssef BENGELLOUN-ZAHR …… Ingénieur Réseaux et Télécoms Technopole
Re: [c-nsp] c6509 booting in ROMMON
Hi, On Mon, Mar 22, 2010 at 10:08 PM, Youssef Bengelloun-Zahr yous...@720.fr wrote: My bootvar / confreg looks correct to me, doesn't it ? What does this give you? #remote command switch sh bootvar cheers, Dale ___ 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] IPv6: Getting started
Hello! Peter Rathlev wrote: Q: We run an MPLS VPN network, global routing only used for management. According to this document (which should also cover 12.2SX): http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-ov_mpls_6vpe.html#wp1054029 6VPE supports an MPLS IPv4-signaled core. An MPLS IPv6-signaled core is not supported. We have to keep an IPv4 core then? I guess the important part is to enable IPv6 for the users and services, but (excuse my french) it seems a little half-assed to not support an IPv6 core. Especially MPLS being what it is. Why don't keep it ipv4? If you run MPLS VPN netowork i don't see why you want something else in core. MPLS don't care about ipv4/6 and PE just assign labels for prefix/vpn and distribute it to other PEs. For me it looks like double security here, if your core has no ipv6 i can't be accessed (read: hacked) from outside ipv6 world/vpns. ___ 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] IOS Image for Voice GateKeeper
Ip voice. Sent from handheld. On Mar 22, 2010, at 4:43 AM, Felix Nkansah felixnkan...@gmail.com wrote: Hello, Please which is the lowest IOS image packages (and licenses if any) that would support the following functionalities on my Cisco 2800 series routers - Voice Gateway - Voice Gatekeeper Thanks in advance for your replies. Felix ___ 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] c6509 booting in ROMMON
Hello all, Here is the result : BB1.IX1#remote command switch sh bootvar BOOT variable = bootdisk:s72033-advipservicesk9_wan-mz.122-33.SXH2a.bin,1; CONFIG_FILE variable does not exist BOOTLDR variable does not exist Configuration register is 0x2100 Confregs aren't identical ? How do I change this ? How come is this possible ? Thanks. Y. 2010/3/22 Dale Shaw dale.shaw+cisco-...@gmail.comdale.shaw%2bcisco-...@gmail.com Hi, On Mon, Mar 22, 2010 at 10:08 PM, Youssef Bengelloun-Zahr yous...@720.fr wrote: My bootvar / confreg looks correct to me, doesn't it ? What does this give you? #remote command switch sh bootvar cheers, Dale -- Youssef BENGELLOUN-ZAHR …… Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr …….www.720.fr ___ 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] c6509 booting in ROMMON
Hey, Googled it, found this : http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00803e5282.shtml Will that solv my problems ? Thanks. Y. 2010/3/22 Youssef Bengelloun-Zahr yous...@720.fr Hello all, Here is the result : BB1.IX1#remote command switch sh bootvar BOOT variable = bootdisk:s72033-advipservicesk9_wan-mz.122-33.SXH2a.bin,1; CONFIG_FILE variable does not exist BOOTLDR variable does not exist Configuration register is 0x2100 Confregs aren't identical ? How do I change this ? How come is this possible ? Thanks. Y. 2010/3/22 Dale Shaw dale.shaw+cisco-...@gmail.comdale.shaw%2bcisco-...@gmail.com Hi, On Mon, Mar 22, 2010 at 10:08 PM, Youssef Bengelloun-Zahr yous...@720.fr wrote: My bootvar / confreg looks correct to me, doesn't it ? What does this give you? #remote command switch sh bootvar cheers, Dale -- Youssef BENGELLOUN-ZAHR …… Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr …….www.720.fr -- Youssef BENGELLOUN-ZAHR …… Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr …….www.720.fr ___ 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] c6509 booting in ROMMON
Hello all, Solved it, that did the trick. Question is : how could that happen ? I'd better check that my production chassis are ok :-) Thanks. Y. 2010/3/22 Youssef Bengelloun-Zahr yous...@720.fr Hey, Googled it, found this : http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00803e5282.shtml Will that solv my problems ? Thanks. Y. 2010/3/22 Youssef Bengelloun-Zahr yous...@720.fr Hello all, Here is the result : BB1.IX1#remote command switch sh bootvar BOOT variable = bootdisk:s72033-advipservicesk9_wan-mz.122-33.SXH2a.bin,1; CONFIG_FILE variable does not exist BOOTLDR variable does not exist Configuration register is 0x2100 Confregs aren't identical ? How do I change this ? How come is this possible ? Thanks. Y. 2010/3/22 Dale Shaw dale.shaw+cisco-...@gmail.comdale.shaw%2bcisco-...@gmail.com Hi, On Mon, Mar 22, 2010 at 10:08 PM, Youssef Bengelloun-Zahr yous...@720.fr wrote: My bootvar / confreg looks correct to me, doesn't it ? What does this give you? #remote command switch sh bootvar cheers, Dale -- Youssef BENGELLOUN-ZAHR …… Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr …….www.720.fr -- Youssef BENGELLOUN-ZAHR …… Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr …….www.720.fr -- Youssef BENGELLOUN-ZAHR …… Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr …….www.720.fr ___ 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] per-user static routes getting stuck
I have a 7206vxr running c7200-js-mz.123-23 doing a mix of T1 aggregation and PPPoA/PPPoE DSL termination. Lately, we've been seeing an issue with one particular PPPoE DSL user. They have a static IP and a /30 via their RADIUS profile. When this user disconnects, the per-user static route for their subnet isn't getting cleared from the routing table. Their static /32 does get cleared. The only way I've found to clear the /30 is to enter the route into the config, and then remove it from the config. With an uptime of 2.5 years, I should probably just upgrade to 12.3(26) and reboot...but I wonder if anyone else has seen this? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] c6509 booting in ROMMON
The explanation I got from Cisco was that this is working as designed. During the failure, it is supposed to 0x0 to prevent a loop. I said bs but they stuck by it *shrug*. --WM On 3/22/10, Youssef Bengelloun-Zahr yous...@720.fr wrote: Hello all, Solved it, that did the trick. Question is : how could that happen ? I'd better check that my production chassis are ok :-) Thanks. Y. 2010/3/22 Youssef Bengelloun-Zahr yous...@720.fr Hey, Googled it, found this : http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00803e5282.shtml Will that solv my problems ? Thanks. Y. 2010/3/22 Youssef Bengelloun-Zahr yous...@720.fr Hello all, Here is the result : BB1.IX1#remote command switch sh bootvar BOOT variable = bootdisk:s72033-advipservicesk9_wan-mz.122-33.SXH2a.bin,1; CONFIG_FILE variable does not exist BOOTLDR variable does not exist Configuration register is 0x2100 Confregs aren't identical ? How do I change this ? How come is this possible ? Thanks. Y. 2010/3/22 Dale Shaw dale.shaw+cisco-...@gmail.comdale.shaw%2bcisco-...@gmail.com Hi, On Mon, Mar 22, 2010 at 10:08 PM, Youssef Bengelloun-Zahr yous...@720.fr wrote: My bootvar / confreg looks correct to me, doesn't it ? What does this give you? #remote command switch sh bootvar cheers, Dale -- Youssef BENGELLOUN-ZAHR …… Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr …….www.720.fr -- Youssef BENGELLOUN-ZAHR …… Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr …….www.720.fr -- Youssef BENGELLOUN-ZAHR …… Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr …….www.720.fr -- Sent from my mobile device William McCall, CCIE #25044 ___ 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] c6509 booting in ROMMON
Once again, unbelievable ! Thanks a lot M. Cisco for making my nights easier ! Y. 2010/3/22 William McCall william.mcc...@gmail.com The explanation I got from Cisco was that this is working as designed. During the failure, it is supposed to 0x0 to prevent a loop. I said bs but they stuck by it *shrug*. --WM On 3/22/10, Youssef Bengelloun-Zahr yous...@720.fr wrote: Hello all, Solved it, that did the trick. Question is : how could that happen ? I'd better check that my production chassis are ok :-) Thanks. Y. 2010/3/22 Youssef Bengelloun-Zahr yous...@720.fr Hey, Googled it, found this : http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00803e5282.shtml Will that solv my problems ? Thanks. Y. 2010/3/22 Youssef Bengelloun-Zahr yous...@720.fr Hello all, Here is the result : BB1.IX1#remote command switch sh bootvar BOOT variable = bootdisk:s72033-advipservicesk9_wan-mz.122-33.SXH2a.bin,1; CONFIG_FILE variable does not exist BOOTLDR variable does not exist Configuration register is 0x2100 Confregs aren't identical ? How do I change this ? How come is this possible ? Thanks. Y. 2010/3/22 Dale Shaw dale.shaw+cisco-...@gmail.com dale.shaw%2bcisco-...@gmail.com dale.shaw%2bcisco-...@gmail.com dale.shaw%252bcisco-...@gmail.com Hi, On Mon, Mar 22, 2010 at 10:08 PM, Youssef Bengelloun-Zahr yous...@720.fr wrote: My bootvar / confreg looks correct to me, doesn't it ? What does this give you? #remote command switch sh bootvar cheers, Dale -- Youssef BENGELLOUN-ZAHR …… Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr …….www.720.fr -- Youssef BENGELLOUN-ZAHR …… Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr …….www.720.fr -- Youssef BENGELLOUN-ZAHR …… Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr …….www.720.fr -- Sent from my mobile device William McCall, CCIE #25044 -- Youssef BENGELLOUN-ZAHR …… Ingénieur Réseaux et Télécoms Technopole de l'Aube en Champagne - BP 601 - 10901 TROYES Cedex 9 Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE Tel +33 (0) 825 000 720 Tel. direct +33 (0) 1 77 35 59 14 Tel. portable +33 (0) 6 22 42 63 80 Emaily...@720.fr …….www.720.fr ___ 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] per-user static routes getting stuck
On Mar 22, 2010, at 10:01 AM, Jon Lewis wrote: to clear the /30 is to enter the route into the config, and then remove it from the config. With an uptime of 2.5 years, I should probably just upgrade to 12.3(26) and reboot...but I wonder if anyone else has seen this? I've had precisely the same problem on 12.3(23), didn't try (26). I moved several customers off mainline and onto 12.2SB, but then quickly went to 12.4t, on account of (20) having the 'same' cef guts that SB was blessed with (and 20k idb's on 7200). Interestingly, year+ uptime on 12.4(20)T in the same places has not resulted in stuck fib entries, no missing fib entries, and aaa/radius hasn't missed a beat. -Tk ___ 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] IPv6: Getting started
Hi Peter. Q: We almost only use 6500/Sup720 (12.2(33)SXI) and 3560/3750 (12.2(5n)SEn). According to Cisco's IPv6 technology white paper we should be okay. Are all relevant management stuff IPv6-ready? TACACS +, NetFlow (C6k FTW!), SSH, syslog, SNMPv3 et cetera. There were a severe bug (CSCir01027) affecting SNMP over IPv6 across a large number of IOS-trains. The fix should be in SXI, but no mentioning of 3560/3750 software. -- Pelle A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ 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] NPE-G1 / G2 performance
ASR1k is the place to look/be for this area. Rodney On 3/19/10 9:35 PM, Lee wrote: We had a solution involving NAT on some 6500s - it didn't take long for them to run out of memory reboot. Cisco eventually said there was a limitation of ~57K NAT translations on the PFC3B. We added a ip nat translation max-entries 5 to the configs and asked our security office to pretty please NOT do any more Nessus scansthere. That fixed the rebooting issue, but I think we're back to not doing NAT on any 6500s now. Regards, Lee On 3/19/10, Jeff Baconba...@walleyesoftware.com wrote: I'm looking for something that can: (1) handle about 100mbit (microbursting to gig) of mcast, taking it in interface A and pushing it out interfaces B and C, and maybe D (2) sustain 500-800mbit of throughput (assume 100-byte packets, occasional gig burst) coming in interface B and going out C, just straight routing (3) NAT a few TCP streams coming in interface C and going out interface A, none of which are anything big-shakes (meg or two of throughput) This is going to be the backup box; the primary is going to be a cat6500/sup720. I'm trying to avoid buying a second cat6500. I'm guessing this is beyond what an NPE-G1 can handle. How about a G2? If I have to buy an ASR, I'll just buy the 6500; I have a pile of 6500s and no ASRs. ___ 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/ ___ 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] Odd problem with bgp resets on SRD3
Thank you for answer,
This bug details is very similar to our problem.
We will try to apply this workaround
If this helps us we will write about it
2010/3/22 Paolo Lucente pl+l...@pmacct.net pl%2bl...@pmacct.net
Perhaps it's CSCtd26215. If BGP dampening is enabled, give a try disabling
it.
Cheers,
Paolo
On Mon, Mar 22, 2010 at 01:02:59PM +0200, teslenko.and...@gmail.com wrote:
Hello all,
We have faced the same problem when we have tried to update to version
SRD4.
Our hardware is Cisco 7600 with RSP720-3CXL-GE with 2GB RAM and
WS-X6704-10GE.
We have observed the bgp notification in logging such as neighbor
1xx.x.x.x 3/1 (update malformed).
The all sessions get down after that with message Down No memory
Who was faced with such problem also? How to solve it?
We had the following errors log occur:
%BGP-5-ADJCHANGE: neighbor 1xx.x.x.x Down BGP Notification sent
%BGP-3-NOTIFICATION: sent to neighbor 1xx.x.x.x 3/1 (update malformed) 0
bytes
%BGP-4-MSGDUMP: unsupported or mal-formatted message received from
1xx.x.x.x: 004F 0200 3440
0101 0040 0208 0203 00AE 04D7 8F11 4003 0495 068D A980 0404 0001 4C26
4006 00C0 0706 8F11 D018 1489 C008 0800 AE52 0800 AE55 FD18 C029 A2
%BGP-5-ADJCHANGE: neighbor 10.x.x.x vpn vrf XX Down No memory
%BGP_SESSION-5-ADJCHANGE: neighbor 10.x.x.x IPv4 Unicast vpn vrf IT
topology base removed from session No memory
%BGP-5-ADJCHANGE: neighbor 6x.x.x.x Down No memory
%BGP_SESSION-5-ADJCHANGE: neighbor 6x.x.x.x IPv4 Unicast topology base
removed from session No memory ...
Mack McBride ??:
I am looking at 2 - 7600s with RSP720-3CXLs w/ 4GB of RAM and 6708-3CXL
cards running SRD3.
These are not currently production equipment but are connected to
upstreams
as well as route-reflectors but are not advertising routes as we have
advertisements blocked
with a deny-all prefix list. We THINK the dumped BGP packet is
correctly formatted and
the packet dumped is actually the packet before the bad packet. Has
anyone else
seen similar issues? Does anyone else know if this is a known bug that
exists in this code or
early versions of the SRD train? I know there are entirely too many
caveats in SRC5.
Mack McBride
Network Architect
ViaWest, Inc.
We had the following errors occur:
Log from 7600-01:
Nov 24 02:41:59.696 MST: %BGP-5-ADJCHANGE: neighbor 207.xx.xx.xx Down
BGP Notification sent
Nov 24 02:41:59.696 MST: %BGP-3-NOTIFICATION: sent to neighbor
207.xx.xx.xx 3/1 (update malformed) 0 bytes
Nov 24 02:41:59.696 MST: %BGP-4-MSGDUMP: unsupported or mal-formatted
message received from 207.xx.xx.xx:
0064 0200 4940 0101 0040
0208 0203
10E3 00AE 0865 4003 04CF FA73 1540 0600 C007 0608 659A 3604 36C0 0824
10E3 0033
10E3 01F5 10E3 03F7 10E3 09C7 10E3 C350 FE4D 03F7 FE4E 0004 FE4F 0001
FE50 012D
18C0 2104
Nov 24 02:41:59.748 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx1 Down
No memory
Nov 24 02:41:59.748 MST: %BGP_SESSION-5-ADJCHANGE: neighbor
74.xx.xx.xx1 IPv4 Unicast topology base removed from session No memory
Nov 24 02:41:59.748 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx2 Down
No memory
Nov 24 02:41:59.748 MST: %BGP_SESSION-5-ADJCHANGE: neighbor
74.xx.xx.xx2 IPv4 Unicast topology base removed from session No memory
Nov 24 02:41:59.748 MST: %BGP_SESSION-5-ADJCHANGE: neighbor
207.xx.xx.xx IPv4 Unicast topology base removed from session BGP
Notification sent
Nov 24 02:42:06.384 MST: %BGP-5-ADJCHANGE: neighbor 207.xx.xx.xx Up
Nov 24 02:42:12.640 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx2 Up
Nov 24 02:42:12.672 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx1 Up
Nov 24 02:42:31.436 MST: %BGP-5-ADJCHANGE: neighbor 207.xx.xx.xx Down
BGP Notification sent
Nov 24 02:42:31.436 MST: %BGP-3-NOTIFICATION: sent to neighbor
207.xx.xx.xx 3/1 (update malformed) 0 bytes
Nov 24 02:42:31.440 MST: %BGP-4-MSGDUMP: unsupported or mal-formatted
message received from 207.xx.xx.xx:
0064 0200 4940 0101 0040
0208 0203
10E3 00AE 0865 4003 04CF FA73 1540 0600 C007 0608 659A 3604 42C0 0824
10E3 0033
10E3 01F5 10E3 03F7 10E3 09C7 10E3 C350 FE4D 03F7 FE4E 0004 FE4F 0001
FE50 012D
18C0 2104
Nov 24 02:42:31.504 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx1 Down
No memory
Nov 24 02:42:31.504 MST: %BGP_SESSION-5-ADJCHANGE: neighbor
74.xx.xx.xx1 IPv4 Unicast topology base removed from session No memory
Nov 24 02:42:31.504 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx2 Down
No memory
Nov 24 02:42:31.504 MST: %BGP_SESSION-5-ADJCHANGE: neighbor
74.xx.xx.xx2 IPv4 Unicast topology base removed from session No memory
Nov 24 02:42:31.504 MST: %BGP_SESSION-5-ADJCHANGE: neighbor
207.xx.xx.xx IPv4 Unicast topology base removed from session BGP
Notification sent
Nov 24
Re: [c-nsp] strange ipv6 problems on 3550 SVI
Hi. According to my tests, IPv6 is somewhat supported on the 3550 with 12.2(44)SE1 and SE2, however only in software. The switch can send out IPv6 packets (that's why you are seeing EIGRP adjacency established for a short time) but cannot receive any (that's why EIGRP adjacency is flapping), which means it drops inbound IPv6 packets sent to the switch itself because the hardware seemingly cannot understand them. I also checked this behavior with Wireshark. debug ipv6 packet Mar 22 15:38:43: IPV6: source 2001:::::2 (local) Mar 22 15:38:43: dest FF02::1:FF00:2 (Vlan2) Mar 22 15:38:43: traffic class 224, flow 0x0, len 72+8, prot 58, hops 255, originating Mar 22 15:38:43: IPv6: Sending on Vlan2 The interesting part is that IPv6 tunneling (GRE mode, because ipv6ip mode cannot be selected) is working on the 3550 with the above IOS versions. Enable ipv6 unicast-routing and create a tunnel interface, assign an IPv6 address to it and set an IPv6 capable router's IPv4 address as the tunnel destination. It will work because the switch will receive IPv4 packets and the IPv6 packets encapsulated into them are processed by the CPU. ipv6 unicast-routing interface Tunnel6 no ip address ipv6 address 2001::::6::2/112 ipv6 enable tunnel source 192.168.1.5 tunnel destination 192.168.1.7 end ipv6 route ::/0 2001::::6::1 c3550#ping 2001:::::1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:::::1, timeout is 2 seconds: ! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms Best regards, Andras On Fri, Mar 19, 2010 at 5:22 PM, Matthew Huff mh...@ox.com wrote: Bingo! Yes, I agree, it's worse. I knew the 3550 only did ipv6 in software, but this was going to be a low packet count test. Something things seem to work, but not really. Oh well, that division budgets won't be available to upgrade that switch until after Sept 2011, so it will have to wait. ___ 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] per-user static routes getting stuck
On Mon, 22 Mar 2010, Jess Kitchen wrote: I've had precisely the same problem on 12.3(23), didn't try (26). I moved several customers off mainline and onto 12.2SB, but then quickly went to 12.4t, on account of (20) having the 'same' cef guts that SB was blessed with (and 20k idb's on 7200). Interestingly, year+ uptime on 12.4(20)T in the same places has not resulted in stuck fib entries, no missing fib entries, and aaa/radius hasn't missed a beat. curious whether theres any difference if you're using Framed-Route as opposed to ip:route .. in a Cisco-AVPair attribute? bizarre behaviour in any case The one in my case is a Framed-Route. I haven't tried the other way. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] per-user static routes getting stuck
On Mon, 22 Mar 2010, Anton Kapela wrote: to clear the /30 is to enter the route into the config, and then remove it from the config. With an uptime of 2.5 years, I should probably just upgrade to 12.3(26) and reboot...but I wonder if anyone else has seen this? I've had precisely the same problem on 12.3(23), didn't try (26). I moved several customers off mainline and onto 12.2SB, but then quickly went to 12.4t, on account of (20) having the 'same' cef guts that SB was blessed with (and 20k idb's on 7200). Interestingly, year+ uptime on 12.4(20)T in the same places has not resulted in stuck fib entries, no missing fib entries, and aaa/radius hasn't missed a beat. curious whether theres any difference if you're using Framed-Route as opposed to ip:route .. in a Cisco-AVPair attribute? bizarre behaviour in any case ___ 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] Odd problem with bgp resets on SRD3
this is definitely this bug. Disabling solves the problem
Regards,
Jan
Paolo Lucente schrieb:
Perhaps it's CSCtd26215. If BGP dampening is enabled, give a try disabling
it.
Cheers,
Paolo
On Mon, Mar 22, 2010 at 01:02:59PM +0200, teslenko.and...@gmail.com wrote:
Hello all,
We have faced the same problem when we have tried to update to version
SRD4.
Our hardware is Cisco 7600 with RSP720-3CXL-GE with 2GB RAM and
WS-X6704-10GE.
We have observed the bgp notification in logging such as neighbor
1xx.x.x.x 3/1 (update malformed).
The all sessions get down after that with message Down No memory
Who was faced with such problem also? How to solve it?
We had the following errors log occur:
%BGP-5-ADJCHANGE: neighbor 1xx.x.x.x Down BGP Notification sent
%BGP-3-NOTIFICATION: sent to neighbor 1xx.x.x.x 3/1 (update malformed) 0
bytes
%BGP-4-MSGDUMP: unsupported or mal-formatted message received from
1xx.x.x.x: 004F 0200 3440
0101 0040 0208 0203 00AE 04D7 8F11 4003 0495 068D A980 0404 0001 4C26
4006 00C0 0706 8F11 D018 1489 C008 0800 AE52 0800 AE55 FD18 C029 A2
%BGP-5-ADJCHANGE: neighbor 10.x.x.x vpn vrf XX Down No memory
%BGP_SESSION-5-ADJCHANGE: neighbor 10.x.x.x IPv4 Unicast vpn vrf IT
topology base removed from session No memory
%BGP-5-ADJCHANGE: neighbor 6x.x.x.x Down No memory
%BGP_SESSION-5-ADJCHANGE: neighbor 6x.x.x.x IPv4 Unicast topology base
removed from session No memory ...
Mack McBride ??:
I am looking at 2 - 7600s with RSP720-3CXLs w/ 4GB of RAM and 6708-3CXL cards
running SRD3.
These are not currently production equipment but are connected to upstreams
as well as route-reflectors but are not advertising routes as we have
advertisements blocked
with a deny-all prefix list. We THINK the dumped BGP packet is correctly
formatted and
the packet dumped is actually the packet before the bad packet. Has anyone else
seen similar issues? Does anyone else know if this is a known bug that exists
in this code or
early versions of the SRD train? I know there are entirely too many caveats in
SRC5.
Mack McBride
Network Architect
ViaWest, Inc.
We had the following errors occur:
Log from 7600-01:
Nov 24 02:41:59.696 MST: %BGP-5-ADJCHANGE: neighbor 207.xx.xx.xx Down BGP
Notification sent
Nov 24 02:41:59.696 MST: %BGP-3-NOTIFICATION: sent to neighbor 207.xx.xx.xx 3/1
(update malformed) 0 bytes
Nov 24 02:41:59.696 MST: %BGP-4-MSGDUMP: unsupported or mal-formatted message
received from 207.xx.xx.xx:
0064 0200 4940 0101 0040 0208 0203
10E3 00AE 0865 4003 04CF FA73 1540 0600 C007 0608 659A 3604 36C0 0824 10E3 0033
10E3 01F5 10E3 03F7 10E3 09C7 10E3 C350 FE4D 03F7 FE4E 0004 FE4F 0001 FE50 012D
18C0 2104
Nov 24 02:41:59.748 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx1 Down No memory
Nov 24 02:41:59.748 MST: %BGP_SESSION-5-ADJCHANGE: neighbor 74.xx.xx.xx1 IPv4
Unicast topology base removed from session No memory
Nov 24 02:41:59.748 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx2 Down No memory
Nov 24 02:41:59.748 MST: %BGP_SESSION-5-ADJCHANGE: neighbor 74.xx.xx.xx2 IPv4
Unicast topology base removed from session No memory
Nov 24 02:41:59.748 MST: %BGP_SESSION-5-ADJCHANGE: neighbor 207.xx.xx.xx IPv4
Unicast topology base removed from session BGP Notification sent
Nov 24 02:42:06.384 MST: %BGP-5-ADJCHANGE: neighbor 207.xx.xx.xx Up
Nov 24 02:42:12.640 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx2 Up
Nov 24 02:42:12.672 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx1 Up
Nov 24 02:42:31.436 MST: %BGP-5-ADJCHANGE: neighbor 207.xx.xx.xx Down BGP
Notification sent
Nov 24 02:42:31.436 MST: %BGP-3-NOTIFICATION: sent to neighbor 207.xx.xx.xx 3/1
(update malformed) 0 bytes
Nov 24 02:42:31.440 MST: %BGP-4-MSGDUMP: unsupported or mal-formatted message
received from 207.xx.xx.xx:
0064 0200 4940 0101 0040 0208 0203
10E3 00AE 0865 4003 04CF FA73 1540 0600 C007 0608 659A 3604 42C0 0824 10E3 0033
10E3 01F5 10E3 03F7 10E3 09C7 10E3 C350 FE4D 03F7 FE4E 0004 FE4F 0001 FE50 012D
18C0 2104
Nov 24 02:42:31.504 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx1 Down No memory
Nov 24 02:42:31.504 MST: %BGP_SESSION-5-ADJCHANGE: neighbor 74.xx.xx.xx1 IPv4
Unicast topology base removed from session No memory
Nov 24 02:42:31.504 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx2 Down No memory
Nov 24 02:42:31.504 MST: %BGP_SESSION-5-ADJCHANGE: neighbor 74.xx.xx.xx2 IPv4
Unicast topology base removed from session No memory
Nov 24 02:42:31.504 MST: %BGP_SESSION-5-ADJCHANGE: neighbor 207.xx.xx.xx IPv4
Unicast topology base removed from session BGP Notification sent
Nov 24 02:42:38.620 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx2 Up
Nov 24 02:42:38.620 MST: %BGP-5-ADJCHANGE: neighbor 207.xx.xx.xx Up
Nov 24 02:42:42.928 MST: %BGP-5-ADJCHANGE: neighbor 74.xx.xx.xx1 Up
7600-02:
Nov 24 02:42:16.343 MST: %BGP-5-ADJCHANGE: neighbor 4.xx.xx.xx Down BGP
Notification sent
Nov 24 02:42:16.343
[c-nsp] ASR 1002-F BGP table size
I'm having a hard (impossible) time locating performance and BGP specs for the ASR 1002-F. Since it has a not really an ESP built-in, the ESP5/10/20 specs aren't helping me a lot. Other than it should have ~2.5Gbs forwarding (full-duplex?), I'can't find anything definitive on it. References keep coming up with the ASR-1002 with the removable ESP. I'm looking at replacing our upstream routers (7206-VXR/G1) on GigE links with something that can better handle D/DoS attacks. The original thought was to use a small 6500/Sup720. Empirical testing shows that Netflow (even with the table size under control) really beats up on the SP CPU. The ASR-1002F seems like it should fit the bill, but I found something (that I've now lost) that mentioned 500K routes. I'm looking for a device that: - is a lightbulb; relatively inexpensive, single-upstream - 3 GigE ports - 1 Gbs full-duplex (2Gbs total) hardware forwarding - uRPF - Netflow - 1,000,000+ IPv4 BGP routes - IPv6 support As an additional comment on the Sup720/Netflow, CPU on the SP hit ~30% with only a couple hundred Mbs and roughly 50% TCAM utilization. Is the ASR-1002F what I'm looking for? Can anybody direct me to 1002F (vs modular 1002) specs? Thanks, ___ 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] Sup720 CoPP, limits on CPU performance
Hi all, We recently had an experience that has convinced us CoPP might be a good idea. I know it's a little embarrassing that we haven't implemented CoPP yet, but now we're motivated. :-) We're graphing non-unicast packets in/out with Cacti and expect to work out a baseline from those numbers. As another viewpoint I'd like to know how I can assess what amount of traffic I can safely send to the Sup720 CPU. Would anyone have any numbers for that, i.e. how much broadcast I can safely allow in a CoPP policy if I were to not look at that baseline at all? (P.S: No, this network isn't Internet reachable, the experience was from an internal loop, the cause of which is being mitigated in other ways too.) -- Peter ___ 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] IPv6: Getting started
On Mon, 2010-03-22 at 14:38 +0300, Tima Maryin wrote: Why don't keep it ipv4? If you run MPLS VPN netowork i don't see why you want something else in core. MPLS don't care about ipv4/6 and PE just assign labels for prefix/vpn and distribute it to other PEs. For me it looks like double security here, if your core has no ipv6 i can't be accessed (read: hacked) from outside ipv6 world/vpns. It's no practical problem at all to keep the core IPv4. I was just curious about why a pure IPv6 MPLS network wasn't possible (yet, on Cisco boxen). That leads me to another thing: If we _could_ make the core run IPv6, and if we weren't using no mpls ip propagate-ttl, how would a traceroute from an IPv4-only machine work out? Would the core send ICMPv6 Time Exceeded back to the host, which would then just discard these unintelligible packets and show *s for that hop? -- Peter ___ 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] BLSR protection on long-haul OC-192 links
I'm putting together a regional four-node SONET network that will have two long-haul OC-192 fiber links. To provide path diversity, one leg will be about 450 miles longer than the other. Termination gear will be Cisco ONS-15454s and we will be running GigE circuits (protected) across the links. My concern is that with one leg being more than twice the length of the other, will BLSR still maintain a hitless transition in the event that one of the OC-192s fails? I asked Cisco this question and we went through several techs before it was escalated to their developers, who labbed it out and said it would work. This is a little disconcerting, since I seriously doubt I am the first to ask this question. Is there anyone out there who has done this and could could share their experience with this type of design? Thanks - ___ 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] Sup720 CoPP, limits on CPU performance
On (2010-03-22 19:05 +0100), Peter Rathlev wrote: As another viewpoint I'd like to know how I can assess what amount of traffic I can safely send to the Sup720 CPU. Would anyone have any numbers for that, i.e. how much broadcast I can safely allow in a CoPP policy if I were to not look at that baseline at all? SUP720-3BXL had issues to manage 5Mbps of SYN/BGP and generally 10Mbps of minimum size frames (about 20kpps) is what I could manage in 2006 with SRA without affecting IS-IS or LDP. I'd recommend very generic and simple CoPP 1) allow trusted sources, MGMT, core links, core loops 2) allow important untrusted SYN, eBGP neighbours 3) allow important untrusted, eBGP !SYN 4) allow unimportant icmp, udp traceroute, hsrp, vrrp, dns, ntp, dhcp, multicast 5) drop all remaining IP Unfortunately policing is for bps not pps. Also documentation is bit flaky, but IPv6 is supported (enable compression) and ARP is not supported. Also amount of MLS rate-limiters should be bit higher. Prior to deploying CoPP we very often used telnet from PE to customer mail server and such for troubleshooting, unfortunately with CoPP it's not very easy. It would be nice if IOS telnet would accept source port, so you could allow some low bps back to that port from every address. To workaround with this, on top of CoPP list we have CoPP-DENY and CoPP-PERMIT box specific hack ACL's where we can add ad'hoc entries. -- ++ytti ___ 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] Sup720 CoPP, limits on CPU performance
Dropping all remaining IP leads to some odd behavior since traffic not destined for the router can get process switched, that traffic would get dropped. It is better to drop unsolicited traffic aimed at router interface ips. And rate limit the remaining traffic to some reasonable level to allow process switched traffic to get through. LR Mack McBride Network Architect Viawest Inc. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Saku Ytti Sent: Monday, March 22, 2010 1:21 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Sup720 CoPP, limits on CPU performance On (2010-03-22 19:05 +0100), Peter Rathlev wrote: As another viewpoint I'd like to know how I can assess what amount of traffic I can safely send to the Sup720 CPU. Would anyone have any numbers for that, i.e. how much broadcast I can safely allow in a CoPP policy if I were to not look at that baseline at all? SUP720-3BXL had issues to manage 5Mbps of SYN/BGP and generally 10Mbps of minimum size frames (about 20kpps) is what I could manage in 2006 with SRA without affecting IS-IS or LDP. I'd recommend very generic and simple CoPP 1) allow trusted sources, MGMT, core links, core loops 2) allow important untrusted SYN, eBGP neighbours 3) allow important untrusted, eBGP !SYN 4) allow unimportant icmp, udp traceroute, hsrp, vrrp, dns, ntp, dhcp, multicast 5) drop all remaining IP Unfortunately policing is for bps not pps. Also documentation is bit flaky, but IPv6 is supported (enable compression) and ARP is not supported. Also amount of MLS rate-limiters should be bit higher. Prior to deploying CoPP we very often used telnet from PE to customer mail server and such for troubleshooting, unfortunately with CoPP it's not very easy. It would be nice if IOS telnet would accept source port, so you could allow some low bps back to that port from every address. To workaround with this, on top of CoPP list we have CoPP-DENY and CoPP-PERMIT box specific hack ACL's where we can add ad'hoc entries. -- ++ytti ___ 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] [in/ex]clude CE vlans with QinQ
I'm searching for a way to optionally include/exclude certain VLANs for a QinQ link. I have a vlan trunk coming from a distribution switch into a core switch which is attached to a L2 Service Provider. I'd like to encapsulate multiple (some but not all) Customer (CE) Vlans from the distribution switch into QinQ vlans SP vlan. For example, I'd like to encapsulated CE vlans 10-20 into SP vlan 100, and CE vlans 21-30 from the distribution switch into SP vlan 200, etc. Other than creating multiple trunks from the distro switch to the core, are there any other suggestions? Thanks, Chris ___ 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] Sup720 CoPP, limits on CPU performance
On (2010-03-22 12:45 -0700), Mack McBride wrote: Dropping all remaining IP leads to some odd behavior since traffic not destined for the router can get process switched, that traffic would get dropped. It is better to drop unsolicited traffic aimed at router interface ips. And rate limit the remaining traffic to some reasonable level to allow process switched traffic to get through. Such traffic could be e.g. uRPF ACL, or ACL permit entry with log, neither which I do. Also IP options naturally are process switched, which I police to 10pps. Generally prerequisite for control plane policing is understanding explicitly what the box is doing. If you need to generally forward something in software in 7600, you are likely using wrong box. If you don't know for sure what needs to be allowed, only thing you're doing is putting bad and good traffic in same queue, making box drop the good traffic earlier than it would do without CoPP. -- ++ytti ___ 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] [in/ex]clude CE vlans with QinQ
Get a device that supports selective QinQ/vlan mapping/etc (ME-3400, ME-3750, 7600/CWAN cards, etc). -- Tassos Christopher Hunt wrote on 22/03/2010 21:54: I'm searching for a way to optionally include/exclude certain VLANs for a QinQ link. I have a vlan trunk coming from a distribution switch into a core switch which is attached to a L2 Service Provider. I'd like to encapsulate multiple (some but not all) Customer (CE) Vlans from the distribution switch into QinQ vlans SP vlan. For example, I'd like to encapsulated CE vlans 10-20 into SP vlan 100, and CE vlans 21-30 from the distribution switch into SP vlan 200, etc. Other than creating multiple trunks from the distro switch to the core, are there any other suggestions? Thanks, Chris ___ 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] Sup720 CoPP, limits on CPU performance
On 03/22/2010 07:21 PM, Saku Ytti wrote: On (2010-03-22 19:05 +0100), Peter Rathlev wrote: As another viewpoint I'd like to know how I can assess what amount of traffic I can safely send to the Sup720 CPU. Would anyone have any numbers for that, i.e. how much broadcast I can safely allow in a CoPP policy if I were to not look at that baseline at all? SUP720-3BXL had issues to manage 5Mbps of SYN/BGP and generally 10Mbps of minimum size frames (about 20kpps) is what I could manage in 2006 with SRA without affecting IS-IS or LDP. I'd recommend very generic and simple CoPP 1) allow trusted sources, MGMT, core links, core loops 2) allow important untrusted SYN, eBGP neighbours 3) allow important untrusted, eBGP !SYN 4) allow unimportant icmp, udp traceroute, hsrp, vrrp, dns, ntp, dhcp, multicast 5) drop all remaining IP In general this is a reasonable starting point, but the OP should be aware that traffic which is not destined to the box, most notably packets punted to CPU for arp lookup (glean) have CoPP applied, so a deny on any particular class of traffic will mean packets matching the ACL can never trigger a glean lookup. Whether this is important or not will depend on your traffic patterns; it makes default-denying SSH if you have unix boxes tricky, for example. ___ 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] BLSR protection on long-haul OC-192 links
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/22/2010 2:54 PM, Bit Bucket wrote: I'm putting together a regional four-node SONET network that will have two long-haul OC-192 fiber links. To provide path diversity, one leg will be about 450 miles longer than the other. Termination gear will be Cisco ONS-15454s and we will be running GigE circuits (protected) across the links. My concern is that with one leg being more than twice the length of the other, will BLSR still maintain a hitless transition in the event that one of the OC-192s fails? I asked Cisco this question and we went through several techs before it was escalated to their developers, who labbed it out and said it would work. This is a little disconcerting, since I seriously doubt I am the first to ask this question. Is there anyone out there who has done this and could could share their experience with this type of design? Thanks - ___ 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/ Stab in the dark here if we assume that latency is caused purely by photonic delay, at 725Km, the one-way latency would be about 3.45msec, well within SONET's targetted 50msec switch window. My calculations: 725Km/.7c = 3.45msec Or am I way off? Interesting problem. Let us know how it goes. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkunxOwACgkQQr/gMVyFYyTWYQCgjloTvbtQWK7UAWDM7yB0iDMB Cw8Amwalo6RFdW+0e1BSBYtnBkXC0cG9 =uShU -END 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] 6500 nvram contents changing
Mon, Mar 22, 2010 at 09:27:35AM +, Ben Cooper: John, It looks like Jared was correct, we had another instance of rancid running on another box a roughly the same time, I shifted the the cron job forward 30 minutes, and the diffs have stopped. i can't reproduce it. if anyone knows the error that the cli displays when this contention occurs, please e-mail the info to me so that i can fix rancid to deal with it. ___ 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] Sup720 CoPP, limits on CPU performance
On (2010-03-22 20:49 +), Phil Mayers wrote: In general this is a reasonable starting point, but the OP should be aware that traffic which is not destined to the box, most notably packets punted to CPU for arp lookup (glean) have CoPP applied, so a deny on any particular class of traffic will mean packets matching the ACL can never trigger a glean lookup. Whether this is important or not will depend on your traffic patterns; it makes default-denying SSH if you have unix boxes tricky, for example. I should add that certain traffic patterns exacerbate this; for example we came across it in HSRP setups where inbound traffic comes in via the HSRP slave, and only the master had a current ARP entry. Only possible explanation I can think of this is that you've been running deny in 'class-default', defining 'class-default' is not good idea, but explicitly having class to match all IP via ACL and drop packets in that class. Class-default in software likely will see ARP as you explain, but that is not even the biggest problem, using class-default will eat MPLS label lookup from superman (as it'll also match MPLS labeled packets), causing recirculation for your L3 MPLS VPN customers. Also people who run IS-IS would be rather sad if class-default would be configured to drop everything. -- ++ytti ___ 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] Sup720 CoPP, limits on CPU performance
Can any provide links to good documentation? I've read through the cisco docs, but I'm interested in reading about other folks implementations. Jimmy Changa via Droid On Mar 22, 2010 4:52 PM, Phil Mayers p.may...@imperial.ac.uk wrote: On 03/22/2010 07:21 PM, Saku Ytti wrote: On (2010-03-22 19:05 +0100), Peter Rathlev wrote: ... In general this is a reasonable starting point, but the OP should be aware that traffic which is not destined to the box, most notably packets punted to CPU for arp lookup (glean) have CoPP applied, so a deny on any particular class of traffic will mean packets matching the ACL can never trigger a glean lookup. Whether this is important or not will depend on your traffic patterns; it makes default-denying SSH if you have unix boxes tricky, for example. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net h... ___ 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] ASR 1002-F BGP table size
Hi Rick, Here is a quick comparison. The Cisco ASR 1002-F has RP1 with 1G RAM, ESP 2.5 with 1G RAM (2.5Gbps bandwidth), SIP-10, 1SPA, and 4 GE ports built in chassis, running IOS-XE and has SW redundancy via VM, capcable to have 500K IPv4 and 125K Ipv6 The Cisco ASR1002 has 1 RP1 integrated in the chassis comes with 4GB RAM by default, 1 ESP slot for ESP5/10 to provide 5Gbps/10Gbps bandwidth, it also has 4-built in GE-ports, 3 SPA ports, running IOS XE and has SW redundancy via VM. On Mon, Mar 22, 2010 at 7:30 PM, Rick Ernst c...@shreddedmail.com wrote: I'm having a hard (impossible) time locating performance and BGP specs for the ASR 1002-F. Since it has a not really an ESP built-in, the ESP5/10/20 specs aren't helping me a lot. Other than it should have ~2.5Gbs forwarding (full-duplex?), I'can't find anything definitive on it. References keep coming up with the ASR-1002 with the removable ESP. I'm looking at replacing our upstream routers (7206-VXR/G1) on GigE links with something that can better handle D/DoS attacks. The original thought was to use a small 6500/Sup720. Empirical testing shows that Netflow (even with the table size under control) really beats up on the SP CPU. The ASR-1002F seems like it should fit the bill, but I found something (that I've now lost) that mentioned 500K routes. I'm looking for a device that: - is a lightbulb; relatively inexpensive, single-upstream - 3 GigE ports - 1 Gbs full-duplex (2Gbs total) hardware forwarding - uRPF - Netflow - 1,000,000+ IPv4 BGP routes - IPv6 support As an additional comment on the Sup720/Netflow, CPU on the SP hit ~30% with only a couple hundred Mbs and roughly 50% TCAM utilization. Is the ASR-1002F what I'm looking for? Can anybody direct me to 1002F (vs modular 1002) specs? Thanks, ___ 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/ -- Mounir Mohamed, CCIE No.19573(RS, SP) Senior Network Engineer, Core Team NOOR Data Networks, SAE http://mounirmohamed.wordpress.com http://www.linkedin.com/in/mounirmohamed ___ 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] Sup720 CoPP, limits on CPU performance
On Mon, Mar 22, 2010 at 5:35 PM, Saku Ytti s...@ytti.fi wrote: On (2010-03-22 20:49 +), Phil Mayers wrote: In general this is a reasonable starting point, but the OP should be aware that traffic which is not destined to the box, most notably packets punted to CPU for arp lookup (glean) have CoPP applied, so a deny on any particular class of traffic will mean packets matching the ACL can never trigger a glean lookup. Whether this is important or not will depend on your traffic patterns; it makes default-denying SSH if you have unix boxes tricky, for example. I should add that certain traffic patterns exacerbate this; for example we came across it in HSRP setups where inbound traffic comes in via the HSRP slave, and only the master had a current ARP entry. Only possible explanation I can think of this is that you've been running deny in 'class-default', defining 'class-default' is not good idea, but explicitly having class to match all IP via ACL and drop packets in that class. Class-default in software likely will see ARP as you explain, but that is not even the biggest problem, using class-default will eat MPLS label lookup from superman (as it'll also match MPLS labeled packets), causing recirculation for your L3 MPLS VPN customers. Also people who run IS-IS would be rather sad if class-default would be configured to drop everything. -- ++ytti ___ 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/ CoPP is quite challenging on the 6500. We've finally come down to a class per protocol. Some oddities include bfd not matching acl entries but apparently matching the class and being policed correctly (is this because bfd runs on the sp?) Not being able to differntiate receive from glean traffic is a huge problem. This makes it difficult/impossible to permit approved control plane traffic, then deny everything else. If you do, glean traffic won't hit the control plane, causing arp failures. Not fun. According to N7K docs, this is all fixed in EARL8... -- Tim: ___ 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] Unicast traffic being sent to every port? Aging issue?
We have two Dell PowerConnect M6220 switches (A1 and B1). They are not cross-connected, but both have uplinks to the same subnet: zfs1 / ++ | A1 |-| ++ +---+ | Cisco |--- linux1 ++ +---+ | B1 |-| ++ / \ esx1 esx2 There's a host hanging off of A1 (zfs1) and several ESX hosts hanging off of B1 (esx1, esx2, etc). There's a host linux1 hanging off the Cisco as well (actually many hosts, but for the sake of description What's happening is, esx1/2 beging talking to zfs1. All is well for a while... but at some point, zfs1's MAC address expires from the CAM on the switch (I guess that is what is happening). At that point, the Cisco begins forwarding the unicast packets to all its ports. The result -- linux1, and all other hosts see the packets. Occasionally, when we're dealing with a lot of traffic, this seriously impacts performance. My question here is.. what is the _right_ way to deal with this? This flooding can continue for many minutes at a time.. it isn't until an ARP reply eminates from zfs1 that the CAM table is populated again and the broadcasting stops. I wonder if zfs1 would send back an ARP response quicker were it not behind an additional switch (the PowerConnect)... Thanks, Ray ___ 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] Unicast traffic being sent to every port? Aging issue?
On 3/22/10 7:03 PM, Ray Van Dolson wrote: We have two Dell PowerConnect M6220 switches (A1 and B1). They are not cross-connected, but both have uplinks to the same subnet: zfs1 / ++ | A1 |-| ++ +---+ | Cisco |--- linux1 ++ +---+ | B1 |-| ++ / \ esx1 esx2 There's a host hanging off of A1 (zfs1) and several ESX hosts hanging off of B1 (esx1, esx2, etc). There's a host linux1 hanging off the Cisco as well (actually many hosts, but for the sake of description What's happening is, esx1/2 beging talking to zfs1. All is well for a while... but at some point, zfs1's MAC address expires from the CAM on the switch (I guess that is what is happening). At that point, the Cisco begins forwarding the unicast packets to all its ports. The result -- linux1, and all other hosts see the packets. Occasionally, when we're dealing with a lot of traffic, this seriously impacts performance. Is the Cisco a router or a layer 2 switch? All hosts in the same IP subnet? Subnet masks all match? Nothing doing proxy-arp? My question here is.. what is the _right_ way to deal with this? This flooding can continue for many minutes at a time.. it isn't until an ARP reply eminates from zfs1 that the CAM table is populated again and the broadcasting stops. If these are layer 2 switches, ARP won't have anything to do with it. If zfs1's MAC expires from the MAC address table on the cisco, it will flood the next packet for that MAC. A1 will forward it to zfs1 or flood if it too has expired the MAC. When zfs1 replies, A1 forwards the reply to the cisco. At that point, the cisco should re-install the MAC into its address table and the flooding cease. This should happen with a single packet. Does this happen with any other hosts behind A1? Any interface errors on any of the devices? I wonder if zfs1 would send back an ARP response quicker were it not behind an additional switch (the PowerConnect)... If layer 2 switches, ARP doesn't have anything to do with it. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ 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] Unicast traffic being sent to every port? Aging issue?
On Mon, Mar 22, 2010 at 08:04:10PM -0700, Jay Hennigan wrote: On 3/22/10 7:03 PM, Ray Van Dolson wrote: We have two Dell PowerConnect M6220 switches (A1 and B1). They are not cross-connected, but both have uplinks to the same subnet: zfs1 / ++ | A1 |-| ++ +---+ | Cisco |--- linux1 ++ +---+ | B1 |-| ++ / \ esx1 esx2 There's a host hanging off of A1 (zfs1) and several ESX hosts hanging off of B1 (esx1, esx2, etc). There's a host linux1 hanging off the Cisco as well (actually many hosts, but for the sake of description What's happening is, esx1/2 beging talking to zfs1. All is well for a while... but at some point, zfs1's MAC address expires from the CAM on the switch (I guess that is what is happening). At that point, the Cisco begins forwarding the unicast packets to all its ports. The result -- linux1, and all other hosts see the packets. Occasionally, when we're dealing with a lot of traffic, this seriously impacts performance. Is the Cisco a router or a layer 2 switch? All hosts in the same IP subnet? Subnet masks all match? Nothing doing proxy-arp? My question here is.. what is the _right_ way to deal with this? This flooding can continue for many minutes at a time.. it isn't until an ARP reply eminates from zfs1 that the CAM table is populated again and the broadcasting stops. If these are layer 2 switches, ARP won't have anything to do with it. If zfs1's MAC expires from the MAC address table on the cisco, it will flood the next packet for that MAC. A1 will forward it to zfs1 or flood if it too has expired the MAC. When zfs1 replies, A1 forwards the reply to the cisco. At that point, the cisco should re-install the MAC into its address table and the flooding cease. This should happen with a single packet. Does this happen with any other hosts behind A1? Any interface errors on any of the devices? I wonder if zfs1 would send back an ARP response quicker were it not behind an additional switch (the PowerConnect)... If layer 2 switches, ARP doesn't have anything to do with it. I'll have to find out how the Cisco's are configured. I wouldn't be surprised if they're doing some Layer 3 though as I know some VLAN routing is going on... The Dell switches both seem to have Routing Mode enabled as well (but proxy arp disabled). There currently aren't any other hosts behind A1, but that would be a good test. No interface errors currently. Firmware is old on A1, so at this point I'm a little suspicious it's to blame. Just wanted to try and wrap my head around this first. Thanks, Ray ___ 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] Unicast traffic being sent to every port? Aging issue?
Long ago, I had this problem but the zfs1 in this case was a syslog server. What was happening was, all the hosts were sending traffic to the server but since it was just receiving syslog/UDP, that host rarely ever sent any traffic back out. So switches didn't know where it was once the forwarding table expired the MAC and flooded all ports. We just setup a cron job every 10 minutes (or something. It was 13 years ago.) to send out a ping to the host connected to the farthest switch. So, I guess it kind of depends on what traffic is going/coming from zfs1. If it's like syslog, it may be the same as what I went through. On Mon, Mar 22, 2010 at 11:14 PM, Ray Van Dolson rvandol...@esri.com wrote: On Mon, Mar 22, 2010 at 08:04:10PM -0700, Jay Hennigan wrote: On 3/22/10 7:03 PM, Ray Van Dolson wrote: We have two Dell PowerConnect M6220 switches (A1 and B1). They are not cross-connected, but both have uplinks to the same subnet: zfs1 / ++ | A1 |-| ++ +---+ | Cisco |--- linux1 ++ +---+ | B1 |-| ++ / \ esx1 esx2 There's a host hanging off of A1 (zfs1) and several ESX hosts hanging off of B1 (esx1, esx2, etc). There's a host linux1 hanging off the Cisco as well (actually many hosts, but for the sake of description What's happening is, esx1/2 beging talking to zfs1. All is well for a while... but at some point, zfs1's MAC address expires from the CAM on the switch (I guess that is what is happening). At that point, the Cisco begins forwarding the unicast packets to all its ports. The result -- linux1, and all other hosts see the packets. Occasionally, when we're dealing with a lot of traffic, this seriously impacts performance. Is the Cisco a router or a layer 2 switch? All hosts in the same IP subnet? Subnet masks all match? Nothing doing proxy-arp? My question here is.. what is the _right_ way to deal with this? This flooding can continue for many minutes at a time.. it isn't until an ARP reply eminates from zfs1 that the CAM table is populated again and the broadcasting stops. If these are layer 2 switches, ARP won't have anything to do with it. If zfs1's MAC expires from the MAC address table on the cisco, it will flood the next packet for that MAC. A1 will forward it to zfs1 or flood if it too has expired the MAC. When zfs1 replies, A1 forwards the reply to the cisco. At that point, the cisco should re-install the MAC into its address table and the flooding cease. This should happen with a single packet. Does this happen with any other hosts behind A1? Any interface errors on any of the devices? I wonder if zfs1 would send back an ARP response quicker were it not behind an additional switch (the PowerConnect)... If layer 2 switches, ARP doesn't have anything to do with it. I'll have to find out how the Cisco's are configured. I wouldn't be surprised if they're doing some Layer 3 though as I know some VLAN routing is going on... The Dell switches both seem to have Routing Mode enabled as well (but proxy arp disabled). There currently aren't any other hosts behind A1, but that would be a good test. No interface errors currently. Firmware is old on A1, so at this point I'm a little suspicious it's to blame. Just wanted to try and wrap my head around this first. Thanks, Ray ___ 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] Unicast traffic being sent to every port? Aging issue?
What's happening is, esx1/2 beging talking to zfs1. All is well for a while... but at some point, zfs1's MAC address expires from the CAM on the switch (I guess that is what is happening). Great, this is a good step; however, you need to have valid data to backup your theory! Have you logged into the switch to verify the MAC is expiring? At that point, the Cisco begins forwarding the unicast packets to all its ports. The result -- linux1, and all other hosts see the packets. Occasionally, when we're dealing with a lot of traffic, this seriously impacts performance. Have you conducted any packet captures (Wireshark is your friend). My question here is.. what is the _right_ way to deal with this? This flooding can continue for many minutes at a time.. it isn't until an ARP reply eminates from zfs1 that the CAM table is populated again and the broadcasting stops. When did this start? Is this a new environment? What was changed in the network? Was anything added? Have you released a new application or released an update to the application? There are many questions to be asked as a first step. You state that performance is impacted; very possible you have a broadcast storm (Check the broadcast counters on the interfaces [what is the cpu utilization like on the switches?]), bad NIC on a server, many possibilities here. What makes you think that flooding is occurring to a point that is causing performance issues? IMHO, your first start is to check the status of all switches during the issue and also start capturing packets utilizing wireshark on the hosts and/or possibly SPAN a port on the Cisco/Dells. Good Luck E.B ___ 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] Unicast traffic being sent to every port? Aging issue?
On 3/22/2010 11:14 PM, Ray Van Dolson wrote: On Mon, Mar 22, 2010 at 08:04:10PM -0700, Jay Hennigan wrote: On 3/22/10 7:03 PM, Ray Van Dolson wrote: We have two Dell PowerConnect M6220 switches (A1 and B1). They are not cross-connected, but both have uplinks to the same subnet: zfs1 / ++ | A1 |-| ++ +---+ | Cisco |--- linux1 ++ +---+ | B1 |-| ++ / \ esx1 esx2 There's a host hanging off of A1 (zfs1) and several ESX hosts hanging off of B1 (esx1, esx2, etc). There's a host linux1 hanging off the Cisco as well (actually many hosts, but for the sake of description What's happening is, esx1/2 beging talking to zfs1. All is well for a while... but at some point, zfs1's MAC address expires from the CAM on the switch (I guess that is what is happening). At that point, the Cisco begins forwarding the unicast packets to all its ports. The result -- linux1, and all other hosts see the packets. Occasionally, when we're dealing with a lot of traffic, this seriously impacts performance. Is the Cisco a router or a layer 2 switch? All hosts in the same IP subnet? Subnet masks all match? Nothing doing proxy-arp? My question here is.. what is the _right_ way to deal with this? This flooding can continue for many minutes at a time.. it isn't until an ARP reply eminates from zfs1 that the CAM table is populated again and the broadcasting stops. If these are layer 2 switches, ARP won't have anything to do with it. If zfs1's MAC expires from the MAC address table on the cisco, it will flood the next packet for that MAC. A1 will forward it to zfs1 or flood if it too has expired the MAC. When zfs1 replies, A1 forwards the reply to the cisco. At that point, the cisco should re-install the MAC into its address table and the flooding cease. This should happen with a single packet. Does this happen with any other hosts behind A1? Any interface errors on any of the devices? I wonder if zfs1 would send back an ARP response quicker were it not behind an additional switch (the PowerConnect)... If layer 2 switches, ARP doesn't have anything to do with it. I'll have to find out how the Cisco's are configured. I wouldn't be surprised if they're doing some Layer 3 though as I know some VLAN routing is going on... The Dell switches both seem to have Routing Mode enabled as well (but proxy arp disabled). There currently aren't any other hosts behind A1, but that would be a good test. No interface errors currently. Firmware is old on A1, so at this point I'm a little suspicious it's to blame. Just wanted to try and wrap my head around this first. Thanks, Ray ___ 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/ In other multivendor LAN setups, We've noticed similar behavior and enjoyed some success by synching the arp timers. That's worth a look if you haven't already followed that line of investigation. ___ 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] Unicast traffic being sent to every port? Aging issue?
On Mon, Mar 22, 2010 at 07:03:36PM -0700, Ray Van Dolson wrote: We have two Dell PowerConnect M6220 switches (A1 and B1). They are not cross-connected, but both have uplinks to the same subnet: zfs1 / ++ | A1 |-| ++ +---+ | Cisco |--- linux1 ++ +---+ | B1 |-| ++ / \ esx1 esx2 There's a host hanging off of A1 (zfs1) and several ESX hosts hanging off of B1 (esx1, esx2, etc). There's a host linux1 hanging off the Cisco as well (actually many hosts, but for the sake of description What's happening is, esx1/2 beging talking to zfs1. All is well for a while... but at some point, zfs1's MAC address expires from the CAM on the switch (I guess that is what is happening). At that point, the Cisco begins forwarding the unicast packets to all its ports. The result -- linux1, and all other hosts see the packets. Occasionally, when we're dealing with a lot of traffic, this seriously impacts performance. My question here is.. what is the _right_ way to deal with this? This flooding can continue for many minutes at a time.. it isn't until an ARP reply eminates from zfs1 that the CAM table is populated again and the broadcasting stops. I wonder if zfs1 would send back an ARP response quicker were it not behind an additional switch (the PowerConnect)... Well, I think I've nailed down the cause for this. Probably if I'd more completely described things some of you woulda pointed it out right away, but I was trying to keep the model simplistic. zfs1 is multi-homed. Two interfaces on the same subnet. Running Solaris 10 with no special source based routing setup I probably don't need to go any further, but, suffice it to say, packets destined for one interface on zfs1 were going in just fine, but the replies were going out the other interface -- with a different MAC address. So obviously the switches eventually lose track of the real MAC address and we get the symptoms I described. Probably can be corrected with ipfilter in Solaris or changing our infrastructure somewhat to handle this better. Thanks all who replied -- it was good to learn about unicast storms! Ray ___ 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/
