[c-nsp] l3 gateway redundancy without eating three ip addresses in the subnet
Is there a supported cisco method to provide gateway redundancy (hsrp, vrrp) without having to use three ip addresses from the same subnet? slb? Thanks, Joe ___ 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] ASA memory usage, finding a leak
Anyone know how to decipher a 'show proc mem' on an ASA (ver 7.2.3)? Seeing a memory loss of about 2MB per day on our 5520.I assumed that for a given process, 'Allocated' minus 'Freed' would give you how much it's still holding, but for some processes, this results in a negative number, and for others, it's a 500 megabyte difference (ASA only has 512MB total). I looked through the interim release notes for 7.2 versions, but can't view bug CSCsk49149, which involves ESMTP inspection which we're using. Any ideas? Thanks, Chuck xkjl-asa-01# sh proc mem Allocs Allocated Frees Freed Process (bytes) (bytes) 814 110755318 1040 *System Main* 1768 2 8324 tcp_fast 00 0 0 fover_rx 00 0 0 arp_forward_thread 224 309 166068arp_timer 00 0 0 emweb/cifs_timer 47 43551433448 NIC status poll 00 0 0 ssh/timer 283241258136 vpnlb_thread 140 0 0 update_cpu_usage 6503958 0 0 lu_ctl 36 182232 0 0 fover_thread 00 0 0 Integrity Fw Timer Thread 29 82415 4 65971 ci/console 00 2 32900 vpnfol_thread_unsent 00 0 0 557statspoll 614112 4 16648 Integrity FW Task 00 0 0 vpnfol_thread_sync 00 0 0 557mcfix 00 0 0 RADIUS Proxy Time Keeper 00 0 0 vpnfol_thread_timer 441600 0 RADIUS Proxy Listener 00 0 0 vpnfol_thread_msg 00 0 0 Thread Logger 00 0 0 RADIUS Proxy Event Daemon 00 0 0 dbgtrace 00 2 152 Logger 766121945372779708 19598025 IKE Daemon 986125 2372 NTP 00 0 0 SMTP 00 2 32900 IKE Timekeeper 148093309345 19706 3461749 dhcp_daemon 00 2 32900 pm_timer_thread 15 10212 110309882664tcp_thread 00 6 388 DHCPD Timer 00 0 0 uauth_urlb clean 4930 157760 0 0 udp_thread 30 75040 0 0 listen/ssh 22190265 889030472 22068368 756124316 snmp 00 0 0 Uauth_Proxy 00 0 0 Crypto CA 2661 2042924 2 204 icmp_thread 6142 554749 0 0 IKE Receiver 139 94298 3933343 accept/http 00 0 0 CMGR Timer Process 42440022 1466460 uauth 00 0 0 Crypto PKI RECV 386 23620 1 136 ARP Thread 442728 -650873128 0 0 listen/https 00 0 0 CMGR Server Process 681800 0 Session Manager 00 0 0 IP Thread 00 22239020qos_metric_daemon 4744 0 0 Quack process 682755456928 66733 5084698 tmatch compile thread 00 0 0 dns_process 108630 4865650 1086064850010 ssh 487 105524 319 102683aaa 00 0 0 IP Background 00 0 0 lu_dynamic_sync 00 0 0 dns_cache_timer 00 0 0 Reload Control Thread 00 0 0 ICMP event
Re: [c-nsp] SUP720 IOS Version
Latest 12.2(18)SXF(number) version on CCO. Are you going the 65xx route or the 76xx route moving forward? They split after SXF release. On Wed, Feb 20, 2008 at 10:46:50AM -0300, Juliano Luz - Sicredi wrote: We are currently in the process of selecting an IOS image for a new 6509 with SUP7203B switch. We need only basic features such as etherchannel, STP, QOS, static routing and SSH support. Does anyone can point me to a stable release I can upgrade to and what release are you using? Juliano Luz Analista de Redes e Telecomunica??es Infra-Estrutura de Redes e Telecomunica??es Telem?tica - Confedera??o SICREDI - Porto Alegre +55 (51) 3358-7113 http://www.sicredi.com.br As informacoes contidas neste e-mail e nos arquivos anexados podem ser informacoes confidenciais ou privilegiadas. Caso voce nao seja o destinatario correto, apague o conteudo desta mensagem e notifique o remetente imediatamente. ___ 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] NPE-G2: mixed interrupt/polling packet processing on POS interface
Philippe, I need to check back with the BU on it. I thought they were putting a document out on this G2 processing reporting issue. Basically due to the way the G2 does CPU accounting it looks like it's higher at lower loads based on the CPU measurements. If you put it in the lab and measure NDR's the CPU can forward much more than the G1 even though the G2 shows higher CPU in the output. That has confused a lot of folks and understandably so. Rodney On Wed, Feb 20, 2008 at 03:12:27PM +0100, Philippe Strauss wrote: Hello c-nsp, We are running c7200 vxr with NPE-G2, but are seeing way to high CPU usage (85%) at only 225kPPS in+out. It _seems_ it's due to the fact we're using a POS interface. I _guess_, the G2, when using GigE interface, is doing a mixed interrupt/polling mode for processing each packets. (like linux NAPI: above a certain PPS value, the driver switch from interrupt to polling mode). It's a guess. But the CPU usage is for sure much lower when using only the 3 GigE embeded on the mainboard. Keeping interrupt only processing for POS, which may be used to switch voice traffic, has some rational behind it. But we're using it only to switch data/ip, and I'm wondering if there's a way to lower the CPU usage despite using POS? like a switch to enable mixed interrupt/polling driver on the POS? would be highly helpfull. regards. -- Philippe Strauss av. de Beaulieu 25 1004 Lausanne http://philou.ch ___ 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] l3 gateway redundancy without eating three ip addresses inthe subnet
Joe, One option is to use VRRP. In VRRP the virtual IP is the actual IP used on the physical interface of the primary router, so you will still have to assign an IP address for each router (but this would be the case in any solution anyway), but no need for a 3rd IP for the virtual. For VRRP, check: http://www.cisco.com/en/US/docs/ios/12_4t/ip_appl/configuration/guide/ht apvrrp.html Arie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Maimon Sent: Wednesday, February 20, 2008 16:40 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] l3 gateway redundancy without eating three ip addresses inthe subnet Is there a supported cisco method to provide gateway redundancy (hsrp, vrrp) without having to use three ip addresses from the same subnet? slb? Thanks, Joe ___ 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] DFC-3BXL vs DFC-3CXL
Tassos, DFC-3CXL is used with RSP720, while DFC-3BXL is used with SUP720. The DFC has to be matched with the RSP/SUP module, as it is basically a replica of the PFC. Arie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tassos Chatzithomaoglou Sent: Wednesday, February 20, 2008 17:41 PM To: cisco-nsp Subject: [c-nsp] DFC-3BXL vs DFC-3CXL I'm looking for a document describing the differences between these 2 DFC modules. Looking through various CCO pages, the only difference i found was the number of mac addresses supported (64k vs 96k). Is there anything else i'm missing? Also, has anyone used DFC-3CXL with 67xx modules on a 6500/SUP720-3BXL system? I guess they get downgraded to 3BXL, but since their price is the same, why not get the newer ones? -- Tassos ___ 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] DFC-3BXL vs DFC-3CXL
I'm looking for a document describing the differences between these 2 DFC modules. Looking through various CCO pages, the only difference i found was the number of mac addresses supported (64k vs 96k). Is there anything else i'm missing? Also, has anyone used DFC-3CXL with 67xx modules on a 6500/SUP720-3BXL system? I guess they get downgraded to 3BXL, but since their price is the same, why not get the newer ones? -- Tassos ___ 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] DFC-3BXL vs DFC-3CXL
Hi Arie, Can you please explain the has to be matched part? I have both 6500/SUP720 and 7600/RSP720 systems and i would prefer to get DFC-3CXL cards (instead of DFC-3BXL), so i can use them at their maximum efficiency in both systems (interchangeably). Isn't that possible? Regards, Tassos Arie Vayner (avayner) wrote on 20/2/2008 6:00 μμ: Tassos, DFC-3CXL is used with RSP720, while DFC-3BXL is used with SUP720. The DFC has to be matched with the RSP/SUP module, as it is basically a replica of the PFC. Arie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tassos Chatzithomaoglou Sent: Wednesday, February 20, 2008 17:41 PM To: cisco-nsp Subject: [c-nsp] DFC-3BXL vs DFC-3CXL I'm looking for a document describing the differences between these 2 DFC modules. Looking through various CCO pages, the only difference i found was the number of mac addresses supported (64k vs 96k). Is there anything else i'm missing? Also, has anyone used DFC-3CXL with 67xx modules on a 6500/SUP720-3BXL system? I guess they get downgraded to 3BXL, but since their price is the same, why not get the newer ones? -- Tassos ___ 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] DFC-3BXL vs DFC-3CXL
Tassos, Basically, if you have a Sup720-3B, it means you have a PFC3B. If you have a module with DFC-3BXL then you will gain nothing, as the DFC has to match with the PFC model, so basically even though you have DFC-3BXL, it would operate in 3B mode. The same works the other way. If you have Sup720-3BXL and DFC-3B on some module, you would basically force the whole router to work in 3B mode. The reason for this is very simple. The DFC is basically a distributed replica of the central PFC, so they can only operate in the same mode. Arie -Original Message- From: Tassos Chatzithomaoglou [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 20, 2008 18:11 PM To: Arie Vayner (avayner) Cc: cisco-nsp Subject: Re: [c-nsp] DFC-3BXL vs DFC-3CXL Hi Arie, Can you please explain the has to be matched part? I have both 6500/SUP720 and 7600/RSP720 systems and i would prefer to get DFC-3CXL cards (instead of DFC-3BXL), so i can use them at their maximum efficiency in both systems (interchangeably). Isn't that possible? Regards, Tassos Arie Vayner (avayner) wrote on 20/2/2008 6:00 μμ: Tassos, DFC-3CXL is used with RSP720, while DFC-3BXL is used with SUP720. The DFC has to be matched with the RSP/SUP module, as it is basically a replica of the PFC. Arie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tassos Chatzithomaoglou Sent: Wednesday, February 20, 2008 17:41 PM To: cisco-nsp Subject: [c-nsp] DFC-3BXL vs DFC-3CXL I'm looking for a document describing the differences between these 2 DFC modules. Looking through various CCO pages, the only difference i found was the number of mac addresses supported (64k vs 96k). Is there anything else i'm missing? Also, has anyone used DFC-3CXL with 67xx modules on a 6500/SUP720-3BXL system? I guess they get downgraded to 3BXL, but since their price is the same, why not get the newer ones? -- Tassos ___ 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] DFC-3BXL vs DFC-3CXL
I think i haven't made it clear enough Let's suppose i have the following 2 systems: 6500/SUP720-3BXL 6724-SFP (DFC-3CXL) 6500/SUP720-3BXL 6724-SFP (DFC-3BXL) If i'm not mistaken both will operate in 3BXL mode, so what is the disadvantage of the first one? Now, suppose i also have the following 2 systems: 7600/RSP720-3CXL 6724-SFP (DFC-3CXL) 7600/RSP720-3CXL 6724-SFP (DFC-3BXL) If i'm not mistaken, the first one will operate in 3CXL, while the second one in 3BXL. So the first one would be better (in what terms? That is my secondary question). Generally, why should i choose 3BXL, when with a 3CXL i can have a 3BXL plus something more? That is my primary question. Regards, Tassos Arie Vayner (avayner) wrote on 20/2/2008 6:20 μμ: Tassos, Basically, if you have a Sup720-3B, it means you have a PFC3B. If you have a module with DFC-3BXL then you will gain nothing, as the DFC has to match with the PFC model, so basically even though you have DFC-3BXL, it would operate in 3B mode. The same works the other way. If you have Sup720-3BXL and DFC-3B on some module, you would basically force the whole router to work in 3B mode. The reason for this is very simple. The DFC is basically a distributed replica of the central PFC, so they can only operate in the same mode. Arie -Original Message- From: Tassos Chatzithomaoglou [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 20, 2008 18:11 PM To: Arie Vayner (avayner) Cc: cisco-nsp Subject: Re: [c-nsp] DFC-3BXL vs DFC-3CXL Hi Arie, Can you please explain the has to be matched part? I have both 6500/SUP720 and 7600/RSP720 systems and i would prefer to get DFC-3CXL cards (instead of DFC-3BXL), so i can use them at their maximum efficiency in both systems (interchangeably). Isn't that possible? Regards, Tassos Arie Vayner (avayner) wrote on 20/2/2008 6:00 μμ: Tassos, DFC-3CXL is used with RSP720, while DFC-3BXL is used with SUP720. The DFC has to be matched with the RSP/SUP module, as it is basically a replica of the PFC. Arie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tassos Chatzithomaoglou Sent: Wednesday, February 20, 2008 17:41 PM To: cisco-nsp Subject: [c-nsp] DFC-3BXL vs DFC-3CXL I'm looking for a document describing the differences between these 2 DFC modules. Looking through various CCO pages, the only difference i found was the number of mac addresses supported (64k vs 96k). Is there anything else i'm missing? Also, has anyone used DFC-3CXL with 67xx modules on a 6500/SUP720-3BXL system? I guess they get downgraded to 3BXL, but since their price is the same, why not get the newer ones? -- Tassos ___ 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/ -- *** Tassos Chatzithomaoglou Network Design Development Department FORTHnet S.A. [EMAIL PROTECTED] *** ___ 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] redundant VPNs
Hi, A customer of ours has two sites, one with an 1800 the other with a 2800. There's a point-to-point T1 connecting the locations. The two locations also have a backup link through my network via DSL. The customer wants to establish a VPN between the two locations over the ptp T1, and a backup VPN over the DSL lines in case the ptp T1 goes down. I should be able to rely on the 1800/2800 for this, shouldn't I? I can add sonicwalls on each end if needed, but I think the routers should be able to handle it alone. What do you think? Thanks, Adam ___ 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] redundant VPNs
Should be fine. Both models have built-in VPN accelerators, should haven't a couple megabit without skipping a beat. Chuck Church Principal Network Engineer, CCIE #8776 Harris Information Technology Services EDS Contractor - Navy Marine Corps Intranet (NMCI) 1210 N. Parker Rd. | Greenville, SC 29609 Office: 864-335-9473 | Cell: 864-266-3978 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Greene Sent: Wednesday, February 20, 2008 11:48 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] redundant VPNs Hi, A customer of ours has two sites, one with an 1800 the other with a 2800. There's a point-to-point T1 connecting the locations. The two locations also have a backup link through my network via DSL. The customer wants to establish a VPN between the two locations over the ptp T1, and a backup VPN over the DSL lines in case the ptp T1 goes down. I should be able to rely on the 1800/2800 for this, shouldn't I? I can add sonicwalls on each end if needed, but I think the routers should be able to handle it alone. What do you think? Thanks, Adam ___ 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] redundant VPNs
1800/2800 should have no problem handling T1 VPN. Use AIM-SSL1/SSL2 encryption cards for them. Tag on Zone-base FW and IOS IPS and your customer should feel safe :) -lmn On Feb 20, 2008 11:48 AM, Adam Greene [EMAIL PROTECTED] wrote: Hi, A customer of ours has two sites, one with an 1800 the other with a 2800. There's a point-to-point T1 connecting the locations. The two locations also have a backup link through my network via DSL. The customer wants to establish a VPN between the two locations over the ptp T1, and a backup VPN over the DSL lines in case the ptp T1 goes down. I should be able to rely on the 1800/2800 for this, shouldn't I? I can add sonicwalls on each end if needed, but I think the routers should be able to handle it alone. What do you think? Thanks, Adam ___ 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] DFC-3BXL vs DFC-3CXL
Unless i'm reading something wrong, both have $15000 as a GPL price. -- Tassos Dirk-Jan van Helmond wrote on 20/2/2008 7:30 μμ: The 3CXL will work with a Sup720/3BXL, but will (ofcourse) operate in 3BXL mode. no disadvantage (except financially). The 3CXL has some more features than the 3BXL, the ones i know of: - more MAC addresses - 3CXL is needed for vss-1440 grtz, Dirk I think i haven't made it clear enough Let's suppose i have the following 2 systems: 6500/SUP720-3BXL 6724-SFP (DFC-3CXL) 6500/SUP720-3BXL 6724-SFP (DFC-3BXL) If i'm not mistaken both will operate in 3BXL mode, so what is the disadvantage of the first one? Now, suppose i also have the following 2 systems: 7600/RSP720-3CXL 6724-SFP (DFC-3CXL) 7600/RSP720-3CXL 6724-SFP (DFC-3BXL) If i'm not mistaken, the first one will operate in 3CXL, while the second one in 3BXL. So the first one would be better (in what terms? That is my secondary question). Generally, why should i choose 3BXL, when with a 3CXL i can have a 3BXL plus something more? That is my primary question. Regards, Tassos Arie Vayner (avayner) wrote on 20/2/2008 6:20 i`i`: Tassos, Basically, if you have a Sup720-3B, it means you have a PFC3B. If you have a module with DFC-3BXL then you will gain nothing, as the DFC has to match with the PFC model, so basically even though you have DFC-3BXL, it would operate in 3B mode. The same works the other way. If you have Sup720-3BXL and DFC-3B on some module, you would basically force the whole router to work in 3B mode. The reason for this is very simple. The DFC is basically a distributed replica of the central PFC, so they can only operate in the same mode. Arie -Original Message- From: Tassos Chatzithomaoglou [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 20, 2008 18:11 PM To: Arie Vayner (avayner) Cc: cisco-nsp Subject: Re: [c-nsp] DFC-3BXL vs DFC-3CXL Hi Arie, Can you please explain the has to be matched part? I have both 6500/SUP720 and 7600/RSP720 systems and i would prefer to get DFC-3CXL cards (instead of DFC-3BXL), so i can use them at their maximum efficiency in both systems (interchangeably). Isn't that possible? Regards, Tassos Arie Vayner (avayner) wrote on 20/2/2008 6:00 i`i`: Tassos, DFC-3CXL is used with RSP720, while DFC-3BXL is used with SUP720. The DFC has to be matched with the RSP/SUP module, as it is basically a replica of the PFC. Arie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tassos Chatzithomaoglou Sent: Wednesday, February 20, 2008 17:41 PM To: cisco-nsp Subject: [c-nsp] DFC-3BXL vs DFC-3CXL I'm looking for a document describing the differences between these 2 DFC modules. Looking through various CCO pages, the only difference i found was the number of mac addresses supported (64k vs 96k). Is there anything else i'm missing? Also, has anyone used DFC-3CXL with 67xx modules on a 6500/SUP720-3BXL system? I guess they get downgraded to 3BXL, but since their price is the same, why not get the newer ones? -- Tassos ___ 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] Cisco WS-2950T-24 stencil
You are right, it should be there but it isn't. El mié, 20-02-2008 a las 08:39 -0500, Christian Koch escribió: should be here http://cisco.com/en/US/prod/assets/visio/product_visio_icon0900aecd80094d04.zip On Wed, Feb 20, 2008 at 6:08 AM, Ultramajestic [EMAIL PROTECTED] wrote: Can anyone send me the stencil for a 2950T-24 switch? I can't find it, it is not at cisco.com neither visiocafe.com 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/ ___ 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] RSP720-3CXL-10GE 10G interface capabilities
Does anyone know what the capabilities of the on-board 10G interfaces? Do they compare more with the LAN 10G ports like what are found on the 6704/8 linecards or do they compare better with the 10G WAN interfaces found on the ES20 or SPAs? I'm wondering if the on-board 10G interfaces would allow me to delay any more 10G interface purchases until after the ES40 is out. Thanks Justin ___ 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] Fallback (vlan) Bridging on the 6500
I need to run vlan bridging on a 6500 sup2 for 3 weeks. I'm following the documentation here: http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800a7af6.shtml#sample2 show bridge tells me, among other things, Total of 300 station blocks, 298 free (just doing a test vlan right now). Which means I have a bridge table of 300 entries, and when I run out, more RAM will be allocated for another 300. Question is, how much RAM and how do I keep track? I have 1000 entries in the ARP table (95% will be on a bridge at one point or another), and roughly 55MB on the router. Am I in store for a bad day? Some output below. TIA! -porkchop ch-dist1#show mem sum HeadTotal(b) Used(b) Free(b) Lowest(b) Largest(b) Processor 41958F4090861760145010927636066875738784 76283940 I/O70016777216 32358121354140413488104 13541212 ch-dist1#show mem alloc | incl bridge 419C77A0140 419C7744 419C7858 1 Tbridge Monitor 40268350 Watched Queue 424612F8 92 42461298 42461380 1 Tbridge Monitor 402680B0 Event Threads 4256D81C536 4256D7C0 4256DA60 1 Tbridge Monitor 4027B738 Process 4256E644108 4256E4E0 4256E6DC 1 Tbridge Monitor 40268350 Watched Queue 4256E6DC108 4256E644 4256E774 1 Tbridge Monitor 40268350 Watched Queue 4256E774 52 4256E6DC 4256E7D4 1 Tbridge Monitor 402680B0 Event Threads 4256E7D4 52 4256E774 4256E834 1 Tbridge Monitor 402680B0 Event Threads 42572CFC 24 42572CA4 42572D40 1 *Dead* 408E40C4 bridge group name 4257C410108 4257C3B4 4257C4A8 1 Tbridge Monitor 4027FF90 Process Signals 4261CC7C140 4261CC20 4261CD34 1 Tbridge Monitor 40268668 Process Events 4261D980 28 4261D920 4261D9C8 1 *Dead* 408E40C4 bridge group name 42666F2C 6000 42666E38 426686C8 1 Tbridge Monitor 4028052C Process Stack 426C8E10 22976 426C5F60 426CE7FC 1 *Dead* 408D6CA8 tbridgetype 427347AC 22976 427318A0 4273A198 1 *Dead* 408D6CA8 tbridgetype ch-dist1# -- Michael Porkchop Kaegler, Sr. Network Analyst (845) 575-3061 Marist College, Poughkeepsie, NY ___ 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] DFC-3BXL vs DFC-3CXL
Tassos Chatzithomaoglou wrote: I think i haven't made it clear enough Let's suppose i have the following 2 systems: 6500/SUP720-3BXL 6724-SFP (DFC-3CXL) 6500/SUP720-3BXL 6724-SFP (DFC-3BXL) If i'm not mistaken both will operate in 3BXL mode, so what is the disadvantage of the first one? There is no disadvantage (unless you're worried about immature hardware, which I don't think is a valid concern here) Now, suppose i also have the following 2 systems: 7600/RSP720-3CXL 6724-SFP (DFC-3CXL) 7600/RSP720-3CXL 6724-SFP (DFC-3BXL) If i'm not mistaken, the first one will operate in 3CXL, while the second one in 3BXL. So the first one would be better (in what terms? That is my secondary question). Yes the first one would be better. Primarily it would have 96k mac table rather than 64k. I believe there are some bug-fixes in the PFC/DFC 3C but they're minor (I recall a CoPP related one). The *main* think the -3C does above the -3B is VSS but obviously if you're on RSP720 that's not available. It's possible there are loads of features squirrelled away inside the -3C but evidence is it's a pretty minor HW rev for the VSS support, and I presume Cisco are keen to stop making the -3B purely on cost reasons. Generally, why should i choose 3BXL, when with a 3CXL i can have a 3BXL plus something more? That is my primary question. You should not, is my understanding. ___ 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] How to load balance multiple MPLS links from two different providers?
You might want to look at optimized edge routing (OER). http://www.cisco.com/en/US/products/ps6628/products_ios_protocol_option_home.html -- Colin McNamara (858)208-8105 CCIE #18233,RHCE,GCIH http://www.colinmcnamara.com http://www.linkedin.com/in/colinmcnamara The difficult we do immediately, the impossible just takes a little longer On Wed, 2008-02-20 at 13:30 -0800, jacob c wrote: We have two MPLS connections to every site. One is Sprint and one is ATT. The ATT link carries all the voice data amongst the sites and everything else goes over the Sprint link. We hav no control over any of this as it is all managed by the providers. I would like to take better advantage of the links by load balancing all my traffic across both links but avoid asymetric routing. Is there a way to do this? The only option that comes to mind is a DNS type of load balancer which I have used in the past for multiple internet pipes, each with it's own unique block of addresses from the ISP. My local lan though is only one subnet. Any ideas or suggestions? Thank you, - Never miss a thing. Make Yahoo your homepage. ___ 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] RSP720-3CXL-10GE 10G interface capabilities
On (2008-02-20 16:01 -0600), Justin Shore wrote: Does anyone know what the capabilities of the on-board 10G interfaces? Do they compare more with the LAN 10G ports like what are found on the 6704/8 linecards or do they compare better with the 10G WAN interfaces found on the ES20 or SPAs? I'm wondering if the on-board 10G interfaces would allow me to delay any more 10G interface purchases until after the ES40 is out. They're LAN cards. -- ++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/
