From TGlover at eintellego.net Thu Oct 1 02:09:38 2009 From: TGlover at eintellego.net (Toby Glover) Date: Thu, 1 Oct 2009 16:09:38 +1000 Subject: [c-nsp] Q in Q injection Message-ID: <292AF25E62B8894C921B893B53A19D973957E7F6B9@BUSINESSEX.business.ad> Hi Guys, Quick question, what platform (eg 6500 with X line card) can inject VLANs into Q in Q? I know you can use a loopback cable on any system that supports Q in Q but this is not optimal. ..Toby -- Toby Glover, R&D Network Engineer eintellego Pty Ltd - The Networking Specialists toby at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)433 808 165 / skype://yobledoc -- From avayner at cisco.com Thu Oct 1 02:39:36 2009 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Thu, 1 Oct 2009 08:39:36 +0200 Subject: [c-nsp] Q in Q injection In-Reply-To: <292AF25E62B8894C921B893B53A19D973957E7F6B9@BUSINESSEX.business.ad> References: <292AF25E62B8894C921B893B53A19D973957E7F6B9@BUSINESSEX.business.ad> Message-ID: Toby, Can you explain a bit better what you want to achieve by "inject VLANs into Q in Q"? Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Toby Glover Sent: Thursday, October 01, 2009 08:10 To: cisco-nsp at puck.nether.net Subject: [c-nsp] Q in Q injection Hi Guys, Quick question, what platform (eg 6500 with X line card) can inject VLANs into Q in Q? I know you can use a loopback cable on any system that supports Q in Q but this is not optimal. ..Toby -- Toby Glover, R&D Network Engineer eintellego Pty Ltd - The Networking Specialists toby at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)433 808 165 / skype://yobledoc -- _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From eng_mssk at hotmail.com Thu Oct 1 03:26:24 2009 From: eng_mssk at hotmail.com (Mohammad Khalil) Date: Thu, 1 Oct 2009 10:26:24 +0300 Subject: [c-nsp] Graph packet loss , delay , BER Message-ID: hey all i want to be able to graph the packet loss between 2 routers or even between a router and a remote site as well as BER or delay , can i do that ? what is the best method to calculate this ? _________________________________________________________________ Windows Live?: Keep your life in sync. Check it out! http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 From TGlover at eintellego.net Thu Oct 1 03:36:37 2009 From: TGlover at eintellego.net (Toby Glover) Date: Thu, 1 Oct 2009 17:36:37 +1000 Subject: [c-nsp] Q in Q injection In-Reply-To: <292AF25E62B8894C921B893B53A19D973957E7F6B9@BUSINESSEX.business.ad> References: <292AF25E62B8894C921B893B53A19D973957E7F6B9@BUSINESSEX.business.ad> Message-ID: <292AF25E62B8894C921B893B53A19D973957E7F6BF@BUSINESSEX.business.ad> More information: What I need to do is add the outer layer VLAN ID. I have a VMware cloud, out of that comes a bunch of trunks with various customer VLANs. I need to be able to match VLANs then add an outer VLAN ie QinQ. So customer might have 3 servers, VLANs 100-102, They then need to be encapsulated as 3000/100 3000/101... They traverse the network and come out a QinQ tunnel port to the customer. Therefore the customer can just configure their port as a trunk, and it greatly eliminates the amount of VLANs trunked through our network. I know we can achieve this with loop back cables. As well 7600 with ES cards can "push" VLAN outer IDs, I have found sites saying that 3750me also do this, but I can't find the Cisco commands (they only seem to translate or drop not add). Anyone know any other (cheaper) platforms that can do this? Or a better way of achieving the above? Thanks. ..Toby -- Toby Glover, R&D Network Engineer eintellego Pty Ltd - The Networking Specialists toby at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)433 808 165 / skype://yobledoc -- -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Toby Glover Sent: Thursday, 1 October 2009 4:10 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Q in Q injection Hi Guys, Quick question, what platform (eg 6500 with X line card) can inject VLANs into Q in Q? I know you can use a loopback cable on any system that supports Q in Q but this is not optimal. ..Toby -- Toby Glover, R&D Network Engineer eintellego Pty Ltd - The Networking Specialists toby at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)433 808 165 / skype://yobledoc -- _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.115/2403 - Release Date: 09/29/09 17:56:00 From zivl at gilat.net Thu Oct 1 03:40:04 2009 From: zivl at gilat.net (Ziv Leyes) Date: Thu, 1 Oct 2009 09:40:04 +0200 Subject: [c-nsp] Graph packet loss , delay , BER In-Reply-To: References: Message-ID: We do a few monitors of this kind with cacti server using this template that works with a perl script http://forums.cacti.net/about5107.html It uses an snmp write community on the router and tells it to ping another remote device, the results are saved in RRD and you can make a graph out of it. Hope this helps, Ziv -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mohammad Khalil Sent: Thursday, October 01, 2009 9:26 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Graph packet loss , delay , BER hey all i want to be able to graph the packet loss between 2 routers or even between a router and a remote site as well as BER or delay , can i do that ? what is the best method to calculate this ? _________________________________________________________________ Windows Live(tm): Keep your life in sync. Check it out! http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 _______________________________________________ cisco-nsp mailing list cisco-nsp at 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. ************************************************************************************ From tomas at soitron.com Thu Oct 1 03:41:57 2009 From: tomas at soitron.com (Daniska, Tomas) Date: Thu, 1 Oct 2009 09:41:57 +0200 Subject: [c-nsp] Q in Q injection In-Reply-To: <292AF25E62B8894C921B893B53A19D973957E7F6BF@BUSINESSEX.business.ad> References: <292AF25E62B8894C921B893B53A19D973957E7F6B9@BUSINESSEX.business.ad> <292AF25E62B8894C921B893B53A19D973957E7F6BF@BUSINESSEX.business.ad> Message-ID: <6B43981C32F8464CB24CEE209DA32BD3026272E0@kenya.tronet.as> Toby, > What I need to do is add the outer layer VLAN ID. > I know we can achieve this with loop back cables. As well 7600 with ES > cards can "push" VLAN outer IDs, I have found sites saying that 3750me > also do this, but I can't find the Cisco commands (they only seem to > translate or drop not add). > > Anyone know any other (cheaper) platforms that can do this? > > Or a better way of achieving the above? switchport mode dot1q-tunnel is what you're seeking for -- deejay __________ Informacia od ESET NOD32 Antivirus, verzia databazy 4470 (20090930) __________ Tuto spravu preveril ESET NOD32 Antivirus. http://www.eset.sk From oboehmer at cisco.com Thu Oct 1 04:06:22 2009 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Thu, 1 Oct 2009 10:06:22 +0200 Subject: [c-nsp] Graph packet loss , delay , BER In-Reply-To: References: Message-ID: <6E4D2678AC543844917CA081C9D6B33F697CDC@XMB-AMS-103.cisco.com> Mohammad Khalil <> wrote on Thursday, October 01, 2009 09:26: > hey all > > i want to be able to graph the packet loss between 2 routers or even > between a router and a remote site as well as BER or delay , can i do > that ? > what is the best method to calculate this ? I would set up an IP-SLA probe on the router(s) to measure the latency/etc., and I would expect there are mrtg/cacti scripts around which are able to graph this data (using SNMP)... check out www.cisco.com/go/ipsla for more info on ip-sla.. oli From gk at ax.tc Thu Oct 1 04:50:16 2009 From: gk at ax.tc (Gerald Krause) Date: Thu, 01 Oct 2009 10:50:16 +0200 Subject: [c-nsp] So when is IPv6 failover coming to the ASA? In-Reply-To: <20090928175143.GA8804@lboro.ac.uk> References: <20090928161248.GT7045@lboro.ac.uk> <4AC0F4A9.3010002@inex.ie> <20090928175143.GA8804@lboro.ac.uk> Message-ID: <4AC46D48.60503@ax.tc> Am 28.09.2009 19:51, Alan Buxey schrieb: > Hi, > >> It certainly passes traffic and performs stateful packet firewalling. It >> doesn't do inspection very well, and failover is documented as not >> implemented. > > as Nick has said - it'll do the stuff when its alive and working. > > just dont expect to use the ADSM mgmt console to do any IPv6 stuff either. The newest ASDM support at least some basic IPv6 configuration (e.g. ACLs). -- Gerald (ax/tc) From lists at memetic.org Thu Oct 1 05:03:09 2009 From: lists at memetic.org (Adam Armstrong) Date: Thu, 01 Oct 2009 10:03:09 +0100 Subject: [c-nsp] Smartnet pricing? In-Reply-To: References: <01d401ca407d$f1797900$d46c6b00$@com> <4AC267B2.2080609@inex.ie> Message-ID: <4AC4704D.8060302@memetic.org> e ninja wrote: > Nick, > * > inline...* > > > On Tue, Sep 29, 2009 at 1:01 PM, Nick Hilliard wrote: > > >> On 29/09/2009 19:20, e ninja wrote: >> >> >>> No it is not right. >>> >>> 1. Anybody that has paid for software, should *never* have to pay for >>> bug >>> fixes. See http://resources.multiven.com/dossier-3 >>> >>> >> That is an interesting wish-list. Have you considered what it would do to >> the price of software if vendors were made liable? >> > > * > So vendors should not be made liable for software that people purchase? When > was the last time you happily paid for a brand-new car that won't start? > Software is always "new" because it can't break from over-use.* *Do > Microsoft, Apple, HP etc. charge customers for bug fixes in their OS? * > >> I can't imagine the insurance premiums, and the gratuitous law suits. >> Worse still, open source would be killed by it. >> > * > The bill of rights clearly refers to software that is paid for. Open source > software is free.* > In the UK we have laws stating that products should be fit for the purpose they're sold for (IANAL, though). Perhaps if it was tested in court properly, it would mean bug fixes which would prevent the use of the software safely would have to be provided free? I do, however, suspect that EULAs try to strip away as much legal protection as possible from the customer. >> I know that if I were to be held liable, I wouldn't ever release anything >> or contribute anything to open source software. >> >> > * > N/A. If you offer free software that nobody has to purchase, you are not > liable for the product.* > > >> 2. Forcing people to pay for a service they haven't used is >> >>> extortion- a criminal act - >>> seek legal counse >> Legal counsel would probably argue that if you left your support >> subscription lapse and then attempted to renew it several years later, that >> the reason for doing so was because of some failure outside the >> manufacturer's control, and that you were pulling a fast one. >> > * > I'm sure as a smart guy, you know there is no wear-and-tear in software. > Therefore, a user cannot 'break' software from over-use. All bugs in > proprietary software are inherent from the manufacturer, whether you > discover them from day 3 of purchase or 1000 years later.* > Think of hardware support as "insurance". The cost of providing the service when it finally breaks is spread across the entire lifetime of the contract. If someone has a device unsupported for 5 years, takes out support and it dies 2 years later, the supplier has lost the vast majority of the money they'd have used to pay for the replacement. Now, I don't think this should be the case for simple software upgrades, but I can see why it's the case for hardware replacement contracts. (And I can see why recert exists). adam. From david.freedman at uk.clara.net Thu Oct 1 07:25:45 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Thu, 01 Oct 2009 12:25:45 +0100 Subject: [c-nsp] Another bughunt, this time VRF PBR In-Reply-To: <7B8B0D6F623C3A40A0D0A80A66756E2B2C2F13@EXVS01.claranet.local> References: <7B8B0D6F623C3A40A0D0A80A66756E2B2C2F13@EXVS01.claranet.local> Message-ID: Well, after some extensive testing, I eventually found a working release. Tears of joy were indeed shed. For those whom are interested, it was 12.2SB but the only image with sufficient feature parity was the a3jk91s (enterprise) Dave. From moua0100 at umn.edu Thu Oct 1 09:49:09 2009 From: moua0100 at umn.edu (Ge Moua) Date: Thu, 01 Oct 2009 08:49:09 -0500 Subject: [c-nsp] Graph packet loss , delay , BER In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F697CDC@XMB-AMS-103.cisco.com> References: <6E4D2678AC543844917CA081C9D6B33F697CDC@XMB-AMS-103.cisco.com> Message-ID: <4AC4B355.4000206@umn.edu> smokeping Regards, Ge Moua | Email: moua0100 at umn.edu Network Design Engineer University of Minnesota | Networking & Telecommunications Services Oliver Boehmer (oboehmer) wrote: > Mohammad Khalil <> wrote on Thursday, October 01, 2009 09:26: > > >> hey all >> >> i want to be able to graph the packet loss between 2 routers or even >> between a router and a remote site as well as BER or delay , can i do >> that ? >> what is the best method to calculate this ? >> > > I would set up an IP-SLA probe on the router(s) to measure the > latency/etc., and I would expect there are mrtg/cacti scripts around > which are able to graph this data (using SNMP)... > check out www.cisco.com/go/ipsla for more info on ip-sla.. > > oli > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From eng_mssk at hotmail.com Thu Oct 1 12:30:15 2009 From: eng_mssk at hotmail.com (Mohammad Khalil) Date: Thu, 1 Oct 2009 19:30:15 +0300 Subject: [c-nsp] facebook related Message-ID: hey I was asked today if i recieved a message on facebook can i know the ip address of the sender _________________________________________________________________ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx From asturluismi at gmail.com Thu Oct 1 12:35:43 2009 From: asturluismi at gmail.com (luismi) Date: Thu, 01 Oct 2009 18:35:43 +0200 Subject: [c-nsp] sliding window quota Message-ID: <1254414943.7369.0.camel@dsba-ipso> Hi all, Any product from Cisco -or not- to manage sliding window BW quotas? From gert at greenie.muc.de Thu Oct 1 12:54:53 2009 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 1 Oct 2009 18:54:53 +0200 Subject: [c-nsp] facebook related In-Reply-To: References: Message-ID: <20091001165453.GD1508@greenie.muc.de> Hi, On Thu, Oct 01, 2009 at 07:30:15PM +0300, Mohammad Khalil wrote: > I was asked today if i recieved a message on facebook can i know the ip address of the sender Since this is the cisco-nsp list, I'm guessing that you bought a nice product from Cisco to achieve this, and now need our help in configuring it. So - what is this product? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From eng_mssk at hotmail.com Thu Oct 1 12:55:43 2009 From: eng_mssk at hotmail.com (Mohammad Khalil) Date: Thu, 1 Oct 2009 19:55:43 +0300 Subject: [c-nsp] facebook related In-Reply-To: <76130104-3A0E-4F3C-B175-862F32CE0315@edgewire.sg> References: Message-ID: sorry all as i told i asked here as its ip related thats it sorry again all > Subject: Re: [c-nsp] facebook related > From: mark at edgewire.sg > Date: Fri, 2 Oct 2009 00:50:28 +0800 > CC: cisco-nsp at puck.nether.net > To: eng_mssk at hotmail.com > > No, probably not. How is this Cisco related by the way? > > On 02-Oct-2009, at 12:30 AM, Mohammad Khalil wrote: > > > hey > > > > I was asked today if i recieved a message on facebook can i know > > the ip address of the sender > > > > _________________________________________________________________ > > Show them the way! Add maps and directions to your party invites. > > http://www.microsoft.com/windows/windowslive/products/events.aspx > > _______________________________________________ > > cisco-nsp mailing list cisco-nsp at puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us From andy.petrenko at gmail.com Thu Oct 1 12:55:50 2009 From: andy.petrenko at gmail.com (Andrey 'sshd' Petrenko) Date: Thu, 1 Oct 2009 19:55:50 +0300 Subject: [c-nsp] facebook related In-Reply-To: References: Message-ID: <6b300f5d0910010955h3fbbdeebn1eb9c6877f06d4cf@mail.gmail.com> You have message from system, or another user? 2009/10/1 Mohammad Khalil > hey > > I was asked today if i recieved a message on facebook can i know the ip > address of the sender > > _________________________________________________________________ > Show them the way! Add maps and directions to your party invites. > http://www.microsoft.com/windows/windowslive/products/events.aspx > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- With best regards, Andrey 'sshd' Petrenko xmmp: sshd at jabber.org gtalk: andy.petrenko at gmail.com skype: andy.petrenko web: http://sshd.by From streiner at cluebyfour.org Thu Oct 1 13:07:22 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 1 Oct 2009 13:07:22 -0400 (EDT) Subject: [c-nsp] facebook related In-Reply-To: References: Message-ID: On Thu, 1 Oct 2009, Mohammad Khalil wrote: > I was asked today if i recieved a message on facebook can i know the > ip address of the sender My guess is that you will not see the IP address of the sender when you receive a message through Facebook. Facebook doesn't present full message headers on messages that are sent through the website. Since all communication happens through the website, that provides a layer of abstraction if Facebook/Myspace/insert_portal_here chooses not to reveal the sender's IP address to you. jms From avayner at cisco.com Thu Oct 1 13:08:38 2009 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Thu, 1 Oct 2009 19:08:38 +0200 Subject: [c-nsp] sliding window quota In-Reply-To: <1254414943.7369.0.camel@dsba-ipso> References: <1254414943.7369.0.camel@dsba-ipso> Message-ID: Hi, What do you want to achieve? Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of luismi Sent: Thursday, October 01, 2009 18:36 To: cisco-nsp at puck.nether.net Subject: [c-nsp] sliding window quota Hi all, Any product from Cisco -or not- to manage sliding window BW quotas? _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From KaeglerM at tessco.com Thu Oct 1 13:12:36 2009 From: KaeglerM at tessco.com (Kaegler, Mike) Date: Thu, 01 Oct 2009 13:12:36 -0400 Subject: [c-nsp] sliding window quota In-Reply-To: <1254414943.7369.0.camel@dsba-ipso> Message-ID: Packeteer (now owned by Blue Coat) will play with TCP window sizes as part of their bandwidth management bag of tricks. Packeteer can handle some complex shaping/management plans in a understandable way. I strongly encourage anyone looking at bandwidth management to take a look. Staying on the Cisco side, WAAS and the various IOS QoS stuff will help. -porkchop On 10/1/09 12:35 PM, "luismi" wrote: > Hi all, > > Any product from Cisco -or not- to manage sliding window BW quotas? > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295 Your wireless success, nothing less. http://www.tessco.com/ From eng_mssk at hotmail.com Thu Oct 1 13:23:38 2009 From: eng_mssk at hotmail.com (Mohammad Khalil) Date: Thu, 1 Oct 2009 20:23:38 +0300 Subject: [c-nsp] facebook related In-Reply-To: References: Message-ID: thanks alot justin for the reply , i got ur point > Date: Thu, 1 Oct 2009 13:07:22 -0400 > From: streiner at cluebyfour.org > To: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] facebook related > > On Thu, 1 Oct 2009, Mohammad Khalil wrote: > > > I was asked today if i recieved a message on facebook can i know the > > ip address of the sender > > My guess is that you will not see the IP address of the sender when you > receive a message through Facebook. Facebook doesn't present full message > headers on messages that are sent through the website. Since all > communication happens through the website, that provides a layer of > abstraction if Facebook/Myspace/insert_portal_here chooses not to reveal > the sender's IP address to > you. > > jms > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us From paul at paulstewart.org Thu Oct 1 13:26:49 2009 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 1 Oct 2009 13:26:49 -0400 Subject: [c-nsp] sliding window quota In-Reply-To: References: <1254414943.7369.0.camel@dsba-ipso> Message-ID: <000f01ca42bc$5c6a0fa0$153e2ee0$@org> One of the best solutions in my opinion is Arbor (presuming I understood your reference to sliding window BW quotas).... highly recommend their gear. Paul -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Kaegler, Mike Sent: October 1, 2009 1:13 PM To: luismi; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] sliding window quota Packeteer (now owned by Blue Coat) will play with TCP window sizes as part of their bandwidth management bag of tricks. Packeteer can handle some complex shaping/management plans in a understandable way. I strongly encourage anyone looking at bandwidth management to take a look. Staying on the Cisco side, WAAS and the various IOS QoS stuff will help. -porkchop On 10/1/09 12:35 PM, "luismi" wrote: > Hi all, > > Any product from Cisco -or not- to manage sliding window BW quotas? > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295 Your wireless success, nothing less. http://www.tessco.com/ _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From andy.petrenko at gmail.com Thu Oct 1 13:31:17 2009 From: andy.petrenko at gmail.com (Andrey 'sshd' Petrenko) Date: Thu, 1 Oct 2009 20:31:17 +0300 Subject: [c-nsp] facebook related In-Reply-To: References: Message-ID: <6b300f5d0910011031j47800be2qe949555f7e60c096@mail.gmail.com> if you resived any messages from facebook, you will see ip address of facebook server.p.s. sorry for my english =) 2009/10/1 Justin M. Streiner > On Thu, 1 Oct 2009, Mohammad Khalil wrote: > > I was asked today if i recieved a message on facebook can i know the ip >> address of the sender >> > > My guess is that you will not see the IP address of the sender when you > receive a message through Facebook. Facebook doesn't present full message > headers on messages that are sent through the website. Since all > communication happens through the website, that provides a layer of > abstraction if Facebook/Myspace/insert_portal_here chooses not to reveal the > sender's IP address to you. > > jms > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- With best regards, Andrey 'sshd' Petrenko xmmp: sshd at jabber.org gtalk: andy.petrenko at gmail.com skype: andy.petrenko web: http://sshd.by From mark at edgewire.sg Thu Oct 1 12:50:28 2009 From: mark at edgewire.sg (mark (at) edgewire) Date: Fri, 2 Oct 2009 00:50:28 +0800 Subject: [c-nsp] facebook related In-Reply-To: References: Message-ID: <76130104-3A0E-4F3C-B175-862F32CE0315@edgewire.sg> No, probably not. How is this Cisco related by the way? On 02-Oct-2009, at 12:30 AM, Mohammad Khalil wrote: > hey > > I was asked today if i recieved a message on facebook can i know > the ip address of the sender > > _________________________________________________________________ > Show them the way! Add maps and directions to your party invites. > http://www.microsoft.com/windows/windowslive/products/events.aspx > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From avayner at cisco.com Thu Oct 1 15:04:07 2009 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Thu, 1 Oct 2009 21:04:07 +0200 Subject: [c-nsp] sliding window quota In-Reply-To: References: <1254414943.7369.0.camel@dsba-ipso> Message-ID: On the Cisco side you should also take a look at the SCE solution. Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Kaegler, Mike Sent: Thursday, October 01, 2009 19:13 To: luismi; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] sliding window quota Packeteer (now owned by Blue Coat) will play with TCP window sizes as part of their bandwidth management bag of tricks. Packeteer can handle some complex shaping/management plans in a understandable way. I strongly encourage anyone looking at bandwidth management to take a look. Staying on the Cisco side, WAAS and the various IOS QoS stuff will help. -porkchop On 10/1/09 12:35 PM, "luismi" wrote: > Hi all, > > Any product from Cisco -or not- to manage sliding window BW quotas? > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295 Your wireless success, nothing less. http://www.tessco.com/ _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From harbor235 at gmail.com Thu Oct 1 15:39:37 2009 From: harbor235 at gmail.com (harbor235) Date: Thu, 1 Oct 2009 15:39:37 -0400 Subject: [c-nsp] Strange Pix Firewall issue. Proxy Arp In-Reply-To: <4AC41B37.60301@cisco.com> References: <4AC41B37.60301@cisco.com> Message-ID: <836bf1f90910011239r4fedcdebs5d3ee5870cdecc00@mail.gmail.com> Or, the devices on the inside network have an incorrect mask mike On Wed, Sep 30, 2009 at 11:00 PM, David White, Jr. (dwhitejr) < dwhitejr at cisco.com> wrote: > Hi Brad, > > The below static would not cause the behavior you describe. > Are you sure you don't have another "static (outside,inside)..." > statement which covers the network range of the inside network? > > As a temporary workaround you can most likely disable proxy-arps on the > inside interface via 'sysopt noproxyarp inside'. > > Sincerely, > > David. > > > Brad Case wrote: > > Hi there, > > > > I am having a very strange isse on a Pix firewall: > > > > The following is configured: > > > > nameif vlan2512 INSIDE security22 > > nameif vlan2100 OUTSIDE security20 > > > > ip address INSIDE 192.168.35.129 255.255.255.128 standby 192.168.35.130 > > ip address OUTSIDE 192.168.35.1 255.255.255.128 standby 192.168.35.2 > > > > # Identity NAT statement: > > > > static (INSIDE,OUTSIDE) 192.168.35.128 192.168.35.128 netmask > > 255.255.255.128 > > > > With the above configuration I am getting a strange thing happening with > > proxy arp. If a server on the INSIDE interface does a ARP request for an > IP > > in the same subnet range as the INSIDE interface for an IP address other > > than 192.168.35.129 or 192.168.35.130, the firewall is replying to it. > Can > > anybody explain the reason why this behaviour would be occuring with the > > above? > > _______________________________________________ > > cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From ttauber at 1-4-5.net Thu Oct 1 16:06:16 2009 From: ttauber at 1-4-5.net (Tony Tauber) Date: Thu, 1 Oct 2009 13:06:16 -0700 Subject: [c-nsp] facebook related In-Reply-To: References: Message-ID: <20091001200616.GK9785@1-4-5.net> Aww. I thought this was going to introduce the Facebook app "IOS Upgrade Manager" which enables you to navigate www.cisco.com by using Facebook. Answer burning questions like : "If your friends were IOS software, which train/version would they be?" Or games like "Two of your friends configured EIGRP using Protocol Wars". Well, there's still hope for the future. Tony On Thu, Oct 01, 2009 at 01:07:22PM -0400, Justin M. Streiner wrote: > On Thu, 1 Oct 2009, Mohammad Khalil wrote: > >> I was asked today if i recieved a message on facebook can i know the >> ip address of the sender > > My guess is that you will not see the IP address of the sender when > you receive a message through Facebook. Facebook doesn't present > full message headers on messages that are sent through the website. > Since all communication happens through the website, that provides a > layer of abstraction if Facebook/Myspace/insert_portal_here chooses > not to reveal the sender's IP address to you. From Jonathan.Brashear at hq.speakeasy.net Thu Oct 1 16:16:08 2009 From: Jonathan.Brashear at hq.speakeasy.net (Jonathan Brashear) Date: Thu, 1 Oct 2009 13:16:08 -0700 Subject: [c-nsp] facebook related In-Reply-To: <20091001200616.GK9785@1-4-5.net> References: <20091001200616.GK9785@1-4-5.net> Message-ID: <725755F5E728EE4086DAAF1A54DACF4F1A2D8119CD@sea5exbe1.speakeasy.hq> I'm working on a Twitter MPLS optimizer, personally. #makemplsfaster Network Engineer, JNCIS-M > 214-981-1954 (office) > 214-642-4075 (cell) > jbrashear at hq.speakeasy.net http://www.speakeasy.net -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tony Tauber Sent: Thursday, October 01, 2009 3:06 PM To: Justin M. Streiner Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] facebook related Aww. I thought this was going to introduce the Facebook app "IOS Upgrade Manager" which enables you to navigate www.cisco.com by using Facebook. Answer burning questions like : "If your friends were IOS software, which train/version would they be?" Or games like "Two of your friends configured EIGRP using Protocol Wars". Well, there's still hope for the future. Tony On Thu, Oct 01, 2009 at 01:07:22PM -0400, Justin M. Streiner wrote: > On Thu, 1 Oct 2009, Mohammad Khalil wrote: > >> I was asked today if i recieved a message on facebook can i know the >> ip address of the sender > > My guess is that you will not see the IP address of the sender when > you receive a message through Facebook. Facebook doesn't present > full message headers on messages that are sent through the website. > Since all communication happens through the website, that provides a > layer of abstraction if Facebook/Myspace/insert_portal_here chooses > not to reveal the sender's IP address to you. _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From mcaudill at cisco.com Thu Oct 1 17:17:59 2009 From: mcaudill at cisco.com (Mike Caudill) Date: Thu, 01 Oct 2009 17:17:59 -0400 Subject: [c-nsp] facebook related In-Reply-To: <20091001200616.GK9785@1-4-5.net> References: <20091001200616.GK9785@1-4-5.net> Message-ID: <4AC51C87.7040608@cisco.com> On 10/1/09 4:06 PM, Tony Tauber wrote: > Aww. I thought this was going to introduce the Facebook app > "IOS Upgrade Manager" which enables you to navigate www.cisco.com by > using Facebook. Answer burning questions like : > "If your friends were IOS software, which train/version would they be?" > Or games like "Two of your friends configured EIGRP using Protocol Wars". > > Well, there's still hope for the future. > > Tony > BGP peering or CDP via facebook: You have 2 peer/neighbor requests: Cisco7206 -- 8 peers [Confirm] [Ignore] C3750 -- 40 neighbors [Confirm] [Ignore] You could even use it for network management. My network device friends on Facebook: Forwarding breakdown: 36% layer 3 / 64% layer 2 Geographic distribution: 190 countries, 50 states Protocol preference: 100% IPv4, 37% IPv6 Relationship status: connected. Favorite IOS version: 12.4T etc. Too funny... -Mike- -- Mike Caudill PSIRT Incident Manager DSS PGP: 0xEBBD5271 +1.919.392.2855 / +1.919.522.4931 (cell) http://www.cisco.com/go/psirt From judah.scott.iam at gmail.com Thu Oct 1 19:39:19 2009 From: judah.scott.iam at gmail.com (Judah Scott) Date: Thu, 1 Oct 2009 16:39:19 -0700 Subject: [c-nsp] Smartnet pricing? In-Reply-To: <4AC4704D.8060302@memetic.org> References: <01d401ca407d$f1797900$d46c6b00$@com> <4AC267B2.2080609@inex.ie> <4AC4704D.8060302@memetic.org> Message-ID: <3172b9cb0910011639t1780195bq8163969c4cec7fe1@mail.gmail.com> If you consider support contracts as insurance then it sounds crazy to pay for the years you were not insured. An example is fire insurance: If you buy fire insurance 10 years after a home is built, State Farm isn't going to charge you for the first 10 years. A quick inspection to verify that all hardware is working may be required just to make sure there is no pre-contract damage. -J Scott On Thu, Oct 1, 2009 at 2:03 AM, Adam Armstrong wrote: > e ninja wrote: > >> Nick, >> * >> inline...* >> >> >> On Tue, Sep 29, 2009 at 1:01 PM, Nick Hilliard wrote: >> >> >> >>> On 29/09/2009 19:20, e ninja wrote: >>> >>> >>> >>>> No it is not right. >>>> >>>> 1. Anybody that has paid for software, should *never* have to pay for >>>> bug >>>> fixes. See http://resources.multiven.com/dossier-3 >>>> >>>> >>>> >>> That is an interesting wish-list. Have you considered what it would do >>> to >>> the price of software if vendors were made liable? >>> >>> >> >> * >> So vendors should not be made liable for software that people purchase? >> When >> was the last time you happily paid for a brand-new car that won't start? >> Software is always "new" because it can't break from over-use.* *Do >> Microsoft, Apple, HP etc. charge customers for bug fixes in their OS? * >> >> >>> I can't imagine the insurance premiums, and the gratuitous law suits. >>> Worse still, open source would be killed by it. >>> >>> >> * >> The bill of rights clearly refers to software that is paid for. Open >> source >> software is free.* >> >> > In the UK we have laws stating that products should be fit for the purpose > they're sold for (IANAL, though). Perhaps if it was tested in court > properly, it would mean bug fixes which would prevent the use of the > software safely would have to be provided free? I do, however, suspect that > EULAs try to strip away as much legal protection as possible from the > customer. > > I know that if I were to be held liable, I wouldn't ever release anything >>> or contribute anything to open source software. >>> >>> >>> >> * >> N/A. If you offer free software that nobody has to purchase, you are not >> liable for the product.* >> >> >> >>> 2. Forcing people to pay for a service they haven't used is >>> >>> >>>> extortion- a criminal act - >>>> seek legal counse >>>> >>> Legal counsel would probably argue that if you left your support >>> subscription lapse and then attempted to renew it several years later, >>> that >>> the reason for doing so was because of some failure outside the >>> manufacturer's control, and that you were pulling a fast one. >>> >>> >> * >> I'm sure as a smart guy, you know there is no wear-and-tear in software. >> Therefore, a user cannot 'break' software from over-use. All bugs in >> proprietary software are inherent from the manufacturer, whether you >> discover them from day 3 of purchase or 1000 years later.* >> >> > Think of hardware support as "insurance". The cost of providing the service > when it finally breaks is spread across the entire lifetime of the contract. > If someone has a device unsupported for 5 years, takes out support and it > dies 2 years later, the supplier has lost the vast majority of the money > they'd have used to pay for the replacement. > > Now, I don't think this should be the case for simple software upgrades, > but I can see why it's the case for hardware replacement contracts. (And I > can see why recert exists). > > adam. > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From Skeeve at eintellego.net Fri Oct 2 00:38:24 2009 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Fri, 2 Oct 2009 14:38:24 +1000 Subject: [c-nsp] Cisco 887 (not V) availability Message-ID: <292AF25E62B8894C921B893B53A19D973957E7F6EE@BUSINESSEX.business.ad> Hey all, Has anyone heard when the Cisco 887 will be available. It isn't on the website main section yet, but I've found some references to it in various places, but most specifically here: http://www.google.com.au/url?sa=t&source=web&ct=res&cd=3&url=http%3A%2F%2Fwww.cisco.com%2Fen%2FUS%2Fprod%2Fcollateral%2Frouters%2Fps380%2Fdata_sheet_c78_459542.pdf&ei=h4LFSoi6CMa9kAXHxaw7&rct=j&q=cisco+887+adsl&usg=AFQjCNG88o021o8QhCoaR_D7cnZxNXVFIg Would love to know when I can do a Cisco ADSL CPE with N for a reasonable price (non 1800+) ...Skeeve -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. From jp at softnet.si Fri Oct 2 03:38:25 2009 From: jp at softnet.si (Primoz Jeroncic) Date: Fri, 2 Oct 2009 09:38:25 +0200 (CEST) Subject: [c-nsp] FCIP and Cisco ASA5510 Message-ID: Hi I'm trying to get fiber channel over IP, and people configuring FC boxes have bunch of problems. At the moment I have Cisco ASA5510 on both locations with IPSec VPN between them. Normal IP traffic goes through VPN fine, but their connection between their boxes is constantly dropping after second or two. I got some recomendation from HP about settings of ASA, but I have idea how to configure this. Recommendations are following: - "turn off" FCIP inspection of inside ethernet port ! based on this what I see, only standard inspection is configured (dns, ftp, h323, rsh, smtp...) - configure service policy: Global policy: Service-policy: global_policy Class-map: FCIP Set connection policy: random-sequence-number disable drop 0 Set connection timeout policy: embryonic 12:00:00 half-closed 12:00:00 tcp 12:00:00 DCD: disabled, retry-interval 0:00:15, max-retries 5 DCD: client-probe 0, server-probe 0, conn-expiration 0 Would someone mind explaining, how to configure this, since I can't find any at least a bit specific config for FCIP on CCO. I would also appreciate some sample config if anyone configured something similar already. PS: My current config on ASA looks like this (I will copy config of just one, since other is pretty much same with reversed IP addresses of course): interface Ethernet0/0 description UPSTREAM nameif outside security-level 0 ip address 20.1.1.2 255.255.255.252 ! interface Ethernet0/1 description LAN nameif inside security-level 100 ip address 10.1.1.1 255.255.255.128 ! ftp mode passive dns server-group DefaultDNS domain-name xxxx.si access-list outside-fw extended permit gre host x.x.x.x host y.y.y.y access-list outside-fw extended permit esp host x.x.x.x host y.y.y.y access-list outside-fw extended permit udp host x.x.x.x host y.y.y.y eq isakmp access-list outside-fw extended permit udp host x.x.x.x host y.y.y.y eq 4500 access-list nonat extended permit ip 10.1.1.0 255.255.255.0 10.1.2.0 255.255.255.0 access-list vpn-lj extended permit ip 10.1.1.0 255.255.255.128 10.1.2.0 255.255.255.128 access-list vpn-lj extended permit esp 10.1.1.0 255.255.255.128 10.1.2.0 255.255.255.128 access-list vpn-lj extended permit gre 10.1.1.0 255.255.255.128 10.1.2.0 255.255.255.128 access-list vpn-lj extended permit igmp 10.1.1.0 255.255.255.128 10.1.2.0 255.255.255.128 pager lines 24 logging enable logging monitor notifications logging buffered notifications logging asdm informational mtu outside 1500 mtu inside 1500 no failover icmp unreachable rate-limit 1 burst-size 1 no asdm history enable arp timeout 14400 global (outside) 1 interface nat (inside) 0 access-list nonat nat (lan2) 0 access-list nonat access-group outside-fw in interface outside route outside 0.0.0.0 0.0.0.0 20.1.1.1 1 timeout xlate 3:00:00 timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02 timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00 timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00 timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute timeout tcp-proxy-reassembly 0:01:00 dynamic-access-policy-record DfltAccessPolicy crypto ipsec transform-set cset-aes256-sha esp-aes-256 esp-sha-hmac crypto ipsec security-association lifetime seconds 28800 crypto ipsec security-association lifetime kilobytes 4608000 crypto map cmap 1 match address vpn-lj crypto map cmap 1 set peer x.x.x.x crypto map cmap 1 set transform-set cset-aes256-sha crypto map cmap interface outside crypto isakmp enable outside crypto isakmp policy 1 authentication pre-share encryption aes-256 hash sha group 1 lifetime 3600 ! threat-detection basic-threat threat-detection statistics access-list no threat-detection statistics tcp-intercept webvpn tunnel-group x.x.x.x type ipsec-l2l tunnel-group x.x.x.x ipsec-attributes pre-shared-key * ! class-map inspection_default match default-inspection-traffic ! policy-map type inspect dns preset_dns_map parameters message-length maximum 512 policy-map global_policy class inspection_default inspect dns preset_dns_map inspect ftp inspect h323 h225 inspect h323 ras inspect rsh inspect rtsp inspect esmtp inspect sqlnet inspect skinny inspect sunrpc inspect xdmcp inspect sip inspect netbios inspect tftp ! Thanks for all help in advance already. :) Have fun, Primoz Jeroncic Support - IP Connectivity & Routing ------------------------------------------------------------------- Softnet d.o.o. tel: +386 1 562 31 40 | Borovec 2 fax: +386 1 562 18 55 | 1 + 1 = 3 1236 Trzin primoz(at)softnet.si | for larger values of 1 Slovenija http://flea.softnet.si/ ------------------------------------------------------------------- From tue at steria.dk Fri Oct 2 05:36:48 2009 From: tue at steria.dk (tue at steria.dk) Date: Fri, 2 Oct 2009 11:36:48 +0200 Subject: [c-nsp] Strange Pix Firewall issue. Proxy Arp Message-ID: > > The following is configured: > > > > nameif vlan2512 INSIDE security22 > > nameif vlan2100 OUTSIDE security20 > > > > ip address INSIDE 192.168.35.129 255.255.255.128 standby 192.168.35.130 > > ip address OUTSIDE 192.168.35.1 255.255.255.128 standby 192.168.35.2 > > > > # Identity NAT statement: > > > > static (INSIDE,OUTSIDE) 192.168.35.128 192.168.35.128 netmask > > 255.255.255.128 The ip 192.168.35.128 is the broadcast address for the OUTSIDE interface Perhaps this explains the strange behavior Best regards Tue ------------------------------------------------------------------------------------ Med en oms?tning p? DKK 14 mia. og 19.000 ansatte er Steria blandt de ti f?rende it-serviceleverand?rer i Europa. Gruppen, som er repr?senteret i 16 lande, herunder i Danmark med ca. 170 medarbejdere, leverer komplette l?sninger inden for f?lgende fokusomr?der: R?dgivning, systemintegration og it-drift. Det betyder, at Steria bist?r med alt fra forretnings- og it-r?dgivning til projektledelse, systemudvikling og infrastrukturleverancer til drift, hosting og vedligehold. Yderligere oplysninger kan l?ses p? www.steria.dk og www.steria.com. This email originates from Steria A/S, Tonsbakken 16-18, DK-2740 Skovlunde - www.steria.dk. This email and any attachments may contain confidential/intellectual property/copyright information and is only for the use of the addressee(s). You are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way if you are not the addressee(s) or responsible for delivery. If you receive this email by mistake, please advise the sender and cancel it immediately. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Any email is susceptible to alteration and its integrity cannot be assured. Steria shall not be liable if the message is altered, modified, falsified, or even edited. From jonas.jonsson at netent.com Fri Oct 2 07:20:07 2009 From: jonas.jonsson at netent.com (Jonas Jonsson) Date: Fri, 2 Oct 2009 13:20:07 +0200 Subject: [c-nsp] Crypto tunnel issue or undocumented feature? Message-ID: <78DD389C2574C947AD8B34B9D043309E035EC447@ex01.netentertainment.com> I have a small question regarding the behavior that I have noticed on a crypto tunnel between a Cisco router and a ASA. The tunnel is a vanilla tunnel with crypto map etc on the router side and the corresponding on the ASA. Tunnel is set up ok and all is fine until you do a forbidden action towards the ASA, i.e. icmp is not allowed in the tunnel. Then the following event happens: 001326: *Sep 28 13:49:32.171 UTC: ISAKMP:(1237):deleting SA reason "Recevied fatal informational" state (R) QM_IDLE (peer 19.17.18.22) 001327: *Sep 28 13:49:32.171 UTC: ISAKMP:(1237):deleting node 2127279974 error FALSE reason "Informational (in) state 1" 001328: *Sep 28 13:49:32.171 UTC: ISAKMP:(1237):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY 001329: *Sep 28 13:49:32.171 UTC: ISAKMP:(1237):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE It was a bit puzzling until after looking at the remote config we allowed icmp and the tunnel now stays up. Hence is this an undocumented feature or a bug? /// Best regards, Jonas -------------------------------------------------------- Jonas Jonsson Net Entertainment NE AB, Birger Jarlsgatan 57 B, S-113 56 Stockholm, Sweden M: +46707609811, T: +46707609811, F: +46 8 556 967 07 jonas.jonsson at netent.com, www.netent.com Better Games From jfitz at Princeton.EDU Fri Oct 2 09:36:19 2009 From: jfitz at Princeton.EDU (Jeff Fitzwater) Date: Fri, 2 Oct 2009 09:36:19 -0400 Subject: [c-nsp] Will UDLD work with converters ? Message-ID: Is there any issues with running UDLD with TX to Fiber converters at each end of a gig cisco to cisco link? We are just over the distance budget with the 10KM optics. 6500 TX port--- to fiber converter--- 18KM fiber--- to converter--- back to TX port on 3750. We are looking at the converters because the Cisco ZX optics are very expensive and the converters with 30KM optics are much cheaper than the 60 KM ZX optics. Thanks in advance... Jeff Fitzwater OIT Network Systems Princeton University From nick at inex.ie Fri Oct 2 10:05:41 2009 From: nick at inex.ie (Nick Hilliard) Date: Fri, 02 Oct 2009 15:05:41 +0100 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: References: Message-ID: <4AC608B5.6010804@inex.ie> On 02/10/2009 14:36, Jeff Fitzwater wrote: > Is there any issues with running UDLD with TX to Fiber converters at > each end of a gig cisco to cisco link? We are just over the distance > budget with the 10KM optics. > > 6500 TX port--- to fiber converter--- 18KM fiber--- to converter--- back > to TX port on 3750. > > We are looking at the converters because the Cisco ZX optics are very > expensive and the converters with 30KM optics are much cheaper than the > 60 KM ZX optics. UDLD should be fine - it's just data packets, after all. So unless your media converters are doing something very strange and very wrong, it will be fine. You may want to look at third party optics from reputable manufacturers (e.g. http://www.finisar.com/optical_modules_2), although many organisations have policies in place which work against using third party components. Also, it is very easy to pick up grey optics with cisco serial numbers on them, which means that the special command which we all know about isn't necessary. Also, bear in mind that not all c65k ports support reading DDM info from SFPs. SUP720 cards will, as will later hardware revisions of the 6724sfp blades. Earlier hardware revisions won't. Also, 12.2SX >= SXF9 will not present DDM unless it sees a Cisco serial number. Nick From gert at greenie.muc.de Fri Oct 2 10:15:56 2009 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 2 Oct 2009 16:15:56 +0200 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: References: Message-ID: <20091002141556.GR1508@greenie.muc.de> Hi, On Fri, Oct 02, 2009 at 09:36:19AM -0400, Jeff Fitzwater wrote: > Is there any issues with running UDLD with TX to Fiber converters at > each end of a gig cisco to cisco link? We are just over the distance > budget with the 10KM optics. As far as I remember, Cisco will never do UDLD on TX ports. We'd stay away from converters, and better get 3rd-party ZX optics instead. Converters are always trouble (autosensing yes/no? will it properly signal 'link down' when there is a problem with the other side? etc.). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From zoe-nsp at complicity.co.uk Fri Oct 2 10:24:05 2009 From: zoe-nsp at complicity.co.uk (Zoe O'Connell) Date: Fri, 02 Oct 2009 15:24:05 +0100 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <4AC608B5.6010804@inex.ie> References: <4AC608B5.6010804@inex.ie> Message-ID: <4AC60D05.20003@complicity.co.uk> Nick Hilliard wrote: > You may want to look at third party optics from reputable > manufacturers (e.g. http://www.finisar.com/optical_modules_2), > although many organisations have policies in place which work against > using third party components. Also, it is very easy to pick up grey > optics with cisco serial numbers on them, which means that the special > command which we all know about isn't necessary. > > Also, bear in mind that not all c65k ports support reading DDM info > from SFPs. SUP720 cards will, as will later hardware revisions of the > 6724sfp blades. Earlier hardware revisions won't. Also, 12.2SX >= > SXF9 will not present DDM unless it sees a Cisco serial number. It's worth noting that while the restriction on optics in general is just annoying, the DOM restrictions do seem to be there for a reason: I have a number of non-Cisco optics reporting DOM data that's obviously incorrect, so I don't trust anything that's non-Cisco. Sadly, on platforms where it will show you DOM from any SFP, there's no obvious indication if it's a Cisco or third party optic. From uvh at siemens.com Fri Oct 2 10:25:48 2009 From: uvh at siemens.com (Hansen, Ulrich Vestergaard B. (E R WP EN 343)) Date: Fri, 2 Oct 2009 16:25:48 +0200 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <4AC608B5.6010804@inex.ie> References: <4AC608B5.6010804@inex.ie> Message-ID: <5FD7A7EC774B114092B1603D69E42C9B02D079A0@BDKB1EEA.ww007.siemens.net> I can personally recommend SmartOptics. A norwegian company selling transeivers with cisco blueprint at low cost. http://www.smartoptics.com/ List price SFP, 1.25 Gbps Gigabit Ethernet, 1310nm, SM/MM, DDM, 20dB, 40km $533 compared to Cisco's $3995 for their ZX In the end their cisco/smartoptics/finisar is probably made on the same factory, so it's only a matter of company policy. You should though consider Cisco's third party policy before making your decision, http://www.cisco.com/en/US/prod/prod_warranty09186a00800b5594.html // Ulrich -----Oprindelig meddelelse----- Fra: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] P? vegne af Nick Hilliard Sendt: 2. oktober 2009 16:06 Til: cisco-nsp at puck.nether.net Emne: Re: [c-nsp] Will UDLD work with converters ? On 02/10/2009 14:36, Jeff Fitzwater wrote: > Is there any issues with running UDLD with TX to Fiber converters at > each end of a gig cisco to cisco link? We are just over the distance > budget with the 10KM optics. > > 6500 TX port--- to fiber converter--- 18KM fiber--- to converter--- back > to TX port on 3750. > > We are looking at the converters because the Cisco ZX optics are very > expensive and the converters with 30KM optics are much cheaper than the > 60 KM ZX optics. UDLD should be fine - it's just data packets, after all. So unless your media converters are doing something very strange and very wrong, it will be fine. You may want to look at third party optics from reputable manufacturers (e.g. http://www.finisar.com/optical_modules_2), although many organisations have policies in place which work against using third party components. Also, it is very easy to pick up grey optics with cisco serial numbers on them, which means that the special command which we all know about isn't necessary. Also, bear in mind that not all c65k ports support reading DDM info from SFPs. SUP720 cards will, as will later hardware revisions of the 6724sfp blades. Earlier hardware revisions won't. Also, 12.2SX >= SXF9 will not present DDM unless it sees a Cisco serial number. Nick _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From justin at justinshore.com Fri Oct 2 10:27:37 2009 From: justin at justinshore.com (Justin Shore) Date: Fri, 02 Oct 2009 09:27:37 -0500 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: References: Message-ID: <4AC60DD9.6080207@justinshore.com> Jeff Fitzwater wrote: > Is there any issues with running UDLD with TX to Fiber converters at > each end of a gig cisco to cisco link? We are just over the distance > budget with the 10KM optics. > > 6500 TX port--- to fiber converter--- 18KM fiber--- to converter--- back > to TX port on 3750. Should work fine. I'm doing the same thing over several back to back media converters with 80k optics. I'd love to replace the MCs with something better but otherwise UDLD works fine over them. > We are looking at the converters because the Cisco ZX optics are very > expensive and the converters with 30KM optics are much cheaper than the > 60 KM ZX optics. Agreed. This is on my list of major Cisco gripes. 10km is laughable in the SP world. Where are the 20k and 40k optics? Where are the 80k and 110k optics? Cabletron had 110k optics a decade ago. The single-strand Cisco GigE optic is limited to 10km too. Single-strand optics are critical in the SP world. Not everyone has excess bundles of dark fiber to play with to turn up a simple GigE link. I understand that Cisco wouldn't sell a lot of these since most of their business is enterprise. I get that. I would suggest that they pick a well-known and reliable SFP manufacturer like Champion and support their optics. Fill in the void with someone else's gear if you don't think the cost would justify the benefits of doing it yourself. There are other ways to do things besides doing it all in-house. Another major Cisco SFP gripe I have is that some BUs require optics that no other BU supports which makes common sparing across your product lines impossible. The ONSs require specific optics. The GLC- and SFP- that the switches and routers support don't work in ONS's LCs like the XPonder. We've found that the SFP- optics aren't supported in some switches with older code. DOM isn't universally supported so why pay for thee DOM optic when your switch or linecard doesn't support it. DWDM SFP support was added to some switches in the later 12.2(40+)SE releases such as 12.2(46)SE for the ME3750. However it wasn't added to all switches such as the 3560, 3750, or 2960 but it was added to the 3560/3750 E series. The beefy 4948s and monster 4900Ms are still out in the cold on DWDM support for SFPs too (I know that the 10G X2 optic supports DWDM). It seems to me that there should be a standards body within Cisco that should mandate certain minimum requirements of all product lines. If and when there is the ability for BUs and product lines to share common and trivial products like SFPs then they should require it. It would save them R&D and QA money if nothing else. Back to your question though, yes UDLD should work fine over MCs. Justin From drew.weaver at thenap.com Fri Oct 2 10:43:30 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 2 Oct 2009 10:43:30 -0400 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 Message-ID: Anyone deployed this monster yet? Have any wacky issues that were unexpected? -Drew From nick at inex.ie Fri Oct 2 10:44:01 2009 From: nick at inex.ie (Nick Hilliard) Date: Fri, 02 Oct 2009 15:44:01 +0100 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <4AC60D05.20003@complicity.co.uk> References: <4AC608B5.6010804@inex.ie> <4AC60D05.20003@complicity.co.uk> Message-ID: <4AC611B1.60509@inex.ie> On 02/10/2009 15:24, Zoe O'Connell wrote: > It's worth noting that while the restriction on optics in general is > just annoying, the DOM restrictions do seem to be there for a reason: I > have a number of non-Cisco optics reporting DOM data that's obviously > incorrect, so I don't trust anything that's non-Cisco. Sadly, on > platforms where it will show you DOM from any SFP, there's no obvious > indication if it's a Cisco or third party optic. "show idprom interface gig x/y" should give you a pretty good idea of what's plugged into the box (on a 65k). Yes, there are very poor quality transceivers out there. Cisco appears to re-sell Finisar and Opnext, which would suggest that these companies produce good quality kit. I'm personally not convinced that restricting equipment to use own-brand transceivers does much more than create a lucrative grey market for sophisticated knock-offs. I've also heard the incorrect DOM readings line being trotted out before, but I'm not convinced by it: if you buy cheap-ass equipment, you should expect high mileage variation. Nick From nick at inex.ie Fri Oct 2 11:14:56 2009 From: nick at inex.ie (Nick Hilliard) Date: Fri, 02 Oct 2009 16:14:56 +0100 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <4AC60DD9.6080207@justinshore.com> References: <4AC60DD9.6080207@justinshore.com> Message-ID: <4AC618F0.3000608@inex.ie> [100% agreed on rant. ghods, it is so depressing to fork out for cisco optics and find that they don't work on other cisco gear]. On 02/10/2009 15:27, Justin Shore wrote: > Back to your question though, yes UDLD should work fine over MCs. as someone else noted, only for optical transceivers. TX does not support UDLD (which was what the original poster was wondering about). Nick From moua0100 at umn.edu Fri Oct 2 11:18:23 2009 From: moua0100 at umn.edu (Ge Moua) Date: Fri, 02 Oct 2009 10:18:23 -0500 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: References: Message-ID: <4AC619BF.7040009@umn.edu> not a on Sup720 but deployed this with a Sup32 recently; still working with Cisco TAC on Norton Ghost muliticast causing OSPF to reset. Regards, Ge Moua | Email: moua0100 at umn.edu Network Design Engineer University of Minnesota | Networking & Telecommunications Services Drew Weaver wrote: > Anyone deployed this monster yet? Have any wacky issues that were unexpected? > > -Drew > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From drew.weaver at thenap.com Fri Oct 2 11:23:34 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 2 Oct 2009 11:23:34 -0400 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: <4AC619BF.7040009@umn.edu> References: <4AC619BF.7040009@umn.edu> Message-ID: That doesn't sound so friendly =) -----Original Message----- From: Ge Moua [mailto:moua0100 at umn.edu] Sent: Friday, October 02, 2009 11:18 AM To: Drew Weaver Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] SUP720 - 12.2(18)SXF17 not a on Sup720 but deployed this with a Sup32 recently; still working with Cisco TAC on Norton Ghost muliticast causing OSPF to reset. Regards, Ge Moua | Email: moua0100 at umn.edu Network Design Engineer University of Minnesota | Networking & Telecommunications Services Drew Weaver wrote: > Anyone deployed this monster yet? Have any wacky issues that were unexpected? > > -Drew > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From jfitz at Princeton.EDU Fri Oct 2 11:30:45 2009 From: jfitz at Princeton.EDU (Jeff Fitzwater) Date: Fri, 2 Oct 2009 11:30:45 -0400 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <4AC618F0.3000608@inex.ie> References: <4AC60DD9.6080207@justinshore.com> <4AC618F0.3000608@inex.ie> Message-ID: <1D2D5DF5-2D47-49C8-8490-0A3A1CB344D8@princeton.edu> Why do you say "TX does not support UDLD"? The doc and port configs support it. Am I missing something? Jeff On Oct 2, 2009, at 11:14 AM, Nick Hilliard wrote: > [100% agreed on rant. ghods, it is so depressing to fork out for > cisco optics and find that they don't work on other cisco gear]. > > On 02/10/2009 15:27, Justin Shore wrote: >> Back to your question though, yes UDLD should work fine over MCs. > > as someone else noted, only for optical transceivers. TX does not > support UDLD (which was what the original poster was wondering about). > > Nick > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From jfitz at Princeton.EDU Fri Oct 2 11:42:15 2009 From: jfitz at Princeton.EDU (Jeff Fitzwater) Date: Fri, 2 Oct 2009 11:42:15 -0400 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <1D2D5DF5-2D47-49C8-8490-0A3A1CB344D8@princeton.edu> References: <4AC60DD9.6080207@justinshore.com> <4AC618F0.3000608@inex.ie> <1D2D5DF5-2D47-49C8-8490-0A3A1CB344D8@princeton.edu> Message-ID: According to the doc if I am using a TX port the DEFAULT is UDLD DISABLED, so I have to enable it and also it states that I need to run in AGGRESSIVE MODE when using TX. I think I read that correct! Jeff On Oct 2, 2009, at 11:30 AM, Jeff Fitzwater wrote: > Why do you say "TX does not support UDLD"? The doc and port > configs support it. Am I missing something? > > > Jeff > On Oct 2, 2009, at 11:14 AM, Nick Hilliard wrote: > >> [100% agreed on rant. ghods, it is so depressing to fork out for >> cisco optics and find that they don't work on other cisco gear]. >> >> On 02/10/2009 15:27, Justin Shore wrote: >>> Back to your question though, yes UDLD should work fine over MCs. >> >> as someone else noted, only for optical transceivers. TX does not >> support UDLD (which was what the original poster was wondering >> about). >> >> Nick >> >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From md at bts.sk Fri Oct 2 11:45:54 2009 From: md at bts.sk (=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=) Date: Fri, 2 Oct 2009 17:45:54 +0200 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <4AC60D05.20003@complicity.co.uk> References: <4AC608B5.6010804@inex.ie> <4AC60D05.20003@complicity.co.uk> Message-ID: <20091002153109.M94491@bts.sk> On Fri, 02 Oct 2009 15:24:05 +0100, Zoe O'Connell wrote > Nick Hilliard wrote: > > Also, bear in mind that not all c65k ports support reading DDM info > > from SFPs. SUP720 cards will, as will later hardware revisions of the > > 6724sfp blades. *Beware*, in SXI train, there's again a nasty IOS lock on 6724 cards: >show inte gi 3/1 transceiver DOM is not supported on this linecard It's really odd that things that finally work as expected are again being disabled in software for no reason. > It's worth noting that while the restriction on optics in general is > just annoying, the DOM restrictions do seem to be there for a reason: I > have a number of non-Cisco optics reporting DOM data that's obviously > incorrect You get what you've paid for. If you're buying noname greymarket crap, DOM might be broken. With any decent SFP manufacturer, it works just fine. With kind regards, M. From rodunn at cisco.com Fri Oct 2 11:48:25 2009 From: rodunn at cisco.com (Rodney Dunn) Date: Fri, 02 Oct 2009 11:48:25 -0400 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: References: <4AC619BF.7040009@umn.edu> Message-ID: <4AC620C9.3060208@cisco.com> It's not set to TTL==1 is it? ;) That's the #1 issue we'd seen with that application and no TTL exceeded rate limiters configured. Rodney Drew Weaver wrote: > That doesn't sound so friendly =) > > -----Original Message----- > From: Ge Moua [mailto:moua0100 at umn.edu] > Sent: Friday, October 02, 2009 11:18 AM > To: Drew Weaver > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] SUP720 - 12.2(18)SXF17 > > not a on Sup720 but deployed this with a Sup32 recently; still working > with Cisco TAC on Norton Ghost muliticast causing OSPF to reset. > > Regards, > Ge Moua | Email: moua0100 at umn.edu > > Network Design Engineer > University of Minnesota | Networking & Telecommunications Services > > > > Drew Weaver wrote: >> Anyone deployed this monster yet? Have any wacky issues that were unexpected? >> >> -Drew >> >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From cchurc05 at harris.com Fri Oct 2 11:55:46 2009 From: cchurc05 at harris.com (Church, Charles) Date: Fri, 2 Oct 2009 11:55:46 -0400 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: References: <4AC60DD9.6080207@justinshore.com> <4AC618F0.3000608@inex.ie> <1D2D5DF5-2D47-49C8-8490-0A3A1CB344D8@princeton.edu> Message-ID: <290EF89F13F04F4E924BB235A46D18F1AF3A89@MLBMXUS2.cs.myharris.net> Definitely avoid aggressive mode with converters, unless you've got errdisable recovery timers enabled. Otherwise if you reload one side, the other side will stop receiving UDLD but it's link is still up (from the converter), so it'll errdisable the port. Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Fitzwater Sent: Friday, October 02, 2009 11:42 AM To: Jeff Fitzwater Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Will UDLD work with converters ? According to the doc if I am using a TX port the DEFAULT is UDLD DISABLED, so I have to enable it and also it states that I need to run in AGGRESSIVE MODE when using TX. I think I read that correct! Jeff On Oct 2, 2009, at 11:30 AM, Jeff Fitzwater wrote: > Why do you say "TX does not support UDLD"? The doc and port > configs support it. Am I missing something? > > > Jeff > On Oct 2, 2009, at 11:14 AM, Nick Hilliard wrote: > >> [100% agreed on rant. ghods, it is so depressing to fork out for >> cisco optics and find that they don't work on other cisco gear]. >> >> On 02/10/2009 15:27, Justin Shore wrote: >>> Back to your question though, yes UDLD should work fine over MCs. >> >> as someone else noted, only for optical transceivers. TX does not >> support UDLD (which was what the original poster was wondering >> about). >> >> Nick >> >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp at 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 at 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 at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From tdurack at gmail.com Fri Oct 2 11:59:44 2009 From: tdurack at gmail.com (Tim Durack) Date: Fri, 2 Oct 2009 11:59:44 -0400 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <4AC60DD9.6080207@justinshore.com> References: <4AC60DD9.6080207@justinshore.com> Message-ID: <9e246b4d0910020859u47997a28j20cc706044053432@mail.gmail.com> >> We are looking at the converters because the Cisco ZX optics are very >> expensive and the converters with 30KM optics are much cheaper than the 60 >> KM ZX optics. > > Agreed. ?This is on my list of major Cisco gripes. ?10km is laughable in the > SP world. ?Where are the 20k and 40k optics? ?Where are the 80k and 110k > optics? ?Cabletron had 110k optics a decade ago. > > The single-strand Cisco GigE optic is limited to 10km too. Single-strand > optics are critical in the SP world. ?Not everyone has excess bundles of > dark fiber to play with to turn up a simple GigE link. ?I understand that > Cisco wouldn't sell a lot of these since most of their business is > enterprise. ?I get that. ?I would suggest that they pick a well-known and > reliable SFP manufacturer like Champion and support their optics. ?Fill in > the void with someone else's gear if you don't think the cost would justify > the benefits of doing it yourself. There are other ways to do things besides > doing it all in-house. > > Another major Cisco SFP gripe I have is that some BUs require optics that no > other BU supports which makes common sparing across your product lines > impossible. ?The ONSs require specific optics. ?The GLC- and SFP- that the > switches and routers support don't work in ONS's LCs like the XPonder. > ?We've found that the SFP- optics aren't supported in some switches with > older code. ?DOM isn't universally supported so why pay for thee DOM optic > when your switch or linecard doesn't support it. DWDM SFP support was added > to some switches in the later 12.2(40+)SE releases such as 12.2(46)SE for > the ME3750. ?However it wasn't added to all switches such as the 3560, 3750, > or 2960 but it was added to the 3560/3750 E series. ?The beefy 4948s and > monster 4900Ms are still out in the cold on DWDM support for SFPs too (I > know that the 10G X2 optic supports DWDM). > > It seems to me that there should be a standards body within Cisco that > should mandate certain minimum requirements of all product lines. ?If and > when there is the ability for BUs and product lines to share common and > trivial products like SFPs then they should require it. ?It would save them > R&D and QA money if nothing else. > Without derailing this discussion, I think the support of "OEM" vs "Vendor" optics is a bigger issue. There are a number of switch vendors that refuse to support 3rd party optics, even if they are re-branding those same optics. The problem is margins are so high on optics, it is a major cash-cow for most switch vendors. I have had this discussion with switch vendor: they will not budge, giving all kinds of quality/support issues as the reason. It is possible to vote with your wallet, and only buy from vendors that support 3rd party. But at some point you get stuck needing to buy equipment from a vendor that doesn't support 3rd party. It seems to me that optics should be considered like parts for a car. If you want to install 3rd party, go ahead. Don't expect optics support from anybody but the 3rd party. But don't stop me from doing it either. Tim:> From gert at greenie.muc.de Fri Oct 2 12:01:56 2009 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 2 Oct 2009 18:01:56 +0200 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <4AC618F0.3000608@inex.ie> References: <4AC60DD9.6080207@justinshore.com> <4AC618F0.3000608@inex.ie> Message-ID: <20091002160156.GS1508@greenie.muc.de> Hi, On Fri, Oct 02, 2009 at 04:14:56PM +0100, Nick Hilliard wrote: > On 02/10/2009 15:27, Justin Shore wrote: > >Back to your question though, yes UDLD should work fine over MCs. > > as someone else noted, only for optical transceivers. TX does not support > UDLD (which was what the original poster was wondering about). Well, the "someone" was me, and my routers tell me I have no clue... :-) It seems that this was an older restriction on CatOS boxes, and I never even tried enabling it in "more recent" IOS versions - and indeed, it *does* work on copper ports in at least SXF13 and SXH3a. Cisco-M-XXI#sh udld g1/2 Interface Gi1/2 --- Port enable administrative configuration setting: Enabled Port enable operational state: Enabled Current bidirectional state: Bidirectional ... Cisco-M-XXI#sh int status Gi1/2 connected routed a-full a-1000 10/100/1000BaseT Mmmmh :-) (Not that this would usually be necessary, as GigE T autoneg would notice if the link isn't properly wired) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From bjohnson at drtel.com Fri Oct 2 11:30:01 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Fri, 2 Oct 2009 10:30:01 -0500 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: References: Message-ID: <29A54911243620478FF59F00EBB12F4701A60A37@ex01.drtel.lan> I don't believe you can do UDLD on TX (copper) interfaces. Even if you could, the MCs would make this not very useful. Generally speaking... make sure the MC does this for you. :) Brian Johnson Converged Network Engineer (CCNP, ENA) Dickey Rural Networks > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Jeff Fitzwater > Sent: Friday, October 02, 2009 8:36 AM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] Will UDLD work with converters ? > > Is there any issues with running UDLD with TX to Fiber converters at > each end of a gig cisco to cisco link? We are just over the distance > budget with the 10KM optics. > > 6500 TX port--- to fiber converter--- 18KM fiber--- to converter--- > back to TX port on 3750. > > We are looking at the converters because the Cisco ZX optics are very > expensive and the converters with 30KM optics are much cheaper than > the 60 KM ZX optics. > > Thanks in advance... > > > Jeff Fitzwater > OIT Network Systems > Princeton University > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From bacon at walleyesoftware.com Fri Oct 2 12:44:06 2009 From: bacon at walleyesoftware.com (Jeff Bacon) Date: Fri, 2 Oct 2009 11:44:06 -0500 Subject: [c-nsp] DWDM optics on 6500s Message-ID: <5A69C25361FED34F83ABF05F50475245072BC0C6@wally.walleyetrading.net> I am looking at getting some metro waves (mostly 20-40km) between sites; I'm working with a provider who is using passive splitters on dark runs and they're willing to split me out a wave for near the same cost as just running a gig switched. Currently, I am thinking of using a 6704 blade with a DFC3B (I'm using sup7203Bs - no call for the C model in my environ) and buying tuned optics. The goal is primarily serialization latency delay reduction, not actually running 10G of traffic - I'll be lucky to run 1-2GB (though it'll mostly be 60-100byte packets). 1) The cisco optics appear to be in short supply and damn expensive. I may have to go third-party. I know it's a gamble. Any other issues I Should think about besides what's been discussed here? 2) Is XENPAK on 6704 viable? Any gotchas I should know about with XENPAKs vs X2? 3) Does 6500 switching performance blow super-hard, or just so-so hard? (6-15us is ok.) Yes a 4900M might be faster, or a J-product, but I don't want to change platform really, I need NAT and don't want to use routers, I want to keep box count down (co-lo), and having a whole box just for passing 10G doesn't IMO make sense because I'd still have to get it into the 6500 anyway. 4) What's reliability on the tuned optics (vs say using a freq-shift box with a normal 10G optic)? Is this of the level that I should expect significant BER, or keep a spare on the shelf, or is it pretty much rock-solid? As you might guess, this is my first foray into actually implementing DWDM runs - I've studied it and planned it, but this is now at the "buy stuff" level, and I don't want to assume I know everything. Relevant document pointers appreciated. Thanks, -bacon From justin at justinshore.com Fri Oct 2 12:47:11 2009 From: justin at justinshore.com (Justin Shore) Date: Fri, 02 Oct 2009 11:47:11 -0500 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <4AC618F0.3000608@inex.ie> References: <4AC60DD9.6080207@justinshore.com> <4AC618F0.3000608@inex.ie> Message-ID: <4AC62E8F.1070503@justinshore.com> Nick Hilliard wrote: > [100% agreed on rant. ghods, it is so depressing to fork out for cisco > optics and find that they don't work on other cisco gear]. Yeah, it's awful. We're looking at ONSs right now and are faced with the penalty (I think that's the appropriate word) of having to spare a completely unique set of GigE optics just for the ONSs. I can understand to a degree Cisco only supporting Cisco optics but not even all of Cisco supports all of Cisco's optics. That's the worst part about it. > On 02/10/2009 15:27, Justin Shore wrote: >> Back to your question though, yes UDLD should work fine over MCs. > > as someone else noted, only for optical transceivers. TX does not > support UDLD (which was what the original poster was wondering about). I saw that as well and that's curious because I'm doing it today on TX interfaces. Been doing it for years and it works great. It's even served it's purpose on one occasion when a 80k single-strand optic in a series of back to back MCs partially failed and was transmitting but not receiving. Locating the 1 bad optic was a PITA but at least it brought the link down so my alternate routing paths picked up the load with minimal loss. 7613-1.clr#sh int gi9/9 capabilities GigabitEthernet9/9 Model: WS-X6748-GE-TX Type: 10/100/1000BaseT Speed: 10,100,1000,auto Duplex: half,full Trunk encap. type: 802.1Q,ISL Trunk mode: on,off,desirable,nonegotiate Channel: yes Broadcast suppression: percentage(0-100) Flowcontrol: rx-(off,on,desired),tx-(off,on,desired) Membership: static Fast Start: yes QOS scheduling: rx-(2q8t), tx-(1p3q8t) CoS rewrite: yes ToS rewrite: yes Inline power: no SPAN: source/destination UDLD yes Link Debounce: yes Link Debounce Time: no Ports on ASIC: 1-12 Port-Security: yes 7613-1.clr#sh udld neighbors Port Device Name Device ID Port ID Neighbor State ---- ----------- --------- ------- -------------- Gi9/9 0169D2180B4 1 Gi1/1 Bidirectional Gi9/9.40 0169D2180B4 1 Gi1/1 Bidirectional 6524-1.brd#sh int gi1/1 capabilities GigabitEthernet1/1 Model: ME-C6524GT-8S Type: 10/100/1000BaseT Speed: 10,100,1000,auto Duplex: half,full Trunk encap. type: 802.1Q,ISL Trunk mode: on,off,desirable,nonegotiate Channel: yes Broadcast suppression: none Flowcontrol: rx-(off,on,desired),tx-(off,on,desired) Membership: static Fast Start: yes QOS scheduling: rx-(1q2t), tx-(1p3q8t) QOS queueing mode: rx-(cos), tx-(cos) CoS rewrite: yes ToS rewrite: yes Inline power: no Inline power policing: no SPAN: source/destination UDLD yes Link Debounce: yes Link Debounce Time: no Ports on ASIC: 1-12 Remote switch uplink: no Dot1x: yes Port-Security: yes 6524-1.brd#sh udld neighbors Port Device Name Device ID Port ID Neighbor State ---- ----------- --------- ------- -------------- Gi1/1 0187425650 1 Gi9/9 Bidirectional Gi1/1.4010 0187425650 1 Gi9/9 Bidirectional Perhaps TX UDLD is only available on certain platforms. Justin From gert at greenie.muc.de Fri Oct 2 13:08:53 2009 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 2 Oct 2009 19:08:53 +0200 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <4AC62E8F.1070503@justinshore.com> References: <4AC60DD9.6080207@justinshore.com> <4AC618F0.3000608@inex.ie> <4AC62E8F.1070503@justinshore.com> Message-ID: <20091002170853.GT1508@greenie.muc.de> Hi, On Fri, Oct 02, 2009 at 11:47:11AM -0500, Justin Shore wrote: > understand to a degree Cisco only supporting Cisco optics but not even > all of Cisco supports all of Cisco's optics. That's the worst part > about it. There's no "all of Cisco". There's competing BUs. If you buy switch BU SFPs, the ONS BU won't get money. Can't have that. (The amazing part is that not even the stock market seems to think that this is a good strategy - it *does* increase revenue, though, until enough customers are annoyed enough to find other vendors) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From nick at inex.ie Fri Oct 2 13:19:22 2009 From: nick at inex.ie (Nick Hilliard) Date: Fri, 02 Oct 2009 18:19:22 +0100 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC0C6@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC0C6@wally.walleyetrading.net> Message-ID: <4AC6361A.9040807@inex.ie> On 02/10/2009 17:44, Jeff Bacon wrote: > I am looking at getting some metro waves (mostly 20-40km) between sites; > I'm working with a provider who is using passive splitters on dark runs > and they're willing to split me out a wave for near the same cost as > just running a gig switched. I went through this some while back, and on the basis that: - coloured xenpaks are exotic, expensive and only produced by a single manufacturer in the world (opnext, as you ask) - coloured xenpaks will only last as long as your 6704 card, meaning that when you retire this kit, your entire coloured optics investment is lost - transponders were not hugely more expensive than the prices I was quoted for cisco coloured optics ... I decided that coloured xenpaks, while marginally cheaper in the short term, were actually a bad strategic move in the long term. Given the way that our network has changed since we made that decision, it turns out that it was a good decision to make, as we're completely flexible about what kit we use at each end of the link, and have chosen to exercise that flexibility. There is also a much better selection of coloured XFPs on the market than coloured xenpak. > The goal is primarily serialization latency delay reduction, not > actually running 10G of traffic - I'll be lucky to run 1-2GB (though > it'll mostly be 60-100byte packets). If you want to cut delay for switching, you may want to consider the new top-of-rack 10G boxes, which are typically cut-through. You may find that these boxes + SR SFP+ + wdm transponders is quite cost favourable compared to c6500 chassis space + 6704 + coloured xenpak. Cisco N5K may be a good option here. But other vendors have similar style boxes (Brocade Ti24X, Extreme X650, F10 S2410, Arista Networks *.*, etc). Oh, and the SFP+ boxes will also run 1G ethernet on SFPs (although the N2K has some limitations). This is a nice feature win. > 1) The cisco optics appear to be in short supply and damn expensive. I > may have to go third-party. I know it's a gamble. Any other issues I > Should think about besides what's been discussed here? coloured xenpaks are a single vendor product and I have heard that they are mostly made to order, hence the delay. > 2) Is XENPAK on 6704 viable? Any gotchas I should know about with > XENPAKs vs X2? X2 == xenpak version 2. Their power draw is slightly less than xenpak, but lots more than xfp / sfp+. Only HP and Cisco use X2 for ethernet switches - everyone else uses XFP and latterly SFP+, which means that there is less pricing pressure and and more vendor lock-in if you go down the X2 route. Personally, I have a bit of a thing against X2, but that's just me. Make your own mind up. > 3) Does 6500 switching performance blow super-hard, or just so-so hard? > (6-15us is ok.) Yes a 4900M might be faster, or a J-product, but I don't > want to change platform really, I need NAT and don't want to use > routers, I want to keep box count down (co-lo), and having a whole box > just for passing 10G doesn't IMO make sense because I'd still have to > get it into the 6500 anyway. The 6500 is a great 1G switch platform, but doesn't excel in the 10G range, particularly with 6704 blades. Nick From petelists at templin.org Fri Oct 2 12:33:29 2009 From: petelists at templin.org (Pete Templin) Date: Fri, 02 Oct 2009 11:33:29 -0500 Subject: [c-nsp] Route reflection - need second set(s) of eyes please Message-ID: <4AC62B59.2030105@templin.org> All, I'm trying to figure out some unexpected behavior relating to route reflection. First, a diagram: RAS/A1---Dist/A1---Core/A1---Core/B1---Dist/B1---RAS/B1 (City A and City B, one device of each type represented) All routers shown above are in the same ASN. As currently configured, the cores are fully-meshed. The dists are neighbored with the cores, and the dists are route reflector clients of the cores (I guess from a configuration perspective, the cores see the dists as route reflector clients). The dists are neighbored with the RASen, but the RASen are not currently considered route reflector clients. To the best of my knowledge, since the dists aren't configured to treat the RASen as route reflector clients, they shouldn't be passing the RAS routes along to the core (who would then reflect them to the other city's core, who would then reflect them to that city's dists). However, it appears that the RAS routes are making it across the network. Should I be confused? Should I be configuring the dists to treat the RASen as RRC, to avoid future surprises? Thanks, Pete From tvarriale at comcast.net Fri Oct 2 14:10:26 2009 From: tvarriale at comcast.net (Tony Varriale) Date: Fri, 2 Oct 2009 13:10:26 -0500 Subject: [c-nsp] Route reflection - need second set(s) of eyes please References: <4AC62B59.2030105@templin.org> Message-ID: <6A377A2D070A452897D1A434BFD6908B@flamdt01> I assume RAS is traditional dial in? And I assume when you say "RAS routes" you mean /32s or more specifics than you would like? tv ----- Original Message ----- From: "Pete Templin" To: "Cisco Nsp" Sent: Friday, October 02, 2009 11:33 AM Subject: [c-nsp] Route reflection - need second set(s) of eyes please > All, > > I'm trying to figure out some unexpected behavior relating to route > reflection. First, a diagram: > > RAS/A1---Dist/A1---Core/A1---Core/B1---Dist/B1---RAS/B1 > > (City A and City B, one device of each type represented) > > All routers shown above are in the same ASN. As currently configured, the > cores are fully-meshed. The dists are neighbored with the cores, and the > dists are route reflector clients of the cores (I guess from a > configuration perspective, the cores see the dists as route reflector > clients). The dists are neighbored with the RASen, but the RASen are not > currently considered route reflector clients. > > To the best of my knowledge, since the dists aren't configured to treat > the RASen as route reflector clients, they shouldn't be passing the RAS > routes along to the core (who would then reflect them to the other city's > core, who would then reflect them to that city's dists). However, it > appears that the RAS routes are making it across the network. > > Should I be confused? Should I be configuring the dists to treat the > RASen as RRC, to avoid future surprises? > > Thanks, > > Pete > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From drew.weaver at thenap.com Fri Oct 2 14:28:05 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 2 Oct 2009 14:28:05 -0400 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: <4AC620C9.3060208@cisco.com> References: <4AC619BF.7040009@umn.edu> <4AC620C9.3060208@cisco.com> Message-ID: That whole TTL exceeded thing is a real problem these days, huh? -----Original Message----- From: Rodney Dunn [mailto:rodunn at cisco.com] Sent: Friday, October 02, 2009 11:48 AM To: Drew Weaver Cc: 'moua0100 at umn.edu'; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] SUP720 - 12.2(18)SXF17 It's not set to TTL==1 is it? ;) That's the #1 issue we'd seen with that application and no TTL exceeded rate limiters configured. Rodney Drew Weaver wrote: > That doesn't sound so friendly =) > > -----Original Message----- > From: Ge Moua [mailto:moua0100 at umn.edu] > Sent: Friday, October 02, 2009 11:18 AM > To: Drew Weaver > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] SUP720 - 12.2(18)SXF17 > > not a on Sup720 but deployed this with a Sup32 recently; still working > with Cisco TAC on Norton Ghost muliticast causing OSPF to reset. > > Regards, > Ge Moua | Email: moua0100 at umn.edu > > Network Design Engineer > University of Minnesota | Networking & Telecommunications Services > > > > Drew Weaver wrote: >> Anyone deployed this monster yet? Have any wacky issues that were unexpected? >> >> -Drew >> >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From gsgranados at comcast.net Fri Oct 2 16:31:47 2009 From: gsgranados at comcast.net (Scott Granados) Date: Fri, 2 Oct 2009 13:31:47 -0700 Subject: [c-nsp] which version of asdm to use with the asa 5520?? Message-ID: <019601ca439f$6153e6b0$0202fea9@am.thmulti.com> Hi all, I'm in the process of updating a pair of ASA 5520S from 7.0.7 to 7.2.4-33. I have the intermediate 7.1x release that I'll switch to in the middle but not sure what to do with the asdm code. What version should I use? It wasn't obvious to me on the Cisco site, how do I tell which version goes with a specific firmware release? Any pointers would be appreciated. Thank you Scott From rwest at zyedge.com Fri Oct 2 16:43:01 2009 From: rwest at zyedge.com (Ryan West) Date: Fri, 2 Oct 2009 16:43:01 -0400 Subject: [c-nsp] which version of asdm to use with the asa 5520?? In-Reply-To: <019601ca439f$6153e6b0$0202fea9@am.thmulti.com> References: <019601ca439f$6153e6b0$0202fea9@am.thmulti.com> Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F99FB@zy-ex1.zyedge.local> Hey Scott, Under the 7.2 line, I would use the latest interim release of the 5.2.4 ASDM. In this case it would be interim release 56 -> http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=cisco/crypto/3DES/ciscosecure/asa/interim/asdm-52456.bin&app=Tablebuild&status=showC2A -ryan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados Sent: Friday, October 02, 2009 4:32 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] which version of asdm to use with the asa 5520?? Hi all, I'm in the process of updating a pair of ASA 5520S from 7.0.7 to 7.2.4-33. I have the intermediate 7.1x release that I'll switch to in the middle but not sure what to do with the asdm code. What version should I use? It wasn't obvious to me on the Cisco site, how do I tell which version goes with a specific firmware release? Any pointers would be appreciated. Thank you Scott _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From gsgranados at comcast.net Fri Oct 2 16:46:37 2009 From: gsgranados at comcast.net (Scott Granados) Date: Fri, 2 Oct 2009 13:46:37 -0700 Subject: [c-nsp] which version of asdm to use with the asa 5520?? References: <019601ca439f$6153e6b0$0202fea9@am.thmulti.com> <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F99FB@zy-ex1.zyedge.local> Message-ID: <01d901ca43a1$74ec9da0$0202fea9@am.thmulti.com> Do I need a midway point one to use for the brief period I'm on 7.1 or just update this once? Thank you Scott ----- Original Message ----- From: "Ryan West" To: "Scott Granados" ; Sent: Friday, October 02, 2009 1:43 PM Subject: RE: [c-nsp] which version of asdm to use with the asa 5520?? Hey Scott, Under the 7.2 line, I would use the latest interim release of the 5.2.4 ASDM. In this case it would be interim release 56 -> http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=cisco/crypto/3DES/ciscosecure/asa/interim/asdm-52456.bin&app=Tablebuild&status=showC2A -ryan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados Sent: Friday, October 02, 2009 4:32 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] which version of asdm to use with the asa 5520?? Hi all, I'm in the process of updating a pair of ASA 5520S from 7.0.7 to 7.2.4-33. I have the intermediate 7.1x release that I'll switch to in the middle but not sure what to do with the asdm code. What version should I use? It wasn't obvious to me on the Cisco site, how do I tell which version goes with a specific firmware release? Any pointers would be appreciated. Thank you Scott _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From rwest at zyedge.com Fri Oct 2 16:47:12 2009 From: rwest at zyedge.com (Ryan West) Date: Fri, 2 Oct 2009 16:47:12 -0400 Subject: [c-nsp] which version of asdm to use with the asa 5520?? In-Reply-To: <01d901ca43a1$74ec9da0$0202fea9@am.thmulti.com> References: <019601ca439f$6153e6b0$0202fea9@am.thmulti.com> <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F99FB@zy-ex1.zyedge.local> <01d901ca43a1$74ec9da0$0202fea9@am.thmulti.com> Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F99FE@zy-ex1.zyedge.local> Assuming you're upgrading from CLI, no. Worst case scenario, you'll get a message saying the version is too old. -ryan -----Original Message----- From: Scott Granados [mailto:gsgranados at comcast.net] Sent: Friday, October 02, 2009 4:47 PM To: Ryan West; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] which version of asdm to use with the asa 5520?? Do I need a midway point one to use for the brief period I'm on 7.1 or just update this once? Thank you Scott ----- Original Message ----- From: "Ryan West" To: "Scott Granados" ; Sent: Friday, October 02, 2009 1:43 PM Subject: RE: [c-nsp] which version of asdm to use with the asa 5520?? Hey Scott, Under the 7.2 line, I would use the latest interim release of the 5.2.4 ASDM. In this case it would be interim release 56 -> http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=cisco/crypto/3DES/ciscosecure/asa/interim/asdm-52456.bin&app=Tablebuild&status=showC2A -ryan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados Sent: Friday, October 02, 2009 4:32 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] which version of asdm to use with the asa 5520?? Hi all, I'm in the process of updating a pair of ASA 5520S from 7.0.7 to 7.2.4-33. I have the intermediate 7.1x release that I'll switch to in the middle but not sure what to do with the asdm code. What version should I use? It wasn't obvious to me on the Cisco site, how do I tell which version goes with a specific firmware release? Any pointers would be appreciated. Thank you Scott _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From gsgranados at comcast.net Fri Oct 2 16:50:59 2009 From: gsgranados at comcast.net (Scott Granados) Date: Fri, 2 Oct 2009 13:50:59 -0700 Subject: [c-nsp] which version of asdm to use with the asa 5520?? References: <019601ca439f$6153e6b0$0202fea9@am.thmulti.com> <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F99FB@zy-ex1.zyedge.local> <01d901ca43a1$74ec9da0$0202fea9@am.thmulti.com> <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F99FE@zy-ex1.zyedge.local> Message-ID: <01f901ca43a2$11697f90$0202fea9@am.thmulti.com> Cool, thanks! I don't use the asdm anyway but wanted to be complete. Thanks for the great pointers as always! Scott ----- Original Message ----- From: "Ryan West" To: "Scott Granados" ; Sent: Friday, October 02, 2009 1:47 PM Subject: RE: [c-nsp] which version of asdm to use with the asa 5520?? Assuming you're upgrading from CLI, no. Worst case scenario, you'll get a message saying the version is too old. -ryan -----Original Message----- From: Scott Granados [mailto:gsgranados at comcast.net] Sent: Friday, October 02, 2009 4:47 PM To: Ryan West; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] which version of asdm to use with the asa 5520?? Do I need a midway point one to use for the brief period I'm on 7.1 or just update this once? Thank you Scott ----- Original Message ----- From: "Ryan West" To: "Scott Granados" ; Sent: Friday, October 02, 2009 1:43 PM Subject: RE: [c-nsp] which version of asdm to use with the asa 5520?? Hey Scott, Under the 7.2 line, I would use the latest interim release of the 5.2.4 ASDM. In this case it would be interim release 56 -> http://www.cisco.com/cgi-bin/Software/Tablebuild/doftp.pl?ftpfile=cisco/crypto/3DES/ciscosecure/asa/interim/asdm-52456.bin&app=Tablebuild&status=showC2A -ryan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados Sent: Friday, October 02, 2009 4:32 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] which version of asdm to use with the asa 5520?? Hi all, I'm in the process of updating a pair of ASA 5520S from 7.0.7 to 7.2.4-33. I have the intermediate 7.1x release that I'll switch to in the middle but not sure what to do with the asdm code. What version should I use? It wasn't obvious to me on the Cisco site, how do I tell which version goes with a specific firmware release? Any pointers would be appreciated. Thank you Scott _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From nicholas.hatch at gmail.com Fri Oct 2 17:03:06 2009 From: nicholas.hatch at gmail.com (nick hatch) Date: Fri, 2 Oct 2009 14:03:06 -0700 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <4AC60DD9.6080207@justinshore.com> References: <4AC60DD9.6080207@justinshore.com> Message-ID: On Fri, Oct 2, 2009 at 7:27 AM, Justin Shore wrote: > > The single-strand Cisco GigE optic is limited to 10km too. Single-strand > optics are critical in the SP world. Not everyone has excess bundles of > dark fiber to play with to turn up a simple GigE link. I understand that > Cisco wouldn't sell a lot of these since most of their business is > enterprise. I get that. > I get that too, but I strongly disagree with the strategy. In this part of the world (Whatcom/Skagit county, Washington state), dark fiber is cheap and readily available for about the cost of a T1 in many locations. (If buildout is required, it's often subsidized into the MRC.) My network at $dayjob is hardly big enough to be considered enterprise (our fanciest piece of kit is a 3560), yet for branch locations we still have the need to use unsupported 70km and single-strand optics. Surely the world has other communities like this, with cheap plentiful fiber? $4k for a ZX transceiver with the right logo on it is laughable. -Nick From eng_mssk at hotmail.com Fri Oct 2 17:24:10 2009 From: eng_mssk at hotmail.com (Mohammad Khalil) Date: Sat, 3 Oct 2009 00:24:10 +0300 Subject: [c-nsp] facebook related In-Reply-To: <4AC51C87.7040608@cisco.com> References: <20091001200616.GK9785@1-4-5.net> <4AC51C87.7040608@cisco.com> Message-ID: poke mike Request time out Request time out > Date: Thu, 1 Oct 2009 17:17:59 -0400 > From: mcaudill at cisco.com > To: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] facebook related > > On 10/1/09 4:06 PM, Tony Tauber wrote: > > Aww. I thought this was going to introduce the Facebook app > > "IOS Upgrade Manager" which enables you to navigate www.cisco.com by > > using Facebook. Answer burning questions like : > > "If your friends were IOS software, which train/version would they be?" > > Or games like "Two of your friends configured EIGRP using Protocol Wars". > > > > Well, there's still hope for the future. > > > > Tony > > > > BGP peering or CDP via facebook: > > You have 2 peer/neighbor requests: > > Cisco7206 -- 8 peers [Confirm] [Ignore] > C3750 -- 40 neighbors [Confirm] [Ignore] > > You could even use it for network management. > > > My network device friends on Facebook: > > Forwarding breakdown: 36% layer 3 / 64% layer 2 > Geographic distribution: 190 countries, 50 states > Protocol preference: 100% IPv4, 37% IPv6 > Relationship status: connected. > Favorite IOS version: 12.4T > > etc. > > Too funny... > > -Mike- > > -- > > Mike Caudill > PSIRT Incident Manager > DSS PGP: 0xEBBD5271 > +1.919.392.2855 / +1.919.522.4931 (cell) > http://www.cisco.com/go/psirt > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _________________________________________________________________ Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail?. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009 From justin at justinshore.com Fri Oct 2 21:21:06 2009 From: justin at justinshore.com (Justin Shore) Date: Fri, 02 Oct 2009 20:21:06 -0500 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: References: <4AC60DD9.6080207@justinshore.com> Message-ID: <4AC6A702.6010302@justinshore.com> nick hatch wrote: > I get that too, but I strongly disagree with the strategy. In this part > of the world (Whatcom/Skagit county, Washington state), dark fiber is > cheap and readily available for about the cost of a T1 in many > locations. (If buildout is required, it's often subsidized into the MRC.) Unfortunately where I'm at in the Midwest there is no dark fiber to be had. None of the large local LECs are willing to even carry a wavelength for a customer. There simply isn't anyone in the areas that I'm located to in offering wavelengths or dark fiber as a product to force the other players to compete. Now in KC, Denver, Lincoln or OKC it's different story. There are enough people willing to do it there that the other LECs have all fallen into step and also offer the service. Many are the very same LECs that refuse to do so here. > My network at $dayjob is hardly big enough to be considered enterprise > (our fanciest piece of kit is a 3560), yet for branch locations we still > have the need to use unsupported 70km and single-strand optics. I'd love to have the potential to lease dark fiber like that. It would make my life much easier. > Surely the world has other communities like this, with cheap plentiful > fiber? $4k for a ZX transceiver with the right logo on it is laughable. It depends on the market but it's not available everywhere. Forbes rated a city 15m away from our HQ (and one of the towns we CLECed) in the top 10 of IT meccas in the US and yet it's still not possible there. Go figure. The state independent telcos are working together to build a state fiber network to provide low-cost transport across the state, like what they did in Indiana and Texas. It's a few years out though. Justin From andy.saykao at staff.netspace.net.au Sat Oct 3 00:53:42 2009 From: andy.saykao at staff.netspace.net.au (Andy Saykao) Date: Sat, 3 Oct 2009 14:53:42 +1000 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 References: Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AACFC@vic-cr-ex1.staff.netspace.net.au> We went to 12.2(18)SXF16 and got burnt by a nat bug (BUG id CSCed60335) that caused our router to continually reboot. Had to down grade back to 12.2(18)SXF11. Not sure if the nat bug has been fixed in 12.2(18)SXF17 yet. Cheers. Andy This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the organisation. Finally, the recipient should check this email and any attachments for the presence of viruses. The organisation accepts no liability for any damage caused by any virus transmitted by this email. From baard at dahlmo.no Sat Oct 3 02:59:18 2009 From: baard at dahlmo.no (=?ISO-8859-15?Q?B=E5rd_Dahlmo?=) Date: Sat, 3 Oct 2009 08:59:18 +0200 (CEST) Subject: [c-nsp] facebook related In-Reply-To: <20091001200616.GK9785@1-4-5.net> References: <20091001200616.GK9785@1-4-5.net> Message-ID: On Thu, 1 Oct 2009, Tony Tauber wrote: > Aww. I thought this was going to introduce the Facebook app > "IOS Upgrade Manager" which enables you to navigate www.cisco.com by > using Facebook. Answer burning questions like : > "If your friends were IOS software, which train/version would they be?" > Or games like "Two of your friends configured EIGRP using Protocol Wars". There's always an implementation of RFC 5514 you can play with, http://tools.ietf.org/html/rfc5514 There you can route ipv6 packets using your friends as routers. -- B?rd Dahlmo From uvh at siemens.com Sat Oct 3 05:19:55 2009 From: uvh at siemens.com (Hansen, Ulrich Vestergaard B. (E R WP EN 343)) Date: Sat, 3 Oct 2009 11:19:55 +0200 Subject: [c-nsp] Smartnet pricing? In-Reply-To: <4AC1CBF7.5060600@harg.net> References: <01d401ca407d$f1797900$d46c6b00$@com> <4AC19BE5.7040506@gmx.de><4AC1A18A.5030900@pantheranet.com> <4AC1CBF7.5060600@harg.net> Message-ID: <5FD7A7EC774B114092B1603D69E42C9B02D079E3@BDKB1EEA.ww007.siemens.net> Does this 'SASU' contract apply to hardware and IOS Upgrades? -----Oprindelig meddelelse----- Fra: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] P? vegne af Will Hargrave Sendt: 29. september 2009 10:57 Cc: 'Cisco-NSP Mailing List' Emne: Re: [c-nsp] Smartnet pricing? Steven Saner wrote: > Is this really available? I was asking a SmartNet rep about this once > and was led to believe this isn't an option. Maybe it wasn't then and is > now? Maybe they were pulling my leg? 'SASU' - Software Application Support plus Upgrades But last time I priced it up I got the same price for that as 8x5xNBD hardware support, which was disappointing. OP could go to a third party for support rather than Cisco, which should reduce the cost yet still allow legitimate access to newer IOS. _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From p.mayers at imperial.ac.uk Sat Oct 3 08:14:47 2009 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Sat, 03 Oct 2009 13:14:47 +0100 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: References: <4AC619BF.7040009@umn.edu> <4AC620C9.3060208@cisco.com> Message-ID: <4AC74037.3050408@imperial.ac.uk> Drew Weaver wrote: > That whole TTL exceeded thing is a real problem these days, huh? When you have an application as badly-written as ghost (seriously: it's awful, awful, awful stuff) then it could probably find a way to break the network regardless. But yes, splurging a 30gig hard-disk image out over multicast with TTL=1 on the packets will definitely cause TTL-exceeded problems ;o) From mtinka at globaltransit.net Sat Oct 3 08:18:53 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Sat, 3 Oct 2009 20:18:53 +0800 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <20091002141556.GR1508@greenie.muc.de> References: <20091002141556.GR1508@greenie.muc.de> Message-ID: <200910032018.54836.mtinka@globaltransit.net> On Friday 02 October 2009 10:15:56 pm Gert Doering wrote: > We'd stay away from converters, and better get 3rd-party > ZX optics instead. Agree. We've seen strange issues with converters were providers were unable to guarantee Jumbo frame MTU sizes because the media converters don't support them - what the hell... Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From mtinka at globaltransit.net Sat Oct 3 08:19:23 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Sat, 3 Oct 2009 20:19:23 +0800 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <4AC60DD9.6080207@justinshore.com> References: <4AC60DD9.6080207@justinshore.com> Message-ID: <200910032019.24083.mtinka@globaltransit.net> On Friday 02 October 2009 10:27:37 pm Justin Shore wrote: > It seems to me that there should be a standards body > within Cisco that should mandate certain minimum > requirements of all product lines. If and when there is > the ability for BUs and product lines to share common and > trivial products like SFPs then they should require it. > It would save them R&D and QA money if nothing else. This is the thing I really like about "J". Across a specific series of platforms, e.g., M/T/MX, all optics are shared, including SFP-to-copper modules. It's a real pity when you can no longer take such simple pleasures for granted. I think Cisco's SPA technology is a step in the right direction re: optical modules, since they're all shared among the various platforms that support this interface model, but I wonder how many of Cisco's customers will be moving to the SIP/SPA format soon (and it likely won't be because of common SFP/XFP sparing). Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From ml at kenweb.org Sat Oct 3 08:38:33 2009 From: ml at kenweb.org (ML) Date: Sat, 03 Oct 2009 08:38:33 -0400 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AACFC@vic-cr-ex1.staff.netspace.net.au> References: <56F211C5E3F24F47B103EA1B253822BE044AACFC@vic-cr-ex1.staff.netspace.net.au> Message-ID: <4AC745C9.2090908@kenweb.org> Andy Saykao wrote: > We went to 12.2(18)SXF16 and got burnt by a nat bug (BUG id CSCed60335) > that caused our router to continually reboot. Had to down grade back to > 12.2(18)SXF11. Not sure if the nat bug has been fixed in 12.2(18)SXF17 > yet. > > Cheers. > > Andy > > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > Please notify the sender immediately by email if you have received this > email by mistake and delete this email from your system. Please note that > any views or opinions presented in this email are solely those of the > author and do not necessarily represent those of the organisation. > Finally, the recipient should check this email and any attachments for > the presence of viruses. The organisation accepts no liability for any > damage caused by any virus transmitted by this email. > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ We were hit by the same bug. TAC said it would be fixed in 12.2(18)SXF17. From mtinka at globaltransit.net Sat Oct 3 08:43:55 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Sat, 3 Oct 2009 20:43:55 +0800 Subject: [c-nsp] Route reflection - need second set(s) of eyes please In-Reply-To: <4AC62B59.2030105@templin.org> References: <4AC62B59.2030105@templin.org> Message-ID: <200910032044.03359.mtinka@globaltransit.net> On Saturday 03 October 2009 12:33:29 am Pete Templin wrote: > The > dists are neighbored with the cores, and the dists are > route reflector clients of the cores (I guess from a > configuration perspective, the cores see the dists as > route reflector clients). Not necessarily, unless you've configured the "Distribution" routers as such. > The dists are neighbored with > the RASen, but the RASen are not currently considered > route reflector clients. Okay... > To the best of my knowledge, since the dists aren't > configured to treat the RASen as route reflector clients, > they shouldn't be passing the RAS routes along to the > core (who would then reflect them to the other city's > core, who would then reflect them to that city's dists). > However, it appears that the RAS routes are making it > across the network. Can you dump a copy of your BGP configuration from all these routers? > Should I be confused? Should I be configuring the dists > to treat the RASen as RRC, to avoid future surprises? Ideally, centralizing the route reflector function would be best, i.e., if you core routers are running that function, then have your routers run iBGP with your core routers. However, this may be moot if the ASCII diagram you sent through is your actual topology, i.e., your RAS's have a single link to your "Distribution" routers. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From vijay.ramcharan at verizonbusiness.com Sat Oct 3 10:58:04 2009 From: vijay.ramcharan at verizonbusiness.com (Ramcharan, Vijay A) Date: Sat, 03 Oct 2009 14:58:04 +0000 Subject: [c-nsp] OT: Juniper JTAC software download assistance - blown away by good customer service In-Reply-To: <200910032044.03359.mtinka@globaltransit.net> Message-ID: <8171C8272CE8FE4A8F5BFF8A97CE6AB301A78258@ASHEVS006.mcilink.com> Like most other folks these days, I'm somewhat jaded when it comes to expecting customer requests that fall outside of the normal spectrum of issues to be handled in the manner you'd hope. This is not a plug by any means for Juniper but I do want to give credit where I believe it's due. Having just come off the Cisco SP train, I decided that what better way to build upon that than by learning about what is outside of Cisco-land. I purchased a couple of low-end J series routers off Ebay. The software release on them was quite old I belive, at 7.x. While I probably could have used that release I decided to try opening an account with Juniper to see how far I could get before having to fork out a couple thousand for a new device with a current support contract. After getting my account set up, I opened a case to request access to software downloads; not with much hope of getting it added to my account. Much to my surprise I received an email about a day or so later IN ADDITION to a phone call with the good news that software access had been added to my account. I am really quite shocked and pleasantly surprised at the same time that customer service this accommodating still exists. The almighty dollar it seems doesn't always call the shots. Wow. Granted, software access without a support contract, may or may not be a common occurrence. To have this sort of resolution in such a timely manner and with only a single web portal support request, without me having to pay for a current support contract, is in my opinion, truly outstanding. Thank you JTAC. Vijay Ramcharan, CCIE #14824 (RS/SP), CCDP. Net. Eng., Verizon Business - ITSGD. C: 917-821-8009. From scottowens12 at gmail.com Sat Oct 3 11:37:28 2009 From: scottowens12 at gmail.com (scott owens) Date: Sat, 3 Oct 2009 10:37:28 -0500 Subject: [c-nsp] Enclosed rack with filtered air Message-ID: Hello, I need to put two 6509s in a non-clean warehouse. I thought I could just put them in a standard rack with some AC filters attached to the bottom and let the air get pulled out of the top. However the rack is not airtight enough and I am getting a lot of drywall/dust in the rack and switches. Anyone here know where / how to find a semi-sealed enclosed rack with filtered forced air ? From jackson.tim at gmail.com Sat Oct 3 11:50:02 2009 From: jackson.tim at gmail.com (Tim Jackson) Date: Sat, 3 Oct 2009 10:50:02 -0500 Subject: [c-nsp] Enclosed rack with filtered air In-Reply-To: References: Message-ID: <4407932e0910030850l6b61eeb4v9c9dcdaa381ac6f7@mail.gmail.com> http://www.cablingnetworks.com/nema_12.htm NEMA 12 cabinets are rated for this exact application... -- Tim On Sat, Oct 3, 2009 at 10:37 AM, scott owens wrote: > Hello, > ? I need to put two 6509s in a non-clean warehouse. ?I thought I could just > put them in a standard rack with some AC filters attached to the bottom and > let the air get pulled out of the top. ?However the rack is not airtight > enough and I am getting a lot of drywall/dust in the rack and switches. > > Anyone here know where / how to find a semi-sealed enclosed rack with > filtered forced air ?? > _______________________________________________ > cisco-nsp mailing list ?cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From asturluismi at gmail.com Sat Oct 3 12:09:46 2009 From: asturluismi at gmail.com (luismi) Date: Sat, 03 Oct 2009 18:09:46 +0200 Subject: [c-nsp] OT: Juniper JTAC software download assistance - blown away by good customer service In-Reply-To: <8171C8272CE8FE4A8F5BFF8A97CE6AB301A78258@ASHEVS006.mcilink.com> References: <8171C8272CE8FE4A8F5BFF8A97CE6AB301A78258@ASHEVS006.mcilink.com> Message-ID: <1254586186.16585.1.camel@dsba-ipso> Juniper has also great disccounts for certifications from 100%!! :D http://www.juniper.net/us/en/training/fasttrack/ El s?b, 03-10-2009 a las 14:58 +0000, Ramcharan, Vijay A escribi?: > Like most other folks these days, I'm somewhat jaded when it comes to > expecting customer requests that fall outside of the normal spectrum of > issues to be handled in the manner you'd hope. > > This is not a plug by any means for Juniper but I do want to give credit > where I believe it's due. > > Having just come off the Cisco SP train, I decided that what better way > to build upon that than by learning about what is outside of Cisco-land. > > I purchased a couple of low-end J series routers off Ebay. The software > release on them was quite old I belive, at 7.x. > > While I probably could have used that release I decided to try opening > an account with Juniper to see how far I could get before having to fork > out a couple thousand for a new device with a current support contract. > > After getting my account set up, I opened a case to request access to > software downloads; not with much hope of getting it added to my > account. > > Much to my surprise I received an email about a day or so later IN > ADDITION to a phone call with the good news that software access had > been added to my account. I am really quite shocked and pleasantly > surprised at the same time that customer service this accommodating > still exists. The almighty dollar it seems doesn't always call the > shots. Wow. > > Granted, software access without a support contract, may or may not be a > common occurrence. To have this sort of resolution in such a timely > manner and with only a single web portal support request, without me > having to pay for a current support contract, is in my opinion, truly > outstanding. > > Thank you JTAC. > > Vijay Ramcharan, CCIE #14824 (RS/SP), CCDP. > Net. Eng., Verizon Business - ITSGD. > C: 917-821-8009. > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From dschuemann at gmail.com Sat Oct 3 13:41:31 2009 From: dschuemann at gmail.com (Dustin Schuemann) Date: Sat, 3 Oct 2009 13:41:31 -0400 Subject: [c-nsp] Enclosed rack with filtered air In-Reply-To: <4407932e0910030850l6b61eeb4v9c9dcdaa381ac6f7@mail.gmail.com> References: <4407932e0910030850l6b61eeb4v9c9dcdaa381ac6f7@mail.gmail.com> Message-ID: Liebert has some nice sealed racks. On Oct 3, 2009, at 11:50 AM, Tim Jackson wrote: > http://www.cablingnetworks.com/nema_12.htm > > NEMA 12 cabinets are rated for this exact application... > > -- > Tim > > On Sat, Oct 3, 2009 at 10:37 AM, scott owens > wrote: >> Hello, >> I need to put two 6509s in a non-clean warehouse. I thought I >> could just >> put them in a standard rack with some AC filters attached to the >> bottom and >> let the air get pulled out of the top. However the rack is not >> airtight >> enough and I am getting a lot of drywall/dust in the rack and >> switches. >> >> Anyone here know where / how to find a semi-sealed enclosed rack with >> filtered forced air ? >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From drew.weaver at thenap.com Sat Oct 3 14:38:27 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Sat, 3 Oct 2009 14:38:27 -0400 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: <4AC74037.3050408@imperial.ac.uk> References: <4AC619BF.7040009@umn.edu> <4AC620C9.3060208@cisco.com> <4AC74037.3050408@imperial.ac.uk> Message-ID: Not to fault Cisco, or anyone else for that matter but shouldn't switches that cost a quarter of a million dollars be able to protect themselves from these sorts of things just as a default? Just thinking out loud... -----Original Message----- From: Phil Mayers [mailto:p.mayers at imperial.ac.uk] Sent: Saturday, October 03, 2009 8:15 AM To: Drew Weaver Cc: 'rodunn at cisco.com'; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] SUP720 - 12.2(18)SXF17 Drew Weaver wrote: > That whole TTL exceeded thing is a real problem these days, huh? When you have an application as badly-written as ghost (seriously: it's awful, awful, awful stuff) then it could probably find a way to break the network regardless. But yes, splurging a 30gig hard-disk image out over multicast with TTL=1 on the packets will definitely cause TTL-exceeded problems ;o) From colin at netech.ie Sat Oct 3 19:24:23 2009 From: colin at netech.ie (Colin Whittaker) Date: Sun, 4 Oct 2009 00:24:23 +0100 Subject: [c-nsp] Enclosed rack with filtered air In-Reply-To: References: Message-ID: <20091003232423.GA5016@infiltrator.stdlib.net> On Sat, Oct 03, 2009 at 10:37:28AM -0500, scott owens wrote: > Hello, > I need to put two 6509s in a non-clean warehouse. I thought I could just > put them in a standard rack with some AC filters attached to the bottom and > let the air get pulled out of the top. However the rack is not airtight > enough and I am getting a lot of drywall/dust in the rack and switches. > > Anyone here know where / how to find a semi-sealed enclosed rack with > filtered forced air ? We have some units that are completely closed loop for putting in such environments. http://www.pacific-secureit.com/smartbunker.htm I believe ours were ordered from http://www.mainlinecomputer.com/ Colin -- Colin Whittaker +353 (0)86 8211 965 http://colin.netech.ie colin at netech.ie From streiner at cluebyfour.org Sat Oct 3 21:14:52 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 3 Oct 2009 21:14:52 -0400 (EDT) Subject: [c-nsp] facebook related In-Reply-To: <6b300f5d0910011031j47800be2qe949555f7e60c096@mail.gmail.com> References: <6b300f5d0910011031j47800be2qe949555f7e60c096@mail.gmail.com> Message-ID: On Thu, 1 Oct 2009, Andrey 'sshd' Petrenko wrote: > if you resived any messages from facebook, you will see ip address of > facebook server.p.s. sorry for my english =) Correct, but you will not see the IP address of the sender, just servers that belong to facebook. jms > 2009/10/1 Justin M. Streiner > >> On Thu, 1 Oct 2009, Mohammad Khalil wrote: >> >> I was asked today if i recieved a message on facebook can i know the ip >>> address of the sender >>> >> >> My guess is that you will not see the IP address of the sender when you >> receive a message through Facebook. Facebook doesn't present full message >> headers on messages that are sent through the website. Since all >> communication happens through the website, that provides a layer of >> abstraction if Facebook/Myspace/insert_portal_here chooses not to reveal the >> sender's IP address to you. >> >> jms >> >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp at puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > > > > -- > With best regards, > Andrey 'sshd' Petrenko > xmmp: sshd at jabber.org > gtalk: andy.petrenko at gmail.com > skype: andy.petrenko > web: http://sshd.by > From kgraham at industrial-marshmallow.com Sat Oct 3 23:12:47 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Sat, 3 Oct 2009 20:12:47 -0700 (PDT) Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <4AC608B5.6010804@inex.ie> References: <4AC608B5.6010804@inex.ie> Message-ID: <266720.16480.qm@web503.biz.mail.mud.yahoo.com> > Also, bear in mind that not all c65k ports support reading DDM info from SFPs. > SUP720 cards will, as will later hardware revisions of the 6724sfp blades. > Earlier hardware revisions won't. Yeah. I really wish this had gone under a new part number (WS-X6724A-SFP?). It hasn't happened yet, but I dread having to RMA one of our HW rev >= 3.0 cards. Does anyone know if RMA requests can specify minimum hardware rev's? With regards to bogus values, I was going to illustrate some brokenness with null thresholds from some DOM devices (at least one batch of Cisco X2's), but it looks like this got fixed between SXH and SXI. From md at bts.sk Sun Oct 4 03:20:09 2009 From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=) Date: Sun, 4 Oct 2009 09:20:09 +0200 Subject: [c-nsp] DOM on 6724-SFP (was: Will UDLD work with converters ?) In-Reply-To: <266720.16480.qm@web503.biz.mail.mud.yahoo.com> References: <4AC608B5.6010804@inex.ie> <266720.16480.qm@web503.biz.mail.mud.yahoo.com> Message-ID: <20091004072009.GA68835@bts.sk> On Sat, Oct 03, 2009 at 08:12:47PM -0700, Kevin Graham wrote: > > Also, bear in mind that not all c65k ports support reading DDM info from SFPs. > > > SUP720 cards will, as will later hardware revisions of the 6724sfp blades. > > Earlier hardware revisions won't. > > Yeah. I really wish this had gone under a new part number (WS-X6724A-SFP?). > It hasn't happened yet, but I dread having to RMA one of our HW rev >= 3.0 > cards. Well, DOM on 6724-SFP is one of the "policy-banned" features I'm afraid. For many years, multiple customers tried several times to get it working. This topic was also mentioned on various meetings with Cisco, for example in 2007 I gave the following presentation on European NREN workshop: http://md.bts.sk/wien2007-dom.pdf In 2008, the broken I2C bus was fixed on 6724-SFP linecards (HW rev 3.0) and everyone hoped the problem is over. But instead of announcing DOM support on these cards, new IOS "enhancements" were put into SXI train, which aim to disable this functionality in software: #sh inte g 3/1 tra Module 3 doesn't support DOM #sh inte tra supported-modules Mod DOM support ---- -------------- 3 Not Applicable I really fail to undestand, why someone at Cisco tries to make our work harder and disables highly useful features for no reason. I suppose it's just a belief that customers will buy ES20 modules instead, but given that wirespeed 1RU switches with 10G uplinks and 24 SFP downlinks are available from multiple vendors at reasonable prices, this assumption fails miserably. With kind regards, -------------------------------------------------------------------------- ---- ---- ---- Marian ?urkovi? network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 571 041 81 ---- ---- Computer Centre, N?m. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md at bts.sk ---- ---- ---- -------------------------------------------------------------------------- From amr.ccie at gmail.com Sun Oct 4 03:52:40 2009 From: amr.ccie at gmail.com (Jason Alex) Date: Sun, 4 Oct 2009 09:52:40 +0200 Subject: [c-nsp] Cisco SCE simultaneous users Message-ID: Dear All, can anyone advice, does the SCE QM (Quota Manager) supports that a Username is running on Multiple SCE at the same time ? we have users in our network that can access the Network from two different places using the same username So what we got is that we have this username is running on multiple SCE on the same time my question is there is any problem in quota calculation when the same Subscriber is running on the same time on multiple SCEs ? Thanks Jason From peter.hicks at poggs.co.uk Sun Oct 4 04:45:47 2009 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Sun, 04 Oct 2009 09:45:47 +0100 Subject: [c-nsp] Crypto tunnel issue or undocumented feature? In-Reply-To: <78DD389C2574C947AD8B34B9D043309E035EC447@ex01.netentertainment.com> References: <78DD389C2574C947AD8B34B9D043309E035EC447@ex01.netentertainment.com> Message-ID: <4AC860BB.3040803@poggs.co.uk> Hi Jonas Jonas Jonsson wrote: > It was a bit puzzling until after looking at the remote config we > allowed icmp and the tunnel now stays up. Hence is this an undocumented > feature or a bug? Can you post the ACLs at either end, and provide software versions for both ends? Peter From Liviu.Cohen at veraznetworks.com Sun Oct 4 05:13:43 2009 From: Liviu.Cohen at veraznetworks.com (Liviu Cohen) Date: Sun, 4 Oct 2009 11:13:43 +0200 Subject: [c-nsp] support of PBR action: "set ip next-hop" under VRF Message-ID: <7E7134574402C14FBD1F3FC1F78A3479545CB6@VRZIL-EX01.il.veraznetworks.com> Hi . Though I read past reference, I'm still confused about support of PBR action: "set ip next-hop" under VRF. Thanks. Liviu Cohen Director of Network Engineering R&D Media Gateways Veraz Networks Ltd. www.veraznetworks.com Mail????? Liviu.cohen at veraznetworks.com Phone? +972-3? -970-9047 Cell????? +972-54-970-9047 Fax????? +972-3-970-9442 ? From avayner at cisco.com Sun Oct 4 05:53:22 2009 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Sun, 4 Oct 2009 11:53:22 +0200 Subject: [c-nsp] Cisco SCE simultaneous users In-Reply-To: References: Message-ID: Jason, It's not supported, The Cisco Quota Manager implementation assumes a subscriber can exist on one SCE at any given time. However, customers may implement their own QM on top of the SCE Subscribers API and have it support such topology. Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jason Alex Sent: Sunday, October 04, 2009 09:53 To: cisco-nsp at puck.nether.net Subject: [c-nsp] Cisco SCE simultaneous users Dear All, can anyone advice, does the SCE QM (Quota Manager) supports that a Username is running on Multiple SCE at the same time ? we have users in our network that can access the Network from two different places using the same username So what we got is that we have this username is running on multiple SCE on the same time my question is there is any problem in quota calculation when the same Subscriber is running on the same time on multiple SCEs ? Thanks Jason _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From avayner at cisco.com Sun Oct 4 08:58:01 2009 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Sun, 4 Oct 2009 14:58:01 +0200 Subject: [c-nsp] support of PBR action: "set ip next-hop" under VRF In-Reply-To: <7E7134574402C14FBD1F3FC1F78A3479545CB6@VRZIL-EX01.il.veraznetworks.com> References: <7E7134574402C14FBD1F3FC1F78A3479545CB6@VRZIL-EX01.il.veraznetworks.com> Message-ID: Liviu, Can you explain a bit what you want to achieve? Thanks Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Liviu Cohen Sent: Sunday, October 04, 2009 11:14 To: cisco-nsp at puck.nether.net Subject: [c-nsp] support of PBR action: "set ip next-hop" under VRF Hi . Though I read past reference, I'm still confused about support of PBR action: "set ip next-hop" under VRF. Thanks. Liviu Cohen Director of Network Engineering R&D Media Gateways Veraz Networks Ltd. www.veraznetworks.com Mail????? Liviu.cohen at veraznetworks.com Phone? +972-3? -970-9047 Cell????? +972-54-970-9047 Fax????? +972-3-970-9442 ? _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From avayner at cisco.com Sun Oct 4 11:06:54 2009 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Sun, 4 Oct 2009 17:06:54 +0200 Subject: [c-nsp] support of PBR action: "set ip next-hop" under VRF In-Reply-To: <7E7134574402C14FBD1F3FC1F78A3479545CB6@VRZIL-EX01.il.veraznetworks.com> References: <7E7134574402C14FBD1F3FC1F78A3479545CB6@VRZIL-EX01.il.veraznetworks.com> Message-ID: This is possible using the "set vrf next-hop" command: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_pi2.html#wp1035512 Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Liviu Cohen Sent: Sunday, October 04, 2009 11:14 To: cisco-nsp at puck.nether.net Subject: [c-nsp] support of PBR action: "set ip next-hop" under VRF Hi . Though I read past reference, I'm still confused about support of PBR action: "set ip next-hop" under VRF. Thanks. Liviu Cohen Director of Network Engineering R&D Media Gateways Veraz Networks Ltd. www.veraznetworks.com Mail????? Liviu.cohen at veraznetworks.com Phone? +972-3? -970-9047 Cell????? +972-54-970-9047 Fax????? +972-3-970-9442 ? _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From peter.hicks at poggs.co.uk Sun Oct 4 18:10:07 2009 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Sun, 04 Oct 2009 23:10:07 +0100 Subject: [c-nsp] IOS 15.0 - why the numbering jump? Message-ID: <4AC91D3F.4080101@poggs.co.uk> All, Just noticed IOS 15.0 is out... but why the sudden jump in image naming?! Poggs From simon at slimey.org Sun Oct 4 18:50:04 2009 From: simon at slimey.org (Simon Lockhart) Date: Sun, 4 Oct 2009 23:50:04 +0100 Subject: [c-nsp] IOS 15.0 - why the numbering jump? In-Reply-To: <4AC91D3F.4080101@poggs.co.uk> References: <4AC91D3F.4080101@poggs.co.uk> Message-ID: <20091004225004.GH20581@virtual.bogons.net> On Sun Oct 04, 2009 at 11:10:07PM +0100, Peter Hicks wrote: > Just noticed IOS 15.0 is out... but why the sudden jump in image naming?! Looks like they've jumped from 12.4 to 15.0. Sounds a bit like the jump from Solaris 2.6 to Solaris 7. Took a look at 15.0 for my 877... ADVANCED IP SERVICES c870-advipservicesk9-mz.150-1.M.bin Release Date: 01/Oct/2009 Size: 23554.10 KB (24119396 bytes) Minimum Memory: DRAM:192 MB Flash:36 MB My 877 is fairly new (couple of months old), and only has 128M of RAM and 24M of flash. Gah, bloat. Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From peter.hicks at poggs.co.uk Sun Oct 4 19:09:30 2009 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Mon, 05 Oct 2009 00:09:30 +0100 Subject: [c-nsp] IOS 15.0 - why the numbering jump? In-Reply-To: <20091004225004.GH20581@virtual.bogons.net> References: <4AC91D3F.4080101@poggs.co.uk> <20091004225004.GH20581@virtual.bogons.net> Message-ID: <4AC92B2A.5040901@poggs.co.uk> Simon Lockhart wrote: > Took a look at 15.0 for my 877... > > ADVANCED IP SERVICES > c870-advipservicesk9-mz.150-1.M.bin > Release Date: 01/Oct/2009 > Size: 23554.10 KB (24119396 bytes) > Minimum Memory: DRAM:192 MB Flash:36 MB > > My 877 is fairly new (couple of months old), and only has 128M of RAM and 24M > of flash. Gah, bloat. IIRC, 128Mb DRAM and 24Mb flash was the most you could fit in an 877W, although I recall having one with 192Mb after an accidental "oh, it works" with a 128Mb DIMM. Poggs From jlewis at lewis.org Sun Oct 4 21:37:59 2009 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 4 Oct 2009 21:37:59 -0400 (EDT) Subject: [c-nsp] IOS 15.0 - why the numbering jump? In-Reply-To: <20091004225004.GH20581@virtual.bogons.net> References: <4AC91D3F.4080101@poggs.co.uk> <20091004225004.GH20581@virtual.bogons.net> Message-ID: On Sun, 4 Oct 2009, Simon Lockhart wrote: > Looks like they've jumped from 12.4 to 15.0. > > Sounds a bit like the jump from Solaris 2.6 to Solaris 7. > > Took a look at 15.0 for my 877... > > ADVANCED IP SERVICES > c870-advipservicesk9-mz.150-1.M.bin > Release Date: 01/Oct/2009 > Size: 23554.10 KB (24119396 bytes) > Minimum Memory: DRAM:192 MB Flash:36 MB > > My 877 is fairly new (couple of months old), and only has 128M of RAM and 24M > of flash. Gah, bloat. And that's for a little DSL router? I don't know whether to be shocked or happy that the cisco 877 DSL router is upgradable to 256mb RAM and 52mb Flash. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jeff-kell at utc.edu Sun Oct 4 21:59:28 2009 From: jeff-kell at utc.edu (Jeff Kell) Date: Sun, 04 Oct 2009 21:59:28 -0400 Subject: [c-nsp] IOS 15.0 - why the numbering jump? In-Reply-To: <4AC92B2A.5040901@poggs.co.uk> References: <4AC91D3F.4080101@poggs.co.uk> <20091004225004.GH20581@virtual.bogons.net> <4AC92B2A.5040901@poggs.co.uk> Message-ID: <4AC95300.9080807@utc.edu> 13 I can see skipping for superstitious reasons. 14 I dunno... maybe 15 to round it out to a '5', like Firefox 3.0 -> 3.5? Jeff From matt at deploylinux.net Sun Oct 4 22:20:13 2009 From: matt at deploylinux.net (Matthew Marlowe) Date: Sun, 4 Oct 2009 19:20:13 -0700 (PDT) Subject: [c-nsp] IOS 15.0 - why the numbering jump? In-Reply-To: <4AC91D3F.4080101@poggs.co.uk> Message-ID: <1654412392.2191254709213519.JavaMail.root@mail1.deploylinux.net> Peter, Someone on twitter said that Asian culture has a phobia of the number 14, similar to the western phobia of 13. I would have preferred Cisco just ignore this stuff, but if they were going to bump, I guess 15 is just as good as 14. At least they are not naming it Cisco IOS 2010 or some such. Also, I just saw some references to what appears to be show version output for next version of ISR routers....down near the bottom of: http://www.cisco.com/en/US/docs/ios/fundamentals/configuration/guide/cf_dgtly_sgnd_sw.html, you can see what appears to be a Cisco 3945 booting. Matt ----- "Peter Hicks" wrote: > All, > > Just noticed IOS 15.0 is out... but why the sudden jump in image > naming?! > > > Poggs > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- -- Matthew Marlowe - http://www.deploylinux.net/ CEO @ DeployLinux Consulting, Inc matt at deploylinux.net, 858-400-7430 http://www.twitter.com/deploylinux From tvarriale at comcast.net Sun Oct 4 23:39:36 2009 From: tvarriale at comcast.net (Tony Varriale) Date: Sun, 4 Oct 2009 22:39:36 -0500 Subject: [c-nsp] IOS 15.0 - why the numbering jump? References: <1654412392.2191254709213519.JavaMail.root@mail1.deploylinux.net> Message-ID: New routers will be announced this week (Tuesday IIRC?). tv ----- Original Message ----- From: "Matthew Marlowe" To: "Peter Hicks" Cc: Sent: Sunday, October 04, 2009 9:20 PM Subject: Re: [c-nsp] IOS 15.0 - why the numbering jump? > Peter, > > Someone on twitter said that Asian culture has a phobia of the number 14, > similar to the western phobia of 13. I would have preferred Cisco just > ignore this stuff, but if they were going to bump, I guess 15 is just as > good as 14. At least they are not naming it Cisco IOS 2010 or some such. > > Also, I just saw some references to what appears to be show version output > for next version of ISR routers....down near the bottom of: > http://www.cisco.com/en/US/docs/ios/fundamentals/configuration/guide/cf_dgtly_sgnd_sw.html, > you can see what appears to be a Cisco 3945 booting. > > Matt > > ----- "Peter Hicks" wrote: > >> All, >> >> Just noticed IOS 15.0 is out... but why the sudden jump in image >> naming?! >> >> >> Poggs >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp at puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > > -- > -- > Matthew Marlowe - http://www.deploylinux.net/ > CEO @ DeployLinux Consulting, Inc > matt at deploylinux.net, 858-400-7430 > http://www.twitter.com/deploylinux > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From mawhi at vestas.com Mon Oct 5 01:09:08 2009 From: mawhi at vestas.com (Matthew White) Date: Sun, 4 Oct 2009 22:09:08 -0700 Subject: [c-nsp] Enclosed rack with filtered air In-Reply-To: References: Message-ID: I've had good success with Hoffman cabinets: http://www.hoffmanonline.com/product_catalog/product_detail.aspx?cat_1=34&cat_2=2410&cat_3=81607&catID=81607&itemID=69583 You can get them with or without integrated AC units. I can put you in touch with a reputable manufacturer's rep if you need further information. -mtw ________________________________________ From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of scott owens [scottowens12 at gmail.com] Sent: Saturday, October 03, 2009 08:37 To: cisco-nsp at puck.nether.net Subject: [c-nsp] Enclosed rack with filtered air Hello, I need to put two 6509s in a non-clean warehouse. I thought I could just put them in a standard rack with some AC filters attached to the bottom and let the air get pulled out of the top. However the rack is not airtight enough and I am getting a lot of drywall/dust in the rack and switches. Anyone here know where / how to find a semi-sealed enclosed rack with filtered forced air ? _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From mtinka at globaltransit.net Mon Oct 5 02:40:43 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Mon, 5 Oct 2009 14:40:43 +0800 Subject: [c-nsp] IOS 15.0 - why the numbering jump? In-Reply-To: <1654412392.2191254709213519.JavaMail.root@mail1.deploylinux.net> References: <1654412392.2191254709213519.JavaMail.root@mail1.deploylinux.net> Message-ID: <200910051440.48166.mtinka@globaltransit.net> On Monday 05 October 2009 10:20:13 am Matthew Marlowe wrote: > Peter, > > Someone on twitter said that Asian culture has a phobia > of the number 14,... Well, to be exact, the Chinese are generally superstitious of the number "4". That includes anything that has a "4" in it, e.g., 14, 24, 34, 44, e.t.c. Conversely, "8" is considered to be associated with good luck and fortune. I can't speak to other Asian nationals/cultures re: numbers. > similar to the western phobia of 13. I > would have preferred Cisco just ignore this stuff, but if > they were going to bump, I guess 15 is just as good as > 14. At least they are not naming it Cisco IOS 2010 or > some such. Perhaps Cisco saw Juniper were gaining on them with their upcoming release of JUNOS 10. Knowing Juniper's release cycle, it wouldn't be long before JUNOS 12 became available (oh my, imagine JUNOS 12.2, JUNOS 12.3, JUNOS 12.4, JUNOS 12.5, e.t.c.). I guess IOS 15 keeps Cisco a couple of steps ahead :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From A.L.M.Buxey at lboro.ac.uk Mon Oct 5 05:09:59 2009 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Mon, 5 Oct 2009 10:09:59 +0100 Subject: [c-nsp] IOS 15.0 - why the numbering jump? In-Reply-To: <200910051440.48166.mtinka@globaltransit.net> References: <1654412392.2191254709213519.JavaMail.root@mail1.deploylinux.net> <200910051440.48166.mtinka@globaltransit.net> Message-ID: <20091005090959.GB29398@lboro.ac.uk> Hi, > Conversely, "8" is considered to be associated with good > luck and fortune. ...and whilst we dont have such superstitions in the Western world life might be better if we did.. ASA 8.x, RedHat 8.x, IE 8.x, SUSE 8.x and IOS 12.2-SXF8 all spring to mind ;-) alan From mtinka at globaltransit.net Mon Oct 5 05:15:19 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Mon, 5 Oct 2009 17:15:19 +0800 Subject: [c-nsp] IOS 15.0 - why the numbering jump? In-Reply-To: <20091005090959.GB29398@lboro.ac.uk> References: <1654412392.2191254709213519.JavaMail.root@mail1.deploylinux.net> <200910051440.48166.mtinka@globaltransit.net> <20091005090959.GB29398@lboro.ac.uk> Message-ID: <200910051715.25202.mtinka@globaltransit.net> On Monday 05 October 2009 05:09:59 pm Alan Buxey wrote: > ... SUSE 8.x... SuSE 8.2 was actually very good - it's been downhill ever since, although I'm still a loyal follower :-). Okay, really going off-topic now :-). Cheers, Mark <= who's running openSuSE-11.1 over VMware Fusion 2.0.5 over Mac OS X 10.6.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From A.L.M.Buxey at lboro.ac.uk Mon Oct 5 05:38:07 2009 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Mon, 5 Oct 2009 10:38:07 +0100 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: <4AC74037.3050408@imperial.ac.uk> References: <4AC619BF.7040009@umn.edu> <4AC620C9.3060208@cisco.com> <4AC74037.3050408@imperial.ac.uk> Message-ID: <20091005093807.GJ29398@lboro.ac.uk> Hi, > But yes, splurging a 30gig hard-disk image out over multicast with TTL=1 > on the packets will definitely cause TTL-exceeded problems ;o) bonus points++ for the application using a global multicast address too. nice. alan From A.L.M.Buxey at lboro.ac.uk Mon Oct 5 05:39:33 2009 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Mon, 5 Oct 2009 10:39:33 +0100 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: References: <4AC619BF.7040009@umn.edu> <4AC620C9.3060208@cisco.com> <4AC74037.3050408@imperial.ac.uk> Message-ID: <20091005093933.GK29398@lboro.ac.uk> Hi, > Not to fault Cisco, or anyone else for that matter but shouldn't switches that cost a quarter of a million dollars be able to protect themselves from these sorts of things just as a default? turn off multicast for that VLAN - its its TTL=1 then it didnt really want to multicast anyway - thats a broadcast :-) alan From p.mayers at imperial.ac.uk Mon Oct 5 05:43:03 2009 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Mon, 05 Oct 2009 10:43:03 +0100 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: <20091005093933.GK29398@lboro.ac.uk> References: <4AC619BF.7040009@umn.edu> <4AC620C9.3060208@cisco.com> <4AC74037.3050408@imperial.ac.uk> <20091005093933.GK29398@lboro.ac.uk> Message-ID: <4AC9BFA7.4060203@imperial.ac.uk> Alan Buxey wrote: > Hi, >> Not to fault Cisco, or anyone else for that matter but shouldn't switches that cost a quarter of a million dollars be able to protect themselves from these sorts of things just as a default? > > turn off multicast for that VLAN - its its TTL=1 then it didnt really want to multicast > anyway - thats a broadcast :-) > > alan Alternatively, we do this: interface Vlan55 vrf forwarding xxx ip verify unicast source reachable-via rx no ip proxy-arp ip flow ingress ip pim sparse-mode ip multicast boundary MULTICAST-in ip igmp access-group MULTICAST-in ip access-list standard MULTICAST-in deny 224.0.1.60 deny 224.77.0.0 0.0.255.255 deny 226.77.0.0 0.0.255.255 permit 239.192.0.0 0.3.255.255 deny 239.0.0.0 0.255.255.255 permit 224.0.0.0 15.255.255.255 mls rate-limit all ttl-failure 100 10 mls rate-limit all mtu-failure 100 10 There's no reason not to have the TTL failure rate limit enabled AFAIK. Choose a value appropriate to you, obviously. From p.mayers at imperial.ac.uk Mon Oct 5 07:57:08 2009 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Mon, 05 Oct 2009 12:57:08 +0100 Subject: [c-nsp] Monitoring HTTP / url access @10gig Message-ID: <4AC9DF14.3040904@imperial.ac.uk> We currently monitor web access from our campus with a VACL capture, picked up by a server-class machine with a 10gig port. Hardware is sup720, and our internet links are 10gig, doing well over 1gbit/sec. For various reasons this solution is unsatisfactory; the VACL doesn't work well and doesn't support IPv6, SPAN sessions are limited and policy routing to a web cache is exactly what we don't want to do. What other solutions can people recommend? I see that GigaMon make an interesting (and expensive looking) product: http://www.gigamon.com/gigavue-420.php ...which claims to be able to tap a 10gig link, filter the traffic then direct it to a 1gig port. This could be interesting for a number of reasons. Other suggestions welcome. From moua0100 at umn.edu Mon Oct 5 09:24:26 2009 From: moua0100 at umn.edu (Ge Moua) Date: Mon, 05 Oct 2009 08:24:26 -0500 Subject: [c-nsp] Monitoring HTTP / url access @10gig In-Reply-To: <4AC9DF14.3040904@imperial.ac.uk> References: <4AC9DF14.3040904@imperial.ac.uk> Message-ID: <4AC9F38A.5000006@umn.edu> We beta tested the GigaMon platform and for the most part it does what it claims it can do; basically takes a span feed and "fans" it out for analysis; in the end it was just too $$pricey$$ (> ~$100K USD); seems like the target mkt are carriers and large service providers. Our OITSecurity group has been looking at NetOptics as a less expensive alternative: http://www.network-taps.eu/home/home.php Does basically the same as the Gigamon but not nearly as expensive (~$50K USD); albeit with less bells and whistles. I forgot to mention that our focus is on IPS/IDS and these 10-gig feeds are to our IPS/IDS "home grown" clusters. Good luck. Regards, Ge Moua | Email: moua0100 at umn.edu Network Design Engineer University of Minnesota | Networking & Telecommunications Services Phil Mayers wrote: > We currently monitor web access from our campus with a VACL capture, > picked up by a server-class machine with a 10gig port. Hardware is > sup720, and our internet links are 10gig, doing well over 1gbit/sec. > > For various reasons this solution is unsatisfactory; the VACL doesn't > work well and doesn't support IPv6, SPAN sessions are limited and > policy routing to a web cache is exactly what we don't want to do. > What other solutions can people recommend? > > I see that GigaMon make an interesting (and expensive looking) product: > > http://www.gigamon.com/gigavue-420.php > > ...which claims to be able to tap a 10gig link, filter the traffic > then direct it to a 1gig port. This could be interesting for a number > of reasons. > > Other suggestions welcome. > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From p.mayers at imperial.ac.uk Mon Oct 5 09:39:49 2009 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Mon, 05 Oct 2009 14:39:49 +0100 Subject: [c-nsp] Monitoring HTTP / url access @10gig In-Reply-To: <4AC9F38A.5000006@umn.edu> References: <4AC9DF14.3040904@imperial.ac.uk> <4AC9F38A.5000006@umn.edu> Message-ID: <4AC9F725.40608@imperial.ac.uk> Ge Moua wrote: > We beta tested the GigaMon platform and for the most part it does what > it claims it can do; basically takes a span feed and "fans" it out for > analysis; in the end it was just too $$pricey$$ (> ~$100K USD); seems > like the target mkt are carriers and large service providers. > > Our OITSecurity group has been looking at NetOptics as a less expensive > alternative: > http://www.network-taps.eu/home/home.php > > Does basically the same as the Gigamon but not nearly as expensive > (~$50K USD); albeit with less bells and whistles. Which specific products are you using, if you don't mind my asking? From moua0100 at umn.edu Mon Oct 5 09:59:15 2009 From: moua0100 at umn.edu (Ge Moua) Date: Mon, 05 Oct 2009 08:59:15 -0500 Subject: [c-nsp] Monitoring HTTP / url access @10gig In-Reply-To: <4AC9F725.40608@imperial.ac.uk> References: <4AC9DF14.3040904@imperial.ac.uk> <4AC9F38A.5000006@umn.edu> <4AC9F725.40608@imperial.ac.uk> Message-ID: <4AC9FBB3.1040405@umn.edu> I'm a bit surprise you were not able to match on IPv6 addresses; will something like this get any IPv6 traffic at all? ipv6 access-list IPv6-Sample-ACL permit ipv6 any any To answer your question: current: * Vlan based SPANs, with edge feed on dot.1q trunk; this allows for "poor man" granularity by vlan ("permit all" & not as good as VACL) * IDS are open-bsd running snort with extensive ruleset for matching attack signatures not-so-distant-future (which will buy as a few years): * net-optics In my opinion all of this is analogous to an "arms race" where at some point traffic volume over-runs current method or technology used then the whole design needs to be re-visited again; but then again IT is somewhat like that by nature. Regards, Ge Moua | Email: moua0100 at umn.edu Network Design Engineer University of Minnesota | Networking & Telecommunications Services 2218 University Ave SE | Minneapolis, MN 55414-3029 Office: 612.626.2779 | Pager: 612.648.0103 | Fax: 612.626.1818 Phil Mayers wrote: > Ge Moua wrote: >> We beta tested the GigaMon platform and for the most part it does >> what it claims it can do; basically takes a span feed and "fans" it >> out for analysis; in the end it was just too $$pricey$$ (> ~$100K >> USD); seems like the target mkt are carriers and large service >> providers. >> >> Our OITSecurity group has been looking at NetOptics as a less >> expensive alternative: >> http://www.network-taps.eu/home/home.php >> >> Does basically the same as the Gigamon but not nearly as expensive >> (~$50K USD); albeit with less bells and whistles. > > Which specific products are you using, if you don't mind my asking? From p.mayers at imperial.ac.uk Mon Oct 5 10:03:20 2009 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Mon, 05 Oct 2009 15:03:20 +0100 Subject: [c-nsp] Monitoring HTTP / url access @10gig In-Reply-To: <4AC9FBB3.1040405@umn.edu> References: <4AC9DF14.3040904@imperial.ac.uk> <4AC9F38A.5000006@umn.edu> <4AC9F725.40608@imperial.ac.uk> <4AC9FBB3.1040405@umn.edu> Message-ID: <4AC9FCA8.3090405@imperial.ac.uk> Ge Moua wrote: > I'm a bit surprise you were not able to match on IPv6 addresses; will > something like this get any IPv6 traffic at all? It's complicated, but seemingly the 6500 won't VACL-capture IPv6 traffic which it's also routing. It could be a bug, but as I say we've had other problems with VACL capture (e.g. it just stopped working one day with no config changes, then started back up a week later with no explanation) so we're keen to move away from it. From moua0100 at umn.edu Mon Oct 5 10:05:14 2009 From: moua0100 at umn.edu (Ge Moua) Date: Mon, 05 Oct 2009 09:05:14 -0500 Subject: [c-nsp] Monitoring HTTP / url access @10gig In-Reply-To: <4AC9FCA8.3090405@imperial.ac.uk> References: <4AC9DF14.3040904@imperial.ac.uk> <4AC9F38A.5000006@umn.edu> <4AC9F725.40608@imperial.ac.uk> <4AC9FBB3.1040405@umn.edu> <4AC9FCA8.3090405@imperial.ac.uk> Message-ID: <4AC9FD1A.70709@umn.edu> What code are you running on the Sup720 (3bxl ? I assume) ?? Regards, Ge Moua | Email: moua0100 at umn.edu Network Design Engineer University of Minnesota | Networking & Telecommunications Services Phil Mayers wrote: > Ge Moua wrote: >> I'm a bit surprise you were not able to match on IPv6 addresses; will >> something like this get any IPv6 traffic at all? > > It's complicated, but seemingly the 6500 won't VACL-capture IPv6 > traffic which it's also routing. It could be a bug, but as I say we've > had other problems with VACL capture (e.g. it just stopped working one > day with no config changes, then started back up a week later with no > explanation) so we're keen to move away from it. > > From p.mayers at imperial.ac.uk Mon Oct 5 10:11:29 2009 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Mon, 05 Oct 2009 15:11:29 +0100 Subject: [c-nsp] Monitoring HTTP / url access @10gig In-Reply-To: <4AC9FD1A.70709@umn.edu> References: <4AC9DF14.3040904@imperial.ac.uk> <4AC9F38A.5000006@umn.edu> <4AC9F725.40608@imperial.ac.uk> <4AC9FBB3.1040405@umn.edu> <4AC9FCA8.3090405@imperial.ac.uk> <4AC9FD1A.70709@umn.edu> Message-ID: <4AC9FE91.7030007@imperial.ac.uk> Ge Moua wrote: > What code are you running on the Sup720 (3bxl ? I assume) ?? 12.2(33)SXI, but we've seen other problems on other versions; I don't have an exhaustive list, to hand. The config is something along the lines of: vlan access-map v6_Capture 10 match mac address PERMIT_ANY action forward capture vlan access-map v4_capture 10 match ip address WEB_TRAFFIC action forward capture vlan access-map v4_capture 20 match ip address PERMIT_ANY action forward vlan filter v6_capture vlan-list 4000 vlan filter v4_capture vlan-list 4001 int Vlan4000 description ipv6 upstream ipv6 address 2001:db8:100::1/126 int Vlan4001 description ipv4 upstream ipv6 address 192.0.2.1 255.255.255.252 int Te1/1 switchport mode trunk switchport trunk allowed vlan 4000,4001 ...now, this all *used* to work when we had: int Vlan4000 description layer2 only vlan, goes to ipv6 router no ip address mac packet-classify ...that latter line is *ABSOLUTELY* necessary, as is the no-IP SVI. Once we moved the routing onto the 6500, no combination of config would make VACL capture the ipv6. From chip.gwyn at gmail.com Mon Oct 5 10:14:49 2009 From: chip.gwyn at gmail.com (chip) Date: Mon, 5 Oct 2009 10:14:49 -0400 Subject: [c-nsp] sliding window quota In-Reply-To: References: <1254414943.7369.0.camel@dsba-ipso> Message-ID: <64a8ad980910050714y39d4c910p9b61e74dac72615@mail.gmail.com> There's also the Citrix Wan Scaler appliance (old Orbital Data) and the offering from Asankya. -- Just my $.02, your mileage may vary, batteries not included, etc.... From bacon at walleyesoftware.com Mon Oct 5 10:35:10 2009 From: bacon at walleyesoftware.com (Jeff Bacon) Date: Mon, 5 Oct 2009 09:35:10 -0500 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: References: Message-ID: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net> > If you want to cut delay for switching, you may want to consider the > new top-of-rack 10G boxes, which are typically cut-through. You may find I'm thinking about that for within the datacenter. It's hard finding a justification for the C-vendor's products though - a N7 is just too much, and I guess the N5 is OK but even starting out it's not... inexpensive, esp when it doesn't even include a meaningful layer-3 capability. I guess I understand the product reasoning - a large datacenter is built around N7Ks, with N5K distro - which is great, if you have a massive datacenter... but what about us poor saps in the middle and lower tiers? Or aren't we interesting anymore? Oh, I understand, we're supposed to be virtualizing and buying the 1000v switches...except virtual servers don't do me crap for good... > Personally, I have a bit of a thing against X2, but that's just me. > Make your own mind up. Fair enough. > > 3) Does 6500 switching performance blow super-hard, or just so-so hard? > > (6-15us is ok.) Yes a 4900M might be faster, or a J-product, but I don't > > want to change platform really, I need NAT and don't want to use > > routers, I want to keep box count down (co-lo), and having a whole box > > just for passing 10G doesn't IMO make sense because I'd still have to > > get it into the 6500 anyway. > The 6500 is a great 1G switch platform, but doesn't excel in the 10G > range, particularly with 6704 blades. Admittedly, for the cost, I can buy an arista 1U for wave passthru and just tap multiple 1Gs over to the 6500. Why "particularly with 6704 blades"? Is there something particularly wrong with them? Thanks, -bacon From nick at inex.ie Mon Oct 5 11:06:31 2009 From: nick at inex.ie (Nick Hilliard) Date: Mon, 05 Oct 2009 16:06:31 +0100 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net> Message-ID: <4ACA0B77.5090106@inex.ie> On 05/10/2009 15:35, Jeff Bacon wrote: > Admittedly, for the cost, I can buy an arista 1U for wave passthru and > just tap multiple 1Gs over to the 6500. Aristas use SFP+. Good luck running colours over them. :-) Actually, Optoway in Taiwan produce CWDM SFP+ transceivers. I don't know anyone using them, but given the power constraints imposed by the SFP+ form factor, I wouldn't expect long reach or anything. > Why "particularly with 6704 blades"? Is there something particularly > wrong with them? Depends on what you do with them. They are a first generation blade, and are 6yo technology at this stage and, well, things have moved on since 2003. XENPAK is moribund as a transceiver type which means that any money you invest into buying transceivers will probably be written off when you retire the blade. If you're concerned about storm control (which personally, I am), the 6704 can only limit to 0.33% of port capacity, which means that if you get a broadcast / multicast storm on a 6704 port, it will bang out 33 megs of data before storm control even notices. Most hosts will happily ignore the multicast traffic, but the broadcast traffic could cause serious trouble. If you need to push wire-speed 10G on a 6704, there are conflicting reports as to whether this works well. Some people say yes; others no - there's lots of discussion about this in the c-nsp archives. It can help to use a DFC if you're banging out a lot of traffic, but that's extra ??? on top of a product which already has a high cost per port. The 6708 is lots better than the 6704 if you operate it in non- oversubscribe mode, apart from anything else, it has a built-in DFC, which means that you don't need to retrofit this for high traffic environments. As I said, it depends on what you want to do. If you're running just a couple of gigs and don't care about the broadcast traffic problem or, say, are using them for L3 traffic instead of L2, then they are great. Similarly, the C65k+sup720 platform makes a really nice high density, feature rich 1G platform. But if you're planning to run lots of very high bandwidth stuff, it might be better to use a different platform. Nick From azher at hep.caltech.edu Mon Oct 5 12:30:59 2009 From: azher at hep.caltech.edu (Azher Mughal) Date: Mon, 05 Oct 2009 09:30:59 -0700 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <4ACA0B77.5090106@inex.ie> References: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net> <4ACA0B77.5090106@inex.ie> Message-ID: <4ACA1F43.5020603@hep.caltech.edu> In order to use SFP+ from other vendors in Arista, you need to get them enabled first. -Azher Nick Hilliard wrote: > On 05/10/2009 15:35, Jeff Bacon wrote: >> Admittedly, for the cost, I can buy an arista 1U for wave passthru and >> just tap multiple 1Gs over to the 6500. > > Aristas use SFP+. Good luck running colours over them. :-) > > Actually, Optoway in Taiwan produce CWDM SFP+ transceivers. I don't > know anyone using them, but given the power constraints imposed by the > SFP+ form factor, I wouldn't expect long reach or anything. > >> Why "particularly with 6704 blades"? Is there something particularly >> wrong with them? > > Depends on what you do with them. They are a first generation blade, > and are 6yo technology at this stage and, well, things have moved on > since 2003. XENPAK is moribund as a transceiver type which means that > any money you invest into buying transceivers will probably be written > off when you retire the blade. > > If you're concerned about storm control (which personally, I am), the > 6704 can only limit to 0.33% of port capacity, which means that if you > get a broadcast / multicast storm on a 6704 port, it will bang out 33 > megs of data before storm control even notices. Most hosts will > happily ignore the multicast traffic, but the broadcast traffic could > cause serious trouble. > > If you need to push wire-speed 10G on a 6704, there are conflicting > reports as to whether this works well. Some people say yes; others no > - there's lots of discussion about this in the c-nsp archives. It can > help to use a DFC if you're banging out a lot of traffic, but that's > extra ??? on top of a product which already has a high cost per port. > > The 6708 is lots better than the 6704 if you operate it in non- > oversubscribe mode, apart from anything else, it has a built-in DFC, > which means that you don't need to retrofit this for high traffic > environments. > > As I said, it depends on what you want to do. If you're running just > a couple of gigs and don't care about the broadcast traffic problem > or, say, are using them for L3 traffic instead of L2, then they are > great. Similarly, the C65k+sup720 platform makes a really nice high > density, feature rich 1G platform. But if you're planning to run lots > of very high bandwidth stuff, it might be better to use a different > platform. > > Nick > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From zhassan at gmx.net Mon Oct 5 15:08:17 2009 From: zhassan at gmx.net (Zahid Hassan) Date: Mon, 5 Oct 2009 12:08:17 -0700 (PDT) Subject: [c-nsp] Invitation to connect on LinkedIn Message-ID: <1691001311.792687.1254769697238.JavaMail.app@ech3-cdn07.prod> LinkedIn ------------ Zahid Hassan pidi? a?adirte como contacto en LinkedIn: ------------------------------------------ Sebasti?n, I'd like to add you to my professional network on LinkedIn. - Zahid Aceptar invitaci?n de Zahid Hassan http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1483081203_2/pmpxnSRJrSdvj4R5fnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_cBYPc38Ne30Pe3gNiiZTlPlIgABArOYRdzoUdzwUdPsLrCBxbOYWrSlI/EML_comm_afe/ Ver invitaci?n de Zahid Hassan http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1483081203_2/39vcP0OcjwMcPwQckALqnpPbOYWrSlI/svi/ ------------------------------------------ ?Por qu? puede ser una buena idea conectar con Zahid Hassan? La gente que conoce a Zahid Hassan podr?a descubrir tu perfil: Conectar con Zahid Hassan atraer? la atenci?n de otros usuarios de LinkedIn. Averigua qui?n ha visto tu perfil: http://www.linkedin.com/e/wvp/inv18_wvmp/ ------ (c) 2009, LinkedIn Corporation From abalashov at evaristesys.com Mon Oct 5 15:17:26 2009 From: abalashov at evaristesys.com (Alex Balashov) Date: Mon, 05 Oct 2009 15:17:26 -0400 Subject: [c-nsp] Invitation to connect on LinkedIn In-Reply-To: <1691001311.792687.1254769697238.JavaMail.app@ech3-cdn07.prod> References: <1691001311.792687.1254769697238.JavaMail.app@ech3-cdn07.prod> Message-ID: <4ACA4646.5000409@evaristesys.com> Fail. Zahid Hassan wrote: > LinkedIn > ------------ > > Zahid Hassan pidi? a?adirte como contacto en LinkedIn: > ------------------------------------------ > > Sebasti?n, > > I'd like to add you to my professional network on LinkedIn. > > - Zahid > > Aceptar invitaci?n de Zahid Hassan > http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1483081203_2/pmpxnSRJrSdvj4R5fnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_cBYPc38Ne30Pe3gNiiZTlPlIgABArOYRdzoUdzwUdPsLrCBxbOYWrSlI/EML_comm_afe/ > > Ver invitaci?n de Zahid Hassan > http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1483081203_2/39vcP0OcjwMcPwQckALqnpPbOYWrSlI/svi/ > > ------------------------------------------ > > ?Por qu? puede ser una buena idea conectar con Zahid Hassan? > > La gente que conoce a Zahid Hassan podr?a descubrir tu perfil: > Conectar con Zahid Hassan atraer? la atenci?n de otros usuarios de LinkedIn. Averigua qui?n ha visto tu perfil: > > http://www.linkedin.com/e/wvp/inv18_wvmp/ > > > ------ > (c) 2009, LinkedIn Corporation > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 From achatz at forthnet.gr Mon Oct 5 15:49:45 2009 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Mon, 05 Oct 2009 22:49:45 +0300 Subject: [c-nsp] does PBR apply to traffic from connected interfaces to router itself? Message-ID: <4ACA4DD9.10608@forthnet.gr> I'm doing some tests and i have a case where a vpdn user is able to send snmp requests to the router's loopback where he's connected, although i have a route-map under his vtemplate sending all snmp to null0. I have verified that snmp cannot go outside of router (so route-map is indeed working), but i had the impression that he shouldn't be able to snmp anobody, including the router itself. There is a trick, because vtemplate is using Loopback's ip, but i don't know if that's the reason snmp is allowed to "bypass" the route-map. ip access-list extended SNMP-ACL permit udp any any eq snmp route-map TEST-ROUTEMAP permit 10 match ip address SNMP-ACL set interface Null0 interface Virtual-Template1 ip unnumbered Loopback0 ip policy route-map TEST-ROUTEMAP Router is a 7200 running 12.2(31)SB14. I'm going to repeat the test using icmp, but it seems quite strange until now. PS1 : Local PBR is used for router generated traffic (router=src), so it shouldn't have any effect in my case. PS2 : I know there are other ways to stop snmp traffic from reaching the router or to block snmp traffic leaving an interface, but that's not my issue right now. -- Tassos From jay at west.net Mon Oct 5 15:50:24 2009 From: jay at west.net (Jay Hennigan) Date: Mon, 05 Oct 2009 12:50:24 -0700 Subject: [c-nsp] Invitation to connect on LinkedIn In-Reply-To: <4ACA4646.5000409@evaristesys.com> References: <1691001311.792687.1254769697238.JavaMail.app@ech3-cdn07.prod> <4ACA4646.5000409@evaristesys.com> Message-ID: <4ACA4E00.60606@west.net> Alex Balashov wrote: > Fail. Fail indeed. Why anyone would provide their email password to sites which guarantee to spam every address they can find 1s surprising. Why anyone on this list would do so is mind-boggling. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jp at saucer.midcoast.com Mon Oct 5 15:54:09 2009 From: jp at saucer.midcoast.com (jp) Date: Mon, 5 Oct 2009 15:54:09 -0400 Subject: [c-nsp] Enclosed rack with filtered air In-Reply-To: References: Message-ID: <20091005195409.GA6978@saucer.midcoast.com> A minor reconfiguration to positive pressure would prevent dust from getting sucked in. Put the filter on the bottom, then the fan drawing air through the filter, then it will create a small pressure inside the cabient, keeping dust out, except that which might leak through or around the filter element. On Sat, Oct 03, 2009 at 10:37:28AM -0500, scott owens wrote: > Hello, > I need to put two 6509s in a non-clean warehouse. I thought I could just > put them in a standard rack with some AC filters attached to the bottom and > let the air get pulled out of the top. However the rack is not airtight > enough and I am getting a lot of drywall/dust in the rack and switches. > > Anyone here know where / how to find a semi-sealed enclosed rack with > filtered forced air ? > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- /* Jason Philbrook | Midcoast Internet Solutions - Wireless and DSL KB1IOJ | Broadband Internet Access, Dialup, and Hosting http://f64.nu/ | for Midcoast Maine http://www.midcoast.com/ */ From irsk.inc at gmail.com Mon Oct 5 14:35:16 2009 From: irsk.inc at gmail.com (Inder Rishi Singh Kochar) Date: Mon, 5 Oct 2009 11:35:16 -0700 (PDT) Subject: [c-nsp] Invitation to connect on LinkedIn Message-ID: <748005571.750796.1254767716725.JavaMail.app@ech3-cdn13.prod> LinkedIn ------------ Inder Rishi Singh Kochar pidi? a?adirte como contacto en LinkedIn: ------------------------------------------ Sebasti?n, I'd like to add you to my professional network on LinkedIn. - Inder Rishi Singh Aceptar invitaci?n de Inder Rishi Singh Kochar http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1482978773_2/pmpxnSRJrSdvj4R5fnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_cBYPdPsUdPAOe3gNiiZhj5kUrnpOtiYSdz8Rc3wUdPsLrCBxbOYWrSlI/EML_comm_afe/ Ver invitaci?n de Inder Rishi Singh Kochar http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1482978773_2/39vcPsTe3sVczwQckALqnpPbOYWrSlI/svi/ ------------------------------------------ ?Por qu? puede ser una buena idea conectar con Inder Rishi Singh Kochar? Los contactos de Inder Rishi Singh Kochar podr?an serte ?tiles: Tras aceptar la invitaci?n de Inder Rishi Singh Kochar, revisa los contactos de Inder Rishi Singh Kochar para ver a qui?n m?s conoces y a qui?n te gustar?a que te presentaran. Forjar contactos puede crear oportunidades futuras. ------ (c) 2009, LinkedIn Corporation From jp at saucer.midcoast.com Mon Oct 5 16:03:10 2009 From: jp at saucer.midcoast.com (jp) Date: Mon, 5 Oct 2009 16:03:10 -0400 Subject: [c-nsp] facebook related In-Reply-To: <20091001200616.GK9785@1-4-5.net> References: <20091001200616.GK9785@1-4-5.net> Message-ID: <20091005200310.GB6978@saucer.midcoast.com> Which Cisco router are you? [obnoxious moving graphics] Congratulation; You are the 7500 series; you are power hungry, warm, impressive looking, and traditional. Watch out; Geeks are attracted to your pretty color and impressive presence. See what routers your friends are. If you want to know someone's IP address, send them in a message a unique URL to visit (or inline hyperlinked image in email) from a webserver you control, then watch the logs for their visit. On Thu, Oct 01, 2009 at 01:06:16PM -0700, Tony Tauber wrote: > Aww. I thought this was going to introduce the Facebook app > "IOS Upgrade Manager" which enables you to navigate www.cisco.com by > using Facebook. Answer burning questions like : > "If your friends were IOS software, which train/version would they be?" > Or games like "Two of your friends configured EIGRP using Protocol Wars". > > Well, there's still hope for the future. > > Tony > > On Thu, Oct 01, 2009 at 01:07:22PM -0400, Justin M. Streiner wrote: > > On Thu, 1 Oct 2009, Mohammad Khalil wrote: > > > >> I was asked today if i recieved a message on facebook can i know the > >> ip address of the sender > > > > My guess is that you will not see the IP address of the sender when > > you receive a message through Facebook. Facebook doesn't present > > full message headers on messages that are sent through the website. > > Since all communication happens through the website, that provides a > > layer of abstraction if Facebook/Myspace/insert_portal_here chooses > > not to reveal the sender's IP address to you. > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- /* Jason Philbrook | Midcoast Internet Solutions - Wireless and DSL KB1IOJ | Broadband Internet Access, Dialup, and Hosting http://f64.nu/ | for Midcoast Maine http://www.midcoast.com/ */ From ras at e-gerbil.net Mon Oct 5 16:04:50 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 5 Oct 2009 15:04:50 -0500 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <4ACA0B77.5090106@inex.ie> References: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net> <4ACA0B77.5090106@inex.ie> Message-ID: <20091005200450.GZ51443@gerbil.cluepon.net> On Mon, Oct 05, 2009 at 04:06:31PM +0100, Nick Hilliard wrote: > Depends on what you do with them. They are a first generation blade, and > are 6yo technology at this stage and, well, things have moved on since > 2003. XENPAK is moribund as a transceiver type which means that any money > you invest into buying transceivers will probably be written off when you > retire the blade. Don't forget they are absurdly under-buffered (16MB per card, compared to 256MB for 6708), and you can easily cause head of line blocking with certain traffic profiles. If you want to run anywhere close to line rate on them you need to monitor for drops or overruns and be prepared to play the port shuffle game to find an arrangement that works. Passing a lot of traffic within the same fabric channel (from port 1<->2, or 3<->4) is the biggest sin, it will start dropping at 7 Gbps. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From streiner at cluebyfour.org Mon Oct 5 16:32:03 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 5 Oct 2009 16:32:03 -0400 (EDT) Subject: [c-nsp] Invitation to connect on LinkedIn In-Reply-To: <748005571.750796.1254767716725.JavaMail.app@ech3-cdn13.prod> References: <748005571.750796.1254767716725.JavaMail.app@ech3-cdn13.prod> Message-ID: Fail, yet again. Would an inbound filter in mailman to nuke any message with a subject of "Invitation to connect on LinkedIn" with an appropriate nastygram back to the sender be feasible? Silently dropping the message would be OK too, I think. jms On Mon, 5 Oct 2009, Inder Rishi Singh Kochar wrote: > LinkedIn > ------------ > > Inder Rishi Singh Kochar pidi? a?adirte como contacto en LinkedIn: > ------------------------------------------ > > Sebasti?n, > > I'd like to add you to my professional network on LinkedIn. > > - Inder Rishi Singh > > Aceptar invitaci?n de Inder Rishi Singh Kochar > http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1482978773_2/pmpxnSRJrSdvj4R5fnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_cBYPdPsUdPAOe3gNiiZhj5kUrnpOtiYSdz8Rc3wUdPsLrCBxbOYWrSlI/EML_comm_afe/ > > Ver invitaci?n de Inder Rishi Singh Kochar > http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1482978773_2/39vcPsTe3sVczwQckALqnpPbOYWrSlI/svi/ > > ------------------------------------------ > > ?Por qu? puede ser una buena idea conectar con Inder Rishi Singh Kochar? > > Los contactos de Inder Rishi Singh Kochar podr?an serte ?tiles: > Tras aceptar la invitaci?n de Inder Rishi Singh Kochar, revisa los contactos de Inder Rishi Singh Kochar para ver a qui?n m?s conoces y a qui?n te gustar?a que te presentaran. Forjar contactos puede crear oportunidades futuras. > > > ------ > (c) 2009, LinkedIn Corporation > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From gsgranados at comcast.net Mon Oct 5 16:32:02 2009 From: gsgranados at comcast.net (Scott Granados) Date: Mon, 5 Oct 2009 13:32:02 -0700 Subject: [c-nsp] Invitation to connect on LinkedIn References: <748005571.750796.1254767716725.JavaMail.app@ech3-cdn13.prod> Message-ID: <028801ca45fa$eac72260$2408120a@am.thmulti.com> Oh I don't know, sometimes it's nice to see the clueless in action, especially during the vendor selection process.:) ----- Original Message ----- From: "Justin M. Streiner" To: "Sebasti??n Veloso Varas" Sent: Monday, October 05, 2009 1:32 PM Subject: Re: [c-nsp] Invitation to connect on LinkedIn Fail, yet again. Would an inbound filter in mailman to nuke any message with a subject of "Invitation to connect on LinkedIn" with an appropriate nastygram back to the sender be feasible? Silently dropping the message would be OK too, I think. jms On Mon, 5 Oct 2009, Inder Rishi Singh Kochar wrote: > LinkedIn > ------------ > > Inder Rishi Singh Kochar pidi? a?adirte como contacto en LinkedIn: > ------------------------------------------ > > Sebasti?n, > > I'd like to add you to my professional network on LinkedIn. > > - Inder Rishi Singh > > Aceptar invitaci?n de Inder Rishi Singh Kochar > http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1482978773_2/pmpxnSRJrSdvj4R5fnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_cBYPdPsUdPAOe3gNiiZhj5kUrnpOtiYSdz8Rc3wUdPsLrCBxbOYWrSlI/EML_comm_afe/ > > Ver invitaci?n de Inder Rishi Singh Kochar > http://www.linkedin.com/e/vyPV953ymgwhJZim_QSTkIEJ407GCYbmqcvZFAK/blk/I1482978773_2/39vcPsTe3sVczwQckALqnpPbOYWrSlI/svi/ > > ------------------------------------------ > > ?Por qu? puede ser una buena idea conectar con Inder Rishi Singh Kochar? > > Los contactos de Inder Rishi Singh Kochar podr?an serte ?tiles: > Tras aceptar la invitaci?n de Inder Rishi Singh Kochar, revisa los > contactos de Inder Rishi Singh Kochar para ver a qui?n m?s conoces y a > qui?n te gustar?a que te presentaran. Forjar contactos puede crear > oportunidades futuras. > > > ------ > (c) 2009, LinkedIn Corporation > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From bacon at walleyesoftware.com Mon Oct 5 16:47:05 2009 From: bacon at walleyesoftware.com (Jeff Bacon) Date: Mon, 5 Oct 2009 15:47:05 -0500 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: References: Message-ID: <5A69C25361FED34F83ABF05F50475245072BC11C@wally.walleyetrading.net> > Don't forget they are absurdly under-buffered (16MB per card, compared > to 256MB for 6708), and you can easily cause head of line blocking with > certain traffic profiles. If you want to run anywhere close to line rate > on them you need to monitor for drops or overruns and be prepared to > play the port shuffle game to find an arrangement that works. Passing a > lot of traffic within the same fabric channel (from port 1<->2, or > 3<->4) is the biggest sin, it will start dropping at 7 Gbps. Well that's wonderfully comforting. Though I really probably only need two ports anyway - ring-in and ring-out. Maybe not so bad. I'd consider a 720-VS-10G head if I had some confidence that those two ports on the sup were actually connected to the fabric. I don't really need to run line rate - this is more about latency and burst capacity than sustained throughput. I have loads that burst from 0 to 500Mb/sec (then back) in nothing flat, and multiple of those may run through the wire at the same time. Or not. Someone pointed out that the X2 and SFP+ xcvrs don't have much punch, and I'm going to be shooting 20-30km through passive MUXes. So that might matter. (This is a bit of a roll-yer-own local metro NYC ring, which I'm doing because I can get the wave for not much more than I'd pay for the switched gig.) From justin at justinshore.com Mon Oct 5 17:52:06 2009 From: justin at justinshore.com (Justin Shore) Date: Mon, 05 Oct 2009 16:52:06 -0500 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <200910032018.54836.mtinka@globaltransit.net> References: <20091002141556.GR1508@greenie.muc.de> <200910032018.54836.mtinka@globaltransit.net> Message-ID: <4ACA6A86.3040907@justinshore.com> Mark Tinka wrote: > We've seen strange issues with converters were providers > were unable to guarantee Jumbo frame MTU sizes because the > media converters don't support them - what the hell... This happened to me with Versitron MCs. I had a set in production that worked perfectly fine. Then one day BGP started flapping. A lengthy period of time for troubleshooting later it was finally determined that the damn MCs suddenly started filtering jumbos in only 1 direction. I hope that doesn't hold true for some of my other more important Versitron GigE links where I have 8 of the very same model back to back... Justin From ras at e-gerbil.net Mon Oct 5 17:59:34 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 5 Oct 2009 16:59:34 -0500 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC11C@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC11C@wally.walleyetrading.net> Message-ID: <20091005215933.GA51443@gerbil.cluepon.net> On Mon, Oct 05, 2009 at 03:47:05PM -0500, Jeff Bacon wrote: > Well that's wonderfully comforting. Though I really probably only need > two ports anyway - ring-in and ring-out. Maybe not so bad. I'd consider > a 720-VS-10G head if I had some confidence that those two ports on the > sup were actually connected to the fabric. Can't tell you anything about the VS-10G, but if you're doing it on 6704 make sure you use 1 and 3, or 2 and 4, not 1->2 etc. Unfortunately I have to deal with many hundreds of 10GE ports on 6704s (what can I say, they're cheap :P), so we tend to try to pair them up as port-channels (i.e. members 1/1 and 1/2, 2/1 and 2/2, etc) since this guarantees traffic will never go in port 1 and out port 2 on any given fabric channel. > I don't really need to run line rate - this is more about latency and > burst capacity than sustained throughput. I have loads that burst from 0 > to 500Mb/sec (then back) in nothing flat, and multiple of those may run > through the wire at the same time. Or not. Yeah ok that won't challenge pretty much any hardware. :) > Someone pointed out that the X2 and SFP+ xcvrs don't have much punch, > and I'm going to be shooting 20-30km through passive MUXes. So that > might matter. X2 is nothing more than a physically smaller XENPAK case, the interface and for the most part the components (if you take apart a modern XENPAK, you'll see most of it is empty space) are exactly the same. Basically X2 only exists so lazy companies who don't want to redesign their boards (Hi Cisco!) can keep using the same components from their old XENPAK designs. SFP+ is an entirely different beast, two generations removed from XENPAK (XENPAK->XFP->SFP), and with very low max power caps which prevent it from being used for most long reach/DWDM applications. Basically SFP+ only exists so you can stuff 48 10GE ports into a blade or 1U switch, but it's really only useful if you need to do a large number of short reach ports (i.e. datacenter aggregation). The only redeeming quality of SFP+ is you can finally get LR for them (I won't touch SR outside of same-rack applications, way too many problems) at not unreasonable prices. XFP is still the best all-around optics platform for the full range of features, but unfortunately you'll see less and less focus here as everyone jumps on the SFP+ bandwagon as "the next new thing" even when it is completely unnecessary and infact only serves to limit function. Slightly dated now (from feb 08) but mostly still accurate: http://www.nanog.org/meetings/nanog42/presentations/pluggables.pdf -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From tdurack at gmail.com Mon Oct 5 21:24:11 2009 From: tdurack at gmail.com (Tim Durack) Date: Mon, 5 Oct 2009 21:24:11 -0400 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC11C@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC11C@wally.walleyetrading.net> Message-ID: <9e246b4d0910051824j461bc286i33f41d332732dea8@mail.gmail.com> > Well that's wonderfully comforting. Though I really probably only need > two ports anyway - ring-in and ring-out. Maybe not so bad. I'd consider > a 720-VS-10G head if I had some confidence that those two ports on the > sup were actually connected to the fabric. The 10Gig ports on the VS-S720 are fabric attached. > I don't really need to run line rate - this is more about latency and > burst capacity than sustained throughput. I have loads that burst from 0 > to 500Mb/sec (then back) in nothing flat, and multiple of those may run > through the wire at the same time. Or not. I think lots of people are in the latency not bandwidth situation. That's probably why most vendors aren't producing dense 10Gig cards yet. We have the situation where GigE latency is too high for some apps, but 10Gig is okay. > Someone pointed out that the X2 and SFP+ xcvrs don't have much punch, > and I'm going to be shooting 20-30km through passive MUXes. So that > might matter Opnext claims ER SFP+. Haven't seen anyone doing ZR or anything more exotic yet. Sure it will come though. Something FEC/EFEC in the 200km range would be interesting for many people. -- Tim:> Sent from New York, NY, United States From tdurack at gmail.com Mon Oct 5 21:32:15 2009 From: tdurack at gmail.com (Tim Durack) Date: Mon, 5 Oct 2009 21:32:15 -0400 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC11C@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC11C@wally.walleyetrading.net> Message-ID: <9e246b4d0910051832y667a4e40y336fb00a0b44eaaf@mail.gmail.com> We've selected the 6708 for our 10Gig installs. DFCs and good sized buffers. Lots of availability on the used market. Can be run in line-rate or over-subscribed mode, which might suit your deployment. I have hopes for SFP+ linecards to drive 10Gig costs down, but I don't think much is going to happen until 40Gig/100Gig is the new backbone. Tim:> On Mon, Oct 5, 2009 at 4:47 PM, Jeff Bacon wrote: >> Don't forget they are absurdly under-buffered (16MB per card, compared >> to 256MB for 6708), and you can easily cause head of line blocking > with >> certain traffic profiles. If you want to run anywhere close to line > rate >> on them you need to monitor for drops or overruns and be prepared to >> play the port shuffle game to find an arrangement that works. Passing > a >> lot of traffic within the same fabric channel (from port 1<->2, or >> 3<->4) is the biggest sin, it will start dropping at 7 Gbps. > > Well that's wonderfully comforting. Though I really probably only need > two ports anyway - ring-in and ring-out. Maybe not so bad. I'd consider > a 720-VS-10G head if I had some confidence that those two ports on the > sup were actually connected to the fabric. > > I don't really need to run line rate - this is more about latency and > burst capacity than sustained throughput. I have loads that burst from 0 > to 500Mb/sec (then back) in nothing flat, and multiple of those may run > through the wire at the same time. Or not. > > Someone pointed out that the X2 and SFP+ xcvrs don't have much punch, > and I'm going to be shooting 20-30km through passive MUXes. So that > might matter. > > (This is a bit of a roll-yer-own local metro NYC ring, which I'm doing > because I can get the wave for not much more than I'd pay for the > switched gig.) > > _______________________________________________ > cisco-nsp mailing list ?cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- Tim:> Sent from New York, NY, United States From mtinka at globaltransit.net Mon Oct 5 17:41:14 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 6 Oct 2009 05:41:14 +0800 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <4ACA0B77.5090106@inex.ie> References: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net> <4ACA0B77.5090106@inex.ie> Message-ID: <200910060541.19686.mtinka@globaltransit.net> On Monday 05 October 2009 11:06:31 pm Nick Hilliard wrote: > As I said, it depends on what you want to do. If you're > running just a couple of gigs and don't care about the > broadcast traffic problem or, say, are using them for L3 > traffic instead of L2, then they are great. Similarly, > the C65k+sup720 platform makes a really nice high > density, feature rich 1G platform. But if you're > planning to run lots of very high bandwidth stuff, it > might be better to use a different platform. From Cisco, I think that if the goal is to aggregate n x 10Gbps Ethernet in abundance, for pure Layer 2 core switching over a limited distance (within the data centre), the Nexus 5000 might not be such a bad consideration. Preliminary pricing for this vs. a couple of WS-X6708 is comparable, and better in certain cases. YMMV. That said, it's also clear the 6500 isn't done yet, and it's still got a number of tricks up its sleeve. The question is, "Will you wait?". Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From v.jones at networkingunlimited.com Mon Oct 5 22:48:24 2009 From: v.jones at networkingunlimited.com (Vincent C Jones) Date: Mon, 05 Oct 2009 22:48:24 -0400 Subject: [c-nsp] does PBR apply to traffic from connected interfaces to router itself? In-Reply-To: <4ACA4DD9.10608@forthnet.gr> References: <4ACA4DD9.10608@forthnet.gr> Message-ID: <1254797304.6125.47.camel@X61.NetworkingUnlimited.nul> On Mon, 2009-10-05 at 22:49 +0300, Tassos Chatzithomaoglou wrote: > I'm doing some tests and i have a case where a vpdn user is able to send snmp requests to > the router's loopback where he's connected, although i have a route-map under his > vtemplate sending all snmp to null0. I have verified that snmp cannot go outside of router > (so route-map is indeed working), but i had the impression that he shouldn't be able to > snmp anobody, including the router itself. > > There is a trick, because vtemplate is using Loopback's ip, but i don't know if that's the > reason snmp is allowed to "bypass" the route-map. > > ip access-list extended SNMP-ACL > permit udp any any eq snmp > > route-map TEST-ROUTEMAP permit 10 > match ip address SNMP-ACL > set interface Null0 > > interface Virtual-Template1 > ip unnumbered Loopback0 > ip policy route-map TEST-ROUTEMAP > > > Router is a 7200 running 12.2(31)SB14. > I'm going to repeat the test using icmp, but it seems quite strange until now. > > PS1 : Local PBR is used for router generated traffic (router=src), so it shouldn't have > any effect in my case. > > PS2 : I know there are other ways to stop snmp traffic from reaching the router or to > block snmp traffic leaving an interface, but that's not my issue right now. Cisco loopback interfaces are not like normal interfaces. Apply the policy globally using the "ip local policy route-map TEST-ROUTEMAP" command. Royal pain because if you have multiple loopbacks and want a different policy on each, you need to define all choices in a single monster policy. Vince -- Vincent C Jones Networking Unlimited, Inc 14 Dogwood Lane, Tenafly NJ Voice: 201 568-7810 From jckdaniels12 at gmail.com Tue Oct 6 02:27:43 2009 From: jckdaniels12 at gmail.com (jack daniels) Date: Tue, 6 Oct 2009 11:57:43 +0530 Subject: [c-nsp] multilink doc Message-ID: <8bb137f40910052327p223c05cbpd332f764353ff4d5@mail.gmail.com> Hi , Please help me with any doc which states about multilink regarding " MULTILINK SHOULD NOT have its L2 links from diffrent service providers or with diffrent delay" <<<<< but bandwidth of links is same in my case. We are having some issues of slowness while accessing citrix application across multilink. Thanks and Regards From gkg at gmx.de Tue Oct 6 03:09:34 2009 From: gkg at gmx.de (Garry) Date: Tue, 06 Oct 2009 09:09:34 +0200 Subject: [c-nsp] multilink doc In-Reply-To: <8bb137f40910052327p223c05cbpd332f764353ff4d5@mail.gmail.com> References: <8bb137f40910052327p223c05cbpd332f764353ff4d5@mail.gmail.com> Message-ID: <4ACAED2E.8090506@gmx.de> jack daniels wrote: > Hi , > > Please help me with any doc which states about multilink regarding " > MULTILINK SHOULD NOT have its L2 links from diffrent service providers or > with diffrent delay" <<<<< but bandwidth of links is same in my case. > We are having some issues of slowness while accessing citrix application > across multilink. > General info on the workings of MPPP (assuming this is what you are using): Multilink PPP splits up packets between the links involved. If you have different line speeds, or more than nominal latency differences, the transmission will be as slow as the slowest link, or might fail completely ... also, errors on one link will cause performance degradation, as the whole packet is retransmitted ... Don't have a doc handy at the moment ... If you have different lines, albeit with same speed, and do not need the combined speed for single flows (which I assume from you mentioning Citrix), you could always set up two separate links with same routes going over both ... that way, traffic will be distributed among the links, with overall less impact by the slower link ... -garry From asturluismi at gmail.com Tue Oct 6 06:00:47 2009 From: asturluismi at gmail.com (luismi) Date: Tue, 06 Oct 2009 12:00:47 +0200 Subject: [c-nsp] Recommendations for IOS 12.4T for 7206VXR NPE-G2 Message-ID: <1254823247.10811.6.camel@dsba-ipso> Any recommendation? Technologies used: BGP, EIGRP.VRF, RACL, ACL, uRPF, AAA, GRE. EtherChannel From asturluismi at gmail.com Tue Oct 6 06:05:04 2009 From: asturluismi at gmail.com (luismi) Date: Tue, 06 Oct 2009 12:05:04 +0200 Subject: [c-nsp] Cisco 3750 Stack less disruptive EtherChannel configuration Message-ID: <1254823504.10811.11.camel@dsba-ipso> Hi, We had a problem with a stack 3750 here and the configuration is.. Stack (2x3750) === FEC === SW 2960 It is a cross etherchannel configuration. 3750 is not working with L3 mode at all. The FEC config is "mode on". So, one the 3750 had a problem yesterday and it creates disruption in the connectivity with the 2960 switches. I didn't expect from Etherchannel. It is supossed that is pretty fast but it was not. I would like to see if there is anyone here with a similar configuration or other one to fix this situation. Any comment is welcome From reuben-cisco-nsp at reub.net Tue Oct 6 06:23:22 2009 From: reuben-cisco-nsp at reub.net (Reuben Farrelly) Date: Tue, 06 Oct 2009 21:23:22 +1100 Subject: [c-nsp] Recommendations for IOS 12.4T for 7206VXR NPE-G2 In-Reply-To: <1254823247.10811.6.camel@dsba-ipso> References: <1254823247.10811.6.camel@dsba-ipso> Message-ID: <4ACB1A9A.3060609@reub.net> I'd suggest you have two choices: 1. Jump straight to 15.0 mainline rather than run 12.4T. You can of course go to 12.4T but as 15.0(1) mainline superseeds and includes bug fixes from 12.4(24)T it will be the new stable train going forward. You could say that 15.0(1) is not that well tested, well, 12.4(24)T is still a bit rough around some edges too.... 2. Run 12.4(15)T10 which seems to have been the best stable 12.4T release so far. Reuben luismi wrote: > Any recommendation? > Technologies used: BGP, EIGRP.VRF, RACL, ACL, uRPF, AAA, GRE. > EtherChannel From sjuon74 at gmail.com Tue Oct 6 08:04:08 2009 From: sjuon74 at gmail.com (Stefan Juon) Date: Tue, 6 Oct 2009 14:04:08 +0200 Subject: [c-nsp] vrf-lite over a layer3 link Message-ID: Hi all This is my first post to this list, so I guess I should say hello ;-) We are considering an advanced network design which allows us to separate several services or customers using vrf-lite. There are some local sites which are connected by our own cabling. Nevertheless there are also some remote sites which are connected over a provider which provides common layer3 links. I understand that vrf-lite uses vlan's to separate the customers between ce and pe, I have seen these in all the examples I already read. As supposely no provider supports vlan's but rather layer 3 lines the big question is: How to span a network using vrf-lite over a provider? Thanks for any ideas. From rwest at zyedge.com Tue Oct 6 08:07:41 2009 From: rwest at zyedge.com (Ryan West) Date: Tue, 6 Oct 2009 08:07:41 -0400 Subject: [c-nsp] Cisco 3750 Stack less disruptive EtherChannel configuration In-Reply-To: <1254823504.10811.11.camel@dsba-ipso> References: <1254823504.10811.11.camel@dsba-ipso> Message-ID: <5DE002B0-173F-4A3D-8208-8F41A3D8DD29@zyedge.com> Might want to consider LACP for better fault detection. Sent from handheld. On Oct 6, 2009, at 6:18 AM, "luismi" wrote: > Hi, > > We had a problem with a stack 3750 here and the configuration is.. > > Stack (2x3750) === FEC === SW 2960 > > It is a cross etherchannel configuration. > 3750 is not working with L3 mode at all. > > The FEC config is "mode on". > So, one the 3750 had a problem yesterday and it creates disruption in > the connectivity with the 2960 switches. I didn't expect from > Etherchannel. It is supossed that is pretty fast but it was not. > > I would like to see if there is anyone here with a similar > configuration > or other one to fix this situation. > Any comment is welcome > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From drrtuy at ya.ru Tue Oct 6 08:42:18 2009 From: drrtuy at ya.ru (Roman A. Nozdrin) Date: Tue, 06 Oct 2009 15:42:18 +0300 Subject: [c-nsp] vrf-lite over a layer3 link In-Reply-To: References: Message-ID: <4ACB3B2A.60708@ya.ru> Hello. > This is my first post to this list, so I guess I should say hello ;-) > We are considering an advanced network design which allows us to separate > several services or customers using vrf-lite. There are some local sites > which are connected by our own cabling. Nevertheless there are also some > remote sites which are connected over a provider which provides common > layer3 links. I understand that vrf-lite uses vlan's to separate the > customers between ce and pe, I have seen these in all the examples I already > read. As supposely no provider supports vlan's but rather layer 3 lines the > big question is: How to span a network using vrf-lite over a provider? In this particular situation I would prefer tunnelling technologies to tie remote POPs. You can put tunnels into different vrfs and forward VRFs' traffic through respective tunnel next hop using static or dynamic routing. If the ISP can route Your customers prefixes You can also take a difficult way. Your networks edge router can merge all the customers' routes before the ISP segment using route leaking feature. The other edge router will redistribute the routes back to VRFs using the same feature. WBR Roman A. Nozdrin From Ian.Mackinnon at lumison.net Tue Oct 6 08:08:25 2009 From: Ian.Mackinnon at lumison.net (Ian MacKinnon) Date: Tue, 6 Oct 2009 13:08:25 +0100 Subject: [c-nsp] vrf-lite over a layer3 link In-Reply-To: References: Message-ID: You need to tunnel it :-) GRE is one option, and there is some info about this in the Building MPLS Based Broadband Access VPNs book -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Stefan Juon Sent: 06 October 2009 13:04 To: cisco-nsp at puck.nether.net Subject: [c-nsp] vrf-lite over a layer3 link Hi all This is my first post to this list, so I guess I should say hello ;-) We are considering an advanced network design which allows us to separate several services or customers using vrf-lite. There are some local sites which are connected by our own cabling. Nevertheless there are also some remote sites which are connected over a provider which provides common layer3 links. I understand that vrf-lite uses vlan's to separate the customers between ce and pe, I have seen these in all the examples I already read. As supposely no provider supports vlan's but rather layer 3 lines the big question is: How to span a network using vrf-lite over a provider? Thanks for any ideas. _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.420 / Virus Database: 270.14.3/2415 - Release Date: 10/05/09 18:23:00 -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. From jeff-kell at utc.edu Tue Oct 6 08:51:51 2009 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 06 Oct 2009 08:51:51 -0400 Subject: [c-nsp] vrf-lite over a layer3 link In-Reply-To: References: Message-ID: <4ACB3D67.6040207@utc.edu> Stefan Juon wrote: > I understand that vrf-lite uses vlan's to separate the > customers between ce and pe, I have seen these in all the examples I already > read. As supposely no provider supports vlan's but rather layer 3 lines the > big question is: How to span a network using vrf-lite over a provider? The suggested method is to use GRE tunneling for each VRF instance over the global L3 link. This is a very platform/software dependent feature and will likely be process switched if supported at all. I have done this for one local VRF simply to get end-to-edge connectivity for an isolated, low-traffic instance without having to drill the L2 vlan through the entire local path. Jeff From david.freedman at uk.clara.net Tue Oct 6 09:03:12 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 06 Oct 2009 14:03:12 +0100 Subject: [c-nsp] vrf-lite over a layer3 link In-Reply-To: References: Message-ID: <4ACB4010.60403@uk.clara.net> If you don't have overlapping subnets and are brave, you could try vrf source-select or vrf pbr , with "global" next hops (since both of these techniques create a half-duplex vrf situation), this avoids the mess of tunnels and their packet overheads, but introduces another mess (and potentially security hole) of its own :) Dave. Ian MacKinnon wrote: > You need to tunnel it :-) > GRE is one option, and there is some info about this in the Building MPLS Based Broadband Access VPNs book > > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Stefan Juon > Sent: 06 October 2009 13:04 > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] vrf-lite over a layer3 link > > Hi all > This is my first post to this list, so I guess I should say hello ;-) > We are considering an advanced network design which allows us to separate > several services or customers using vrf-lite. There are some local sites > which are connected by our own cabling. Nevertheless there are also some > remote sites which are connected over a provider which provides common > layer3 links. I understand that vrf-lite uses vlan's to separate the > customers between ce and pe, I have seen these in all the examples I already > read. As supposely no provider supports vlan's but rather layer 3 lines the > big question is: How to span a network using vrf-lite over a provider? > > Thanks for any ideas. > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.420 / Virus Database: 270.14.3/2415 - Release Date: 10/05/09 18:23:00 > > -- > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the sender. Any > offers or quotation of service are subject to formal specification. > Errors and omissions excepted. Please note that any views or opinions > presented in this email are solely those of the author and do not > necessarily represent those of Lumison. > Finally, the recipient should check this email and any attachments for the > presence of viruses. Lumison accept no liability for any > damage caused by any virus transmitted by this email. > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From david.freedman at uk.clara.net Tue Oct 6 09:03:12 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 06 Oct 2009 14:03:12 +0100 Subject: [c-nsp] vrf-lite over a layer3 link In-Reply-To: References: Message-ID: <4ACB4010.60403@uk.clara.net> If you don't have overlapping subnets and are brave, you could try vrf source-select or vrf pbr , with "global" next hops (since both of these techniques create a half-duplex vrf situation), this avoids the mess of tunnels and their packet overheads, but introduces another mess (and potentially security hole) of its own :) Dave. Ian MacKinnon wrote: > You need to tunnel it :-) > GRE is one option, and there is some info about this in the Building MPLS Based Broadband Access VPNs book > > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Stefan Juon > Sent: 06 October 2009 13:04 > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] vrf-lite over a layer3 link > > Hi all > This is my first post to this list, so I guess I should say hello ;-) > We are considering an advanced network design which allows us to separate > several services or customers using vrf-lite. There are some local sites > which are connected by our own cabling. Nevertheless there are also some > remote sites which are connected over a provider which provides common > layer3 links. I understand that vrf-lite uses vlan's to separate the > customers between ce and pe, I have seen these in all the examples I already > read. As supposely no provider supports vlan's but rather layer 3 lines the > big question is: How to span a network using vrf-lite over a provider? > > Thanks for any ideas. > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.420 / Virus Database: 270.14.3/2415 - Release Date: 10/05/09 18:23:00 > > -- > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the sender. Any > offers or quotation of service are subject to formal specification. > Errors and omissions excepted. Please note that any views or opinions > presented in this email are solely those of the author and do not > necessarily represent those of Lumison. > Finally, the recipient should check this email and any attachments for the > presence of viruses. Lumison accept no liability for any > damage caused by any virus transmitted by this email. > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From alex at digriz.org.uk Tue Oct 6 08:56:05 2009 From: alex at digriz.org.uk (Alexander Clouter) Date: Tue, 6 Oct 2009 13:56:05 +0100 Subject: [c-nsp] Cisco 3750 Stack less disruptive EtherChannel configuration References: <1254823504.10811.11.camel@dsba-ipso> Message-ID: <5crrp6-7f2.ln1@chipmunk.wormnet.eu> luismi wrote: > > We had a problem with a stack 3750 here and the configuration is.. > > Stack (2x3750) === FEC === SW 2960 > > It is a cross etherchannel configuration. > 3750 is not working with L3 mode at all. > > The FEC config is "mode on". > We use 'active' as then it is using LACP and testing not just that the link is up but it is also successfully shifting packets over it; plus some other goodies. > So, one the 3750 had a problem yesterday and it creates disruption in > the connectivity with the 2960 switches. I didn't expect from > Etherchannel. It is supossed that is pretty fast but it was not. > > I would like to see if there is anyone here with a similar configuration > or other one to fix this situation. > > Any comment is welcome > Depends what the disruption was, as you are all L2, if it was the VLAN instance that was affected then that would be your longer than expected outage. The Etherchannel will only protect you from link failures on the Etherchannel, not from what might be happening inside that Etherchannel. Cheers -- Alexander Clouter .sigmonster says: Oh, I get it!! "The BEACH goes on", huh, SONNY?? From lists at memetic.org Tue Oct 6 10:39:41 2009 From: lists at memetic.org (Adam Armstrong) Date: Tue, 06 Oct 2009 15:39:41 +0100 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <4AC611B1.60509@inex.ie> References: <4AC608B5.6010804@inex.ie> <4AC60D05.20003@complicity.co.uk> <4AC611B1.60509@inex.ie> Message-ID: <4ACB56AD.5070008@memetic.org> Nick Hilliard wrote: > On 02/10/2009 15:24, Zoe O'Connell wrote: >> It's worth noting that while the restriction on optics in general is >> just annoying, the DOM restrictions do seem to be there for a reason: I >> have a number of non-Cisco optics reporting DOM data that's obviously >> incorrect, so I don't trust anything that's non-Cisco. Sadly, on >> platforms where it will show you DOM from any SFP, there's no obvious >> indication if it's a Cisco or third party optic. > > "show idprom interface gig x/y" should give you a pretty good idea of > what's plugged into the box (on a 65k). > > Yes, there are very poor quality transceivers out there. Cisco appears > to re-sell Finisar and Opnext, which would suggest that these > companies produce good quality kit. > > I'm personally not convinced that restricting equipment to use > own-brand transceivers does much more than create a lucrative grey > market for sophisticated knock-offs. I've also heard the incorrect > DOM readings line being trotted out before, but I'm not convinced by > it: if you buy cheap-ass equipment, you should expect high mileage > variation. FWIW: I have a great many Cisco SFPs sourced via Dimension Data (at ridiculously over-inflated cost, of course). I get varying degrees of bullshit back as DOM readings from quite a few of them. Sounds like more FUD to me. adam. From lists at memetic.org Tue Oct 6 11:27:54 2009 From: lists at memetic.org (Adam Armstrong) Date: Tue, 06 Oct 2009 16:27:54 +0100 Subject: [c-nsp] Will UDLD work with converters ? In-Reply-To: <200910032019.24083.mtinka@globaltransit.net> References: <4AC60DD9.6080207@justinshore.com> <200910032019.24083.mtinka@globaltransit.net> Message-ID: <4ACB61FA.7030003@memetic.org> Mark Tinka wrote: > On Friday 02 October 2009 10:27:37 pm Justin Shore wrote: > > >> It seems to me that there should be a standards body >> within Cisco that should mandate certain minimum >> requirements of all product lines. If and when there is >> the ability for BUs and product lines to share common and >> trivial products like SFPs then they should require it. >> It would save them R&D and QA money if nothing else. >> > > This is the thing I really like about "J". > > Across a specific series of platforms, e.g., M/T/MX, all > optics are shared, including SFP-to-copper modules. > > It's a real pity when you can no longer take such simple > pleasures for granted. > > I think Cisco's SPA technology is a step in the right > direction re: optical modules, since they're all shared > among the various platforms that support this interface > model, but I wonder how many of Cisco's customers will be > moving to the SIP/SPA format soon (and it likely won't be > because of common SFP/XFP sparing). > SPA allows them to keep costs in the stratosphere though, nothing like 6700 LAN cards in a SPA world... adam. From justin at justinshore.com Tue Oct 6 17:13:11 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 06 Oct 2009 16:13:11 -0500 Subject: [c-nsp] Problem encountered while securing NTP Message-ID: <4ACBB2E7.3090002@justinshore.com> Given the recent NTP PSIRT from Cisco (cisco-sa-20090923-ntp) I decided to spend the morning revisiting my NTP practices to lessen the chance of getting kicked in the teeth by this router-crashing bug later on. In my networks I usually have a pair (or more sometimes) of border routers as local NTP servers, advertising themselves internally as stratum-3. They use stratum-1s on the Internet in geographically diverse areas. The local network devices are configured to use both of the local NTP servers with authentication. Here's a border router's config: ntp authentication-key 1 md5 BLAHBLAHBLAH 7 ntp authenticate ntp trusted-key 1 ntp source Loopback1 ntp access-group peer 5 ntp access-group serve-only 6 ntp master 3 ntp update-calendar ntp server a.a.a.a prefer ntp server b.b.b.b ntp peer LOCAL.BORDER.RTR.TWO key 1 ntp server c.c.c.c ! access-list 5 remark NTP Peers access-list 5 permit 127.127.7.1 access-list 5 permit a.a.a.a. access-list 5 permit b.b.b.b access-list 5 permit c.c.c.c access-list 5 permit LOCAL.BORDER.RTR.ONE access-list 5 permit LOCAL.BORDER.RTR.TWO access-list 5 deny any log ! access-list 6 remark NTP Serve-Only access-list 6 permit LOCAL.NETWORK.MANAGEMENT.PREFIXES x.x.x.mask access-list 6 permit LOCAL.RIR.ASSIGNED.PREFIXES x.x.x.mask access-list 6 deny any log Here's a client device's config: ntp authentication-key 1 md5 105D020D0619061B4851 7 ntp authenticate ntp trusted-key 1 ntp clock-period 17179513 ntp source Vlan224 ntp access-group serve-only 6 ntp server 64.71.98.51 key 1 ntp server 64.71.98.59 key 1 ! access-list 6 remark NTP Serve-Only access-list 6 permit LOCAL.NETWORK.MANAGEMENT.PREFIXES x.x.x.mask access-list 6 permit LOCAL.RIR.ASSIGNED.PREFIXES x.x.x.mask access-list 6 deny any log (Same as above for simplicity's sake) That's my standard NTP config that I run on several networks without any real problems, normally. There may be other or better ways to help secure NTP that I either haven't implemented yet (iACLs, CoPP) or don't know about but I'm always open to suggestions. The problem I'm running into today is that the 'access-group peer' statements on the NTP servers are matching local clients with ACL 6 as well as configured stratum-1 peers (successfully matching the peers at that). The local clients should be matched with the 'access-group serve-only' ACL 6, but for some reason they are not. Strangely enough I have ACE counters increasing on ACL 6's lines that correspond to my network infrastructure, even though the 'deny any log' ACE in ACL 5 is also reporting denied hits for the very same subnets. It's as if I've freaked out NTP. I made changes to the ACL earlier today as part of my initial review. Then NTP for the network infrastructure stopped working. Could this be an IOS bug by chance? My next step is to blow away the NTP config from the borders, hopefully killing the NTP process at the same time, and re-add the config. Thoughts before I blow away the config and start over? Justin From kgraham at industrial-marshmallow.com Tue Oct 6 19:54:43 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Tue, 6 Oct 2009 16:54:43 -0700 (PDT) Subject: [c-nsp] Problem encountered while securing NTP In-Reply-To: <4ACBB2E7.3090002@justinshore.com> References: <4ACBB2E7.3090002@justinshore.com> Message-ID: <815825.32201.qm@web503.biz.mail.mud.yahoo.com> > The problem I'm running into today is that the 'access-group peer' statements on > the NTP servers are matching local clients with ACL 6 as well as configured > stratum-1 peers (successfully matching the peers at that). The local clients > should be matched with the 'access-group serve-only' ACL 6, but for some reason > they are not. CSCsw79186. Its broken more than the bug suggests; both v3 and v4 clients are get applied only to the 'peer' access-group. I had meant to bring this to PSIRT's attention when the advisory went out, but got distracted by something shiny. From jckdaniels12 at gmail.com Wed Oct 7 03:50:35 2009 From: jckdaniels12 at gmail.com (jack daniels) Date: Wed, 7 Oct 2009 13:20:35 +0530 Subject: [c-nsp] AUDIT Message-ID: <8bb137f40910070050n1e1e732aoca3d5ba4411debaa@mail.gmail.com> Dear Group, I have been assigned to do AUDIT ( LAN / WAN ) for a NETWORK comprising of devices 2950 , 3750 , 4500 , 2800 , 2600 , 7206 VXR . Please advice which commands showuld I need to conectrate more and check outputs for making audit report Thanks and Regards From justin at justinshore.com Wed Oct 7 03:51:46 2009 From: justin at justinshore.com (Justin Shore) Date: Wed, 07 Oct 2009 02:51:46 -0500 Subject: [c-nsp] Problem encountered while securing NTP In-Reply-To: <815825.32201.qm@web503.biz.mail.mud.yahoo.com> References: <4ACBB2E7.3090002@justinshore.com> <815825.32201.qm@web503.biz.mail.mud.yahoo.com> Message-ID: <4ACC4892.6010800@justinshore.com> Kevin Graham wrote: > CSCsw79186. Its broken more than the bug suggests; both v3 and v4 clients are > get applied only to the 'peer' access-group. I had meant to bring this to > PSIRT's attention when the advisory went out, but got distracted by something > shiny. Excellent catch. I tried to search the BugToolkit today for anything related to NTP and couldn't get it to work. I rebooted the router tonight and bumped the rev to 24T1 in hopes that it would fix the issue. It didn't. Clearly this problem isn't fixed as the BugToolkit indicates since there isn't a T-train release with the alleged fix in it. I'll hammer on them later today about this. I don't think that the severity of the problem is moderate as the bug notes indicate. For me it's severe since it's affecting NTP from our VoIP phones and soft switch. I think the PSIRT folks would also disagree with a failure of NTP being only a moderate issue too since logging with accurate timestamps is essential to any security model. Justin From asturluismi at gmail.com Wed Oct 7 04:33:57 2009 From: asturluismi at gmail.com (luismi) Date: Wed, 07 Oct 2009 10:33:57 +0200 Subject: [c-nsp] AUDIT In-Reply-To: <8bb137f40910070050n1e1e732aoca3d5ba4411debaa@mail.gmail.com> References: <8bb137f40910070050n1e1e732aoca3d5ba4411debaa@mail.gmail.com> Message-ID: <1254904437.7830.0.camel@dsba-ipso> nipper and rat (router audito tool) El mi?, 07-10-2009 a las 13:20 +0530, jack daniels escribi?: > Dear Group, > > I have been assigned to do AUDIT ( LAN / WAN ) for a NETWORK comprising of > devices 2950 , 3750 , 4500 , 2800 , 2600 , 7206 VXR . Please advice which > commands showuld I need to conectrate more and check outputs for making > audit report > > Thanks and Regards > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From anthony.mcgarry at plannet21.ie Wed Oct 7 06:23:56 2009 From: anthony.mcgarry at plannet21.ie (Anthony McGarry) Date: Wed, 7 Oct 2009 11:23:56 +0100 Subject: [c-nsp] ME3400 - Priority Queue Message-ID: <4ACC6C3C.2070209@plannet21.ie> Hi, From the following command I can see the egress priority queue is disabled on the port sh platform qos debug interface g0/12 queueing GigabitEthernet0/12 Egress Priority Queue : disabled Shaped queue weights (absolute) : 332 0 0 0 Shared queue weights : 0 255 255 1 The port bandwidth limit : 100 (Operational Bandwidth:100.0) The port is mapped to qset : 4 However I have a policy map with the voip class using police with the priority command. Service-policy output: test-vrf-out Class-map: qos-ef (match-any) 2475 packets Match: ip dscp ef (46) Priority police cir 3000000 bc 93750 conform-action transmit exceed-action drop conform: 2726 (packets) exceed: 0 (packets) Output Queue: Max queue-limit default threshold: 160 Tail Packets Drop: 0 Is there a command I am missing to enable the egress priority queue on this interface. Thanks Anthony From t.dahm at resolution.de Wed Oct 7 05:57:01 2009 From: t.dahm at resolution.de (Thorsten Dahm) Date: Wed, 07 Oct 2009 10:57:01 +0100 Subject: [c-nsp] AUDIT In-Reply-To: <8bb137f40910070050n1e1e732aoca3d5ba4411debaa@mail.gmail.com> References: <8bb137f40910070050n1e1e732aoca3d5ba4411debaa@mail.gmail.com> Message-ID: <4ACC65ED.6040700@resolution.de> jack daniels wrote: > I have been assigned to do AUDIT ( LAN / WAN ) for a NETWORK comprising of > devices 2950 , 3750 , 4500 , 2800 , 2600 , 7206 VXR . Please advice which > commands showuld I need to conectrate more and check outputs for making > audit report If you are a bit more specific about what kind of Audit we could perhaps help better. For now: RANCID + diff/grep could be a good start. cheers, Thorsten From bluffmaster4hearts at gmail.com Wed Oct 7 08:32:12 2009 From: bluffmaster4hearts at gmail.com (bharath kondi) Date: Wed, 7 Oct 2009 20:32:12 +0800 Subject: [c-nsp] GSR CPU Process is very HIGH 95% Message-ID: <82957ce50910070532i44454871mb90376a5b1460ab4@mail.gmail.com> Hi All, I am seeing a strange thing in our GSR 12000, CPU process reached 95%. Below is the findings, can anyone help me ASAP. The highest usage is Net Input. What is Net Input? Please help me guys. Thanks in advance. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 66 1485974962884865916 0 17.91% 15.99% 16.04% 0 Net Input ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GW-01-KLS-MY#show processes cpu CPU utilization for five seconds: 95%/71%; one minute: 96%; five minutes: 95% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 276 4999 55 0.00% 0.00% 0.00% 0 Chunk Manager 2 17848 2601954 6 0.00% 0.00% 0.00% 0 Load Meter 3 7930952 8730366 908 0.00% 0.13% 0.15% 0 OSPF-1 Hello 4 0 1 0 0.00% 0.00% 0.00% 0 EE48 TCAM Carve 5 143111728 7403379 19330 0.00% 1.67% 1.29% 0 Check heaps 6 592 1014 583 0.00% 0.00% 0.00% 0 Pool Manager 7 0 2 0 0.00% 0.00% 0.00% 0 Timers 8 0 2 0 0.00% 0.00% 0.00% 0 RP LC ATM Common 9 0 2 0 0.00% 0.00% 0.00% 0 Serial Backgroun 10 0 1 0 0.00% 0.00% 0.00% 0 LB Daemon 11 196 20433 9 0.00% 0.00% 0.00% 0 MBUS Flash 12 45480 20345689 2 0.00% 0.00% 0.00% 0 MBUS System 13 24252 13034266 1 0.00% 0.00% 0.00% 0 MBUS interface S 14 27968 64775693 0 0.00% 0.00% 0.00% 0 Test CPUHOG proc 15 0 2 0 0.00% 0.00% 0.00% 0 Fabric 16 0 9 0 0.00% 0.00% 0.00% 0 GoodieMgr Server 17 288 218659 1 0.00% 0.00% 0.00% 0 IPC Dynamic Cach 18 0 1 0 0.00% 0.00% 0.00% 0 NonBlk Xmt Sl 0 19 16924 13034266 1 0.00% 0.00% 0.00% 0 IPC Periodic Tim 20 52069932 306854514 169 0.47% 0.54% 0.53% 0 IPC Seat Manager 21 15728 13034286 1 0.00% 0.00% 0.00% 0 IPC Deferred Por 22 1044 1311179 0 0.00% 0.00% 0.00% 0 Compute SRP rate 23 12694176 64786441 195 0.00% 0.09% 0.10% 0 ARP Input 24 14104 12942815 1 0.00% 0.00% 0.00% 0 PFE statistics C 25 17696 1300822 13 0.00% 0.00% 0.00% 0 HC Counter Timer 26 0 2 0 0.00% 0.00% 0.00% 0 DDR Timers 27 20 27 740 0.00% 0.00% 0.00% 0 Entity MIB API 28 0 1 0 0.00% 0.00% 0.00% 0 SERIAL A'detect 29 0 1 0 0.00% 0.00% 0.00% 0 IPC Zone Manager 30 1432648 122155691 11 0.00% 0.07% 0.07% 0 Mbus Agent Manag 31 6784 5707 1188 0.00% 0.00% 0.00% 0 Mbus Agent Downl 32 23844 172499 138 0.00% 0.00% 0.00% 0 Board Management 33 28 2291 12 0.00% 0.00% 0.00% 0 Logger MBUS tx 34 132 2553 51 0.00% 0.00% 0.00% 0 Logger IPC tx 35 2044120 39245664 52 0.07% 0.02% 0.00% 0 RP MBUS heartbea 36 44 45 977 0.00% 0.00% 0.00% 0 RP Arbitration 37 0 1 0 0.00% 0.00% 0.00% 0 User LED Message 38 0 1 0 0.00% 0.00% 0.00% 0 Critical Bkgnd 39 701828 2834530 247 0.00% 0.01% 0.00% 0 Net Background 40 0 3 0 0.00% 0.00% 0.00% 0 IDB Work 41 692 23956 28 0.00% 0.00% 0.00% 0 Logger 42 26256 12942800 2 0.00% 0.00% 0.00% 0 TTY Background 43 97096 13850111 7 0.00% 0.00% 0.00% 0 Per-Second Jobs 44 0 1 0 0.00% 0.00% 0.00% 0 NonBlkResp Sl0 45 0 4 0 0.00% 0.00% 0.00% 0 NonBlk Xmt Sl 1 46 0 1 0 0.00% 0.00% 0.00% 0 NonBlkResp Sl1 PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 47 0 1 0 0.00% 0.00% 0.00% 0 NonBlkResp Sl1 48 0 1 0 0.00% 0.00% 0.00% 0 Field Diag Autob 49 0 1 0 0.00% 0.00% 0.00% 0 Field Diag msg p 50 0 1 0 0.00% 0.00% 0.00% 0 Field Diag Misc 51 11260 13034300 0 0.00% 0.00% 0.00% 0 ICC Slave Reques 52 0 1 0 0.00% 0.00% 0.00% 0 ICC Async mcast 53 520 37 14054 0.00% 0.00% 0.00% 0 OIR Sync Process 54 32340 13034274 2 0.00% 0.00% 0.00% 0 FIA Poll 55 173236 283385374 0 0.00% 0.04% 0.02% 0 Fabric Ping 56 0 1 0 0.00% 0.00% 0.00% 0 Inode Table Dest 57 0 1 0 0.00% 0.00% 0.00% 0 QoS HA CHKPT 58 197120 6538296 30 0.00% 0.00% 0.00% 0 rf task 59 0 2 0 0.00% 0.00% 0.00% 0 IPC Apps Task 60 0 1 0 0.00% 0.00% 0.00% 0 IPC RTTYC Messag 61 112880 435694 259 0.00% 0.00% 0.00% 0 RP Standby 62 0 1 0 0.00% 0.00% 0.00% 0 NonBlkResp Sl0 63 412512 5265597 78 0.00% 0.00% 0.00% 0 GSR RP CMD Event 64 36 298 120 0.00% 0.00% 0.00% 0 RTTYS Process 65 8 26 307 0.00% 0.00% 0.00% 0 NonBlk Xmt Sl 2 * 66 1485974962884865916 0 17.91% 15.99% 16.04% 0 Net Input * 67 339752 4475894 75 0.00% 0.04% 0.02% 0 Compute load avg 68 7998564 307368 26022 0.00% 0.03% 0.05% 0 Per-minute Jobs 69 0 1 0 0.00% 0.00% 0.00% 0 NonBlkResp Sl2 70 0 1 0 0.00% 0.00% 0.00% 0 NonBlkResp Sl2 71 2356 31202 75 0.00% 0.00% 0.00% 0 Board Mgr sl 2 72 56 217 258 0.00% 0.00% 0.00% 0 NonBlk Xmt Sl 3 73 0 1 0 0.00% 0.00% 0.00% 0 NonBlkResp Sl3 74 0 1 0 0.00% 0.00% 0.00% 0 NonBlkResp Sl3 75 2732 31196 87 0.00% 0.00% 0.00% 0 Board Mgr sl 3 76 4 17 235 0.00% 0.00% 0.00% 0 NonBlk Xmt Sl 6 77 0 1 0 0.00% 0.00% 0.00% 0 NonBlkResp Sl6 78 0 1 0 0.00% 0.00% 0.00% 0 NonBlkResp Sl6 79 4256 29356 144 0.00% 0.00% 0.00% 0 Board Mgr sl 6 80 0 16 0 0.00% 0.00% 0.00% 0 NonBlk Xmt Sl 8 81 0 1 0 0.00% 0.00% 0.00% 0 NonBlkResp Sl8 82 0 1 0 0.00% 0.00% 0.00% 0 NonBlkResp Sl8 83 2612 29355 88 0.00% 0.00% 0.00% 0 Board Mgr sl 8 84 23380 12943077 1 0.00% 0.00% 0.00% 0 MBUS Config 85 532660 71175882 7 0.00% 0.07% 0.06% 0 Env Mon 86 80600 12943006 6 0.00% 0.00% 0.00% 0 RP Ethernet 87 0 1 0 0.00% 0.00% 0.00% 0 GSR RLC Manager 88 0 2 0 0.00% 0.00% 0.00% 0 RLC RVI HA 89 0 1 0 0.00% 0.00% 0.00% 0 FPD Management P 90 0 1 0 0.00% 0.00% 0.00% 0 FPD Action Proce 91 0 1 0 0.00% 0.00% 0.00% 0 Memory Scanner 92 0 1 0 0.00% 0.00% 0.00% 0 BMA Microcode Lo 93 0 1 0 0.00% 0.00% 0.00% 0 GLC POST Loader 94 0 21 0 0.00% 0.00% 0.00% 0 bfr_fab_bw_info_ PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 95 0 1 0 0.00% 0.00% 0.00% 0 BITS Clock Mgr p 96 4 2 2000 0.00% 0.00% 0.00% 0 MIP Mailbox 97 0 1 0 0.00% 0.00% 0.00% 0 vcq_proc 98 0 22 0 0.00% 0.00% 0.00% 0 TurboACL 99 0 2 0 0.00% 0.00% 0.00% 0 TurboACL chunk 100 0 2 0 0.00% 0.00% 0.00% 0 MCAST HA 101 4 16 250 0.00% 0.00% 0.00% 0 GSR COS init 102 0 1 0 0.00% 0.00% 0.00% 0 GSR DTS init 103 1304 4380 297 0.00% 0.00% 0.00% 0 LC adj updater 104 0 6 0 0.00% 0.00% 0.00% 0 GSR SSRP queuein 105 17436 2601502 6 0.00% 0.00% 0.00% 0 Distributed Mult 106 28727104 109128095 263 0.31% 0.45% 0.43% 0 IP Input 107 4 1 4000 0.00% 0.00% 0.00% 0 ICMP event handl 108 3836880 3228486 1188 0.00% 0.04% 0.05% 0 CDP Protocol 109 0 22 0 0.00% 0.00% 0.00% 0 QoS Manager 110 0 1 0 0.00% 0.00% 0.00% 0 PPP IP Add Route 111 0 1 0 0.00% 0.00% 0.00% 0 LSP Tunnel FRR 112 0 2 0 0.00% 0.00% 0.00% 0 MPLS Auto-Tunnel 113 0 5 0 0.00% 0.00% 0.00% 0 dMATM RP msg han 114 0 2 0 0.00% 0.00% 0.00% 0 HDLC HA 115 23260 2034726 11 0.00% 0.00% 0.00% 0 ARP HA 116 1376 2475 555 0.00% 0.00% 0.00% 0 EM FD Syslog 117 0 2 0 0.00% 0.00% 0.00% 0 EM FD SNMP 118 0 1 0 0.00% 0.00% 0.00% 0 AC Switch 119 0 1 0 0.00% 0.00% 0.00% 0 ac_atm_state_eve 120 0 1 0 0.00% 0.00% 0.00% 0 SSS Manager 121 0 1 0 0.00% 0.00% 0.00% 0 SSS Feature Mana 122 100152 50892410 1 0.00% 0.00% 0.00% 0 SSS Feature Time 123 72 1169 61 0.00% 0.00% 0.00% 0 SSM connection m 124 0 2 0 0.00% 0.00% 0.00% 0 SSCOP Input 125 0 2 0 0.00% 0.00% 0.00% 0 SSCOP Output 126 496 217137 2 0.00% 0.00% 0.00% 0 SSCOP Timer 127 20922632 722654 28952 0.00% 0.13% 0.13% 0 IP Background 128 0 2 0 0.00% 0.00% 0.00% 0 ILMI Input 129 0 2 0 0.00% 0.00% 0.00% 0 SNMP Timers 130 0 2 0 0.00% 0.00% 0.00% 0 ILMI Request 131 0 2 0 0.00% 0.00% 0.00% 0 ILMI Response 132 0 1 0 0.00% 0.00% 0.00% 0 ILMI Timer Proce 133 4 2 2000 0.00% 0.00% 0.00% 0 ATM PVC Discover 134 0 2 0 0.00% 0.00% 0.00% 0 ATMSIG DRIVERAPI 135 300676 682768 440 0.00% 0.00% 0.00% 0 Adj Manager 136 1952840 28999991 67 0.00% 0.11% 0.12% 0 CEF process 137 0 16 0 0.00% 0.00% 0.00% 0 Routemap RP IPC 138 219300 123720446 1 0.00% 0.02% 0.00% 0 MDFS RP process 139 0 1 0 0.00% 0.00% 0.00% 0 CHKPT EXAMPLE 140 0 1 0 0.00% 0.00% 0.00% 0 CHKPT DevTest 141 180332 10527491 17 0.00% 0.01% 0.00% 0 TCP Timer 142 96060 430337 223 0.00% 0.00% 0.00% 0 TCP Protocols PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 143 0 1 0 0.00% 0.00% 0.00% 0 RARP Input 145 3780 216804 17 0.00% 0.00% 0.00% 0 IP Cache Ager 146 0 1 0 0.00% 0.00% 0.00% 0 Uidb Mgr 147 20 10880 1 0.00% 0.00% 0.00% 0 Feature Manager 148 8196 4332167 1 0.00% 0.00% 0.00% 0 ISE MQC Download 149 4620 433616 10 0.00% 0.00% 0.00% 0 ISE MQC DRR quan 150 0 2 0 0.00% 0.00% 0.00% 0 PIM mdt tunnel a 151 492 217137 2 0.00% 0.00% 0.00% 0 TCP Intercept Ti 152 0 1 0 0.00% 0.00% 0.00% 0 Socket Timers 153 0 2 0 0.00% 0.00% 0.00% 0 TC-ATM Proc 154 0 2 0 0.00% 0.00% 0.00% 0 Tag Input 155 4 15 266 0.00% 0.00% 0.00% 0 LFIB FRR IOS 156 0 4 0 0.00% 0.00% 0.00% 0 TSPTUN HA 157 0 1 0 0.00% 0.00% 0.00% 0 L2X Socket proce 158 0 1 0 0.00% 0.00% 0.00% 0 L2TP mgmt daemon 159 0 2 0 0.00% 0.00% 0.00% 0 FR HA 160 0 3 0 0.00% 0.00% 0.00% 0 IPv6 CEF process 161 20612 216805 95 0.00% 0.00% 0.00% 0 6PE Scanner 162 0 1 0 0.00% 0.00% 0.00% 0 6PE fibidb Scann 163 0 2 0 0.00% 0.00% 0.00% 0 PPP HA 164 0 2 0 0.00% 0.00% 0.00% 0 ATM HA 165 0 1 0 0.00% 0.00% 0.00% 0 L2X Data Daemon 166 0 1 0 0.00% 0.00% 0.00% 0 Key chain liveke 167 16 30 533 0.00% 0.00% 0.00% 0 NonBlk Xmt Sl 4 168 0 25 0 0.00% 0.00% 0.00% 0 MPLS Auto Mesh P 169 0 1 0 0.00% 0.00% 0.00% 0 Encrypt Proc 170 4578332 30717 149053 0.00% 0.00% 0.00% 0 Key Proc 171 0 1 0 0.00% 0.00% 0.00% 0 Crypto Support 172 36 3 12000 0.00% 0.00% 0.00% 0 Crypto CA 173 0 2 0 0.00% 0.00% 0.00% 0 Lawful Intercept 174 0 2 0 0.00% 0.00% 0.00% 0 LI messaging 175 4416 220934 19 0.00% 0.00% 0.00% 0 SPA ENTITY Proce 176 0 1 0 0.00% 0.00% 0.00% 0 NonBlkResp Sl4 177 0 1 0 0.00% 0.00% 0.00% 0 SNMP ConfCopyPro 178 0 1 0 0.00% 0.00% 0.00% 0 Syslog Traps 179 0 1 0 0.00% 0.00% 0.00% 0 SONET Traps 180 0 1 0 0.00% 0.00% 0.00% 0 IP Source Tracke 181 0 1 0 0.00% 0.00% 0.00% 0 DATA Transfer Pr 182 0 1 0 0.00% 0.00% 0.00% 0 DATA Collector 183 0 4 0 0.00% 0.00% 0.00% 0 EM Server 184 0 1 0 0.00% 0.00% 0.00% 0 MAC ACL RP msg h 185 0 2 0 0.00% 0.00% 0.00% 0 EM Applet Direct 186 191300 715241 267 0.00% 0.00% 0.00% 0 CEF Scanner 187 1036816 51181537 20 0.00% 0.01% 0.03% 0 CEF RP IPC Backg 188 2944 180951 16 0.00% 0.00% 0.00% 0 SSH Event handle 189 23567044 74381747 316 0.55% 0.33% 0.35% 0 IP SNMP 190 7748276 37082413 208 0.31% 0.14% 0.12% 0 PDU DISPATCHER 191 44648072 37364151 1194 1.11% 0.67% 0.67% 0 SNMP ENGINE PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 192 3144 5310 592 0.00% 0.00% 0.00% 0 SNMP Traps 193 1784 2583 690 0.00% 0.00% 0.00% 0 Mbus Agent Upgra 194 16 133 120 0.00% 0.00% 0.00% 0 TCP Listener 195 44848 13302324 3 0.00% 0.00% 0.00% 0 NTP 196 0 11 0 0.00% 0.00% 0.00% 0 Delayed function 197 3060 634 4826 0.00% 0.00% 0.00% 0 Async i/o server 198 2176 423 5144 0.00% 0.00% 0.00% 0 Async i/o server 199 802932 14893657 53 0.00% 0.00% 0.00% 0 OSPF-1 Router 200 25683912 63061115 407 0.23% 0.23% 0.19% 0 BGP Router 201 2313128 15901418 145 0.00% 0.05% 0.01% 0 BGP I/O 202 1270749548 477837637 2659 2.07% 2.04% 2.29% 0 BGP Scanner 203 21580 1300806 16 0.00% 0.00% 0.00% 0 OBFL Envmon 204 0 2 0 0.00% 0.00% 0.00% 0 cpf_process_msg_ 205 0 1 0 0.00% 0.00% 0.00% 0 NonBlkResp Sl4 206 54924 4082881 13 0.00% 0.00% 0.00% 0 cpf_process_ipcQ 207 1160 1910 607 0.00% 0.00% 0.00% 0 Board Mgr sl 4 208 4832 5458 885 0.31% 1.43% 0.58% 3 SSH Process GW-01-KLS-MY# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks and Regards, Bharath Kondi. From oboehmer at cisco.com Wed Oct 7 08:57:03 2009 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Wed, 7 Oct 2009 14:57:03 +0200 Subject: [c-nsp] GSR CPU Process is very HIGH 95% In-Reply-To: <82957ce50910070532i44454871mb90376a5b1460ab4@mail.gmail.com> References: <82957ce50910070532i44454871mb90376a5b1460ab4@mail.gmail.com> Message-ID: <6E4D2678AC543844917CA081C9D6B33F729B86@XMB-AMS-103.cisco.com> bharath kondi <> wrote on Wednesday, October 07, 2009 14:32: > Hi All, > > I am seeing a strange thing in our GSR 12000, CPU process reached > 95%. Below is the findings, can anyone help me ASAP. > > The highest usage is Net Input. What is Net Input? Please help me > guys. > > Thanks in advance. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 66 1485974962884865916 0 17.91% 15.99% 16.04% 0 Net > Input > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > GW-01-KLS-MY#show processes cpu > > CPU utilization for five seconds: 95%/71%; one minute: 96%; five > minutes: 95% are you switching traffic across the PRP/GRP's Management Ethernet ports? Those must only be used for management, i.e. traffic from/to the GSR .. oli From bluffmaster4hearts at gmail.com Wed Oct 7 09:10:12 2009 From: bluffmaster4hearts at gmail.com (bharath kondi) Date: Wed, 7 Oct 2009 21:10:12 +0800 Subject: [c-nsp] GSR CPU Process is very HIGH 95% In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F729B86@XMB-AMS-103.cisco.com> References: <82957ce50910070532i44454871mb90376a5b1460ab4@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F729B86@XMB-AMS-103.cisco.com> Message-ID: <82957ce50910070610x5fcd478cje2b0e9773fde7551@mail.gmail.com> Dear Oliver, No. Thanks. Bharath Kondi On Wed, Oct 7, 2009 at 8:57 PM, Oliver Boehmer (oboehmer) < oboehmer at cisco.com> wrote: > bharath kondi <> wrote on Wednesday, October 07, 2009 14:32: > > > Hi All, > > > > I am seeing a strange thing in our GSR 12000, CPU process reached > > 95%. Below is the findings, can anyone help me ASAP. > > > > The highest usage is Net Input. What is Net Input? Please help me > > guys. > > > > Thanks in advance. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > 66 1485974962884865916 0 17.91% 15.99% 16.04% 0 Net > > Input > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > GW-01-KLS-MY#show processes cpu > > > > CPU utilization for five seconds: 95%/71%; one minute: 96%; five > > minutes: 95% > > are you switching traffic across the PRP/GRP's Management Ethernet > ports? Those must only be used for management, i.e. traffic from/to the > GSR .. > > oli > -- (?`?.???) With --------------------`?.?(?`?.???) Lots of ------- (?`?.??(?`?.???)?.?? Love & Luck... `?.?.?? ? ????... ?? From bluffmaster4hearts at gmail.com Wed Oct 7 09:21:12 2009 From: bluffmaster4hearts at gmail.com (bharath kondi) Date: Wed, 7 Oct 2009 21:21:12 +0800 Subject: [c-nsp] GSR CPU Process is very HIGH 95% In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F729B86@XMB-AMS-103.cisco.com> References: <82957ce50910070532i44454871mb90376a5b1460ab4@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F729B86@XMB-AMS-103.cisco.com> Message-ID: <82957ce50910070621s2e8b202csc8b84aa1f60ae068@mail.gmail.com> Thanks Oliver. My problem solved. I was disconnecting each and every cable connected to GSR and check the process and found one unwanted cable connecting and generating traffic. Now everything back to normal. Thanks for your support. Regards, Bharath Kondi On Wed, Oct 7, 2009 at 8:57 PM, Oliver Boehmer (oboehmer) < oboehmer at cisco.com> wrote: > bharath kondi <> wrote on Wednesday, October 07, 2009 14:32: > > > Hi All, > > > > I am seeing a strange thing in our GSR 12000, CPU process reached > > 95%. Below is the findings, can anyone help me ASAP. > > > > The highest usage is Net Input. What is Net Input? Please help me > > guys. > > > > Thanks in advance. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > 66 1485974962884865916 0 17.91% 15.99% 16.04% 0 Net > > Input > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > GW-01-KLS-MY#show processes cpu > > > > CPU utilization for five seconds: 95%/71%; one minute: 96%; five > > minutes: 95% > > are you switching traffic across the PRP/GRP's Management Ethernet > ports? Those must only be used for management, i.e. traffic from/to the > GSR .. > > oli > From oboehmer at cisco.com Wed Oct 7 09:22:07 2009 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Wed, 7 Oct 2009 15:22:07 +0200 Subject: [c-nsp] GSR CPU Process is very HIGH 95% In-Reply-To: <82957ce50910070610x5fcd478cje2b0e9773fde7551@mail.gmail.com> References: <82957ce50910070532i44454871mb90376a5b1460ab4@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F729B86@XMB-AMS-103.cisco.com> <82957ce50910070610x5fcd478cje2b0e9773fde7551@mail.gmail.com> Message-ID: <6E4D2678AC543844917CA081C9D6B33F729BBF@XMB-AMS-103.cisco.com> bharath kondi wrote on Wednesday, October 07, 2009 15:10: > are you switching traffic across the PRP/GRP's Management Ethernet > ports? Those must only be used for management, i.e. traffic from/to > the GSR .. > > Dear Oliver, > > No. hmm, your high interrupt load (the 71 in "CPU utilization for five seconds: 95%/71%") suggests that the RP's CPU switches traffic, which should not happen on a GSR as all traffic is switched by hardware.. It requires a closer look at the config and linecards to see what could cause this. I'd contact TAC.. oli From andy.saykao at staff.netspace.net.au Wed Oct 7 09:53:25 2009 From: andy.saykao at staff.netspace.net.au (Andy Saykao) Date: Thu, 8 Oct 2009 00:53:25 +1100 Subject: [c-nsp] Debug help with AS5400 Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AAD5A@vic-cr-ex1.staff.netspace.net.au> Hi All, Just wondering if anybody has any ideas on what debug commands I should be using on the AS5400 to see why our fax server keeps receiving a busy signal. No changes have been done on the fax server and AS5400. We've tried rebooting both the fax server and AS5400 but no joy. We send fax requests to the fax server/gateway which is running hylafax. The server then sends the fax request to the AS5400 which is acting as a fax relay using t38. All of a sudden we are getting a "ERR Busy signal detected" in the logs on the fax server when trying to send a fax out. /var/log/messages: Oct 7 13:26:56 faxserv FaxQueuer[175]: SUBMIT JOB 9842 Oct 7 13:26:58 faxserv FaxGetty[184]: ANSWER: Can not lock modem device Oct 7 13:27:03 faxserv FaxSend[843]: MODEM VYACHESLAV FROLOV T38FAX/0.6.2 Oct 7 13:27:03 faxserv FaxSend[843]: SEND FAX: JOB 9842 DEST 0398110002 COMMID 00021663 DEVICE '/dev/ttyx1' O/G connection to 61398110002 at as1.melbourne.netspace.net.au Closing connection Oct 7 13:27:09 faxserv FaxSend[843]: SEND FAILED: JOB 9842 DEST 0398110002 ERR Busy signal detected Oct 7 13:27:09 faxserv FaxQueuer[175]: NOTIFY: bin/notify "sendq/q9842" "requeued" "" "13:30" Oct 7 13:27:34 faxserv FaxGetty[184]: MODEM VYACHESLAV FROLOV T38FAX/0.6.2 hylafax log: Oct 08 00:36:06.40: [ 636]: SESSION BEGIN 00021824 61393337467 Oct 08 00:36:06.40: [ 636]: HylaFAX (tm) Version 4.1.1 Oct 08 00:36:06.40: [ 636]: SEND FAX: JOB 9857 DEST 61393337467 COMMID 00021824 DEVICE '/dev/ttyx1' Oct 08 00:36:06.40: [ 636]: MODEM set DTR OFF Oct 08 00:36:06.40: [ 636]: MODEM set baud rate: 0 baud (flow control unchanged) Oct 08 00:36:06.40: [ 636]: DELAY 75 ms Oct 08 00:36:06.48: [ 636]: MODEM set DTR ON Oct 08 00:36:06.48: [ 636]: DELAY 2600 ms Oct 08 00:36:09.08: [ 636]: MODEM set baud rate: 19200 baud, input flow RTS/CTS, output flow RTS/CTS Oct 08 00:36:09.08: [ 636]: MODEM flush i/o Oct 08 00:36:09.08: [ 636]: <-- [4:ATZ\r] Oct 08 00:36:09.10: [ 636]: --> [3:ATZ] Oct 08 00:36:09.10: [ 636]: --> [2:OK] Oct 08 00:36:09.10: [ 636]: DELAY 3000 ms Oct 08 00:36:12.10: [ 636]: <-- [5:ATE0\r] Oct 08 00:36:12.10: [ 636]: --> [4:ATE0] Oct 08 00:36:12.10: [ 636]: --> [2:OK] Oct 08 00:36:12.10: [ 636]: <-- [5:ATV1\r] Oct 08 00:36:12.10: [ 636]: --> [2:OK] Oct 08 00:36:12.10: [ 636]: <-- [5:ATQ0\r] Oct 08 00:36:12.10: [ 636]: --> [2:OK] Oct 08 00:36:12.10: [ 636]: <-- [7:ATS0=0\r] Oct 08 00:36:12.10: [ 636]: --> [2:OK] Oct 08 00:36:12.10: [ 636]: <-- [7:ATS8=2\r] Oct 08 00:36:12.10: [ 636]: --> [2:OK] Oct 08 00:36:12.10: [ 636]: <-- [8:ATS7=60\r] Oct 08 00:36:12.10: [ 636]: --> [2:OK] Oct 08 00:36:12.10: [ 636]: <-- [12:AT+FCLASS=1\r] Oct 08 00:36:12.10: [ 636]: --> [2:OK] Oct 08 00:36:12.10: [ 636]: <-- [7:ATL0M1\r] Oct 08 00:36:12.10: [ 636]: --> [2:OK] Oct 08 00:36:12.10: [ 636]: STATE CHANGE: RUNNING -> SENDING Oct 08 00:36:12.10: [ 636]: MODEM input buffering enabled Oct 08 00:36:12.10: [ 636]: <-- [12:AT+FCLASS=1\r] Oct 08 00:36:12.20: [ 636]: --> [2:OK] Oct 08 00:36:12.20: [ 636]: DIAL 61393337467 Oct 08 00:36:12.20: [ 636]: <-- [16:ATDT61393337467\r] Oct 08 00:36:12.37: [ 636]: --> [4:BUSY] Oct 08 00:36:12.37: [ 636]: SEND FAILED: JOB 9857 DEST 61393337467 ERR Busy signal detected Thanks. Andy This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the organisation. Finally, the recipient should check this email and any attachments for the presence of viruses. The organisation accepts no liability for any damage caused by any virus transmitted by this email. From ler762 at gmail.com Wed Oct 7 10:13:20 2009 From: ler762 at gmail.com (Lee) Date: Wed, 7 Oct 2009 10:13:20 -0400 Subject: [c-nsp] log-input acl keyword not working on an ASR Message-ID: Is there some way to get the MAC address of packets blocked by an input access list on an ASR? The "log-input" keyword isn't working for me on an ASR. On a 3845 with an input access list that ends with deny ip any any log-input I get the mac address in addition to the IP address - eg: %SEC-6-IPACCESSLOGSP: list foo denied igmp 10.10.10.7 (G0/3/0 0004.96xx.xxxx) -> 224.0.0.2 But the same input access list on an ASR doesn't show the mac-address: %FMANFP-6-IPACCESSLOGNP: F0: fman_fp_image: list foo denied 2 10.10.10.7 G0/0/0-> 224.0.0.1 TIA, Lee From jviadzishchau at gmail.com Wed Oct 7 10:18:46 2009 From: jviadzishchau at gmail.com (Jauhen Viadzishchau) Date: Wed, 07 Oct 2009 17:18:46 +0300 Subject: [c-nsp] Cisco 3750 Stack less disruptive EtherChannel configuration In-Reply-To: <1254823504.10811.11.camel@dsba-ipso> References: <1254823504.10811.11.camel@dsba-ipso> Message-ID: <4ACCA346.5010908@gmail.com> well, in cross-stack etherchannel, the only supported protocol is LACP, not "mode on" Jauhen. luismi wrote: > Hi, > > We had a problem with a stack 3750 here and the configuration is.. > > Stack (2x3750) === FEC === SW 2960 > > It is a cross etherchannel configuration. > 3750 is not working with L3 mode at all. > > The FEC config is "mode on". > So, one the 3750 had a problem yesterday and it creates disruption in > the connectivity with the 2960 switches. I didn't expect from > Etherchannel. It is supossed that is pretty fast but it was not. > > I would like to see if there is anyone here with a similar configuration > or other one to fix this situation. > Any comment is welcome > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From rwest at zyedge.com Wed Oct 7 10:26:49 2009 From: rwest at zyedge.com (Ryan West) Date: Wed, 7 Oct 2009 10:26:49 -0400 Subject: [c-nsp] Cisco 3750 Stack less disruptive EtherChannel configuration In-Reply-To: <4ACCA346.5010908@gmail.com> References: <1254823504.10811.11.camel@dsba-ipso> <4ACCA346.5010908@gmail.com> Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F9C84@zy-ex1.zyedge.local> Jauhen, Manual etherchannels using mode on are supported, but can cause the issues that the OP reported. http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configuration_example09186a00806cb982.shtml#stack -ryan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jauhen Viadzishchau Sent: Wednesday, October 07, 2009 10:19 AM To: cisco-nsp Subject: Re: [c-nsp] Cisco 3750 Stack less disruptive EtherChannel configuration well, in cross-stack etherchannel, the only supported protocol is LACP, not "mode on" Jauhen. From drew.weaver at thenap.com Wed Oct 7 11:20:42 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 7 Oct 2009 11:20:42 -0400 Subject: [c-nsp] Anomaly Detection Module/Anomaly Guard Module Message-ID: I was wondering if anyone has any experience working with the Cisco ADM AGM modules for the 6500s and how they compare with external appliance based solutions for DDoS mitigation. Anyone have any opinions on these? It seems like it would be nice to just drop these into a few systems but I'm just trying to avoid caveats that mitigate (pun intended) the usefulness of these products. Any thoughts? -Drew From oboehmer at cisco.com Wed Oct 7 11:21:26 2009 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Wed, 7 Oct 2009 17:21:26 +0200 Subject: [c-nsp] GSR CPU Process is very HIGH 95% In-Reply-To: References: <82957ce50910070532i44454871mb90376a5b1460ab4@mail.gmail.com><6E4D2678AC543844917CA081C9D6B33F729B86@XMB-AMS-103.cisco.com><82957ce50910070610x5fcd478cje2b0e9773fde7551@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F729BBF@XMB-AMS-103.cisco.com> Message-ID: <6E4D2678AC543844917CA081C9D6B33F729CA3@XMB-AMS-103.cisco.com> Lasher, Donn wrote on Wednesday, October 07, 2009 17:08: > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oliver Boehmer > (oboehmer) > Sent: Wednesday, October 07, 2009 6:22 AM > To: bharath kondi > Cc: BHARATH KONDI; bharath at vtelecoms.com.my; cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] GSR CPU Process is very HIGH 95% > >> hmm, your high interrupt load (the 71 in "CPU utilization for five >> seconds: 95%/71%") suggests that the RP's CPU switches traffic, which >> should not happen on a GSR as all traffic is switched by hardware.. >> It requires a closer look at the config and linecards to see what >> could cause this. I'd contact TAC.. > > To clarify, this depends on both the card type (engine 0/1/2/3/4/5) > and traffic type (mpls, DSCP marking, etc). You can be doing everything > right, and still have 50% CPU with the wrong combination of those > two.. (For example, MPLS Labeling and Engine0 GIG-E card at 100M of > traffic) sorry, you are obviously right. I should have said "all traffic is switched by the linecards". If the linecard forwarding hardware can't switch the packet, it's punted to the linecard CPU, but should never be switched by the RP's CPU. The only exception are packets switched out the RP's Mangement-Ethernet ports (so this should be avoided). oli From DLasher at newedgenetworks.com Wed Oct 7 11:07:34 2009 From: DLasher at newedgenetworks.com (Lasher, Donn) Date: Wed, 7 Oct 2009 08:07:34 -0700 Subject: [c-nsp] GSR CPU Process is very HIGH 95% In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F729BBF@XMB-AMS-103.cisco.com> References: <82957ce50910070532i44454871mb90376a5b1460ab4@mail.gmail.com><6E4D2678AC543844917CA081C9D6B33F729B86@XMB-AMS-103.cisco.com><82957ce50910070610x5fcd478cje2b0e9773fde7551@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F729BBF@XMB-AMS-103.cisco.com> Message-ID: -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oliver Boehmer (oboehmer) Sent: Wednesday, October 07, 2009 6:22 AM To: bharath kondi Cc: BHARATH KONDI; bharath at vtelecoms.com.my; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] GSR CPU Process is very HIGH 95% >hmm, your high interrupt load (the 71 in "CPU utilization for five >seconds: 95%/71%") suggests that the RP's CPU switches traffic, which >should not happen on a GSR as all traffic is switched by hardware.. >It requires a closer look at the config and linecards to see what could >cause this. I'd contact TAC.. To clarify, this depends on both the card type (engine 0/1/2/3/4/5) and traffic type (mpls, DSCP marking, etc). You can be doing everything right, and still have 50% CPU with the wrong combination of those two.. (For example, MPLS Labeling and Engine0 GIG-E card at 100M of traffic) From bluffmaster4hearts at gmail.com Wed Oct 7 12:01:50 2009 From: bluffmaster4hearts at gmail.com (bharath kondi) Date: Thu, 8 Oct 2009 00:01:50 +0800 Subject: [c-nsp] GSR CPU Process is very HIGH 95% In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F729BC0@XMB-AMS-103.cisco.com> References: <82957ce50910070532i44454871mb90376a5b1460ab4@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F729B86@XMB-AMS-103.cisco.com> <82957ce50910070621s2e8b202csc8b84aa1f60ae068@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F729BC0@XMB-AMS-103.cisco.com> Message-ID: <82957ce50910070901j15e4271bt482828b386c3b2b4@mail.gmail.com> Dear All, It is a Tagged port connecting to our multi layer switch, where we tagged so many vlans which is not needed (This port is configured for IBGP with a dot1q vlan on GSR, and the other side multilayer switch allowing so many vlans, this is configured by earlier engineer, right now we are not using IBGP on this port). Once I shutdown the port everything back to normal. As Jeff mentioned below, it is true in my case. These unknown packets coming from our multilayer switch to GSR made CPU process high. // Net Input is a process that handles "unknown" types of Packets. These packets get sent directly to NULL, thus being black-holed. The CPU is spiking because your input queue is getting hit hard with whatever these packets are and is having to make a send to Null/discard decision. // --- By Jeff Regards, Bharath Kondi On Wed, Oct 7, 2009 at 9:22 PM, Oliver Boehmer (oboehmer) < oboehmer at cisco.com> wrote: > where was this cable connected to? > > ------------------------------ > *From:* bharath kondi [mailto:bluffmaster4hearts at gmail.com] > *Sent:* Wednesday, October 07, 2009 15:21 > *To:* Oliver Boehmer (oboehmer) > *Cc:* cisco-nsp at puck.nether.net; BHARATH KONDI; bharath at vtelecoms.com.my > *Subject:* Re: [c-nsp] GSR CPU Process is very HIGH 95% > > Thanks Oliver. My problem solved. I was disconnecting each and every cable > connected to GSR and check the process and found one unwanted cable > connecting and generating traffic. Now everything back to normal. > Thanks for your support. > > Regards, > Bharath Kondi > > > On Wed, Oct 7, 2009 at 8:57 PM, Oliver Boehmer (oboehmer) < > oboehmer at cisco.com> wrote: > >> bharath kondi <> wrote on Wednesday, October 07, 2009 14:32: >> >> > Hi All, >> > >> > I am seeing a strange thing in our GSR 12000, CPU process reached >> > 95%. Below is the findings, can anyone help me ASAP. >> > >> > The highest usage is Net Input. What is Net Input? Please help me >> > guys. >> > >> > Thanks in advance. >> > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > >> > 66 1485974962884865916 0 17.91% 15.99% 16.04% 0 Net >> > Input >> > >> > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > >> > GW-01-KLS-MY#show processes cpu >> > >> > CPU utilization for five seconds: 95%/71%; one minute: 96%; five >> > minutes: 95% >> >> are you switching traffic across the PRP/GRP's Management Ethernet >> ports? Those must only be used for management, i.e. traffic from/to the >> GSR .. >> >> oli >> > > > > > -- (?`?.???) With --------------------`?.?(?`?.???) Lots of ------- (?`?.??(?`?.???)?.?? Love & Luck... `?.?.?? ? ????... ?? From pavel.skovajsa at gmail.com Wed Oct 7 12:20:31 2009 From: pavel.skovajsa at gmail.com (Pavel Skovajsa) Date: Wed, 7 Oct 2009 18:20:31 +0200 Subject: [c-nsp] Cisco 3400 port shaping message limitation Message-ID: <323aca890910070920i5df1f5f5qef6d7778fb552a52@mail.gmail.com> Hello all, I was in the middle of the configuration of ME-3400-24TS-A (12.2(50)SE1) for port-shaping and run into interesting message: censw(config-if)#! censw(config-if)#! censw(config-if)#interface FastEthernet0/12 censw(config-if)#service-policy output UNI-out-internet-1024kbps censw(config-if)#service-policy input UNI-in-internet-1024kbps censw(config-if)#! censw(config-if)#! censw(config-if)#interface FastEthernet0/22 censw(config-if)#service-policy output UNI-out-internet-1024kbps censw(config-if)#service-policy input UNI-in-internet-1024kbps censw(config-if)#! censw(config-if)#! censw(config-if)#interface FastEthernet0/5 censw(config-if)#service-policy output UNI-out-internet-1024kbps QoS: Configuration failed. The configured rate 1024000 bps is not achievable in hw within 1% of configuration. Closest value(s) are: 1111111 bps, 1000000 bps censw(config-if)#service-policy input UNI-in-internet-1024kbps censw(config-if)# censw(config-if)#service-policy output UNI-out-internet-1024kbps QoS: Configuration failed. The configured rate 1024000 bps is not achievable in hw within 1% of configuration. Closest value(s) are: 1111111 bps, 1000000 bps censw(config-if)#service-policy output UNI-out-internet-1024kbps QoS: Configuration failed. The configured rate 1024000 bps is not achievable in hw within 1% of configuration. Closest value(s) are: 1111111 bps, 1000000 bps The configuration of the policy-map is straightforward: policy-map UNI-out-internet-1024kbps class class-default shape average 1024000 queue-limit 272 The setting of the queue-limit is configured according to the recommendation over here: http://www.cisco.com/en/US/docs/switches/metro/me3400/software/release/12.2_52_se/configuration/guide/swqos.html#wp1497063 After little experimenting I figured out that when I change the policy-map to this: policy-map UNI-out-internet-1024kbps class class-default shape average 1000000 queue-limit 272 It starts to work fine. The question still remains, what does this error message actually mean, and why it got triggered when I applied the policy to the 3rd interface in a row.... Can somebody shed some light into this? Regards, Pavel Skovajsa From eninja at gmail.com Wed Oct 7 12:45:56 2009 From: eninja at gmail.com (Eninja) Date: Wed, 7 Oct 2009 18:45:56 +0200 Subject: [c-nsp] GSR CPU Process is very HIGH 95% Message-ID: <673BFC3C-0143-49ED-A1B7-E44B05CA725E@gmail.com> Bharath, Several things can cause RP (or LC) CPU spike at interrupt level. What does a 'sh align', 'sh int stat', 'sh ver' and 'sh diag summ' say? If they reveal no clues, you may have to profile the CPU. Oli, "Contact TAC" should probably be re-phrased to say "contact your maintenance service provider" - which may or may not be Cisco ;-) Eninja On Oct 7, 2009, at 3:22 PM, "Oliver Boehmer (oboehmer)" wrote: > bharath kondi wrote on > Wednesday, > October 07, 2009 15:10: >> are you switching traffic across the PRP/GRP's Management > Ethernet >> ports? Those must only be used for management, i.e. traffic > from/to >> the GSR .. >> >> Dear Oliver, >> >> No. > > hmm, your high interrupt load (the 71 in "CPU utilization for five > seconds: 95%/71%") suggests that the RP's CPU switches traffic, which > should not happen on a GSR as all traffic is switched by hardware.. > It requires a closer look at the config and linecards to see what > could > cause this. I'd contact TAC.. > > oli > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From petelists at templin.org Wed Oct 7 12:01:38 2009 From: petelists at templin.org (Pete Templin) Date: Wed, 07 Oct 2009 11:01:38 -0500 Subject: [c-nsp] GSR CPU Process is very HIGH 95% In-Reply-To: References: <82957ce50910070532i44454871mb90376a5b1460ab4@mail.gmail.com><6E4D2678AC543844917CA081C9D6B33F729B86@XMB-AMS-103.cisco.com><82957ce50910070610x5fcd478cje2b0e9773fde7551@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F729BBF@XMB-AMS-103.cisco.com> Message-ID: <4ACCBB62.8030004@templin.org> Lasher, Donn wrote: > To clarify, this depends on both the card type (engine 0/1/2/3/4/5) and > traffic type (mpls, DSCP marking, etc). You can be doing everything > right, and still have 50% CPU with the wrong combination of those two.. > (For example, MPLS Labeling and Engine0 GIG-E card at 100M of traffic) Right, but that'd be 50% CPU on the linecard, not on the xRP, right? (In other words, you'd find 50% CPU by doing 'execute-on all sh proc c s | e 0.0.%' but wouldn't find it by doing 'sh proc c s | e 0.0.%'.) pt From Sam.Vuillaume at cogecodata.com Wed Oct 7 14:02:15 2009 From: Sam.Vuillaume at cogecodata.com (Sam Vuillaume) Date: Wed, 7 Oct 2009 14:02:15 -0400 Subject: [c-nsp] ES40 OIR feedback Message-ID: <598E14F70F824D4CB925768598BEBAE10E9383@bupwxdb2.cogeco.com> Hi guys, I'm planning to do an ES40 online insertion into 7600 Chassis pretty soon. Cisco say those card are OIR, however i've heard some bad experience during the online insertion. Any feedback to provide to me? My management is now worrried.... Those PE's are MPLS P/PE. tks Sam Do you really need to print this email? Help preserve our environment! Devez-vous vraiment imprimer ce courriel? Pensons a l'environnement This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from us may be monitored. Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this message, or any attachment, that have arisen as a result of e-mail transmission. If verification is required, please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company. From ayourtch at cisco.com Wed Oct 7 14:19:40 2009 From: ayourtch at cisco.com (Andrew Yourtchenko) Date: Wed, 7 Oct 2009 20:19:40 +0200 (CEST) Subject: [c-nsp] So when is IPv6 failover coming to the ASA? In-Reply-To: <4AC0F4A9.3010002@inex.ie> References: <20090928161248.GT7045@lboro.ac.uk> <4AC0F4A9.3010002@inex.ie> Message-ID: On Mon, 28 Sep 2009, Nick Hilliard wrote: > On 28/09/2009 18:13, Abello, Vinny wrote: >> I don't care so much at this point if it fails over or not. If I were to >> configure it, would it at least work as far as passing the traffic? I >> thought I read early on that it would cause a conflict between the two ASA >> devices or is this not the case? If that's all I have to worry about, it's >> not critical that it fails over automatically at this point for me. It's >> more of an initial staging of the technology so I can start numbering my >> devices and verify connectivity, etc... As you said, you turn IPv6 off and >> back on. Is that all that's needed at this point in time? I can deal with >> that for the time being. > > It certainly passes traffic and performs stateful packet firewalling. It > doesn't do inspection very well, and failover is documented as not > implemented. > > What I have observed is that these things are overlooked during specification > because you feel that you can live with an occasional amount of pain. But > once you get the boxes into production, you'll find that ipv6 breaks at times > which are, well, frankly rather inconvenient, like during time-constrained > maintenance windows or when a switch crashes or reboots or whatever. both units act in ND and RA as if they had the same IPv6 address configured - "failover" and "ipv6" are unaware of each other. Hence the effect you observe - there are pseudo-stable states in this scenario. 8.2.2 should make the ipv6 and failover better friends than they are now. thanks, andrew > > This isn't intended as a jab at Cisco or anything - ipv6 failover is well > documented as not being implemented yet and, well, that's that. It's a known > failure mode. It's just that we're all human and because failover often > occurs under times of extreme network stress, end-users and management may > get unhappy and may start shouting and colourful verbal incantations may be > invoked when ipv6 stops working all of a sudden. > > Unfortunately, ASA boxes are beloved of enterprises, and ipv6 is very much > down the list as far as the enterprise market segment is concerned. The > service provider market has significantly different needs, but Cisco's ASA > product managers are not especially focussed on this segment. > > Nick > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > From dominic at broadconnect.ca Wed Oct 7 14:21:15 2009 From: dominic at broadconnect.ca (Dominic) Date: Wed, 7 Oct 2009 14:21:15 -0400 Subject: [c-nsp] Unable To Use T3 Card (PA-MC-2T3-EC) References: Message-ID: <001401ca477a$f544cef0$d400a8c0@dominic> Hi Everyone: I am trying to install a Cisco T3 Card, Model #: PA-MC-2T3-EC, on a Cisco 7206VXR with NPE-G2. When I insert the card, I get the alarm below. Oct 7 18:11:45.100: %ENTITY_ALARM-6-INFO: CLEAR CRITICAL PA Slot 2 Active Card Removed OIR Alarm Oct 7 18:11:50.220: %PA-3-REVNOTSUPPORTED: PA in slot2 (Ethernet) requires base h/w revision of (1.14) for this chassis Oct 7 18:11:50.220: %PA-3-DEACTIVATED: port adapter in bay [2] powered off. The google info suggests this might be an earlier version of the card, which is why I tried a recently manufactured replacement, but with the same result. Does anyone know what's going on, or how to fix this? Thank you in advance. Dominic From rsnyder at toontown.erial.nj.us Wed Oct 7 15:19:21 2009 From: rsnyder at toontown.erial.nj.us (Bob Snyder) Date: Wed, 7 Oct 2009 15:19:21 -0400 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: <4AC9BFA7.4060203@imperial.ac.uk> References: <4AC619BF.7040009@umn.edu> <4AC620C9.3060208@cisco.com> <4AC74037.3050408@imperial.ac.uk> <20091005093933.GK29398@lboro.ac.uk> <4AC9BFA7.4060203@imperial.ac.uk> Message-ID: <6edfd6c20910071219u3f9514e3i48b831612ddde2cc@mail.gmail.com> On Mon, Oct 5, 2009 at 5:43 AM, Phil Mayers wrote: > mls rate-limit all ttl-failure 100 10 > mls rate-limit all mtu-failure 100 10 > > There's no reason not to have the TTL failure rate limit enabled AFAIK. > Choose a value appropriate to you, obviously. One gotcha here is that busy routers will start dropping traceroute packets as the trace hits routers that are actively rate-limiting. Even through end to end traffic isn't affected, you may get user calls (or confused network admins) complaining about packet loss because of a misleading traceroute. Still definitely a good idea, but something to consider when setting thresholds and managing expectations. Bob From dominic at broadconnect.ca Wed Oct 7 15:37:40 2009 From: dominic at broadconnect.ca (Dominic) Date: Wed, 7 Oct 2009 15:37:40 -0400 Subject: [c-nsp] Unable To Use T3 Card (PA-MC-2T3-EC) References: <1254943599.v2.mailanyonewebmail-222491@fuse49> Message-ID: <003501ca4785$a1df2a20$d400a8c0@dominic> I am currently running (C7200P-SPSERVICESK9-M), Version 12.4(4)XD10 Dominic ----- Original Message ----- From: "Byrd, William" To: "Dominic" Sent: Wednesday, October 07, 2009 3:26 PM Subject: Re: [c-nsp] Unable To Use T3 Card (PA-MC-2T3-EC) > What IOS version are you using? There is a minimum supported IOS for this > card. > > -Will > > ----- Original Message ----- > From: "Dominic" > Sent: Wed, October 7, 2009 14:21 > Subject:[c-nsp] Unable To Use T3 Card (PA-MC-2T3-EC) > > > Hi Everyone: > > I am trying to install a Cisco T3 Card, Model #: PA-MC-2T3-EC, on a Cisco > 7206VXR with NPE-G2. When I insert the card, I get the alarm below. > > Oct 7 18:11:45.100: %ENTITY_ALARM-6-INFO: CLEAR CRITICAL PA Slot 2 Active > Card Removed OIR Alarm > Oct 7 18:11:50.220: %PA-3-REVNOTSUPPORTED: PA in slot2 (Ethernet) > requires > base h/w revision of (1.14) for this chassis > Oct 7 18:11:50.220: %PA-3-DEACTIVATED: port adapter in bay [2] powered > off. > > > The google info suggests this might be an earlier version of the card, > which > is why I tried a recently manufactured replacement, but with the same > result. Does anyone know what's going on, or how to fix this? > > > Thank you in advance. > Dominic > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > ----- End of original message ----- > > > From devon at noved.org Wed Oct 7 15:26:21 2009 From: devon at noved.org (Devon True) Date: Wed, 07 Oct 2009 15:26:21 -0400 Subject: [c-nsp] Anyone Running SXI2a on 6500 Sup720-3BXL Message-ID: <4ACCEB5D.1000002@noved.org> All: Anyone running 12.2(33)SXI2a on a 6500 Sup720-3BXL? We are looking at installing it on our systems and wanted to see if it has any field exposure. Features include: OSPFv2 BGP HSRP 10G interfaces Rapid STP CoPP SVIs Monitor sessions We are also planning to implement IPv6 and related protocols (OSPFv3, MP-BGP, IPv6 HSRP, etc). Any input is appreciated! -- Devon From DLasher at newedgenetworks.com Wed Oct 7 17:01:26 2009 From: DLasher at newedgenetworks.com (Lasher, Donn) Date: Wed, 7 Oct 2009 14:01:26 -0700 Subject: [c-nsp] GSR CPU Process is very HIGH 95% In-Reply-To: <4ACCBB62.8030004@templin.org> References: <82957ce50910070532i44454871mb90376a5b1460ab4@mail.gmail.com><6E4D2678AC543844917CA081C9D6B33F729B86@XMB-AMS-103.cisco.com><82957ce50910070610x5fcd478cje2b0e9773fde7551@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F729BBF@XMB-AMS-103.cisco.com> <4ACCBB62.8030004@templin.org> Message-ID: -----Original Message----- From: Pete Templin [mailto:petelists at templin.org] Subject: Re: [c-nsp] GSR CPU Process is very HIGH 95% Lasher, Donn wrote: >> To clarify, this depends on both the card type (engine 0/1/2/3/4/5) and >> traffic type (mpls, DSCP marking, etc). You can be doing everything >> right, and still have 50% CPU with the wrong combination of those two.. >> (For example, MPLS Labeling and Engine0 GIG-E card at 100M of traffic) >Right, but that'd be 50% CPU on the linecard, not on the xRP, right? > >(In other words, you'd find 50% CPU by doing 'execute-on all sh proc c s >| e 0.0.%' but wouldn't find it by doing 'sh proc c s | e 0.0.%'.) No, in the example I gave, 100M of CE-PE MPLS traffic (IE the router is labeling/unlabeling) on an Engine0 1-port GIG-E line card will run the Processor CPU up nice and high. Swap the Engine0 LC for an Engine3 LC (4-port), and the Proc CPU is sub 5% with the same traffic patterns. Whether it's interrupts, whether it's packet handling, the Processor CPU load is affected. (FWIW, in a P-role, forwarding already-labeled traffic, it doesn't appear to have the same CPU hit) From eninja at gmail.com Wed Oct 7 22:31:46 2009 From: eninja at gmail.com (e ninja) Date: Wed, 7 Oct 2009 19:31:46 -0700 Subject: [c-nsp] GSR CPU Process is very HIGH 95% In-Reply-To: References: <82957ce50910070532i44454871mb90376a5b1460ab4@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F729B86@XMB-AMS-103.cisco.com> <82957ce50910070610x5fcd478cje2b0e9773fde7551@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F729BBF@XMB-AMS-103.cisco.com> <4ACCBB62.8030004@templin.org> Message-ID: On Wed, Oct 7, 2009 at 2:01 PM, Lasher, Donn wrote: > -----Original Message----- > From: Pete Templin [mailto:petelists at templin.org] > Subject: Re: [c-nsp] GSR CPU Process is very HIGH 95% > > Lasher, Donn wrote: > > >> To clarify, this depends on both the card type (engine 0/1/2/3/4/5) > and > >> traffic type (mpls, DSCP marking, etc). You can be doing everything > >> right, and still have 50% CPU with the wrong combination of those > two.. > >> (For example, MPLS Labeling and Engine0 GIG-E card at 100M of > traffic) > > >Right, but that'd be 50% CPU on the linecard, not on the xRP, right? > > > >(In other words, you'd find 50% CPU by doing 'execute-on all sh proc c > s > >| e 0.0.%' but wouldn't find it by doing 'sh proc c s | e 0.0.%'.) > > No, in the example I gave, 100M of CE-PE MPLS traffic (IE the router is > labeling/unlabeling) on an Engine0 1-port GIG-E line card will run the > Processor CPU up nice and high. *That is because an Eng 0 LC switches traffic in software i.e. the LC CPU does each and every lookup off the LC FIB table ( a rather CPU intensive activity - at....you guessed it, LC CPU "interrupt level") - which was downloaded as normal from the RP FIB table. (GSR Architecture in four bullet points) The GSR (and most distributed platforms are designed as follows... * - *RP takes care of coalescing routes, creating FIB tables and all other housekeeping activities.* - *RP pushes FIB table down to all LCs and IOS 'inconsistency checker' runs every so often to ensure the 'consistency' of RP and LC copies of FIB tables et al. * - *If LC has hardware switching capabilities (i.e. > Eng 1)...yipppe. It switches packets in HW (ASIC) or else...* - *It switches in software i.e. LC CPU 'manually' does the CEF table lookup for each and every packet header - very CPU intensive. However, if, for some strange reason, a route doesn't exists on LC CEF table, the LC will punt to RP CPU. And RP will the final say on what happens to the packet. * ** Eninja From poxman at cisco.com Thu Oct 8 00:55:53 2009 From: poxman at cisco.com (Paul Oxman (poxman)) Date: Thu, 8 Oct 2009 12:55:53 +0800 Subject: [c-nsp] Problem encountered while securing NTP In-Reply-To: References: Message-ID: Hello, Cisco PSIRT will be amending the NTP advisory to reflect the encountered bug, update should be available in about 24 hours. CSCsw79186 will be available in 12.4(24)T2, which according to our knowledge, should be available for download on Cisco.Com mid-October/2009. It is also currently fixed in 15.0(1)M. Regards Name: Paul Oxman Phone: +65 6317 7418 Mobile: +65 9111 0157 Title: PSIRT Incident Manager PGP Key: 0x6EA839A6 Have you seen the Security Intelligence Operations Portal http://www.cisco.com/security Have you seen the new Cisco Security Blog: http://blogs.cisco.com/security From eninja at gmail.com Thu Oct 8 04:33:01 2009 From: eninja at gmail.com (Eninja) Date: Thu, 8 Oct 2009 10:33:01 +0200 Subject: [c-nsp] GSR CPU Process is very HIGH 95% In-Reply-To: References: <82957ce50910070532i44454871mb90376a5b1460ab4@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F729B86@XMB-AMS-103.cisco.com> <82957ce50910070610x5fcd478cje2b0e9773fde7551@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F729BBF@XMB-AMS-103.cisco.com> <4ACCBB62.8030004@templin.org> Message-ID: <47D0D670-1A49-4747-9C10-EEDA0F7019FF@gmail.com> Sent from my iPhone - apologies for typos. On Oct 8, 2009, at 4:31 AM, e ninja wrote: > > > On Wed, Oct 7, 2009 at 2:01 PM, Lasher, Donn > wrote: > -----Original Message----- > From: Pete Templin [mailto:petelists at templin.org] > Subject: Re: [c-nsp] GSR CPU Process is very HIGH 95% > > Lasher, Donn wrote: > > >> To clarify, this depends on both the card type (engine 0/1/2/3/4/5) > and > >> traffic type (mpls, DSCP marking, etc). You can be doing > everything > >> right, and still have 50% CPU with the wrong combination of those > two.. > >> (For example, MPLS Labeling and Engine0 GIG-E card at 100M of > traffic) > > >Right, but that'd be 50% CPU on the linecard, not on the xRP, right? > > > >(In other words, you'd find 50% CPU by doing 'execute-on all sh > proc c > s > >| e 0.0.%' but wouldn't find it by doing 'sh proc c s | e 0.0.%'.) > > No, in the example I gave, 100M of CE-PE MPLS traffic (IE the router > is > labeling/unlabeling) on an Engine0 1-port GIG-E line card will run the > Processor CPU up nice and high. > > That is because an Eng 0 LC switches traffic in software i.e. the LC > CPU does each and every lookup off the LC FIB table ( a rather CPU > intensive activity - at....you guessed it, LC CPU "interrupt level") > - which was downloaded as normal from the RP FIB table. > > (GSR Architecture in four bullet points) > > The GSR (and most distributed platforms are designed as follows... > RP takes care of coalescing routes, creating FIB tables and all > other housekeeping activities. > RP pushes FIB table down to all LCs and IOS 'inconsistency checker' > runs every so often to ensure the 'consistency' of RP and LC copies > of FIB tables et al. > If LC has hardware switching capabilities (i.e. > Eng 1)...yipppe. > It switches packets in HW (ASIC) or else... > It switches in software i.e. LC CPU 'manually' does the CEF table > lookup for each and every packet header - very CPU intensive. > However, if, for some strange reason, a route doesn't exists on LC > CEF table, the LC will punt to RP CPU. And RP will the final say on > what happens to the packet. PS. Needless to say that nearly all packets that get punted to the RP will be 'management' traffic and packets destined to the device itself - which should be little since these are core routers and therefore have minimal impact on RP CPUs. Bottomline, the whole idea of distributed switching is to take the 'load' off the RP and 'outsource' packet switching to the ingress LCs. Therefore, RP CPU on a distributed architecture platform that is configured well _should_ never be under a consistently heavy CPU load above device baseline figures. Eninja From ivan at ig.sk Thu Oct 8 04:03:46 2009 From: ivan at ig.sk (Ivan Gasparik) Date: Thu, 8 Oct 2009 10:03:46 +0200 Subject: [c-nsp] Cisco 3400 port shaping message limitation In-Reply-To: <323aca890910070920i5df1f5f5qef6d7778fb552a52@mail.gmail.com> References: <323aca890910070920i5df1f5f5qef6d7778fb552a52@mail.gmail.com> Message-ID: <200910081003.46363.ivan@ig.sk> Hi, There are different shape rates supported if service-policy attached to a port operating at different physical speed. I assume that ports of your switch don't operate at the same speed. Ivan On Wednesday 07 October 2009, Pavel Skovajsa wrote: > Hello all, > > I was in the middle of the configuration of ME-3400-24TS-A > (12.2(50)SE1) for port-shaping and run into interesting message: > > censw(config-if)#! > censw(config-if)#! > censw(config-if)#interface FastEthernet0/12 > censw(config-if)#service-policy output UNI-out-internet-1024kbps > censw(config-if)#service-policy input UNI-in-internet-1024kbps > censw(config-if)#! > censw(config-if)#! > censw(config-if)#interface FastEthernet0/22 > censw(config-if)#service-policy output UNI-out-internet-1024kbps > censw(config-if)#service-policy input UNI-in-internet-1024kbps > censw(config-if)#! > censw(config-if)#! > censw(config-if)#interface FastEthernet0/5 > censw(config-if)#service-policy output UNI-out-internet-1024kbps > QoS: Configuration failed. The configured rate 1024000 bps is not > achievable in hw within 1% of configuration. > Closest value(s) are: 1111111 bps, 1000000 bps > censw(config-if)#service-policy input UNI-in-internet-1024kbps > censw(config-if)# > censw(config-if)#service-policy output UNI-out-internet-1024kbps > QoS: Configuration failed. The configured rate 1024000 bps is not > achievable in hw within 1% of configuration. > Closest value(s) are: 1111111 bps, 1000000 bps > censw(config-if)#service-policy output UNI-out-internet-1024kbps > QoS: Configuration failed. The configured rate 1024000 bps is not > achievable in hw within 1% of configuration. > Closest value(s) are: 1111111 bps, 1000000 bps > > > The configuration of the policy-map is straightforward: > policy-map UNI-out-internet-1024kbps > class class-default > shape average 1024000 > queue-limit 272 > > The setting of the queue-limit is configured according to the > recommendation over here: > http://www.cisco.com/en/US/docs/switches/metro/me3400/software/rele >ase/12.2_52_se/configuration/guide/swqos.html#wp1497063 > > After little experimenting I figured out that when I change the > policy-map to this: > policy-map UNI-out-internet-1024kbps > class class-default > shape average 1000000 > queue-limit 272 > > It starts to work fine. The question still remains, what does this > error message actually mean, and why it got triggered when I > applied the policy to the 3rd interface in a row.... > > Can somebody shed some light into this? > > Regards, > Pavel Skovajsa > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From p.mayers at imperial.ac.uk Thu Oct 8 05:18:57 2009 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Thu, 08 Oct 2009 10:18:57 +0100 Subject: [c-nsp] Anyone Running SXI2a on 6500 Sup720-3BXL In-Reply-To: <4ACCEB5D.1000002@noved.org> References: <4ACCEB5D.1000002@noved.org> Message-ID: <4ACDAE81.80406@imperial.ac.uk> Devon True wrote: > All: > > Anyone running 12.2(33)SXI2a on a 6500 Sup720-3BXL? We are looking at > installing it on our systems and wanted to see if it has any field exposure. > > Features include: > > OSPFv2 > BGP > HSRP > 10G interfaces > Rapid STP > CoPP > SVIs > Monitor sessions There is a bug in SXI (all versions) where the new "monitor capture" session (i.e. local tcpdump-like facility) breaks future ERSPAN sessions. I am awaiting the bug ID from TAC. > > We are also planning to implement IPv6 and related protocols (OSPFv3, > MP-BGP, IPv6 HSRP, etc). We're using more or less all of the above, including the v6 features, and it seems to work. We've only got it on one router as of yet though. From kron at linkey.ru Thu Oct 8 06:32:19 2009 From: kron at linkey.ru (Aleksandr Gurbo) Date: Thu, 8 Oct 2009 14:32:19 +0400 Subject: [c-nsp] In Service Software Upgrade Message-ID: <20091008143219.a0793326.kron@linkey.ru> Hello, I want upgrade IOS on the cisco 7600 with two Sup32 without rebooting. I use for this ISSU procedure. I try migrate from SRC to SRD branch. IOS is upgraded, but downtime duration is about 280 seconds. All sessions(ospf, mpls, bgp) with neighbors was lost. NSF and GR(for mpls,ospf,bgp) are turned on. In ISSU process I saw that c7600 has switched from SSO to RPR mode. All interface cards have been reloaded. I thought that the problem in IOS, because I use different branches of IOS(SRC->SRD3). For the test, I tried to switch from SRD2 to SRD3 - the result is the same. I think the problem is in the switching mode(from SSO to RPR). How to upgrade IOS without downtime? -- Aleksandr Gurbo From twelcome at mobileemail.vodafonesa.co.za Thu Oct 8 06:36:13 2009 From: twelcome at mobileemail.vodafonesa.co.za (twelcome at mobileemail.vodafonesa.co.za) Date: Thu, 8 Oct 2009 10:36:13 +0000 Subject: [c-nsp] Cisco 7609 Temperature monitoring Anomalies Message-ID: <2075969783-1254998229-cardhu_decombobulator_blackberry.rim.net-1233247153-@bda192.bisx.produk.on.blackberry> Hi List I'm currently monitoring temperature of inlets and outlets of a 7609 router via snmp and via ios commands, and I see that for some modules the inlet temperature is higher than the outlet temperature. Now, either the chassis is having a net cooling effect in some areas (not all), or the sensors are confused. The readings taken from the ios command line confirm what we're reading via snmp, so I've ruled out mib issues. Another question: what is the discrepancy (in general terms) between the chassis sensor readings at inlets, and the air temperature read using a handheld thermometer next to the inlet? Should they be close, I.e is the router reported temperature at the inlet a reasonable approximation of the ambient vault temperature? Thanks, Traiano Sent via my BlackBerry from Vodacom - let your email find you! From Marcus.Gerdon at versatel.de Thu Oct 8 05:32:58 2009 From: Marcus.Gerdon at versatel.de (Marcus.Gerdon) Date: Thu, 8 Oct 2009 11:32:58 +0200 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 Message-ID: <227142482560EF458FF1F7E784E26AB80140EDE5@FLBVEXCH01.versatel.local> But traceroute's one of the killer apps for Sup720's regardless if used in 6500 or 7600. Dependent on the traffic you pass through there might be lots of 'TTL expired' (nearly fully originating from running traceroutes, else I'd suspect you've another more serious problem). Running plain-IP-configuration passing 10-15gbps originating mostly from residential internet access across a 7600 I've seen a good 20% CPU coming from roughly 2000 'TTL expired's *per second*. The ever more widespread abuse of traceroute (before someone starts arguing: yes, I call permanent use of mtr and alike for end-user pseudo-monitoring 'network abuse') is something you'll be forced into limiting to protect your network at some point in time despite the complaints of some customers not understanding the technology behind. Marcus > -----Urspr?ngliche Nachricht----- > Von: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von Bob Snyder > Gesendet: Mittwoch, 7. Oktober 2009 21:19 > An: cisco-nsp at puck.nether.net > Betreff: Re: [c-nsp] SUP720 - 12.2(18)SXF17 > > On Mon, Oct 5, 2009 at 5:43 AM, Phil Mayers > wrote: > > > mls rate-limit all ttl-failure 100 10 > > mls rate-limit all mtu-failure 100 10 > > > > There's no reason not to have the TTL failure rate limit > enabled AFAIK. > > Choose a value appropriate to you, obviously. > > One gotcha here is that busy routers will start dropping traceroute > packets as the trace hits routers that are actively rate-limiting. > Even through end to end traffic isn't affected, you may get user calls > (or confused network admins) complaining about packet loss because of > a misleading traceroute. > > Still definitely a good idea, but something to consider when setting > thresholds and managing expectations. > > Bob > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From achatz at forthnet.gr Thu Oct 8 08:03:33 2009 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Thu, 08 Oct 2009 15:03:33 +0300 Subject: [c-nsp] Cisco 3400 port shaping message limitation In-Reply-To: <323aca890910070920i5df1f5f5qef6d7778fb552a52@mail.gmail.com> References: <323aca890910070920i5df1f5f5qef6d7778fb552a52@mail.gmail.com> Message-ID: <4ACDD515.9080302@forthnet.gr> This has to do with the granularity of the ME-3400 hardware for the shaping action. There is a formula for port shaping ( 1 - 16/N ) * rate, where N is from 17 to 64K, that can give you all the possible values (rate is the interface speed). As you can see from the formula, you have awful granularity at the low end and very good granularity at the high end. The opposite is happening with class-based shaping. Btw, ME-3400E is much better on this one. -- Tassos Pavel Skovajsa wrote on 07/10/2009 19:20: > Hello all, > > I was in the middle of the configuration of ME-3400-24TS-A > (12.2(50)SE1) for port-shaping and run into interesting message: > > censw(config-if)#! > censw(config-if)#! > censw(config-if)#interface FastEthernet0/12 > censw(config-if)#service-policy output UNI-out-internet-1024kbps > censw(config-if)#service-policy input UNI-in-internet-1024kbps > censw(config-if)#! > censw(config-if)#! > censw(config-if)#interface FastEthernet0/22 > censw(config-if)#service-policy output UNI-out-internet-1024kbps > censw(config-if)#service-policy input UNI-in-internet-1024kbps > censw(config-if)#! > censw(config-if)#! > censw(config-if)#interface FastEthernet0/5 > censw(config-if)#service-policy output UNI-out-internet-1024kbps > QoS: Configuration failed. The configured rate 1024000 bps is not > achievable in hw within 1% of configuration. > Closest value(s) are: 1111111 bps, 1000000 bps > censw(config-if)#service-policy input UNI-in-internet-1024kbps > censw(config-if)# > censw(config-if)#service-policy output UNI-out-internet-1024kbps > QoS: Configuration failed. The configured rate 1024000 bps is not > achievable in hw within 1% of configuration. > Closest value(s) are: 1111111 bps, 1000000 bps > censw(config-if)#service-policy output UNI-out-internet-1024kbps > QoS: Configuration failed. The configured rate 1024000 bps is not > achievable in hw within 1% of configuration. > Closest value(s) are: 1111111 bps, 1000000 bps > > > The configuration of the policy-map is straightforward: > policy-map UNI-out-internet-1024kbps > class class-default > shape average 1024000 > queue-limit 272 > > The setting of the queue-limit is configured according to the > recommendation over here: > http://www.cisco.com/en/US/docs/switches/metro/me3400/software/release/12.2_52_se/configuration/guide/swqos.html#wp1497063 > > After little experimenting I figured out that when I change the > policy-map to this: > policy-map UNI-out-internet-1024kbps > class class-default > shape average 1000000 > queue-limit 272 > > It starts to work fine. The question still remains, what does this > error message actually mean, and why it got triggered when I applied > the policy to the 3rd interface in a row.... > > Can somebody shed some light into this? > > Regards, > Pavel Skovajsa > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From synack at live.com Thu Oct 8 08:19:46 2009 From: synack at live.com (Darin Herteen) Date: Thu, 8 Oct 2009 07:19:46 -0500 Subject: [c-nsp] In Service Software Upgrade In-Reply-To: <20091008143219.a0793326.kron@linkey.ru> References: <20091008143219.a0793326.kron@linkey.ru> Message-ID: I may be incorrect here but I don't believe SSO ISSU is supported for upgrades from 12.2(33)SRB/SRC to 12.2(33)SRDx I received the following from TAC when opening a case quite similar to this a while back: Thank you for all of the information you have provided. The failure you are seeing with the ISSU upgrade from 12.2(33)SRB5 to 12.2(33)SRD or SRD1 is because SSO ISSU is not supported for upgrades from 12.2(33)SRB and 12.2(33)SRC images to 12.2(33)SRD. To upgrade from SRB and SRC releases to SRD, RPR mode must be used and should be the configured redundancy mode prior to the upgrade process. CSCsm32582 SSO based ISSU process needs to be blocked between SRB/SRC and SRD Internally found moderate (Sev3) bug: R-Resolved The following software bug was filed because because when trying to upgrade from SRB or SRC to SRD via SSO ISSU, the router should default back to RPR and not SSO, which leads to the failure. This is an external bug you can access on Cisco.com, however, I have included the release notes below as well. CSCsv90323 SRB2/SRB4 CCO to SRD CCO upgrade failed Externally found severe (Sev2) bug: A-Assigned Release-note: Symptoms: ISSU upgrade to Cisco IOS Release 12.2(33)SRD did not put router into route processor redundancy (RPR) mode. Conditions: Occurs when "no service image-version efsu" is enabled. During ISSU upgrade from Cisco IOS Release 12.2(33)SRB or SRC to Cisco IOS Release 12.2(33)SRD, the router incorrectly goes into stateful switchover (SSO). The correct mode is RPR because SSO ISSU from these releases to Cisco IOS Release 12.2(33)SRD is not supported. Workaround: Remove the "no service image-version efsu" configuration by the default "service image-version efsu" and continue the upgrade process. Further Problem Description: If any of the following Config, Exec or ROMMON variables are set, the SSO-based ISSU will not be blocked: Config: "no service image-version efsu", "no service image-version compatibility", Exec: "issu image-version compatibility disable", ROMMON variable: RED_MODE = "RPR_PLUS' RED_MODE_SSO RF_REDUN_COMP = 1 When performing any ISSU upgrade from SRB/SRC to SRD, make sure none of the above overrides is set on the router. The "service image-version efsu" command detects the incompatibility and puts the router in RPR mode. I hope some of this information was helpful. I have been in the process of upgrading about 8 7600's and I have run into bug after bug with regards to the upgrade process.. Darin Herteen. > Date: Thu, 8 Oct 2009 14:32:19 +0400 > From: kron at linkey.ru > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] In Service Software Upgrade > > Hello, > > I want upgrade IOS on the cisco 7600 with two Sup32 without rebooting. I use for this ISSU procedure. > I try migrate from SRC to SRD branch. IOS is upgraded, but downtime duration is about 280 seconds. All sessions(ospf, mpls, bgp) with neighbors was lost. NSF and GR(for mpls,ospf,bgp) are turned on. > In ISSU process I saw that c7600 has switched from SSO to RPR mode. All interface cards have been reloaded. I thought that the problem in IOS, because I use different branches of IOS(SRC->SRD3). For the test, I tried to switch from SRD2 to SRD3 - the result is the same. > I think the problem is in the switching mode(from SSO to RPR). > > How to upgrade IOS without downtime? > > -- > Aleksandr Gurbo > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _________________________________________________________________ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/171222985/direct/01/ From linux.yahoo at gmail.com Thu Oct 8 09:31:36 2009 From: linux.yahoo at gmail.com (Manu Chao) Date: Thu, 8 Oct 2009 15:31:36 +0200 Subject: [c-nsp] In Service Software Upgrade In-Reply-To: <20091008143219.a0793326.kron@linkey.ru> References: <20091008143219.a0793326.kron@linkey.ru> Message-ID: <7100ed370910080631sa916bb3o649d6550bf3cf82d@mail.gmail.com> ISSU not possible on 7600 platform (possible on CRS-1, ASR 9000, Nexus 7000) On Thu, Oct 8, 2009 at 12:32 PM, Aleksandr Gurbo wrote: > Hello, > > I want upgrade IOS on the cisco 7600 with two Sup32 without rebooting. I > use for this ISSU procedure. > I try migrate from SRC to SRD branch. IOS is upgraded, but downtime > duration is about 280 seconds. All sessions(ospf, mpls, bgp) with neighbors > was lost. NSF and GR(for mpls,ospf,bgp) are turned on. > In ISSU process I saw that c7600 has switched from SSO to RPR mode. All > interface cards have been reloaded. I thought that the problem in IOS, > because I use different branches of IOS(SRC->SRD3). For the test, I tried to > switch from SRD2 to SRD3 - the result is the same. > I think the problem is in the switching mode(from SSO to RPR). > > How to upgrade IOS without downtime? > > -- > Aleksandr Gurbo > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From cisco-nsp at ml.karotte.org Thu Oct 8 10:16:40 2009 From: cisco-nsp at ml.karotte.org (Sebastian Wiesinger) Date: Thu, 8 Oct 2009 16:16:40 +0200 Subject: [c-nsp] In Service Software Upgrade In-Reply-To: <7100ed370910080631sa916bb3o649d6550bf3cf82d@mail.gmail.com> References: <20091008143219.a0793326.kron@linkey.ru> <7100ed370910080631sa916bb3o649d6550bf3cf82d@mail.gmail.com> Message-ID: <20091008141640.GA19729@danton.fire-world.de> * Manu Chao [2009-10-08 15:32]: > ISSU not possible on 7600 platform (possible on CRS-1, ASR 9000, Nexus 7000) It certainly is, I used it on an 7606/3B-XL to upgrade from SRB5 to SRB5a. Didn't work very good but it worked. Regards, Sebastian -- New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From jeff-kell at utc.edu Thu Oct 8 10:33:09 2009 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 08 Oct 2009 10:33:09 -0400 Subject: [c-nsp] Problem encountered while securing NTP In-Reply-To: References: Message-ID: <4ACDF825.4010805@utc.edu> While we're on the subject, I came in this morning to find our core 6500 out of NTP sync. Checking the associations, a local host was in the list as a "dynamic" association, with an invalid time. I was under the (apparently incorrect) assumption that IOS would not accept unsolicited/unconfigured NTP control requests from anyone... as I haven't revisited my NTP configuration in years. The IOS in question (12.2(33)SXI2) does not have a "ntp broadcast client" option I can simply turn off, as the generic NTP configuration suggests. The access-group documentation is a bit confusing... I'd like to have control requests restricted to my configured 'ntp server' list, but allow queries from anyone, and certainly not accept NTP updates from unsolicited sources. Does anyone have a nice, canned NTP config to accomplish this goal they would care to share? Thanks, Jeff From rwest at zyedge.com Thu Oct 8 10:46:45 2009 From: rwest at zyedge.com (Ryan West) Date: Thu, 8 Oct 2009 10:46:45 -0400 Subject: [c-nsp] Cost Effective Traffic Shaping Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DE6F9D84@zy-ex1.zyedge.local> Hello group, I'm looking for a cost effective way to provide traffic shaping CIR and PIR rates for a group of customers in a small data center offering. The infrastructure is very small, currently only two 3560G-48TS's, but adequate for their needs. Tuning the shapers on the 3560's isn't really what I'm looking for as it will only scale to 4 and I won't have anything quantitative to show from it via Cacti or other polling methods. I was originally leaning towards an ebay special 7204VXR with a NPE-G1 or a 3845 as the aggregate upstream bandwidth from the primary carrier is 200 mbps. The router performance doc lists the 3845 at 256 mbps, but with shaping enabled, it doesn't seem that it will fit the bill. The NPE-G1 can push 521 mbps, so that has me covered. Neither one of these routers is necessarily budget conscience for the size of the engagement. However, the ME 3400G-2CS seems to be a good fit. Are there other viable products I'm overlooking and could anyone provide some feedback of using the ME3400 in this type of scenario? Besides shaping, I'm only looking to terminate a default originate BGP session on the device as well. Thanks guys! -ryan From p.mayers at imperial.ac.uk Thu Oct 8 12:03:04 2009 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Thu, 08 Oct 2009 17:03:04 +0100 Subject: [c-nsp] Problem encountered while securing NTP In-Reply-To: <4ACDF825.4010805@utc.edu> References: <4ACDF825.4010805@utc.edu> Message-ID: <4ACE0D38.1080201@imperial.ac.uk> Jeff Kell wrote: > While we're on the subject, I came in this morning to find our core 6500 > out of NTP sync. Checking the associations, a local host was in the > list as a "dynamic" association, with an invalid time. Yeah, we've seen that. You need an ACL. This is dumb. To anyone from cisco reading - this is dumb, fix it. > > I was under the (apparently incorrect) assumption that IOS would not > accept unsolicited/unconfigured NTP control requests from anyone... as I > haven't revisited my NTP configuration in years. > > The IOS in question (12.2(33)SXI2) does not have a "ntp broadcast > client" option I can simply turn off, as the generic NTP configuration > suggests. > > The access-group documentation is a bit confusing... > > I'd like to have control requests restricted to my configured 'ntp > server' list, but allow queries from anyone, and certainly not accept > NTP updates from unsolicited sources. > > Does anyone have a nice, canned NTP config to accomplish this goal they > would care to share? Ours does not do what you need; it restricts NTP querying to the NTP servers & our management network (nagios checks the routers are in-sync with an NTP query packet). Give the caveat mentioned earlier in the thread (CSCsw79186) it's not clear to me that you *can* do what you want. Any reason you can't just run an NTP server? From james at gitflorida.com Thu Oct 8 11:52:38 2009 From: james at gitflorida.com (James P. Ashton) Date: Thu, 8 Oct 2009 11:52:38 -0400 (EDT) Subject: [c-nsp] BGP Router CPU Utilization Sup720+iBGP+IPv6 In-Reply-To: <1923944.16861255016939417.JavaMail.root@mail.gitflorida.com> Message-ID: <17846795.16881255017158927.JavaMail.root@mail.gitflorida.com> Hello everyone, I have just turned up iBGP between 2 7609s with Sup720-3BXLs (12.2(33)SRD1 AdIpServices) I am now showing a constant 50% CPU use for the BGP Router process. These routers have 450M of memory free. I have 2 Full table IPv4 peers on each and an IPv4 iBGP session between them using Lo0. I am attempting the same iBGP setup using IPv6. This is the iBGP config I have added to each router. Very similar to what I have with IPv4. ====================== neighbor internalv6 peer-group neighbor internalv6 remote-as 1*** neighbor internalv6 description iBGP-peers neighbor internalv6 update-source Loopback0 neighbor internalv6 version 4 ! neighbor 2607:****:*:*::1 remote-as 1*** neighbor 2607:****:*:*::1 peer-group internal ! address-family ipv6 neighbor internalv6 send-community neighbor internalv6 next-hop-self neighbor internalv6 soft-reconfiguration inbound neighbor 2607:****:*:*::1 activate exit-address-family ======================= Any thoughts on the CPU usage..? I have one IPv6 session with a Level3 tunnel prior to this and had no CPU issues. But am about to turn up another v6 link. This one on the second router. Thats what prompted the iBGP turnup. Thanks James From eng_mssk at hotmail.com Thu Oct 8 13:35:56 2009 From: eng_mssk at hotmail.com (Mohammad Khalil) Date: Thu, 8 Oct 2009 20:35:56 +0300 Subject: [c-nsp] server with 2 urls Message-ID: hey all I have a server with 2 interface cards I want to put each interface in a different networks and want to put 2 html pages on the server i want each one to be accessable separated Can be this is be done ? Can cisco router spearate requests ? Or is there any other way Thanks _________________________________________________________________ Windows Live: Make it easier for your friends to see what you?re up to on Facebook. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009 From eng_mssk at hotmail.com Thu Oct 8 13:36:30 2009 From: eng_mssk at hotmail.com (Mohammad Khalil) Date: Thu, 8 Oct 2009 20:36:30 +0300 Subject: [c-nsp] server with 2 urls Message-ID: hey all I have a server with 2 interface cards I want to put each interface in a different networks and want to put 2 html pages on the server i want each one to be accessable separated Can be this is be done ? Can cisco router spearate requests ? Or is there any other way Thanks _________________________________________________________________ Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail?. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009 From james at gitflorida.com Thu Oct 8 13:35:34 2009 From: james at gitflorida.com (James P. Ashton) Date: Thu, 8 Oct 2009 13:35:34 -0400 (EDT) Subject: [c-nsp] BGP Router CPU Utilization Sup720+iBGP+IPv6 In-Reply-To: <17846795.16881255017158927.JavaMail.root@mail.gitflorida.com> Message-ID: <17671650.16941255023334464.JavaMail.root@mail.gitflorida.com> Oddly enough, It seams to have run at 50% CPU for about an hour and is now back at 3% and seams to be stable there... This concerns me a bit. I don't see any errata regarding this for this IOS rev. ----- Original Message ----- From: "James P. Ashton" To: cisco-nsp at puck.nether.net Sent: Thursday, October 8, 2009 11:52:38 AM GMT -05:00 US/Canada Eastern Subject: [c-nsp] BGP Router CPU Utilization Sup720+iBGP+IPv6 Hello everyone, I have just turned up iBGP between 2 7609s with Sup720-3BXLs (12.2(33)SRD1 AdIpServices) I am now showing a constant 50% CPU use for the BGP Router process. These routers have 450M of memory free. I have 2 Full table IPv4 peers on each and an IPv4 iBGP session between them using Lo0. I am attempting the same iBGP setup using IPv6. This is the iBGP config I have added to each router. Very similar to what I have with IPv4. ====================== neighbor internalv6 peer-group neighbor internalv6 remote-as 1*** neighbor internalv6 description iBGP-peers neighbor internalv6 update-source Loopback0 neighbor internalv6 version 4 ! neighbor 2607:****:*:*::1 remote-as 1*** neighbor 2607:****:*:*::1 peer-group internal ! address-family ipv6 neighbor internalv6 send-community neighbor internalv6 next-hop-self neighbor internalv6 soft-reconfiguration inbound neighbor 2607:****:*:*::1 activate exit-address-family ======================= Any thoughts on the CPU usage..? I have one IPv6 session with a Level3 tunnel prior to this and had no CPU issues. But am about to turn up another v6 link. This one on the second router. Thats what prompted the iBGP turnup. Thanks James _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From justin at justinshore.com Thu Oct 8 16:50:03 2009 From: justin at justinshore.com (Justin Shore) Date: Thu, 08 Oct 2009 15:50:03 -0500 Subject: [c-nsp] Anomaly Detection Module/Anomaly Guard Module In-Reply-To: References: Message-ID: <4ACE507B.603@justinshore.com> Drew Weaver wrote: > I was wondering if anyone has any experience working with the Cisco ADM AGM modules for the 6500s and how they compare with external appliance based solutions for DDoS mitigation. > > Anyone have any opinions on these? > > It seems like it would be nice to just drop these into a few systems but I'm just trying to avoid caveats that mitigate (pun intended) the usefulness of these products. If you try to buy the LCs your account team should try to convince you to go with the appliances instead. My account team told me that they LCs are being terminated at some point in the future and replaced with the appliances so if you buy the LCs today you will most likely run into software limitations down the road as appliances get all the good stuff and the LCs get bug fixes only (at some point in their life at least). I'd go with the appliances. Justin From jared at puck.nether.net Thu Oct 8 16:59:25 2009 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 8 Oct 2009 16:59:25 -0400 Subject: [c-nsp] Anomaly Detection Module/Anomaly Guard Module In-Reply-To: <4ACE507B.603@justinshore.com> References: <4ACE507B.603@justinshore.com> Message-ID: <51F19E38-FC7E-419B-B67F-FE1F1A946E57@puck.nether.net> On Oct 8, 2009, at 4:50 PM, Justin Shore wrote: > Drew Weaver wrote: >> I was wondering if anyone has any experience working with the Cisco >> ADM AGM modules for the 6500s and how they compare with external >> appliance based solutions for DDoS mitigation. >> Anyone have any opinions on these? >> It seems like it would be nice to just drop these into a few >> systems but I'm just trying to avoid caveats that mitigate (pun >> intended) the usefulness of these products. > > If you try to buy the LCs your account team should try to convince > you to go with the appliances instead. My account team told me that > they LCs are being terminated at some point in the future and > replaced with the appliances so if you buy the LCs today you will > most likely run into software limitations down the road as > appliances get all the good stuff and the LCs get bug fixes only (at > some point in their life at least). I'd go with the appliances. There have been a number of different rumors floating around related to this that I've heard. I certainly would avoid investing in something that does not have a clear roadmap. If they can't present you roadmap slides, panic? Either way, there are other solutions in this space as well. - Jared From gsgranados at comcast.net Thu Oct 8 17:05:41 2009 From: gsgranados at comcast.net (Scott Granados) Date: Thu, 8 Oct 2009 14:05:41 -0700 Subject: [c-nsp] Anomaly Detection Module/Anomaly Guard Module References: <4ACE507B.603@justinshore.com> <51F19E38-FC7E-419B-B67F-FE1F1A946E57@puck.nether.net> Message-ID: <01ba01ca485b$1f084560$0202fea9@am.thmulti.com> Arbor Networks has some great products in this area. ----- Original Message ----- From: "Jared Mauch" To: "Justin Shore" Cc: Sent: Thursday, October 08, 2009 1:59 PM Subject: Re: [c-nsp] Anomaly Detection Module/Anomaly Guard Module > > On Oct 8, 2009, at 4:50 PM, Justin Shore wrote: > >> Drew Weaver wrote: >>> I was wondering if anyone has any experience working with the Cisco >>> ADM AGM modules for the 6500s and how they compare with external >>> appliance based solutions for DDoS mitigation. >>> Anyone have any opinions on these? >>> It seems like it would be nice to just drop these into a few >>> systems but I'm just trying to avoid caveats that mitigate (pun >>> intended) the usefulness of these products. >> >> If you try to buy the LCs your account team should try to convince >> you to go with the appliances instead. My account team told me that >> they LCs are being terminated at some point in the future and >> replaced with the appliances so if you buy the LCs today you will >> most likely run into software limitations down the road as >> appliances get all the good stuff and the LCs get bug fixes only (at >> some point in their life at least). I'd go with the appliances. > > There have been a number of different rumors floating around related > to this that I've heard. I certainly would avoid investing in > something that does not have a clear roadmap. If they can't present > you roadmap slides, panic? > > Either way, there are other solutions in this space as well. > > - Jared > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From lsawyer at gci.com Thu Oct 8 18:22:40 2009 From: lsawyer at gci.com (Leif Sawyer) Date: Thu, 8 Oct 2009 14:22:40 -0800 Subject: [c-nsp] So when is IPv6 failover coming to the ASA? In-Reply-To: Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102B91C@fnb1mbx01.gci.com> Andrew Yourtchenko writes, in response to > Nick Hilliard whom wrote: > >> Unfortunately, ASA boxes are beloved of enterprises, and >> ipv6 is very much down the list as far as the enterprise >> market segment is concerned. The service provider market >> has significantly different needs, but Cisco's ASA product >> managers are not especially focussed on this segment. > > 8.2.2 should make the ipv6 and failover better friends than > they are now. How about some love for the FWSM's as well? I'm part of a service provider operation. We don't get any love for IPv6 support here. Driving me crazy. I mean, seriously, do I have to rip out the FWSM's and put in 10GE trunks to a pair of Linux boxes just to get IPv4+IPv6 to work correctly at the same time? It'd probably save me time and effort in the long run. Sigh. And while you're at it, Cisco, *PLEASE* fix the ASDM IPv6 support such that I can just drop in the IPv6 object into an existing rule, and the back end figures out the magic? I shouldn't have to duplicate all my rules for both IPv4 and IPv6. From brandon at burn.net Thu Oct 8 19:18:15 2009 From: brandon at burn.net (Brandon Applegate) Date: Thu, 8 Oct 2009 19:18:15 -0400 (EDT) Subject: [c-nsp] CEF flags explanation ? Message-ID: So I've been fighting a strange issue all day. I have a prefix that is having reachability issues, and after exhausting all the normal 'internet is broken' checks, traceroutes etc, I find that a traceroute inside my own AS doesn't even work (well). The one thing I find different about this prefix are the 'flags' from show ip cef x.x.x.x detail. Other 'healthy' prefixes don't have this. Routing table looks fine BTW. router#sh ip cef 192.168.0.0 detail | inc flags 192.168.0.0/24, epoch 11, flags need ps clean 'flags need ps clean' - that's the head scratcher. I have a TAC case opened on it, but I thought I might get a quicker and better answer from the list. Thanks in advance. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 "SH1-0151. This is the serial number, of our orbital gun." From will-lists at collier-byrd.net Thu Oct 8 22:38:06 2009 From: will-lists at collier-byrd.net (Byrd, William) Date: Thu, 8 Oct 2009 22:38:06 -0400 Subject: [c-nsp] Anomaly Detection Module/Anomaly Guard Module In-Reply-To: <1ebb7fa90910081436n764809f1v9166bb17311eb35@mail.gmail.com> References: <4ACE507B.603@justinshore.com> <51F19E38-FC7E-419B-B67F-FE1F1A946E57@puck.nether.net> <01ba01ca485b$1f084560$0202fea9@am.thmulti.com> <1ebb7fa90910081436n764809f1v9166bb17311eb35@mail.gmail.com> Message-ID: <1ebb7fa90910081938r2ae216fex10b43075c4c7c743@mail.gmail.com> Sorry if this comes through as a double post. I sent it hours ago but I never saw it show up. As I am in the process of wrapping up an Arbor Peakflow SP deployment right now I'd whole heartedly agree with this statement. A few things I'd strongly recommend to anyone deploying this with Cisco gear keep in mind however: - You're not getting TCP flags off of 6500/7600 routers - The Supervisors for 6500/7600 routers do not currently generate Netflow for MPLS switched packets (majority of this SP's traffic) - Netflow in general on the 6500/7600 routers isn't wonderful. You'll probably need to be running pretty new code to get any kind of worthwhile Netflow data - If you purchase the Arbor TMS you might have to do a lot of work with it to get it installed and mitigating attacks in a way that works on your network. The TMS is amazingly flexible however so you have a lot of different options for this. Caveats listed above aside the Arbor support staff and in particular our Sales Engineer have been wonderful and amazingly responsive. My Sales Engineer has worked with me as late as 11:30 - 12:00 EST on getting our deployment up and running. (12 - 14 hour days. Mind blown.) If you're seriously looking into buying a security product I'd throw my suggestion behind the Peakflow SP solution. Arbor really has incredible support. Cisco could stand to learn a few lessons from them on how to run a Support organization. -Will (No I do not work for Arbor) On Thu, Oct 8, 2009 at 5:05 PM, Scott Granados wrote: > Arbor Networks has some great products in this area. > From dale.shaw+cisco-nsp at gmail.com Fri Oct 9 00:00:58 2009 From: dale.shaw+cisco-nsp at gmail.com (Dale Shaw) Date: Fri, 9 Oct 2009 15:00:58 +1100 Subject: [c-nsp] WCCPv2 - issuing "ip wccp" command over "ip wccp accelerated" Message-ID: <3329cbb40910082100x4acb609av418085576616d6fc@mail.gmail.com> Hi all, One from left field -- Does anyone know what the impact (if any) is on a hardware-based platform (in my case a 6500/SUP2/MSFC2) running: ip wccp 61 accelerated ip wccp 62 accelerated ..when the following commands are issued over the top? ip wccp 61 ip wccp 62 There are active WAEs in the 61/62 service groups, but they're already configured for l2-redirect and mask assignment. Unfortunately I don't have a similarly configured 6500 available to play on. I just want to know if this is likely to cause some kind of WCCP re-negotiation and whether it's likely to result in a disruption to traffic flow. If I understand the usage of "accelerated" correctly, it doesn't actually do anything 'extra' as long as the WAEs are L2 adjacent and configured for l2-redirect/mask assign: hardware-accelerated WCCP should be negotiated anyway. Just trying to standardise some configs. cheers, Dale From ayourtch at cisco.com Thu Oct 8 23:59:56 2009 From: ayourtch at cisco.com (Andrew Yourtchenko) Date: Fri, 9 Oct 2009 05:59:56 +0200 (CEST) Subject: [c-nsp] So when is IPv6 failover coming to the ASA? In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102B91C@fnb1mbx01.gci.com> References: <18B2C6E38A3A324986B392B2D18ABC5102B91C@fnb1mbx01.gci.com> Message-ID: On Thu, 8 Oct 2009, Leif Sawyer wrote: > Andrew Yourtchenko writes, in response to >> Nick Hilliard whom wrote: >> >>> Unfortunately, ASA boxes are beloved of enterprises, and >>> ipv6 is very much down the list as far as the enterprise >>> market segment is concerned. The service provider market >>> has significantly different needs, but Cisco's ASA product >>> managers are not especially focussed on this segment. >> >> 8.2.2 should make the ipv6 and failover better friends than >> they are now. > > How about some love for the FWSM's as well? > > I'm part of a service provider operation. We don't get any love > for IPv6 support here. Driving me crazy. > > I mean, seriously, do I have to rip out the FWSM's and put in > 10GE trunks to a pair of Linux boxes just to get IPv4+IPv6 to work > correctly at the same time? > > It'd probably save me time and effort in the long run. Sigh. My mail was about ASA. What was applicable to FWSM, I wrote in a thread half a year ago - my apologies for not being able to add anything to that. < and if I were to write anything about messengers, it'd go here :-) > > > And while you're at it, Cisco, *PLEASE* fix the ASDM IPv6 support > such that I can just drop in the IPv6 object into an existing > rule, and the back end figures out the magic? I shouldn't have to > duplicate all my rules for both IPv4 and IPv6. ASDM rules<->config is bidirectional, so the magic would need to be an invertible function - hence it is more difficult than it seems. Nonetheless, I'll mention this to ASDM folks when I have a chance. Mind unicasting me your config so I could take a look at it ? @all: does everyone (who does deal with firewalls+IPv6) have also the almost identical IPv4 and IPv6 policies ? kind regards, andrew From zafarullah_pk at hotmail.com Fri Oct 9 00:39:25 2009 From: zafarullah_pk at hotmail.com (zafar ullah) Date: Fri, 9 Oct 2009 10:39:25 +0600 Subject: [c-nsp] ASA Firewalls placement in the network! Message-ID: Hi List Members! I am a new user of this list so please accept my apology in advance, if my post looks silly. I want to ask list users a question regarding ASA Firewalls placement in the existing network. Please see below for question; Where should the firewalls be placed in the network topology? e.g. Firewalls at the edge of network facing internet cloud or behind routers, in which case router will be facing internet and firewalls will precede routers. What you guys suggest, which is best approach for robust & scalable secure network? Also please guide me to some pointer for pros & cons of both approaches. Thanks & Regards Iqbal! _________________________________________________________________ Windows Live: Keep your friends up to date with what you do online. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010 From rdobbins at arbor.net Fri Oct 9 01:05:41 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 9 Oct 2009 12:05:41 +0700 Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: References: Message-ID: <64FEF27A-B8AF-4EB5-839E-93CB2D72021D@arbor.net> On Oct 9, 2009, at 11:39 AM, zafar ullah wrote: > What you guys suggest, which is best approach for robust & scalable > secure network? Firewalls have no place in front of servers at all. They add no security value at all, and make the servers behind them vastly more vulnerable to DDoS, as well as greatly increasing the attack surface if so-called 'protocol inspectors' are enabled. Server access policies should be enforced via a mixture of host/OS/app BCPs and stateless filtering via ACLs in hardware-based routers. Firewalls do make sense for protecting access LANs for enterprises. Firewalls deployed for this purpose must by definition be placed behind the enterprise edge router(s) and in front of the internal enterprise access network. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From will-lists at collier-byrd.net Thu Oct 8 17:36:19 2009 From: will-lists at collier-byrd.net (Byrd, William) Date: Thu, 8 Oct 2009 17:36:19 -0400 Subject: [c-nsp] Anomaly Detection Module/Anomaly Guard Module In-Reply-To: <01ba01ca485b$1f084560$0202fea9@am.thmulti.com> References: <4ACE507B.603@justinshore.com> <51F19E38-FC7E-419B-B67F-FE1F1A946E57@puck.nether.net> <01ba01ca485b$1f084560$0202fea9@am.thmulti.com> Message-ID: <1ebb7fa90910081436n764809f1v9166bb17311eb35@mail.gmail.com> As I am in the process of wrapping up an Arbor Peakflow SP deployment right now I'd whole heartedly agree with this statement. A few things I'd strongly recommend to anyone deploying this with Cisco gear keep in mind however: - You're not getting TCP flags off of 6500/7600 routers - The Supervisors for 6500/7600 routers do not currently generate Netflow for MPLS switched packets (majority of this SP's traffic) - Netflow in general on the 6500/7600 routers isn't wonderful. You'll probably need to be running pretty new code to get any kind of worthwhile Netflow data - If you purchase the Arbor TMS you might have to do a lot of work with it to get it installed and mitigating attacks in a way that works on your network. The TMS is amazingly flexible however so you have a lot of different options for this. Caveats listed above aside the Arbor support staff and in particular our Sales Engineer have been wonderful and amazingly responsive. My Sales Engineer has worked with me as late as 11:30 - 12:00 EST on getting our deployment up and running. (12 - 14 hour days. Mind blown.) If you're seriously looking into buying a security product I'd throw my suggestion behind the Peakflow SP solution. Arbor really has incredible support. Cisco could stand to learn a few lessons from them on how to run a Support organization. -Will (No I do not work for Arbor) On Thu, Oct 8, 2009 at 5:05 PM, Scott Granados wrote: > Arbor Networks has some great products in this area. > > ----- Original Message ----- From: "Jared Mauch" > To: "Justin Shore" > Cc: > Sent: Thursday, October 08, 2009 1:59 PM > Subject: Re: [c-nsp] Anomaly Detection Module/Anomaly Guard Module > > > > >> On Oct 8, 2009, at 4:50 PM, Justin Shore wrote: >> >> Drew Weaver wrote: >>> >>>> I was wondering if anyone has any experience working with the Cisco ADM >>>> AGM modules for the 6500s and how they compare with external appliance >>>> based solutions for DDoS mitigation. >>>> Anyone have any opinions on these? >>>> It seems like it would be nice to just drop these into a few systems >>>> but I'm just trying to avoid caveats that mitigate (pun intended) the >>>> usefulness of these products. >>>> >>> >>> If you try to buy the LCs your account team should try to convince you >>> to go with the appliances instead. My account team told me that they LCs >>> are being terminated at some point in the future and replaced with the >>> appliances so if you buy the LCs today you will most likely run into >>> software limitations down the road as appliances get all the good stuff and >>> the LCs get bug fixes only (at some point in their life at least). I'd go >>> with the appliances. >>> >> >> There have been a number of different rumors floating around related to >> this that I've heard. I certainly would avoid investing in something that >> does not have a clear roadmap. If they can't present you roadmap slides, >> panic? >> >> Either way, there are other solutions in this space as well. >> >> - Jared >> > From kron at linkey.ru Fri Oct 9 02:05:50 2009 From: kron at linkey.ru (Aleksandr Gurbo) Date: Fri, 9 Oct 2009 10:05:50 +0400 Subject: [c-nsp] In Service Software Upgrade In-Reply-To: <20091008143219.a0793326.kron@linkey.ru> References: <20091008143219.a0793326.kron@linkey.ru> Message-ID: <20091009100550.8de72880.kron@linkey.ru> Answer from Cisco TAC: I verified the bug you mentioned, it is fixed in 12.2(33)SRD1, so it should not have caused the failure with upgrade from SRD2 to SRD3. I found another bug that can bring the device to RPR mode during ISSU, bug id is CSCsm98000, this bug is also fixed in 12.2(33)SRD, so it should have caused the failure with upgrade from SRD2 to SRD3. > Hello, > > I want upgrade IOS on the cisco 7600 with two Sup32 without rebooting. I use for this ISSU procedure. > I try migrate from SRC to SRD branch. IOS is upgraded, but downtime duration is about 280 seconds. All sessions(ospf, mpls, bgp) with neighbors was lost. NSF and GR(for mpls,ospf,bgp) are turned on. > In ISSU process I saw that c7600 has switched from SSO to RPR mode. All interface cards have been reloaded. I thought that the problem in IOS, because I use different branches of IOS(SRC->SRD3). For the test, I tried to switch from SRD2 to SRD3 - the result is the same. > I think the problem is in the switching mode(from SSO to RPR). > > How to upgrade IOS without downtime? -- Alexandr Gurbo From blahu77 at gmail.com Fri Oct 9 04:28:28 2009 From: blahu77 at gmail.com (Mateusz Blaszczyk) Date: Fri, 9 Oct 2009 09:28:28 +0100 Subject: [c-nsp] Migrate 6500 to 7600 In-Reply-To: <20090829163907.GF31692@thorgal> References: <20090829163907.GF31692@thorgal> Message-ID: <20091009082828.GB8830@thorgal> On Sat, Aug 29, 2009 at 05:39:07PM +0100, Mateusz Blaszczyk wrote: > List, > > We are going to replace a chassis of our core router (SUP720). > At the moment it is a standard 6509, but the new one is going to be a > smaller 7606S, using the same SUP720 (also the plan is to update the TCAM > with XL memory upgrade kit). The box is running SXF. > > Did anyone undergo such switchover? Are there any gotchas to avoid, some > tips(howtos) to follow? We will run SRB or SRC, not sure yet. For the archives We finalized the migration yesterday. First device was pretty straightforward as ppl suggested. Second not so much. So : 1) We decided to go with SRB6 as we don't need features/bugs? from SRC,D. This still works fine for us, I am aware that SRB will be deprecated sometime in the future so I will keep an eye on the archives here and upgrade when appropriate. 2) Gotcha#1 - remeber to format your flash (if you are using a new one) under the SXF IOS, when I did it under SRD (on a distinct device), it won't boot at all. 3) Gotcha#2 - the 3BXL upgrade is 2 stage process - you need to upgrade memory DIMMs and install a PFC daughtercard. On the second occasion the memory DIMMs were not seated properly. After installing the the upgraded SUP into new chassis, there was no console output, no LEDs on, nothing. After reseating DIMM modules SUP booted no probs. This is documented in troubleshooting section on the leaflet that comes with 3BXL upgrade kit. 4) Gotcha#3 (or stupidity on our part) - as, I think Gert mentioned, bring up first 1 IGP adjacency, then get your full BGP feed, then bring all other IGP adjacencies. That will save you from creating huge loops in the network. Mea culpa. That's all for now. Best Regards, -mat -- Mateusz Blaszczyk pgp-key 0x64643FCE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From gert at greenie.muc.de Fri Oct 9 06:28:08 2009 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 9 Oct 2009 12:28:08 +0200 Subject: [c-nsp] So when is IPv6 failover coming to the ASA? In-Reply-To: References: <18B2C6E38A3A324986B392B2D18ABC5102B91C@fnb1mbx01.gci.com> Message-ID: <20091009102808.GT1508@greenie.muc.de> Hi, On Fri, Oct 09, 2009 at 05:59:56AM +0200, Andrew Yourtchenko wrote: > @all: does everyone (who does deal with firewalls+IPv6) have also the > almost identical IPv4 and IPv6 policies ? Right now, our policies tend to diverge a bit, due to having to maintain them individually and us being lazy people ("there is a problem -> adjust IPv4 now, fix IPv6 later on"). Firewalls being what they are, that is, policy enforcement devices, our policies actually *should* be very similar in many cases, e.g.: - office networks can do outbound HTTP/HTTPS "to access the web" (no need to distinguish v4 or v6 here) - mail server is reachable on SMTP and POP3/IMAP "from the world", and SSH "from the office networks" - again, no need to have differences between v4/v6 here (well, "the office network" is a different address block, of course, but the *concept* is the same) so indeed, having integrated v4+v6 firewall management would prevent lots of extra work and configuration accidents. Of course you need to have the option to do "v4-only" or "v6-only" in special cases. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From A.L.M.Buxey at lboro.ac.uk Fri Oct 9 06:57:29 2009 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Fri, 9 Oct 2009 11:57:29 +0100 Subject: [c-nsp] So when is IPv6 failover coming to the ASA? In-Reply-To: <20091009102808.GT1508@greenie.muc.de> References: <18B2C6E38A3A324986B392B2D18ABC5102B91C@fnb1mbx01.gci.com> <20091009102808.GT1508@greenie.muc.de> Message-ID: <20091009105729.GB12594@lboro.ac.uk> Hi, > > @all: does everyone (who does deal with firewalls+IPv6) have also the > > almost identical IPv4 and IPv6 policies ? pretty much so - why would the policy be any different? incoming port 80 traffic to a web server is same whether its v4 or v6 - the target must be known and checked. likewise outgoing customer traffic etc. its just a new way of delivering the same TCP/UDP data after all. the only different we have is with respect to allowed multicast and ICMP as IPv6 uses a lot of that to function properly :-) alan From kilobit at gmail.com Fri Oct 9 07:30:23 2009 From: kilobit at gmail.com (bas) Date: Fri, 9 Oct 2009 13:30:23 +0200 Subject: [c-nsp] In Service Software Upgrade In-Reply-To: <7100ed370910080631sa916bb3o649d6550bf3cf82d@mail.gmail.com> References: <20091008143219.a0793326.kron@linkey.ru> <7100ed370910080631sa916bb3o649d6550bf3cf82d@mail.gmail.com> Message-ID: On Thu, Oct 8, 2009 at 3:31 PM, Manu Chao wrote: > ISSU not possible on 7600 platform (possible on CRS-1, ASR 9000, Nexus 7000) I would not say ISSU (where U stands for Upgrade) is possible on the CRS-1. Updates are sometimes possible without traffic interruption, but upgrades are not. Where upgrades have anything to do with newer versions and updates are "patches" Of the last 20 SMU's provided by cisco for 3.6.2 only 11 were without traffic interruption. Real fun doing reloads on CRS-1's most take about 45 minutes from start to end.. So imagine the maintenance window you have to plan for 8 SMU's that require a reload. I regularly get flak from management why our million dollar routers require so many reboots while I told them these shiny routers could do ISSU, Bastiaan From ayourtch at cisco.com Fri Oct 9 07:30:56 2009 From: ayourtch at cisco.com (Andrew Yourtchenko) Date: Fri, 9 Oct 2009 13:30:56 +0200 (CEST) Subject: [c-nsp] So when is IPv6 failover coming to the ASA? In-Reply-To: <20091009105729.GB12594@lboro.ac.uk> References: <18B2C6E38A3A324986B392B2D18ABC5102B91C@fnb1mbx01.gci.com> <20091009102808.GT1508@greenie.muc.de> <20091009105729.GB12594@lboro.ac.uk> Message-ID: Hi Alan, Gert, first of all - thanks for sharing! On Fri, 9 Oct 2009, Alan Buxey wrote: >>> @all: does everyone (who does deal with firewalls+IPv6) have also the >>> almost identical IPv4 and IPv6 policies ? > > pretty much so - why would the policy be any different? incoming port 80 E.g. if someone has the applications that they know are IPv4-only, depending on the security policy one might either keep both v6 and v4 ports open, or only v4. I've seen much more v4-only policies than v4+v6, so wanted to get a better picture. > traffic to a web server is same whether its v4 or v6 - the target must > be known and checked. likewise outgoing customer traffic etc. its just > a new way of delivering the same TCP/UDP data after all. > > the only different we have is with respect to allowed multicast and ICMP > as IPv6 uses a lot of that to function properly :-) > Indeed. :-) kind regards, andrew From dgranzer at gmail.com Fri Oct 9 07:58:28 2009 From: dgranzer at gmail.com (David Granzer) Date: Fri, 9 Oct 2009 13:58:28 +0200 Subject: [c-nsp] MLS QoS 6500/7600 Message-ID: <844ef89c0910090458o14893037k50be70bf91136ee4@mail.gmail.com> Hello, please could anybody explain the diffrence when 6500/7600 running with MLS QoS enabled (mls qos) and when running with MLS QoS disabled "no mls qos" ? Regards, David From drew.weaver at thenap.com Fri Oct 9 08:58:30 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 9 Oct 2009 08:58:30 -0400 Subject: [c-nsp] Anomaly Detection Module/Anomaly Guard Module In-Reply-To: <01ba01ca485b$1f084560$0202fea9@am.thmulti.com> References: <4ACE507B.603@justinshore.com> <51F19E38-FC7E-419B-B67F-FE1F1A946E57@puck.nether.net> <01ba01ca485b$1f084560$0202fea9@am.thmulti.com> Message-ID: Yes, they do but most of the implementation of arbor products i've seen also include Cisco Guard (for some reason). I've never been clear on the interconnectedness of the two products. thanks, -Drew -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados Sent: Thursday, October 08, 2009 5:06 PM To: Jared Mauch; Justin Shore Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Anomaly Detection Module/Anomaly Guard Module Arbor Networks has some great products in this area. ----- Original Message ----- From: "Jared Mauch" To: "Justin Shore" Cc: Sent: Thursday, October 08, 2009 1:59 PM Subject: Re: [c-nsp] Anomaly Detection Module/Anomaly Guard Module > > On Oct 8, 2009, at 4:50 PM, Justin Shore wrote: > >> Drew Weaver wrote: >>> I was wondering if anyone has any experience working with the Cisco >>> ADM AGM modules for the 6500s and how they compare with external >>> appliance based solutions for DDoS mitigation. >>> Anyone have any opinions on these? >>> It seems like it would be nice to just drop these into a few >>> systems but I'm just trying to avoid caveats that mitigate (pun >>> intended) the usefulness of these products. >> >> If you try to buy the LCs your account team should try to convince >> you to go with the appliances instead. My account team told me that >> they LCs are being terminated at some point in the future and >> replaced with the appliances so if you buy the LCs today you will >> most likely run into software limitations down the road as >> appliances get all the good stuff and the LCs get bug fixes only (at >> some point in their life at least). I'd go with the appliances. > > There have been a number of different rumors floating around related > to this that I've heard. I certainly would avoid investing in > something that does not have a clear roadmap. If they can't present > you roadmap slides, panic? > > Either way, there are other solutions in this space as well. > > - Jared > _______________________________________________ > cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From drew.weaver at thenap.com Fri Oct 9 09:01:43 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 9 Oct 2009 09:01:43 -0400 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: <227142482560EF458FF1F7E784E26AB80140EDE5@FLBVEXCH01.versatel.local> References: <227142482560EF458FF1F7E784E26AB80140EDE5@FLBVEXCH01.versatel.local> Message-ID: I assume you were being sarcastic when you said: " But traceroute's one of the killer apps for Sup720's regardless if used in 6500 or 7600." as we have found out that whenever the BGP Scanner process goes wild it totally botches trace routes. Apparently this is not an issue on the GSR because the line cards originate the ICMP unreachables but on the 6500/7600 platform the unreachables come from the RP (or so I'm told). Has anyone found a way to make any headway on cleaning up the ugly traceroute effect of BGP Scanner? I obviously realize that traceroutes are all but worthless as far as diagnostics go, but it's a "presentation" thing. thanks, -Drew -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Marcus.Gerdon Sent: Thursday, October 08, 2009 5:33 AM To: Bob Snyder; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] SUP720 - 12.2(18)SXF17 But traceroute's one of the killer apps for Sup720's regardless if used in 6500 or 7600. Dependent on the traffic you pass through there might be lots of 'TTL expired' (nearly fully originating from running traceroutes, else I'd suspect you've another more serious problem). Running plain-IP-configuration passing 10-15gbps originating mostly from residential internet access across a 7600 I've seen a good 20% CPU coming from roughly 2000 'TTL expired's *per second*. The ever more widespread abuse of traceroute (before someone starts arguing: yes, I call permanent use of mtr and alike for end-user pseudo-monitoring 'network abuse') is something you'll be forced into limiting to protect your network at some point in time despite the complaints of some customers not understanding the technology behind. Marcus > -----Urspr?ngliche Nachricht----- > Von: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von Bob Snyder > Gesendet: Mittwoch, 7. Oktober 2009 21:19 > An: cisco-nsp at puck.nether.net > Betreff: Re: [c-nsp] SUP720 - 12.2(18)SXF17 > > On Mon, Oct 5, 2009 at 5:43 AM, Phil Mayers > wrote: > > > mls rate-limit all ttl-failure 100 10 > > mls rate-limit all mtu-failure 100 10 > > > > There's no reason not to have the TTL failure rate limit > enabled AFAIK. > > Choose a value appropriate to you, obviously. > > One gotcha here is that busy routers will start dropping traceroute > packets as the trace hits routers that are actively rate-limiting. > Even through end to end traffic isn't affected, you may get user calls > (or confused network admins) complaining about packet loss because of > a misleading traceroute. > > Still definitely a good idea, but something to consider when setting > thresholds and managing expectations. > > Bob > _______________________________________________ > cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From jared at puck.nether.net Fri Oct 9 09:16:27 2009 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 9 Oct 2009 09:16:27 -0400 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: References: <227142482560EF458FF1F7E784E26AB80140EDE5@FLBVEXCH01.versatel.local> Message-ID: <666DA8E3-45C0-48AD-8DFB-FA83097DDB7D@puck.nether.net> I think it's important to note that there are similar limiters in other devices, eg: Juniper m20/m40 that we've encountered over the years. This has caused customer confusion as they hit these, even in a fully distributed linecard environment. The reality is unless it's done in a low-level ASIC, it can easily turn into a security vulnerability. Drop 5 gigs of ttl=1 traffic at a device and it will fall over unless there is some protection. It may not even need to be as high as 5g. There are a lot of rate-limiters available, check out 'show mls rate- limit' on your Earl7 (76k, ie: (65|76)00) based device. Set them low to avoid problems. I find 100/10 works well. - Jared On Oct 9, 2009, at 9:01 AM, Drew Weaver wrote: > I assume you were being sarcastic when you said: " But traceroute's > one of the killer apps for Sup720's regardless if used in 6500 or > 7600." as we have found out that whenever the BGP Scanner process > goes wild it totally botches trace routes. Apparently this is not an > issue on the GSR because the line cards originate the ICMP > unreachables but on the 6500/7600 platform the unreachables come > from the RP (or so I'm told). Has anyone found a way to make any > headway on cleaning up the ugly traceroute effect of BGP Scanner? I > obviously realize that traceroutes are all but worthless as far as > diagnostics go, but it's a "presentation" thing. > > thanks, > -Drew From p.mayers at imperial.ac.uk Fri Oct 9 10:10:58 2009 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Fri, 09 Oct 2009 15:10:58 +0100 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: <666DA8E3-45C0-48AD-8DFB-FA83097DDB7D@puck.nether.net> References: <227142482560EF458FF1F7E784E26AB80140EDE5@FLBVEXCH01.versatel.local> <666DA8E3-45C0-48AD-8DFB-FA83097DDB7D@puck.nether.net> Message-ID: <4ACF4472.50407@imperial.ac.uk> Jared Mauch wrote: > I think it's important to note that there are similar limiters in > other devices, eg: Juniper m20/m40 that we've encountered over the > years. > > This has caused customer confusion as they hit these, even in a fully > distributed linecard environment. The reality is unless it's done in > a low-level ASIC, it can easily turn into a security vulnerability. > > Drop 5 gigs of ttl=1 traffic at a device and it will fall over unless > there is some protection. It may not even need to be as high as 5g. > > There are a lot of rate-limiters available, check out 'show mls rate- > limit' on your Earl7 (76k, ie: (65|76)00) based device. Set them low > to avoid problems. I find 100/10 works well. One point worth adding - some of the rate-limiters can do more harm than good, in some cases a *lot* more harm than good. The main examples cited tend to be the "CEF RECEIVE" and "CEF GLEAN" ones. Both just serve to drop traffic earlier than it would otherwise, but with no granularity, so an attacker can DoS the CPU for legitimate services. CoPP is far superior to the former, and the latter is hard to fix without per-layer3-interface rate-limiters. I also vaguely recall TAC telling me there are underlying problems with the CEF GLEAN one, but they never forwarded the bug ID to me. But I agree, we set 100/10 for RPF/TTL/UNREACH-no-route/MTU failure, and I'm glad of it, because it's saved us from a couple of nasties. From Marcus.Gerdon at versatel.de Fri Oct 9 10:04:12 2009 From: Marcus.Gerdon at versatel.de (Marcus.Gerdon) Date: Fri, 9 Oct 2009 16:04:12 +0200 Subject: [c-nsp] WG: SUP720 - 12.2(18)SXF17 Message-ID: <227142482560EF458FF1F7E784E26AB80140F60F@FLBVEXCH01.versatel.local> Hi Drew! Unfortunately not. I've been through that discussion initially about 2 years back. The initial state had been 5min-average cpu runing at 60-70% at SXE, lowering to 40-50% after upgrade to SXF10 (the peer-group not working bug of SXE had been one of the heavier culprits) which is still far too much (approx. 100 bgp sessions at that time). I didn't find the cpu graph from that time back anymore but only an email regarding the results from the following discussion regarding the traceroute results. Reconfiguring the 'TTL expired's from no limit down to 100 per sec gained another 15-25% of cpu (dependent on the number of subscribers connected to the attached access systems). I've actively seen that across reconfiguration under load. First we've got a bunch of discussions about the rate-limit and resulting 'poor' presentation traceroutes gives after limiting it but they only pop up occasionally (once a month or so) nowadays. Most I like 'it's no traceoute, my mtr shows there's packet loss' - nothing to comment on that. Despite the discussions it's been definitely worth the trouble. The bgp scanner issue eating up 100% cpu every 60s is something that's seen at all platforms, just that the lc's in really active systems like the gsr aren't effected by the engine cpu. I think this is some process-priority/queing-topic somewhere inside. One interesting thing I've seen then was that the bgp scanner seemingly doesn't go along with maximum priority in the process chain. After limiting the TTL's the time taken by the scanner to be completed also reduced by a few seconds. This suggests that processing of packets in RP or at least generating the ICMP's picks some cpu time off the bgp scanner process. If you've a larger number of residential access flowing through your network you just might want to give the limiters a try and see how cpu changes (never seen any service affecting issue when configuring those under load). regards, Marcus ---------------------------------------------------------------------------------------- Engineering IP Services Versatel West GmbH Unterste-Wilms-Strasse 29 D-44143 Dortmund Fon: +49-(0)231-399-4486 | Fax: +49-(0)231-399-4491 marcus.gerdon at versatel.de | www.versatel.de Sitz der Gesellschaft: Dortmund | Registergericht: Dortmund HRB 21738 Gesch?ftsf?hrer: Marc L?tzenkirchen, Dr. Hai Cheng, Dr. Max Padberg, Peter Schindler ---------------------------------------------------------------------------------------- AS8881 / AS8638 / AS13270 | MG3031-RIPE ---------------------------------------------------------------------------------------- From Marcus.Gerdon at versatel.de Fri Oct 9 10:17:53 2009 From: Marcus.Gerdon at versatel.de (Marcus.Gerdon) Date: Fri, 9 Oct 2009 16:17:53 +0200 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 Message-ID: <227142482560EF458FF1F7E784E26AB80140F619@FLBVEXCH01.versatel.local> Besides limiting TTL-1's I'm currently completely dropping (limit 0) acl-drops and rpf-failures. Everything that's being dropped by an rpf 'source any' of course doesn't need a reply, as well as any anti-spoofing/anto-bogon-acl doesn't make sense of a reply sent. Before reconfiguring a bunch of rate-limiters check for the grouping to be sure not to limit something unintentionally at a rate too low. Btw, being at mls commands: 'mls cef error action' is a nice one defaulting to 'freeze' (default checked last with SXF10). I'd have to dig for the rather old description about the command but roughly this means freezing updates to the forwarding tables in case of a detected failure. I prefer running 'recover' here - better to rebuilt tables than being stuck with an old table version :-). regards, Marcus > -----Urspr?ngliche Nachricht----- > Von: Jared Mauch [mailto:jared at puck.nether.net] > Gesendet: Freitag, 9. Oktober 2009 15:16 > An: Drew Weaver > Cc: Marcus.Gerdon; Bob Snyder; cisco-nsp at puck.nether.net > Betreff: Re: [c-nsp] SUP720 - 12.2(18)SXF17 > > I think it's important to note that there are similar limiters in > other devices, eg: Juniper m20/m40 that we've encountered over the > years. > > This has caused customer confusion as they hit these, even in > a fully > distributed linecard environment. The reality is unless it's > done in > a low-level ASIC, it can easily turn into a security vulnerability. > > Drop 5 gigs of ttl=1 traffic at a device and it will fall > over unless > there is some protection. It may not even need to be as high as 5g. > > There are a lot of rate-limiters available, check out 'show mls rate- > limit' on your Earl7 (76k, ie: (65|76)00) based device. Set them low > to avoid problems. I find 100/10 works well. > > - Jared > > On Oct 9, 2009, at 9:01 AM, Drew Weaver wrote: > > > I assume you were being sarcastic when you said: " But > traceroute's > > one of the killer apps for Sup720's regardless if used in 6500 or > > 7600." as we have found out that whenever the BGP Scanner process > > goes wild it totally botches trace routes. Apparently this > is not an > > issue on the GSR because the line cards originate the ICMP > > unreachables but on the 6500/7600 platform the unreachables come > > from the RP (or so I'm told). Has anyone found a way to make any > > headway on cleaning up the ugly traceroute effect of BGP > Scanner? I > > obviously realize that traceroutes are all but worthless as far as > > diagnostics go, but it's a "presentation" thing. > > > > thanks, > > -Drew > > From rsnyder at toontown.erial.nj.us Fri Oct 9 11:04:20 2009 From: rsnyder at toontown.erial.nj.us (Bob Snyder) Date: Fri, 9 Oct 2009 11:04:20 -0400 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: <227142482560EF458FF1F7E784E26AB80140EDE5@FLBVEXCH01.versatel.local> References: <227142482560EF458FF1F7E784E26AB80140EDE5@FLBVEXCH01.versatel.local> Message-ID: <3B1E48CC-0893-492E-8602-B6142D44AA53@toontown.erial.nj.us> On Oct 8, 2009, at 5:32 AM, Marcus.Gerdon wrote: > The ever more widespread abuse of traceroute (before someone starts > arguing: yes, I call permanent use of mtr and alike for end-user > pseudo-monitoring 'network abuse') is something you'll be forced > into limiting to protect your network at some point in time despite > the complaints of some customers not understanding the technology > behind. Oh, my comments weren't intended to say you shouldn't rate-limit TTL, only that there needs to be user/other network admin education along with the change so that people don't use traceroute to try to prove a non-existant problem. Probably a bigger deal for ISPs; I know we have routers that I am confident will show drops on any given traceroute during peak times. On Oct 9, 2009, at 9:16 AM, Jared Mauch wrote: > There are a lot of rate-limiters available, check out 'show mls rate- > limit' on your Earl7 (76k, ie: (65|76)00) based device. Set them low > to avoid problems. I find 100/10 works well. One note here is that I believe there's only 8 or so hardware rate limiters available, so you'll probably run into issues if you try and use more. Probably not a concern for most, but if you're doing a lot of different rate-limiters, it may impact you. Bob From ross at kallisti.us Fri Oct 9 11:42:18 2009 From: ross at kallisti.us (Ross Vandegrift) Date: Fri, 9 Oct 2009 11:42:18 -0400 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: <4ACF4472.50407@imperial.ac.uk> References: <227142482560EF458FF1F7E784E26AB80140EDE5@FLBVEXCH01.versatel.local> <666DA8E3-45C0-48AD-8DFB-FA83097DDB7D@puck.nether.net> <4ACF4472.50407@imperial.ac.uk> Message-ID: <20091009154218.GB29032@kallisti.us> On Fri, Oct 09, 2009 at 03:10:58PM +0100, Phil Mayers wrote: > But I agree, we set 100/10 for RPF/TTL/UNREACH-no-route/MTU failure, and > I'm glad of it, because it's saved us from a couple of nasties. How are folks arriving at the 100/10 setting? Our boxes are using 500/100, but hell if I remember how we came up with those numbers. Interesting to notice that you guys have them turned down quite a bit more than we do. -- Ross Vandegrift ross at kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From tvarriale at comcast.net Fri Oct 9 12:04:56 2009 From: tvarriale at comcast.net (Tony Varriale) Date: Fri, 9 Oct 2009 11:04:56 -0500 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 References: <227142482560EF458FF1F7E784E26AB80140EDE5@FLBVEXCH01.versatel.local> <3B1E48CC-0893-492E-8602-B6142D44AA53@toontown.erial.nj.us> Message-ID: There are 8 layer 3 and 5 layer 2 but I think some of those are reserved. sh mls rate-limit usage will show your buckets as well as if there are any shared. tv ----- Original Message ----- From: "Bob Snyder" To: Sent: Friday, October 09, 2009 10:04 AM Subject: Re: [c-nsp] SUP720 - 12.2(18)SXF17 > > On Oct 8, 2009, at 5:32 AM, Marcus.Gerdon wrote: > >> The ever more widespread abuse of traceroute (before someone starts >> arguing: yes, I call permanent use of mtr and alike for end-user >> pseudo-monitoring 'network abuse') is something you'll be forced into >> limiting to protect your network at some point in time despite the >> complaints of some customers not understanding the technology behind. > > Oh, my comments weren't intended to say you shouldn't rate-limit TTL, > only that there needs to be user/other network admin education along with > the change so that people don't use traceroute to try to prove a > non-existant problem. Probably a bigger deal for ISPs; I know we have > routers that I am confident will show drops on any given traceroute > during peak times. > > On Oct 9, 2009, at 9:16 AM, Jared Mauch wrote: > >> There are a lot of rate-limiters available, check out 'show mls rate- >> limit' on your Earl7 (76k, ie: (65|76)00) based device. Set them low to >> avoid problems. I find 100/10 works well. > > One note here is that I believe there's only 8 or so hardware rate > limiters available, so you'll probably run into issues if you try and use > more. Probably not a concern for most, but if you're doing a lot of > different rate-limiters, it may impact you. > > Bob > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From leonardo.souza at nec.com.br Fri Oct 9 09:48:30 2009 From: leonardo.souza at nec.com.br (Leonardo Gama Souza) Date: Fri, 9 Oct 2009 10:48:30 -0300 Subject: [c-nsp] RES: Migrate 6500 to 7600 In-Reply-To: <20091009082828.GB8830@thorgal> References: <20090829163907.GF31692@thorgal> <20091009082828.GB8830@thorgal> Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D02C99D0D@spsrvmail03.nec.br> > 4) Gotcha#3 (or stupidity on our part) - as, I think Gert mentioned, > bring up first 1 IGP adjacency, then get your full BGP feed, then bring > all other IGP adjacencies. > That will save you from creating huge loops in the network. Mea culpa. If you are running IS-IS, it is generally a good idea to configure 'set-overload-bit on-startup wait-for-bgp' under router isis. []?s From p.mayers at imperial.ac.uk Fri Oct 9 12:28:56 2009 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Fri, 09 Oct 2009 17:28:56 +0100 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: <20091009154218.GB29032@kallisti.us> References: <227142482560EF458FF1F7E784E26AB80140EDE5@FLBVEXCH01.versatel.local> <666DA8E3-45C0-48AD-8DFB-FA83097DDB7D@puck.nether.net> <4ACF4472.50407@imperial.ac.uk> <20091009154218.GB29032@kallisti.us> Message-ID: <4ACF64C8.3040400@imperial.ac.uk> Ross Vandegrift wrote: > On Fri, Oct 09, 2009 at 03:10:58PM +0100, Phil Mayers wrote: >> But I agree, we set 100/10 for RPF/TTL/UNREACH-no-route/MTU failure, and >> I'm glad of it, because it's saved us from a couple of nasties. > > How are folks arriving at the 100/10 setting? Our boxes are using > 500/100, but hell if I remember how we came up with those numbers. > Interesting to notice that you guys have them turned down quite a bit > more than we do. > I think I guessed ;o) More likely it's in a cisco recommendation, or I read it in a c-nsp archive posting, but I can't honestly remember. From jcposeidon at cantv.net Fri Oct 9 14:00:50 2009 From: jcposeidon at cantv.net (Juan C. Crespo R.) Date: Fri, 09 Oct 2009 13:30:50 -0430 Subject: [c-nsp] Cisco Layer 3 and Giga Message-ID: <4ACF7A52.8050503@cantv.net> Guys Could any one of you advice me a good Switch with Layer 3, Jumbo Packets support ? I was thinking about one 3550 but I'm not sure Thanks From nicholas.hatch at gmail.com Fri Oct 9 16:17:40 2009 From: nicholas.hatch at gmail.com (nick hatch) Date: Fri, 9 Oct 2009 13:17:40 -0700 Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: <64FEF27A-B8AF-4EB5-839E-93CB2D72021D@arbor.net> References: <64FEF27A-B8AF-4EB5-839E-93CB2D72021D@arbor.net> Message-ID: On Thu, Oct 8, 2009 at 10:05 PM, Roland Dobbins wrote: > > On Oct 9, 2009, at 11:39 AM, zafar ullah wrote: > > What you guys suggest, which is best approach for robust & scalable secure >> network? >> > > Firewalls have no place in front of servers at all. They add no security > value at all, and make the servers behind them vastly more vulnerable to > DDoS, as well as greatly increasing the attack surface if so-called > 'protocol inspectors' are enabled. > That is unless you're talking about an Arbor Peakflow SP Threat Managment System, right? I hear its "a fully integrated component [... which] conducts surgical mitigation of network and service-layer attacks that threaten your Internet Data Center." This glossy website in front of me also says that for Web 2.0 apps, the Peakflow device fully protects a server's Web services by stopping malformed HTTP packets and rate-limiting HTTP requests. And its abilities to protect VoIP and DNS servers, as well as generic TCP normalization techniques are well-advertised. Are you saying that Arbor networks is misguided about their server protection devices, Roland? (add an appropriate grain of salt or two...) -Nick From avayner at cisco.com Fri Oct 9 16:23:08 2009 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Fri, 9 Oct 2009 22:23:08 +0200 Subject: [c-nsp] Cisco Layer 3 and Giga In-Reply-To: <4ACF7A52.8050503@cantv.net> References: <4ACF7A52.8050503@cantv.net> Message-ID: Juan, Can you provide more information about your requirements? Routing protocols? Number of routes? Application? Etc? Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Juan C. Crespo R. Sent: Friday, October 09, 2009 20:01 To: cisco-nsp at puck.nether.net Subject: [c-nsp] Cisco Layer 3 and Giga Guys Could any one of you advice me a good Switch with Layer 3, Jumbo Packets support ? I was thinking about one 3550 but I'm not sure Thanks _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From avayner at cisco.com Fri Oct 9 16:23:53 2009 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Fri, 9 Oct 2009 22:23:53 +0200 Subject: [c-nsp] MLS QoS 6500/7600 In-Reply-To: <844ef89c0910090458o14893037k50be70bf91136ee4@mail.gmail.com> References: <844ef89c0910090458o14893037k50be70bf91136ee4@mail.gmail.com> Message-ID: David, I would suggest you read this reference: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/con figuration/guide/qos.html Basically, what is described above is turned on when "mls qos" is enabled. Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Granzer Sent: Friday, October 09, 2009 13:58 To: cisco-nsp at puck.nether.net Subject: [c-nsp] MLS QoS 6500/7600 Hello, please could anybody explain the diffrence when 6500/7600 running with MLS QoS enabled (mls qos) and when running with MLS QoS disabled "no mls qos" ? Regards, David _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From jcposeidon at cantv.net Fri Oct 9 16:35:29 2009 From: jcposeidon at cantv.net (Juan C. Crespo R.) Date: Fri, 09 Oct 2009 16:05:29 -0430 Subject: [c-nsp] Cisco Layer 3 and Giga In-Reply-To: References: <4ACF7A52.8050503@cantv.net> Message-ID: <4ACF9E91.7030104@cantv.net> BGP Jumbo Packets Not full BGP Probably OSPF, ISIS Core Arie Vayner (avayner) escribi?: > Juan, > > Can you provide more information about your requirements? > > Routing protocols? Number of routes? Application? Etc? > > Arie > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Juan C. Crespo > R. > Sent: Friday, October 09, 2009 20:01 > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] Cisco Layer 3 and Giga > > Guys > > Could any one of you advice me a good Switch with Layer 3, Jumbo > Packets support ? I was thinking about one 3550 but I'm not sure > > Thanks > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > From avayner at cisco.com Fri Oct 9 16:43:25 2009 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Fri, 9 Oct 2009 22:43:25 +0200 Subject: [c-nsp] Cisco Layer 3 and Giga In-Reply-To: <4ACF9E91.7030104@cantv.net> References: <4ACF7A52.8050503@cantv.net> <4ACF9E91.7030104@cantv.net> Message-ID: Juan, I would recommend that you take a look at the 4948 switches. They could be a good choice for small routing devices. Be aware that there is a relatively low limit for the number of routes they can support. If you require also QOS support, and more fancy features (like for example NetFlow), you should be looking at routers and not desktop switches (which are usually designed for LAN environments). Arie From: Juan C. Crespo R. [mailto:jcposeidon at cantv.net] Sent: Friday, October 09, 2009 22:35 To: Arie Vayner (avayner) Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Cisco Layer 3 and Giga BGP Jumbo Packets Not full BGP Probably OSPF, ISIS Core Arie Vayner (avayner) escribi?: Juan, Can you provide more information about your requirements? Routing protocols? Number of routes? Application? Etc? Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Juan C. Crespo R. Sent: Friday, October 09, 2009 20:01 To: cisco-nsp at puck.nether.net Subject: [c-nsp] Cisco Layer 3 and Giga Guys Could any one of you advice me a good Switch with Layer 3, Jumbo Packets support ? I was thinking about one 3550 but I'm not sure Thanks _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From jckdaniels12 at gmail.com Fri Oct 9 15:47:26 2009 From: jckdaniels12 at gmail.com (jack daniels) Date: Sat, 10 Oct 2009 01:17:26 +0530 Subject: [c-nsp] AUDIT In-Reply-To: <4ACC65ED.6040700@resolution.de> References: <8bb137f40910070050n1e1e732aoca3d5ba4411debaa@mail.gmail.com> <4ACC65ED.6040700@resolution.de> Message-ID: <8bb137f40910091247m47d1f8c9x830c2fd448f9a2e2@mail.gmail.com> Hi All, Please advise any doc which can help in studying " show Tech-support" for switch and router output while doing audit. Regards J.Daniels On Wed, Oct 7, 2009 at 3:27 PM, Thorsten Dahm wrote: > jack daniels wrote: > >> I have been assigned to do AUDIT ( LAN / WAN ) for a NETWORK comprising >> of >> devices 2950 , 3750 , 4500 , 2800 , 2600 , 7206 VXR . Please advice which >> commands showuld I need to conectrate more and check outputs for making >> audit report >> > > If you are a bit more specific about what kind of Audit we could perhaps > help better. > > For now: RANCID + diff/grep could be a good start. > > cheers, > Thorsten > From sethm at rollernet.us Fri Oct 9 16:57:29 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 09 Oct 2009 13:57:29 -0700 Subject: [c-nsp] AUDIT In-Reply-To: <8bb137f40910091247m47d1f8c9x830c2fd448f9a2e2@mail.gmail.com> References: <8bb137f40910070050n1e1e732aoca3d5ba4411debaa@mail.gmail.com> <4ACC65ED.6040700@resolution.de> <8bb137f40910091247m47d1f8c9x830c2fd448f9a2e2@mail.gmail.com> Message-ID: <4ACFA3B9.3030007@rollernet.us> jack daniels wrote: > Hi All, > > Please advise any doc which can help in studying " show Tech-support" for > switch and router output while doing audit. > Audit what? You are the one deciding what to audit, you choose what to look at. ~Seth From spinthiras.mario at gmail.com Fri Oct 9 18:51:33 2009 From: spinthiras.mario at gmail.com (Mario Spinthiras) Date: Fri, 9 Oct 2009 23:51:33 +0100 Subject: [c-nsp] AUDIT In-Reply-To: <4ACFA3B9.3030007@rollernet.us> References: <8bb137f40910070050n1e1e732aoca3d5ba4411debaa@mail.gmail.com> <4ACC65ED.6040700@resolution.de> <8bb137f40910091247m47d1f8c9x830c2fd448f9a2e2@mail.gmail.com> <4ACFA3B9.3030007@rollernet.us> Message-ID: <4f890e580910091551v3b6803ye4c7536daa3b860d@mail.gmail.com> How will the audit be focused? If you are looking for security then I would start from the design board and look at a more general view of the network with focus on end to end security and device to device. You would obviously have to build a very precise topological image of the network (even in the case of non security focused audits). In terms of configuration, there are a myriad of guidelines on the Internet and on cisco.com to follow, however I don't see the essence of doing something without the actual theory behind it. If you want to build a view of the network to work from there, then I assume you use LLDP and CDP commands to do so. However an "audit" could be anything form an intentory to a vigorous security audit. If it is a simple configuration audit, get RANCID and work from there. Could you be more specific as to what you are looking for or the specifications/guidlelines of the task? My 2p. Regards, Mario. From peter at rathlev.dk Fri Oct 9 19:01:00 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Sat, 10 Oct 2009 01:01:00 +0200 Subject: [c-nsp] MLS QoS 6500/7600 In-Reply-To: <844ef89c0910090458o14893037k50be70bf91136ee4@mail.gmail.com> References: <844ef89c0910090458o14893037k50be70bf91136ee4@mail.gmail.com> Message-ID: <1255129260.3474.14.camel@abehat.net.rm.dk> On Fri, 2009-10-09 at 13:58 +0200, David Granzer wrote: > please could anybody explain the diffrence when 6500/7600 running with > MLS QoS enabled (mls qos) and when running with MLS QoS disabled "no > mls qos" ? Here's a relatively compact and quite good explanation of 6500 QoS: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11_538840.html Remember that QoS is all about _degrading_ certain services for the benifit of other services. It will not raise the total "quality". Just enabling "mls qos" without doing anything else and without having a plan should be considered an error. When enabling QoS globally (via "mls qos") the switch will adjust certain parameters like drop thresholds and CoS-maps. Take a look at the output of "show queueing interface GiX/Y" from a configuration with and without "mls qos" to get some hints: Router#sh queueing int gi4/1 Interface GigabitEthernet4/1 queueing strategy: Weighted Round-Robin QoS is disabled globally Trust boundary disabled Trust state: trust DSCP Extend trust state: not trusted [COS = 0] Default COS is 0 Queueing Mode In Tx direction: mode-cos Transmit queues [type = 1p3q8t]: Queue Id Scheduling Num of thresholds ----------------------------------------- 01 WRR 08 02 WRR 08 03 WRR 08 04 Priority 01 WRR bandwidth ratios: 100[queue 1] 0[queue 2] 0[queue 3] queue-limit ratios: 100[queue 1] 0[queue 2] 0[queue 3] 0[Pri Queue] queue tail-drop-thresholds -------------------------- 1 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 2 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 3 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] queue random-detect-min-thresholds ---------------------------------- 1 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 2 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 3 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] queue random-detect-max-thresholds ---------------------------------- 1 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 2 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 3 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] WRED disabled queues: 1 2 3 queue thresh cos-map --------------------------------------- 1 1 0 1 2 3 4 5 6 7 1 2 1 3 1 4 1 5 1 6 1 7 1 8 2 1 2 2 2 3 2 4 2 5 2 6 2 7 2 8 3 1 3 2 3 3 3 4 3 5 3 6 3 7 3 8 4 1 Queueing Mode In Rx direction: mode-cos Receive queues [type = 1q8t]: Queue Id Scheduling Num of thresholds ----------------------------------------- 01 WRR 08 WRR bandwidth ratios: 100[queue 1] queue-limit ratios: 100[queue 1] queue tail-drop-thresholds -------------------------- 1 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] queue thresh cos-map --------------------------------------- 1 1 0 1 2 3 4 5 6 7 1 2 1 3 1 4 1 5 1 6 1 7 1 8 Packets dropped on Transmit: BPDU packets: 0 queue dropped [cos-map] --------------------------------------------- 1 0 [0 1 2 3 4 5 6 7 ] Packets dropped on Receive: BPDU packets: 0 queue dropped [cos-map] --------------------------------------------- 1 0 [0 1 2 3 4 5 6 7 ] Router# Router#conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#mls qos Router(config)#^Z Router# Router#sh queuei int gi4/1 Interface GigabitEthernet4/1 queueing strategy: Weighted Round-Robin Port QoS is enabled Trust boundary disabled Trust state: trust DSCP Extend trust state: not trusted [COS = 0] Default COS is 0 Queueing Mode In Tx direction: mode-cos Transmit queues [type = 1p3q8t]: Queue Id Scheduling Num of thresholds ----------------------------------------- 01 WRR 08 02 WRR 08 03 WRR 08 04 Priority 01 WRR bandwidth ratios: 100[queue 1] 150[queue 2] 200[queue 3] queue-limit ratios: 50[queue 1] 20[queue 2] 15[queue 3] 15[Pri Queue] queue tail-drop-thresholds -------------------------- 1 70[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 2 70[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 3 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] queue random-detect-min-thresholds ---------------------------------- 1 40[1] 70[2] 70[3] 70[4] 70[5] 70[6] 70[7] 70[8] 2 40[1] 70[2] 70[3] 70[4] 70[5] 70[6] 70[7] 70[8] 3 70[1] 70[2] 70[3] 70[4] 70[5] 70[6] 70[7] 70[8] queue random-detect-max-thresholds ---------------------------------- 1 70[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 2 70[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] 3 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] WRED disabled queues: queue thresh cos-map --------------------------------------- 1 1 0 1 2 1 1 3 1 4 1 5 1 6 1 7 1 8 2 1 2 2 2 3 4 2 3 2 4 2 5 2 6 2 7 2 8 3 1 6 7 3 2 3 3 3 4 3 5 3 6 3 7 3 8 4 1 5 Queueing Mode In Rx direction: mode-cos Receive queues [type = 1q8t]: Queue Id Scheduling Num of thresholds ----------------------------------------- 01 WRR 08 WRR bandwidth ratios: 100[queue 1] queue-limit ratios: 100[queue 1] queue tail-drop-thresholds -------------------------- 1 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8] queue thresh cos-map --------------------------------------- 1 1 0 1 2 3 4 5 6 7 1 2 1 3 1 4 1 5 1 6 1 7 1 8 Packets dropped on Transmit: BPDU packets: 0 queue dropped [cos-map] --------------------------------------------- 1 0 [0 1 ] 2 0 [2 3 4 ] 3 1 [6 7 ] 4 0 [5 ] Packets dropped on Receive: BPDU packets: 0 queue dropped [cos-map] --------------------------------------------- 1 0 [0 1 2 3 4 5 6 7 ] Router# -- Peter From bruce.horth at sheridanc.on.ca Fri Oct 9 20:09:54 2009 From: bruce.horth at sheridanc.on.ca (Bruce Horth) Date: Fri, 9 Oct 2009 20:09:54 -0400 Subject: [c-nsp] WAN Accelerator deployment in a SP network Message-ID: Hi, I am a college student working with a medium-size network service provider in southern Ontario, Canada to determine the feasibility in offering WAN Acceleration as a managed service as a final graduation project. I am hoping that people on this list may have some experience using these products both in an enterprise?environment?and specifically in a SP network. If anyone can shed some light on the following questions, I would really appreciate it: 1) Is anyone currently using WAN acceleration products from companies like Riverbed, Cisco, Juniper or Blue Coat (Packeteer)? 2) If you have deployed WAN acceleration, what were the main business reasons driving the decision to go with WAN acceleration? 3) Which products have you been most/least happy with? 4) Have you encountered any serious network outages directly attributable to a WAN acceleration appliance? Are some products more/less reliable than others? 5) Does any telco/ISP/network company offer WAN acceleration as a managed service and if so, what are some of the issues that you have dealt with (either as a customer or a provider)? I am looking for any and all feedback from people with experience in this relatively new area of networking. Thanks -- BH From bjohnson at drtel.com Fri Oct 9 23:06:49 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Fri, 9 Oct 2009 22:06:49 -0500 Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: <64FEF27A-B8AF-4EB5-839E-93CB2D72021D@arbor.net> References: <64FEF27A-B8AF-4EB5-839E-93CB2D72021D@arbor.net> Message-ID: <29A54911243620478FF59F00EBB12F4701A60D0D@ex01.drtel.lan> > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Roland Dobbins > Sent: Friday, October 09, 2009 12:06 AM > To: Cisco-nsp > Subject: Re: [c-nsp] ASA Firewalls placement in the network! > > > On Oct 9, 2009, at 11:39 AM, zafar ullah wrote: > > > What you guys suggest, which is best approach for robust & scalable > > secure network? > > Firewalls have no place in front of servers at all. They add no > security value at all, and make the servers behind them vastly more > vulnerable to DDoS, as well as greatly increasing the attack surface > if so-called 'protocol inspectors' are enabled. Server access > policies should be enforced via a mixture of host/OS/app BCPs and > stateless filtering via ACLs in hardware-based routers. So are you actually saying that DPI is a bad thing relative to server protection? What makes this a bad idea? In what way does it make them more vulnerable to attacks? My experience with crafted packet attacks (being attacked, not attacking others :P) tells me that this is a good layer of protection. What Arbor product would you like to sell me to accomplish this type of protection? > > Firewalls do make sense for protecting access LANs for enterprises. > Firewalls deployed for this purpose must by definition be placed > behind the enterprise edge router(s) and in front of the internal > enterprise access network. > Ok... So it's ok to protect end users from the Internet? Gotcha. Not trying to be snide here (at least not anymore ;P), but I doubt that the majority of CFOs would be fine leaving their servers behind simple ACLs. I would never do that. - Brian From sj_hznm at yahoo.com.cn Fri Oct 9 23:40:16 2009 From: sj_hznm at yahoo.com.cn (Joe Shen) Date: Sat, 10 Oct 2009 11:40:16 +0800 (CST) Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: Message-ID: <474272.95985.qm@web15601.mail.cnb.yahoo.com> > > That is unless you're talking about an Arbor Peakflow SP > Threat Managment > System, right? I hear its "a fully integrated component > [... which] conducts > surgical mitigation of network and service-layer attacks > that threaten your > Internet Data Center." This glossy website in front of me > also says that for > Web 2.0 apps, the Peakflow device fully protects a server's > Web services by > stopping malformed HTTP packets and rate-limiting HTTP > requests. And its > abilities to protect VoIP and DNS servers, as well as > generic TCP > normalization techniques are well-advertised. > > Are you saying that Arbor networks is misguided about their > server > protection devices, Roland? > if some guy trust Arbor peakflow anyway automatic interaction between peakflow and router could be considered. But, threshhold for trigerring and internet traffic features varies time to time, how could we expect arbot catch the way all the time? joe ___________________________________________________________ ????????????????? http://card.mail.cn.yahoo.com/ From sj_hznm at yahoo.com.cn Fri Oct 9 23:40:16 2009 From: sj_hznm at yahoo.com.cn (Joe Shen) Date: Sat, 10 Oct 2009 11:40:16 +0800 (CST) Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: Message-ID: <474272.95985.qm@web15601.mail.cnb.yahoo.com> > > That is unless you're talking about an Arbor Peakflow SP > Threat Managment > System, right? I hear its "a fully integrated component > [... which] conducts > surgical mitigation of network and service-layer attacks > that threaten your > Internet Data Center." This glossy website in front of me > also says that for > Web 2.0 apps, the Peakflow device fully protects a server's > Web services by > stopping malformed HTTP packets and rate-limiting HTTP > requests. And its > abilities to protect VoIP and DNS servers, as well as > generic TCP > normalization techniques are well-advertised. > > Are you saying that Arbor networks is misguided about their > server > protection devices, Roland? > if some guy trust Arbor peakflow anyway automatic interaction between peakflow and router could be considered. But, threshhold for trigerring and internet traffic features varies time to time, how could we expect arbot catch the way all the time? joe ___________________________________________________________ ????????????????? http://card.mail.cn.yahoo.com/ From rdobbins at arbor.net Sat Oct 10 04:49:52 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 10 Oct 2009 15:49:52 +0700 Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60D0D@ex01.drtel.lan> References: <64FEF27A-B8AF-4EB5-839E-93CB2D72021D@arbor.net> <29A54911243620478FF59F00EBB12F4701A60D0D@ex01.drtel.lan> Message-ID: On Oct 10, 2009, at 10:06 AM, Brian Johnson wrote: > So are you actually saying that DPI is a bad thing relative to server > protection? What makes this a bad idea? In what way does it make them > more vulnerable to attacks? DPI <> firewalls. > My experience with crafted packet attacks (being attacked, not > attacking > others :P) tells me that this is a good layer of protection. Concur. Again, it has nothing to do with stateful firewalls. > > What Arbor product would you like to sell me to accomplish > this type of protection? I publicly held this position when I worked for the world's largest vendor of stateful firewalls. My position was based upon operational experience then, as now. In this threat, I stated that enforcing policy should be handled by stateless ACLs in hardware. Arbor Networks doesn't make routers. > Not trying to be snide here (at least not anymore ;P), but I doubt > that > the majority of CFOs would be fine leaving their servers behind simple > ACLs. I would never do that That's because you, like your hypothetical CFOs, obviously have no experience running large-scale public-facing Internet properties. Any large-scale, publicly-visible Web site you can name doesn't have stateful firewalls in front of its servers. For a server like a DNS server, a Web server, and so forth, every connection which comes into said server is by definition unsolicited. So, the entire purpose of stateful inspection in front of such servers is moot. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From rdobbins at arbor.net Sat Oct 10 05:05:52 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 10 Oct 2009 16:05:52 +0700 Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: References: <64FEF27A-B8AF-4EB5-839E-93CB2D72021D@arbor.net> Message-ID: <55D1ED9D-B128-4446-9510-4CA5D0A05EB2@arbor.net> On Oct 10, 2009, at 3:17 AM, nick hatch wrote: > Are you saying that Arbor networks is misguided about their server > protection devices, Roland? My position on this subject, based on hands-on operational experience, was the same when I worked for the world's largest vendor of stateful firewalls as it is now - namely, that policy enforcement for servers should be handled by stateless ACLs on hardware-based routers, *not* by stateful firewalls, because it makes no sense to put a stateful inspection firewall in front of Web servers, DNS servers, et. al., as *by definition*, every connection said servers receive is unsolicited, and therefore simply not a candidate for stateful inspection in the first place. Note that my employer, Arbor Networks doesn't make routers of any type, nor indeed any sort of policy-enforcement device at all; that's not what we do. Our TMS does in fact protect firewalls and everything behind them from DDoS; we've many customers who use them for this purpose. So, as you see, I've no pecuniary interest whatsoever in stating that it makes no sense to put stateful firewalls in front of servers, as it makes not one whit of difference to us - in fact, given the propensity of firewalls to collapse under DDoS, one could say *quite the opposite*. My purpose in stating that firewalls have no place in front of servers was meant to be educational in nature, nothing more. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From rdobbins at arbor.net Sat Oct 10 05:12:59 2009 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 10 Oct 2009 16:12:59 +0700 Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: <55D1ED9D-B128-4446-9510-4CA5D0A05EB2@arbor.net> References: <64FEF27A-B8AF-4EB5-839E-93CB2D72021D@arbor.net> <55D1ED9D-B128-4446-9510-4CA5D0A05EB2@arbor.net> Message-ID: On Oct 10, 2009, at 4:05 PM, Roland Dobbins wrote: > nor indeed any sort of policy-enforcement device at all This should read ' . . . any sort of server-oriented policy- enforcement device at all . . .', apologies for the typo. ----------------------------------------------------------------------- Roland Dobbins // Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 From ras at e-gerbil.net Sat Oct 10 07:35:57 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sat, 10 Oct 2009 06:35:57 -0500 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: <666DA8E3-45C0-48AD-8DFB-FA83097DDB7D@puck.nether.net> References: <227142482560EF458FF1F7E784E26AB80140EDE5@FLBVEXCH01.versatel.local> <666DA8E3-45C0-48AD-8DFB-FA83097DDB7D@puck.nether.net> Message-ID: <20091010113557.GY51443@gerbil.cluepon.net> On Fri, Oct 09, 2009 at 09:16:27AM -0400, Jared Mauch wrote: > I think it's important to note that there are similar limiters in > other devices, eg: Juniper m20/m40 that we've encountered over the > years. > > This has caused customer confusion as they hit these, even in a fully > distributed linecard environment. The reality is unless it's done in > a low-level ASIC, it can easily turn into a security vulnerability. > > Drop 5 gigs of ttl=1 traffic at a device and it will fall over unless > there is some protection. It may not even need to be as high as 5g. > > There are a lot of rate-limiters available, check out 'show mls rate- > limit' on your Earl7 (76k, ie: (65|76)00) based device. Set them low > to avoid problems. I find 100/10 works well. Juniper has some extremely low arbitrary hard-coded limits built in, as low as 50pps per FPC on M20/M40 type cards. Even on higher end boxes it's not much better, hardcoded at 250 or 500pps per FPC for 40g/slot cards. It only takes a couple of people on the internet running mtr to destroy those rate-limits and completely break your traceroute, to say nothing of what happens when you get a TTL expiring DoS or someone creates a forwarding loop. We routinely bump these limits, nearly 24/7 on some routers, which only serves to confuse/annoy customers (and other random people on the Internet who somehow managed to work a phone or email to complain about what you're doing to their gamer score). I can't even imagine configuring a 100/10 rate-limiter, it would get destroyed on any network with any amount of traceroute going through it. At least Cisco doesn't have those silly hard-coded limits, but on the other hand since the TTL expiration handling isn't distributed I'm sure it doesn't work out much better than a 500pps per FPC rate-limiter anyways. Some days I would pay good money for a traceroute handling ASIC, or at least some primitives for it in some microcode somewhere, so it isn't at the mercy of BGP scanner, someone running a complex sh ip bgp on the cli, or any random kid capable of generating > 500pps. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From lukasz at bromirski.net Sat Oct 10 07:57:10 2009 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Sat, 10 Oct 2009 13:57:10 +0200 Subject: [c-nsp] SUP720 - 12.2(18)SXF17 In-Reply-To: <20091010113557.GY51443@gerbil.cluepon.net> References: <227142482560EF458FF1F7E784E26AB80140EDE5@FLBVEXCH01.versatel.local> <666DA8E3-45C0-48AD-8DFB-FA83097DDB7D@puck.nether.net> <20091010113557.GY51443@gerbil.cluepon.net> Message-ID: <4AD07696.2080602@bromirski.net> On 2009-10-10 13:35, Richard A Steenbergen wrote: > Some days I would pay good money for a traceroute handling ASIC, or at > least some primitives for it in some microcode somewhere, so it isn't at > the mercy of BGP scanner, someone running a complex sh ip bgp on the > cli, or any random kid capable of generating> 500pps. Then look no more :) Actually, the Sup6E is supposed to have the TTL expired and other stuff (including IP Options) support built in into the IPP ASIC (the one that handles all IP traffic). Unfortunately, Sup6E in Cat4500 or 4900M which is based on that is hardly a core router. However, there's sign that those things go into the ASICs with time. Next generation of hardware will propably have it also if that's already cheap enough to fit into generally orderable products. And yes, I agree, that CoPP or whatever-you-call-it should be always tuneable, to not bounce off some artificial limits that are not visible at the first, second and third look into the design. -- "Everything will be okay in the end. | ?ukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net From lists at memetic.org Sat Oct 10 09:15:21 2009 From: lists at memetic.org (Adam Armstrong) Date: Sat, 10 Oct 2009 14:15:21 +0100 Subject: [c-nsp] Cisco Layer 3 and Giga In-Reply-To: References: <4ACF7A52.8050503@cantv.net> <4ACF9E91.7030104@cantv.net> Message-ID: <4AD088E9.2050000@memetic.org> Arie Vayner (avayner) wrote: > I would recommend that you take a look at the 4948 switches. They could be a good choice for small routing devices. > > Be aware that there is a relatively low limit for the number of routes they can support. > No hardware IPv6 support. You shouldn't be buying hardware which doesn't do IPv6 properly now unless you are sure you won't have to replace it. 4948 is SupIV, so no IPv6. 4900M is Sup6E, so has hardware IPv6. You could also consider the 6524, or look at offerings from other vendors, as Cisco's product line is a bit rubbish in this space. adam. From amr.ccie at gmail.com Sat Oct 10 15:21:18 2009 From: amr.ccie at gmail.com (Jason Alex) Date: Sat, 10 Oct 2009 21:21:18 +0200 Subject: [c-nsp] Hidiing a traceroute Message-ID: Dear All, I want to hide a traceroute hops inside my network i know you can hide the traceroute inside an MPLS network can we hide also the traceroute inside an IP network Thanks In advance Regards Jason CCIE#24775 From mail4hh at pobox.com Sat Oct 10 15:55:22 2009 From: mail4hh at pobox.com (Hector Herrera) Date: Sat, 10 Oct 2009 12:55:22 -0700 Subject: [c-nsp] Hidiing a traceroute In-Reply-To: References: Message-ID: On Sat, Oct 10, 2009 at 12:21 PM, Jason Alex wrote: > Dear All, > ? ? ? ? ? ? I want to hide a traceroute hops inside my network > i know you can hide the traceroute inside an MPLS network > > can we hide also the traceroute inside an IP network > > Thanks In advance > > Regards > Jason > CCIE#24775 An MPLS network hides the network hops because as far as the packet is concerned, the MPLS network is a tunnel with no router hops. To hide a traceroute inside a L3 network, you need to block ICMP TTL-expired messages from the hops you want to hide. However, the hops will still be visible since every router decrements the TTL by one, and the traceroute source will notice it is missing TTL-expired messages from your hidden hops. Hector From techtalm at gmail.com Sat Oct 10 16:32:35 2009 From: techtalm at gmail.com (techtalm at gmail.com) Date: Sat, 10 Oct 2009 22:32:35 +0200 Subject: [c-nsp] Hidiing a traceroute In-Reply-To: References: Message-ID: <6BCCA9D2AEC04C8A849D2E9F0B281564@zeus> Not so accurate, in an MPLS network you can disable the process which copies the IP TTL from the header to the label and vice verse. By doing that you are "hiding" the MPLS core routers from a traceroute operation. As for an IP network you can either discard or drop an ICMP type 8 (echo request) And by that block the traceroute operation, The user will get asterisks marks instead of the IP of the router. MTC. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Hector Herrera Sent: Saturday, October 10, 2009 9:55 PM To: Jason Alex Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Hidiing a traceroute On Sat, Oct 10, 2009 at 12:21 PM, Jason Alex wrote: > Dear All, > ? ? ? ? ? ? I want to hide a traceroute hops inside my network > i know you can hide the traceroute inside an MPLS network > > can we hide also the traceroute inside an IP network > > Thanks In advance > > Regards > Jason > CCIE#24775 An MPLS network hides the network hops because as far as the packet is concerned, the MPLS network is a tunnel with no router hops. To hide a traceroute inside a L3 network, you need to block ICMP TTL-expired messages from the hops you want to hide. However, the hops will still be visible since every router decrements the TTL by one, and the traceroute source will notice it is missing TTL-expired messages from your hidden hops. Hector _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.9/2427 - Release Date: 10/10/09 06:39:00 From cisco-nsp at itpro.co.nz Sat Oct 10 19:05:25 2009 From: cisco-nsp at itpro.co.nz (Ivan) Date: Sun, 11 Oct 2009 12:05:25 +1300 (NZDT) Subject: [c-nsp] Hidiing a traceroute In-Reply-To: <6BCCA9D2AEC04C8A849D2E9F0B281564@zeus> References: <6BCCA9D2AEC04C8A849D2E9F0B281564@zeus> Message-ID: <2274.118.90.10.252.1255215925.squirrel@mail.orcon.net.nz> http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_m1.html#wp1013846 > Not so accurate, in an MPLS network you can disable the process which > copies > the IP TTL from the header to the label and vice verse. By doing that you > are "hiding" the MPLS core routers from a traceroute operation. > > As for an IP network you can either discard or drop an ICMP type 8 (echo > request) > And by that block the traceroute operation, The user will get asterisks > marks instead of the IP of the router. > > MTC. > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Hector Herrera > Sent: Saturday, October 10, 2009 9:55 PM > To: Jason Alex > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Hidiing a traceroute > > On Sat, Oct 10, 2009 at 12:21 PM, Jason Alex wrote: >> Dear All, >> ? ? ? ? ? ? I want to hide a traceroute hops inside my network >> i know you can hide the traceroute inside an MPLS network >> >> can we hide also the traceroute inside an IP network >> >> Thanks In advance >> >> Regards >> Jason >> CCIE#24775 > > An MPLS network hides the network hops because as far as the packet is > concerned, the MPLS network is a tunnel with no router hops. > > To hide a traceroute inside a L3 network, you need to block ICMP > TTL-expired messages from the hops you want to hide. However, the > hops will still be visible since every router decrements the TTL by > one, and the traceroute source will notice it is missing TTL-expired > messages from your hidden hops. > > Hector > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.421 / Virus Database: 270.14.9/2427 - Release Date: 10/10/09 > 06:39:00 > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From ecralar at hotmail.com Sun Oct 11 03:55:30 2009 From: ecralar at hotmail.com (Alex) Date: Sun, 11 Oct 2009 08:55:30 +0100 Subject: [c-nsp] Hidiing a traceroute In-Reply-To: <6BCCA9D2AEC04C8A849D2E9F0B281564@zeus> References: <6BCCA9D2AEC04C8A849D2E9F0B281564@zeus> Message-ID: ICMP type 8 with incrementing TTL is Windows tracert. Unix traceroute is UDP starting with port 33434 through (33434+-1). Starting port is user-configurable. And there is also tcptraceroute: http://en.wikipedia.org/wiki/Tcptraceroute What you need is to block tracert/traceroute/tcptraceroute response, which is ICMP TTL Exceeded, towards untrusted IP addresses. Rgds Alex -------------------------------------------------- From: Date: 10 October 2009 21:32 To: ; "'Jason Alex'" Cc: Subject: Re: [c-nsp] Hidiing a traceroute > Not so accurate, in an MPLS network you can disable the process which > copies > the IP TTL from the header to the label and vice verse. By doing that you > are "hiding" the MPLS core routers from a traceroute operation. > > As for an IP network you can either discard or drop an ICMP type 8 (echo > request) > And by that block the traceroute operation, The user will get asterisks > marks instead of the IP of the router. > > MTC. > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Hector Herrera > Sent: Saturday, October 10, 2009 9:55 PM > To: Jason Alex > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Hidiing a traceroute > > On Sat, Oct 10, 2009 at 12:21 PM, Jason Alex wrote: >> Dear All, >> I want to hide a traceroute hops inside my network >> i know you can hide the traceroute inside an MPLS network >> >> can we hide also the traceroute inside an IP network >> >> Thanks In advance >> >> Regards >> Jason >> CCIE#24775 > > An MPLS network hides the network hops because as far as the packet is > concerned, the MPLS network is a tunnel with no router hops. > > To hide a traceroute inside a L3 network, you need to block ICMP > TTL-expired messages from the hops you want to hide. However, the > hops will still be visible since every router decrements the TTL by > one, and the traceroute source will notice it is missing TTL-expired > messages from your hidden hops. > > Hector > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.421 / Virus Database: 270.14.9/2427 - Release Date: 10/10/09 > 06:39:00 > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From lists at memetic.org Sun Oct 11 11:40:40 2009 From: lists at memetic.org (Adam Armstrong) Date: Sun, 11 Oct 2009 16:40:40 +0100 Subject: [c-nsp] Hidiing a traceroute In-Reply-To: References: Message-ID: <4AD1FC78.2060404@memetic.org> Jason Alex wrote: > Dear All, > I want to hide a traceroute hops inside my network > i know you can hide the traceroute inside an MPLS network > > can we hide also the traceroute inside an IP network > The number of hops? not unless you know a way to disable the TTL decrementing mechanism, no. The identity of hops? Block ICMP Time Exceeded. For example : access-list 100 deny icmp any any ttl-exceeded > CCIE#24775 Oh man. How many Weetos tokens did you have to collect for that? adam. From gert at greenie.muc.de Sun Oct 11 12:41:40 2009 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 11 Oct 2009 18:41:40 +0200 Subject: [c-nsp] Unable To Use T3 Card (PA-MC-2T3-EC) In-Reply-To: <003501ca4785$a1df2a20$d400a8c0@dominic> <001401ca477a$f544cef0$d400a8c0@dominic> References: <1254943599.v2.mailanyonewebmail-222491@fuse49> <003501ca4785$a1df2a20$d400a8c0@dominic> <001401ca477a$f544cef0$d400a8c0@dominic> Message-ID: <20091011164140.GA1508@greenie.muc.de> Hi, On Wed, Oct 07, 2009 at 02:21:15PM -0400, Dominic wrote: > I am trying to install a Cisco T3 Card, Model #: PA-MC-2T3-EC, on a Cisco > 7206VXR with NPE-G2. When I insert the card, I get the alarm below. > > Oct 7 18:11:45.100: %ENTITY_ALARM-6-INFO: CLEAR CRITICAL PA Slot 2 Active > Card Removed OIR Alarm > Oct 7 18:11:50.220: %PA-3-REVNOTSUPPORTED: PA in slot2 (Ethernet) requires > base h/w revision of (1.14) for this chassis > Oct 7 18:11:50.220: %PA-3-DEACTIVATED: port adapter in bay [2] powered off. This is a bit surprising. So far, I have seen this message only when an older PA is inserted into a VXR chassis, which has certain minimum hardware requirements (as opposed to the non-VXR chassis). OTOH... On Wed, Oct 07, 2009 at 03:37:40PM -0400, Dominic wrote: > I am currently running (C7200P-SPSERVICESK9-M), Version 12.4(4)XD10 ... it might be that this software just doesn't know about this specific PA (which is very new, and anything based on 12.4(4) is a few years old now regarding hardware support). "C7200P" smells like NPE-G2, so you don't have that many options - I'm no NPE-G2 expert, but I think all you *can* use is "12.4T" or "12.2SR" - so I'd pick a recent one of either IOS versions and try that. Or go for 15.0(1)M, which might or might not be less bugged than 12.4(max)T. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From gert at greenie.muc.de Sun Oct 11 13:00:29 2009 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 11 Oct 2009 19:00:29 +0200 Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: <29A54911243620478FF59F00EBB12F4701A60D0D@ex01.drtel.lan> References: <64FEF27A-B8AF-4EB5-839E-93CB2D72021D@arbor.net> <29A54911243620478FF59F00EBB12F4701A60D0D@ex01.drtel.lan> Message-ID: <20091011170029.GB1508@greenie.muc.de> Hi, On Fri, Oct 09, 2009 at 10:06:49PM -0500, Brian Johnson wrote: > So are you actually saying that DPI is a bad thing relative to server > protection? What makes this a bad idea? In what way does it make them > more vulnerable to attacks? Well, the point of a well-maintained server is that it is *open* to the world - if you want a web server to be visible by the world, then there isn't much you can do, besides "open HTTP to it". And other services should not be running in the first place. So, if you put a fiewall in front of a well-maintained server, all you add is "extra state table handling" with all the problems it brings - state table overflow (=new connections getting dropped), state getting desynchronized with the server, firewall CPU exploding long before the server is hitting any load boundaries, and worst of all, weaknesses in the firewall products that can be used to crash the firewall, DoSing the server. The worst thing you can do is put a stateful firewall in front of a busy DNS server - every single packet creating new state will bring most hardware-based firewalls to their knees, because "session churn" is usually handled at much lower packet rate as "pure packet throughput for existing state"... Now, for a typical "office network", things look different, because you don't have that stringent control over the machines behind the firewall (so you never know who installed what application on their machine), and the typical direction for connection setup is different (outbound connection = state handling is needed for the return packets). Your example of "crafted packets that crash the server but can be handled by the firewall" brings up the interesting question why one would upgrade the firewall (to recognize this packet), but not the server (to be not vulnerable to the bad packet in the first place)... - and *that* is what I meant by "well-maintained server" in the first paragraph. Now, if your servers are not hardened enough, I'm happy to sell you a firewall to put in front of it - but it won't do zilch against the next buggy PHP application that will be used to exploit the server via perfectly nice HTTP requests - no crafted packets, just bad applications... (I'm also one of those people that think the claim "NAT will improve your security" was true 10 years ago, but wont't help at all for todays security issues - browser exploits, e-mail viruses, etc.) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From shinejoseph at dodo.com.au Sun Oct 11 15:20:04 2009 From: shinejoseph at dodo.com.au (Shine Joseph) Date: Mon, 12 Oct 2009 03:20:04 +0800 Subject: [c-nsp] mGRE with VRF-Lite Message-ID: Hi, I am working on a solution to run mGRE for VRF-Lite. This is my situation: there are 5 sites currently connected by MPLS IPWAn provided by ISP. I want to run VRF-Lite throughout the network for path isolation between various VLANs. VRF-Lite works great within the site (Vrf-Lite end-to-end is being deployed). In order for to cross the IPWAN, mutipoint-GRE tunnels are being looked at. tunnels are getting created, but when advertised in the VRF routing process, neighbor is not being esablished. If I use the potint to point tunnel, neighbor relationship is estanblished, working as expected. The issue will be I need to create over 50 tunnels to achieve the expected results. Can someone help me, if the mGRE with VRF-Lite is a feasible solution? Thanks in advance Shine ---------------------------- Following is a snippet of my configuration: Router 1 ======== interface Tunnel110 ip vrf forwarding Data ip address 10.40.61.1 255.255.255.224 no ip redirects ip nhrp map 10.40.61.2 172.16.123.2 ip nhrp map 10.40.61.3 172.16.123.3 ip nhrp network-id 110 ip nhrp cache non-authoritative tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 router eigrp 100 no auto-summary ! address-family ipv4 vrf Gorgon_Data network 10.40.61.1 0.0.0.0 no auto-summary autonomous-system 100 exit-address-family ! Router 2 ======== interface Tunnel110 ip vrf forwarding Data ip address 10.40.61.2 255.255.255.224 no ip redirects ip nhrp map 10.40.61.1 172.16.123.1 ip nhrp map 10.40.61.3 172.16.123.3 ip nhrp network-id 110 ip nhrp cache non-authoritative tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 router eigrp 100 no auto-summary ! address-family ipv4 vrf Gorgon_Data network 10.40.61.2 0.0.0.0 no auto-summary autonomous-system 100 exit-address-family ! Router 3 ======== interface Tunnel110 ip vrf forwarding Data ip address 10.40.61.3 255.255.255.224 no ip redirects ip nhrp map 10.40.61.1 172.16.123.1 ip nhrp map 10.40.61.2 172.16.123.2 ip nhrp network-id 110 ip nhrp cache non-authoritative tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 router eigrp 100 no auto-summary ! address-family ipv4 vrf Gorgon_Data network 10.40.61.3 0.0.0.0 no auto-summary autonomous-system 100 exit-address-family From sethm at rollernet.us Sun Oct 11 18:13:57 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 11 Oct 2009 15:13:57 -0700 Subject: [c-nsp] Unable To Use T3 Card (PA-MC-2T3-EC) In-Reply-To: <003501ca4785$a1df2a20$d400a8c0@dominic> References: <1254943599.v2.mailanyonewebmail-222491@fuse49> <003501ca4785$a1df2a20$d400a8c0@dominic> Message-ID: <4AD258A5.2080009@rollernet.us> Dominic wrote: > I am currently running (C7200P-SPSERVICESK9-M), Version 12.4(4)XD10 > http://www.cisco.com/en/US/prod/collateral/modules/ps2033/ps2762/product_data_sheet0900aecd8054951d.html Enhanced capability port adapters Cisco 7204 and 7206VXR Cisco 7200VXR Series NPE-G1 and NPE-G2 Network Processing Engines 12.4(11)T and 12.2SRC -- Seth Mattinen sethm at rollernet.us Roller Network LLC From tony at lava.net Sun Oct 11 18:27:09 2009 From: tony at lava.net (Antonio Querubin) Date: Sun, 11 Oct 2009 12:27:09 -1000 (HST) Subject: [c-nsp] 7206VXR NPE for ~1000 RBE interfaces Message-ID: I'm researching upgrading a 7206VXR to handle about 1000 RBE interfaces off of either 2 T3 or 1 OC3 ATM line. Anybody got any recommendations on which NPE would handle this scenario? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From moua0100 at umn.edu Sun Oct 11 20:00:15 2009 From: moua0100 at umn.edu (Ge Moua) Date: Sun, 11 Oct 2009 19:00:15 -0500 Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: <20091011170029.GB1508@greenie.muc.de> References: <64FEF27A-B8AF-4EB5-839E-93CB2D72021D@arbor.net> <29A54911243620478FF59F00EBB12F4701A60D0D@ex01.drtel.lan> <20091011170029.GB1508@greenie.muc.de> Message-ID: <4AD2718F.801@umn.edu> >> The worst thing you can do is put a stateful firewall in front of a busy DNS server - every single packet creating new state will bring most hardware-based firewalls to their knees, because "session churn" is usually handled at much lower packet rate as "pure packet throughput for existing state"... I concur and have battle scar to attest for this; we tried to put a stateful firewall in front of our public NTP server (which also happen to be our DNS servers) and the firewall tipped over within 5 minutes; state tables got exhausted quick. - Ge Univ of Mn Gert Doering wrote: > Hi, > > On Fri, Oct 09, 2009 at 10:06:49PM -0500, Brian Johnson wrote: > >> So are you actually saying that DPI is a bad thing relative to server >> protection? What makes this a bad idea? In what way does it make them >> more vulnerable to attacks? >> > > Well, the point of a well-maintained server is that it is *open* to > the world - if you want a web server to be visible by the world, then > there isn't much you can do, besides "open HTTP to it". And other > services should not be running in the first place. > > So, if you put a fiewall in front of a well-maintained server, all you > add is "extra state table handling" with all the problems it brings > - state table overflow (=new connections getting dropped), state getting > desynchronized with the server, firewall CPU exploding long before the > server is hitting any load boundaries, and worst of all, weaknesses in > the firewall products that can be used to crash the firewall, DoSing > the server. > > The worst thing you can do is put a stateful firewall in front of a > busy DNS server - every single packet creating new state will bring > most hardware-based firewalls to their knees, because "session churn" > is usually handled at much lower packet rate as "pure packet throughput > for existing state"... > > > Now, for a typical "office network", things look different, because you > don't have that stringent control over the machines behind the firewall > (so you never know who installed what application on their machine), and > the typical direction for connection setup is different (outbound > connection = state handling is needed for the return packets). > > > Your example of "crafted packets that crash the server but can be handled > by the firewall" brings up the interesting question why one would upgrade > the firewall (to recognize this packet), but not the server (to be not > vulnerable to the bad packet in the first place)... - and *that* is > what I meant by "well-maintained server" in the first paragraph. > > Now, if your servers are not hardened enough, I'm happy to sell you a > firewall to put in front of it - but it won't do zilch against the next > buggy PHP application that will be used to exploit the server via > perfectly nice HTTP requests - no crafted packets, just bad applications... > > > (I'm also one of those people that think the claim "NAT will improve > your security" was true 10 years ago, but wont't help at all for > todays security issues - browser exploits, e-mail viruses, etc.) > > gert > > > ------------------------------------------------------------------------ > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From bjohnson at drtel.com Sun Oct 11 21:26:53 2009 From: bjohnson at drtel.com (Brian Johnson) Date: Sun, 11 Oct 2009 20:26:53 -0500 Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: References: <64FEF27A-B8AF-4EB5-839E-93CB2D72021D@arbor.net><29A54911243620478FF59F00EBB12F4701A60D0D@ex01.drtel.lan> Message-ID: <29A54911243620478FF59F00EBB12F4701A60D24@ex01.drtel.lan> > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Roland Dobbins > Sent: Saturday, October 10, 2009 3:50 AM > To: Cisco-nsp > Subject: Re: [c-nsp] ASA Firewalls placement in the network! > > > On Oct 10, 2009, at 10:06 AM, Brian Johnson wrote: > > > So are you actually saying that DPI is a bad thing relative to server > > protection? What makes this a bad idea? In what way does it make them > > more vulnerable to attacks? > > DPI <> firewalls. Agreed, but are you saying that DPI is a bad thing relative to unsolicited server connections? > > > My experience with crafted packet attacks (being attacked, not > > attacking > > others :P) tells me that this is a good layer of protection. > > Concur. Again, it has nothing to do with stateful firewalls. OK, So I know that DPI can be done with other devices, including routers, but you never mentioned DPI in your solution. > > > > > What Arbor product would you like to sell me to accomplish > > this type of protection? > > I publicly held this position when I worked for the world's largest > vendor of stateful firewalls. My position was based upon operational > experience then, as now. Working at the big C must have been such a burden. :) > > In this threat, I stated that enforcing policy should be handled by > stateless ACLs in hardware. Arbor Networks doesn't make routers. OK. No problem with this idea and in fact this is the only way to enforce access policy at the edge of a network that I'm aware of. Good call. > > > Not trying to be snide here (at least not anymore ;P), but I doubt > > that > > the majority of CFOs would be fine leaving their servers behind > simple > > ACLs. I would never do that > > That's because you, like your hypothetical CFOs, obviously have no > experience running large-scale public-facing Internet properties. Any > large-scale, publicly-visible Web site you can name doesn't have > stateful firewalls in front of its servers. OOPS.. I meant CTOs. No, I do have such experience (depending on your definition of large scale) and know real CTOs (or their equivalent). They might not be the "biggest players" in the arena, but they are a small volume compared to the other players who will use these technologies. > > For a server like a DNS server, a Web server, and so forth, every > connection which comes into said server is by definition unsolicited. > So, the entire purpose of stateful inspection in front of such servers > is moot. > Thanks for knowing me so well and assigning my experience from a single post. Can you tell the future and bring back the dead too? I would agree that a "miss-sized" security appliance (be it a firewall or router with security features like ACLS and DPI), can be problematic. I disagree that its purpose is "moot". A security appliance in front of servers can help to stop crafted packet attacks and SYN floods. Why attack a target that is being defended when there are so many targets that aren't I have worked with this stuff for a long time (>10 years). I am MOT an expert and distrust statements from people/vendors who make finite statements that I can prove wrong out of hand. Let's try to be respectful of people and ideas. Disagreeing is fine, but insisting that one's opinion is correct in all circumstances is foolhardy and only negates your opinion. I agree that you are right in some circumstances, but not all. Also that the circumstances that I would follow your opinion are few and far between. Just my, and my hypothetical CTOs, $.02 - Brian From Fossett.Jeff at con-way.com Sun Oct 11 22:08:09 2009 From: Fossett.Jeff at con-way.com (Fossett, Jeff S) Date: Sun, 11 Oct 2009 19:08:09 -0700 Subject: [c-nsp] BGP Backdoor Links Problem Message-ID: Hi Team - figured most of you could provide a fix for the following scenario in your sleep, so I thought I'd reach out. We have a Primary DataCenter and a DR Facility, attached via MPLS privately (using EIGRP across that link to peer the two DataCenters)... both also have an eBGP Peering Relationship with a Service Provider that is providing a private Cellular APN. Though both connections are "Active" to the Service Provider Cellular PN, we want an "Active/Standby" type of routing scenario. Our DR Center is not built up in a manner that adequately supports Active/Active from an Application/Middle Tier/Mainframe standpoint. Scenario: In our BGP peering relationship with the ISP (giving Cell Services) we are running eBGP. Whenever routes are learned with eBGP they have a local cost of 20. Since our "DataCenter Gateway" is getting the routes to the cell private networks from eBGP via "DR Gateway" they are always preferred over the Portland learned EIGRP external routes with a 170 cost. When peering to the cell carriers is active in both the DataCenter and DR, the data sourced or destined for DR from the cell carrier networks will fail. Problem: We used the BGP Backdoor option on the DataCenter gateway to change the distance on the Cellular Cloud networks from 20 to 200 in order to allow our DataCenter gateway to prefer EIGRP routes within the DataCenter environment, and then redistribute into BGP. But once we put this in, BGP no longer advertises any networks that are associated with the backdoor command. Should we pursue some sort of Conditional Advertisement, or Synchronization/Redistribution scenario??? Any advice? Thanks so much in advance for the help . . . From mtinka at globaltransit.net Mon Oct 12 00:20:07 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Mon, 12 Oct 2009 12:20:07 +0800 Subject: [c-nsp] MLS QoS 6500/7600 In-Reply-To: <1255129260.3474.14.camel@abehat.net.rm.dk> References: <844ef89c0910090458o14893037k50be70bf91136ee4@mail.gmail.com> <1255129260.3474.14.camel@abehat.net.rm.dk> Message-ID: <200910121220.19841.mtinka@globaltransit.net> On Saturday 10 October 2009 07:01:00 am Peter Rathlev wrote: > Just enabling "mls qos" without doing anything else and > without having a plan should be considered an error. I can attest to this. I know a network that couldn't figure out why its customer's traffic was having their ToS byte being re-written yet the network was providing a pure Layer 2 Metro-E service. Turned out QoS was enabled on the 4500 and 7600 platforms being used in the Metro-E edge/core without anything else being done to fully utilize it, or at the very least, to preserve the customer's ToS byte settings. Of course, simply disabling QoS fixed the issue. At the risk of starting a war, this story rekindles that adage: "increasing bandwidth is probably more practical than implementing QoS" Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From mtinka at globaltransit.net Mon Oct 12 00:39:29 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Mon, 12 Oct 2009 12:39:29 +0800 Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: <20091011170029.GB1508@greenie.muc.de> References: <29A54911243620478FF59F00EBB12F4701A60D0D@ex01.drtel.lan> <20091011170029.GB1508@greenie.muc.de> Message-ID: <200910121239.34727.mtinka@globaltransit.net> On Monday 12 October 2009 01:00:29 am Gert Doering wrote: > So, if you put a fiewall in front of a well-maintained > server, all you add is "extra state table handling" with > all the problems it brings - state table overflow (=new > connections getting dropped), state getting > desynchronized with the server, firewall CPU exploding > long before the server is hitting any load boundaries, > and worst of all, weaknesses in the firewall products > that can be used to crash the firewall, DoSing the > server. > > The worst thing you can do is put a stateful firewall in > front of a busy DNS server - every single packet creating > new state will bring most hardware-based firewalls to > their knees, because "session churn" is usually handled > at much lower packet rate as "pure packet throughput for > existing state"... Agree. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From ploopster at gmail.com Mon Oct 12 06:04:35 2009 From: ploopster at gmail.com (Sridhar Ayengar) Date: Mon, 12 Oct 2009 06:04:35 -0400 Subject: [c-nsp] GEIP+ Prices Message-ID: <4AD2FF33.7000401@gmail.com> Why do GEIP+ cards go for so much money? There can't be *that* many people left on the 7500 platform... Peace... Sridhar From nick at inex.ie Mon Oct 12 06:39:27 2009 From: nick at inex.ie (Nick Hilliard) Date: Mon, 12 Oct 2009 11:39:27 +0100 Subject: [c-nsp] MLS QoS 6500/7600 In-Reply-To: <200910121220.19841.mtinka@globaltransit.net> References: <844ef89c0910090458o14893037k50be70bf91136ee4@mail.gmail.com> <1255129260.3474.14.camel@abehat.net.rm.dk> <200910121220.19841.mtinka@globaltransit.net> Message-ID: <4AD3075F.8020906@inex.ie> On 12/10/2009 05:20, Mark Tinka wrote: > "increasing bandwidth is probably more practical than > implementing QoS" or as some wags state differently: QoS really means "quantity of service", because quality of service only ever becomes an issue if there is a shortage of quantity. /me runs and hides nick From dr at cluenet.de Mon Oct 12 09:05:12 2009 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 12 Oct 2009 15:05:12 +0200 Subject: [c-nsp] GEIP+ Prices In-Reply-To: <4AD2FF33.7000401@gmail.com> References: <4AD2FF33.7000401@gmail.com> Message-ID: <20091012130512.GA25661@srv03.cluenet.de> On Mon, Oct 12, 2009 at 06:04:35AM -0400, Sridhar Ayengar wrote: > Why do GEIP+ cards go for so much money? There can't be *that* many people > left on the 7500 platform... Because anyone still in the market for GEIP+ must be very very desperate? :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From justin at justinshore.com Mon Oct 12 09:13:03 2009 From: justin at justinshore.com (Justin Shore) Date: Mon, 12 Oct 2009 08:13:03 -0500 Subject: [c-nsp] Unable To Use T3 Card (PA-MC-2T3-EC) In-Reply-To: <20091011164140.GA1508@greenie.muc.de> References: <1254943599.v2.mailanyonewebmail-222491@fuse49> <003501ca4785$a1df2a20$d400a8c0@dominic> <001401ca477a$f544cef0$d400a8c0@dominic> <20091011164140.GA1508@greenie.muc.de> Message-ID: <4AD32B5F.9030609@justinshore.com> Gert Doering wrote: >> I am currently running (C7200P-SPSERVICESK9-M), Version 12.4(4)XD10 > > ... it might be that this software just doesn't know about this specific > PA (which is very new, and anything based on 12.4(4) is a few years old > now regarding hardware support). > > "C7200P" smells like NPE-G2, so you don't have that many options - I'm > no NPE-G2 expert, but I think all you *can* use is "12.4T" or "12.2SR" - > so I'd pick a recent one of either IOS versions and try that. Or go for > 15.0(1)M, which might or might not be less bugged than 12.4(max)T. I agree. Dominic is running a code train that was put out just for the initial release of the NPE-G2. He's running a code train that's slated for death essentially and should move into a regular train such as 12.4 mainline, 12.4T or 12.2SR since G2 support has been rolled into them. I haven't yet loaded 15.0 on a G2 but I am running on one on 24T1 and that box has a PA-MC-2T3-EC in it. It of course has the NTP bug (and several others) that require 24T2 or 15.0 to fix. 12.4T has been fairly stable for me though. Justin From swmike at swm.pp.se Mon Oct 12 09:26:48 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 12 Oct 2009 15:26:48 +0200 (CEST) Subject: [c-nsp] GEIP+ Prices In-Reply-To: <4AD2FF33.7000401@gmail.com> References: <4AD2FF33.7000401@gmail.com> Message-ID: On Mon, 12 Oct 2009, Sridhar Ayengar wrote: > Why do GEIP+ cards go for so much money? There can't be *that* many > people left on the 7500 platform... They are around 1kUSD on ebay, considering just the PA-GE goes for 800, I don't think that's expensive? They're actually increasing in price, the GEIP (not +) was 600 USD a year ago, now they seem to not be available even close to that price. -- Mikael Abrahamsson email: swmike at swm.pp.se From jlewis at lewis.org Mon Oct 12 09:29:37 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 12 Oct 2009 09:29:37 -0400 (EDT) Subject: [c-nsp] GEIP+ Prices In-Reply-To: References: <4AD2FF33.7000401@gmail.com> Message-ID: On Mon, 12 Oct 2009, Mikael Abrahamsson wrote: > On Mon, 12 Oct 2009, Sridhar Ayengar wrote: > >> Why do GEIP+ cards go for so much money? There can't be *that* many people >> left on the 7500 platform... > > They are around 1kUSD on ebay, considering just the PA-GE goes for 800, I > don't think that's expensive? They're actually increasing in price, the GEIP > (not +) was 600 USD a year ago, now they seem to not be available even close > to that price. Maybe not a whole lot were sold new, so there's limited supply. You do realize it talks GE, but can't actually do anywhere close to line rate? i.e. are you sure you really want one and it'll do what you need? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From lists at carels.info Mon Oct 12 09:03:02 2009 From: lists at carels.info (Maarten Carels) Date: Mon, 12 Oct 2009 15:03:02 +0200 Subject: [c-nsp] Shape traffic on 6500 Message-ID: I'm trying to limit traffic to certain ports of a 6500 switch. By reading manuals and posts to this list I came up with: Global: access-list 100 permit ip any any ! class-map m100 match access-group 100 ! policy-map p100 class m100 shape average 32000 This all looks fine. But when I apply this policy to an interface with: int gi3/1 service-policy input p100 the switch complains with shape average command is not supported for this interface Configuration failed! When I replace the 'shape' command with a 'police': police 32000 conform-action transmit exceed-action drop the configuration is accepted Shaping looks nicer, as it does not drop packets, but delays them, having TCP better adapt to the bandwith. Any comments on this? What interfaces have the 'shape average' command supported? The manuals are very non-helpful on this, as they say 'This command is supported in the IOS 12.2SX train. Support in a specific 12.2SX release depends on your feature set, platform and platform hardware. No table of what is supported on what... Used hardware for my test config is: 6509 chassis, sup720 (WS-SUP720-3BXL), interfaces on WS-X6748-GE-TX board with Distributed Forwarding Card WS-F6700-DFC3A IOS 12.2(33)SXH2a ADVANCED ENTERPRISE SERVICES (s72033-advipservicesk9_wan-mz.122-33.SXH2a.bin) Anyone who can shine some light on this?? --maarten -- --- Maarten Carels XS4ALL Internet From swmike at swm.pp.se Mon Oct 12 09:56:55 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 12 Oct 2009 15:56:55 +0200 (CEST) Subject: [c-nsp] Shape traffic on 6500 In-Reply-To: References: Message-ID: On Mon, 12 Oct 2009, Maarten Carels wrote: > Any comments on this? What interfaces have the 'shape average' command > supported? The expensive ones. The cheap LAN interfaces generally do not support shaping because they don't have much buffering and are built to be cheap, thus limited support for a lot of the more advanced stuff. -- Mikael Abrahamsson email: swmike at swm.pp.se From Ian.Mackinnon at lumison.net Mon Oct 12 10:01:09 2009 From: Ian.Mackinnon at lumison.net (Ian MacKinnon) Date: Mon, 12 Oct 2009 15:01:09 +0100 Subject: [c-nsp] Shape traffic on 6500 In-Reply-To: References: Message-ID: > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Mikael Abrahamsson > Sent: 12 October 2009 14:57 > To: Maarten Carels > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Shape traffic on 6500 > > On Mon, 12 Oct 2009, Maarten Carels wrote: > > > Any comments on this? What interfaces have the 'shape average' > command > > supported? > > The expensive ones. The cheap LAN interfaces generally do not support > shaping because they don't have much buffering and are built to be > cheap, > thus limited support for a lot of the more advanced stuff. > [Ian MacKinnon] From http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801c8c4b.shtml :- The PFC3 supports both ingress and egress policing. Traffic shaping is only supported on certain WAN modules for the Catalyst 6500/7600 series, such as the Optical Services Modules (OSMs) and FlexWAN modules. Refer to the Cisco 7600 Series Router Module Configuration Notes for more information -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. From adrian.minta at gmail.com Mon Oct 12 11:28:13 2009 From: adrian.minta at gmail.com (Adrian Minta) Date: Mon, 12 Oct 2009 18:28:13 +0300 Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: <4AD2718F.801@umn.edu> References: <64FEF27A-B8AF-4EB5-839E-93CB2D72021D@arbor.net> <29A54911243620478FF59F00EBB12F4701A60D0D@ex01.drtel.lan> <20091011170029.GB1508@greenie.muc.de> <4AD2718F.801@umn.edu> Message-ID: <4AD34B0D.2060300@gmail.com> Ge Moua wrote: >>> The worst thing you can do is put a stateful firewall in front of a > busy DNS server - every single packet creating new state will bring > most hardware-based firewalls to their knees, because "session churn" > is usually handled at much lower packet rate as "pure packet throughput > for existing state"... > > > I concur and have battle scar to attest for this; we tried to put a > stateful firewall in front of our public NTP server (which also happen > to be our DNS servers) and the firewall tipped over within 5 minutes; > state tables got exhausted quick. Is there a way to disable sessions for specific port or IP ? -- Best regards, Adrian Minta From sj_hznm at yahoo.com.cn Mon Oct 12 10:46:26 2009 From: sj_hznm at yahoo.com.cn (Joe Shen) Date: Mon, 12 Oct 2009 22:46:26 +0800 (CST) Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: <20091011170029.GB1508@greenie.muc.de> Message-ID: <493540.15093.qm@web15607.mail.cnb.yahoo.com> > Well, the point of a well-maintained server is that it is > *open* to > the world - if you want a web server to be visible by the > world, then > there isn't much you can do, besides "open HTTP to > it".? And other > services should not be running in the first place. Agree. Focusing server resource on its public service and remove all unnecessary should be first consideration other than putting in another box. > The worst thing you can do is put a stateful firewall in > front of a > busy DNS server Yes. We do suffer from such solution years ago. At that time, when incoming request increases the firewall we use reaches its threshhold quickly and reject new ones. Now, we just connect DNS servers to cisco 6509 directly, ACL on interface protects server very well. On the other hand, tuning DNS server performance is relatively easily than application servers. But, it seems there needs new technology or method on detecting and controling abnormal incoming requests. Months ago, failure of primary DNS server for baofeng.com causes ISP cache server out of resource because too many clients resolve that domain recursively. Joe ___________________________________________________________ ????????????????? http://card.mail.cn.yahoo.com/ From gsgranados at comcast.net Mon Oct 12 12:00:33 2009 From: gsgranados at comcast.net (Scott Granados) Date: Mon, 12 Oct 2009 09:00:33 -0700 Subject: [c-nsp] ASA Firewalls placement in the network! References: <493540.15093.qm@web15607.mail.cnb.yahoo.com> Message-ID: <00dd01ca4b55$294520a0$2408120a@am.thmulti.com> I have to agree here, good solid server administration and best practices are far superior to placing hardware in front to do your job for you. (Microsoft, are you listening?) The services running should be the bare minimum, should have their own internal ACLs properly configured (think SSH as an example) and the internal facility such as IPChains or IPF what ever should be used after the services are squared away. This is an art that seems lost on a lot of administrators.:( ----- Original Message ----- From: "Joe Shen" To: "Brian Johnson" ; "Gert Doering" Cc: "Cisco-nsp" Sent: Monday, October 12, 2009 7:46 AM Subject: Re: [c-nsp] ASA Firewalls placement in the network! >> Well, the point of a well-maintained server is that it is >> *open* to >> the world - if you want a web server to be visible by the >> world, then >> there isn't much you can do, besides "open HTTP to >> it". And other >> services should not be running in the first place. > > Agree. Focusing server resource on its public service and remove all > unnecessary should be first consideration other than putting in another > box. > >> The worst thing you can do is put a stateful firewall in >> front of a >> busy DNS server > > Yes. We do suffer from such solution years ago. At that time, when > incoming request increases the firewall we use reaches its threshhold > quickly and reject new ones. Now, we just connect DNS servers to cisco > 6509 directly, ACL on interface protects server very well. > > On the other hand, tuning DNS server performance is relatively easily > than application servers. But, it seems there needs new technology or > method on detecting and controling abnormal incoming requests. > > Months ago, failure of primary DNS server for baofeng.com causes ISP > cache server out of resource because too many clients resolve that domain > recursively. > > Joe > > > > ___________________________________________________________ > ????????????????? > http://card.mail.cn.yahoo.com/ > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From moua0100 at umn.edu Mon Oct 12 11:44:23 2009 From: moua0100 at umn.edu (Ge Moua) Date: Mon, 12 Oct 2009 10:44:23 -0500 Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: <4AD34B0D.2060300@gmail.com> References: <64FEF27A-B8AF-4EB5-839E-93CB2D72021D@arbor.net> <29A54911243620478FF59F00EBB12F4701A60D0D@ex01.drtel.lan> <20091011170029.GB1508@greenie.muc.de> <4AD2718F.801@umn.edu> <4AD34B0D.2060300@gmail.com> Message-ID: <4AD34ED7.6010207@umn.edu> yes, but the whole point of public NTP services is to allow any IPv4 to do NTP sync. Regards, Ge Moua | Email: moua0100 at umn.edu Network Design Engineer University of Minnesota | Networking & Telecommunications Services Adrian Minta wrote: > Ge Moua wrote: >>>> The worst thing you can do is put a stateful firewall in front of a >> busy DNS server - every single packet creating new state will bring >> most hardware-based firewalls to their knees, because "session churn" >> is usually handled at much lower packet rate as "pure packet throughput >> for existing state"... >> >> >> I concur and have battle scar to attest for this; we tried to put a >> stateful firewall in front of our public NTP server (which also >> happen to be our DNS servers) and the firewall tipped over within 5 >> minutes; state tables got exhausted quick. > Is there a way to disable sessions for specific port or IP ? From moua0100 at umn.edu Mon Oct 12 13:09:43 2009 From: moua0100 at umn.edu (Ge Moua) Date: Mon, 12 Oct 2009 12:09:43 -0500 Subject: [c-nsp] ASA Firewalls placement in the network! In-Reply-To: <4AD35729.4080205@opus1.com> References: <4AD35729.4080205@opus1.com> Message-ID: <4AD362D7.20902@umn.edu> Joel M Snyder - >> If you do the job right, from a security point of view, you can certainly put a fine firewall in front of a very busy DNS server. (and when I say "very busy" I'm talking 10K queries a second, which is to say about 20Mbit/second sustained round-the-clock load, for less than $10K) what you recommend for this? Some of my colleague have suggested a redundant open-bsd cluster (with plenty of RAM b/c memory is cheap these days) with PF; I can see a scalable home grown solution that can address the "exhausted state table" issue; I'm just wondering if cheap fast CPU will be on par (performance and throughput wise) with fast ASIC like the big box vendor uses on their firewall products. What do you think? Regards, Ge Moua | Email: moua0100 at umn.edu Network Design Engineer University of Minnesota | Networking & Telecommunications Services Joel M Snyder wrote: > > The worst thing you can do is put a stateful firewall in > > front of a > > busy DNS server > > Well, as a security guy (rather than as a network guy), I would > respectfully disagree. > > First of all, if your firewall is underspecified or underrated, then > yes, you'll have problems. Secondly, if your firewall is > misconfigured or mistuned, then yes, you'll have problems. Of > course, both of these things are true of the network itself as > everyone on this list knows very well. > > If you do the job right, from a security point of view, you can > certainly put a fine firewall in front of a very busy DNS server. > (and when I say "very busy" I'm talking 10K queries a second, which is > to say about 20Mbit/second sustained round-the-clock load, for less > than $10K) > > So then the question comes: well, what's the point? I think that a > lot of the folks on this list feel that throwing an ACL in front of a > box is effectively the same, from a security point of view, as a > firewall and a hell of a lot cheaper. > > If you have a lousy firewall (i.e., one that is doing nothing more > than keeping a UDP session open), yes, absolutely. However, good > firewalls are doing a lot more than that. > > You may remember last year's "the Internet is falling and only Dan > Kaminsky can explain it" flap around DNS. Well, a lot of the > discussion around this bug/problem/issue ignored the truth that a good > firewall prevented the attack directly, by knowing enough 'deep packet > smarts' around the DNS protocol that the attack scenario was > effectively blocked (hey, that's why we have a session table in the > first place!). Similarly, a well-configured firewall would have per-IP > rate limits in it, which would have been a second line of defense. > > Now, if you put in a piece-o-crap firewall that is misconfigured, too > slow, doesn't have a big enough session table, and doesn't do anything > more than your average reflexive access control list, then you're > right on: rip that junk out and go bareback. > > But if you do it right, there is value to be provided by a firewall. > > jms > > From Joel.Snyder at Opus1.COM Mon Oct 12 12:19:53 2009 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Mon, 12 Oct 2009 09:19:53 -0700 Subject: [c-nsp] cisco-nsp Digest, Vol 83, Issue 39 In-Reply-To: References: Message-ID: <4AD35729.4080205@opus1.com> > The worst thing you can do is put a stateful firewall in > front of a > busy DNS server Well, as a security guy (rather than as a network guy), I would respectfully disagree. First of all, if your firewall is underspecified or underrated, then yes, you'll have problems. Secondly, if your firewall is misconfigured or mistuned, then yes, you'll have problems. Of course, both of these things are true of the network itself as everyone on this list knows very well. If you do the job right, from a security point of view, you can certainly put a fine firewall in front of a very busy DNS server. (and when I say "very busy" I'm talking 10K queries a second, which is to say about 20Mbit/second sustained round-the-clock load, for less than $10K) So then the question comes: well, what's the point? I think that a lot of the folks on this list feel that throwing an ACL in front of a box is effectively the same, from a security point of view, as a firewall and a hell of a lot cheaper. If you have a lousy firewall (i.e., one that is doing nothing more than keeping a UDP session open), yes, absolutely. However, good firewalls are doing a lot more than that. You may remember last year's "the Internet is falling and only Dan Kaminsky can explain it" flap around DNS. Well, a lot of the discussion around this bug/problem/issue ignored the truth that a good firewall prevented the attack directly, by knowing enough 'deep packet smarts' around the DNS protocol that the attack scenario was effectively blocked (hey, that's why we have a session table in the first place!). Similarly, a well-configured firewall would have per-IP rate limits in it, which would have been a second line of defense. Now, if you put in a piece-o-crap firewall that is misconfigured, too slow, doesn't have a big enough session table, and doesn't do anything more than your average reflexive access control list, then you're right on: rip that junk out and go bareback. But if you do it right, there is value to be provided by a firewall. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From frnkblk at iname.com Mon Oct 12 14:12:01 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Mon, 12 Oct 2009 13:12:01 -0500 Subject: [c-nsp] 7206VXR NPE for ~1000 RBE interfaces In-Reply-To: References: Message-ID: An NPE400 should do fine if you're looking used or on a tight budget, but if you're looking to buy for growth, just get a G2 and be done with it. Frank -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Antonio Querubin Sent: Sunday, October 11, 2009 5:27 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] 7206VXR NPE for ~1000 RBE interfaces I'm researching upgrading a 7206VXR to handle about 1000 RBE interfaces off of either 2 T3 or 1 OC3 ATM line. Anybody got any recommendations on which NPE would handle this scenario? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From sthaug at nethelp.no Mon Oct 12 15:37:52 2009 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 12 Oct 2009 21:37:52 +0200 (CEST) Subject: [c-nsp] cisco-nsp Digest, Vol 83, Issue 39 In-Reply-To: <4AD35729.4080205@opus1.com> References: <4AD35729.4080205@opus1.com> Message-ID: <20091012.213752.74741620.sthaug@nethelp.no> > If you have a lousy firewall (i.e., one that is doing nothing more than > keeping a UDP session open), yes, absolutely. However, good firewalls > are doing a lot more than that. Some of us have seen too much damage done by firewalls to DNS, SMTP and a number of other protocols to really believe in this. > Now, if you put in a piece-o-crap firewall that is misconfigured, too > slow, doesn't have a big enough session table, and doesn't do anything > more than your average reflexive access control list, then you're right > on: rip that junk out and go bareback. It would seem that the piece-o-crap firewalls vastly outnumber the good firewalls. See, for instance, the discussions on various DNS lists about firewalls and EDNS0. > But if you do it right, there is value to be provided by a firewall. In some circumstances, agreed. For DNS servers (whether recursive or authoritative), absolutely not. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From gsgranados at comcast.net Mon Oct 12 15:57:32 2009 From: gsgranados at comcast.net (Scott Granados) Date: Mon, 12 Oct 2009 12:57:32 -0700 Subject: [c-nsp] cisco-nsp Digest, Vol 83, Issue 39 References: <4AD35729.4080205@opus1.com> <20091012.213752.74741620.sthaug@nethelp.no> Message-ID: <017001ca4b76$44f91880$2408120a@am.thmulti.com> And further more, why inject more points of failure for little to no value? Everything listed in the OP's message that he considers good things about firewalls in front can be done with a properly administered server and good patching habbits. Firewalls have their places but generally not in the front of DNS servers or servers in general. (Anything Microsoft could be an exception to this) As long as you're running a real OS and have decent to good clue firewalls are extra and offer almost nothing. Thank you Scott ----- Original Message ----- From: To: Cc: ; Sent: Monday, October 12, 2009 12:37 PM Subject: Re: [c-nsp] cisco-nsp Digest, Vol 83, Issue 39 >> If you have a lousy firewall (i.e., one that is doing nothing more than >> keeping a UDP session open), yes, absolutely. However, good firewalls >> are doing a lot more than that. > > Some of us have seen too much damage done by firewalls to DNS, SMTP and > a number of other protocols to really believe in this. > >> Now, if you put in a piece-o-crap firewall that is misconfigured, too >> slow, doesn't have a big enough session table, and doesn't do anything >> more than your average reflexive access control list, then you're right >> on: rip that junk out and go bareback. > > It would seem that the piece-o-crap firewalls vastly outnumber the good > firewalls. See, for instance, the discussions on various DNS lists > about firewalls and EDNS0. > >> But if you do it right, there is value to be provided by a firewall. > > In some circumstances, agreed. For DNS servers (whether recursive or > authoritative), absolutely not. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From peter at rathlev.dk Mon Oct 12 16:10:22 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Mon, 12 Oct 2009 22:10:22 +0200 Subject: [c-nsp] Firewalls in front of Internet servers (was: cisco-nsp Digest, Vol 83, Issue 39) In-Reply-To: <4AD35729.4080205@opus1.com> References: <4AD35729.4080205@opus1.com> Message-ID: <1255378223.2832.19.camel@abehat.net.rm.dk> On Mon, 2009-10-12 at 09:19 -0700, Joel M Snyder wrote: > You may remember last year's "the Internet is falling and only Dan > Kaminsky can explain it" flap around DNS. Well, a lot of the > discussion around this bug/problem/issue ignored the truth that a good > firewall prevented the attack directly, by knowing enough 'deep packet > smarts' around the DNS protocol that the attack scenario was > effectively blocked (hey, that's why we have a session table in the > first place!). The "Kaminsky attack" only makes sense towards recursive resolvers, and I think most posters here are thinking about authoritative Internet facing nameservers. Who runs a recursive nameserver open towards the Internet now adays? Even so: The nameservers make outbound requests and for those it sort of does make sense to have stateful inspection. Except AFAIK the Kaminsky attack works with spoofed answers, i.e. spoofing both source IP and ports and query ID. How would a firewall (including DPI) catch this? By randomizing source ports or query IDs like TCP sequence number randomization? I'm not sure I agree that's a good idea. By denying all but one answers? Perfect way to DoS yourself. > Similarly, a well-configured firewall would have per-IP rate limits in > it, which would have been a second line of defense. Um... wouldn't that just make a DoS attempt even easier for an attacker? > Now, if you put in a piece-o-crap firewall that is misconfigured, too > slow, doesn't have a big enough session table, and doesn't do anything > more than your average reflexive access control list, then you're > right on: rip that junk out and go bareback. > > But if you do it right, there is value to be provided by a firewall. As always, costs are important. Why should I spend $$$ for a large enough firewall that doesn't give me any extra value? -- Peter From jfitz at Princeton.EDU Mon Oct 12 16:43:11 2009 From: jfitz at Princeton.EDU (Jeff Fitzwater) Date: Mon, 12 Oct 2009 16:43:11 -0400 Subject: [c-nsp] filtering IPV6 for L2 bridged traffic ? Message-ID: <53344014-9EA3-401A-AD50-91A139B98DEB@Princeton.EDU> I am running SXI code on sup720-CXL and need to filter out certain IPV6 packets like MDNS on trunked L2 port? I was going to use an vlan access-map but it appears that it does not allow me to do a MATCH on an IPV6 acl, I guess I am stuck with a MAC ACL to filter bridged IPV6 traffic. Any ideas on this issue? How else can it be done? Thanks in advance> Jeff Fitzwater OIT Network Systems Princeton University From kgraham at industrial-marshmallow.com Mon Oct 12 15:58:19 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Mon, 12 Oct 2009 12:58:19 -0700 (PDT) Subject: [c-nsp] cisco-nsp Digest, Vol 83, Issue 39 In-Reply-To: <4AD35729.4080205@opus1.com> References: <4AD35729.4080205@opus1.com> Message-ID: <905710.4590.qm@web504.biz.mail.mud.yahoo.com> > However, good firewalls are doing a lot more than that. > > You may remember last year's "the Internet is falling and only Dan Kaminsky can > explain it" flap around DNS. Well, a lot of the discussion around this > bug/problem/issue ignored the truth that a good firewall prevented the attack > directly As I read it, the discussion here was a public/authoritative name server. The only thing those servers would have seen from the attack is backscatter. > by knowing enough 'deep packet smarts' around the DNS protocol that > the attack scenario was effectively blocked (hey, that's why we have a session > table in the first place!). Which product's 'deep packet smarts' catch a duplicate transaction ID? For that matter, does anyone know of a breakdown of _actual_ protocol analysis applied by different products? The few I've poked at fail to catch many deviations of well-formed and common protocols. Egress traffic -- firewall to death (especially if you can offload heavy lifting to a full ALG), but inbound is much more effectively addressed by application / server administration with a tight ingress and egress ACL. > But if you do it right, there is value to be provided by a firewall. > Similarly, a well-configured firewall would have per-IP rate limits in it, > which would have been a second line of defense. ...and now we're back to Arbor, which get this w/o being in the forwarding path. That said, there are lots of places where I'd love to be able to apply QoS policies on a per-address (rather than per-flow or per-acl) basis both for security and performance motivations. From David.Lima at alphasys.com.bo Mon Oct 12 16:49:51 2009 From: David.Lima at alphasys.com.bo (David Lima) Date: Mon, 12 Oct 2009 16:49:51 -0400 Subject: [c-nsp] About WAAS and File Sharing Message-ID: Hi Guys, I'm testing WAAS performance with sharing Word and pdf files, and it is working as I expected. But when I share an *.exe file or *.bin file the result is not the same. I can't see any improvement. Please help me to understand that. Waas works nice with data files (word, power point, pdf, txt, etc) and not with *.bin or *.exe files? Thanks a lot guys David From Joel.Snyder at Opus1.COM Mon Oct 12 17:00:11 2009 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Mon, 12 Oct 2009 14:00:11 -0700 Subject: [c-nsp] Firewalls in front of Internet servers In-Reply-To: <1255378223.2832.19.camel@abehat.net.rm.dk> References: <4AD35729.4080205@opus1.com> <1255378223.2832.19.camel@abehat.net.rm.dk> Message-ID: <4AD398DB.7070106@opus1.com> Peter Rathlev wrote: > On Mon, 2009-10-12 at 09:19 -0700, Joel M Snyder wrote: >> You may remember last year's "the Internet is falling and only Dan >> Kaminsky can explain it" flap around DNS. Well, a lot of the >> discussion around this bug/problem/issue ignored the truth that a good >> firewall prevented the attack directly, by knowing enough 'deep packet >> smarts' around the DNS protocol that the attack scenario was >> effectively blocked (hey, that's why we have a session table in the >> first place!). > > The "Kaminsky attack" only makes sense towards recursive resolvers, and > I think most posters here are thinking about authoritative Internet > facing nameservers. Who runs a recursive nameserver open towards the > Internet now adays? Well, if "nowadays" is "the day before the Kaminsky press..." then I'd say "all kinds of people." Including prominent NANOG contributors. I suspect most of those folks have cleaned up their acts since then, but I have learned never to be surprised at the level of security as actually deployed. And I don't even have a seat-of-the-pants number to throw out, but I'd bet that you'd be surprised if you did a little survey at how many recursive resolvers are reachable from the general purpose Internet. > > Even so: The nameservers make outbound requests and for those it sort of > does make sense to have stateful inspection. Except AFAIK the Kaminsky > attack works with spoofed answers, i.e. spoofing both source IP and > ports and query ID. How would a firewall (including DPI) catch this? By > randomizing source ports or query IDs like TCP sequence number > randomization? I'm not sure I agree that's a good idea. By denying all > but one answers? Perfect way to DoS yourself. I don't see that as a DoS issue. Let's say that the firewall has an idea that a DNS query should have only one answer (which would be correct). If you start to get multiple answers for each query, then wouldn't that be something you'd want to know about? We're not talking about port scanning here; we're talking about clearly broken behavior--either a broken DNS server which is multi-replying to queries or some third party trying to inject bad juju. Yes, it turns out that almost anything the security people put in place can be used by a malicious attacker to create a DoS. For example, if I know you have a brand firewall, I can send a medium-size ZIP files, better double-ZIPped (more is suspicious), through the firewall with email and watch those little files have an impact equal to 10x their normal bandwidth. Even if you have NO security hardware in place, by knowing your routing infrastructure and desire to patch, I can cause DoS attacks with crafty choice of traffic designed to either cause disproportionate load or, even better, a nice reload every once in a while. Yes, I'll acknowledge that the security hardware is MUCH more susceptible to this kind of attack. I was in the lab a few months ago with a massive IPS from and accidentally chose the "wrong" port to send throughput test traffic on, and watched that box go from 40Gbps to about 2Gbps. Now, maybe this is NANOG and ISPs operate in a 'we're just a utility company; you buy your own water softener or surge suppressor' mindset. But a lot of the thinking that goes into engineering large ISP networks is applicable to large enterprise networks, and vice versa. I see organizations in the carrier business who a few years ago would never dream of anything but the lightest of ACLs across their infrastructure now investing in big firewalls and other tools to provide security. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From Joel.Snyder at Opus1.COM Mon Oct 12 17:14:39 2009 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Mon, 12 Oct 2009 14:14:39 -0700 Subject: [c-nsp] Firewalls in front of Internet servers In-Reply-To: <4AD398DB.7070106@opus1.com> References: <4AD35729.4080205@opus1.com> <1255378223.2832.19.camel@abehat.net.rm.dk> <4AD398DB.7070106@opus1.com> Message-ID: <4AD39C3F.3030106@opus1.com> Sorry: > Now, maybe this is NANOG and ISPs operate in a 'we're just a utility Meant "maybe this is cisco NSP ..." Apologies for the obvious stupid error. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From ivannetw at gmail.com Mon Oct 12 20:44:13 2009 From: ivannetw at gmail.com (Ivan c) Date: Tue, 13 Oct 2009 11:44:13 +1100 Subject: [c-nsp] Cisco routers can do more than just route... Message-ID: <75b1b4850910121744i54261886s438b345897063ba4@mail.gmail.com> Everyone wants a piece of the Linux action.... http://www.h-online.com/security/Cisco-routers-can-do-more-than-just-route--/news/114437 From kgraham at industrial-marshmallow.com Mon Oct 12 23:41:31 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Mon, 12 Oct 2009 20:41:31 -0700 (PDT) Subject: [c-nsp] RMON history collection caveats? Message-ID: <204973.10674.qm@web504.biz.mail.mud.yahoo.com> Is anyone doing large-scale RMON history collection presently? We're considering it for capacity and error monitoring, as history buckets allow for really trivial implementation of otherwise complex checks like "on any given port, I don't care about a 1000 errors in a bucket, but I do care about 10 errors in each of 3 consecutive buckets". Most of the CCO notes seem to date back to when RMON was new and cool and how to turn it up on a cat5k. An efficient implementation would suggest that the switch collects existing interface counters every history bucket; presumably these will exhibit all of the usual platform-specific counter quirks? Is there any reason at all to be concerned about CPU/memory utilization? Obviously on most platforms I wouldn't think twice, but for example a large 3750 stack serious skews the ratio of ports to cpu/mem. We'd be looking at doing this indiscriminately across 6500's, 4500's and any mix of small DSBU switches (from 3750E's to some 3500XL's that refuse to die). From jckdaniels12 at gmail.com Tue Oct 13 02:42:26 2009 From: jckdaniels12 at gmail.com (jack daniels) Date: Tue, 13 Oct 2009 12:12:26 +0530 Subject: [c-nsp] best practices switches/Router Message-ID: <8bb137f40910122342u4842c6c5s8c7b9830be7e81f1@mail.gmail.com> Hi , I'm looking for doc which suggests best practices for network ( ROUTERS and SWITCHES ) Please help me with doc link if any there. Regards From renukakb at gmail.com Tue Oct 13 02:48:49 2009 From: renukakb at gmail.com (Renuka K) Date: Tue, 13 Oct 2009 12:18:49 +0530 Subject: [c-nsp] How to do Traffic control in firewall Message-ID: <114c24980910122348t320e9d8erfce4293f7bf6ff2c@mail.gmail.com> From gkg at gmx.de Tue Oct 13 03:19:55 2009 From: gkg at gmx.de (Garry) Date: Tue, 13 Oct 2009 09:19:55 +0200 Subject: [c-nsp] best practices switches/Router In-Reply-To: <8bb137f40910122342u4842c6c5s8c7b9830be7e81f1@mail.gmail.com> References: <8bb137f40910122342u4842c6c5s8c7b9830be7e81f1@mail.gmail.com> Message-ID: <4AD42A1B.9040106@gmx.de> jack daniels wrote: > Hi , > > I'm looking for doc which suggests best practices for network ( ROUTERS and > SWITCHES ) > Please help me with doc link if any there. > It might be helpful if you could point out what exactly you are interested in, or what topics you require ... otherwise your request would be overly broad and a good place to start might be http://cisco.com ... ;) From joohwil at gmail.com Tue Oct 13 03:57:49 2009 From: joohwil at gmail.com (John Wilkes) Date: Tue, 13 Oct 2009 09:57:49 +0200 Subject: [c-nsp] MPLS exp imposition on 7600 Message-ID: <7d490c2d0910130057h1e5186a3weba1142dd5fb1e49@mail.gmail.com> Hi. I seem to be going mad. This is supposed to work, right? I'm trying to get a policy-map to mark EXP5 for all traffic coming from a vlan. mls qos policy-map TEST ?class class-default ? ?set mpls exp impo 5 int vlan123 ?descr to-CE ?service-policy input TEST The counters aren't increasing: PE#show policy-map interface Vlan123 ?Service-policy input: TEST ? ?class-map: class-default (match-any) ? ? ?Match: any ? ? ?set mpls experimental 5: ? ? ?Earl in slot 5 : ? ? ? ?0 bytes ? ? ? ?30 second offered rate 0 bps ? ? ? ?aggregate-forwarded 0 bytes And a traceroute from the CE through PE shows that EXP is 0 for every hop. And yes, this is where the traffic goes. Setting the policy-map in the outgoing direction does increase the counters, but that doesn't help much. I also tried a policer with conform-action set mpls exp transmit, same results. No trust (cos or dscp) configured anywhere. "mls qos mpls trust experimental" is on by default and not disabled. What could be wrong? Sup: RSP720-3CXL CE attached to: WS-X6748-GE-TX IOS: 12.2(33)SRB1 From tayfun.sari at superonline.net Tue Oct 13 03:31:54 2009 From: tayfun.sari at superonline.net (TAYFUN SARI) Date: Tue, 13 Oct 2009 10:31:54 +0300 Subject: [c-nsp] best practices switches/Router In-Reply-To: <4AD42A1B.9040106@gmx.de> References: <8bb137f40910122342u4842c6c5s8c7b9830be7e81f1@mail.gmail.com> <4AD42A1B.9040106@gmx.de> Message-ID: Hi, After adding the etherchannel configuration between the switches ME3400 and Cisco3600,we were unable to ping and test the L3 connectivity.But when we verify that mac addressses could be determined by the devices successfully.Could you please investigate and inform us as soon as possible? Regards ME3400 Version 12.2(46)SE: interface Port-channel3 description test port-type nni switchport access vlan 150 ! interface FastEthernet0/1 port-type nni switchport access vlan 150 channel-group 3 mode on interface Vlan150 ip address 1.1.1.17 255.255.255.252 no ip route-cache no ip mroute-cache 3600 Version 12.4(23): ! interface Port-channel3 ip address 1.1.1.18 255.255.255.252 no ip redirects ! interface FastEthernet4/0 no ip address duplex auto speed auto channel-group 3 ************************************************************************ Bu elektronik posta ve onunla iletilen butun dosyalar sadece gondericisi tarafindan almasi amaclanan yetkili gercek ya da tuzel kisinin kullanimi icindir. Eger soz konusu yetkili alici degilseniz bu elektronik postanin icerigini aciklamaniz, kopyalamaniz, yonlendirmeniz ve kullanmaniz hukuka aykiri ve yasaktir, eger bu mesaji yanlislikla aldiysaniz lutfen gondereni ile temasa geciniz ve bu elektronik postayi siliniz. Tellcom Iletisim Hizmetleri A.S. bu mesajin icerdigi bilgilerin dogrulugu veya eksiksiz oldugu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve saklanmasindan sorumlu degildir. Bu mesajdaki gorusler yalnizca gonderen kisiye aittir ve Tellcom Iletisim Hizmetleri A.S. nin goruslerini yansitmayabilir Bu e-posta bilinen butun bilgisayar viruslerine karsi taranmistir. ************************************************************************ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibitedan may be unlawful. If you receive this in error, please contact the sender and delete the material from any computer. Please note that any opinions expressed in this e-mail are those of the author personally and not Tellcom Iletisim Hizmetleri A.S. who do not accept responsibility for the contents of the message. This e-mail has been scanned for all known computer viruses. ************************************************************************ From avayner at cisco.com Tue Oct 13 04:19:29 2009 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Tue, 13 Oct 2009 10:19:29 +0200 Subject: [c-nsp] MPLS exp imposition on 7600 In-Reply-To: <7d490c2d0910130057h1e5186a3weba1142dd5fb1e49@mail.gmail.com> References: <7d490c2d0910130057h1e5186a3weba1142dd5fb1e49@mail.gmail.com> Message-ID: John, How is that VLAN connected to the customer? Over a trunk? You should have the "mls qos vlan-based" command on the physical connection... Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of John Wilkes Sent: Tuesday, October 13, 2009 09:58 To: cisco-nsp at puck.nether.net Subject: [c-nsp] MPLS exp imposition on 7600 Hi. I seem to be going mad. This is supposed to work, right? I'm trying to get a policy-map to mark EXP5 for all traffic coming from a vlan. mls qos policy-map TEST ?class class-default ? ?set mpls exp impo 5 int vlan123 ?descr to-CE ?service-policy input TEST The counters aren't increasing: PE#show policy-map interface Vlan123 ?Service-policy input: TEST ? ?class-map: class-default (match-any) ? ? ?Match: any ? ? ?set mpls experimental 5: ? ? ?Earl in slot 5 : ? ? ? ?0 bytes ? ? ? ?30 second offered rate 0 bps ? ? ? ?aggregate-forwarded 0 bytes And a traceroute from the CE through PE shows that EXP is 0 for every hop. And yes, this is where the traffic goes. Setting the policy-map in the outgoing direction does increase the counters, but that doesn't help much. I also tried a policer with conform-action set mpls exp transmit, same results. No trust (cos or dscp) configured anywhere. "mls qos mpls trust experimental" is on by default and not disabled. What could be wrong? Sup: RSP720-3CXL CE attached to: WS-X6748-GE-TX IOS: 12.2(33)SRB1 _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From joohwil at gmail.com Tue Oct 13 04:29:43 2009 From: joohwil at gmail.com (John Wilkes) Date: Tue, 13 Oct 2009 10:29:43 +0200 Subject: [c-nsp] MPLS exp imposition on 7600 In-Reply-To: References: <7d490c2d0910130057h1e5186a3weba1142dd5fb1e49@mail.gmail.com> Message-ID: <7d490c2d0910130129y370c8fcdhc0c5682611be0696@mail.gmail.com> On Tue, Oct 13, 2009 at 10:19 AM, Arie Vayner (avayner) wrote: > How is that VLAN connected to the customer? Over a trunk? > You should have the "mls qos vlan-based" command on the physical connection... Yes! That was it. Thank you. From saku at ytti.fi Tue Oct 13 04:37:47 2009 From: saku at ytti.fi (Saku Ytti) Date: Tue, 13 Oct 2009 11:37:47 +0300 Subject: [c-nsp] 3rd party NVRAM for Cisco 800 series? Message-ID: <20091013083747.GA7462@mx.ytti.net> Anyone know vendor selling these: http://ytti.fi/20091005018.jpg http://ytti.fi/20091005017.jpg (Size reference) They are 24MB of flash in 877, 878 boxes. Current 12.5M does not fit the 24MB size and I'd rather buy 3rd party memory than CSCO original (or obviously AMBIT original:) Crucial and Kingston said no. Thanks, -- ++ytti From jdurand at renater.fr Tue Oct 13 05:24:31 2009 From: jdurand at renater.fr (Jerome Durand) Date: Tue, 13 Oct 2009 11:24:31 +0200 Subject: [c-nsp] mls qos on 7600 with native vlan and MPLS Message-ID: <4AD4474F.8070109@renater.fr> Hi all, I do run a 7600 3CXL based backone and have 2 questions with MLS QOS related to native ethernet vlan. 1?) How can I do egress scheduling on customers interfaces (routed interfaces "no switchport" on LAN cards with no 802.1Q enabled) My understanding is that this queueing mode can be based only on COS field on GE and 10/100/1000 line cards. So what will be the router behaviour if there is no 802.Q and therefore no 802.1p? I think I don't have problem for 10GE interfaces as I could use dscp based queueing (honnestly I don't really need egress scheduling on 10GE customers interfaces...) 2?) I do run MPLS in the core for VPN services. The core interfaces are in mode "no switchport" and are untagged as well (routed ports on 10GE interfaces). Here too, what happens if I have cos based queueing (as this is native ethernet)? What happens if I run DSCP based queueing (as this is MPLS, can dscp be used?) My goal here is more to make sure that my qos does not break anything. Any good reference for mls qos on MPLS backbone is welcome! Thanks a lot! Jerome -- ------------------------------------------------------------- Jerome Durand Responsable des services aux usagers Services operations & support manager R?seau National de T?l?communications pour la Technologie, l'Enseignement et la Recherche Tel: +33 (0) 1 53 94 20 40 | GIP RENATER Fax: +33 (0) 1 53 94 20 41 | c/o ENSAM E-mail: jdurand at renater.fr | 151 Boulevard de l'H?pital http://www.renater.fr | 75013 PARIS -------------------------------------------------------------- From tim at pelican.org Tue Oct 13 06:12:10 2009 From: tim at pelican.org (Tim Franklin) Date: Tue, 13 Oct 2009 10:12:10 +0000 (GMT) Subject: [c-nsp] About WAAS and File Sharing In-Reply-To: Message-ID: <32365754.1521255428730844.JavaMail.root@jennyfur.pelican.org> > Hi Guys, I'm testing WAAS performance with sharing Word and pdf files, > and it is working as I expected. But when I share an *.exe file or > *.bin file the result is not the same. I can't see any improvement. > Please help me to understand that. Waas works nice with data files > (word, power point, pdf, txt, etc) and not with *.bin or *.exe files? You'll typically get better compression on docs than executables. What's your latency like between sites? If you're already low-latency, most of the WAAS benefit is going to come from data compression (I'm including DRE here, as well as the LZ), so if you have low-compression files... Regards, Tim. From linux.yahoo at gmail.com Tue Oct 13 06:52:18 2009 From: linux.yahoo at gmail.com (Manu Chao) Date: Tue, 13 Oct 2009 12:52:18 +0200 Subject: [c-nsp] ibgp TTL Message-ID: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> For a very specific design, i need to limit TTL value in ibgp-multihop. Is it possible to limit iBGP TTL like we do with ebgp-multihop ttl command? Any input appreciated. Manu From jawwad14 at gmail.com Tue Oct 13 07:26:23 2009 From: jawwad14 at gmail.com (Muhammad Jawwad Paracha) Date: Tue, 13 Oct 2009 16:26:23 +0500 Subject: [c-nsp] ibgp TTL In-Reply-To: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> Message-ID: neighbour timer will do the trick for you. On Tue, Oct 13, 2009 at 3:52 PM, Manu Chao wrote: > For a very specific design, i need to limit TTL value in ibgp-multihop. > > Is it possible to limit iBGP TTL like we do with ebgp-multihop ttl command? > > Any input appreciated. > > Manu > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From z at amused.net Tue Oct 13 07:00:31 2009 From: z at amused.net (Patrick Cole) Date: Tue, 13 Oct 2009 22:00:31 +1100 Subject: [c-nsp] L2TP LNS issue Message-ID: <20091013110031.GA15189@amused.net> Hi all, Got a really weird problem that I'm hoping is the result of something simple and stupid on my part. I've got a 7204VXR running 12.2(31)SB16 and am trying to terminate a PPP session using L2TP/VPDN as an LNS. The test LAC is linux using xl2tpd/pppd. Here is some debug logging from when the connection goes through: *Oct 8 12:19:17.790: L2TP: I SCCRQ from hatika tnl 19184 *Oct 8 12:19:17.790: AAA/BIND(00000A91): Bind i/f *Oct 8 12:19:17.790: Tnl 23179 L2TP: Tunnel Authorization started for host hatika *Oct 8 12:19:17.790: Tnl 23179 L2TP: New tunnel created for remote hatika, address *Oct 8 12:19:17.790: L2X: Tunnel author reply found L2X info *Oct 8 12:19:17.790: Tnl 23179 L2TP: O SCCRP to hatika tnlid 19184 *Oct 8 12:19:17.790: Tnl 23179 L2TP: Control channel retransmit delay set to 1 seconds *Oct 8 12:19:17.790: Tnl 23179 L2TP: Tunnel state change from idle to wait-ctl-reply *Oct 8 12:19:17.798: Tnl 23179 L2TP: I SCCCN from hatika tnl 19184 *Oct 8 12:19:17.798: Tnl 23179 L2TP: Control connection authentication skipped/passed. *Oct 8 12:19:17.798: Tnl 23179 L2TP: Tunnel auth counter, Overall Ignored, now 63 *Oct 8 12:19:17.798: Tnl 23179 L2TP: Tunnel state change from wait-ctl-reply to established *Oct 8 12:19:17.798: Tnl 23179 L2TP: SM State established *Oct 8 12:19:17.798: Tnl 23179 L2TP: Perform early message digest validation for ICRQ *Oct 8 12:19:17.798: Tnl 23179 L2TP: Control connection authentication skipped/passed. *Oct 8 12:19:17.798: Tnl 23179 L2TP: Tunnel auth counter, Overall Ignored, now 64 *Oct 8 12:19:17.798: Tnl 23179 L2TP: I ICRQ from hatika tnl 19184 *Oct 8 12:19:17.798: L2X Session DB (Tnl/Sn: 23179/2608): Stored the control session in the session DB *Oct 8 12:19:17.798: Tnl/Sn 23179/2608 L2TP: Create session *Oct 8 12:19:17.798: Tnl/Sn 23179/2608 L2TP: Session state change from idle to wait-connect *Oct 8 12:19:17.798: Tnl/Sn 23179/2608 L2TP: PW-MGMT: PW peer , vcid 0 *Oct 8 12:19:17.798: Tnl/Sn 23179/2608 L2TP: PW-MGMT: Reason [Protocol DOWN] *Oct 8 12:19:17.798: Tnl/Sn 23179/2608 L2TP: PW-MGMT: Local VC DOWN, Remote VC DOWN *Oct 8 12:19:17.798: Tnl/Sn 23179/2608 L2TP: PW-MGMT: Provisioned NO, Established NO *Oct 8 12:19:17.798: Tnl/Sn 23179/2608 L2TP: PW-MGMT: No change in PW state *Oct 8 12:19:17.798: Tnl/Sn 23179/2608 L2TP: Accepted ICRQ, new session created *Oct 8 12:19:17.798: AAA/BIND(00000A92): Bind i/f *Oct 8 12:19:17.798: uid:605 Tnl/Sn 23179/2608 L2TP: O ICRP to hatika 19184/39100 *Oct 8 12:19:17.798: Tnl 23179 L2TP: Control channel retransmit delay set to 1 seconds *Oct 8 12:19:17.806: Tnl 23179 L2TP: Perform early message digest validation for ICCN *Oct 8 12:19:17.806: Tnl 23179 L2TP: Control connection authentication skipped/passed. *Oct 8 12:19:17.806: Tnl 23179 L2TP: Tunnel auth counter, Overall Ignored, now 65 *Oct 8 12:19:17.806: uid:605 Tnl/Sn 23179/2608 L2TP: I ICCN from hatika tnl 19184, cl 39100 *Oct 8 12:19:17.806: uid:605 Tnl/Sn 23179/2608 L2TP: Session state change from wait-connect to wait-for-service-selection-iccn *Oct 8 12:19:17.806: uid:605 Tnl/Sn 23179/2608 L2TP: PW-MGMT: PW peer , vcid 0 *Oct 8 12:19:17.806: uid:605 Tnl/Sn 23179/2608 L2TP: PW-MGMT: Reason [Protocol DOWN] *Oct 8 12:19:17.806: uid:605 Tnl/Sn 23179/2608 L2TP: PW-MGMT: Local VC DOWN, Remote VC DOWN *Oct 8 12:19:17.806: uid:605 Tnl/Sn 23179/2608 L2TP: PW-MGMT: Provisioned NO, Established NO *Oct 8 12:19:17.806: uid:605 Tnl/Sn 23179/2608 L2TP: PW-MGMT: No change in PW state *Oct 8 12:19:17.810: uid:605 Tnl/Sn 23179/2608 L2TP: L2X session data plane setup successful *Oct 8 12:19:17.810: AAA/BIND(00000A92): Bind i/f Virtual-Template1 *Oct 8 12:19:17.810: L2X Session DB (Tnl/Sn: 23179/2608): Stored the switching session in the session DB *Oct 8 12:19:17.810: L2TP:(Tnl23179:Sn2608)L2X s/w switching session provisioned *Oct 8 12:19:17.810: ppp605 PPP: Initialized Context 64744360 *Oct 8 12:19:17.810: ppp605 PPP: Using AAA Unique Id = A92 *Oct 8 12:19:17.810: ppp605 PPP: Dynamic Bind peer_type[4] *Oct 8 12:19:17.810: ppp605 PPP: Send Message[Dynamic Bind Response] *Oct 8 12:19:17.810: ppp605 PPP: Authorization required *Oct 8 12:19:20.818: ppp605 PPP SSS: forwarding request *Oct 8 12:19:20.822: ppp605 PPP SSS: Receive SSS-Mgr Need-More-Keys *Oct 8 12:19:20.822: AAA/AUTHEN/PPP (00000A92): Pick method list 'default' *Oct 8 12:19:20.822: ppp605 PPP: Sent PAP LOGIN Request *Oct 8 12:19:20.822: RADIUS/ENCODE(00000A92):Orig. component type = VPDN *Oct 8 12:19:20.822: RADIUS: AAA Unsupported Attr: password [274] 4 *Oct 8 12:19:20.822: RADIUS: 74 65 [ te] *Oct 8 12:19:20.822: RADIUS: AAA Unsupported Attr: interface [185] 15 *Oct 8 12:19:20.822: RADIUS: 55 6E 69 71 2D 53 65 73 73 2D 49 44 36 [ Uniq-Sess-ID6] *Oct 8 12:19:20.822: RADIUS(00000A92): Config NAS IP: 0.0.0.0 *Oct 8 12:19:20.822: RADIUS/ENCODE(00000A92): acct_session_id: 2696 *Oct 8 12:19:20.822: RADIUS(00000A92): sending *Oct 8 12:19:20.822: RADIUS/ENCODE: Best Local IP-Address for Radius-Server *Oct 8 12:19:20.822: RADIUS(00000A92): Send Access-Request to :1812 id 1645/47, len 118 *Oct 8 12:19:20.822: RADIUS: authenticator DF 17 C7 EF 81 4B BD 0D - 1D 8F F6 60 45 93 25 99 *Oct 8 12:19:20.822: RADIUS: Framed-Protocol [7] 6 PPP [1] *Oct 8 12:19:20.822: RADIUS: User-Name [1] 23 "user at test.realm.com" *Oct 8 12:19:20.822: RADIUS: User-Password [2] 18 * *Oct 8 12:19:20.822: RADIUS: Connect-Info [77] 10 "10000000" *Oct 8 12:19:20.822: RADIUS: NAS-Port-Type [61] 6 Virtual [5] *Oct 8 12:19:20.822: RADIUS: NAS-Port [5] 6 605 *Oct 8 12:19:20.822: RADIUS: NAS-Port-Id [87] 17 "Uniq-Sess-ID605" *Oct 8 12:19:20.822: RADIUS: Service-Type [6] 6 Framed [2] *Oct 8 12:19:20.822: RADIUS: NAS-IP-Address [4] 6 *Oct 8 12:19:20.890: RADIUS: Received from id 1645/47 :1812, Access-Accept, len 62 *Oct 8 12:19:20.890: RADIUS: authenticator AA B0 25 2A A0 E5 E7 F5 - 46 AC 74 89 92 50 E5 24 *Oct 8 12:19:20.890: RADIUS: Framed-IP-Address [8] 6 10.0.0.1 *Oct 8 12:19:20.890: RADIUS: Framed-IP-Netmask [9] 6 255.255.255.255 *Oct 8 12:19:20.890: RADIUS: Port-Limit [62] 6 1 *Oct 8 12:19:20.890: RADIUS: Framed-MTU [12] 6 1500 *Oct 8 12:19:20.890: RADIUS: Service-Type [6] 6 Framed [2] *Oct 8 12:19:20.894: RADIUS: Framed-Protocol [7] 6 PPP [1] *Oct 8 12:19:20.894: RADIUS: Framed-Compression [13] 6 VJ TCP/IP Header Compressi[1] *Oct 8 12:19:20.894: RADIUS(00000A92): Received from id 1645/47 *Oct 8 12:19:20.894: ppp605 PPP: Received LOGIN Response PASS *Oct 8 12:19:20.894: ppp605 PPP AUTHOR: Author Data Available *Oct 8 12:19:20.894: ppp605 PPP: Receive Attrs from[authen] Keep[LCP] MERGE *Oct 8 12:19:20.894: ppp605 PPP: Skip Attr: addr 10.0.0.1 *Oct 8 12:19:20.894: ppp605 PPP: Skip Attr: netmask 255.255.255.255 *Oct 8 12:19:20.894: ppp605 PPP: Skip Attr: Port-Limit 1 (0x1) *Oct 8 12:19:20.894: ppp605 PPP: Skip Attr: Framed-MTU 1500 (0x5DC) *Oct 8 12:19:20.894: ppp605 PPP: Keep Attr: service-type 2 [Framed] *Oct 8 12:19:20.894: ppp605 PPP: Keep Attr: Framed-Protocol 1 [PPP] *Oct 8 12:19:20.894: ppp605 PPP: Skip Attr: link-compression 4 [vj] *Oct 8 12:19:20.894: ppp605 PPP SSS: forwarding request *Oct 8 12:19:20.894: ppp605 PPP: Receive Attrs from[SSS] Keep[NCPs] MERGE *Oct 8 12:19:20.894: ppp605 PPP: Keep Attr: addr 10.0.0.1 *Oct 8 12:19:20.894: ppp605 PPP: Keep Attr: netmask 255.255.255.255 *Oct 8 12:19:20.894: ppp605 PPP: Keep Attr: Port-Limit 1 (0x1) *Oct 8 12:19:20.894: ppp605 PPP: Skip Attr: Framed-MTU 1500 (0x5DC) *Oct 8 12:19:20.894: ppp605 PPP: Skip Attr: service-type 2 [Framed] *Oct 8 12:19:20.894: ppp605 PPP: Skip Attr: Framed-Protocol 1 [PPP] *Oct 8 12:19:20.894: ppp605 PPP: Skip Attr: link-compression 4 [vj] *Oct 8 12:19:20.898: Vi4 PPP: Change SIP state from Init to Down *Oct 8 12:19:20.898: Vi4 PPP: old[Init] event[Encap] state[Down] *Oct 8 12:19:20.902: L2TP:(Tnl23179:Sn2608)L2X s/w session mode changed to L2_L3 *Oct 8 12:19:20.902: L2TP:(Tnl23179:Sn2608)L2X s/w switching session bound *Oct 8 12:19:20.902: PPP: Bind ppp605 to Virtual-Access4 *Oct 8 12:19:20.902: AAA/BIND(00000A92): Bind i/f Virtual-Access4 *Oct 8 12:19:20.902: Vi4 PPP: Static Bind peer_type[4] *Oct 8 12:19:20.902: AAA/AUTHEN/PPP (00000A92): Pick method list 'default' *Oct 8 12:19:20.902: Vi4 PPP: Sent PAP SENDAUTH Request *Oct 8 12:19:20.902: Vi4 LCP AUTHOR: Process LCP Author Data *Oct 8 12:19:20.902: Vi4 LCP AUTHOR: Process Attr: service-type *Oct 8 12:19:20.902: Vi4 LCP AUTHOR: Process Attr: Framed-Protocol *Oct 8 12:19:20.902: Vi4 LCP AUTHOR: Authorization succeeded *Oct 8 12:19:20.902: Vi4 PPP: Send Message[Static Bind Response] <-------------------------------------------------------------------------> *Oct 8 12:19:20.902: RADIUS/ENCODE(00000A92): check username/password; FAIL *Oct 8 12:19:20.902: RADIUS/ENCODE(00000A92): send packet; FAIL <-------------------------------------------------------------------------> *Oct 8 12:19:20.902: Vi4 Tnl/Sn 23179/2608 L2TP: Session state change from wait-for-service-selection-iccn to established *Oct 8 12:19:20.902: Vi4 Tnl/Sn 23179/2608 L2TP: PW-MGMT: PW peer , vcid 0 *Oct 8 12:19:20.902: Vi4 Tnl/Sn 23179/2608 L2TP: PW-MGMT: Reason [Protocol UP] *Oct 8 12:19:20.902: Vi4 Tnl/Sn 23179/2608 L2TP: PW-MGMT: Local VC DOWN, Remote VC DOWN *Oct 8 12:19:20.902: Vi4 Tnl/Sn 23179/2608 L2TP: PW-MGMT: Provisioned NO, Established YES *Oct 8 12:19:20.902: Vi4 Tnl/Sn 23179/2608 L2TP: PW-MGMT: No change in PW state <-------------------------------------------------------------------------> *Oct 8 12:19:20.902: Vi4 PPP: Received SENDAUTH Response FAIL *Oct 8 12:19:20.902: Vi4 PPP: Sending Acct Event[Down] id[A92] <-------------------------------------------------------------------------> The above lines seem to be the cause of the drama, just not sure what it means. *Oct 8 12:19:20.902: Vi4 Tnl/Sn 23179/2608 L2TP: O SLI to hatika 19184/39100 *Oct 8 12:19:20.902: Vi4 Tnl/Sn 23179/2608 L2TP: Sending send ACCM 0xFFFFFFFF and receive ACCM 0xFFFFFFFF *Oct 8 12:19:20.902: Tnl 23179 L2TP: Control channel retransmit delay set to 1 seconds *Oct 8 12:19:20.906: %LINK-3-UPDOWN: Interface Virtual-Access4, changed state to up *Oct 8 12:19:20.910: Tnl 23179 L2TP: Early authen passing ZLB *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: O SLI to hatika 19184/39100 *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: Sending send ACCM 0xFFFFFFFF and receive ACCM 0xFFFFFFFF *Oct 8 12:19:20.914: Tnl 23179 L2TP: Control channel retransmit delay set to 1 seconds *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: O SLI to hatika 19184/39100 *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: Sending send ACCM 0xFFFFFFFF and receive ACCM 0xFFFFFFFF *Oct 8 12:19:20.914: Vi4 PPP: Clearing AAA Unique Id = A92 *Oct 8 12:19:20.914: Vi4 PPP: Send Message[Disconnect] *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: disconnect (L2X) IETF: 9/nas-error Ascend: 66/VPDN Local PPP Disconnect *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: O CDN to hatika 19184/39100 *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: Destroying session *Oct 8 12:19:20.914: L2X Session DB (Tnl/Sn: 23179/2608): Removed the control session from the session DB *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: Session state change from established to idle *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: PW-MGMT: PW peer , vcid 0 *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: PW-MGMT: Reason [Protocol DOWN] *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: PW-MGMT: Local VC DOWN, Remote VC DOWN *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: PW-MGMT: Provisioned NO, Established NO *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: PW-MGMT: No change in PW state *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: L2X request teardown data plane *Oct 8 12:19:20.914: Vi4 Tnl/Sn 23179/2608 L2TP: Unbinding session from idb *Oct 8 12:19:20.914: Tnl 23179 L2TP: Tunnel state change from established to no-sessions-left *Oct 8 12:19:20.914: Tnl 23179 L2TP: No more sessions in tunnel, shutdown (likely) in 10 seconds *Oct 8 12:19:20.914: L2TP:(Tnl23179:Sn2608)L2X s/w switching session unprovisioned *Oct 8 12:19:20.914: L2X Session DB (Tnl/Sn: 23179/2608): Removed the switching session from the session DB *Oct 8 12:19:20.918: %LINK-3-UPDOWN: Interface Virtual-Access4, changed state to down *Oct 8 12:19:20.918: Vi4 PPP: ppp_sip_switching_cleanup *Oct 8 12:19:20.918: Vi4 PPP: old[Down] event[DeEncap] state[Init] *Oct 8 12:19:20.918: Tnl 23179 L2TP: Early authen passing ZLB *Oct 8 12:19:20.922: Tnl 23179 L2TP: Early authen passing ZLB *Oct 8 12:19:20.922: Tnl 23179 L2TP: Early authen passing ZLB *Oct 8 12:19:21.862: Tnl 23179 L2TP: Perform early message digest validation for StopCCN *Oct 8 12:19:21.862: Tnl 23179 L2TP: Control connection authentication skipped/passed. *Oct 8 12:19:21.862: Tnl 23179 L2TP: Tunnel auth counter, Overall Ignored, now 66 *Oct 8 12:19:21.862: Tnl 23179 L2TP: I StopCCN from hatika tnl 19184 *Oct 8 12:19:21.862: Tnl 23179 L2TP: Tunnel state change from no-sessions-left to shutting-down *Oct 8 12:19:21.862: Tnl 23179 L2TP: Shutdown tunnel *Oct 8 12:19:21.866: Tnl 23179 L2TP: Tunnel state change from shutting-down to idle The radius authentication returns auth accept, the attributes seem fine, but then something goes wrong and the cisco sends an 0x201 followed by a TermReq: Oct 13 19:19:51 hatika pppd[27298]: sent [LCP ConfReq id=0x1 ] Oct 13 19:19:53 hatika pppd[27298]: rcvd [LCP ConfReq id=0x1 ] Oct 13 19:19:53 hatika pppd[27298]: sent [LCP ConfAck id=0x1 ] Oct 13 19:19:54 hatika pppd[27298]: sent [LCP ConfReq id=0x1 ] Oct 13 19:19:54 hatika pppd[27298]: rcvd [LCP ConfAck id=0x1 ] Oct 13 19:19:54 hatika pppd[27298]: sent [LCP EchoReq id=0x0 magic=0xfb9e08cf] Oct 13 19:19:54 hatika pppd[27298]: sent [PAP AuthReq id=0x1 user="user at test.domain.com" password=] Oct 13 19:19:54 hatika pppd[27298]: rcvd [proto=0x201] 00 05 00 Oct 13 19:19:54 hatika pppd[27298]: discarding proto 0x201 in phase 5 Oct 13 19:19:54 hatika pppd[27298]: rcvd [LCP TermReq id=0x2] Oct 13 19:19:54 hatika pppd[27298]: sent [LCP TermAck id=0x2] Here is the config on the box: version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname router ! boot-start-marker boot system disk0:c7200-js-mz.122-31.SB16.bin boot-end-marker ! logging buffered 65535 notifications ! aaa new-model ! ! aaa authentication login default local aaa authentication enable default enable aaa authentication ppp default if-needed group radius aaa authorization network default group radius aaa accounting delay-start vrf default aaa accounting update periodic 240 ! ! ! ! aaa session-id common clock timezone GMT 11 ip subnet-zero ! ! ip name-server ip name-server ! ! ip cef ! ! vpdn enable ! vpdn-group hatika accept-dialin protocol l2tp virtual-template 1 terminate-from hostname hatika lcp renegotiation always no l2tp tunnel authentication ! mpls traffic-eng tunnels mpls label protocol ldp call rsvp-sync ! ! ! ! ! no file verify auto username [.....] username [.....] ! ! ! interface Loopback1 ip address 255.255.255.255 ! interface FastEthernet0/0 ip address 255.255.255.192 speed auto duplex auto ! interface Virtual-Template1 description LNS ip unnumbered FastEthernet0/0 peer default ip address pool test ppp authentication pap ! router ospf 1 log-adjacency-changes area 0.0.0.0 authentication redistribute connected subnets redistribute static subnets network 0.0.0.63 area 0.0.0.0 ! ip local pool test 10.0.9.1 10.0.9.254 ip classless ip route 0.0.0.0 0.0.0.0 ! no ip http server ! ! no cdp run ! radius-server host auth-port 1812 acct-port 1813 key ! control-plane ! ! ! dial-peer cor custom ! ! ! ! gatekeeper shutdown ! ! line con 0 stopbits 1 line aux 0 stopbits 1 line vty 0 4 ! end Any assistance appreciated. Regards, Pat From jckdaniels12 at gmail.com Tue Oct 13 08:03:44 2009 From: jckdaniels12 at gmail.com (jack daniels) Date: Tue, 13 Oct 2009 17:33:44 +0530 Subject: [c-nsp] best practices switches/Router In-Reply-To: <4AD42A1B.9040106@gmx.de> References: <8bb137f40910122342u4842c6c5s8c7b9830be7e81f1@mail.gmail.com> <4AD42A1B.9040106@gmx.de> Message-ID: <8bb137f40910130503g5f23473en5a3a22e5b8ccb1d6@mail.gmail.com> Hi Garry, my aim is to do review of the configs of ROUTERS and Switches in my network. As a review , need to track down the best practices that should be configured and are not there in my network. Regards On Tue, Oct 13, 2009 at 12:49 PM, Garry wrote: > jack daniels wrote: > > Hi , > > > > I'm looking for doc which suggests best practices for network ( ROUTERS > and > > SWITCHES ) > > Please help me with doc link if any there. > > > It might be helpful if you could point out what exactly you are > interested in, or what topics you require ... otherwise your request > would be overly broad and a good place to start might be > http://cisco.com ... ;) > From bacon at walleyesoftware.com Tue Oct 13 08:10:24 2009 From: bacon at walleyesoftware.com (Jeff Bacon) Date: Tue, 13 Oct 2009 07:10:24 -0500 Subject: [c-nsp] 3560 buffering Message-ID: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> I use a number of 3560Gs as distribution switches in my co-lo farm, with 4G uplinks to 4948s. The load is fin-svcs, and can be quite bursty, tends to be a lot of small packets, but with a mix of larger stuff and standard file transfer etc. I've been seeing a number of output drops on the etherchannel ports to the 4948s, as well as to the servers themselves. What's an output drop mean, in a 3560 context? Queue to the host is full? Host interface already maxed out, "there was a packet on the wire being transmitted to the host, so sorry I'll drop the packet"? Or can it be an ingress/switching decision of some sort? How deep is the individual buffer/ring on a gig PHY? Or is it buffered per-ASIC? (Doesn't seem to be) Is there a way to tell the 3560 to buffer more aggressively? The 4948s don't really have any of these problems, and when I moved some of the hosts to the 4948s which were showing output drops (to the server from the switch), the problems went away, so either the 4948 buffers better, transmits better, or just doesn't log as well. (Yes, the 4948 is a better switch. But it's not like the 3560s are oversubscribed either - if they're doing 1Mpps at peak it'd be a miracle. It's a finsvcs load but it's not THAT intense, just bursty.) Then there's this mysterious output from "sh cont eth port-asic stat" wherein I get a number (not huge) of "RxBuffer Drop DestIndex Cou". Huh? Not documented anywhere; trying to pull info out of TAC but it's a slow process. Thanks, -bacon From swmike at swm.pp.se Tue Oct 13 08:21:44 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 13 Oct 2009 14:21:44 +0200 (CEST) Subject: [c-nsp] best practices switches/Router In-Reply-To: <8bb137f40910130503g5f23473en5a3a22e5b8ccb1d6@mail.gmail.com> References: <8bb137f40910122342u4842c6c5s8c7b9830be7e81f1@mail.gmail.com> <4AD42A1B.9040106@gmx.de> <8bb137f40910130503g5f23473en5a3a22e5b8ccb1d6@mail.gmail.com> Message-ID: On Tue, 13 Oct 2009, jack daniels wrote: > my aim is to do review of the configs of ROUTERS and Switches in my > network. As a review , need to track down the best practices that should > be configured and are not there in my network. Start with "ISP essentials", it's old but still valid. (google should find the original PDF for you if you look a bit). -- Mikael Abrahamsson email: swmike at swm.pp.se From synack at live.com Tue Oct 13 08:23:47 2009 From: synack at live.com (Darin Herteen) Date: Tue, 13 Oct 2009 07:23:47 -0500 Subject: [c-nsp] best practices switches/Router Message-ID: Well from a security standpoint, this link might be useful: http://www.nsa.gov/ia/guidance/security_configuration_guides/cisco_router_guides.shtml Darin Herteen Hi Garry, my aim is to do review of the configs of ROUTERS and Switches in my network. As a review , need to track down the best practices that should be configured and are not there in my network. Regards On Tue, Oct 13, 2009 at 12:49 PM, Garry wrote: > jack daniels wrote: > > Hi , > > > > I'm looking for doc which suggests best practices for network ( ROUTERS > and > > SWITCHES ) > > Please help me with doc link if any there. > > > It might be helpful if you could point out what exactly you are > interested in, or what topics you require ... otherwise your request > would be overly broad and a good place to start might be > http://cisco.com ... ;) > Hi Garry, my aim is to do review of the configs of ROUTERS and Switches in my network. As a review , need to track down the best practices that should be configured and are not there in my network. Regards On Tue, Oct 13, 2009 at 12:49 PM, Garry wrote: > jack daniels wrote: > > Hi , > > > > I'm looking for doc which suggests best practices for network ( ROUTERS > and > > SWITCHES ) > > Please help me with doc link if any there. > > > It might be helpful if you could point out what exactly you are > interested in, or what topics you require ... otherwise your request > would be overly broad and a good place to start might be > http://cisco.com ... ;) > _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/171222986/direct/01/ From linux.yahoo at gmail.com Tue Oct 13 08:29:16 2009 From: linux.yahoo at gmail.com (Manu Chao) Date: Tue, 13 Oct 2009 14:29:16 +0200 Subject: [c-nsp] ibgp TTL In-Reply-To: References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> Message-ID: <7100ed370910130529x38f68ae7p58c1476a7f14228d@mail.gmail.com> timers have nothing to do with TTL ;) On Tue, Oct 13, 2009 at 1:26 PM, Muhammad Jawwad Paracha wrote: > neighbour timer will do the trick for you. > > On Tue, Oct 13, 2009 at 3:52 PM, Manu Chao wrote: > >> For a very specific design, i need to limit TTL value in ibgp-multihop. >> >> Is it possible to limit iBGP TTL like we do with ebgp-multihop ttl >> command? >> >> Any input appreciated. >> >> Manu >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp at puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > > From nilesh5555in at yahoo.com Tue Oct 13 07:58:48 2009 From: nilesh5555in at yahoo.com (Nilesh Sawant) Date: Tue, 13 Oct 2009 04:58:48 -0700 (PDT) Subject: [c-nsp] MPLS QoS Query Message-ID: <469782.81058.qm@web52107.mail.re2.yahoo.com> Hi I have to configure the qos on the Cisco 7606S given the priority for the Voice traffic with 70% . I am using Cisco 7606S with SUP 32-8GE-3B Please find below the config for the same , can you please comment on the below configurations ? is it correct not need to change any parameter ? interface-range gig 6/1-8 mls qos trust ip-prec ** wrr-queue cos-map 1 1 0 ** wrr-queue cos-map 2 1 3 2 1 wrr-queue cos-map 3 1 4 6 7 ** priority-queue cos map 1 5 wrr-queue bandwidth 1 1 4 priority-queue queue-limit 21 wrr-queue queue-limit 20 20 40 wrr-queue threshold 1 50 50 50 50 50 50 50 50 wrr-queue threshold 2 70 70 70 70 70 70 70 70 ** wrr-queue threshold 3 100 100 100 100 100 100 100 100 wrr-queue random-detect min-threshold 1 30 30 30 30 30 30 30 30 wrr-queue random-detect max-threshold 1 50 50 50 50 50 50 50 50 wrr-queue random-detect min-threshold 2 50 50 50 50 50 50 50 50 wrr-queue random-detect max-threshold 2 70 70 70 70 70 70 70 70 wrr-queue random-detect min-threshold 3 80 80 80 80 80 80 80 80 ** wrr-queue random-detect max-threshold 3 100 100 100 100 100 100 100 end I have configured the above config on one the Gig interface but few lines are missing in sh run of said interface eventhough those are accepted in config which are marked "*" Please suggest on same ? interface GigabitEthernet6/8 no ip address shutdown wrr-queue bandwidth 1 1 4 priority-queue queue-limit 21 wrr-queue queue-limit 20 20 40 wrr-queue threshold 1 50 50 50 50 50 50 50 50 wrr-queue threshold 2 70 70 70 70 70 70 70 70 wrr-queue random-detect min-threshold 1 30 30 30 30 30 30 30 30 wrr-queue random-detect min-threshold 2 50 50 50 50 50 50 50 50 wrr-queue random-detect min-threshold 3 80 80 80 80 80 80 80 80 wrr-queue random-detect max-threshold 1 50 50 50 50 50 50 50 50 wrr-queue random-detect max-threshold 2 70 70 70 70 70 70 70 70 wrr-queue cos-map 2 1 1 2 3 wrr-queue cos-map 3 1 4 6 7 mls qos trust ip-precedence end Thank in Advance Nilesh From david.freedman at uk.clara.net Tue Oct 13 09:38:13 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 13 Oct 2009 14:38:13 +0100 Subject: [c-nsp] ibgp TTL In-Reply-To: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> Message-ID: <4AD482C5.40401@uk.clara.net> Can I just ask why you would want to do this? unless you are using passive/auto-peer, you need to have neighbors configured both sides to form an adjacency, the transport addresses also, surprisingly, need to be reachable :) If you are indeed doing passive/autopeer and have a /good/ reason for doing this, how about using ACLs or at the very least MD5 passwords. Dave. From david.freedman at uk.clara.net Tue Oct 13 09:38:13 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 13 Oct 2009 14:38:13 +0100 Subject: [c-nsp] ibgp TTL In-Reply-To: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> Message-ID: <4AD482C5.40401@uk.clara.net> Can I just ask why you would want to do this? unless you are using passive/auto-peer, you need to have neighbors configured both sides to form an adjacency, the transport addresses also, surprisingly, need to be reachable :) If you are indeed doing passive/autopeer and have a /good/ reason for doing this, how about using ACLs or at the very least MD5 passwords. Dave. From sony.scaria at gmail.com Tue Oct 13 10:08:50 2009 From: sony.scaria at gmail.com (Sony Scaria) Date: Tue, 13 Oct 2009 19:38:50 +0530 Subject: [c-nsp] best practices switches/Router In-Reply-To: <8bb137f40910130503g5f23473en5a3a22e5b8ccb1d6@mail.gmail.com> References: <8bb137f40910122342u4842c6c5s8c7b9830be7e81f1@mail.gmail.com> <4AD42A1B.9040106@gmx.de> <8bb137f40910130503g5f23473en5a3a22e5b8ccb1d6@mail.gmail.com> Message-ID: <4ad489fb.0c58560a.62b9.0899@mx.google.com> Hi, Checkout this link, it might be helpful http://www.nsa.gov/ia/guidance/security_configuration_guides/cisco_router_gu ides.shtml SONY -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of jack daniels Sent: 13 October 2009 17:34 To: Garry Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] best practices switches/Router Hi Garry, my aim is to do review of the configs of ROUTERS and Switches in my network. As a review , need to track down the best practices that should be configured and are not there in my network. Regards On Tue, Oct 13, 2009 at 12:49 PM, Garry wrote: > jack daniels wrote: > > Hi , > > > > I'm looking for doc which suggests best practices for network ( ROUTERS > and > > SWITCHES ) > > Please help me with doc link if any there. > > > It might be helpful if you could point out what exactly you are > interested in, or what topics you require ... otherwise your request > would be overly broad and a good place to start might be > http://cisco.com ... ;) > _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From clucas at infosat.tm.fr Tue Oct 13 09:04:48 2009 From: clucas at infosat.tm.fr (Christophe Lucas) Date: Tue, 13 Oct 2009 15:04:48 +0200 Subject: [c-nsp] L2TP LNS issue In-Reply-To: <20091013110031.GA15189@amused.net> References: <20091013110031.GA15189@amused.net> Message-ID: <20091013130448.GW22413@mcom.fr> Patrick Cole (z at amused.net) wrote: > version 12.2 > service timestamps debug datetime msec > service timestamps log datetime msec > no service password-encryption > ! > hostname router > ! [...] > interface Virtual-Template1 > description LNS > ip unnumbered FastEthernet0/0 > peer default ip address pool test > ppp authentication pap > ! > router ospf 1 > log-adjacency-changes > area 0.0.0.0 authentication > redistribute connected subnets > redistribute static subnets > network 0.0.0.63 area 0.0.0.0 > ! > ip local pool test 10.0.9.1 10.0.9.254 > ip classless > ip route 0.0.0.0 0.0.0.0 > ! Hi, I have quickly read your mail. Sorry if it is not answer to your question... I have made a lab on this kind of network. My LAC et LNS was Cisco routers. I have long searched why my PPP is not established on my LNS and 'ppp mtu adaptive' under 'Virtual Template 1' was my answer. I hope it can solve your problem. Regards, -- Christophe Lucas | Phone: +33 (0)9.74.76.25.95 Network Engineer | Fax: +33 (0)2.35.63.48.22 INFOSAT ICPS SA | GSM: +33 (0)6.14.63.55.15 132 rue Kennedy | email: c.lucas at infosat.tm.fr 76140 Petit-Quevilly, France | URL: http://www.infosat.tm.fr From amsoares at netcabo.pt Tue Oct 13 11:31:16 2009 From: amsoares at netcabo.pt (Antonio Soares) Date: Tue, 13 Oct 2009 16:31:16 +0100 Subject: [c-nsp] Cisco 12416 Power Management Message-ID: Group, I'm trying to figure out why i have this output: ++++++++++++++++++++++++++++++++++++++++++++++ 12k2>sh env power_supply Failsafe power system Slot # 48V AMP_48 (Volt) (Amp) 27 PEM1 53 10 Failsafe-PEM= Failsafe PS PEM2 No module detected PEM3 No module detected PEM4 No module detected 12k2> ++++++++++++++++++++++++++++++++++++++++++++++ When i have a similar 12k showing this: ++++++++++++++++++++++++++++++++++++++++++++++ 12k1>sh env power_supply DC Power Supplies Slot # 48V AMP_48 (Volt) (Amp) 27 PEM1 52 4 PWR-GSR16-DC= Standard DC PS PEM2 52 7 PWR-GSR16-DC= Standard DC PS PEM3 54 16 PWR-GSR16-DC= Standard DC PS PEM4 55 20 PWR-GSR16-DC= Standard DC PS 12k1> ++++++++++++++++++++++++++++++++++++++++++++++ Both 12k's have 4 2000W DC Power Supplies. The only thing i was able to verify is that in 12k2, Zone 2 Power Consumption is above 2000W. Could this lead to the apparently abnormal situation above ? Thanks. Regards, Antonio Soares, CCIE #18473 (R&S) amsoares at netcabo.pt From peter at rathlev.dk Tue Oct 13 11:59:55 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Tue, 13 Oct 2009 17:59:55 +0200 Subject: [c-nsp] 3560 buffering In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> Message-ID: <1255449595.3217.40.camel@abehat.net.rm.dk> On Tue, 2009-10-13 at 07:10 -0500, Jeff Bacon wrote: > I use a number of 3560Gs as distribution switches in my co-lo farm, > with 4G uplinks to 4948s. The load is fin-svcs, and can be quite > bursty, tends to be a lot of small packets, but with a mix of larger > stuff and standard file transfer etc. > > I've been seeing a number of output drops on the etherchannel ports to > the 4948s, as well as to the servers themselves. > > What's an output drop mean, in a 3560 context? Queue to the host is > full? Host interface already maxed out, "there was a packet on the > wire being transmitted to the host, so sorry I'll drop the packet"? Or > can it be an ingress/switching decision of some sort? Given a new enough IOS (at least 12.2(50)SE works) the "show interface counters errors" should name the specific cause. A guess might be "OutDiscards", which are output buffer overruns. > How deep is the individual buffer/ring on a gig PHY? Or is it buffered > per-ASIC? (Doesn't seem to be) AFAIK the SRR platforms (3560/3750) have a somewhat special way of buffering. My guess is that the TX ring is relatively small and the buffering happens primarily in the SRR logic. This is configured via the "mls qos" global config commands. http://www.cisco.com/en/US/docs/switches/lan/catalyst3750e_3560e/software/release/12.2_50_se/configuration/guide/swqos.html http://tinyurl.com/yg76fm5 > Is there a way to tell the 3560 to buffer more aggressively? There might be. If I remember correctly, the "no QoS enabled" defaults from 12.2(25)SEE and earlier and 12.2(46)SE and later are somewhat better than the version in between. We had many problems with too aggressive drops when moving traffic coming in a Gigabit link and out a FastEthernet link. I have attached what should be a minimal configuration enabling QoS and adjusting the output buffer sizes. This seemed to help in our lab tests, making the switch behave almost like a 3550. -- Peter -------------- next part -------------- ! Enable QoS mls qos ! ! Only output queue-set 1, queue 2 is used. Adjust all thresholds to ! 400% of default. (This is AFAIK the maximum even though the parser ! accepts up to 3200%.) mls qos queue-set output 1 threshold 2 400 400 100 400 ! ! Assign all buffers to queue 2 (also used by the CPU) mls qos queue-set output 1 buffers 0 100 0 0 ! ! Map all output traffic to queue 2, threshold 3 ! CoS-map mls qos srr-queue output cos-map queue 2 threshold 3 0 1 2 3 4 5 6 7 ! DSCP-map mls qos srr-queue output dscp-map queue 2 threshold 3 0 1 2 3 4 5 6 7 mls qos srr-queue output dscp-map queue 2 threshold 3 8 9 10 11 12 13 14 15 mls qos srr-queue output dscp-map queue 2 threshold 3 16 17 18 19 20 21 22 23 mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31 mls qos srr-queue output dscp-map queue 2 threshold 3 32 33 34 35 36 37 38 39 mls qos srr-queue output dscp-map queue 2 threshold 3 40 41 42 43 44 45 46 47 mls qos srr-queue output dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55 mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63 ! ! By default all interfaces are in queue-set 1. If not, move them there: ! ! interface range Fa0/1 - 24 , Gi0/1 - 2 ! queue-set 1 ! exit ! ! ! ! By default the switch will zeroize DSCP with QoS enabled. If needed, one ! can configure trust, e.g. DSCP trust: ! ! interface range Fa0/1 - 24 , Gi0/1 - 2 ! mls qos trust dscp ! exit ! ! ! From bacon at walleyesoftware.com Tue Oct 13 12:45:25 2009 From: bacon at walleyesoftware.com (Jeff Bacon) Date: Tue, 13 Oct 2009 11:45:25 -0500 Subject: [c-nsp] 3560 buffering In-Reply-To: <1255449595.3217.40.camel@abehat.net.rm.dk> References: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> <1255449595.3217.40.camel@abehat.net.rm.dk> Message-ID: <5A69C25361FED34F83ABF05F50475245072BC1D5@wally.walleyetrading.net> Gads. Show int count error. I can't believe I missed that. I just can't. *whacks head* I am (unfortunately?) running 12.2(44)SE, thus clearly shooting myself in the foot. Sigh. I've wondered about upgrading... and was planning to try QoS to prioritize the trading system traffic at least (another way around the buffering issue) - and just to turn on mls qos, so one could look at the buffering, since you need the qos commands to look and you don't have them when qos is off. Thanks!! > Given a new enough IOS (at least 12.2(50)SE works) the "show interface > counters errors" should name the specific cause. A guess might be > "OutDiscards", which are output buffer overruns. > > > Is there a way to tell the 3560 to buffer more aggressively? > > There might be. If I remember correctly, the "no QoS enabled" defaults > from 12.2(25)SEE and earlier and 12.2(46)SE and later are somewhat > better than the version in between. We had many problems with too > aggressive drops when moving traffic coming in a Gigabit link and out a > FastEthernet link. > > I have attached what should be a minimal configuration enabling QoS and > adjusting the output buffer sizes. This seemed to help in our lab > tests, making the switch behave almost like a 3550. > > -- > Peter From peter at rathlev.dk Tue Oct 13 12:56:47 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Tue, 13 Oct 2009 18:56:47 +0200 Subject: [c-nsp] 3560 buffering In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC1D5@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> <1255449595.3217.40.camel@abehat.net.rm.dk> <5A69C25361FED34F83ABF05F50475245072BC1D5@wally.walleyetrading.net> Message-ID: <1255453007.3217.43.camel@abehat.net.rm.dk> On Tue, 2009-10-13 at 11:45 -0500, Jeff Bacon wrote: > Gads. Show int count error. I can't believe I missed that. I just > can't. *whacks head* > > I am (unfortunately?) running 12.2(44)SE, thus clearly shooting myself > in the foot. Sigh. I've wondered about upgrading... and was planning > to try QoS to prioritize the trading system traffic at least (another > way around the buffering issue) - and just to turn on mls qos, so one > could look at the buffering, since you need the qos commands to look > and you don't have them when qos is off. You can see the specific drops with "show platform port-asic stats drop GiX/Y", which also works when "mls qos" isn't enabled. I'm not sure how 12.2(44)SE works, but just turning on QoS (or even worse: using auto-qos) might make things much worse than they are without. As usual. :-) -- Peter From giesen at snickers.org Tue Oct 13 13:12:38 2009 From: giesen at snickers.org (Gary T. Giesen) Date: Tue, 13 Oct 2009 13:12:38 -0400 Subject: [c-nsp] cisco 7206 VXR router In-Reply-To: <4AC26B3F.80006@eltopia.com> References: <8bb137f40909290446y66c3eb67qe98e5960a7c8a5bd@mail.gmail.com> <4AC1FEA7.8050301@thingy.com> <8bb137f40909290613k1f82f19fs3649cca9785098c7@mail.gmail.com> <4AC23EB2.7080905@rollernet.us> <020501ca4132$5b3bdae0$2408120a@am.thmulti.com> <4AC26287.5080906@west.net> <4AC26B3F.80006@eltopia.com> Message-ID: <9a9d0c6a0910131012h79b80cfbye7365eb4da6d7acc@mail.gmail.com> It's not only "C" routers. The J-series have 4x Gig interfaces, and that box definitely can't route 4 Gig of traffic. Though the issue is definitely more prevalent on the "C" side. The biggest commonality is that they are software routers. Although even on hardware routers, you'll run into things like backplane oversubscription... GG On Tue, Sep 29, 2009 at 4:17 PM, Aaron Seelye wrote: > Agreed, but I think he was pointing out the fact that it's not "routers" > that have this problem, it's c-routers :). > > -Aaron > > Jay Hennigan wrote: >> >> Scott Granados wrote: >> >>> Better worded, a common issue with vendor C is that they have processors >>> that the interfaces can't keep up with. ?Other vendors including one that >>> starts with a J have fewer issues in this area.;) >> >> I think you have it bass-ackwards. ?There are interfaces that the >> processors can't keep up with. >> >> -- >> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net >> Impulse Internet Service ?- ?http://www.impulse.net/ >> Your local telephone and internet company - 805 884-6323 - WB6RDV >> _______________________________________________ >> cisco-nsp mailing list ?cisco-nsp at puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >> >> ------------------------------------------------------------------------ >> >> >> Internal Virus Database is out of date. >> Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: >> 270.13.111/2386 - Release Date: 09/21/09 05:51:00 >> > _______________________________________________ > cisco-nsp mailing list ?cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > From giesen at snickers.org Tue Oct 13 13:19:48 2009 From: giesen at snickers.org (Gary T. Giesen) Date: Tue, 13 Oct 2009 13:19:48 -0400 Subject: [c-nsp] Hardware for 'managed firewall' In-Reply-To: References: <4AC271C6.1090508@reachone.com> Message-ID: <9a9d0c6a0910131019s67639c9ej1e40ecacd4905c12@mail.gmail.com> We use ASA's in context mode plus some sort of IOS box (28xx, 38xx) with VRF for both Client VPN and LAN-to-LAN VPN. Works decently... GG On Tue, Sep 29, 2009 at 11:34 PM, christian wrote: > netscreen management (cli/NSM) is one of the worst i've ever encountered > > as far as the topic at hand - i agree w/ Justin's comments - what i've > done in past is FWSM's in the chassis and a pair of asa's for vpn > termination > > On Tue, Sep 29, 2009 at 8:23 PM, Dave Weis wrote: >> >> On Wed, 30 Sep 2009, David Hughes wrote: >>> >>> On 30/09/2009, at 7:08 AM, Dave Weis wrote: >>>> >>>> On Tue, 29 Sep 2009, Christopher Hunt wrote: >>>>> >>>>> As I painfully discovered, the Cisco ASA in Multiple Context mode does >>>>> not support IPSEC VPN clients nor L2TP3 tunnels >>>> >>>> That's a pretty big omission! Any ETA to add that capability? >>> >>> Yeah, they've never supported VPN in multi-context mode. ?Major pain. ?And >>> if you are a dense hosting provider the 50 context limit (and limited >>> performance) of a 5540 for example doesn't work too well. ?These issues made >>> us look around again and J-Vendor's boxes are making the ASA's look a bit >>> ordinary. >> >> I never enjoyed working on the netscreens. I suppose if each virtual >> firewall customer could get the same awkward web interface for self >> provisioning it could be made to work. >> >> -- >> Dave Weis >> djweis at internetsolver.com >> http://www.internetsolver.com/ >> >> _______________________________________________ >> cisco-nsp mailing list ?cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > From kgraham at industrial-marshmallow.com Tue Oct 13 13:37:13 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Tue, 13 Oct 2009 10:37:13 -0700 (PDT) Subject: [c-nsp] best practices switches/Router In-Reply-To: References: Message-ID: <62034.2521.qm@web508.biz.mail.mud.yahoo.com> > my aim is to do review of the configs of ROUTERS and Switches in my network. > As a review , need to track down the best practices that should be > configured and are not there in my network. Was: http://www.google.com/search?q=site%3Acisco.com+best+practices ...not sufficient? >From a security standpoint, in addition to the NSA SNAC publications already mentioned, Cisco's Network Security Baseline is very much worth reading: https://www.cisco.com/en/US/docs/solutions/Enterprise/Security/Baseline_Security/securebasebook.html From gsgranados at comcast.net Tue Oct 13 13:55:18 2009 From: gsgranados at comcast.net (Scott Granados) Date: Tue, 13 Oct 2009 10:55:18 -0700 Subject: [c-nsp] best practices switches/Router References: <62034.2521.qm@web508.biz.mail.mud.yahoo.com> Message-ID: <028801ca4c2e$5a4c8010$2408120a@am.thmulti.com> NSA security policy, hmmmm, does that involve a lot of port mirroring and copying of data to non existant trunks. (shshshshshsh) Or use of encryption standards that are almost secure.;) Call me crazy (you wouldn't be the first) but I have to say I'm always skeptical when someone says "Hi, we're from the Government and we're here to help!" ----- Original Message ----- From: "Kevin Graham" To: ; Sent: Tuesday, October 13, 2009 10:37 AM Subject: Re: [c-nsp] best practices switches/Router > >> my aim is to do review of the configs of ROUTERS and Switches in my >> network. >> As a review , need to track down the best practices that should be >> configured and are not there in my network. > > Was: > > http://www.google.com/search?q=site%3Acisco.com+best+practices > > ...not sufficient? > >>From a security standpoint, in addition to the NSA SNAC publications >>already > mentioned, Cisco's Network Security Baseline is very much worth reading: > > > https://www.cisco.com/en/US/docs/solutions/Enterprise/Security/Baseline_Security/securebasebook.html > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From long.kenny at gmail.com Tue Oct 13 15:26:02 2009 From: long.kenny at gmail.com (Kenny Long) Date: Tue, 13 Oct 2009 13:26:02 -0600 Subject: [c-nsp] Cisco ASA running 8.0(4) seems to listen on a ton of TCP ports Message-ID: Has anyone else ran a port-scan against a Cisco ASA and gotten back a bunch of unexpected, listening ports? This Nmap below shows that from port 1 to 80, 3,5,6,8,9,10 and others arent listening, but how come all of these are? This nmap was ran across a L2L VPN with no filtering. user at laptop:~$ nmap 10.223.4.5 -sT -p 1-80 Starting Nmap 4.62 ( http://nmap.org ) at 2009-10-13 13:23 MDT Interesting ports on 10.28.4.5: Not shown: 34 filtered ports PORT STATE SERVICE 1/tcp open tcpmux 2/tcp open compressnet 4/tcp open unknown 7/tcp open echo 11/tcp open systat 12/tcp open unknown 13/tcp open daytime 14/tcp open unknown 19/tcp open chargen 20/tcp open ftp-data 21/tcp open ftp 22/tcp open ssh 23/tcp open telnet 24/tcp open priv-mail 25/tcp open smtp 26/tcp open unknown 31/tcp open msg-auth 34/tcp open unknown 35/tcp open priv-print 36/tcp open unknown 40/tcp open unknown 43/tcp open whois 45/tcp open mpm 47/tcp open ni-ftp 49/tcp open tacacs 52/tcp open xns-time 53/tcp open domain 55/tcp open isi-gl 56/tcp open xns-auth 57/tcp open priv-term 59/tcp open priv-file 62/tcp open acas 63/tcp open via-ftp 64/tcp open covia 65/tcp open tacacs-ds 67/tcp open dhcps 69/tcp open tftp 70/tcp open gopher 71/tcp open netrjs-1 72/tcp open netrjs-2 73/tcp open netrjs-3 74/tcp open netrjs-4 75/tcp open priv-dial 78/tcp open vettcp 79/tcp open finger 80/tcp open http Kenny Long From jeff-kell at utc.edu Tue Oct 13 15:44:06 2009 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 13 Oct 2009 15:44:06 -0400 Subject: [c-nsp] Cisco ASA running 8.0(4) seems to listen on a ton of TCP ports In-Reply-To: References: Message-ID: <4AD4D886.10904@utc.edu> Kenny Long wrote: > Has anyone else ran a port-scan against a Cisco ASA and gotten back a bunch > of unexpected, listening ports? This Nmap below shows that from port 1 to > 80, 3,5,6,8,9,10 and others arent listening, but how come all of these are? Is that on the management IP of the ASA? Or an IP involved in NAT? My first guess would be tcp intercept... Jeff From shinejoseph at dodo.com.au Tue Oct 13 15:46:47 2009 From: shinejoseph at dodo.com.au (Shine Joseph) Date: Wed, 14 Oct 2009 03:46:47 +0800 Subject: [c-nsp] mGRE with VRF-Lite References: <3c6ab8da0910112210o27923bb3x5c1ed0059e0ae710@mail.gmail.com> <3c6ab8da0910112219u3d6f8835r3892220ad7dc92c9@mail.gmail.com> <790E2A460226464A84253AA77140BD34@au.didata.local> <3c6ab8da0910121833s57c09bc5w3c38d4d96bd466e0@mail.gmail.com> Message-ID: ----- Original Message ----- From: Brad Holding To: Shine Joseph Sent: Tuesday, October 13, 2009 9:33 AM Subject: Re: [c-nsp] mGRE with VRF-Lite So when you added the 'ip nhrp map multicast 172.16.123.xxx' under the tunnel the EIGRP neighbours would just flap? On Tue, Oct 13, 2009 at 4:55 AM, Shine Joseph wrote: Hi, Thanks for your responses and pointers. the vrf names in the tunnel and routing process is just an editing error. I can't get the multicasting working for the mGRE, it works well for the p2p GRE. When multicasting is used for EIGRP, the neibghors come up, but flaps and no routes are being exchanged. The Q counter is not zero. The only way, I got the mGRE worked is using neighbor statements in the routing process. See below my working config for two VRFs. Let me know if you have any further thoughts on this. Thanks Shine ------------------------------------------------------------ Router 1 ========= ip vrf data rd 100:110 ! ip vrf voice rd 100:111 ! interface Tunnel110 ip vrf forwarding data ip address 10.40.60.1 255.255.255.0 no ip redirects ip nhrp map 10.40.60.2 172.16.123.2 ip nhrp map 10.40.60.3 172.16.123.3 ip nhrp network-id 110 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 ! interface Tunnel111 ip vrf forwarding voice ip address 10.40.61.1 255.255.255.0 no ip redirects ip nhrp map 10.40.61.2 172.16.123.2 ip nhrp map 10.40.61.3 172.16.123.3 ip nhrp network-id 111 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 111 ! router eigrp 100 no auto-summary ! address-family ipv4 vrf voice network 10.40.61.1 0.0.0.0 no auto-summary autonomous-system 100 neighbor 10.40.61.2 Tunnel111 neighbor 10.40.61.3 Tunnel111 exit-address-family ! address-family ipv4 vrf data network 1.1.1.1 0.0.0.0 network 10.40.60.1 0.0.0.0 no auto-summary autonomous-system 100 neighbor 10.40.60.3 Tunnel110 neighbor 10.40.60.2 Tunnel110 exit-address-family ! Router 2 ========= ip vrf data rd 100:110 ! ip vrf voice rd 100:111 ! interface Tunnel110 ip vrf forwarding data ip address 10.40.60.2 255.255.255.0 no ip redirects ip nhrp map 10.40.60.1 172.16.123.1 ip nhrp network-id 110 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 ! interface Tunnel111 ip vrf forwarding voice ip address 10.40.61.2 255.255.255.0 no ip redirects ip nhrp map 10.40.61.1 172.16.123.1 ip nhrp network-id 111 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 111 ! router eigrp 100 no auto-summary ! address-family ipv4 vrf voice network 2.2.2.2 0.0.0.0 network 10.40.61.2 0.0.0.0 no auto-summary autonomous-system 100 neighbor 10.40.61.1 Tunnel111 exit-address-family ! address-family ipv4 vrf data network 10.40.60.2 0.0.0.0 no auto-summary autonomous-system 100 neighbor 10.40.60.1 Tunnel110 exit-address-family Router 3 ========= ip vrf data rd 100:110 ! ip vrf voice rd 100:111 ! interface Tunnel110 ip vrf forwarding data ip address 10.40.60.3 255.255.255.0 no ip redirects ip nhrp map 10.40.60.1 172.16.123.1 ip nhrp network-id 110 ip nhrp cache non-authoritative tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 ! interface Tunnel111 ip vrf forwarding voice ip address 10.40.61.3 255.255.255.0 no ip redirects ip nhrp map 10.40.61.1 172.16.123.1 ip nhrp network-id 111 ip nhrp cache non-authoritative tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 111 ! router eigrp 100 no auto-summary ! address-family ipv4 vrf voice network 10.40.61.3 0.0.0.0 no auto-summary autonomous-system 100 neighbor 10.40.61.1 Tunnel111 exit-address-family ! address-family ipv4 vrf data network 10.40.60.3 0.0.0.0 no auto-summary autonomous-system 100 neighbor 10.40.60.1 Tunnel110 exit-address-family ! ----- Original Message ----- From: Brad Holding To: shinejoseph at dodo.com.au Sent: Monday, October 12, 2009 1:19 PM Subject: Fwd: [c-nsp] mGRE with VRF-Lite Also, the VRF names under the interfaces and the routing processes are not the same. ie. interface Tunnel110 ip vrf forwarding Data router eigrp 100 no auto-summary ! address-family ipv4 vrf Gorgon_Data Because you don't appear to have a NHRP hub, dynamic multicast mapping may not work. If it isn't, try mapping multicast traffic to each neighbour: ip nhrp map multicast 172.16.123.xxx On Mon, Oct 12, 2009 at 1:10 PM, Brad Holding wrote: Hey Mate, You need to map multicast traffic dynamically under NHRP on the tunnel interface: ip nhrp map multicast dynamic This will allow the EIGRP hello's to be tunneled to the endpoints and the neighbour relationships will then establish. Brad On Mon, Oct 12, 2009 at 3:20 AM, Shine Joseph wrote: Hi, I am working on a solution to run mGRE for VRF-Lite. This is my situation: there are 5 sites currently connected by MPLS IPWAn provided by ISP. I want to run VRF-Lite throughout the network for path isolation between various VLANs. VRF-Lite works great within the site (Vrf-Lite end-to-end is being deployed). In order for to cross the IPWAN, mutipoint-GRE tunnels are being looked at. tunnels are getting created, but when advertised in the VRF routing process, neighbor is not being esablished. If I use the potint to point tunnel, neighbor relationship is estanblished, working as expected. The issue will be I need to create over 50 tunnels to achieve the expected results. Can someone help me, if the mGRE with VRF-Lite is a feasible solution? Thanks in advance Shine ---------------------------- Following is a snippet of my configuration: Router 1 ======== interface Tunnel110 ip vrf forwarding Data ip address 10.40.61.1 255.255.255.224 no ip redirects ip nhrp map 10.40.61.2 172.16.123.2 ip nhrp map 10.40.61.3 172.16.123.3 ip nhrp network-id 110 ip nhrp cache non-authoritative tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 router eigrp 100 no auto-summary ! address-family ipv4 vrf Gorgon_Data network 10.40.61.1 0.0.0.0 no auto-summary autonomous-system 100 exit-address-family ! Router 2 ======== interface Tunnel110 ip vrf forwarding Data ip address 10.40.61.2 255.255.255.224 no ip redirects ip nhrp map 10.40.61.1 172.16.123.1 ip nhrp map 10.40.61.3 172.16.123.3 ip nhrp network-id 110 ip nhrp cache non-authoritative tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 router eigrp 100 no auto-summary ! address-family ipv4 vrf Gorgon_Data network 10.40.61.2 0.0.0.0 no auto-summary autonomous-system 100 exit-address-family ! Router 3 ======== interface Tunnel110 ip vrf forwarding Data ip address 10.40.61.3 255.255.255.224 no ip redirects ip nhrp map 10.40.61.1 172.16.123.1 ip nhrp map 10.40.61.2 172.16.123.2 ip nhrp network-id 110 ip nhrp cache non-authoritative tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 router eigrp 100 no auto-summary ! address-family ipv4 vrf Gorgon_Data network 10.40.61.3 0.0.0.0 no auto-summary autonomous-system 100 exit-address-family _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From MatlockK at exempla.org Tue Oct 13 16:07:23 2009 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Tue, 13 Oct 2009 14:07:23 -0600 Subject: [c-nsp] ibgp TTL In-Reply-To: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> Router bgp Neighbor ttl-security hops ? Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Manu Chao Sent: Tuesday, October 13, 2009 4:52 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] ibgp TTL For a very specific design, i need to limit TTL value in ibgp-multihop. Is it possible to limit iBGP TTL like we do with ebgp-multihop ttl command? Any input appreciated. Manu _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From shinejoseph at dodo.com.au Tue Oct 13 15:48:58 2009 From: shinejoseph at dodo.com.au (Shine Joseph) Date: Wed, 14 Oct 2009 03:48:58 +0800 Subject: [c-nsp] mGRE with VRF-Lite References: <3c6ab8da0910112210o27923bb3x5c1ed0059e0ae710@mail.gmail.com> <3c6ab8da0910112219u3d6f8835r3892220ad7dc92c9@mail.gmail.com> <790E2A460226464A84253AA77140BD34@au.didata.local> <3c6ab8da0910121833s57c09bc5w3c38d4d96bd466e0@mail.gmail.com> Message-ID: <6D91147F5AA346C7A44AD3B94B8E9470@au.didata.local> Hi, That's correct. The neighbors come up, flaps. Also, they did not any exchange any routes. ----- Original Message ----- From: Brad Holding To: Shine Joseph Sent: Tuesday, October 13, 2009 9:33 AM Subject: Re: [c-nsp] mGRE with VRF-Lite So when you added the 'ip nhrp map multicast 172.16.123.xxx' under the tunnel the EIGRP neighbours would just flap? On Tue, Oct 13, 2009 at 4:55 AM, Shine Joseph wrote: Hi, Thanks for your responses and pointers. the vrf names in the tunnel and routing process is just an editing error. I can't get the multicasting working for the mGRE, it works well for the p2p GRE. When multicasting is used for EIGRP, the neibghors come up, but flaps and no routes are being exchanged. The Q counter is not zero. The only way, I got the mGRE worked is using neighbor statements in the routing process. See below my working config for two VRFs. Let me know if you have any further thoughts on this. Thanks Shine ------------------------------------------------------------ Router 1 ========= ip vrf data rd 100:110 ! ip vrf voice rd 100:111 ! interface Tunnel110 ip vrf forwarding data ip address 10.40.60.1 255.255.255.0 no ip redirects ip nhrp map 10.40.60.2 172.16.123.2 ip nhrp map 10.40.60.3 172.16.123.3 ip nhrp network-id 110 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 ! interface Tunnel111 ip vrf forwarding voice ip address 10.40.61.1 255.255.255.0 no ip redirects ip nhrp map 10.40.61.2 172.16.123.2 ip nhrp map 10.40.61.3 172.16.123.3 ip nhrp network-id 111 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 111 ! router eigrp 100 no auto-summary ! address-family ipv4 vrf voice network 10.40.61.1 0.0.0.0 no auto-summary autonomous-system 100 neighbor 10.40.61.2 Tunnel111 neighbor 10.40.61.3 Tunnel111 exit-address-family ! address-family ipv4 vrf data network 1.1.1.1 0.0.0.0 network 10.40.60.1 0.0.0.0 no auto-summary autonomous-system 100 neighbor 10.40.60.3 Tunnel110 neighbor 10.40.60.2 Tunnel110 exit-address-family ! Router 2 ========= ip vrf data rd 100:110 ! ip vrf voice rd 100:111 ! interface Tunnel110 ip vrf forwarding data ip address 10.40.60.2 255.255.255.0 no ip redirects ip nhrp map 10.40.60.1 172.16.123.1 ip nhrp network-id 110 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 ! interface Tunnel111 ip vrf forwarding voice ip address 10.40.61.2 255.255.255.0 no ip redirects ip nhrp map 10.40.61.1 172.16.123.1 ip nhrp network-id 111 tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 111 ! router eigrp 100 no auto-summary ! address-family ipv4 vrf voice network 2.2.2.2 0.0.0.0 network 10.40.61.2 0.0.0.0 no auto-summary autonomous-system 100 neighbor 10.40.61.1 Tunnel111 exit-address-family ! address-family ipv4 vrf data network 10.40.60.2 0.0.0.0 no auto-summary autonomous-system 100 neighbor 10.40.60.1 Tunnel110 exit-address-family Router 3 ========= ip vrf data rd 100:110 ! ip vrf voice rd 100:111 ! interface Tunnel110 ip vrf forwarding data ip address 10.40.60.3 255.255.255.0 no ip redirects ip nhrp map 10.40.60.1 172.16.123.1 ip nhrp network-id 110 ip nhrp cache non-authoritative tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 ! interface Tunnel111 ip vrf forwarding voice ip address 10.40.61.3 255.255.255.0 no ip redirects ip nhrp map 10.40.61.1 172.16.123.1 ip nhrp network-id 111 ip nhrp cache non-authoritative tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 111 ! router eigrp 100 no auto-summary ! address-family ipv4 vrf voice network 10.40.61.3 0.0.0.0 no auto-summary autonomous-system 100 neighbor 10.40.61.1 Tunnel111 exit-address-family ! address-family ipv4 vrf data network 10.40.60.3 0.0.0.0 no auto-summary autonomous-system 100 neighbor 10.40.60.1 Tunnel110 exit-address-family ! ----- Original Message ----- From: Brad Holding To: shinejoseph at dodo.com.au Sent: Monday, October 12, 2009 1:19 PM Subject: Fwd: [c-nsp] mGRE with VRF-Lite Also, the VRF names under the interfaces and the routing processes are not the same. ie. interface Tunnel110 ip vrf forwarding Data router eigrp 100 no auto-summary ! address-family ipv4 vrf Gorgon_Data Because you don't appear to have a NHRP hub, dynamic multicast mapping may not work. If it isn't, try mapping multicast traffic to each neighbour: ip nhrp map multicast 172.16.123.xxx On Mon, Oct 12, 2009 at 1:10 PM, Brad Holding wrote: Hey Mate, You need to map multicast traffic dynamically under NHRP on the tunnel interface: ip nhrp map multicast dynamic This will allow the EIGRP hello's to be tunneled to the endpoints and the neighbour relationships will then establish. Brad On Mon, Oct 12, 2009 at 3:20 AM, Shine Joseph wrote: Hi, I am working on a solution to run mGRE for VRF-Lite. This is my situation: there are 5 sites currently connected by MPLS IPWAn provided by ISP. I want to run VRF-Lite throughout the network for path isolation between various VLANs. VRF-Lite works great within the site (Vrf-Lite end-to-end is being deployed). In order for to cross the IPWAN, mutipoint-GRE tunnels are being looked at. tunnels are getting created, but when advertised in the VRF routing process, neighbor is not being esablished. If I use the potint to point tunnel, neighbor relationship is estanblished, working as expected. The issue will be I need to create over 50 tunnels to achieve the expected results. Can someone help me, if the mGRE with VRF-Lite is a feasible solution? Thanks in advance Shine ---------------------------- Following is a snippet of my configuration: Router 1 ======== interface Tunnel110 ip vrf forwarding Data ip address 10.40.61.1 255.255.255.224 no ip redirects ip nhrp map 10.40.61.2 172.16.123.2 ip nhrp map 10.40.61.3 172.16.123.3 ip nhrp network-id 110 ip nhrp cache non-authoritative tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 router eigrp 100 no auto-summary ! address-family ipv4 vrf Gorgon_Data network 10.40.61.1 0.0.0.0 no auto-summary autonomous-system 100 exit-address-family ! Router 2 ======== interface Tunnel110 ip vrf forwarding Data ip address 10.40.61.2 255.255.255.224 no ip redirects ip nhrp map 10.40.61.1 172.16.123.1 ip nhrp map 10.40.61.3 172.16.123.3 ip nhrp network-id 110 ip nhrp cache non-authoritative tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 router eigrp 100 no auto-summary ! address-family ipv4 vrf Gorgon_Data network 10.40.61.2 0.0.0.0 no auto-summary autonomous-system 100 exit-address-family ! Router 3 ======== interface Tunnel110 ip vrf forwarding Data ip address 10.40.61.3 255.255.255.224 no ip redirects ip nhrp map 10.40.61.1 172.16.123.1 ip nhrp map 10.40.61.2 172.16.123.2 ip nhrp network-id 110 ip nhrp cache non-authoritative tunnel source GigabitEthernet0/1 tunnel mode gre multipoint tunnel key 110 router eigrp 100 no auto-summary ! address-family ipv4 vrf Gorgon_Data network 10.40.61.3 0.0.0.0 no auto-summary autonomous-system 100 exit-address-family _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From andy.petrenko at gmail.com Tue Oct 13 16:55:56 2009 From: andy.petrenko at gmail.com (Andrey 'sshd' Petrenko) Date: Tue, 13 Oct 2009 23:55:56 +0300 Subject: [c-nsp] ibgp TTL In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> Message-ID: <6b300f5d0910131355u5f2adeafl63da07abbcb399f7@mail.gmail.com> I think that command it's not there was due in first post. 2009/10/13 Matlock, Kenneth L > Router bgp > Neighbor ttl-security hops > > ? > > Ken Matlock > Network Analyst > Exempla Healthcare > (303) 467-4671 > matlockk at exempla.org > > > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Manu Chao > Sent: Tuesday, October 13, 2009 4:52 AM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] ibgp TTL > > For a very specific design, i need to limit TTL value in ibgp-multihop. > > Is it possible to limit iBGP TTL like we do with ebgp-multihop ttl > command? > > Any input appreciated. > > Manu > _______________________________________________ > cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- With best regards, Andrey 'sshd' Petrenko xmmp: sshd at jabber.org gtalk: andy.petrenko at gmail.com skype: andy.petrenko web: http://sshd.by From paul.cosgrove.nsp at gmail.com Tue Oct 13 17:06:29 2009 From: paul.cosgrove.nsp at gmail.com (Paul Cosgrove) Date: Tue, 13 Oct 2009 22:06:29 +0100 Subject: [c-nsp] best practices switches/Router In-Reply-To: <028801ca4c2e$5a4c8010$2408120a@am.thmulti.com> References: <62034.2521.qm@web508.biz.mail.mud.yahoo.com> <028801ca4c2e$5a4c8010$2408120a@am.thmulti.com> Message-ID: <73636ae00910131406s4e91ddb8g1e4c89714660e7b2@mail.gmail.com> Hi Scott, Would have to recommend reading the document, as the NSA have produced very well written guides for many years. Then adopt whichever recommendations you like, or a cunning disguise if you prefer. Paul. On Tue, Oct 13, 2009 at 6:55 PM, Scott Granados wrote: > NSA security policy, hmmmm, does that involve a lot of port mirroring and > copying of data to non existant trunks. (shshshshshsh) Or use of encryption > standards that are almost secure.;) > > Call me crazy (you wouldn't be the first) but I have to say I'm always > skeptical when someone says "Hi, we're from the Government and we're here to > help!" > > > > ----- Original Message ----- From: "Kevin Graham" < > kgraham at industrial-marshmallow.com> > To: ; > Sent: Tuesday, October 13, 2009 10:37 AM > Subject: Re: [c-nsp] best practices switches/Router > > > >> my aim is to do review of the configs of ROUTERS and Switches in my >>> network. >>> As a review , need to track down the best practices that should be >>> configured and are not there in my network. >>> >> >> Was: >> >> http://www.google.com/search?q=site%3Acisco.com+best+practices >> >> ...not sufficient? >> >> From a security standpoint, in addition to the NSA SNAC publications >>> already >>> >> mentioned, Cisco's Network Security Baseline is very much worth reading: >> >> >> >> https://www.cisco.com/en/US/docs/solutions/Enterprise/Security/Baseline_Security/securebasebook.html >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From gsgranados at comcast.net Tue Oct 13 17:16:12 2009 From: gsgranados at comcast.net (Scott Granados) Date: Tue, 13 Oct 2009 14:16:12 -0700 Subject: [c-nsp] best practices switches/Router References: <62034.2521.qm@web508.biz.mail.mud.yahoo.com> <028801ca4c2e$5a4c8010$2408120a@am.thmulti.com> <73636ae00910131406s4e91ddb8g1e4c89714660e7b2@mail.gmail.com> Message-ID: <03dd01ca4c4a$6c2363f0$2408120a@am.thmulti.com> I'm sure you're right. I just found the whole conversation odd and the idea of the NSA being helpful humorous, especially when you walk by buildings that don't exist! Sort of like asking the IRS for tax advice and hoping that you'll get the most cost effective option.;) You have a good point though and if anyone should be able to pull together security documentation you'd hope the NSA would be a great resource. Thanks Scott ----- Original Message ----- From: Paul Cosgrove To: Scott Granados Cc: Kevin Graham ; jckdaniels12 at gmail.com ; cisco-nsp at puck.nether.net Sent: Tuesday, October 13, 2009 2:06 PM Subject: Re: [c-nsp] best practices switches/Router Hi Scott, Would have to recommend reading the document, as the NSA have produced very well written guides for many years. Then adopt whichever recommendations you like, or a cunning disguise if you prefer. Paul. On Tue, Oct 13, 2009 at 6:55 PM, Scott Granados wrote: NSA security policy, hmmmm, does that involve a lot of port mirroring and copying of data to non existant trunks. (shshshshshsh) Or use of encryption standards that are almost secure.;) Call me crazy (you wouldn't be the first) but I have to say I'm always skeptical when someone says "Hi, we're from the Government and we're here to help!" ----- Original Message ----- From: "Kevin Graham" To: ; Sent: Tuesday, October 13, 2009 10:37 AM Subject: Re: [c-nsp] best practices switches/Router my aim is to do review of the configs of ROUTERS and Switches in my network. As a review , need to track down the best practices that should be configured and are not there in my network. Was: http://www.google.com/search?q=site%3Acisco.com+best+practices ...not sufficient? From a security standpoint, in addition to the NSA SNAC publications already mentioned, Cisco's Network Security Baseline is very much worth reading: https://www.cisco.com/en/US/docs/solutions/Enterprise/Security/Baseline_Security/securebasebook.html _______________________________________________ cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From plunin at senetsy.ru Tue Oct 13 17:26:15 2009 From: plunin at senetsy.ru (Pavel Lunin) Date: Wed, 14 Oct 2009 01:26:15 +0400 Subject: [c-nsp] Hardware for 'managed firewall' In-Reply-To: References: <4AC271C6.1090508@reachone.com> Message-ID: <77c10e260910131426w15557910q5bc2463012a47557@mail.gmail.com> I have a bit of experience with managed firewall services. We tried to provide it for several years. To be honest, can't claim a tremendous success :) Although I disagree about netscreen cli (at least in comparison with pix/asa), I can add that any sort of cli/webui of a network/security device itself is insufficient for providing it to enterprise customers. Even the most popular IOS cli provided to customers will require lots of helpdesk support. If we add the price of a license for context/vsys, I would think again whether this approach has business perspectives since (just my guess for the Russian market) most customers, who are skilled enough to administrate any sort of firewall appliance, prefer to have their own boxes. Moreover (maybe it is also a sort of local mental attitude) customers often think that enterprise network security is something you'd rather keep as closer to you as possible. So the most common customer for a managed firewall service is a small company with little experience in IT. A good exception is data centers where such a service goes better. But it is quite a different story. What about providing managed firewall service to the enterprise customers, I'd propose to use some external management solution with a primitive web interface for the end customers. This sort of service provisioning system will cost some additional money but in general such a model doesn't require multiple contexts. However it needs a firewall which is ready for automated management (e. g. has an XML interface) and also supports enough of routing instances (separate routing domains in a single context) for private IP spaces overlapping. I know a vendor, which produces firewalls capable to do all this, but it is not cisco :) -- Kind regards, Pavel 2009/9/30 Dave Weis > > On Wed, 30 Sep 2009, David Hughes wrote: > >> On 30/09/2009, at 7:08 AM, Dave Weis wrote: >> >>> On Tue, 29 Sep 2009, Christopher Hunt wrote: >>> >>>> As I painfully discovered, the Cisco ASA in Multiple Context mode does >>>> not support IPSEC VPN clients nor L2TP3 tunnels >>>> >>> >>> That's a pretty big omission! Any ETA to add that capability? >>> >> Yeah, they've never supported VPN in multi-context mode. Major pain. And >> if you are a dense hosting provider the 50 context limit (and limited >> performance) of a 5540 for example doesn't work too well. These issues made >> us look around again and J-Vendor's boxes are making the ASA's look a bit >> ordinary. >> > > I never enjoyed working on the netscreens. I suppose if each virtual > firewall customer could get the same awkward web interface for self > provisioning it could be made to work. > > -- > Dave Weis > djweis at internetsolver.com > http://www.internetsolver.com/ > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From peter at rathlev.dk Tue Oct 13 18:36:54 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Wed, 14 Oct 2009 00:36:54 +0200 Subject: [c-nsp] MPLS QoS Query In-Reply-To: <469782.81058.qm@web52107.mail.re2.yahoo.com> References: <469782.81058.qm@web52107.mail.re2.yahoo.com> Message-ID: <1255473414.3960.2.camel@abehat.net.rm.dk> On Tue, 2009-10-13 at 04:58 -0700, Nilesh Sawant wrote: ... > interface-range gig 6/1-8 ... > ** wrr-queue cos-map 1 1 0 > ** wrr-queue cos-map 2 1 3 2 1 ... > ** priority-queue cos map 1 5 ... > ** wrr-queue threshold 3 100 100 100 100 100 100 100 100 ... > ** wrr-queue random-detect max-threshold 3 100 100 100 100 100 100 100 > > end > > > I have configured the above config on one the Gig interface but few > lines are missing in sh run of said interface eventhough those are > accepted in config which are marked "*" Please suggest on same ? It is most probably because those values are the defaults, which are not shown on the interface. Regarding the specific values in the other lines it's hard to comment; only knowledge of the traffic and testing can tell you if those values are the right ones for you. -- Peter From z at amused.net Tue Oct 13 18:59:16 2009 From: z at amused.net (Patrick Cole) Date: Wed, 14 Oct 2009 09:59:16 +1100 Subject: [c-nsp] L2TP LNS issue In-Reply-To: <20091013130448.GW22413@mcom.fr> References: <20091013110031.GA15189@amused.net> <20091013130448.GW22413@mcom.fr> Message-ID: <20091013225916.GA3155@amused.net> Chris, Thanks for your suggestion but I originally had ppp mtu adaptive on. The PPP negotiation does not even seem to get to the MRU negotiation phase at all. The cisco seems to send an AuthAck but then a TermAck straight after it. Pat Tue, Oct 13, 2009 at 03:04:48PM +0200, Christophe Lucas wrote: > Patrick Cole (z at amused.net) wrote: > > version 12.2 > > service timestamps debug datetime msec > > service timestamps log datetime msec > > no service password-encryption > > ! > > hostname router > > ! > > [...] > > > interface Virtual-Template1 > > description LNS > > ip unnumbered FastEthernet0/0 > > peer default ip address pool test > > ppp authentication pap > > ! > > router ospf 1 > > log-adjacency-changes > > area 0.0.0.0 authentication > > redistribute connected subnets > > redistribute static subnets > > network 0.0.0.63 area 0.0.0.0 > > ! > > ip local pool test 10.0.9.1 10.0.9.254 > > ip classless > > ip route 0.0.0.0 0.0.0.0 > > ! > > Hi, > > I have quickly read your mail. Sorry if it is not answer to your > question... > > I have made a lab on this kind of network. My LAC et LNS was Cisco > routers. I have long searched why my PPP is not established on my LNS > and 'ppp mtu adaptive' under 'Virtual Template 1' was my answer. > > I hope it can solve your problem. > > Regards, > -- > Christophe Lucas | Phone: +33 (0)9.74.76.25.95 > Network Engineer | Fax: +33 (0)2.35.63.48.22 > INFOSAT ICPS SA | GSM: +33 (0)6.14.63.55.15 > 132 rue Kennedy | email: c.lucas at infosat.tm.fr > 76140 Petit-Quevilly, France | URL: http://www.infosat.tm.fr > From gert at greenie.muc.de Wed Oct 14 02:44:24 2009 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 14 Oct 2009 08:44:24 +0200 Subject: [c-nsp] 3560 buffering In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> Message-ID: <20091014064424.GA1508@greenie.muc.de> Hi, On Tue, Oct 13, 2009 at 07:10:24AM -0500, Jeff Bacon wrote: > What's an output drop mean, in a 3560 context? Traffic too bursty, output buffers too tiny. > Is there a way to tell the 3560 to buffer more aggressively? As far as our experience with 2960Gs goes, the only way to achieve that is to buy a Force10 switch. The small Cisco switches do not seem to handle bursty switch very well. (You can turn *off* "mls qos". On the 2960, turning on QoS means "take the tiny buffers, and split them into 4 different queues" - and unless your traffic distributes to multiple queues, this just causes "more drops") gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From r.tahina at moov.mg Wed Oct 14 01:52:27 2009 From: r.tahina at moov.mg (RAZAFINDRATSIFA Rivo Tahina) Date: Wed, 14 Oct 2009 08:52:27 +0300 Subject: [c-nsp] ASN statistic tools Message-ID: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> Daer All, I'm looking for utilities which allow to have ASN statistics, the netflow tools I tried doesn't do that, any idea? BR From christian at automatick.net Wed Oct 14 03:12:45 2009 From: christian at automatick.net (christian) Date: Wed, 14 Oct 2009 00:12:45 -0700 Subject: [c-nsp] ASN statistic tools In-Reply-To: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> References: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> Message-ID: take a look at: https://neon1.net/as-stats/as-stats-presentation-swinog16.pdf On Tue, Oct 13, 2009 at 10:52 PM, RAZAFINDRATSIFA Rivo Tahina wrote: > Daer All, > > I'm looking for utilities which allow to have ASN statistics, the netflow > tools I tried doesn't do that, any idea? > > BR > _______________________________________________ > cisco-nsp mailing list ?cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From md at bts.sk Wed Oct 14 03:55:41 2009 From: md at bts.sk (=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=) Date: Wed, 14 Oct 2009 09:55:41 +0200 Subject: [c-nsp] 3560 buffering In-Reply-To: <20091014064424.GA1508@greenie.muc.de> References: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> <20091014064424.GA1508@greenie.muc.de> Message-ID: <20091014072843.M20756@bts.sk> On Wed, 14 Oct 2009 08:44:24 +0200, Gert Doering wrote > Hi, > > On Tue, Oct 13, 2009 at 07:10:24AM -0500, Jeff Bacon wrote: > > What's an output drop mean, in a 3560 context? > > Traffic too bursty, output buffers too tiny. > > > Is there a way to tell the 3560 to buffer more aggressively? There's a fundamental clash between desktop switch design and TCP operation on recent operating systems. Switches like 3560G by default buffer 100 MTU-sized packets, i.e. something like 150 kB of data. 3560Es are even worse, they only buffer 64 MTU-sized packets by default (~100 kB of data). But in recent Linux kernels (as well as in Windows Vista) TCP buffer autotuning rises TCP window to megabyte(!) ranges. Hence a *single* TCP connection has no problem to overrun the buffer space and cause large amount of drops. With kind regards, M. From vijaygore27 at gmail.com Wed Oct 14 03:57:15 2009 From: vijaygore27 at gmail.com (vijay gore) Date: Wed, 14 Oct 2009 13:27:15 +0530 Subject: [c-nsp] file transfer Message-ID: <31533f200910140057g72517b4bnc15c6fb3813e606c@mail.gmail.com> dear team, i want to check my bandwidth using file transfer please help how to do that. From Gideon at gilat.net Wed Oct 14 04:02:13 2009 From: Gideon at gilat.net (Gideon Popol) Date: Wed, 14 Oct 2009 10:02:13 +0200 Subject: [c-nsp] ASN statistic tools In-Reply-To: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> References: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> Message-ID: Hello , Did you tried NetFlow Analyzer http://www.manageengine.com/products/netflow/index.html they have ASN statistics Best Regards Gideon Popol gideon at gilat.net Office:?? +972.3.9255039 MSN:??? ?gidi_pop at hotmail.com www.gilat.net The Winner of the ?Best Satellite Service Provider 2007? Award The information contained in this e-mail message and its attachments is confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender, and then delete the message from your computer. ?Thank you! -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of RAZAFINDRATSIFA Rivo Tahina Sent: Wednesday, October 14, 2009 7:52 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] ASN statistic tools Daer All, I'm looking for utilities which allow to have ASN statistics, the netflow tools I tried doesn't do that, any idea? BR _______________________________________________ cisco-nsp mailing list cisco-nsp at 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. ************************************************************************************ From gkg at gmx.de Wed Oct 14 04:42:20 2009 From: gkg at gmx.de (Garry) Date: Wed, 14 Oct 2009 10:42:20 +0200 Subject: [c-nsp] file transfer In-Reply-To: <31533f200910140057g72517b4bnc15c6fb3813e606c@mail.gmail.com> References: <31533f200910140057g72517b4bnc15c6fb3813e606c@mail.gmail.com> Message-ID: <4AD58EEC.900@gmx.de> vijay gore wrote: > dear team, > i want to check my bandwidth using file transfer please help how to do that+ Using file transfer for performance measurement is unreliable ... google iperf/jperf for decent point-2-point throughput measurement ... please note that it requires access to both the local site as well as a remote station to test against ... -garry From linux.yahoo at gmail.com Wed Oct 14 04:51:40 2009 From: linux.yahoo at gmail.com (Manu Chao) Date: Wed, 14 Oct 2009 10:51:40 +0200 Subject: [c-nsp] ibgp TTL In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> Message-ID: <7100ed370910140151x72a0f59fvd1bfd685a9e710a@mail.gmail.com> AFAIK this command is for eBGP only, no? On Tue, Oct 13, 2009 at 10:07 PM, Matlock, Kenneth L wrote: > Router bgp > Neighbor ttl-security hops > > ? > > Ken Matlock > Network Analyst > Exempla Healthcare > (303) 467-4671 > matlockk at exempla.org > > > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Manu Chao > Sent: Tuesday, October 13, 2009 4:52 AM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] ibgp TTL > > For a very specific design, i need to limit TTL value in ibgp-multihop. > > Is it possible to limit iBGP TTL like we do with ebgp-multihop ttl > command? > > Any input appreciated. > > Manu > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From ghs at serve.dk Wed Oct 14 05:39:37 2009 From: ghs at serve.dk (Gustaf Hyllested Serve) Date: Wed, 14 Oct 2009 11:39:37 +0200 Subject: [c-nsp] ASN statistic tools In-Reply-To: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> References: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> Message-ID: <2638c6520910140239r44848221k9ba4c8cc5dc80ff4@mail.gmail.com> > I'm looking for utilities which allow to have ASN statistics, the netflow > tools I tried doesn't do that, any idea? take a look at NetQos ReportAnalyzer -- Gustaf Hyllested Serve From blahu77 at gmail.com Wed Oct 14 05:45:01 2009 From: blahu77 at gmail.com (Mateusz Blaszczyk) Date: Wed, 14 Oct 2009 10:45:01 +0100 Subject: [c-nsp] 3560 buffering In-Reply-To: <1255449595.3217.40.camel@abehat.net.rm.dk> References: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> <1255449595.3217.40.camel@abehat.net.rm.dk> Message-ID: <20091014094501.GF8830@thorgal> On Tue, Oct 13, 2009 at 05:59:55PM +0200, Peter Rathlev wrote: [...] > ! Only output queue-set 1, queue 2 is used. Adjust all thresholds to > ! 400% of default. (This is AFAIK the maximum even though the parser > ! accepts up to 3200%.) > mls qos queue-set output 1 threshold 2 400 400 100 400 So main differnce to "no mls qos" is that thresholds are lifted from default 100% to maximum 400% - is that correct - meaning the packets are dropped later then earlier? > ! Assign all buffers to queue 2 (also used by the CPU) > mls qos queue-set output 1 buffers 0 100 0 0 > ! What is the default here? All queues are used by default? Best Regards, -- Mateusz Blaszczyk pgp-key 0x64643FCE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From peter at rathlev.dk Wed Oct 14 06:05:37 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Wed, 14 Oct 2009 12:05:37 +0200 Subject: [c-nsp] 3560 buffering In-Reply-To: <20091014094501.GF8830@thorgal> References: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> <1255449595.3217.40.camel@abehat.net.rm.dk> <20091014094501.GF8830@thorgal> Message-ID: <1255514737.3677.8.camel@abehat.net.rm.dk> On Wed, 2009-10-14 at 10:45 +0100, Mateusz Blaszczyk wrote: > On Tue, Oct 13, 2009 at 05:59:55PM +0200, Peter Rathlev wrote: > [...] > > ! Only output queue-set 1, queue 2 is used. Adjust all thresholds to > > ! 400% of default. (This is AFAIK the maximum even though the parser > > ! accepts up to 3200%.) > > mls qos queue-set output 1 threshold 2 400 400 100 400 > > So main differnce to "no mls qos" is that thresholds are lifted from > default 100% to maximum 400% - is that correct - meaning the packets > are dropped later then earlier? Default thresholds can be seen with "show mls qos queue-set (1|2)"; AFAICT the defaults are 100%. So yes, the command has the effect of allocating more buffer space, meaning less drops on bursts. I still don't quite understand why the default ("no mls qos") won't use all buffer space, but our lab tests points towards that they simply don't. > > ! Assign all buffers to queue 2 (also used by the CPU) > > mls qos queue-set output 1 buffers 0 100 0 0 > > ! > > What is the default here? All queues are used by default? Hm... looking at a switch that has never had "mls qos" configured: someswitch#sh mls qos QoS is disabled QoS ip packet dscp rewrite is enabled someswitch#sh platform port-asic stats enqueue gi0/1 Interface Gi0/1 TxQueue Enqueue Statistics Queue 0 Weight 0 Frames 2 Weight 1 Frames 0 Weight 2 Frames 0 Queue 1 Weight 0 Frames 0 Weight 1 Frames 34736 Weight 2 Frames 318358119 Queue 2 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 3 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 425983701 someswitch# It seems that all queues are actually used according to the default CoS map. I think I'm getting confused here. Can anybody shed light on this? The reason I used queue 2 in the example is that the CPU apparantly uses it so you can never allocate 0% for this queue. The "no QoS" scenario is best achieved with one simple queue using all buffer space. -- Peter From linux.yahoo at gmail.com Wed Oct 14 06:50:05 2009 From: linux.yahoo at gmail.com (Manu Chao) Date: Wed, 14 Oct 2009 12:50:05 +0200 Subject: [c-nsp] BGP Backdoor Links Problem In-Reply-To: References: Message-ID: <7100ed370910140350n15a7d6aft2702203e86f909f0@mail.gmail.com> You needn't BGP Backdoor option Prefer BGP Communities, easier, better On Mon, Oct 12, 2009 at 4:08 AM, Fossett, Jeff S wrote: > Hi Team - figured most of you could provide a fix for the following > scenario in your sleep, so I thought I'd reach out. > We have a Primary DataCenter and a DR Facility, attached via MPLS privately > (using EIGRP across that link to peer the two DataCenters)... both also have > an eBGP Peering Relationship with a Service Provider that is providing a > private Cellular APN. Though both connections are "Active" to the Service > Provider Cellular PN, we want an "Active/Standby" type of routing scenario. > Our DR Center is not built up in a manner that adequately supports > Active/Active from an Application/Middle Tier/Mainframe standpoint. > Scenario: In our BGP peering relationship with the ISP (giving Cell > Services) we are running eBGP. Whenever routes are learned with eBGP they > have a local cost of 20. Since our "DataCenter Gateway" is getting the > routes to the cell private networks from eBGP via "DR Gateway" they are > always preferred over the Portland learned EIGRP external routes with a 170 > cost. When peering to the cell carriers is active in both the DataCenter > and DR, the data sourced or destined for DR from the cell carrier networks > will fail. > Problem: We used the BGP Backdoor option on the DataCenter gateway to > change the distance on the Cellular Cloud networks from 20 to 200 in order > to allow our DataCenter gateway to prefer EIGRP routes within the DataCenter > environment, and then redistribute into BGP. > But once we put this in, BGP no longer advertises any networks that are > associated with the backdoor command. Should we pursue some sort of > Conditional Advertisement, or Synchronization/Redistribution scenario??? > Any advice? Thanks so much in advance for the help . . . > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From bacon at walleyesoftware.com Wed Oct 14 07:45:32 2009 From: bacon at walleyesoftware.com (Jeff Bacon) Date: Wed, 14 Oct 2009 06:45:32 -0500 Subject: [c-nsp] 3560 buffering In-Reply-To: <20091014072843.M20756@bts.sk> References: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> <20091014064424.GA1508@greenie.muc.de> <20091014072843.M20756@bts.sk> Message-ID: <5A69C25361FED34F83ABF05F50475245072BC1EF@wally.walleyetrading.net> > There's a fundamental clash between desktop switch design and TCP operation on > recent operating systems. Switches like 3560G by default buffer 100 MTU-sized > packets, i.e. something like 150 kB of data. 3560Es are even worse, they only > buffer 64 MTU-sized packets by default (~100 kB of data). > > But in recent Linux kernels (as well as in Windows Vista) TCP buffer autotuning > rises TCP window to megabyte(!) ranges. Hence a *single* TCP connection has no > problem to overrun the buffer space and cause large amount of drops. Though in theory, assuming that the switch is capable of receiving and transmitting at wire speed, the maximum amount of buffer it would need to deal with a 1Gb/s flow between A and B would be *1Gbit (plus a shade) since from the switch's point of view, data-in == data-out, irrespective of the window size of the hosts. Any additional buffer space is essentially just making up for the notion that more than one sender may be sending to the same dest port, in which case you're hanging onto packets from host C hoping that the burst of packets from host A will subside enough that you can fit in some packets from host C. At some point you've got to drop packets to tell the senders that _someone_ has to back off because the receiver can only handle 1Gb/sec. So how much _should_ a switch buffer on behalf of the host? Not sure it has a ton to do with the window sizes of the hosts involved. (Rhetorical question, really. I'd like to buffer more, but not a ton more or then my switches become a significant source of latency when really the hosts need fatter pipes. Some might feel it better to buffer less and tell the hosts to back off. Depends on the workload involved, I imagine.) Here at home, it does appear there was a distinct deficiency in 12.2(44)SE; it appears behavior is significantly improved with 12.2(52)SE. From oboehmer at cisco.com Wed Oct 14 08:10:39 2009 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Wed, 14 Oct 2009 14:10:39 +0200 Subject: [c-nsp] ibgp TTL In-Reply-To: <7100ed370910140151x72a0f59fvd1bfd685a9e710a@mail.gmail.com> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com><4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> <7100ed370910140151x72a0f59fvd1bfd685a9e710a@mail.gmail.com> Message-ID: <6E4D2678AC543844917CA081C9D6B33F7CD4F8@XMB-AMS-103.cisco.com> yes, only supported for ebgp. Would be interested about the "very specific design" and why Manu requires this functionality? oli > AFAIK this command is for eBGP only, no? > > On Tue, Oct 13, 2009 at 10:07 PM, Matlock, Kenneth L > wrote: > > > Router bgp > > Neighbor ttl-security hops > > > > ? > > > > Ken Matlock > > Network Analyst > > Exempla Healthcare > > (303) 467-4671 > > matlockk at exempla.org > > > > > > > > -----Original Message----- > > From: cisco-nsp-bounces at puck.nether.net > > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Manu Chao > > Sent: Tuesday, October 13, 2009 4:52 AM > > To: cisco-nsp at puck.nether.net > > Subject: [c-nsp] ibgp TTL > > > > For a very specific design, i need to limit TTL value in ibgp-multihop. > > > > Is it possible to limit iBGP TTL like we do with ebgp-multihop ttl > > command? > > > > Any input appreciated. > > > > Manu > > _______________________________________________ > > cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From md at bts.sk Wed Oct 14 08:25:15 2009 From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=) Date: Wed, 14 Oct 2009 14:25:15 +0200 Subject: [c-nsp] 3560 buffering In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC1EF@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> <20091014064424.GA1508@greenie.muc.de> <20091014072843.M20756@bts.sk> <5A69C25361FED34F83ABF05F50475245072BC1EF@wally.walleyetrading.net> Message-ID: <20091014122515.GA68065@bts.sk> On Wed, Oct 14, 2009 at 06:45:32AM -0500, Jeff Bacon wrote: > > There's a fundamental clash between desktop switch design and TCP operation on > > recent operating systems. Switches like 3560G by default buffer 100 MTU-sized > > packets, i.e. something like 150 kB of data. 3560Es are even worse, they only > > buffer 64 MTU-sized packets by default (~100 kB of data). > > > > But in recent Linux kernels (as well as in Windows Vista) TCP buffer autotuning > > rises TCP window to megabyte(!) ranges. Hence a *single* TCP connection has no > > problem to overrun the buffer space and cause large amount of drops. > > > Though in theory, assuming that the switch is capable of receiving and > transmitting at wire speed, the maximum amount of buffer it would need > to deal with a 1Gb/s flow between A and B would be *1Gbit > (plus a shade) since from the switch's point of view, data-in == data-out, > irrespective of the window size of the hosts. Yes, if both hosts are connected at the same speed, no extensive buffering is needed. However, another usage scenario for such switches is speed downshift, e.g. 1Gbps uplink -> 100 Mbps host (or 10 Gbps -> 1 Gbps), where the relation to TCP window size does apply. With kind regards, M. From david.freedman at uk.clara.net Wed Oct 14 09:13:31 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 14 Oct 2009 14:13:31 +0100 Subject: [c-nsp] L2TP LNS issue In-Reply-To: <20091013110031.GA15189@amused.net> References: <20091013110031.GA15189@amused.net> Message-ID: <4AD5CE7B.1000700@uk.clara.net> Silly (semi-related) question, but I (hope) you are not installing a default to ppp0 on your *nix box when the session comes up, or if you are, you have a static via your main nic to the l2tp endpoint address, else you will cause the tunnel to fall down due to recursion. Dave. From david.freedman at uk.clara.net Wed Oct 14 09:13:31 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 14 Oct 2009 14:13:31 +0100 Subject: [c-nsp] L2TP LNS issue In-Reply-To: <20091013110031.GA15189@amused.net> References: <20091013110031.GA15189@amused.net> Message-ID: <4AD5CE7B.1000700@uk.clara.net> Silly (semi-related) question, but I (hope) you are not installing a default to ppp0 on your *nix box when the session comes up, or if you are, you have a static via your main nic to the l2tp endpoint address, else you will cause the tunnel to fall down due to recursion. Dave. From frosya84 at mail.ru Wed Oct 14 09:59:44 2009 From: frosya84 at mail.ru (=?koi8-r?Q?=EF=CC=D8=C7=C1_=F2=D5=D6=C1=CE=D3=CB=C1=D1?=) Date: Wed, 14 Oct 2009 17:59:44 +0400 Subject: [c-nsp] =?koi8-r?b?bWxzIHFvcyBvbiA3NjAwIHdpdGggbmF0aXZlIHZsYW4g?= =?koi8-r?b?YW5kIE1QTFM=?= Message-ID: Hello, > My understanding is that this queueing mode can be based only on COS > field on GE and 10/100/1000 line cards. So what will be the router > behaviour if there is no 802.Q and therefore no 802.1p During processing, PFC QoS represents the priority of all traffic (including non-IP traffic) with an internal DSCP value. On the PFC, before any marking or policing takes place, PFC QoS derives the initial internal DSCP value as follows: From received CoS values or from port CoS values for trust CoS traffic. Mapped from received IP precedence values for trust IP precedence traffic. From received DSCP values for trust DSCP traffic. Mapped from port CoS or DSCP values configured in policy maps for untrusted traffic. For all egress traffic, PFC QoS uses a configurable map to derive a CoS value from the final internal DSCP value associated with the traffic. > I do run MPLS in the core for VPN services. The core interfaces are > in mode "no switchport" and are untagged as well (routed ports on 10GE > interfaces). Here too, what happens if I have cos based queueing (as > this is native ethernet)? What happens if I run DSCP based queueing (as > this is MPLS, can dscp be used?) My goal here is more to make sure that > my qos does not break anything. For received Layer 3 MPLS packets, the PFC usually trusts the EXP value in the received topmost label. None of the following have any effect on MPLS packets: Interface trust state Port CoS value Policy-map trust command Actually, there are a lot of information. I hope that these links will be usefull: 1) http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/qos.html 2) http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/mplsqos.html Best regards, Olga. From oboehmer at cisco.com Wed Oct 14 10:22:51 2009 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Wed, 14 Oct 2009 16:22:51 +0200 Subject: [c-nsp] Cisco 12416 Power Management In-Reply-To: References: Message-ID: <6E4D2678AC543844917CA081C9D6B33F7CD650@XMB-AMS-103.cisco.com> > > I'm trying to figure out why i have this output: > > ++++++++++++++++++++++++++++++++++++++++++++++ > 12k2>sh env power_supply > > Failsafe power system > > Slot # 48V AMP_48 > (Volt) (Amp) > 27 PEM1 53 10 Failsafe-PEM= Failsafe PS this looks like CSCsk88926 (PEMS appear in Failsafe Mode during IOS image upgrade or power cycle), duplicate of CSCsj91286 fixed in 12.0(32)SY5 and 12.0(32)S9. Which release do you run? Only 12.0(32)SY3 and 12.0(32)S6 should be affected.. oli From eng_mssk at hotmail.com Wed Oct 14 10:34:07 2009 From: eng_mssk at hotmail.com (Mohammad Khalil) Date: Wed, 14 Oct 2009 17:34:07 +0300 Subject: [c-nsp] Cisco SCE RTM Message-ID: hi all i have SCE 2020 with sca console 3.5.0 i installed RTM on it and all is working fine now i have another SCE with SCA console 3.5.0 (the same console version) and its 8000 series but when i try to apply the ./rtmcmd.sh with the rest of the line , i get the below error Failed to process templates. Aborting! even though when i try to graph the concurrent sessions on the SCE2020 [root at Core ~]# snmpwalk -v2c -c s3c4r3 10.62.112.10 .1.3.6.1.4.1.5655.4.1.8.1.1.9.1 SNMPv2-SMI::enterprises.5655.4.1.8.1.1.9.1 = Gauge32: 566 on the SCE8000 [root at FT ~]# snmpwalk -v2c -c tSaf_Gnirts 62.215.0.10 .1.3.6.1.4.1.5655.4.1.8.1.1.9.1 SNMPv2-SMI::enterprises.5655.4.1.8.1.1.9.1 = No Such Object available on this agent at this OID any ideas what should i do ? thanks in advance _________________________________________________________________ Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail?. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009 From amsoares at netcabo.pt Wed Oct 14 10:41:41 2009 From: amsoares at netcabo.pt (Antonio Soares) Date: Wed, 14 Oct 2009 15:41:41 +0100 Subject: [c-nsp] Cisco 12416 Power Management In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F7CD650@XMB-AMS-103.cisco.com> References: <6E4D2678AC543844917CA081C9D6B33F7CD650@XMB-AMS-103.cisco.com> Message-ID: Hello Oliver, Any possibilities of 12.0(32)SY6 being affected too ? 12k2>sh ver | inc IOS IOS (tm) GS Software (C12KPRP-P-M), Version 12.0(32)SY6, RELEASE SOFTWARE (fc2) 12k2> Because the Bug you mentioned is exactly what i have: 12k2>sh diag (...) PEM 1 (AC_PWR_1): Failsafe PS [Failsafe-PEM=] PEM 2 (AC_PWR_2): No PEM present PEM 3 (AC_PWR_3): No PEM present 12k2> Thanks. Regards, Antonio Soares, CCIE #18473 (R&S) amsoares at netcabo.pt -----Original Message----- From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com] Sent: quarta-feira, 14 de Outubro de 2009 15:23 To: Antonio Soares; cisco-nsp at puck.nether.net Subject: RE: [c-nsp] Cisco 12416 Power Management > > I'm trying to figure out why i have this output: > > ++++++++++++++++++++++++++++++++++++++++++++++ > 12k2>sh env power_supply > > Failsafe power system > > Slot # 48V AMP_48 > (Volt) (Amp) > 27 PEM1 53 10 Failsafe-PEM= Failsafe PS this looks like CSCsk88926 (PEMS appear in Failsafe Mode during IOS image upgrade or power cycle), duplicate of CSCsj91286 fixed in 12.0(32)SY5 and 12.0(32)S9. Which release do you run? Only 12.0(32)SY3 and 12.0(32)S6 should be affected.. oli From jdurand at renater.fr Wed Oct 14 10:58:36 2009 From: jdurand at renater.fr (Jerome Durand) Date: Wed, 14 Oct 2009 16:58:36 +0200 Subject: [c-nsp] mls qos on 7600 with native vlan and MPLS In-Reply-To: References: Message-ID: <4AD5E71C.2040205@renater.fr> > For all egress traffic, PFC QoS uses a configurable map to derive a CoS value from the final internal DSCP value associated with the traffic. I understand, but what if your port is native? (ie. without 802.1p, means without cos??) How does the router classify from unexisting cos? Thanks for the good references. Jerome >> I do run MPLS in the core for VPN services. The core interfaces are >> in mode "no switchport" and are untagged as well (routed ports on 10GE >> interfaces). Here too, what happens if I have cos based queueing (as >> this is native ethernet)? What happens if I run DSCP based queueing (as >> this is MPLS, can dscp be used?) My goal here is more to make sure that >> my qos does not break anything. > For received Layer 3 MPLS packets, the PFC usually trusts the EXP value in the received topmost label. None of the following have any effect on MPLS packets: > Interface trust state > Port CoS value > Policy-map trust command > > > Actually, there are a lot of information. I hope that these links will be usefull: > 1) http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/qos.html > 2) http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/mplsqos.html > > Best regards, > Olga. > > > -- ------------------------------------------------------------- Jerome Durand Responsable des services aux usagers Services operations & support manager R?seau National de T?l?communications pour la Technologie, l'Enseignement et la Recherche Tel: +33 (0) 1 53 94 20 40 | GIP RENATER Fax: +33 (0) 1 53 94 20 41 | c/o ENSAM E-mail: jdurand at renater.fr | 151 Boulevard de l'H?pital http://www.renater.fr | 75013 PARIS -------------------------------------------------------------- From markom at markom.info Wed Oct 14 11:42:50 2009 From: markom at markom.info (Marko Milivojevic) Date: Wed, 14 Oct 2009 15:42:50 +0000 Subject: [c-nsp] ibgp TTL In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F7CD4F8@XMB-AMS-103.cisco.com> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> <7100ed370910140151x72a0f59fvd1bfd685a9e710a@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD4F8@XMB-AMS-103.cisco.com> Message-ID: On Wed, Oct 14, 2009 at 12:10, Oliver Boehmer (oboehmer) wrote: > yes, only supported for ebgp. Would be interested about the "very > specific design" and why Manu requires this functionality? I'm not sure what Manu has in mind, but I had a need to use similar feature to prevent iBGP working over less-desirable IGP path. -- Marko CCIE #18427 (SP) My network blog: http://cisco.markom.info/ From giesen at snickers.org Wed Oct 14 11:54:41 2009 From: giesen at snickers.org (Gary T. Giesen) Date: Wed, 14 Oct 2009 11:54:41 -0400 Subject: [c-nsp] file transfer In-Reply-To: <4AD58EEC.900@gmx.de> References: <31533f200910140057g72517b4bnc15c6fb3813e606c@mail.gmail.com> <4AD58EEC.900@gmx.de> Message-ID: <9a9d0c6a0910140854y34b581f7gf1594a1b616a8535@mail.gmail.com> ttcp is also an option. It's a hidden command in most IOS platforms/releases, and allows you to test TCP throughput. There's also a UNIX version you can use to test between a router and a unix box or between unix boxes. You can google for the code.. On Wed, Oct 14, 2009 at 4:42 AM, Garry wrote: > vijay gore wrote: >> dear team, >> i want to check my bandwidth using file transfer please help how to do that+ > Using file transfer for performance measurement is unreliable ... google > iperf/jperf for decent point-2-point throughput measurement ... please > note that it requires access to both the local site as well as a remote > station to test against ... > > -garry > _______________________________________________ > cisco-nsp mailing list ?cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > From psirt at cisco.com Wed Oct 14 12:00:00 2009 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 14 Oct 2009 09:00:00 -0700 Subject: [c-nsp] Cisco Security Advisory: Cisco Unified Presence Denial of Service Vulnerabilities Message-ID: <200910140900.cup@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco Unified Presence Denial of Service Vulnerabilities Advisory ID: cisco-sa-20091014-cup Revision 1.0 For Public Release 2009 October 14 1600 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco Unified Presence contains two denial of service (DoS) vulnerabilities that may cause an interruption to presence services. These vulnerabilities were discovered internally by Cisco, and there are no workarounds. Cisco has released free software updates that address these vulnerabilities. This advisory is posted at: http://www.cisco.com/warp/public/707/cisco-sa-20091014-cup.shtml Affected Products ================= Vulnerable Products +------------------ The following products are affected: * Cisco Unified Presence 1.x versions * Cisco Unified Presence 6.x versions prior to 6.0(6) * Cisco Unified Presence 7.x versions prior to 7.0(4) 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" via the Command Line Interface (CLI). Products Confirmed Not Vulnerable +-------------------------------- No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= Network Flooding Vulnerability +----------------------------- Cisco Unified Presence contains a denial of service (DoS) vulnerability that may cause the TimesTenD process to fail when TCP ports 16200 or 22794 are flooded with connections. TCP 3-way handshakes must be completed for the attack to be successful. The TimesTenD process will be automatically restarted upon failure. This vulnerability is documented in Cisco Bug ID CSCsy17662 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-2874. Network Connection Tracking Vulnerability +---------------------------------------- Cisco Unified Presence contains a DoS vulnerability that involves the tracking of network connections by the embedded firewall. An attacker can overwhelm the table that is used to track network connections and prevent new connections from being established to system services by establishing many TCP connections with a vulnerable system. Any service that listens to a TCP port on a vulnerable system could be affected by this vulnerability. This vulnerability is documented in Cisco Bug ID CSCsw52371 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-2052. 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 CSCsy17662 - TimesTenD Coredump During TCP Flood 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 CSCsw52371 - CUP: IP_Conntrack Fills Up During TCP Flood Attack 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. 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. Cisco Unified Presence version 6.0(6) is available at the following link: http://tools.cisco.com/support/downloads/go/ReleaseType.x?optPlat=&isPlatform=Y&mdfid=281010019&sftType=Unified+Presence+Server+%28CUPS%29+Updates&treeName=Voice+and+Unified+Communications&modelName=Cisco+Unified+Presence+Version+6.0&mdfLevel=null&treeMdfId=278875240&modifmdfid=null&imname=&hybrid=Y&imst=N Cisco Unified Presence version 7.0(5) is available at the following link: http://tools.cisco.com/support/downloads/go/PlatformList.x?sftType=Unified+Presence+Server+%28CUPS%29+Updates&mdfid=281820245&treeName=Voice+and+Unified+Communications&mdfLevel=Software%20Version/Option&url=null&modelName=Cisco+Unified+Presence+Version+7.0&isPlatform=N&treeMdfId=278875240&modifmdfid=null&imname=&hybrid=Y&imst=N Note: Administrators running Cisco Unified Presence version 1.x are encouraged to upgrade to version 6.0 or later. Workarounds =========== No workarounds are available; however, mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory, which is available at the following link: http://www.cisco.com/warp/public/707/cisco-amb-20091014-cup.shtml Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at: http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at: http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to: http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. These vulnerabilities were discovered by Cisco. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20091014-cup.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2009-October-14 | public | | | | release | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at: http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- iD8DBQFK1eiV86n/Gc8U/uARAtI9AKCY7cOV/RqoTcFB0pjPXMW0HXuWWwCePvum 65XRgnU+TCu1veQd+gWlE7g= =uBzn -----END PGP SIGNATURE----- From linux.yahoo at gmail.com Wed Oct 14 11:57:00 2009 From: linux.yahoo at gmail.com (Manu Chao) Date: Wed, 14 Oct 2009 17:57:00 +0200 Subject: [c-nsp] ibgp TTL In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F7CD4F8@XMB-AMS-103.cisco.com> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> <7100ed370910140151x72a0f59fvd1bfd685a9e710a@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD4F8@XMB-AMS-103.cisco.com> Message-ID: <7100ed370910140857l53db6ce9hd355a5d959ede840@mail.gmail.com> Oli, More detail: I have a standard IP/MPLS backbone with MP-iBGP between PEs loopbacks with IS-IS L2 or OSPF area 0 as IGP. This IGP is extended to some non MPLS routers X. In some backbone links failure, IGP allow MP-iBGP to stay UP via X links (non MPLS). This specific IGP design introduce a L3VPN blackhole that can be solved by IGP prefix filtering or by limiting TTL for MP-iBGP sessions, if possible :) On Wed, Oct 14, 2009 at 2:10 PM, Oliver Boehmer (oboehmer) < oboehmer at cisco.com> wrote: > yes, only supported for ebgp. Would be interested about the "very > specific design" and why Manu requires this functionality? > > oli > > > AFAIK this command is for eBGP only, no? > > > > On Tue, Oct 13, 2009 at 10:07 PM, Matlock, Kenneth L > > wrote: > > > > > Router bgp > > > Neighbor ttl-security hops > > > > > > ? > > > > > > Ken Matlock > > > Network Analyst > > > Exempla Healthcare > > > (303) 467-4671 > > > matlockk at exempla.org > > > > > > > > > > > > -----Original Message----- > > > From: cisco-nsp-bounces at puck.nether.net > > > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Manu Chao > > > Sent: Tuesday, October 13, 2009 4:52 AM > > > To: cisco-nsp at puck.nether.net > > > Subject: [c-nsp] ibgp TTL > > > > > > For a very specific design, i need to limit TTL value in > ibgp-multihop. > > > > > > Is it possible to limit iBGP TTL like we do with ebgp-multihop ttl > > > command? > > > > > > Any input appreciated. > > > > > > Manu > > > _______________________________________________ > > > cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From jsahala at gmail.com Wed Oct 14 12:04:19 2009 From: jsahala at gmail.com (joshua sahala) Date: Wed, 14 Oct 2009 10:04:19 -0600 Subject: [c-nsp] 3560 buffering In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> Message-ID: <4b8f66d70910140904j5ba6a1e5v65ba71ee2e4cdcc8@mail.gmail.com> jeff, at a previous employer, all the cisco 3750/3560 switches were scrapped and replaced with 4948s or f10 s50n. the f10 had one of the worst ncurses interfaces i've seen (but, now that they run sftos, the cli is markedly improved). the buffer sizes on the small form-factor cisco switches are too small for anything but a quiet office lan. the exception is the 4948. as others have mentioned, you can play with mls qos/buffer tuning, but, i personally would recommend planning an upgrade to something that is more capable. /joshua -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams - From david.freedman at uk.clara.net Wed Oct 14 12:33:29 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 14 Oct 2009 17:33:29 +0100 Subject: [c-nsp] ibgp TTL In-Reply-To: <7100ed370910140857l53db6ce9hd355a5d959ede840@mail.gmail.com> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> <7100ed370910140151x72a0f59fvd1bfd685a9e710a@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD4F8@XMB-AMS-103.cisco.com> <7100ed370910140857l53db6ce9hd355a5d959ede840@mail.gmail.com> Message-ID: <4AD5FD59.8050203@uk.clara.net> Manu Chao wrote: > Oli, > > More detail: > > I have a standard IP/MPLS backbone with MP-iBGP between PEs loopbacks with > IS-IS L2 or OSPF area 0 as IGP. > > This IGP is extended to some non MPLS routers X. > > In some backbone links failure, IGP allow MP-iBGP to stay UP via X links > (non MPLS). > Assuming you are just doing plain old LDP, How about LDP/IGP Sync? :) http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fsldpsyn.html From david.freedman at uk.clara.net Wed Oct 14 12:33:29 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 14 Oct 2009 17:33:29 +0100 Subject: [c-nsp] ibgp TTL In-Reply-To: <7100ed370910140857l53db6ce9hd355a5d959ede840@mail.gmail.com> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> <7100ed370910140151x72a0f59fvd1bfd685a9e710a@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD4F8@XMB-AMS-103.cisco.com> <7100ed370910140857l53db6ce9hd355a5d959ede840@mail.gmail.com> Message-ID: <4AD5FD59.8050203@uk.clara.net> Manu Chao wrote: > Oli, > > More detail: > > I have a standard IP/MPLS backbone with MP-iBGP between PEs loopbacks with > IS-IS L2 or OSPF area 0 as IGP. > > This IGP is extended to some non MPLS routers X. > > In some backbone links failure, IGP allow MP-iBGP to stay UP via X links > (non MPLS). > Assuming you are just doing plain old LDP, How about LDP/IGP Sync? :) http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fsldpsyn.html From linux.yahoo at gmail.com Wed Oct 14 12:37:47 2009 From: linux.yahoo at gmail.com (Manu Chao) Date: Wed, 14 Oct 2009 18:37:47 +0200 Subject: [c-nsp] ibgp TTL In-Reply-To: <4AD5FD59.8050203@uk.clara.net> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> <7100ed370910140151x72a0f59fvd1bfd685a9e710a@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD4F8@XMB-AMS-103.cisco.com> <7100ed370910140857l53db6ce9hd355a5d959ede840@mail.gmail.com> <4AD5FD59.8050203@uk.clara.net> Message-ID: <7100ed370910140937h4ef5cb76w92cab3fd5f709902@mail.gmail.com> I am running IS-IS :( This feature is not yet supported but it is a good option Thanks for your input On Wed, Oct 14, 2009 at 6:33 PM, David Freedman wrote: > Manu Chao wrote: > > Oli, > > > > More detail: > > > > I have a standard IP/MPLS backbone with MP-iBGP between PEs loopbacks > with > > IS-IS L2 or OSPF area 0 as IGP. > > > > This IGP is extended to some non MPLS routers X. > > > > In some backbone links failure, IGP allow MP-iBGP to stay UP via X links > > (non MPLS). > > > > Assuming you are just doing plain old LDP, How about LDP/IGP Sync? :) > > http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fsldpsyn.html > > From oboehmer at cisco.com Wed Oct 14 12:44:22 2009 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Wed, 14 Oct 2009 18:44:22 +0200 Subject: [c-nsp] ibgp TTL In-Reply-To: <7100ed370910140857l53db6ce9hd355a5d959ede840@mail.gmail.com> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> <7100ed370910140151x72a0f59fvd1bfd685a9e710a@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD4F8@XMB-AMS-103.cisco.com> <7100ed370910140857l53db6ce9hd355a5d959ede840@mail.gmail.com> Message-ID: <6E4D2678AC543844917CA081C9D6B33F7CD75D@XMB-AMS-103.cisco.com> Manu, > More detail: > > I have a standard IP/MPLS backbone with MP-iBGP between PEs loopbacks with > IS-IS L2 or OSPF area 0 as IGP. > > This IGP is extended to some non MPLS routers X. > > In some backbone links failure, IGP allow MP-iBGP to stay UP?via X?links > (non MPLS). > > This specific IGP design introduce a L3VPN blackhole that can be solved by > IGP prefix filtering?or by limiting TTL for MP-iBGP sessions, if possible :) Hmm, you could also cause iBGP session to fail if you just add an interface ACL not allowing iBGP between your PEs across the links not running MPLS. Not sure if there is any real solution to this, other than increasing the link metric towards the "non-MPLS-capble part" so much that MPLS packets will not cross these links (or turn this part of the network into a stub area to achieve the same). oli > On Wed, Oct 14, 2009 at 2:10 PM, Oliver Boehmer (oboehmer) > wrote: > yes, only supported for ebgp. Would be interested about the "very > specific design" and why Manu requires this functionality? > > ? ? ? ?oli > > > AFAIK this command is for eBGP only, no? > > > > On Tue, Oct 13, 2009 at 10:07 PM, Matlock, Kenneth L > > wrote: > > > > > Router bgp > > > Neighbor ttl-security hops > > > > > > ? > > > > > > Ken Matlock > > > Network Analyst > > > Exempla Healthcare > > > (303) 467-4671 > > > matlockk at exempla.org > > > > > > > > > > > > -----Original Message----- > > > From: cisco-nsp-bounces at puck.nether.net > > > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Manu Chao > > > Sent: Tuesday, October 13, 2009 4:52 AM > > > To: cisco-nsp at puck.nether.net > > > Subject: [c-nsp] ibgp TTL > > > > > > For a very specific design, i need to limit TTL value in > ibgp-multihop. > > > > > > Is it possible to limit iBGP TTL like we do with ebgp-multihop ttl > > > command? > > > > > > Any input appreciated. > > > > > > Manu > > > ?_______________________________________________ > > > cisco-nsp mailing list ?cisco-nsp at 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 at puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ From david.freedman at uk.clara.net Wed Oct 14 12:57:41 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 14 Oct 2009 17:57:41 +0100 Subject: [c-nsp] ibgp TTL In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F7CD75D@XMB-AMS-103.cisco.com> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> <7100ed370910140151x72a0f59fvd1bfd685a9e710a@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD4F8@XMB-AMS-103.cisco.com> <7100ed370910140857l53db6ce9hd355a5d959ede840@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD75D@XMB-AMS-103.cisco.com> Message-ID: <4AD60305.5080702@uk.clara.net> How about explicit path TE with no autoroute announce (and only statics for these dedicated iBGP loopbacks?) > Manu, > >> More detail: >> >> I have a standard IP/MPLS backbone with MP-iBGP between PEs loopbacks with >> IS-IS L2 or OSPF area 0 as IGP. >> >> This IGP is extended to some non MPLS routers X. >> >> In some backbone links failure, IGP allow MP-iBGP to stay UP via X links >> (non MPLS). >> >> This specific IGP design introduce a L3VPN blackhole that can be solved by >> IGP prefix filtering or by limiting TTL for MP-iBGP sessions, if possible :) > > Hmm, you could also cause iBGP session to fail if you just add an interface ACL not allowing iBGP between your PEs across the links not running MPLS. > > Not sure if there is any real solution to this, other than increasing the link metric towards the "non-MPLS-capble part" so much that MPLS packets will not cross these links (or turn this part of the network into a stub area to achieve the same). > > oli > > > >> On Wed, Oct 14, 2009 at 2:10 PM, Oliver Boehmer (oboehmer) >> wrote: >> yes, only supported for ebgp. Would be interested about the "very >> specific design" and why Manu requires this functionality? >> >> oli >> >>> AFAIK this command is for eBGP only, no? >>> >>> On Tue, Oct 13, 2009 at 10:07 PM, Matlock, Kenneth L >>> wrote: >>> >>>> Router bgp >>>> Neighbor ttl-security hops >>>> >>>> ? >>>> >>>> Ken Matlock >>>> Network Analyst >>>> Exempla Healthcare >>>> (303) 467-4671 >>>> matlockk at exempla.org >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: cisco-nsp-bounces at puck.nether.net >>>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Manu Chao >>>> Sent: Tuesday, October 13, 2009 4:52 AM >>>> To: cisco-nsp at puck.nether.net >>>> Subject: [c-nsp] ibgp TTL >>>> >>>> For a very specific design, i need to limit TTL value in >> ibgp-multihop. >>>> Is it possible to limit iBGP TTL like we do with ebgp-multihop ttl >>>> command? >>>> >>>> Any input appreciated. >>>> >>>> Manu >>>> _______________________________________________ >>>> cisco-nsp mailing list cisco-nsp at 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 at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From david.freedman at uk.clara.net Wed Oct 14 12:57:41 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 14 Oct 2009 17:57:41 +0100 Subject: [c-nsp] ibgp TTL In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F7CD75D@XMB-AMS-103.cisco.com> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> <7100ed370910140151x72a0f59fvd1bfd685a9e710a@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD4F8@XMB-AMS-103.cisco.com> <7100ed370910140857l53db6ce9hd355a5d959ede840@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD75D@XMB-AMS-103.cisco.com> Message-ID: <4AD60305.5080702@uk.clara.net> How about explicit path TE with no autoroute announce (and only statics for these dedicated iBGP loopbacks?) > Manu, > >> More detail: >> >> I have a standard IP/MPLS backbone with MP-iBGP between PEs loopbacks with >> IS-IS L2 or OSPF area 0 as IGP. >> >> This IGP is extended to some non MPLS routers X. >> >> In some backbone links failure, IGP allow MP-iBGP to stay UP via X links >> (non MPLS). >> >> This specific IGP design introduce a L3VPN blackhole that can be solved by >> IGP prefix filtering or by limiting TTL for MP-iBGP sessions, if possible :) > > Hmm, you could also cause iBGP session to fail if you just add an interface ACL not allowing iBGP between your PEs across the links not running MPLS. > > Not sure if there is any real solution to this, other than increasing the link metric towards the "non-MPLS-capble part" so much that MPLS packets will not cross these links (or turn this part of the network into a stub area to achieve the same). > > oli > > > >> On Wed, Oct 14, 2009 at 2:10 PM, Oliver Boehmer (oboehmer) >> wrote: >> yes, only supported for ebgp. Would be interested about the "very >> specific design" and why Manu requires this functionality? >> >> oli >> >>> AFAIK this command is for eBGP only, no? >>> >>> On Tue, Oct 13, 2009 at 10:07 PM, Matlock, Kenneth L >>> wrote: >>> >>>> Router bgp >>>> Neighbor ttl-security hops >>>> >>>> ? >>>> >>>> Ken Matlock >>>> Network Analyst >>>> Exempla Healthcare >>>> (303) 467-4671 >>>> matlockk at exempla.org >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: cisco-nsp-bounces at puck.nether.net >>>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Manu Chao >>>> Sent: Tuesday, October 13, 2009 4:52 AM >>>> To: cisco-nsp at puck.nether.net >>>> Subject: [c-nsp] ibgp TTL >>>> >>>> For a very specific design, i need to limit TTL value in >> ibgp-multihop. >>>> Is it possible to limit iBGP TTL like we do with ebgp-multihop ttl >>>> command? >>>> >>>> Any input appreciated. >>>> >>>> Manu >>>> _______________________________________________ >>>> cisco-nsp mailing list cisco-nsp at 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 at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From pl+list at pmacct.net Wed Oct 14 13:26:51 2009 From: pl+list at pmacct.net (Paolo Lucente) Date: Wed, 14 Oct 2009 18:26:51 +0100 Subject: [c-nsp] ASN statistic tools In-Reply-To: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> References: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> Message-ID: <20091014172651.GA27128@london.pmacct.net> Hi, You can certainly have a look to the following page which captures a number of NetFlow collector packages (free and commercial) available around. I'm sure most of them are supporting ASNs: http://www.switch.ch/network/projects/completed/TF-NGN/floma/software.html If you are looking at something that goes a bit further than simply grabbing peer/origin AS numbers from within NetFlow packets (and possibly aggregating/accounting), i would like to point you a presentation i gave recently (09/2009) at UKNOF and SwiNOG: "Introducing BGP natively into a NetFlow/sFlow collector": http://www.pmacct.net/lucente_pmacct_uknof14.pdf In short, this allows to join accounting information (NetFlow) and routing information (BGP). Main outcomes are: a) ability to correlate peer and origin AS numbers (and not having to choose one of them) and b) get insight of traffic levels on primitives like AS-PATH, BGP communities, Local Preference, etc. Hope it could be of interest. Cheers, Paolo On Wed, Oct 14, 2009 at 08:52:27AM +0300, RAZAFINDRATSIFA Rivo Tahina wrote: > Daer All, > > I'm looking for utilities which allow to have ASN statistics, the > netflow tools I tried doesn't do that, any idea? > > BR From gsgranados at comcast.net Wed Oct 14 13:28:45 2009 From: gsgranados at comcast.net (Scott Granados) Date: Wed, 14 Oct 2009 10:28:45 -0700 Subject: [c-nsp] ASA5520 IPSEC and windows mobile? Message-ID: <01de01ca4cf3$ccd86ca0$2408120a@am.thmulti.com> Hi, Has anyone successfuly configured the ASA5520 to accept VPN connections from windows mobile 6.1 devices? I can't figure out how to define a tunnel-group and google results aren't helping much. I saw one example where you put the username/tunnel so something like sgranados/internal-is-access but that doesn't seem to work. Any pointers would be appreciated. Thanks Scott From linux.yahoo at gmail.com Wed Oct 14 14:07:58 2009 From: linux.yahoo at gmail.com (Manu Chao) Date: Wed, 14 Oct 2009 20:07:58 +0200 Subject: [c-nsp] ibgp TTL In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F7CD75D@XMB-AMS-103.cisco.com> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> <7100ed370910140151x72a0f59fvd1bfd685a9e710a@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD4F8@XMB-AMS-103.cisco.com> <7100ed370910140857l53db6ce9hd355a5d959ede840@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD75D@XMB-AMS-103.cisco.com> Message-ID: <7100ed370910141107j7718c4a7n31b092f22fbd3a60@mail.gmail.com> Thank you Oli, OSPF stub area or IS-IS Level 1 was the better option compared to ACL on the non-MPLS router because routing control stay under MPLS backbone control Increasing metric is useless because non MPLS path must NEVER be used On Wed, Oct 14, 2009 at 6:44 PM, Oliver Boehmer (oboehmer) < oboehmer at cisco.com> wrote: > Manu, > > > More detail: > > > > I have a standard IP/MPLS backbone with MP-iBGP between PEs loopbacks > with > > IS-IS L2 or OSPF area 0 as IGP. > > > > This IGP is extended to some non MPLS routers X. > > > > In some backbone links failure, IGP allow MP-iBGP to stay UP via X links > > (non MPLS). > > > > This specific IGP design introduce a L3VPN blackhole that can be solved > by > > IGP prefix filtering or by limiting TTL for MP-iBGP sessions, if possible > :) > > Hmm, you could also cause iBGP session to fail if you just add an interface > ACL not allowing iBGP between your PEs across the links not running MPLS. > > Not sure if there is any real solution to this, other than increasing the > link metric towards the "non-MPLS-capble part" so much that MPLS packets > will not cross these links (or turn this part of the network into a stub > area to achieve the same). > > oli > > > > > On Wed, Oct 14, 2009 at 2:10 PM, Oliver Boehmer (oboehmer) > > wrote: > > yes, only supported for ebgp. Would be interested about the "very > > specific design" and why Manu requires this functionality? > > > > oli > > > > > AFAIK this command is for eBGP only, no? > > > > > > On Tue, Oct 13, 2009 at 10:07 PM, Matlock, Kenneth L > > > wrote: > > > > > > > Router bgp > > > > Neighbor ttl-security hops > > > > > > > > ? > > > > > > > > Ken Matlock > > > > Network Analyst > > > > Exempla Healthcare > > > > (303) 467-4671 > > > > matlockk at exempla.org > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: cisco-nsp-bounces at puck.nether.net > > > > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Manu Chao > > > > Sent: Tuesday, October 13, 2009 4:52 AM > > > > To: cisco-nsp at puck.nether.net > > > > Subject: [c-nsp] ibgp TTL > > > > > > > > For a very specific design, i need to limit TTL value in > > ibgp-multihop. > > > > > > > > Is it possible to limit iBGP TTL like we do with ebgp-multihop ttl > > > > command? > > > > > > > > Any input appreciated. > > > > > > > > Manu > > > > _______________________________________________ > > > > cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > From A.L.M.Buxey at lboro.ac.uk Wed Oct 14 14:19:10 2009 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Wed, 14 Oct 2009 19:19:10 +0100 Subject: [c-nsp] monitoring switch stacks Message-ID: <20091014181910.GC5236@lboro.ac.uk> hi, just wondered what folk did out there to monitor switch stacks (eg stackwise+ switch stacks like 3750e, 2975gs etc (not the older gigastack ones....) ) - using the basic methods such as ICMP will only show the presence of connectivity to the stack but not the actual health of the stack - eg one member is missing. I'm looking at maybe SNMP but support for MIBS in stacks seems somewhat poor and that leaves the syslog method to alert when something happens to the stack... best practice? alan From dwcarder at wisc.edu Wed Oct 14 14:34:42 2009 From: dwcarder at wisc.edu (Dale W. Carder) Date: Wed, 14 Oct 2009 13:34:42 -0500 Subject: [c-nsp] monitoring switch stacks In-Reply-To: <20091014181910.GC5236@lboro.ac.uk> References: <20091014181910.GC5236@lboro.ac.uk> Message-ID: On Oct 14, 2009, at 1:19 PM, Alan Buxey wrote: > > just wondered what folk did out there to monitor switch stacks > (eg stackwise+ switch stacks like 3750e, 2975gs etc (not the older > gigastack ones....) ) - using the basic methods such as ICMP will > only show the presence of connectivity to the stack but not the > actual health of the stack - eg one member is missing. I'm looking > at maybe SNMP but support for MIBS in stacks seems somewhat poor They show up fine, at least on recent code. On earlier versions of code (2 years ago or so), it was very buggy and was not reliable. We monitor the following. There have been occasions when the switch stack ports fail and this caught it. Cheers, Dale IF-MIB::ifDescr.5365 = STRING: StackPort1 IF-MIB::ifDescr.5366 = STRING: StackSub-St1-1 IF-MIB::ifDescr.5367 = STRING: StackSub-St1-2 IF-MIB::ifDescr.5368 = STRING: StackPort2 IF-MIB::ifDescr.5369 = STRING: StackSub-St2-1 IF-MIB::ifDescr.5370 = STRING: StackSub-St2-2 IF-MIB::ifDescr.5371 = STRING: StackPort3 IF-MIB::ifDescr.5372 = STRING: StackSub-St3-1 IF-MIB::ifDescr.5373 = STRING: StackSub-St3-2 IF-MIB::ifOperStatus.5365 = INTEGER: up(1) IF-MIB::ifOperStatus.5366 = INTEGER: up(1) IF-MIB::ifOperStatus.5367 = INTEGER: up(1) IF-MIB::ifOperStatus.5368 = INTEGER: up(1) IF-MIB::ifOperStatus.5369 = INTEGER: up(1) IF-MIB::ifOperStatus.5370 = INTEGER: up(1) IF-MIB::ifOperStatus.5371 = INTEGER: up(1) IF-MIB::ifOperStatus.5372 = INTEGER: up(1) IF-MIB::ifOperStatus.5373 = INTEGER: up(1) CISCO-STACKWISE-MIB::cswSwitchState.1001 = INTEGER: ready(4) CISCO-STACKWISE-MIB::cswSwitchState.2001 = INTEGER: ready(4) CISCO-STACKWISE-MIB::cswSwitchState.3001 = INTEGER: ready(4) From moua0100 at umn.edu Wed Oct 14 14:59:45 2009 From: moua0100 at umn.edu (Ge Moua) Date: Wed, 14 Oct 2009 13:59:45 -0500 Subject: [c-nsp] monitoring switch stacks In-Reply-To: References: <20091014181910.GC5236@lboro.ac.uk> Message-ID: <4AD61FA1.4040109@umn.edu> Dale Carder- Are you guys also monitoring queue drops on the interfaces too; if so can you forward me the OID? Regards, Ge Moua | Email: moua0100 at umn.edu Network Design Engineer University of Minnesota | Networking & Telecommunications Services Dale W. Carder wrote: > > On Oct 14, 2009, at 1:19 PM, Alan Buxey wrote: >> >> just wondered what folk did out there to monitor switch stacks >> (eg stackwise+ switch stacks like 3750e, 2975gs etc (not the older >> gigastack ones....) ) - using the basic methods such as ICMP will >> only show the presence of connectivity to the stack but not the >> actual health of the stack - eg one member is missing. I'm looking >> at maybe SNMP but support for MIBS in stacks seems somewhat poor > > They show up fine, at least on recent code. On earlier > versions of code (2 years ago or so), it was very buggy > and was not reliable. > > We monitor the following. There have been occasions when > the switch stack ports fail and this caught it. > > Cheers, > Dale > > IF-MIB::ifDescr.5365 = STRING: StackPort1 > IF-MIB::ifDescr.5366 = STRING: StackSub-St1-1 > IF-MIB::ifDescr.5367 = STRING: StackSub-St1-2 > IF-MIB::ifDescr.5368 = STRING: StackPort2 > IF-MIB::ifDescr.5369 = STRING: StackSub-St2-1 > IF-MIB::ifDescr.5370 = STRING: StackSub-St2-2 > IF-MIB::ifDescr.5371 = STRING: StackPort3 > IF-MIB::ifDescr.5372 = STRING: StackSub-St3-1 > IF-MIB::ifDescr.5373 = STRING: StackSub-St3-2 > > IF-MIB::ifOperStatus.5365 = INTEGER: up(1) > IF-MIB::ifOperStatus.5366 = INTEGER: up(1) > IF-MIB::ifOperStatus.5367 = INTEGER: up(1) > IF-MIB::ifOperStatus.5368 = INTEGER: up(1) > IF-MIB::ifOperStatus.5369 = INTEGER: up(1) > IF-MIB::ifOperStatus.5370 = INTEGER: up(1) > IF-MIB::ifOperStatus.5371 = INTEGER: up(1) > IF-MIB::ifOperStatus.5372 = INTEGER: up(1) > IF-MIB::ifOperStatus.5373 = INTEGER: up(1) > > CISCO-STACKWISE-MIB::cswSwitchState.1001 = INTEGER: ready(4) > CISCO-STACKWISE-MIB::cswSwitchState.2001 = INTEGER: ready(4) > CISCO-STACKWISE-MIB::cswSwitchState.3001 = INTEGER: ready(4) > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From ANDY.WEBSTER at illinois.gov Wed Oct 14 15:01:50 2009 From: ANDY.WEBSTER at illinois.gov (Webster, Andy) Date: Wed, 14 Oct 2009 14:01:50 -0500 Subject: [c-nsp] Es20+ card and licensing question Message-ID: Hi, I'm looking at the ES20+ cards for 7600s and I am confused by the licensing options. There are two license options 76-ES+BASIC and 76-ES+ADVIP. Do I need to purchase one of these two options for each ES20+ card or is it possible to run the card without either license? Is each license linked to a specific card? Do I just purchase enough licenses to cover the cards I have in use and forget about it? Are the licenses each linked to a specific card's serial number? What happens if I rma the ES20+ card? Would I have to get the old card's license associated with the new rma'd card? I see that Layer 3 IP/MPLS VPN requires the 76-ES+ADVIP license. I figure that means as soon as I put 'vrf forwarding test' on an ES20+ interface and pass some traffic over it the 76-ES+ADVIP license is required. Am I correct about that? Thanks in advance, Andy Webster From dwcarder at wisc.edu Wed Oct 14 15:18:26 2009 From: dwcarder at wisc.edu (Dale W. Carder) Date: Wed, 14 Oct 2009 14:18:26 -0500 Subject: [c-nsp] monitoring switch stacks In-Reply-To: <4AD61FA1.4040109@umn.edu> References: <20091014181910.GC5236@lboro.ac.uk> <4AD61FA1.4040109@umn.edu> Message-ID: <4E6002A6-C251-4AF0-91D8-7B811228267F@wisc.edu> Hey Ge! We monitor for input queue drops on 6500's with this oid: .1.3.6.1.4.1.9.9.276.1.1.1.1.10 Our alert for the NOC is drops > 100/sec results in a major alarm. Usually it's something stupid happening on a given vlan that needs to be beat down. For SVI's, this goes hand in hand with punts causing cpu exhaustion on these wimpy RP's. I've thought about watching output queue drops, but am not sure how to how to differentiate normal from abnormal. Dale On Oct 14, 2009, at 1:59 PM, Ge Moua wrote: > Dale Carder- > Are you guys also monitoring queue drops on the interfaces too; if > so can you forward me the OID? > > Regards, > Ge Moua | Email: moua0100 at umn.edu > > Network Design Engineer > University of Minnesota | Networking & Telecommunications Services > > > > Dale W. Carder wrote: >> >> On Oct 14, 2009, at 1:19 PM, Alan Buxey wrote: >>> >>> just wondered what folk did out there to monitor switch stacks >>> (eg stackwise+ switch stacks like 3750e, 2975gs etc (not the older >>> gigastack ones....) ) - using the basic methods such as ICMP will >>> only show the presence of connectivity to the stack but not the >>> actual health of the stack - eg one member is missing. I'm looking >>> at maybe SNMP but support for MIBS in stacks seems somewhat poor >> >> They show up fine, at least on recent code. On earlier >> versions of code (2 years ago or so), it was very buggy >> and was not reliable. >> >> We monitor the following. There have been occasions when >> the switch stack ports fail and this caught it. >> >> Cheers, >> Dale >> >> IF-MIB::ifDescr.5365 = STRING: StackPort1 >> IF-MIB::ifDescr.5366 = STRING: StackSub-St1-1 >> IF-MIB::ifDescr.5367 = STRING: StackSub-St1-2 >> IF-MIB::ifDescr.5368 = STRING: StackPort2 >> IF-MIB::ifDescr.5369 = STRING: StackSub-St2-1 >> IF-MIB::ifDescr.5370 = STRING: StackSub-St2-2 >> IF-MIB::ifDescr.5371 = STRING: StackPort3 >> IF-MIB::ifDescr.5372 = STRING: StackSub-St3-1 >> IF-MIB::ifDescr.5373 = STRING: StackSub-St3-2 >> >> IF-MIB::ifOperStatus.5365 = INTEGER: up(1) >> IF-MIB::ifOperStatus.5366 = INTEGER: up(1) >> IF-MIB::ifOperStatus.5367 = INTEGER: up(1) >> IF-MIB::ifOperStatus.5368 = INTEGER: up(1) >> IF-MIB::ifOperStatus.5369 = INTEGER: up(1) >> IF-MIB::ifOperStatus.5370 = INTEGER: up(1) >> IF-MIB::ifOperStatus.5371 = INTEGER: up(1) >> IF-MIB::ifOperStatus.5372 = INTEGER: up(1) >> IF-MIB::ifOperStatus.5373 = INTEGER: up(1) >> >> CISCO-STACKWISE-MIB::cswSwitchState.1001 = INTEGER: ready(4) >> CISCO-STACKWISE-MIB::cswSwitchState.2001 = INTEGER: ready(4) >> CISCO-STACKWISE-MIB::cswSwitchState.3001 = INTEGER: ready(4) >> >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp at puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ From moua0100 at umn.edu Wed Oct 14 15:46:53 2009 From: moua0100 at umn.edu (Ge Moua) Date: Wed, 14 Oct 2009 14:46:53 -0500 Subject: [c-nsp] monitoring switch stacks In-Reply-To: <4E6002A6-C251-4AF0-91D8-7B811228267F@wisc.edu> References: <20091014181910.GC5236@lboro.ac.uk> <4AD61FA1.4040109@umn.edu> <4E6002A6-C251-4AF0-91D8-7B811228267F@wisc.edu> Message-ID: <4AD62AAD.1090803@umn.edu> Dale, are you guys monitoring queue drops on the edge switches like a Cisco 3750? If so, I'm thinking the OID will be slightly different? Thanks for the reply ! Regards, Ge Moua | Email: moua0100 at umn.edu Network Design Engineer University of Minnesota | Networking & Telecommunications Services Dale W. Carder wrote: > > Hey Ge! > > We monitor for input queue drops on 6500's with this oid: > > .1.3.6.1.4.1.9.9.276.1.1.1.1.10 > > Our alert for the NOC is drops > 100/sec results in a > major alarm. Usually it's something stupid happening on > a given vlan that needs to be beat down. For SVI's, this > goes hand in hand with punts causing cpu exhaustion on > these wimpy RP's. > > I've thought about watching output queue drops, but am not > sure how to how to differentiate normal from abnormal. > > Dale > > > On Oct 14, 2009, at 1:59 PM, Ge Moua wrote: > >> Dale Carder- >> Are you guys also monitoring queue drops on the interfaces too; if so >> can you forward me the OID? >> >> Regards, >> Ge Moua | Email: moua0100 at umn.edu >> >> Network Design Engineer >> University of Minnesota | Networking & Telecommunications Services >> >> >> >> Dale W. Carder wrote: >>> >>> On Oct 14, 2009, at 1:19 PM, Alan Buxey wrote: >>>> >>>> just wondered what folk did out there to monitor switch stacks >>>> (eg stackwise+ switch stacks like 3750e, 2975gs etc (not the older >>>> gigastack ones....) ) - using the basic methods such as ICMP will >>>> only show the presence of connectivity to the stack but not the >>>> actual health of the stack - eg one member is missing. I'm looking >>>> at maybe SNMP but support for MIBS in stacks seems somewhat poor >>> >>> They show up fine, at least on recent code. On earlier >>> versions of code (2 years ago or so), it was very buggy >>> and was not reliable. >>> >>> We monitor the following. There have been occasions when >>> the switch stack ports fail and this caught it. >>> >>> Cheers, >>> Dale >>> >>> IF-MIB::ifDescr.5365 = STRING: StackPort1 >>> IF-MIB::ifDescr.5366 = STRING: StackSub-St1-1 >>> IF-MIB::ifDescr.5367 = STRING: StackSub-St1-2 >>> IF-MIB::ifDescr.5368 = STRING: StackPort2 >>> IF-MIB::ifDescr.5369 = STRING: StackSub-St2-1 >>> IF-MIB::ifDescr.5370 = STRING: StackSub-St2-2 >>> IF-MIB::ifDescr.5371 = STRING: StackPort3 >>> IF-MIB::ifDescr.5372 = STRING: StackSub-St3-1 >>> IF-MIB::ifDescr.5373 = STRING: StackSub-St3-2 >>> >>> IF-MIB::ifOperStatus.5365 = INTEGER: up(1) >>> IF-MIB::ifOperStatus.5366 = INTEGER: up(1) >>> IF-MIB::ifOperStatus.5367 = INTEGER: up(1) >>> IF-MIB::ifOperStatus.5368 = INTEGER: up(1) >>> IF-MIB::ifOperStatus.5369 = INTEGER: up(1) >>> IF-MIB::ifOperStatus.5370 = INTEGER: up(1) >>> IF-MIB::ifOperStatus.5371 = INTEGER: up(1) >>> IF-MIB::ifOperStatus.5372 = INTEGER: up(1) >>> IF-MIB::ifOperStatus.5373 = INTEGER: up(1) >>> >>> CISCO-STACKWISE-MIB::cswSwitchState.1001 = INTEGER: ready(4) >>> CISCO-STACKWISE-MIB::cswSwitchState.2001 = INTEGER: ready(4) >>> CISCO-STACKWISE-MIB::cswSwitchState.3001 = INTEGER: ready(4) >>> >>> _______________________________________________ >>> cisco-nsp mailing list cisco-nsp at puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ > From kgraham at industrial-marshmallow.com Wed Oct 14 15:37:22 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Wed, 14 Oct 2009 12:37:22 -0700 (PDT) Subject: [c-nsp] monitoring switch stacks In-Reply-To: <20091014181910.GC5236@lboro.ac.uk> References: <20091014181910.GC5236@lboro.ac.uk> Message-ID: <324945.5430.qm@web506.biz.mail.mud.yahoo.com> > just wondered what folk did out there to monitor switch stacks > (eg stackwise+ switch stacks like 3750e, 2975gs etc (not the older > gigastack ones....) ) - using the basic methods such as ICMP will > only show the presence of connectivity to the stack but not the > actual health of the stack - eg one member is missing. Perhaps the easiest for this is walking: CISCO-STACKWISE-MIB::cswStackPortOperStatus ...to handle non-stackables or non-stacked stackables, we ignore on a NOSUCHOBJECT or where row count is <= 2. After those conditions are satisfied, its reasonable to alert on >= 1 ports in a state other than up(1). Stack ports from missing members will still be there (and obviously in a non-up operStatus), so you catch that state as well as a partially-cabled stack. For example, this is a 2 switch stack with a missing member: CISCO-STACKWISE-MIB::cswStackPortOperStatus.5180 = INTEGER: down(2) CISCO-STACKWISE-MIB::cswStackPortOperStatus.5181 = INTEGER: down(2) CISCO-STACKWISE-MIB::cswStackPortOperStatus.5183 = INTEGER: down(2) CISCO-STACKWISE-MIB::cswStackPortOperStatus.5184 = INTEGER: down(2) ...and this is a 4 switch stack with a broken cable: CISCO-STACKWISE-MIB::cswStackPortOperStatus.5366 = INTEGER: down(2) CISCO-STACKWISE-MIB::cswStackPortOperStatus.5367 = INTEGER: up(1) CISCO-STACKWISE-MIB::cswStackPortOperStatus.5369 = INTEGER: up(1) CISCO-STACKWISE-MIB::cswStackPortOperStatus.5370 = INTEGER: down(2) CISCO-STACKWISE-MIB::cswStackPortOperStatus.5372 = INTEGER: up(1) CISCO-STACKWISE-MIB::cswStackPortOperStatus.5373 = INTEGER: up(1) CISCO-STACKWISE-MIB::cswStackPortOperStatus.5375 = INTEGER: up(1) CISCO-STACKWISE-MIB::cswStackPortOperStatus.5376 = INTEGER: up(1) We had _really_ hoped to also catch 'flapping' stack ports by watching ifLastChange (since healthy stack ports never change state), but CSCsr85997 killed that idea. I would be elated to see CISCO-SWITCH-HARDWARE-CAPACITY-MIB or its equivalent for these switches (given their limited and variably sized resources), but it seems unlikely that will ever happen... From dale.shaw+cisco-nsp at gmail.com Wed Oct 14 18:52:13 2009 From: dale.shaw+cisco-nsp at gmail.com (Dale Shaw) Date: Thu, 15 Oct 2009 09:52:13 +1100 Subject: [c-nsp] Es20+ card and licensing question In-Reply-To: References: Message-ID: <3329cbb40910141552p24f37b12kcaf8876a4f9462ce@mail.gmail.com> Hi Andy, On Thu, Oct 15, 2009 at 6:01 AM, Webster, Andy wrote: > Hi, > ? ? ? ?I'm looking at the ES20+ cards for 7600s and I am confused by > the licensing options. ?There are two license options 76-ES+BASIC and > 76-ES+ADVIP. ?Do I need to purchase one of these two options for each > ES20+ card or is it possible to run the card without either license? 76-ES20-BASIC-LIC is a $0 line item with the purchase of the card itself. If you want/need 76-ES20-ADVIP-LIC, that's $extra. In both cases you need one license per card (no big deal with the $0 basic license, obviously). I don't have any first hand experience with these gadgets so I can't help with your other questions, sorry. I just ran it (a 7600-ES20-GE3C=) through the configuration tool [1]. cheers, Dale [1] https://tools.cisco.com/qtc/config/jsp/configureHome.jsp From z at amused.net Wed Oct 14 18:57:53 2009 From: z at amused.net (Patrick Cole) Date: Thu, 15 Oct 2009 09:57:53 +1100 Subject: [c-nsp] L2TP LNS issue In-Reply-To: <4AD5CE7B.1000700@uk.clara.net> References: <20091013110031.GA15189@amused.net> <4AD5CE7B.1000700@uk.clara.net> Message-ID: <20091014225753.GA17512@amused.net> Dave, Negative - the ppp doesn't even get to IPCP stage and defaultroute is not turned on. On another note, I tested a cisco and the LAC and it's working fine with the same config so must be something with pppd/xl2tpd. I've used this config before with l2tpns but never tried with IOS before. Not a big drama, just annoying. Pat Wed, Oct 14, 2009 at 02:13:31PM +0100, David Freedman wrote: > Silly (semi-related) question, but I (hope) you are not installing a > default to ppp0 on your *nix box when the session comes up, or if you > are, you have a static via your main nic to the l2tp endpoint address, > else you will cause the tunnel to fall down due to recursion. > > Dave. > From ml at kenweb.org Wed Oct 14 23:03:35 2009 From: ml at kenweb.org (ML) Date: Wed, 14 Oct 2009 23:03:35 -0400 Subject: [c-nsp] IPv6 on ME3400 Message-ID: <4AD69107.6010303@kenweb.org> I've got a customer that *needs* a 1-2 RU router that handles IPv6 in hardware. I know the 3650/3750 can handle but I only need at most 4 SFP ports. The ME-3400G-2CS-A is perfect. However I know IPv6 was just added to this platform. Can anyone confirm the quality of IPv6 functionality on this platform? I don't need anything special: OSPFv3, BGP4 (maybe), IPv6 multicast (in the future). Thanks From sony.scaria at gmail.com Wed Oct 14 23:19:19 2009 From: sony.scaria at gmail.com (Sony Scaria) Date: Thu, 15 Oct 2009 08:49:19 +0530 Subject: [c-nsp] Flexwan module - Memory Message-ID: I noticed the following on my cisco 6509E, Switch02#dir ? /all List all files /recursive List files recursively all-filesystems List files on all filesystems bootflash: Directory or file name const_nvram: Directory or file name cwan1/0-disk0: Directory or file name cwan1/1-disk0: Directory or file name disk0: Directory or file name disk1: Directory or file name null: Directory or file name nvram: Directory or file name sup-bootflash: Directory or file name sup-image: Directory or file name sup-microcode: Directory or file name system: Directory or file name Switch02#dir cwan1/0-disk0: Directory of cwan1/0-disk0:/ 1 -rw- 56829 Apr 16 2008 17:06:10 +00:00 running-config 128167936 bytes total (128110592 bytes free) Switch02#dir cwan1/1-disk0: Directory of cwan1/1-disk0:/ No files in directory 128167936 bytes total (128167936 bytes free) My doubt are 1. whether these cwan1/0-disk0: and cwan1/1-disk0: are builtin flash modules on Flexwan module? 2. if so can i upload my IOS in those modules becoz, my current flash size will not support my new IOS 3. If #2 is okay, is it a best practise? thanks Sony From dwcarder at wisc.edu Wed Oct 14 23:47:29 2009 From: dwcarder at wisc.edu (Dale W. Carder) Date: Wed, 14 Oct 2009 22:47:29 -0500 Subject: [c-nsp] IPv6 on ME3400 In-Reply-To: <4AD69107.6010303@kenweb.org> References: <4AD69107.6010303@kenweb.org> Message-ID: <69D1761D-500A-4A86-BF5F-0F11C15D4E0F@wisc.edu> On Oct 14, 2009, at 10:03 PM, ML wrote: > I've got a customer that *needs* a 1-2 RU router that handles IPv6 > in hardware. I know the 3650/3750 can handle but I only need at > most 4 SFP ports. The ME-3400G-2CS-A is perfect. However I know > IPv6 was just added to this platform. Can anyone confirm the > quality of IPv6 functionality on this platform? Make sure what you want to do fits in the "sdm profile". Carving up tcam for ipv6 steals from other areas like mac addrs, vlans, v4 routes and such. Also, no uRPF is a big step backwards in functionality. Dale From ml at kenweb.org Wed Oct 14 23:54:25 2009 From: ml at kenweb.org (ML) Date: Wed, 14 Oct 2009 23:54:25 -0400 Subject: [c-nsp] IPv6 on ME3400 In-Reply-To: <69D1761D-500A-4A86-BF5F-0F11C15D4E0F@wisc.edu> References: <4AD69107.6010303@kenweb.org> <69D1761D-500A-4A86-BF5F-0F11C15D4E0F@wisc.edu> Message-ID: <4AD69CF1.6020503@kenweb.org> Dale W. Carder wrote: > On Oct 14, 2009, at 10:03 PM, ML wrote: >> I've got a customer that *needs* a 1-2 RU router that handles IPv6 in >> hardware. I know the 3650/3750 can handle but I only need at most 4 >> SFP ports. The ME-3400G-2CS-A is perfect. However I know IPv6 was >> just added to this platform. Can anyone confirm the quality of IPv6 >> functionality on this platform? > > Make sure what you want to do fits in the "sdm profile". > Carving up tcam for ipv6 steals from other areas like > mac addrs, vlans, v4 routes and such. > > Also, no uRPF is a big step backwards in functionality. > > Dale > > Speaking of uRPF does anyone have it working at all on the ME3400. I've yet to find a working configuration. Far as I can tell Cisco said they had it but never delivered. From sony.scaria at gmail.com Thu Oct 15 00:33:59 2009 From: sony.scaria at gmail.com (Sony Scaria) Date: Thu, 15 Oct 2009 10:03:59 +0530 Subject: [c-nsp] Flexwan module - Memory In-Reply-To: <328314.36901.qm@web503.biz.mail.mud.yahoo.com> References: <328314.36901.qm@web503.biz.mail.mud.yahoo.com> Message-ID: Thanks a lot Kevin, one more doubt pls, then what is the purpose of Flash in Flexman? Rgds/ Sony On Thu, Oct 15, 2009 at 9:48 AM, Kevin Graham < kgraham at industrial-marshmallow.com> wrote: > > > > > > My doubt are 1. whether these cwan1/0-disk0: and cwan1/1-disk0: are > builtin > > flash modules on Flexwan module? > > Yes. > > > 2. if so can i upload my IOS in those modules > > No. FlexWAN (as with all linecards) boots after the MSFC/Sup. Its devices > are inaccessible from either Sup or MSFC ROMMON. > > > becoz, my current flash size will not support my new IOS > > Presumably this is is a Sup2/MSFC2? If so, just use a CompactFlash card in > a PCMCIA adapter (which will be presented as 'disk0'. I haven't tested > how large of cards are accepted (on any of the sup's), however 512mb's > haven't caused any problems in this setup for us. > From lukasz at bromirski.net Thu Oct 15 01:17:48 2009 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Thu, 15 Oct 2009 07:17:48 +0200 Subject: [c-nsp] IPv6 on ME3400 In-Reply-To: <4AD69CF1.6020503@kenweb.org> References: <4AD69107.6010303@kenweb.org> <69D1761D-500A-4A86-BF5F-0F11C15D4E0F@wisc.edu> <4AD69CF1.6020503@kenweb.org> Message-ID: <4AD6B07C.3020103@bromirski.net> On 2009-10-15 05:54, ML wrote: > Speaking of uRPF does anyone have it working at all on the ME3400. I've > yet to find a working configuration. Far as I can tell Cisco said they > had it but never delivered. The hardware on ME3400 is not capable to perform uRPF check. Making it in software would be non realistic at speeds ME3400 can offer. -- "Everything will be okay in the end. | ?ukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net From kgraham at industrial-marshmallow.com Thu Oct 15 00:19:39 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Wed, 14 Oct 2009 21:19:39 -0700 (PDT) Subject: [c-nsp] Flexwan module - Memory In-Reply-To: References: Message-ID: <511704.39486.qm@web507.biz.mail.mud.yahoo.com> > My doubt are 1. whether these cwan1/0-disk0: and cwan1/1-disk0: are builtin > flash modules on Flexwan module? Yes. > 2. if so can i upload my IOS in those modules No. FlexWAN (as with all linecards) boots after the MSFC/Sup. Its devices are inaccessible from either Sup or MSFC ROMMON. > becoz, my current flash size will not support my new IOS Presumably this is is a Sup2/MSFC2? If so, just use a CompactFlash card in a PCMCIA adapter (which will be presented as 'disk0'. I haven't tested how large of cards are accepted (on any of the sup's), however 512mb's haven't caused any problems in this setup for us. From oboehmer at cisco.com Thu Oct 15 02:09:02 2009 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Thu, 15 Oct 2009 08:09:02 +0200 Subject: [c-nsp] ibgp TTL In-Reply-To: <4AD60305.5080702@uk.clara.net> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> <7100ed370910140151x72a0f59fvd1bfd685a9e710a@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD4F8@XMB-AMS-103.cisco.com> <7100ed370910140857l53db6ce9hd355a5d959ede840@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD75D@XMB-AMS-103.cisco.com> <4AD60305.5080702@uk.clara.net> Message-ID: <6E4D2678AC543844917CA081C9D6B33F7CD899@XMB-AMS-103.cisco.com> > How about explicit path TE with no autoroute announce (and only statics > for these dedicated iBGP loopbacks?) well, if the only path to the destination is through the "non-MPLS part of the network", there will be no TE path available. so the tunnel will go down and the statics go away, and IGP path will be chosen. Well, you could add loating statics to Null0.. but this is certainly not "nice" and requires lot of manual work.. oli > >> More detail: > >> > >> I have a standard IP/MPLS backbone with MP-iBGP between PEs loopbacks > with > >> IS-IS L2 or OSPF area 0 as IGP. > >> > >> This IGP is extended to some non MPLS routers X. > >> > >> In some backbone links failure, IGP allow MP-iBGP to stay UP via X links > >> (non MPLS). > >> > >> This specific IGP design introduce a L3VPN blackhole that can be solved > by > >> IGP prefix filtering or by limiting TTL for MP-iBGP sessions, if possible > :) > > > > Hmm, you could also cause iBGP session to fail if you just add an > interface ACL not allowing iBGP between your PEs across the links not > running MPLS. > > > > Not sure if there is any real solution to this, other than increasing the > link metric towards the "non-MPLS-capble part" so much that MPLS packets > will not cross these links (or turn this part of the network into a stub > area to achieve the same). > > > > oli > > > > > > > >> On Wed, Oct 14, 2009 at 2:10 PM, Oliver Boehmer (oboehmer) > >> wrote: > >> yes, only supported for ebgp. Would be interested about the "very > >> specific design" and why Manu requires this functionality? > >> > >> oli > >> > >>> AFAIK this command is for eBGP only, no? > >>> > >>> On Tue, Oct 13, 2009 at 10:07 PM, Matlock, Kenneth L > >>> wrote: > >>> > >>>> Router bgp > >>>> Neighbor ttl-security hops > >>>> > >>>> ? > >>>> > >>>> Ken Matlock > >>>> Network Analyst > >>>> Exempla Healthcare > >>>> (303) 467-4671 > >>>> matlockk at exempla.org > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: cisco-nsp-bounces at puck.nether.net > >>>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Manu Chao > >>>> Sent: Tuesday, October 13, 2009 4:52 AM > >>>> To: cisco-nsp at puck.nether.net > >>>> Subject: [c-nsp] ibgp TTL > >>>> > >>>> For a very specific design, i need to limit TTL value in > >> ibgp-multihop. > >>>> Is it possible to limit iBGP TTL like we do with ebgp-multihop ttl > >>>> command? > >>>> > >>>> Any input appreciated. > >>>> > >>>> Manu > >>>> _______________________________________________ > >>>> cisco-nsp mailing list cisco-nsp at 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 at 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 at puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > From brad.henshaw at qcn.com.au Thu Oct 15 01:25:17 2009 From: brad.henshaw at qcn.com.au (Brad Henshaw) Date: Thu, 15 Oct 2009 15:25:17 +1000 Subject: [c-nsp] IPv6 on ME3400 Message-ID: <8B25B862BC09784B9B74FB950D4F64D40F8676@qcnapp01.corp.qcn> Dale W. Carder wrote: >On Oct 14, 2009, at 10:03 PM, ML wrote: >> I've got a customer that *needs* a 1-2 RU router that handles IPv6 in >> hardware. > Make sure what you want to do fits in the "sdm profile". > Carving up tcam for ipv6 steals from other areas like mac addrs, vlans, v4 routes and such. Also be aware of the traffic shaping and buffer limitations on the ME3400 platform if that's relevant to your situation. Remember this isn't a router - it's a Layer 3 switch. Regards, Brad From ccie15385 at gmail.com Thu Oct 15 02:54:49 2009 From: ccie15385 at gmail.com (JC Cockburn) Date: Thu, 15 Oct 2009 08:54:49 +0200 Subject: [c-nsp] ibgp TTL In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F7CD899@XMB-AMS-103.cisco.com> References: <7100ed370910130352l3c6d5566medae2bab42fcafcf@mail.gmail.com> <4288131ED5E3024C9CD4782CECCAD2C7065D3B5D@LMC-MAIL2.exempla.org> <7100ed370910140151x72a0f59fvd1bfd685a9e710a@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD4F8@XMB-AMS-103.cisco.com> <7100ed370910140857l53db6ce9hd355a5d959ede840@mail.gmail.com> <6E4D2678AC543844917CA081C9D6B33F7CD75D@XMB-AMS-103.cisco.com> <4AD60305.5080702@uk.clara.net> <6E4D2678AC543844917CA081C9D6B33F7CD899@XMB-AMS-103.cisco.com> Message-ID: <000001ca4d64$66de6640$349b32c0$@com> Hi, What about simple acl on the non-mpls interfaces blocking bgp from loopback of ibgp src -> loopback of ibgp dest? Am I missing the boat completely? I know you don't want acl's on any core intf's, but if you want funny solutions you might have to do funny stuff... Cheers ;-) -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oliver Boehmer (oboehmer) Sent: Thursday, October 15, 2009 8:09 AM To: David Freedman Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] ibgp TTL > How about explicit path TE with no autoroute announce (and only statics > for these dedicated iBGP loopbacks?) well, if the only path to the destination is through the "non-MPLS part of the network", there will be no TE path available. so the tunnel will go down and the statics go away, and IGP path will be chosen. Well, you could add loating statics to Null0.. but this is certainly not "nice" and requires lot of manual work.. oli > >> More detail: > >> > >> I have a standard IP/MPLS backbone with MP-iBGP between PEs loopbacks > with > >> IS-IS L2 or OSPF area 0 as IGP. > >> > >> This IGP is extended to some non MPLS routers X. > >> > >> In some backbone links failure, IGP allow MP-iBGP to stay UP via X links > >> (non MPLS). > >> > >> This specific IGP design introduce a L3VPN blackhole that can be solved > by > >> IGP prefix filtering or by limiting TTL for MP-iBGP sessions, if possible > :) > > > > Hmm, you could also cause iBGP session to fail if you just add an > interface ACL not allowing iBGP between your PEs across the links not > running MPLS. > > > > Not sure if there is any real solution to this, other than increasing the > link metric towards the "non-MPLS-capble part" so much that MPLS packets > will not cross these links (or turn this part of the network into a stub > area to achieve the same). > > > > oli > > > > > > > >> On Wed, Oct 14, 2009 at 2:10 PM, Oliver Boehmer (oboehmer) > >> wrote: > >> yes, only supported for ebgp. Would be interested about the "very > >> specific design" and why Manu requires this functionality? > >> > >> oli > >> > >>> AFAIK this command is for eBGP only, no? > >>> > >>> On Tue, Oct 13, 2009 at 10:07 PM, Matlock, Kenneth L > >>> wrote: > >>> > >>>> Router bgp > >>>> Neighbor ttl-security hops > >>>> > >>>> ? > >>>> > >>>> Ken Matlock > >>>> Network Analyst > >>>> Exempla Healthcare > >>>> (303) 467-4671 > >>>> matlockk at exempla.org > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: cisco-nsp-bounces at puck.nether.net > >>>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Manu Chao > >>>> Sent: Tuesday, October 13, 2009 4:52 AM > >>>> To: cisco-nsp at puck.nether.net > >>>> Subject: [c-nsp] ibgp TTL > >>>> > >>>> For a very specific design, i need to limit TTL value in > >> ibgp-multihop. > >>>> Is it possible to limit iBGP TTL like we do with ebgp-multihop ttl > >>>> command? > >>>> > >>>> Any input appreciated. > >>>> > >>>> Manu > >>>> _______________________________________________ > >>>> cisco-nsp mailing list cisco-nsp at 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 at 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 at 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 at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From blahu77 at gmail.com Thu Oct 15 04:18:14 2009 From: blahu77 at gmail.com (Mateusz Blaszczyk) Date: Thu, 15 Oct 2009 09:18:14 +0100 Subject: [c-nsp] 3560 buffering In-Reply-To: <1255514737.3677.8.camel@abehat.net.rm.dk> References: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> <1255449595.3217.40.camel@abehat.net.rm.dk> <20091014094501.GF8830@thorgal> <1255514737.3677.8.camel@abehat.net.rm.dk> Message-ID: <20091015081814.GK8830@thorgal> On Wed, Oct 14, 2009 at 12:05:37PM +0200, Peter Rathlev wrote: > > It seems that all queues are actually used according to the default CoS > map. I think I'm getting confused here. Can anybody shed light on this? I saw that myself and that's why I asked you. It is very confusing. > The reason I used queue 2 in the example is that the CPU apparantly uses > it so you can never allocate 0% for this queue. The "no QoS" scenario is > best achieved with one simple queue using all buffer space. > > Isn't it better to give cos 6,7 (BPDUs, Routing) access to CPU queue and allocate all other cos values to separate queue? -mat -- Mateusz Blaszczyk pgp-key 0x64643FCE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From peter at rathlev.dk Thu Oct 15 05:10:33 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Thu, 15 Oct 2009 11:10:33 +0200 Subject: [c-nsp] 3560 buffering In-Reply-To: <20091015081814.GK8830@thorgal> References: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> <1255449595.3217.40.camel@abehat.net.rm.dk> <20091014094501.GF8830@thorgal> <1255514737.3677.8.camel@abehat.net.rm.dk> <20091015081814.GK8830@thorgal> Message-ID: <1255597833.3219.23.camel@abehat.net.rm.dk> On Thu, 2009-10-15 at 09:18 +0100, Mateusz Blaszczyk wrote: > > The reason I used queue 2 in the example is that the CPU apparantly > > uses it so you can never allocate 0% for this queue. The "no QoS" > > scenario is best achieved with one simple queue using all buffer > > space. > > Isn't it better to give cos 6,7 (BPDUs, Routing) access to CPU queue > and allocate all other cos values to separate queue? I would agree, but I thought that would be more "implementing QoS"-like. Since the switch actually seems to do exactly this even with "no mls qos" it's probably a good idea to do. Otherwise "normal" traffic might starve the CPU queue. I can see that the default Auto-QoS maps (cos-map / dscp-map) use queue 2 for CoS 3, 6 and 7 (and DSCP 24-31, 48-55 and 56-63). I can't immediately remember what CoS 3 is usually meant for; we currently use it for "critical bulk traffic" but not for any special reason. -- Peter From peter at rathlev.dk Thu Oct 15 05:29:08 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Thu, 15 Oct 2009 11:29:08 +0200 Subject: [c-nsp] QoS best practices Message-ID: <1255598948.3219.42.camel@abehat.net.rm.dk> The 3560 buffering discussion has reminded me: It's not hard to find documentation on configuring QoS, but I haven't yet found any "best practices" reagarding how to specifically classify, i.e. what traffic goes in what queue with what DSCP/CoS marking. For VoIP it seems there are some notes, so it seems very "best practice" to use EF for voice traffic and AF31 for signaling. But what about all other traffic? What I'm looking for is something along: "Use AF23 for text based remote access (telnet/ssh), AF33 for GUI based remote access (remote X/ICA/RDP), AF99 for H.323 ..." et cetera. Also some notes on buffer partitioning would be nice. Anybody know if there are some "authoritative" sources on this? (I know that the classification part isn't so much SP as it is enterprise, but hopefully someone has some comments anyway. :-)) -- Peter From A.L.M.Buxey at lboro.ac.uk Thu Oct 15 05:39:10 2009 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Thu, 15 Oct 2009 10:39:10 +0100 Subject: [c-nsp] QoS best practices In-Reply-To: <1255598948.3219.42.camel@abehat.net.rm.dk> References: <1255598948.3219.42.camel@abehat.net.rm.dk> Message-ID: <20091015093910.GI6929@lboro.ac.uk> Hi, > The 3560 buffering discussion has reminded me: > > It's not hard to find documentation on configuring QoS, but I haven't > yet found any "best practices" reagarding how to specifically classify, > i.e. what traffic goes in what queue with what DSCP/CoS marking. > > For VoIP it seems there are some notes, so it seems very "best practice" > to use EF for voice traffic and AF31 for signaling. But what about all > other traffic? for cisco voip there are preconfigured templates and 'autoqos' - these set the values to pretty much what you need - even handling the subtle change that cisco cover in QoS/VOIP courses regarding call signalling IIRC. > What I'm looking for is something along: "Use AF23 for text based remote > access (telnet/ssh), AF33 for GUI based remote access (remote > X/ICA/RDP), AF99 for H.323 ..." et cetera. Also some notes on buffer > partitioning would be nice. :-) well, thats down to site and link policies. This guide is pretty much our current 'tablet' http://tools.ietf.org/html/rfc4594 ...and this was adopted by JANET(UK) as guidelines for QoS: http://www.ja.net/documents/development/network-engineering/qos/suggested-dscp-marking-scheme.pdf alan From b.turnbow at twt.it Thu Oct 15 05:55:30 2009 From: b.turnbow at twt.it (Brian Turnbow) Date: Thu, 15 Oct 2009 11:55:30 +0200 Subject: [c-nsp] QoS best practices In-Reply-To: <1255598948.3219.42.camel@abehat.net.rm.dk> References: <1255598948.3219.42.camel@abehat.net.rm.dk> Message-ID: >The 3560 buffering discussion has reminded me: >It's not hard to find documentation on configuring QoS, but I haven't >yet found any "best practices" reagarding how to specifically classify, For VoIP it seems there are some notes, so it seems very "best practice" >to use EF for voice traffic and AF31 for signaling. But what about all >other traffic? This is cisco's. I recently got into a discussion with another supplier about AF31 As a Cisco shop we used AF31 for VoIP signalling, they used CS5 as per RFC4594. So Even here it is not so clear. Brian From ygauteron at gmail.com Thu Oct 15 07:52:52 2009 From: ygauteron at gmail.com (Yann Gauteron) Date: Thu, 15 Oct 2009 13:52:52 +0200 Subject: [c-nsp] Cisco SCE RTM In-Reply-To: References: Message-ID: <8097baf0910150452g659c5880n6360ca91ca083711@mail.gmail.com> I privately answered to Khalil: "Please refer to http://www.cisco.com/en/US/docs/cable/serv_exch/serv_control/broadband_app/rel350/swcfg8000/AppendixA_MIBs.html You'll read that Cisco replaced the Pcube MIBs (Pcube is the company who created the SCE 1000 and SCE 2000 and which was acquired and merged into Cisco) by Cisco Service Control MIBs. SCE 1000/2000 still use the Pcube MIBs, while the SCE 8000 (which is a product completely made by Cisco) is using the Cisco MIBs." 2009/10/14 Mohammad Khalil > > hi all > > i have SCE 2020 with sca console 3.5.0 > i installed RTM on it and all is working fine > > now i have another SCE with SCA console 3.5.0 (the same console version) > and its 8000 series > but when i try to apply the ./rtmcmd.sh with the rest of the line , i get > the below error > > > Failed > to process templates. Aborting! > > > even though when i try to graph the concurrent sessions > on the SCE2020 > [root at Core ~]# snmpwalk -v2c -c *** *** .1.3.6.1.4.1.5655.4.1.8.1.1.9.1 > SNMPv2-SMI::enterprises.5655.4.1.8.1.1.9.1 = Gauge32: 566 > > on the SCE8000 > [root at FT ~]# snmpwalk -v2c -c *** *** 0 .1.3.6.1.4.1.5655.4.1.8.1.1.9.1 > SNMPv2-SMI::enterprises.5655.4.1.8.1.1.9.1 = No Such Object available on > this agent at this OID > > any ideas what should i do ? > thanks in advance > > > _________________________________________________________________ > Windows Live Hotmail: Your friends can get your Facebook updates, right > from Hotmail?. > > http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009 > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From achatz at forthnet.gr Thu Oct 15 07:59:19 2009 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Thu, 15 Oct 2009 14:59:19 +0300 Subject: [c-nsp] QoS best practices In-Reply-To: References: <1255598948.3219.42.camel@abehat.net.rm.dk> Message-ID: <4AD70E97.1020403@forthnet.gr> Brian Turnbow wrote on 15/10/2009 12:55: > > >> The 3560 buffering discussion has reminded me: > >> It's not hard to find documentation on configuring QoS, but I haven't >> yet found any "best practices" reagarding how to specifically classify, > > RFC 4594 is a good start > >> For VoIP it seems there are some notes, so it seems very "best > practice" >> to use EF for voice traffic and AF31 for signaling. But what about all >> other traffic? > > This is cisco's. I recently got into a discussion with another supplier > about AF31 > As a Cisco shop we used AF31 for VoIP signalling, they used CS5 as per > RFC4594. So > Even here it is not so clear. > Cisco has changed it to CS3. === The QoS Baseline recommends marking Call-Signaling to CS3. However, currently most Cisco IP Telephony products mark Call-Signaling to AF31. A marking migration from AF31 to CS3 is under way within Cisco, but in the interim it is recommended that both AF31 and CS3 be reserved for Call-Signaling and that Locally-Defined Mission-Critical Data applications be marked to a temporary placeholder non-standard DSCP, such as 25. Upon completion of the migration, the QoS Baseline marking recommendations of CS3 for Call-Signaling and AF31 for Locally-Defined Mission-Critical Data applications should be used. These marking recommendations are more in line with RFC 2474 and RFC 2597. === -- Tassos From benny+usenet at amorsen.dk Thu Oct 15 09:03:54 2009 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Thu, 15 Oct 2009 15:03:54 +0200 Subject: [c-nsp] 3560 buffering In-Reply-To: <20091014122515.GA68065@bts.sk> ("Marian =?utf-8?B?xI51cmtv?= =?utf-8?B?dmnEjSIncw==?= message of "Wed, 14 Oct 2009 14:25:15 +0200") References: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> <20091014064424.GA1508@greenie.muc.de> <20091014072843.M20756@bts.sk> <5A69C25361FED34F83ABF05F50475245072BC1EF@wally.walleyetrading.net> <20091014122515.GA68065@bts.sk> Message-ID: Marian ?urkovi? writes: > Yes, if both hosts are connected at the same speed, no extensive buffering > is needed. However, another usage scenario for such switches is speed > downshift, e.g. 1Gbps uplink -> 100 Mbps host (or 10 Gbps -> 1 Gbps), > where the relation to TCP window size does apply. It would be extremely handy if the switch did flow control in that case. However, I believe the 3560-series is incapable of transmitting XON/XOFF, while it does respect incoming XON/XOFF. /Benny From r.tahina at moov.mg Thu Oct 15 10:41:38 2009 From: r.tahina at moov.mg (RAZAFINDRATSIFA Rivo Tahina) Date: Thu, 15 Oct 2009 17:41:38 +0300 Subject: [c-nsp] ASN statistic tools In-Reply-To: References: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> Message-ID: <7.0.1.0.2.20091015174104.01070108@moov.mg> Hi Christian, I'm trying that now, will revert back later. BR. At 10:12 14/10/2009, christian wrote: >take a look at: > >https://neon1.net/as-stats/as-stats-presentation-swinog16.pdf > >On Tue, Oct 13, 2009 at 10:52 PM, RAZAFINDRATSIFA Rivo Tahina > wrote: > > Daer All, > > > > I'm looking for utilities which allow to have ASN statistics, the netflow > > tools I tried doesn't do that, any idea? > > > > BR > > _______________________________________________ > > cisco-nsp mailing list cisco-nsp at puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > From r.tahina at moov.mg Thu Oct 15 10:44:32 2009 From: r.tahina at moov.mg (RAZAFINDRATSIFA Rivo Tahina) Date: Thu, 15 Oct 2009 17:44:32 +0300 Subject: [c-nsp] AS5300 issue Message-ID: <7.0.1.0.2.20091015174143.04cd9718@moov.mg> Hi, I have trouble with an AS5300, during seconds, it is unreachable and I have this in log: Oct 15 17:21:10.876: -Traceback= 60252E7C 602F8364 60271D88 6017D884 6017F524 604C9C8C 60458438 Oct 15 17:21:10.900: ASSERTION FAILED: file "../as/if_as_pm7366_packet.c", line 746 Any one know what it is about? BR From r.tahina at moov.mg Thu Oct 15 10:45:41 2009 From: r.tahina at moov.mg (RAZAFINDRATSIFA Rivo Tahina) Date: Thu, 15 Oct 2009 17:45:41 +0300 Subject: [c-nsp] ASN statistic tools In-Reply-To: References: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> Message-ID: <7.0.1.0.2.20091015174522.04d22e50@moov.mg> Hi, I tried but didn't help. BR At 11:02 14/10/2009, Gideon Popol wrote: >Hello , >Did you tried >NetFlow Analyzer >http://www.manageengine.com/products/netflow/index.html > >they have ASN statistics > > > >Best Regards > >Gideon Popol > >gideon at gilat.net >Office: +972.3.9255039 >MSN: gidi_pop at hotmail.com >www.gilat.net > >The Winner of the "Best Satellite Service Provider 2007" Award >The information contained in this e-mail message and its attachments >is confidential information intended only for the use of the >individual or entity named above. If the reader of this message is >not the intended recipient, you are hereby notified that any >dissemination, distribution or copying of this communication is >strictly prohibited. If you have received this communication in >error, please notify us immediately by replying to the sender, and >then delete the message from your computer. Thank you! > > >-----Original Message----- >From: cisco-nsp-bounces at puck.nether.net >[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of >RAZAFINDRATSIFA Rivo Tahina >Sent: Wednesday, October 14, 2009 7:52 AM >To: cisco-nsp at puck.nether.net >Subject: [c-nsp] ASN statistic tools > >Daer All, > >I'm looking for utilities which allow to have ASN statistics, the >netflow tools I tried doesn't do that, any idea? > >BR >_______________________________________________ >cisco-nsp mailing list cisco-nsp at 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. >************************************************************************************ From r.tahina at moov.mg Thu Oct 15 10:46:09 2009 From: r.tahina at moov.mg (RAZAFINDRATSIFA Rivo Tahina) Date: Thu, 15 Oct 2009 17:46:09 +0300 Subject: [c-nsp] ASN statistic tools In-Reply-To: <2638c6520910140226t5acd2731q69994a29be3ea2b6@mail.gmail.co m> References: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> <2638c6520910140226t5acd2731q69994a29be3ea2b6@mail.gmail.com> Message-ID: <7.0.1.0.2.20091015174553.04d2c2a8@moov.mg> Hi, Will try also this one. BR. At 12:26 14/10/2009, Gustaf Hyllested Serve wrote: > > I'm looking for utilities which allow to have ASN statistics, the netflow > > tools I tried doesn't do that, any idea? > >take a look at NetQos ReportAnalyzer > >-- >Gustaf Hyllested Serve From r.tahina at moov.mg Thu Oct 15 10:52:10 2009 From: r.tahina at moov.mg (RAZAFINDRATSIFA Rivo Tahina) Date: Thu, 15 Oct 2009 17:52:10 +0300 Subject: [c-nsp] ASN statistic tools In-Reply-To: <20091014172651.GA27128@london.pmacct.net> References: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> <20091014172651.GA27128@london.pmacct.net> Message-ID: <7.0.1.0.2.20091015175151.0215d510@moov.mg> Hi, Thank you, I will check. BR At 20:26 14/10/2009, Paolo Lucente wrote: >Hi, > >You can certainly have a look to the following page which >captures a number of NetFlow collector packages (free and >commercial) available around. I'm sure most of them are >supporting ASNs: > >http://www.switch.ch/network/projects/completed/TF-NGN/floma/software.html > >If you are looking at something that goes a bit further >than simply grabbing peer/origin AS numbers from within >NetFlow packets (and possibly aggregating/accounting), i >would like to point you a presentation i gave recently >(09/2009) at UKNOF and SwiNOG: > >"Introducing BGP natively into a NetFlow/sFlow collector": >http://www.pmacct.net/lucente_pmacct_uknof14.pdf > >In short, this allows to join accounting information (NetFlow) >and routing information (BGP). Main outcomes are: a) ability to >correlate peer and origin AS numbers (and not having to choose >one of them) and b) get insight of traffic levels on primitives >like AS-PATH, BGP communities, Local Preference, etc. > >Hope it could be of interest. > >Cheers, >Paolo > > >On Wed, Oct 14, 2009 at 08:52:27AM +0300, RAZAFINDRATSIFA Rivo Tahina wrote: > > Daer All, > > > > I'm looking for utilities which allow to have ASN statistics, the > > netflow tools I tried doesn't do that, any idea? > > > > BR From drew.weaver at thenap.com Thu Oct 15 12:56:07 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Thu, 15 Oct 2009 12:56:07 -0400 Subject: [c-nsp] Possible interface counter bug, but wanted to check.. Message-ID: Hi, We have a Gig-E connection going from a GSR to a 6500 and the 6500 appears to be showing almost double the amount of traffic/packets per second than the GSR is showing in its interface counters (for the same connection) GSR: 30 second input rate 326816000 bits/sec, 233144 packets/sec 30 second output rate 172271000 bits/sec, 223016 packets/sec 6500/Sup720: 30 second input rate 381479000 bits/sec, 479251 packets/sec 30 second output rate 708996000 bits/sec, 497164 packets/sec Has anyone seen this before and know what the issue could be? The 6500 is running: 12.2(18)SXD7b I'm more inclined to believe the stats coming from the GSR, but I wanted to check with you folks and see if anyone has any experience with this particular errata. -Drew From drew.weaver at thenap.com Thu Oct 15 13:12:06 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Thu, 15 Oct 2009 13:12:06 -0400 Subject: [c-nsp] Possible interface counter bug, but wanted to check.. In-Reply-To: References: Message-ID: Ah, it looks like the SNMP counters match between the 6500 and GSR so this must be an interface counter bug, but i was under the impression that they used the same counter. -Drew -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Drew Weaver Sent: Thursday, October 15, 2009 12:56 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Possible interface counter bug, but wanted to check.. Hi, We have a Gig-E connection going from a GSR to a 6500 and the 6500 appears to be showing almost double the amount of traffic/packets per second than the GSR is showing in its interface counters (for the same connection) GSR: 30 second input rate 326816000 bits/sec, 233144 packets/sec 30 second output rate 172271000 bits/sec, 223016 packets/sec 6500/Sup720: 30 second input rate 381479000 bits/sec, 479251 packets/sec 30 second output rate 708996000 bits/sec, 497164 packets/sec Has anyone seen this before and know what the issue could be? The 6500 is running: 12.2(18)SXD7b I'm more inclined to believe the stats coming from the GSR, but I wanted to check with you folks and see if anyone has any experience with this particular errata. -Drew _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From Steven.Raymond at integratelecom.com Thu Oct 15 13:17:47 2009 From: Steven.Raymond at integratelecom.com (Raymond, Steven) Date: Thu, 15 Oct 2009 10:17:47 -0700 Subject: [c-nsp] Possible interface counter bug, but wanted to check.. In-Reply-To: References: Message-ID: <775A75B5625C6B418FC01477094E0BCC25A1106AA7@IDCMAILBOX1.ads.integratelecom.com> > Has anyone seen this before and know what the issue could be? > > The 6500 is running: 12.2(18)SXD7b > > I'm more inclined to believe the stats coming from the GSR, but I wanted > to check with you folks and see if anyone has any experience with this > particular errata. Definitely saw 2:1 counting on a sup720 with 12.2(33)SRA(5 or 6?) train when a L2 trunk was connected some smaller 3xxx switch. The gig interface on the 7600 was doubling the real amount of traffic, while the 3xxx reported the accurate traffic levels. This was observed on practically any trunk in the code mentioned. From gert at greenie.muc.de Thu Oct 15 14:18:49 2009 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 15 Oct 2009 20:18:49 +0200 Subject: [c-nsp] Possible interface counter bug, but wanted to check.. In-Reply-To: References: Message-ID: <20091015181849.GD1508@greenie.muc.de> Hi, On Thu, Oct 15, 2009 at 12:56:07PM -0400, Drew Weaver wrote: > We have a Gig-E connection going from a GSR to a 6500 and the 6500 > appears to be showing almost double the amount of traffic/packets > per second than the GSR is showing in its interface counters Not that anybody has ever heard of "counter bugs" in IOS before... :-) > The 6500 is running: 12.2(18)SXD7b This IOS is ancient. I have not seen obvious counter bugs of this sort on our 6500s yet, but the oldest IOS we've ever used there is SXF. So it might or might not be an old-IOS-bug... If you sum up *other* interfaces on these boxes, or compare the interface byte counters, do they agree with the GSR or the 6500? (Since the values are *so* different, just getting a rough idea from looking at the interface counters every 5 minute and calculating the average bandwidth by hand should suffice) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From charlie at playlouder.com Thu Oct 15 15:40:14 2009 From: charlie at playlouder.com (Charlie Allom) Date: Thu, 15 Oct 2009 20:40:14 +0100 Subject: [c-nsp] ASN statistic tools In-Reply-To: References: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> Message-ID: <20091015194013.GF463@eatyourpets.com> On Wed, Oct 14, 2009 at 12:12:45AM -0700, christian wrote: > take a look at: > > https://neon1.net/as-stats/as-stats-presentation-swinog16.pdf This notes: "should be possible given src/dst IP address and a full BGP table to map IP address ? ASN" Is this something it does? I have some hosts where my upstream manages the routing - I would love to know where my traffic goes per-ASN. I've been looking for a while (and thought stager might do this). pmacct also looks promising but I can't find anywhere it explicitly mentions it. C. -- http://blog.playlouder.com/ 020 7729 4797 From lsawyer at gci.com Thu Oct 15 16:37:16 2009 From: lsawyer at gci.com (Leif Sawyer) Date: Thu, 15 Oct 2009 12:37:16 -0800 Subject: [c-nsp] IOS question for c12406 In-Reply-To: <20091013225916.GA3155@amused.net> Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102B980@fnb1mbx01.gci.com> In the process of upgrading from a c12008 to a c12406, with the following linecards: SIP-601 + SPA-10X1GE-V2 2 x PRP-2 LC-4OC3/POS-SM 4GE-SFP-LC Looks like I've got a choice between these two: c12kprp-k4p-mz.120-32.SY10.bin c12kprp-k4p-mz.120-33.S5.bin feature-set comparison doesn't list these, but based on the most recent version in it, the only difference that I would be concerned with is CEF/dCEF - Cisco Express Forwarding however, in botting the SY train, it appears that dCEF truly is enabled. Anybody have any experience with these, recommendations, comments or caveats? Thanks, Leif From rlucas at nz1.ibm.com Thu Oct 15 16:46:12 2009 From: rlucas at nz1.ibm.com (Raymond Lucas) Date: Fri, 16 Oct 2009 09:46:12 +1300 Subject: [c-nsp] QoS best practices In-Reply-To: References: Message-ID: Peter, Agree with others about RFC4594 being a particularly good discussion of what different types of traffic there are and appropriate markings. For quick Cisco overviews the "At a Glance" documents are quite good - http://www.cisco.com/en/US/tech/tk543/tk759/tech_white_papers_list.html. Also the Cisco Enterprise QoS Solution Reference Network Design Guide is quite good going through recommended markings and then excruciating detail on how to implement on all sorts of different platforms. Of course not all the recommendations match so there is still plenty of room for personal interpretation. Ray From vuillaumes at gmail.com Thu Oct 15 17:50:17 2009 From: vuillaumes at gmail.com (samuel vuillaume) Date: Thu, 15 Oct 2009 17:50:17 -0400 Subject: [c-nsp] EoMPLS issue between 3750-ME and 7600-ES card Message-ID: Hi guys, here's my diagram: 6500-----(ES40 card) 7600------------------- (ES port) 3750ME(FastEthernet 1 port)--------------- I'm currently running a PW between the ES card and the 3750ME (FE port), and it doesn;t work due to an MTU issue: ES Card : 9000 bytes FastEthernet on 3750: 1998 bytes max MPLS is up and running, but my PW doesn't come up if i don't drop the MTU on the ES Card to 1998 bytes. I'd like to keep 9K bytes on the ES, and don't burn my gigabitport on the 3750. Is there a way of bringing up this PW, ignoring the MTU negociation between the ES card and the 3750 FE1 port? i've tried to play with mpls mtu on the 3750 FE port, but nothing... tks Sam From eninja at gmail.com Thu Oct 15 20:06:35 2009 From: eninja at gmail.com (Eninja) Date: Fri, 16 Oct 2009 02:06:35 +0200 Subject: [c-nsp] IOS question for c12406 In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102B980@fnb1mbx01.gci.com> References: <18B2C6E38A3A324986B392B2D18ABC5102B980@fnb1mbx01.gci.com> Message-ID: Leif, Not sure what you're asking but GSR 12K is a distributed platform where each LC switches packets independently of the RP....and whatever IOS is running on the box. Eninja On Oct 15, 2009, at 10:37 PM, Leif Sawyer wrote: > In the process of upgrading from a c12008 to a c12406, with the > following > linecards: > > SIP-601 + SPA-10X1GE-V2 > 2 x PRP-2 > LC-4OC3/POS-SM > 4GE-SFP-LC > > > Looks like I've got a choice between these two: > c12kprp-k4p-mz.120-32.SY10.bin > c12kprp-k4p-mz.120-33.S5.bin > > feature-set comparison doesn't list these, but based on the most > recent > version in it, the only difference that I would be concerned with is > CEF/dCEF - Cisco Express Forwarding > > however, in botting the SY train, it appears that dCEF truly is > enabled. > > > Anybody have any experience with these, recommendations, comments or > caveats? > > > Thanks, > > Leif > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From lsawyer at gci.com Thu Oct 15 20:09:38 2009 From: lsawyer at gci.com (Leif Sawyer) Date: Thu, 15 Oct 2009 16:09:38 -0800 Subject: [c-nsp] IOS question for c12406 In-Reply-To: Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102B992@fnb1mbx01.gci.com> I'm stating a that Feature Set Navigator is unstable for purposes of my research (based on the (d)CEF issue, and lack of updates) and asking for feedback about which train (SY or S) to use on my 12406, given the listed linecards. > -----Original Message----- > From: Eninja [mailto:eninja at gmail.com] > Sent: Thursday, October 15, 2009 4:07 PM > To: Leif Sawyer > Cc: cisco-nsp at puck.nether.net; e ninja > Subject: Re: [c-nsp] IOS question for c12406 > > Leif, > > Not sure what you're asking but GSR 12K is a distributed > platform where each LC switches packets independently of the > RP....and whatever IOS is running on the box. > > Eninja > > > On Oct 15, 2009, at 10:37 PM, Leif Sawyer wrote: > > > In the process of upgrading from a c12008 to a c12406, with the > > following > > linecards: > > > > SIP-601 + SPA-10X1GE-V2 > > 2 x PRP-2 > > LC-4OC3/POS-SM > > 4GE-SFP-LC > > > > > > Looks like I've got a choice between these two: > > c12kprp-k4p-mz.120-32.SY10.bin > > c12kprp-k4p-mz.120-33.S5.bin > > > > feature-set comparison doesn't list these, but based on the most > > recent version in it, the only difference that I would be concerned > > with is > > CEF/dCEF - Cisco Express Forwarding > > > > however, in botting the SY train, it appears that dCEF truly is > > enabled. > > > > > > Anybody have any experience with these, recommendations, > comments or > > caveats? > > > > > > Thanks, > > > > Leif > > _______________________________________________ > > cisco-nsp mailing list cisco-nsp at puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From eninja at gmail.com Thu Oct 15 20:21:36 2009 From: eninja at gmail.com (Eninja) Date: Fri, 16 Oct 2009 02:21:36 +0200 Subject: [c-nsp] IOS question for c12406 In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102B992@fnb1mbx01.gci.com> References: <18B2C6E38A3A324986B392B2D18ABC5102B992@fnb1mbx01.gci.com> Message-ID: GSR 12Ks only run DCEF. So any software suitable for this platform will support DCEF. Feature navigator is imperfect - like a lot of 'tools' on CCO. Eninja On Oct 16, 2009, at 2:09 AM, Leif Sawyer wrote: > I'm stating a that Feature Set Navigator is unstable for purposes > of my research (based on the (d)CEF issue, and lack of updates) and > asking for feedback about which train (SY or S) to use on my 12406, > given the listed linecards. > >> -----Original Message----- >> From: Eninja [mailto:eninja at gmail.com] >> Sent: Thursday, October 15, 2009 4:07 PM >> To: Leif Sawyer >> Cc: cisco-nsp at puck.nether.net; e ninja >> Subject: Re: [c-nsp] IOS question for c12406 >> >> Leif, >> >> Not sure what you're asking but GSR 12K is a distributed >> platform where each LC switches packets independently of the >> RP....and whatever IOS is running on the box. >> >> Eninja >> >> >> On Oct 15, 2009, at 10:37 PM, Leif Sawyer wrote: >> >>> In the process of upgrading from a c12008 to a c12406, with the >>> following >>> linecards: >>> >>> SIP-601 + SPA-10X1GE-V2 >>> 2 x PRP-2 >>> LC-4OC3/POS-SM >>> 4GE-SFP-LC >>> >>> >>> Looks like I've got a choice between these two: >>> c12kprp-k4p-mz.120-32.SY10.bin >>> c12kprp-k4p-mz.120-33.S5.bin >>> >>> feature-set comparison doesn't list these, but based on the most >>> recent version in it, the only difference that I would be concerned >>> with is >>> CEF/dCEF - Cisco Express Forwarding >>> >>> however, in botting the SY train, it appears that dCEF truly is >>> enabled. >>> >>> >>> Anybody have any experience with these, recommendations, >> comments or >>> caveats? >>> >>> >>> Thanks, >>> >>> Leif >>> _______________________________________________ >>> cisco-nsp mailing list cisco-nsp at puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> From lsawyer at gci.com Thu Oct 15 20:25:13 2009 From: lsawyer at gci.com (Leif Sawyer) Date: Thu, 15 Oct 2009 16:25:13 -0800 Subject: [c-nsp] IOS question for c12406 In-Reply-To: Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102B993@fnb1mbx01.gci.com> I understand this. My point is that Feature Navigator is not a worthwhile tool for investigating the differences between the trains, which is why I'm asking for feedback. Real. World. Feedback. As in people who have tested already. Does this make sense yet? > -----Original Message----- > From: Eninja [mailto:eninja at gmail.com] > Sent: Thursday, October 15, 2009 4:22 PM > To: Leif Sawyer > Cc: cisco-nsp at puck.nether.net; e ninja > Subject: Re: [c-nsp] IOS question for c12406 > > GSR 12Ks only run DCEF. So any software suitable for this > platform will support DCEF. > > Feature navigator is imperfect - like a lot of 'tools' on CCO. > > Eninja > > > > On Oct 16, 2009, at 2:09 AM, Leif Sawyer wrote: > > > I'm stating a that Feature Set Navigator is unstable for > purposes of > > my research (based on the (d)CEF issue, and lack of updates) and > > asking for feedback about which train (SY or S) to use on > my 12406, > > given the listed linecards. > > > >> -----Original Message----- > >> From: Eninja [mailto:eninja at gmail.com] > >> Sent: Thursday, October 15, 2009 4:07 PM > >> To: Leif Sawyer > >> Cc: cisco-nsp at puck.nether.net; e ninja > >> Subject: Re: [c-nsp] IOS question for c12406 > >> > >> Leif, > >> > >> Not sure what you're asking but GSR 12K is a distributed platform > >> where each LC switches packets independently of the RP....and > >> whatever IOS is running on the box. > >> > >> Eninja > >> > >> > >> On Oct 15, 2009, at 10:37 PM, Leif Sawyer wrote: > >> > >>> In the process of upgrading from a c12008 to a c12406, with the > >>> following > >>> linecards: > >>> > >>> SIP-601 + SPA-10X1GE-V2 > >>> 2 x PRP-2 > >>> LC-4OC3/POS-SM > >>> 4GE-SFP-LC > >>> > >>> > >>> Looks like I've got a choice between these two: > >>> c12kprp-k4p-mz.120-32.SY10.bin > >>> c12kprp-k4p-mz.120-33.S5.bin > >>> > >>> feature-set comparison doesn't list these, but based on the most > >>> recent version in it, the only difference that I would be > concerned > >>> with is > >>> CEF/dCEF - Cisco Express Forwarding > >>> > >>> however, in botting the SY train, it appears that dCEF truly is > >>> enabled. > >>> > >>> > >>> Anybody have any experience with these, recommendations, > >> comments or > >>> caveats? > >>> > >>> > >>> Thanks, > >>> > >>> Leif > >>> _______________________________________________ > >>> cisco-nsp mailing list cisco-nsp at puck.nether.net > >>> https://puck.nether.net/mailman/listinfo/cisco-nsp > >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ > >> > From eninja at gmail.com Thu Oct 15 20:33:43 2009 From: eninja at gmail.com (Eninja) Date: Fri, 16 Oct 2009 02:33:43 +0200 Subject: [c-nsp] IOS question for c12406 In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102B993@fnb1mbx01.gci.com> References: <18B2C6E38A3A324986B392B2D18ABC5102B993@fnb1mbx01.gci.com> Message-ID: <8600E87D-EC41-41BB-B807-1C5FCA6EE1CF@gmail.com> Any worthwhile "real world" feedback would involve folks understanding what protocols and technologies you intend to deploy rather than just a list of LCs. Eninja On Oct 16, 2009, at 2:25 AM, Leif Sawyer wrote: > I understand this. > > My point is that Feature Navigator is not a worthwhile tool for > investigating > the differences between the trains, which is why I'm asking for > feedback. > > Real. World. Feedback. As in people who have tested already. > > Does this make sense yet? > >> -----Original Message----- >> From: Eninja [mailto:eninja at gmail.com] >> Sent: Thursday, October 15, 2009 4:22 PM >> To: Leif Sawyer >> Cc: cisco-nsp at puck.nether.net; e ninja >> Subject: Re: [c-nsp] IOS question for c12406 >> >> GSR 12Ks only run DCEF. So any software suitable for this >> platform will support DCEF. >> >> Feature navigator is imperfect - like a lot of 'tools' on CCO. >> >> Eninja >> >> >> >> On Oct 16, 2009, at 2:09 AM, Leif Sawyer wrote: >> >>> I'm stating a that Feature Set Navigator is unstable for >> purposes of >>> my research (based on the (d)CEF issue, and lack of updates) and >>> asking for feedback about which train (SY or S) to use on >> my 12406, >>> given the listed linecards. >>> >>>> -----Original Message----- >>>> From: Eninja [mailto:eninja at gmail.com] >>>> Sent: Thursday, October 15, 2009 4:07 PM >>>> To: Leif Sawyer >>>> Cc: cisco-nsp at puck.nether.net; e ninja >>>> Subject: Re: [c-nsp] IOS question for c12406 >>>> >>>> Leif, >>>> >>>> Not sure what you're asking but GSR 12K is a distributed platform >>>> where each LC switches packets independently of the RP....and >>>> whatever IOS is running on the box. >>>> >>>> Eninja >>>> >>>> >>>> On Oct 15, 2009, at 10:37 PM, Leif Sawyer wrote: >>>> >>>>> In the process of upgrading from a c12008 to a c12406, with the >>>>> following >>>>> linecards: >>>>> >>>>> SIP-601 + SPA-10X1GE-V2 >>>>> 2 x PRP-2 >>>>> LC-4OC3/POS-SM >>>>> 4GE-SFP-LC >>>>> >>>>> >>>>> Looks like I've got a choice between these two: >>>>> c12kprp-k4p-mz.120-32.SY10.bin >>>>> c12kprp-k4p-mz.120-33.S5.bin >>>>> >>>>> feature-set comparison doesn't list these, but based on the most >>>>> recent version in it, the only difference that I would be >> concerned >>>>> with is >>>>> CEF/dCEF - Cisco Express Forwarding >>>>> >>>>> however, in botting the SY train, it appears that dCEF truly is >>>>> enabled. >>>>> >>>>> >>>>> Anybody have any experience with these, recommendations, >>>> comments or >>>>> caveats? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Leif >>>>> _______________________________________________ >>>>> cisco-nsp mailing list cisco-nsp at puck.nether.net >>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>>> >> From vuillaumes at gmail.com Thu Oct 15 22:26:12 2009 From: vuillaumes at gmail.com (samuel vuillaume) Date: Thu, 15 Oct 2009 22:26:12 -0400 Subject: [c-nsp] Shared CISCO IOS IP SLA shadow Router in QinQ envirment Message-ID: Hi guys, find enclosed a project i;m working on... It's just an idea and i'd like to get your thoughts! context: Shared CISCO Router ISR 2811 with IOS IP SLA running to Customer sites. Each customer is Q tunneled across VPLS. My Management Server is in the global routing table, and both cstomers into their own VRF. I'd like to try and end up those Q tunnel on the CISCO 2800 using IPoQinQ (see my diagram attached): interface GigabitEthernet5/0.X ip vrf xxxxx encapsulation dot1Q X second-dot1q Y ip address a.b.c.d 255.255.255.252 tks Sam From swmike at swm.pp.se Fri Oct 16 01:34:01 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 16 Oct 2009 07:34:01 +0200 (CEST) Subject: [c-nsp] IOS question for c12406 In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102B980@fnb1mbx01.gci.com> References: <18B2C6E38A3A324986B392B2D18ABC5102B980@fnb1mbx01.gci.com> Message-ID: On Thu, 15 Oct 2009, Leif Sawyer wrote: > Anybody have any experience with these, recommendations, comments or > caveats? 12.0(32)SY train has a huge exposure to real world, "everybody" is running it. 12.0(33)S hasn't got even close to that field exposure, so I'd recommend to stay away unless you actually need some of the features provided (like etherchannel on E5 linecards). -- Mikael Abrahamsson email: swmike at swm.pp.se From ivan at ig.sk Fri Oct 16 02:11:22 2009 From: ivan at ig.sk (Ivan Gasparik) Date: Fri, 16 Oct 2009 08:11:22 +0200 Subject: [c-nsp] EoMPLS issue between 3750-ME and 7600-ES card In-Reply-To: References: Message-ID: <200910160811.22827.ivan@ig.sk> Hi You can set the MTU on each subinterface separately: interface GigabitEthernet1/0/0.1 encapsulation dot1Q 1 xconnect 1.2.3.4 10 encapsulation mpls mtu 1998 The same applies for PW configured inside service instance. You'll need at least 12.2(33)SRC on the 7600 to support that feature. Ivan On Thursday 15 October 2009, samuel vuillaume wrote: > Hi guys, > > here's my diagram: > > > 6500-----(ES40 card) 7600------------------- (ES port) > 3750ME(FastEthernet 1 port)--------------- > > I'm currently running a PW between the ES card and the 3750ME (FE > port), and it doesn;t work due to an MTU issue: > > ES Card : 9000 bytes > FastEthernet on 3750: 1998 bytes max > > MPLS is up and running, but my PW doesn't come up if i don't drop > the MTU on the ES Card to 1998 bytes. I'd like to keep 9K bytes on > the ES, and don't burn my gigabitport on the 3750. > > Is there a way of bringing up this PW, ignoring the MTU negociation > between the ES card and the 3750 FE1 port? i've tried to play with > mpls mtu on the 3750 FE port, but nothing... > > tks > Sam > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From jdurand at renater.fr Fri Oct 16 05:02:58 2009 From: jdurand at renater.fr (Jerome Durand) Date: Fri, 16 Oct 2009 11:02:58 +0200 Subject: [c-nsp] 7600 MPLS PFC QoS - mls qos rewrite ip dscp Message-ID: <4AD836C2.9020002@renater.fr> Hi all, I'm trying to put QoS in our IP/MPLS backbone with 7600's and LAN cards... All the 7600's are P and PE's and therefore can receive on a backbone interface either MPLS or IP traffic. Customers are marking packets (I use their marcking for my policy) and I want to do DSCP transparency. I read the following reference: http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/mplsqos.html and found the following that I don't understand: "The *no mls qos rewrite ip dscp* command is incompatible with MPLS. The default *mls qos rewrite ip dscp* command must remain enabled in order for the PFC to assign the correct EXP value for the labels that it imposes." This seems to cause a problem for me when IP traffic flows over our network. A router being both P and PE (depending of weither traffic is just transiting or not), it can receive a pure IP packet when it is egress PE (due to PHP). But that router can also receive MPLS packets for transiting traffic. Therefore for this router I would need to leave *mls qos rewrite ip dscp* for P behaviour and *no mls qos rewrite ip dscp* for PE behaviour (to keep DSCP transparency) ??? I'm a bit lost here as I doubt router will keep both configuration statements ;) What do I misunderstand? Any hint? Thanks, Jerome From frosya84 at mail.ru Fri Oct 16 05:00:59 2009 From: frosya84 at mail.ru (=?koi8-r?Q?=EF=CC=D8=C7=C1_=F2=D5=D6=C1=CE=D3=CB=C1=D1?=) Date: Fri, 16 Oct 2009 13:00:59 +0400 Subject: [c-nsp] =?koi8-r?b?bWxzIHFvcyBvbiA3NjAwIHdpdGggbmF0aXZlIHZsYW4g?= =?koi8-r?b?YW5kIE1QTFM=?= In-Reply-To: <4AD5E71C.2040205@renater.fr> References: <4AD5E71C.2040205@renater.fr> Message-ID: Hello, >> For all egress traffic, PFC QoS uses a configurable map to derive a CoS value from the final internal >> DSCP value associated with the traffic. > > I understand, but what if your port is native? (ie. without 802.1p, > means without cos??) How does the router classify from unexisting cos? This is the output for L2 port from Port Trust section of manual : "Not all traffic carries a CoS value. Only ISL, 802.1Q, and 802.1P traffic carries a CoS value. PFC QoS applies the port CoS value to any traffic that does not carry a CoS value. On untrusted ports, PFC QoS applies the port CoS value to all traffic, overwriting any received CoS value. Received CoS values are preserved only on ports configured to trust CoS. " So, if You have not specified anything other - it will be 0 for native vlan either on trust/untrusted port (becuse port cos is 0 by default). Best regards, Olga From peter at rathlev.dk Fri Oct 16 06:13:35 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Fri, 16 Oct 2009 12:13:35 +0200 Subject: [c-nsp] QoS best practices In-Reply-To: References: Message-ID: <1255688015.2792.5.camel@abehat.net.rm.dk> On Fri, 2009-10-16 at 09:46 +1300, Raymond Lucas wrote: > Agree with others about RFC4594 being a particularly good discussion > of what different types of traffic there are and appropriate markings. Thank you all for the pointers. I seems that RFC4594 is indeed a good reference. > For quick Cisco overviews the "At a Glance" documents are quite good - > http://www.cisco.com/en/US/tech/tk543/tk759/tech_white_papers_list.html. I like the "at-a-glance" papers; they seem perfect for arguing that it's a good idea to spend some time actually defining policies based on business needs, instead of assuming that it's only a matter of configuration. :-) > Also the Cisco Enterprise QoS Solution Reference Network Design Guide is > quite good going through recommended markings and then excruciating detail > on how to implement on all sorts of different platforms. I have previously read the QoS SRND, but I must say I'm not impressed. I know by testing that e.g. Auto-QoS doesn't solve the buffering problems (it actually seems to worsen it) and I find the SRND somewhat mechanically written. I may just have had a bad day though. :-) -- Peter From md at bts.sk Fri Oct 16 06:45:57 2009 From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=) Date: Fri, 16 Oct 2009 12:45:57 +0200 Subject: [c-nsp] Cisco RSTP interop with 802.1w equipment Message-ID: <20091016104557.GA3341@bts.sk> Hi all, I wonder if there's any solution to the following interoperability issue: Cat6500 with IOS 12.2(18)SXF16 running spanning-tree mode rapid-pvst, 802.1w compliant switch running IEEE version of rapid STP When those are connected by access ports, everything works as expected. However, when connected by 802.1Q trunk with vlans 1500-1520, the behaviour is this: 802.1w switch sending BPDUs to IEEE STP MAC address (0180.c200.0000) Cat6500 sending per-vlan BPDUs to Cisco MAC address (0100.0ccc.cccd) but nothing to IEEE STP MAC address Aren't Cisco switches supposed to send BPDUs also to IEEE STP MAC address on 802.1Q trunks? Or is there any special config needed for this? Thanks & kind regards, M. From asturluismi at gmail.com Fri Oct 16 06:59:27 2009 From: asturluismi at gmail.com (luismi) Date: Fri, 16 Oct 2009 12:59:27 +0200 Subject: [c-nsp] 12.2.33 SRC5 experiences? Message-ID: <1255690767.16675.0.camel@dsba-ipso> how is the ios, any bug sev1 or interesting? From p.mayers at imperial.ac.uk Fri Oct 16 07:06:39 2009 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Fri, 16 Oct 2009 12:06:39 +0100 Subject: [c-nsp] Cisco RSTP interop with 802.1w equipment In-Reply-To: <20091016104557.GA3341@bts.sk> References: <20091016104557.GA3341@bts.sk> Message-ID: <4AD853BF.5060106@imperial.ac.uk> Marian ?urkovi? wrote: > Hi all, > > I wonder if there's any solution to the following interoperability issue: > > Cat6500 with IOS 12.2(18)SXF16 running spanning-tree mode rapid-pvst, > 802.1w compliant switch running IEEE version of rapid STP > > When those are connected by access ports, everything works as expected. > However, when connected by 802.1Q trunk with vlans 1500-1520, the > behaviour is this: > > 802.1w switch sending BPDUs to IEEE STP MAC address (0180.c200.0000) > Cat6500 sending per-vlan BPDUs to Cisco MAC address (0100.0ccc.cccd) > but nothing to IEEE STP MAC address > > Aren't Cisco switches supposed to send BPDUs also to IEEE STP MAC address Generally, no. Vlan 1 is treated specially. > on 802.1Q trunks? Or is there any special config needed for this? Vlan number 1 will interop, so if you do this: int Gi1/1 switchport mode trunk switchport trunk native vlan 1 switchport trunk allowed vlan 1,2,3 ...then vlan 1 will form an 802.1w adjacency with the neighbour, vlans 2 and 3 will just pass straight through it. In general, PVST passes straight through non-PVST switches; the non-PVST switches appear as if they're shared segments. From frosya84 at mail.ru Fri Oct 16 07:13:12 2009 From: frosya84 at mail.ru (=?koi8-r?Q?=EF=CC=D8=C7=C1_=F2=D5=D6=C1=CE=D3=CB=C1=D1?=) Date: Fri, 16 Oct 2009 15:13:12 +0400 Subject: [c-nsp] =?koi8-r?b?NzYwMCBNUExTIFBGQyBRb1MgLSBtbHMgcW9zIHJld3Jp?= =?koi8-r?b?dGUgaXAgZHNjcA==?= Message-ID: Hello, That's all because of "internal DSCP" logic.. We had that problem with SIP400 cards, and even've opened a case in TAC. If use have a PFC 3CXL, "no mls qos rewrite ip dscp" is a solution. Best regards, Olga From frosya84 at mail.ru Fri Oct 16 07:35:20 2009 From: frosya84 at mail.ru (=?koi8-r?Q?=EF=CC=D8=C7=C1_=F2=D5=D6=C1=CE=D3=CB=C1=D1?=) Date: Fri, 16 Oct 2009 15:35:20 +0400 Subject: [c-nsp] WS-X6704-10GE card doesn't perform DSCP marking (Ruzhanskaya Olga) Message-ID: Hello List! We are using WS-X6704-10GE line cards on 7604-RSP720-3CXL routers (12.2(33)SRC1). These routers play PE role in MPLS network. One interface is connected to 3750E Catalyst, and services are terminated on 7604 with dot1q subinterfaces. The problem arises when we are trying to use simle policy map, like this: Policy Map test Class test1 police cir 2097000 bc 393216 be 786432 conform-action set-dscp-transmit af33 exceed-action drop violate-action drop Class class-default set ip dscp af31 The outputs are following: 1) CORE#sh policy-map interface TenGigabitEthernet3/2.340 TenGigabitEthernet3/2.340 Service-policy input: test class-map: test1 (match-all) Match: access-group 100 police : 2096000 bps 393000 limit 393000 extended limit Earl in slot 1 : 47318 bytes 30 second offered rate 10768 bps aggregate-forwarded 47318 bytes action: set-dscp-transmit exceeded 0 bytes action: drop aggregate-forward 37848 bps exceed 0 bps class-map: class-default (match-any) Match: any set dscp 26: Earl in slot 1 : 4568517 bytes 30 second offered rate 812640 bps aggregate-forwarded 4568517 bytes 2) CORE#sh mls qos ip TenGigabitEthernet3/2.340 [In] Policy map is test [Out] Default. QoS Summary [IPv4]: (* - shared aggregates, Mod - switch module) Int Mod Dir Class-map DSCP Agg Trust Fl AgForward-By AgPoliced-By Id Id ------------------------------------------------------------------------------- Te3/2.340 1 In test1 30 197 No 0 118000 0 Te3/2.340 1 In class-defa 26 199 No 0 17857513 0 3) CORE#sh mls qos QoS is enabled globally Policy marking depends on port_trust QoS ip packet dscp rewrite disabled globally But nothing is marked (even in class-default) - I catch packets on the other side of network with source/destination matching, not with DSCP... I've read as much information about PFC QoS as possible from cisco.com, and it is written that such settings must work. But it doesn't:-( Have anyone observed such problem? Any suggestions? P.S. I'm sorry if someone have already written about this, I didn't find appropriate information in archives. Please, provide a link.. Best regards, Olga From md at bts.sk Fri Oct 16 07:45:13 2009 From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=) Date: Fri, 16 Oct 2009 13:45:13 +0200 Subject: [c-nsp] Cisco RSTP interop with 802.1w equipment In-Reply-To: <4AD853BF.5060106@imperial.ac.uk> References: <20091016104557.GA3341@bts.sk> <4AD853BF.5060106@imperial.ac.uk> Message-ID: <20091016114513.GA9476@bts.sk> On Fri, Oct 16, 2009 at 12:06:39PM +0100, Phil Mayers wrote: > >Aren't Cisco switches supposed to send BPDUs also to IEEE STP MAC address > > Generally, no. Vlan 1 is treated specially. > > >on 802.1Q trunks? Or is there any special config needed for this? > > Vlan number 1 will interop, so if you do this: > > int Gi1/1 > switchport mode trunk > switchport trunk native vlan 1 > switchport trunk allowed vlan 1,2,3 > > ...then vlan 1 will form an 802.1w adjacency with the neighbour, vlans 2 > and 3 will just pass straight through it. Is that ultimately limited to vlan #1, or could it be done with the native vlan on trunk (e.g. vlan #1520) as well? We're removing vlan #1 from all trunks by principle for obvious reasons... Thanks & kind regards, M. From p.mayers at imperial.ac.uk Fri Oct 16 08:40:55 2009 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Fri, 16 Oct 2009 13:40:55 +0100 Subject: [c-nsp] Cisco RSTP interop with 802.1w equipment In-Reply-To: <20091016114513.GA9476@bts.sk> References: <20091016104557.GA3341@bts.sk> <4AD853BF.5060106@imperial.ac.uk> <20091016114513.GA9476@bts.sk> Message-ID: <4AD869D7.8080803@imperial.ac.uk> Marian ?urkovi? wrote: > On Fri, Oct 16, 2009 at 12:06:39PM +0100, Phil Mayers wrote: >>> Aren't Cisco switches supposed to send BPDUs also to IEEE STP MAC address >> Generally, no. Vlan 1 is treated specially. >> >>> on 802.1Q trunks? Or is there any special config needed for this? >> Vlan number 1 will interop, so if you do this: >> >> int Gi1/1 >> switchport mode trunk >> switchport trunk native vlan 1 >> switchport trunk allowed vlan 1,2,3 >> >> ...then vlan 1 will form an 802.1w adjacency with the neighbour, vlans 2 >> and 3 will just pass straight through it. > > Is that ultimately limited to vlan #1, or could it be done with the native > vlan on trunk (e.g. vlan #1520) as well? vlan #1 as far as I know. > > We're removing vlan #1 from all trunks by principle for obvious reasons... Sure. It's not a very useful feature ;o) From lukasz at trabinski.net Fri Oct 16 09:10:23 2009 From: lukasz at trabinski.net (Lukasz Trabinski) Date: Fri, 16 Oct 2009 15:10:23 +0200 (CEST) Subject: [c-nsp] Xconnect on Portchannel interface [EoMPLS] Message-ID: Hello I have problem with xconnect on portchannel interface. Portchannel is up and works correctly when configuration is: interface Port-channel10 mtu 9216 no ip address load-interval 30 storm-control broadcast level 2.00 storm-control multicast level 2.00 end interface Port-channel10.508 no ip address encapsulation dot1Q 508 xconnect 10.50.0.3 508 encapsulation mpls end waw-sw1#show mpls l2transport vc 508 Local intf Local circuit Dest address VC ID Status ------------- -------------------------- --------------- ---------- ---------- Po10.508 Eth VLAN 508 10.50.0.3 508 UP waw-sw1#show interfaces description | inc Po10 Po10 up up Po10.508 up up but I want to do with untagged vlan: waw-sw1#show running-config interface port-channel 10 Building configuration... Current configuration : 211 bytes ! interface Port-channel10 mtu 9216 no ip address load-interval 30 storm-control broadcast level 2.00 storm-control multicast level 2.00 xconnect 10.50.0.3 508 encapsulation mpls end waw-sw1#show mpls l2transport vc 508 Local intf Local circuit Dest address VC ID Status ------------- -------------------------- --------------- ---------- ---------- Po10 Ethernet 10.50.0.3 508 UP It's works only 2-3 minutes and after it portchannel change do state down. Oct 16 15:07:00.404: %LINK-3-UPDOWN: Interface Port-channel10, changed state to down Oct 16 15:07:00.404: %XCONNECT-5-PW_STATUS: MPLS peer 10.50.0.3 vcid 508, VC DOWN, VC state DOWN Oct 16 15:07:02.599: %EC-SP-5-L3DONTBNDL2: Gi1/9 suspended: LACP currently not enabled on the remote port. Oct 16 15:07:08.500: %EC-SP-5-L3DONTBNDL2: Gi1/10 suspended: LACP currently not enabled on the remote port. Oct 16 15:07:11.440: %EC-SP-5-L3DONTBNDL2: Gi1/9 suspended: LACP currently not enabled on the remote port. How to do xconnect from untagged portchanel interface? -- ?T From markom at markom.info Fri Oct 16 09:54:52 2009 From: markom at markom.info (Marko Milivojevic) Date: Fri, 16 Oct 2009 13:54:52 +0000 Subject: [c-nsp] Xconnect on Portchannel interface [EoMPLS] In-Reply-To: References: Message-ID: 2009/10/16 Lukasz Trabinski : > Hello > > I have problem with xconnect on portchannel interface. [...] > How to do xconnect from untagged portchanel interface? Have you tried disabling LACP on the EC interface and have it statically configured (mode on)? -- Marko CCIE #18427 (SP) My network blog: http://cisco.markom.info/ From leonardo.souza at nec.com.br Fri Oct 16 11:04:34 2009 From: leonardo.souza at nec.com.br (Leonardo Gama Souza) Date: Fri, 16 Oct 2009 12:04:34 -0300 Subject: [c-nsp] RES: IOS question for c12406 In-Reply-To: <18B2C6E38A3A324986B392B2D18ABC5102B992@fnb1mbx01.gci.com> References: <18B2C6E38A3A324986B392B2D18ABC5102B992@fnb1mbx01.gci.com> Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D02CFEFDD@spsrvmail03.nec.br> Hi, Both are similar in performance and suitable for you hardware, but watch out for some bugs that were not fixed in 33S5 yet. CSCsz12423, CSCsx94290 and CSCsz19255. I'd go with SY. You can check additional information at: http://www.cisco.com/en/US/docs/ios/12_0s/release/ntes/120SNEWF.html http://www.cisco.com/en/US/docs/ios/12_0/12_0sy/release/notes/120SYrn.ht ml Unfortunately they are not updated as well... -----Mensagem original----- De: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] Em nome de Leif Sawyer Enviada em: quinta-feira, 15 de outubro de 2009 21:10 Para: Eninja Cc: cisco-nsp at puck.nether.net Assunto: Re: [c-nsp] IOS question for c12406 I'm stating a that Feature Set Navigator is unstable for purposes of my research (based on the (d)CEF issue, and lack of updates) and asking for feedback about which train (SY or S) to use on my 12406, given the listed linecards. > -----Original Message----- > From: Eninja [mailto:eninja at gmail.com] > Sent: Thursday, October 15, 2009 4:07 PM > To: Leif Sawyer > Cc: cisco-nsp at puck.nether.net; e ninja > Subject: Re: [c-nsp] IOS question for c12406 > > Leif, > > Not sure what you're asking but GSR 12K is a distributed > platform where each LC switches packets independently of the > RP....and whatever IOS is running on the box. > > Eninja > > > On Oct 15, 2009, at 10:37 PM, Leif Sawyer wrote: > > > In the process of upgrading from a c12008 to a c12406, with the > > following > > linecards: > > > > SIP-601 + SPA-10X1GE-V2 > > 2 x PRP-2 > > LC-4OC3/POS-SM > > 4GE-SFP-LC > > > > > > Looks like I've got a choice between these two: > > c12kprp-k4p-mz.120-32.SY10.bin > > c12kprp-k4p-mz.120-33.S5.bin > > > > feature-set comparison doesn't list these, but based on the most > > recent version in it, the only difference that I would be concerned > > with is > > CEF/dCEF - Cisco Express Forwarding > > > > however, in botting the SY train, it appears that dCEF truly is > > enabled. > > > > > > Anybody have any experience with these, recommendations, > comments or > > caveats? > > > > > > Thanks, > > > > Leif > > _______________________________________________ > > cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From peter at rathlev.dk Fri Oct 16 11:48:47 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Fri, 16 Oct 2009 17:48:47 +0200 Subject: [c-nsp] WS-X6704-10GE card doesn't perform DSCP marking (Ruzhanskaya Olga) In-Reply-To: References: Message-ID: <1255708127.2704.1.camel@abehat.net.rm.dk> Hi Olga, On Fri, 2009-10-16 at 15:35 +0400, ????? ????????? wrote: > 3) CORE#sh mls qos [...] > QoS ip packet dscp rewrite disabled globally > > But nothing is marked (even in class-default) - I catch packets on the > other side of network with source/destination matching, not with > DSCP... Would you happen to have a "no mls qos rewrite ip dscp" command in global config? -- Peter From CFlint at mt.gov Fri Oct 16 12:23:15 2009 From: CFlint at mt.gov (Flint, Chris) Date: Fri, 16 Oct 2009 10:23:15 -0600 Subject: [c-nsp] WS-X6704-10GE card doesn't perform DSCP marking Message-ID: <169F1B4CBA47CC4F93BF2BD0A504C0552EF5C09EAF@doaisd05222.state.mt.ads> Per Cisco's site, I don't think the 6704 can use DSCP markings. Under the 'Primary Features and Benefits' section the 6704 is listed as COS only, and the 6708 and 6716 as COS/DSCP. http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a00801dce34_ps4835_Products_Data_Sheet.html Chris --------------------------- Message: 2 Date: Fri, 16 Oct 2009 17:48:47 +0200 From: Peter Rathlev To: ????? ????????? Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] WS-X6704-10GE card doesn't perform DSCP marking (Ruzhanskaya Olga) Message-ID: <1255708127.2704.1.camel at abehat.net.rm.dk> Content-Type: text/plain; charset="UTF-8" Hi Olga, On Fri, 2009-10-16 at 15:35 +0400, ????? ????????? wrote: > 3) CORE#sh mls qos [...] > QoS ip packet dscp rewrite disabled globally > > But nothing is marked (even in class-default) - I catch packets on the > other side of network with source/destination matching, not with > DSCP... Would you happen to have a "no mls qos rewrite ip dscp" command in global config? -- Peter From Jeff.Wojciechowski at midlandpaper.com Fri Oct 16 14:08:17 2009 From: Jeff.Wojciechowski at midlandpaper.com (Jeff Wojciechowski) Date: Fri, 16 Oct 2009 13:08:17 -0500 Subject: [c-nsp] Possible interface counter bug, but wanted to check.. In-Reply-To: <20091015181849.GD1508@greenie.muc.de> References: <20091015181849.GD1508@greenie.muc.de> Message-ID: <6B8401A83219DF499C34DEAEE9A5999219F620DA79@XBOX.midlandpaper.com> Yea just had my own counter anomaly from show service-module on a 2821 router running 12.4(22)T3 ip base: Total Data (last 96 15 minute intervals): 0 Line Code Violations, 0 Path Code Violations 2147483647 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins Correct me if I am wrong but 96 x 15 min = 1 day. 2,147,483,647 seconds = 24,855.1348 days??? Cisco into time travel now? Think you need an enhanced IOS image for that :) -Jeff -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Gert Doering Sent: Thursday, October 15, 2009 1:19 PM To: Drew Weaver Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Possible interface counter bug, but wanted to check.. Hi, On Thu, Oct 15, 2009 at 12:56:07PM -0400, Drew Weaver wrote: > We have a Gig-E connection going from a GSR to a 6500 and the 6500 > appears to be showing almost double the amount of traffic/packets per > second than the GSR is showing in its interface counters Not that anybody has ever heard of "counter bugs" in IOS before... :-) > The 6500 is running: 12.2(18)SXD7b This IOS is ancient. I have not seen obvious counter bugs of this sort on our 6500s yet, but the oldest IOS we've ever used there is SXF. So it might or might not be an old-IOS-bug... If you sum up *other* interfaces on these boxes, or compare the interface byte counters, do they agree with the GSR or the 6500? (Since the values are *so* different, just getting a rough idea from looking at the interface counters every 5 minute and calculating the average bandwidth by hand should suffice) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From drew.weaver at thenap.com Fri Oct 16 15:09:22 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 16 Oct 2009 15:09:22 -0400 Subject: [c-nsp] Right sizing new router purchase Message-ID: Howdy, We generally only make major upgrades to our network on a 3-4year cycle and that cycle has now cycled =) Our main concern is 'most bang for the buck' followed by working NetFlow, and rock-solid reliability. This is the configuration we're looking at: 12810 2xPRP-2 12000-SIP-600 SPA-10X1GE-V2 This device will be used as an Internet border router with several (as many as 3) connections to the Internet /w full BGP routes. We are currently running 12012s /w GRP-B and they're definitely starting to show their age. My question is, with what we're looking at (and considering the stuff we're currently using) does anyone see a problem with expecting 3-4 years out of this new equipment? Thanks for any advice =) -Drew From mtinka at globaltransit.net Fri Oct 16 15:57:17 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Sat, 17 Oct 2009 03:57:17 +0800 Subject: [c-nsp] 12.2.33 SRC5 experiences? In-Reply-To: <1255690767.16675.0.camel@dsba-ipso> References: <1255690767.16675.0.camel@dsba-ipso> Message-ID: <200910170357.24287.mtinka@globaltransit.net> On Friday 16 October 2009 06:59:27 pm luismi wrote: > how is the ios, any bug sev1 or interesting? We shall be migrating a number of 7200 boxes over to SRC5 by the end of the month. SRC5 is only bug fixes, no new features. A lot of the issues we've raised before SRC5 have, apparently, been fixed. A number of bugs we've been chasing since SRC have, apparently, been fixed too (finally, I hope). Lab'ing it so far seems promising, but will report back if anything is out of place, next month :-). We've been waiting for this release a looooooong time. Something tells me it might be the most stable, yet. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From mtinka at globaltransit.net Fri Oct 16 16:04:55 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Sat, 17 Oct 2009 04:04:55 +0800 Subject: [c-nsp] Right sizing new router purchase In-Reply-To: References: Message-ID: <200910170404.56349.mtinka@globaltransit.net> On Saturday 17 October 2009 03:09:22 am Drew Weaver wrote: > This is the configuration we're looking at: > > 12810 > 2xPRP-2 > 12000-SIP-600 > SPA-10X1GE-V2 You're more likely to get a CRS-1 for about 5% - 10% cheaper than a GSR or XR 12000 platform these days. That'd surely be more bang for your buck! Talk to your account team, you'd be surprised. We were :-). Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From peter at rathlev.dk Fri Oct 16 16:24:21 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Fri, 16 Oct 2009 22:24:21 +0200 Subject: [c-nsp] Possible interface counter bug, but wanted to check.. In-Reply-To: <6B8401A83219DF499C34DEAEE9A5999219F620DA79@XBOX.midlandpaper.com> References: <20091015181849.GD1508@greenie.muc.de> <6B8401A83219DF499C34DEAEE9A5999219F620DA79@XBOX.midlandpaper.com> Message-ID: <1255724661.13394.1.camel@abehat.net.rm.dk> On Fri, 2009-10-16 at 13:08 -0500, Jeff Wojciechowski wrote: > Yea just had my own counter anomaly from show service-module on a 2821 > router running 12.4(22)T3 ip base: > > Total Data (last 96 15 minute intervals): > 0 Line Code Violations, 0 Path Code Violations > 2147483647 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded > Mins > > Correct me if I am wrong but 96 x 15 min = 1 day. > > 2,147,483,647 seconds = 24,855.1348 days??? Cisco into time travel > now? Think you need an enhanced IOS image for that :) It's 2^31 - 1, so probably some simple "invalid" value of sorts. -- Peter From kgraham at industrial-marshmallow.com Fri Oct 16 23:48:39 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Fri, 16 Oct 2009 20:48:39 -0700 (PDT) Subject: [c-nsp] Monitoring software-switching utilization ("IP Input") on modular/ION Message-ID: <807329.97018.qm@web503.biz.mail.mud.yahoo.com> We were considering pushing out monitoring templates watching for broken devices doing slow-path switching seeing high (>10%?) utilization of the IP Input process. In ION, presumably this lumped in with lots of other stuff in "ios-base". Is there a good way to get at this data, or am I not understanding modular properly? Similarly, is anyone aware of a consistent identifier that would indicate that a platform is hardware-accelerated (ie. L3 swouter or perhaps PXF)? To keep monitoring configuration simple, I'd like to apply the same checks across the board, which would allow us to flag devices where heavy interrupt switching is actually a Bad Thing. From alex at digriz.org.uk Sat Oct 17 05:24:29 2009 From: alex at digriz.org.uk (Alexander Clouter) Date: Sat, 17 Oct 2009 10:24:29 +0100 Subject: [c-nsp] filtering IPV6 for L2 bridged traffic ? References: <53344014-9EA3-401A-AD50-91A139B98DEB@Princeton.EDU> Message-ID: Jeff Fitzwater wrote: > > I am running SXI code on sup720-CXL and need to filter out certain > IPV6 packets like MDNS on trunked L2 port? > > I was going to use an vlan access-map but it appears that it does not > allow me to do a MATCH on an IPV6 acl, I guess I am stuck with a MAC > ACL to filter bridged IPV6 traffic. > > Any ideas on this issue? How else can it be done? > Eugh, I am having a similar problem. Seems our 3750's are blind to 'permit any any 0x86dd 0x0' and I have to RSPAN *everything* and get it filtered on the next hop...then to add to my pain it's awkward and not wholely predictable even there; on a pair of 6509's. For you however there might be a solution. Your magic cookie hint is... http://en.wikipedia.org/wiki/Multicast_address#Ethernet_multicast_addresses Enjoy -- Alexander Clouter .sigmonster says: What's love but a second-hand emotion? -- Tina Turner From vlado_r at net.hr Sat Oct 17 12:16:38 2009 From: vlado_r at net.hr (Vladimir Rabljenovic) Date: Sat, 17 Oct 2009 18:16:38 +0200 Subject: [c-nsp] MLPPP QoS issue on SPA-1XCHSTM1/OC3 - traffic stops when link is congested Message-ID: <4ad9ede6.51.7768.603909041@net.hr> hello, I have Cisco 7606, RSP720, SIP-400 linecard with SPA-1XCHSTM1/OC3 in it. Ch STM-1 is connected to SDH MUX, which delivers 2 x E1 from CPE location. configuration is done with ML-PPP bundling, ppp MRU is set currently to 680 bytes, and MRRU to 674 bytes (small packets are transferred, target is to have as small as possible delay/jitter without fragmentation). on Multilink interface there is outgoing QoS policy, one priority class, 2 AF classes and class default. AF classes and class default are sharing available bandwidth with remaining ratio percentage-based (1% configured for class default). with one test tool we create realtime and important traffic going to EF and AF classes/queues respectively, while with traffic generator we create UDP stream of 4Mbps (packet size was 1500 at the beginning, now it is changed to around 500bytes), going into default class. at some point in time, suddenly, traffic in outgoing direction stops completely, we saw it with Nethawk, cisco 7606 did not send almost nothing on the line. what is only being captured is regular LCP packets. Since both PPP and ML-PPP stayed up, it seems it is not PPP related issue, but somehow QoS. on QoS map, in EF and AF class, we see some strange counters, some small offered rate, and exactly the same value for drop rate (it looks like counters are not accurate, since there should be more traffic in those classes). So, link was congested for a some hours, and then suddenly stop to send the traffic out on the interface. at the same time, incoming packets are arriving on the interface normally, and being forwarded to other egress interface. when UDP traffic generator is stopped, connectivity is again there. if someone has some idea how exactly does QoS policy with remaining ratio reflects in this hardware and ML-PPP configuration, or has some idea what we should look for, i would really appreciate it. also, could someone explain what is the connection between MLPPP fragmentation in hardware (for this card,it is possible to have 3 values, 128,256 and 512 bytes, 512 is enabled by default) and MRU/MTU/MRRU values? Receive buffer limit 10784 bytes, frag timeout 1000 ms Bundle is Distributed 0/0 fragments/bytes in reassembly list 0 lost fragments, 0 reordered 0/0 discarded fragments/bytes, 0 lost received 0x0 received sequence, 0x0 sent sequence Distributed fragmentation on. Fragment size 512. Multilink in Hardware. Member links: 2 active, 0 inactive (max not set, min not set) Se2/1/0.1/1/1/2:1, since 01:57:16 Se2/1/0.1/1/1/1:1, since 01:57:16 thanks in advance, vlado From philxor at gmail.com Sat Oct 17 19:19:52 2009 From: philxor at gmail.com (Phil Bedard) Date: Sat, 17 Oct 2009 19:19:52 -0400 Subject: [c-nsp] Cisco RSTP interop with 802.1w equipment In-Reply-To: <20091016114513.GA9476@bts.sk> References: <20091016104557.GA3341@bts.sk> <4AD853BF.5060106@imperial.ac.uk> <20091016114513.GA9476@bts.sk> Message-ID: <52A6C3BE-73FD-4198-A61A-12C6219367A3@gmail.com> If you change the native VLAN on the cisco, it will still only send to the IEEE STP MAC on VLAN 1. If you were using PVST+ on the Cisco changing the native vlan will tell it to send PVST+ BPDUs to the Cisco MAC untagged on that VLAN. Phil On Oct 16, 2009, at 7:45 AM, Marian ?urkovi? wrote: > On Fri, Oct 16, 2009 at 12:06:39PM +0100, Phil Mayers wrote: >>> Aren't Cisco switches supposed to send BPDUs also to IEEE STP MAC >>> address >> >> Generally, no. Vlan 1 is treated specially. >> >>> on 802.1Q trunks? Or is there any special config needed for this? >> >> Vlan number 1 will interop, so if you do this: >> >> int Gi1/1 >> switchport mode trunk >> switchport trunk native vlan 1 >> switchport trunk allowed vlan 1,2,3 >> >> ...then vlan 1 will form an 802.1w adjacency with the neighbour, >> vlans 2 >> and 3 will just pass straight through it. > > Is that ultimately limited to vlan #1, or could it be done with the > native > vlan on trunk (e.g. vlan #1520) as well? > > We're removing vlan #1 from all trunks by principle for obvious > reasons... > > Thanks & kind regards, > > M. > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From gsgranados at comcast.net Sat Oct 17 20:22:31 2009 From: gsgranados at comcast.net (Scott Granados) Date: Sat, 17 Oct 2009 17:22:31 -0700 Subject: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel Message-ID: <003e01ca4f89$15e3b980$830f120a@am.thmulti.com> Hi, I'm having the following problem. I have an ASA5520 running ASA724-33-k8 and a Pix 501 running 6.3. I have the following on the asa access-list test-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.128 255.255.255.240 access-list test-vpn extended permit ip 10.18.1.0 255.255.255.0 10.18.15.128 255.255.255.240 crypto map vpn-ra-map 20 match test-vpn crypto map vpn-ra-map 20 peer 75.x.x.28 crypto map vpn-ra-map 20 transform vpn-transform1 vpn-transform2 vpn-transform3 vpn-transform4 crypto map vpn-ra-map 20 reverse-route the transforms are simply aes and aes-256 des and 3des each with an md5 or sha hash isakmp policies exist and match as well on the pix access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.0.0 255.255.255.0 access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.1.0 255.255.255.0 crypto map map1 match test-vpn crypto map map1 interface outside crypto map map1 peer 206.x.x.232 isakmp policy 20 preshare isakmp policy 20 group 2 isakmp policy 20 encrypt aes-256 isakmp policy 20 hash sha isakmp policy 20 life 28800 A show isakmp sa and show crypto ipsec on both sides seems to show a tunnel up. With a debug crypto isakmp and debug crypto ipsec on the pix 501 I keep getting IKMP_NO_ERR_NO_TRANS The 5520 side shows a tunnel active and the pix a tunnel idle. Pings or traffic of any form can't traverse the tunnel. What have I missed? Any pointers would be appreciated. Thanks Scott From rwest at zyedge.com Sat Oct 17 20:36:50 2009 From: rwest at zyedge.com (Ryan West) Date: Sat, 17 Oct 2009 20:36:50 -0400 Subject: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel In-Reply-To: <003e01ca4f89$15e3b980$830f120a@am.thmulti.com> References: <003e01ca4f89$15e3b980$830f120a@am.thmulti.com> Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DFAF3F29@zy-ex1.zyedge.local> Scott, Can you post your 'show ipsec sa' and 'show isakmp sa' output on both firewall, as well as 'show nat' and the associated nat 0 entries? Also please post the contents of the 4 transforms on the ASA as well as the transforms on the PIX. -ryan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados Sent: Saturday, October 17, 2009 8:23 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel Hi, I'm having the following problem. I have an ASA5520 running ASA724-33-k8 and a Pix 501 running 6.3. I have the following on the asa access-list test-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.128 255.255.255.240 access-list test-vpn extended permit ip 10.18.1.0 255.255.255.0 10.18.15.128 255.255.255.240 crypto map vpn-ra-map 20 match test-vpn crypto map vpn-ra-map 20 peer 75.x.x.28 crypto map vpn-ra-map 20 transform vpn-transform1 vpn-transform2 vpn-transform3 vpn-transform4 crypto map vpn-ra-map 20 reverse-route the transforms are simply aes and aes-256 des and 3des each with an md5 or sha hash isakmp policies exist and match as well on the pix access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.0.0 255.255.255.0 access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.1.0 255.255.255.0 crypto map map1 match test-vpn crypto map map1 interface outside crypto map map1 peer 206.x.x.232 isakmp policy 20 preshare isakmp policy 20 group 2 isakmp policy 20 encrypt aes-256 isakmp policy 20 hash sha isakmp policy 20 life 28800 A show isakmp sa and show crypto ipsec on both sides seems to show a tunnel up. With a debug crypto isakmp and debug crypto ipsec on the pix 501 I keep getting IKMP_NO_ERR_NO_TRANS The 5520 side shows a tunnel active and the pix a tunnel idle. Pings or traffic of any form can't traverse the tunnel. What have I missed? Any pointers would be appreciated. Thanks Scott _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From lukasz at bromirski.net Sat Oct 17 21:47:53 2009 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Sun, 18 Oct 2009 03:47:53 +0200 Subject: [c-nsp] 3560 buffering In-Reply-To: <1255514737.3677.8.camel@abehat.net.rm.dk> References: <5A69C25361FED34F83ABF05F50475245072BC1BB@wally.walleyetrading.net> <1255449595.3217.40.camel@abehat.net.rm.dk> <20091014094501.GF8830@thorgal> <1255514737.3677.8.camel@abehat.net.rm.dk> Message-ID: <4ADA73C9.4070908@bromirski.net> On 2009-10-14 12:05, Peter Rathlev wrote: > someswitch#sh platform port-asic stats enqueue gi0/1 > Interface Gi0/1 TxQueue Enqueue Statistics > Queue 0 > Weight 0 Frames 2 > Queue 1 > Weight 1 Frames 34736 > Weight 2 Frames 318358119 > Queue 2 > Queue 3 > Weight 2 Frames 425983701 > someswitch# > It seems that all queues are actually used according to the default CoS > map. I think I'm getting confused here. Can anybody shed light on this? With the 'mls qos' not configured, the output TX queue is choosen by looking at the ingress QoS label - which for this configuration has value of 0 (sh platform qos label, remember the output is 0-based, not 1-based, so for "Tx queue-htr" it will show "3-2", which means fourth queue actually). Next, there's some traffic that will get into TX Q1, as it's queue used by CPU to do it's control plane traffic and this can't be changed as You noted. By simply enabling 'mls qos', the traffic will be assigned a QoS label of 1 and it means it will move to be serviced by TX Q2 in default setting. Hope this clears a bit. As for the original poster problems with drops - I'd enable mls qos and make sure the all traffic and buffers are allocated to TX Q1. Bear in mind however bad things can happen for control-plane traffic in such config if there's long oversubscription of the queue itself. -- "Everything will be okay in the end. | ?ukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net From frosya84 at mail.ru Sun Oct 18 13:19:07 2009 From: frosya84 at mail.ru (=?windows-1251?Q?=CE=EB=FC=E3=E0_=D0=F3=E6=E0=ED=F1=EA=E0=FF?=) Date: Sun, 18 Oct 2009 21:19:07 +0400 Subject: [c-nsp] =?windows-1251?q?WS-X6704-10GE_card_doesn=27t_perform_DSC?= =?windows-1251?q?P_marking?= In-Reply-To: <1255708127.2704.1.camel@abehat.net.rm.dk> References: <1255708127.2704.1.camel@abehat.net.rm.dk> Message-ID: Thank You for answers, > Would you happen to have a "no mls qos rewrite ip dscp" command in > global config? Yes, I have this command in global config. We've added it to save DSCP transparency on the edge routers - because without it, DSCP field is rewritten with MPLS EXP field value. And there are a lot of client's services with policy-maps with double-set statements : set mpls exp imposition Y set ip dscp XX > Try to add "mls qos rewrite ip dscp" to you global configuration. But this will destroy DSCP transparency.. I've used this link (we have RSP720, 3CXL): http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/rsp720.html#wp1042557 Although, I've tried to add "mls qos rewrite ip dscp", the result is the same - traffic is matched on the router, but not marked:-( Best regards, Olga From jckdaniels12 at gmail.com Sun Oct 18 15:16:59 2009 From: jckdaniels12 at gmail.com (jack daniels) Date: Mon, 19 Oct 2009 00:46:59 +0530 Subject: [c-nsp] AUDIT In-Reply-To: <8bb137f40910091247m47d1f8c9x830c2fd448f9a2e2@mail.gmail.com> References: <8bb137f40910070050n1e1e732aoca3d5ba4411debaa@mail.gmail.com> <4ACC65ED.6040700@resolution.de> <8bb137f40910091247m47d1f8c9x830c2fd448f9a2e2@mail.gmail.com> Message-ID: <8bb137f40910181216o2ba0af92n116d6b956f43ba60@mail.gmail.com> Hi all, I wanted help in like what parameters to check in output of show tech of router or switch ----- U all can help with your experience Like bootvar , config register , bpdugaurd etc for switch.... Regards J.Daniels On Sat, Oct 10, 2009 at 1:17 AM, jack daniels wrote: > Hi All, > > Please advise any doc which can help in studying " show Tech-support" for > switch and router output while doing audit. > > Regards > J.Daniels > > On Wed, Oct 7, 2009 at 3:27 PM, Thorsten Dahm wrote: > >> jack daniels wrote: >> >>> I have been assigned to do AUDIT ( LAN / WAN ) for a NETWORK comprising >>> of >>> devices 2950 , 3750 , 4500 , 2800 , 2600 , 7206 VXR . Please advice which >>> commands showuld I need to conectrate more and check outputs for making >>> audit report >>> >> >> If you are a bit more specific about what kind of Audit we could perhaps >> help better. >> >> For now: RANCID + diff/grep could be a good start. >> >> cheers, >> Thorsten >> > > From rlucas at nz1.ibm.com Sun Oct 18 17:35:09 2009 From: rlucas at nz1.ibm.com (Raymond Lucas) Date: Mon, 19 Oct 2009 10:35:09 +1300 Subject: [c-nsp] QoS best practices In-Reply-To: References: Message-ID: Peter, On Fri, 2009-10-16 at 12:13 +0200, Peter Rathlev wrote: > I have previously read the QoS SRND, but I must say I'm not impressed. I > know by testing that e.g. Auto-QoS doesn't solve the buffering problems > (it actually seems to worsen it) and I find the SRND somewhat > mechanically written. I may just have had a bad day though. :-) I was more mentioning the SRND in the context of what markings to use for what traffic and how the different queues should be treated. You are right that some of the implementation recommendations aren't great. We also saw the buffering issue I think you are referring to. For us it was 3750MEs acting as WAN routers. The same QoS model as 3560s and 'normal' 3750s. Much testing and tweaking of buffer sizes followed and we ended up with good enough results for us using: Queue : 1 2 3 4 ---------------------------------------------- buffers : 20 30 45 5 threshold1: 100 700 700 40 threshold2: 100 800 800 100 reserved : 50 100 100 100 maximum : 400 1000 1000 100 Egress Priority Queue : enabled Shaped queue weights (absolute) : 3 0 0 0 Shared queue weights : 1 60 35 5 This is for an enterprise scenario. We never had problems with q1, presumably since it's priority and there shouldn't be too much need for queuing anyway. q4 is bulk traffic in our scenario so we aren't worried about drops there anyway. It is also worth noting these interfaces were being rate limited by setting the interface speed to 10/100 as appropriate and using "srr-queue bandwidth limit x" to get values between 2 and 64 Mbps which I don't think helped. We never used Auto-QoS so I can't comment on that. I could discuss further with you off list if you want. Cheers, Ray From gsgranados at comcast.net Sun Oct 18 21:14:37 2009 From: gsgranados at comcast.net (Scott Granados) Date: Sun, 18 Oct 2009 18:14:37 -0700 Subject: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel References: <003e01ca4f89$15e3b980$830f120a@am.thmulti.com> <6E21B2BDEF6E714EA0B5BA8D5D0E140124DFAF3F29@zy-ex1.zyedge.local> Message-ID: <00c301ca5059$87736ac0$830f120a@am.thmulti.com> Hi, thanks for the help, here are the important bits. PIX 501 test-fw# show isakmp sa Total : 1 Embryonic : 0 dst src state pending created 75.x.x.28 206.x.x.232 QM_IDLE 0 0 test-fw# sh  show ipsec sa interface: outside Crypto map tag: map1, local addr. 75.x.x.28 local ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) remote ident (addr/mask/prot/port): (10.18.5.0/255.255.255.0/0/0) current_peer: 206.x.x.232:0 PERMIT, flags={origin_is_acl,} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 75.x.x.28, remote crypto endpt.: 206.x.x.232 path mtu 1500, ipsec overhead 0, media mtu 1500 current outbound spi: 0 inbound esp sas: inbound ah sas: <--- More ---> inbound pcp sas: outbound esp sas: outbound ah sas: outbound pcp sas: local ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) remote ident (addr/mask/prot/port): (10.18.3.0/255.255.255.0/0/0) current_peer: 206.x.x.232:0 PERMIT, flags={origin_is_acl,} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 <--- More ---> local crypto endpt.: 75.x.x.28, remote crypto endpt.: 206.x.x.232 path mtu 1500, ipsec overhead 0, media mtu 1500 current outbound spi: 0 inbound esp sas: inbound ah sas: inbound pcp sas: outbound esp sas: outbound ah sas: outbound pcp sas: local ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) <--- More ---> remote ident (addr/mask/prot/port): (10.18.1.0/255.255.255.0/0/0) current_peer: 206.x.x.232:500 PERMIT, flags={origin_is_acl,} #pkts encaps: 1748, #pkts encrypt: 1748, #pkts digest 1748 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 1, #recv errors 0 local crypto endpt.: 75.x.x.28, remote crypto endpt.: 206.x.x.232 path mtu 1500, ipsec overhead 72, media mtu 1500 current outbound spi: 7631b778 inbound esp sas: spi: 0x38a1f0f(59383567) transform: esp-aes-256 esp-sha-hmac , in use settings ={Tunnel, } slot: 0, conn id: 1, crypto map: map1 sa timing: remaining key lifetime (k/sec): (4608000/17772) IV size: 16 bytes replay detection support: Y inbound ah sas: <--- More ---> inbound pcp sas: outbound esp sas: spi: 0x7631b778(1982969720) transform: esp-aes-256 esp-sha-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2, crypto map: map1 sa timing: remaining key lifetime (k/sec): (4607836/17718) IV size: 16 bytes replay detection support: Y outbound ah sas: outbound pcp sas: local ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) remote ident (addr/mask/prot/port): (10.18.0.0/255.255.255.0/0/0) <--- More ---> current_peer: 206.x.x.232:0 PERMIT, flags={origin_is_acl,} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 75.x.x.28, remote crypto endpt.: 206.x.x.232 path mtu 1500, ipsec overhead 0, media mtu 1500 current outbound spi: 0 inbound esp sas: inbound ah sas: inbound pcp sas: outbound esp sas: <--- More ---> outbound ah sas: outbound pcp sas: CONFIG test-fw# write t Building configuration... : Saved : PIX Version 6.3(5) interface ethernet0 auto interface ethernet1 100full nameif ethernet0 outside security0 nameif ethernet1 inside security100 hostname test-fw domain-name mycompany.com fixup protocol dns maximum-length 512 fixup protocol ftp 21 fixup protocol h323 h225 1720 fixup protocol h323 ras 1718-1719 fixup protocol http 80 fixup protocol rsh 514 fixup protocol rtsp 554 fixup protocol sip 5060 fixup protocol sip udp 5060 fixup protocol skinny 2000 fixup protocol smtp 25 fixup protocol sqlnet 1521 fixup protocol tftp 69 names access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.0.0 255.255.255.0 access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.1.0 255.255.255.0 access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.3.0 255.255.255.0 access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.5.0 255.255.255.0 access-list inside permit ip any any access-list outside permit icmp any any access-list outside deny ip any any pager lines 24 icmp permit 10.18.15.128 255.255.255.240 inside mtu outside 1500 mtu inside 1500 ip address outside 75.x.x.28 255.255.255.248 ip address inside 10.18.15.129 255.255.255.240 ip audit info action alarm ip audit attack action alarm pdm history enable arp timeout 14400 global (outside) 1 75.x.x.26-75.x.x.27 netmask 255.255.255.248 global (outside) 1 75.x.x.29 netmask 255.255.255.248 nat (inside) 0 access-list test-vpn nat (inside) 1 0.0.0.0 0.0.0.0 0 0 access-group inside in interface inside route outside 0.0.0.0 0.0.0.0 75.147.137.30 1 timeout xlate 3:00:00 timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00 timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00 timeout sip-disconnect 0:02:00 sip-invite 0:03:00 timeout uauth 0:05:00 absolute aaa-server TACACS+ protocol tacacs+ aaa-server TACACS+ max-failed-attempts 3 aaa-server TACACS+ deadtime 10 aaa-server RADIUS protocol radius aaa-server RADIUS max-failed-attempts 3 aaa-server RADIUS deadtime 10 aaa-server LOCAL protocol local http server enable http 10.18.15.130 255.255.255.255 inside no snmp-server location no snmp-server contact snmp-server community public no snmp-server enable traps floodguard enable sysopt connection permit-ipsec crypto ipsec transform-set set1 esp-aes-256 esp-sha-hmac crypto map map1 10 ipsec-isakmp crypto map map1 10 match address test-vpn crypto map map1 10 set peer 206.x.x.232 crypto map map1 10 set transform-set set1 crypto map map1 interface outside isakmp enable outside isakmp key ******** address 206.x.x.232 netmask 255.255.255.255 isakmp nat-traversal 20 isakmp policy 20 authentication pre-share isakmp policy 20 encryption aes-256 isakmp policy 20 hash sha isakmp policy 20 group 2 isakmp policy 20 lifetime 3600 isakmp policy 30 authentication pre-share isakmp policy 30 encryption aes-256 isakmp policy 30 hash sha isakmp policy 30 group 2 isakmp policy 30 lifetime 28800 dhcpd address 10.18.15.131-10.18.15.136 inside dhcpd dns 208.67.222.222 208.67.220.220 dhcpd wins 10.18.1.14 10.18.1.15 dhcpd lease 9000 dhcpd ping_timeout 750 dhcpd auto_config outside dhcpd enable inside encrypted privilege 2 terminal width 80 [OK] test-fw#          (*NOTE* the dns servers listed are opendns public servers so releasing the IP has no risk) ASA 5520 side Active SA: 10 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey) Total IKE SA: 10 6 IKE Peer: 75.x.x.28 Type : L2L Role : initiator Rekey : no State : MM_ACTIVE vpn# show ipsec sa interface: outside Crypto map tag: dynmap, seq num: 10, local addr: 206.x.x.232 Crypto map tag: vpn-ra-map, seq num: 20, local addr: 206.x.x.232 access-list test-vpn permit ip 10.18.0.0 255.255.255.0 10.18.15.128 255.255.255.240 local ident (addr/mask/prot/port): (10.18.0.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) current_peer: 75.x.x.28 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 206.x.x.232, remote crypto endpt.: 75.x.x.28 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: A4D9786C inbound esp sas: spi: 0x6F906AE6 (1871735526) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4373999/27751) IV size: 16 bytes replay detection support: Y outbound esp sas: spi: 0xA4D9786C (2765715564) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4374000/27751) IV size: 16 bytes replay detection support: Y Crypto map tag: vpn-ra-map, seq num: 20, local addr: 206.x.x.232 access-list test-vpn permit ip 10.18.1.0 255.255.255.0 10.18.15.128 255.255.255.240 local ident (addr/mask/prot/port): (10.18.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) current_peer: 75.x.x.28 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 1942, #pkts decrypt: 1942, #pkts verify: 1942 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 206.x.x.232, remote crypto endpt.: 75.x.x.28 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: 038A1F0F inbound esp sas: spi: 0x7631B778 (1982969720) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4373819/16564) IV size: 16 bytes replay detection support: Y outbound esp sas: spi: 0x038A1F0F (59383567) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4374000/16564) IV size: 16 bytes replay detection support: Y Crypto map tag: vpn-ra-map, seq num: 20, local addr: 206.x.x.232 access-list test-vpn permit ip 10.18.3.0 255.255.255.0 10.18.15.128 255.255.255.240 local ident (addr/mask/prot/port): (10.18.3.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) current_peer: 75.x.x.28 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 206.x.x.232, remote crypto endpt.: 75.x.x.28 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: B6096032 inbound esp sas: spi: 0x62DA2363 (1658463075) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4373999/27783) IV size: 16 bytes replay detection support: Y outbound esp sas: spi: 0xB6096032 (3054067762) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4374000/27783) IV size: 16 bytes replay detection support: Y Crypto map tag: vpn-ra-map, seq num: 20, local addr: 206.x.x.232 access-list test-vpn permit ip 10.18.5.0 255.255.255.0 10.18.15.128 255.255.255.240 local ident (addr/mask/prot/port): (10.18.5.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) current_peer: 75.x.x.28 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 206.x.x.232, remote crypto endpt.: 75.x.x.28 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: 75F7C1A5 inbound esp sas: spi: 0x01E9D9E2 (32102882) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4373999/27791) IV size: 16 bytes replay detection support: Y outbound esp sas: spi: 0x75F7C1A5 (1979171237) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4374000/27791) IV size: 16 bytes replay detection support: Y vpn# write t : Saved : ASA Version 7.2(4)33 ! hostname vpn domain-name mycompany.com names ! interface GigabitEthernet0/0 nameif outside security-level 0 ip address 206.x.x.232 255.255.255.224 standby 206.169.98.233 ! interface GigabitEthernet0/1 nameif inside security-level 100 ip address 10.18.14.6 255.255.255.0 standby 10.18.14.7 ! interface GigabitEthernet0/2 shutdown no nameif no security-level no ip address ! interface GigabitEthernet0/3 description LAN/STATE Failover Interface ! interface Management0/0 nameif management security-level 100 ip address 192.168.1.1 255.255.255.0 management-only ! ftp mode passive dns server-group DefaultDNS domain-name mycompany.com object-group network mycompany-domain-controllers network-object host 10.18.1.14 network-object host 10.18.1.15 access-list FWBlockIn extended permit tcp any any eq 990 access-list FWBlockIn extended deny ip any any access-list FWAllowAnyOut extended permit ip any any access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 192.168.122.0 255.255.255.192 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 157.254.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip host 216.27.189.196 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.0.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.1.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.2.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.3.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.4.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.5.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.6.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.7.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.8.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.9.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.10.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.15.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 192.168.255.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.11.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.12.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.13.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.16.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.192.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.224.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.225.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.226.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.227.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.228.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.229.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.230.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 192.168.122.0 255.255.255.192 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 157.254.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip host 216.27.189.196 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.0.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.1.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.2.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.3.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.4.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.5.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.6.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.7.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.8.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.9.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.10.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.15.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 192.168.255.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.11.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.12.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.13.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.16.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.192.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.224.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.225.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.226.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.227.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.228.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.229.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.230.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list vprn-qa extended permit ip 10.18.14.0 255.255.255.0 10.18.8.0 255.255.255.0 access-list test-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.128 255.255.255.240 access-list test-vpn extended permit ip 10.18.1.0 255.255.255.0 10.18.15.128 255.255.255.240 access-list test-vpn extended permit ip 10.18.3.0 255.255.255.0 10.18.15.128 255.255.255.240 access-list test-vpn extended permit ip 10.18.5.0 255.255.255.0 10.18.15.128 255.255.255.240 mtu outside 1500 mtu inside 1500 mtu management 1500 ip local pool VPRN-team-vpn-pool1 10.18.14.96-10.18.14.127 mask 255.255.255.0 ip local pool VPRN-team-vpn-pool2 10.18.14.160-10.18.14.191 mask 255.255.255.0 ip local pool vprn-is-pool 10.18.14.20-10.18.14.31 mask 255.255.255.0 ip local pool vprn-qa-pool 10.18.14.64-10.18.14.71 mask 255.255.255.0 ip local pool vprn-eng-pool 10.18.14.32-10.18.14.47 mask 255.255.255.0 ip local pool QAAugmentum-pool 10.18.14.248-10.18.14.254 mask 255.255.255.0 icmp unreachable rate-limit 1 burst-size 1 asdm image disk0:/asdm-507.bin no asdm history enable arp timeout 14400 global (outside) 1 206.169.98.234 nat (inside) 0 access-list nonat nat (inside) 1 0.0.0.0 0.0.0.0 route outside 0.0.0.0 0.0.0.0 206.169.98.225 1 route inside 10.1.192.0 255.255.255.0 10.18.14.1 1 route inside 10.18.16.0 255.255.255.0 10.18.14.1 1 route inside 10.18.13.0 255.255.255.0 10.18.14.1 1 route inside 10.18.12.0 255.255.255.0 10.18.14.1 1 route inside 10.18.11.0 255.255.255.0 10.18.14.1 1 route inside 172.30.0.0 255.255.0.0 10.18.14.1 1 route inside 192.168.255.0 255.255.255.0 10.18.14.1 1 route inside 10.32.0.0 255.240.0.0 10.18.14.1 1 route inside 157.254.0.0 255.255.0.0 10.18.14.1 1 route inside 192.168.122.0 255.255.255.192 10.18.14.1 1 route inside 141.11.0.0 255.255.0.0 10.18.14.1 1 route inside 10.18.10.0 255.255.255.0 10.18.14.1 1 route inside 10.18.9.0 255.255.255.0 10.18.14.1 1 route inside 10.18.8.0 255.255.255.0 10.18.14.1 1 route inside 10.18.7.0 255.255.255.0 10.18.14.1 1 route inside 10.18.6.0 255.255.255.0 10.18.14.1 1 route inside 10.18.5.0 255.255.255.0 10.18.14.1 1 route inside 10.18.4.0 255.255.255.0 10.18.14.1 1 route inside 10.18.3.0 255.255.255.0 10.18.14.1 1 route inside 10.18.2.0 255.255.255.0 10.18.14.1 1 route inside 10.18.1.0 255.255.255.0 10.18.14.1 1 route inside 10.18.0.0 255.255.255.0 10.18.14.1 1 route inside 10.66.0.0 255.255.0.0 10.18.14.1 1 route inside 10.11.0.0 255.255.0.0 10.18.14.1 1 route inside 10.64.0.0 255.255.0.0 10.18.14.1 1 route inside 10.1.0.0 255.255.0.0 10.18.14.1 1 route inside 10.15.0.0 255.255.0.0 10.18.14.1 1 aaa-server my_authent_grp protocol nt aaa-server my_authent_grp (inside) host 10.18.1.14 nt-auth-domain-controller dc04 aaa-server my_authent_grp (inside) host 10.18.1.15 nt-auth-domain-controller dc05 aaa authentication ssh console LOCAL aaa authentication enable console LOCAL service resetoutside crypto ipsec transform-set ny-trans esp-aes-192 esp-md5-hmac crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac crypto ipsec transform-set vpn-transform4 esp-aes esp-sha-hmac crypto ipsec security-association lifetime seconds 28800 crypto ipsec security-association lifetime kilobytes 4608000 crypto dynamic-map dynmap 10 set pfs crypto dynamic-map dynmap 10 set transform-set vpn-transform1 vpn-transform2 vpn-transform3 crypto dynamic-map dynmap 10 set reverse-route crypto map vpn-ra-map 10 match address ny-vpn-acl crypto map vpn-ra-map 10 set peer ny-fw-outside crypto map vpn-ra-map 10 set transform-set vpn-transform2 vpn-transform1 vpn-transform3 vpn-transform4 crypto map vpn-ra-map 10 set reverse-route crypto map vpn-ra-map 20 match address test-vpn crypto map vpn-ra-map 20 set peer 75.x.x.28 crypto map vpn-ra-map 20 set transform-set vpn-transform2 vpn-transform1 vpn-transform3 vpn-transform4 crypto map vpn-ra-map 20 set reverse-route crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap crypto map vpn-ra-map interface outside crypto isakmp enable outside crypto isakmp policy 5 authentication pre-share encryption aes-256 hash sha group 5 lifetime 3600 crypto isakmp policy 10 authentication pre-share encryption aes-256 hash sha group 2 lifetime 3600 crypto isakmp policy 20 authentication pre-share encryption 3des hash sha group 2 lifetime 3600 crypto isakmp policy 30 authentication pre-share encryption aes-192 hash md5 group 2 lifetime 28800 crypto isakmp policy 40 authentication pre-share encryption aes hash sha group 2 lifetime 28800 crypto isakmp policy 50 authentication pre-share encryption aes-256 hash sha group 2 lifetime 28800 crypto isakmp nat-traversal 20 crypto isakmp reload-wait client-update enable group-policy 75.x.x.28 internal group-policy 75.x.x.28 attributes vpn-tunnel-protocol IPSec l2tp-ipsec ip-comp enable ipsec-udp enable ipsec-udp-port 10000 tunnel-group 75.x.x.28 type ipsec-l2l tunnel-group 75.x.x.28 general-attributes default-group-policy 75.x.x.28 tunnel-group 75.x.x.28 ipsec-attributes pre-shared-key * peer-id-validate nocheck ! I tried to remove all the other non related bits. Thanks Scott  ----- Original Message ----- From: "Ryan West" To: "Scott Granados" ; Sent: Saturday, October 17, 2009 5:36 PM Subject: RE: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel Scott, Can you post your 'show ipsec sa' and 'show isakmp sa' output on both firewall, as well as 'show nat' and the associated nat 0 entries? Also please post the contents of the 4 transforms on the ASA as well as the transforms on the PIX. -ryan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados Sent: Saturday, October 17, 2009 8:23 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel Hi, I'm having the following problem. I have an ASA5520 running ASA724-33-k8 and a Pix 501 running 6.3. I have the following on the asa access-list test-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.128 255.255.255.240 access-list test-vpn extended permit ip 10.18.1.0 255.255.255.0 10.18.15.128 255.255.255.240 crypto map vpn-ra-map 20 match test-vpn crypto map vpn-ra-map 20 peer 75.x.x.28 crypto map vpn-ra-map 20 transform vpn-transform1 vpn-transform2 vpn-transform3 vpn-transform4 crypto map vpn-ra-map 20 reverse-route the transforms are simply aes and aes-256 des and 3des each with an md5 or sha hash isakmp policies exist and match as well on the pix access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.0.0 255.255.255.0 access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.1.0 255.255.255.0 crypto map map1 match test-vpn crypto map map1 interface outside crypto map map1 peer 206.x.x.232 isakmp policy 20 preshare isakmp policy 20 group 2 isakmp policy 20 encrypt aes-256 isakmp policy 20 hash sha isakmp policy 20 life 28800 A show isakmp sa and show crypto ipsec on both sides seems to show a tunnel up. With a debug crypto isakmp and debug crypto ipsec on the pix 501 I keep getting IKMP_NO_ERR_NO_TRANS The 5520 side shows a tunnel active and the pix a tunnel idle. Pings or traffic of any form can't traverse the tunnel. What have I missed? Any pointers would be appreciated. Thanks Scott _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From sethm at rollernet.us Mon Oct 19 00:06:47 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 18 Oct 2009 21:06:47 -0700 Subject: [c-nsp] OSPF-4-FLOOD_WAR Message-ID: <4ADBE5D7.8050908@rollernet.us> I'm getting this error message: 000050: Oct 19 04:00:17.546: %OSPF-4-FLOOD_WAR: Process 9000 flushes LSA ID 208.79.242.161 type-2 adv-rtr 208.79.242.139 in area 0 But I can't for the life of me figure it out because all of my routers have the OSPF router-id configured manually. What should I look for other than duplicate router-id? ~Seth From jason.koh at webvisions.com Sun Oct 18 22:34:43 2009 From: jason.koh at webvisions.com (Jason Koh) Date: Mon, 19 Oct 2009 10:34:43 +0800 Subject: [c-nsp] Sup720-3BXL reboots periodically References: Message-ID: <6AEEE85747ED41CDA6E5CA2340C0C683@corporate.webvisions.com> Hi all. Recently 1 of my Cat6506 reboots with this message. Uptime for this control processor is 6 days, 18 hours, 0 minutes Time since switched to active is 6 days, 17 hours, 59 minutes System returned to ROM by software NMI at PC 0x0, address 0x0 at 04:22:40 SGT+8 Fri Nov 14 2008 (SP by software NMI at PC 0x4074D708, address 0x0) System restarted at 16:29:23 SGT+8 Mon Oct 12 2009 System image file is "sup-bootdisk:s72033-adventerprisek9_wan-mz.122-33.SXH3a.bin" I was wondering what kind of event can trigger Non-Masked Interrupts. I have another Cat6 which is running the same IOS and hardware configuration as this one, but it doesn't reboot. Hopefully someone can help to shed some light on this. Thanks From mtinka at globaltransit.net Mon Oct 19 01:16:11 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Mon, 19 Oct 2009 13:16:11 +0800 Subject: [c-nsp] Sup720-3BXL reboots periodically In-Reply-To: <6AEEE85747ED41CDA6E5CA2340C0C683@corporate.webvisions.com> References: <6AEEE85747ED41CDA6E5CA2340C0C683@corporate.webvisions.com> Message-ID: <200910191316.12564.mtinka@globaltransit.net> On Monday 19 October 2009 10:34:43 am Jason Koh wrote: > I was wondering what kind of event can trigger Non-Masked > Interrupts. I have another Cat6 which is running the same > IOS and hardware configuration as this one, but it > doesn't reboot. Hopefully someone can help to shed some > light on this. We had similar crashes due to 'watchdog timer nmi reset' on SRC. Issues initially pointed to bad software, then bad hardware, then bad software. It was later confirmed to be bad software, triggered by BFD, which, for the life of me, I hope has finally been fixed in SRC5. Coming back to your issue, it could be a software-related problem, but since another supervisor module is running fine, it could also be hardware-related. Note, though, that in our case, uncommanded reboots across the network were not synchronized. However, eventually, all affected routers (NPE-G1's) did reboot; it was only a matter of when, not if. At any rate, filing a case with TAC is probably your best recourse. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From oboehmer at cisco.com Mon Oct 19 02:28:59 2009 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Mon, 19 Oct 2009 08:28:59 +0200 Subject: [c-nsp] OSPF-4-FLOOD_WAR In-Reply-To: <4ADBE5D7.8050908@rollernet.us> References: <4ADBE5D7.8050908@rollernet.us> Message-ID: <6E4D2678AC543844917CA081C9D6B33F818F0A@XMB-AMS-103.cisco.com> > I'm getting this error message: > > 000050: Oct 19 04:00:17.546: %OSPF-4-FLOOD_WAR: Process 9000 flushes LSA > ID 208.79.242.161 type-2 adv-rtr 208.79.242.139 in area 0 > > But I can't for the life of me figure it out because all of my routers > have the OSPF router-id configured manually. What should I look for > other than duplicate router-id? duplicate interface IP 208.79.242.161 configured on more than one router? Multiple OSPF processes on one router interconnected somehow? oli From sethm at rollernet.us Mon Oct 19 02:36:09 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 18 Oct 2009 23:36:09 -0700 Subject: [c-nsp] OSPF-4-FLOOD_WAR In-Reply-To: <6E4D2678AC543844917CA081C9D6B33F818F0A@XMB-AMS-103.cisco.com> References: <4ADBE5D7.8050908@rollernet.us> <6E4D2678AC543844917CA081C9D6B33F818F0A@XMB-AMS-103.cisco.com> Message-ID: <4ADC08D9.6030206@rollernet.us> Oliver Boehmer (oboehmer) wrote: >> I'm getting this error message: >> >> 000050: Oct 19 04:00:17.546: %OSPF-4-FLOOD_WAR: Process 9000 flushes > LSA >> ID 208.79.242.161 type-2 adv-rtr 208.79.242.139 in area 0 >> >> But I can't for the life of me figure it out because all of my routers >> have the OSPF router-id configured manually. What should I look for >> other than duplicate router-id? > > duplicate interface IP 208.79.242.161 configured on more than one > router? Multiple OSPF processes on one router interconnected somehow? > Yep, it was an interface on a different switch in "down" state that had the same IP. Odd though as there were other interfaces in the same state (I was migrating equipment) that didn't trigger the same problem. ~Seth From r.tahina at moov.mg Mon Oct 19 07:10:30 2009 From: r.tahina at moov.mg (RAZAFINDRATSIFA Rivo Tahina) Date: Mon, 19 Oct 2009 14:10:30 +0300 Subject: [c-nsp] ASN statistic tools In-Reply-To: References: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> Message-ID: <7.0.1.0.2.20091019140724.02019da8@moov.mg> Dear All, I installed this, what I have is just a graph of my upstream's ASN. I do note receive internet BGP routing table, it is filtered at my upstream. Do I need to have internet routing table? BR. At 10:12 14/10/2009, christian wrote: >take a look at: > >https://neon1.net/as-stats/as-stats-presentation-swinog16.pdf > >On Tue, Oct 13, 2009 at 10:52 PM, RAZAFINDRATSIFA Rivo Tahina > wrote: > > Daer All, > > > > I'm looking for utilities which allow to have ASN statistics, the netflow > > tools I tried doesn't do that, any idea? > > > > BR > > _______________________________________________ > > cisco-nsp mailing list cisco-nsp at puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > From nick at inex.ie Mon Oct 19 07:42:10 2009 From: nick at inex.ie (Nick Hilliard) Date: Mon, 19 Oct 2009 12:42:10 +0100 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <200910060541.19686.mtinka@globaltransit.net> References: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net> <4ACA0B77.5090106@inex.ie> <200910060541.19686.mtinka@globaltransit.net> Message-ID: <4ADC5092.7040905@inex.ie> On 05/10/2009 22:41, Mark Tinka wrote: > That said, it's also clear the 6500 isn't done yet, and it's > still got a number of tricks up its sleeve. The question is, > "Will you wait?". The c6500 is just a chassis. So, if you're referring to the trick of upgrading both the line cards and the supervisor engine to something better, then yes, it's got more tricks up its sleeve. As a side issue, there are electrical limitations imposed by the physical cross-bar unit inside the actual chassis, but I don't know how much of a problem these limitations are in practice. Perhaps the problem of getting reliable 20G+ parallel data transfers across the backplane is greater than dealing with the bandwidth limitations imposed by the electrical characteristics of the physical crossbar. Being hardware-related, this sort of stuff is well beyond my sphere of knowledge, and for all I know, c65k's operate using hoards of maxwell's daemons being slave-driven by microscopic evil pixies. Nick From eric at atlantech.net Mon Oct 19 08:53:52 2009 From: eric at atlantech.net (Eric Van Tol) Date: Mon, 19 Oct 2009 08:53:52 -0400 Subject: [c-nsp] 4-byte ASN Support - ME3400 Message-ID: <2C05E949E19A9146AF7BDF9D44085B863B3E882164@exchange.aoihq.local> Anyone know if 4-byte ASN support is available on ME3400? If not, anyone have any idea if/when it will be available? The AS23456 workaround doesn't seem particularly scalable. Thanks, evt From rwest at zyedge.com Mon Oct 19 08:54:54 2009 From: rwest at zyedge.com (Ryan West) Date: Mon, 19 Oct 2009 08:54:54 -0400 Subject: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel In-Reply-To: <00c301ca5059$87736ac0$830f120a@am.thmulti.com> References: <003e01ca4f89$15e3b980$830f120a@am.thmulti.com> <6E21B2BDEF6E714EA0B5BA8D5D0E140124DFAF3F29@zy-ex1.zyedge.local> <00c301ca5059$87736ac0$830f120a@am.thmulti.com> Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124DFAF3F41@zy-ex1.zyedge.local> Scott, Try this out, wax these sections and then do a packet-tracer: tunnel-group 75.x.x.28 general-attributes no default-group-policy 75.x.x.28 Clear configure group-policy 75.x.x.28 packet-tracer input inside icmp 10.18.1.14 8 0 10.18.15.130 detailed It doesn't matter if those addresses do not exist, it's the output that's important. You may need to run the command twice, but you want output similar to this: Phase: 10 Type: VPN Subtype: encrypt Result: ALLOW Config: Additional Information: Forward Flow based lookup yields rule: out id=0xd7e757a0, priority=70, domain=encrypt, deny=false hits=24687, user_data=0x143ac44c, cs_id=0xd6efc0a8, reverse, flags=0x0, protocol=0 src ip=10.2.3.0, mask=255.255.255.0, port=0 dst ip=10.2.4.0, mask=255.255.255.0, port=0, dscp=0x0 I'm pretty sure the issue is on your ASA and not the PIX. Hope that helps. -ryan -----Original Message----- From: Scott Granados [mailto:gsgranados at comcast.net] Sent: Sunday, October 18, 2009 9:15 PM To: Ryan West; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel Hi, thanks for the help, here are the important bits. PIX 501 test-fw# show isakmp sa Total : 1 Embryonic : 0 dst src state pending created 75.x.x.28 206.x.x.232 QM_IDLE 0 0 test-fw# sh   show ipsec sa interface: outside Crypto map tag: map1, local addr. 75.x.x.28 local ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) remote ident (addr/mask/prot/port): (10.18.5.0/255.255.255.0/0/0) current_peer: 206.x.x.232:0 PERMIT, flags={origin_is_acl,} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 75.x.x.28, remote crypto endpt.: 206.x.x.232 path mtu 1500, ipsec overhead 0, media mtu 1500 current outbound spi: 0 inbound esp sas: inbound ah sas: <--- More ---> inbound pcp sas: outbound esp sas: outbound ah sas: outbound pcp sas: local ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) remote ident (addr/mask/prot/port): (10.18.3.0/255.255.255.0/0/0) current_peer: 206.x.x.232:0 PERMIT, flags={origin_is_acl,} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 <--- More ---> local crypto endpt.: 75.x.x.28, remote crypto endpt.: 206.x.x.232 path mtu 1500, ipsec overhead 0, media mtu 1500 current outbound spi: 0 inbound esp sas: inbound ah sas: inbound pcp sas: outbound esp sas: outbound ah sas: outbound pcp sas: local ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) <--- More ---> remote ident (addr/mask/prot/port): (10.18.1.0/255.255.255.0/0/0) current_peer: 206.x.x.232:500 PERMIT, flags={origin_is_acl,} #pkts encaps: 1748, #pkts encrypt: 1748, #pkts digest 1748 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 1, #recv errors 0 local crypto endpt.: 75.x.x.28, remote crypto endpt.: 206.x.x.232 path mtu 1500, ipsec overhead 72, media mtu 1500 current outbound spi: 7631b778 inbound esp sas: spi: 0x38a1f0f(59383567) transform: esp-aes-256 esp-sha-hmac , in use settings ={Tunnel, } slot: 0, conn id: 1, crypto map: map1 sa timing: remaining key lifetime (k/sec): (4608000/17772) IV size: 16 bytes replay detection support: Y inbound ah sas: <--- More ---> inbound pcp sas: outbound esp sas: spi: 0x7631b778(1982969720) transform: esp-aes-256 esp-sha-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2, crypto map: map1 sa timing: remaining key lifetime (k/sec): (4607836/17718) IV size: 16 bytes replay detection support: Y outbound ah sas: outbound pcp sas: local ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) remote ident (addr/mask/prot/port): (10.18.0.0/255.255.255.0/0/0) <--- More ---> current_peer: 206.x.x.232:0 PERMIT, flags={origin_is_acl,} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 75.x.x.28, remote crypto endpt.: 206.x.x.232 path mtu 1500, ipsec overhead 0, media mtu 1500 current outbound spi: 0 inbound esp sas: inbound ah sas: inbound pcp sas: outbound esp sas: <--- More ---> outbound ah sas: outbound pcp sas: CONFIG test-fw# write t Building configuration... : Saved : PIX Version 6.3(5) interface ethernet0 auto interface ethernet1 100full nameif ethernet0 outside security0 nameif ethernet1 inside security100 hostname test-fw domain-name mycompany.com fixup protocol dns maximum-length 512 fixup protocol ftp 21 fixup protocol h323 h225 1720 fixup protocol h323 ras 1718-1719 fixup protocol http 80 fixup protocol rsh 514 fixup protocol rtsp 554 fixup protocol sip 5060 fixup protocol sip udp 5060 fixup protocol skinny 2000 fixup protocol smtp 25 fixup protocol sqlnet 1521 fixup protocol tftp 69 names access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.0.0 255.255.255.0 access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.1.0 255.255.255.0 access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.3.0 255.255.255.0 access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.5.0 255.255.255.0 access-list inside permit ip any any access-list outside permit icmp any any access-list outside deny ip any any pager lines 24 icmp permit 10.18.15.128 255.255.255.240 inside mtu outside 1500 mtu inside 1500 ip address outside 75.x.x.28 255.255.255.248 ip address inside 10.18.15.129 255.255.255.240 ip audit info action alarm ip audit attack action alarm pdm history enable arp timeout 14400 global (outside) 1 75.x.x.26-75.x.x.27 netmask 255.255.255.248 global (outside) 1 75.x.x.29 netmask 255.255.255.248 nat (inside) 0 access-list test-vpn nat (inside) 1 0.0.0.0 0.0.0.0 0 0 access-group inside in interface inside route outside 0.0.0.0 0.0.0.0 75.147.137.30 1 timeout xlate 3:00:00 timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00 timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00 timeout sip-disconnect 0:02:00 sip-invite 0:03:00 timeout uauth 0:05:00 absolute aaa-server TACACS+ protocol tacacs+ aaa-server TACACS+ max-failed-attempts 3 aaa-server TACACS+ deadtime 10 aaa-server RADIUS protocol radius aaa-server RADIUS max-failed-attempts 3 aaa-server RADIUS deadtime 10 aaa-server LOCAL protocol local http server enable http 10.18.15.130 255.255.255.255 inside no snmp-server location no snmp-server contact snmp-server community public no snmp-server enable traps floodguard enable sysopt connection permit-ipsec crypto ipsec transform-set set1 esp-aes-256 esp-sha-hmac crypto map map1 10 ipsec-isakmp crypto map map1 10 match address test-vpn crypto map map1 10 set peer 206.x.x.232 crypto map map1 10 set transform-set set1 crypto map map1 interface outside isakmp enable outside isakmp key ******** address 206.x.x.232 netmask 255.255.255.255 isakmp nat-traversal 20 isakmp policy 20 authentication pre-share isakmp policy 20 encryption aes-256 isakmp policy 20 hash sha isakmp policy 20 group 2 isakmp policy 20 lifetime 3600 isakmp policy 30 authentication pre-share isakmp policy 30 encryption aes-256 isakmp policy 30 hash sha isakmp policy 30 group 2 isakmp policy 30 lifetime 28800 dhcpd address 10.18.15.131-10.18.15.136 inside dhcpd dns 208.67.222.222 208.67.220.220 dhcpd wins 10.18.1.14 10.18.1.15 dhcpd lease 9000 dhcpd ping_timeout 750 dhcpd auto_config outside dhcpd enable inside encrypted privilege 2 terminal width 80 [OK] test-fw#          (*NOTE* the dns servers listed are opendns public servers so releasing the IP has no risk) ASA 5520 side Active SA: 10 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey) Total IKE SA: 10 6 IKE Peer: 75.x.x.28 Type : L2L Role : initiator Rekey : no State : MM_ACTIVE vpn# show ipsec sa interface: outside Crypto map tag: dynmap, seq num: 10, local addr: 206.x.x.232 Crypto map tag: vpn-ra-map, seq num: 20, local addr: 206.x.x.232 access-list test-vpn permit ip 10.18.0.0 255.255.255.0 10.18.15.128 255.255.255.240 local ident (addr/mask/prot/port): (10.18.0.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) current_peer: 75.x.x.28 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 206.x.x.232, remote crypto endpt.: 75.x.x.28 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: A4D9786C inbound esp sas: spi: 0x6F906AE6 (1871735526) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4373999/27751) IV size: 16 bytes replay detection support: Y outbound esp sas: spi: 0xA4D9786C (2765715564) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4374000/27751) IV size: 16 bytes replay detection support: Y Crypto map tag: vpn-ra-map, seq num: 20, local addr: 206.x.x.232 access-list test-vpn permit ip 10.18.1.0 255.255.255.0 10.18.15.128 255.255.255.240 local ident (addr/mask/prot/port): (10.18.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) current_peer: 75.x.x.28 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 1942, #pkts decrypt: 1942, #pkts verify: 1942 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 206.x.x.232, remote crypto endpt.: 75.x.x.28 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: 038A1F0F inbound esp sas: spi: 0x7631B778 (1982969720) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4373819/16564) IV size: 16 bytes replay detection support: Y outbound esp sas: spi: 0x038A1F0F (59383567) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4374000/16564) IV size: 16 bytes replay detection support: Y Crypto map tag: vpn-ra-map, seq num: 20, local addr: 206.x.x.232 access-list test-vpn permit ip 10.18.3.0 255.255.255.0 10.18.15.128 255.255.255.240 local ident (addr/mask/prot/port): (10.18.3.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) current_peer: 75.x.x.28 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 206.x.x.232, remote crypto endpt.: 75.x.x.28 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: B6096032 inbound esp sas: spi: 0x62DA2363 (1658463075) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4373999/27783) IV size: 16 bytes replay detection support: Y outbound esp sas: spi: 0xB6096032 (3054067762) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4374000/27783) IV size: 16 bytes replay detection support: Y Crypto map tag: vpn-ra-map, seq num: 20, local addr: 206.x.x.232 access-list test-vpn permit ip 10.18.5.0 255.255.255.0 10.18.15.128 255.255.255.240 local ident (addr/mask/prot/port): (10.18.5.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) current_peer: 75.x.x.28 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 206.x.x.232, remote crypto endpt.: 75.x.x.28 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: 75F7C1A5 inbound esp sas: spi: 0x01E9D9E2 (32102882) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4373999/27791) IV size: 16 bytes replay detection support: Y outbound esp sas: spi: 0x75F7C1A5 (1979171237) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4374000/27791) IV size: 16 bytes replay detection support: Y vpn# write t : Saved : ASA Version 7.2(4)33 ! hostname vpn domain-name mycompany.com names ! interface GigabitEthernet0/0 nameif outside security-level 0 ip address 206.x.x.232 255.255.255.224 standby 206.169.98.233 ! interface GigabitEthernet0/1 nameif inside security-level 100 ip address 10.18.14.6 255.255.255.0 standby 10.18.14.7 ! interface GigabitEthernet0/2 shutdown no nameif no security-level no ip address ! interface GigabitEthernet0/3 description LAN/STATE Failover Interface ! interface Management0/0 nameif management security-level 100 ip address 192.168.1.1 255.255.255.0 management-only ! ftp mode passive dns server-group DefaultDNS domain-name mycompany.com object-group network mycompany-domain-controllers network-object host 10.18.1.14 network-object host 10.18.1.15 access-list FWBlockIn extended permit tcp any any eq 990 access-list FWBlockIn extended deny ip any any access-list FWAllowAnyOut extended permit ip any any access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 192.168.122.0 255.255.255.192 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 157.254.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip host 216.27.189.196 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.0.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.1.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.2.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.3.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.4.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.5.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.6.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.7.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.8.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.9.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.10.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.15.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 192.168.255.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.11.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.12.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.13.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.16.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.192.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.224.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.225.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.226.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.227.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.228.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.229.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.230.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 192.168.122.0 255.255.255.192 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 157.254.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip host 216.27.189.196 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.0.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.1.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.2.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.3.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.4.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.5.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.6.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.7.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.8.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.9.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.10.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.15.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 192.168.255.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.11.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.12.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.13.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.16.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.192.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.224.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.225.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.226.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.227.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.228.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.229.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.230.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list vprn-qa extended permit ip 10.18.14.0 255.255.255.0 10.18.8.0 255.255.255.0 access-list test-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.128 255.255.255.240 access-list test-vpn extended permit ip 10.18.1.0 255.255.255.0 10.18.15.128 255.255.255.240 access-list test-vpn extended permit ip 10.18.3.0 255.255.255.0 10.18.15.128 255.255.255.240 access-list test-vpn extended permit ip 10.18.5.0 255.255.255.0 10.18.15.128 255.255.255.240 mtu outside 1500 mtu inside 1500 mtu management 1500 ip local pool VPRN-team-vpn-pool1 10.18.14.96-10.18.14.127 mask 255.255.255.0 ip local pool VPRN-team-vpn-pool2 10.18.14.160-10.18.14.191 mask 255.255.255.0 ip local pool vprn-is-pool 10.18.14.20-10.18.14.31 mask 255.255.255.0 ip local pool vprn-qa-pool 10.18.14.64-10.18.14.71 mask 255.255.255.0 ip local pool vprn-eng-pool 10.18.14.32-10.18.14.47 mask 255.255.255.0 ip local pool QAAugmentum-pool 10.18.14.248-10.18.14.254 mask 255.255.255.0 icmp unreachable rate-limit 1 burst-size 1 asdm image disk0:/asdm-507.bin no asdm history enable arp timeout 14400 global (outside) 1 206.169.98.234 nat (inside) 0 access-list nonat nat (inside) 1 0.0.0.0 0.0.0.0 route outside 0.0.0.0 0.0.0.0 206.169.98.225 1 route inside 10.1.192.0 255.255.255.0 10.18.14.1 1 route inside 10.18.16.0 255.255.255.0 10.18.14.1 1 route inside 10.18.13.0 255.255.255.0 10.18.14.1 1 route inside 10.18.12.0 255.255.255.0 10.18.14.1 1 route inside 10.18.11.0 255.255.255.0 10.18.14.1 1 route inside 172.30.0.0 255.255.0.0 10.18.14.1 1 route inside 192.168.255.0 255.255.255.0 10.18.14.1 1 route inside 10.32.0.0 255.240.0.0 10.18.14.1 1 route inside 157.254.0.0 255.255.0.0 10.18.14.1 1 route inside 192.168.122.0 255.255.255.192 10.18.14.1 1 route inside 141.11.0.0 255.255.0.0 10.18.14.1 1 route inside 10.18.10.0 255.255.255.0 10.18.14.1 1 route inside 10.18.9.0 255.255.255.0 10.18.14.1 1 route inside 10.18.8.0 255.255.255.0 10.18.14.1 1 route inside 10.18.7.0 255.255.255.0 10.18.14.1 1 route inside 10.18.6.0 255.255.255.0 10.18.14.1 1 route inside 10.18.5.0 255.255.255.0 10.18.14.1 1 route inside 10.18.4.0 255.255.255.0 10.18.14.1 1 route inside 10.18.3.0 255.255.255.0 10.18.14.1 1 route inside 10.18.2.0 255.255.255.0 10.18.14.1 1 route inside 10.18.1.0 255.255.255.0 10.18.14.1 1 route inside 10.18.0.0 255.255.255.0 10.18.14.1 1 route inside 10.66.0.0 255.255.0.0 10.18.14.1 1 route inside 10.11.0.0 255.255.0.0 10.18.14.1 1 route inside 10.64.0.0 255.255.0.0 10.18.14.1 1 route inside 10.1.0.0 255.255.0.0 10.18.14.1 1 route inside 10.15.0.0 255.255.0.0 10.18.14.1 1 aaa-server my_authent_grp protocol nt aaa-server my_authent_grp (inside) host 10.18.1.14 nt-auth-domain-controller dc04 aaa-server my_authent_grp (inside) host 10.18.1.15 nt-auth-domain-controller dc05 aaa authentication ssh console LOCAL aaa authentication enable console LOCAL service resetoutside crypto ipsec transform-set ny-trans esp-aes-192 esp-md5-hmac crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac crypto ipsec transform-set vpn-transform4 esp-aes esp-sha-hmac crypto ipsec security-association lifetime seconds 28800 crypto ipsec security-association lifetime kilobytes 4608000 crypto dynamic-map dynmap 10 set pfs crypto dynamic-map dynmap 10 set transform-set vpn-transform1 vpn-transform2 vpn-transform3 crypto dynamic-map dynmap 10 set reverse-route crypto map vpn-ra-map 10 match address ny-vpn-acl crypto map vpn-ra-map 10 set peer ny-fw-outside crypto map vpn-ra-map 10 set transform-set vpn-transform2 vpn-transform1 vpn-transform3 vpn-transform4 crypto map vpn-ra-map 10 set reverse-route crypto map vpn-ra-map 20 match address test-vpn crypto map vpn-ra-map 20 set peer 75.x.x.28 crypto map vpn-ra-map 20 set transform-set vpn-transform2 vpn-transform1 vpn-transform3 vpn-transform4 crypto map vpn-ra-map 20 set reverse-route crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap crypto map vpn-ra-map interface outside crypto isakmp enable outside crypto isakmp policy 5 authentication pre-share encryption aes-256 hash sha group 5 lifetime 3600 crypto isakmp policy 10 authentication pre-share encryption aes-256 hash sha group 2 lifetime 3600 crypto isakmp policy 20 authentication pre-share encryption 3des hash sha group 2 lifetime 3600 crypto isakmp policy 30 authentication pre-share encryption aes-192 hash md5 group 2 lifetime 28800 crypto isakmp policy 40 authentication pre-share encryption aes hash sha group 2 lifetime 28800 crypto isakmp policy 50 authentication pre-share encryption aes-256 hash sha group 2 lifetime 28800 crypto isakmp nat-traversal 20 crypto isakmp reload-wait client-update enable group-policy 75.x.x.28 internal group-policy 75.x.x.28 attributes vpn-tunnel-protocol IPSec l2tp-ipsec ip-comp enable ipsec-udp enable ipsec-udp-port 10000 tunnel-group 75.x.x.28 type ipsec-l2l tunnel-group 75.x.x.28 general-attributes default-group-policy 75.x.x.28 tunnel-group 75.x.x.28 ipsec-attributes pre-shared-key * peer-id-validate nocheck ! I tried to remove all the other non related bits. Thanks Scott  ----- Original Message ----- From: "Ryan West" To: "Scott Granados" ; Sent: Saturday, October 17, 2009 5:36 PM Subject: RE: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel Scott, Can you post your 'show ipsec sa' and 'show isakmp sa' output on both firewall, as well as 'show nat' and the associated nat 0 entries? Also please post the contents of the 4 transforms on the ASA as well as the transforms on the PIX. -ryan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados Sent: Saturday, October 17, 2009 8:23 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel Hi, I'm having the following problem. I have an ASA5520 running ASA724-33-k8 and a Pix 501 running 6.3. I have the following on the asa access-list test-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.128 255.255.255.240 access-list test-vpn extended permit ip 10.18.1.0 255.255.255.0 10.18.15.128 255.255.255.240 crypto map vpn-ra-map 20 match test-vpn crypto map vpn-ra-map 20 peer 75.x.x.28 crypto map vpn-ra-map 20 transform vpn-transform1 vpn-transform2 vpn-transform3 vpn-transform4 crypto map vpn-ra-map 20 reverse-route the transforms are simply aes and aes-256 des and 3des each with an md5 or sha hash isakmp policies exist and match as well on the pix access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.0.0 255.255.255.0 access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.1.0 255.255.255.0 crypto map map1 match test-vpn crypto map map1 interface outside crypto map map1 peer 206.x.x.232 isakmp policy 20 preshare isakmp policy 20 group 2 isakmp policy 20 encrypt aes-256 isakmp policy 20 hash sha isakmp policy 20 life 28800 A show isakmp sa and show crypto ipsec on both sides seems to show a tunnel up. With a debug crypto isakmp and debug crypto ipsec on the pix 501 I keep getting IKMP_NO_ERR_NO_TRANS The 5520 side shows a tunnel active and the pix a tunnel idle. Pings or traffic of any form can't traverse the tunnel. What have I missed? Any pointers would be appreciated. Thanks Scott _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From mtinka at globaltransit.net Mon Oct 19 09:09:34 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Mon, 19 Oct 2009 21:09:34 +0800 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <4ADC5092.7040905@inex.ie> References: <200910060541.19686.mtinka@globaltransit.net> <4ADC5092.7040905@inex.ie> Message-ID: <200910192109.41961.mtinka@globaltransit.net> On Monday 19 October 2009 07:42:10 pm Nick Hilliard wrote: > The c6500 is just a chassis. So, if you're referring to > the trick of upgrading both the line cards and the > supervisor engine to something better, then yes, it's got > more tricks up its sleeve. Of course, that's what I meant :-). I'd think it's implied that a chassis without any useful line cards is just a rock taking up space :-). My reference was more in terms of the platform than just a series of chassis'. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From gsgranados at comcast.net Mon Oct 19 10:05:00 2009 From: gsgranados at comcast.net (Scott Granados) Date: Mon, 19 Oct 2009 07:05:00 -0700 Subject: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel References: <003e01ca4f89$15e3b980$830f120a@am.thmulti.com> <6E21B2BDEF6E714EA0B5BA8D5D0E140124DFAF3F29@zy-ex1.zyedge.local> <00c301ca5059$87736ac0$830f120a@am.thmulti.com> <6E21B2BDEF6E714EA0B5BA8D5D0E140124DFAF3F41@zy-ex1.zyedge.local> Message-ID: <006b01ca50c5$32f9ede0$7ad6cc63@am.thmulti.com> Hi Ryan, I'll give that a run. I ran with out the policy entry at first though. Will give it a shot and post the output, thanks! ----- Original Message ----- From: "Ryan West" To: "Scott Granados" ; Sent: Monday, October 19, 2009 5:54 AM Subject: RE: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel Scott, Try this out, wax these sections and then do a packet-tracer: tunnel-group 75.x.x.28 general-attributes no default-group-policy 75.x.x.28 Clear configure group-policy 75.x.x.28 packet-tracer input inside icmp 10.18.1.14 8 0 10.18.15.130 detailed It doesn't matter if those addresses do not exist, it's the output that's important. You may need to run the command twice, but you want output similar to this: Phase: 10 Type: VPN Subtype: encrypt Result: ALLOW Config: Additional Information: Forward Flow based lookup yields rule: out id=0xd7e757a0, priority=70, domain=encrypt, deny=false hits=24687, user_data=0x143ac44c, cs_id=0xd6efc0a8, reverse, flags=0x0, protocol=0 src ip=10.2.3.0, mask=255.255.255.0, port=0 dst ip=10.2.4.0, mask=255.255.255.0, port=0, dscp=0x0 I'm pretty sure the issue is on your ASA and not the PIX. Hope that helps. -ryan -----Original Message----- From: Scott Granados [mailto:gsgranados at comcast.net] Sent: Sunday, October 18, 2009 9:15 PM To: Ryan West; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel Hi, thanks for the help, here are the important bits. PIX 501 test-fw# show isakmp sa Total : 1 Embryonic : 0 dst src state pending created 75.x.x.28 206.x.x.232 QM_IDLE 0 0 test-fw# sh   show ipsec sa interface: outside Crypto map tag: map1, local addr. 75.x.x.28 local ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) remote ident (addr/mask/prot/port): (10.18.5.0/255.255.255.0/0/0) current_peer: 206.x.x.232:0 PERMIT, flags={origin_is_acl,} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 75.x.x.28, remote crypto endpt.: 206.x.x.232 path mtu 1500, ipsec overhead 0, media mtu 1500 current outbound spi: 0 inbound esp sas: inbound ah sas: <--- More ---> inbound pcp sas: outbound esp sas: outbound ah sas: outbound pcp sas: local ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) remote ident (addr/mask/prot/port): (10.18.3.0/255.255.255.0/0/0) current_peer: 206.x.x.232:0 PERMIT, flags={origin_is_acl,} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 <--- More ---> local crypto endpt.: 75.x.x.28, remote crypto endpt.: 206.x.x.232 path mtu 1500, ipsec overhead 0, media mtu 1500 current outbound spi: 0 inbound esp sas: inbound ah sas: inbound pcp sas: outbound esp sas: outbound ah sas: outbound pcp sas: local ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) <--- More ---> remote ident (addr/mask/prot/port): (10.18.1.0/255.255.255.0/0/0) current_peer: 206.x.x.232:500 PERMIT, flags={origin_is_acl,} #pkts encaps: 1748, #pkts encrypt: 1748, #pkts digest 1748 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 1, #recv errors 0 local crypto endpt.: 75.x.x.28, remote crypto endpt.: 206.x.x.232 path mtu 1500, ipsec overhead 72, media mtu 1500 current outbound spi: 7631b778 inbound esp sas: spi: 0x38a1f0f(59383567) transform: esp-aes-256 esp-sha-hmac , in use settings ={Tunnel, } slot: 0, conn id: 1, crypto map: map1 sa timing: remaining key lifetime (k/sec): (4608000/17772) IV size: 16 bytes replay detection support: Y inbound ah sas: <--- More ---> inbound pcp sas: outbound esp sas: spi: 0x7631b778(1982969720) transform: esp-aes-256 esp-sha-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2, crypto map: map1 sa timing: remaining key lifetime (k/sec): (4607836/17718) IV size: 16 bytes replay detection support: Y outbound ah sas: outbound pcp sas: local ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) remote ident (addr/mask/prot/port): (10.18.0.0/255.255.255.0/0/0) <--- More ---> current_peer: 206.x.x.232:0 PERMIT, flags={origin_is_acl,} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 75.x.x.28, remote crypto endpt.: 206.x.x.232 path mtu 1500, ipsec overhead 0, media mtu 1500 current outbound spi: 0 inbound esp sas: inbound ah sas: inbound pcp sas: outbound esp sas: <--- More ---> outbound ah sas: outbound pcp sas: CONFIG test-fw# write t Building configuration... : Saved : PIX Version 6.3(5) interface ethernet0 auto interface ethernet1 100full nameif ethernet0 outside security0 nameif ethernet1 inside security100 hostname test-fw domain-name mycompany.com fixup protocol dns maximum-length 512 fixup protocol ftp 21 fixup protocol h323 h225 1720 fixup protocol h323 ras 1718-1719 fixup protocol http 80 fixup protocol rsh 514 fixup protocol rtsp 554 fixup protocol sip 5060 fixup protocol sip udp 5060 fixup protocol skinny 2000 fixup protocol smtp 25 fixup protocol sqlnet 1521 fixup protocol tftp 69 names access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.0.0 255.255.255.0 access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.1.0 255.255.255.0 access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.3.0 255.255.255.0 access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.5.0 255.255.255.0 access-list inside permit ip any any access-list outside permit icmp any any access-list outside deny ip any any pager lines 24 icmp permit 10.18.15.128 255.255.255.240 inside mtu outside 1500 mtu inside 1500 ip address outside 75.x.x.28 255.255.255.248 ip address inside 10.18.15.129 255.255.255.240 ip audit info action alarm ip audit attack action alarm pdm history enable arp timeout 14400 global (outside) 1 75.x.x.26-75.x.x.27 netmask 255.255.255.248 global (outside) 1 75.x.x.29 netmask 255.255.255.248 nat (inside) 0 access-list test-vpn nat (inside) 1 0.0.0.0 0.0.0.0 0 0 access-group inside in interface inside route outside 0.0.0.0 0.0.0.0 75.147.137.30 1 timeout xlate 3:00:00 timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00 timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00 timeout sip-disconnect 0:02:00 sip-invite 0:03:00 timeout uauth 0:05:00 absolute aaa-server TACACS+ protocol tacacs+ aaa-server TACACS+ max-failed-attempts 3 aaa-server TACACS+ deadtime 10 aaa-server RADIUS protocol radius aaa-server RADIUS max-failed-attempts 3 aaa-server RADIUS deadtime 10 aaa-server LOCAL protocol local http server enable http 10.18.15.130 255.255.255.255 inside no snmp-server location no snmp-server contact snmp-server community public no snmp-server enable traps floodguard enable sysopt connection permit-ipsec crypto ipsec transform-set set1 esp-aes-256 esp-sha-hmac crypto map map1 10 ipsec-isakmp crypto map map1 10 match address test-vpn crypto map map1 10 set peer 206.x.x.232 crypto map map1 10 set transform-set set1 crypto map map1 interface outside isakmp enable outside isakmp key ******** address 206.x.x.232 netmask 255.255.255.255 isakmp nat-traversal 20 isakmp policy 20 authentication pre-share isakmp policy 20 encryption aes-256 isakmp policy 20 hash sha isakmp policy 20 group 2 isakmp policy 20 lifetime 3600 isakmp policy 30 authentication pre-share isakmp policy 30 encryption aes-256 isakmp policy 30 hash sha isakmp policy 30 group 2 isakmp policy 30 lifetime 28800 dhcpd address 10.18.15.131-10.18.15.136 inside dhcpd dns 208.67.222.222 208.67.220.220 dhcpd wins 10.18.1.14 10.18.1.15 dhcpd lease 9000 dhcpd ping_timeout 750 dhcpd auto_config outside dhcpd enable inside encrypted privilege 2 terminal width 80 [OK] test-fw#          (*NOTE* the dns servers listed are opendns public servers so releasing the IP has no risk) ASA 5520 side Active SA: 10 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey) Total IKE SA: 10 6 IKE Peer: 75.x.x.28 Type : L2L Role : initiator Rekey : no State : MM_ACTIVE vpn# show ipsec sa interface: outside Crypto map tag: dynmap, seq num: 10, local addr: 206.x.x.232 Crypto map tag: vpn-ra-map, seq num: 20, local addr: 206.x.x.232 access-list test-vpn permit ip 10.18.0.0 255.255.255.0 10.18.15.128 255.255.255.240 local ident (addr/mask/prot/port): (10.18.0.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) current_peer: 75.x.x.28 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 206.x.x.232, remote crypto endpt.: 75.x.x.28 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: A4D9786C inbound esp sas: spi: 0x6F906AE6 (1871735526) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4373999/27751) IV size: 16 bytes replay detection support: Y outbound esp sas: spi: 0xA4D9786C (2765715564) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4374000/27751) IV size: 16 bytes replay detection support: Y Crypto map tag: vpn-ra-map, seq num: 20, local addr: 206.x.x.232 access-list test-vpn permit ip 10.18.1.0 255.255.255.0 10.18.15.128 255.255.255.240 local ident (addr/mask/prot/port): (10.18.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) current_peer: 75.x.x.28 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 1942, #pkts decrypt: 1942, #pkts verify: 1942 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 206.x.x.232, remote crypto endpt.: 75.x.x.28 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: 038A1F0F inbound esp sas: spi: 0x7631B778 (1982969720) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4373819/16564) IV size: 16 bytes replay detection support: Y outbound esp sas: spi: 0x038A1F0F (59383567) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4374000/16564) IV size: 16 bytes replay detection support: Y Crypto map tag: vpn-ra-map, seq num: 20, local addr: 206.x.x.232 access-list test-vpn permit ip 10.18.3.0 255.255.255.0 10.18.15.128 255.255.255.240 local ident (addr/mask/prot/port): (10.18.3.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) current_peer: 75.x.x.28 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 206.x.x.232, remote crypto endpt.: 75.x.x.28 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: B6096032 inbound esp sas: spi: 0x62DA2363 (1658463075) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4373999/27783) IV size: 16 bytes replay detection support: Y outbound esp sas: spi: 0xB6096032 (3054067762) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4374000/27783) IV size: 16 bytes replay detection support: Y Crypto map tag: vpn-ra-map, seq num: 20, local addr: 206.x.x.232 access-list test-vpn permit ip 10.18.5.0 255.255.255.0 10.18.15.128 255.255.255.240 local ident (addr/mask/prot/port): (10.18.5.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.18.15.128/255.255.255.240/0/0) current_peer: 75.x.x.28 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #send errors: 0, #recv errors: 0 local crypto endpt.: 206.x.x.232, remote crypto endpt.: 75.x.x.28 path mtu 1500, ipsec overhead 74, media mtu 1500 current outbound spi: 75F7C1A5 inbound esp sas: spi: 0x01E9D9E2 (32102882) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4373999/27791) IV size: 16 bytes replay detection support: Y outbound esp sas: spi: 0x75F7C1A5 (1979171237) transform: esp-aes-256 esp-sha-hmac none in use settings ={L2L, Tunnel, } slot: 0, conn_id: 915, crypto-map: vpn-ra-map sa timing: remaining key lifetime (kB/sec): (4374000/27791) IV size: 16 bytes replay detection support: Y vpn# write t : Saved : ASA Version 7.2(4)33 ! hostname vpn domain-name mycompany.com names ! interface GigabitEthernet0/0 nameif outside security-level 0 ip address 206.x.x.232 255.255.255.224 standby 206.169.98.233 ! interface GigabitEthernet0/1 nameif inside security-level 100 ip address 10.18.14.6 255.255.255.0 standby 10.18.14.7 ! interface GigabitEthernet0/2 shutdown no nameif no security-level no ip address ! interface GigabitEthernet0/3 description LAN/STATE Failover Interface ! interface Management0/0 nameif management security-level 100 ip address 192.168.1.1 255.255.255.0 management-only ! ftp mode passive dns server-group DefaultDNS domain-name mycompany.com object-group network mycompany-domain-controllers network-object host 10.18.1.14 network-object host 10.18.1.15 access-list FWBlockIn extended permit tcp any any eq 990 access-list FWBlockIn extended deny ip any any access-list FWAllowAnyOut extended permit ip any any access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 192.168.122.0 255.255.255.192 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 157.254.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip host 216.27.189.196 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.0.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.1.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.2.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.3.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.4.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.5.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.6.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.7.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.8.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.9.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.10.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.15.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 192.168.255.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.11.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.12.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.13.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.16.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.192.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.224.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.225.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.226.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.227.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.228.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.229.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.230.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 192.168.122.0 255.255.255.192 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 157.254.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip host 216.27.189.196 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.0.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.1.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.2.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.3.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.4.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.5.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.6.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.7.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.8.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.9.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.10.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.15.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 192.168.255.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.11.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.12.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.13.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.16.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.192.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.224.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.225.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.226.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.227.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.228.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.229.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.1.230.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list vprn-qa extended permit ip 10.18.14.0 255.255.255.0 10.18.8.0 255.255.255.0 access-list test-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.128 255.255.255.240 access-list test-vpn extended permit ip 10.18.1.0 255.255.255.0 10.18.15.128 255.255.255.240 access-list test-vpn extended permit ip 10.18.3.0 255.255.255.0 10.18.15.128 255.255.255.240 access-list test-vpn extended permit ip 10.18.5.0 255.255.255.0 10.18.15.128 255.255.255.240 mtu outside 1500 mtu inside 1500 mtu management 1500 ip local pool VPRN-team-vpn-pool1 10.18.14.96-10.18.14.127 mask 255.255.255.0 ip local pool VPRN-team-vpn-pool2 10.18.14.160-10.18.14.191 mask 255.255.255.0 ip local pool vprn-is-pool 10.18.14.20-10.18.14.31 mask 255.255.255.0 ip local pool vprn-qa-pool 10.18.14.64-10.18.14.71 mask 255.255.255.0 ip local pool vprn-eng-pool 10.18.14.32-10.18.14.47 mask 255.255.255.0 ip local pool QAAugmentum-pool 10.18.14.248-10.18.14.254 mask 255.255.255.0 icmp unreachable rate-limit 1 burst-size 1 asdm image disk0:/asdm-507.bin no asdm history enable arp timeout 14400 global (outside) 1 206.169.98.234 nat (inside) 0 access-list nonat nat (inside) 1 0.0.0.0 0.0.0.0 route outside 0.0.0.0 0.0.0.0 206.169.98.225 1 route inside 10.1.192.0 255.255.255.0 10.18.14.1 1 route inside 10.18.16.0 255.255.255.0 10.18.14.1 1 route inside 10.18.13.0 255.255.255.0 10.18.14.1 1 route inside 10.18.12.0 255.255.255.0 10.18.14.1 1 route inside 10.18.11.0 255.255.255.0 10.18.14.1 1 route inside 172.30.0.0 255.255.0.0 10.18.14.1 1 route inside 192.168.255.0 255.255.255.0 10.18.14.1 1 route inside 10.32.0.0 255.240.0.0 10.18.14.1 1 route inside 157.254.0.0 255.255.0.0 10.18.14.1 1 route inside 192.168.122.0 255.255.255.192 10.18.14.1 1 route inside 141.11.0.0 255.255.0.0 10.18.14.1 1 route inside 10.18.10.0 255.255.255.0 10.18.14.1 1 route inside 10.18.9.0 255.255.255.0 10.18.14.1 1 route inside 10.18.8.0 255.255.255.0 10.18.14.1 1 route inside 10.18.7.0 255.255.255.0 10.18.14.1 1 route inside 10.18.6.0 255.255.255.0 10.18.14.1 1 route inside 10.18.5.0 255.255.255.0 10.18.14.1 1 route inside 10.18.4.0 255.255.255.0 10.18.14.1 1 route inside 10.18.3.0 255.255.255.0 10.18.14.1 1 route inside 10.18.2.0 255.255.255.0 10.18.14.1 1 route inside 10.18.1.0 255.255.255.0 10.18.14.1 1 route inside 10.18.0.0 255.255.255.0 10.18.14.1 1 route inside 10.66.0.0 255.255.0.0 10.18.14.1 1 route inside 10.11.0.0 255.255.0.0 10.18.14.1 1 route inside 10.64.0.0 255.255.0.0 10.18.14.1 1 route inside 10.1.0.0 255.255.0.0 10.18.14.1 1 route inside 10.15.0.0 255.255.0.0 10.18.14.1 1 aaa-server my_authent_grp protocol nt aaa-server my_authent_grp (inside) host 10.18.1.14 nt-auth-domain-controller dc04 aaa-server my_authent_grp (inside) host 10.18.1.15 nt-auth-domain-controller dc05 aaa authentication ssh console LOCAL aaa authentication enable console LOCAL service resetoutside crypto ipsec transform-set ny-trans esp-aes-192 esp-md5-hmac crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac crypto ipsec transform-set vpn-transform4 esp-aes esp-sha-hmac crypto ipsec security-association lifetime seconds 28800 crypto ipsec security-association lifetime kilobytes 4608000 crypto dynamic-map dynmap 10 set pfs crypto dynamic-map dynmap 10 set transform-set vpn-transform1 vpn-transform2 vpn-transform3 crypto dynamic-map dynmap 10 set reverse-route crypto map vpn-ra-map 10 match address ny-vpn-acl crypto map vpn-ra-map 10 set peer ny-fw-outside crypto map vpn-ra-map 10 set transform-set vpn-transform2 vpn-transform1 vpn-transform3 vpn-transform4 crypto map vpn-ra-map 10 set reverse-route crypto map vpn-ra-map 20 match address test-vpn crypto map vpn-ra-map 20 set peer 75.x.x.28 crypto map vpn-ra-map 20 set transform-set vpn-transform2 vpn-transform1 vpn-transform3 vpn-transform4 crypto map vpn-ra-map 20 set reverse-route crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap crypto map vpn-ra-map interface outside crypto isakmp enable outside crypto isakmp policy 5 authentication pre-share encryption aes-256 hash sha group 5 lifetime 3600 crypto isakmp policy 10 authentication pre-share encryption aes-256 hash sha group 2 lifetime 3600 crypto isakmp policy 20 authentication pre-share encryption 3des hash sha group 2 lifetime 3600 crypto isakmp policy 30 authentication pre-share encryption aes-192 hash md5 group 2 lifetime 28800 crypto isakmp policy 40 authentication pre-share encryption aes hash sha group 2 lifetime 28800 crypto isakmp policy 50 authentication pre-share encryption aes-256 hash sha group 2 lifetime 28800 crypto isakmp nat-traversal 20 crypto isakmp reload-wait client-update enable group-policy 75.x.x.28 internal group-policy 75.x.x.28 attributes vpn-tunnel-protocol IPSec l2tp-ipsec ip-comp enable ipsec-udp enable ipsec-udp-port 10000 tunnel-group 75.x.x.28 type ipsec-l2l tunnel-group 75.x.x.28 general-attributes default-group-policy 75.x.x.28 tunnel-group 75.x.x.28 ipsec-attributes pre-shared-key * peer-id-validate nocheck ! I tried to remove all the other non related bits. Thanks Scott  ----- Original Message ----- From: "Ryan West" To: "Scott Granados" ; Sent: Saturday, October 17, 2009 5:36 PM Subject: RE: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel Scott, Can you post your 'show ipsec sa' and 'show isakmp sa' output on both firewall, as well as 'show nat' and the associated nat 0 entries? Also please post the contents of the 4 transforms on the ASA as well as the transforms on the PIX. -ryan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados Sent: Saturday, October 17, 2009 8:23 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] ASA5520 > Pix 501, NO_ERR_NO_TRANS error on VPN tunnel Hi, I'm having the following problem. I have an ASA5520 running ASA724-33-k8 and a Pix 501 running 6.3. I have the following on the asa access-list test-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.128 255.255.255.240 access-list test-vpn extended permit ip 10.18.1.0 255.255.255.0 10.18.15.128 255.255.255.240 crypto map vpn-ra-map 20 match test-vpn crypto map vpn-ra-map 20 peer 75.x.x.28 crypto map vpn-ra-map 20 transform vpn-transform1 vpn-transform2 vpn-transform3 vpn-transform4 crypto map vpn-ra-map 20 reverse-route the transforms are simply aes and aes-256 des and 3des each with an md5 or sha hash isakmp policies exist and match as well on the pix access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.0.0 255.255.255.0 access-list test-vpn permit ip 10.18.15.128 255.255.255.240 10.18.1.0 255.255.255.0 crypto map map1 match test-vpn crypto map map1 interface outside crypto map map1 peer 206.x.x.232 isakmp policy 20 preshare isakmp policy 20 group 2 isakmp policy 20 encrypt aes-256 isakmp policy 20 hash sha isakmp policy 20 life 28800 A show isakmp sa and show crypto ipsec on both sides seems to show a tunnel up. With a debug crypto isakmp and debug crypto ipsec on the pix 501 I keep getting IKMP_NO_ERR_NO_TRANS The 5520 side shows a tunnel active and the pix a tunnel idle. Pings or traffic of any form can't traverse the tunnel. What have I missed? Any pointers would be appreciated. Thanks Scott _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From charlie at playlouder.com Mon Oct 19 11:10:12 2009 From: charlie at playlouder.com (Charlie Allom) Date: Mon, 19 Oct 2009 16:10:12 +0100 Subject: [c-nsp] ASN statistic tools In-Reply-To: <7.0.1.0.2.20091019140724.02019da8@moov.mg> References: <7.0.1.0.2.20091014085045.0222f2d0@moov.mg> <7.0.1.0.2.20091019140724.02019da8@moov.mg> Message-ID: <20091019151012.GK59231@eatyourpets.com> On Mon, Oct 19, 2009 at 02:10:30PM +0300, RAZAFINDRATSIFA Rivo Tahina wrote: > Dear All, > > I installed this, what I have is just a graph of my upstream's ASN. > I do note receive internet BGP routing table, it is filtered at my upstream. > Do I need to have internet routing table? Look into pmacct. cf. http://wiki.pmacct.net/OfficialExamples IX. Quickstart guide to setup a NetFlow agent/probe & networks_file: /path/to/networks.lst -- Media Service Provider Ltd. http://blog.playlouder.com/ http://as47998.net/ 020 7729 4797 From vuillaumes at gmail.com Mon Oct 19 11:26:27 2009 From: vuillaumes at gmail.com (samuel vuillaume) Date: Mon, 19 Oct 2009 11:26:27 -0400 Subject: [c-nsp] Basic RSTP question Message-ID: Hi guys, Just quick question pretty straight forward about RSTP. In a triangle topology as below A(f) ---------- (f)C | (b) B(f)_________| Let's say A is root and B backup root, port to B is block on C, and port to A is forwarding. When i shut down the root port, no problem, it converges in less than 1 sec. My question is when the port on C is un shut, so back up, the handshake starts between A and C ( i mean proposal and agreement), and after the handshake, on C port facing A should move from blocking to forwarding. In that case, does C send out a TC on this port and flush is MAC address table? tks Sam From kgraham at industrial-marshmallow.com Mon Oct 19 11:45:15 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Mon, 19 Oct 2009 08:45:15 -0700 (PDT) Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <4ADC5092.7040905@inex.ie> References: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net> <4ACA0B77.5090106@inex.ie> <200910060541.19686.mtinka@globaltransit.net> <4ADC5092.7040905@inex.ie> Message-ID: <828027.91138.qm@web508.biz.mail.mud.yahoo.com> > As a side issue, there are electrical limitations imposed by the physical > cross-bar unit inside the actual chassis, but I don't know how much of a problem > these limitations are in practice. 6500E was the key for this. Besides nutty amounts of POE capacity, it also picked up improved backplane for >20g+ fabric and extending to all 11 LC slots in the 6513. (Still need to dig up details, as faster SSO time is also tied to chassis, though I can't recall why). From kgraham at industrial-marshmallow.com Mon Oct 19 11:55:42 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Mon, 19 Oct 2009 08:55:42 -0700 (PDT) Subject: [c-nsp] RPR between 720-3B and 720-3BXL Message-ID: <197336.26914.qm@web503.biz.mail.mud.yahoo.com> I could have sworn this had been covered on the list before, but I can't find it in archives. We need to get a switch w/ Sup720-3B's upgraded to a Sup720-3BXL's. Though I'm sure its not supported, does anyone know if a (same generation but larger) PFC can come up as a standby? SSO seems too much to hope for, so presumably this would just be RPR. The only interest is in running this way for ~10m to sync up configs, etc to the first BXL before switching over to it and swapping out the other sup. From jeremyparr at gmail.com Mon Oct 19 13:20:54 2009 From: jeremyparr at gmail.com (Jeremy Parr) Date: Mon, 19 Oct 2009 13:20:54 -0400 Subject: [c-nsp] 1811 DOT11-3-POWERS_INVALID Message-ID: <91dee5fc0910191020k5b53372aqae9c02656563c665@mail.gmail.com> I have a number (over a dozen) Cisco 1811s that have given up their wireless adapters with the error: *Oct 19 13:13:55: %DOT11-3-POWERS_INVALID: Interface Dot11Radio0, no valid power levels available Sometimes this occurs after an IOS upgrade, and rolling back to the previous version will correct it. Cisco has claimed that each time it is a hardware failure, and happily RMAs the unit, but the problem will reoccur. This has been in the neighborhood of a 50% failure rate for us. Standalone APs and 871Ws seem to work just fine, with only the 1811Ws being problematic. The config can be barebones simple, I have tried hard coding antenna gains and power levels etc, but the interface still stays in a "reset" state. It seems that somehow the card or the router loses its country code, as I am able to configure channels well above 2.4ghz ISM (FCC): (config-if)#channel ? <1-2732> One of: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 65535 65535 65535 65535 65535 65535 65535 65535 65535 65535 65535 65535 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484 2512 2532 2552 2572 2592 2612 2632 2652 2672 2692 2712 2732 least-congested Scan for best frequency Carrier busy test: Frequency Carrier Busy % --------- -------------- 2412 100 2417 100 2422 100 2427 100 2432 100 2437 100 2442 100 2447 100 2452 100 2457 100 2462 100 2467 100 2472 100 2484 100 2512 100 2532 100 2552 100 2572 100 2592 100 2612 100 2632 100 2652 100 2672 100 2692 100 2712 100 2732 100 From drew.weaver at thenap.com Mon Oct 19 13:48:26 2009 From: drew.weaver at thenap.com (Drew Weaver) Date: Mon, 19 Oct 2009 13:48:26 -0400 Subject: [c-nsp] SIP-600/SIP-601 Message-ID: Quick question, anyone who recently purchased a SIP-600 wish they would've paid up for the 601? The reason I ask is that for the most part, we don't use any FastEthernet or OC-X in our routers, but I am trying to see if anyone has run into unexpected problems. I'm thinking that if we did need to run FastE or OC-x we could just use the standard line-cards but I'm wondering if there is a problem with that idea as well? Any thoughts? -Drew From cchurc05 at harris.com Mon Oct 19 14:12:11 2009 From: cchurc05 at harris.com (Church, Charles) Date: Mon, 19 Oct 2009 14:12:11 -0400 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <828027.91138.qm@web508.biz.mail.mud.yahoo.com> References: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net> <4ACA0B77.5090106@inex.ie> <200910060541.19686.mtinka@globaltransit.net> <4ADC5092.7040905@inex.ie> <828027.91138.qm@web508.biz.mail.mud.yahoo.com> Message-ID: <290EF89F13F04F4E924BB235A46D18F1043B2BA143@MLBMXUS2.cs.myharris.net> Are you saying a 6513-E chassis exists? I can't find any reference to it. That would solve a few of the problems we currently have (density issue) Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Kevin Graham Sent: Monday, October 19, 2009 11:45 AM To: Nick Hilliard; mtinka at globaltransit.net Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] DWDM optics on 6500s > As a side issue, there are electrical limitations imposed by the physical > cross-bar unit inside the actual chassis, but I don't know how much of a problem > these limitations are in practice. 6500E was the key for this. Besides nutty amounts of POE capacity, it also picked up improved backplane for >20g+ fabric and extending to all 11 LC slots in the 6513. (Still need to dig up details, as faster SSO time is also tied to chassis, though I can't recall why). _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From peter at rathlev.dk Mon Oct 19 15:40:49 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Mon, 19 Oct 2009 21:40:49 +0200 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <290EF89F13F04F4E924BB235A46D18F1043B2BA143@MLBMXUS2.cs.myharris.net> References: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net> <4ACA0B77.5090106@inex.ie> <200910060541.19686.mtinka@globaltransit.net> <4ADC5092.7040905@inex.ie> <828027.91138.qm@web508.biz.mail.mud.yahoo.com> <290EF89F13F04F4E924BB235A46D18F1043B2BA143@MLBMXUS2.cs.myharris.net> Message-ID: <1255981249.3370.5.camel@abehat.net.rm.dk> On Mon, 2009-10-19 at 14:12 -0400, Church, Charles wrote: > Are you saying a 6513-E chassis exists? I can't find any reference to > it. That would solve a few of the problems we currently have (density > issue) We've been told about it at a local tech update about the Catalyst platform about a month ago, but I also can't find any material about it. -- Peter From peter at rathlev.dk Mon Oct 19 15:48:52 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Mon, 19 Oct 2009 21:48:52 +0200 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <1255981249.3370.5.camel@abehat.net.rm.dk> References: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net> <4ACA0B77.5090106@inex.ie> <200910060541.19686.mtinka@globaltransit.net> <4ADC5092.7040905@inex.ie> <828027.91138.qm@web508.biz.mail.mud.yahoo.com> <290EF89F13F04F4E924BB235A46D18F1043B2BA143@MLBMXUS2.cs.myharris.net> <1255981249.3370.5.camel@abehat.net.rm.dk> Message-ID: <1255981732.3370.7.camel@abehat.net.rm.dk> On Mon, 2009-10-19 at 21:40 +0200, Peter Rathlev wrote: > On Mon, 2009-10-19 at 14:12 -0400, Church, Charles wrote: > > Are you saying a 6513-E chassis exists? I can't find any reference to > > it. That would solve a few of the problems we currently have (density > > issue) > > We've been told about it at a local tech update about the Catalyst > platform about a month ago, but I also can't find any material about it. Actually I found the presentation from the update: http://www.cisco.com/web/DK/assets/docs/presentations/4500-6500-tech-update-sept09.pdf Some of it is in danish, but most is english. The 6513E is mentioned on page 36, but only by name. We were told it was capable of 2 x 40 Gb/s in all slots. -- Peter From kgraham at industrial-marshmallow.com Mon Oct 19 15:51:24 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Mon, 19 Oct 2009 12:51:24 -0700 (PDT) Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <290EF89F13F04F4E924BB235A46D18F1043B2BA143@MLBMXUS2.cs.myharris.net> References: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net> <4ACA0B77.5090106@inex.ie> <200910060541.19686.mtinka@globaltransit.net> <4ADC5092.7040905@inex.ie> <828027.91138.qm@web508.biz.mail.mud.yahoo.com> <290EF89F13F04F4E924BB235A46D18F1043B2BA143@MLBMXUS2.cs.myharris.net> Message-ID: <766836.2808.qm@web501.biz.mail.mud.yahoo.com> > Are you saying a 6513-E chassis exists? I can't find any reference to it. Apparently not yet. (I had never paid attention to availability, as any places we might use it would depend on full fabric connectivity). Quick search turned up (the rather depressing): http://www.cisco.com/web/AP/partners/assets/docs/Day1_03a_Catalyst_Update.pdf ...it would appear the intention is to release the chassis with the new supervisor. (Obviously the timelines cited there are out of date, since that also cites an EARL8-based 720 in '09 and VTOR, which I'm guessing we'll never see on a 6k). Several of the used vendors have matches for "WS-C6513-E", so it may well be on the global price list. > That would solve a few of the problems we currently have (density issue) My understanding to date is that it won't do any good until the next-gen sup is out (as presumably there would be no other reason to hold back on an 11x2 fabric configuration). From tvarriale at comcast.net Mon Oct 19 17:06:56 2009 From: tvarriale at comcast.net (Tony Varriale) Date: Mon, 19 Oct 2009 16:06:56 -0500 Subject: [c-nsp] DWDM optics on 6500s References: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net><4ACA0B77.5090106@inex.ie> <200910060541.19686.mtinka@globaltransit.net><4ADC5092.7040905@inex.ie><828027.91138.qm@web508.biz.mail.mud.yahoo.com> <290EF89F13F04F4E924BB235A46D18F1043B2BA143@MLBMXUS2.cs.myharris.net> Message-ID: <64A2673D120E4B408424519469A78A6C@flamdt01> It will shortly but it won't do you any good with the existing family of sups. The 2T will be the first (and last?) sup that can push the bandwidth to all those slots. You can also reference the 6509-V-E...it's ready for 80gbps/slot. You can order that today. Note that it's a NEBS chassis. tv ----- Original Message ----- From: "Church, Charles" To: "Kevin Graham" Cc: Sent: Monday, October 19, 2009 1:12 PM Subject: Re: [c-nsp] DWDM optics on 6500s > Are you saying a 6513-E chassis exists? I can't find any reference to it. > That would solve a few of the problems we currently have (density issue) > > Chuck > > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Kevin Graham > Sent: Monday, October 19, 2009 11:45 AM > To: Nick Hilliard; mtinka at globaltransit.net > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] DWDM optics on 6500s > > >> As a side issue, there are electrical limitations imposed by the physical > >> cross-bar unit inside the actual chassis, but I don't know how much of a >> problem >> these limitations are in practice. > > 6500E was the key for this. Besides nutty amounts of POE capacity, it also > picked up > improved backplane for >20g+ fabric and extending to all 11 LC slots in > the 6513. > > (Still need to dig up details, as faster SSO time is also tied to chassis, > though > I can't recall why). > _______________________________________________ > cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From justin at justinshore.com Mon Oct 19 17:49:40 2009 From: justin at justinshore.com (Justin Shore) Date: Mon, 19 Oct 2009 16:49:40 -0500 Subject: [c-nsp] Inserting a default route into a MPLS/VPN pointing out of the VRF Message-ID: <4ADCDEF4.3060503@justinshore.com> I'm having to rush a MPLS/VPN into service this week. Certain customers will connect into this MPLS/VPN on PEs facing L2 switches with sub-ints in the correct VRF, MLPPP bundles, direct connect to PEs, etc (lots of variety down the road). Simple so far. The majority of the traffic will exit our network out another PE at a peering point across our network, exiting out another interface also assigned to the same VRF. Still simple. I'm doing similar things today to support our data center and some other L3VPNs. Easy stuff. The problem that I'm faced with is figuring out how to insert a default route into that MPLS/VPN. I do this today with the data center VRFs with the assistance of a FWSM in our core. I insert a default route pointed to the backside of the customer's context on the FWSM; that route is a static in the VRF. The FWSM bridges the gap between my MPLS/VPN and my default VRF quite nicely. However in this situation I can't use the FWSMs. I need to extract traffic from the VRF for the private network and out into the default VRF on my core where I keep my Internet routes. Longest-match will take care of the MPLS/VPN routes to properly route traffic to my peer. Everything else needs to get out of the VRF and to the Internet. At my main POP I'm planning on inserting 2 default routes, 1 from each core router with different weights. My daul core routers are homed to both of my border routers. Here's the simplified topology: BR1 BR2 | \/ | | /\ | | / \ | P1----P2----PE1--Peer | | | | PE2 PE3 | | CE1 CE2 There are more Ps and PEs but this gets the general idea across. I've come across route-leaking examples but they all require me to point traffic to an outward-facing interface. Ie, I can't just point the default route to a specific upstream-facing interface. Is there another way? I can't see a solution with importing routes at the route-target level. Can I point it to a loopback outside of the VRF? http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml This is probably a simple process but I haven't had to do it before without the FWSM which made it trivially easy. What simple solution have I overlooked and will kick myself for missing later? Thanks Justin From graham at g-rock.net Mon Oct 19 18:24:34 2009 From: graham at g-rock.net (Graham Wooden) Date: Mon, 19 Oct 2009 17:24:34 -0500 Subject: [c-nsp] 2600XM usability? In-Reply-To: <4ADCDEF4.3060503@justinshore.com> Message-ID: Hi all, I have a new network connecting to me that I will be shoving down some routes to them via a 5Mb metro-ethernet. They have a 2621XM. It will be doing BGP, with maybe a route table of 86K routes (mine plus their other provider, which I think is being delivered by a 2xT1 mlppp). I think it's the 128D/32F model. Not sure of the IOS as of yet. Does anyone have any real-world usability with this platform? Will this box hold up to 8Mb of traffic, with QoS/ACL and BGP with this number of routes? Thanks, -graham From mulitskiy at acedsl.com Mon Oct 19 17:54:22 2009 From: mulitskiy at acedsl.com (Michael Ulitskiy) Date: Mon, 19 Oct 2009 17:54:22 -0400 Subject: [c-nsp] PFC3B policing again Message-ID: <200910191754.22175.mulitskiy@acedsl.com> Hello, I wonder if anyone can comment on the following: CORE1#sh policy-map int vlan 21 Vlan21 Service-policy output: POLICE-DSL class-map: FROM-ACE-VOIP (match-all) Match: access-group name FROM-ACE-VOIP police aggregate OC3-VOIP-OUT : 1000000 bps 180000 limit 180000 extended limit Earl in slot 5 : 1775926349 bytes 5 minute offered rate 1933504 bps aggregate-forwarded 1775926349 bytes action: transmit exceeded 0 bytes action: transmit aggregate-forward 1632704 bps exceed 0 bps As you can see traffic matching works just fine and the rates it's showing is reasonable, but there's no traffic counted as exceeded even though both "aggregate-forward bps" and "5 minute offered rate" exceeds a configured rate of 1M. Is it a bug? Is aggregate policing supported on SVI in outbound direction? From the docs it looks like it is, but it doesn't seem to work for me. Equipment: 6509, SUP32, PFC3B. IOS: 12.2(33)SXH4 Config: ! mls qos aggregate-policer OC3-VOIP-OUT 1000000 180000 180000 conform-action transmit exceed-action transmit ! class-map FROM-ACE-VOIP match access-group name FROM-ACE-VOIP ! policy-map POLICE-DSL class FROM-ACE-VOIP police aggregate OC3-VOIP-OUT ! interface range vlan21,vlan25-29 service-policy output POLICE-DSL ! Any pointers is greatly appreciated, Thanks, Michael From erpa22276 at yahoo.com Mon Oct 19 17:35:46 2009 From: erpa22276 at yahoo.com (Per A) Date: Mon, 19 Oct 2009 14:35:46 -0700 (PDT) Subject: [c-nsp] Content Services Switch (CSS) question Message-ID: <647616.40238.qm@web36205.mail.mud.yahoo.com> I need to determine if I can examine the Content Length value in an HTTP header to prevent a web server from recieving invalid requests. Here is the challenge: I have an application out in the world that is submitting a blank XML document to one of my web services and it is causing the server to throw an exception. The exceptions are happening with enough frequency that the server is getting overwhelmed. I want to prevent these requests from reaching the server and I'm hoping that I can use CSS to identify the requests and send back an error (or send to another server to handle) when the METHOD=POST and Content Length = 0. Is this possible? From pshem.k at gmail.com Mon Oct 19 18:51:53 2009 From: pshem.k at gmail.com (Pshem Kowalczyk) Date: Tue, 20 Oct 2009 11:51:53 +1300 Subject: [c-nsp] Inserting a default route into a MPLS/VPN pointing out of the VRF In-Reply-To: <4ADCDEF4.3060503@justinshore.com> References: <4ADCDEF4.3060503@justinshore.com> Message-ID: <20fe625b0910191551j58c6755fsca80702753bad029@mail.gmail.com> Hi, I don't think there is a simple solution to that problem. Here are two ideas that we came up with to solve our issues and still maintain relatively 'clean' design. 1. With border routers as CEs - run a trunk between the PE and border routers with one vlan per vrf. That gives you ability to put a static in a vrf. 2. Turn the border routers into PEs and move the internet table into a vrf. From that vrf you can leak only specific routes (like the default). Ultimately we implemented second option (mainly because it was easier to scale). kind regards Pshem 2009/10/20 Justin Shore : > I'm having to rush a MPLS/VPN into service this week. ?Certain customers > will connect into this MPLS/VPN on PEs facing L2 switches with sub-ints in > the correct VRF, MLPPP bundles, direct connect to PEs, etc (lots of variety > down the road). ?Simple so far. ?The majority of the traffic will exit our > network out another PE at a peering point across our network, exiting out > another interface also assigned to the same VRF. Still simple. ?I'm doing > similar things today to support our data center and some other L3VPNs. ?Easy > stuff. > > The problem that I'm faced with is figuring out how to insert a default > route into that MPLS/VPN. ?I do this today with the data center VRFs with > the assistance of a FWSM in our core. ?I insert a default route pointed to > the backside of the customer's context on the FWSM; that route is a static > in the VRF. ?The FWSM bridges the gap between my MPLS/VPN and my default VRF > quite nicely. ?However in this situation I can't use the FWSMs. ?I need to > extract traffic from the VRF for the private network and out into the > default VRF on my core where I keep my Internet routes. ?Longest-match will > take care of the MPLS/VPN routes to properly route traffic to my peer. > ?Everything else needs to get out of the VRF and to the Internet. > > At my main POP I'm planning on inserting 2 default routes, 1 from each core > router with different weights. ?My daul core routers are homed to both of my > border routers. ?Here's the simplified topology: > > > BR1 ? BR2 > | ?\/ ?| > | ?/\ ?| > | / ?\ | > P1----P2----PE1--Peer > | ? ? ?| > | ? ? ?| > PE2 ? ? PE3 > | ? ? ?| > CE1 ? ?CE2 > > There are more Ps and PEs but this gets the general idea across. > > I've come across route-leaking examples but they all require me to point > traffic to an outward-facing interface. ?Ie, I can't just point the default > route to a specific upstream-facing interface. ?Is there another way? ?I > can't see a solution with importing routes at the route-target level. ?Can I > point it to a loopback outside of the VRF? > > http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml > > This is probably a simple process but I haven't had to do it before without > the FWSM which made it trivially easy. ?What simple solution have I > overlooked and will kick myself for missing later? > > Thanks > ?Justin > _______________________________________________ > cisco-nsp mailing list ?cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From mawhi at vestas.com Mon Oct 19 19:32:41 2009 From: mawhi at vestas.com (Matthew White) Date: Mon, 19 Oct 2009 16:32:41 -0700 Subject: [c-nsp] 2600XM usability? In-Reply-To: References: <4ADCDEF4.3060503@justinshore.com> Message-ID: Hi Graham, Of course YMMV, however I just replaced a 2691XM that was doing DMVPN duties running EIGRP (~350 routes). The unit was equiped with a cypto card and max throughput was around 10Mbps. At peak traffic times the CPU would hit 65/70% and this is without running QoS. So, from my perspective the 2621XM doesn't have enough juice to do what you want it to do. Hope this helps, -mtw -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Graham Wooden Sent: Monday, October 19, 2009 3:25 PM To: cisco-nsp Subject: [c-nsp] 2600XM usability? Hi all, I have a new network connecting to me that I will be shoving down some routes to them via a 5Mb metro-ethernet. They have a 2621XM. It will be doing BGP, with maybe a route table of 86K routes (mine plus their other provider, which I think is being delivered by a 2xT1 mlppp). I think it's the 128D/32F model. Not sure of the IOS as of yet. Does anyone have any real-world usability with this platform? Will this box hold up to 8Mb of traffic, with QoS/ACL and BGP with this number of routes? Thanks, -graham _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From awain567 at yahoo.com Mon Oct 19 18:33:40 2009 From: awain567 at yahoo.com (Alex Wa) Date: Mon, 19 Oct 2009 15:33:40 -0700 (PDT) Subject: [c-nsp] ip sla question Message-ID: <719497.7206.qm@web58003.mail.re3.yahoo.com> Hi guys, ? Why do we need to specify dst-port as in ? ip sla 1 udp-jitter ? even when the ip sla responder doen't have one particular port where it listens to? ? thanks in advance to everyone alejandro w. From graham at g-rock.net Mon Oct 19 20:07:59 2009 From: graham at g-rock.net (Graham Wooden) Date: Mon, 19 Oct 2009 19:07:59 -0500 Subject: [c-nsp] 2600XM usability? In-Reply-To: Message-ID: I appreciate the reply Matthew. Yikes, yeah - I don't think that'll work. Any suggestions for something on the used market that will suffice? Maybe I should look for a 3640 or something. Thanks! -graham On 10/19/09 6:32 PM, "Matthew White" wrote: > Hi Graham, > > Of course YMMV, however I just replaced a 2691XM that was doing DMVPN duties > running EIGRP (~350 routes). The unit was equiped with a cypto card and max > throughput was around 10Mbps. > > At peak traffic times the CPU would hit 65/70% and this is without running > QoS. So, from my perspective the 2621XM doesn't have enough juice to do what > you want it to do. > > Hope this helps, > > -mtw > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Graham Wooden > Sent: Monday, October 19, 2009 3:25 PM > To: cisco-nsp > Subject: [c-nsp] 2600XM usability? > > Hi all, > > I have a new network connecting to me that I will be shoving down some > routes to them via a 5Mb metro-ethernet. They have a 2621XM. It will be > doing BGP, with maybe a route table of 86K routes (mine plus their other > provider, which I think is being delivered by a 2xT1 mlppp). I think it's > the 128D/32F model. Not sure of the IOS as of yet. > > Does anyone have any real-world usability with this platform? Will this box > hold up to 8Mb of traffic, with QoS/ACL and BGP with this number of routes? > > Thanks, > > -graham > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From philxor at gmail.com Mon Oct 19 20:16:36 2009 From: philxor at gmail.com (Phil Bedard) Date: Mon, 19 Oct 2009 20:16:36 -0400 Subject: [c-nsp] Inserting a default route into a MPLS/VPN pointing out of the VRF In-Reply-To: <4ADCDEF4.3060503@justinshore.com> References: <4ADCDEF4.3060503@justinshore.com> Message-ID: <39509708-F402-46C0-8E15-E238B1BB2B22@gmail.com> If you are already using a VRF to carry the default table you should be able to import a default route from that vrf into your customer vrf. You can use an import-map to select only the default. The only time I've implemented something similar to this I've used external firewalls which have their own trusted sub-int into the customer network and their untrust side connected to an Internet router. Similar to what you say you are doing on the datacenter side. You could do the same thing without a firewall, just need a dedicated trunk so you can bridge between the default VRF/global table and the customer VRF. Then just static routes out that interface. Phil On Oct 19, 2009, at 5:49 PM, Justin Shore wrote: > I'm having to rush a MPLS/VPN into service this week. Certain > customers will connect into this MPLS/VPN on PEs facing L2 switches > with sub-ints in the correct VRF, MLPPP bundles, direct connect to > PEs, etc (lots of variety down the road). Simple so far. The > majority of the traffic will exit our network out another PE at a > peering point across our network, exiting out another interface also > assigned to the same VRF. Still simple. I'm doing similar things > today to support our data center and some other L3VPNs. Easy stuff. > > The problem that I'm faced with is figuring out how to insert a > default route into that MPLS/VPN. I do this today with the data > center VRFs with the assistance of a FWSM in our core. I insert a > default route pointed to the backside of the customer's context on > the FWSM; that route is a static in the VRF. The FWSM bridges the > gap between my MPLS/VPN and my default VRF quite nicely. However in > this situation I can't use the FWSMs. I need to extract traffic > from the VRF for the private network and out into the default VRF on > my core where I keep my Internet routes. Longest-match will take > care of the MPLS/VPN routes to properly route traffic to my peer. > Everything else needs to get out of the VRF and to the Internet. > > At my main POP I'm planning on inserting 2 default routes, 1 from > each core router with different weights. My daul core routers are > homed to both of my border routers. Here's the simplified topology: > > > BR1 BR2 > | \/ | > | /\ | > | / \ | > P1----P2----PE1--Peer > | | > | | > PE2 PE3 > | | > CE1 CE2 > > There are more Ps and PEs but this gets the general idea across. > > I've come across route-leaking examples but they all require me to > point traffic to an outward-facing interface. Ie, I can't just > point the default route to a specific upstream-facing interface. Is > there another way? I can't see a solution with importing routes at > the route-target level. Can I point it to a loopback outside of the > VRF? > > http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml > > This is probably a simple process but I haven't had to do it before > without the FWSM which made it trivially easy. What simple solution > have I overlooked and will kick myself for missing later? > > Thanks > Justin > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From mawhi at vestas.com Mon Oct 19 20:28:53 2009 From: mawhi at vestas.com (Matthew White) Date: Mon, 19 Oct 2009 17:28:53 -0700 Subject: [c-nsp] 2600XM usability? In-Reply-To: References: Message-ID: Hi Graham, I think a 2821 with enough memory would do the trick. Even new, the ones without the AIM module are fairly inexpensive. -mtw -----Original Message----- From: Graham Wooden [mailto:graham at g-rock.net] Sent: Monday, October 19, 2009 5:08 PM To: Matthew White; cisco-nsp Subject: Re: [c-nsp] 2600XM usability? I appreciate the reply Matthew. Yikes, yeah - I don't think that'll work. Any suggestions for something on the used market that will suffice? Maybe I should look for a 3640 or something. Thanks! -graham On 10/19/09 6:32 PM, "Matthew White" wrote: > Hi Graham, > > Of course YMMV, however I just replaced a 2691XM that was doing DMVPN duties > running EIGRP (~350 routes). The unit was equiped with a cypto card and max > throughput was around 10Mbps. > > At peak traffic times the CPU would hit 65/70% and this is without running > QoS. So, from my perspective the 2621XM doesn't have enough juice to do what > you want it to do. > > Hope this helps, > > -mtw > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Graham Wooden > Sent: Monday, October 19, 2009 3:25 PM > To: cisco-nsp > Subject: [c-nsp] 2600XM usability? > > Hi all, > > I have a new network connecting to me that I will be shoving down some > routes to them via a 5Mb metro-ethernet. They have a 2621XM. It will be > doing BGP, with maybe a route table of 86K routes (mine plus their other > provider, which I think is being delivered by a 2xT1 mlppp). I think it's > the 128D/32F model. Not sure of the IOS as of yet. > > Does anyone have any real-world usability with this platform? Will this box > hold up to 8Mb of traffic, with QoS/ACL and BGP with this number of routes? > > Thanks, > > -graham > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From yuribank at gmail.com Mon Oct 19 23:04:37 2009 From: yuribank at gmail.com (Yuri Bank) Date: Mon, 19 Oct 2009 20:04:37 -0700 Subject: [c-nsp] Basic RSTP question In-Reply-To: References: Message-ID: <2e38d2400910192004y3c7e911cwabf68a12c197a2db@mail.gmail.com> You're correct. The port between C and A will be the only port in a forwarding state eligible for the TC to be sent out. ( C will be blocking its port to B at this point). On Mon, Oct 19, 2009 at 8:26 AM, samuel vuillaume wrote: > Hi guys, > > Just quick question pretty straight forward about RSTP. In a triangle > topology as below > > > A(f) ---------- (f)C > | (b) > B(f)_________| > > Let's say A is root and B backup root, port to B is block on C, and port > to > A is forwarding. > > When i shut down the root port, no problem, it converges in less than 1 > sec. > > > My question is when the port on C is un shut, so back up, the handshake > starts between A and C ( i mean proposal and agreement), > > and after the handshake, on C port facing A should move from blocking to > forwarding. In that case, does C send out a TC on this port and flush is > MAC > address table? > > > tks > Sam > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From dale.shaw+cisco-nsp at gmail.com Tue Oct 20 00:31:11 2009 From: dale.shaw+cisco-nsp at gmail.com (Dale Shaw) Date: Tue, 20 Oct 2009 15:31:11 +1100 Subject: [c-nsp] Does a cisco 837 support traffic shaping on Ethernet? Message-ID: <3329cbb40910192131n6f5deeccr6ba04d6cf5aad63c@mail.gmail.com> Hi, I don't have an 837 handy, and I know they're a bit ancient and useless, but I have a customer asking about support for class-based shaping on his ageing fleet of 837s. He has Ethernet0 configured as LAN-side and Ethernet2 configured as WAN-side -- not using the ADSL/ATM interface at all. He wants to do egress shaping towards the WAN, preferably using MQC, but Feature Navigator suggests neither class-based shaping or GTS are supported on this platform. Other literature suggests traffic shaping is supported on the ATM interface. Possible? All signs point to 'no', but I couldn't find a definitive reference. cheers, Dale From vijaygore27 at gmail.com Tue Oct 20 01:21:34 2009 From: vijaygore27 at gmail.com (vijay gore) Date: Tue, 20 Oct 2009 10:51:34 +0530 Subject: [c-nsp] file transfer In-Reply-To: <9a9d0c6a0910140854y34b581f7gf1594a1b616a8535@mail.gmail.com> References: <31533f200910140057g72517b4bnc15c6fb3813e606c@mail.gmail.com> <4AD58EEC.900@gmx.de> <9a9d0c6a0910140854y34b581f7gf1594a1b616a8535@mail.gmail.com> Message-ID: <31533f200910192221i4e2cf279u7152db7d946b0a9e@mail.gmail.com> Dear sir, i want do this test on router , on mpls vpn On Wed, Oct 14, 2009 at 9:24 PM, Gary T. Giesen wrote: > ttcp is also an option. It's a hidden command in most IOS > platforms/releases, and allows you to test TCP throughput. There's > also a UNIX version you can use to test between a router and a unix > box or between unix boxes. You can google for the code.. > > On Wed, Oct 14, 2009 at 4:42 AM, Garry wrote: > > vijay gore wrote: > >> dear team, > >> i want to check my bandwidth using file transfer please help how to do > that+ > > Using file transfer for performance measurement is unreliable ... google > > iperf/jperf for decent point-2-point throughput measurement ... please > > note that it requires access to both the local site as well as a remote > > station to test against ... > > > > -garry > > _______________________________________________ > > cisco-nsp mailing list cisco-nsp at puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > From security at cytanet.com.cy Tue Oct 20 01:14:07 2009 From: security at cytanet.com.cy (Michalis Palis) Date: Tue, 20 Oct 2009 08:14:07 +0300 Subject: [c-nsp] MPLS internatl Link Balancing Message-ID: Hello all I Have 3 STM-1 links between two routers on an MPLS core network. The problem is that load balancing for traffic passing through this STM connections is done only on one way and not on both ways. Is their any way to balance both ways? OSPF is running as an IGP protocol. Your advice will be appreciated From victor.lyapunov at gmail.com Tue Oct 20 03:53:46 2009 From: victor.lyapunov at gmail.com (Victor Lyapunov) Date: Tue, 20 Oct 2009 10:53:46 +0300 Subject: [c-nsp] 7609 DHCP alternatives - EVC / Subinterfaces Message-ID: Hi All I am trying to test DHCP functionality with 7600 router. Traffic arrives from all customer facing interfaces (ES+), arrive using the same VLAN. 7600 perfoms DHCP relay and acts as a gateway for all of them. With the new cards ES+ we have two options for the configuration of customer facing interfaces 1. Using EVC + SVI interface int g4/1 service instance 100 ethernet encapsulation dot1q 100 rewrite ingress tag pop 1 symmetric bridge-domain 100 split-horizon int g4/2 service instance 100 ethernet encapsulation dot1q 100 rewrite ingress tag pop 1 symmetric bridge-domain 100 split-horizon int Vlan 100 ip address 10.0.0.1 255.255.255.0 ip helper address 192.168.0.1 2. Using IP subinterfaces int loopback 100 ip address 10.0.0.1 255.255.255.0 int g4/1.100 encapsulation dot1q 100 ip address unnumbered loopback 100 ip helper address 192.168.0.1 int g4/2.100 encapsulation dot1q 100 ip address unnumbered loopback 100 ip helper address 192.168.0.1 Both configurations seem to achieve the same effect but I am not sure which one is the preferable for large amount of traffic / subscribers. For example due to the bridge domain I would expect that the first alternative will create more entries in the mac-address table. Thanx Victor From peter at rathlev.dk Tue Oct 20 04:23:57 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Tue, 20 Oct 2009 10:23:57 +0200 Subject: [c-nsp] ip sla question In-Reply-To: <719497.7206.qm@web58003.mail.re3.yahoo.com> References: <719497.7206.qm@web58003.mail.re3.yahoo.com> Message-ID: <1256027037.2994.5.camel@abehat.net.rm.dk> On Mon, 2009-10-19 at 15:33 -0700, Alex Wa wrote: > Why do we need to specify dst-port as in > > ip sla 1 > udp-jitter > > even when the ip sla responder doen't have one particular port where > it listens to? If you only enable "ip sla responder" the query device uses control packets to enable the port you specify on the receiving device. If you specify a port on the receiving device (e.g. "ip sla responder udp-echo port 65500") you can run SLA probes without control packets from the query device: ip sla 1 udp-echo 10.0.0.1 65500 control disable ! So the port is always used, but the IP SLA control packets tells the receiving device to listen on the specific port before the probe is sent. -- Peter From lukasz at trabinski.net Tue Oct 20 04:47:37 2009 From: lukasz at trabinski.net (Lukasz Trabinski) Date: Tue, 20 Oct 2009 10:47:37 +0200 (CEST) Subject: [c-nsp] Xconnect on Portchannel interface [EoMPLS] In-Reply-To: References: Message-ID: On Fri, 16 Oct 2009, Marko Milivojevic wrote: Hello. > 2009/10/16 Lukasz Trabinski : >> Hello >> >> I have problem with xconnect on portchannel interface. > [...] >> How to do xconnect from untagged portchanel interface? > > Have you tried disabling LACP on the EC interface and have it > statically configured (mode on)? Yes, it's works but only from cisco side. On other side of port-chanell we have Force10 device and when I configure mode on, I have port-channel UP. on cisco device, but "down" on Force10. The question is, why it's works when xconnect is configured on subinterface with tagged vlan? Maybe is it conflict with LACP/MPLS signalization? From markom at markom.info Tue Oct 20 06:01:01 2009 From: markom at markom.info (Marko Milivojevic) Date: Tue, 20 Oct 2009 10:01:01 +0000 Subject: [c-nsp] Xconnect on Portchannel interface [EoMPLS] In-Reply-To: References: Message-ID: > Yes, it's works but only from cisco side. On other side of port-chanell we > have Force10 device and when I configure mode on, I have port-channel UP. on > cisco device, but "down" on Force10. The question is, why it's works when > xconnect is configured on subinterface with tagged vlan? Maybe is it > conflict with LACP/MPLS signalization? I had another thought after my original reply, but for some reason I didn't send you follow-up. Have you tried not enabling EC on Cisco doing xconnect (PE) at all and simply having it just on end-nodes: A===PE1---PE2===B Enable EC just on A and B and do simple xconnect from all interfaces on PE1 and PE2? My knowledge is very rusty, but it could be that LACP will be carried over in port mode. -- Marko CCIE #18427 (SP) My network blog: http://cisco.markom.info/ From cchurc05 at harris.com Tue Oct 20 10:14:37 2009 From: cchurc05 at harris.com (Church, Charles) Date: Tue, 20 Oct 2009 10:14:37 -0400 Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <64A2673D120E4B408424519469A78A6C@flamdt01> References: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net><4ACA0B77.5090106@inex.ie> <200910060541.19686.mtinka@globaltransit.net><4ADC5092.7040905@inex.ie><828027.91138.qm@web508.biz.mail.mud.yahoo.com> <290EF89F13F04F4E924BB235A46D18F1043B2BA143@MLBMXUS2.cs.myharris.net> <64A2673D120E4B408424519469A78A6C@flamdt01> Message-ID: <290EF89F13F04F4E924BB235A46D18F1043B41E802@MLBMXUS2.cs.myharris.net> Thanks. I assume that even though the 6509-V-E is available, until the 80gig line cards and Sup are available, you'd be stuck at 40gig/slot? Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tony Varriale Sent: Monday, October 19, 2009 5:07 PM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] DWDM optics on 6500s It will shortly but it won't do you any good with the existing family of sups. The 2T will be the first (and last?) sup that can push the bandwidth to all those slots. You can also reference the 6509-V-E...it's ready for 80gbps/slot. You can order that today. Note that it's a NEBS chassis. tv ----- Original Message ----- From: "Church, Charles" To: "Kevin Graham" Cc: Sent: Monday, October 19, 2009 1:12 PM Subject: Re: [c-nsp] DWDM optics on 6500s > Are you saying a 6513-E chassis exists? I can't find any reference to it. > That would solve a few of the problems we currently have (density issue) > > Chuck > > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Kevin Graham > Sent: Monday, October 19, 2009 11:45 AM > To: Nick Hilliard; mtinka at globaltransit.net > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] DWDM optics on 6500s > > >> As a side issue, there are electrical limitations imposed by the physical > >> cross-bar unit inside the actual chassis, but I don't know how much of a >> problem >> these limitations are in practice. > > 6500E was the key for this. Besides nutty amounts of POE capacity, it also > picked up > improved backplane for >20g+ fabric and extending to all 11 LC slots in > the 6513. > > (Still need to dig up details, as faster SSO time is also tied to chassis, > though > I can't recall why). > _______________________________________________ > cisco-nsp mailing list cisco-nsp at 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 at 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 at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From bacon at walleyesoftware.com Tue Oct 20 10:14:26 2009 From: bacon at walleyesoftware.com (Jeff Bacon) Date: Tue, 20 Oct 2009 09:14:26 -0500 Subject: [c-nsp] XFP, SFP+, ??? Message-ID: <5A69C25361FED34F83ABF05F50475245072BC26E@wally.walleyetrading.net> So, I am looking at doing DWDM for some mid-haul passive-splitter links around NYC metro - working with a carrier that's buying dark and offering to hand me lambdas off passive splitters. I'm going to need to punch enough power to go 20-40km + losses in the passive splitters. Do I need to look at SXI + SIP-400 + SPA to go XFP? Am I better off with a 6704 to get XENPAK even tho it's not the best board in the known universe? Or do I go with X2 tuned optics? Effectively, what's the cheapest practical option, assuming I need no more than 4 ports per 6500 and don't have > 1 slot available? (I have physical space constraints, I mostly work with 03E and 04E chassis) Thanks, -bacon From jan.w at lzer.net Tue Oct 20 06:45:00 2009 From: jan.w at lzer.net (Jan Walzer) Date: Tue, 20 Oct 2009 12:45:00 +0200 Subject: [c-nsp] Content Services Switch (CSS) question In-Reply-To: <647616.40238.qm@web36205.mail.mud.yahoo.com> References: <647616.40238.qm@web36205.mail.mud.yahoo.com> Message-ID: On Mon, 19 Oct 2009 23:35:46 +0200, Per A wrote: > I have an application out in the world that is submitting a blank XML > document to one of my web services and it is causing the server to throw > an exception. The exceptions are happening with enough frequency that > the server is getting overwhelmed. I want to prevent these requests from > reaching the server and I'm hoping that I can use CSS to identify the > requests and send back an error (or send to another server to handle) > when the METHOD=POST and Content Length = 0. > > Is this possible? Hi Per A, It's been a while since I last played with the arrowp^WCSS-Boxes, but it should be possible. You need a L5-Rule, to act on that headerfield and redirect it to another service, which then acts different on what you want as response, maybe returning a 404. Greetings, Jan -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From kgraham at industrial-marshmallow.com Tue Oct 20 10:48:26 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Tue, 20 Oct 2009 07:48:26 -0700 (PDT) Subject: [c-nsp] DWDM optics on 6500s In-Reply-To: <290EF89F13F04F4E924BB235A46D18F1043B41E802@MLBMXUS2.cs.myharris.net> References: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net><4ACA0B77.5090106@inex.ie> <200910060541.19686.mtinka@globaltransit.net><4ADC5092.7040905@inex.ie><828027.91138.qm@web508.biz.mail.mud.yahoo.com> <290EF89F13F04F4E924BB235A46D18F1043B2BA143@MLBMXUS2.cs.myharris.net> <64A2673D120E4B408424519469A78A6C@flamdt01> <290EF89F13F04F4E924BB235A46D18F1043B41E802@MLBMXUS2.cs.myharris.net> Message-ID: <180961.49953.qm@web506.biz.mail.mud.yahoo.com> > I assume that even though the 6509-V-E is available, until the 80gig > line cards and Sup are available, you'd be stuck at 40gig/slot? Correct (nothing special about the 09-V-E in this respect compared to any other the -E's as far as I know). This is the same as how the traditional (pre-E) 6500 chassis was capable of doing to do 2x20gb per slot, but it was a step ahead of the rest of the system which would only deliver 8gb (w/ SFM/SFM2) until the Sup720 was released. From david.freedman at uk.clara.net Tue Oct 20 10:48:27 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 20 Oct 2009 15:48:27 +0100 Subject: [c-nsp] XFP, SFP+, ??? In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC26E@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC26E@wally.walleyetrading.net> Message-ID: <4ADDCDBB.8000808@uk.clara.net> > So, I am looking at doing DWDM for some mid-haul passive-splitter links > around NYC metro - working with a carrier that's buying dark and > offering to hand me lambdas off passive splitters. Did you consider an "active" unit before you go running in vendor "coloured pluggable" compatability issues (which technically should be "few and far between" now cisco have pulled their finger out) http://www.nanog.org/meetings/nanog42/presentations/pluggables.pdf is a good presentation from nanog42 with regards to pluggables. I see you have 6500, but you make no mention of 1G or 10G being your requirement, if you meant 10G then I assume this means you are thinking of WS-X6704/8 and in such case you can /technically/ get hold of coloured xenpaks (I believe opnext manafacture these) but I would personally not waste my money here. If 1G, your options are more open, plenty of people manafacture coloured SFPs which are cisco "compatible" Dave. Jeff Bacon wrote: > So, I am looking at doing DWDM for some mid-haul passive-splitter links > around NYC metro - working with a carrier that's buying dark and > offering to hand me lambdas off passive splitters. > > I'm going to need to punch enough power to go 20-40km + losses in the > passive splitters. > > Do I need to look at SXI + SIP-400 + SPA to go XFP? > Am I better off with a 6704 to get XENPAK even tho it's not the best > board in the known universe? > Or do I go with X2 tuned optics? > > Effectively, what's the cheapest practical option, assuming I need no > more than 4 ports per 6500 and don't have > 1 slot available? (I have > physical space constraints, I mostly work with 03E and 04E chassis) > > Thanks, > -bacon > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From david.freedman at uk.clara.net Tue Oct 20 10:48:27 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 20 Oct 2009 15:48:27 +0100 Subject: [c-nsp] XFP, SFP+, ??? In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC26E@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC26E@wally.walleyetrading.net> Message-ID: <4ADDCDBB.8000808@uk.clara.net> > So, I am looking at doing DWDM for some mid-haul passive-splitter links > around NYC metro - working with a carrier that's buying dark and > offering to hand me lambdas off passive splitters. Did you consider an "active" unit before you go running in vendor "coloured pluggable" compatability issues (which technically should be "few and far between" now cisco have pulled their finger out) http://www.nanog.org/meetings/nanog42/presentations/pluggables.pdf is a good presentation from nanog42 with regards to pluggables. I see you have 6500, but you make no mention of 1G or 10G being your requirement, if you meant 10G then I assume this means you are thinking of WS-X6704/8 and in such case you can /technically/ get hold of coloured xenpaks (I believe opnext manafacture these) but I would personally not waste my money here. If 1G, your options are more open, plenty of people manafacture coloured SFPs which are cisco "compatible" Dave. Jeff Bacon wrote: > So, I am looking at doing DWDM for some mid-haul passive-splitter links > around NYC metro - working with a carrier that's buying dark and > offering to hand me lambdas off passive splitters. > > I'm going to need to punch enough power to go 20-40km + losses in the > passive splitters. > > Do I need to look at SXI + SIP-400 + SPA to go XFP? > Am I better off with a 6704 to get XENPAK even tho it's not the best > board in the known universe? > Or do I go with X2 tuned optics? > > Effectively, what's the cheapest practical option, assuming I need no > more than 4 ports per 6500 and don't have > 1 slot available? (I have > physical space constraints, I mostly work with 03E and 04E chassis) > > Thanks, > -bacon > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From bacon at walleyesoftware.com Tue Oct 20 10:55:15 2009 From: bacon at walleyesoftware.com (Jeff Bacon) Date: Tue, 20 Oct 2009 09:55:15 -0500 Subject: [c-nsp] XFP, SFP+, ??? In-Reply-To: <4ADDCDBB.8000808@uk.clara.net> References: <5A69C25361FED34F83ABF05F50475245072BC26E@wally.walleyetrading.net> <4ADDCDBB.8000808@uk.clara.net> Message-ID: <5A69C25361FED34F83ABF05F50475245072BC276@wally.walleyetrading.net> > I see you have 6500, but you make no mention of 1G or 10G being your > requirement, if you meant 10G then I assume this means you are thinking > of WS-X6704/8 and in such case you can /technically/ get hold of > coloured xenpaks (I believe opnext manafacture these) but I would > personally not waste my money here. > > If 1G, your options are more open, plenty of people manafacture > coloured SFPs which are cisco "compatible" Desire is for 10G. If I wanted 1G I can just have the carrier give me switched enet and not bother with any of the fuss. I could temporarily use 1G colored SFPs but that's IMO a throwaway. The bandwidth requirement is for 1G < X < 10G; primarily bursting to 3-5G with well under 1G average for now, eventually the average will come up but that's 6mo-1yr+. Policing the streams to fit in a 1G pipe is not an option; the bursts have to get through and dropping packets is not acceptable. 6708 uses X2, yes? Or are we considering XENPAK/X2 interchangeable from the POV of buying colored optics? Using an external box to condition the wave is an option but now I'm paying bux for the colored optics in the box, plus the box, plus the 10G to get into the 6500, which seems like a net big lose. -bacon From dominic at broadconnect.ca Tue Oct 20 11:05:35 2009 From: dominic at broadconnect.ca (Dominic) Date: Tue, 20 Oct 2009 11:05:35 -0400 Subject: [c-nsp] Bonded T1 Circuits References: Message-ID: <00b901ca5196$c6abe9e0$d400a8c0@dominic> Hi Everyone: Two questions: 1. I need to bond two T1 circuits. Does anyone have a working sample config? The POP end is a 7206VXR with NPE-G2 and the PA-MC-2T3-EC Card, and the customer end is a Cisco 1841. 2. Also need to bond as many as 4 T1s. Would that be pushing it, and what would generally be the cleanest way to do it? Dominic From nick at inex.ie Tue Oct 20 11:19:53 2009 From: nick at inex.ie (Nick Hilliard) Date: Tue, 20 Oct 2009 16:19:53 +0100 Subject: [c-nsp] XFP, SFP+, ??? In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC276@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC26E@wally.walleyetrading.net> <4ADDCDBB.8000808@uk.clara.net> <5A69C25361FED34F83ABF05F50475245072BC276@wally.walleyetrading.net> Message-ID: <4ADDD519.1010301@inex.ie> On 20/10/2009 15:55, Jeff Bacon wrote: > Using an external box to condition the wave is an option but now I'm > paying bux for the colored optics in the box, plus the box, plus the 10G > to get into the 6500, which seems like a net big lose. The advantage that this gives you is that you don't end up paying for coloured xenpaks or X2s (both of which are ridiculously expensive), and you do end with a transmission system which is completely vendor and transceiver independent. "Cheap" is a fluid concept. Are you measuring "cheap" according to up-front capex right now, or by 1Y / 3Y / 5Y tco or whatever your depreciation time period is, or by reusability if you change from one client transceiver type to another? Nick From moua0100 at umn.edu Tue Oct 20 11:35:21 2009 From: moua0100 at umn.edu (Ge Moua) Date: Tue, 20 Oct 2009 10:35:21 -0500 Subject: [c-nsp] Bonded T1 Circuits In-Reply-To: <00b901ca5196$c6abe9e0$d400a8c0@dominic> References: <00b901ca5196$c6abe9e0$d400a8c0@dominic> Message-ID: <4ADDD8B9.8000306@umn.edu> something like this should work (got it off one of production router): interface Serial0/0/0 mtu 4470 no ip address encapsulation ppp ppp multilink ppp multilink group 1 interface Serial0/1/0 mtu 4470 no ip address encapsulation ppp ppp multilink ppp multilink group 1 interface Multilink1 mtu 4470 ip address 192.168.11.205 255.255.255.252 ppp multilink ppp multilink group 1 ppp multilink fragment disable Regards, Ge Moua | Email: moua0100 at umn.edu Network Design Engineer University of Minnesota | Networking & Telecommunications Services Dominic wrote on 10/20/2009 10:05 AM: > Hi Everyone: > > Two questions: > > 1. I need to bond two T1 circuits. Does anyone have a working sample > config? The POP end is a 7206VXR with NPE-G2 and the PA-MC-2T3-EC > Card, and the customer end is a Cisco 1841. > 2. Also need to bond as many as 4 T1s. Would that be pushing it, and > what would generally be the cleanest way to do it? > > > Dominic > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From Jeff.Wojciechowski at midlandpaper.com Tue Oct 20 11:39:13 2009 From: Jeff.Wojciechowski at midlandpaper.com (Jeff Wojciechowski) Date: Tue, 20 Oct 2009 10:39:13 -0500 Subject: [c-nsp] Bonded T1 Circuits In-Reply-To: <00b901ca5196$c6abe9e0$d400a8c0@dominic> References: <00b901ca5196$c6abe9e0$d400a8c0@dominic> Message-ID: <6B8401A83219DF499C34DEAEE9A5999219FC13ED86@XBOX.midlandpaper.com> Hi Dominic, We do ours with MLPPP: interface Multilink1 bandwidth 3072 ip address xxxxxxxx no cdp enable ppp multilink ppp multilink group 1 ! interface Serial0/0/0:0 bandwidth 1536 no ip address no ip proxy-arp encapsulation ppp no cdp enable ppp multilink ppp multilink group 1 ! interface Serial0/0/1:0 bandwidth 1536 no ip address no ip proxy-arp encapsulation ppp no cdp enable ppp multilink ppp multilink group 1 1) Both serial interfaces are a part of the logical Multilink interface. Nice part about this is you can add and remove circuits/interfaces to the Multilink quite easily. 2) Depending on the router on your end, you may run into limitations for how many ckts you can have in the bundle and have it work properly. Not sure how many the 1841 will support. In our case, I believe our 2821 can support a max of 4 T1s. -Jeff -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dominic Sent: Tuesday, October 20, 2009 10:06 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Bonded T1 Circuits Hi Everyone: Two questions: 1. I need to bond two T1 circuits. Does anyone have a working sample config? The POP end is a 7206VXR with NPE-G2 and the PA-MC-2T3-EC Card, and the customer end is a Cisco 1841. 2. Also need to bond as many as 4 T1s. Would that be pushing it, and what would generally be the cleanest way to do it? Dominic _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From bacon at walleyesoftware.com Tue Oct 20 11:56:02 2009 From: bacon at walleyesoftware.com (Jeff Bacon) Date: Tue, 20 Oct 2009 10:56:02 -0500 Subject: [c-nsp] XFP, SFP+, ??? In-Reply-To: <4ADDD519.1010301@inex.ie> References: <5A69C25361FED34F83ABF05F50475245072BC26E@wally.walleyetrading.net> <4ADDCDBB.8000808@uk.clara.net> <5A69C25361FED34F83ABF05F50475245072BC276@wally.walleyetrading.net> <4ADDD519.1010301@inex.ie> Message-ID: <5A69C25361FED34F83ABF05F50475245072BC279@wally.walleyetrading.net> > On 20/10/2009 15:55, Jeff Bacon wrote: > > Using an external box to condition the wave is an option but now I'm > > paying bux for the colored optics in the box, plus the box, plus the 10G > > to get into the 6500, which seems like a net big lose. > > The advantage that this gives you is that you don't end up paying for > coloured xenpaks or X2s (both of which are ridiculously expensive), and you > do end with a transmission system which is completely vendor and > transceiver independent. Well, yer always dependent on _some_ vendor - be it Cisco, opt-whoever, or whoever's making your external box. I suppose if you're avoiding XENPAK/X2 and trying to go XFP, then your XFP is theoretically portable. (Though you could fork for a SIP400 and the 10G SPA and then be XFP-happy.) > "Cheap" is a fluid concept. Are you measuring "cheap" according to > up-front capex right now, or by 1Y / 3Y / 5Y tco or whatever your > depreciation time period is, or by reusability if you change from one > client transceiver type to another? Up-front capex, 2yr TCO (though in the given case I'm not sure what else factors into TCO besides the MRC of the fiber path and cost of rack space). It feels like a crap-shoot on XFP / SFP+, with reach issues on the SFP+ that could be an issue. >From the docs Peter kindly posted earlier, it appears Cisco is planning to "cope" with SFP+ with the CVR-X2-SFP10G OneX X2->SFP+ adapters. Doesn't help now b/c it's SR/copper only, but I'd be surprised if this didn't get fleshed out. From sethm at rollernet.us Tue Oct 20 12:01:42 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 20 Oct 2009 09:01:42 -0700 Subject: [c-nsp] Bonded T1 Circuits In-Reply-To: <6B8401A83219DF499C34DEAEE9A5999219FC13ED86@XBOX.midlandpaper.com> References: <00b901ca5196$c6abe9e0$d400a8c0@dominic> <6B8401A83219DF499C34DEAEE9A5999219FC13ED86@XBOX.midlandpaper.com> Message-ID: <4ADDDEE6.3030804@rollernet.us> Jeff Wojciechowski wrote: > > 2) Depending on the router on your end, you may run into limitations for how many ckts you can have in the bundle and have it work properly. Not sure how many the 1841 will support. In our case, I believe our 2821 can support a max of 4 T1s. > You could do 8 if you use four VWIC-2MFT-T1 cards, which is pretty much as high as you'd ever want to go with MLPPP. ~Seth From md at bts.sk Tue Oct 20 12:13:41 2009 From: md at bts.sk (=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=) Date: Tue, 20 Oct 2009 18:13:41 +0200 Subject: [c-nsp] XFP, SFP+, ??? In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC279@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC26E@wally.walleyetrading.net> <4ADDCDBB.8000808@uk.clara.net> <5A69C25361FED34F83ABF05F50475245072BC276@wally.walleyetrading.net> <4ADDD519.1010301@inex.ie> <5A69C25361FED34F83ABF05F50475245072BC279@wally.walleyetrading.net> Message-ID: <20091020160802.M43032@bts.sk> On Tue, 20 Oct 2009 10:56:02 -0500, Jeff Bacon wrote > It feels like a crap-shoot on XFP / SFP+, with reach issues on the SFP+ > that could be an issue. > > >From the docs Peter kindly posted earlier, it appears Cisco is planning > to "cope" with SFP+ with the CVR-X2-SFP10G OneX X2->SFP+ adapters. > Doesn't help now b/c it's SR/copper only, but I'd be surprised if this > didn't get fleshed out. Well, the biggest problem with SFP+ is, no DWDM nor 80 km version exists today and noone knows when (if at all) this will be available. As for the adapter, an X2->XFP is also doable and would help many customers, but it's apparently not planned... With kind regards, M. From ras at e-gerbil.net Tue Oct 20 12:20:54 2009 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Tue, 20 Oct 2009 11:20:54 -0500 Subject: [c-nsp] XFP, SFP+, ??? In-Reply-To: <5A69C25361FED34F83ABF05F50475245072BC26E@wally.walleyetrading.net> References: <5A69C25361FED34F83ABF05F50475245072BC26E@wally.walleyetrading.net> Message-ID: <20091020162054.GQ51443@gerbil.cluepon.net> On Tue, Oct 20, 2009 at 09:14:26AM -0500, Jeff Bacon wrote: > So, I am looking at doing DWDM for some mid-haul passive-splitter links > around NYC metro - working with a carrier that's buying dark and > offering to hand me lambdas off passive splitters. > > I'm going to need to punch enough power to go 20-40km + losses in the > passive splitters. > > Do I need to look at SXI + SIP-400 + SPA to go XFP? > Am I better off with a 6704 to get XENPAK even tho it's not the best > board in the known universe? > Or do I go with X2 tuned optics? > > Effectively, what's the cheapest practical option, assuming I need no > more than 4 ports per 6500 and don't have > 1 slot available? (I have > physical space constraints, I mostly work with 03E and 04E chassis) SIP/SPA or ES cards are horrifically overpriced if all you want to do is use XFP. You can find DWDM XENPAKs which work just fine, but they're quite pricey if you get them new, and in limited quantity if you want to find them used. If you only need a pair of DWDM optics you're probably fine to find a used or third party XENPAK to meet your needs, and this will be the cheapest option. If you actually have to buy these things in any kind of quantity (i.e. hundreds+) you're probably going to want to go XFP purely for availability and lead time. Your best (or atleast cheapest, but I can't say anything bad about them other than they don't do FEC like some similar higher priced/lower density converters) bet if you need an external converter to run DWDM XFP line side and LR client side is the MRV 2XFP repeater in a Fiber Driver chassis. http://www.mrv.com/datasheets/FD/PDF300/MRV-FD-2XFP_HI.pdf -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From wyatt.eliasson at gmail.com Tue Oct 20 12:23:04 2009 From: wyatt.eliasson at gmail.com (Wyatt Mattias Gyllenvarg) Date: Tue, 20 Oct 2009 18:23:04 +0200 Subject: [c-nsp] Multicast trickery Message-ID: <994752fe0910200923gbccf016wb523d183252993c3@mail.gmail.com> Hi All I am in need of pointers regarding a multicast configuration that does not fit the models found online or in the literature I have at hand. The network is built on PIM-SM with 2 BSR-RP routers (core1 and core2). At Core1 we receive a set of Multicast streams from IPTV-Provider 1 via PIM-SM and MSDP, this works fine. The mroutes are announced to Core2 via MSDP, works fine. At Core2 we receive a set of Multicasts that are flooded too us, this is the problem source. I can't distribute this in MSDP if I run PIM-SM. If I run PIM-DM they call me in a hurry and tell me that my PIM packets are disturbing the network. - So long I have not been able to filter out PIM packets with outbound acls on the SVI. I have used IP IGMP unidirectional... but that broke MSDP between the cores. Trying ip mroute gave me "invalid source address" How should I proceed too accept the multicast streams and inject them into MDSP. My hope is that I will get to a point where I can use MSDP between cores and ANYCAST my RPs. Best regards Mattias Gyllenvarg Omnitron Sweden From wyatt.eliasson at gmail.com Tue Oct 20 13:03:57 2009 From: wyatt.eliasson at gmail.com (Wyatt Mattias Gyllenvarg) Date: Tue, 20 Oct 2009 19:03:57 +0200 Subject: [c-nsp] Multicast trickery In-Reply-To: <8598977CC92EF44D8A167BB11C5ADB44010BE09C@SERVER01.winitu.local> References: <994752fe0910200923gbccf016wb523d183252993c3@mail.gmail.com> <8598977CC92EF44D8A167BB11C5ADB44010BE09C@SERVER01.winitu.local> Message-ID: <994752fe0910201003h7156bbdbo381862339efd5981@mail.gmail.com> Hi Hans I have set BSR-BORDER on the interface, so that should not be it. I want too run PIM-DM but as long as I send PIM-packets I can not. Anyone have a theory about the filter not biting? Im not at work now but it looks something like. Deny ip pim any any Deny ip any Permit any any Best regards Mattias Gyllenvarg 2009/10/20 Hans Verkerk : > Hi, > > " If I run PIM-DM they call me in a hurry and tell me that my PIM > packets are disturbing the network." Maybe your BSR packets are > interfering with SP2's network, so include "ip pim bsr-border" on > interface facing SP2. > > PIM DM sources can be distributed as follows into MSDP: > > http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_msdp > _im_pim_sm_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp105549 > 3 > > > HTH, > Hans > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Wyatt Mattias > Gyllenvarg > Sent: Tuesday, October 20, 2009 6:23 PM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] Multicast trickery > > Hi All > > I am in need of pointers regarding a multicast configuration that does > not fit the models found online or in the literature I have at hand. > > The network is built on PIM-SM with 2 BSR-RP routers (core1 and core2). > > At Core1 we receive a set of Multicast streams from IPTV-Provider 1 > via PIM-SM and MSDP, this works fine. > The mroutes are announced to Core2 via MSDP, works fine. > At Core2 we receive a set of Multicasts that are flooded too us, this > is the problem source. > > I can't distribute this in MSDP if I run PIM-SM. > If I run PIM-DM they call me in a hurry and tell me that my PIM > packets are disturbing the network. > ?- So long I have not been able to filter out PIM packets with > outbound acls on the SVI. > I have used IP IGMP unidirectional... ?but that broke MSDP between the > cores. > Trying ip mroute gave me "invalid source address" > > How should I proceed too accept the multicast streams and inject them > into MDSP. > > My hope is that I will get to a point where I can use MSDP between > cores and ANYCAST my RPs. > > Best regards > Mattias Gyllenvarg > Omnitron > Sweden > _______________________________________________ > cisco-nsp mailing list ?cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From rbf+cisco-nsp at panix.com Tue Oct 20 14:09:34 2009 From: rbf+cisco-nsp at panix.com (Brett Frankenberger) Date: Tue, 20 Oct 2009 13:09:34 -0500 Subject: [c-nsp] Inserting a default route into a MPLS/VPN pointing out of the VRF In-Reply-To: <4ADCDEF4.3060503@justinshore.com> References: <4ADCDEF4.3060503@justinshore.com> Message-ID: <20091020180934.GA11047@panix.com> On Mon, Oct 19, 2009 at 04:49:40PM -0500, Justin Shore wrote: > > I've come across route-leaking examples but they all require me to point > traffic to an outward-facing interface. Ie, I can't just point the > default route to a specific upstream-facing interface. Is there another > way? I can't see a solution with importing routes at the route-target > level. Can I point it to a loopback outside of the VRF? > > [ ... ] > > This is probably a simple process but I haven't had to do it before > without the FWSM which made it trivially easy. What simple solution > have I overlooked and will kick myself for missing later? Cisco has no support for: ip route vrf vrfX x.x.x.x/x next-hop next-hop vrfY where the traffic in vrfX matching that route would be sent over into vrfY (and then forwarded according to vryY's forwarding table). (Some other vendors can do that.) (In your case, you want "vrfY" to be "global", but that's not doable either.) The only clean way is to connect via an interface. For example, connect a cable from GIa/b to GIc/d and then configure: int GIa/b ip address x.x.x.1/30 int GIc/d ip vrf forwarding vrfX ip address x.x.x.2/30 ip route vrf vrfX 0.0.0.0/0 GIc/d x.x.x.1 (obviosuly I'm not using exact IOS commands above, but you get the idea.) On some platforms, this can be done with tunnels instead of physical interfaces to avoid using two physical ports and dealing with the risk that those ports might fail: int lo1 ip address z.z.z.10/32 int lo2 ip address x.x.x.20/32 int tun1 ip address x.x.x.1/30 tunnel source lo1 tunnel destination x.x.x.20 int tun2 ip vrf forwarding vrfX ip address x.x.x.2/30 tunnel source lo2 tunnel destination x.x.x.20 ip route vrf vrfX 0.0.0.0/0 tun2 How well this works depends on how tunnels are implemented on the platform you're using. It works fine on software-based routers. ASR1000s worked OK in my testing. Never tried 6500/7600s. Note that the suggestion to leak default from your global table into the VRF potentially fails on two accounts. First, you might or might not have a default in your global table. Second, if you do, leaking that would direct all internet traffic to follow the default route, and, assuming you have default plus a lot of more other routes in your global table, you wouldn't want traffic covered by a more-specific in the global table to follow the default if it originated in vrfX. That is, with a global table of: 100.0.0.0/8 -> A 0.0.0.0/0 -> B if you import only 0.0.0.0/0 into a vrf, then all traffic matching the default in that VRF will be sent to B, even traffic traffic to 100.0.0.0/8. -- Brett From kgraham at industrial-marshmallow.com Tue Oct 20 14:51:35 2009 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Tue, 20 Oct 2009 11:51:35 -0700 (PDT) Subject: [c-nsp] Bonded T1 Circuits In-Reply-To: <4ADDDEE6.3030804@rollernet.us> References: <00b901ca5196$c6abe9e0$d400a8c0@dominic> <6B8401A83219DF499C34DEAEE9A5999219FC13ED86@XBOX.midlandpaper.com> <4ADDDEE6.3030804@rollernet.us> Message-ID: <908402.20676.qm@web507.biz.mail.mud.yahoo.com> > You could do 8 if you use four VWIC-2MFT-T1 cards, which is pretty much > as high as you'd ever want to go with MLPPP. With the major caveat that the clock is shared between both ports on a the VWIC. Even knowing this, it has still bitten us when originally identical T1's got groomed onto different upstream circuits. HWIC-4T1/E1 doesn't have this limitation, but is only supported on the 2821 and up. From billbuhlman at yahoo.com Tue Oct 20 14:56:15 2009 From: billbuhlman at yahoo.com (Bill Buhlman) Date: Tue, 20 Oct 2009 11:56:15 -0700 (PDT) Subject: [c-nsp] Bonded T1 Circuits In-Reply-To: <00b901ca5196$c6abe9e0$d400a8c0@dominic> Message-ID: <479640.4974.qm@web43141.mail.sp1.yahoo.com> MLPPP working config below. Do the same thing on the remote router ie:create multilink interface with IP address and add DS1 interfaces to multilink group ? interface Multilink1 ?description Orinda bundle DS3 channels 11,18,12 ?ip address xxx.xxx.x.177 255.255.255.252 ?ip flow ingress ?ppp multilink ?multilink-group 1 ?service-policy output MLPPP-4.6 ? interface Serial1/0/0/11:0 ?description Orinda #1 Circuit ID xxxx-001PT ?no ip address ?encapsulation ppp ?ppp multilink ?multilink-group 1 ! interface Serial1/0/0/12:0 ?description Link to Orinda #3 CID xxx-001PT ?no ip address ?encapsulation ppp ?ppp multilink ?multilink-group 1 interface Serial1/0/0/18:0 ?description Orinda USD #2 Circuit ID xxx-001PT ?no ip address ?encapsulation ppp ?ppp multilink ?multilink-group 1 --- On Tue, 10/20/09, Dominic wrote: From: Dominic Subject: [c-nsp] Bonded T1 Circuits To: cisco-nsp at puck.nether.net Date: Tuesday, October 20, 2009, 8:05 AM Hi Everyone: Two questions: 1. I need to bond two T1 circuits. Does anyone have a working sample config? The POP end is a 7206VXR with NPE-G2 and the PA-MC-2T3-EC Card, and the customer end is a Cisco 1841. 2. Also need to bond as many as 4 T1s.? Would that be pushing it, and what would generally be the cleanest way to do it? Dominic _______________________________________________ cisco-nsp mailing list? cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From blahu77 at gmail.com Tue Oct 20 15:45:59 2009 From: blahu77 at gmail.com (Mateusz Blaszczyk) Date: Tue, 20 Oct 2009 20:45:59 +0100 Subject: [c-nsp] Multicast trickery In-Reply-To: <994752fe0910201003h7156bbdbo381862339efd5981@mail.gmail.com> References: <994752fe0910200923gbccf016wb523d183252993c3@mail.gmail.com> <8598977CC92EF44D8A167BB11C5ADB44010BE09C@SERVER01.winitu.local> <994752fe0910201003h7156bbdbo381862339efd5981@mail.gmail.com> Message-ID: <383357750910201245i16efba5cyb3e8d00b72511a1e@mail.gmail.com> Wyatt, > I have set BSR-BORDER on the interface, so that should not be it. > > I want too run PIM-DM but as long as I send PIM-packets I can not. > > Anyone have a theory about the filter not biting? how about ip multicast boundary and blocking ALL-PIM-ROUTERS 224.0.0.13 and allowing all other groups from another SP? Best Regards, -mat From paul.cosgrove.nsp at gmail.com Tue Oct 20 15:55:15 2009 From: paul.cosgrove.nsp at gmail.com (Paul Cosgrove) Date: Tue, 20 Oct 2009 20:55:15 +0100 Subject: [c-nsp] Multicast trickery In-Reply-To: <994752fe0910201003h7156bbdbo381862339efd5981@mail.gmail.com> References: <994752fe0910200923gbccf016wb523d183252993c3@mail.gmail.com> <8598977CC92EF44D8A167BB11C5ADB44010BE09C@SERVER01.winitu.local> <994752fe0910201003h7156bbdbo381862339efd5981@mail.gmail.com> Message-ID: <73636ae00910201255m4dead2a1l23691d00c53debf@mail.gmail.com> Hi Mattias If I understand your topology correctly, the configuration should be very similar to what you would use for any other internal source. The difference in this case that the source in this case is the provider network, and being untrusted requires additional precautions on the input interface (only). Considering a conventional Anycast RP multicast topology for a moment, when the multicast packets are received by the DR, the DR encapsulates the packets as unicast register messages and sends them to the nearest RP for that group. The RP effectively converts the first register messages to a source active message, and then sends the SA to each configured MSDP peer. In this example the SA is originated because a register messages has been received for a new source. The register message is sent to that router because it is a active RP for the group. Since you are using BSR you have only one active RP for each group, and is may be important which that is in this case. Is your second C-RP is the active RP for the group you are having problems with? Tested a topology with a combined DR and RP, some years ago. It may work if you run PIM-SM and the RP is the DR for the subnet, but if I recall correctly, behaviour differed between different routers/software versions and it did not work well/often. You should be able to test this easily enough by debugging msdp and pinging an unused multicast group from a router connected to your RP. With pim-sm enabled on the RP's input interface, and the RP elected as DR, you may still find that no SA is originated. You could try to persuade your second provider to provide MSDP and BGP information, but I guess you have already tried that approach. Alternatively attach another router to your RP and have the provider present the multicast stream on that. As well as the bsr boundary, and acls to stop pim (inc unicast pim), make sure you have pim register rate-limit applied. You must also make sure that traffic to the auto rp groups is not permitted into your network. IP multicast boundary is useful. The method in the link that Hans provided should also work, though I would think it wise to test in a lab first if you are thinking of applying it to one of your main C-RP routers; or apply it on another router entirely. The acl you mentioned will not stop multicast packets sent by the router on which it is applied, and that is likely to be why multicast traffic is still leaking through. If this router is the RP for a particular multicast group, when one of your sources begins sending to a group, the first packet the RP router receives is as a unicast register message, which it decapsulates before transmission. The path of the packet through the router is not the same as for native multicast, since it is unicast to the RP and has to be punted to the CPU; it may be that these decapsulated packets are not being filtered. If you have static RP definitions anywhere in your network, traffic to groups without a configured RP might also be leaking out. IP multicast boundary may help. You mentioned Anycast-RP, and using that with static RP definitions is quite straightforward to configure and maintain, perhaps easier than you think. Paul. On Tue, Oct 20, 2009 at 6:03 PM, Wyatt Mattias Gyllenvarg < wyatt.eliasson at gmail.com> wrote: > Hi Hans > > I have set BSR-BORDER on the interface, so that should not be it. > > I want too run PIM-DM but as long as I send PIM-packets I can not. > > Anyone have a theory about the filter not biting? > Im not at work now but it looks something like. > Deny ip pim any any > Deny ip any > Permit any any > > Best regards > Mattias Gyllenvarg > > 2009/10/20 Hans Verkerk : > > Hi, > > > > " If I run PIM-DM they call me in a hurry and tell me that my PIM > > packets are disturbing the network." Maybe your BSR packets are > > interfering with SP2's network, so include "ip pim bsr-border" on > > interface facing SP2. > > > > PIM DM sources can be distributed as follows into MSDP: > > > > http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_msdp > > _im_pim_sm_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp105549 > > 3 > > > > > > HTH, > > Hans > > > > -----Original Message----- > > From: cisco-nsp-bounces at puck.nether.net > > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Wyatt Mattias > > Gyllenvarg > > Sent: Tuesday, October 20, 2009 6:23 PM > > To: cisco-nsp at puck.nether.net > > Subject: [c-nsp] Multicast trickery > > > > Hi All > > > > I am in need of pointers regarding a multicast configuration that does > > not fit the models found online or in the literature I have at hand. > > > > The network is built on PIM-SM with 2 BSR-RP routers (core1 and core2). > > > > At Core1 we receive a set of Multicast streams from IPTV-Provider 1 > > via PIM-SM and MSDP, this works fine. > > The mroutes are announced to Core2 via MSDP, works fine. > > At Core2 we receive a set of Multicasts that are flooded too us, this > > is the problem source. > > > > I can't distribute this in MSDP if I run PIM-SM. > > If I run PIM-DM they call me in a hurry and tell me that my PIM > > packets are disturbing the network. > > - So long I have not been able to filter out PIM packets with > > outbound acls on the SVI. > > I have used IP IGMP unidirectional... but that broke MSDP between the > > cores. > > Trying ip mroute gave me "invalid source address" > > > > How should I proceed too accept the multicast streams and inject them > > into MDSP. > > > > My hope is that I will get to a point where I can use MSDP between > > cores and ANYCAST my RPs. > > > > Best regards > > Mattias Gyllenvarg > > Omnitron > > Sweden > > _______________________________________________ > > cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From Jeff.Wojciechowski at midlandpaper.com Tue Oct 20 15:57:46 2009 From: Jeff.Wojciechowski at midlandpaper.com (Jeff Wojciechowski) Date: Tue, 20 Oct 2009 14:57:46 -0500 Subject: [c-nsp] ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS Message-ID: <6B8401A83219DF499C34DEAEE9A5999219FC13EDDE@XBOX.midlandpaper.com> Hi All, Has anyone gotten ASA based VPN (soft clients) to work with Windows 2008 NPS - AD Integrated RADIUS to work? As our engineer put it: "Cisco does not have a document for authentication configuration with Windows 2008. Since they say the ASA configuration looks fine they have washed their hands of it and want to close the case." I can see this in the logs on our AD server: Contact the Network Policy Server administrator for more information. User: Security ID: NULL SID Account Name: %domain\username% Account Domain: - Fully Qualified Account Name: - Client Machine: Security ID: NULL SID Account Name: - Fully Qualified Account Name: - OS-Version: - Called Station Identifier: %some ip address% Calling Station Identifier: %some originating ip address% NAS: NAS IPv4 Address: %ip of server% NAS IPv6 Address: - NAS Identifier: - NAS Port-Type: Virtual NAS Port: 159744 RADIUS Client: Client Friendly Name: whl_vpn_new Client IP Address: %ip address of client% Authentication Details: Proxy Policy Name: - Network Policy Name: - Authentication Provider: - Authentication Server: %fqdn of server% Authentication Type: - EAP Type: - Account Session Identifier: - Reason Code: 49 Reason: The connection attempt did not match any connection request policy. If this has been asked and answered (or if there is a better forum for this), I apologize. If someone could nudge me in the right direction that would be very awesome. Technet for the above error is pretty pointless as usual.... Thanks again, -Jeff From tvarriale at comcast.net Tue Oct 20 16:29:15 2009 From: tvarriale at comcast.net (Tony Varriale) Date: Tue, 20 Oct 2009 15:29:15 -0500 Subject: [c-nsp] Bonded T1 Circuits References: <00b901ca5196$c6abe9e0$d400a8c0@dominic> Message-ID: Looks like I'm late to the game but I would recommend MLPPP. Note the EC card has the MLPPP offload so I would stick with those. The only thing to be aware of is always turn off frag (I believe you have received config examples of this). http://www.cisco.com/en/US/prod/collateral/modules/ps2033/prod_white_paper0900aecd8056d3cb.html tv ----- Original Message ----- From: "Dominic" To: Sent: Tuesday, October 20, 2009 10:05 AM Subject: [c-nsp] Bonded T1 Circuits > Hi Everyone: > > Two questions: > > 1. I need to bond two T1 circuits. Does anyone have a working sample > config? The POP end is a 7206VXR with NPE-G2 and the PA-MC-2T3-EC Card, > and the customer end is a Cisco 1841. > 2. Also need to bond as many as 4 T1s. Would that be pushing it, and what > would generally be the cleanest way to do it? > > > Dominic > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From justin at justinshore.com Tue Oct 20 16:31:13 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 20 Oct 2009 15:31:13 -0500 Subject: [c-nsp] Inserting a default route into a MPLS/VPN pointing out of the VRF In-Reply-To: <39509708-F402-46C0-8E15-E238B1BB2B22@gmail.com> References: <4ADCDEF4.3060503@justinshore.com> <39509708-F402-46C0-8E15-E238B1BB2B22@gmail.com> Message-ID: <4ADE1E11.4070205@justinshore.com> Phil Bedard wrote: > If you are already using a VRF to carry the default table you should be > able to import a default route from that vrf into your customer vrf. > You can use an import-map to select only the default. The only time > I've implemented something similar to this I've used external firewalls > which have their own trusted sub-int into the customer network and their > untrust side connected to an Internet router. Similar to what you say > you are doing on the datacenter side. You could do the same thing > without a firewall, just need a dedicated trunk so you can bridge > between the default VRF/global table and the customer VRF. Then just > static routes out that interface. Thanks to all the replies. I didn't word my initial message very well. My Internet tables are in the default VRF (ie, the global VRF). I don't carry around Inet tables in dedicated VRFs (though I've been told by some that this is a good idea). My FWSMs provided me the same functionality as your external FWs. Unfortunately this is for raw, unfiltered and unprotected customer Internet access. I suppose a different technique would be to take these special customers and use routing to push traffic destined for the special peering network into that dedicated VRF and keep all their other traffic in the default VRF. While I can say that I can't envision a way to accomplish that. I think it's easier to start in the dedicated VRF and leak traffic out of it. I thought of a couple possible solutions last night. One was the use of the 'global' statement in the default route inside the VRF. It has the same problems as the static route to an interface. I want the core Ps to make a routing decision on the upstream exit point which I can't do if I'm setting the next-hop to be an IP on an upstream router or an interface facing an upstream router. The other option I thought of was to not inject the default on the core Ps but instead do it on PE1, the peering router to this special network. Ultimately PE1 will be dual-homed to P1 and P2. I could then set the next-hop for the default in the VRF on PE1 to be a FHRP floater on P1 and P2 and use that as the global IP. I think that would work too but haven't tried it. Another c-nsp reader gave me what I think will most likely be my solution. His suggestion was to use an import map on the VRD, a route-map and prefix-list to import a default route into the VRF that way. I'm sure that will work. I'm intrigued by the tunnel solutions too. PE1 will be replaced with an ASR in a few months so I may give that a try as well. It's good to know all the various ways to accomplish the goal in case I have to implement something different someday. Thanks for all the suggestions Justin From justin at justinshore.com Tue Oct 20 16:41:55 2009 From: justin at justinshore.com (Justin Shore) Date: Tue, 20 Oct 2009 15:41:55 -0500 Subject: [c-nsp] Inserting a default route into a MPLS/VPN pointing out of the VRF In-Reply-To: <20091020180934.GA11047@panix.com> References: <4ADCDEF4.3060503@justinshore.com> <20091020180934.GA11047@panix.com> Message-ID: <4ADE2093.9000403@justinshore.com> Brett Frankenberger wrote: > Cisco has no support for: > ip route vrf vrfX x.x.x.x/x next-hop next-hop vrfY > where the traffic in vrfX matching that route would be sent over into vrfY > (and then forwarded according to vryY's forwarding table). (Some other > vendors can do that.) (In your case, you want "vrfY" to be "global", > but that's not doable either.) I cracked open my MPLS books last night and found a similar solution with an IP next-hop in the MPLS & VPN Arch book. It set the next-hop to be an IP in the global VRF by using the 'global' keyword. ip default vrf VRFx 0.0.0.0 0.0.0.0 1.2.3.4 global It has the same problems as the other solution I found for setting the next-hop to be an exit interface. I want the Ps to make a routing decision to determine the exit path for the packet, not hardcode it to go one way or another (and possibly have a iBGP-meshed BR1 decide that the better exit point would be another BR and route that back to the core P to get to BR2. This is why I was wondering if the target interface or IP could be a loopback on the Ps. I really need to lab these ideas. > The only clean way is to connect via an interface. For example, > connect a cable from GIa/b to GIc/d and then configure: > int GIa/b > ip address x.x.x.1/30 > int GIc/d > ip vrf forwarding vrfX > ip address x.x.x.2/30 > ip route vrf vrfX 0.0.0.0/0 GIc/d x.x.x.1 > (obviosuly I'm not using exact IOS commands above, but you get the > idea.) I thought about that and I could do that. It's an added expense though. > On some platforms, this can be done with tunnels instead of physical > interfaces to avoid using two physical ports and dealing with the risk > that those ports might fail: > int lo1 > ip address z.z.z.10/32 > int lo2 > ip address x.x.x.20/32 > int tun1 > ip address x.x.x.1/30 > tunnel source lo1 > tunnel destination x.x.x.20 > int tun2 > ip vrf forwarding vrfX > ip address x.x.x.2/30 > tunnel source lo2 > tunnel destination x.x.x.20 > ip route vrf vrfX 0.0.0.0/0 tun2 > How well this works depends on how tunnels are implemented on the > platform you're using. It works fine on software-based routers. > ASR1000s worked OK in my testing. Never tried 6500/7600s. This is a thought. I haven't tried it on 7600s either but it's worth trying to see if it would work. > Note that the suggestion to leak default from your global table into > the VRF potentially fails on two accounts. First, you might or might > not have a default in your global table. Second, if you do, leaking > that would direct all internet traffic to follow the default route, > and, assuming you have default plus a lot of more other routes in your > global table, you wouldn't want traffic covered by a more-specific in > the global table to follow the default if it originated in vrfX. That > is, with a global table of: > 100.0.0.0/8 -> A > 0.0.0.0/0 -> B > if you import only 0.0.0.0/0 into a vrf, then all traffic matching the > default in that VRF will be sent to B, even traffic traffic to > 100.0.0.0/8. I originate a default in my IGP on each BR currently. I'm thinking about moving that into iBGP though. I'll originate a default on the Ps in the VRF with MP-iBGP. This touches on the problem I outlined above talking about the Ps making the decision on exit path. My Ps are part of the iBGP mesh with full tables from the BRs. In theory they should make the same routing decision for a given packet that a BR will do when it receives that same packet milliseconds later. I'm going to try the importing of the default in the VRF statement. I think that will work but I'll find out for sure with my testing. If it doesn't then I may have to try the tunneling solution. I may have to settle for inefficient routing for a few months until the ASR comes in and then do tunnels on it. Either way I think I'm on the right track. Thanks for the insight Justin From eriks at nationalfastfreight.com Tue Oct 20 16:13:43 2009 From: eriks at nationalfastfreight.com (Erik Soosalu) Date: Tue, 20 Oct 2009 16:13:43 -0400 Subject: [c-nsp] ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS In-Reply-To: <6B8401A83219DF499C34DEAEE9A5999219FC13EDDE@XBOX.midlandpaper.com> References: <6B8401A83219DF499C34DEAEE9A5999219FC13EDDE@XBOX.midlandpaper.com> Message-ID: <0B224A2FE01CC54C860290D42474BF6003F9BFBD@exchange.nff.local> With a 5510 we are using 2008 NPS for AD auth. Do you have something under you Connection Request Policy? The log seems to be telling you that there is something missing there. Thanks, Erik -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Wojciechowski Sent: Tuesday, October 20, 2009 3:58 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS Hi All, Has anyone gotten ASA based VPN (soft clients) to work with Windows 2008 NPS - AD Integrated RADIUS to work? As our engineer put it: "Cisco does not have a document for authentication configuration with Windows 2008. Since they say the ASA configuration looks fine they have washed their hands of it and want to close the case." I can see this in the logs on our AD server: Contact the Network Policy Server administrator for more information. User: Security ID: NULL SID Account Name: %domain\username% Account Domain: - Fully Qualified Account Name: - Client Machine: Security ID: NULL SID Account Name: - Fully Qualified Account Name: - OS-Version: - Called Station Identifier: %some ip address% Calling Station Identifier: %some originating ip address% NAS: NAS IPv4 Address: %ip of server% NAS IPv6 Address: - NAS Identifier: - NAS Port-Type: Virtual NAS Port: 159744 RADIUS Client: Client Friendly Name: whl_vpn_new Client IP Address: %ip address of client% Authentication Details: Proxy Policy Name: - Network Policy Name: - Authentication Provider: - Authentication Server: %fqdn of server% Authentication Type: - EAP Type: - Account Session Identifier: - Reason Code: 49 Reason: The connection attempt did not match any connection request policy. If this has been asked and answered (or if there is a better forum for this), I apologize. If someone could nudge me in the right direction that would be very awesome. Technet for the above error is pretty pointless as usual.... Thanks again, -Jeff _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From onamrubio at hotmail.com Tue Oct 20 17:02:10 2009 From: onamrubio at hotmail.com (Onam Rubio) Date: Tue, 20 Oct 2009 15:02:10 -0600 Subject: [c-nsp] 802.1ad 4PortsWIC 1751 Message-ID: Hello experts, I need to know if a 4PortsWIC support 802.1ad(ethertype 0x88a8) to connect one of it's ports as a trunk to an Extreme summit 48si. Cisco1751(4PortsWIC_Port1 as a Trunk)<------------>(Port1 as a Trunk)Extrme Summit 48si I connected a PC to each side of the topology and don't see each other trough the VMAN. Best regards. _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us From egirard at focustsi.com Tue Oct 20 16:32:20 2009 From: egirard at focustsi.com (Eric Girard) Date: Tue, 20 Oct 2009 16:32:20 -0400 Subject: [c-nsp] ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS In-Reply-To: <6B8401A83219DF499C34DEAEE9A5999219FC13EDDE@XBOX.midlandpaper.com> References: <6B8401A83219DF499C34DEAEE9A5999219FC13EDDE@XBOX.midlandpaper.com> Message-ID: Jeff, I've done several VPN setups with 2008 NPS, and from what I remember offhand they were no different than the 'old' IAS. Some of the items might have moved around a bit in the GUI, but the basic IAS functionality is still there. From the error message, I would look at the connection policies, because if I am remembering correctly the default is not very useful and needs to be changed. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Wojciechowski Sent: Tuesday, October 20, 2009 3:58 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS Hi All, Has anyone gotten ASA based VPN (soft clients) to work with Windows 2008 NPS - AD Integrated RADIUS to work? As our engineer put it: "Cisco does not have a document for authentication configuration with Windows 2008. Since they say the ASA configuration looks fine they have washed their hands of it and want to close the case." I can see this in the logs on our AD server: Contact the Network Policy Server administrator for more information. User: Security ID: NULL SID Account Name: %domain\username% Account Domain: - Fully Qualified Account Name: - Client Machine: Security ID: NULL SID Account Name: - Fully Qualified Account Name: - OS-Version: - Called Station Identifier: %some ip address% Calling Station Identifier: %some originating ip address% NAS: NAS IPv4 Address: %ip of server% NAS IPv6 Address: - NAS Identifier: - NAS Port-Type: Virtual NAS Port: 159744 RADIUS Client: Client Friendly Name: whl_vpn_new Client IP Address: %ip address of client% Authentication Details: Proxy Policy Name: - Network Policy Name: - Authentication Provider: - Authentication Server: %fqdn of server% Authentication Type: - EAP Type: - Account Session Identifier: - Reason Code: 49 Reason: The connection attempt did not match any connection request policy. If this has been asked and answered (or if there is a better forum for this), I apologize. If someone could nudge me in the right direction that would be very awesome. Technet for the above error is pretty pointless as usual.... Thanks again, -Jeff _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From walter.keen at RainierConnect.net Tue Oct 20 17:13:49 2009 From: walter.keen at RainierConnect.net (Walter Keen) Date: Tue, 20 Oct 2009 14:13:49 -0700 Subject: [c-nsp] Router reccomendation Message-ID: <4ADE280D.2080700@rainierconnect.net> I'm looking for a box that can take in a gigabit connection, which will have 6 sites remotely connected each at 100mbit. It's likely that near full rate will be desired on the remote sites in this hub/spoke design. The customer has some 3750's and 2800 series routers, but I am looking to see if anyone has a recommendation on the 3750's passing 100mbit (routed) and something for a main site router that could aggregate 600mbit or more. From Jeff.Wojciechowski at midlandpaper.com Tue Oct 20 17:16:53 2009 From: Jeff.Wojciechowski at midlandpaper.com (Jeff Wojciechowski) Date: Tue, 20 Oct 2009 16:16:53 -0500 Subject: [c-nsp] FW: ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS Message-ID: <6B8401A83219DF499C34DEAEE9A5999219FC13EDF7@XBOX.midlandpaper.com> Its Windows....try restarting NPS Service :) Thanks to the off-list responses! -Jeff -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Wojciechowski Sent: Tuesday, October 20, 2009 2:58 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS Hi All, Has anyone gotten ASA based VPN (soft clients) to work with Windows 2008 NPS - AD Integrated RADIUS to work? As our engineer put it: "Cisco does not have a document for authentication configuration with Windows 2008. Since they say the ASA configuration looks fine they have washed their hands of it and want to close the case." I can see this in the logs on our AD server: Contact the Network Policy Server administrator for more information. User: Security ID: NULL SID Account Name: %domain\username% Account Domain: - Fully Qualified Account Name: - Client Machine: Security ID: NULL SID Account Name: - Fully Qualified Account Name: - OS-Version: - Called Station Identifier: %some ip address% Calling Station Identifier: %some originating ip address% NAS: NAS IPv4 Address: %ip of server% NAS IPv6 Address: - NAS Identifier: - NAS Port-Type: Virtual NAS Port: 159744 RADIUS Client: Client Friendly Name: whl_vpn_new Client IP Address: %ip address of client% Authentication Details: Proxy Policy Name: - Network Policy Name: - Authentication Provider: - Authentication Server: %fqdn of server% Authentication Type: - EAP Type: - Account Session Identifier: - Reason Code: 49 Reason: The connection attempt did not match any connection request policy. If this has been asked and answered (or if there is a better forum for this), I apologize. If someone could nudge me in the right direction that would be very awesome. Technet for the above error is pretty pointless as usual.... Thanks again, -Jeff _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From gsgranados at comcast.net Tue Oct 20 17:29:10 2009 From: gsgranados at comcast.net (Scott Granados) Date: Tue, 20 Oct 2009 14:29:10 -0700 Subject: [c-nsp] FW: ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS References: <6B8401A83219DF499C34DEAEE9A5999219FC13EDF7@XBOX.midlandpaper.com> Message-ID: <023901ca51cc$629b65d0$2008120a@am.thmulti.com> Oh God, Winders in the authorization chain. Clearly someone doesn't like sleeping well.;) The only thing I've seen more frightening than that is an entirely Windows NT 4.0 based heart care environment where the review stations would crash when the Fore ATM adapters took more than 50 megabits of traffic. (Sorry sir, we'd be working on your heart attack and trying to do some imaging here but we've bluescreened, can you hold?) ----- Original Message ----- From: "Jeff Wojciechowski" To: Sent: Tuesday, October 20, 2009 2:16 PM Subject: [c-nsp] FW: ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS > Its Windows....try restarting NPS Service :) > > Thanks to the off-list responses! > > -Jeff > > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Wojciechowski > Sent: Tuesday, October 20, 2009 2:58 PM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS > > Hi All, > > Has anyone gotten ASA based VPN (soft clients) to work with Windows 2008 > NPS - AD Integrated RADIUS to work? > > As our engineer put it: > > "Cisco does not have a document for authentication configuration with > Windows 2008. Since they say the ASA configuration looks fine they have > washed their hands of it and want to close the case." > > > I can see this in the logs on our AD server: > > Contact the Network Policy Server administrator for more information. > > User: > Security ID: > NULL SID > Account Name: > %domain\username% > Account Domain: - > Fully Qualified Account Name: - > > Client Machine: > Security ID: > NULL SID > Account Name: - > Fully Qualified Account Name: - > OS-Version: - > Called Station Identifier: %some ip > address% > Calling Station Identifier: %some > originating ip address% > > NAS: > NAS IPv4 Address: %ip of > server% > NAS IPv6 Address: - > NAS Identifier: - > NAS Port-Type: Virtual > NAS Port: > 159744 > > RADIUS Client: > Client Friendly Name: whl_vpn_new > Client IP Address: %ip > address of client% > > Authentication Details: > Proxy Policy Name: - > Network Policy Name: - > Authentication Provider: - > Authentication Server: %fqdn of > server% > Authentication Type: - > EAP Type: - > Account Session Identifier: - > Reason Code: 49 > Reason: > The connection attempt did not match any connection request policy. > > If this has been asked and answered (or if there is a better forum for > this), I apologize. If someone could nudge me in the right direction that > would be very awesome. Technet for the above error is pretty pointless as > usual.... > > Thanks again, > > -Jeff > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From dean at eatworms.org.uk Tue Oct 20 17:51:23 2009 From: dean at eatworms.org.uk (Dean Smith) Date: Tue, 20 Oct 2009 22:51:23 +0100 Subject: [c-nsp] Router reccomendation In-Reply-To: <4ADE280D.2080700@rainierconnect.net> References: <4ADE280D.2080700@rainierconnect.net> Message-ID: <006e01ca51cf$77d52d20$677f8760$@org.uk> Being switched based the 3750 will do 100Mbit easily. Its software features its lacks and has limited route table size. For your head end router, 600Mb/s is at the tope end of what you should expect from a 7201/7200 NPE-G2. Certainly if you wanted QoS you couldn't do it. So if you have basic feature requirements only then you could look at another 3750 (or any of the larger switches - 4500,4900,6500). If you want a router rather than a L3 Switch, then you're looking at an ASR1002 ESP5. Dean -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Walter Keen Sent: 20 October 2009 22:14 To: 'Cisco-nsp' Subject: [c-nsp] Router reccomendation I'm looking for a box that can take in a gigabit connection, which will have 6 sites remotely connected each at 100mbit. It's likely that near full rate will be desired on the remote sites in this hub/spoke design. The customer has some 3750's and 2800 series routers, but I am looking to see if anyone has a recommendation on the 3750's passing 100mbit (routed) and something for a main site router that could aggregate 600mbit or more. _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From rsm at fast-serv.com Tue Oct 20 18:10:10 2009 From: rsm at fast-serv.com (Randy McAnally) Date: Tue, 20 Oct 2009 18:10:10 -0400 Subject: [c-nsp] Router reccomendation In-Reply-To: <4ADE280D.2080700@rainierconnect.net> References: <4ADE280D.2080700@rainierconnect.net> Message-ID: <20091020220801.M25368@fast-serv.com> I've routed over a gigabit with a 3750 switch taking limited BGP tables. It will meet your throughput needs fine as long as you don't need large BGP tables or fancy features. -- Randy ---------- Original Message ----------- From: Walter Keen To: "'Cisco-nsp'" Sent: Tue, 20 Oct 2009 14:13:49 -0700 Subject: [c-nsp] Router reccomendation > I'm looking for a box that can take in a gigabit connection, which > will have 6 sites remotely connected each at 100mbit. It's likely > that near full rate will be desired on the remote sites in this > hub/spoke design. The customer has some 3750's and 2800 series > routers, but I am looking to see if anyone has a recommendation on > the 3750's passing 100mbit > (routed) and something for a main site router that could aggregate > 600mbit or more. _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp archive at > http://puck.nether.net/pipermail/cisco-nsp/ ------- End of Original Message ------- From tvarriale at comcast.net Tue Oct 20 19:22:29 2009 From: tvarriale at comcast.net (Tony Varriale) Date: Tue, 20 Oct 2009 18:22:29 -0500 Subject: [c-nsp] DWDM optics on 6500s References: <5A69C25361FED34F83ABF05F50475245072BC100@wally.walleyetrading.net><4ACA0B77.5090106@inex.ie><200910060541.19686.mtinka@globaltransit.net><4ADC5092.7040905@inex.ie><828027.91138.qm@web508.biz.mail.mud.yahoo.com><290EF89F13F04F4E924BB235A46D18F1043B2BA143@MLBMXUS2.cs.myharris.net> <64A2673D120E4B408424519469A78A6C@flamdt01> <290EF89F13F04F4E924BB235A46D18F1043B41E802@MLBMXUS2.cs.myharris.net> Message-ID: <32FF6544707C450D9DDCFEDBC6F21F4C@flamdt01> Yup! No 80g cards yet. I haven't been debriefed on the architecture but I'm assuming it is going to be 2 x 40g or 4 x 20g backplane lanes. tv ----- Original Message ----- From: "Church, Charles" To: "Tony Varriale" ; Sent: Tuesday, October 20, 2009 9:14 AM Subject: RE: [c-nsp] DWDM optics on 6500s Thanks. I assume that even though the 6509-V-E is available, until the 80gig line cards and Sup are available, you'd be stuck at 40gig/slot? Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tony Varriale Sent: Monday, October 19, 2009 5:07 PM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] DWDM optics on 6500s It will shortly but it won't do you any good with the existing family of sups. The 2T will be the first (and last?) sup that can push the bandwidth to all those slots. You can also reference the 6509-V-E...it's ready for 80gbps/slot. You can order that today. Note that it's a NEBS chassis. tv ----- Original Message ----- From: "Church, Charles" To: "Kevin Graham" Cc: Sent: Monday, October 19, 2009 1:12 PM Subject: Re: [c-nsp] DWDM optics on 6500s > Are you saying a 6513-E chassis exists? I can't find any reference to it. > That would solve a few of the problems we currently have (density issue) > > Chuck > > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Kevin Graham > Sent: Monday, October 19, 2009 11:45 AM > To: Nick Hilliard; mtinka at globaltransit.net > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] DWDM optics on 6500s > > >> As a side issue, there are electrical limitations imposed by the physical > >> cross-bar unit inside the actual chassis, but I don't know how much of a >> problem >> these limitations are in practice. > > 6500E was the key for this. Besides nutty amounts of POE capacity, it also > picked up > improved backplane for >20g+ fabric and extending to all 11 LC slots in > the 6513. > > (Still need to dig up details, as faster SSO time is also tied to chassis, > though > I can't recall why). > _______________________________________________ > cisco-nsp mailing list cisco-nsp at 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 at 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 at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From wyatt.eliasson at gmail.com Wed Oct 21 03:41:25 2009 From: wyatt.eliasson at gmail.com (Wyatt Mattias Gyllenvarg) Date: Wed, 21 Oct 2009 09:41:25 +0200 Subject: [c-nsp] Multicast trickery In-Reply-To: <73636ae00910201255m4dead2a1l23691d00c53debf@mail.gmail.com> References: <994752fe0910200923gbccf016wb523d183252993c3@mail.gmail.com> <8598977CC92EF44D8A167BB11C5ADB44010BE09C@SERVER01.winitu.local> <994752fe0910201003h7156bbdbo381862339efd5981@mail.gmail.com> <73636ae00910201255m4dead2a1l23691d00c53debf@mail.gmail.com> Message-ID: <994752fe0910210041n5681fccao37c2f8bc3d5bce76@mail.gmail.com> Dear All Paul, thank you for your reply! I will test some of this today. What I am missing in my understanding of this is 2 major things. How would I get the SVI toward the flooding multicast provider to know what floods it is receiving? ip mroute? or does it learn when a certain packet is recieved? Perhaps I have not waited long enough? What would a static multicast route look like, all my attempts indicate that I don not understand how it works :p Best regards Mattias Gyllenvarg Omnitron 2009/10/20 Paul Cosgrove : > Hi Mattias > > If I understand your topology correctly, the configuration should be very > similar to what you would use for any other internal source.? The difference > in this case that the source in this case is the provider network, and being > untrusted requires additional precautions on the input interface (only). > > Considering a conventional Anycast RP multicast topology for a moment, when > the multicast packets are received by the DR, the DR encapsulates the > packets as unicast register messages and sends them to the nearest RP for > that group.? The RP effectively converts the first register messages to a > source active message, and then sends the SA to each configured MSDP peer. > In this example the SA is originated because a register messages has been > received for a new source.? The register message is sent to that router > because it is a active RP for the group. > > Since you are using BSR you have only one active RP for each group, and is > may be important which that is in this case.? Is your second C-RP is the > active RP for the group you are having problems with?? Tested a topology > with a combined DR and RP, some years ago. ? It may work if you run PIM-SM > and the RP is the DR for the subnet, but if I recall correctly, behaviour > differed between different routers/software versions and it did not work > well/often.? You should be able to test this easily enough by debugging msdp > and pinging an unused multicast group from a router connected to your RP. > With pim-sm enabled on the RP's input interface, and the RP elected as DR, > you may still find that no SA is originated. > > You could try to persuade your second provider to provide MSDP and BGP > information, but I guess you have already tried that approach. > Alternatively attach another router to your RP and have the provider present > the multicast stream on that.? As well as the bsr boundary, and acls to stop > pim (inc unicast pim), make sure you have pim register rate-limit applied. > You must also make sure that traffic to the auto rp groups is not permitted > into your network.? IP multicast boundary is useful. > > The method in the link that Hans provided should also work, though I would > think it wise to test in a lab first if you are thinking of applying it to > one of your main C-RP routers; or apply it on another router entirely.? The > acl you mentioned will not stop multicast packets sent by the router on > which it is applied, and that is likely to be why multicast traffic is still > leaking through.? If this router is the RP for a particular multicast group, > when one of your sources begins sending to a group, the first packet the RP > router receives is as a unicast register message, which it decapsulates > before transmission. The path of the packet through the router is not the > same as for native multicast, since it is unicast to the RP and has to be > punted to the CPU; it may be that these decapsulated packets are not being > filtered.? If you have static RP definitions anywhere in your network, > traffic to groups without a configured RP might also be leaking out.? IP > multicast boundary may help. > > You mentioned Anycast-RP, and using that with static RP definitions is quite > straightforward to configure and maintain, perhaps easier than you think. > > Paul. > > On Tue, Oct 20, 2009 at 6:03 PM, Wyatt Mattias Gyllenvarg > wrote: >> >> Hi Hans >> >> I have set BSR-BORDER on the interface, so that should not be it. >> >> I want too run PIM-DM but as long as I send PIM-packets I can not. >> >> Anyone have a theory about the filter not biting? >> Im not at work now but it looks something like. >> Deny ip pim any any >> Deny ip any >> Permit any any >> >> Best regards >> Mattias Gyllenvarg >> >> 2009/10/20 Hans Verkerk : >> > Hi, >> > >> > " If I run PIM-DM they call me in a hurry and tell me that my PIM >> > packets are disturbing the network." Maybe your BSR packets are >> > interfering with SP2's network, so include "ip pim bsr-border" on >> > interface facing SP2. >> > >> > PIM DM sources can be distributed as follows into MSDP: >> > >> > http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_msdp >> > _im_pim_sm_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp105549 >> > 3 >> > >> > >> > HTH, >> > Hans >> > >> > -----Original Message----- >> > From: cisco-nsp-bounces at puck.nether.net >> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Wyatt Mattias >> > Gyllenvarg >> > Sent: Tuesday, October 20, 2009 6:23 PM >> > To: cisco-nsp at puck.nether.net >> > Subject: [c-nsp] Multicast trickery >> > >> > Hi All >> > >> > I am in need of pointers regarding a multicast configuration that does >> > not fit the models found online or in the literature I have at hand. >> > >> > The network is built on PIM-SM with 2 BSR-RP routers (core1 and core2). >> > >> > At Core1 we receive a set of Multicast streams from IPTV-Provider 1 >> > via PIM-SM and MSDP, this works fine. >> > The mroutes are announced to Core2 via MSDP, works fine. >> > At Core2 we receive a set of Multicasts that are flooded too us, this >> > is the problem source. >> > >> > I can't distribute this in MSDP if I run PIM-SM. >> > If I run PIM-DM they call me in a hurry and tell me that my PIM >> > packets are disturbing the network. >> > ?- So long I have not been able to filter out PIM packets with >> > outbound acls on the SVI. >> > I have used IP IGMP unidirectional... ?but that broke MSDP between the >> > cores. >> > Trying ip mroute gave me "invalid source address" >> > >> > How should I proceed too accept the multicast streams and inject them >> > into MDSP. >> > >> > My hope is that I will get to a point where I can use MSDP between >> > cores and ANYCAST my RPs. >> > >> > Best regards >> > Mattias Gyllenvarg >> > Omnitron >> > Sweden >> > _______________________________________________ >> > cisco-nsp mailing list ?cisco-nsp at 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 at puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > > From vikassharmas at gmail.com Wed Oct 21 04:14:08 2009 From: vikassharmas at gmail.com (Vikas Sharma) Date: Wed, 21 Oct 2009 13:44:08 +0530 Subject: [c-nsp] Multicast on PPP Message-ID: Hi, Does anyone has implemented multicast over PPP interface? Since PPP does not support PIM, I am trying to use proxy-service and mroute-proxy. When I do join on dialer interface, I am able to ping the multicast ip (this confirms no issue in n/w wrt multicast). But when I join on LAN interface (removing igmp-join from dialer interface), it does no work, I am not able to ping the multicast IP from remote CE. Can anyone help me here? Regards, Vikas Sharma From zoe-nsp at complicity.co.uk Wed Oct 21 05:13:05 2009 From: zoe-nsp at complicity.co.uk (Zoe O'Connell) Date: Wed, 21 Oct 2009 10:13:05 +0100 Subject: [c-nsp] Multicast on PPP In-Reply-To: References: Message-ID: <4ADED0A1.2070308@complicity.co.uk> Vikas Sharma wrote: > Does anyone has implemented multicast over PPP interface? Since PPP > does not support PIM, I am trying to use proxy-service and > mroute-proxy. When I do join on dialer interface, I am able to ping > the multicast ip (this confirms no issue in n/w wrt multicast). But > when I join on LAN interface (removing igmp-join from dialer > interface), it does no work, I am not able to ping the multicast IP > from remote CE. > > Can anyone help me here? We have Multicast working quite happily over PPP/ADSL, it just needs "ip pim sparse-mode" and "ip pim bsm-border" on the appropriate virtual-template interface. (I would not recommend using dialer interfaces) From patrickg at layer8llc.com Wed Oct 21 19:26:46 2009 From: patrickg at layer8llc.com (Patrick J Greene) Date: Wed, 21 Oct 2009 19:26:46 -0400 Subject: [c-nsp] Circuit Management Software Message-ID: <4716E5BFA7B2514D84F8F8885F37799F192FE1D9C1@mse18be2.mse18.exchange.ms> Are there any "canned" packages out there to managed circuits, DID's, subnets, etc, etc? Thanks, Patrick Greene From jonas at bjorklund.cn Thu Oct 22 02:29:18 2009 From: jonas at bjorklund.cn (=?ISO-8859-1?Q?Jonas_Bj=F6rklund?=) Date: Thu, 22 Oct 2009 08:29:18 +0200 (CEST) Subject: [c-nsp] WS-X6148A-GE-TX not working with SUP2 Message-ID: Hello, I have a WS-X6148A-GE-TX thats inserted in a SUP2 but only get "Unknown" when I do "sh mod". The IOS is 12.1(27b)E4. 6500-1#sh mod Mod Ports Card Type Model Serial No. --- ----- -------------------------------------- ------------------ ----------- 1 2 Catalyst 6000 supervisor 2 (Active) WS-X6K-SUP2-2GE SAL10019MNG 2 2 Catalyst 6000 supervisor 2 (Standby) WS-X6K-SUP2-2GE SAD054204FA 4 16 SFM-capable 16 port 10/100/1000mb RJ45 WS-X6516-GE-TX SAL06447YCJ 5 16 SFM-capable 16 port 10/100/1000mb RJ45 WS-X6516-GE-TX SAD060101AF 6 48 Unknown Unknown Unknown 6500-1#sh power system power redundancy mode = redundant system power total = 1153.32 Watts (27.46 Amps @ 42V) system power used = 574.56 Watts (13.68 Amps @ 42V) system power available = 578.76 Watts (13.78 Amps @ 42V) The same WS-X6148A-GE-TX is working in another chassi with SUP720-3bxl. On the cisco website I can read that the line card should be supported in SUP2 with the IOS thats running. http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/hardware/Module_Installation/Mod_Install_Guide/02ethern.html#wp1042813 Any ideas? /Jonas From td_miles at yahoo.com Thu Oct 22 03:05:50 2009 From: td_miles at yahoo.com (Tony) Date: Thu, 22 Oct 2009 00:05:50 -0700 (PDT) Subject: [c-nsp] Inserting a default route into a MPLS/VPN pointing out of the VRF In-Reply-To: <4ADE2093.9000403@justinshore.com> Message-ID: <213710.73195.qm@web110113.mail.gq1.yahoo.com> --- On Wed, 21/10/09, Justin Shore wrote: > From: Justin Shore > Subject: Re: [c-nsp] Inserting a default route into a MPLS/VPN pointing out of the VRF > To: "Brett Frankenberger" > Cc: "'Cisco-nsp'" > Received: Wednesday, 21 October, 2009, 7:41 AM > Brett Frankenberger wrote: > > Cisco has no support for: > >? ? ip route vrf vrfX x.x.x.x/x next-hop > next-hop vrfY > > where the traffic in vrfX matching that route would be > sent over into vrfY > > (and then forwarded according to vryY's forwarding > table).? (Some other > > vendors can do that.)? (In your case, you want > "vrfY" to be "global", > > but that's not doable either.) > > > On some platforms, this can be done with tunnels > instead of physical > > interfaces to avoid using two physical ports and > dealing with the risk that those ports might fail: > >? ???int lo1 > >? ? ? ip address z.z.z.10/32 > >? ???int lo2 > >? ? ? ip address x.x.x.20/32 > >? ???int tun1 > >? ? ? ip address x.x.x.1/30 > >? ? ? tunnel source lo1 > >? ? ? tunnel destination x.x.x.20 > >? ???int tun2 > >? ? ? ip vrf forwarding vrfX > >? ? ? ip address x.x.x.2/30 > >? ? ? tunnel source lo2 > >? ? ? tunnel destination x.x.x.20 > >? ???ip route vrf vrfX 0.0.0.0/0 > tun2 How well this works depends on how tunnels are > implemented on the > > platform you're using.? It works fine on > software-based routers. ASR1000s worked OK in my testing. > Never tried 6500/7600s. > > This is a thought.? I haven't tried it on 7600s either > but it's worth trying to see if it would work. I tried this a couple of months ago on a 7609 with SRD1 and couldn't get it to work. The traffic couldn't/wouldn't go through the tunnels properly. After wresting with it on & off for about two weeks I ended up doing it using a variation on physical interfaces.. Because the 6500/7600 has the limitation of global VLAN significance across all LAN cards, you can't even use two ports on the same 7609 and just run a crossover trunk between them because the VLAN will be the "same" on both of the ports. We had to run a crossover cable trunk from one box to another and then put one end of the VLAN on first box into vrfX and the other end of the VLAN on second box into vrfY. It's horrible and I feel like I need to have a shower after every time I think about it, but it was the only solution that we could come up with that works without burning a lot of ports on the 7609 (two for each vrf cross connect). The only thing that calms me slightly is that it's only for a few Mbps of traffic for us and it won't be a huge setback if something dies and it stops working until we can fix it up. Before trying it on the 7600 I tested it with 7200 on dynamips and was able to get it working with tunnels on the same box after some fiddling around. I had to disable and re-enable ip route-cache on the fast ethernet interfaces even though the tunnel was between loopbacks ? I'd encourage you to try the tunnel method and would be very pleased to hear if you manage to get it working on the 7600. regards, Tony. __________________________________________________________________________________ Get more done like never before with Yahoo!7 Mail. Learn more: http://au.overview.mail.yahoo.com/ From peter at rathlev.dk Thu Oct 22 04:11:47 2009 From: peter at rathlev.dk (Peter Rathlev) Date: Thu, 22 Oct 2009 10:11:47 +0200 Subject: [c-nsp] Migrating from STP "pathcost short" to "pathcost long" Message-ID: <1256199107.2792.7.camel@abehat.net.rm.dk> Hello everybody, We've been migrating from 16-bit pathcost values ("pathcost short", Cisco default) to 32-bit values ("pathcost long") a couple of places and I can't seem to figure out if there are supposed to problems in a transition state. We have seen some strange symptoms, like no L2 connectivity between devices in the same VLAN. Chronology points at pathcost inconsistency being the cause, though I can't see why. When migrating, there will of course be short periods where the STP topology is strange, but after reconvergence I don't see why long and short can't co-exist in a network. Would anybody know if we're supposed to see these problems? Is it a "no-no" to mix short ang long pathcosts in a spanning tree? Thank you in advance. -- Peter From sony.scaria at gmail.com Thu Oct 22 06:57:57 2009 From: sony.scaria at gmail.com (Sony Scaria) Date: Thu, 22 Oct 2009 16:27:57 +0530 Subject: [c-nsp] Boot statement on 6509E Message-ID: <4ae03ac0.161bf30a.5754.73d5@mx.google.com> Hi there, I have a 6509E (SUP 720 ) switch where I am gonna upgrade the IOS . The present code is loaded on sup-bootflash: ( 65Mb). So I added an external disk which gives me enough space. Nor23#dir ? /all List all files /recursive List files recursively all-filesystems List files on all filesystems bootflash: Directory or file name const_nvram: Directory or file name cwan1/0-disk0: Directory or file name cwan1/1-disk0: Directory or file name disk0: Directory or file name disk1: Directory or file name null: Directory or file name nvram: Directory or file name sup-bootflash: Directory or file name sup-image: Directory or file name sup-microcode: Directory or file name system: Directory or file name After loading the news ios to the disk0, what will be the new boot statement? boot system disk0:ios.bin or boot system flash disk0:ios.bin SONY From andriy.bilous at gmail.com Thu Oct 22 07:29:56 2009 From: andriy.bilous at gmail.com (Andriy Bilous) Date: Thu, 22 Oct 2009 13:29:56 +0200 Subject: [c-nsp] Boot statement on 6509E In-Reply-To: <4ae03ac0.161bf30a.5754.73d5@mx.google.com> References: <4ae03ac0.161bf30a.5754.73d5@mx.google.com> Message-ID: Both will work. Seeing you have FlexWAN and probably migrating from SXF to SXH/SXI do not forget to place FPD image on the same file system where new IOS sits. On Thu, Oct 22, 2009 at 12:57 PM, Sony Scaria wrote: > > > Hi there, > > > > I have a 6509E (SUP 720 ) switch where I am gonna upgrade the IOS . The > present code is loaded on sup-bootflash: ( 65Mb). So I added an external > disk which gives me enough space. > > > > Nor23#dir ? > /all List all files > /recursive List files recursively > all-filesystems List files on all filesystems > bootflash: Directory or file name > const_nvram: Directory or file name > cwan1/0-disk0: Directory or file name > cwan1/1-disk0: Directory or file name > disk0: Directory or file name > disk1: Directory or file name > null: Directory or file name > nvram: Directory or file name > sup-bootflash: Directory or file name > sup-image: Directory or file name > sup-microcode: Directory or file name > system: Directory or file name > > > > After loading the news ios to the disk0, what will be the new boot > statement? > > > > boot system disk0:ios.bin > > or > > boot system flash disk0:ios.bin > > > > > > SONY > > > > > > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From Marcus.Gerdon at versatel.de Thu Oct 22 07:56:41 2009 From: Marcus.Gerdon at versatel.de (Marcus.Gerdon) Date: Thu, 22 Oct 2009 13:56:41 +0200 Subject: [c-nsp] WS-X6148A-GE-TX not working with SUP2 Message-ID: <227142482560EF458FF1F7E784E26AB80150159B@FLBVEXCH01.versatel.local> Hello Jonas, I didn't check but I'd suspect your 12.1 won't support a 48xGE blade. Maybe you've mistakenly checked for 6148 w/o the -GE? Would it be possible to run 12.2SXF instaed of 12.1? I've had that running on Sup2/MSFC2 for quite some while working fine. regards, Marcus > -----Urspr?ngliche Nachricht----- > Von: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von > Jonas Bj?rklund > Gesendet: Donnerstag, 22. Oktober 2009 08:29 > An: cisco-nsp at puck.nether.net > Betreff: [c-nsp] WS-X6148A-GE-TX not working with SUP2 > > Hello, > > I have a WS-X6148A-GE-TX thats inserted in a SUP2 but only > get "Unknown" when I do "sh mod". > > The IOS is 12.1(27b)E4. > > 6500-1#sh mod > Mod Ports Card Type Model > Serial No. > --- ----- -------------------------------------- > ------------------ ----------- > 1 2 Catalyst 6000 supervisor 2 (Active) > WS-X6K-SUP2-2GE SAL10019MNG > 2 2 Catalyst 6000 supervisor 2 (Standby) > WS-X6K-SUP2-2GE SAD054204FA > 4 16 SFM-capable 16 port 10/100/1000mb RJ45 > WS-X6516-GE-TX SAL06447YCJ > 5 16 SFM-capable 16 port 10/100/1000mb RJ45 > WS-X6516-GE-TX SAD060101AF > 6 48 Unknown Unknown > Unknown > > 6500-1#sh power > system power redundancy mode = redundant > system power total = 1153.32 Watts (27.46 Amps @ 42V) > system power used = 574.56 Watts (13.68 Amps @ 42V) > system power available = 578.76 Watts (13.78 Amps @ 42V) > > > The same WS-X6148A-GE-TX is working in another chassi with > SUP720-3bxl. > > On the cisco website I can read that the line card should be > supported in SUP2 with the IOS thats running. > > http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/hard > ware/Module_Installation/Mod_Install_Guide/02ethern.html#wp1042813 > > Any ideas? > > /Jonas > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From gnasses at tcfbank.com Thu Oct 22 11:03:19 2009 From: gnasses at tcfbank.com (Nasses, Gus) Date: Thu, 22 Oct 2009 10:03:19 -0500 Subject: [c-nsp] QoS with Traffic shaping on ATM OC3 on 7206 Message-ID: <3F32A25E5E4DA14591780DC424B0AD0202DAB3E4@mn-exch7.mn.tcf.biz> I am having trouble getting a policy-map with traffic shaping and a child QoS policy to apply to an ATM OC3 interface on 7206 router. Cisco TAC recommended IOS upgrade (as always) to 12.4(25b) but this did not help. The PVC on the subinterface will take the command, and if I do a 'do show run' I see it as applied, but a 'do show policy-map int' shows no output and as soon as I exit out of command mode the command does not show in running-config. I suspect that somehow this is not supported on PVC and not giving a clear error message, but it errors when tried to apply to subinterface or main interface. If so, does anyone know if there is another way to accomplish this? This is the policy and child policy: policy-map ProviderAccess description ******************Provider Traffic************************* class RTT bandwidth remaining percent 70 class Cert bandwidth remaining percent 10 class Batch bandwidth remaining percent 15 policy-map Traffic-Shape class Provider shape average 450000 service-policy ProviderAccess Do show run and show policy-map after applying: 7206(config-if-atm-vc)#do sh run int ATM5/0.1 interface ATM5/0.1 point-to-point description ** To Provider - VPI/VCI 3/77 ** ip address 192.168.80.146 255.255.255.252 pvc 7206-EPVC 3/77 vbr-nrt 40960 40960 94 oam-pvc manage 0 encapsulation aal5snap no protocol ip inarp service-policy output Traffic-Shape 7206(config-if-atm-vc)#do sh pol 7206(config-if-atm-vc)#do sh policy-map interface 7206(config-if-atm-vc)#exit 7206(config-subif)# Show run after exiting command mode: 7206#show run int ATM5/0.1 interface ATM5/0.1 point-to-point description ** To Provider - VPI/VCI 3/77 ** ip address 192.168.80.146 255.255.255.252 pvc 7206-EPVC 3/77 vbr-nrt 40960 40960 94 oam-pvc manage 0 encapsulation aal5snap no protocol ip inarp TIA, smart guys. Gus Nasses From panocisco77 at gmail.com Thu Oct 22 11:06:42 2009 From: panocisco77 at gmail.com (Renelson Panosky) Date: Thu, 22 Oct 2009 11:06:42 -0400 Subject: [c-nsp] Problem after upgrading ios on the 6509-E Message-ID: <16e2ac180910220806m190e0214rf5d27552520eed37@mail.gmail.com> A lot of my WS-X6148A-GE-45AF showing up with minor error after i upgrade the IOS on my switch, does any body here have any idea why and how to fix it? I've tried the following but still showing up with errors 1) i reset the module 2) i reseat the module ( take it out and put it back in) Renelson From tim at pelican.org Thu Oct 22 11:17:24 2009 From: tim at pelican.org (Tim Franklin) Date: Thu, 22 Oct 2009 15:17:24 +0000 (GMT) Subject: [c-nsp] QoS with Traffic shaping on ATM OC3 on 7206 In-Reply-To: <3F32A25E5E4DA14591780DC424B0AD0202DAB3E4@mn-exch7.mn.tcf.biz> Message-ID: <17981356.01256224643968.JavaMail.root@jennyfur.pelican.org> > I am having trouble getting a policy-map with traffic shaping and a > child QoS policy to apply to