Re: [c-nsp] NPE-G1 support for jumbo frames
How about PA-2FE-TX does anybody have a chance to test ? Maybe we need to test it with 12.2(3X)SBX also :) PA-2FE-TX with NPE-G2/7206VXR run 12.4.4-XD9 on slot 5 5/1 foo#mtu ? 64-17940 MTU size in bytes foo#mtu 1570 % Interface FastEthernet5/0 does not support user settable mtu. -- hsa Tuesday, April 1, 2008, 7:34:53 PM, you wrote: Jose schrieb: We have not been able to change the MTU for the PA-FE-TXs to anything larger than the standard 1500. Every time you try and change it, it spits back an error about not being allowed on this interface. This is with the 7206VXR NPE300 running 12.2(15)T. We're running up to 1530 on a PA-FE-TX (NPE300/7206VXR with 12.2(31)SB) because of MPLS: Slot 4: Fast-ethernet (TX-ISL) Port adapter, 1 port Port adapter is analyzed Port adapter insertion time 28w3d ago EEPROM contents at hardware discovery: Hardware revision 1.0 Board revision A0 Serial number 3579616 Part number73-1688-03 FRU Part Number: PA-FE-TX ! interface FastEthernet4/0 ... mtu 1530 ... ! -- Gerald (ax/tc) ___ 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/ -- Best regards, ___ 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] OT: Check Point v Cisco PIX (ASA 5500 Series)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jarrod Friedland Sent: Friday, April 04, 2008 03:18 To: cisco-nsp@puck.nether.net Subject: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) Hi All I wonder if anyone can offer me some sound professional opinion in terms of using a Check Point FW device v Cisco PIX (ASA 5500 Series) Devices. Currently we are using Checkpoint Devices however, I have an opportunity to possible include a pix device in our mix, however all my reading thus far seems to be more based on personal opinion than operational pro's and con's. Im looking for info in relation to can do's and cannots - Administration comparisons etc. If you are able to offer some insight but would like to take this offline, please let me know and I can send you my direct contact details. Since we're using both checkpoint asas, here's what I think about them. We only use them for ipsec (enduser site to site) and packet filtering. All kinds of protocol inspection run on seperate proxies, where they belong. Checkpoint has a great log viewer, but that's just about all I can say in their favor. They don't know how to apply rulesets to interfaces, just globally. Setting up vpns is a pain because they like to send out strange subnet configs. They're horribly expensive (we ran them on Nokia's, whose network cards do not support autoneg btw). Their support is pretty terrible as well. They also need arcane changes to their backend firewall database whenever something doesn't go as expected. Cisco ASAs are pretty cheap and have reasonable performance, but has lots of strange quirks. They don't decrement TTL by default (and I still haven't found a way to decrement it over vpn connections), handling icmp errors is a black art (still haven't gotten mtr working through asa's), do strange things with your tcp MSS, don't send out RSTs to denied connections, and other such fun stuff. Most of there can be configured to work correctly, but they're far from the default. Cisco's central management tool (Cisco Security Manager) is pretty horrible, I guess the lag is about 1 year between when the ASA gets a new feature and when Security Manager learns how to use it. On the other hand, the free gui (asdm) is pretty decent, and unliky checkpoint it comes with a cli. Software updates fixes don't get released as often as checkpoint, which I consider a downside for the ASAs. I still think ASAs are a step up from checkpoint gear, but neither are great. I'm seriously considering netscreens for my next rollouts. If I ever manage to convince the upper echelons here, I'd go with pf on either openbsd freebsd. // nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Speed limitations - RF problem or IP ?
Yes, I´ve tested this on an unused downstream and upstrean port in the head end and the download speed is achieved without problem. Apparently there are no factors to unable to pass 20Mb of download on some of the optical... Someone has a similar problem? On Fri, Apr 4, 2008 at 2:58 AM, Frank Bulk - iNAME [EMAIL PROTECTED] wrote: It will be difficult to attain the ~38 Mbps of downstream if you're shared with other usershave you tested this on an unused downstream and upstream port in the head end? Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Miguel Sent: Thursday, April 03, 2008 6:03 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Speed limitations - RF problem or IP ? Hello, Does anyone know what the best things to do when you have speed problems with cable modems in different downstream/upstream? This is the scenario: uBR 10K with about 17000 customers. Each downstream is configured with 256qam and all upstream have 16qam of modulation. In some cases the upstreams have a load-balance configuration with 2 or 3 upstream per optical node. There are no problems of SNR and FEC. All values are regular... And the used bandwidth are low.. After that, in some upstream can not go to the 20Mb of download Bandwidth and with the configuration used, should arrive without problem to 37Mb... I tested several cable modems and the problem still remain ... Someone has suggestions or ways of action to overcome this type of problem? Thks for your help ___ 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] OT: Check Point v Cisco PIX (ASA 5500 Series)
If you really need a firewall thn you must go for Netscreen. Netscreen is a truly firewall with pretty nice/stable packet inspection engine and pretty nice GUI/Command line interface. A single box (netscreen 500) will work like a charm for packet inspection, attack prevention and vpn tunnels termination. Oh yea you will not face any issue like icmp response packets or tcp flags... mtr is working fine too :) Regards, Masood Ahmad Shah -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, April 04, 2008 12:39 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jarrod Friedland Sent: Friday, April 04, 2008 03:18 To: cisco-nsp@puck.nether.net Subject: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) Hi All I wonder if anyone can offer me some sound professional opinion in terms of using a Check Point FW device v Cisco PIX (ASA 5500 Series) Devices. Currently we are using Checkpoint Devices however, I have an opportunity to possible include a pix device in our mix, however all my reading thus far seems to be more based on personal opinion than operational pro's and con's. Im looking for info in relation to can do's and cannots - Administration comparisons etc. If you are able to offer some insight but would like to take this offline, please let me know and I can send you my direct contact details. Since we're using both checkpoint asas, here's what I think about them. We only use them for ipsec (enduser site to site) and packet filtering. All kinds of protocol inspection run on seperate proxies, where they belong. Checkpoint has a great log viewer, but that's just about all I can say in their favor. They don't know how to apply rulesets to interfaces, just globally. Setting up vpns is a pain because they like to send out strange subnet configs. They're horribly expensive (we ran them on Nokia's, whose network cards do not support autoneg btw). Their support is pretty terrible as well. They also need arcane changes to their backend firewall database whenever something doesn't go as expected. Cisco ASAs are pretty cheap and have reasonable performance, but has lots of strange quirks. They don't decrement TTL by default (and I still haven't found a way to decrement it over vpn connections), handling icmp errors is a black art (still haven't gotten mtr working through asa's), do strange things with your tcp MSS, don't send out RSTs to denied connections, and other such fun stuff. Most of there can be configured to work correctly, but they're far from the default. Cisco's central management tool (Cisco Security Manager) is pretty horrible, I guess the lag is about 1 year between when the ASA gets a new feature and when Security Manager learns how to use it. On the other hand, the free gui (asdm) is pretty decent, and unliky checkpoint it comes with a cli. Software updates fixes don't get released as often as checkpoint, which I consider a downside for the ASAs. I still think ASAs are a step up from checkpoint gear, but neither are great. I'm seriously considering netscreens for my next rollouts. If I ever manage to convince the upper echelons here, I'd go with pf on either openbsd freebsd. // nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] OT: Check Point v Cisco PIX (ASA 5500 Series)
Hi, If you really need a firewall thn you must go for Netscreen. Netscreen is a truly firewall with pretty nice/stable packet inspection engine and pretty nice GUI/Command line interface. even against ASA 5580-40 ? can someone point me to a compelling reason to think of a netscreen instead of such a box? alan ___ 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] OT: Check Point v Cisco PIX (ASA 5500 Series)
i wouldnt use a netscreen over an asa 5520 + at all..we're phasing out all our netscreens, iIMO they arent a great performer... however the SSG/ISG platforms are more solid On Fri, Apr 4, 2008 at 9:15 AM, [EMAIL PROTECTED] wrote: Hi, If you really need a firewall thn you must go for Netscreen. Netscreen is a truly firewall with pretty nice/stable packet inspection engine and pretty nice GUI/Command line interface. even against ASA 5580-40 ? can someone point me to a compelling reason to think of a netscreen instead of such a box? alan ___ 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] OT: Check Point v Cisco PIX (ASA 5500 Series)
don't send out RSTs to denied connections, and other such fun stuff. for a firewall, not sending an RST for a denied connection, isn´t it the Right Thing to do? regards javier On 4/4/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jarrod Friedland Sent: Friday, April 04, 2008 03:18 To: cisco-nsp@puck.nether.net Subject: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) Hi All I wonder if anyone can offer me some sound professional opinion in terms of using a Check Point FW device v Cisco PIX (ASA 5500 Series) Devices. Currently we are using Checkpoint Devices however, I have an opportunity to possible include a pix device in our mix, however all my reading thus far seems to be more based on personal opinion than operational pro's and con's. Im looking for info in relation to can do's and cannots - Administration comparisons etc. If you are able to offer some insight but would like to take this offline, please let me know and I can send you my direct contact details. Since we're using both checkpoint asas, here's what I think about them. We only use them for ipsec (enduser site to site) and packet filtering. All kinds of protocol inspection run on seperate proxies, where they belong. Checkpoint has a great log viewer, but that's just about all I can say in their favor. They don't know how to apply rulesets to interfaces, just globally. Setting up vpns is a pain because they like to send out strange subnet configs. They're horribly expensive (we ran them on Nokia's, whose network cards do not support autoneg btw). Their support is pretty terrible as well. They also need arcane changes to their backend firewall database whenever something doesn't go as expected. Cisco ASAs are pretty cheap and have reasonable performance, but has lots of strange quirks. They don't decrement TTL by default (and I still haven't found a way to decrement it over vpn connections), handling icmp errors is a black art (still haven't gotten mtr working through asa's), do strange things with your tcp MSS, don't send out RSTs to denied connections, and other such fun stuff. Most of there can be configured to work correctly, but they're far from the default. Cisco's central management tool (Cisco Security Manager) is pretty horrible, I guess the lag is about 1 year between when the ASA gets a new feature and when Security Manager learns how to use it. On the other hand, the free gui (asdm) is pretty decent, and unliky checkpoint it comes with a cli. Software updates fixes don't get released as often as checkpoint, which I consider a downside for the ASAs. I still think ASAs are a step up from checkpoint gear, but neither are great. I'm seriously considering netscreens for my next rollouts. If I ever manage to convince the upper echelons here, I'd go with pf on either openbsd freebsd. // nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] OT: Check Point v Cisco PIX (ASA 5500 Series)
Hi, for a firewall, not sending an RST for a denied connection, isn´t it the Right Thing to do? ah, the perennial DROP or REJECT question. alan ___ 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] Router down - What is Net Background?
I just had a 3660 terminating about 1500 PVCs for DSL die this AM. The 3660 is running 12.3(22) w/ 256MB of RAM. I'm at the remote POP now, consoled in and looking at the box. The console hangs for 45-60s before I get a chance to run a quick command or two. Then it goes back to the hung state about 5 seconds later. The box keeps dropping my 2 OC3s and bouncing my IS-IS processes. Syslog didn't appear to capture anything interesting leading up to this crash. I had the box power cycled while I was driving down here. Overall the CPU is low and neither CPU nor memory were being taxed over the past number of months. The Net Background process is using a fair bit of the processor. Actually, that's an understatement. At times it's only using 9% or so. At other times it's up to 97% as was the case here: 3660-2.brd#sh proc cpu sort 5m CPU utilization for five seconds: 1%/0%; one minute: 17%; five minutes: 19% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 28 4715940 6117731049 97.09% 13.74% 9.23% 0 Net Background 31 238608 865 275847 2.65% 8.58% 8.48% 0 Per-Second Jobs 58336 684 12187 0.00% 0.56% 0.68% 0 Check heaps 607764 7776998 0.01% 0.27% 0.43% 0 IP Input 183856 8741441 0.00% 0.42% 0.33% 0 ARP Input 1672556 3046839 0.02% 0.12% 0.13% 0 ISIS Upd 140273215 182133 0.00% 0.00% 0.12% 0 Key Proc 1791680 1676 1002 0.00% 0.13% 0.11% 0 OSPF Router 471912 152 12578 0.00% 0.12% 0.11% 0 Per-minute Jobs 821792 597 3001 0.01% 0.15% 0.11% 0 IP Background 31828 238 7680 0.00% 0.11% 0.09% 0 OSPF Hello 100 644 1217529 0.00% 0.13% 0.08% 0 DHCPD Receive 511700 376 4521 0.00% 0.04% 0.05% 0 ATM Periodic 83 700 417 1678 0.00% 0.01% 0.02% 0 IP RIB Update 108 500 871574 0.00% 0.06% 0.02% 0 CEF process 124 172 471365 0.00% 0.04% 0.02% 0 Exec 166 620 1908324 0.00% 0.03% 0.02% 0 ISIS Adj 106 420 284 1478 0.00% 0.03% 0.00% 0 Adj Manager 6 436 1406310 0.00% 0.02% 0.00% 0 Pool Manager 91 188 556338 0.00% 0.01% 0.00% 0 ILMI Timer Proce 163 92 1795 51 0.00% 0.00% 0.00% 0 CLNS Input Per-Second Jobs is also using quite a bit of CPU. The log has CPUHOG entries in it pointing at the Net Background process too: 000428: .Apr 4 08:36:31 CDT: %SYS-3-CPUHOG: Task ran for 50332 msec (10/0), process = Net Background, PC = 60439FFC. -Traceback= 6043A004 What does the Net Background process do? I haven't been able to find any answers on Cisco.com. We're in the middle of SmartNet renewals and negotiations and unfortunately this box's contract has expired. I can have our AM bless a TAC case for us if need be, assuming I can locate him; I think he's in training this week back East. Any ideas? I'm going to go back and scrutinize the log for anything useful. As of right now the box is intermittently pingable, corresponding directly to the brief instances that I can use the console. Customer packets seem to flow about as well. 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/
Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2008 16:42 To: Javier Liendo Cc: Nauwelaerts, Nick (TCM); cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) Hi, for a firewall, not sending an RST for a denied connection, isn´t it the Right Thing to do? ah, the perennial DROP or REJECT question. Yup, I'm for rejecting. It's what applications expect and I still have not heared any convincing arguments as to why I would want to drop instead. It seems dropping increases your security in some magical way, but for a well done portscan dropping isn't even an extra hurdle. All dropping does is make troubleshooting a pain. // nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series)
I'd tend to think that it's less about portscans and more about preventing someone using you to perform a bounced RST flood. Just my 0x2. -- robbie nick.nauwelaerts @thomson.com Sent by: To cisco-nsp-bounces cisco-nsp@puck.nether.net @puck.nether.net cc Subject 04/04/2008 09:55 Re: [c-nsp] OT: Check Point v Cisco AMPIX (ASA 5500 Series) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2008 16:42 To: Javier Liendo Cc: Nauwelaerts, Nick (TCM); cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) Hi, for a firewall, not sending an RST for a denied connection, isn´t it the Right Thing to do? ah, the perennial DROP or REJECT question. Yup, I'm for rejecting. It's what applications expect and I still have not heared any convincing arguments as to why I would want to drop instead. It seems dropping increases your security in some magical way, but for a well done portscan dropping isn't even an extra hurdle. All dropping does is make troubleshooting a pain. // nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] OT: Check Point v Cisco PIX (ASA 5500 Series)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2008 17:04 To: Nauwelaerts, Nick (TCM) Cc: cisco-nsp@puck.nether.net; [EMAIL PROTECTED] Subject: Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) I'd tend to think that it's less about portscans and more about preventing someone using you to perform a bounced RST flood. Just my 0x2. That's a good argument, but you can use your regular rate limiters (which are in place for icmp for example) and anomaly detection for that. Or whatever antispoofing you might have in place. // nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Speed limitations - RF problem or IP ?
If it works fine on an unused downstream and upstream port, then wouldnt the angle that its sharing traffic with others be a reason why 38 Mbps cant be achieved on production link? Theres also all the timing/contention issues involved in a product link, too. Frank From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Progressus Sent: Friday, April 04, 2008 3:51 AM To: [EMAIL PROTECTED] Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Speed limitations - RF problem or IP ? Yes, I´ve tested this on an unused downstream and upstrean port in the head end and the download speed is achieved without problem. Apparently there are no factors to unable to pass 20Mb of download on some of the optical... Someone has a similar problem? On Fri, Apr 4, 2008 at 2:58 AM, Frank Bulk - iNAME [EMAIL PROTECTED] wrote: It will be difficult to attain the ~38 Mbps of downstream if you're shared with other usershave you tested this on an unused downstream and upstream port in the head end? Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Miguel Sent: Thursday, April 03, 2008 6:03 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Speed limitations - RF problem or IP ? Hello, Does anyone know what the best things to do when you have speed problems with cable modems in different downstream/upstream? This is the scenario: uBR 10K with about 17000 customers. Each downstream is configured with 256qam and all upstream have 16qam of modulation. In some cases the upstreams have a load-balance configuration with 2 or 3 upstream per optical node. There are no problems of SNR and FEC. All values are regular... And the used bandwidth are low.. After that, in some upstream can not go to the 20Mb of download Bandwidth and with the configuration used, should arrive without problem to 37Mb... I tested several cable modems and the problem still remain ... Someone has suggestions or ways of action to overcome this type of problem? Thks for your help ___ 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] Router down - What is Net Background?
the net background proess. sends interface keepalive packets and processes interface state changes On Fri, Apr 4, 2008 at 10:42 AM, Justin Shore [EMAIL PROTECTED] wrote: I just had a 3660 terminating about 1500 PVCs for DSL die this AM. The 3660 is running 12.3(22) w/ 256MB of RAM. I'm at the remote POP now, consoled in and looking at the box. The console hangs for 45-60s before I get a chance to run a quick command or two. Then it goes back to the hung state about 5 seconds later. The box keeps dropping my 2 OC3s and bouncing my IS-IS processes. Syslog didn't appear to capture anything interesting leading up to this crash. I had the box power cycled while I was driving down here. Overall the CPU is low and neither CPU nor memory were being taxed over the past number of months. The Net Background process is using a fair bit of the processor. Actually, that's an understatement. At times it's only using 9% or so. At other times it's up to 97% as was the case here: 3660-2.brd#sh proc cpu sort 5m CPU utilization for five seconds: 1%/0%; one minute: 17%; five minutes: 19% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 28 4715940 6117731049 97.09% 13.74% 9.23% 0 Net Background 31 238608 865 275847 2.65% 8.58% 8.48% 0 Per-Second Jobs 58336 684 12187 0.00% 0.56% 0.68% 0 Check heaps 607764 7776998 0.01% 0.27% 0.43% 0 IP Input 183856 8741441 0.00% 0.42% 0.33% 0 ARP Input 1672556 3046839 0.02% 0.12% 0.13% 0 ISIS Upd 140273215 182133 0.00% 0.00% 0.12% 0 Key Proc 1791680 1676 1002 0.00% 0.13% 0.11% 0 OSPF Router 471912 152 12578 0.00% 0.12% 0.11% 0 Per-minute Jobs 821792 597 3001 0.01% 0.15% 0.11% 0 IP Background 31828 238 7680 0.00% 0.11% 0.09% 0 OSPF Hello 100 644 1217529 0.00% 0.13% 0.08% 0 DHCPD Receive 511700 376 4521 0.00% 0.04% 0.05% 0 ATM Periodic 83 700 417 1678 0.00% 0.01% 0.02% 0 IP RIB Update 108 500 871574 0.00% 0.06% 0.02% 0 CEF process 124 172 471365 0.00% 0.04% 0.02% 0 Exec 166 620 1908324 0.00% 0.03% 0.02% 0 ISIS Adj 106 420 284 1478 0.00% 0.03% 0.00% 0 Adj Manager 6 436 1406310 0.00% 0.02% 0.00% 0 Pool Manager 91 188 556338 0.00% 0.01% 0.00% 0 ILMI Timer Proce 163 92 1795 51 0.00% 0.00% 0.00% 0 CLNS Input Per-Second Jobs is also using quite a bit of CPU. The log has CPUHOG entries in it pointing at the Net Background process too: 000428: .Apr 4 08:36:31 CDT: %SYS-3-CPUHOG: Task ran for 50332 msec (10/0), process = Net Background, PC = 60439FFC. -Traceback= 6043A004 What does the Net Background process do? I haven't been able to find any answers on Cisco.com. We're in the middle of SmartNet renewals and negotiations and unfortunately this box's contract has expired. I can have our AM bless a TAC case for us if need be, assuming I can locate him; I think he's in training this week back East. Any ideas? I'm going to go back and scrutinize the log for anything useful. As of right now the box is intermittently pingable, corresponding directly to the brief instances that I can use the console. Customer packets seem to flow about as well. 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/ ___ 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] OT: Check Point v Cisco PIX (ASA 5500 Series)
RST wouldn't be the right thing to do if you choose to reject anyway; ICMP Administratively Prohibited would be the correct response. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, April 04, 2008 9:42 To: Javier Liendo Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) Hi, for a firewall, not sending an RST for a denied connection, isn´t it the Right Thing to do? ah, the perennial DROP or REJECT question. alan ___ 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] Router down - What is Net Background?
Thanks for all the replies. One of our OC3s had the FREF light on, sometimes flashing too. I started pulling IMA T1s to see if it was customer traffic. None of them fixed the problem. When I pulled that particular OC3 the problem cleared up. I did see flaps in the log for that particular OC3. They were happening approximately every 60s. Looking at the log a little closer I see that ATM3/0 would come up and then drop within 3-4s, wait 60s, rinse and repeat. I have on that OC3 about 300 PVCs. None of the PVCs have a ubr over 1664. We're using RBE instead of PPPoX. I have ingress egress ACLs on each PVC as well as uRPF. The vast majority of the PVCs are unnumbered to a loopback, though a few have /30s. Other than that the interface config is basic. There isn't any QoS or shaping going on, other than setting the ubr. When I started disconnecting circuits I was speculating that customer traffic could have been to blame. In the log I noticed repeating ACL drops from RFC1918 IPs to our name servers. There weren't that many hits on the ACL but there were some occasional ACL rate-limit overruns. I've seen far worse though. I can't remember if ACLs happen in HW on the 3660 or not; even if they do ACL logging is a process level function isn't it? Every time that OC3 bounces that's about 300 sub-ints bouncing with it. I imagine repeated bounces would be a painful thing. I've pulled the carrier's OC3 card to get the 3660 back online. I'm planning on shutting down all 300 sub-ints on that OC3 and bring the OC3 back up. If the 3660 is still ok I'll enable about 50 PVCs at a time until the box either flips out or I have all the PVCs back online. I have a spare carrier card but I don't think I have a spare OC3 NM so hopefully that's not the problem. Thanks for all the input. Justin Christian wrote: the net background proess. sends interface keepalive packets and processes interface state changes On Fri, Apr 4, 2008 at 10:42 AM, Justin Shore [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I just had a 3660 terminating about 1500 PVCs for DSL die this AM. The 3660 is running 12.3(22) w/ 256MB of RAM. I'm at the remote POP now, consoled in and looking at the box. The console hangs for 45-60s before I get a chance to run a quick command or two. Then it goes back to the hung state about 5 seconds later. The box keeps dropping my 2 OC3s and bouncing my IS-IS processes. Syslog didn't appear to capture anything interesting leading up to this crash. I had the box power cycled while I was driving down here. Overall the CPU is low and neither CPU nor memory were being taxed over the past number of months. The Net Background process is using a fair bit of the processor. Actually, that's an understatement. At times it's only using 9% or so. At other times it's up to 97% as was the case here: 3660-2.brd#sh proc cpu sort 5m CPU utilization for five seconds: 1%/0%; one minute: 17%; five minutes: 19% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 28 4715940 6117731049 97.09% 13.74% 9.23% 0 Net Background 31 238608 865 275847 2.65% 8.58% 8.48% 0 Per-Second Jobs 58336 684 12187 0.00% 0.56% 0.68% 0 Check heaps 607764 7776998 0.01% 0.27% 0.43% 0 IP Input 183856 8741441 0.00% 0.42% 0.33% 0 ARP Input 1672556 3046839 0.02% 0.12% 0.13% 0 ISIS Upd 140273215 182133 0.00% 0.00% 0.12% 0 Key Proc 1791680 1676 1002 0.00% 0.13% 0.11% 0 OSPF Router 471912 152 12578 0.00% 0.12% 0.11% 0 Per-minute Jobs 821792 597 3001 0.01% 0.15% 0.11% 0 IP Background 31828 238 7680 0.00% 0.11% 0.09% 0 OSPF Hello 100 644 1217529 0.00% 0.13% 0.08% 0 DHCPD Receive 511700 376 4521 0.00% 0.04% 0.05% 0 ATM Periodic 83 700 417 1678 0.00% 0.01% 0.02% 0 IP RIB Update 108 500 871574 0.00% 0.06% 0.02% 0 CEF process 124 172 471365 0.00% 0.04% 0.02% 0 Exec 166 620 1908324 0.00% 0.03% 0.02% 0 ISIS Adj 106 420 284 1478 0.00% 0.03% 0.00% 0 Adj Manager 6 436 1406310 0.00% 0.02% 0.00% 0 Pool Manager 91 188 556338 0.00% 0.01% 0.00% 0 ILMI Timer Proce 163 92 1795 51 0.00% 0.00% 0.00% 0 CLNS Input Per-Second Jobs is also using quite a bit of CPU. The log
Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series)
Netscreen 5400 15x the 3des performance, 2.5x number of tunnels and SUB 1 second stateful failover arent compelling enough reasons? Brandon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, April 04, 2008 6:15 AM To: Masood Ahmad Shah Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) Hi, If you really need a firewall thn you must go for Netscreen. Netscreen is a truly firewall with pretty nice/stable packet inspection engine and pretty nice GUI/Command line interface. even against ASA 5580-40 ? can someone point me to a compelling reason to think of a netscreen instead of such a box? alan ___ 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] Router down - What is Net Background?
Justin, What do you mean by die? A crash is not the same thing as a hang. Did your 3660 crash or hang? If the former, IOS should dump a crashinfo file - if you have one, lets take a look at it. If the latter, take a look at; http://www.cisco.com/en/US/products/hw/routers/ps359/products_tech_note09186a0080106fd7.shtml /eninja On Fri, Apr 4, 2008 at 7:42 AM, Justin Shore [EMAIL PROTECTED] wrote: I just had a 3660 terminating about 1500 PVCs for DSL die this AM. The 3660 is running 12.3(22) w/ 256MB of RAM. I'm at the remote POP now, consoled in and looking at the box. The console hangs for 45-60s before I get a chance to run a quick command or two. Then it goes back to the hung state about 5 seconds later. The box keeps dropping my 2 OC3s and bouncing my IS-IS processes. Syslog didn't appear to capture anything interesting leading up to this crash. I had the box power cycled while I was driving down here. Overall the CPU is low and neither CPU nor memory were being taxed over the past number of months. The Net Background process is using a fair bit of the processor. Actually, that's an understatement. At times it's only using 9% or so. At other times it's up to 97% as was the case here: 3660-2.brd#sh proc cpu sort 5m CPU utilization for five seconds: 1%/0%; one minute: 17%; five minutes: 19% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 28 4715940 6117731049 97.09% 13.74% 9.23% 0 Net Background 31 238608 865 275847 2.65% 8.58% 8.48% 0 Per-Second Jobs 58336 684 12187 0.00% 0.56% 0.68% 0 Check heaps 607764 7776998 0.01% 0.27% 0.43% 0 IP Input 183856 8741441 0.00% 0.42% 0.33% 0 ARP Input 1672556 3046839 0.02% 0.12% 0.13% 0 ISIS Upd 140273215 182133 0.00% 0.00% 0.12% 0 Key Proc 1791680 1676 1002 0.00% 0.13% 0.11% 0 OSPF Router 471912 152 12578 0.00% 0.12% 0.11% 0 Per-minute Jobs 821792 597 3001 0.01% 0.15% 0.11% 0 IP Background 31828 238 7680 0.00% 0.11% 0.09% 0 OSPF Hello 100 644 1217529 0.00% 0.13% 0.08% 0 DHCPD Receive 511700 376 4521 0.00% 0.04% 0.05% 0 ATM Periodic 83 700 417 1678 0.00% 0.01% 0.02% 0 IP RIB Update 108 500 871574 0.00% 0.06% 0.02% 0 CEF process 124 172 471365 0.00% 0.04% 0.02% 0 Exec 166 620 1908324 0.00% 0.03% 0.02% 0 ISIS Adj 106 420 284 1478 0.00% 0.03% 0.00% 0 Adj Manager 6 436 1406310 0.00% 0.02% 0.00% 0 Pool Manager 91 188 556338 0.00% 0.01% 0.00% 0 ILMI Timer Proce 163 92 1795 51 0.00% 0.00% 0.00% 0 CLNS Input Per-Second Jobs is also using quite a bit of CPU. The log has CPUHOG entries in it pointing at the Net Background process too: 000428: .Apr 4 08:36:31 CDT: %SYS-3-CPUHOG: Task ran for 50332 msec (10/0), process = Net Background, PC = 60439FFC. -Traceback= 6043A004 What does the Net Background process do? I haven't been able to find any answers on Cisco.com. We're in the middle of SmartNet renewals and negotiations and unfortunately this box's contract has expired. I can have our AM bless a TAC case for us if need be, assuming I can locate him; I think he's in training this week back East. Any ideas? I'm going to go back and scrutinize the log for anything useful. As of right now the box is intermittently pingable, corresponding directly to the brief instances that I can use the console. Customer packets seem to flow about as well. 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/ ___ 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] OT: Check Point v Cisco PIX (ASA 5500 Series)
Van: Yaroslav Doroshenko [mailto:[EMAIL PROTECTED] Verzonden: vr 4/4/2008 8:37 Aan: Nauwelaerts, Nick (TCM) CC: [EMAIL PROTECTED]; [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Onderwerp: Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) I believe dropping is also preferable if you need more performance and bandwidth capacity although I'm not sure sending RST cost CPU time on ASA platform. Correct, each packet you schedule takes up a certain amount of bandwidth cpu resources, though it'll be comparably small. Still that bandwidth cpu power will most likely be cheaper than the additional troubleshooting complexity you get by dropping. But as the introductary poster already stated, everyone has their own idea about this subject. I'm with the reject crew, that's the way tcp is meant to work. // nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series)
I believe dropping is also preferable if you need more performance and bandwidth capacity although I'm not sure sending RST cost CPU time on ASA platform. On Apr 4, 2008, at 7:18 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'd tend to think that it's less about portscans and more about preventing someone using you to perform a bounced RST flood. Just my 0x2. That's a good argument, but you can use your regular rate limiters (which are in place for icmp for example) and anomaly detection for that. Or whatever antispoofing you might have in place -- Yaroslav Doroshenko ___ 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] Router down - What is Net Background?
The problem turned out to be a bad NM-1A-OC3SMI. I scrounged up a spare and replaced it and resolved the issue. The bouncing circuit was definitely the problem. Even with all the sub-ints admin down the bouncing of the OC3 itself was enough to make the 3660 waiver. I can only imagine what it would have been like if I hadn't had the sub-ints down. Actually, I guess I don't have to try and imagine it; it happened this AM. The router did actually crash. 3 times this AM. I have 3 crash logs to work with. I'm going to use them to RMA the NM with TAC. All is well right now. I'm surprised at how painful an OC3 state change can be. I don't recall ever having that kind of drain on the resources when working with them before. It's something to remember though. Thanks for all the info, Justin e ninja wrote: Justin, What do you mean by die? A crash is not the same thing as a hang. Did your 3660 crash or hang? If the former, IOS should dump a crashinfo file - if you have one, lets take a look at it. If the latter, take a look at; http://www.cisco.com/en/US/products/hw/routers/ps359/products_tech_note09186a0080106fd7.shtml /eninja On Fri, Apr 4, 2008 at 7:42 AM, Justin Shore [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I just had a 3660 terminating about 1500 PVCs for DSL die this AM. The 3660 is running 12.3(22) w/ 256MB of RAM. I'm at the remote POP now, consoled in and looking at the box. The console hangs for 45-60s before I get a chance to run a quick command or two. Then it goes back to the hung state about 5 seconds later. The box keeps dropping my 2 OC3s and bouncing my IS-IS processes. Syslog didn't appear to capture anything interesting leading up to this crash. I had the box power cycled while I was driving down here. Overall the CPU is low and neither CPU nor memory were being taxed over the past number of months. The Net Background process is using a fair bit of the processor. Actually, that's an understatement. At times it's only using 9% or so. At other times it's up to 97% as was the case here: 3660-2.brd#sh proc cpu sort 5m CPU utilization for five seconds: 1%/0%; one minute: 17%; five minutes: 19% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 28 4715940 6117731049 97.09% 13.74% 9.23% 0 Net Background 31 238608 865 275847 2.65% 8.58% 8.48% 0 Per-Second Jobs 58336 684 12187 0.00% 0.56% 0.68% 0 Check heaps 607764 7776998 0.01% 0.27% 0.43% 0 IP Input 183856 8741441 0.00% 0.42% 0.33% 0 ARP Input 1672556 3046839 0.02% 0.12% 0.13% 0 ISIS Upd 140273215 182133 0.00% 0.00% 0.12% 0 Key Proc 1791680 1676 1002 0.00% 0.13% 0.11% 0 OSPF Router 471912 152 12578 0.00% 0.12% 0.11% 0 Per-minute Jobs 821792 597 3001 0.01% 0.15% 0.11% 0 IP Background 31828 238 7680 0.00% 0.11% 0.09% 0 OSPF Hello 100 644 1217529 0.00% 0.13% 0.08% 0 DHCPD Receive 511700 376 4521 0.00% 0.04% 0.05% 0 ATM Periodic 83 700 417 1678 0.00% 0.01% 0.02% 0 IP RIB Update 108 500 871574 0.00% 0.06% 0.02% 0 CEF process 124 172 471365 0.00% 0.04% 0.02% 0 Exec 166 620 1908324 0.00% 0.03% 0.02% 0 ISIS Adj 106 420 284 1478 0.00% 0.03% 0.00% 0 Adj Manager 6 436 1406310 0.00% 0.02% 0.00% 0 Pool Manager 91 188 556338 0.00% 0.01% 0.00% 0 ILMI Timer Proce 163 92 1795 51 0.00% 0.00% 0.00% 0 CLNS Input Per-Second Jobs is also using quite a bit of CPU. The log has CPUHOG entries in it pointing at the Net Background process too: 000428: .Apr 4 08:36:31 CDT: %SYS-3-CPUHOG: Task ran for 50332 msec (10/0), process = Net Background, PC = 60439FFC. -Traceback= 6043A004 What does the Net Background process do? I haven't been able to find any answers on Cisco.com. We're in the middle of SmartNet renewals and negotiations and unfortunately this box's contract has expired. I can have our AM bless a TAC case for us if need be, assuming I can locate him; I think he's in training this week back East. Any ideas? I'm going to go back and scrutinize the log for anything useful. As of right now the box is intermittently pingable, corresponding directly to the brief
[c-nsp] BGP redistribution
Hi All, Question on BGP to EIGRP redistribution In this topology, does the R2 router redistribute the IBGP route learned route (10.1.1.0/24) from R1. I am redistributing BGP into EIGRP on R2. I don't think it does, but I am not 100%. Thanks 10.1.1.0/24 | - | R4 R5 | | | | |EBGP |EBGP | | | | R1---R2R3-- IBGPEIGRP - The information contained in this transmission may be privileged and confidential and is intended only for the use of the person(s) named above. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender immediately by reply e-mail and destroy all copies of the original message. Please note that we do not accept account orders and/or instructions by e-mail, and therefore will not be responsible for carrying out such orders and/or instructions. If you, as the intended recipient of this message, the purpose of which is to inform and update our clients, prospects and consultants of developments relating to our services and products, would not like to receive further e-mail correspondence from the sender, please reply to the sender indicating your wishes. In the U.S.: 1345 Avenue of the Americas, New York, NY 10105. ___ 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] BGP redistribution
You have to use the bgp redistribute-internal command to redistribute iBGP routes into an IGP... Bill Murphy Senior Network Analyst University of Texas Health Science Center - Houston -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Uddin, Tahir Sent: Friday, April 04, 2008 3:23 PM To: Cisco-nsp Subject: [c-nsp] BGP redistribution Hi All, Question on BGP to EIGRP redistribution In this topology, does the R2 router redistribute the IBGP route learned route (10.1.1.0/24) from R1. I am redistributing BGP into EIGRP on R2. I don't think it does, but I am not 100%. Thanks 10.1.1.0/24 | - | R4 R5 | | | | |EBGP |EBGP | | | | R1---R2R3-- IBGPEIGRP - The information contained in this transmission may be privileged and confidential and is intended only for the use of the person(s) named above. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender immediately by reply e-mail and destroy all copies of the original message. Please note that we do not accept account orders and/or instructions by e-mail, and therefore will not be responsible for carrying out such orders and/or instructions. If you, as the intended recipient of this message, the purpose of which is to inform and update our clients, prospects and consultants of developments relating to our services and products, would not like to receive further e-mail correspondence from the sender, please reply to the sender indicating your wishes. In the U.S.: 1345 Avenue of the Americas, New York, NY 10105. ___ 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] OT: Check Point v Cisco PIX (ASA 5500 Series)
Hi, Netscreen 5400 15x the 3des performance, 2.5x number of tunnels and SUB 1 second stateful failover arent compelling enough reasons? i dont do VPN termination on firewalls. the stateful failover is a point though alan ___ 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] OT: Check Point v Cisco PIX (ASA 5500 Series)
Checkpoint also does stateful failover... Bill Murphy Senior Network Analyst University of Texas Health Science Center - Houston -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, April 04, 2008 5:05 PM To: Brandon Price Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) Hi, Netscreen 5400 15x the 3des performance, 2.5x number of tunnels and SUB 1 second stateful failover arent compelling enough reasons? i dont do VPN termination on firewalls. the stateful failover is a point though alan ___ 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] OT: Check Point v Cisco PIX (ASA 5500 Series)
As does the ASA 5520.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Murphy, William Sent: Friday, April 04, 2008 3:31 PM To: [EMAIL PROTECTED]; Brandon Price Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) Checkpoint also does stateful failover... Bill Murphy Senior Network Analyst University of Texas Health Science Center - Houston -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, April 04, 2008 5:05 PM To: Brandon Price Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) Hi, Netscreen 5400 15x the 3des performance, 2.5x number of tunnels and SUB 1 second stateful failover arent compelling enough reasons? i dont do VPN termination on firewalls. the stateful failover is a point though alan ___ 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] changing from ospf to eigrp
Hello, I would like to change our layer 3 switches from ospf to eirgrp. Is there a way I can accomplish this on a live system without causing problems? Can I run both at the same time? Thanks, Dan. ___ 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] changing from ospf to eigrp
Can I run both at the same time? - You can run both at the same time. I would like to change our layer 3 switches from ospf to eirgrp. Is there a way I can accomplish this on a live system without causing problems? - If you talking about redistribution between IGPs, then technically yes. Just be very careful not to create a routing loop. A strategy on how to do this will all depend on the size of your network and the complexity of the migration. May I inquire as to why your moving from OSPF to EIGRP? -Original Message- From: [EMAIL PROTECTED] on behalf of Dan Letkeman Sent: Fri 4/4/2008 7:48 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] changing from ospf to eigrp Hello, I would like to change our layer 3 switches from ospf to eirgrp. Is there a way I can accomplish this on a live system without causing problems? Can I run both at the same time? Thanks, Dan. ___ 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] changing from ospf to eigrp
We just went through years of pain and money to change from eigrp to ospf. :-) Jeff Cartier wrote: Can I run both at the same time? - You can run both at the same time. I would like to change our layer 3 switches from ospf to eirgrp. Is there a way I can accomplish this on a live system without causing problems? - If you talking about redistribution between IGPs, then technically yes. Just be very careful not to create a routing loop. A strategy on how to do this will all depend on the size of your network and the complexity of the migration. May I inquire as to why your moving from OSPF to EIGRP? -Original Message- From: [EMAIL PROTECTED] on behalf of Dan Letkeman Sent: Fri 4/4/2008 7:48 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] changing from ospf to eigrp Hello, I would like to change our layer 3 switches from ospf to eirgrp. Is there a way I can accomplish this on a live system without causing problems? Can I run both at the same time? Thanks, Dan. ___ 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] changing from ospf to eigrp
On Fri, 4 Apr 2008, Dan Letkeman wrote: Hello, I would like to change our layer 3 switches from ospf to eirgrp. Is there a way I can accomplish this on a live system without causing problems? Yes. I've done the opposite without much grief but we still called a it flag day and did everything in one maintenance window. Can I run both at the same time? YesBut keep in mind that EIGRP carries with it an administrative distance of only '5' whereas OSPF is at 110.You might consider moving the adminstrative distance for EIGRP to something above OSPF across your network until everyhting is in both routing processes. Then kill off OSFP and move AD back to it's default values. rgds, --r ___ 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] changing from ospf to eigrp
Can I run both at the same time? If you do, you may want to consider tweaking the administrative distances until EIGRP has been fully implemented across the network. Remember, by default EIGRP has an AD of 90 (internal) and OSPF of 110, so EIGRP-learned routes will be preferred. This has the potential to cause problems if EIGRP is misconfigured or only partially enabled during migration. stretch http://www.packetlife.net/ Dan Letkeman wrote: Hello, I would like to change our layer 3 switches from ospf to eirgrp. Is there a way I can accomplish this on a live system without causing problems? Can I run both at the same time? Thanks, Dan. ___ 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] changing from ospf to eigrp
On Sat, Apr 5, 2008 at 12:43 PM, Robert J. Huey [EMAIL PROTECTED] wrote: YesBut keep in mind that EIGRP carries with it an administrative distance of only '5' whereas OSPF is at 110.You might consider moving the adminstrative distance for EIGRP to something above OSPF across your network until everyhting is in both routing processes. Then kill off OSFP and move AD back to it's default values. rgds, --r EIGRP Summary Routes have an admin distance of 5 and have to be configured manually on a per interface basis Normal EIGRP Routes have an admin distance of 90 OSPF is admin distance is 110 My questions when doing this doing this would be. 1. How complicated is the network? 2. What better, rolling EIGRP in from the edges to the core, or out from the core to the edges? The beauty of moving from OSPF TO EIGRP is, in theory at least, the EIGRP Routes will be prefered over the OSPF Routes when the administrative distance is the deciding factor. Cheers ___ 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] changing from ospf to eigrp
So long as the OSPF network remains intact until the EIGRP network is up and running, OSPF should effectively operate as a backup route in the cases where EIGRP has no route, correct? It'd it be like running a floating static route, except your using a dynamic routing protocol, wouldn't it? On Sat, Apr 5, 2008 at 10:52 AM, Jeremy Stretch [EMAIL PROTECTED] wrote: Can I run both at the same time? If you do, you may want to consider tweaking the administrative distances until EIGRP has been fully implemented across the network. Remember, by default EIGRP has an AD of 90 (internal) and OSPF of 110, so EIGRP-learned routes will be preferred. This has the potential to cause problems if EIGRP is misconfigured or only partially enabled during migration. stretch http://www.packetlife.net/ Dan Letkeman wrote: Hello, I would like to change our layer 3 switches from ospf to eirgrp. Is there a way I can accomplish this on a live system without causing problems? Can I run both at the same time? Thanks, Dan. ___ 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] changing from ospf to eigrp
What you are doing is known as ships in the night routing where you run multiple protocols that are unaware of each other, I would go ahead and deploy your EIGRP config while keeping your OSPF running and as someone else has mentioned the default admin distance for EIGRP is 90 which will take precedence over your 110 OSPF, bare in mind if you use redistributed routes in EIGRP they will show up as admin distance of 170 though. Either way just go from router to router deploying your EIGRP and then when your happy you've done all your devices go and check your route tables to see what OSPF routes are still showing up and then determine why, and if they are needed, as EIGRP obviously isn't seeing them (at least from a non redistributed PoV). OSPF will pick up your slack while you deploy this in the above method, the only real danger I see is if you a) miss a router or b) fail to check the route tables for remaining OSPF routes after full EIGRP migration before turning OSPF off. Ben On 05/04/2008, at 12:30 PM, Whisper wrote: So long as the OSPF network remains intact until the EIGRP network is up and running, OSPF should effectively operate as a backup route in the cases where EIGRP has no route, correct? It'd it be like running a floating static route, except your using a dynamic routing protocol, wouldn't it? On Sat, Apr 5, 2008 at 10:52 AM, Jeremy Stretch [EMAIL PROTECTED] wrote: Can I run both at the same time? If you do, you may want to consider tweaking the administrative distances until EIGRP has been fully implemented across the network. Remember, by default EIGRP has an AD of 90 (internal) and OSPF of 110, so EIGRP-learned routes will be preferred. This has the potential to cause problems if EIGRP is misconfigured or only partially enabled during migration. stretch http://www.packetlife.net/ Dan Letkeman wrote: Hello, I would like to change our layer 3 switches from ospf to eirgrp. Is there a way I can accomplish this on a live system without causing problems? Can I run both at the same time? Thanks, Dan. ___ 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/ ___ 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] changing from ospf to eigrp
Actually just to correct myself before anyone else decides to, I think ships in the night refers to using a different network protocol aswell as a different routing protocol working independently of each other, ie ipv6 with OSPF and ipv4 with EIGRP, either way you get my drift :) On 05/04/2008, at 1:39 PM, Ben Steele wrote: What you are doing is known as ships in the night routing where you run multiple protocols that are unaware of each other, I would go ahead and deploy your EIGRP config while keeping your OSPF running and as someone else has mentioned the default admin distance for EIGRP is 90 which will take precedence over your 110 OSPF, bare in mind if you use redistributed routes in EIGRP they will show up as admin distance of 170 though. Either way just go from router to router deploying your EIGRP and then when your happy you've done all your devices go and check your route tables to see what OSPF routes are still showing up and then determine why, and if they are needed, as EIGRP obviously isn't seeing them (at least from a non redistributed PoV). OSPF will pick up your slack while you deploy this in the above method, the only real danger I see is if you a) miss a router or b) fail to check the route tables for remaining OSPF routes after full EIGRP migration before turning OSPF off. Ben On 05/04/2008, at 12:30 PM, Whisper wrote: So long as the OSPF network remains intact until the EIGRP network is up and running, OSPF should effectively operate as a backup route in the cases where EIGRP has no route, correct? It'd it be like running a floating static route, except your using a dynamic routing protocol, wouldn't it? On Sat, Apr 5, 2008 at 10:52 AM, Jeremy Stretch [EMAIL PROTECTED] wrote: Can I run both at the same time? If you do, you may want to consider tweaking the administrative distances until EIGRP has been fully implemented across the network. Remember, by default EIGRP has an AD of 90 (internal) and OSPF of 110, so EIGRP-learned routes will be preferred. This has the potential to cause problems if EIGRP is misconfigured or only partially enabled during migration. stretch http://www.packetlife.net/ Dan Letkeman wrote: Hello, I would like to change our layer 3 switches from ospf to eirgrp. Is there a way I can accomplish this on a live system without causing problems? Can I run both at the same time? Thanks, Dan. ___ 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/ ___ 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] OT: Check Point v Cisco PIX (ASA 5500 Series)
And yes this is such an important feature since the devices are so crappy they keep crashing. Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gregori Parker Sent: Friday, April 04, 2008 2:36 PM To: Murphy, William ; [EMAIL PROTECTED]; Brandon Price Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) As does the ASA 5520.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Murphy, William Sent: Friday, April 04, 2008 3:31 PM To: [EMAIL PROTECTED]; Brandon Price Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) Checkpoint also does stateful failover... Bill Murphy Senior Network Analyst University of Texas Health Science Center - Houston -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, April 04, 2008 5:05 PM To: Brandon Price Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OT: Check Point v Cisco PIX (ASA 5500 Series) Hi, Netscreen 5400 15x the 3des performance, 2.5x number of tunnels and SUB 1 second stateful failover arent compelling enough reasons? i dont do VPN termination on firewalls. the stateful failover is a point though alan ___ 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/ ___ 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] Cat6500 - Support for MPLS and IPv6
Gert, FWIW, I spent a lot of time researching the 6500/7600 BU issue in preparation for our last round of upgrades. The best (and most honest) answer I got about service provider software features on the 6500 series was this: We'll still support MPLS, IPv6 etc, but new feature may be released on the 7600 series first, and made available for the 6500 series later. It was also implied that some specific features may not make the 6500 code train at all. -- Stephen Gert Doering wrote: Hi, On Sun, Mar 30, 2008 at 10:52:04PM -0400, Juno Guy wrote: It is my understanding that somewhere after the 12.2SX release MPLS and IPv6 will no longer be supported on the 6500 (but will continue to be supported on the 7600 as I understand). Well, as far as I understand, this is currently not the case, and I haven't seen any announcement to that extent. (Except as has already been written: the *modular* variant of SXF had no support for either, but that was not yet, and not not any longer). OTOH, personally, I have great distrust for the 7600/6500 BUs, and it wouldn't surprise me to come to a point in the future where I need to decide do I want support for 32 bit AS numbers, or do I want support for my existing hardware. Cisco needs to do a *lot* to get back the customer trust that these two BUs have destroyed. gert ___ 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 2811 and WIC-1DSU-T1.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Doug McIntyre Sent: Thursday, April 03, 2008 8:38 PM To: Justin Shore Cc: 'cisco-nsp' Subject: Re: [c-nsp] Cisco 2811 and WIC-1DSU-T1. I believe the main reason for this (besides the fact that the WIC-1DSU-T1 card was EOL'd before the ISR was released) is the rampant piracy of this WIC, and this is an effort by Cisco to lessen some of that. I think that isn't correct. The V2 introduced the ability to attenuate output transmission with the cablelength parameter. This would have required a fundamental redesign of the CSU part of the ASIC chip. I'm sure they also took the opportunity to cheapen the WIC down as well. (ie: their cost to manufacture, not our price we pay) Likely there were some timing parameters between the WIC interface and WIC slot that changed, and the designers didn't want to go back and redesign the WIC or slot silicon to match the older routers. As long as Cisco has their stuff manufactured overseas, in Asia, they are going to have rampant piracy of their parts. After all it's the same production factories that are churning out the Cisco parts for Cisco that are also churning out the counterfeited stuff on the sly for the pirates. If Cisco were to shut down all their Asian production and start making the stuff in the US like they used to do, the piracy problems would go away. Ted ___ 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/
