Re: [c-nsp] BFD in XR 3.9.1
On Wed, Aug 25, 2010 at 09:08:42AM +1200, Pshem Kowalczyk wrote: that surprising). We have encountered one limitation - currently BFD over ethtrunks is not supported (at least on 9k). We tested it with 20ms intervals (even though 15ms is the minimal value Cisco advised us to use 20ms). BFD is an IP based protocol, it's completely ignorant of L2 multipath and will almost always get hashed over a single link arbitrarily. This means that most failures will not be detected at all, and even if the packets do happen to get hashed on the physical member which goes down, it will bring down the entire port-channel. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ cisco-nsp 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] (no subject)
Hello @all, I hope I've just a problem I'm not getting rid of by simply not having found the according doc or command/option yet. IOS 12.2.(33)SRE1 running on 7200 and 7600 is creating a log entry each time a config session is closed: Aug 24 10:03:46.988 CEST: %SYS-6-EXIT_CONFIG: User has exited tty session 1(a.b.c.d) and I'd like to get rid of those messages without changing the log level (this one's filling up the log due to regular script connects). Does anybody know if there's some command switch to get this messages disabled? 12.2SB and 12.2SX didn't create that lines. thanks in advance, Marcus ___ cisco-nsp 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] 3750 stack
Hi, Interesting, Cisco told us it is generally a bad idea going much above five switch stacks. Something to do with the fact that at the rear of the switch you have a token ring-esque system and 40Gbps of backplane (off the top of my head). In the early code they only had a single token flying around the switches which caused horrible latency woes I would imagine, but things improved when they had multiple tokens rotating through the loop. StackWisePlus is a 32G full duplex bidirectional ring (when cables all installed properly this means you should still be better ff using it rather than having 2 stacks and trying to link the 2 together using eg expensive 10G ethernet X2's or port-channelled 1G's alan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] (no subject)
Hello, yesterday, a stack of three WS-C3750G-24TS-S IPBASE 12.2(50)SE3 reloaded after having erased its configuration... i tried to find the issue but i haven't found anything. I just have syslog messages as following: Notice 2010-08-2414:36:584606: 004527: Aug 24 14:36:57.301: %SYS-5-RELOAD: Reload requested by HRPC x_setup request handler. Reload reason: Reason unspecified Info 2010-08-2414:36:574605: 004526: Aug 24 14:36:56.295: %EXPRESS_SETUP-6-CONFIG_IS_RESET: The configuration is reset and the system will now reboot Do you have an idea of what happened? Thank you in advance. ___ cisco-nsp 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] 3750 stack
Hi, * Alan Buxey a.l.m.bu...@lboro.ac.uk [2010-08-25 08:55:00+0100]: Interesting, Cisco told us it is generally a bad idea going much above five switch stacks. Something to do with the fact that at the rear of the switch you have a token ring-esque system and 40Gbps of backplane (off the top of my head). In the early code they only had a single token flying around the switches which caused horrible latency woes I would imagine, but things improved when they had multiple tokens rotating through the loop. StackWisePlus is a 32G full duplex bidirectional ring (when cables all installed properly this means you should still be better ff using it rather than having 2 stacks and trying to link the 2 together using eg expensive 10G ethernet X2's or port-channelled 1G's I should have been clearer, we have 3750 stacks in our data closests as workstation edge termination kit. Pulling two numbers out of nowhere and slapping them together (plus our use of 'switchport protected' in our standard access port template) tells me 99% of the traffic is not workstation-workstation. So for us, I still am thinking two stacks is better than one :) Cheers -- Alexander Clouter .sigmonster says: Is death legally binding? ___ cisco-nsp 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] BFD in XR 3.9.1
On Wed, 2010-08-25 at 01:02 -0500, Richard A Steenbergen wrote: BFD is an IP based protocol, it's completely ignorant of L2 multipath and will almost always get hashed over a single link arbitrarily. Cisco may view it as only L3 relevant, but from RFC 5882 section 2: Its sole purpose is to verify connectivity between a pair of systems, for a particular data protocol across a path (which may be of any technology, length, or OSI layer). So theoretically BFD could be used for fast detection of loss of a L2 link. I would actually very much like to have something like BFD for L2. When constructing EoMPLS paths through the network failover (seen from between two CE devices) can be oh-so-slow, with RSTP (~6 sec) and UDLD (~5 sec) being the quickest to discover loss of connectivity. Or did I overlook something? -- 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] (no subject)
You can use the logging discriminator command.. Initially you create a discriminator and then you enable it on the syslog,buffer or console logging *logging discriminator YOURNAME msg-body drops YOURTEXT logging host x.x.x.x discriminator YOURNAME logging buffered discriminator YOURNAME* You can check this also.. http://www.cisco.com/en/US/docs/ios/netmgmt/command/reference/nm_09.html#wp1062700 ps. you better put a subject to your mails ;) George ___ cisco-nsp 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] Storm-Control on server switch uplinks.
Hi I just found out I can't set different levels for broadcast and multicast storm control I tried this on a C6503-E/Sup32/WS-X6516A running 12.2(33)SXI4a and a C6506-E/VS-S720-10G/WS-X6724-SFP running 12.2(33)SXI3 Looks like a bug. -Jens Thank you everyone. I will set the broadcast and multicast storm-control to 0.35 (35%) on the interinks between the distribution and access layer switches. At a later time, I will add the filters to all edge ports as well. Thank you for your help, Christina Today's Topics: 1. Re: Storm-Control on server switch uplinks. (Saku Ytti) 2. Re: Storm-Control on server switch uplinks. (Phil Mayers) 3. Re: Storm-Control on server switch uplinks. (Peter Rathlev) 4. 3750 stack (James Greig) 5. Re: Storm-Control on server switch uplinks. (Saku Ytti) 6. Re: Cogent IOS upgrade == BGP-3, update malformed (Tima Maryin) 7. Re: 3750 stack (Matt Bennett) 8. Re: Juniper M20 to Cisco 2600 Multilink Frame Relay FRF.16 issues (Keegan Holley) Jens S Andersen Email: j...@adm.aau.dk Aalborg University Telf: 9940 9464 Selma Lagerlöfs Vej 300, 4.2.59 Fax:9940 7593 9220 Aalborg Denmark ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3750 stack
Priority 15 is the important part. Cannot remember details, but first switch numbered 9 became a standard when merging two stacks long time ago. With all switches at default priority highest numbered switch will be master. To avoid having to do this with scheduled downtime this configuring master at switch9/priority15 just makes this even more safe Jon -Opprinnelig melding- Fra: Alan Buxey [mailto:a.l.m.bu...@lboro.ac.uk] Sendt: 24. august 2010 22:40 Til: Bøvre Jon Harald Kopi: cisco-nsp@puck.nether.net Emne: Re: [c-nsp] 3750 stack Hi, We have a number of 3750 stacks with anything from 2 to 8 switches. Our standard when configuring new stack: First switch numbered 9, second switch numbered 8 Switch # 9 given priority 15 (highest) Advantage? We are able to add new switches 7 -6- 5 - without any downtime and does add switches during daytime with no impact to customers I'm intrigued by the first switch being numbered 9 - why not just numbered 1 and go up incrementally? obviously 'priority 15' is important... just wondering what wierd little thing I missed... alan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Storm-Control on server switch uplinks.
On Wed, 2010-08-25 at 08:22 +0200, Jens S Andersen wrote: I just found out I can't set different levels for broadcast and multicast storm control Cisco hints at this in the documentation, e.g. for the storm-control broadcast level command: Enables broadcast traffic storm control on the interface, configures the traffic storm control level, and applies the traffic storm control level to all traffic storm control modes enabled on the interface. http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/storm.html#wp1021340 Looks like a bug. Rather than a bug they probably call it a hardware limitation. :-) -- 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] BFD in XR 3.9.1
On Wed, 25 Aug 2010, Peter Rathlev wrote: I would actually very much like to have something like BFD for L2. When constructing EoMPLS paths through the network failover (seen from between two CE devices) can be oh-so-slow, with RSTP (~6 sec) and UDLD (~5 sec) being the quickest to discover loss of connectivity. Or did I overlook something? BFD WG was initially chartered to develop BFD over 802.3 in close collaboration with IEEE. This has not materialized in BFD deliverables. I understand this is due to IEEE OAM (ah, ag) mechanisms improving and IEEE not being very interested in working on this. I've seen it mentioned recently in e.g. Juniper's some presentations, so maybe something non-standard is going on. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ cisco-nsp 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] Flash adapter RMON....
Hi All, This maybe a simple solution but I have a quick question about the compact flash adapter. I was reading the guide and getting ready to install it when I noticed that there was a small yellow label on the adapter that says Min. SP RMON: 8.4(2) Min. RP RMON: 12.2(17r)S4. When I execute show version | include ROM on the supervisor module it says my version is 12.2(17r)S2 (Note the S2 instead of S4). Do you think that matters? Thanks for the help! SP ___ cisco-nsp 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] Storm-Control on server switch uplinks.
On Wed, 25 Aug 2010, Peter Rathlev wrote: On Wed, 2010-08-25 at 08:22 +0200, Jens S Andersen wrote: I just found out I can't set different levels for broadcast and multicast storm control Cisco hints at this in the documentation, e.g. for the storm-control broadcast level command: Enables broadcast traffic storm control on the interface, configures the traffic storm control level, and applies the traffic storm control level to all traffic storm control modes enabled on the interface. Even clearer than that: Each port has a single traffic storm control level that is used for all types of traffic (broadcast, multicast, and unicast). Traffic storm control monitors the level of each traffic type for which you enable traffic storm control in 1-second traffic storm control intervals. So it seems there's one storm-control threshold per interface, and you decide which types of traffic (unicast/broadcast/multicast) have that threshold applied. It then gets a little murky: Traffic storm control on the Catalyst 6500 series switches is implemented in hardware. The traffic storm control circuitry monitors packets passing from a LAN interface to the switching bus. Using the Individual/Group bit in the packet destination address, the traffic storm control circuitry determines if the packet is unicast or broadcast, keeps track of the current count of packets within the 1-second interval, and when a threshold is reached, filters out subsequent packets. Because hardware traffic storm control uses a bandwidth-based method to measure traffic, the most significant implementation factor is setting the percentage of total available bandwidth that can be used by controlled traffic. Because packets do not arrive at uniform intervals, the 1-second interval during which controlled traffic activity is measured can affect the behavior of traffic storm control. Here, they first say storm control keeps track of the count of packets which implies to me number of packets or PPS, but then they say it's bandwidth based. I think I'd actually prefer if it were simply based on PPS or if configuring it as PPS was at least an option. We had a recent event in which a few VMs started sending an excessive rate of both broadcast and multicast. The traffic was arriving on 1gig interfaces on a pair of 6509s, and at a traffic rate of about 55mbit/s, we were seeing 78k PPS, and the 6509s were not amused. This got me looking at storm-control again. We'd experimented with it years ago, but never fully implemented it. One thing I'm curious about...if I have an interface with storm-control configured, and that interface is the source for a monitor session, during a traffic storm, will I see the dropped packets on the monitor session destination? -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Storm-Control on server switch uplinks.
On Wed, Aug 25, 2010 at 10:37 AM, Jon Lewis jle...@lewis.org wrote:
Even clearer than that:
Each port has a single traffic storm control level that is used for all
types of traffic (broadcast, multicast, and unicast).
Traffic storm control monitors the level of each traffic type for which you
enable traffic storm control in 1-second traffic storm control intervals.
So it seems there's one storm-control threshold per interface, and you
decide which types of traffic (unicast/broadcast/multicast) have that
threshold applied.
It then gets a little murky:
Traffic storm control on the Catalyst 6500 series switches is implemented
in hardware. The traffic storm control circuitry monitors packets passing
from a LAN interface to the switching bus. Using the Individual/Group bit in
the packet destination address, the traffic storm control circuitry
determines if the packet is unicast or broadcast, keeps track of the current
count of packets within the 1-second interval, and when a threshold is
reached, filters out subsequent packets.
Because hardware traffic storm control uses a bandwidth-based method to
measure traffic, the most significant implementation factor is setting the
percentage of total available bandwidth that can be used by controlled
traffic. Because packets do not arrive at uniform intervals, the 1-second
interval during which controlled traffic activity is measured can affect the
behavior of traffic storm control.
Here, they first say storm control keeps track of the count of packets
which implies to me number of packets or PPS, but then they say it's
bandwidth based. I think I'd actually prefer if it were simply based on PPS
or if configuring it as PPS was at least an option. We had a recent event
in which a few VMs started sending an excessive rate of both broadcast and
multicast. The traffic was arriving on 1gig interfaces on a pair of 6509s,
and at a traffic rate of about 55mbit/s, we were seeing 78k PPS, and the
6509s were not amused. This got me looking at storm-control again. We'd
experimented with it years ago, but never fully implemented it.
I'm glad it's not just me that thinks this way. Looking at other
vendors, most seem to imitate Cisco and do percentage based, which is
almost pointless. pps would make this a useful protection.
Interestingly NX-OS allows a decimal point:
storm-control {broadcast | multicast | unicast} level percentage[.fraction]
Wonder what the technical reason is for not allowing this to be
configured with pps as well.
--
Tim:
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Cisco Security Advisory: Cisco Unified Communications Manager Denial of Service Vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Cisco Unified Communications Manager Denial of Service Vulnerabilities Advisory ID: cisco-sa-20100825-cucm Revision 1.0 For Public Release 2010 August 25 1600 UTC (GMT) +- Summary === Cisco Unified Communications Manager contains two denial of service (DoS) vulnerabilities that affect the processing of Session Initiation Protocol (SIP) messages. Exploitation of these vulnerabilities could cause an interruption of voice services. Cisco has released free software updates that address these vulnerabilities. There are no workarounds for these vulnerabilities. This advisory is posted at: http://www.cisco.com/warp/public/707/cisco-sa-20100825-cucm.shtml Affected Products = Vulnerable Products +-- The following products are affected by vulnerabilities that are described in this advisory: * Cisco Unified Communications Manager 6.x * Cisco Unified Communications Manager 7.x * Cisco Unified Communications Manager 8.x Products Confirmed Not Vulnerable + Cisco Unified Communications Manager version 4.x is not affected by these vulnerabilities. No other Cisco products are currently known to be affected by these vulnerabilities. Details === Cisco Unified Communications Manager is the call processing component of the Cisco IP Telephony solution that extends enterprise telephony features and functions to packet telephony network devices, such as IP phones, media processing devices, VoIP gateways, and multimedia applications. Cisco Unified Communications Manager contains two DoS vulnerabilities that involve the processing of SIP messages. Each vulnerability is triggered by a malformed SIP message that could cause a critical process to fail, which could result in the disruption of voice services. All SIP ports (TCP ports 5060 and 5061, UDP ports 5060 and 5061) are affected. The first SIP DoS vulnerability is documented in Cisco bug ID CSCtd17310 and has been assigned the CVE identifier CVE-2010-2837. This vulnerability is fixed in Cisco Unified Communications Manager versions 6.1(5)SU1, 7.0(2a)SU3, 7.1(3b)SU2, 7.1(5) and 8.0(1). Cisco Unified Communications Manager version 4.x is not affected. The second SIP DoS vulnerability is documented in Cisco bug ID CSCtf66305 and has been assigned the CVE identifier CVE-2010-2838. The second vulnerability is fixed in Cisco Unified Communications Manager versions 7.0(2a)SU3, 7.1(5) and 8.0(3). Cisco Unified Communications Manager versions 4.x and 6.x are not affected. Vulnerability Scoring Details = Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss CSCtd17310 - potential core dump issue in SIPStationInit code CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact- None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCtf66305 - CCM Coredump From SendCombinedStatusInfo on Fuzzed REGISTER Message CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact- None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact == Successful exploitation of the vulnerabilities that are described in this advisory could result in the interruption of voice services. Cisco Unified Communications Manager will restart the affected processes, but repeated attacks may result in a sustained DoS Condition. Software Versions and Fixes === When considering software upgrades, also consult: http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution
[c-nsp] Cisco Security Advisory: Cisco Unified Presence Denial of Service Vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Cisco Unified Presence Denial of Service Vulnerabilities Advisory ID: cisco-sa-20100825-cup Revision 1.0 For Public Release 2010 August 25 1600 UTC (GMT) +- Summary === Cisco Unified Presence contains two denial of service (DoS) vulnerabilities that affect the processing of Session Initiation Protocol (SIP) messages. Exploitation of these vulnerabilities could cause an interruption of presence services. Cisco has released free software updates that address these vulnerabilities. There are no workarounds for these vulnerabilities. This advisory is posted at: http://www.cisco.com/warp/public/707/cisco-sa-20100825-cup.shtml Affected Products = Vulnerable Products +-- The following products are affected: * Cisco Unified Presence 6.0 versions prior to 6.0(7) * Cisco Unified Presence 7.0 versions prior to 7.0(8) Note: Cisco Unified Presence version 8.0(1) shipped with software fixes for all the vulnerabilities described in this advisory. Administrators of systems running Cisco Unified Presence can determine the software version by viewing the main page of the Cisco Unified Presence Administration interface. The software version can be determined by running the command show version active using the command line interface (CLI). Products Confirmed Not Vulnerable + No other Cisco products are currently known to be affected by these vulnerabilities. Details === Cisco Unified Presence contains two DoS vulnerabilities that involve the processing of SIP messages. Each vulnerability is triggered by a malformed SIP message that could cause a critical process to fail, which could result in the disruption of presence services. All SIP ports (TCP ports 5060 and 5061, UDP ports 5060 and 5061) are affected. The first SIP DoS vulnerability is documented in Cisco bug ID CSCtd14474 and has been assigned the CVE identifier CVE-2010-2839. This vulnerability is fixed in Cisco Unified Presence versions 6.0(7) and 7.0(8). The second SIP DoS vulnerability is documented in Cisco bug ID CSCtd39629 and has been assigned the CVE identifier CVE-2010-2840. This vulnerability is fixed in Cisco Unified Presence versions 6.0(7) and 7.0(8). Vulnerability Scoring Details = Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss CSCtd14474 - SIPD Coredumps due to Possible Stack Corruption During Fuzzing CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact- None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCtd39629 - PE Coredump On Subscribe Message with Contact Field Error CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact- None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact == Successful exploitation of any of the vulnerabilities may result in the interruption of presence services. Cisco Unified Presence will restart the affected processes, but repeated attacks may result in a sustained DoS condition. Software Versions and Fixes === When considering software upgrades, also consult: http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance
Re: [c-nsp] Storm-Control on server switch uplinks.
On Wed, 2010-08-25 at 11:30 -0400, Tim Durack wrote:
Interestingly NX-OS allows a decimal point:
storm-control {broadcast | multicast | unicast} level percentage[.fraction]
So does the 6500 actually. The fraction can be specified with two
decimal digits. :-)
(It'll be many years before I'll accept that NX-OS is an improvement
over IOS!)
--
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] 3750 stack
On Wed, Aug 25, 2010 at 12:55 AM, Alan Buxey a.l.m.bu...@lboro.ac.ukwrote: Hi, StackWisePlus is a 32G full duplex bidirectional ring (when cables all installed properly this means you should still be better ff using it rather than having 2 stacks and trying to link the 2 together using eg expensive 10G ethernet X2's or port-channelled 1G's alan Hi, One of potential problem to have only one single stack is the downtime during OS upgrade (and other maintenance). Two stack and backup each other via VRRP/HSRP could provide higher availability to clients (machines/customers) under them, provided those clients equips two up links to two different stacks. -- Michel~ ___ cisco-nsp 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] Storage Solution doubt
Hi, I've been asked to design a storage solution where I work (which is a ISP), I have been considering using one of the 2 equipments - Cisco MDS 9148 Multilayer Fabric Switch - Cisco MDS 9222i Multiservice Modular Switch Could anyone with experience/knowledge point out the difference between them? My ISP has a medium size structure and one of our main solutions is to offer web hosting to customers. Best regards, ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Juniper M20 to Cisco 2600 Multilink Frame Relay FRF.16 issues
Keegan Holley wrote: Well the cisco is getting LMI from the juniper. Do you see the lmi counters incrementing on the Juniper side? Nope. output_removed LMI type ANSI T391 LIV polling timer 10 T392 polling verification timer 15 N391 full status polling count 6 N392 error threshold3 N393 monitored event count 4 output_removed The above doesn't change ___ cisco-nsp 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] (no subject)
Hi, I have never seen anything about 'HRPC' before, but some googling suggests that its some Remote Procedure Call component they are using. RPC basically provides access for calling software functions a device, from another device. It might be what is being used in the stack for interswitch software comms, the interesting thing is x_setup. To me that suggests each device in the stack is providing a function for a 'factory reset'. I have no idea now a packet/RPC call from the real world would get messed up with that (if something came from outside the device), the only obvious things are using the CLI or web interface to perform a factory reset. Did you reset any switches at all around the same time? Also, the logs are the wrong way around? Not very helpful I know, but atleast it might explain what the error messages are actually saying... H On 25 August 2010 08:56, PARATTE Florent (G) florent.para...@gmail.comwrote: Hello, yesterday, a stack of three WS-C3750G-24TS-S IPBASE 12.2(50)SE3 reloaded after having erased its configuration... i tried to find the issue but i haven't found anything. I just have syslog messages as following: Notice 2010-08-2414:36:584606: 004527: Aug 24 14:36:57.301: %SYS-5-RELOAD: Reload requested by HRPC x_setup request handler. Reload reason: Reason unspecified Info 2010-08-2414:36:574605: 004526: Aug 24 14:36:56.295: %EXPRESS_SETUP-6-CONFIG_IS_RESET: The configuration is reset and the system will now reboot Do you have an idea of what happened? Thank you in advance. ___ cisco-nsp 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] Router 2 factor authentication
Hi I am looking for a 2FA solution in order to connect to Cisco devices. I would like to use either Radius or TACACS as the AAA part, however I'd like to know whether/how I could interconnect this to a 2nd auth such as a token based RSA securID platform I'd appreciate any input if this is possible at all? Regards Mark ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Router 2 factor authentication
How about users appending the token digits to the password? Of course this would mean your storing plain text passwords on the tacacs server somewhere.. On 25 August 2010 21:06, Mark Tech techcon...@yahoo.com wrote: Hi I am looking for a 2FA solution in order to connect to Cisco devices. I would like to use either Radius or TACACS as the AAA part, however I'd like to know whether/how I could interconnect this to a 2nd auth such as a token based RSA securID platform I'd appreciate any input if this is possible at all? Regards Mark ___ cisco-nsp 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] asr1000
Hello, we have an asr1000 acts as an LNS. Two weeks ago we upgraded it to XNF2, but the packet forwarding was not working at half of the pppoe sessions. We tested it with ping, the cpe received the icmp packet, and it sent the icmp replay, but the asr1000 was unable to handle it, so the pppoe connection (virtual-access interface) was up, but not working. Downgrading back to XNE1 didn't solve the issue, we had the same problem (maybe a microcode downgrade was not successful). After clearing the virtual-template and recreating the virtual-template the sessions were working again. Till now. We reloaded the box again, the first pppoe connection setup is ok, but if we cleared the session, then it didn't work any more: the connection setup was fine, but packet forwarding is broken... There no special thing in the cef table :-( Is any hint? BR, -A. ___ cisco-nsp 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] 3750 stack
Hi, One of potential problem to have only one single stack is the downtime during OS upgrade (and other maintenance). Two stack and backup each other via VRRP/HSRP could provide higher availability to clients (machines/customers) under them, provided those clients equips two up links to two different stacks. yes, I was going to ask about this - there isnt a direct way that I can see from cisco docs to upgrade a stack without suffering downtimes...thus all hosts connected. I can see a way of doing it that might work (havent tested the theory yet) if the hosts or switches connected are dual-linked or more to the stack. 1) force software upload onto a member, reboot said member... 2) stack will either migrate to new member when it reloads with latest IOS or mark it as version mismatch and not put it into operation - now reload other member(s) - the newest upgrade may now come into play 3) upgrade other membersthen reload them. hmm. any real or recommended ways? these stacks are supposed to remove SPoF location but at some point we need to reload (just like our routers - but those can be - as the aggregation switches are linked to multiple routers and we use eg HSRPv2 et al.. in fact, currently we can drop 50% of our routers during working hours without end user (thats great, it means less working strange hours) - but now our aggregation layer is the pain.. alan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Router 2 factor authentication
I am looking for a 2FA solution in order to connect to Cisco devices. I would like to use either Radius or TACACS as the AAA part, however I'd like to know whether/how I could interconnect this to a 2nd auth such as a token based RSA securID platform I'd appreciate any input if this is possible at all? I haven't used it for a while but doesn't Cisco ACS support token based authentication using an RSA SecurID server as it's authentication method? Chris ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Router 2 factor authentication
On Wed, Aug 25, 2010 at 01:06:24PM -0700, Mark Tech wrote: I am looking for a 2FA solution in order to connect to Cisco devices. I would like to use either Radius or TACACS as the AAA part, however I'd like to know whether/how I could interconnect this to a 2nd auth such as a token based RSA securID platform I'd appreciate any input if this is possible at all? RSA ACE server: http://www.rsa.com/node.aspx?id=1156 I've read that is does RADIUS by itself. If that ain't enough for your needs, a Cisco ACS might act as a mediator: http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_configuration_example09186a0080094650.shtml Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- d...@ircnet -- PGP: 0xA85C8AA0 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Router 2 factor authentication
Hello Mark: -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Mark Tech Sent: Wednesday, August 25, 2010 1:06 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Router 2 factor authentication Hi I am looking for a 2FA solution in order to connect to Cisco devices. I would like to use either Radius or TACACS as the AAA part, however I'd like to know whether/how I could interconnect this to a 2nd auth such as a token based RSA securID platform I'd appreciate any input if this is possible at all? Regards Mark We use the SecurID 7.0 servers from RSA and those boxes have the opensource ACS client as part of the installation. Or, you can also use their internal Radius server as well. Or, if you have already invested in ACS you can have the ACS authenticate against tokens directly. Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) ___ cisco-nsp 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] 0/0 into an ipv4 vrf
I'm fiddling with my lab, attempting to edumacate myself on L3VPNs. I'm trying to figure out the best way to get a default route into my test vrf. Since I'm doing BGP between all my PEs, it seems sensible that I try to originate the default route in BGP instead of redistributing it from another protocol. I'm having problems doing this. - I've tried to default-information originate within the ipv4 address family, then redistribute that default from the global table into the VRF, but Cisco doesn't like bgp to bgp redistribution. - The BGP sessions that are established between the PEs are established via the global table, not from within the ipv4 vrf address family, so I can't configure default-originate from in there either. - I'd rather not establish sessions with other PEs from within the ipv4 vrf address family. Other than being able to see the default route in that address family, there's really no other information that has to be in that routing table, so unless there's no other way to do what I want, I don't see a need to complicate that routing table at all. Any ideas? I'm sure it's possible, I'm just still a bit ignorant. Thanks in advance. ___ cisco-nsp 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] 3750 stack
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750e_3560e/software/release/12.2_50_se/command/reference/cli2.html#wp7675790 The joys of express setup... somebody held down the mode button for 10+ seconds. There should be files on the flash containing the old boot config and vlan.dat. Chris = Date: Wed, 25 Aug 2010 21:28:59 +0100 From: Heath Jones hj1...@gmail.com To: PARATTE Florent (G) florent.para...@gmail.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] (no subject) Message-ID: aanlktinfryc0rj=j4v1uz7bdhgrwek-n+qrfimjka...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, I have never seen anything about 'HRPC' before, but some googling suggests that its some Remote Procedure Call component they are using. RPC basically provides access for calling software functions a device, from another device. It might be what is being used in the stack for interswitch software comms, the interesting thing is x_setup. To me that suggests each device in the stack is providing a function for a 'factory reset'. I have no idea now a packet/RPC call from the real world would get messed up with that (if something came from outside the device), the only obvious things are using the CLI or web interface to perform a factory reset. Did you reset any switches at all around the same time? Also, the logs are the wrong way around? Not very helpful I know, but atleast it might explain what the error messages are actually saying... H On 25 August 2010 08:56, PARATTE Florent (G) florent.para...@gmail.comwrote: Hello, yesterday, a stack of three WS-C3750G-24TS-S IPBASE 12.2(50)SE3 reloaded after having erased its configuration... i tried to find the issue but i haven't found anything. I just have syslog messages as following: Notice 2010-08-2414:36:584606: 004527: Aug 24 14:36:57.301: %SYS-5-RELOAD: Reload requested by HRPC x_setup request handler. Reload reason: Reason unspecified Info 2010-08-2414:36:574605: 004526: Aug 24 14:36:56.295: %EXPRESS_SETUP-6-CONFIG_IS_RESET: The configuration is reset and the system will now reboot Do you have an idea of what happened? Thank you in advance. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Router 2 factor authentication
Out of curiosity can you tell me what led you to wanting 2FA for these devices, and how the traditional acl/tacacs method failed your requirements? Of course anyone who has implemented it is free to chime in, just generally interested in peoples security concerns around this and how you feel it mitigates whatever risks you were associating with it, also curious if it affected the way you handle OOB access aswell. Ben On Thu, Aug 26, 2010 at 6:06 AM, Mark Tech techcon...@yahoo.com wrote: Hi I am looking for a 2FA solution in order to connect to Cisco devices. I would like to use either Radius or TACACS as the AAA part, however I'd like to know whether/how I could interconnect this to a 2nd auth such as a token based RSA securID platform I'd appreciate any input if this is possible at all? Regards Mark ___ cisco-nsp 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] Storm-Control on server switch uplinks.
On 24/08/2010, at 8:59 PM, Saku Ytti wrote: First CSCO box to support policing unknown unicast is EARL7.5 but it is per chassis instead of per port. I'm not sure if any Cisco can support per port unknown unicast policing, but if Nexus7k/EARL8 doesn't do it, I'm betting there isn't any box which does it. generally speaking, cisco-nsp is not really the forum where we talk about internal details of internal implementation details of packet/frame forwarding within silicon, but... N7K M1 (EARL8) I/O modules do not currently do unknown unicast policing (UUFB aka unknown unicast flood blocking) at this point in time in any shipping release of NX-OS. do we plan to enable it? yes. can we do it per port? yes will we do so? yes. It is one of the two big WTFs I have with Cisco switches, the 2nd is inability to limit port MAC count without also employing port-security, which murders convergency budget. historically, enabling port security resulted in L2 (MAC) learning in h/w being disabled on many platforms, which would make MAC learning behave like many other vendors' switches that don't do h/w L2 learning. speaking for N7K M1 (EARL8) I/O modules, we can and still do h/w L2 learning with Port Security enabled on a port provided you use the protect port security method as outlined in http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/security/configuration/guide/Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_5.x_chapter16.html#con_1210940. cheers, lincoln. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Router 2 factor authentication
Hello Ben: -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Ben Steele Sent: Wednesday, August 25, 2010 5:42 PM To: Mark Tech Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Router 2 factor authentication Out of curiosity can you tell me what led you to wanting 2FA for these devices, and how the traditional acl/tacacs method failed your requirements? Of course anyone who has implemented it is free to chime in, just generally interested in peoples security concerns around this and how you feel it mitigates whatever risks you were associating with it, also curious if it affected the way you handle OOB access aswell. Ben In our case it's for compliance reasons. There are requirements within scope for many models that require two-factor authentication. For OOB, we use 2-factor to an OOB network that doesn't have any outside connectivity beyond our border firewalls. Granted, we are only in a few locations and do all of our OOB using IP addressed devices. If I had a dial-in AUX device at some remote location I would ask for mitigating circumstances for that device. Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Router 2 factor authentication
On Thu, 26 Aug 2010 10:42:28 +1000 Ben Steele b...@bensteele.org wrote: Out of curiosity can you tell me what led you to wanting 2FA for these devices, and how the traditional acl/tacacs method failed your requirements? We are using RSA SecurID on P and PE Routers to secure the core network and fullfil customer demands. 2FA on CE Routers is depending on the customer-needs, those who asked for it on the PE and P are usually having it on their CEs too. On OOB Devices it's a 2-step auth with encryption and callback. Regards, Dominik ___ cisco-nsp 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] QoS sometimes drives me nuts
I have really enjoyed learning about QoS, it's challenging. But I ran across something so simple today that doesn't work that I'm questioning whether I have learned anything at all All I wanted to do on a 6500 with Sup2's is mark all incoming traffic into my gig1/1 from a certain source address x.x.x.x to DSCP set to EF (46), like this: acc 101 permit udp x.x.x.x 0.0.0.255 any acc 101 permit tcp x.x.x.x 0.0.0.255 any class-map match-any IncomingVoiceTraffic match access-group 101 policy-map MarkIncomingVOIPTraffic class IncomingVoiceTraffic set ip dscp ef interface GigabitEthernet1/1 ip address blah blah service-policy input MarkIncomingVOIPTraffic When I look with Wireshark the RTP packets for a voip session aren't getting tagged inbound. Going back out gig1/1 is fine because the voip server is marking the traffic properly. I'm just having trouble inbound. Any gurus still awake? Thanks, CJ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
