Re: [c-nsp] Nagios plugin to check Cisco hardware
Well the original script that I just posted also has the option to check powersupply's,fans and temp using the cisco option instead of ciscoSW further more I check: Routing Engine CPU Routing Engine Memory Supervisor Engine CPU Supervisor Engine Memory some BGP sessions and some interfaces BTW, I use Opsview (opsview.org) witch is a great web interface for controlling your nagios without using those awful nagios scripts. - Original Message - From: Eric Cables [EMAIL PROTECTED] To: Michiel Timmers [EMAIL PROTECTED] Cc: cisco-nsp@puck.nether.net Sent: Tuesday, March 25, 2008 7:59 PM Subject: Re: [c-nsp] Nagios plugin to check Cisco hardware Thanks for the tip, this is a pretty useful plugin. This brings up the question of any other useful plugins people are using in Nagios. I know I've spent plenty of time searching NagiosExchange, but it is a somewhat daunting task, given the huge hierarchical layout. I'd like to know of the top plugins, similar to how Cacti's top plugins are thold, mactrack, etc. On Tue, Mar 25, 2008 at 3:22 PM, Michiel Timmers [EMAIL PROTECTED] wrote: Hi all, I post this here because I think that there are a lot of Nagios users on this list that might find the following useful. I recently enriched a Nagios plugin to check all sorts of Juniper hardware using SNMP. The original plugin also let you alow to check Cisco blades/modules and is created by Patrick Proy ( http://nagios.manubulon.com/) but he never published this updated version on his site but I think you like it. Here is a example output of a Cisco 6500 router that had some problems: #./check_snmp_environment.pl -H ip -C snmp -T ciscoSW Card slot 0(Centralized Forwarding Card): status DownCard slot 4(CEF720 4 port 10-Gigabit Ethernet): status Down7/9cards OK, 0modules OK : CRITICAL and on a 12400: #./check_snmp_environment.pl -H ip -C snmp -T ciscoSW Card slot 0(Performance Route Processor): status Down, : 6/7cards OK, : CRITICAL See the following site for more details and download: http://www.nagiosexchange.org/Networking.53.0.html?tx_netnagext_pi1[p_view]=1269http://www.nagiosexchange.org/Networking.53.0.html?tx_netnagext_pi1%5Bp_view%5D=1269 Michiel ___ 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/ -- Eric Cables ___ 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-voip] Cisco VPN Client for 64-bit????
Always keep in mind there's the Linux option, one day it might be the right choice for admins... Users? They'll get used to it, they're like farm animals, they'll eat what you give them and eventually learn to love it... :) Ziv -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, March 25, 2008 12:12 PM To: Jonathan Charles Cc: [EMAIL PROTECTED]; Scott Voll; cisco-nsp@puck.nether.net; Jason Aarons (US) Subject: Re: [c-nsp] [cisco-voip] Cisco VPN Client for 64-bit Hi, Yep... that's what I ended up doing... there are some other ways, eg http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2007-October/001968.html 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/ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6509 noob question
The following two could probably help you too: remote command switch xxx remote login switch -- Tassos David Prall wrote on 25/3/2008 11:05 μμ: Switch console can only be done from catos. You want to find and entry that has a mac address within the cisco range. What does sh cdp neighbor give you. I don't remember this working, but it has been a long time. Then sh cdp neighbor detail for the address. Might get lucky. David -- http://dcp.dcptech.com -Original Message- From: Adam Greene [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2008 4:58 PM To: David Prall; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 6509 noob question Thanks, all. Neither the session nor switch console commands are recognized on the IOS side. Is there anything specific I should look for in the ARP table? There are about 1000 entries in there. I guess next step will be to call this switch's admin thanks, Adam - Original Message - From: David Prall [EMAIL PROTECTED] To: 'Adam Greene' [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Tuesday, March 25, 2008 4:45 PM Subject: RE: [c-nsp] 6509 noob question You need the management interface address for the catos side, from their you can session to the msfc/msfc's. Can telnet from the msfc to the catos side if you know the address. Might be able to figure out where it is from the arp table. David -- http://dcp.dcptech.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Greene Sent: Tuesday, March 25, 2008 4:20 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] 6509 noob question How's this for a stupid question? I'm working remotely on a pair of 6509's: CatOS 8.3(3) / IOS 12.1(8a)E3. I can telnet to the devices and access the IOS CLI. The million-dollar question: how to I access the CatOS CLI? As far as I can tell all the switch configs live in CatOS while the routing configs live in IOS, and I'm trying to gain access to the spanning-tree info (CatOS), to see if the switch is running PVST+, MST or what. 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/ ___ 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] EasyVPN IOS-ASA55xx with no user interaction?
Hi, I have a setup which consists of a IOS based router connecting to a ASA5500 firewall device. I've got it working in network extension mode but it requires user interaction on the router, heres a cut from the log: *Mar 3 02:50:28.823: EZVPN(EASYVPN): Pending XAuth Request, Please enter the following command: *Mar 3 02:50:28.823: EZVPN: crypto ipsec client ezvpn xauth For the tunnel to be established you have to do `crypto ipsec client ezvpn xauth` from the CLI and enter a username and password. Is there any way I can get around doing the above? I dont want the user to have to enter that, just turn ongo. EasyVPN config looks like: crypto ipsec client ezvpn EASYVPN connect auto group mytunnel key mykey mode network-extension peer mypeer username myusername password mypassword ASA: group-policy myGROUP attributes password-storage enable split-tunnel-policy tunnelspecified split-tunnel-network-list value ezvpn1 nem enable I was under the impression that 'password-storage enable' would do the trick but I still have to enter the password. Any help would be appreciated. Regards, W ___ 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] control-plane qos marking
Hello! I there any way to set some dscp value to packets originating from Cisco IOS itself? I mean syslog messages, netflow data export, snmp messages, icmp and so on. I know about default cs6 marking for routing protocols, but it is not all traffic :) Could anybody point me to right direction? Thanks! P.S. platforms are C7600 and Cat3750 -- Dmitry Kiselev ___ 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] EasyVPN IOS-ASA55xx with no user interaction?
Hi, You need isakmp ikev1-user-authentication none under tunnel-group myGROUP ipsec-attributes. It is advisable to have another group for Easy VPN peers and not mix them with users if you use XAUTH - the latter is used for user authentication while IKE is used for device authentication. On Mar 26, 2008, at 13:01, William wrote: Hi, I have a setup which consists of a IOS based router connecting to a ASA5500 firewall device. I've got it working in network extension mode but it requires user interaction on the router, heres a cut from the log: *Mar 3 02:50:28.823: EZVPN(EASYVPN): Pending XAuth Request, Please enter the following command: *Mar 3 02:50:28.823: EZVPN: crypto ipsec client ezvpn xauth For the tunnel to be established you have to do `crypto ipsec client ezvpn xauth` from the CLI and enter a username and password. Is there any way I can get around doing the above? I dont want the user to have to enter that, just turn ongo. EasyVPN config looks like: crypto ipsec client ezvpn EASYVPN connect auto group mytunnel key mykey mode network-extension peer mypeer username myusername password mypassword ASA: group-policy myGROUP attributes password-storage enable split-tunnel-policy tunnelspecified split-tunnel-network-list value ezvpn1 nem enable I was under the impression that 'password-storage enable' would do the trick but I still have to enter the password. Any help would be appreciated. Regards, W ___ 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/ HTH Kaj -- Kaj J. Niemi [EMAIL PROTECTED] +358 45 63 12000 ___ 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] control-plane qos marking
On Wed, Mar 26, 2008 at 02:36:56PM +0200, Dmitry Kiselev wrote: Hello! I there any way to set some dscp value to packets originating from Cisco IOS itself? I mean syslog messages, netflow data export, snmp messages, icmp and so on. I know about default cs6 marking for routing protocols, but it is not all traffic :) Could anybody point me to right direction? Thanks! P.S. platforms are C7600 and Cat3750 -- Dmitry Kiselev You can use PBR to mark the local generated traffic: ! Use ACL to specify what you want to have marked access-list 166 permit ... ... route-map local-qos permit 10 match ip address 166 set ip precedence x ip local policy route-map local-qos regards Reinhold ___ 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] pvst+ r-pvst (WAS Re: mst pvst)
Thanks, Peter! - Original Message - From: Peter Rathlev [EMAIL PROTECTED] To: Adam Greene [EMAIL PROTECTED] Cc: cisco-nsp@puck.nether.net Sent: Tuesday, March 25, 2008 6:42 PM Subject: Re: [c-nsp] pvst+ r-pvst (WAS Re: mst pvst) On Tue, 2008-03-25 at 17:53 -0400, Adam Greene wrote: OK, I made my way into the 6509, and it's not running MST as expected, but PVST+. Duh ... the configs say set spantree mode pvst+ so I should have known. Anyways. So ... 6509: PVST+ 3750: rapid-PVST My impression is that the 3750 will fall back to 802.1D in this scenario, which means slower convergence, but otherwise things will work OK. Any gotchas I should be aware of before I try this (besides checking the topology and adjusting priorities as needed)? Nope, Rapid PVST is backwards compatible with PVST+, so just slower convergence on the PVST links. Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FWSM - No Traceroute
The FWSM isn't a half-assed ASA. It is a firewall-only module. It doesn't have the VPN capabilities of the ASA, obviously does not have modules you can add like an IPS or CSC, and is strictly a firewall. It also lags behind in features; you'll notice that the FWSM is one or two features behind an ASA. I have no doubt you'll be impressed with the next major rev when it comes out though. So I wouldn't call the FWSM a half-assed ASA, meaning it wanted to be like an ASA but couldn't quite hack it. Rather, it tries to fit into a different role, and does quite well at it. Thanks, Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Sent: Tuesday, March 25, 2008 5:24 PM To: Raul Lopez Nevot Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] FWSM - No Traceroute traceroute is in ASA though... /act# traceroute ? Hostname or A.B.C.D Trace route to IPv4 address or hostname /act# traceroute and FWSM is like a half-ass ASA..thats why i am curious what exactly is the technical reason that there isnt a traceroute command On Tue, Mar 25, 2008 at 5:12 PM, Raul Lopez Nevot [EMAIL PROTECTED] wrote: On Tue, Mar 25, 2008 at 8:17 PM, Christian [EMAIL PROTECTED] wrote: yeah why is there no traceroute command, sorrry not being clearer This question only can be answered by cisco people, but I live with cisco PIX (so then ASA and FWSM, we have a few) since version 4.4 and never was this command there. Since the PIX is not native from cisco (its OS, named Finesse, was from another company, Network Translation I think it was), and is not IOS-powered, sure the former did not implement this command and nobody at Cisco did. By the way, and sorry for the very BIG off-topic, do anybody know the name of Cisco Engineer that converted a PIX into FWSM? They told me this engineer is from Sabadell (Barcelona/Spain), and I'm from there, and it would be nice to meet him! Sorry again for the OT. ___ 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/ smime.p7s Description: S/MIME cryptographic signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6509 noob question
I believe those commands are for Native IOS, to get to the switch processor, where you can do nifty things like a packet capture if you know the commands. For Hybrid CatOS/IOS you'd have to go from the SP to the RP. Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tassos Chatzithomaoglou Sent: Wednesday, March 26, 2008 6:40 AM To: David Prall Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 6509 noob question The following two could probably help you too: remote command switch xxx remote login switch -- Tassos David Prall wrote on 25/3/2008 11:05 μμ: Switch console can only be done from catos. You want to find and entry that has a mac address within the cisco range. What does sh cdp neighbor give you. I don't remember this working, but it has been a long time. Then sh cdp neighbor detail for the address. Might get lucky. David -- http://dcp.dcptech.com -Original Message- From: Adam Greene [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2008 4:58 PM To: David Prall; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 6509 noob question Thanks, all. Neither the session nor switch console commands are recognized on the IOS side. Is there anything specific I should look for in the ARP table? There are about 1000 entries in there. I guess next step will be to call this switch's admin thanks, Adam - Original Message - From: David Prall [EMAIL PROTECTED] To: 'Adam Greene' [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Tuesday, March 25, 2008 4:45 PM Subject: RE: [c-nsp] 6509 noob question You need the management interface address for the catos side, from their you can session to the msfc/msfc's. Can telnet from the msfc to the catos side if you know the address. Might be able to figure out where it is from the arp table. David -- http://dcp.dcptech.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Greene Sent: Tuesday, March 25, 2008 4:20 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] 6509 noob question How's this for a stupid question? I'm working remotely on a pair of 6509's: CatOS 8.3(3) / IOS 12.1(8a)E3. I can telnet to the devices and access the IOS CLI. The million-dollar question: how to I access the CatOS CLI? As far as I can tell all the switch configs live in CatOS while the routing configs live in IOS, and I'm trying to gain access to the spanning-tree info (CatOS), to see if the switch is running PVST+, MST or what. 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/ ___ 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/ smime.p7s Description: S/MIME cryptographic signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FWSM - No Traceroute
Hi, The FWSM works really at high bandwidth rates and integrates quite well into a Catalyst (no cabling, your choice of being in front of MSFC or behind, etc.) as long as you do not exceed limits on ACEs, see http://www.cisco.com/en/US/docs/security/fwsm/fwsm23/configuration/guide/specs.html#wpxref93963 - in very high security (or pedantic ;-)) environment it can happen quite soon. On Mar 26, 2008, at 15:25, Fred Reimer wrote: The FWSM isn't a half-assed ASA. It is a firewall-only module. It doesn't have the VPN capabilities of the ASA, obviously does not have modules you can add like an IPS or CSC, and is strictly a firewall. It also lags behind in features; you'll notice that the FWSM is one or two features behind an ASA. I have no doubt you'll be impressed with the next major rev when it comes out though. So I wouldn't call the FWSM a half-assed ASA, meaning it wanted to be like an ASA but couldn't quite hack it. Rather, it tries to fit into a different role, and does quite well at it. Thanks, Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Sent: Tuesday, March 25, 2008 5:24 PM To: Raul Lopez Nevot Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] FWSM - No Traceroute traceroute is in ASA though... /act# traceroute ? Hostname or A.B.C.D Trace route to IPv4 address or hostname /act# traceroute and FWSM is like a half-ass ASA..thats why i am curious what exactly is the technical reason that there isnt a traceroute command On Tue, Mar 25, 2008 at 5:12 PM, Raul Lopez Nevot [EMAIL PROTECTED] wrote: On Tue, Mar 25, 2008 at 8:17 PM, Christian [EMAIL PROTECTED] wrote: yeah why is there no traceroute command, sorrry not being clearer This question only can be answered by cisco people, but I live with cisco PIX (so then ASA and FWSM, we have a few) since version 4.4 and never was this command there. Since the PIX is not native from cisco (its OS, named Finesse, was from another company, Network Translation I think it was), and is not IOS-powered, sure the former did not implement this command and nobody at Cisco did. By the way, and sorry for the very BIG off-topic, do anybody know the name of Cisco Engineer that converted a PIX into FWSM? They told me this engineer is from Sabadell (Barcelona/Spain), and I'm from there, and it would be nice to meet him! Sorry again for the OT. ___ 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/ HTH Kaj -- Kaj J. Niemi [EMAIL PROTECTED] +358 45 63 12000 ___ 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] Monitoring Tengigabit Interfaces
Hi, I would like to monitor the Optical Power in the Ten Gigabit interface. I use this command : show int teX/y transceiver. On some interfaces I've a answer : 1#sh int te2/1 transceiver Transceiver monitoring is disabled for all interfaces. ITU Channel not available (Wavelength not available), Transceiver is internally calibrated. If device is externally calibrated, only calibrated values are printed. ++ : high alarm, + : high warning, - : low warning, -- : low alarm. NA or N/A: not applicable, Tx: transmit, Rx: receive. mA: milliamperes, dBm: decibels (milliwatts). Optical Optical Temperature Voltage Current Tx Power Rx Power Port (Celsius)(Volts) (mA) (dBm) (dBm) --- --- --- Te2/1 38.5 0.00 7.9 -1.9 -3.0 But for another I have : #sh int gi9/1 transceiver Diagnostic Monitoring Data is not available. Why this command failed on some interfaces ? Regards, Sébastien DAVID Service Exploitation Réseau Ecritel site de Clichy : 7-9, rue Petit 92582 Clichy Cedex Tél: 01.73.02.50.76 Fax: 01.47.56.04.48 Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Site web: www.ecritel.fr http://www.ecritel.fr/ This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internetcan not guarantee the integrity of this message. ECRITEL (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, ECRITEL (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. ___ 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] control-plane qos marking
Hello! On Wed, Mar 26, 2008 at 02:15:46PM +0100, Reinhold Fischer wrote: I there any way to set some dscp value to packets originating from Cisco IOS itself? I mean syslog messages, netflow data export, snmp messages, icmp and so on. I know about default cs6 marking for routing protocols, but it is not all traffic :) Could anybody point me to right direction? Thanks! P.S. platforms are C7600 and Cat3750 You can use PBR to mark the local generated traffic: ! Use ACL to specify what you want to have marked access-list 166 permit ... ... route-map local-qos permit 10 match ip address 166 set ip precedence x ip local policy route-map local-qos Aha! It works fine on Cat3750 and all RP's traffic on C7600. Thanks a lot! But question still open for 7600 SP - NDE process for example. -- Dmitry Kiselev ___ 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] control-plane qos marking
Dmitry Kiselev wrote on Wednesday, March 26, 2008 3:06 PM: Hello! On Wed, Mar 26, 2008 at 02:15:46PM +0100, Reinhold Fischer wrote: I there any way to set some dscp value to packets originating from Cisco IOS itself? I mean syslog messages, netflow data export, snmp messages, icmp and so on. I know about default cs6 marking for routing protocols, but it is not all traffic :) Could anybody point me to right direction? Thanks! P.S. platforms are C7600 and Cat3750 You can use PBR to mark the local generated traffic: ! Use ACL to specify what you want to have marked access-list 166 permit ... ... route-map local-qos permit 10 match ip address 166 set ip precedence x ip local policy route-map local-qos Aha! It works fine on Cat3750 and all RP's traffic on C7600. Thanks a lot! But question still open for 7600 SP - NDE process for example. on most platforms, NDE traffic can't be classified locally as it bypasses the regular IOS output features (which also include local PBR), and I think this applies to the 7600 too.. Flexible netflow (future Netflow infrastructure) allows to set DSCP for netflow export packets.. oli ___ 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] FWSM - No Traceroute
What I'll add to this is that just like any other Cisco product, if you know of a feature that really should be available, dont hesitate to let your account team know about them. I've been in regular contact with them to try to get a handle on some things that could be improved in the SNMP implementation on the FWSM, among other things. As the saying goes, the squeaky wheel gets the grease :) jms ___ 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] Monitoring Tengigabit Interfaces
Optics have to be DOM Compliant. http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/compa tibility/matrix/OL_8031.html http://tinyurl.com/2jedp2 David -- http://dcp.dcptech.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DAVID Sébastien Sent: Wednesday, March 26, 2008 9:44 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Monitoring Tengigabit Interfaces Hi, I would like to monitor the Optical Power in the Ten Gigabit interface. I use this command : show int teX/y transceiver. On some interfaces I've a answer : 1#sh int te2/1 transceiver Transceiver monitoring is disabled for all interfaces. ITU Channel not available (Wavelength not available), Transceiver is internally calibrated. If device is externally calibrated, only calibrated values are printed. ++ : high alarm, + : high warning, - : low warning, -- : low alarm. NA or N/A: not applicable, Tx: transmit, Rx: receive. mA: milliamperes, dBm: decibels (milliwatts). Optical Optical Temperature Voltage Current Tx Power Rx Power Port (Celsius)(Volts) (mA) (dBm) (dBm) --- --- --- Te2/1 38.5 0.00 7.9 -1.9 -3.0 But for another I have : #sh int gi9/1 transceiver Diagnostic Monitoring Data is not available. Why this command failed on some interfaces ? Regards, Sébastien DAVID Service Exploitation Réseau Ecritel site de Clichy : 7-9, rue Petit 92582 Clichy Cedex Tél: 01.73.02.50.76 Fax: 01.47.56.04.48 Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Site web: www.ecritel.fr http://www.ecritel.fr/ This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internetcan not guarantee the integrity of this message. ECRITEL (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, ECRITEL (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. ___ 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] 6509 noob question
Those are both commands available in Native IOS. I don't know if they are available in Hybrid, although it would be nice to know if they were. -- http://dcp.dcptech.com -Original Message- From: Tassos Chatzithomaoglou [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2008 6:40 AM To: David Prall Cc: 'Adam Greene'; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 6509 noob question The following two could probably help you too: remote command switch xxx remote login switch -- Tassos David Prall wrote on 25/3/2008 11:05 μμ: Switch console can only be done from catos. You want to find and entry that has a mac address within the cisco range. What does sh cdp neighbor give you. I don't remember this working, but it has been a long time. Then sh cdp neighbor detail for the address. Might get lucky. David -- http://dcp.dcptech.com -Original Message- From: Adam Greene [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2008 4:58 PM To: David Prall; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 6509 noob question Thanks, all. Neither the session nor switch console commands are recognized on the IOS side. Is there anything specific I should look for in the ARP table? There are about 1000 entries in there. I guess next step will be to call this switch's admin thanks, Adam - Original Message - From: David Prall [EMAIL PROTECTED] To: 'Adam Greene' [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Tuesday, March 25, 2008 4:45 PM Subject: RE: [c-nsp] 6509 noob question You need the management interface address for the catos side, from their you can session to the msfc/msfc's. Can telnet from the msfc to the catos side if you know the address. Might be able to figure out where it is from the arp table. David -- http://dcp.dcptech.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Greene Sent: Tuesday, March 25, 2008 4:20 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] 6509 noob question How's this for a stupid question? I'm working remotely on a pair of 6509's: CatOS 8.3(3) / IOS 12.1(8a)E3. I can telnet to the devices and access the IOS CLI. The million-dollar question: how to I access the CatOS CLI? As far as I can tell all the switch configs live in CatOS while the routing configs live in IOS, and I'm trying to gain access to the spanning-tree info (CatOS), to see if the switch is running PVST+, MST or what. 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/ ___ 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] Cisco Security Advisory: Vulnerability in Cisco IOS with OSPF, MPLS VPN, and Supervisor 32, Supervisor 720, or Route Switch Processor 720
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Vulnerability in Cisco IOS with OSPF, MPLS VPN, and Supervisor 32, Supervisor 720, or Route Switch Processor 720 Advisory ID: cisco-sa-20080326-queue http://www.cisco.com/warp/public/707/cisco-sa-20080326-queue.shtml Revision 1.0 For Public Release 2008 March 26 1600 UTC (GMT) Summary === Certain Cisco Catalyst 6500 Series and Cisco 7600 Router devices that run branches of Cisco IOS based on 12.2 can be vulnerable to a denial of service vulnerability that can prevent any traffic from entering an affected interface. For a device to be vulnerable, it must be configured for Open Shortest Path First (OSPF) Sham-Link and Multi Protocol Label Switching (MPLS) Virtual Private Networking (VPN). This vulnerability only affects Cisco Catalyst 6500 Series or Catalyst 7600 Series devices with the Supervisor Engine 32 (Sup32), Supervisor Engine 720 (Sup720) or Route Switch Processor 720 (RSP720) modules. The Supervisor 32, Supervisor 720, Supervisor 720-3B, Supervisor 720-3BXL, Route Switch Processor 720, Route Switch Processor 720-3C, and Route Switch Processor 720-3CXL are all potentially vulnerable. The OSPF and MPLS VPNs are not enabled by default. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080326-queue.shtml Note: The March 26, 2008 publication includes five Security Advisories. The Advisories all affect Cisco IOS. Each Advisory lists the releases that correct the vulnerability described in the Advisory, and the Advisories also detail the releases that correct the vulnerabilities in all five Advisories. Please reference the following software table to find a release which fixes all published Security Advisories as of March 26th, 2008. * March 26th bundled IOS Advisory Table http://www.cisco.com/warp/public/707/cisco-sa-20080326-bundle.shtml Individual publication links are listed below: * Cisco IOS Virtual Private Dial-up Network Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20080326-pptp.shtml * Multiple DLSw Denial of Service Vulnerabilities in Cisco IOS http://www.cisco.com/warp/public/707/cisco-sa-20080326-dlsw.shtml * Cisco IOS User Datagram Protocol Delivery Issue For IPv4/IPv6 Dual-stack Routers http://www.cisco.com/warp/public/707/cisco-sa-20080326-IPv4IPv6.shtml * Vulnerability in Cisco IOS with OSPF, MPLS VPN, and Supervisor 32, Supervisor 720, or Route Switch Processor 720 http://www.cisco.com/warp/public/707/cisco-sa-20080326-queue.shtml * Cisco IOS Multicast Virtual Private Network (MVPN) Data Leak http://www.cisco.com/warp/public/707/cisco-sa-20080326-mvpn.shtml Affected Products Vulnerable Products +-- All Cisco products based on the Supervisor Engine 32 (Sup32), Supervisor Engine 720 (Sup720) or Route Switch Processor 720 (RSP720) are potentially vulnerable. Cisco Sup720 and RSP720 products have support for daughter cards that enhance their functionality. These daughter cards attach directly to the Sup720 or RSP720 and have names like PFC-3B, PFC-3BXL, PFC-3C, and PFC-3CXL. The product number of the Sup720 or RSP720 can change to reflect the daughter card that is installed, such as RSP720-3CXL. Because the vulnerability affects the Sup720 and RSP720, all versions of the Sup720 or RSP720 are vulnerable, regardless of the daughter card that is installed. * Cisco Catalyst 6500 Series devices with the Sup32, Sup720, Sup720-3B, or Sup720-3BXL * Cisco 7600 Series devices with the Sup32, Sup720, Sup720-3B, or Sup720-3BXL * Cisco 7600 Series devices with the RSP720, RSP720-3C, or RSP720-3CXL * Cisco ME 6524 Ethernet Switch Products Confirmed Not Vulnerable + No other Cisco products are currently known to be affected by this vulnerability. Cisco Bug ID CSCsf12082 was integrated into additional IOS releases that do not run on the vulnerable hardware, but only the platforms mentioned in the Vulnerable Products section above are affected by this vulnerability. Details === Vulnerable Cisco devices, when configured for Multi Protocol Label Switching (MPLS) Virtual Private Networking (VPN) and Open Shortest Path First (OSPF) sham-link, can suffer from a blocked queue, memory leak and/or restart of the device This vulnerability is documented in Cisco bug ID CSCsf12082, and has been assigned CVE ID CVE-2008-0057. The following combination of hardware and software configuration must be present for the device to be vulnerable: * Cisco Catalyst Sup32, Sup720, or RSP720 is present * MPLS VPN is configured * OSPF sham-link is configured In order to determine whether you are running this feature, use the show running-config command and search for the address-family vpnv4 and area sham-link router configuration commands. The following command
[c-nsp] BGP Router Considerations
Hi folks. Looking for some input on a network design. Today, pair of 6509's with Sup2/MSFC2 and a Cisco 12012 GSR make up the distribution and core routing. What I'm considering is removing the 12012 because of the space it consumes (does all BGP today) and replacing it with a pair of 7606's Sup720-3BXL etc For BGP edge that's feeding 3 full BGP transit feeds and a couple hundred peering sessions will the Sup720-3BXL cope ok from a memory perspective. The traffic is not a lot (500Mb/s or so) on this network . My final version would be a pair of 6509's doing core switching (distribution layer routing) in a mesh configuration to a pair of 7606's doing core routing .. Should I be looking at small GSR's for the core routing instead? Thanks for any feedback.. We have lots of 6500's but everyone keeps telling me lately to go 7600 series instead?? Paul ___ 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] Cisco Security Advisory: Cisco IOS Virtual Private Dial-up Network Denial of Service Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Cisco IOS Virtual Private Dial-up Network Denial of Service Vulnerability Advisory ID: cisco-sa-20080326-pptp http://www.cisco.com/warp/public/707/cisco-sa-20080326-pptp.shtml Revision 1.0 For Public Release 2008 March 26 1600 UTC (GMT) Summary === Two vulnerabilities exist in the virtual private dial-up network (VPDN) solution when Point-to-Point Tunneling Protocol (PPTP) is used in certain Cisco IOS releases prior to 12.3. PPTP is only one of the supported tunneling protocols used to tunnel PPP frames within the VPDN solution. The first vulnerability is a memory leak that occurs as a result of PPTP session termination. The second vulnerability may consume all interface descriptor blocks on the affected device because those devices will not reuse virtual access interfaces. If these vulnerabilities are repeatedly exploited, the memory and/or interface resources of the attacked device may be depleted. Cisco has made free software available to address these vulnerabilities for affected customers. There are no workarounds available to mitigate the effects of these vulnerabilities. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080326-pptp.shtml Note: The March 26, 2008 publication includes five security advisories. The advisories all address vulnerabilities in Cisco's Internetwork Operating System (IOS) software. Each advisory lists the releases that correct the vulnerability described in the advisory, and also lists the releases that correct the vulnerabilities in the other five advisories. Please reference the following software table to find a release that fixes all published software advisories as of March 26th, 2008: * March 26th Bundled IOS Advisory Table http://www.cisco.com/warp/public/707/cisco-sa-20080326-bundle.shtml Individual publication links are listed below: * Cisco IOS Virtual Private Dial-up Network Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20080326-pptp.shtml * Multiple DLSw Denial of Service Vulnerabilities in Cisco IOS http://www.cisco.com/warp/public/707/cisco-sa-20080326-dlsw.shtml * Cisco IOS User Datagram Protocol Delivery Issue For IPv4/IPv6 Dual-stack Routers http://www.cisco.com/warp/public/707/cisco-sa-20080326-IPv4IPv6.shtml * Vulnerability in Cisco IOS with OSPF, MPLS VPN, and Supervisor 32, Supervisor 720, or Route Switch Processor 720 http://www.cisco.com/warp/public/707/cisco-sa-20080326-queue.shtml * Cisco IOS Multicast Virtual Private Network (MVPN) Data Leak http://www.cisco.com/warp/public/707/cisco-sa-20080326-mvpn.shtml Affected Products = Devices that are running certain Cisco IOS versions prior to 12.3 with VPDN enabled may be affected by these vulnerabilities. Vulnerable Products +-- Devices that are running affected versions of Cisco IOS with VPDN enabled and are configured to accept termination of PPTP sessions are vulnerable. To determine whether VPDN is enabled on your device, log in to the device and issue the command-line interface (CLI) command show running-config. If the output contains vpdn enable along with a vpdn-group name command, VPDN is enabled on the device. The device will accept termination of PPTP sessions if the command protocol any or protocol pptp is defined under the vpdn-group name command. The following example shows a device that is running VPDN and will accept termination of PPTP sessions: Router#show running-config Building configuration... ! !--- Output truncated. ! vpdn enable ! vpdn-group test_only ! Default PPTP VPDN group accept-dialin protocol pptp virtual-template 1 ! !---Remaining output truncated. To determine the software version running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS software will identify itself as Internetwork Operating System Software or simply IOS. On the next line of output, the image name will be displayed between parentheses, followed by Version and the IOS release name. Other Cisco devices will not have the show version command or will give different output. The following example identifies a Cisco product that is running Cisco IOS release 12.2(7): Cisco Internetwork Operating System Software IOS (tm) 7200 Software (C7200-IS-M), Version 12.2(7), RELEASE SOFTWARE (fc1) Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Tue 15-Jan-02 18:31 by pwade Image text-base: 0x600089C0, data-base: 0x613A6000 Additional information about Cisco IOS release naming can be found at http://www.cisco.com/warp/public/620/1.html. Products Confirmed Not Vulnerable + Devices that are running Cisco IOS versions 12.3
[c-nsp] QoS problems on ATM pvc - IOS bug?
This one is a real head scratcher for me. I've got two 7206s, both running c7200-p-mz.123-22.bin, both with identical PAs. One is in production, the other is a hot spare. I got frustrated enough with trying to get QoS set up that I pulled this config line for line from an example on CCO: class-map match-all VoIP-Control match ip precedence 3 class-map match-all Video match ip precedence 4 policy-map WAN class VoIP-Control bandwidth 64 class Video bandwidth 2000 class class-default fair-queue And I'm applying it here: !test box PVC - this one works fine interface ATM2/0.666 point-to-point description Irritated Customer, LLC ip address 192.168.209.253 255.255.255.252 pvc 5/54 protocol ip 192.168.209.254 broadcast encapsulation aal5snap service-policy output WAN !production box - will have nothing to do with a policy being placed on the PVC interface ATM2/0.98004 point-to-point description Irritated Customer, LLC ip address 192.168.209.253 255.255.255.252 pvc 5/54 protocol ip 192.168.209.254 broadcast encapsulation aal5snap !many attempts to get the service policy right here, ain't put on an appearance yet I've wrestled with this one quite a bit and even went so far as getting a maintenance window and rebooting the darned thing - someone else had been fooling with QoS stuff before they called me in and I was starting to think maybe they'd managed to aggravate some seldom touched bits of the MQC. The production machine has 32 subinterfaces which correspond to frame T1 endpoints on the far side. There are 600+ DSL PPPoA sessions terminating on this machine as well. The processor runs at a consistent 32%, there are only a few hundred routes via OSPF. The engine is an NPE400 with 512 meg. The machine has been in production for quite some time and is stable and trustworthy. There is no Smartnet on it. So ... anyone have any ideas here? -- mailto:[EMAIL PROTECTED] // GoogleTalk: [EMAIL PROTECTED] IM: nealrauhauser ___ 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 Router Considerations
Hi, On Wed, Mar 26, 2008 at 12:02:15PM -0400, Paul Stewart wrote: What I'm considering is removing the 12012 because of the space it consumes (does all BGP today) and replacing it with a pair of 7606's Sup720-3BXL etc For BGP edge that's feeding 3 full BGP transit feeds and a couple hundred peering sessions will the Sup720-3BXL cope ok from a memory perspective. The Sup720 is not very fast, regarding CPU wise (= BGP update handling) but it will handle 3 full feeds just fine. If you want a faster CPU, you might want to check the RSP720, but beware (see below). The traffic is not a lot (500Mb/s or so) on this network . Traffic-wise, the Sup720 *is* fast :-) Thanks for any feedback.. We have lots of 6500's but everyone keeps telling me lately to go 7600 series instead?? Basically it's the same thing. And with IOS 12.2SX*, there was no difference, except chassis colour. Then came the 7600 business unit (BU) inside Cisco and decided we're going to sell Real Routers, can't have this switch chassis crap around! and forked a software train (12.2SRA/SRB/SRC) that nowadays doesn't run on chassis that are labeled 6500 anymore. Just because they do an EEPROM check. Otherwise there is still no difference. There is some new hardware - the RSP720, the ES20 line cards, and the 7600-S chassis - that are *only* supported by SR* software. OTOH, there are LAN style line cards, notably the 6708 8x10GE card, that only just recently have been supported in SRC, and as far as I have heard, SRC is not very mature yet. Politely said. OTOH, there is the 6500 business unit, that targets enterprises - their IOS fork is 12.2SXH these days. They build nice things that ISPs might want to have as well, like modular IOS with restartable processes in case BGP leaks memory (and, in theory, upgrades-without-reboot, and such), the Sup720-10G supervisor engine, and thus. Until recently, buying a 7600+Sup720 and running SXF/SXH was what we considered future proof - you have a chassis that supports all the software that's out there, and are saved from the internal politics bullshit. Unfortunately, that's not completely true anymore - the 7600-S chassis are NOT supported by SXH IOS, and as far as we have been told, there are no plans to do so. So - what's the summary? Cisco internal politics is hurting customers. Whatever you decide upon, you'll be f***ed in a year or so. Get a Juniper M7i. For your traffic needs, it's definitely fast enough - and the CPU to handle the BGP updates is much faster. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] pgpYtMTp0eJcK.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP Router Considerations
Thanks Gert... appreciate your open approach to this ;) I'm hoping to sell some ideas internally on a 5 year plan long time to justify anything it seems anymore... Is there a GSR/switch combo I could use intead? We've had GSR's and they are rock solid, turn them on and forget them boxes ... at least for us if we went GSR route, perhaps I could look at 4500 series switches or similar then Cost is always a consideration but I'm trying to combine scalability, redundancy, and future-proof all in one... I know it's like a dream but if I can be reasonably close than all the better Paul -Original Message- From: Gert Doering [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2008 1:13 PM To: Paul Stewart Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] BGP Router Considerations Hi, On Wed, Mar 26, 2008 at 12:02:15PM -0400, Paul Stewart wrote: What I'm considering is removing the 12012 because of the space it consumes (does all BGP today) and replacing it with a pair of 7606's Sup720-3BXL etc For BGP edge that's feeding 3 full BGP transit feeds and a couple hundred peering sessions will the Sup720-3BXL cope ok from a memory perspective. The Sup720 is not very fast, regarding CPU wise (= BGP update handling) but it will handle 3 full feeds just fine. If you want a faster CPU, you might want to check the RSP720, but beware (see below). The traffic is not a lot (500Mb/s or so) on this network . Traffic-wise, the Sup720 *is* fast :-) Thanks for any feedback.. We have lots of 6500's but everyone keeps telling me lately to go 7600 series instead?? Basically it's the same thing. And with IOS 12.2SX*, there was no difference, except chassis colour. Then came the 7600 business unit (BU) inside Cisco and decided we're going to sell Real Routers, can't have this switch chassis crap around! and forked a software train (12.2SRA/SRB/SRC) that nowadays doesn't run on chassis that are labeled 6500 anymore. Just because they do an EEPROM check. Otherwise there is still no difference. There is some new hardware - the RSP720, the ES20 line cards, and the 7600-S chassis - that are *only* supported by SR* software. OTOH, there are LAN style line cards, notably the 6708 8x10GE card, that only just recently have been supported in SRC, and as far as I have heard, SRC is not very mature yet. Politely said. OTOH, there is the 6500 business unit, that targets enterprises - their IOS fork is 12.2SXH these days. They build nice things that ISPs might want to have as well, like modular IOS with restartable processes in case BGP leaks memory (and, in theory, upgrades-without-reboot, and such), the Sup720-10G supervisor engine, and thus. Until recently, buying a 7600+Sup720 and running SXF/SXH was what we considered future proof - you have a chassis that supports all the software that's out there, and are saved from the internal politics bullshit. Unfortunately, that's not completely true anymore - the 7600-S chassis are NOT supported by SXH IOS, and as far as we have been told, there are no plans to do so. So - what's the summary? Cisco internal politics is hurting customers. Whatever you decide upon, you'll be f***ed in a year or so. Get a Juniper M7i. For your traffic needs, it's definitely fast enough - and the CPU to handle the BGP updates is much faster. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025 [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/
Re: [c-nsp] BGP Router Considerations
Or you may want to look into the new ASR routers. They are supposed to be positioned between the 7200's and the 7600's, but it doesn't sound like you are really pushing that much traffic through the system. If you need it now it's probably not an option, but if you are looking to what would be ideal in the near future this may be the answer. Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gert Doering Sent: Wednesday, March 26, 2008 1:13 PM To: Paul Stewart Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] BGP Router Considerations Hi, On Wed, Mar 26, 2008 at 12:02:15PM -0400, Paul Stewart wrote: What I'm considering is removing the 12012 because of the space it consumes (does all BGP today) and replacing it with a pair of 7606's Sup720-3BXL etc For BGP edge that's feeding 3 full BGP transit feeds and a couple hundred peering sessions will the Sup720-3BXL cope ok from a memory perspective. The Sup720 is not very fast, regarding CPU wise (= BGP update handling) but it will handle 3 full feeds just fine. If you want a faster CPU, you might want to check the RSP720, but beware (see below). The traffic is not a lot (500Mb/s or so) on this network . Traffic-wise, the Sup720 *is* fast :-) Thanks for any feedback.. We have lots of 6500's but everyone keeps telling me lately to go 7600 series instead?? Basically it's the same thing. And with IOS 12.2SX*, there was no difference, except chassis colour. Then came the 7600 business unit (BU) inside Cisco and decided we're going to sell Real Routers, can't have this switch chassis crap around! and forked a software train (12.2SRA/SRB/SRC) that nowadays doesn't run on chassis that are labeled 6500 anymore. Just because they do an EEPROM check. Otherwise there is still no difference. There is some new hardware - the RSP720, the ES20 line cards, and the 7600-S chassis - that are *only* supported by SR* software. OTOH, there are LAN style line cards, notably the 6708 8x10GE card, that only just recently have been supported in SRC, and as far as I have heard, SRC is not very mature yet. Politely said. OTOH, there is the 6500 business unit, that targets enterprises - their IOS fork is 12.2SXH these days. They build nice things that ISPs might want to have as well, like modular IOS with restartable processes in case BGP leaks memory (and, in theory, upgrades-without-reboot, and such), the Sup720-10G supervisor engine, and thus. Until recently, buying a 7600+Sup720 and running SXF/SXH was what we considered future proof - you have a chassis that supports all the software that's out there, and are saved from the internal politics bullshit. Unfortunately, that's not completely true anymore - the 7600-S chassis are NOT supported by SXH IOS, and as far as we have been told, there are no plans to do so. So - what's the summary? Cisco internal politics is hurting customers. Whatever you decide upon, you'll be f***ed in a year or so. Get a Juniper M7i. For your traffic needs, it's definitely fast enough - and the CPU to handle the BGP updates is much faster. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025 [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] BGP - hiding AS
I have the following topology Router 1(AS65501) - Router 2 (AS123) - Router 3 (AS456) - Router4 (AS65504) Router 1 is my site (private AS) R2 is network provider (public AS - I cant change config) R3 is my other site (public AS) R4 is end customer (private AS) Router 1 advertises network 10.1.1.1 to R2, then R2 to R3, R3 to R4. Problem is that I need to suppres / hide / remove the private AS of R1 by the time it gets to R4. This is because R4 can see the same private AS in use elsewhere on its own network. I would use the *neighbor x.x.x.x remove-private-as ***command but understand that this doesn't work if you have public and private AS numbers in the path. What is best practice? Thanks in advance Gary ** ___ 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] QoS problems on ATM pvc - IOS bug?
Check the TX Ring limit. The TX Ring is the number of particles/packets that queue in the hardware queue before being transmitted out of the interface. If this is set too big you can experience problems with packets seeming to be placed and process through the Priority queue, when in fact they are now sat in a hardware queue. Under the interface; interface ATM0 pvc 0/38 tx-ring-limit 3 Hope it helps - or at least rules out that this isn't the problem. Gary On Wed, Mar 26, 2008 at 4:34 PM, neal rauhauser [EMAIL PROTECTED] wrote: This one is a real head scratcher for me. I've got two 7206s, both running c7200-p-mz.123-22.bin, both with identical PAs. One is in production, the other is a hot spare. I got frustrated enough with trying to get QoS set up that I pulled this config line for line from an example on CCO: class-map match-all VoIP-Control match ip precedence 3 class-map match-all Video match ip precedence 4 policy-map WAN class VoIP-Control bandwidth 64 class Video bandwidth 2000 class class-default fair-queue And I'm applying it here: !test box PVC - this one works fine interface ATM2/0.666 point-to-point description Irritated Customer, LLC ip address 192.168.209.253 255.255.255.252 pvc 5/54 protocol ip 192.168.209.254 broadcast encapsulation aal5snap service-policy output WAN !production box - will have nothing to do with a policy being placed on the PVC interface ATM2/0.98004 point-to-point description Irritated Customer, LLC ip address 192.168.209.253 255.255.255.252 pvc 5/54 protocol ip 192.168.209.254 broadcast encapsulation aal5snap !many attempts to get the service policy right here, ain't put on an appearance yet I've wrestled with this one quite a bit and even went so far as getting a maintenance window and rebooting the darned thing - someone else had been fooling with QoS stuff before they called me in and I was starting to think maybe they'd managed to aggravate some seldom touched bits of the MQC. The production machine has 32 subinterfaces which correspond to frame T1 endpoints on the far side. There are 600+ DSL PPPoA sessions terminating on this machine as well. The processor runs at a consistent 32%, there are only a few hundred routes via OSPF. The engine is an NPE400 with 512 meg. The machine has been in production for quite some time and is stable and trustworthy. There is no Smartnet on it. So ... anyone have any ideas here? -- mailto:[EMAIL PROTECTED] // GoogleTalk: [EMAIL PROTECTED] IM: nealrauhauser ___ 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] QoS problems on ATM pvc - IOS bug?
On Wed, March 26, 2008 4:34 pm, neal rauhauser wrote: !production box - will have nothing to do with a policy being placed on the PVC interface ATM2/0.98004 point-to-point description Irritated Customer, LLC ip address 192.168.209.253 255.255.255.252 pvc 5/54 protocol ip 192.168.209.254 broadcast encapsulation aal5snap !many attempts to get the service policy right here, ain't put on an appearance yet Is there anything in the log? In my experience, when QoS config fails to take, there's often an explanation written to the log, but *not* to the console / VTY, regardless of your logging or 'term mon' settings. This makes it looks like the command is failing silently, when in reality it's complaining about something where you can't see it :( Regards, Tim. I've wrestled with this one quite a bit and even went so far as getting a maintenance window and rebooting the darned thing - someone else had been fooling with QoS stuff before they called me in and I was starting to think maybe they'd managed to aggravate some seldom touched bits of the MQC. The production machine has 32 subinterfaces which correspond to frame T1 endpoints on the far side. There are 600+ DSL PPPoA sessions terminating on this machine as well. The processor runs at a consistent 32%, there are only a few hundred routes via OSPF. The engine is an NPE400 with 512 meg. The machine has been in production for quite some time and is stable and trustworthy. There is no Smartnet on it. So ... anyone have any ideas here? -- mailto:[EMAIL PROTECTED] // GoogleTalk: [EMAIL PROTECTED] IM: nealrauhauser ___ 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] SNMP MIB update interval on CISCO?
Thanks for the information. Do the routers maintain a timestamp of when they last updated their MIB. The time difference between the updates will give me a good indication of the average traffic being observed by the router. Thanks, -Proveen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mack Sent: Tuesday, March 25, 2008 5:42 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] SNMP MIB update interval on CISCO? On the 6500/7600 platform you can set: service counters max age 5 Obviously this is platform specific. On high CPU load SNMP counters may be updated at a longer interval. At extreme levels SNMP may stop updating completely until the load goes down. Most platforms have a best-effort interval of 10 seconds. As for the accuracy: % Accuracy~=update interval*100/sample interval So with a 60 second sample interval and a ten second update interval you can have a variance of ~17%. With a 5 minute sample interval the variance is ~3%. The accuracy is an approximation as the update interval is best-effort. To sum it up you can sample slower and get more accurate readings or faster and get less accurate readings. -- LR Mack McBride Network Administrator Alpha Red, Inc. Message: 9 Date: Tue, 25 Mar 2008 20:02:23 - From: Dean Smith [EMAIL PROTECTED] Subject: Re: [c-nsp] SNMP MIB update interval on CISCO? To: cisco-nsp@puck.nether.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Basically - No. Counters like those are really only valid for polling every minute at a minimum and even then you can occasionally see strange affects due to the internal updates happening out of sync. If you essentially need granularity of a second or so sampling you probably need an external tool. Dean -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gurung, Provin Sent: 25 March 2008 17:02 To: cisco-nsp@puck.nether.net Subject: [c-nsp] SNMP MIB update interval on CISCO? I have a question about how to get the cisco routers updates rate of one of the snmp mib entries. Background: I am using a cisco 3640 series router running ios 12.4. I am cyclically doing snmpwalks to get the number of bytes transmitted on an output interface for a particular Diff serv code point. The actually snmpwalk call is for cbQosMatchPrePolicyByte (enterprises.9.9.166.1.16.1.1.5) in the CISCO-CLASS-BASED-QOS-MIB mib. My problem. I would like to compute the number of bytes sent per second as quickly and accurately as possible. However I found that the above mib entry can be updated anywhere from 6 to 10 seconds. Sometimes if I poll this snmp entry every 8 seconds the entry hasn't had a chance to change yet and my message rate incorrectly is 0 kbs. My question: 1) Is there somewhere in the mib or cisco's command line interface where I can get the cyclic rate that is being used? Or the timestamp when the MIB entries are being updated? 2) Is it possible to set this rate via snmp or the cisco command line interface and make the router update at a fixed interval of my choosing? 3) Alternatively, Is there a way to generate SNMP traps when router updates its traffic statistics for some DSCP value? Thanks for any inputs, -Proveen ___ 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] Multicast Subsecond Convergence
Hi, Investigating scalability of this feature (and potential issues). Any real field example? http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fs_subcv.html Tks, Alaerte ___ 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] WS-SVC-NAM-1 Modules
Hi folks. I have a chance to pickup some WS-SVC-NAM-1 modules at a *very* good price - have looked at them before and think they'll meet some of our needs.. Anyways, the WS-SVC-NAM-2 is later, greater etc. but according to Cisco's website the WS-SVC-NAM-1 is still current product but just with less horsepower than the 2 version. Anybody using them - can you share your thoughts on them? Thanks, Paul ___ 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 Router Considerations
Be very mindful of features here. The feature list for all but certain large carriers is pretty slim pickens. From: Fred Reimer [EMAIL PROTECTED] Date: Wed, 26 Mar 2008 13:22:37 -0400 To: Gert Doering [EMAIL PROTECTED], Paul Stewart [EMAIL PROTECTED] Cc: cisco-nsp@puck.nether.net Conversation: [c-nsp] BGP Router Considerations Subject: Re: [c-nsp] BGP Router Considerations Or you may want to look into the new ASR routers. They are supposed to be positioned between the 7200's and the 7600's, but it doesn't sound like you are really pushing that much traffic through the system. If you need it now it's probably not an option, but if you are looking to what would be ideal in the near future this may be the answer. Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gert Doering Sent: Wednesday, March 26, 2008 1:13 PM To: Paul Stewart Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] BGP Router Considerations Hi, On Wed, Mar 26, 2008 at 12:02:15PM -0400, Paul Stewart wrote: What I'm considering is removing the 12012 because of the space it consumes (does all BGP today) and replacing it with a pair of 7606's Sup720-3BXL etc For BGP edge that's feeding 3 full BGP transit feeds and a couple hundred peering sessions will the Sup720-3BXL cope ok from a memory perspective. The Sup720 is not very fast, regarding CPU wise (= BGP update handling) but it will handle 3 full feeds just fine. If you want a faster CPU, you might want to check the RSP720, but beware (see below). The traffic is not a lot (500Mb/s or so) on this network . Traffic-wise, the Sup720 *is* fast :-) Thanks for any feedback.. We have lots of 6500's but everyone keeps telling me lately to go 7600 series instead?? Basically it's the same thing. And with IOS 12.2SX*, there was no difference, except chassis colour. Then came the 7600 business unit (BU) inside Cisco and decided we're going to sell Real Routers, can't have this switch chassis crap around! and forked a software train (12.2SRA/SRB/SRC) that nowadays doesn't run on chassis that are labeled 6500 anymore. Just because they do an EEPROM check. Otherwise there is still no difference. There is some new hardware - the RSP720, the ES20 line cards, and the 7600-S chassis - that are *only* supported by SR* software. OTOH, there are LAN style line cards, notably the 6708 8x10GE card, that only just recently have been supported in SRC, and as far as I have heard, SRC is not very mature yet. Politely said. OTOH, there is the 6500 business unit, that targets enterprises - their IOS fork is 12.2SXH these days. They build nice things that ISPs might want to have as well, like modular IOS with restartable processes in case BGP leaks memory (and, in theory, upgrades-without-reboot, and such), the Sup720-10G supervisor engine, and thus. Until recently, buying a 7600+Sup720 and running SXF/SXH was what we considered future proof - you have a chassis that supports all the software that's out there, and are saved from the internal politics bullshit. Unfortunately, that's not completely true anymore - the 7600-S chassis are NOT supported by SXH IOS, and as far as we have been told, there are no plans to do so. So - what's the summary? Cisco internal politics is hurting customers. Whatever you decide upon, you'll be f***ed in a year or so. Get a Juniper M7i. For your traffic needs, it's definitely fast enough - and the CPU to handle the BGP updates is much faster. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025 [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/ This email and any attachments (Message) may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege. ___ 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 - hiding AS
Router 1(AS65501) - Router 2 (AS123) - Router 3 (AS456) - Router4 (AS65504) I would use the *neighbor x.x.x.x remove-private-as ***command but understand that this doesn't work if you have public and private AS numbers in the path. I think it would work ok, but this command shoudl be used on R2 advertising routes to R3, shouldn't it? you might consider using multihop bgp R1-R4? Best Regards, -- -mat ___ 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 transit, selecting providers based on source IP
Hello All: -Original Message- From: [EMAIL PROTECTED] [mailto:cisco-nsp- [EMAIL PROTECTED] On Behalf Of Bruce Pinsky Sent: Tuesday, March 25, 2008 3:54 PM To: Wayne Lee Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] bgp transit, selecting providers based on source IP * PGP Signed by an unverified key: 03/25/08 at 15:54:12 Wayne Lee wrote: Hi List We currently have 3 transit providers. all works as expected. We recently have connected a customer who requires BGP transit from us but with a twist. The customer for whatever reason do not want their traffic going via our preferred provider, is there any way I can force the customers outbound traffic to go via my other 2 providers instead? I have created the prefix-lists to stop announcing the customers routes via the main provider so no traffic should return by them. The customer is multi-homed with another transit provider. You could either use Policy Based Routing to forward based on their source address range or you could use VRF-Lite to create a separate routing table instance that only includes the routes to 2 out of the 3 providers. Which is best would require a bit more info about your environment. The answer to this may be no way. :-) If you have a peering session with the customer, why not only announce your routes from your two other providers so that the customer doesn't see the routes from the one they want to avoid? Wouldn't that accomplish the same thing? You could tag your transit routes with a community, add the two you want to transit to a community-list and then announce only the routes that match the list. Thinking out loud, but not necessarily well. :-) Mike PGP.sig Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] bgp transit, selecting providers based on source IP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael K. Smith - Adhost wrote: ...snip...snip... The answer to this may be no way. :-) If you have a peering session with the customer, why not only announce your routes from your two other providers so that the customer doesn't see the routes from the one they want to avoid? Wouldn't that accomplish the same thing? You could tag your transit routes with a community, add the two you want to transit to a community-list and then announce only the routes that match the list. Thinking out loud, but not necessarily well. :-) And when the packets reach his routers that have all 3 provider exit points available, how is he going to prevent those packets from choosing the undesired exit point? It's not a question of what he advertises to his customer, but rather how the forwarding decision is modified for just this customer. - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6rJdE1XcgMgrtyYRAqiUAJ9WrZEqdo3wvfHIECABL/1lumg4gACgvb2F 0ohoY6gFi5RWdjyEv86KT7Y= =2oTl -END PGP SIGNATURE- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] UBRL on 6500 running 12.2SXH on 720-CXL
We just upgraded our sup from 720-3B to 720-CXL on 6500 running 12.2-33SXH1 We were using User Based Rate Limiting UBRL and all was working. QOS is enabled. I have a class map to match just the source address of hosts on a subnet that have a dst to any. The policy-map matches the class and uses the src-only flow mask to rate limit each host to 2M I apply the service-policy input (policy-map ) to a layer 2 interface gi3/2 By default QOS policing is port based. I first look at the access-list to see if it is getting any hits and it is not. So at this point no packets are being sent to the policer. I check the policy-map for the interface and it looks fine. When I change the policing to VLAN-BASED and move the SERVICE-POLICY to the VLAN, I can now see hits on access list but doing some speed tests from one of the hosts, it does not seem to limit traffic. Q. Does anybody have any ideas on this before I submit it to TAC? Its been a long day so maybe I missed something. Thanks for any help. Jeff Fitzwater OIT Network Systems Princeton University ___ 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 transit, selecting providers based on source IP
...snip...snip... The answer to this may be no way. :-) If you have a peering session with the customer, why not only announce your routes from your two other providers so that the customer doesn't see the routes from the one they want to avoid? Wouldn't that accomplish the same thing? You could tag your transit routes with a community, add the two you want to transit to a community-list and then announce only the routes that match the list. Thinking out loud, but not necessarily well. :-) And when the packets reach his routers that have all 3 provider exit points available, how is he going to prevent those packets from choosing the undesired exit point? It's not a question of what he advertises to his customer, but rather how the forwarding decision is modified for just this customer. Got it! You can't adjust your upstream's FIB. So MPLS or PBR. Mike PGP.sig Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP Router Considerations
Absolutely, that's why I said if you need it now it is probably not an option. However, that will change with time. I expect the feature list to be mostly complete a year from now. If it is a question of long-term planning then the platform should be considered. Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 -Original Message- From: David Curran [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2008 4:03 PM To: Fred Reimer; Gert Doering; Paul Stewart Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] BGP Router Considerations Be very mindful of features here. The feature list for all but certain large carriers is pretty slim pickens. From: Fred Reimer [EMAIL PROTECTED] Date: Wed, 26 Mar 2008 13:22:37 -0400 To: Gert Doering [EMAIL PROTECTED], Paul Stewart [EMAIL PROTECTED] Cc: cisco-nsp@puck.nether.net Conversation: [c-nsp] BGP Router Considerations Subject: Re: [c-nsp] BGP Router Considerations Or you may want to look into the new ASR routers. They are supposed to be positioned between the 7200's and the 7600's, but it doesn't sound like you are really pushing that much traffic through the system. If you need it now it's probably not an option, but if you are looking to what would be ideal in the near future this may be the answer. Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gert Doering Sent: Wednesday, March 26, 2008 1:13 PM To: Paul Stewart Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] BGP Router Considerations Hi, On Wed, Mar 26, 2008 at 12:02:15PM -0400, Paul Stewart wrote: What I'm considering is removing the 12012 because of the space it consumes (does all BGP today) and replacing it with a pair of 7606's Sup720-3BXL etc For BGP edge that's feeding 3 full BGP transit feeds and a couple hundred peering sessions will the Sup720-3BXL cope ok from a memory perspective. The Sup720 is not very fast, regarding CPU wise (= BGP update handling) but it will handle 3 full feeds just fine. If you want a faster CPU, you might want to check the RSP720, but beware (see below). The traffic is not a lot (500Mb/s or so) on this network . Traffic-wise, the Sup720 *is* fast :-) Thanks for any feedback.. We have lots of 6500's but everyone keeps telling me lately to go 7600 series instead?? Basically it's the same thing. And with IOS 12.2SX*, there was no difference, except chassis colour. Then came the 7600 business unit (BU) inside Cisco and decided we're going to sell Real Routers, can't have this switch chassis crap around! and forked a software train (12.2SRA/SRB/SRC) that nowadays doesn't run on chassis that are labeled 6500 anymore. Just because they do an EEPROM check. Otherwise there is still no difference. There is some new hardware - the RSP720, the ES20 line cards, and the 7600-S chassis - that are *only* supported by SR* software. OTOH, there are LAN style line cards, notably the 6708 8x10GE card, that only just recently have been supported in SRC, and as far as I have heard, SRC is not very mature yet. Politely said. OTOH, there is the 6500 business unit, that targets enterprises - their IOS fork is 12.2SXH these days. They build nice things that ISPs might want to have as well, like modular IOS with restartable processes in case BGP leaks memory (and, in theory, upgrades-without-reboot, and such), the Sup720-10G supervisor engine, and thus. Until recently, buying a 7600+Sup720 and running SXF/SXH was what we considered future proof - you have a chassis that supports all the software that's out there, and are saved from the internal politics bullshit. Unfortunately, that's not completely true anymore - the 7600-S chassis are NOT supported by SXH IOS, and as far as we have been told, there are no plans to do so. So - what's the summary? Cisco internal politics is hurting customers. Whatever you decide upon, you'll be f***ed in a year or so. Get a Juniper M7i. For your traffic needs, it's definitely fast enough - and the CPU to handle the BGP updates is much faster. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025 [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/ This email and any attachments (Message) may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and
[c-nsp] 7600 / SUP720-3BXL - mixing fabric and non-fabric enabled line cards
Dear All, I am having to mix fabric and non-fabric enabled line cards on a single chassis. These are my line cards: WS-X6704-10GE WS-X6408A-GBIC WS-X6148-GE-TX What's the theoretical maximum expected throughput in running with mix fabric line cards ? Also, what will be the optimal and the recommended switching mode to run (truncated vs.. bus-mode) ? Any inputs will be greatly appreciated. Regards, ZH ___ 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] System MTU on trunks for Q in Q
I've been bashing my head against the wall all day for a definitive answer on this: On a Cisco switch that supports QinQ (3550, 3750, ME3400, 3560 etc) What is the _minimum_ value I need to set the system MTU to, to do QinQ? 1504? 1522? 1526? 1546? I can't seem to find one concise answer... Thanks!! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] QoS problems on ATM pvc - IOS bug?
Before applying the policy under your pvc specify the bandwidth in your ATM subint and make sure it's within the reserved range, otherwise use max-reserved-bandwidth x to accommodate it, I feel your pain as i've experienced the whole apply the policy it takes it then when you go to view it it's gone thing on the 7200's with ATM subint's, I found the give and take for me was due to it trying to reserve more than the default amount of bandwidth (75%), it just wouldn't error when applying the policy. Also doesn't like LLQ using the percent command (slightly annoying but dealt with it via multiple policies) Ben On 27/03/2008, at 3:04 AM, neal rauhauser wrote: This one is a real head scratcher for me. I've got two 7206s, both running c7200-p-mz.123-22.bin, both with identical PAs. One is in production, the other is a hot spare. I got frustrated enough with trying to get QoS set up that I pulled this config line for line from an example on CCO: class-map match-all VoIP-Control match ip precedence 3 class-map match-all Video match ip precedence 4 policy-map WAN class VoIP-Control bandwidth 64 class Video bandwidth 2000 class class-default fair-queue And I'm applying it here: !test box PVC - this one works fine interface ATM2/0.666 point-to-point description Irritated Customer, LLC ip address 192.168.209.253 255.255.255.252 pvc 5/54 protocol ip 192.168.209.254 broadcast encapsulation aal5snap service-policy output WAN !production box - will have nothing to do with a policy being placed on the PVC interface ATM2/0.98004 point-to-point description Irritated Customer, LLC ip address 192.168.209.253 255.255.255.252 pvc 5/54 protocol ip 192.168.209.254 broadcast encapsulation aal5snap !many attempts to get the service policy right here, ain't put on an appearance yet I've wrestled with this one quite a bit and even went so far as getting a maintenance window and rebooting the darned thing - someone else had been fooling with QoS stuff before they called me in and I was starting to think maybe they'd managed to aggravate some seldom touched bits of the MQC. The production machine has 32 subinterfaces which correspond to frame T1 endpoints on the far side. There are 600+ DSL PPPoA sessions terminating on this machine as well. The processor runs at a consistent 32%, there are only a few hundred routes via OSPF. The engine is an NPE400 with 512 meg. The machine has been in production for quite some time and is stable and trustworthy. There is no Smartnet on it. So ... anyone have any ideas here? -- mailto:[EMAIL PROTECTED] // GoogleTalk: [EMAIL PROTECTED] IM: nealrauhauser ___ 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] System MTU on trunks for Q in Q
I tend to run into this table often and has been a good reference for me. This table relates specifically to system MTU: http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note 09186a00801350c8.shtml#topic2 This would suggest 'system mtu 1504' would be appropriate. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Armstrong Sent: Wednesday, March 26, 2008 16:02 To: cisco-nsp@puck.nether.net Subject: [c-nsp] System MTU on trunks for Q in Q I've been bashing my head against the wall all day for a definitive answer on this: On a Cisco switch that supports QinQ (3550, 3750, ME3400, 3560 etc) What is the _minimum_ value I need to set the system MTU to, to do QinQ? 1504? 1522? 1526? 1546? I can't seem to find one concise answer... 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/
Re: [c-nsp] System MTU on trunks for Q in Q
1504 is the system mtu you want, however i'd find a higher common value between your switches incase you choose to run mpls down the track, or anything else that is going to add to your frame size. Ben On 27/03/2008, at 9:31 AM, Dan Armstrong wrote: I've been bashing my head against the wall all day for a definitive answer on this: On a Cisco switch that supports QinQ (3550, 3750, ME3400, 3560 etc) What is the _minimum_ value I need to set the system MTU to, to do QinQ? 1504? 1522? 1526? 1546? I can't seem to find one concise answer... 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/
Re: [c-nsp] System MTU on trunks for Q in Q
Since 1500 is the default and 1504 is by default supported on 802.1q trunk links, i guess 1504 should be the correct value for 802.1q tunneling. I guess the ethernet header is not counted by default. My proposition? Use something that covers all of them (i.e. 1600 for GE, 1546 for FE) and (as long as you don't change the routing MTU if you also use the switch as a L3 device ) you'll be fine... for many years. I still haven't found any reason for keeping a low MTU on L2 switches (although i don't know if any L2 protocols can generate such large frames which could possibly get dropped in a 1500 link). -- Tassos Dan Armstrong wrote on 27/3/2008 1:01 πμ: I've been bashing my head against the wall all day for a definitive answer on this: On a Cisco switch that supports QinQ (3550, 3750, ME3400, 3560 etc) What is the _minimum_ value I need to set the system MTU to, to do QinQ? 1504? 1522? 1526? 1546? I can't seem to find one concise answer... 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/
Re: [c-nsp] System MTU on trunks for Q in Q
The reason I don't want to raise it too high - is if we're selling TLS services to a customer, (ie a VLAN provisioned on 2 ports on different switches, carried across our core/trunks) - I don't want them being able to send any packet larger than 1500 byes. A bit bigger wouldn't be a problem, but if I set it to, say 9000, and all of a sudden we have some jackass with a storage head that could be firing 9000 byte packet across our backbone... not cool, I believe it would cause havoc with small packet applications like VoIP, even with QoS, the bit-time to send a 9000 byte packet out an interface is significant. I've also never been too clear on the interaction between the system mtu command, and the system mtu jumbo command. I've always just made them match... Peter Rathlev wrote: On Wed, 2008-03-26 at 19:01 -0400, Dan Armstrong wrote: I've been bashing my head against the wall all day for a definitive answer on this: On a Cisco switch that supports QinQ (3550, 3750, ME3400, 3560 etc) What is the _minimum_ value I need to set the system MTU to, to do QinQ? 1504? 1522? 1526? 1546? I can't seem to find one concise answer... I'm not entirely sure what the system mtu specifies, i.e. if it's interface MTUs (typically excluding data link headers) or what. IPv4 packet = 1500 bytes. Ethernet header = 14 bytes. 802.1q header = 4 bytes. Another one = 4 bytes more. So for simple QinQ of regular IPv4 traffic it would be max 1522 bytes of data per packets. Any special reason not to just raise it to the maximum of 2000 bytes? Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Prepare for router Wednesday
I've decided I do not like Router Wednesday 1 or 2 advisories in a day and you will probably read them thoroughly, like you should. 5 or more of them more or less altogether and I think a lot of people will only start binning them, as we don't have the time to dedicate to reading 5 fairly long e-mails all in 1 go. What do you guys think? On Tue, Mar 18, 2008 at 6:40 AM, Gert Doering [EMAIL PROTECTED] wrote: Hi, On Mon, Mar 17, 2008 at 08:04:17PM +0100, Florian Weimer wrote: This is one precondition for creating a market for intelligence derived by comparing subsequent IOS versions. Certainly an interesting development. Nothing new here. IOS release notes tend to be very vague regarding bugs at certain times. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025 [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/ ___ 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] System MTU on trunks for Q in Q
Your better off just running system mtu 1504(if you want to deliver QinQ to customers) and then specifying the larger mtu frames on your trunk interfaces, this still restricts your customer access ports to 1504 while allowing you to run what you need, jumbo frame mtu on an interface will override the system baby jumbo mtu command. On 27/03/2008, at 12:12 PM, Dan Armstrong wrote: The reason I don't want to raise it too high - is if we're selling TLS services to a customer, (ie a VLAN provisioned on 2 ports on different switches, carried across our core/trunks) - I don't want them being able to send any packet larger than 1500 byes. A bit bigger wouldn't be a problem, but if I set it to, say 9000, and all of a sudden we have some jackass with a storage head that could be firing 9000 byte packet across our backbone... not cool, I believe it would cause havoc with small packet applications like VoIP, even with QoS, the bit-time to send a 9000 byte packet out an interface is significant. I've also never been too clear on the interaction between the system mtu command, and the system mtu jumbo command. I've always just made them match... Peter Rathlev wrote: On Wed, 2008-03-26 at 19:01 -0400, Dan Armstrong wrote: I've been bashing my head against the wall all day for a definitive answer on this: On a Cisco switch that supports QinQ (3550, 3750, ME3400, 3560 etc) What is the _minimum_ value I need to set the system MTU to, to do QinQ? 1504? 1522? 1526? 1546? I can't seem to find one concise answer... I'm not entirely sure what the system mtu specifies, i.e. if it's interface MTUs (typically excluding data link headers) or what. IPv4 packet = 1500 bytes. Ethernet header = 14 bytes. 802.1q header = 4 bytes. Another one = 4 bytes more. So for simple QinQ of regular IPv4 traffic it would be max 1522 bytes of data per packets. Any special reason not to just raise it to the maximum of 2000 bytes? Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] System MTU on trunks for Q in Q
On Thursday 27 March 2008, Tassos Chatzithomaoglou wrote: I still haven't found any reason for keeping a low MTU on L2 switches (although i don't know if any L2 protocols can generate such large frames which could possibly get dropped in a 1500 link). We have gone with 9,000 bytes across the network (well, where it's supported depending on what kit is sitting on the LAN). This is how we found out the PA-GE only supports 4,470 bytes :-(. MTU nasties wreak havoc on OSPF adjacency formations - it only takes one router that doesn't support large MTU's on the segment to kill the whole jumbo-frame-support initiative. Mark. signature.asc Description: This is a digitally signed message part. ___ 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] Prepare for router Wednesday
On Thu, 27 Mar 2008, Whisper wrote: I've decided I do not like Router Wednesday 1 or 2 advisories in a day and you will probably read them thoroughly, like you should. 5 or more of them more or less altogether and I think a lot of people will only start binning them, as we don't have the time to dedicate to reading 5 fairly long e-mails all in 1 go. I didn't read all of them end to end, but it was nice that they included the URLs for all of the advisories individually. Personally, I'm glad that Cisco is forthcoming about issues like these. Sure anyone with a job title like Network Engineer is likely very busy with 15,000 other things, but these are things that are definitely important enough not to throw in the trash, sight unseen. Look over the Affected Products and Details sections. If this includes something that you're running, read the Impact, Software Versions and Fixes and Workarounds sections. If you're running code that is vulnerable, then you know what to do or how you can work around the problem and reading them this way should allow you to quickly understand the gist of the problem, if it affects you, and what to do if it does. For example one of the vulnerabilities was a DLSw issue. If you're not running DLSw anywhere, then there's not much need to continue reading that bulletin. jms ___ 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] Prepare for router Wednesday
Gary Wasn't this router Wednesday only a month or so worth of updates, if that? If so, imagine 6 months worth! I guess we get to find out what it is really like at the end of September 2008. On Thu, Mar 27, 2008 at 1:18 PM, Buhrmaster, Gary [EMAIL PROTECTED] wrote: For example one of the vulnerabilities was a DLSw issue. If you're not running DLSw anywhere, then there's not much need to continue reading that bulletin. From Microsoft Tuesday experience, that is not an entirely safe approach. You have to read far enough into the advisory so that you are sure you are not running some combination of features that end up enabling the vulnerability as a side effect. While Cisco has fewer side effects than some vendors, sometimes a default is not what one would expect, and just reading the title is not adequate (oh, you mean I get proxy-arp by default?) Carefully reading a handful of emails every six months (and others as necessary for active exploits) does not feel like a large burden to me. But I may be unique. Gary ___ 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] specifying next-hop via interface while still getting cef switched
I seem to recall there was a command that allowed a router to still cef switch packets when the next hop was an interface rather than an ip address, ie an ADSL client dialer interface with ip route 0.0.0.0 0.0.0.0 d0 Am I dreaming or was there a command which still allowed this to be cef switched as by default that is unsupported via cef, platform is 877 advip. Cheers Ben ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
