From nic.tjirkalli at za.verizonbusiness.com Mon Sep 1 02:20:15 2008 From: nic.tjirkalli at za.verizonbusiness.com (Nic Tjirkalli) Date: Mon, 1 Sep 2008 08:20:15 +0200 (SAST) Subject: [c-nsp] PPP Multilink with L2TP interfaces Message-ID: howdy ho, i am trying to get a CPE to 1) fire up a PPPoE session over an Ethernet interface to bring up a Dialer1 interface 2) over this interface, fire up 2 L2TP sessions (Virtual-PPP1 and Virtual-PPP2 and put these in a multilink bundel) The L2TP tunnels are terminating on 196.30.121.42 Now all works well except for the Multilink PPP part. the 2 L2TP sessions come up individual but there is no sign of any attempt to multilink (nothing seen in any debug ppp multilink) I have included my current config if anybody can tell me if what i am trying to do is even possible and how to fix my config i would be very happy and thankful thanx in advance =================== CPE configuration ============================= Current configuration : 3481 bytes ! version 12.4 no service timestamps debug uptime no service timestamps log uptime service password-encryption ! hostname l2tp-multilink ! boot-start-marker boot-end-marker ! logging buffered 4096 debugging enable secret 5 $1$8ZOc$o9WmyJlHqGd1R8E/iYAR0/ ! no aaa new-model ip cef ! ! ! ! no ip domain lookup ip auth-proxy max-nodata-conns 3 ip admission max-nodata-conns 3 vpdn enable ! l2tp-class l2tpclass1 authentication password 7 15115E0B2C7221027123 ! ! multilink virtual-template 1 ! ! no crypto engine onboard 0 ! ! pseudowire-class pwclass1 encapsulation l2tpv2 protocol l2tpv2 l2tpclass1 ip local interface Dialer1 ! pseudowire-class pwclass2 encapsulation l2tpv2 protocol l2tpv2 l2tpclass1 ip local interface Dialer1 ! ! ! ! ! interface Loopback0 ip address 172.16.1.1 255.255.255.255 ! interface Null0 no ip unreachables ! interface FastEthernet0/0 no ip address speed 100 full-duplex pppoe enable group global pppoe-client dial-pool-number 1 ! interface FastEthernet0/1 no ip address duplex auto speed auto ! interface Virtual-PPP1 ip address negotiated ip mtu 1452 ip virtual-reassembly no logging event link-status no peer neighbor-route no cdp enable ppp chap hostname testuser1 ppp chap password 7 XXXXXXXX ppp pap sent-username testuser1 password 7 XXXXXXXX ppp multilink pseudowire 196.30.121.42 10 pw-class pwclass1 ! interface Virtual-Template1 ip unnumbered Loopback0 ppp multilink ! interface Virtual-PPP2 ip address negotiated ip mtu 1452 ip virtual-reassembly no logging event link-status no peer neighbor-route no cdp enable ppp chap hostname testuser2 ppp chap password 7 XXXXXXX ppp pap sent-username testuser2 password 7 XXXXXXX ppp multilink pseudowire 196.30.121.42 100 pw-class pwclass2 ! interface Dialer1 mtu 1492 ip address negotiated ip virtual-reassembly encapsulation ppp ip tcp adjust-mss 1452 dialer pool 1 dialer-group 1 ppp chap hostname testuser1 ppp chap password 7 XXXXXXXX ppp pap sent-username testuser1 password 7 XXXXXXXX ! no ip forward-protocol nd ip route 0.0.0.0 0.0.0.0 Virtual-PPP1 ip route 196.30.121.42 255.255.255.255 Dialer1 ! ! ip http server no ip http secure-server ! ip access-list extended check_packets_in permit ahp any any permit esp any any permit udp any eq isakmp any eq isakmp permit ip any any ! access-list 1 permit any access-list 2 deny any access-list 3 permit 10.0.0.2 access-list 3 permit 206.64.200.15 access-list 3 permit 196.22.64.194 access-list 3 permit 10.222.0.1 access-list 3 permit 10.222.0.2 access-list 3 permit 10.244.0.2 no cdp run ! ! ! ! control-plane ! ! banner motd ^CC ################################################################## # You Should Not Be Here - Logg Off Imediately Thankyou # # # # # ################################################################## ^C ! line con 0 exec-timeout 0 0 line aux 0 exec-timeout 0 0 line vty 0 4 access-class 3 in exec-timeout 0 0 password 7 1315181718 login line vty 5 8 exec-timeout 0 0 no login line vty 9 15 no login ! scheduler allocate 20000 1000 end l2tp-multilink# --------------------------------------------------------------------- I like you. You remind me of when I was young and stupid. Nic Tjirkalli Verizon Business South Africa Network Strategy Team Verizon Business is a brand of Verizon South Africa (Pty) Ltd. This e-mail is strictly confidential and intended only for use by the addressee unless otherwise indicated. Company Information:http:// www.verizonbusiness.com/za/contact/legal/ This e-mail is strictly confidential and intended only for use by the addressee unless otherwise indicated. From oboehmer at cisco.com Mon Sep 1 03:37:32 2008 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Mon, 1 Sep 2008 09:37:32 +0200 Subject: [c-nsp] Error using VFI with local VLAN's on 7600/RSP720 12.2 SRC1 In-Reply-To: <6bb5f5b10808311627v6f49bb69i96e38c700e877dd9@mail.gmail.com> References: <48B9DFC4.5070701@lists.esoteric.ca> <70B7A1CCBFA5C649BD562B6D9F7ED78405ED27B7@xmb-ams-333.emea.cisco.com> <6bb5f5b10808311627v6f49bb69i96e38c700e877dd9@mail.gmail.com> Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED78405ED28D2@xmb-ams-333.emea.cisco.com> Not sure if this would work. Stephen: What are you trying to achieve? oli Rubens Kuhl Jr. wrote on Monday, September 01, 2008 1:27 AM: > Can he add VLAN translation to the scenario ? > > > Rubens > > > On Sun, Aug 31, 2008 at 4:13 AM, Oliver Boehmer (oboehmer) > wrote: >> Stephen Fulton <> wrote on Sunday, August 31, 2008 2:03 AM: >> >>> Hi all, >>> >>> I'm testing out VFI's in a lab, and I've run into the following >>> when I attempt to add a second VLAN to the VFI instance. >> >> well, adding a 2nd SVI/Vlan to a VFI doesn't make sense (at least to >> me), if you want to bridge both segments (and the remote VFIs) >> together, you would put them into the same broadcast domain (speak: >> vlan). You can't use VFI/VPLS to create a single bridge domain for >> two local vlans. >> >> >> 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 muarwi at gmail.com Mon Sep 1 03:48:41 2008 From: muarwi at gmail.com (Muarwi) Date: Mon, 1 Sep 2008 14:48:41 +0700 Subject: [c-nsp] Interdomain Multicast Routing Message-ID: <465d309c0809010048j1a5f5fbaja2bad4b1b07dfd3f@mail.gmail.com> Hi guys, I'm sorry if my questions is rather out of cisco's things. I've read books about interdomain multicast routing (also one from cisco press). From what I get, the solutions offered is PIM SM - MBGP - MSDP. My questions is : 1. what about using PIM Bidir for interdomain multicast? Is it possible to implement it in Cisco? 2. Has BGMP been being implemented in vendors? Thanks a lot for your response From gordon.bezzina at bell.net.mt Mon Sep 1 03:58:53 2008 From: gordon.bezzina at bell.net.mt (Gordon Bezzina) Date: Mon, 1 Sep 2008 09:58:53 +0200 Subject: [c-nsp] exceeding the hardware maximum routes in a 720BXL In-Reply-To: References: Message-ID: <014901c90c08$940c8550$bc258ff0$@bezzina@bell.net.mt> Hi, Just a quick question what will happen if you exceed the maximum routes That the FIB TCAM can store. c7600#sh mls cef maximum-routes FIB TCAM maximum routes : ======================= Current :- ------- IPv4 + MPLS - 512k (default) IPv6 + IP Multicast - 256k (default) c7600# Will switch completely to software routing, or just switch the Excess routes to software routing? Or will it drop routes or worst Still crash!? Also is there a best practice on changing the default maximum routes Allocations? Thanks Gordon From jeff.nsp at gmail.com Mon Sep 1 04:48:08 2008 From: jeff.nsp at gmail.com (Jeff Tantsura) Date: Mon, 1 Sep 2008 10:48:08 +0200 Subject: [c-nsp] Interdomain Multicast Routing In-Reply-To: <465d309c0809010048j1a5f5fbaja2bad4b1b07dfd3f@mail.gmail.com> References: <465d309c0809010048j1a5f5fbaja2bad4b1b07dfd3f@mail.gmail.com> Message-ID: <000601c90c0f$764584c0$650c10ac@ad.redback.com> Hi, The combination you've described has been working for many years, very well tested, supported by all major vendors. PIM (bidir as well) is used for intradomain multicast routing independently of interdomain multicast (MSDP/MBGP). Cisco does support PIM Bidir Cheers, Jeff P.S. Best book ever - "Interdomain Mutlicast Routing" by Edwards/Giuliano/Wright > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Muarwi > Sent: maandag 1 september 2008 9:49 > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] Interdomain Multicast Routing > > Hi guys, I'm sorry if my questions is rather out of cisco's things. > > I've read books about interdomain multicast routing (also one from cisco > press). From what I get, the solutions offered is PIM SM - MBGP - MSDP. > > My questions is : > 1. what about using PIM Bidir for interdomain multicast? Is it possible to > implement it in Cisco? > 2. Has BGMP been being implemented in vendors? > > Thanks a lot for your response > _______________________________________________ > 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 ltd at cisco.com Mon Sep 1 05:50:49 2008 From: ltd at cisco.com (Lincoln Dale) Date: Mon, 01 Sep 2008 19:50:49 +1000 Subject: [c-nsp] exceeding the hardware maximum routes in a 720BXL In-Reply-To: <014901c90c08$940c8550$bc258ff0$@bezzina@bell.net.mt> References: <014901c90c08$940c8550$bc258ff0$@bezzina@bell.net.mt> Message-ID: <48BBBAF9.70009@cisco.com> Gordon Bezzina wrote: > Hi, > > Just a quick question what will happen if you exceed the maximum routes > That the FIB TCAM can store. > > c7600#sh mls cef maximum-routes > FIB TCAM maximum routes : > ======================= > Current :- > ------- > IPv4 + MPLS - 512k (default) > IPv6 + IP Multicast - 256k (default) > > > c7600# > > > Will switch completely to software routing, or just switch the > Excess routes to software routing? Or will it drop routes or worst > Still crash!? > it will switch to partial h/w, partial s/w. a wildcard will be installed that matches on anything that doesn't fit into the table (i.e. it'll be a punt-to-software for "0/0"). > > Also is there a best practice on changing the default maximum routes > Allocations? > default is 50/50 split between IPv4/MPLS / IPv6/Multicast. its perhaps difficult to crystal-ball uptake of IPv6 over the next 2 years, but its probably fair to say the current defaults are ok. cheers, lincoln. From Andrey_Oleinik at bms-consulting.com Mon Sep 1 07:29:37 2008 From: Andrey_Oleinik at bms-consulting.com (Andrey Oleinik) Date: Mon, 1 Sep 2008 14:29:37 +0300 Subject: [c-nsp] MWR 1941 Message-ID: <68D5E673B49F1D45A5BE41058C8AFDBC010247681CD5@BMSEXCH.BMS-CONSULTING.COM> Do anybody know if MWR 1941 DC supports HWIC-4ESW? Thank U. -- Respect, Andy Oleynik From leonardo.souza at nec.com.br Mon Sep 1 09:56:48 2008 From: leonardo.souza at nec.com.br (Leonardo Gama Souza) Date: Mon, 1 Sep 2008 10:56:48 -0300 Subject: [c-nsp] RES: Sup720 Config registry In-Reply-To: <083120081248.27528.48BA9304000ADD6F00006B882200763692080B0E9C0E@comcast.net> References: <083120081248.27528.48BA9304000ADD6F00006B882200763692080B0E9C0E@comcast.net> Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D0194F9AD@spsrvmail03.nec.br> Notice this can be broken due to CSCeg76624, CSCeg22424 or CSCed58891. You're safe if you're running 8.5(1) though. []?s -----Mensagem original----- De: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] Em nome de asadh at comcast.net Enviada em: domingo, 31 de agosto de 2008 09:48 Para: Brett Clausenhauf; cisco-nsp at puck.nether.net Assunto: Re: [c-nsp] Sup720 Config registry You can check the config-register setting on SP by: rem comm sw sh ver | i register SP is probably still set to 2142. You should change it to 0x2102 by going to config on RP. When you save the config it will be saved on SP also. After saving you can issue: rem comm sw sh ver | i register It should indicate 0x2102 aftrer reboot. Asad -------------- Original message -------------- From: "Brett Clausenhauf" > Hey Guys.. > > I have a query I cannot seem to find any answer too. > > > When a sup720 module is booting, if you do a CTRL + Break into rommon > & change the confreg register on the SP module (Changed to confreg > 0x2142 & NOT the RP module, what does this actually do? I did this by > mistake whilst troubleshooting an issue. The issue is now resolved but > I never got the opportunity to put this back (Also not sure what to > put it back too). The module boots up the config & appears to be > working 100 percent fine... I am very concerned if doing this does > anything detrimental that is going to be a concern later. > > Can anybody who might know advise? It would be very much appreciated.. > > > Thanks in advance. > _______________________________________________ > 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 p.mayers at imperial.ac.uk Mon Sep 1 11:33:39 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Mon, 01 Sep 2008 16:33:39 +0100 Subject: [c-nsp] RES: Cisco Catalyst 6513 IOS version In-Reply-To: <20080829072040.GD27310@lboro.ac.uk> References: <48B520CE.7030008@actrix.co.nz> <48B5602E.7010705@imperial.ac.uk> <079b01c90970$092d2330$f211a8c0@flamadam> <20080829072040.GD27310@lboro.ac.uk> Message-ID: <48BC0B53.4040000@imperial.ac.uk> A.L.M.Buxey at lboro.ac.uk wrote: > Hi, > >> Lastest one running SXH1. No problems so far with FWSM, ACE and 6748s. > > we've got a 12.2(33)SXH3 box up and alive now - so far so much > better than SXH2 (and 2b) but we've yet to drive packets through > in anger. certainly looks like we might be SXH'd by the new year > (but dont quote me on that! ;-) ) Just don't try and "scp" anything from it... From MLouis at nwnit.com Mon Sep 1 11:45:06 2008 From: MLouis at nwnit.com (Mike Louis) Date: Mon, 1 Sep 2008 11:45:06 -0400 Subject: [c-nsp] Interdomain Multicast Routing Message-ID: This has been a confusing subject for me. If you enabled msdp between 2 pim sm domains and enabled mc routing on the intermediate bgp routers while using normal non-mbgp routing wouldn't mc still work? Why would you want to use mbgp unless you wanted mc routes to take a different path than unicast routes? Do most sp these days support mc in their networks for customers? Thanks mike -----Original Message----- From: Jeff Tantsura Sent: Monday, September 01, 2008 4:53 AM To: 'Muarwi' ; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Interdomain Multicast Routing Hi, The combination you've described has been working for many years, very well tested, supported by all major vendors. PIM (bidir as well) is used for intradomain multicast routing independently of interdomain multicast (MSDP/MBGP). Cisco does support PIM Bidir Cheers, Jeff P.S. Best book ever - "Interdomain Mutlicast Routing" by Edwards/Giuliano/Wright > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Muarwi > Sent: maandag 1 september 2008 9:49 > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] Interdomain Multicast Routing > > Hi guys, I'm sorry if my questions is rather out of cisco's things. > > I've read books about interdomain multicast routing (also one from cisco > press). From what I get, the solutions offered is PIM SM - MBGP - MSDP. > > My questions is : > 1. what about using PIM Bidir for interdomain multicast? Is it possible to > implement it in Cisco? > 2. Has BGMP been being implemented in vendors? > > Thanks a lot for your response > _______________________________________________ > 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. From A.L.M.Buxey at lboro.ac.uk Mon Sep 1 11:47:00 2008 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 1 Sep 2008 16:47:00 +0100 Subject: [c-nsp] RES: Cisco Catalyst 6513 IOS version In-Reply-To: <48BC0B53.4040000@imperial.ac.uk> References: <48B520CE.7030008@actrix.co.nz> <48B5602E.7010705@imperial.ac.uk> <079b01c90970$092d2330$f211a8c0@flamadam> <20080829072040.GD27310@lboro.ac.uk> <48BC0B53.4040000@imperial.ac.uk> Message-ID: <20080901154700.GB24224@lboro.ac.uk> Hi, >> we've got a 12.2(33)SXH3 box up and alive now - so far so much >> better than SXH2 (and 2b) but we've yet to drive packets through >> in anger. certainly looks like we might be SXH'd by the new year >> (but dont quote me on that! ;-) ) > > Just don't try and "scp" anything from it... 8-) dont worry - i saw _that_ posting. anything with SXH in the subject line right now gets my immediate attention (remember that spammers.... ;-) ) alan From gert at greenie.muc.de Mon Sep 1 12:11:41 2008 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 1 Sep 2008 18:11:41 +0200 Subject: [c-nsp] Interdomain Multicast Routing In-Reply-To: References: Message-ID: <20080901161141.GS233@greenie.muc.de> Hi, On Mon, Sep 01, 2008 at 11:45:06AM -0400, Mike Louis wrote: > Do most sp these days support mc in their networks for customers? Do you know *any* SPs these days that support multicast? Yes, there are a few that have it still turned on, but does that mean it's a first grade, fully supported, product? We disabled external multicasting in our SP network last week - because there was only minimal customer demand in the last 6 or 7 years, and on those few occasions, I usually spent ages diagnosing black hole issues at one of our upstreams (turned up a new line, forgot to enable PIM on it, and such things). IPv4 multicast is extremely painful to debug. The whole MSDP/MBGP/PIM model is too complicated to maintain and too brittle for stable operations (SSM might be better - we never tried). 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: 304 bytes Desc: not available URL: From criling at gmail.com Mon Sep 1 12:35:15 2008 From: criling at gmail.com (Chris Riling) Date: Mon, 1 Sep 2008 12:35:15 -0400 Subject: [c-nsp] Sup720 Config registry In-Reply-To: <20080831144435.GA4763@gerbil.cluepon.net> References: <20080831144435.GA4763@gerbil.cluepon.net> Message-ID: <8c829ec10809010935g11c22639s488104a8ff8e7ee8@mail.gmail.com> I have seen an interesting one as well... I had a 7606 with a sup32 out of sync once, and any input from the console port (or sometimes just on it's own) it would halt the switch processor and force a reboot... I'd suggest you make sure the SP and RP are always in sync :) Chris On Sun, Aug 31, 2008 at 10:44 AM, Richard A Steenbergen wrote: > On Sun, Aug 31, 2008 at 03:28:18PM +0200, Mikael Abrahamsson wrote: > > On Sun, 31 Aug 2008, Brett Clausenhauf wrote: > > > > >Can anybody who might know advise? It would be very much appreciated.. > > > > I had a similar issue back in SXE days (2+ years ago) where the conf-reg > > would get out of sync between modules on the Sup720-3bxl (it would show > > conf-reg 0x2102 in IOS, but rebooting would go into rommon). > > > > To fix it, I would simply do a conf-reg 0x2102 and "wr" in regular config > > mode, which seemed to set this conf-reg on all modules, making the > problem > > go away. > > I've seen a couple really cool side-effects from an out-of-sync config > register between RP and SP... For example, I was once rebooting a sup720 > to change the cef maximum-routes tcam partitioning, and as soon as it > would boot back up it would install a "reboot in 10 minutes" rule, > like what Jared mentioned here: > > http://puck.nether.net/pipermail/cisco-nsp/2006-October/035266.html > > After sitting through a lot of automatic reboots and trying everything > known to man to stop them, I finally found the problem was a desynced > config-register that you couldn't see from IOS at all (you had to start > a shell on the SP to see it), which caused the SP to not process the > RP's new tcam partition config. Apparently there was some edge condition > which might need you to reboot twice to fully update the SP, so Cisco > just wrote code to automatically reboot if the SP wasn't updated > correctly. Combine that with an out-of-sync config-register and you've > got lots of endless rebooting fun. :) > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > _______________________________________________ > cisco-nsp mailing list cisco-nsp 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 Sep 1 12:39:12 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Mon, 01 Sep 2008 17:39:12 +0100 Subject: [c-nsp] Interdomain Multicast Routing In-Reply-To: <20080901161141.GS233@greenie.muc.de> References: <20080901161141.GS233@greenie.muc.de> Message-ID: <48BC1AB0.4050406@imperial.ac.uk> Gert Doering wrote: > Hi, > > On Mon, Sep 01, 2008 at 11:45:06AM -0400, Mike Louis wrote: >> Do most sp these days support mc in their networks for customers? > > Do you know *any* SPs these days that support multicast? > > Yes, there are a few that have it still turned on, but does that mean > it's a first grade, fully supported, product? > > We disabled external multicasting in our SP network last week - because > there was only minimal customer demand in the last 6 or 7 years, and > on those few occasions, I usually spent ages diagnosing black hole > issues at one of our upstreams (turned up a new line, forgot to enable > PIM on it, and such things). > > IPv4 multicast is extremely painful to debug. The whole MSDP/MBGP/PIM > model is too complicated to maintain and too brittle for stable operations > (SSM might be better - we never tried). SSM is certainly *easier* to troubleshoot as is IPv6 embedded RP. I wouldn't say they're "good" though; a large portion of the issues I've run into are much more general e.g. firewalls, lack of IGMP forwarding, lack of layer2 support, TTL problems, MTU problems, etc. From julien.leroiso at gmail.com Mon Sep 1 12:47:06 2008 From: julien.leroiso at gmail.com (julien leroiso) Date: Mon, 1 Sep 2008 18:47:06 +0200 Subject: [c-nsp] "real" BGP test router Message-ID: Hi, I know I can use quagga or dynamips/gns3 to validate my labs. But something real where other person add/remove routes should be great. so I'm looking for a "real" BGP router on internet to test my configuration. A router where peoble can ask a peering to test their conf. Regards, Julien. From frnkblk at iname.com Mon Sep 1 14:03:23 2008 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 1 Sep 2008 13:03:23 -0500 Subject: [c-nsp] Few questions regarding fixed vs modular and when which is better. In-Reply-To: <6D6205FA-8F23-48FC-B495-9A022F1B5304@short.id.au> References: <48B6C5AE.5030501@lumison.net> <48B6CAC3.8000308@templin.org> <20080829073336.GH233@greenie.muc.de> <001b01c909c4$638d89b0$2aa89d10$@org.uk> <6D6205FA-8F23-48FC-B495-9A022F1B5304@short.id.au> Message-ID: Seems like a lot of extra cabling gymnastics to compensate for the failure of Cisco to provide an affordable 48-port dual-PSU 1U switch. Frank -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Shane Short Sent: Friday, August 29, 2008 6:30 AM To: cisco-nsp Subject: Re: [c-nsp] Few questions regarding fixed vs modular and when which is better. I've had pretty good success doing this in the past, however, I've run double the density and split it over two racks. Ie, 24 Servers per rack, so a 48port switch per rack, with 48 ties between the rack to tie it all together, each server would hit the switch in it's own rack, then tie over to the adjacent rack. Idea generally behind this was to have the servers/switches on opposing phases to eliminate power problems, without having to get Dual Power supplies in the switches themselves. -Shane On 29/08/2008, at 6:45 PM, Dean Smith wrote: > Surely 2 basic Switches - With Servers dual homed across giving you > independent uplinks to the core, dual control planes and dual power > etc > gives far better resilience at the price point than a simple switch > with an > extra PSU ? > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Gert Doering > Sent: 29 August 2008 08:34 > To: Pete Templin > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Few questions regarding fixed vs modular and > when which > is better. > > Hi, > > On Thu, Aug 28, 2008 at 10:56:51AM -0500, Pete Templin wrote: >> Have you looked at their product line lately? I attended one of >> their >> LAN Switching Update events, and learned a lot about their new >> products, such as 1U 3560E models with 24 or 48 10/100/1000 ports and >> two X2 10G uplinks and dual power. Might that suffice? > > Still "full L3" with the L3 price tag. > > Something like a 2960G-24TC with dual power would be cool. > > 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 > > _______________________________________________ > 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 paul.cosgrove at heanet.ie Mon Sep 1 14:48:13 2008 From: paul.cosgrove at heanet.ie (Paul Cosgrove) Date: Mon, 01 Sep 2008 19:48:13 +0100 Subject: [c-nsp] Interdomain Multicast Routing In-Reply-To: References: Message-ID: <48BC38ED.4000508@heanet.ie> Hi Mike, Normally MSDP will work with just unicast BGP, but then RPF check changed between IOS and IOS XR... In IOS a router performing an RPF check looks first at the multicast routing table, and if it doesn't find a match it then looks at the unicast table. In IOS XR if you have any routes in the multicast table, and you do not find the one you are looking for, RPF fails. Doesn't matter whether or not the prefix is in the unicast table. You may have a situation where you are given multicast feeds (e.g. IPTV) and are only supplied with multicast BGP routes because they do not want any of your unicast traffic. You may well wish to receive those feeds, and also receive multicasts from sources which only advertises unicast routes. If I understand the RPF correctly, this presents you with a problem and may have to look at statics/ACLs etc. Paul. Mike Louis wrote: > This has been a confusing subject for me. If you enabled msdp between 2 pim sm domains and enabled mc routing on the intermediate bgp routers while using normal non-mbgp routing wouldn't mc still work? Why would you want to use mbgp unless you wanted mc routes to take a different path than unicast routes? Do most sp these days support mc in their networks for customers? > > Thanks > > mike > > -----Original Message----- > From: Jeff Tantsura > Sent: Monday, September 01, 2008 4:53 AM > To: 'Muarwi' ; cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Interdomain Multicast Routing > > > Hi, > > The combination you've described has been working for many years, > very well tested, supported by all major vendors. > PIM (bidir as well) is used for intradomain multicast routing independently > of interdomain multicast (MSDP/MBGP). > Cisco does support PIM Bidir > > Cheers, > Jeff > > P.S. Best book ever - "Interdomain Mutlicast Routing" by > Edwards/Giuliano/Wright > >> -----Original Message----- >> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- >> bounces at puck.nether.net] On Behalf Of Muarwi >> Sent: maandag 1 september 2008 9:49 >> To: cisco-nsp at puck.nether.net >> Subject: [c-nsp] Interdomain Multicast Routing >> >> Hi guys, I'm sorry if my questions is rather out of cisco's things. >> >> I've read books about interdomain multicast routing (also one from cisco >> press). From what I get, the solutions offered is PIM SM - MBGP - MSDP. >> >> My questions is : >> 1. what about using PIM Bidir for interdomain multicast? Is it possible to >> implement it in Cisco? >> 2. Has BGMP been being implemented in vendors? >> >> Thanks a lot for your response >> _______________________________________________ >> 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/ > > > Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. > > _______________________________________________ > 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/ > -- HEAnet Limited Ireland's Education & Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. From tseveendorj at gmail.com Mon Sep 1 21:54:05 2008 From: tseveendorj at gmail.com (Tseveendorj Ochirlantuu) Date: Tue, 2 Sep 2008 09:54:05 +0800 Subject: [c-nsp] RTP related question Message-ID: <62c908120809011854y707caf87vd5325bcd7e9cedb0@mail.gmail.com> Hi I couldn't imagine how to test RTP between 2 points. How do I know remote RTP ports open? Sincerely, Tseveen From muarwi at gmail.com Mon Sep 1 22:49:23 2008 From: muarwi at gmail.com (Muarwi) Date: Tue, 2 Sep 2008 09:49:23 +0700 Subject: [c-nsp] Interdomain Multicast Routing In-Reply-To: <000601c90c0f$764584c0$650c10ac@ad.redback.com> References: <465d309c0809010048j1a5f5fbaja2bad4b1b07dfd3f@mail.gmail.com> <000601c90c0f$764584c0$650c10ac@ad.redback.com> Message-ID: <465d309c0809011949k2beb5eb7qda9a6d022aed36ce@mail.gmail.com> Hi Jeff, thanks a lot for your response. Then how about BGMP (RFC 3913) ? Is it still a proposed protocol? Thanks . On 9/1/08, Jeff Tantsura wrote: > > Hi, > > The combination you've described has been working for many years, > very well tested, supported by all major vendors. > PIM (bidir as well) is used for intradomain multicast routing > independently > of interdomain multicast (MSDP/MBGP). > Cisco does support PIM Bidir > > Cheers, > Jeff > > P.S. Best book ever - "Interdomain Mutlicast Routing" by > Edwards/Giuliano/Wright > > > > -----Original Message----- > > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > > bounces at puck.nether.net] On Behalf Of Muarwi > > Sent: maandag 1 september 2008 9:49 > > To: cisco-nsp at puck.nether.net > > Subject: [c-nsp] Interdomain Multicast Routing > > > > Hi guys, I'm sorry if my questions is rather out of cisco's things. > > > > I've read books about interdomain multicast routing (also one from cisco > > press). From what I get, the solutions offered is PIM SM - MBGP - MSDP. > > > > My questions is : > > 1. what about using PIM Bidir for interdomain multicast? Is it possible > to > > implement it in Cisco? > > 2. Has BGMP been being implemented in vendors? > > > > Thanks a lot for your response > > > _______________________________________________ > > 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 abalashov at evaristesys.com Mon Sep 1 22:51:10 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Mon, 1 Sep 2008 22:51:10 -0400 (EDT) Subject: [c-nsp] RTP related question In-Reply-To: <62c908120809011854y707caf87vd5325bcd7e9cedb0@mail.gmail.com> References: <62c908120809011854y707caf87vd5325bcd7e9cedb0@mail.gmail.com> Message-ID: <1cb627fb84d83ce4aa3f4ecd58c94efd.squirrel@webmail.corp.evaristesys.com> As RTP contains no backward acknowledgment mechanisms (other than RTCP reports), you really can't. You need to use a VoIP user agent and generate a bidirectional RTP stream (a conversation) and verify media receipt with a packet capture or subjectively, or via some means that the user agent provides. On Mon, September 1, 2008 9:54 pm, Tseveendorj Ochirlantuu wrote: > Hi > > I couldn't imagine how to test RTP between 2 points. How do I know remote > RTP ports open? > > Sincerely, > Tseveen > _______________________________________________ > 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 Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From pshuleski at gmail.com Mon Sep 1 23:15:13 2008 From: pshuleski at gmail.com (Pete S.) Date: Mon, 1 Sep 2008 23:15:13 -0400 Subject: [c-nsp] RES: Cisco Catalyst 6513 IOS version In-Reply-To: <20080901154700.GB24224@lboro.ac.uk> References: <48B520CE.7030008@actrix.co.nz> <48B5602E.7010705@imperial.ac.uk> <079b01c90970$092d2330$f211a8c0@flamadam> <20080829072040.GD27310@lboro.ac.uk> <48BC0B53.4040000@imperial.ac.uk> <20080901154700.GB24224@lboro.ac.uk> Message-ID: <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> We've been running a mix od SXF, and SXH (un)fortunately. SXF is pretty solid. If you don't have any features(like VPN, adjust-mss specifically), or modules which require an SXH train(i.e. 6716) I'd suggest you stick with safe harbor SXF. The biggest running issue I have with SXH, is not containing the ISSU capability in the non-modular flavor. Modular still makes me nervous for production. --Pete On Mon, Sep 1, 2008 at 11:47 AM, wrote: > Hi, > >>> we've got a 12.2(33)SXH3 box up and alive now - so far so much >>> better than SXH2 (and 2b) but we've yet to drive packets through >>> in anger. certainly looks like we might be SXH'd by the new year >>> (but dont quote me on that! ;-) ) >> >> Just don't try and "scp" anything from it... > > 8-) dont worry - i saw _that_ posting. anything with SXH > in the subject line right now gets my immediate attention > (remember that spammers.... ;-) ) > > alan > _______________________________________________ > 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 dudepron at gmail.com Mon Sep 1 23:48:15 2008 From: dudepron at gmail.com (Aaron) Date: Mon, 1 Sep 2008 23:48:15 -0400 Subject: [c-nsp] Interdomain Multicast Routing In-Reply-To: References: Message-ID: <480dad640809012048o32821575we5e4a798b5e924da@mail.gmail.com> The large ones do. I know Sprint has been doing it for over 11 years. I would say that most do not charge or if they do it is minimal. NOC support may vary from provider to provider. On Mon, Sep 1, 2008 at 11:45 AM, Mike Louis wrote: > This has been a confusing subject for me. If you enabled msdp between 2 > pim sm domains and enabled mc routing on the intermediate bgp routers while > using normal non-mbgp routing wouldn't mc still work? Why would you want to > use mbgp unless you wanted mc routes to take a different path than unicast > routes? Do most sp these days support mc in their networks for customers? > > Thanks > > mike > > -----Original Message----- > From: Jeff Tantsura > Sent: Monday, September 01, 2008 4:53 AM > To: 'Muarwi' ; cisco-nsp at puck.nether.net < > cisco-nsp at puck.nether.net> > Subject: Re: [c-nsp] Interdomain Multicast Routing > > > Hi, > > The combination you've described has been working for many years, > very well tested, supported by all major vendors. > PIM (bidir as well) is used for intradomain multicast routing > independently > of interdomain multicast (MSDP/MBGP). > Cisco does support PIM Bidir > > Cheers, > Jeff > > P.S. Best book ever - "Interdomain Mutlicast Routing" by > Edwards/Giuliano/Wright > > > -----Original Message----- > > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > > bounces at puck.nether.net] On Behalf Of Muarwi > > Sent: maandag 1 september 2008 9:49 > > To: cisco-nsp at puck.nether.net > > Subject: [c-nsp] Interdomain Multicast Routing > > > > Hi guys, I'm sorry if my questions is rather out of cisco's things. > > > > I've read books about interdomain multicast routing (also one from cisco > > press). From what I get, the solutions offered is PIM SM - MBGP - MSDP. > > > > My questions is : > > 1. what about using PIM Bidir for interdomain multicast? Is it possible > to > > implement it in Cisco? > > 2. Has BGMP been being implemented in vendors? > > > > Thanks a lot for your response > > _______________________________________________ > > 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/ > > > Note: This message and any attachments is intended solely for the use of > the individual or entity to which it is addressed and may contain > information that is non-public, proprietary, legally privileged, > confidential, and/or exempt from disclosure. If you are not the intended > recipient, you are hereby notified that any use, dissemination, > distribution, or copying of this communication is strictly prohibited. If > you have received this communication in error, please notify the original > sender immediately by telephone or return email and destroy or delete this > message along with any attachments immediately. > > _______________________________________________ > 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 Tue Sep 2 00:25:03 2008 From: vikassharmas at gmail.com (Vikas Sharma) Date: Tue, 2 Sep 2008 09:55:03 +0530 Subject: [c-nsp] mpls ldp discovery transport-address Message-ID: Hi, Below is the output of sh mpls ldp discovery. Here LDP identifier and LDP discovery source are different. I can change discovery source using "mpls ldp discovery transport-address but my question here is what is the best practice and what are the benefits? is it using both LDP identifier and Discovery source same or different? One of the benefit I can see is if I use the same IP for both is I can reduce the number of labels. Any other benefit wrt security!!! router1# sh mpls ldp discovery Local LDP Identifier: 212.74.65.105:0 Discovery Sources: Interfaces: GigabitEthernet0/1 (ldp): xmit/recv LDP Id: 212.74.65.124:0 GigabitEthernet0/2 (ldp): xmit/recv LDP Id: 212.74.65.126:0 Targeted Hellos: 212.74.65.105 -> 212.74.65.124 (ldp): passive, xmit/recv LDP Id: 212.74.65.124:0 212.74.65.105 -> 212.74.65.126 (ldp): passive, xmit/recv LDP Id: 212.74.65.126:0 router1#sh mpls fo router1#sh mpls forwarding-table | in 212.74.65.124 4560 Pop tag 212.74.65.124/32 0 Gi0/1 212.74.88.233 router1#sh mpls forwarding-table | in 212.74.65.105 router1# Regards, Vikas Sharma From oboehmer at cisco.com Tue Sep 2 01:53:13 2008 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Tue, 2 Sep 2008 07:53:13 +0200 Subject: [c-nsp] mpls ldp discovery transport-address In-Reply-To: References: Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED78405F396A2@xmb-ams-333.emea.cisco.com> Vikas Sharma <> wrote on Tuesday, September 02, 2008 6:25 AM: > Hi, > > Below is the output of sh mpls ldp discovery. Here LDP identifier and > LDP discovery source are different. I can change discovery source > using "mpls ldp discovery transport-address but my question here is > what is the best practice and what are the benefits? is it using both > LDP identifier and Discovery source same or different? best practice is to use a loopback as LDP router-ID and advertise this address as transport address (i.e. use the default behavior). This has multiple advantages: - less config - if you have multiple links between two nodes, you don't have to worry about advertising the same address on both links - it allows you to keep the session established even if the link supplying the transport address goes down (good for convergence) Or where you thinking about using a dedicated loopback as transport address? Not sure what the benefit of this would be. I've seen the transport address being used in some cases where the LDP router-ID is not advertised in IGP (for whatever reason), but these were corner cases.. > One of the benefit I can see is if I use the same IP for both is I can > reduce the number of labels. Any other benefit wrt security!!! not sure what you mean by "reducing number of labels".. Number of IGP labels is usually not a concern. Not sure about the security argument. oli From swmike at swm.pp.se Tue Sep 2 02:08:13 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 2 Sep 2008 08:08:13 +0200 (CEST) Subject: [c-nsp] mpls ldp discovery transport-address In-Reply-To: <70B7A1CCBFA5C649BD562B6D9F7ED78405F396A2@xmb-ams-333.emea.cisco.com> References: <70B7A1CCBFA5C649BD562B6D9F7ED78405F396A2@xmb-ams-333.emea.cisco.com> Message-ID: > I've seen the transport address being used in some cases where the LDP > router-ID is not advertised in IGP (for whatever reason), but these were > corner cases.. I've had to use it when there were vendor interop-problems, the LDP session wouldn't come up otherwise. I even posted to the IETF MPLS list regarding the fact that I couldn't figure out where in the standard it was said what address should be used where, but I received no reply so I am still none the wiser how it should work so I know what vendor to tell to go fix their stuff. -- Mikael Abrahamsson email: swmike at swm.pp.se From gert at greenie.muc.de Tue Sep 2 02:27:32 2008 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 2 Sep 2008 08:27:32 +0200 Subject: [c-nsp] RES: Cisco Catalyst 6513 IOS version In-Reply-To: <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> References: <48B520CE.7030008@actrix.co.nz> <48B5602E.7010705@imperial.ac.uk> <079b01c90970$092d2330$f211a8c0@flamadam> <20080829072040.GD27310@lboro.ac.uk> <48BC0B53.4040000@imperial.ac.uk> <20080901154700.GB24224@lboro.ac.uk> <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> Message-ID: <20080902062732.GU233@greenie.muc.de> Hi, On Mon, Sep 01, 2008 at 11:15:13PM -0400, Pete S. wrote: > The biggest running issue I have with SXH, My biggest issues are: - no BFD on SVIs (worked fine in SXF) - the BGP ghost bug is back :-( (SXH3 regularily forgets to send withdraws to iBGP peers if a prefix completely disappears. During the course of 4 weeks, I have observed it twice, once for IPv4 and once for IPv6, without actually *looking* for it - so it's likely happening much more often) The thing I like most about SXH is the reworked mls netflow architecture where you only fill up netflow TCAM for those interfaces that you really want to see, and not "for all interfaces and the collector has to filter". 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: 304 bytes Desc: not available URL: From b.turnbow at twt.it Tue Sep 2 03:00:41 2008 From: b.turnbow at twt.it (Brian Turnbow) Date: Tue, 2 Sep 2008 09:00:41 +0200 Subject: [c-nsp] RTP related question In-Reply-To: <62c908120809011854y707caf87vd5325bcd7e9cedb0@mail.gmail.com> References: <62c908120809011854y707caf87vd5325bcd7e9cedb0@mail.gmail.com> Message-ID: You can use saa on cisco routers to simmulate traffic and gather stats (jitter packet loss ecc). That won't tell if the ports oare open but you can check line quality ecc. http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a00801b1a1e.shtml Brian -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tseveendorj Ochirlantuu Sent: marted? 2 settembre 2008 3.54 To: cisco-voip at puck.nether.net Cc: cisco-nsp at puck.nether.net Subject: [c-nsp] RTP related question Hi I couldn't imagine how to test RTP between 2 points. How do I know remote RTP ports open? Sincerely, Tseveen _______________________________________________ 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 julien.leroiso at gmail.com Tue Sep 2 04:14:55 2008 From: julien.leroiso at gmail.com (julien leroiso) Date: Tue, 2 Sep 2008 10:14:55 +0200 Subject: [c-nsp] "real" BGP test router In-Reply-To: References: Message-ID: I said "real" because I'm thinking test router where other persons use it to test. But this BGP router have no impact on internet. This platform could be automatic with a form and give you an unused private AS number in their tables :p On Mon, Sep 1, 2008 at 6:47 PM, julien leroiso wrote: > Hi, > > I know I can use quagga or dynamips/gns3 to validate my labs. > But something real where other person add/remove routes should be great. > > so I'm looking for a "real" BGP router on internet to test my > configuration. > A router where peoble can ask a peering to test their conf. > > Regards, > Julien. > From list-cisco-nsp at pwns.ms Tue Sep 2 04:29:49 2008 From: list-cisco-nsp at pwns.ms (list-cisco-nsp at pwns.ms) Date: Tue, 2 Sep 2008 08:29:49 +0000 Subject: [c-nsp] "real" BGP test router In-Reply-To: References: Message-ID: <20080902082949.GA8158@pwns.ms> > I said "real" because I'm thinking test router where other persons use it to > test. > But this BGP router have no impact on internet. > > This platform could be automatic with a form and give you an unused private > AS number in their tables :p Do you mean something like http://noc.mono-ix.net/? From tomas at soitron.com Tue Sep 2 08:02:07 2008 From: tomas at soitron.com (Tomas Daniska) Date: Tue, 2 Sep 2008 14:02:07 +0200 Subject: [c-nsp] SRB4 (was RE: SRC2?) In-Reply-To: <1219992936.6106.16.camel@moby> References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <200808132004.24869.mtinka@globaltransit.net> <6B43981C32F8464CB24CEE209DA32BD3016D84C0@kenya.tronet.as> <1219992936.6106.16.camel@moby> Message-ID: <6B43981C32F8464CB24CEE209DA32BD30175B4C2@kenya.tronet.as> are you using ES20's? beware of CSCsm61571 -- deejay > -----Original Message----- > From: Liviu Pislaru [mailto:liviu.pislaru at gmail.com] > Sent: 29 August 2008 08:56 > To: Tomas Daniska > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] SRB4 (was RE: SRC2?) > > hi, > > i'm running SRB4 on WS-SUP720-3BXL & WS-F6700-DFC3CXL linecards. > > i was running SRB2, hit some BUGs and had to option: > > 1. upgrade to SRB4 > 2. downgrade to SRA7 (change DFC3CXL linecards) > > i went for option 1. and everything is working fine now except my logs > are full of these lines: > > Aug 29 09:45:59 EETDST: %DIAG-SP-3-TEST_SKIPPED: Module 7: > TestFabricFlowControlStatus{ID=33} is skipped > > Aug 29 09:46:01 EETDST: %DIAG-SP-3-TEST_SKIPPED: Module 7: > TestFabricFlowControlStatus{ID=33} is skipped > > > [...] > > 7 2 Supervisor Engine 720 (Hot) WS-SUP720-3BXL > SAL09412THT > 8 2 Supervisor Engine 720 (Active) WS-SUP720-3BXL > SAL09368YPZ > [...] > > > > i'm not worried (yet) because cisco says: > > ===================================================================== > > %DIAG-3-TEST_SKIPPED (x1): [chars]: [chars]{ID=[dec]} is skipped > > Explanation: The specified diagnostic test cannot be run. > > Recommended Action: None. Although the test cannot be run, this message > does > not indicate a problem. > > ===================================================================== > > or > > ===================================================================== > > %DIAG-3-TEST_SKIPPED (x0): [chars]: [chars]{ID=[dec]} is skipped > > Explanation: This message indicates that the diagnostic test cannot be > run. > > Recommended Action: No action is required. The system is working > properly. > > ===================================================================== > > but i had to filter these lines from my logs. > > i'm running BGP (full bgp table), MPLS, OSPF, MULTICAST on this router. > so i'm pretty pleased with SRB4 until now. > > -- > liviu. > > On Wed, 2008-08-13 at 14:58 +0200, Tomas Daniska wrote: > > speaking of the releases... is anyone running SRB4 in production yet? > > > > cheers > > > > -- > > > > deejay > > > > > > > -----Original Message----- > > > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > > > bounces at puck.nether.net] On Behalf Of Mark Tinka > > > Sent: 13 August 2008 14:04 > > > To: cisco-nsp at puck.nether.net > > > Subject: Re: [c-nsp] SRC2? > > > > > > On Tuesday 12 August 2008 23:32:42 Chris Griffin wrote: > > > > > > > Anyone know when 12.2(33)SRC2 is supposed to be released, > > > > specifically for the 7600. I had heard by the end of > > > > July, but so far no release. > > > > > > Same here... heard it was meant to be mid-July, but nothing > > > yet. > > > > > > Having waited this long, it'll come when it comes, I > > > guess :-). > > > > > > Cheers, > > > > > > Mark. > > _______________________________________________ > > 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 tbeecher at localnet.com Tue Sep 2 09:08:46 2008 From: tbeecher at localnet.com (Thomas Beecher) Date: Tue, 02 Sep 2008 09:08:46 -0400 Subject: [c-nsp] PA-POS-OC3SMI vs. PA-POS-OC3SML In-Reply-To: <200808291454.03298.kratzers@pa.net> References: <200808291454.03298.kratzers@pa.net> Message-ID: <48BD3ADE.3060405@localnet.com> Stephen- If L3 is handing this OC3 off to you inside your building, the SMI card is fine. It's technically rated at 9 miles between stations, so unless you're farther than that from the hand off, you're all set. Stephen Kratzer wrote: > All, > > We're looking to turn up an OC3 with Level3, but we've been unable to get a > hardware recommendation from them. All we know is that it'll be single mode > using SC connectors. Is the PA-POS-OC3SMI a safe bet, or do we need to get > distance information and purchase accordingly? Thanks. > > Stephen Kratzer > Network Engineer > CTI Networks, Inc. > _______________________________________________ > 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/ > -- Thomas Beecher II Senior Network Administrator LocalNet Corp. CoreComm Internet Services tbeecher at localnet.com From tdurack at gmail.com Tue Sep 2 09:09:18 2008 From: tdurack at gmail.com (Tim Durack) Date: Tue, 2 Sep 2008 09:09:18 -0400 Subject: [c-nsp] SUP720-3B / 3rd party CF Message-ID: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> This is a mystery to me: I've got a few new VS-S720-10G-3C Sups that work just fine with Kingston 1GB CF. I've also got some old SUP720-3Bs that refuse to recognise anything other than Cisco CF. Tried formatting, upgrading rommon (8.5(2)), dd'ing Cisco flash to Kingston etc. This is under 12.2(33)SXH2 in case it makes a difference. Googling around and checking cisco-nsp archives suggest 3rd party flash should work just fine with the 3B. Anyone else run into this? Tim:> From maillist at webjogger.net Tue Sep 2 09:13:12 2008 From: maillist at webjogger.net (Adam Greene) Date: Tue, 2 Sep 2008 09:13:12 -0400 Subject: [c-nsp] PPP Multilink with L2TP interfaces References: Message-ID: <011e01c90cfd$a7003e40$12140a0a@GINKGO> Nic, Not familiar with L2TP in particular, but working with MLPPP in other contexts, it is usually necessary to specify a multilink group; i.e. everywhere you have the "ppp multilink" command you may need a corresponding "ppp multilink group 1" command, to put all the links in the same bundle. Also, I don't see a multilink interface in your configurations, but again that might be because with L2TP it's not required. However, something to consider. Thanks, Adam ----- Original Message ----- From: "Nic Tjirkalli" To: Sent: Monday, September 01, 2008 2:20 AM Subject: [c-nsp] PPP Multilink with L2TP interfaces > > howdy ho, > > i am trying to get a CPE to > 1) fire up a PPPoE session over an Ethernet interface to bring up a > Dialer1 > interface > 2) over this interface, fire up 2 L2TP sessions (Virtual-PPP1 and > Virtual-PPP2 and put these in a multilink bundel) > The L2TP tunnels are terminating on 196.30.121.42 > > Now all works well except for the Multilink PPP part. the 2 L2TP sessions > come up individual but there is no sign of any attempt to multilink > (nothing seen in any debug ppp multilink) > > I have included my current config > > if anybody can tell me if what i am trying to do is even possible and how > to fix my config i would be very happy and thankful > > thanx in advance > > > =================== CPE configuration ============================= > Current configuration : 3481 bytes > ! > version 12.4 > no service timestamps debug uptime > no service timestamps log uptime > service password-encryption > ! > hostname l2tp-multilink > ! > boot-start-marker > boot-end-marker > ! > logging buffered 4096 debugging > enable secret 5 $1$8ZOc$o9WmyJlHqGd1R8E/iYAR0/ > ! > no aaa new-model > ip cef > ! > ! > ! > ! > no ip domain lookup > ip auth-proxy max-nodata-conns 3 > ip admission max-nodata-conns 3 > vpdn enable > ! > l2tp-class l2tpclass1 > authentication > password 7 15115E0B2C7221027123 > ! > ! > multilink virtual-template 1 > ! > ! > no crypto engine onboard 0 > ! > ! > pseudowire-class pwclass1 > encapsulation l2tpv2 > protocol l2tpv2 l2tpclass1 > ip local interface Dialer1 > ! > pseudowire-class pwclass2 > encapsulation l2tpv2 > protocol l2tpv2 l2tpclass1 > ip local interface Dialer1 > ! > ! ! > ! > ! > interface Loopback0 > ip address 172.16.1.1 255.255.255.255 > ! > interface Null0 > no ip unreachables > ! > interface FastEthernet0/0 > no ip address > speed 100 > full-duplex > pppoe enable group global > pppoe-client dial-pool-number 1 > ! > interface FastEthernet0/1 > no ip address > duplex auto > speed auto > ! > interface Virtual-PPP1 > ip address negotiated > ip mtu 1452 > ip virtual-reassembly > no logging event link-status > no peer neighbor-route > no cdp enable > ppp chap hostname testuser1 > ppp chap password 7 XXXXXXXX > ppp pap sent-username testuser1 password 7 XXXXXXXX > ppp multilink > pseudowire 196.30.121.42 10 pw-class pwclass1 > ! > interface Virtual-Template1 > ip unnumbered Loopback0 > ppp multilink > ! > interface Virtual-PPP2 > ip address negotiated > ip mtu 1452 > ip virtual-reassembly > no logging event link-status > no peer neighbor-route > no cdp enable > ppp chap hostname testuser2 > ppp chap password 7 XXXXXXX > ppp pap sent-username testuser2 password 7 XXXXXXX > ppp multilink > pseudowire 196.30.121.42 100 pw-class pwclass2 > ! > interface Dialer1 > mtu 1492 > ip address negotiated > ip virtual-reassembly > encapsulation ppp > ip tcp adjust-mss 1452 > dialer pool 1 > dialer-group 1 > ppp chap hostname testuser1 > ppp chap password 7 XXXXXXXX > ppp pap sent-username testuser1 password 7 XXXXXXXX > ! > no ip forward-protocol nd > ip route 0.0.0.0 0.0.0.0 Virtual-PPP1 > ip route 196.30.121.42 255.255.255.255 Dialer1 > ! > ! > ip http server > no ip http secure-server > ! > ip access-list extended check_packets_in > permit ahp any any > permit esp any any > permit udp any eq isakmp any eq isakmp > permit ip any any > ! > access-list 1 permit any > access-list 2 deny any > access-list 3 permit 10.0.0.2 > access-list 3 permit 206.64.200.15 > access-list 3 permit 196.22.64.194 > access-list 3 permit 10.222.0.1 > access-list 3 permit 10.222.0.2 > access-list 3 permit 10.244.0.2 > no cdp run > ! > ! > ! > ! > control-plane > ! > ! > banner motd ^CC > ################################################################## > # You Should Not Be Here - Logg Off Imediately Thankyou # > # # > # # > ################################################################## > ^C > ! > line con 0 > exec-timeout 0 0 > line aux 0 > exec-timeout 0 0 > line vty 0 4 > access-class 3 in > exec-timeout 0 0 > password 7 1315181718 > login > line vty 5 8 > exec-timeout 0 0 > no login > line vty 9 15 > no login > ! > scheduler allocate 20000 1000 > end > > l2tp-multilink# > > > > --------------------------------------------------------------------- > I like you. You remind me of when I was young and stupid. > > Nic Tjirkalli > Verizon Business South Africa > Network Strategy Team > > Verizon Business is a brand of Verizon South Africa (Pty) Ltd. This e-mail > is strictly confidential and intended only for use by the addressee unless > otherwise indicated. > > Company Information:http:// www.verizonbusiness.com/za/contact/legal/ > > This e-mail is strictly confidential and intended only for use by the > addressee unless otherwise indicated. > > _______________________________________________ > 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 ml at t-b-o-h.net Tue Sep 2 09:38:28 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Tue, 2 Sep 2008 09:38:28 -0400 (EDT) Subject: [c-nsp] How they do that? Message-ID: <200809021338.m82DcS56015726@himinbjorg.tucs-beachin-obx-house.com> Hi, Not a Cisco specific question, but thought this group would have the best insight. After 10 hours on the road, I'm more dopey than usual. Pull into a Marriott, and of course the first thing I do is hook the laptop up. Normally, during the FreeBSD boot process I stop it and switch the config over from a hardcoded IP/gateway (For use at home/office... I need to be DMZ'd for somet things, so the IP is static) to DHCP. Wasn't thinking straight and let it boot. Oddly, it resolved all my NTP servers, but then couldn't sync NTP time. Weird. My browser autostarts when I bring up X, and all of a sudden its on the Marriott site and asking me to validate I really want to use the net for free. I click it, and I'm good to go. So, I wonder if I just happen to use the same range, and oddly the same gateway (Non standard) as the hotel. I don't think anything of it. I go to dinner, come back, and notice on my console its complaining : Sep 2 09:12:58 himinbjorg kernel: Sep 2 09:12:58 himinbjorg kernel: arplookup 192.168.50.1 failed: host is not on local network I do a tcpdump and notice all sorts of IPs being handled by the 192.168.50.1 .... 10.'s, 172.'s, etc. I even see : 09:32:49.870101 CDPv2, ttl: 180s, Device-ID 'SW1_MDF', length 351 So how is this possible? Is there a protocol or something I haven't heard of? How would it know where my default gateway is? (Maybe just reply to every ARP with the 192.168.50.1 address? Sorta looks it.. I just ping'd something that doesn't exist, and got : ? (192.168.3.23) at 00:08:02:3e:b3:0f on xl0 [ethernet] Oddly an entry for 192.168.3.1 exists, which I would never ping for. Guess it tried to force a gateway on me. :) Then maybe when it gets a packet, it inspects it. If it is going to a real net address it plays gateway, if it isn't it just drops it? Thanks, Tuc Thanks, Tuc From MatlockK at exempla.org Tue Sep 2 10:14:01 2008 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Tue, 2 Sep 2008 08:14:01 -0600 Subject: [c-nsp] How they do that? In-Reply-To: <200809021338.m82DcS56015726@himinbjorg.tucs-beachin-obx-house.com> References: <200809021338.m82DcS56015726@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7037AF7B6@LMC-MAIL2.exempla.org> Sounds like the hotel is doing 2 things: 1) Proxy-arp on the router, giving you the MAC of the router when asking for something outside of what it has configured or layer 3. Whatever is doing the proxy arp must also be paying attention to who made the request, and forwarding the return traffic to you as layer 2. 2) Captive portal, there's a local dns 'server' there letting you resolve addresses, but won't allow any real traffic to flow through until you 'accept' the Terms of Service. (Fairly common setup these days at hospitals). Ken Matlock Network Analyst (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 Tuc at T-B-O-H.NET Sent: Tuesday, September 02, 2008 7:38 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] How they do that? Hi, Not a Cisco specific question, but thought this group would have the best insight. After 10 hours on the road, I'm more dopey than usual. Pull into a Marriott, and of course the first thing I do is hook the laptop up. Normally, during the FreeBSD boot process I stop it and switch the config over from a hardcoded IP/gateway (For use at home/office... I need to be DMZ'd for somet things, so the IP is static) to DHCP. Wasn't thinking straight and let it boot. Oddly, it resolved all my NTP servers, but then couldn't sync NTP time. Weird. My browser autostarts when I bring up X, and all of a sudden its on the Marriott site and asking me to validate I really want to use the net for free. I click it, and I'm good to go. So, I wonder if I just happen to use the same range, and oddly the same gateway (Non standard) as the hotel. I don't think anything of it. I go to dinner, come back, and notice on my console its complaining : Sep 2 09:12:58 himinbjorg kernel: Sep 2 09:12:58 himinbjorg kernel: arplookup 192.168.50.1 failed: host is not on local network I do a tcpdump and notice all sorts of IPs being handled by the 192.168.50.1 .... 10.'s, 172.'s, etc. I even see : 09:32:49.870101 CDPv2, ttl: 180s, Device-ID 'SW1_MDF', length 351 So how is this possible? Is there a protocol or something I haven't heard of? How would it know where my default gateway is? (Maybe just reply to every ARP with the 192.168.50.1 address? Sorta looks it.. I just ping'd something that doesn't exist, and got : ? (192.168.3.23) at 00:08:02:3e:b3:0f on xl0 [ethernet] Oddly an entry for 192.168.3.1 exists, which I would never ping for. Guess it tried to force a gateway on me. :) Then maybe when it gets a packet, it inspects it. If it is going to a real net address it plays gateway, if it isn't it just drops it? Thanks, Tuc Thanks, Tuc _______________________________________________ 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 Tue Sep 2 10:20:14 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 02 Sep 2008 16:20:14 +0200 (CEST) Subject: [c-nsp] How they do that? In-Reply-To: <200809021338.m82DcS56015726@himinbjorg.tucs-beachin-obx-house.com> References: <200809021338.m82DcS56015726@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <20080902.162014.74741570.sthaug@nethelp.no> > So how is this possible? Is there a protocol or something I > haven't heard of? How would it know where my default gateway is? > (Maybe just reply to every ARP with the 192.168.50.1 address? Sorta > looks it.. I just ping'd something that doesn't exist, and got : > > ? (192.168.3.23) at 00:08:02:3e:b3:0f on xl0 [ethernet] > > Oddly an entry for 192.168.3.1 exists, which I would never > ping for. Guess it tried to force a gateway on me. :) It's called proxy ARP, and is on by default on Cisco routers (and switches with routing functionality). It's a horrible default, and leads to all sorts of "interesting" problems. Proxy ARP: Just say no. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From ross at kallisti.us Tue Sep 2 10:38:36 2008 From: ross at kallisti.us (Ross Vandegrift) Date: Tue, 2 Sep 2008 10:38:36 -0400 Subject: [c-nsp] SNMP access to err-disable on 2960s In-Reply-To: <6de481d10808300907q6dec809cveb35a84be0e10f7e@mail.gmail.com> References: <20080829140205.GA14820@kallisti.us> <6de481d10808300907q6dec809cveb35a84be0e10f7e@mail.gmail.com> Message-ID: <20080902143836.GB17734@kallisti.us> On Sat, Aug 30, 2008 at 09:07:28AM -0700, John Jensen wrote: > Have you tried looking at the CISCO-ERR-DISABLE-MIB file? > > You can download it here: > > ftp://ftp-sj.cisco.com/pub/mibs/v2/CISCO-ERR-DISABLE-MIB.my Somehow that was missing from the pack of Cisco MIBs I downloaded and pull my MIBs from. It looks perfect, but isn't supported on any of my 2960s, 3750s, or 6500s. Bah, what a load a crap. Ross -- Ross Vandegrift ross at kallisti.us "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 From jeff.nsp at gmail.com Tue Sep 2 10:46:25 2008 From: jeff.nsp at gmail.com (Jeff Tantsura) Date: Tue, 2 Sep 2008 16:46:25 +0200 Subject: [c-nsp] Interdomain Multicast Routing In-Reply-To: <465d309c0809011949k2beb5eb7qda9a6d022aed36ce@mail.gmail.com> References: <465d309c0809010048j1a5f5fbaja2bad4b1b07dfd3f@mail.gmail.com> <000601c90c0f$764584c0$650c10ac@ad.redback.com> <465d309c0809011949k2beb5eb7qda9a6d022aed36ce@mail.gmail.com> Message-ID: <003501c90d0a$adbabbe0$6602a8c0@ad.redback.com> Hi, I don't see any development on BGMP. For IPv4 multicast PIM ASM/SSM +MSDP (mBGP) is the way to go. Here and there you'd see some enhancements, mostly vendor specific, dual PIM join on Redback is a good example. On the other hand there's a lot happening in MPLS multicast: P2MP RSVP, mLDP, NG mVPN, you name it. Cheers, Jeff _____ From: Muarwi [mailto:muarwi at gmail.com] Sent: dinsdag 2 september 2008 4:49 To: Jeff Tantsura Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Interdomain Multicast Routing Hi Jeff, thanks a lot for your response. Then how about BGMP (RFC 3913) ? Is it still a proposed protocol? Thanks . On 9/1/08, Jeff Tantsura wrote: Hi, The combination you've described has been working for many years, very well tested, supported by all major vendors. PIM (bidir as well) is used for intradomain multicast routing independently of interdomain multicast (MSDP/MBGP). Cisco does support PIM Bidir Cheers, Jeff P.S. Best book ever - "Interdomain Mutlicast Routing" by Edwards/Giuliano/Wright > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Muarwi > Sent: maandag 1 september 2008 9:49 > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] Interdomain Multicast Routing > > Hi guys, I'm sorry if my questions is rather out of cisco's things. > > I've read books about interdomain multicast routing (also one from cisco > press). From what I get, the solutions offered is PIM SM - MBGP - MSDP. > > My questions is : > 1. what about using PIM Bidir for interdomain multicast? Is it possible to > implement it in Cisco? > 2. Has BGMP been being implemented in vendors? > > Thanks a lot for your response > _______________________________________________ > 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 Sep 2 10:53:56 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Tue, 02 Sep 2008 16:53:56 +0200 Subject: [c-nsp] SUP720-3B / 3rd party CF In-Reply-To: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> References: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> Message-ID: <1220367236.17820.3.camel@abehat> On Tue, 2008-09-02 at 09:09 -0400, Tim Durack wrote: > This is a mystery to me: > > I've got a few new VS-S720-10G-3C Sups that work just fine with Kingston 1GB > CF. I've also got some old SUP720-3Bs that refuse to recognise anything > other than Cisco CF. Tried formatting, upgrading rommon (8.5(2)), dd'ing > Cisco flash to Kingston etc. This is under 12.2(33)SXH2 in case it makes a > difference. > > Googling around and checking cisco-nsp archives suggest 3rd party flash > should work just fine with the 3B. > > Anyone else run into this? According to the data sheet[1] the Sup720 only supports up to 512MB flash. We use 512MB cards in a range of 6500s with Sup720 HW-revisions 2.1, 4.3 and 5.2 without problems. Haven't tried 1GB though. Regards, Peter From tdurack at gmail.com Tue Sep 2 11:20:33 2008 From: tdurack at gmail.com (Tim Durack) Date: Tue, 2 Sep 2008 11:20:33 -0400 Subject: [c-nsp] SUP720-3B / 3rd party CF In-Reply-To: <1220367236.17820.3.camel@abehat> References: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> <1220367236.17820.3.camel@abehat> Message-ID: <9e246b4d0809020820ld27c0a4g945413166a2d9606@mail.gmail.com> That's true, but the Cisco 1GB CF I borrowed from a S720-10G for a test seems to work okay. So I'm still scratching my head. At this point I'm probably going to spring for the Cisco CF, but I'd rather know that I could mix-n-match. Tim:> On Tue, Sep 2, 2008 at 10:53 AM, Peter Rathlev wrote: > On Tue, 2008-09-02 at 09:09 -0400, Tim Durack wrote: > > This is a mystery to me: > > > > I've got a few new VS-S720-10G-3C Sups that work just fine with Kingston > 1GB > > CF. I've also got some old SUP720-3Bs that refuse to recognise anything > > other than Cisco CF. Tried formatting, upgrading rommon (8.5(2)), dd'ing > > Cisco flash to Kingston etc. This is under 12.2(33)SXH2 in case it makes > a > > difference. > > > > Googling around and checking cisco-nsp archives suggest 3rd party flash > > should work just fine with the 3B. > > > > Anyone else run into this? > > According to the data sheet[1] the Sup720 only supports up to 512MB > flash. We use 512MB cards in a range of 6500s with Sup720 HW-revisions > 2.1, 4.3 and 5.2 without problems. Haven't tried 1GB though. > > Regards, > Peter > > > From adrian.minta at gmail.com Tue Sep 2 12:02:08 2008 From: adrian.minta at gmail.com (Adrian Minta) Date: Tue, 02 Sep 2008 19:02:08 +0300 Subject: [c-nsp] RES: Cisco Catalyst 6513 IOS version In-Reply-To: <20080902062732.GU233@greenie.muc.de> References: <48B520CE.7030008@actrix.co.nz> <48B5602E.7010705@imperial.ac.uk> <079b01c90970$092d2330$f211a8c0@flamadam> <20080829072040.GD27310@lboro.ac.uk> <48BC0B53.4040000@imperial.ac.uk> <20080901154700.GB24224@lboro.ac.uk> <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> <20080902062732.GU233@greenie.muc.de> Message-ID: <48BD6380.6050309@gmail.com> Gert Doering wrote: > Hi, > > On Mon, Sep 01, 2008 at 11:15:13PM -0400, Pete S. wrote: > >> The biggest running issue I have with SXH, >> > > My biggest issues are: > > - no BFD on SVIs (worked fine in SXF) > > - the BGP ghost bug is back :-( > (SXH3 regularily forgets to send withdraws to iBGP peers if a prefix > completely disappears. During the course of 4 weeks, I have observed > it twice, once for IPv4 and once for IPv6, without actually *looking* > for it - so it's likely happening much more often) > > Yes, the nasty BGP bug is present. The only "solution" seems to be a periodically "clear ip bgp all". Cisco IOS Software, s6523_rp Software (s6523_rp-ADVIPSERVICESK9-M), Version 12.2(33)SXH3, RELEASE SOFTWARE (fc1) -- Best regards, Adrian Minta From peter at rathlev.dk Tue Sep 2 12:09:12 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Tue, 02 Sep 2008 18:09:12 +0200 Subject: [c-nsp] SUP720-3B / 3rd party CF In-Reply-To: <1220367236.17820.3.camel@abehat> References: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> <1220367236.17820.3.camel@abehat> Message-ID: <1220371752.19570.1.camel@abehat> On Tue, 2008-09-02 at 16:53 +0200, Peter Rathlev wrote: > According to the data sheet[1] the Sup720 only supports up to 512MB > flash. We use 512MB cards in a range of 6500s with Sup720 HW-revisions > 2.1, 4.3 and 5.2 without problems. Haven't tried 1GB though. The data sheet ([1]) would of course be found here: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a0080159856.html Regards, Peter From jared at puck.nether.net Tue Sep 2 12:27:32 2008 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 2 Sep 2008 12:27:32 -0400 Subject: [c-nsp] SUP720-3B / 3rd party CF In-Reply-To: <9e246b4d0809020820ld27c0a4g945413166a2d9606@mail.gmail.com> References: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> <1220367236.17820.3.camel@abehat> <9e246b4d0809020820ld27c0a4g945413166a2d9606@mail.gmail.com> Message-ID: <20080902162732.GB1967@puck.nether.net> On Tue, Sep 02, 2008 at 11:20:33AM -0400, Tim Durack wrote: > That's true, but the Cisco 1GB CF I borrowed from a S720-10G for a test > seems to work okay. So I'm still scratching my head. > > At this point I'm probably going to spring for the Cisco CF, but I'd rather > know that I could mix-n-match. Depending on your IOS version, it may make a difference, as well as the monlib on the CF. Make sure you format the devices in the router to insure there are limited/no problems. We have 1G CF cards working fine. In recent IOS versions you ca obtain detailed flash information. I recommend SanDisk. I've not tested over 1G CF cards, but running with SXF and SXH we seem to have no issue. If someone from TAC wants to try to counterpost that a "unsupported" CF card will violate our warranty or any other garbage like that, Please notify me when the PMs decide to ship sufficently sized CF to support the devices to provide core dumps for developers. - Jared Router#show disk0 all -#- --length-- -----date/time------ path 2 1 Jan 1 1980 HA:HA:HA s72033 946323456 bytes available (78217216 bytes used) ******** ATA Flash Card Geometry/Format Info ******** ATA CARD GEOMETRY Manufacturer Name SanDisk Model Number SanDisk SDCFB-1024 Serial Number SECURED Firmware Revision HDX 4.03 Number of Heads 16 Number of Cylinders 1986 Sectors per Cylinder 63 Sector Size 512 Total Sectors 2001888 ATA PARTITION 1 INFO Start Sector 63 Number of Sectors 2001825 Size in Bytes 1024934400 File System Type FAT16 Number of FAT Sectors 245 Sectors Per Cluster 32 Number of Clusters 62533 Number of Data Sectors 2001056 Base FAT Sector 108 Base Root Sector 598 Base Data Sector 630 ATA MONLIB INFO Image Monlib size 69912 Disk Monlib Size 53880 Disk Space Available 54784 Name NA End Sector NA Start sector NA Updated By NA Version NA RFS VERSION : Negotiated Version : 0 Highest version supported in Server : 0 Highest version supported in Client : 0 -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From gert at greenie.muc.de Tue Sep 2 13:12:59 2008 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 2 Sep 2008 19:12:59 +0200 Subject: [c-nsp] RES: Cisco Catalyst 6513 IOS version In-Reply-To: <48BD6380.6050309@gmail.com> References: <48B520CE.7030008@actrix.co.nz> <48B5602E.7010705@imperial.ac.uk> <079b01c90970$092d2330$f211a8c0@flamadam> <20080829072040.GD27310@lboro.ac.uk> <48BC0B53.4040000@imperial.ac.uk> <20080901154700.GB24224@lboro.ac.uk> <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> <20080902062732.GU233@greenie.muc.de> <48BD6380.6050309@gmail.com> Message-ID: <20080902171259.GB233@greenie.muc.de> Hi, On Tue, Sep 02, 2008 at 07:02:08PM +0300, Adrian Minta wrote: > > - the BGP ghost bug is back :-( > > Yes, the nasty BGP bug is present. The only "solution" seems to be a > periodically "clear ip bgp all". > Cisco IOS Software, s6523_rp Software (s6523_rp-ADVIPSERVICESK9-M), > Version 12.2(33)SXH3, RELEASE SOFTWARE (fc1) Gah. For me, "clear ip bgp soft *" seems also to have helped, but still, this is no way to run an ISP... Do you have a bug ID or a TAC case # for this? (I currently can't open cases for the boxes in question, as our gold partner is unable to get the contracts sorted out, but "soon!"). 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: 304 bytes Desc: not available URL: From gschwim at gmail.com Tue Sep 2 13:22:54 2008 From: gschwim at gmail.com (Greg Schwimer) Date: Tue, 2 Sep 2008 10:22:54 -0700 Subject: [c-nsp] Running MPLS across non-MPLS networks Message-ID: <702ea15b0809021022j613a61a8sb05aa687c3f8f1ba@mail.gmail.com> I have a situation where I need to run MPLS across a non-MPLS network (the Internet) to connect two of my networks together. We have looked at GRE, but ran into issues and were later told by Cisco that running MPLS over GRE is unsupported. Any ideas as to a solution to this problem, aside from purchasing a third-party service (circuit, etc)? Greg From adrian.minta at gmail.com Tue Sep 2 13:33:08 2008 From: adrian.minta at gmail.com (Adrian Minta) Date: Tue, 02 Sep 2008 20:33:08 +0300 Subject: [c-nsp] RES: Cisco Catalyst 6513 IOS version In-Reply-To: <20080902171259.GB233@greenie.muc.de> References: <48B520CE.7030008@actrix.co.nz> <48B5602E.7010705@imperial.ac.uk> <079b01c90970$092d2330$f211a8c0@flamadam> <20080829072040.GD27310@lboro.ac.uk> <48BC0B53.4040000@imperial.ac.uk> <20080901154700.GB24224@lboro.ac.uk> <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> <20080902062732.GU233@greenie.muc.de> <48BD6380.6050309@gmail.com> <20080902171259.GB233@greenie.muc.de> Message-ID: <48BD78D4.6010405@gmail.com> Gert Doering wrote: > Hi, > > On Tue, Sep 02, 2008 at 07:02:08PM +0300, Adrian Minta wrote: > >>> - the BGP ghost bug is back :-( >>> >> Yes, the nasty BGP bug is present. The only "solution" seems to be a >> periodically "clear ip bgp all". >> Cisco IOS Software, s6523_rp Software (s6523_rp-ADVIPSERVICESK9-M), >> Version 12.2(33)SXH3, RELEASE SOFTWARE (fc1) >> > > Gah. For me, "clear ip bgp soft *" seems also to have helped, but still, > this is no way to run an ISP... > > Do you have a bug ID or a TAC case # for this? (I currently can't open > cases for the boxes in question, as our gold partner is unable to get the > contracts sorted out, but "soon!"). > > gert > Not yet. Until today I considered this an isolated incident. Next time when the bug will strike I will for sure. -- Best regards, Adrian Minta From dudepron at gmail.com Tue Sep 2 14:15:12 2008 From: dudepron at gmail.com (Aaron) Date: Tue, 2 Sep 2008 14:15:12 -0400 Subject: [c-nsp] Running MPLS across non-MPLS networks In-Reply-To: <702ea15b0809021022j613a61a8sb05aa687c3f8f1ba@mail.gmail.com> References: <702ea15b0809021022j613a61a8sb05aa687c3f8f1ba@mail.gmail.com> Message-ID: <480dad640809021115m4d74887cx57c2d7f75138cddd@mail.gmail.com> l2tpv3 On Tue, Sep 2, 2008 at 1:22 PM, Greg Schwimer wrote: > I have a situation where I need to run MPLS across a non-MPLS network (the > Internet) to connect two of my networks together. We have looked at GRE, > but ran into issues and were later told by Cisco that running MPLS over GRE > is unsupported. > > Any ideas as to a solution to this problem, aside from purchasing a > third-party service (circuit, etc)? > > Greg > _______________________________________________ > 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 Sep 2 14:33:22 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 02 Sep 2008 19:33:22 +0100 Subject: [c-nsp] Leaky SoO Message-ID: Hi, I'm seeing leaky SoO in 12.4M (prefixes get advertised back to sites with same SoO they came from), possibly down to CSCek73579, I notice there are no first-fixed-in 12.4M or 12.2SB targets, would somebody on here from cisco mind taking a look at the internal notes and tell me if this bug applies to normal BGP setups (i.e with no EIGRP) and if so, when I could expect a fix in 12.4M or 12.2SB ? Many thanks David Freedman From tdurack at gmail.com Tue Sep 2 14:48:40 2008 From: tdurack at gmail.com (Tim Durack) Date: Tue, 2 Sep 2008 14:48:40 -0400 Subject: [c-nsp] SUP720-3B / 3rd party CF In-Reply-To: <20080902162732.GB1967@puck.nether.net> References: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> <1220367236.17820.3.camel@abehat> <9e246b4d0809020820ld27c0a4g945413166a2d9606@mail.gmail.com> <20080902162732.GB1967@puck.nether.net> Message-ID: <9e246b4d0809021148g745983d1rd5ff4a6cd84b304d@mail.gmail.com> Hmm. I've got a handful of Kingston cards that work on both 3B/3C and a handful that work only on 3C. Those that don't work give an error on read/format: %Error show disk0: (no such device) Tim:> On Tue, Sep 2, 2008 at 12:27 PM, Jared Mauch wrote: > On Tue, Sep 02, 2008 at 11:20:33AM -0400, Tim Durack wrote: > > That's true, but the Cisco 1GB CF I borrowed from a S720-10G for a test > > seems to work okay. So I'm still scratching my head. > > > > At this point I'm probably going to spring for the Cisco CF, but I'd > rather > > know that I could mix-n-match. > > Depending on your IOS version, it may make a difference, as well as > the monlib on the CF. Make sure you format the devices in the router to > insure there are limited/no problems. > > We have 1G CF cards working fine. In recent IOS versions you ca > obtain > detailed flash information. I recommend SanDisk. I've not tested over 1G > CF > cards, but running with SXF and SXH we seem to have no issue. > > If someone from TAC wants to try to counterpost that a "unsupported" > CF card will violate our warranty or any other garbage like that, Please > notify me when the PMs decide to ship sufficently sized CF to support > the devices to provide core dumps for developers. > > - Jared > > > Router#show disk0 all > -#- --length-- -----date/time------ path > 2 1 Jan 1 1980 HA:HA:HA s72033 > > 946323456 bytes available (78217216 bytes used) > > ******** ATA Flash Card Geometry/Format Info ******** > > ATA CARD GEOMETRY > Manufacturer Name SanDisk > Model Number SanDisk SDCFB-1024 > Serial Number SECURED > Firmware Revision HDX 4.03 > Number of Heads 16 > Number of Cylinders 1986 > Sectors per Cylinder 63 > Sector Size 512 > Total Sectors 2001888 > > ATA PARTITION 1 INFO > Start Sector 63 > Number of Sectors 2001825 > Size in Bytes 1024934400 > File System Type FAT16 > Number of FAT Sectors 245 > Sectors Per Cluster 32 > Number of Clusters 62533 > Number of Data Sectors 2001056 > Base FAT Sector 108 > Base Root Sector 598 > Base Data Sector 630 > > ATA MONLIB INFO > Image Monlib size 69912 > Disk Monlib Size 53880 > Disk Space Available 54784 > Name NA > End Sector NA > Start sector NA > Updated By NA > Version NA > > RFS VERSION : > Negotiated Version : 0 > Highest version supported in Server : 0 > Highest version supported in Client : 0 > > > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only mine. > From sethm at rollernet.us Tue Sep 2 15:07:34 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 02 Sep 2008 12:07:34 -0700 Subject: [c-nsp] IPv6 ACL question for the 3750 Message-ID: <48BD8EF6.6080800@rollernet.us> I'm playing with IPv6 on a 3750. Looking at the release notes for 12.2(46)SE, I see the following limitation for IPv6 access lists: * The switch does not support output port ACLs. It's currently running 12.2(25)SEE and I tested statements like "permit tcp any host x:x:x:x:2d0:b7ff:fee6:574 eq 80" that work fine, but that limitation (which does not appear in the release notes for 12.2(25)SEE) lead me to believe this capability was dropped. Is this true, or am I misreading it? Or am I stuck with jumping all the way to a 6500/Sup720 to get decent (i.e. complete) IPv6 support? ~Seth From cboyd at gizmopartners.com Tue Sep 2 15:46:04 2008 From: cboyd at gizmopartners.com (Chris Boyd) Date: Tue, 2 Sep 2008 14:46:04 -0500 Subject: [c-nsp] How they do that? In-Reply-To: <200809021338.m82DcS56015726@himinbjorg.tucs-beachin-obx-house.com> References: <200809021338.m82DcS56015726@himinbjorg.tucs-beachin-obx-house.com> Message-ID: On Sep 2, 2008, at 8:38 AM, Tuc at T-B-O-H.NET wrote: > Hi, > > Not a Cisco specific question, but thought this group > would have the best insight. > > After 10 hours on the road, I'm more dopey than usual. Pull > into a Marriott, and of course the first thing I do is hook the laptop > up. Normally, during the FreeBSD boot process I stop it and switch the > config over from a hardcoded IP/gateway (For use at home/office... I > need to be DMZ'd for somet things, so the IP is static) to DHCP. > Wasn't > thinking straight and let it boot. Since some have replied about proxy arp and the like, I'll go ahead and reply to the list. It's more complicated than that. Many hotels use a device from Nomadix http://www.nomadix.com/ (now part of DoCoMo). It's a supercharged packet munger that can take almost any end station config and rewrite the headers to get you connected to the outside world, usually after redirecting an HTTP session to the clickthrough "Don't Be Evil" agreement, credit card info collection etc. Very effective and flexible. --Chris From avayner at cisco.com Tue Sep 2 16:25:11 2008 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Tue, 2 Sep 2008 22:25:11 +0200 Subject: [c-nsp] Leaky SoO In-Reply-To: References: Message-ID: <67F7C1FAF83A074AA3520D8F155782A501C9E062@xmb-ams-331.emea.cisco.com> David, This seems to be an EIGRP related bug. I sent a quick note to the DE regarding the fix in the listed releases... Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman Sent: Tuesday, September 02, 2008 21:33 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Leaky SoO Hi, I'm seeing leaky SoO in 12.4M (prefixes get advertised back to sites with same SoO they came from), possibly down to CSCek73579, I notice there are no first-fixed-in 12.4M or 12.2SB targets, would somebody on here from cisco mind taking a look at the internal notes and tell me if this bug applies to normal BGP setups (i.e with no EIGRP) and if so, when I could expect a fix in 12.4M or 12.2SB ? Many thanks David Freedman _______________________________________________ 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 daniel.voyer at bell.ca Tue Sep 2 16:54:23 2008 From: daniel.voyer at bell.ca (daniel.voyer at bell.ca) Date: Tue, 2 Sep 2008 16:54:23 -0400 Subject: [c-nsp] Problem with the mailing list In-Reply-To: <70B7A1CCBFA5C649BD562B6D9F7ED78405F396A2@xmb-ams-333.emea.cisco.com> References: <70B7A1CCBFA5C649BD562B6D9F7ED78405F396A2@xmb-ams-333.emea.cisco.com> Message-ID: <52D7E1CAB4BB0B4EA26C12C51BA771E309AF4B7315@MBX03.bell.corp.bce.ca> Hello, Why do I get every mails in double ? In a week, I get 10131 mails. - dan From howard at leadmon.net Tue Sep 2 17:00:24 2008 From: howard at leadmon.net (Howard Leadmon) Date: Tue, 2 Sep 2008 17:00:24 -0400 Subject: [c-nsp] Cisco ACNS Query regarding negative caching? Message-ID: <016d01c90d3e$ee65eb40$cb31c1c0$@net> I know I don't see much on ACNS here, but was hoping someone might have worked with the ACNS software more than I have, as it's pretty new to me. I have a Content Engine 590 here I am working with, running ACNS 5.9.11, using WCCPv2, and overall it's working well. The problem I am running into is if it sends a request, and that request fails, it seems to cache that request for like 15 min before it will even attempt it again. So for example I was reading a forum remotely, was doing great, and apparently it missed a response, and that was it, it wouldn't even try the forum again till that negative response timed/aged out. I turned off the proxy redirect and all would work fine, turn it back on and dead. Once the negative response aged out things were normal again. Is there some setting to tell it if it gets a negative response to always retry if requested again? I have looked at the config and reference guides from Cisco, and though I can set a ton of stuff, I haven't found a way to stop this behavior. Anyone have any ideas, or clues on how to change this action by the Content Engine? --- Howard Leadmon From apiasecki at gmail.com Tue Sep 2 19:36:58 2008 From: apiasecki at gmail.com (Adam Piasecki) Date: Tue, 2 Sep 2008 19:36:58 -0400 Subject: [c-nsp] How they do that? In-Reply-To: References: <200809021338.m82DcS56015726@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <345400390809021636o1bb0d04aof4e79cde11e836a9@mail.gmail.com> IP3 http://www.ip3.com/ is also a big one that does this type of stuff. I would say 90% of laptop users who travel, know they need to change to a dynamic IP & DNS. This whole hacking the way IP works, really sucks. It leads to all sorts of weird problems, Just to save you a couple of support calls. From mtinka at globaltransit.net Tue Sep 2 21:25:01 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 3 Sep 2008 09:25:01 +0800 Subject: [c-nsp] SUP720-3B / 3rd party CF In-Reply-To: <1220367236.17820.3.camel@abehat> References: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> <1220367236.17820.3.camel@abehat> Message-ID: <200809030925.01720.mtinka@globaltransit.net> On Tuesday 02 September 2008 22:53:56 Peter Rathlev wrote: > According to the data sheet[1] the Sup720 only supports > up to 512MB flash. We use 512MB cards in a range of 6500s > with Sup720 HW-revisions 2.1, 4.3 and 5.2 without > problems. Haven't tried 1GB though. When we were upgrading from the SUP2 to the SUP720, we told Cisco we'd use the IBM 1GB compact flash modules unless they gave us something similar. In the end, Cisco shipped our SUP720's with Cisco-branded 1GB compact flash cards (external). However, the internal flash card remains at 512MB, which is fine with us: #sh file systems * 1024589824 944439296 disk rw disk0:# 512024576 398319616 disk rw sup-bootdisk: sup-bootflash:# 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 jlewis at lewis.org Tue Sep 2 22:09:46 2008 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 2 Sep 2008 22:09:46 -0400 (EDT) Subject: [c-nsp] SUP720-3B / 3rd party CF In-Reply-To: <200809030925.01720.mtinka@globaltransit.net> References: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> <1220367236.17820.3.camel@abehat> <200809030925.01720.mtinka@globaltransit.net> Message-ID: On Wed, 3 Sep 2008, Mark Tinka wrote: > On Tuesday 02 September 2008 22:53:56 Peter Rathlev wrote: > >> According to the data sheet[1] the Sup720 only supports >> up to 512MB flash. We use 512MB cards in a range of 6500s >> with Sup720 HW-revisions 2.1, 4.3 and 5.2 without >> problems. Haven't tried 1GB though. > > When we were upgrading from the SUP2 to the SUP720, we told > Cisco we'd use the IBM 1GB compact flash modules unless > they gave us something similar. > > In the end, Cisco shipped our SUP720's with Cisco-branded > 1GB compact flash cards (external). However, the internal > flash card remains at 512MB, which is fine with us: If you search the archive, you'll find some posts from me about using 2gb and 4gb cards in sup720-3bxls. The 2's work properly. The 4's have an apparently cosmetic size reporting overflow. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ariemer at wesenergy.com.au Wed Sep 3 05:05:31 2008 From: ariemer at wesenergy.com.au (Aaron Riemer) Date: Wed, 3 Sep 2008 17:05:31 +0800 Subject: [c-nsp] 6500 WS-SUP32-GE-3B failure Message-ID: <0867622C64B50C4B878AB45C95F43F1106124A09@MAILWA01.wesenergy.local> Hey guys, We currently have a WS-SUP32-GE-3B where the SFP ports are not coming online. Is there a test that can be run from the switch to detect if there is a hardware failure? A sh module indicates that the SUP is ok.. We are thinking about reseating the SUP as it is in hot standby with another identical SUP and then possibly rebooting before lodging a TAC case. Any suggestions welcome :-) Cheers, Aaron. LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From tomas at soitron.com Wed Sep 3 05:08:02 2008 From: tomas at soitron.com (Tomas Daniska) Date: Wed, 3 Sep 2008 11:08:02 +0200 Subject: [c-nsp] How they do that? In-Reply-To: <345400390809021636o1bb0d04aof4e79cde11e836a9@mail.gmail.com> References: <200809021338.m82DcS56015726@himinbjorg.tucs-beachin-obx-house.com> <345400390809021636o1bb0d04aof4e79cde11e836a9@mail.gmail.com> Message-ID: <6B43981C32F8464CB24CEE209DA32BD30175B5DC@kenya.tronet.as> Leaving the signup/billing page and access control aside, most of the SOHO gateway products do this. I've noticed it first on my home ZyXEL accidentally when messing with my gf's notebook IP config - she had a static 10.x.x.x assignment and the home network is of course 192.168.1.0. Try this at home if you like :) -- deejay > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Adam Piasecki > Sent: 03 September 2008 01:37 > To: Chris Boyd > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] How they do that? > > IP3 http://www.ip3.com/ is also a big one that does this type of stuff. > > I would say 90% of laptop users who travel, know they need to change to a > dynamic IP & DNS. This whole hacking the way IP works, really sucks. It > leads to all sorts of weird problems, Just to save you a couple of support > calls. > _______________________________________________ > 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 Wed Sep 3 05:24:01 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Wed, 3 Sep 2008 10:24:01 +0100 Subject: [c-nsp] SUP720-3B / 3rd party CF In-Reply-To: <1220367236.17820.3.camel@abehat> References: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> <1220367236.17820.3.camel@abehat> Message-ID: <20080903092401.GB32609@wildfire.net.ic.ac.uk> On Tue, Sep 02, 2008 at 04:53:56PM +0200, Peter Rathlev wrote: >On Tue, 2008-09-02 at 09:09 -0400, Tim Durack wrote: >> This is a mystery to me: >> >> I've got a few new VS-S720-10G-3C Sups that work just fine with Kingston 1GB >> CF. I've also got some old SUP720-3Bs that refuse to recognise anything >> other than Cisco CF. Tried formatting, upgrading rommon (8.5(2)), dd'ing >> Cisco flash to Kingston etc. This is under 12.2(33)SXH2 in case it makes a >> difference. >> >> Googling around and checking cisco-nsp archives suggest 3rd party flash >> should work just fine with the 3B. >> >> Anyone else run into this? > >According to the data sheet[1] the Sup720 only supports up to 512MB >flash. We use 512MB cards in a range of 6500s with Sup720 HW-revisions >2.1, 4.3 and 5.2 without problems. Haven't tried 1GB though. We've got non-Cisco 1Gb cards in 3Bs under SXF and SXH2a - sup hardware versions are 4.4, rommon 8.1(3) However we've also had some other 1Gb CF fail, which I think might have been kingston. We didn't look into it in too much detail, just dropped back to 512Mb. > >Regards, >Peter > > >_______________________________________________ >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 djweis at internetsolver.com Wed Sep 3 06:46:48 2008 From: djweis at internetsolver.com (Dave Weis) Date: Wed, 03 Sep 2008 05:46:48 -0500 Subject: [c-nsp] ME3400 DC Power Message-ID: <48BE6B18.2050804@internetsolver.com> Do I need to supply both power supplies with an A&B side for redundancy or will I have redundancy if I have the A side of PS1 and PS2 connected? Thanks dave -- Dave Weis Internet Solver Your Technology Partner 515-224-9229 www.internetsolver.com From david.freedman at uk.clara.net Wed Sep 3 08:01:27 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 3 Sep 2008 13:01:27 +0100 Subject: [c-nsp] Leaky SoO References: <67F7C1FAF83A074AA3520D8F155782A501C9E062@xmb-ams-331.emea.cisco.com> Message-ID: Ok, thanks, the problem I'm seeing follows, note that am not using as-override but instead "allow-as in" on the CE router, I have a very specific reason for doing this (I'm preserving the AS_PATH but instead using SoO to do some site based filtering) It seems not to work, as you can see in my example, the prefix coming from a remote CE with same SoO (10.1.0.0/16) is advertised to my CE (10.12.75.128)... PE (12.4(12)): router bgp 1234 ! ! address-family ipv4 vrf FOO ! neighbor 10.12.75.158 remote-as 65489 neighbor 10.12.75.158 version 4 neighbor 10.12.75.158 activate neighbor 10.12.75.158 soft-reconfiguration inbound neighbor 10.12.75.158 route-map do_stuff in neighbor 10.12.75.158 next-hop-self exit-address-family ! route-map do_stuff permit 5 match ip address prefix-list some_prefixes_a set local-preference 200 set extcommunity soo 65489:5 ! route-map do_stuff permit 10 match ip address prefix-list some_prefixes_b set extcommunity soo 65489:5 ! pe# sh ip bgp v vrf FOO nei 10.12.75.158 | in SoO Site-of-Origin is SoO:65489:5 pe# sh ip bgp v vrf FOO 10.1.0.0/16 BGP routing table entry for 10.1.0.0/16, version 21 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 2 65489 1.1.1.1 from 1.1.1.1 (10.12.1.50) Origin incomplete, metric 0, localpref 200, valid, internal, best Extended Community: SoO:65489:5 pe#sh ip ro v FOO 10.1.0.0 Routing entry for 10.1.0.0/16 Known via "bgp 1234", distance 200, metric 0 Tag 65489, type internal Last update from 1.1.1.1 00:24:24 ago Routing Descriptor Blocks: * 1.1.1.1, from 1.1.1.1, 00:24:24 ago Route metric is 0, traffic share count is 1 AS Hops 1 Route tag 65489 pe#sh ip bgp v vrf FOO nei 10.12.75.158 adv | in 10.1.0.0 *>i10.1.0.0/16 1.1.1.1 0 200 0 65489 ? CE (12.4(12)): ce# sh ip bgp 10.1.0.0/16 BGP routing table entry for 10.1.0.0/16, version 23 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 1234 65489, (received & used) 10.12.75.157 from 10.12.75.157 (2.2.2.2) Origin incomplete, localpref 100, valid, external, best ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: Arie Vayner (avayner) [mailto:avayner at cisco.com] Sent: Tue 9/2/2008 21:25 To: David Freedman; cisco-nsp at puck.nether.net Subject: RE: [c-nsp] Leaky SoO David, This seems to be an EIGRP related bug. I sent a quick note to the DE regarding the fix in the listed releases... Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman Sent: Tuesday, September 02, 2008 21:33 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Leaky SoO Hi, I'm seeing leaky SoO in 12.4M (prefixes get advertised back to sites with same SoO they came from), possibly down to CSCek73579, I notice there are no first-fixed-in 12.4M or 12.2SB targets, would somebody on here from cisco mind taking a look at the internal notes and tell me if this bug applies to normal BGP setups (i.e with no EIGRP) and if so, when I could expect a fix in 12.4M or 12.2SB ? Many thanks David Freedman _______________________________________________ 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 Wed Sep 3 08:26:15 2008 From: tdurack at gmail.com (Tim Durack) Date: Wed, 3 Sep 2008 08:26:15 -0400 Subject: [c-nsp] SUP720-3B / 3rd party CF In-Reply-To: <20080903092401.GB32609@wildfire.net.ic.ac.uk> References: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> <1220367236.17820.3.camel@abehat> <20080903092401.GB32609@wildfire.net.ic.ac.uk> Message-ID: <9e246b4d0809030526s701ffe00q85eab2291152fafb@mail.gmail.com> I've been digging around and it looks like the culprit might be the manufacturer string reported by the cf. Old Kingston's report as Toshiba, whereas new report as Kingston. Old work in the 3Bs only, new work in 3B/3C. My guess is the cf/ata adapter on the 3Bs doesn't recognise the new string as being a valid cf. Tim:> On Wed, Sep 3, 2008 at 5:24 AM, Phil Mayers wrote: > On Tue, Sep 02, 2008 at 04:53:56PM +0200, Peter Rathlev wrote: > >> On Tue, 2008-09-02 at 09:09 -0400, Tim Durack wrote: >> >>> This is a mystery to me: >>> >>> I've got a few new VS-S720-10G-3C Sups that work just fine with Kingston >>> 1GB >>> CF. I've also got some old SUP720-3Bs that refuse to recognise anything >>> other than Cisco CF. Tried formatting, upgrading rommon (8.5(2)), dd'ing >>> Cisco flash to Kingston etc. This is under 12.2(33)SXH2 in case it makes >>> a >>> difference. >>> >>> Googling around and checking cisco-nsp archives suggest 3rd party flash >>> should work just fine with the 3B. >>> >>> Anyone else run into this? >>> >> >> According to the data sheet[1] the Sup720 only supports up to 512MB >> flash. We use 512MB cards in a range of 6500s with Sup720 HW-revisions >> 2.1, 4.3 and 5.2 without problems. Haven't tried 1GB though. >> > > We've got non-Cisco 1Gb cards in 3Bs under SXF and SXH2a - sup hardware > versions are 4.4, rommon 8.1(3) > > However we've also had some other 1Gb CF fail, which I think might have > been kingston. We didn't look into it in too much detail, just dropped back > to 512Mb. > > >> Regards, >> Peter >> >> >> _______________________________________________ >> 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.nsp at gmail.com Wed Sep 3 08:55:06 2008 From: jeff.nsp at gmail.com (Jeff Tantsura) Date: Wed, 3 Sep 2008 14:55:06 +0200 Subject: [c-nsp] Running MPLS across non-MPLS networks In-Reply-To: <702ea15b0809021022j613a61a8sb05aa687c3f8f1ba@mail.gmail.com> References: <702ea15b0809021022j613a61a8sb05aa687c3f8f1ba@mail.gmail.com> Message-ID: <000001c90dc4$4abb26a0$650c10ac@ad.redback.com> L2TPv3? > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Greg Schwimer > Sent: dinsdag 2 september 2008 19:23 > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] Running MPLS across non-MPLS networks > > I have a situation where I need to run MPLS across a non-MPLS network (the > Internet) to connect two of my networks together. We have looked at GRE, > but ran into issues and were later told by Cisco that running MPLS over > GRE > is unsupported. > > Any ideas as to a solution to this problem, aside from purchasing a > third-party service (circuit, etc)? > > Greg > _______________________________________________ > 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 Wed Sep 3 09:16:12 2008 From: justin at justinshore.com (Justin Shore) Date: Wed, 03 Sep 2008 08:16:12 -0500 Subject: [c-nsp] SUP720-3B / 3rd party CF In-Reply-To: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> References: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> Message-ID: <48BE8E1C.90304@justinshore.com> Tim Durack wrote: > This is a mystery to me: > > I've got a few new VS-S720-10G-3C Sups that work just fine with Kingston 1GB > CF. I've also got some old SUP720-3Bs that refuse to recognise anything > other than Cisco CF. Tried formatting, upgrading rommon (8.5(2)), dd'ing > Cisco flash to Kingston etc. This is under 12.2(33)SXH2 in case it makes a > difference. > > Googling around and checking cisco-nsp archives suggest 3rd party flash > should work just fine with the 3B. > > Anyone else run into this? I run $10 1GB Kingstons in all our equipment, from ISRs to our Sup720-3BXLs. They work great. My ISRs all run 12.4T releases and my Sup720s currently run SRB. Justin From tdurack at gmail.com Wed Sep 3 09:33:23 2008 From: tdurack at gmail.com (Tim Durack) Date: Wed, 3 Sep 2008 09:33:23 -0400 Subject: [c-nsp] SUP720-3B / 3rd party CF In-Reply-To: <48BE8E1C.90304@justinshore.com> References: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> <48BE8E1C.90304@justinshore.com> Message-ID: <9e246b4d0809030633h15911927p465f8071f1bf1424@mail.gmail.com> And that's what I'm trying to do, but apparently not all Kingston cf is created equal. My guess is if you do a "show disk0: all" the Kingston cf will show up as a Toshiba something or other. Tim:> On Wed, Sep 3, 2008 at 9:16 AM, Justin Shore wrote: > Tim Durack wrote: > >> This is a mystery to me: >> >> I've got a few new VS-S720-10G-3C Sups that work just fine with Kingston >> 1GB >> CF. I've also got some old SUP720-3Bs that refuse to recognise anything >> other than Cisco CF. Tried formatting, upgrading rommon (8.5(2)), dd'ing >> Cisco flash to Kingston etc. This is under 12.2(33)SXH2 in case it makes a >> difference. >> >> Googling around and checking cisco-nsp archives suggest 3rd party flash >> should work just fine with the 3B. >> >> Anyone else run into this? >> > > I run $10 1GB Kingstons in all our equipment, from ISRs to our > Sup720-3BXLs. They work great. My ISRs all run 12.4T releases and my > Sup720s currently run SRB. > > Justin > > From dan at beanfield.com Wed Sep 3 09:09:45 2008 From: dan at beanfield.com (Dan Armstrong) Date: Wed, 03 Sep 2008 09:09:45 -0400 Subject: [c-nsp] ME3400 DC Power In-Reply-To: <48BE6B18.2050804@internetsolver.com> References: <48BE6B18.2050804@internetsolver.com> Message-ID: <48BE8C99.2010500@beanfield.com> The power supplies on the ME3400s have 2 inputs, for "breaker" redundancy.. some models have to physical power supplies, some have only one - in all cases, each supply has 2 inputs. If your model has 2 power supplies, you can hookup just the A side of each unit, and you'll be fine. Dave Weis wrote: > > Do I need to supply both power supplies with an A&B side for > redundancy or will I have redundancy if I have the A side of PS1 and > PS2 connected? > > Thanks > > dave > > From frnkblk at iname.com Wed Sep 3 12:56:16 2008 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 3 Sep 2008 11:56:16 -0500 Subject: [c-nsp] How they do that? In-Reply-To: <6B43981C32F8464CB24CEE209DA32BD30175B5DC@kenya.tronet.as> References: <200809021338.m82DcS56015726@himinbjorg.tucs-beachin-obx-house.com> <345400390809021636o1bb0d04aof4e79cde11e836a9@mail.gmail.com> <6B43981C32F8464CB24CEE209DA32BD30175B5DC@kenya.tronet.as> Message-ID: Please quantify "most". That's not been my experience. Frank -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tomas Daniska Sent: Wednesday, September 03, 2008 4:08 AM To: Adam Piasecki; Chris Boyd Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] How they do that? Leaving the signup/billing page and access control aside, most of the SOHO gateway products do this. I've noticed it first on my home ZyXEL accidentally when messing with my gf's notebook IP config - she had a static 10.x.x.x assignment and the home network is of course 192.168.1.0. Try this at home if you like :) -- deejay > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Adam Piasecki > Sent: 03 September 2008 01:37 > To: Chris Boyd > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] How they do that? > > IP3 http://www.ip3.com/ is also a big one that does this type of stuff. > > I would say 90% of laptop users who travel, know they need to change to a > dynamic IP & DNS. This whole hacking the way IP works, really sucks. It > leads to all sorts of weird problems, Just to save you a couple of support > calls. > _______________________________________________ > 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 tomz at cisco.com Wed Sep 3 13:21:59 2008 From: tomz at cisco.com (Tom Zingale (tomz)) Date: Wed, 3 Sep 2008 10:21:59 -0700 Subject: [c-nsp] IPv6 ACL question for the 3750 In-Reply-To: <48BD8EF6.6080800@rollernet.us> References: <48BD8EF6.6080800@rollernet.us> Message-ID: The 3750 does not support Ipv6 output port ACL's but does support output router ACL's. You need the advanced IP Services IOS feature set for output router ACL's. > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Seth Mattinen > Sent: Tuesday, September 02, 2008 12:08 PM > To: cisco-nsp > Subject: [c-nsp] IPv6 ACL question for the 3750 > > I'm playing with IPv6 on a 3750. Looking at the release notes for > 12.2(46)SE, I see the following limitation for IPv6 access lists: > > * The switch does not support output port ACLs. > > It's currently running 12.2(25)SEE and I tested statements like "permit > tcp any host x:x:x:x:2d0:b7ff:fee6:574 eq 80" that work fine, but that > limitation (which does not appear in the release notes for 12.2(25)SEE) > lead me to believe this capability was dropped. Is this true, or am I > misreading it? > > Or am I stuck with jumping all the way to a 6500/Sup720 to get decent > (i.e. complete) IPv6 support? > > ~Seth > _______________________________________________ > 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 Sep 3 13:15:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wednesday, 03 September 2008 12:15:00 -0500 Subject: [c-nsp] Cisco Security Advisory: Remote Access VPN and SIP Vulnerabilities in Cisco PIX and Cisco ASA Message-ID: <20080903121500.pixasa@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Remote Access VPN and SIP Vulnerabilities in Cisco PIX and Cisco ASA Advisory ID: cisco-sa-20080903-asa Revision 1.0 For Public Release 2008 September 3 1600 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Multiple vulnerabilities exist in the Cisco ASA 5500 Series Adaptive Security Appliances and Cisco PIX Security Appliances that may result in a reload of the device or disclosure of confidential information. This security advisory outlines details of the following vulnerabilities: * Erroneous SIP Processing Vulnerabilities * IPSec Client Authentication Processing Vulnerability * SSL VPN Memory Leak Vulnerability * URI Processing Error Vulnerability in SSL VPNs * Potential Information Disclosure in Clientless VPNs Note: These vulnerabilities are independent of each other. A device may be affected by one vulnerability and not affected by another. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. This advisory is posted at: http://www.cisco.com/warp/public/707/cisco-sa-20080903-asa.shtml Affected Products ================= The following paragraphs describe the affected Cisco ASA and Cisco PIX software versions: Vulnerable Products +------------------ The following sections provide details on the versions of Cisco ASA that are affected by each vulnerability. The show version command-line interface (CLI) command can be used to determine if a vulnerable version of the Cisco PIX or Cisco ASA software is running. The following example shows a Cisco ASA device that runs software release 8.0(2): ASA# show version Cisco Adaptive Security Appliance Software Version 8.0(2) Device Manager Version 6.0(1) [...] Customers who use the Cisco Adaptive Security Device Manager (ASDM) to manage their devices can find their software version displayed in a table in the login window or in the upper left corner of the ASDM window. Erroneous SIP Processing Vulnerabilities Cisco PIX and Cisco ASA devices configured for SIP inspection are vulnerable to multiple processing errors that may result in denial of service attacks. Cisco PIX and ASA software versions prior to 7.0(7) 16, 7.1(2)71, 7.2(4)7, 8.0(3)20, and 8.1(1)8 are vulnerable to these SIP processing errors. IPSec Client Authentication Processing Vulnerability Cisco PIX and Cisco ASA devices that terminate remote access VPN connections are vulnerable to a denial of service attack if the device is running software versions prior to 7.2(4)2, 8.0(3)14, and 8.1(1)4. Cisco PIX and Cisco ASA devices that run software versions 7.0 and 7.1 are not affected by this vulnerability. SSL VPN Memory Leak Vulnerability Cisco ASA devices that terminate clientless remote access VPN connections are vulnerable to a denial of service attack affecting the SSL processing software if the device is running a software version prior to 7.2(4)2, 8.0(3)14, or 8.1(1)4. Cisco ASA devices that run software versions 7.0 and 7.1 are not affected by this vulnerability. URI Processing Error Vulnerability in SSL VPNs Cisco ASA devices that terminate clientless remote access VPN connections are vulnerable to a denial of service attack in the HTTP server if the device is running software versions prior to 8.0(3)15, and 8.1(1)5. Cisco ASA devices that run software versions 7.0, 7.1, or 7.2 are not affected by this vulnerability. Potential Information Disclosure in Clientless VPNs Cisco ASA devices that terminate clientless remote access VPN connections are vulnerable to potential information disclosure if the device is running affected 8.0 or 8.1 software versions. Cisco ASA devices running software versions 7.0, 7.1, or 7.2 are not affected by this vulnerability. Cisco ASA devices the run software versions prior to 8.0(3)15 and 8.1(1)4, or after 8.0(3)16 and 8.1(1)5 are also not affected by this vulnerability. Products Confirmed Not Vulnerable +-------------------------------- The Cisco Firewall Services Module (FWSM) is not affected by any of these vulnerabilities. Cisco PIX security appliances running software versions 6.x are not vulnerable. IOS, IOS XR, and Cisco Unified Boarder Elements (CUBE) are not vulnerable to these issues. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= The following sections provide details to help determine if a device may be affected by any of the vulnerabilities. Erroneous SIP Processing Vulnerabilities Cisco PIX and Cisco ASA devices configured for SIP inspection are vulnerable to multiple processing errors that may result in denial of service attacks. All Cisco PIX and Cisco ASA software releases may be vulnerable to these SIP processing vulnerabilities. A successful attack may result in a reload of the device. SIP inspection is enabled with the inspect sip command. To determine whether the Cisco PIX or Cisco ASA security appliance is configured to support inspection of sip packets, log in to the device and issue the CLI command show service-policy | include sip. If the output contains the text Inspect: sip and some statistics, then the device has a vulnerable configuration. The following example shows a vulnerable Cisco ASA Security Appliance: asa#show service-policy | include sip Inspect: sip, packet 0, drop 0, reset-drop 0 asa# These vulnerability is documented in the following Cisco Bug IDs and has been assigned Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-2732. * CSCsq07867 * CSCsq57091 * CSCsk60581 * CSCsq39315 IPSec Client Authentication Processing Vulnerability Cisco PIX and Cisco ASA devices configured to terminate client based VPN connections are vulnerable to a crafted authentication processing vulnerability if they are running software versions 7.2, 8.0, or 8.1. Devices that run software versions 7.0 or 7.1 are not affected by this vulnerability. A successful attack may result in a reload of the device. Remote access VPN connections will have Internet Security Association and Key Management Protocol (ISAKMP) enabled on an interface with the crypto command, such as: crypto isakmp enable outside. This vulnerability is documented in Cisco Bug ID CSCso69942 and has been assigned Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-2733. SSL VPN Memory Leak Vulnerability and URI Processing Error Vulnerability in SSL VPNs A crafted SSL or HTTP packet may cause a denial of service condition on a Cisco ASA device that is configured to terminate clientless VPN connections. A successful attack may result in a reload of the device. Cisco ASA devices that run versions 7.2, 8.0, or 8.1 with clientless SSL VPNs enabled may be affected by this vulnerability. Devices that run software versions 7.0 and 7.1 are not affected by this vulnerability. Clientless VPN, SSL VPN Client, and AnyConnect connections are enabled via the webvpn command. For example, the following configuration shows a Cisco ASA with Clientless VPNs configured and enabled. In this case the ASA will listen for VPN connections on the default port, TCP port 443: http server enable ! webvpn enable outside Note that with this particular configuration, the device is vulnerable to attacks coming from the outside interface due to the enable outside command within the webvpn group configuration. These vulnerabilities are documented in Cisco Bug ID CSCso66472 and CSCsq19369. They have been assigned Common Vulnerabilities and Exposures (CVE) identifiers CVE-2008-2734 and CVE-2008-2735. Potential Information Disclosure in Clientless VPNs On Cisco ASA devices configured to terminate clientless VPN connections, an attacker may be able to discover potentially sensitive information such as usernames and passwords. This attack requires an attacker to convince a user to visit a rogue web server, reply to an e-mail, or interact with a service to successfully exploit the vulnerability. Cisco ASA devices running software versions 8.0 or 8.1 with clientless VPNs enabled may be affected by this vulnerability. Cisco ASA devices running that run software versions 7.0, 7.1, or 7.2 are not vulnerable to this vulnerability. Clientless SSL VPN connections are enabled via the webvpn command. For example, the following configuration shows a Cisco ASA device with Clientless VPNs configured and enabled. In this case the Cisco ASA device will listen for VPN connections on the default port, TCP port 443: http server enable ! webvpn enable outside Note that with this particular configuration, the device is vulnerable to attacks coming from the outside interface due to the enable outside command within the webvpn group configuration. This vulnerability is documented in Cisco Bug ID CSCsq45636 and has been assigned Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-2736. 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 calculated 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 Erroneous SIP Processing Vulnerabilities CSCsq07867 - Memory corruption with traceback in SIP inspection code CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official Fix Report Confidence - Confirmed CSCsq57091 - Memory corruption and traceback when inspecting malformed SIP packets 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 CSCsk60581 - Device reload possible when SIP inspection is enabled 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 CSCsq39315 - Traceback when processing malformed SIP requests 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 IPSec Client Authentication Processing Vulnerability CSCso69942 - Traceback in Remote Access Authentication Code CVSS Base Score - 6.8 Access Vector - Network Access Complexity - Low Authentication - Single Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 5.6 Exploitability - Functional Remediation Level - Official Fix Report Confidence - Confirmed SSL VPN Memory Leak Vulnerability CSCso66472 - Crypto memory leak causing Clientless SSL VPNs to hang 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 URI Processing Error Vulnerability in SSL VPNs CSCsq19369 - URI Processing Error in Clientless SSL VPN connections 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 Potential Information Disclosure in Clientless VPNs CSCsq45636 - Potential Information Disclosure in Clientless SSL VPNs CVSS Base Score - 7.1 Access Vector - Network Access Complexity - Medium Authentication - None Confidentiality Impact - Complete Integrity Impact - None Availability Impact - None CVSS Temporal Score - 5.9 Exploitability - Functional Remediation Level - Official Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the Erroneous SIP Processing Vulnerabilities, IPSec Client Authentication Processing Vulnerability, SSL VPN Memory Leak Vulnerability, or URI Processing Error Vulnerability in SSL VPNs may result in the device reloading. This can be repeatedly exploited and may lead to a denial of service attack. The Potential Information Disclosure in Clientless SSL VPNs vulnerability may allow an attacker to obtain user and group credentials if the user interacts with a rogue system or document. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. The following list contains the first fixed software release of each vulnerability: +-----------------------------------------------------+ | | | Affected | First | | Vulnerability | Bug ID | Release | Fixed | | | | | Release | |----------------+------------+----------+------------| | | | 7.0 | 7.0(7)15 | | | |----------+------------| | | | 7.1 | 7.1(2)70 | |Memory | |----------+------------| | corruption | | 7.2 | Not | | with traceback | CSCsq07867 | | vulnerable | |in SIP | |----------+------------| | inspection | | 8.0 | Not | | code | | | vulnerable | | | |----------+------------| | | | 8.1 | Not | | | | | vulnerable | |----------------+------------+----------+------------| | | | 7.0 | Not | | | | | vulnerable | |Memory | |----------+------------| | corruption and | | 7.1 | Not | | traceback when | | | vulnerable | |inspecting |CSCsq57091 |----------+------------| | malformed SIP | | 7.2 | 7.2(4)7 | |packets | |----------+------------| | | | 8.0 | 8.0(3)20 | | | |----------+------------| | | | 8.1 | 8.1(1)8 | |----------------+------------+----------+------------| | | | 7.0 | Not | | | | | vulnerable | | | |----------+------------| | | | 7.1 | Not | | Device reload | | | vulnerable | |possible when |CSCsk60581 |----------+------------| | SIP inspection | | 7.2 | 7.2(3)18 | |is enabled | |----------+------------| | | | 8.0 | 8.0(3)8 | | | |----------+------------| | | | 8.1 | Not | | | | | vulnerable | |----------------+------------+----------+------------| | | | 7.0 | 7.0(7)16 | | | |----------+------------| | | | 7.1 | 7.1(2)71 | | | |----------+------------| | Traceback when | | 7.2 | Not | | processing | CSCsq39315 | | vulnerable | |malformed SIP | |----------+------------| | requests | | 8.0 | Not | | | | | vulnerable | | | |----------+------------| | | | 8.1 | Not | | | | | vulnerable | |----------------+------------+----------+------------| | | | 7.0 | Not | | | | | vulnerable | | | |----------+------------| | Traceback in | | 7.1 | Not | | Remote Access | | | vulnerable | |Authentication |CSCso69942 |----------+------------| | Code | | 7.2 | 7.2(4)2 | | | |----------+------------| | | | 8.0 | 8.0(3)14 | | | |----------+------------| | | | 8.1 | 8.1(1)4 | |----------------+------------+----------+------------| | | | 7.0 | Not | | | | | vulnerable | | | |----------+------------| | Crypto memory | | 7.1 | Not | | leak causing | | | vulnerable | |Clientless SSL |CSCso66472 |----------+------------| | VPNs to hang | | 7.2 | 7.2(4)2 | | | |----------+------------| | | | 8.0 | 8.0(3)14 | | | |----------+------------| | | | 8.1 | 8.1(1)4 | |----------------+------------+----------+------------| | | | 7.0 | Not | | | | | vulnerable | | | |----------+------------| | HTTP | | 7.1 | Not | | Processing | | | vulnerable | |Error in |CSCsq19369 |----------+------------| | Clientless SSL | | 7.2 | Not | | VPN | | | vulnerable | |connections | |----------+------------| | | | 8.0 | 8.0(3)15 | | | |----------+------------| | | | 8.1 | 8.1(1)5 | |----------------+------------+----------+------------| | | | 7.0 | Not | | | | | vulnerable | | | |----------+------------| | Potential | | 7.1 | Not | | Information | | | vulnerable | |Disclosure in |CSCsq45636 |----------+------------| | Clientless SSL | | 7.2 | Not | | VPNs | | | vulnerable | | | |----------+------------| | | | 8.0 | 8.0(3)16 | | | |----------+------------| | | | 8.1 | 8.1(1)6 | |-----------------------------+----------+------------| | | 7.0 | 7.0(7)16 | | |----------+------------| | | 7.1 | 7.1(2)72 | | |----------+------------| | Recommended Release | 7.2 | 7.2(4)9 | | |----------+------------| | | 8.0 | 8.0(4) | | |----------+------------| | | 8.1 | 8.1(1)8 | +-----------------------------------------------------+ Fixed Cisco PIX software can be downloaded from: http://www.cisco.com/pcgi-bin/tablebuild.pl/pix?psrtdcat20e2 Fixed Cisco ASA software can be downloaded from: http://www.cisco.com/pcgi-bin/tablebuild.pl/asa?psrtdcat20e2 Workarounds =========== The following workarounds may help some customers mitigate these vulnerabilities. Additional mitigation techniques that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory: http://www.cisco.com/warp/public/707/cisco-amb-20080903-asa.shtml Erroneous SIP Processing Vulnerabilities SIP inspection should be disabled if it is not needed and temporarily disabling the feature will mitigate the SIP processing vulnerabilities. SIP inspection can be disabled with the command no inspect sip. IPSec Authentication Processing Vulnerability Use strong group credentials for remote access VPN connections and do not give out the group credentials to end users. SSL VPN Memory Leak Vulnerability and URI Processing Error Vulnerability in SSL VPNs IPSec clients are not vulnerable to this issue and may be used in conjunction with strong group credentials until the device can be upgraded. Potential Information Disclosure in Clientless SSL VPNs Client based VPN connections are not vulnerable to the information disclosure vulnerability. If you are running 8.0(3)15, 8.0(3)16, 8.1(1)4, or 8.1(1)5, you may safely use client based VPN connections as an alternative to clientless VPNs. 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/products/prod_warranties_item09186a008088e31f.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/warp/public/687/Directory/DirTAC.shtml 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 reported to Cisco by customers that experienced these issues during normal operation of their equipment and through internal testing efforts. 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-20080903-asa.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 | 2008-Sept-03 | 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----- iD8DBQFIvsPo86n/Gc8U/uARAmOIAKCcTL2O+3w2mEm0GTe2mcnb0NZ5uQCdG9aV ldazcXFRcGmkm4g38B67ezM= =t2NV -----END PGP SIGNATURE----- From kunkel at w-link.net Wed Sep 3 13:58:35 2008 From: kunkel at w-link.net (Rick Kunkel) Date: Wed, 3 Sep 2008 10:58:35 -0700 (Pacific Daylight Time) Subject: [c-nsp] Dreaded FIB Exception on Sup2 Message-ID: Well, I've hit the dreaded error message on my Sup2: %MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched I've done a lot of reading on this (cisco.com, this list, etc.), with the conclusion that this supervisor engine is likely just at the end of its useful lifetime, but I figured I'd double check I wasn't missing anything. This happened when I started getting a full routing table from a provider today. We're connected to one peering point and another aggregation-style provider, and are in the process of adding a Cogent connection (hold any tempting comments on that one, please). Is there a "show" command I can use to find the usage in the TCAM? I can't seem to find a good one. SOme useful ones I've found for the Sup3 don't work on the Sup2 apparently. Some ones I've used to deduce what's going on though: ROUTER#show ip route sum IP routing table name is Default-IP-Routing-Table(0) Route Source Networks Subnets Overhead Memory (bytes) connected 1 6 448 1120 static 8 1 576 1440 eigrp 11 57 4352 10880 bgp 130170 133117 16850368 42131020 External: 263287 Internal: 0 Local: 0 internal 3190 3764200 Total 133380 133181 16855744 45908660 ROUTER#show ip cef sum IP Distributed CEF with switching (Table Version 641214), flags=0x0 263458 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 2992 263458 leaves, 14567 nodes, 50979968 bytes, 640846 inserts, 377388 invalidations 0 load sharing elements, 0 bytes, 0 references universal per-destination load sharing algorithm, id EB4814E6 3(0) CEF resets, 3 revisions of existing leaves Resolution Timer: Exponential (currently 1s, peak 2s) 3 in-place/0 aborted modifications refcounts: 4241756 leaf, 3729408 node Table epoch: 0 (263458 entries at this epoch) Adjacency Table has 71 adjacencies ROUTER#show mls cef sum Total CEF switched packets: 0000271471473221 Total CEF switched bytes: 0182929990663338 Total routes: 261865 IP unicast routes: 261865 IPX routes: 0 IP multicast routes: 0 Any thoughts? Am I simply SOL without a new Sup? I've heard tell of optimizing TCAM memory, but it would appear that maybe that wouldn't even cut the mustard with the amount of routes I'm dealing with maybe...(?) If I get full routes from two providers and a thousand or so routes form the peering point, AND have a 0.0.0.0/0 route out a preferred provider, could that cover my bases? One more thing. My show ver: ROUTER#show ver Cisco Internetwork Operating System Software IOS (tm) c6sup2_rp Software (c6sup2_rp-PSV-M), Version 12.1(26)E8, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2006 by cisco Systems, Inc. Compiled Fri 29-Dec-06 06:42 by hqluong Image text-base: 0x40008F90, data-base: 0x41856000 ROM: System Bootstrap, Version 12.2(17r)S1, RELEASE SOFTWARE (fc1) BOOTLDR: c6sup2_rp Software (c6sup2_rp-PSV-M), Version 12.1(26)E8, RELEASE SOFTWARE (fc1) ROUTER uptime is 37 weeks, 4 days, 6 hours, 54 minutes Time since ROUTER switched to active is 37 weeks, 4 days, 6 hours, 54 minutes System returned to ROM by power-on (SP by power-on) System restarted at 03:01:49 PST Sat Dec 15 2007 System image file is "sup-bootflash:c6sup22-psv-mz.121-26.E8.bin" cisco WS-C6509 (R7000) processor (revision 3.0) with 458752K/65536K bytes of memory. Processor board ID SAL0730H93F R7000 CPU at 300Mhz, Implementation 39, Rev 3.3, 256KB L2, 1024KB L3 Cache Last reset from power-on X.25 software, Version 3.0.0. Bridging software. 2 Virtual Ethernet/IEEE 802.3 interface(s) 48 FastEthernet/IEEE 802.3 interface(s) 10 Gigabit Ethernet/IEEE 802.3 interface(s) 381K bytes of non-volatile configuration memory. 32768K bytes of Flash internal SIMM (Sector size 512K). Configuration register is 0x2102 Thanks much! Rick Kunkel From CB at nianet.dk Wed Sep 3 14:22:19 2008 From: CB at nianet.dk (Christian Bering) Date: Wed, 3 Sep 2008 20:22:19 +0200 Subject: [c-nsp] Dreaded FIB Exception on Sup2 References: Message-ID: Hi Rick, >I've done a lot of reading on this (cisco.com, this list, >etc.), with the conclusion that this supervisor engine is >likely just at the end of its useful lifetime, If you need a full table then yes. >Is there a "show" command I can use to find the usage in >the TCAM? I think 'show mls cef maximum-routes' and 'show mls cef summary' work on a Sup2. >Any thoughts? Am I simply SOL without a new Sup? Yes. For a full table you need to upgrade to an RSP720-3CXL. -- Regards Christian Bering From gsgranados at comcast.net Wed Sep 3 14:31:13 2008 From: gsgranados at comcast.net (Scott Granados) Date: Wed, 3 Sep 2008 11:31:13 -0700 Subject: [c-nsp] Need pointers for configuring NAT on 1841 Message-ID: <010501c90df3$434c55e0$1b0310ac@ccntd1.covad.com> I have a DSL loop provisioned as follows. Via PPPOE I'm assigned a /30 that's allocated from unrouted addresses. I then am routed a public pool /29 in length via the /30. I'm using a Cisco 1841 with a WIC-1-ADSL card and 2 ethernet ports. On one of the LAN ports I have the /29. (This works) I'd like to set up nat on the other LAN port and I would assume that I would use one of my addresses from my /29 for the translation. I have the following config but can't figure out the NAT portion to add or find good examples via google. Any pointers would be appreciated or better still a pointer that could take me through the fundimentals (assuming my config will work at all). Thank you Scott ip dhcp pool lan network 192.168.13.0 255.255.255.0 default-router 192.168.13.1 ! multilink bundle-name authenticated vpdn enable ! vpdn-group 1 request-dialin protocol pppoe l2tp tunnel receive-window 1024 bba-group pppoe global ! ! interface FastEthernet0/0 ip address 192.168.13.1 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 ip address x.x.x.1 255.255.255.248 duplex auto speed auto ! interface ATM0/0/0 no ip address no atm ilmi-keepalive dsl operating-mode auto dsl enable-training-log pvc 0/35 encapsulation aal5snap pppoe-client dial-pool-number 1 ! interface Dialer1 ip address negotiated ip mtu 1492 encapsulation ppp no ip mroute-cache dialer pool 1 dialer-group 1 ppp authentication chap callin ppp chap hostname "YourNameHere at bz8" ppp chap password 0 "YourPassWord" ! ip route 0.0.0.0 0.0.0.0 Dialer1 ! From peter at rathlev.dk Wed Sep 3 15:22:03 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Wed, 03 Sep 2008 21:22:03 +0200 Subject: [c-nsp] 6500 WS-SUP32-GE-3B failure In-Reply-To: <0867622C64B50C4B878AB45C95F43F1106124A09@MAILWA01.wesenergy.local> References: <0867622C64B50C4B878AB45C95F43F1106124A09@MAILWA01.wesenergy.local> Message-ID: <1220469723.32656.3.camel@abehat> On Wed, 2008-09-03 at 17:05 +0800, Aaron Riemer wrote: > We currently have a WS-SUP32-GE-3B where the SFP ports are not coming > online. Is there a test that can be run from the switch to detect if > there is a hardware failure? A sh module indicates that the SUP is ok.. You could try the "diagnostic start module X test Y" commands. It can do some non-disruptive tests too. Regards, Peter From peter at rathlev.dk Wed Sep 3 15:26:44 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Wed, 03 Sep 2008 21:26:44 +0200 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: References: Message-ID: <1220470004.32656.7.camel@abehat> On Wed, 2008-09-03 at 10:58 -0700, Rick Kunkel wrote: > Any thoughts? Am I simply SOL without a new Sup? On Wed, 2008-09-03 at 20:22 +0200, Christian Bering wrote: > Yes. For a full table you need to upgrade to an RSP720-3CXL. And even the SUP720 can manage too, as long as it has the magic "XL" in the end. :-) Regards, Peter From c.spurgeon at mail.utexas.edu Wed Sep 3 15:07:50 2008 From: c.spurgeon at mail.utexas.edu (Charles Spurgeon) Date: Wed, 3 Sep 2008 14:07:50 -0500 Subject: [c-nsp] Crash bug in SXH3 In-Reply-To: <489B7063.8040904@imperial.ac.uk> References: <489B7063.8040904@imperial.ac.uk> Message-ID: <20080903190750.GA19777@argus.gw.utexas.edu> To which I will add another warning: there is also a fatal crash bug in SXH3 that is triggered by removing a route-map. The CSCsk21935 buginfo heading is: "Crash in ipfib_policy_forward after remove policy route-map" This bug is internally viewable only and we got the heading info from the TAC. It's apparently related to this publicly viewable bug: CSCsm75286 This bug in combination with an apparent hardware error on a Sup720 left one of our core routers equipped with dual sup720s crashed and sitting in rommon. We are informed that SXF code also has the route-map bug, but we have more confidence in that code (having removed route-maps in it many times without problems) so we have reverted to SXF6 while awaiting a new SXH build. -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking c.spurgeon at its.utexas.edu / 512.475.9265 On Thu, Aug 07, 2008 at 10:59:40PM +0100, Phil Mayers wrote: > All, > > Just a warning, there is a fatal crash bug in SXH3 related to using SCP. > Considering the release notes claim fixes in that very area, this is > highly amusing (note: issue may not actually be amusing) > > Does anyone else think the 6500 software train is becoming a bad joke? > SRC claims *today* ISSU using dual sups / SSO, a much larger chunk of > (33) features e.g. 6vpe etc. and one presumes a faster rate of ports > from mainline IOS because they don't need to modularise everything. > > SXH on the other hand has... erm... buggy modularity. And... buggy > monolithic too. > > I haven't got a TAC case open because we've rolled back to SXH2a (which > has its own set of crash bugs, but less frequent ones...) and it's late > - a task for tomorrow I feel. > _______________________________________________ > 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 CB at nianet.dk Wed Sep 3 15:53:02 2008 From: CB at nianet.dk (Christian Bering) Date: Wed, 3 Sep 2008 21:53:02 +0200 Subject: [c-nsp] Dreaded FIB Exception on Sup2 References: <1220470004.32656.7.camel@abehat> Message-ID: Hi, >>Yes. For a full table you need to upgrade to an RSP720-3CXL. >And even the SUP720 can manage too, as long as it has the >magic "XL" in the end. :-) Yeah but since the list price for the RSP720-3CXL is the same as the list price for the SUP720-3BXL, I don't see a reason not to go for the RSP. Does one exist? -- Regards Christian Bering From cchurc05 at harris.com Wed Sep 3 15:56:36 2008 From: cchurc05 at harris.com (Church, Charles) Date: Wed, 3 Sep 2008 14:56:36 -0500 Subject: [c-nsp] Crash bug in SXH3 In-Reply-To: <20080903190750.GA19777@argus.gw.utexas.edu> References: <489B7063.8040904@imperial.ac.uk> <20080903190750.GA19777@argus.gw.utexas.edu> Message-ID: -----Original Message----- >From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Charles Spurgeon >Subject: Re: [c-nsp] Crash bug in SXH3 >This bug in combination with an apparent hardware error on a Sup720 >left one of our core routers equipped with dual sup720s crashed and >sitting in rommon. Is this 'sitting in ROMMON' and not automatically rebooting normal? We had a 720 do that a couple weeks ago due to a NAT bug. I thought there was a crash count that put it in ROMMON only if it crashed 'x' number of times in a row. Or is this one of those ROMMON bugs I saw mentioned recently by someone? Chuck From rubensk at gmail.com Wed Sep 3 16:11:40 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Wed, 3 Sep 2008 17:11:40 -0300 Subject: [c-nsp] Crash bug in SXH3 In-Reply-To: <20080903190750.GA19777@argus.gw.utexas.edu> References: <489B7063.8040904@imperial.ac.uk> <20080903190750.GA19777@argus.gw.utexas.edu> Message-ID: <6bb5f5b10809031311p53604476o4e0e0aa0511ff74f@mail.gmail.com> > We are informed that SXF code also has the route-map bug, but we have > more confidence in that code (having removed route-maps in it many > times without problems) so we have reverted to SXF6 while awaiting a > new SXH build. SHX4 is a quarter away, any sightings of a SXH3a on the horizon ? Rubens From A.L.M.Buxey at lboro.ac.uk Wed Sep 3 16:22:50 2008 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Wed, 3 Sep 2008 21:22:50 +0100 Subject: [c-nsp] Crash bug in SXH3 In-Reply-To: <20080903190750.GA19777@argus.gw.utexas.edu> References: <489B7063.8040904@imperial.ac.uk> <20080903190750.GA19777@argus.gw.utexas.edu> Message-ID: <20080903202250.GB2942@lboro.ac.uk> Hi, > times without problems) so we have reverted to SXF6 while awaiting a > new SXH build. any reason for an SXF6 so old? eg why not SXF12 ? alan From cchurc05 at harris.com Wed Sep 3 16:28:36 2008 From: cchurc05 at harris.com (Church, Charles) Date: Wed, 3 Sep 2008 15:28:36 -0500 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: References: <1220470004.32656.7.camel@abehat> Message-ID: I don't think you can put an RSP720 in a 6500 chassis. There is the VS 720 with the 3CXL PFC, but that is about $8K more. I don't think you can get the 3CXL in a 6500 without getting the 10gig ports. Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Christian Bering Sent: Wednesday, September 03, 2008 3:53 PM To: Peter Rathlev Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Dreaded FIB Exception on Sup2 Hi, >>Yes. For a full table you need to upgrade to an RSP720-3CXL. >And even the SUP720 can manage too, as long as it has the >magic "XL" in the end. :-) Yeah but since the list price for the RSP720-3CXL is the same as the list price for the SUP720-3BXL, I don't see a reason not to go for the RSP. Does one exist? -- Regards Christian Bering _______________________________________________ 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 Wed Sep 3 16:29:49 2008 From: justin at justinshore.com (Justin Shore) Date: Wed, 03 Sep 2008 15:29:49 -0500 Subject: [c-nsp] SUP720-3B / 3rd party CF In-Reply-To: <9e246b4d0809030633h15911927p465f8071f1bf1424@mail.gmail.com> References: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> <48BE8E1C.90304@justinshore.com> <9e246b4d0809030633h15911927p465f8071f1bf1424@mail.gmail.com> Message-ID: <48BEF3BD.9090807@justinshore.com> Tim Durack wrote: > And that's what I'm trying to do, but apparently not all Kingston cf is > created equal. > > My guess is if you do a "show disk0: all" the Kingston cf will show up > as a Toshiba something or other. 7613-1#show sup-bootdisk: all -#- --length-- -----date/time------ path 1 33554432 Mar 21 2007 23:45:52 sea_log.dat 2 32896 Jun 20 2007 11:04:06 bgp 4 26110976 Mar 14 2007 08:23:54 c7600-fpd-pkg.122-33.SRB.pkg 5 254679 Mar 01 2007 01:38:50 crashinfo_20070228-203851 6 109627908 Mar 14 2007 08:33:04 c7600s72033-advipservicesk9-mz.122-33.SRB.bin 7 110884868 Jun 21 2007 08:48:02 c7600s72033-advipservicesk9-mz.122-33.SRB1.bin 8 26191872 Jun 21 2007 09:01:30 c7600-fpd-pkg.122-33.SRB1.pkg 205340672 bytes available (306700288 bytes used) ******** ATA Flash Card Geometry/Format Info ******** ATA CARD GEOMETRY Manufacturer Name STI Model Number STI Flash 7.4.0 Serial Number STI J106306210131218 Firmware Revision 01.25.06 Number of Heads 16 Number of Cylinders 993 Sectors per Cylinder 63 Sector Size 512 Total Sectors 1000944 ATA PARTITION 1 INFO Start Sector 63 Number of Sectors 1000881 Size in Bytes 512451072 File System Type FAT16 Number of FAT Sectors 245 Sectors Per Cluster 16 Number of Clusters 62505 Number of Data Sectors 1000080 Base FAT Sector 134 Base Root Sector 624 Base Data Sector 656 ATA MONLIB INFO Image Monlib size 64120 Disk Monlib Size 64120 Disk Space Available 68096 Name c7200-atafslib-m Start sector 2 End sector 127 Updated By s72033_sp-ADVIPSERVICESK9_WAN-M12.2(33)SRA1 Version 1 Monlib Version 2 Monlib Params Version 1 7613-2.clr#sh sup-bootdisk: all -#- --length-- -----date/time------ path 1 109627908 Mar 14 2007 08:34:18 c7600s72033-advipservicesk9-mz.122-33.SRB.bin 2 33554432 Mar 14 2007 13:39:04 sea_log.dat 4 26110976 Mar 14 2007 08:26:20 c7600-fpd-pkg.122-33.SRB.pkg 5 13833 Mar 14 2007 22:02:28 bgp 6 110884868 Jun 20 2007 09:22:22 c7600s72033-advipservicesk9-mz.122-33.SRB1.bin 7 26191872 Jun 21 2007 09:01:46 c7600-fpd-pkg.122-33.SRB1.pkg 205627392 bytes available (306413568 bytes used) ******** ATA Flash Card Geometry/Format Info ******** ATA CARD GEOMETRY Manufacturer Name STI Model Number STI Flash 7.4.0 Serial Number STI J175106335203831 Firmware Revision 01.25.06 Number of Heads 16 Number of Cylinders 993 Sectors per Cylinder 63 Sector Size 512 Total Sectors 1000944 ATA PARTITION 1 INFO Start Sector 63 Number of Sectors 1000881 Size in Bytes 512451072 File System Type FAT16 Number of FAT Sectors 245 Sectors Per Cluster 16 Number of Clusters 62505 Number of Data Sectors 1000080 Base FAT Sector 134 Base Root Sector 624 Base Data Sector 656 ATA MONLIB INFO Image Monlib size 64120 Disk Monlib Size 64120 Disk Space Available 68096 Name c7200-atafslib-m Start sector 2 End sector 127 Updated By s72033_sp-ADVIPSERVICESK9_WAN-M12.2(33)SRA1 Version 1 Monlib Version 2 Monlib Params Version 1 The same command on a 3845 running 12.4(15)T5 omits all tech details above the # of heads. However an identical card in a 2811 running 20T shows that info once again: ATA CARD GEOMETRY Manufacturer Name Model Number CF CARD 1GB Serial Number CF1GB 00005104 Firmware Revision 20070131 Number of Heads 16 Number of Cylinders 1966 Sectors per Cylinder 63 Sector Size 512 Total Sectors 1981728 ATA PARTITION 1 INFO Start Sector 63 Number of Sectors 1981665 Size in Bytes 1014612480 File System Type FAT16 Number of FAT Sectors 242 Sectors Per Cluster 32 Number of Clusters 61879 Number of Data Sectors 1980128 Base FAT Sector 1 Base Root Sector 485 Base Data Sector 517 ATA MONLIB INFO Image Monlib size 112876 Disk Monlib Size NA Disk Space Available NA Name NA End Sector NA Start sector NA Updated By NA Version NA We're using the cheap Kingston modules. Not the fancy ones that claim faster write times. It's the "CF/1GB" model. http://www.kingston.com/flash/cf_standard.asp They can be had for about $10 wholesale. Justin From chip.gwyn at gmail.com Wed Sep 3 16:32:42 2008 From: chip.gwyn at gmail.com (chip) Date: Wed, 3 Sep 2008 16:32:42 -0400 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: References: <1220470004.32656.7.camel@abehat> Message-ID: <64a8ad980809031332q3092b175r171d7569bc8f81f@mail.gmail.com> On Wed, Sep 3, 2008 at 3:53 PM, Christian Bering wrote: > Hi, > > >>Yes. For a full table you need to upgrade to an RSP720-3CXL. > > >And even the SUP720 can manage too, as long as it has the > >magic "XL" in the end. :-) > > Yeah but since the list price for the RSP720-3CXL is the same as the > list price for the SUP720-3BXL, I don't see a reason not to go for the > RSP. Does one exist? > > -- > Regards > Christian Bering > _______________________________________________ > 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/ > There's still some cards that the SUP720-3BXL will support that the RSP720 will not. The EOL'd OC12 cards I think. So just make sure you're covered and you should be ok. --chip -- Just my $.02, your mileage may vary, batteries not included, etc.... From jason at pins.net Wed Sep 3 16:36:47 2008 From: jason at pins.net (Jason Berenson) Date: Wed, 03 Sep 2008 16:36:47 -0400 Subject: [c-nsp] Need pointers for configuring NAT on 1841 In-Reply-To: <010501c90df3$434c55e0$1b0310ac@ccntd1.covad.com> References: <010501c90df3$434c55e0$1b0310ac@ccntd1.covad.com> Message-ID: <48BEF55F.5050208@pins.net> Scott, I believe you will need a public /30 if you want to do NAT on the Cisco. Your dialer would be the "ip nat outside" and the ethernet connection with all the 192.168.x.y/24 addresses would be the "ip nat inside" interface. This should take care of outbound NAT: ip nat inside source list 1 interface dialer1 overload access-list 1 permit 192.168.1.0 0.0.0.255 This should take care of any inbound ports you want to open: ip nat inside source static udp 192.168.x.y 5060 interface dialer1 5060 -Jason Scott Granados wrote: > I have a DSL loop provisioned as follows. Via PPPOE I'm assigned a > /30 that's allocated from unrouted addresses. I then am routed a > public pool /29 in length via the /30. > > I'm using a Cisco 1841 with a WIC-1-ADSL card and 2 ethernet ports. > On one of the LAN ports I have the /29. (This works) I'd like to set > up nat on the other LAN port and I would assume that I would use one > of my addresses from my /29 for the translation. I have the following > config but can't figure out the NAT portion to add or find good > examples via google. Any pointers would be appreciated or better > still a pointer that could take me through the fundimentals (assuming > my config will work at all). > > Thank you > Scott > > ip dhcp pool lan > > network 192.168.13.0 255.255.255.0 > > default-router 192.168.13.1 > ! > > multilink bundle-name authenticated > > vpdn enable > > ! > > vpdn-group 1 > > request-dialin > > protocol pppoe > > l2tp tunnel receive-window 1024 > > > bba-group pppoe global > > ! > > ! > > interface FastEthernet0/0 > > ip address 192.168.13.1 255.255.255.0 > > duplex auto > > speed auto > > ! > > interface FastEthernet0/1 > > ip address x.x.x.1 255.255.255.248 > > duplex auto > > speed auto > > ! > > interface ATM0/0/0 > > no ip address > > no atm ilmi-keepalive > > dsl operating-mode auto > > dsl enable-training-log > > pvc 0/35 > > encapsulation aal5snap > > pppoe-client dial-pool-number 1 > > ! > > interface Dialer1 > > ip address negotiated > > ip mtu 1492 > > encapsulation ppp > > no ip mroute-cache > > dialer pool 1 > > dialer-group 1 > > ppp authentication chap callin > > ppp chap hostname "YourNameHere at bz8" > > ppp chap password 0 "YourPassWord" > > ! > > ip route 0.0.0.0 0.0.0.0 Dialer1 > > ! > > > _______________________________________________ > 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 Wed Sep 3 16:45:03 2008 From: justin at justinshore.com (Justin Shore) Date: Wed, 03 Sep 2008 15:45:03 -0500 Subject: [c-nsp] ME3400 DC Power In-Reply-To: <48BE8C99.2010500@beanfield.com> References: <48BE6B18.2050804@internetsolver.com> <48BE8C99.2010500@beanfield.com> Message-ID: <48BEF74F.3080600@justinshore.com> Doing this in a unit with 2 PSUs will give you PSU redundancy, should one fail. It will also give you breaker/fuse redundancy, should one pop. However it won't give you power source redundancy. You still need a B feed connected to a PSU to get redundancy for the power source. http://www.cisco.com/en/US/docs/switches/metro/me3400/hardware/installation/guide/HGDCPWR.html In my experience you're more likely to lose a power source than a PSU. When it doubt wire the device as indicated with A & B to both PSUs. Though I would never wire a device this way, figure C-7 give you an option for daisy-chaining 2 power feeds through both PSUs. Justin Dan Armstrong wrote: > The power supplies on the ME3400s have 2 inputs, for "breaker" > redundancy.. some models have to physical power supplies, some have only > one - in all cases, each supply has 2 inputs. If your model has 2 power > supplies, you can hookup just the A side of each unit, and you'll be fine. > > > > Dave Weis wrote: >> >> Do I need to supply both power supplies with an A&B side for >> redundancy or will I have redundancy if I have the A side of PS1 and >> PS2 connected? >> >> Thanks >> >> dave From kgraham at industrial-marshmallow.com Wed Sep 3 16:52:24 2008 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Wed, 3 Sep 2008 13:52:24 -0700 (PDT) Subject: [c-nsp] Dreaded FIB Exception on Sup2 Message-ID: <4841.72918.qm@web905.biz.mail.mud.yahoo.com> > Yeah but since the list price for the RSP720-3CXL is the same as the > list price for the SUP720-3BXL, I don't see a reason not to go for the > RSP. Does one exist? It's minimal, but RSP720-3CXL is going to require a "7600", though if you are willing to trade the MSFC4 for VSS, you can go with a VS-Sup720-3CXL. Either one is going to force you off of 12.2SXF. From peter at rathlev.dk Wed Sep 3 17:36:41 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Wed, 03 Sep 2008 23:36:41 +0200 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: References: <1220470004.32656.7.camel@abehat> Message-ID: <1220477801.32656.14.camel@abehat> On Wed, 2008-09-03 at 21:53 +0200, Christian Bering wrote: > Yeah but since the list price for the RSP720-3CXL is the same as the > list price for the SUP720-3BXL, I don't see a reason not to go for the > RSP. Does one exist? Isn't the RSP720 strictly 7600? Seems OP uses a Cat6500. And it introduces newer and thus potentially more buggy elements, the PFC3C and MSFC4, compared to a "plain vanilla" SUP720/PFC3B/MSFC3. (Not that these aren't buggy sometimes... :-)) Regards, Peter From rubensk at gmail.com Wed Sep 3 17:49:06 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Wed, 3 Sep 2008 18:49:06 -0300 Subject: [c-nsp] SXH3 SP memory requirements Message-ID: <6bb5f5b10809031449g1a3a3142hecbdda4e4fdbc8ef@mail.gmail.com> My understanding of the SXH3 release notes was that monolithic IOS (Adv. IP Services feature set) requires 256MB of SP(Switching Processor) memory (which is the ME6524 default) and 512MB of RP(Routing Processor) memory (also the ME6524 default). I've opened a TAC case (SR 609292161, if any Cisco employee wants to review) and TAC tells me that 512MB of SP memory is required to run SHX3. I've tested it on the lab and it seems to boot... any comments ? Rubens From c.spurgeon at mail.utexas.edu Wed Sep 3 18:23:00 2008 From: c.spurgeon at mail.utexas.edu (Charles Spurgeon) Date: Wed, 3 Sep 2008 17:23:00 -0500 Subject: [c-nsp] Crash bug in SXH3 In-Reply-To: <20080903202250.GB2942@lboro.ac.uk> References: <489B7063.8040904@imperial.ac.uk> <20080903190750.GA19777@argus.gw.utexas.edu> <20080903202250.GB2942@lboro.ac.uk> Message-ID: <20080903222300.GA16526@argus.gw.utexas.edu> On Wed, Sep 03, 2008 at 09:22:27PM +0100, A.L.M.Buxey at lboro.ac.uk wrote: > Hi, > > > times without problems) so we have reverted to SXF6 while awaiting a > > new SXH build. > > any reason for an SXF6 so old? eg why not SXF12 ? The usual reason: being very conservative with core/border gear. SXF6 was something we had frozen on for a (long) while, since it was stable and did everything we needed at the time and was even a safe harbor release. Rather than dodge and weave through subsequent SXF releases given various reports on SXF bugs, we just stuck with what worked. When we were forced to back down from SXH3 we went with the release we had last used successfully. If we were planning to stay on SXF I'd be looking at more recent releases. However, we need SXH for 16-port 10GigE card support, so we're waiting for a new release of SXH. The TAC said they'd update us on the next release date for SXH but we haven't heard anything for the last week or so. -Charles From c.spurgeon at mail.utexas.edu Wed Sep 3 18:29:42 2008 From: c.spurgeon at mail.utexas.edu (Charles Spurgeon) Date: Wed, 3 Sep 2008 17:29:42 -0500 Subject: [c-nsp] Crash bug in SXH3 In-Reply-To: References: <489B7063.8040904@imperial.ac.uk> <20080903190750.GA19777@argus.gw.utexas.edu> Message-ID: <20080903222942.GB16526@argus.gw.utexas.edu> On Wed, Sep 03, 2008 at 02:56:13PM -0500, Church, Charles wrote: > -----Original Message----- > >From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Charles Spurgeon > >Subject: Re: [c-nsp] Crash bug in SXH3 > > >This bug in combination with an apparent hardware error on a Sup720 > >left one of our core routers equipped with dual sup720s crashed and > >sitting in rommon. > > Is this 'sitting in ROMMON' and not automatically rebooting normal? We > had a 720 do that a couple weeks ago due to a NAT bug. I thought there > was a crash count that put it in ROMMON only if it crashed 'x' number of > times in a row. Or is this one of those ROMMON bugs I saw mentioned > recently by someone? The TAC engineer appeared to be of the opinion that crashing to rommon was an expected result of the hardware failure. I assumed that it was due to crashing some number of times in a row in relation to a hardware failure. Our attempts to duplicate the orginal crash by repeatedly removing a route-map were unsuccessful. We were told that the bug is intermittent and timing related. When the TAC informed us that there also appeared to be a hardware problem on the sup720 as well as the route-map crash we RMA'd the sup and reverted to SXF code, so we haven't been able to recreate the failure mode. -Charles From RTeller at deltadentalwa.com Wed Sep 3 18:40:27 2008 From: RTeller at deltadentalwa.com (Teller, Robert) Date: Wed, 3 Sep 2008 15:40:27 -0700 Subject: [c-nsp] DHCP and HSRP Message-ID: <06C1E76E03FE9C4B85BFA9C75365D9DA0FC011D4@tiger.deltadentalwa.com> Is it possible to configure two 6509's to share DHCP information so that if the active HSRP router goes down and the standby comes up it doesn't generate a bunch of ip conflicts? Or do I need to maintain a separate scope on each HSRP member? Robert Teller Washington Dental Service Network Administrator (206) 528-2371 RTeller at DeltaDentalWa.com ######################################################### The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended for the sole use of the individual and entity to whom it is addressed. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. ######################################################### From jared at puck.nether.net Wed Sep 3 19:31:22 2008 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 3 Sep 2008 19:31:22 -0400 Subject: [c-nsp] Crash bug in SXH3 In-Reply-To: <20080903222300.GA16526@argus.gw.utexas.edu> References: <489B7063.8040904@imperial.ac.uk> <20080903190750.GA19777@argus.gw.utexas.edu> <20080903202250.GB2942@lboro.ac.uk> <20080903222300.GA16526@argus.gw.utexas.edu> Message-ID: <20080903233122.GC67129@puck.nether.net> On Wed, Sep 03, 2008 at 05:23:00PM -0500, Charles Spurgeon wrote: > On Wed, Sep 03, 2008 at 09:22:27PM +0100, A.L.M.Buxey at lboro.ac.uk wrote: > > Hi, > > > > > times without problems) so we have reverted to SXF6 while awaiting a > > > new SXH build. > > > > any reason for an SXF6 so old? eg why not SXF12 ? > > The usual reason: being very conservative with core/border gear. > > SXF6 was something we had frozen on for a (long) while, since it was > stable and did everything we needed at the time and was even a safe > harbor release. Rather than dodge and weave through subsequent SXF > releases given various reports on SXF bugs, we just stuck with what > worked. > > When we were forced to back down from SXH3 we went with the release we > had last used successfully. If we were planning to stay on SXF I'd be > looking at more recent releases. However, we need SXH for 16-port > 10GigE card support, so we're waiting for a new release of SXH. > > The TAC said they'd update us on the next release date for SXH but > we haven't heard anything for the last week or so. Ask tac to email the release ops team, you should be able to get a tentative date. I've had mixed results with SXH. I suspect that the next major release will beat a rebuild of SXH, but I'm willing to be wrong. Perhaps a TME for the 6500 (whom i know is on the list ;) will chime in about these problems with SXH? - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From MLouis at nwnit.com Wed Sep 3 20:38:22 2008 From: MLouis at nwnit.com (Mike Louis) Date: Wed, 3 Sep 2008 20:38:22 -0400 Subject: [c-nsp] DHCP and HSRP In-Reply-To: <06C1E76E03FE9C4B85BFA9C75365D9DA0FC011D4@tiger.deltadentalwa.com> References: <06C1E76E03FE9C4B85BFA9C75365D9DA0FC011D4@tiger.deltadentalwa.com> Message-ID: If you configure the ip dhcp data base command to write to a common share, say a tftp share for example, you could prevent the ip address conflicts. The dhcp database is used by the local dhcp server to determine the state of the leases that the dhcp server has handed out. If you do not configure a dhcp server, i believe the leases are retained in RAM. If you reboot a switch with leases in RAM then you will have dhcp conflicts when the switch reboots and starts handing out dhcp in a scope that it thinks has an open lease pool. Thats how i have seen it work. HTH Mike ________________________________________ From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of Teller, Robert [RTeller at deltadentalwa.com] Sent: Wednesday, September 03, 2008 6:40 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] DHCP and HSRP Is it possible to configure two 6509's to share DHCP information so that if the active HSRP router goes down and the standby comes up it doesn't generate a bunch of ip conflicts? Or do I need to maintain a separate scope on each HSRP member? Robert Teller Washington Dental Service Network Administrator (206) 528-2371 RTeller at DeltaDentalWa.com ######################################################### The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended for the sole use of the individual and entity to whom it is addressed. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. ######################################################### _______________________________________________ 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. From mtinka at globaltransit.net Wed Sep 3 21:55:21 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 4 Sep 2008 09:55:21 +0800 Subject: [c-nsp] Crash bug in SXH3 In-Reply-To: <20080903190750.GA19777@argus.gw.utexas.edu> References: <489B7063.8040904@imperial.ac.uk> <20080903190750.GA19777@argus.gw.utexas.edu> Message-ID: <200809040955.26302.mtinka@globaltransit.net> On Thursday 04 September 2008 03:07:50 Charles Spurgeon wrote: > To which I will add another warning: there is also a > fatal crash bug in SXH3 that is triggered by removing a > route-map. We've been running SXH3 on our core switches in our larger PoP (6506/SUP720-3BXL + 6509-E/SUP720-3BXL), with WS-X6724-SFP + DFC-3CXL line cards. Suffice it to say, we use them purely for Layer 2 forwarding and IS-IS DIS (primary and backup). The only interesting issue we've faced after moving from SXH2a to SXH3 was the switches started requiring our fall-back enable password rather than the primary one we always used (authentication/accounting is done via TACACS+). Our AAA configuration remained the same, but this issue cropped up. We worked around it, as we try to figure out what's going on. Besides that, no other issues to report, but then again they really aren't doing anything interesting besides creating Layer 2 bandwidth and propagating IS-IS PDU's. 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 overkillxx at gmail.com Wed Sep 3 22:41:12 2008 From: overkillxx at gmail.com (Brett Clausenhauf) Date: Thu, 4 Sep 2008 12:41:12 +1000 Subject: [c-nsp] CSS strange behaviour.... Or is it just my config [7:132492] In-Reply-To: <200809040227.m842RBGe015086@groupstudy.com> References: <200809040227.m842RBGe015086@groupstudy.com> Message-ID: Hi Guys, I have some strange behaviour (Or perhaps wrong config) on a CSS11503. Basically I am just adding a very basic config to it (1 service defined) & for some reason in order for it to work properly I MUST have a group command defined. If I don't have the group statement it worked for awhile & then ceases to forward incoming requests on the VIP address for tcp port 85. Tried suspend/active on the Service & Group.. Still it didn't work. The minute I added the group statement it works.... Being relatively new to the CSS I am not sure why this is needed. Does anyone know why? Here is the elements of the config in question: !************************** SERVICE ************************** service Test102_Web_VIP6_85 ip address 192.168.10.224 port 85 keepalive port 85 keepalive type http keepalive maxfailure 2 keepalive frequency 30 keepalive retryperiod 30 active !*************************** OWNER *************************** owner WWW content contTest102_VIP6_85 port 85 protocol tcp add service Test102_Web_VIP6_85 vip address 10.251.1.31 active !*************************** GROUP *************************** group grpTest102_VIP6 vip address 10.251.1.31 add service Test102_Web_VIP6_85 active From jim at tgasolutions.com Thu Sep 4 00:05:22 2008 From: jim at tgasolutions.com (Jim McBurnett) Date: Thu, 4 Sep 2008 00:05:22 -0400 Subject: [c-nsp] latest stable... Message-ID: Hey folks, It's been awhile but I have run into a strange set of BGP bugs, and the worst is on SUP 720 running 12.2(18)SXD7 CSCef01705 CSCsc36517 Now for the question-with these 2 bugs, and the other 389 BGP relate bugs on this release-what are all of you having the best success on for a sup 720 on a 7606? How about an NPE-G1 on a 7206? I'd like to go ahead an upgrade both of these 2 boxes in a carefully planned manner since they are the internet facing BGP speakers for a medium sized network... And minimize the down time.... Any and all ideas would be greatly appreciated! Thanks, Jim McBurnett From gert at greenie.muc.de Thu Sep 4 02:10:39 2008 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 4 Sep 2008 08:10:39 +0200 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: References: <1220470004.32656.7.camel@abehat> Message-ID: <20080904061039.GM233@greenie.muc.de> Hi, On Wed, Sep 03, 2008 at 09:53:02PM +0200, Christian Bering wrote: > Yeah but since the list price for the RSP720-3CXL is the same as the > list price for the SUP720-3BXL, I don't see a reason not to go for the > RSP. Does one exist? The RSP is made by the business unit inside Cisco that brought us the dreaded "SR IOS for 7600 will not run on 6500 chassis" annoyance. Vote with your money. Besides, if you happen to *have* a 6500 chassis, the RSP won't work there. (Not that there is any difference between a 6500 and a 7600, besides the color of the metal and the EEPROM programming... thankyouverymuch) 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: 304 bytes Desc: not available URL: From gert at greenie.muc.de Thu Sep 4 02:11:58 2008 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 4 Sep 2008 08:11:58 +0200 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: <4841.72918.qm@web905.biz.mail.mud.yahoo.com> References: <4841.72918.qm@web905.biz.mail.mud.yahoo.com> Message-ID: <20080904061158.GN233@greenie.muc.de> Hi, On Wed, Sep 03, 2008 at 01:52:24PM -0700, Kevin Graham wrote: > > Yeah but since the list price for the RSP720-3CXL is the same as the > > > list price for the SUP720-3BXL, I don't see a reason not to go for the > > RSP. Does one exist? > > It's minimal, but RSP720-3CXL is going to require a "7600", though if you > are willing to trade the MSFC4 for VSS, you can go with a VS-Sup720-3CXL. > Either one is going to force you off of 12.2SXF. Since the difference between 3B and 3C mainly seems to be "number of MAC addresses", a Sup720-3BXL will usually do the job well enough. 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: 304 bytes Desc: not available URL: From gert at greenie.muc.de Thu Sep 4 02:22:27 2008 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 4 Sep 2008 08:22:27 +0200 Subject: [c-nsp] CSS strange behaviour.... Or is it just my config [7:132492] In-Reply-To: References: <200809040227.m842RBGe015086@groupstudy.com> Message-ID: <20080904062227.GP233@greenie.muc.de> Hi, On Thu, Sep 04, 2008 at 12:41:12PM +1000, Brett Clausenhauf wrote: > If I don't have the group statement it worked for awhile & then ceases to > forward incoming requests on the VIP address for tcp port 85. > Tried suspend/active on the Service & Group.. Still it didn't work. The > minute I added the group statement it works.... Being relatively new to the > CSS I am not sure why this is needed. Does anyone know why? Stab in the dark: your web server could be doing DNS lookups to write the client hostname to the log. If you have no group statement, DNS will not work (because that's an outgoing session), so the HTTP request will be very slow (DNS timeout). The keepalive will determine "HTTP server down" and will take the server out of service. (As said, this could be completely off base, but you might want to do some tcpdumping on the server to verify what's going on). 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: 304 bytes Desc: not available URL: From gert at greenie.muc.de Thu Sep 4 02:23:52 2008 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 4 Sep 2008 08:23:52 +0200 Subject: [c-nsp] latest stable... In-Reply-To: References: Message-ID: <20080904062352.GQ233@greenie.muc.de> Hi, On Thu, Sep 04, 2008 at 12:05:22AM -0400, Jim McBurnett wrote: > Now for the question-with these 2 bugs, and the other 389 BGP relate bugs on this release-what are all of you having the best success on for a sup 720 on a 7606? I'd go for SXF14. > How about an NPE-G1 on a 7206? Depending on your feature requirements - 12.3 main or 12.2SB. 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: 304 bytes Desc: not available URL: From ariemer at wesenergy.com.au Thu Sep 4 02:27:07 2008 From: ariemer at wesenergy.com.au (Aaron Riemer) Date: Thu, 4 Sep 2008 14:27:07 +0800 Subject: [c-nsp] 6500 WS-SUP32-GE-3B failure In-Reply-To: <1220469723.32656.3.camel@abehat> References: <0867622C64B50C4B878AB45C95F43F1106124A09@MAILWA01.wesenergy.local> <1220469723.32656.3.camel@abehat> Message-ID: <0867622C64B50C4B878AB45C95F43F1106150982@MAILWA01.wesenergy.local> Thanks Pete, Non disruptive tests haven't indicated anything as yet. Will try when we go down for outage. Cheers, Aaron. -----Original Message----- From: Peter Rathlev [mailto:peter at rathlev.dk] Sent: Thursday, 4 September 2008 3:22 AM To: Aaron Riemer Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] 6500 WS-SUP32-GE-3B failure On Wed, 2008-09-03 at 17:05 +0800, Aaron Riemer wrote: > We currently have a WS-SUP32-GE-3B where the SFP ports are not coming > online. Is there a test that can be run from the switch to detect if > there is a hardware failure? A sh module indicates that the SUP is ok.. You could try the "diagnostic start module X test Y" commands. It can do some non-disruptive tests too. Regards, Peter LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From achatz at forthnet.gr Thu Sep 4 03:01:19 2008 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Thu, 04 Sep 2008 10:01:19 +0300 Subject: [c-nsp] how to debug etherchannel on 6500? In-Reply-To: <383357750808290358j6e97cf71hf01c07834ba31344@mail.gmail.com> References: <48B63445.4010406@forthnet.gr> <383357750808290358j6e97cf71hf01c07834ba31344@mail.gmail.com> Message-ID: <48BF87BF.6090701@forthnet.gr> That worked fine, although i'm still not getting the detailed output i was getting on 3750. But it's a start. 6500#remote command switch debug lacp Link Aggregation Control Protocol debugging is on 6500#remote command switch debug pagp Port Aggregation Protocol debugging is on 6500#remote command switch debug etherchannel PAgP/LACP Shim/FEC debugging is on Thx Mateusz ;) -- Tassos Mateusz B?aszczyk wrote on 29/8/2008 1:58 ??: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tassos, > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIt9ZHIvBv0k5esR4RAsnqAJ9rLbJSVRYQsz0SL0s1BcKjG1Ev4wCfcT3c > 4+Pu5a0a1zxsu1sfpCOa6iw= > =wvWL > -----END PGP SIGNATURE----- > > >> Is the "debug etherchannel all" supposed to display anything? If not, is >> there another debug command on the 6500 like the "debug pagp/lacp" on the >> 3750? >> > > when I was testing ME6524s I didnt see any output of the STP debugging > until I did "remote command switch debug ..." > > It might work for you. > > Best Regards, > From ryanclambert at gmail.com Thu Sep 4 03:07:11 2008 From: ryanclambert at gmail.com (Ryan) Date: Thu, 4 Sep 2008 03:07:11 -0400 Subject: [c-nsp] silly qos question Message-ID: <002a01c90e5c$db50b750$91f225f0$@com> Hey all, Quick QoS question here. I seem to be having some trouble getting a policy applied to a Serial (T1) interface, and for the life of me don?t understand why. I?m pretty sure it?s my fault and not a ?feature?. Error I am getting when I try to apply the service policy direction output: %INTERFACE_NAME% class Data-DSCP requested bandwidth 750 (kbps) Available only 656 (kbps) Here are the class/policy map statements: class-map match-any Control-DSCP match ip dscp cs3 match ip dscp af31 class-map match-any Voice-DSCP match ip dscp ef class-map match-any Video-DSCP match ip dscp af41 class-map match-any class-default class-map match-any Data-DSCP match ip dscp default policy-map QoS-Policy-Office class Voice-DSCP priority 360 class Video-DSCP bandwidth 128 class Control-DSCP bandwidth 8 class Data-DSCP bandwidth 750 class class-default If I bump bandwidth of class Data-DSCP down to 656 from 750, it applies with no backtalk. Clearly I am missing something on a conceptual level, here. Any help is appreciated. ? Platform: 7206VXR, NPE-G1 running 12.3(26) SP code. Thanks! -Ryan From ccie15385 at gmail.com Thu Sep 4 03:20:07 2008 From: ccie15385 at gmail.com (JH Cockburn) Date: Thu, 4 Sep 2008 09:20:07 +0200 Subject: [c-nsp] DHCP and HSRP In-Reply-To: References: <06C1E76E03FE9C4B85BFA9C75365D9DA0FC011D4@tiger.deltadentalwa.com> Message-ID: <6099F23391024C8D9A18E647808FC803@africa.enterprise.root> Hi All, Or you can config the router to first ping (I think this is default...) the IP it wants to assign, and if it is active it will assign the next and so forth. JC -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mike Louis Sent: Thursday, September 04, 2008 2:38 AM To: Teller, Robert; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] DHCP and HSRP If you configure the ip dhcp data base command to write to a common share, say a tftp share for example, you could prevent the ip address conflicts. The dhcp database is used by the local dhcp server to determine the state of the leases that the dhcp server has handed out. If you do not configure a dhcp server, i believe the leases are retained in RAM. If you reboot a switch with leases in RAM then you will have dhcp conflicts when the switch reboots and starts handing out dhcp in a scope that it thinks has an open lease pool. Thats how i have seen it work. HTH Mike ________________________________________ From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of Teller, Robert [RTeller at deltadentalwa.com] Sent: Wednesday, September 03, 2008 6:40 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] DHCP and HSRP Is it possible to configure two 6509's to share DHCP information so that if the active HSRP router goes down and the standby comes up it doesn't generate a bunch of ip conflicts? Or do I need to maintain a separate scope on each HSRP member? Robert Teller Washington Dental Service Network Administrator (206) 528-2371 RTeller at DeltaDentalWa.com ######################################################### The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended for the sole use of the individual and entity to whom it is addressed. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. ######################################################### _______________________________________________ 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. _______________________________________________ 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 tseveendorj at gmail.com Thu Sep 4 03:24:03 2008 From: tseveendorj at gmail.com (Tseveendorj Ochirlantuu) Date: Thu, 4 Sep 2008 15:24:03 +0800 Subject: [c-nsp] RTP port Message-ID: <62c908120809040024q72fd82c6u869b4adeb0fbb479@mail.gmail.com> Hi, If is it possible to choose RTP port on AS5350XM? for example: don't use all ports 16000-60000 on gateway. Only use between 16000-17000. Sincerely, Tseveen. From achatz at forthnet.gr Thu Sep 4 03:32:08 2008 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Thu, 04 Sep 2008 10:32:08 +0300 Subject: [c-nsp] silly qos question In-Reply-To: <002a01c90e5c$db50b750$91f225f0$@com> References: <002a01c90e5c$db50b750$91f225f0$@com> Message-ID: <48BF8EF8.60202@forthnet.gr> Ryan, have a look at the max-reserved-bandwidth command. http://www.cisco.com/en/US/docs/ios/12_3/qos/command/reference/qos_m1g.html#wp1113113 -- Tassos Ryan wrote on 4/9/2008 10:07 ??: > Hey all, > > Quick QoS question here. I seem to be having some trouble getting a policy applied to a Serial (T1) interface, and for the life of me don?t understand why. I?m pretty sure it?s my fault and not a "feature". > > Error I am getting when I try to apply the service policy direction output: > > %INTERFACE_NAME% class Data-DSCP requested bandwidth 750 (kbps) Available only 656 (kbps) > > > Here are the class/policy map statements: > > class-map match-any Control-DSCP > match ip dscp cs3 > match ip dscp af31 > class-map match-any Voice-DSCP > match ip dscp ef > class-map match-any Video-DSCP > match ip dscp af41 > class-map match-any class-default > class-map match-any Data-DSCP > match ip dscp default > > policy-map QoS-Policy-Office > class Voice-DSCP > priority 360 > class Video-DSCP > bandwidth 128 > class Control-DSCP > bandwidth 8 > class Data-DSCP > bandwidth 750 > class class-default > > If I bump bandwidth of class Data-DSCP down to 656 from 750, it applies with no backtalk. > > Clearly I am missing something on a conceptual level, here. Any help is appreciated. ? > > Platform: > > 7206VXR, NPE-G1 running 12.3(26) SP code. > > Thanks! > -Ryan > > > > _______________________________________________ > 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 Sep 4 03:32:13 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Thu, 4 Sep 2008 08:32:13 +0100 Subject: [c-nsp] SUP720-3B / 3rd party CF In-Reply-To: <48BEF3BD.9090807@justinshore.com> References: <9e246b4d0809020609r5cc1ee8ftea9af71771f39308@mail.gmail.com> <48BE8E1C.90304@justinshore.com> <9e246b4d0809030633h15911927p465f8071f1bf1424@mail.gmail.com> <48BEF3BD.9090807@justinshore.com> Message-ID: <20080904073213.GA11595@wildfire.net.ic.ac.uk> On Wed, Sep 03, 2008 at 03:29:49PM -0500, Justin Shore wrote: >We're using the cheap Kingston modules. Not the fancy ones that claim >faster write times. It's the "CF/1GB" model. > I wonder if that's it - I'm pretty sure our 2nd batch of cards claimed faster write times (not that it makes any difference - the CF card interface on the sup720 seems slow by design grumble) From ariemer at wesenergy.com.au Thu Sep 4 03:37:49 2008 From: ariemer at wesenergy.com.au (Aaron Riemer) Date: Thu, 4 Sep 2008 15:37:49 +0800 Subject: [c-nsp] silly qos question In-Reply-To: <002a01c90e5c$db50b750$91f225f0$@com> References: <002a01c90e5c$db50b750$91f225f0$@com> Message-ID: <0867622C64B50C4B878AB45C95F43F1106150A2F@MAILWA01.wesenergy.local> This is because you are trying to reserve more than 75% of the actual bandwidth. Remember that by default cisco allows 25% for the class default to allow for routing protocol and network management traffic etc.. It is possibly best to use bandwidth percent and priority percent to make this clear or if the interface is later upgraded etc. You can remove the class-default 25% restriction by the way but I cannot remember the command to do it sorry :) I am sure google will have the answer for you :) Cheers, Aaron. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ryan Sent: Thursday, 4 September 2008 3:07 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] silly qos question Hey all, Quick QoS question here. I seem to be having some trouble getting a policy applied to a Serial (T1) interface, and for the life of me don?t understand why. I?m pretty sure it?s my fault and not a ?feature?. Error I am getting when I try to apply the service policy direction output: %INTERFACE_NAME% class Data-DSCP requested bandwidth 750 (kbps) Available only 656 (kbps) Here are the class/policy map statements: class-map match-any Control-DSCP match ip dscp cs3 match ip dscp af31 class-map match-any Voice-DSCP match ip dscp ef class-map match-any Video-DSCP match ip dscp af41 class-map match-any class-default class-map match-any Data-DSCP match ip dscp default policy-map QoS-Policy-Office class Voice-DSCP priority 360 class Video-DSCP bandwidth 128 class Control-DSCP bandwidth 8 class Data-DSCP bandwidth 750 class class-default If I bump bandwidth of class Data-DSCP down to 656 from 750, it applies with no backtalk. Clearly I am missing something on a conceptual level, here. Any help is appreciated. ? Platform: 7206VXR, NPE-G1 running 12.3(26) SP code. Thanks! -Ryan _______________________________________________ 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/ LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From stretch at packetlife.net Thu Sep 4 03:39:37 2008 From: stretch at packetlife.net (Jeremy Stretch) Date: Thu, 04 Sep 2008 10:39:37 +0300 Subject: [c-nsp] silly qos question In-Reply-To: <002a01c90e5c$db50b750$91f225f0$@com> References: <002a01c90e5c$db50b750$91f225f0$@com> Message-ID: <48BF90B9.8090001@packetlife.net> With the 656 Kbps limit for the Data-DSCP class, your reserved bandwidths total 1152 Kbps, or 75% of a 1.536 Mbps interface. Remember that by default IOS will only reserve up to 75% of an interface's bandwidth. You should be able to change this with the 'max-reserved-bandwidth ' command applied to the interface. -- stretch http://packetlife.net Ryan wrote: > Hey all, > > Quick QoS question here. I seem to be having some trouble getting a policy applied to a Serial (T1) interface, and for the life of me don???t understand why. I???m pretty sure it???s my fault and not a ???feature???. > > Error I am getting when I try to apply the service policy direction output: > > %INTERFACE_NAME% class Data-DSCP requested bandwidth 750 (kbps) Available only 656 (kbps) > > > Here are the class/policy map statements: > > class-map match-any Control-DSCP > match ip dscp cs3 > match ip dscp af31 > class-map match-any Voice-DSCP > match ip dscp ef > class-map match-any Video-DSCP > match ip dscp af41 > class-map match-any class-default > class-map match-any Data-DSCP > match ip dscp default > > policy-map QoS-Policy-Office > class Voice-DSCP > priority 360 > class Video-DSCP > bandwidth 128 > class Control-DSCP > bandwidth 8 > class Data-DSCP > bandwidth 750 > class class-default > > If I bump bandwidth of class Data-DSCP down to 656 from 750, it applies with no backtalk. > > Clearly I am missing something on a conceptual level, here. Any help is appreciated. ??? > > Platform: > > 7206VXR, NPE-G1 running 12.3(26) SP code. > > Thanks! > -Ryan > > > > _______________________________________________ > 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 Sep 4 03:44:23 2008 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Thu, 04 Sep 2008 10:44:23 +0300 Subject: [c-nsp] DHCP and HSRP In-Reply-To: <06C1E76E03FE9C4B85BFA9C75365D9DA0FC011D4@tiger.deltadentalwa.com> References: <06C1E76E03FE9C4B85BFA9C75365D9DA0FC011D4@tiger.deltadentalwa.com> Message-ID: <48BF91D7.9030603@forthnet.gr> Cisco was supposed to add the ip redundancy feature of HSRP to the DHCP server functionality, like it's happening with NAT. I don't know if this has happened... At least the UDP forwarding support is there. -- Tassos Teller, Robert wrote on 4/9/2008 1:40 ??: > Is it possible to configure two 6509's to share DHCP information so that > if the active HSRP router goes down and the standby comes up it doesn't > generate a bunch of ip conflicts? Or do I need to maintain a separate > scope on each HSRP member? > > > > Robert Teller > Washington Dental Service > Network Administrator > (206) 528-2371 > RTeller at DeltaDentalWa.com > > > > > ######################################################### > The information contained in this e-mail and subsequent attachments may be privileged, > confidential and protected from disclosure. This transmission is intended for the sole > use of the individual and entity to whom it is addressed. If you are not the intended > recipient, any dissemination, distribution or copying is strictly prohibited. If you > think that you have received this message in error, please e-mail the sender at the above > e-mail address. > ######################################################### > _______________________________________________ > 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 ariemer at wesenergy.com.au Thu Sep 4 03:45:09 2008 From: ariemer at wesenergy.com.au (Aaron Riemer) Date: Thu, 4 Sep 2008 15:45:09 +0800 Subject: [c-nsp] silly qos question In-Reply-To: <002a01c90e5c$db50b750$91f225f0$@com> References: <002a01c90e5c$db50b750$91f225f0$@com> Message-ID: <0867622C64B50C4B878AB45C95F43F1106150A3C@MAILWA01.wesenergy.local> Further to my original post the way to get around the 25% class-default limit is to use the interface command max-reserved-bandwidth. HTH. Cheers, Aaron. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ryan Sent: Thursday, 4 September 2008 3:07 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] silly qos question Hey all, Quick QoS question here. I seem to be having some trouble getting a policy applied to a Serial (T1) interface, and for the life of me don?t understand why. I?m pretty sure it?s my fault and not a ?feature?. Error I am getting when I try to apply the service policy direction output: %INTERFACE_NAME% class Data-DSCP requested bandwidth 750 (kbps) Available only 656 (kbps) Here are the class/policy map statements: class-map match-any Control-DSCP match ip dscp cs3 match ip dscp af31 class-map match-any Voice-DSCP match ip dscp ef class-map match-any Video-DSCP match ip dscp af41 class-map match-any class-default class-map match-any Data-DSCP match ip dscp default policy-map QoS-Policy-Office class Voice-DSCP priority 360 class Video-DSCP bandwidth 128 class Control-DSCP bandwidth 8 class Data-DSCP bandwidth 750 class class-default If I bump bandwidth of class Data-DSCP down to 656 from 750, it applies with no backtalk. Clearly I am missing something on a conceptual level, here. Any help is appreciated. ? Platform: 7206VXR, NPE-G1 running 12.3(26) SP code. Thanks! -Ryan _______________________________________________ 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/ LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From ryanclambert at gmail.com Thu Sep 4 03:45:41 2008 From: ryanclambert at gmail.com (Ryan) Date: Thu, 4 Sep 2008 03:45:41 -0400 Subject: [c-nsp] silly qos question In-Reply-To: <48BF8EF8.60202@forthnet.gr> References: <002a01c90e5c$db50b750$91f225f0$@com> <48BF8EF8.60202@forthnet.gr> Message-ID: <002b01c90e62$3b99d150$b2cd73f0$@com> Got it. Thanks everyone for the quick response; my hair was coming out. I did a 12.0(28)S -> 12.3(26) upgrade and it started yapping at me. I neglected to mention that, sorry -- it's almost 4am. The old software just let me do it without any feedback. I guess I ASSumed it was all just as well. My first mistake. :) -Ryan -----Original Message----- From: Tassos Chatzithomaoglou [mailto:achatz at forthnet.gr] Sent: Thursday, September 04, 2008 3:32 AM To: Ryan Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] silly qos question Ryan, have a look at the max-reserved-bandwidth command. http://www.cisco.com/en/US/docs/ios/12_3/qos/command/reference/qos_m1g.html# wp1113113 -- Tassos Ryan wrote on 4/9/2008 10:07 ??: > Hey all, > > Quick QoS question here. I seem to be having some trouble getting a policy applied to a Serial (T1) interface, and for the life of me don?t understand why. I?m pretty sure it?s my fault and not a "feature". > > Error I am getting when I try to apply the service policy direction output: > > %INTERFACE_NAME% class Data-DSCP requested bandwidth 750 (kbps) Available only 656 (kbps) > > > Here are the class/policy map statements: > > class-map match-any Control-DSCP > match ip dscp cs3 > match ip dscp af31 > class-map match-any Voice-DSCP > match ip dscp ef > class-map match-any Video-DSCP > match ip dscp af41 > class-map match-any class-default > class-map match-any Data-DSCP > match ip dscp default > > policy-map QoS-Policy-Office > class Voice-DSCP > priority 360 > class Video-DSCP > bandwidth 128 > class Control-DSCP > bandwidth 8 > class Data-DSCP > bandwidth 750 > class class-default > > If I bump bandwidth of class Data-DSCP down to 656 from 750, it applies with no backtalk. > > Clearly I am missing something on a conceptual level, here. Any help is appreciated. ? > > Platform: > > 7206VXR, NPE-G1 running 12.3(26) SP code. > > Thanks! > -Ryan > > > > _______________________________________________ > 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 CB at nianet.dk Thu Sep 4 03:46:33 2008 From: CB at nianet.dk (Christian Bering) Date: Thu, 4 Sep 2008 09:46:33 +0200 Subject: [c-nsp] Dreaded FIB Exception on Sup2 References: <1220470004.32656.7.camel@abehat> <20080904061039.GM233@greenie.muc.de> Message-ID: Gert et al, >Besides, if you happen to *have* a 6500 chassis, the RSP won't >work there. Ah. Since we stuck to 7600s that difference had escaped me. Thanks for clarifying. -- Regards Christian Bering From gert at greenie.muc.de Thu Sep 4 04:02:08 2008 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 4 Sep 2008 10:02:08 +0200 Subject: [c-nsp] CSS strange behaviour.... Or is it just my config [7:132492] In-Reply-To: References: <200809040227.m842RBGe015086@groupstudy.com> <20080904062227.GP233@greenie.muc.de> Message-ID: <20080904080208.GA17238@greenie.muc.de> Hi, On Thu, Sep 04, 2008 at 05:49:31PM +1000, Brett Clausenhauf wrote: > Undortunately this is doubtful. The web server is literally just configured > & is not logging.Regards, By default, most webservers *do* log... As I said, this was just a stab in the dark - run tcpdump (or wireshark) on the server to see what sort of outgoing connections it does. 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 gert at greenie.muc.de Thu Sep 4 04:24:59 2008 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 4 Sep 2008 10:24:59 +0200 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: References: <1220470004.32656.7.camel@abehat> <20080904061039.GM233@greenie.muc.de> Message-ID: <20080904082459.GC17238@greenie.muc.de> Hi, On Thu, Sep 04, 2008 at 09:46:33AM +0200, Christian Bering wrote: > >Besides, if you happen to *have* a 6500 chassis, the RSP won't > >work there. > > Ah. Since we stuck to 7600s that difference had escaped me. Thanks for > clarifying. On a 7600, you can use Sup720 or RSP720, but you can't use Sup720-10Gs, which are quite nice... 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: 304 bytes Desc: not available URL: From jr at xor.at Thu Sep 4 03:37:08 2008 From: jr at xor.at (Johannes Resch) Date: Thu, 4 Sep 2008 09:37:08 +0200 (CEST) Subject: [c-nsp] silly qos question In-Reply-To: <002a01c90e5c$db50b750$91f225f0$@com> References: <002a01c90e5c$db50b750$91f225f0$@com> Message-ID: <36898.195.112.95.126.1220513828.squirrel@and.xor.at> On Thu, September 4, 2008 09:07, Ryan wrote: > Hey all, > > Quick QoS question here. I seem to be having some trouble getting a policy > applied to a Serial (T1) interface, and for the life of me don???t > understand why. I???m pretty sure it???s my fault and not a ???feature???. > > Error I am getting when I try to apply the service policy direction > output: > > %INTERFACE_NAME% class Data-DSCP requested bandwidth 750 (kbps) Available > only 656 (kbps) Did you set "max-reserved-bandwidth" to 100% on the interface? Regards, -jr From Oliver.Dewdney at LBi.com Thu Sep 4 06:20:13 2008 From: Oliver.Dewdney at LBi.com (Oliver Dewdney) Date: Thu, 4 Sep 2008 11:20:13 +0100 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: References: Message-ID: Do you need full routing tables? Jon Lewis emailed a week ago about how to reduce the table by filtering the bgp feeds to get the table to fit. I think that the routing/connectivity should be fine for a hosting provider. http://jonsblog.lewis.org/ which can be used until you are in a position to upgrade or Cisco come out with a FIB optimization, which will never happen. How did Cisco come out with so many 720s that the compatibility matrix is so complicated? Oli -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Rick Kunkel Sent: 03 September 2008 18:59 To: cisco-nsp at puck.nether.net Subject: [c-nsp] Dreaded FIB Exception on Sup2 Well, I've hit the dreaded error message on my Sup2: %MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched I've done a lot of reading on this (cisco.com, this list, etc.), with the conclusion that this supervisor engine is likely just at the end of its useful lifetime, but I figured I'd double check I wasn't missing anything. This happened when I started getting a full routing table from a provider today. We're connected to one peering point and another aggregation-style provider, and are in the process of adding a Cogent connection (hold any tempting comments on that one, please). LBi. The global marketing and technology agency. Winner: Media Guardian Design Innovation Award 2008 LBi Ltd is registered in England and Wales, the registered number and address are 03080409, Truman Brewery, 146 Brick Lane, London, E1 6RU. This email may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From MLouis at nwnit.com Thu Sep 4 07:42:22 2008 From: MLouis at nwnit.com (Mike Louis) Date: Thu, 4 Sep 2008 07:42:22 -0400 Subject: [c-nsp] silly qos question Message-ID: I usually set the max reserve command to 95 percent to leave room for routing and other overhead. That way I don't have to specify a specific class to take care of it if I reserve akll remaining bw in the pm -----Original Message----- From: Johannes Resch Sent: Thursday, September 04, 2008 5:43 AM To: Ryan Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] silly qos question On Thu, September 4, 2008 09:07, Ryan wrote: > Hey all, > > Quick QoS question here. I seem to be having some trouble getting a policy > applied to a Serial (T1) interface, and for the life of me don???t > understand why. I???m pretty sure it???s my fault and not a ???feature???. > > Error I am getting when I try to apply the service policy direction > output: > > %INTERFACE_NAME% class Data-DSCP requested bandwidth 750 (kbps) Available > only 656 (kbps) Did you set "max-reserved-bandwidth" to 100% on the interface? Regards, -jr _______________________________________________ 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. From tim at pelican.org Thu Sep 4 07:55:42 2008 From: tim at pelican.org (Tim Franklin) Date: Thu, 4 Sep 2008 12:55:42 +0100 (BST) Subject: [c-nsp] silly qos question In-Reply-To: References: Message-ID: <7e23c545134878c7cffa696d344457e6.squirrel@webmail.pelican.org> On Thu, September 4, 2008 12:42 pm, Mike Louis wrote: > I usually set the max reserve command to 95 percent to leave room for > routing and other overhead. That way I don't have to specify a specific > class to take care of it if I reserve akll remaining bw in the pm Be careful, this *doesn't* guarantee that remaining 5% is reserved for management / routing, unless you explicitly police all the other classes. It stops you *reserving* it for other classes, but it doesn't stop those other classes *using* it. Much safer, IMO, to put a class (or classes) in for management / routing, and then let the bandwidth reserved for these go back into the pool while it's not being used. Regards, Tim. From fweimer at bfk.de Thu Sep 4 08:05:54 2008 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 04 Sep 2008 14:05:54 +0200 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: (Oliver Dewdney's message of "Thu, 4 Sep 2008 11:20:13 +0100") References: Message-ID: <82vdxc2k0t.fsf@mid.bfk.de> * Oliver Dewdney: > Do you need full routing tables? Jon Lewis emailed a week ago about > how to reduce the table by filtering the bgp feeds to get the table > to fit. I think that the routing/connectivity should be fine for a > hosting provider. > > http://jonsblog.lewis.org/ Do you mean the filters based on RIR minimum allocations? From time to time, someone who should now better announces something smaller without the covering aggregate, so this requires some maintenance. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From gert at greenie.muc.de Thu Sep 4 08:18:49 2008 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 4 Sep 2008 14:18:49 +0200 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: <82vdxc2k0t.fsf@mid.bfk.de> References: <82vdxc2k0t.fsf@mid.bfk.de> Message-ID: <20080904121849.GE17238@greenie.muc.de> Hi, On Thu, Sep 04, 2008 at 02:05:54PM +0200, Florian Weimer wrote: > Do you mean the filters based on RIR minimum allocations? From time > to time, someone who should now better announces something smaller > without the covering aggregate, So what? They do not want your traffic, obviously... 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: 304 bytes Desc: not available URL: From philou at philou.ch Thu Sep 4 07:23:45 2008 From: philou at philou.ch (Philippe Strauss) Date: Thu, 4 Sep 2008 13:23:45 +0200 Subject: [c-nsp] c7604 "starter kit" Message-ID: <20080904112344.GA2758@whitechalk.dfinet.ch> Hello c-nsp, For a small ISP who need to get a routing gear much more resistant do DDoS than 7200 NPE-G1/2 (with a bit over 400kpps on a POS OC3 on a G2, the router is at 100% CPU, probably better on ethernet but...), what is the entry level 7600? I'm new to the convoluted world of hardware routing :-) chassis 7604? 3bxl or 3cxl? sup720 or rsp720? linecard: what are the SPA? distributed forwarding? we don't need it a priori. there is a 6 gbic port (2+4) with PXF, what is this beast? probably something to avoid. I've heard once upon a time a 8 port GigE linecard was available and not anymore. will the 8 port fixed GigE (not 10/100 but only 1000) of the cat6500 line work in a c7600? We don't need 20 ports and that's a bit expensive. All port must do layer3, of course. Full BGP table, many times (3 full peer plus 100 local peerings w few prefixes). TIA! -- Philippe Strauss http://philou.ch From fweimer at bfk.de Thu Sep 4 09:13:21 2008 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 04 Sep 2008 15:13:21 +0200 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: <20080904121849.GE17238@greenie.muc.de> (Gert Doering's message of "Thu, 4 Sep 2008 14:18:49 +0200") References: <82vdxc2k0t.fsf@mid.bfk.de> <20080904121849.GE17238@greenie.muc.de> Message-ID: <82ljy82gwe.fsf@mid.bfk.de> * Gert Doering: > On Thu, Sep 04, 2008 at 02:05:54PM +0200, Florian Weimer wrote: >> Do you mean the filters based on RIR minimum allocations? From time >> to time, someone who should now better announces something smaller >> without the covering aggregate, > > So what? They do not want your traffic, obviously... But your customers might be interested in theirs. To some extent, RIR minimum allocation filters trade FIB resources for operator resources. Desparate attempts at traffic engineering are certainly not restricted to those who have no traffic to deal with. 8-/ -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From rich.davies at gmail.com Thu Sep 4 09:21:37 2008 From: rich.davies at gmail.com (Rich Davies) Date: Thu, 4 Sep 2008 09:21:37 -0400 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: <20080904121849.GE17238@greenie.muc.de> References: <82vdxc2k0t.fsf@mid.bfk.de> <20080904121849.GE17238@greenie.muc.de> Message-ID: <3e4b8fe10809040621i2826be74o6cd14b9648631706@mail.gmail.com> Has anyone ever utilized Unicast RPF (reverse path forwarding) to help mitigate this limitation on the SUP2's? I have also ran into the same limitation with our SUP2's (full BGP routing table, multiple peering sessions) and I have read that enabling Unicast RPF would help temporarily alleviate the TCAM memory being exhausted but in the long run a SUP7203BXL would be the best solution (unfortunately very pricy). Has anyone ever used uRPF to help correct this (for short term) or is the SUP7203BXL the only solution? -Rich Rich Davies rich.davies at gmail.com On Thu, Sep 4, 2008 at 8:18 AM, Gert Doering wrote: > Hi, > > On Thu, Sep 04, 2008 at 02:05:54PM +0200, Florian Weimer wrote: > > Do you mean the filters based on RIR minimum allocations? From time > > to time, someone who should now better announces something smaller > > without the covering aggregate, > > So what? They do not want your traffic, obviously... > > 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 > > _______________________________________________ > 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 saku+cisco-nsp at ytti.fi Thu Sep 4 09:23:55 2008 From: saku+cisco-nsp at ytti.fi (Saku Ytti) Date: Thu, 4 Sep 2008 16:23:55 +0300 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <20080904112344.GA2758@whitechalk.dfinet.ch> References: <20080904112344.GA2758@whitechalk.dfinet.ch> Message-ID: <20080904132355.GA17595@mx.ytti.net> On (2008-09-04 13:23 +0200), Philippe Strauss wrote: Hey, > chassis 7604? This is fine it's 'S' chassis like 7606S and 7609S even though the 'S' is not visible there and it's black and not white :). Technically it's the same. > 3bxl or 3cxl? > sup720 or rsp720? sup720 comes 3c(xl) and rsp720 comes with 3b(xl). Differences between C and B are rather minor and mostly related to L2 (like more MACs). However there are some rarely mentioned things fixed in 3C that affect eg. MPLS. Big benefit of RSP720 is MSFC4, which means you have faster control-plane which can take more memory. I would definitely go with RSP720. > linecard: what are the SPA? distributed forwarding? we don't need it a priori. > there is a 6 gbic port (2+4) with PXF, what is this beast? probably something > to avoid. SPA's house intelligent ports, which means mainly HQoS and vlan local signifance and of course non-ethernet interface. If you don't need any feature SPA has, you really should go with LAN card, due to cost reaons. > I've heard once upon a time a 8 port GigE linecard was available and not anymore. > will the 8 port fixed GigE (not 10/100 but only 1000) of the cat6500 line work > in a c7600? If you buy LAN cards, I wouldn't look other than WS-X67.. and WS-X65.. as they connected to the fabric. > We don't need 20 ports and that's a bit expensive. > All port must do layer3, of course. All LAN cards with 3B/3C will happily do not just L3 but also MPLS. > Full BGP table, many times (3 full peer plus 100 local peerings w few prefixes). No problem (you need XL) You might also look at ASR1k as next-gen PE to replace VXR. 7600 has limitation in hardware, especially in terms of IPv6 (no IPv6 uRPF, lookup key size has compromises in ACL usage and others). When you compare 7600 with SIP/SPA, ASR1k is even cheaper solution and much more flexible. One thing to notice is that ASR1k does not currently have EoMPLS support in any software, but other than that, all generally used features are supported. If I'd need non-ethernet interfaces, vlan local signifance or HQoS and I wouldn't need EoMPLS, I'd definitely go with ASR1k rather than 7600. -- ++ytti From fweimer at bfk.de Thu Sep 4 09:25:33 2008 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 04 Sep 2008 15:25:33 +0200 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: <3e4b8fe10809040621i2826be74o6cd14b9648631706@mail.gmail.com> (Rich Davies's message of "Thu, 4 Sep 2008 09:21:37 -0400") References: <82vdxc2k0t.fsf@mid.bfk.de> <20080904121849.GE17238@greenie.muc.de> <3e4b8fe10809040621i2826be74o6cd14b9648631706@mail.gmail.com> Message-ID: <82d4jk2gc2.fsf@mid.bfk.de> * Rich Davies: > Has anyone ever utilized Unicast RPF (reverse path forwarding) to help > mitigate this limitation on the SUP2's? I have also ran into the same > limitation with our SUP2's (full BGP routing table, multiple peering > sessions) and I have read that enabling Unicast RPF would help temporarily > alleviate the TCAM memory being exhausted On a MSFC2/PFC2, enabling uRPF cuts the number of available routes in half, so it makes things only worse. Don't know about more modern MSFCs, sorry. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From gert at greenie.muc.de Thu Sep 4 09:23:39 2008 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 4 Sep 2008 15:23:39 +0200 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: <3e4b8fe10809040621i2826be74o6cd14b9648631706@mail.gmail.com> References: <82vdxc2k0t.fsf@mid.bfk.de> <20080904121849.GE17238@greenie.muc.de> <3e4b8fe10809040621i2826be74o6cd14b9648631706@mail.gmail.com> Message-ID: <20080904132339.GG17238@greenie.muc.de> Hi, On Thu, Sep 04, 2008 at 09:21:37AM -0400, Rich Davies wrote: > Has anyone ever utilized Unicast RPF (reverse path forwarding) to help > mitigate this limitation on the SUP2's? I have also ran into the same > limitation with our SUP2's (full BGP routing table, multiple peering > sessions) and I have read that enabling Unicast RPF would help temporarily > alleviate the TCAM memory being exhausted You have read funny stuff. Enabling uRPF on the SUP2 *halves* the available TCAM space, to 128k routes. 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: 304 bytes Desc: not available URL: From swmike at swm.pp.se Thu Sep 4 09:30:00 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 4 Sep 2008 15:30:00 +0200 (CEST) Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <20080904112344.GA2758@whitechalk.dfinet.ch> References: <20080904112344.GA2758@whitechalk.dfinet.ch> Message-ID: On Thu, 4 Sep 2008, Philippe Strauss wrote: > I'm new to the convoluted world of hardware routing :-) > > chassis 7604? > 3bxl or 3cxl? > sup720 or rsp720? Latest, same money, newer hardware, so 7604 RSP720-3CXL. > linecard: what are the SPA? distributed forwarding? we don't need it a priori. > there is a 6 gbic port (2+4) with PXF, what is this beast? probably something > to avoid. You need OC3 ports? Yeah, you're going to be paying a lot for SIP-400+SPA, it'll do 4 gigabit/s actual traffic. > I've heard once upon a time a 8 port GigE linecard was available and not anymore. > will the 8 port fixed GigE (not 10/100 but only 1000) of the cat6500 line work > in a c7600? Yes. > We don't need 20 ports and that's a bit expensive. > All port must do layer3, of course. > Full BGP table, many times (3 full peer plus 100 local peerings w few prefixes). Full BGP table costs money, if you're on a budget, get a used Cisco 12000, it'll take you into the gigabits/s realm quite cheaply, then when you're past that, go for 7600. 7600 makes a lot of sense if you're ethernet only, the SONET/SDH interfaces are quite pricey due to the need for SIP/SPAs. -- Mikael Abrahamsson email: swmike at swm.pp.se From lists at memetic.org Thu Sep 4 09:31:56 2008 From: lists at memetic.org (Adam Armstrong) Date: Thu, 04 Sep 2008 14:31:56 +0100 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <20080904112344.GA2758@whitechalk.dfinet.ch> References: <20080904112344.GA2758@whitechalk.dfinet.ch> Message-ID: <48BFE34C.30106@memetic.org> > For a small ISP who need to get a routing gear much more resistant do DDoS than > 7200 NPE-G1/2 (with a bit over 400kpps on a POS OC3 on a G2, the router is at 100% CPU, > probably better on ethernet but...), what is the entry level 7600? > > I'm new to the convoluted world of hardware routing :-) > > chassis 7604? > 7603 or 7604, depending upon wether you want redundant SUP/RSP. > 3bxl or 3cxl? > sup720 or rsp720? > Those two quetsions are the same, SUP720 is 3BXL and RSP720 is 3CXL. The RSP is the 'official' 7600 version. It has twice the router processor speed, and a slightly enanced PFC, so just get the RSP (it's the same price!). > linecard: what are the SPA? distributed forwarding? we don't need it a priori. > there is a 6 gbic port (2+4) with PXF, what is this beast? probably something > to avoid. > SPA are interface cards. On the 7600 platform you put SPAs into SIP, which is basically an ASIC based carrier card which sits on the switch fabric (they do more features than the lan cards). If you're not doing VPLS or very complex QoS, you don't need SIP/SPA, lan cards will be fine. If you need to terminate a POS interface, you will need a SIP/SPA though... Don't use the old PA carriers, as they just effectively have 7200-speed processors doing the forwarding, so are still susceptible to DoS. > I've heard once upon a time a 8 port GigE linecard was available and not anymore. > will the 8 port fixed GigE (not 10/100 but only 1000) of the cat6500 line work > in a c7600? > Almost always, yes. There are some cards which won't, such as the the 8 port 10GE card. > We don't need 20 ports and that's a bit expensive. > All port must do layer3, of course. > Full BGP table, many times (3 full peer plus 100 local peerings w few prefixes). > A 7600 with RSP 7200 will do lots of full tables. All lan cards will do ports as L3. You might want to look at buying the lan cards 2nd user, they're an order of magnitude cheaper than new! (especially older cards like the WS-X6148G). I hope that helps. adam. From dgranzer at gmail.com Thu Sep 4 10:11:06 2008 From: dgranzer at gmail.com (David Granzer) Date: Thu, 4 Sep 2008 16:11:06 +0200 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <20080904132355.GA17595@mx.ytti.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <20080904132355.GA17595@mx.ytti.net> Message-ID: <844ef89c0809040711w480d9586peaade37cc4054102@mail.gmail.com> Hello, On 9/4/08, Saku Ytti wrote: > On (2008-09-04 13:23 +0200), Philippe Strauss wrote: > > Hey, > > > chassis 7604? > > This is fine it's 'S' chassis like 7606S and 7609S even though the 'S' > is not visible there and it's black and not white :). Technically it's > the same. > > > > 3bxl or 3cxl? > > sup720 or rsp720? > > > sup720 comes 3c(xl) and rsp720 comes with 3b(xl). RSP720 comes with 3C(XL) and SUP720 with 3B(XL). WS-SUP720-3BXL RSP720-3CXL-GE SUP720 - Supervisor 720 is designed for 6500 series RSP720 - Route Switch Processor 720 is designed for 7600 series Regards, David > Differences between C and > B are rather minor and mostly related to L2 (like more MACs). However > there are some rarely mentioned things fixed in 3C that affect eg. MPLS. > Big benefit of RSP720 is MSFC4, which means you have faster control-plane > which can take more memory. I would definitely go with RSP720. > > > > linecard: what are the SPA? distributed forwarding? we don't need it a priori. > > there is a 6 gbic port (2+4) with PXF, what is this beast? probably something > > to avoid. > > > SPA's house intelligent ports, which means mainly HQoS and vlan local signifance > and of course non-ethernet interface. > If you don't need any feature SPA has, you really should go with LAN card, > due to cost reaons. > > > > I've heard once upon a time a 8 port GigE linecard was available and not anymore. > > will the 8 port fixed GigE (not 10/100 but only 1000) of the cat6500 line work > > in a c7600? > > > If you buy LAN cards, I wouldn't look other than WS-X67.. and WS-X65.. as > they connected to the fabric. > > > > We don't need 20 ports and that's a bit expensive. > > All port must do layer3, of course. > > > All LAN cards with 3B/3C will happily do not just L3 but also MPLS. > > > > Full BGP table, many times (3 full peer plus 100 local peerings w few prefixes). > > > No problem (you need XL) > > > You might also look at ASR1k as next-gen PE to replace VXR. 7600 has > limitation in hardware, especially in terms of IPv6 (no IPv6 uRPF, lookup > key size has compromises in ACL usage and others). When you compare > 7600 with SIP/SPA, ASR1k is even cheaper solution and much more flexible. > One thing to notice is that ASR1k does not currently have EoMPLS support > in any software, but other than that, all generally used features > are supported. > If I'd need non-ethernet interfaces, vlan local signifance or HQoS and > I wouldn't need EoMPLS, I'd definitely go with ASR1k rather than 7600. > > -- > > ++ytti > > _______________________________________________ > 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 sabt at sabt.net Thu Sep 4 10:00:54 2008 From: sabt at sabt.net (Sebastian Abt) Date: Thu, 4 Sep 2008 16:00:54 +0200 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <20080904132355.GA17595@mx.ytti.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <20080904132355.GA17595@mx.ytti.net> Message-ID: <20080904140054.GL4491@sephina.sabt.net> * Saku Ytti wrote: > sup720 comes 3c(xl) and rsp720 comes with 3b(xl). Vice versa you mean, don't you? sebastian -- SABT-RIPE PGPKEY-D008DA9C From greg at ip-man.net Thu Sep 4 11:17:41 2008 From: greg at ip-man.net (Gregoire Huet) Date: Thu, 04 Sep 2008 17:17:41 +0200 Subject: [c-nsp] Moving Sup720 from cat6k to 7600 Message-ID: <48BFFC15.2020200@ip-man.net> Hello I would like to boot a Sup720-3BXL in a 7604 chassis, but it won't. The sup was previously used in a cat6k chassis (as announced by the bootstrap), and even with a CompactFlash formatted on a running 7604/720-3BXL, the blade does not boot. The compact flash is readable and a 'dir' shows the image, but booting on it crashes after a while (there is just the ATA line displayed), and about 30 seconds after, it's returning to rommon with a weird message (that i can possibly report here if needed). Is there a known trick to 'convert' the blade from cat6k to 76xx ? Thanks a lot for any help Best regards, Gregoire Huet From elmi at 4ever.de Thu Sep 4 11:24:21 2008 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 4 Sep 2008 17:24:21 +0200 Subject: [c-nsp] 7301 (NPE-G1) leaking L2 frames over L3 In-Reply-To: <20080821143415.GT12234@ronin.4ever.de> References: <20080821143415.GT12234@ronin.4ever.de> Message-ID: <20080904152421.GR48711@ronin.4ever.de> Following up on my own problem... (fullquote provided for context in archives) upgrading from 12.3(14)T7 to 12.4(21) fixed the leakage. Just in case anyone else runs into that problem... Yours, Elmar. elmi at 4ever.de (Elmar K. Bins) wrote: > Hi knowledgeable folks, > > I have a somewhat weird issue with an admittedly slightly aged IOS > on a 7301: That router is leaking Ethernet frames from one L3 interface > to another. > > I have been alerted by the folks at the exchange (who monitor very > closely, thanks). Since they haven't turned my port off yet, > leaking should be minimal. > > The box is a 7301 with PA-2FE-TX (f1/0 connected to the exchange), > running IOS 12.3(14)T7. > > Inside - towards some servers - is a L3 portchannel > (via a WS-3750): > > interface Port-channel1 > description PO to sw (via g0/0 and g0/1) > ip address xxx.xxx.xxx.1 255.255.255.0 > ip access-group MGT-no in > ip access-group acl-SERVICE-out out > no ip redirects > no ip unreachables > no ip proxy-arp > ip route-cache same-interface > ip route-cache flow > load-interval 30 > duplex full > hold-queue 150 in > end > > > Outside is a layer 3 port to the exchange fabric: > > interface FastEthernet1/0 > description exchange port > ip address xxx.xxx.xxx.xxx 255.255.254.0 > ip access-group FILTER_IN-FastEthernet1-0-in-3 in > no ip redirects > no ip unreachables > no ip proxy-arp > ip accounting mac-address input > ip accounting mac-address output > ip accounting access-violations > load-interval 30 > duplex full > speed 100 > ipv6 address xx:xx:xx:xx:xx:xx:xx:xx/64 > ipv6 nd suppress-ra > no ipv6 mld router > no keepalive > no cdp enable > end > > > Captured frames show that Ethernet frames with source MACs > of the server NICs make it to the exchange fabric somehow. > > My questions: > > - is this some kind of misconfiguration on my part? > - if not: does anyone know of / remember such a bug? > - how could I find info, probably on cisco.com? > > I'm at a loss here. Blindly upgrading to T14 or whatever > might or might not kill the bug. I'd like to reboot as > rarely as possible... > > Thanks for any help, hints or insight. > > Elmar. From saku+cisco-nsp at ytti.fi Thu Sep 4 11:35:20 2008 From: saku+cisco-nsp at ytti.fi (Saku Ytti) Date: Thu, 4 Sep 2008 18:35:20 +0300 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <20080904140054.GL4491@sephina.sabt.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <20080904132355.GA17595@mx.ytti.net> <20080904140054.GL4491@sephina.sabt.net> Message-ID: <20080904153520.GA22840@mx.ytti.net> On (2008-09-04 16:00 +0200), Sebastian Abt wrote: > * Saku Ytti wrote: > > sup720 comes 3c(xl) and rsp720 comes with 3b(xl). > > Vice versa you mean, don't you? Indeed thanks for catching it. -- ++ytti From cchurc05 at harris.com Thu Sep 4 11:53:38 2008 From: cchurc05 at harris.com (Church, Charles) Date: Thu, 4 Sep 2008 10:53:38 -0500 Subject: [c-nsp] Moving Sup720 from cat6k to 7600 In-Reply-To: <48BFFC15.2020200@ip-man.net> References: <48BFFC15.2020200@ip-man.net> Message-ID: Is it possible you're trying to boot an IOS version that doesn't support that chassis? I'm sure there is a minimum version for a 7604, and I'm sure it's more recent than the minimum for the 6500 it came out of. Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Gregoire Huet Sent: Thursday, September 04, 2008 11:18 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Moving Sup720 from cat6k to 7600 Hello I would like to boot a Sup720-3BXL in a 7604 chassis, but it won't. The sup was previously used in a cat6k chassis (as announced by the bootstrap), and even with a CompactFlash formatted on a running 7604/720-3BXL, the blade does not boot. The compact flash is readable and a 'dir' shows the image, but booting on it crashes after a while (there is just the ATA line displayed), and about 30 seconds after, it's returning to rommon with a weird message (that i can possibly report here if needed). Is there a known trick to 'convert' the blade from cat6k to 76xx ? Thanks a lot for any help Best regards, Gregoire Huet _______________________________________________ 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 Thu Sep 4 12:29:19 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Thu, 04 Sep 2008 18:29:19 +0200 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <48BFE34C.30106@memetic.org> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <48BFE34C.30106@memetic.org> Message-ID: <1220545759.13061.9.camel@abehat> On Thu, 2008-09-04 at 14:31 +0100, Adam Armstrong wrote: > On Thu, 2008-09-04 at 13:23 +0200, Philippe Strauss wrote: > > I've heard once upon a time a 8 port GigE linecard was available and > > not anymore. will the 8 port fixed GigE (not 10/100 but only 1000) of > > the cat6500 line work in a c7600? > > Almost always, yes. There are some cards which won't, such as the the 8 > port 10GE card. C7600/SRC supports the WS-X6708-10G-3C{,XL}. The 16 port WS-X6716-10G-3C is 6500 only though. > A 7600 with RSP 7200 will do lots of full tables. All lan cards will do > ports as L3. You might want to look at buying the lan cards 2nd user, > they're an order of magnitude cheaper than new! (especially older cards > like the WS-X6148G). Beware of the non-fabric-enabled and 8:1 oversubscribed 6148 cards. They're LAN cards, so they have all the PFC features, but capacity wise they're not exactly brilliant. Regards, Peter From peter at rathlev.dk Thu Sep 4 12:36:01 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Thu, 04 Sep 2008 18:36:01 +0200 Subject: [c-nsp] Moving Sup720 from cat6k to 7600 In-Reply-To: <48BFFC15.2020200@ip-man.net> References: <48BFFC15.2020200@ip-man.net> Message-ID: <1220546161.13061.12.camel@abehat> On Thu, 2008-09-04 at 17:17 +0200, Gregoire Huet wrote: > Hello > > I would like to boot a Sup720-3BXL in a 7604 chassis, but it won't. > > The sup was previously used in a cat6k chassis (as announced by the > bootstrap), and even with a CompactFlash formatted on a running > 7604/720-3BXL, the blade does not boot. > > The compact flash is readable and a 'dir' shows the image, but booting > on it crashes after a while (there is just the ATA line displayed), and > about 30 seconds after, it's returning to rommon with a weird message > (that i can possibly report here if needed). > > Is there a known trick to 'convert' the blade from cat6k to 76xx ? You need at least 12.2(18)SXE for the 7604 chassis. What software version is on the card now? If it's the software, you can insert a flash card with the newer software and boot from that. Regards, Peter From MatlockK at exempla.org Thu Sep 4 12:39:22 2008 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Thu, 4 Sep 2008 10:39:22 -0600 Subject: [c-nsp] Odd MGCP issue with Caller-id Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7037AF7E4@LMC-MAIL2.exempla.org> We have a Call Manager 4.1 setup, and are using a few 2851's with FXS cards (VIC-4FXS/DID=) as gateways using MGCP for Fax lines. Everything is (and has) been working fine, but we have been tracing down a problem where *some* destinations could not call these extensions (there wasn't a rhyme or reason we could see at first). What we finally found, was that is was based off the length of the *calling* name. If it was 15 characters or less in call manager, it would work, but 16+ would not (they'd get a reorder tone). The relevant debug logs are as follows: Sep 4 09:46:38 MDT: //-1/7EF7044C8022/MGCP|aaln/S0/SU2/0|-1|-1//gen_caller_id(9324):[ lvl=1]mode == VALIDATE cid =<09/04/09/46,24671,Ken Matlock Test Test Test> Sep 4 09:46:38 MDT: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_cid_str(5889):[lvl=2]time=<09/04/09/46 > num=<24671> name= Sep 4 09:46:38 MDT: //-1/7EF7044C8022/MGCP|aaln/S0/SU2/0|-1|-1//gen_caller_id(9337):[ lvl=0]-- Country code = US Sep 4 09:46:38 MDT: //-1/7EF7044C8022/MGCP|aaln/S0/SU2/0|-1|-1//gen_caller_id(9362):[ lvl=1]-- Caller Id type = 1 Sep 4 09:46:38 MDT: //-1/7EF7044C8022/MGCP|aaln/S0/SU2/0|-1|-1//gen_caller_id(9424):[ lvl=0]-- returns code = 54 Sep 4 09:46:38 MDT: //-1/7EF7044C8022/MGCP|aaln/S0/SU2/0|-1|-1//process_start_signal( 4062):[lvl=2]process_start_signal(): FAIL with rc: 54, need to reject the whole list And Sep 4 09:46:38 MDT: MGCP Packet sent to 172.18.164.136:2427---> 510 100502 unsupported caller id length <--- I've done numerous searches on those errors, and checked the bug toolkit for both IOS version we've tried (12.4(20)T and 12.4(21) ) and no luck. Tried the 'caller-id block' on the port (but since it's not incoming on the FXS port I didn't think it'd help anyway). While we CAN go into Callmanager and shorten all the stations with 16+ character display names, I'd hate to have to go to that trouble if I can help it. Is there a way to increase that limit, or is that a hard-set in either the FXS cards, or MGCP? Ken Matlock Network Analyst (303) 467-4671 matlockk at exempla.org From greg at ip-man.net Thu Sep 4 12:39:43 2008 From: greg at ip-man.net (Gregoire Huet) Date: Thu, 04 Sep 2008 18:39:43 +0200 Subject: [c-nsp] Moving Sup720 from cat6k to 7600 In-Reply-To: References: <48BFFC15.2020200@ip-man.net> Message-ID: <48C00F4F.2040505@ip-man.net> Church, Charles wrote : > Is it possible you're trying to boot an IOS version that doesn't support > that chassis? I'm sure there is a minimum version for a 7604, and I'm > sure it's more recent than the minimum for the 6500 it came out of. I'm trying to boot c7600s72033-advipservicesk9-mz.122-33.SRC1.bin By the way, i have the trace of the booting process : rommon 7 > reset System Bootstrap, Version 8.5(2) Copyright (c) 1994-2007 by cisco Systems, Inc. Cat6k-Sup720/SP processor with 1048576 Kbytes of main memory rommon 1 > boot disk0: Initializing ATA monitor library... string is disk0:c7600s72033-advipservicesk9-mz.122-33.SRC1.bin Loading image, please wait ... Initializing ATA monitor library... *** Illegal Opcode Exception *** PC = 0x80102ae4, Cause = 0x28, Status Reg = 0x30409003 monitor: command "boot" aborted due to exception rommon 2 > Thank you Greg From jp at saucer.midcoast.com Thu Sep 4 12:00:37 2008 From: jp at saucer.midcoast.com (jp) Date: Thu, 4 Sep 2008 12:00:37 -0400 Subject: [c-nsp] Surge protection on leased lines In-Reply-To: References: <48B2D0FF.9090809@west.net> Message-ID: <20080904160037.GA21273@saucer.midcoast.com> Usually our Telco has gas/carbon arrestors at the NID and they differ for pots or T1 as T1 is higher voltage. Make sure your nid, smartbox, router are all grounded together and to the electrical system ground. I suspect they are not if current is flowing in and damaging your wic. I know APC made some ptel series arrestors for T1/ISDN usage for protecting the twisted pairs when the rj45/48 interfaces are used. I have these and they are good. Too bad you don't have access to that. On Mon, Aug 25, 2008 at 06:05:07PM +0200, Brian Turnbow wrote: > Thanks for the response. > They are external csus but they are "telco property" and they don't want us to touch them. > We have asked several times that they install protection coming into the building but no go... > They install a remote powered integrated shdsl modem/csu in an all plastic housing and the only place we > Have been able to connect a ground is to the v.35 mount on the integrated csu. No help there. > Lighting strike= burned modem/csu= burned wic > The v.35 protector would be a try to at least save our wic cards and costs of dispatching a Tech > for every passing storm. > > > Brian > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jay Hennigan > Sent: luned? 25 agosto 2008 17.34 > To: Cisco Mailing list > Subject: Re: [c-nsp] Surge protection on leased lines > > Brian Turnbow wrote: > > Hello, > > > > We have several customers that our having problems every time a storm > > goes through. > > Our national telco company seems to offer no lightning protection on > > their lines, and every storm causes a line outage and burns up the > > attached wic. > > We've made sure the chassis are grounded , but would also like to try > > and install a surge protection detween the v.35 interface of the telco > > and our CPEs. > > I see that Cisco offers a surge protection cable for smart serial > > interfaces, but not for classic serial interfaces. > > I wanted ask what others would recommend / experiences regarding surge > > protection on leased lines. > > This is an external CSU? > > I think you want it between the telco smartjack and the CSU, not on the > v.35. This should be two pairs of wires. > > First thing to do is ensure that the telco smartjack, the CSU, and the > router are solidly connected to a common ground, as this may be the > source of the problem if the sneak current is not coming across the > leased line. > > There are a number of companies making lightning protectors for twisted > pair lines, Reliable Electric and Polyphaser are two. > > But, triple-check the grounding first because if it's common-mode across > a ground differential the protectors won't help. > > -- > 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/ > _______________________________________________ > 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 blahu77 at gmail.com Thu Sep 4 13:00:01 2008 From: blahu77 at gmail.com (=?ISO-8859-2?Q?Mateusz_B=B3aszczyk?=) Date: Thu, 4 Sep 2008 18:00:01 +0100 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU Message-ID: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 List, One of our Edge Routers (NPE-G1,12.2(28)SB6 ) (1 Transit, 100+ peerings) is running on constant ~60% utilization. When BGP scanner kicks in, it peaks up at 80%. The box routes around - input rate 429,009,000 bits/sec, 64,257 packets/sec - output rate 276,711,000 bits/sec, 61,002 packets/sec ======================================================= edge#sh proc cpu sorted CPU utilization for five seconds: 59%/59%; one minute: 62%; five minutes: 61% <---------!!! PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 25 2644284001898122167 139 0.15% 0.38% 0.31% 0 ARP Input 62 2232065721093370453 204 0.15% 0.15% 0.15% 0 IP Input 35 66326072 13016133 5095 0.07% 0.11% 0.08% 0 Net Background 181 470863980 365252356 1289 0.07% 0.10% 0.09% 0 BGP Router 5 227768 783058 290 0.00% 0.00% 0.00% 0 Pool Manager ======================================================= Most of it is on the Interrupts... I was checking the cef switching which led me to the ACL on the port.... ======================================================= edge#sh ip cef switching statistics Path Reason Drop Punt Punt2Host RP LES Packet destined for us 0 140529659 0 RP LES Unresolved route 10984 0 0 RP LES Features 92 0 0 RP LES Total 11076 140529659 0 RP PAS No route 92517 0 73 RP PAS Packet destined for us 0 140529751 0 RP PAS No adjacency 431407 0 356877 RP PAS Incomplete adjacency 61069 0 479 RP PAS Unresolved route 9035960 0 0 RP PAS Bad checksum 118268 0 0 RP PAS TTL expired 0 0 407737419 RP PAS IP options set 0 0 221250 RP PAS Bad IP packet length 288 0 0 RP PAS Routed to Null0 782828 0 188 RP PAS Features 107260019 0 47245292 <--------------!!!! RP PAS Total 117782356 140529751 455561578 All Total 117793432 281059410 455561578 edge#sh ip cef switching statistics feature IPv4 CEF input features: Path Feature Drop Consume Punt Punt2Host Gave route RP LES CAR 92 0 0 0 0 RP PAS Access List 91374396 0 0 47245296 0 <--------------!!!! RP PAS CAR 15885623 0 0 0 0 Total 107260111 0 0 47245296 0 IPv4 CEF output features: Path Feature Drop Consume Punt Punt2Host New i/f Total 0 0 0 0 0 IPv4 CEF post-encap features: Path Feature Drop Consume Punt Punt2Host New i/f Total 0 0 0 0 0 ======================================================= I see that a lot of Punted packets go to CPU "because of" the ACL... On the port I have inbound ACL to protect the infrastructure and filter off rogue, bogus packets... For most of the entries it is quite generic - i.e. deny ip src dst, but for some lines explicitly lists tcp and udp ports. My question is - does this (tcp, udp ports) could force the router to execute the ACL in CPU? Or is it something else? Thanks in advance for any pointers PS. Sorry if that topic was munched many times and I just add to the chaos... Best Regards, - -- - -mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIwBQPIvBv0k5esR4RAonNAKCMZc/rEiZpznuueMRoKvx3xyI6VQCgvElQ PXCtW6qsU5nQxk4tc6cHet4= =ldkL -----END PGP SIGNATURE----- From mathias.spoerr at at.ibm.com Thu Sep 4 09:43:46 2008 From: mathias.spoerr at at.ibm.com (Mathias Spoerr) Date: Thu, 4 Sep 2008 15:43:46 +0200 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <20080904112344.GA2758@whitechalk.dfinet.ch> References: <20080904112344.GA2758@whitechalk.dfinet.ch> Message-ID: maybe the ASR 100x router is more suitable for you. Mathias From: Philippe Strauss To: Cisco NSP Date: 04.09.2008 14:48 Subject: [c-nsp] c7604 "starter kit" Hello c-nsp, For a small ISP who need to get a routing gear much more resistant do DDoS than 7200 NPE-G1/2 (with a bit over 400kpps on a POS OC3 on a G2, the router is at 100% CPU, probably better on ethernet but...), what is the entry level 7600? I'm new to the convoluted world of hardware routing :-) chassis 7604? 3bxl or 3cxl? sup720 or rsp720? linecard: what are the SPA? distributed forwarding? we don't need it a priori. there is a 6 gbic port (2+4) with PXF, what is this beast? probably something to avoid. I've heard once upon a time a 8 port GigE linecard was available and not anymore. will the 8 port fixed GigE (not 10/100 but only 1000) of the cat6500 line work in a c7600? We don't need 20 ports and that's a bit expensive. All port must do layer3, of course. Full BGP table, many times (3 full peer plus 100 local peerings w few prefixes). TIA! -- Philippe Strauss http://philou.ch _______________________________________________ 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7943 bytes Desc: S/MIME Cryptographic Signature URL: From rubensk at gmail.com Thu Sep 4 13:01:53 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Thu, 4 Sep 2008 14:01:53 -0300 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <20080904132355.GA17595@mx.ytti.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <20080904132355.GA17595@mx.ytti.net> Message-ID: <6bb5f5b10809041001q317d4694o8b57be06fcfd54da@mail.gmail.com> > You might also look at ASR1k as next-gen PE to replace VXR. 7600 has > limitation in hardware, especially in terms of IPv6 (no IPv6 uRPF, lookup > key size has compromises in ACL usage and others). When you compare > 7600 with SIP/SPA, ASR1k is even cheaper solution and much more flexible. > One thing to notice is that ASR1k does not currently have EoMPLS support > in any software, but other than that, all generally used features > are supported. > If I'd need non-ethernet interfaces, vlan local signifance or HQoS and > I wouldn't need EoMPLS, I'd definitely go with ASR1k rather than 7600. Can an ASR1k handle 3 full-routing transit feeds and a hundred peers ? Would it require ESP5 or ESP10 ? On the MPLS side, beside EoMPLS, can it do MPLS L3 VPN and MPLS-TE ? Rubens From saku+cisco-nsp at ytti.fi Thu Sep 4 13:09:28 2008 From: saku+cisco-nsp at ytti.fi (Saku Ytti) Date: Thu, 4 Sep 2008 20:09:28 +0300 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <6bb5f5b10809041001q317d4694o8b57be06fcfd54da@mail.gmail.com> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <20080904132355.GA17595@mx.ytti.net> <6bb5f5b10809041001q317d4694o8b57be06fcfd54da@mail.gmail.com> Message-ID: <20080904170928.GA23309@mx.ytti.net> On (2008-09-04 14:01 -0300), Rubens Kuhl Jr. wrote: > Can an ASR1k handle 3 full-routing transit feeds and a hundred peers ? Yes. > Would it require ESP5 or ESP10 ? Shouldn't make difference other than capacity wise. > On the MPLS side, beside EoMPLS, can it do MPLS L3 VPN and MPLS-TE ? L3 VPN yes, TE no sure. -- ++ytti From kratzers at pa.net Thu Sep 4 14:56:01 2008 From: kratzers at pa.net (Stephen Kratzer) Date: Thu, 4 Sep 2008 14:56:01 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> Message-ID: <200809041456.01591.kratzers@pa.net> On Thursday 04 September 2008 13:00:01 Mateusz B?aszczyk wrote: > My question is - does this (tcp, udp ports) could force the router to > execute the ACL in CPU? > Or is it something else? The 'log' keyword will cause matching packets to not be CEF switched. Also, if you're denying a lot of traffic from a certain source, you might want to just bit-bucket it rather than sending ICMP responses. Stephen Kratzer Network Engineer CTI Networks, Inc. From blahu77 at gmail.com Thu Sep 4 15:12:12 2008 From: blahu77 at gmail.com (=?ISO-8859-2?Q?Mateusz_B=B3aszczyk?=) Date: Thu, 4 Sep 2008 20:12:12 +0100 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <200809041456.01591.kratzers@pa.net> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> Message-ID: <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 2008/9/4 Stephen Kratzer : -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIwDMLIvBv0k5esR4RAlzjAJwLMhczm7XSVWQ3KVO3t3EbcRbAFwCfWMis iiGQ+roqhyVjEmFP54MN8ik= =910N -----END PGP SIGNATURE----- > The 'log' keyword will cause matching packets to not be CEF switched. nope, log is not present. > Also, if > you're denying a lot of traffic from a certain source, you might want to just > bit-bucket it rather than sending ICMP responses. you mean - "no ip unreachables"? -- -mat From petelists at templin.org Thu Sep 4 15:44:09 2008 From: petelists at templin.org (Pete Templin) Date: Thu, 04 Sep 2008 14:44:09 -0500 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <1220545759.13061.9.camel@abehat> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <48BFE34C.30106@memetic.org> <1220545759.13061.9.camel@abehat> Message-ID: <48C03A89.2080706@templin.org> Peter Rathlev wrote: > On Thu, 2008-09-04 at 14:31 +0100, Adam Armstrong wrote: >> On Thu, 2008-09-04 at 13:23 +0200, Philippe Strauss wrote: >>> I've heard once upon a time a 8 port GigE linecard was available and >>> not anymore. will the 8 port fixed GigE (not 10/100 but only 1000) of >>> the cat6500 line work in a c7600? > C7600/SRC supports the WS-X6708-10G-3C{,XL}. The 16 port WS-X6716-10G-3C > is 6500 only though. He said 8GE, not 8XE. pt From kratzers at pa.net Thu Sep 4 15:46:23 2008 From: kratzers at pa.net (Stephen Kratzer) Date: Thu, 4 Sep 2008 15:46:23 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> Message-ID: <200809041546.23959.kratzers@pa.net> On Thursday 04 September 2008 15:12:12 Mateusz B?aszczyk wrote: > 2008/9/4 Stephen Kratzer : > > The 'log' keyword will cause matching packets to not be CEF switched. > > nope, log is not present. > > > Also, if > > you're denying a lot of traffic from a certain source, you might want to > > just bit-bucket it rather than sending ICMP responses. > > you mean - "no ip unreachables"? You could match the access list in a route map and set the outbound interface to Null0. From peter at rathlev.dk Thu Sep 4 15:56:45 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Thu, 04 Sep 2008 21:56:45 +0200 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <48C03A89.2080706@templin.org> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <48BFE34C.30106@memetic.org> <1220545759.13061.9.camel@abehat> <48C03A89.2080706@templin.org> Message-ID: <1220558205.7247.4.camel@abehat> On Thu, 2008-09-04 at 14:44 -0500, Pete Templin wrote: > Peter Rathlev wrote: > > On Thu, 2008-09-04 at 14:31 +0100, Adam Armstrong wrote: > >> On Thu, 2008-09-04 at 13:23 +0200, Philippe Strauss wrote: > >>> I've heard once upon a time a 8 port GigE linecard was available and > >>> not anymore. will the 8 port fixed GigE (not 10/100 but only 1000) of > >>> the cat6500 line work in a c7600? > > > C7600/SRC supports the WS-X6708-10G-3C{,XL}. The 16 port WS-X6716-10G-3C > > is 6500 only though. > > He said 8GE, not 8XE. Yes, OP did, but my comment was a response to Adam's mail, mentioning "There are some cards which won't, such as the the 8 port 10GE card.". I don't know the 8 GE card, maybe I should've been more clear in my mail. Regards, Peter From Anton.Schweitzer at o2.com Thu Sep 4 16:03:18 2008 From: Anton.Schweitzer at o2.com (Anton.Schweitzer at o2.com) Date: Thu, 4 Sep 2008 22:03:18 +0200 Subject: [c-nsp] =?iso-8859-1?q?Anton_Schweitzer_ist_au=DFer_Haus=2E?= Message-ID: Ich werde ab 12.08.2008 nicht im B?ro sein. Ich kehre zur?ck am 13.10.2008. Bitte wenden Sie sich an meinen Vorgesetzten Florian Schwarz From acidutu at hotmail.com Thu Sep 4 16:04:23 2008 From: acidutu at hotmail.com (hawk98 TheHawk) Date: Thu, 4 Sep 2008 20:04:23 +0000 Subject: [c-nsp] (no subject) Message-ID: Hello All, We?re noticing a large number of input errors on multiple GigE interfaces on various C720X NPE-G1 routers. These input errors match exactly with the number of overruns on those interfaces. There are a couple strange things that we?ve noticed: 1. this problem happens on more than 1 router (similar configuration on all routers) 2. all routers affected began exhibiting these errors roughly around the same time (same early morning) 3. All routers are G1 and ran the same IOS code 4. One of the routers was rebooted and upgraded to a different code however the problem still persists 5. we suspect it directly affects the functionality of the router as we see random lockups of the units 6. All routers are connected to redundant switches and cabling/switches have been ruled out. Below is a sample output of the show interface on one of the routers: GigabitEthernet0/1 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 00b0.c2ee.b81b (bia 00b0.c2ee.b81b) Description: XXXXXXXX MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 2/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of 'show interface' counters never Input queue: 1/75/499528/97 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 8539000 bits/sec, 10996 packets/sec 5 minute output rate 1905000 bits/sec, 807 packets/sec 139728650 packets input, 10628478461 bytes, 92 no buffer Received 487174 broadcasts, 0 runts, 0 giants, 0 throttles 171399 input errors, 0 CRC, 0 frame, 171399 overrun, 0 ignored 0 watchdog, 1904930 multicast, 0 pause input 0 input packets with dribble condition detected 8125773 packets output, 2521690484 bytes, 0 underruns 2 output errors, 0 collisions, 1 interface resets 3842 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 2 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out Does anyone have any idea what might be going on? I initially suspected an IOS bug (since all devices were affected) however after the upgrade the problem still persists. Any help is appreciated. Adrian _________________________________________________________________ From cchurc05 at harris.com Thu Sep 4 16:12:58 2008 From: cchurc05 at harris.com (Church, Charles) Date: Thu, 4 Sep 2008 15:12:58 -0500 Subject: [c-nsp] Moving Sup720 from cat6k to 7600 In-Reply-To: <48C00F4F.2040505@ip-man.net> References: <48BFFC15.2020200@ip-man.net> <48C00F4F.2040505@ip-man.net> Message-ID: I would think that should support an 7604 chassis. Any chance the IOS is corrupt on the flash? Or the Monlib isn't right. Can you put the card in a working 6500 and verify the IOS image (MD5) and verify via 'show disk0 all' that the monlib stuff is right? Chuck -----Original Message----- From: Gregoire Huet [mailto:greg at ip-man.net] Sent: Thursday, September 04, 2008 12:40 PM To: Church, Charles Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Moving Sup720 from cat6k to 7600 Church, Charles wrote : > Is it possible you're trying to boot an IOS version that doesn't support > that chassis? I'm sure there is a minimum version for a 7604, and I'm > sure it's more recent than the minimum for the 6500 it came out of. I'm trying to boot c7600s72033-advipservicesk9-mz.122-33.SRC1.bin By the way, i have the trace of the booting process : rommon 7 > reset System Bootstrap, Version 8.5(2) Copyright (c) 1994-2007 by cisco Systems, Inc. Cat6k-Sup720/SP processor with 1048576 Kbytes of main memory rommon 1 > boot disk0: Initializing ATA monitor library... string is disk0:c7600s72033-advipservicesk9-mz.122-33.SRC1.bin Loading image, please wait ... Initializing ATA monitor library... *** Illegal Opcode Exception *** PC = 0x80102ae4, Cause = 0x28, Status Reg = 0x30409003 monitor: command "boot" aborted due to exception rommon 2 > Thank you Greg From gm at wavegard.com Thu Sep 4 16:49:49 2008 From: gm at wavegard.com (Grant Moerschel) Date: Thu, 4 Sep 2008 15:49:49 -0500 Subject: [c-nsp] VoIP classifying and queuing in an access switch <--> core Layer 2 network Message-ID: <71BC8F601C01554CA7410616B26C50D1016703CD@mail-37ps.atlarge.net> In an access switch to core where the connections are Layer 2, what is the best method to a) classify voip traffic as it enters the access switch and b) prioritize it via some queuing mechanism as it traverses the trunk going to the core? Does anyone have sample configs for something like this? Pc <-> phone <-> access switch <-> core switch. Priority to VoIP traffic on trunks. Thanks ~~~~ Grant P. Moerschel gm -at- wavegard -dot- com ~~~~ From jdevane at nevadanap.com Thu Sep 4 17:36:46 2008 From: jdevane at nevadanap.com (Jim Devane) Date: Thu, 4 Sep 2008 14:36:46 -0700 Subject: [c-nsp] vtp domain mindef Message-ID: <10188D798B596E4585DEAEAC62596D2309D57FDA@WATERFORD.switchnet.nv> Hello, We observed something interesting. A 6509, IOS, 720-3BXL, 12.2-18 SXF suddenly dumped its vlan.dat. It sounds like a classic case of inserting a switch with a higher VTP rev confg but that was not the case. No network changes either physical or virtual took place (syslog and ACS confirmed) The interesting part. The switch had no VTP domain previously defined. Somewhat magically, vtp domain mindef appeared in the config. This was never configured by a user also syslog and ACS confirmed. Has anyone heard of mindef as a default of some sort for VTP domains? Anyone heard of something like this happening? thanks, jim From j0nneblaze at gmail.com Thu Sep 4 19:06:56 2008 From: j0nneblaze at gmail.com (Matt Schlotman) Date: Thu, 4 Sep 2008 16:06:56 -0700 Subject: [c-nsp] IOS 12.2(18)SXF14 In-Reply-To: References: Message-ID: On Thu, Sep 4, 2008 at 1:30 PM, Matt Schlotman wrote: > I have a Cisco 6509 with a WS-SUP720-3BXL that came with 12.2(18)SXF14 as > the version of IOS. Can anyone recommend if I should continue to run this > version or if I should go with an older, tested version such as SXF11? > From achatz at forthnet.gr Thu Sep 4 19:11:02 2008 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Fri, 05 Sep 2008 02:11:02 +0300 Subject: [c-nsp] vtp domain mindef In-Reply-To: <10188D798B596E4585DEAEAC62596D2309D57FDA@WATERFORD.switchnet.nv> References: <10188D798B596E4585DEAEAC62596D2309D57FDA@WATERFORD.switchnet.nv> Message-ID: <48C06B06.40204@forthnet.gr> I don't know what mindef is, but a switch with a null vtp domain (which is the default) will get the vtp domain of another switch (server or client) through any trunk link. -- Tassos Jim Devane wrote on 05/09/2008 00:36: > Hello, > > We observed something interesting. A 6509, IOS, 720-3BXL, 12.2-18 SXF suddenly dumped its vlan.dat. It sounds like a classic case of inserting a switch with a higher VTP rev confg but that was not the case. No network changes either physical or virtual took place (syslog and ACS confirmed) > The interesting part. The switch had no VTP domain previously defined. Somewhat magically, vtp domain mindef appeared in the config. This was never configured by a user also syslog and ACS confirmed. > > Has anyone heard of mindef as a default of some sort for VTP domains? Anyone heard of something like this happening? > > > thanks, > jim > _______________________________________________ > 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 overkillxx at gmail.com Thu Sep 4 19:52:05 2008 From: overkillxx at gmail.com (Brett Clausenhauf) Date: Fri, 5 Sep 2008 09:52:05 +1000 Subject: [c-nsp] CSS strange behaviour.... Or is it just my config [7:132492] In-Reply-To: <20080904080208.GA17238@greenie.muc.de> References: <200809040227.m842RBGe015086@groupstudy.com> <20080904062227.GP233@greenie.muc.de> <20080904080208.GA17238@greenie.muc.de> Message-ID: Hi Gert, I've since tried other ports (Port 23 for example) & it still does the same thing. This has got me stumped... I cannot figure out why it needs the group command to stay working. On Thu, Sep 4, 2008 at 6:02 PM, Gert Doering wrote: > Hi, > > On Thu, Sep 04, 2008 at 05:49:31PM +1000, Brett Clausenhauf wrote: > > Undortunately this is doubtful. The web server is literally just > configured > > & is not logging.Regards, > > By default, most webservers *do* log... > > As I said, this was just a stab in the dark - run tcpdump (or wireshark) > on the server to see what sort of outgoing connections it does. > > 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 danletkeman at gmail.com Thu Sep 4 20:07:57 2008 From: danletkeman at gmail.com (Dan Letkeman) Date: Thu, 4 Sep 2008 19:07:57 -0500 Subject: [c-nsp] Recommended 2800 ISR Message-ID: I was wondering if anyone has recommendations for a 2800 series router for a 20-30mbit internet connection. I would like to run a firewall IOS and, nat and basic ACL's. Would a 2811 be an appropriate choice? Thanks, Dan. From streiner at cluebyfour.org Thu Sep 4 20:39:06 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 4 Sep 2008 20:39:06 -0400 (EDT) Subject: [c-nsp] Recommended 2800 ISR In-Reply-To: References: Message-ID: On Thu, 4 Sep 2008, Dan Letkeman wrote: > I was wondering if anyone has recommendations for a 2800 series router > for a 20-30mbit internet connection. I would like to run a firewall > IOS and, nat and basic ACL's. Would a 2811 be an appropriate choice? If you're not running BGP with full feeds, you *might* be able to get away with a 2811, given that you're running IOS firewall and NAT as well, but you probably wouldn't have much headroom for growth, or if you decide you need additional features in the future (Netflow, QoS, routing protocols, etc). jms From ben.steele at internode.on.net Thu Sep 4 20:41:11 2008 From: ben.steele at internode.on.net (Ben Steele) Date: Fri, 5 Sep 2008 10:11:11 +0930 Subject: [c-nsp] Recommended 2800 ISR In-Reply-To: References: Message-ID: <00ab01c90ef0$18983d20$49c8b760$@steele@internode.on.net> If you don't plan on expanding that 20-30Mbit too much in the future even 2801 will handle that fairly comfortably, the main killer in your list is the IOS firewall, the rest would have been cef switched, i've done between 20-30Mbit on a 2801 with all the below running with no issues before, 2811 would definitely handle it ok. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dan Letkeman Sent: Friday, 5 September 2008 9:38 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Recommended 2800 ISR I was wondering if anyone has recommendations for a 2800 series router for a 20-30mbit internet connection. I would like to run a firewall IOS and, nat and basic ACL's. Would a 2811 be an appropriate choice? Thanks, Dan. _______________________________________________ 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 giulianocm at uol.com.br Thu Sep 4 20:43:05 2008 From: giulianocm at uol.com.br (GIULIANO (UOL)) Date: Thu, 04 Sep 2008 21:43:05 -0300 Subject: [c-nsp] Recommended 2800 ISR In-Reply-To: References: Message-ID: <48C08099.6060908@uol.com.br> Dan, Yes. It is a good choice. Take a look: http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf Its an initial guide for router performance. Att, Giuliano > I was wondering if anyone has recommendations for a 2800 series router > for a 20-30mbit internet connection. I would like to run a firewall > IOS and, nat and basic ACL's. Would a 2811 be an appropriate choice? > > Thanks, > Dan. > _______________________________________________ > 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 - http://www.avg.com > Version: 8.0.169 / Virus Database: 270.6.16/1652 - Release Date: 04/09/2008 18:54 > From ariemer at wesenergy.com.au Thu Sep 4 21:00:24 2008 From: ariemer at wesenergy.com.au (Aaron Riemer) Date: Fri, 5 Sep 2008 09:00:24 +0800 Subject: [c-nsp] Dashboard Network Monitoring Software Message-ID: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> Hi Guys, Is anyone out there using any open source or free dashboard network monitoring software? I would like to have a map background with our sites and possibly blink the sites RED if the site stopped responding to pings or SNMP queries etc? I know Solarwinds and HP Openview are good but we are not willing to shell out the money just for a dashboard. Cheers, Aaron. LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From acidutu at hotmail.com Thu Sep 4 21:11:41 2008 From: acidutu at hotmail.com (The Hawk) Date: Fri, 5 Sep 2008 01:11:41 +0000 Subject: [c-nsp] C720X NPE-G1 - interface errors + router freezes Message-ID: Forgot to add a subject line last time...Sorry for the double post...some additional info has also been added inline. Hello All, We?re noticing a large number of input errors on multiple GigE interfaces on various C720X NPE-G1 routers. These input errors match exactly with the number of overruns on those interfaces. I wouldn't be so concerned about the errors if other strange things were not happening on the routers. (such as frequent lockups and frequent eigrp drops). At this point they go hand in hand however we need to pinpoint the origin of the problems and it hasn't been easy. These are a couple strange things that we?ve noticed: 1. this problem happens on more than 1 router (similar configuration on all routers) 2. all routers affected began exhibiting these errors roughly around the same time (same early morning) 3. All routers are G1 and ran the same IOS code (12.4.12) 4. One of the routers was rebooted and upgraded to a different code however the problem still persists (12.4.21) 5. we suspect it directly affects the functionality of the router as we see random lockups of the units (which may be the cause of the increased errors not the result of) 6. All routers are connected to redundant switches and cabling/switches have been ruled out. Below is a sample output of the show interface on one of the routers: GigabitEthernet0/1 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 00b0.c2ee.b81b (bia 00b0.c2ee.b81b) Description: XXXXXXXX MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 2/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of 'show interface' counters never Input queue: 1/75/499528/97 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 8539000 bits/sec, 10996 packets/sec 5 minute output rate 1905000 bits/sec, 807 packets/sec 139728650 packets input, 10628478461 bytes, 92 no buffer Received 487174 broadcasts, 0 runts, 0 giants, 0 throttles 171399 input errors, 0 CRC, 0 frame, 171399 overrun, 0 ignored 0 watchdog, 1904930 multicast, 0 pause input 0 input packets with dribble condition detected 8125773 packets output, 2521690484 bytes, 0 underruns 2 output errors, 0 collisions, 1 interface resets 3842 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 2 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out Does anyone have any idea what might be going on? I initially suspected an IOS bug (since all devices were affected) however after the upgrade the problem still persists. Any help is appreciated. Adrian _________________________________________________________________ From zeusdadog at gmail.com Thu Sep 4 21:17:44 2008 From: zeusdadog at gmail.com (Jay Nakamura) Date: Thu, 4 Sep 2008 21:17:44 -0400 Subject: [c-nsp] Recommended 2800 ISR In-Reply-To: <48C08099.6060908@uol.com.br> References: <48C08099.6060908@uol.com.br> Message-ID: <9418aca70809041817j33a453adp45a8c5eb39d27a93@mail.gmail.com> What about going with an ASA? Much more performance for the money. But it depends on what all you want to do on the router. IOS is a lot more flexible on what you can do. On Thu, Sep 4, 2008 at 8:43 PM, GIULIANO (UOL) wrote: > > > http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf > Speaking of performance guide, does anyone know if there are any document like that one that is a little more up to date and include performance numbers for some of the switches that do L3 routing? I use that PDF all the time but wished it was updated more often. From rmg at conviva.com Thu Sep 4 21:47:22 2008 From: rmg at conviva.com (Robert Gutierrez) Date: Thu, 4 Sep 2008 18:47:22 -0700 (PDT) Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <20080904170928.GA23309@mx.ytti.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch><20080904132355.GA17595@mx.ytti.net><6bb5f5b10809041001q317d4694o8b57be06fcfd54da@mail.gmail.com> <20080904170928.GA23309@mx.ytti.net> Message-ID: <014301c90ef9$5a698480$500a10ac@ranma> I tried to sell management here a dual ASR1003 + distro (4900M based), but 10G distro is still just too much! TOR's still had to be 10G connected from the 4900M, and that's a hell of a lot of X2's to buy on top of that. Yeah, I could have bought the 20 port GE card for the 4900M for now, but Taiwan has the single-lane 10G switches coming next year, and I just don't feel that Cisco will drop prices then on X2's or SFP+'s to give me long-term confidence, pricing wise. I might as well do an ASR1003 + 4948-10G as the distro to 2960G's. Ugh, el-cheapo! So I did a pair of 7606's, 3CXL (taking full routes) and a 6748-GE-TX port-channeled to the TOR's. Cisco has 10G locked up for now, but that prices small shops like us out. And also makes sure we *will* go with 3rd party next year, locking out Cisco except for the core. I mean it's not like when I worked at MSN and had zillions to spend on even small lab networks. I have a real budget now. And Cisco is a very hard pill to swallow on a real budget. At least I didn't suggest Vyatta/Quagga on a Dell server feeding Dell switches :P Rob Gutierrez / Sr. Network Engineer Conviva Inc, San Mateo, CA -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Saku Ytti Sent: Thursday, September 04, 2008 10:09 AM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] c7604 "starter kit" On (2008-09-04 14:01 -0300), Rubens Kuhl Jr. wrote: > Can an ASR1k handle 3 full-routing transit feeds and a hundred peers ? Yes. > Would it require ESP5 or ESP10 ? Shouldn't make difference other than capacity wise. > On the MPLS side, beside EoMPLS, can it do MPLS L3 VPN and MPLS-TE ? L3 VPN yes, TE no sure. -- ++ytti _______________________________________________ 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.geyer at eds.com Thu Sep 4 21:49:35 2008 From: nick.geyer at eds.com (Geyer, Nick) Date: Fri, 5 Sep 2008 11:49:35 +1000 Subject: [c-nsp] C720X NPE-G1 - interface errors + router freezes In-Reply-To: References: Message-ID: <83027F7A5EB4D6449A1393A94E4D41DA03C7E2A7@aubwm232.apac.corp.eds.com> I have seen issues like you mention creep up on NPE-G1's that have been in service for a while. It all starts with a few input errors here and there and progressively gets worse. Reseating the NPE seems to clear up all the issues and it starts chugging along happily again. Possibly worth a try on one of your routers to see if it makes a difference. Nick -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of The Hawk Sent: Friday, 5 September 2008 11:12 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] C720X NPE-G1 - interface errors + router freezes Forgot to add a subject line last time...Sorry for the double post...some additional info has also been added inline. Hello All, We're noticing a large number of input errors on multiple GigE interfaces on various C720X NPE-G1 routers. These input errors match exactly with the number of overruns on those interfaces. I wouldn't be so concerned about the errors if other strange things were not happening on the routers. (such as frequent lockups and frequent eigrp drops). At this point they go hand in hand however we need to pinpoint the origin of the problems and it hasn't been easy. These are a couple strange things that we've noticed: 1. this problem happens on more than 1 router (similar configuration on all routers) 2. all routers affected began exhibiting these errors roughly around the same time (same early morning) 3. All routers are G1 and ran the same IOS code (12.4.12) 4. One of the routers was rebooted and upgraded to a different code however the problem still persists (12.4.21) 5. we suspect it directly affects the functionality of the router as we see random lockups of the units (which may be the cause of the increased errors not the result of) 6. All routers are connected to redundant switches and cabling/switches have been ruled out. Below is a sample output of the show interface on one of the routers: GigabitEthernet0/1 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 00b0.c2ee.b81b (bia 00b0.c2ee.b81b) Description: XXXXXXXX MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 2/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of 'show interface' counters never Input queue: 1/75/499528/97 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 8539000 bits/sec, 10996 packets/sec 5 minute output rate 1905000 bits/sec, 807 packets/sec 139728650 packets input, 10628478461 bytes, 92 no buffer Received 487174 broadcasts, 0 runts, 0 giants, 0 throttles 171399 input errors, 0 CRC, 0 frame, 171399 overrun, 0 ignored 0 watchdog, 1904930 multicast, 0 pause input 0 input packets with dribble condition detected 8125773 packets output, 2521690484 bytes, 0 underruns 2 output errors, 0 collisions, 1 interface resets 3842 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 2 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out Does anyone have any idea what might be going on? I initially suspected an IOS bug (since all devices were affected) however after the upgrade the problem still persists. Any help is appreciated. Adrian _________________________________________________________________ _______________________________________________ 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 danletkeman at gmail.com Thu Sep 4 22:01:36 2008 From: danletkeman at gmail.com (Dan Letkeman) Date: Thu, 4 Sep 2008 21:01:36 -0500 Subject: [c-nsp] Recommended 2800 ISR In-Reply-To: <48C08099.6060908@uol.com.br> References: <48C08099.6060908@uol.com.br> Message-ID: I have read that document before, do those numbers (2811 - 61.44mpbs CEF Fast switching) mean that it can process that bandwidth with nothing else running on the router? On Thu, Sep 4, 2008 at 7:43 PM, GIULIANO (UOL) wrote: > Dan, > > Yes. It is a good choice. > > Take a look: > > http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf > > > Its an initial guide for router performance. > > Att, > > Giuliano > > >> I was wondering if anyone has recommendations for a 2800 series router >> for a 20-30mbit internet connection. I would like to run a firewall >> IOS and, nat and basic ACL's. Would a 2811 be an appropriate choice? >> >> Thanks, >> Dan. >> _______________________________________________ >> 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 - http://www.avg.com >> Version: 8.0.169 / Virus Database: 270.6.16/1652 - Release Date: 04/09/2008 18:54 >> > > From mtinka at globaltransit.net Thu Sep 4 22:03:27 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 5 Sep 2008 10:03:27 +0800 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <014301c90ef9$5a698480$500a10ac@ranma> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <20080904170928.GA23309@mx.ytti.net> <014301c90ef9$5a698480$500a10ac@ranma> Message-ID: <200809051003.32163.mtinka@globaltransit.net> On Friday 05 September 2008 09:47:22 Robert Gutierrez wrote: > I tried to sell management here a dual ASR1003... AFAIK, Cisco don't have a 3-slot model of the ASR1000. You probably meant the ASR1002 or ASR1004 :-). 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 acidutu at hotmail.com Thu Sep 4 22:06:16 2008 From: acidutu at hotmail.com (The Hawk) Date: Fri, 5 Sep 2008 02:06:16 +0000 Subject: [c-nsp] C720X NPE-G1 - interface errors + router freezes Message-ID: Hello Nick, Thanks for your suggestion. I will try this one of these nights although I strongly believe that it will not solve this particular issue. As I mentioned in the original post, we have multiple NPE-G1s that all started experiencing the same issue on the same day (early morning around 4:00AM).... I'm leaning towards some sort of attack that's happening on these routers to exploit a known vulnerability. I was really hoping that the IOS upgrade would have fixed that but no luck there. Based on interface reports these GIGe Interfaces are not pushing more than 10 - 40Mb of traffic through them ... if it is some sort of attack, it must be using small packets or once again, a known vulnerability is exploited. Adrian> Subject: RE: [c-nsp] C720X NPE-G1 - interface errors + router freezes> Date: Fri, 5 Sep 2008 11:49:35 +1000> From: nick.geyer at eds.com> To: acidutu at hotmail.com; cisco-nsp at puck.nether.net> > I have seen issues like you mention creep up on NPE-G1's that have been> in service for a while. It all starts with a few input errors here and> there and progressively gets worse.> > Reseating the NPE seems to clear up all the issues and it starts> chugging along happily again. Possibly worth a try on one of your> routers to see if it makes a difference.> > Nick> > -----Original Message-----> From: cisco-nsp-bounces at puck.nether.net> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of The Hawk> Sent: Friday, 5 September 2008 11:12 AM> To: cisco-nsp at puck.nether.net> Subject: [c-nsp] C720X NPE-G1 - interface errors + router freezes> > > > Forgot to add a subject line last time...Sorry for the double> post...some additional info has also been added inline.> > Hello All,> > We're noticing a large number of input errors on multiple GigE> interfaces on various C720X NPE-G1 routers. These input errors match> exactly with the number of overruns on those interfaces. I wouldn't be> so concerned about the errors if other strange things were not happening> on the routers. (such as frequent lockups and frequent eigrp drops). At> this point they go hand in hand however we need to pinpoint the origin> of the problems and it hasn't been easy.> > These are a couple strange things that we've noticed:> > 1. this problem happens on more than 1 router (similar> configuration on all routers)> 2. all routers affected began exhibiting these errors roughly> around the same time (same early morning)> 3. All routers are G1 and ran the same IOS code (12.4.12)> 4. One of the routers was rebooted and upgraded to a different> code however the problem still persists (12.4.21)> 5. we suspect it directly affects the functionality of the router> as we see random lockups of the units (which may be the cause of the> increased errors not the result of)> 6. All routers are connected to redundant switches and> cabling/switches have been ruled out.> > Below is a sample output of the show interface on one of the routers:> > GigabitEthernet0/1 is up, line protocol is up> Hardware is BCM1250 Internal MAC, address is 00b0.c2ee.b81b (bia> 00b0.c2ee.b81b)> Description: XXXXXXXX> MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,> reliability 255/255, txload 1/255, rxload 2/255> Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set> Keepalive set (10 sec)> Full-duplex, 1000Mb/s, media type is RJ45> output flow-control is XON, input flow-control is XON> ARP type: ARPA, ARP Timeout 04:00:00> Last input 00:00:00, output 00:00:00, output hang never> Last clearing of 'show interface' counters never> Input queue: 1/75/499528/97 (size/max/drops/flushes); Total output> drops: 0> Queueing strategy: fifo> Output queue: 0/40 (size/max)> 5 minute input rate 8539000 bits/sec, 10996 packets/sec> 5 minute output rate 1905000 bits/sec, 807 packets/sec> 139728650 packets input, 10628478461 bytes, 92 no buffer> Received 487174 broadcasts, 0 runts, 0 giants, 0 throttles> 171399 input errors, 0 CRC, 0 frame, 171399 overrun, 0 ignored> 0 watchdog, 1904930 multicast, 0 pause input> 0 input packets with dribble condition detected> 8125773 packets output, 2521690484 bytes, 0 underruns> 2 output errors, 0 collisions, 1 interface resets> 3842 unknown protocol drops> 0 babbles, 0 late collision, 0 deferred> 2 lost carrier, 0 no carrier, 0 pause output> 0 output buffer failures, 0 output buffers swapped out> > Does anyone have any idea what might be going on?> > I initially suspected an IOS bug (since all devices were affected)> however after the upgrade the problem still persists.> > Any help is appreciated.> Adrian> _________________________________________________________________> > _______________________________________________> 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 rmg at conviva.com Thu Sep 4 22:14:31 2008 From: rmg at conviva.com (Robert Gutierrez) Date: Thu, 4 Sep 2008 19:14:31 -0700 (PDT) Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <200809051003.32163.mtinka@globaltransit.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <20080904170928.GA23309@mx.ytti.net> <014301c90ef9$5a698480$500a10ac@ranma> <200809051003.32163.mtinka@globaltransit.net> Message-ID: <014f01c90efd$256d61d0$500a10ac@ranma> Oops. yeah, the ASR1002 :) Fingers ahead of the brain on the keyboard. But the rest applies ... Rob Gutierrez / Sr. Network Engineer Conviva Inc, San Mateo, CA. -----Original Message----- From: Mark Tinka [mailto:mtinka at globaltransit.net] Sent: Thursday, September 04, 2008 7:03 PM To: cisco-nsp at puck.nether.net Cc: Robert Gutierrez Subject: Re: [c-nsp] c7604 "starter kit" On Friday 05 September 2008 09:47:22 Robert Gutierrez wrote: > I tried to sell management here a dual ASR1003... AFAIK, Cisco don't have a 3-slot model of the ASR1000. You probably meant the ASR1002 or ASR1004 :-). Cheers, Mark. From mtinka at globaltransit.net Thu Sep 4 22:15:02 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 5 Sep 2008 10:15:02 +0800 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <20080904170928.GA23309@mx.ytti.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <6bb5f5b10809041001q317d4694o8b57be06fcfd54da@mail.gmail.com> <20080904170928.GA23309@mx.ytti.net> Message-ID: <200809051015.06641.mtinka@globaltransit.net> On Friday 05 September 2008 01:09:28 Saku Ytti wrote: > L3 VPN yes, TE no sure. According to FN, MPLS-TE is unsupported. Quite surprising, actually... 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 James.Baker at chelmer.co.nz Thu Sep 4 22:16:56 2008 From: James.Baker at chelmer.co.nz (James Baker) Date: Fri, 5 Sep 2008 14:16:56 +1200 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> Message-ID: <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> Nagios. Look at setting up the 2d Status map. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Riemer Sent: Friday, 5 September 2008 1:00 p.m. To: cisco-nsp at puck.nether.net Subject: [c-nsp] Dashboard Network Monitoring Software Hi Guys, Is anyone out there using any open source or free dashboard network monitoring software? I would like to have a map background with our sites and possibly blink the sites RED if the site stopped responding to pings or SNMP queries etc? I know Solarwinds and HP Openview are good but we are not willing to shell out the money just for a dashboard. Cheers, Aaron. LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ 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/ ---------- The information contained in this e-mail and any attachments is confidential and is intended for the attention and use of the named addressee(s) only. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Chelmer Limited. ##################################################################################### This e-mail message has been scanned for Viruses and Content and cleared by NetIQ MailMarshal ##################################################################################### From ariemer at wesenergy.com.au Thu Sep 4 22:33:27 2008 From: ariemer at wesenergy.com.au (Aaron Riemer) Date: Fri, 5 Sep 2008 10:33:27 +0800 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> Message-ID: <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> Hi James, Yes I thought about nagios. Is it possible to put your own background map in and then position nodes on the map? Thanks for the suggestion. Cheers, Aaron. -----Original Message----- From: James Baker [mailto:James.Baker at chelmer.co.nz] Sent: Friday, 5 September 2008 10:17 AM To: Aaron Riemer; cisco-nsp at puck.nether.net Subject: RE: [c-nsp] Dashboard Network Monitoring Software Nagios. Look at setting up the 2d Status map. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Riemer Sent: Friday, 5 September 2008 1:00 p.m. To: cisco-nsp at puck.nether.net Subject: [c-nsp] Dashboard Network Monitoring Software Hi Guys, Is anyone out there using any open source or free dashboard network monitoring software? I would like to have a map background with our sites and possibly blink the sites RED if the site stopped responding to pings or SNMP queries etc? I know Solarwinds and HP Openview are good but we are not willing to shell out the money just for a dashboard. Cheers, Aaron. LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ 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/ ---------- The information contained in this e-mail and any attachments is confidential and is intended for the attention and use of the named addressee(s) only. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Chelmer Limited. ######################################################################## ############# This e-mail message has been scanned for Viruses and Content and cleared by NetIQ MailMarshal ######################################################################## ############# LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From dhooper at emerge.net.au Thu Sep 4 22:55:26 2008 From: dhooper at emerge.net.au (Daniel Hooper) Date: Fri, 5 Sep 2008 10:55:26 +0800 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> Message-ID: www.nagios.org -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Riemer Sent: Friday, 5 September 2008 9:00 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Dashboard Network Monitoring Software Hi Guys, Is anyone out there using any open source or free dashboard network monitoring software? I would like to have a map background with our sites and possibly blink the sites RED if the site stopped responding to pings or SNMP queries etc? I know Solarwinds and HP Openview are good but we are not willing to shell out the money just for a dashboard. Cheers, Aaron. LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ 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 ben.steele at internode.on.net Thu Sep 4 23:02:35 2008 From: ben.steele at internode.on.net (Ben Steele) Date: Fri, 5 Sep 2008 12:32:35 +0930 Subject: [c-nsp] Recommended 2800 ISR In-Reply-To: References: <48C08099.6060908@uol.com.br> Message-ID: <00ac01c90f03$d9afdeb0$8d0f9c10$@steele@internode.on.net> Those figures aren't a real world typical example, they are based on small(64byte) packet sizes x pps the router can do, if you increase the byte size to above 1000 you can see those numbers quickly explode to a more realistic figure. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dan Letkeman Sent: Friday, 5 September 2008 11:32 AM To: giulianocm at uol.com.br; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Recommended 2800 ISR I have read that document before, do those numbers (2811 - 61.44mpbs CEF Fast switching) mean that it can process that bandwidth with nothing else running on the router? On Thu, Sep 4, 2008 at 7:43 PM, GIULIANO (UOL) wrote: > Dan, > > Yes. It is a good choice. > > Take a look: > > http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerp erformance.pdf > > > Its an initial guide for router performance. > > Att, > > Giuliano > > >> I was wondering if anyone has recommendations for a 2800 series router >> for a 20-30mbit internet connection. I would like to run a firewall >> IOS and, nat and basic ACL's. Would a 2811 be an appropriate choice? >> >> Thanks, >> Dan. >> _______________________________________________ >> 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 - http://www.avg.com >> Version: 8.0.169 / Virus Database: 270.6.16/1652 - Release Date: 04/09/2008 18:54 >> > > _______________________________________________ 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 Thu Sep 4 23:24:43 2008 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Thu, 4 Sep 2008 21:24:43 -0600 Subject: [c-nsp] Odd MGCP issue with Caller-id References: <4288131ED5E3024C9CD4782CECCAD2C7037AF7E4@LMC-MAIL2.exempla.org> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C70489E739@LMC-MAIL2.exempla.org> Just as a follow-up, and to archive this resolution. I added 'cptone GB' to the 'voice-port 0/2/0' interface and it immediately started working. The fax machine behind the port answered, and all is well. That has a 20 character limit, but at least it works short-term. Tonight after the clinic closes I'll put the 12.4(3h) code we're running on another clinic's 2851, and we should be good to go! It looks like the check was enforced starting at 12.4(20)T and 12.4(21), and I'm told the bug ID was CSCsj70344 (although it talks about calling number, I assume they put in the checks at that point). It'd be nice to have a command-line option to turn off the check entirely, but for now at least there's a fix. Thanks to Oliver Boehmer for pointing me in the right direction! Ken Matlock Network Analyst (303) 467-4671 matlockk at exempla.org ________________________________ From: cisco-nsp-bounces at puck.nether.net on behalf of Matlock, Kenneth L Sent: Thu 9/4/2008 10:39 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Odd MGCP issue with Caller-id We have a Call Manager 4.1 setup, and are using a few 2851's with FXS cards (VIC-4FXS/DID=) as gateways using MGCP for Fax lines. Everything is (and has) been working fine, but we have been tracing down a problem where *some* destinations could not call these extensions (there wasn't a rhyme or reason we could see at first). What we finally found, was that is was based off the length of the *calling* name. If it was 15 characters or less in call manager, it would work, but 16+ would not (they'd get a reorder tone). The relevant debug logs are as follows: Sep 4 09:46:38 MDT: //-1/7EF7044C8022/MGCP|aaln/S0/SU2/0|-1|-1//gen_caller_id(9324):[ lvl=1]mode == VALIDATE cid =<09/04/09/46,24671,Ken Matlock Test Test Test> Sep 4 09:46:38 MDT: //-1/xxxxxxxxxxxx/MGCP/mgcp_parse_cid_str(5889):[lvl=2]time=<09/04/09/46 > num=<24671> name= Sep 4 09:46:38 MDT: //-1/7EF7044C8022/MGCP|aaln/S0/SU2/0|-1|-1//gen_caller_id(9337):[ lvl=0]-- Country code = US Sep 4 09:46:38 MDT: //-1/7EF7044C8022/MGCP|aaln/S0/SU2/0|-1|-1//gen_caller_id(9362):[ lvl=1]-- Caller Id type = 1 Sep 4 09:46:38 MDT: //-1/7EF7044C8022/MGCP|aaln/S0/SU2/0|-1|-1//gen_caller_id(9424):[ lvl=0]-- returns code = 54 Sep 4 09:46:38 MDT: //-1/7EF7044C8022/MGCP|aaln/S0/SU2/0|-1|-1//process_start_signal( 4062):[lvl=2]process_start_signal(): FAIL with rc: 54, need to reject the whole list And Sep 4 09:46:38 MDT: MGCP Packet sent to 172.18.164.136:2427---> 510 100502 unsupported caller id length <--- I've done numerous searches on those errors, and checked the bug toolkit for both IOS version we've tried (12.4(20)T and 12.4(21) ) and no luck. Tried the 'caller-id block' on the port (but since it's not incoming on the FXS port I didn't think it'd help anyway). While we CAN go into Callmanager and shorten all the stations with 16+ character display names, I'd hate to have to go to that trouble if I can help it. Is there a way to increase that limit, or is that a hard-set in either the FXS cards, or MGCP? Ken Matlock Network Analyst (303) 467-4671 matlockk at exempla.org _______________________________________________ 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 tedm at toybox.placo.com Thu Sep 4 22:52:41 2008 From: tedm at toybox.placo.com (Ted Mittelstaedt) Date: Thu, 4 Sep 2008 19:52:41 -0700 Subject: [c-nsp] Surge protection on leased lines In-Reply-To: <20080904160037.GA21273@saucer.midcoast.com> Message-ID: Here is an explanation of what your SUPPOSED to have: http://www.cermetek.com/Support/APP-Notes/611-0175.pdf with some schematics in case you want to roll your own protectors. According to this, per FCC part 68, your national telephone company is in violation of FCC regs if it is not providing an isolation barrier at the customer handoff, which clearly it is not if your losing WICs to lighting. They may be sliding under the regulation by giving you the handoff via V.35 but I doubt it. Frankly I've never seen a SHDSL line being handed off to the customer on a V.35. I've seen plenty of Telco-owned muxes that took a T1 or SHDSL and handed off to the customer via both POTS and V35, though, but I don't see the point of an NIU that goes from SHDSL to V.35 - it's extra cost for the Telco, and that would require the customer prem equipment to be sitting next to the Dmarc since your not going to run V.35 a hundred or so feet from the dmarc to the network room. This scheme sounds cockamamie to me. You learn something new every day. If I were you I would call your local municipality on this. All the electrical codes I've ever seen require the utility side of any feed into a building to have a solid, low-resistance ground at the entry point. They cannot just connect to a cold water pipe or some such nonsense, they have to drive a copper rod into the ground and ground to that. The fact that your "national telco" is allowing lightning energy to come into your building is a fire hazard and I am quite sure is in violation of your local wiring codes. They need a sold ground and suppression such as varistors connected between that ground and both wires of the pair that the SHDSL line is on. If you can get the specific code requirements for your municipality you can threaten to report your national telco to both the FCC and the local municipality if they do not install surge suppression. Ted PS I am assuming your in the US, here. > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of jp > Sent: Thursday, September 04, 2008 9:01 AM > To: Brian Turnbow > Cc: Cisco Mailing list > Subject: Re: [c-nsp] Surge protection on leased lines > > > Usually our Telco has gas/carbon arrestors at the NID and they differ > for pots or T1 as T1 is higher voltage. > > Make sure your nid, smartbox, router are all grounded together and to > the electrical system ground. I suspect they are not if current is > flowing in and damaging your wic. > > I know APC made some ptel series arrestors for T1/ISDN usage for > protecting the twisted pairs when the rj45/48 interfaces are used. I > have these and they are good. Too bad you don't have access to that. > > On Mon, Aug 25, 2008 at 06:05:07PM +0200, Brian Turnbow wrote: > > Thanks for the response. > > They are external csus but they are "telco property" and they > don't want us to touch them. > > We have asked several times that they install protection > coming into the building but no go... > > They install a remote powered integrated shdsl modem/csu in an > all plastic housing and the only place we > > Have been able to connect a ground is to the v.35 mount on the > integrated csu. No help there. > > Lighting strike= burned modem/csu= burned wic > > The v.35 protector would be a try to at least save our wic > cards and costs of dispatching a Tech > > for every passing storm. > > > > > > Brian > > > > -----Original Message----- > > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jay Hennigan > > Sent: luned? 25 agosto 2008 17.34 > > To: Cisco Mailing list > > Subject: Re: [c-nsp] Surge protection on leased lines > > > > Brian Turnbow wrote: > > > Hello, > > > > > > We have several customers that our having problems every time a storm > > > goes through. > > > Our national telco company seems to offer no lightning protection on > > > their lines, and every storm causes a line outage and burns up the > > > attached wic. > > > We've made sure the chassis are grounded , but would also like to try > > > and install a surge protection detween the v.35 interface of the telco > > > and our CPEs. > > > I see that Cisco offers a surge protection cable for smart serial > > > interfaces, but not for classic serial interfaces. > > > I wanted ask what others would recommend / experiences regarding surge > > > protection on leased lines. > > > > This is an external CSU? > > > > I think you want it between the telco smartjack and the CSU, not on the > > v.35. This should be two pairs of wires. > > > > First thing to do is ensure that the telco smartjack, the CSU, and the > > router are solidly connected to a common ground, as this may be the > > source of the problem if the sneak current is not coming across the > > leased line. > > > > There are a number of companies making lightning protectors for twisted > > pair lines, Reliable Electric and Polyphaser are two. > > > > But, triple-check the grounding first because if it's > common-mode across > > a ground differential the protectors won't help. > > > > -- > > 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/ > > _______________________________________________ > > 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/ > */ > _______________________________________________ > 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 gtb at slac.stanford.edu Thu Sep 4 23:41:02 2008 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Thu, 4 Sep 2008 20:41:02 -0700 Subject: [c-nsp] Recommended 2800 ISR In-Reply-To: References: <48C08099.6060908@uol.com.br> Message-ID: > I have read that document before, do those numbers (2811 - 61.44mpbs > CEF Fast switching) mean that it can process that bandwidth with > nothing else running on the router? With the wind behind the bits heading downhill. The first paragraph says: Numbers are given with 64 byte packet size, IP only, and are only an indication of raw switching performance. These are testing numbers, usually with FE to FE or POS to POS, no services enabled. As you add ACL's, encryption, compression, etc - performance will decline significantly from the given numbers .... The moment you add (for example) NAT or Firewall features, expect significantly less performance. As always, your Mbps will vary and your situation will be unique (and almost never to your benefit). From sfischer1967 at gmail.com Thu Sep 4 23:57:34 2008 From: sfischer1967 at gmail.com (Steve Fischer) Date: Thu, 4 Sep 2008 23:57:34 -0400 Subject: [c-nsp] IOS 12.2(18)SXF14 Message-ID: <010c01c90f0b$87b7db00$97279100$@com> Matt - We've been running 12.2(18)SXF13 on 4 Cat6500's w/SUP720-3B's for a good little while, and it has proven to be rock solid. I believe we were using the SXF11 code, and there was some impetus, perhaps a security alert, that moved us to the SXF13 code. I recommend 1) reading the release notes, and 2) checking out Cisco's SafeHarbor site: http://www.cisco.com/go/safeharbor . The SafeHarbor site lists SXF11 as "passed", but, when you attempt to download it from Cisco, it lists advisories concerning that release that were addressed in later releases. Looking at the "fixes" in the SXF14 release, there is nothing there compelling me to move from SXF13. My experience with the SXF13 code has been very good. From ecables at gmail.com Fri Sep 5 00:16:08 2008 From: ecables at gmail.com (Eric Cables) Date: Thu, 4 Sep 2008 21:16:08 -0700 Subject: [c-nsp] vtp domain mindef In-Reply-To: <48C06B06.40204@forthnet.gr> References: <10188D798B596E4585DEAEAC62596D2309D57FDA@WATERFORD.switchnet.nv> <48C06B06.40204@forthnet.gr> Message-ID: Not sure if this helps you, but I found a link via a google search w/ someone who also had a "mindef" vtp domain name... http://www.happyrouter.com/forum/index.php?topic=216.0 -- My vtp status: VTP Version : 2 Configuration Revision : 0 Maximum VLANs supported locally : 1005 Number of existing VLANs : 8 VTP Operating Mode : Transparent VTP Domain Name : mindef VTP Pruning Mode : Disabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled MD5 digest : 0x89 0x45 0xAA 0x2D 0x9E 0x3F 0x92 0x92 -- -- Eric Cables On Thu, Sep 4, 2008 at 4:11 PM, Tassos Chatzithomaoglou wrote: > I don't know what mindef is, but a switch with a null vtp domain (which is > the default) will get the vtp domain of another switch (server or client) > through any trunk link. > > -- > Tassos > > Jim Devane wrote on 05/09/2008 00:36: >> >> Hello, >> >> We observed something interesting. A 6509, IOS, 720-3BXL, 12.2-18 SXF >> suddenly dumped its vlan.dat. It sounds like a classic case of inserting a >> switch with a higher VTP rev confg but that was not the case. No network >> changes either physical or virtual took place (syslog and ACS confirmed) >> The interesting part. The switch had no VTP domain previously defined. >> Somewhat magically, vtp domain mindef appeared in the config. This was never >> configured by a user also syslog and ACS confirmed. >> >> Has anyone heard of mindef as a default of some sort for VTP domains? >> Anyone heard of something like this happening? >> >> >> thanks, >> jim >> _______________________________________________ >> 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 ben.steele at internode.on.net Fri Sep 5 00:45:34 2008 From: ben.steele at internode.on.net (Ben Steele) Date: Fri, 5 Sep 2008 14:15:34 +0930 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <200809051015.06641.mtinka@globaltransit.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <6bb5f5b10809041001q317d4694o8b57be06fcfd54da@mail.gmail.com> <20080904170928.GA23309@mx.ytti.net> <200809051015.06641.mtinka@globaltransit.net> Message-ID: <00b901c90f12$3c293010$b47b9030$@steele@internode.on.net> I'm pretty sure it is scheduled for release in an upcoming update, I know there was lots of "hmmm's" when I saw the list of current unsupported technologies during our companies presentation, but I seem to recall most of them set for release in the future, I mean it would be ridiculous to never support mpls-te on the ASR. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mark Tinka Sent: Friday, 5 September 2008 11:45 AM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] c7604 "starter kit" On Friday 05 September 2008 01:09:28 Saku Ytti wrote: > L3 VPN yes, TE no sure. According to FN, MPLS-TE is unsupported. Quite surprising, actually... Mark. From mtinka at globaltransit.net Fri Sep 5 00:47:19 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 5 Sep 2008 12:47:19 +0800 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <00b901c90f12$3c293010$b47b9030$@steele@internode.on.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <200809051015.06641.mtinka@globaltransit.net> <00b901c90f12$3c293010$b47b9030$@steele@internode.on.net> Message-ID: <200809051247.23496.mtinka@globaltransit.net> On Friday 05 September 2008 12:45:34 Ben Steele wrote: > I'm pretty sure it is scheduled for release in an > upcoming update, I know there was lots of "hmmm's" when I > saw the list of current unsupported technologies during > our companies presentation, but I seem to recall most of > them set for release in the future, I mean it would be > ridiculous to never support mpls-te on the ASR. Of course :-). 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 chiwaikam at hotmail.com Fri Sep 5 02:08:14 2008 From: chiwaikam at hotmail.com (tony kam) Date: Fri, 5 Sep 2008 14:08:14 +0800 Subject: [c-nsp] Allow VTY access by telnet and ssh In-Reply-To: <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> Message-ID: Dear all, Please advise if there is any configuration template to enable both telnet and ssh to have access right into router VTY lines. Regards, Tony From James.Baker at chelmer.co.nz Fri Sep 5 01:50:00 2008 From: James.Baker at chelmer.co.nz (James Baker) Date: Fri, 5 Sep 2008 17:50:00 +1200 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local><64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> Message-ID: <64396C74FCE435468BE2AF5A73F9C2FD86920D@chmaexch.chelmer.co.nz> oh yes most defiantly. If it's too rough as well, check out zabbix and there is one more I can't remember(let me google this) ah yes Zenoss which can integrate with google maps Cheers -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Riemer Sent: Friday, 5 September 2008 2:33 p.m. To: James Baker Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Dashboard Network Monitoring Software Hi James, Yes I thought about nagios. Is it possible to put your own background map in and then position nodes on the map? Thanks for the suggestion. Cheers, Aaron. -----Original Message----- From: James Baker [mailto:James.Baker at chelmer.co.nz] Sent: Friday, 5 September 2008 10:17 AM To: Aaron Riemer; cisco-nsp at puck.nether.net Subject: RE: [c-nsp] Dashboard Network Monitoring Software Nagios. Look at setting up the 2d Status map. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Riemer Sent: Friday, 5 September 2008 1:00 p.m. To: cisco-nsp at puck.nether.net Subject: [c-nsp] Dashboard Network Monitoring Software Hi Guys, Is anyone out there using any open source or free dashboard network monitoring software? I would like to have a map background with our sites and possibly blink the sites RED if the site stopped responding to pings or SNMP queries etc? I know Solarwinds and HP Openview are good but we are not willing to shell out the money just for a dashboard. Cheers, Aaron. LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ 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/ ---------- The information contained in this e-mail and any attachments is confidential and is intended for the attention and use of the named addressee(s) only. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Chelmer Limited. ######################################################################## ############# This e-mail message has been scanned for Viruses and Content and cleared by NetIQ MailMarshal ######################################################################## ############# LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ 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 e-mail message has been scanned for Viruses and Content and cleared by NetIQ MailMarshal ##################################################################################### From abalashov at evaristesys.com Fri Sep 5 02:25:18 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Fri, 05 Sep 2008 02:25:18 -0400 Subject: [c-nsp] Allow VTY access by telnet and ssh In-Reply-To: References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> Message-ID: <48C0D0CE.1050504@evaristesys.com> tony kam wrote: > Dear all, > > Please advise if there is any configuration template to enable both telnet and ssh to have access right into router VTY lines. What do you mean by "right into?" -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From abalashov at evaristesys.com Fri Sep 5 02:27:51 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Fri, 05 Sep 2008 02:27:51 -0400 Subject: [c-nsp] VoIP classifying and queuing in an access switch <--> core Layer 2 network In-Reply-To: <71BC8F601C01554CA7410616B26C50D1016703CD@mail-37ps.atlarge.net> References: <71BC8F601C01554CA7410616B26C50D1016703CD@mail-37ps.atlarge.net> Message-ID: <48C0D167.7030602@evaristesys.com> If the switch is purely Layer 2, it would be difficult to classify VoIP traffic ipso facto, as the factors that differentiate it from other kinds of traffic are, by definition, >= Layer 3. About the only thing you can do there is use segregated VLANs, and/or take advantage of the native "voice VLAN" feature of certain Catalysts: http://www.cisco.com/en/US/docs/switches/lan/catalyst2940/software/release/12.1_19_ea1/configuration/guide/swvoip.html Grant Moerschel wrote: > In an access switch to core where the connections are Layer 2, what is > the best method to a) classify voip traffic as it enters the access > switch and b) prioritize it via some queuing mechanism as it traverses > the trunk going to the core? Does anyone have sample configs for > something like this? > > Pc <-> phone <-> access switch <-> core switch. Priority to VoIP traffic > on trunks. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From abalashov at evaristesys.com Fri Sep 5 02:29:49 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Fri, 05 Sep 2008 02:29:49 -0400 Subject: [c-nsp] Recommended 2800 ISR In-Reply-To: <9418aca70809041817j33a453adp45a8c5eb39d27a93@mail.gmail.com> References: <48C08099.6060908@uol.com.br> <9418aca70809041817j33a453adp45a8c5eb39d27a93@mail.gmail.com> Message-ID: <48C0D1DD.9040708@evaristesys.com> Jay Nakamura wrote: > What about going with an ASA? Much more performance for the money. But it > depends on what all you want to do on the router. IOS is a lot more > flexible on what you can do. But, an ASA or PIX is far more optimised for NAT and ACL duty. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From r.engehausen at gmail.com Fri Sep 5 02:33:35 2008 From: r.engehausen at gmail.com (Roy) Date: Thu, 04 Sep 2008 23:33:35 -0700 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> Message-ID: <48C0D2BF.8050407@gmail.com> Try Opsview. Very nice clean GUI for nagios, nagiosgraph, and MRTG. Aaron Riemer wrote: > Hi James, > > Yes I thought about nagios. Is it possible to put your own background > map in and then position nodes on the map? > > Thanks for the suggestion. > > Cheers, > > Aaron. > -----Original Message----- > From: James Baker [mailto:James.Baker at chelmer.co.nz] > Sent: Friday, 5 September 2008 10:17 AM > To: Aaron Riemer; cisco-nsp at puck.nether.net > Subject: RE: [c-nsp] Dashboard Network Monitoring Software > > Nagios. Look at setting up the 2d Status map. > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Riemer > Sent: Friday, 5 September 2008 1:00 p.m. > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] Dashboard Network Monitoring Software > > Hi Guys, > > > > Is anyone out there using any open source or free dashboard network > monitoring software? I would like to have a map background with our > sites and possibly blink the sites RED if the site stopped responding to > pings or SNMP queries etc? I know Solarwinds and HP Openview are good > but we are not willing to shell out the money just for a dashboard. > > > > Cheers, > > > > Aaron. > > > > > > > > > > > LEGAL DISCLAIMER: This message contains confidential information and is > intended only for the individual named. If you are not the named > addressee you should not disseminate, distribute or copy this e-mail. > Please notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. If you are > not the intended recipient you are notified that disclosing, copying, > distributing or taking any action in reliance on the contents of this > information is strictly prohibited. > _______________________________________________ > 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/ > ---------- > > The information contained in this e-mail and any attachments is > confidential > and is intended for the attention and use of the named addressee(s) > only. > Any views expressed in this message are those of the individual sender > and > may not necessarily reflect the views of Chelmer Limited. > > ######################################################################## > ############# > This e-mail message has been scanned for Viruses and Content and cleared > > by NetIQ MailMarshal > ######################################################################## > ############# > > LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. > _______________________________________________ > 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 abalashov at evaristesys.com Fri Sep 5 02:34:12 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Fri, 05 Sep 2008 02:34:12 -0400 Subject: [c-nsp] RTP port In-Reply-To: <62c908120809040024q72fd82c6u869b4adeb0fbb479@mail.gmail.com> References: <62c908120809040024q72fd82c6u869b4adeb0fbb479@mail.gmail.com> Message-ID: <48C0D2E4.1020309@evaristesys.com> Tseveendorj Ochirlantuu wrote: > If is it possible to choose RTP port on AS5350XM? > for example: don't use all ports 16000-60000 on gateway. Only use between > 16000-17000. Not natively, but you could probably do this using NAT on the outgoing interfaces. Although, for various performance reasons, I think you would not want to. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From chiwaikam at hotmail.com Fri Sep 5 02:39:00 2008 From: chiwaikam at hotmail.com (tony kam) Date: Fri, 5 Sep 2008 14:39:00 +0800 Subject: [c-nsp] Allow VTY access by telnet and ssh In-Reply-To: <48C0D0CE.1050504@evaristesys.com> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> <48C0D0CE.1050504@evaristesys.com> Message-ID: It meant users can use either telnet or ssh client to log into router VTY lines. Besides, I think it is possible to use ACL to control which user group can use telnet and which user group can use ssh. Please advise if you have such sample configuration.> Date: Fri, 5 Sep 2008 02:25:18 -0400> From: abalashov at evaristesys.com> To: chiwaikam at hotmail.com> CC: cisco-nsp at puck.nether.net> Subject: Re: [c-nsp] Allow VTY access by telnet and ssh> > tony kam wrote:> > Dear all,> > > > Please advise if there is any configuration template to enable both telnet and ssh to have access right into router VTY lines. > > What do you mean by "right into?"> > -- > Alex Balashov> Evariste Systems> Web : http://www.evaristesys.com/> Tel : (+1) (678) 954-0670> Direct : (+1) (678) 954-0671> Mobile : (+1) (706) 338-8599 From abalashov at evaristesys.com Fri Sep 5 02:41:35 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Fri, 05 Sep 2008 02:41:35 -0400 Subject: [c-nsp] Allow VTY access by telnet and ssh In-Reply-To: References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> <48C0D0CE.1050504@evaristesys.com> Message-ID: <48C0D49F.9080504@evaristesys.com> All logins are on VTYs, so that qualification is not needed. Check out: http://www.cisco.com/en/US/docs/security/asa/asa71/configuration/guide/mgaccess.html tony kam wrote: > It meant users can use either telnet or ssh client to log into router > VTY lines. Besides, I think it is possible to use ACL to control which > user group can use telnet and which user group can use ssh. > > Please advise if you have such sample configuration. > > > Date: Fri, 5 Sep 2008 02:25:18 -0400 > > From: abalashov at evaristesys.com > > To: chiwaikam at hotmail.com > > CC: cisco-nsp at puck.nether.net > > Subject: Re: [c-nsp] Allow VTY access by telnet and ssh > > > > tony kam wrote: > > > Dear all, > > > > > > Please advise if there is any configuration template to enable both > telnet and ssh to have access right into router VTY lines. > > > > What do you mean by "right into?" > > > > -- > > Alex Balashov > > Evariste Systems > > Web : http://www.evaristesys.com/ > > Tel : (+1) (678) 954-0670 > > Direct : (+1) (678) 954-0671 > > Mobile : (+1) (706) 338-8599 > -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From ben.steele at internode.on.net Fri Sep 5 02:43:58 2008 From: ben.steele at internode.on.net (Ben Steele) Date: Fri, 5 Sep 2008 16:13:58 +0930 Subject: [c-nsp] WebVPN via RADIUS - how to identify by group? Message-ID: <00d001c90f22$c6f0e2f0$54d2a8d0$@steele@internode.on.net> Howdy all, Anyone know if it's possible to get as ASA to spit out the group name in an av-pair via radius when authenticating a user? (in this case webvpn). The issue i'm having is multiple clients on the one ASA authenticating via IAS/AD and the possibility of overlapping usernames between clients(groups), I need another identifier from the ASA to auth them against other than user/pass, ie group would be perfect. Any ideas? Cheers Ben From abalashov at evaristesys.com Fri Sep 5 02:42:38 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Fri, 05 Sep 2008 02:42:38 -0400 Subject: [c-nsp] Allow VTY access by telnet and ssh In-Reply-To: <48C0D49F.9080504@evaristesys.com> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> <48C0D0CE.1050504@evaristesys.com> <48C0D49F.9080504@evaristesys.com> Message-ID: <48C0D4DE.7030001@evaristesys.com> Whoops, that was for ASAs. Try: http://articles.techrepublic.com.com/5100-10878_11-5875046.html http://www.cisco.com/en/US/products/sw/iosswrel/ps1818/products_configuration_example09186a0080204528.shtml Alex Balashov wrote: > All logins are on VTYs, so that qualification is not needed. > > Check out: > > http://www.cisco.com/en/US/docs/security/asa/asa71/configuration/guide/mgaccess.html > > > tony kam wrote: > >> It meant users can use either telnet or ssh client to log into router >> VTY lines. Besides, I think it is possible to use ACL to control which >> user group can use telnet and which user group can use ssh. >> >> Please advise if you have such sample configuration. >> >> > Date: Fri, 5 Sep 2008 02:25:18 -0400 >> > From: abalashov at evaristesys.com >> > To: chiwaikam at hotmail.com >> > CC: cisco-nsp at puck.nether.net >> > Subject: Re: [c-nsp] Allow VTY access by telnet and ssh >> > >> > tony kam wrote: >> > > Dear all, >> > > >> > > Please advise if there is any configuration template to enable >> both telnet and ssh to have access right into router VTY lines. >> > >> > What do you mean by "right into?" >> > >> > -- >> > Alex Balashov >> > Evariste Systems >> > Web : http://www.evaristesys.com/ >> > Tel : (+1) (678) 954-0670 >> > Direct : (+1) (678) 954-0671 >> > Mobile : (+1) (706) 338-8599 >> > > -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From john.douglas at gmail.com Fri Sep 5 02:45:26 2008 From: john.douglas at gmail.com (john douglas) Date: Fri, 5 Sep 2008 16:45:26 +1000 Subject: [c-nsp] CF format problems on 6500/7600 SUP720-3BXL Message-ID: <5c846eaf0809042345g6af1bdday59cb23a0ce10f8d1@mail.gmail.com> hi all, firstly i've read the threads about monlib etc, i tend to make it standard practice to format the flash card in whatever chassis it is currently in before use, however in this case, i cant even format the flash cards. we are talking about genuine sandisk 1GB which seem to work ok elsewhere but in the 6500 & 7600 SUP720-3BXL based platforms everything appears fine until you go to format the card and then you get this Router#format disk1: Format operation may take a while. Continue? [confirm] Format operation will destroy all data in "disk1:". Continue? [confirm] %Error formatting disk1 (Format failure - Drive Communication) and then the CF card promptly disappears Router#dir disk1: %Error opening disk1:/ (No such device) Router#sh plat hard cap | i disk 1 SP disk0: 128151552 78741504 61% i have tried formatting these CF cards on other routers eg 7301, 1841, bring them over to the SUP720, they look fine, but the moment you go to re-format - splat. i have tried formatting these CF cards on a PC using a CF card reader, again they look fine, but again splat. now, what is REALLY wierd i format these CF card on a Canon EOS 400D digital SLR and they work just fine in the SUP720 Router#sh disk1: -#- --length-- -----date/time------ path 1 0 Sep 02 2008 15:43:54 DCIM 2 0 Sep 02 2008 15:43:54 DCIM/217CANON 260796416 bytes available (8192 bytes used) Router#dir disk1:/DCIM/217CANON/ Directory of disk1:/DCIM/217CANON/ No files in directory 260804608 bytes total (260796416 bytes free) Router#format disk1: Format operation may take a while. Continue? [confirm] Format operation will destroy all data in "disk1:". Continue? [confirm] Format: Drive communication & 1st Sector Write OK... Writing Monlib sectors. Monlib Version = 2 (0.2) ............................................................................................................................................... Monlib write complete . Format: All system sectors written. OK... Format: Total sectors in formatted partition: 510281 Format: Total bytes in formatted partition: 261263872 Format: Operation completed successfully. Format of disk1 complete very confused... From bandwidth.user at gmail.com Fri Sep 5 02:52:11 2008 From: bandwidth.user at gmail.com (roy) Date: Fri, 05 Sep 2008 14:52:11 +0800 Subject: [c-nsp] Allow VTY access by telnet and ssh In-Reply-To: References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> Message-ID: <1220597531.5582.9.camel@localhost> On Fri, 2008-09-05 at 14:08 +0800, tony kam wrote: > Dear all, > > Please advise if there is any configuration template to enable both > telnet and ssh to have access right into router VTY lines. <...> line vty x y transport input telnet ssh <...> hth, roy From oboehmer at cisco.com Fri Sep 5 03:17:13 2008 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Fri, 5 Sep 2008 09:17:13 +0200 Subject: [c-nsp] VoIP classifying and queuing in an access switch <--> core Layer 2 network In-Reply-To: <48C0D167.7030602@evaristesys.com> References: <71BC8F601C01554CA7410616B26C50D1016703CD@mail-37ps.atlarge.net> <48C0D167.7030602@evaristesys.com> Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED78405F7F91E@xmb-ams-333.emea.cisco.com> Alex Balashov <> wrote on Friday, September 05, 2008 8:28 AM: > If the switch is purely Layer 2, it would be difficult to classify > VoIP traffic ipso facto, as the factors that differentiate it from > other kinds of traffic are, by definition, >= Layer 3. Well, even a Layer 2 switch can classify based on L3 information, most of today's (and yesterday's) Cat2xxx/3xxx support this. I would recommend looking at the Enterprise QoS solution reference at www.cisco.com/go/srnd for plenty of examples for various access switch platforms. oli > About the only thing you can do there is use segregated VLANs, and/or > take advantage of the native "voice VLAN" feature of certain > Catalysts: > > http://www.cisco.com/en/US/docs/switches/lan/catalyst2940/software/relea se/12.1_19_ea1/configuration/guide/swvoip.html > > Grant Moerschel wrote: > >> In an access switch to core where the connections are Layer 2, what >> is the best method to a) classify voip traffic as it enters the >> access switch and b) prioritize it via some queuing mechanism as it >> traverses the trunk going to the core? Does anyone have sample >> configs for something like this? >> >> Pc <-> phone <-> access switch <-> core switch. Priority to VoIP >> traffic on trunks. > > -- > Alex Balashov > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (706) 338-8599 > _______________________________________________ > 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 daniels.id.au Fri Sep 5 02:45:14 2008 From: lists at daniels.id.au (Aaron Daniels - Lists) Date: Fri, 5 Sep 2008 16:45:14 +1000 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> Message-ID: <014b01c90f22$f60cf9c0$e226ed40$@id.au> Also take a look at Zenoss www.zenoss.org Aaron > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Daniel Hooper > Sent: Friday, 5 September 2008 12:55 PM > To: Aaron Riemer > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Dashboard Network Monitoring Software > > www.nagios.org > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Riemer > Sent: Friday, 5 September 2008 9:00 AM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] Dashboard Network Monitoring Software > > Hi Guys, > > > > Is anyone out there using any open source or free dashboard network > monitoring software? I would like to have a map background with our > sites and possibly blink the sites RED if the site stopped responding > to > pings or SNMP queries etc? I know Solarwinds and HP Openview are good > but we are not willing to shell out the money just for a dashboard. > > > > Cheers, > > > > Aaron. > > > > > > > > > > > LEGAL DISCLAIMER: This message contains confidential information and is > intended only for the individual named. If you are not the named > addressee you should not disseminate, distribute or copy this e-mail. > Please notify the sender immediately by e-mail if you have received > this > e-mail by mistake and delete this e-mail from your system. If you are > not the intended recipient you are notified that disclosing, copying, > distributing or taking any action in reliance on the contents of this > information is strictly prohibited. > _______________________________________________ > 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 achatz at forthnet.gr Fri Sep 5 03:18:36 2008 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Fri, 05 Sep 2008 10:18:36 +0300 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <00b901c90f12$3c293010$b47b9030$@steele@internode.on.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <6bb5f5b10809041001q317d4694o8b57be06fcfd54da@mail.gmail.com> <20080904170928.GA23309@mx.ytti.net> <200809051015.06641.mtinka@globaltransit.net> <00b901c90f12$3c293010$b47b9030$@steele@internode.on.net> Message-ID: <48C0DD4C.1020703@forthnet.gr> MPLE TE should be in RLS3; probably EoMPLS too. -- Tassos Ben Steele wrote on 05/09/2008 07:45: > I'm pretty sure it is scheduled for release in an upcoming update, I know > there was lots of "hmmm's" when I saw the list of current unsupported > technologies during our companies presentation, but I seem to recall most of > them set for release in the future, I mean it would be ridiculous to never > support mpls-te on the ASR. > > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mark Tinka > Sent: Friday, 5 September 2008 11:45 AM > To: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] c7604 "starter kit" > > On Friday 05 September 2008 01:09:28 Saku Ytti wrote: > >> L3 VPN yes, TE no sure. > > According to FN, MPLS-TE is unsupported. Quite surprising, actually... > > Mark. > > _______________________________________________ > 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 abalashov at evaristesys.com Fri Sep 5 03:26:41 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Fri, 05 Sep 2008 03:26:41 -0400 Subject: [c-nsp] VoIP classifying and queuing in an access switch <--> core Layer 2 network In-Reply-To: <70B7A1CCBFA5C649BD562B6D9F7ED78405F7F91E@xmb-ams-333.emea.cisco.com> References: <71BC8F601C01554CA7410616B26C50D1016703CD@mail-37ps.atlarge.net> <48C0D167.7030602@evaristesys.com> <70B7A1CCBFA5C649BD562B6D9F7ED78405F7F91E@xmb-ams-333.emea.cisco.com> Message-ID: <48C0DF31.3030200@evaristesys.com> Oliver Boehmer (oboehmer) wrote: > Alex Balashov <> wrote on Friday, September 05, 2008 8:28 AM: > >> If the switch is purely Layer 2, it would be difficult to classify >> VoIP traffic ipso facto, as the factors that differentiate it from >> other kinds of traffic are, by definition, >= Layer 3. > > Well, even a Layer 2 switch can classify based on L3 information, most > of today's (and yesterday's) Cat2xxx/3xxx support this. > I would recommend looking at the Enterprise QoS solution reference at > www.cisco.com/go/srnd for plenty of examples for various access switch > platforms. Really... I wasn't aware Layer 2 devices had DiffServ/DSCP awareness. I stand corrected, then! -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From CB at nianet.dk Fri Sep 5 03:34:09 2008 From: CB at nianet.dk (Christian Bering) Date: Fri, 5 Sep 2008 09:34:09 +0200 Subject: [c-nsp] Allow VTY access by telnet and ssh References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local><64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> Message-ID: Hi, >Please advise if there is any configuration template to enable >both telnet and ssh to have access right into router VTY lines. Do you mean like this, or are you talking about something else? ! line vty 0 4 transport input telnet ssh ! crypto key generate rsa general-keys modulus 2048 ! -- Regards Christian Bering From jay at west.net Fri Sep 5 03:20:54 2008 From: jay at west.net (Jay Hennigan) Date: Fri, 05 Sep 2008 00:20:54 -0700 Subject: [c-nsp] Allow VTY access by telnet and ssh In-Reply-To: References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> Message-ID: <48C0DDD6.8000305@west.net> tony kam wrote: > Dear all, > > Please advise if there is any configuration template to enable both telnet and ssh to have access right into router VTY lines. Did you try: line vty 0 4 transport input telnet ssh The number of vty lines may be different depending on platform and IOS, for example, "line vty 0 15". -- 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 wim.holemans at ua.ac.be Fri Sep 5 04:35:14 2008 From: wim.holemans at ua.ac.be (Holemans Wim) Date: Fri, 5 Sep 2008 10:35:14 +0200 Subject: [c-nsp] FWSM failover transparent mode Message-ID: <2F7B70885960AA42BE820036B3A8CDA02AC25B@xmail06.ad.ua.ac.be> Just upgraded our FWSM to version 3.1.11 after 3 random crashes in a month. Now we are thinking about buying a second FWSM to do failover in order to limit downtime and facilitate upgrades : most of our servers are connected to the 6513 carrying this FWSM. We use the 2 standard virtual contexts of the FWSM, both in transparent mode, 8 bridged vlans on one, 2 bridged vlans on the second. In the release notes of 3.1.11 I however read under Open Caveats "CSCm73157 : Failover is not working in transparent mode..." Anyone has experience with FWSM failover in transparent mode ? Does this really doesn't work ? Does it work under 3.2 or 4.0 ? Any info would be appreciated before we invest more than 15K Euros... Wim Holemans Netwerkdienst Universiteit Antwerpen From ariemer at wesenergy.com.au Fri Sep 5 04:50:02 2008 From: ariemer at wesenergy.com.au (Aaron Riemer) Date: Fri, 5 Sep 2008 16:50:02 +0800 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: <014b01c90f22$f60cf9c0$e226ed40$@id.au> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <014b01c90f22$f60cf9c0$e226ed40$@id.au> Message-ID: <0867622C64B50C4B878AB45C95F43F1106150F02@MAILWA01.wesenergy.local> Zenoss looks cool but it looks like you have to pay for that software :) Cheers for the ideas. Aaron. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Daniels - Lists Sent: Friday, 5 September 2008 2:45 PM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Dashboard Network Monitoring Software Also take a look at Zenoss www.zenoss.org Aaron > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Daniel Hooper > Sent: Friday, 5 September 2008 12:55 PM > To: Aaron Riemer > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Dashboard Network Monitoring Software > > www.nagios.org > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Riemer > Sent: Friday, 5 September 2008 9:00 AM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] Dashboard Network Monitoring Software > > Hi Guys, > > > > Is anyone out there using any open source or free dashboard network > monitoring software? I would like to have a map background with our > sites and possibly blink the sites RED if the site stopped responding > to > pings or SNMP queries etc? I know Solarwinds and HP Openview are good > but we are not willing to shell out the money just for a dashboard. > > > > Cheers, > > > > Aaron. > > > > > > > > > > > LEGAL DISCLAIMER: This message contains confidential information and is > intended only for the individual named. If you are not the named > addressee you should not disseminate, distribute or copy this e-mail. > Please notify the sender immediately by e-mail if you have received > this > e-mail by mistake and delete this e-mail from your system. If you are > not the intended recipient you are notified that disclosing, copying, > distributing or taking any action in reliance on the contents of this > information is strictly prohibited. > _______________________________________________ > 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/ LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From paul.cosgrove at heanet.ie Fri Sep 5 05:04:25 2008 From: paul.cosgrove at heanet.ie (Paul Cosgrove) Date: Fri, 05 Sep 2008 10:04:25 +0100 Subject: [c-nsp] disabling 3750 mac address learning Message-ID: <48C0F619.3090903@heanet.ie> Noticed that the 3750 ios 12.2(46)SE release supports the disabling of mac address learning per vlan. Does anyone have any experience with this release yet? The feature seems to have been introduced earlier in the 3650s and has obviously been in ME switches for a while. http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_46_se/command/reference/cli1.html#wp10289393 Paul. -- HEAnet Limited Ireland's Education & Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. From mailinglist at bangky.net Fri Sep 5 05:42:25 2008 From: mailinglist at bangky.net (Ang Kah Yik) Date: Fri, 5 Sep 2008 17:42:25 +0800 Subject: [c-nsp] Allow VTY access by telnet and ssh In-Reply-To: <48C0DDD6.8000305@west.net> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> <48C0DDD6.8000305@west.net> Message-ID: I think more specifically, he wanted to be able to permit a particular group of users to use telnet and another to use ssh. While I'm not sure why it'd be good to use telnet when ssh is available, I suppose it would be possible to apply an ACL on the VTYs to deny access to telnet/ssh as required. On Fri, Sep 5, 2008 at 3:20 PM, Jay Hennigan wrote: > tony kam wrote: > >> Dear all, >> Please advise if there is any configuration template to enable both >> telnet and ssh to have access right into router VTY lines. >> > > Did you try: > > line vty 0 4 > transport input telnet ssh > > The number of vty lines may be different depending on platform and IOS, for > example, "line vty 0 15". > > -- > 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/ > -- Ang Kah Yik From jay at west.net Fri Sep 5 06:27:59 2008 From: jay at west.net (Jay Hennigan) Date: Fri, 05 Sep 2008 03:27:59 -0700 Subject: [c-nsp] Allow VTY access by telnet and ssh In-Reply-To: References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> <48C0DDD6.8000305@west.net> Message-ID: <48C109AF.7030509@west.net> Ang Kah Yik wrote: > I think more specifically, he wanted to be able to permit a particular group > of users to use telnet and another to use ssh. > While I'm not sure why it'd be good to use telnet when ssh is available, I > suppose it would be possible to apply an ACL on the VTYs to deny access to > telnet/ssh as required. I haven't tried it, but it might be possible to use an extended ACL for this. ip access-list extended vty-list permit tcp 1.1.1.0 0.0.0.255 any eq 22 permit tcp 2.2.2.0 0.0.0.255 any eq 23 line vty 0 4 transport input telnet ssh access-class vty-list in -- 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 allan.eising at gmail.com Fri Sep 5 06:46:14 2008 From: allan.eising at gmail.com (Allan Eising) Date: Fri, 5 Sep 2008 12:46:14 +0200 Subject: [c-nsp] Allow VTY access by telnet and ssh In-Reply-To: <48C109AF.7030509@west.net> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> <48C0DDD6.8000305@west.net> <48C109AF.7030509@west.net> Message-ID: I can't see why you should use an extended acl to do that. "transport input telnet ssh" should allow access only through those two protocols, so filtering that through an ACL is a bit redundant in my opinion. You should be able to use a standard acl like: ip access-list standard vty permit 10.0.0.0 0.0.0.255 permit 10.1.0.0 0.0.0.255 deny any log ! line vty 0 4 transport input telnet ssh access-class vty in ! That should do it. Best regards, Allan Eising On Fri, Sep 5, 2008 at 12:27 PM, Jay Hennigan wrote: > Ang Kah Yik wrote: >> >> I think more specifically, he wanted to be able to permit a particular >> group >> of users to use telnet and another to use ssh. >> While I'm not sure why it'd be good to use telnet when ssh is available, I >> suppose it would be possible to apply an ACL on the VTYs to deny access to >> telnet/ssh as required. > > I haven't tried it, but it might be possible to use an extended ACL for > this. > > ip access-list extended vty-list > permit tcp 1.1.1.0 0.0.0.255 any eq 22 > permit tcp 2.2.2.0 0.0.0.255 any eq 23 > > line vty 0 4 > transport input telnet ssh > access-class vty-list in > > -- > 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/ > From jay at west.net Fri Sep 5 06:53:11 2008 From: jay at west.net (Jay Hennigan) Date: Fri, 05 Sep 2008 03:53:11 -0700 Subject: [c-nsp] Allow VTY access by telnet and ssh In-Reply-To: References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> <48C0DDD6.8000305@west.net> <48C109AF.7030509@west.net> Message-ID: <48C10F97.1040604@west.net> Allan Eising wrote: > I can't see why you should use an extended acl to do that. "transport > input telnet ssh" should allow access only through those two > protocols, so filtering that through an ACL is a bit redundant in my > opinion. > > You should be able to use a standard acl like: > ip access-list standard vty > permit 10.0.0.0 0.0.0.255 > permit 10.1.0.0 0.0.0.255 > deny any log > ! > line vty 0 4 > transport input telnet ssh > access-class vty in > ! The objective was to allow one group to use telnet and another to use ssh. This would require an extended ACL. >> Ang Kah Yik wrote: >>> I think more specifically, he wanted to be able to permit a particular >>> group >>> of users to use telnet and another to use ssh. >>> While I'm not sure why it'd be good to use telnet when ssh is available, I >>> suppose it would be possible to apply an ACL on the VTYs to deny access to >>> telnet/ssh as required. -- 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 sthaug at nethelp.no Fri Sep 5 07:33:37 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 05 Sep 2008 13:33:37 +0200 (CEST) Subject: [c-nsp] disabling 3750 mac address learning In-Reply-To: <48C0F619.3090903@heanet.ie> References: <48C0F619.3090903@heanet.ie> Message-ID: <20080905.133337.74700578.sthaug@nethelp.no> > Noticed that the 3750 ios 12.2(46)SE release supports the disabling of > mac address learning per vlan. Does anyone have any experience with > this release yet? > > The feature seems to have been introduced earlier in the 3650s and has > obviously been in ME switches for a while. The feature has been there longer, in the form of an RSPAN-enabled VLAN. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From streiner at cluebyfour.org Fri Sep 5 07:51:09 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 5 Sep 2008 07:51:09 -0400 (EDT) Subject: [c-nsp] FWSM failover transparent mode In-Reply-To: <2F7B70885960AA42BE820036B3A8CDA02AC25B@xmail06.ad.ua.ac.be> References: <2F7B70885960AA42BE820036B3A8CDA02AC25B@xmail06.ad.ua.ac.be> Message-ID: On Fri, 5 Sep 2008, Holemans Wim wrote: > Just upgraded our FWSM to version 3.1.11 after 3 random crashes in a > month. Now we are thinking about buying a second FWSM to do failover in > order to limit downtime and facilitate upgrades : most of our servers > are connected to the 6513 carrying this FWSM. > > In the release notes of 3.1.11 I however read under Open Caveats > > "CSCm73157 : Failover is not working in transparent mode..." > > Anyone has experience with FWSM failover in transparent mode ? Does this > really doesn't work ? > > Does it work under 3.2 or 4.0 ? FWSM failover in transparent mode does work in 3.2. Specifically, 3.2(4) and above. Right now we're running 3.2(6) and 3.2(7) in production. I want to give the 4.x code more time to 'bake' before I put it in production here. I may try it out in our development lab soon. jms From rodunn at cisco.com Fri Sep 5 08:07:24 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Fri, 5 Sep 2008 08:07:24 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <200809041546.23959.kratzers@pa.net> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> Message-ID: <20080905120724.GI15736@rtp-cse-489.cisco.com> But make sure you do: config t int null 0 no ip unreachables The ACL drops are, last I checked, rate limit punts. If it's high CPU at IP Input really need 12.4(20)T and get a sniffer trace in the punt path to see what traffic it really is. Rodney On Thu, Sep 04, 2008 at 03:46:23PM -0400, Stephen Kratzer wrote: > On Thursday 04 September 2008 15:12:12 Mateusz B??aszczyk wrote: > > 2008/9/4 Stephen Kratzer : > > > The 'log' keyword will cause matching packets to not be CEF switched. > > > > nope, log is not present. > > > > > Also, if > > > you're denying a lot of traffic from a certain source, you might want to > > > just bit-bucket it rather than sending ICMP responses. > > > > you mean - "no ip unreachables"? > > You could match the access list in a route map and set the outbound interface > to Null0. > _______________________________________________ > 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_laporte at harvard.edu Fri Sep 5 08:23:54 2008 From: david_laporte at harvard.edu (LaPorte, David) Date: Fri, 05 Sep 2008 08:23:54 -0400 Subject: [c-nsp] WebVPN via RADIUS - how to identify by group? In-Reply-To: <00d001c90f22$c6f0e2f0$54d2a8d0$@steele@internode.on.net> References: <00d001c90f22$c6f0e2f0$54d2a8d0$@steele@internode.on.net> Message-ID: <48C124DA.5020408@harvard.edu> You could pass the group as a realm to the RADIUS server by having the users log in as USER at GROUP. The RADIUS server could authenticate them and return a Class="OU=GROUP;" attribute to map them properly. You could also provide a group list to the user: http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00808bd83d.shtml I prefer not to do this since it could make enumeration attacks a bit easier, but it has it's place. hope that helps, Dave Ben Steele wrote: > Howdy all, > > > > Anyone know if it's possible to get as ASA to spit out the group name in an > av-pair via radius when authenticating a user? (in this case webvpn). > > > > The issue i'm having is multiple clients on the one ASA authenticating via > IAS/AD and the possibility of overlapping usernames between clients(groups), > I need another identifier from the ASA to auth them against other than > user/pass, ie group would be perfect. > > > > Any ideas? > > > > Cheers > > > > Ben > > > > > > _______________________________________________ > 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/ -- David LaPorte, CISSP, CCNP Security Manager, Network and Server Systems Harvard University Information Systems ----------------------------------------------- Email: david_laporte at harvard.edu PGP: 0x4DC3E508 4A1F058DB2B32FEF10A14F6BD370A6AD4DC3E508 From gert at greenie.muc.de Fri Sep 5 09:34:28 2008 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 5 Sep 2008 15:34:28 +0200 Subject: [c-nsp] CSS strange behaviour.... Or is it just my config [7:132492] In-Reply-To: References: <200809040227.m842RBGe015086@groupstudy.com> <20080904062227.GP233@greenie.muc.de> <20080904080208.GA17238@greenie.muc.de> Message-ID: <20080905133427.GJ17238@greenie.muc.de> Hi, On Fri, Sep 05, 2008 at 09:52:05AM +1000, Brett Clausenhauf wrote: > I've since tried other ports (Port 23 for example) & it still does the same > thing. This has got me stumped... I cannot figure out why it needs the group > command to stay working. telnet (xinetd/tcpd) usually does a DNS lookup as well. As I said: run tcpdump/wireshark to see what sort of outbound connection your machines do. The CSS doesn't need the group section for itself. 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: 304 bytes Desc: not available URL: From tvarriale at comcast.net Fri Sep 5 10:25:23 2008 From: tvarriale at comcast.net (Tony Varriale) Date: Fri, 5 Sep 2008 09:25:23 -0500 Subject: [c-nsp] FWSM failover transparent mode References: <2F7B70885960AA42BE820036B3A8CDA02AC25B@xmail06.ad.ua.ac.be> Message-ID: <005101c90f63$3c73f0e0$f211a8c0@flamadam> I'm running 3.2(6) fairly well in production. I would go up to 3.2(4) or better. tv ----- Original Message ----- From: "Holemans Wim" To: Sent: Friday, September 05, 2008 3:35 AM Subject: [c-nsp] FWSM failover transparent mode > Just upgraded our FWSM to version 3.1.11 after 3 random crashes in a > month. Now we are thinking about buying a second FWSM to do failover in > order to limit downtime and facilitate upgrades : most of our servers > are connected to the 6513 carrying this FWSM. > > We use the 2 standard virtual contexts of the FWSM, both in transparent > mode, 8 bridged vlans on one, 2 bridged vlans on the second. > > > > In the release notes of 3.1.11 I however read under Open Caveats > > "CSCm73157 : Failover is not working in transparent mode..." > > > > Anyone has experience with FWSM failover in transparent mode ? Does this > really doesn't work ? > > Does it work under 3.2 or 4.0 ? > > > > Any info would be appreciated before we invest more than 15K Euros... > > > > Wim Holemans > > Netwerkdienst Universiteit Antwerpen > > > > _______________________________________________ > 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 nic.tjirkalli at za.verizonbusiness.com Fri Sep 5 10:36:08 2008 From: nic.tjirkalli at za.verizonbusiness.com (Nic Tjirkalli) Date: Fri, 5 Sep 2008 16:36:08 +0200 (SAST) Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080905120724.GI15736@rtp-cse-489.cisco.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> Message-ID: howdy ho, > But make sure you do: > > config t > int null 0 > no ip unreachables > > The ACL drops are, last I checked, rate limit punts. this is interesting - there is a good article detailing cef and CPU punting at :- http://searchnetworkingchannel.techtarget.com/generic/0,295582,sid100_gci1261924,00.html Reading that and this posting begs the question - if there is a lrage amount of ACL drops and these packets are punted to cPU and the CPU rate-limit for punted packets has been exceeded, then possible packets that need to be CPU processed will be dropped in favour of ACL denied packets - this seems a bit ridiculous. Any way to get acl dropped packets not to be CPU punted or to use control-plane policing to discard them before they hit the CPU? thanx > > If it's high CPU at IP Input really need 12.4(20)T and get > a sniffer trace in the punt path to see what traffic it really is. > > Rodney > > On Thu, Sep 04, 2008 at 03:46:23PM -0400, Stephen Kratzer wrote: >> On Thursday 04 September 2008 15:12:12 Mateusz B??aszczyk wrote: >>> 2008/9/4 Stephen Kratzer : >>>> The 'log' keyword will cause matching packets to not be CEF switched. >>> >>> nope, log is not present. >>> >>>> Also, if >>>> you're denying a lot of traffic from a certain source, you might want to >>>> just bit-bucket it rather than sending ICMP responses. >>> >>> you mean - "no ip unreachables"? >> >> You could match the access list in a route map and set the outbound interface >> to Null0. >> _______________________________________________ >> 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/ > --------------------------------------------------------------------- It's hard to be nostalgic when you can't remember anything good. Nic Tjirkalli Verizon Business South Africa Network Strategy Team Verizon Business is a brand of Verizon South Africa (Pty) Ltd. This e-mail is strictly confidential and intended only for use by the addressee unless otherwise indicated. Company Information:http:// www.verizonbusiness.com/za/contact/legal/ This e-mail is strictly confidential and intended only for use by the addressee unless otherwise indicated. From serge.devorop at gmail.com Fri Sep 5 10:38:30 2008 From: serge.devorop at gmail.com (Sergey Voropaev) Date: Fri, 5 Sep 2008 18:38:30 +0400 Subject: [c-nsp] free WAN emulation software Message-ID: Hi guys, Could anyone advise free WAN (wide area network) emulator software. I need to find solution for the following reason. We have some network application and we want to know how good this applications work over the WAN with predefined parameters. The better emulator must support operations with more parameters. The main parameters is delay, jitter, throughput, bit errors, packets lost, resequencing etc. I think that this should be server with two NIC and installed soft, so such soft I'm looking for. From MLouis at nwnit.com Fri Sep 5 11:22:40 2008 From: MLouis at nwnit.com (Mike Louis) Date: Fri, 5 Sep 2008 11:22:40 -0400 Subject: [c-nsp] free WAN emulation software In-Reply-To: References: Message-ID: Check out the WAN bridge software on the cisoc waas software download site. Its a live CD. SHould be your best bet. ________________________________________ From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of Sergey Voropaev [serge.devorop at gmail.com] Sent: Friday, September 05, 2008 10:38 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] free WAN emulation software Hi guys, Could anyone advise free WAN (wide area network) emulator software. I need to find solution for the following reason. We have some network application and we want to know how good this applications work over the WAN with predefined parameters. The better emulator must support operations with more parameters. The main parameters is delay, jitter, throughput, bit errors, packets lost, resequencing etc. I think that this should be server with two NIC and installed soft, so such soft I'm looking for. _______________________________________________ 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. From matt at deploylinux.net Fri Sep 5 10:52:42 2008 From: matt at deploylinux.net (Matthew Marlowe) Date: Fri, 5 Sep 2008 07:52:42 -0700 Subject: [c-nsp] Recommended 2800 ISR In-Reply-To: References: <48C08099.6060908@uol.com.br> Message-ID: <006c01c90f67$0d3428a0$279c79e0$@net> Cisco actually is pretty honest about the performance of the routers with most/all security features enabled if you go to the QA section of the product pages and click on router model and look for the question "What is the performance of router XX?". At which point, they'll state that a Cisco 3845 can process a single T3 and that the 28xx's performance is measured in multiples of T-1's (with 2851 being 6xT1 and 2801 being 1xT1). I've done some measuring of 2800/3800 series performance and the statements seem to be born out. If you have the acl's/inspection/ips enabled, a 3845 really will give out around 50Mbps, even though the router is rated with a raw capacity of ~250Mbps. If you just have reasonable acl's and stateful firewall/inspection features, performance seems to double and you might get ~100Mbps on a 3845 imho, I'd think the ratio would be about the same on a 28xx(2851 -> 18Mbps?). Your mileage may vary. The recommendation to look at ASA's is pretty good and would be cheaper. Otherwise, among the ISR's, a 3825 would be the safe bet. Regards, Matt -- Matthew Marlowe matt at deploylinux.net DeployLinux Consulting, Inc Direct: 858-217-5730 Senior Infrastructure Consultant Office: 888-459-0515 Cell: 805-857-9144 Fax: 858-876-1692 YIM:deploylinuxconsulting Designing, Securing, and Maintaining Mission Critical Linux Servers for Successful Internet Applications -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Buhrmaster, Gary Sent: Thursday, September 04, 2008 8:41 PM To: Dan Letkeman; giulianocm at uol.com.br; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Recommended 2800 ISR > I have read that document before, do those numbers (2811 - 61.44mpbs > CEF Fast switching) mean that it can process that bandwidth with > nothing else running on the router? With the wind behind the bits heading downhill. The first paragraph says: Numbers are given with 64 byte packet size, IP only, and are only an indication of raw switching performance. These are testing numbers, usually with FE to FE or POS to POS, no services enabled. As you add ACL's, encryption, compression, etc - performance will decline significantly from the given numbers .... The moment you add (for example) NAT or Firewall features, expect significantly less performance. As always, your Mbps will vary and your situation will be unique (and almost never to your benefit). _______________________________________________ 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 agristina+cisco-nsp at gmail.com Fri Sep 5 12:00:30 2008 From: agristina+cisco-nsp at gmail.com (Andrew Gristina) Date: Fri, 5 Sep 2008 09:00:30 -0700 Subject: [c-nsp] free WAN emulation software In-Reply-To: References: Message-ID: <70bb1b8f0809050900j2adf0cb1ide6f91d6519cf71@mail.gmail.com> The opensource options are dummynet on BSD: http://info.iet.unipi.it/~luigi/ip_dummynet/ Which is good for emulating links 100Mb or slower, I think it needs patches if you are going to emulate long fat pipes. I used the boot floppy, it is easier to use if you have some unix experience. or Nistnet on linux (the traffic shaping stuff is now in kernel). But I find it is old, and that netem is is better in linux- basically the tc commands: http://www.linuxfoundation.org/en/Net:Netem On Fri, Sep 5, 2008 at 7:38 AM, Sergey Voropaev wrote: > Hi guys, > > Could anyone advise free WAN (wide area network) emulator software. I > need to find solution for the following reason. We have some network > application and we want to know how good this applications work over > the WAN with predefined parameters. The better emulator must support > operations with more parameters. The main parameters is delay, jitter, > throughput, bit errors, packets lost, resequencing etc. > > I think that this should be server with two NIC and installed soft, so > such soft I'm looking for. > _______________________________________________ > 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 gert at greenie.muc.de Fri Sep 5 12:13:20 2008 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 5 Sep 2008 18:13:20 +0200 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <844ef89c0809040711w480d9586peaade37cc4054102@mail.gmail.com> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <20080904132355.GA17595@mx.ytti.net> <844ef89c0809040711w480d9586peaade37cc4054102@mail.gmail.com> Message-ID: <20080905161320.GK17238@greenie.muc.de> Hi, On Thu, Sep 04, 2008 at 04:11:06PM +0200, David Granzer wrote: > RSP720 comes with 3C(XL) and SUP720 with 3B(XL). And Sup720-10G (which is nowadays marked as "VSS-something") with 3C(XL) again. Always remember: whatever you expect from the 7600 series: if it's not there at the day of purchasing, and Cisco sales promises you something, don't believe anything. The 7600 BU is not to be trusted. (Plus: expect useful features to suddenly go away). Consider a Juniper M7i or something if all you need is 2 GE ports and the option for WANs. 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: 304 bytes Desc: not available URL: From ecables at gmail.com Fri Sep 5 12:17:03 2008 From: ecables at gmail.com (Eric Cables) Date: Fri, 5 Sep 2008 09:17:03 -0700 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: <0867622C64B50C4B878AB45C95F43F1106150F02@MAILWA01.wesenergy.local> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <014b01c90f22$f60cf9c0$e226ed40$@id.au> <0867622C64B50C4B878AB45C95F43F1106150F02@MAILWA01.wesenergy.local> Message-ID: Zenoss has two versions, Zenoss Community (free) and Zenoss Enterprise (not free). The only notable feature, for network management, I see in Zenoss Enterprise is the RANCID ZenPack. The community version is pretty full featured, and looks very cool (I tested it out for a few days). Unfortunately, it is very robust, which translates to a lot of overhead management to get it running properly. Nagios, in comparison, just "works", and can be setup relatively quickly. Is anyone out there using Zenoss for network monitoring? How do you like it? -- Eric Cables On Fri, Sep 5, 2008 at 1:50 AM, Aaron Riemer wrote: > Zenoss looks cool but it looks like you have to pay for that software :) > > Cheers for the ideas. > > Aaron. > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Daniels - > Lists > Sent: Friday, 5 September 2008 2:45 PM > To: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Dashboard Network Monitoring Software > > Also take a look at Zenoss > www.zenoss.org > > Aaron > >> -----Original Message----- >> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- >> bounces at puck.nether.net] On Behalf Of Daniel Hooper >> Sent: Friday, 5 September 2008 12:55 PM >> To: Aaron Riemer >> Cc: cisco-nsp at puck.nether.net >> Subject: Re: [c-nsp] Dashboard Network Monitoring Software >> >> www.nagios.org >> >> -----Original Message----- >> From: cisco-nsp-bounces at puck.nether.net >> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Riemer >> Sent: Friday, 5 September 2008 9:00 AM >> To: cisco-nsp at puck.nether.net >> Subject: [c-nsp] Dashboard Network Monitoring Software >> >> Hi Guys, >> >> >> >> Is anyone out there using any open source or free dashboard network >> monitoring software? I would like to have a map background with our >> sites and possibly blink the sites RED if the site stopped responding >> to >> pings or SNMP queries etc? I know Solarwinds and HP Openview are good >> but we are not willing to shell out the money just for a dashboard. >> >> >> >> Cheers, >> >> >> >> Aaron. >> >> >> >> >> >> >> >> >> >> >> LEGAL DISCLAIMER: This message contains confidential information and > is >> intended only for the individual named. If you are not the named >> addressee you should not disseminate, distribute or copy this e-mail. >> Please notify the sender immediately by e-mail if you have received >> this >> e-mail by mistake and delete this e-mail from your system. If you are >> not the intended recipient you are notified that disclosing, copying, >> distributing or taking any action in reliance on the contents of this >> information is strictly prohibited. >> _______________________________________________ >> 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/ > > LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. > _______________________________________________ > 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 jml at packetpimp.org Fri Sep 5 12:18:21 2008 From: jml at packetpimp.org (Jason LeBlanc) Date: Fri, 05 Sep 2008 12:18:21 -0400 Subject: [c-nsp] Recommended 2800 ISR In-Reply-To: References: Message-ID: <48C15BCD.6060805@packetpimp.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have two 2811s with a full view on each and partial for ibgp, no issues. Justin M. Streiner wrote: > On Thu, 4 Sep 2008, Dan Letkeman wrote: > >> I was wondering if anyone has recommendations for a 2800 series router >> for a 20-30mbit internet connection. I would like to run a firewall >> IOS and, nat and basic ACL's. Would a 2811 be an appropriate choice? > > If you're not running BGP with full feeds, you *might* be able to get > away with a 2811, given that you're running IOS firewall and NAT as > well, but you probably wouldn't have much headroom for growth, or if you > decide you need additional features in the future (Netflow, QoS, routing > protocols, etc). > > 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/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIwVvNw+p9Y9BHZ8kRAtBBAJ9MVa6OsKlL3fRZ73LrSGjqSMIk3QCghJBz YC6nP2buuoVWQE5H3cUJKjg= =o7vd -----END PGP SIGNATURE----- From tvarriale at comcast.net Fri Sep 5 12:16:00 2008 From: tvarriale at comcast.net (Tony Varriale) Date: Fri, 5 Sep 2008 11:16:00 -0500 Subject: [c-nsp] Recommended 2800 ISR References: <48C08099.6060908@uol.com.br> <006c01c90f67$0d3428a0$279c79e0$@net> Message-ID: <000e01c90f72$b0164e30$f211a8c0@flamadam> I would agree. I've actually found they are a little conversative in their numbers from their concentrators up to the routers. tv ----- Original Message ----- From: "Matthew Marlowe" To: "'Buhrmaster, Gary'" ; "'Dan Letkeman'" ; ; Sent: Friday, September 05, 2008 9:52 AM Subject: Re: [c-nsp] Recommended 2800 ISR > Cisco actually is pretty honest about the performance of the routers with > most/all security features enabled if you go to the QA section of the > product pages and click on router model and look for the question "What is > the performance of router XX?". At which point, they'll state that a > Cisco 3845 can process a single T3 and that the 28xx's performance is > measured in multiples of T-1's (with 2851 being 6xT1 and 2801 being 1xT1). > > I've done some measuring of 2800/3800 series performance and the > statements > seem to be born out. If you have the acl's/inspection/ips enabled, a 3845 > really will give out around 50Mbps, even though the router is rated with a > raw capacity of ~250Mbps. If you just have reasonable acl's and stateful > firewall/inspection features, performance seems to double and you might > get > ~100Mbps on a 3845 imho, I'd think the ratio would be about the same on a > 28xx(2851 -> 18Mbps?). Your mileage may vary. > > The recommendation to look at ASA's is pretty good and would be cheaper. > Otherwise, among the ISR's, a 3825 would be the safe bet. > > Regards, > Matt > -- > Matthew Marlowe matt at deploylinux.net > DeployLinux Consulting, Inc Direct: 858-217-5730 > Senior Infrastructure Consultant Office: 888-459-0515 > Cell: 805-857-9144 Fax: 858-876-1692 YIM:deploylinuxconsulting > > Designing, Securing, and Maintaining Mission Critical Linux Servers > for Successful Internet Applications > > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Buhrmaster, Gary > Sent: Thursday, September 04, 2008 8:41 PM > To: Dan Letkeman; giulianocm at uol.com.br; cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Recommended 2800 ISR > > >> I have read that document before, do those numbers (2811 - 61.44mpbs >> CEF Fast switching) mean that it can process that bandwidth with >> nothing else running on the router? > > With the wind behind the bits heading downhill. > The first paragraph says: > > Numbers are given with 64 byte packet size, IP only, > and are only an indication of raw switching performance. > These are testing numbers, usually with FE to FE or POS > to POS, no services enabled. As you add ACL's, encryption, > compression, etc - performance will decline significantly > from the given numbers .... > > The moment you add (for example) NAT or Firewall features, > expect significantly less performance. As always, your > Mbps will vary and your situation will be unique (and > almost never to your benefit). > _______________________________________________ > 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 paul.cosgrove at heanet.ie Fri Sep 5 12:38:35 2008 From: paul.cosgrove at heanet.ie (Paul Cosgrove) Date: Fri, 05 Sep 2008 17:38:35 +0100 Subject: [c-nsp] disabling 3750 mac address learning In-Reply-To: <20080905.133337.74700578.sthaug@nethelp.no> References: <48C0F619.3090903@heanet.ie> <20080905.133337.74700578.sthaug@nethelp.no> Message-ID: <48C1608B.3000508@heanet.ie> sthaug at nethelp.no wrote: >> Noticed that the 3750 ios 12.2(46)SE release supports the disabling of >> mac address learning per vlan. Does anyone have any experience with >> this release yet? >> >> The feature seems to have been introduced earlier in the 3650s and has >> obviously been in ME switches for a while. > > The feature has been there longer, in the form of an RSPAN-enabled VLAN. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > Thanks Steinar, I think there are a few differences between these. The command docs say the following about RSPAN VLANs: - All traffic in the RSPAN VLAN is always flooded. - No MAC address learning occurs on the RSPAN VLAN. - RSPAN VLAN traffic only flows on trunk ports. - RSPAN VLANs must be configured in VLAN configuration mode by using the remote-span VLAN configuration mode command. - STP can run on RSPAN VLAN trunks but not on SPAN destination ports. - An RSPAN VLAN cannot be a private-VLAN primary or secondary VLAN. The first and third points suggests that for RSPAN VLANs you: - cannot use static mac assignments - cannot use access ports Paul. -- HEAnet Limited Ireland's Education & Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. From Gregori.Parker at theplatform.com Fri Sep 5 12:49:13 2008 From: Gregori.Parker at theplatform.com (Gregori Parker) Date: Fri, 5 Sep 2008 09:49:13 -0700 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local><014b01c90f22$f60cf9c0$e226ed40$@id.au><0867622C64B50C4B878AB45C95F43F1106150F02@MAILWA01.wesenergy.local> Message-ID: <1A9866F953006D45AEE0166066114E091307F95A@TPMAIL02.corp.theplatform.com> We just moved to Zenoss Ent for server monitoring, and I think it was a great move. In my tests however, Zenoss simply didn't cut it for managing/monitoring our network devices - at least not without weeks of template customization. So my search for the ultimate NMS for network devices continues...until then I'll continue to segment NMS responsibilities into various subcategories (fault mgmt, config mgmt, security mgmt, perf mgmt, capacity mgmt, etc) and handle those with a mix of tools. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Eric Cables Sent: Friday, September 05, 2008 9:17 AM To: Aaron Riemer Cc: Aaron Daniels - Lists; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Dashboard Network Monitoring Software Zenoss has two versions, Zenoss Community (free) and Zenoss Enterprise (not free). The only notable feature, for network management, I see in Zenoss Enterprise is the RANCID ZenPack. The community version is pretty full featured, and looks very cool (I tested it out for a few days). Unfortunately, it is very robust, which translates to a lot of overhead management to get it running properly. Nagios, in comparison, just "works", and can be setup relatively quickly. Is anyone out there using Zenoss for network monitoring? How do you like it? -- Eric Cables On Fri, Sep 5, 2008 at 1:50 AM, Aaron Riemer wrote: > Zenoss looks cool but it looks like you have to pay for that software :) > > Cheers for the ideas. > > Aaron. > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Daniels - > Lists > Sent: Friday, 5 September 2008 2:45 PM > To: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Dashboard Network Monitoring Software > > Also take a look at Zenoss > www.zenoss.org > > Aaron > >> -----Original Message----- >> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- >> bounces at puck.nether.net] On Behalf Of Daniel Hooper >> Sent: Friday, 5 September 2008 12:55 PM >> To: Aaron Riemer >> Cc: cisco-nsp at puck.nether.net >> Subject: Re: [c-nsp] Dashboard Network Monitoring Software >> >> www.nagios.org >> >> -----Original Message----- >> From: cisco-nsp-bounces at puck.nether.net >> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Riemer >> Sent: Friday, 5 September 2008 9:00 AM >> To: cisco-nsp at puck.nether.net >> Subject: [c-nsp] Dashboard Network Monitoring Software >> >> Hi Guys, >> >> >> >> Is anyone out there using any open source or free dashboard network >> monitoring software? I would like to have a map background with our >> sites and possibly blink the sites RED if the site stopped responding >> to >> pings or SNMP queries etc? I know Solarwinds and HP Openview are good >> but we are not willing to shell out the money just for a dashboard. >> >> >> >> Cheers, >> >> >> >> Aaron. >> >> >> >> >> >> >> >> >> >> >> LEGAL DISCLAIMER: This message contains confidential information and > is >> intended only for the individual named. If you are not the named >> addressee you should not disseminate, distribute or copy this e-mail. >> Please notify the sender immediately by e-mail if you have received >> this >> e-mail by mistake and delete this e-mail from your system. If you are >> not the intended recipient you are notified that disclosing, copying, >> distributing or taking any action in reliance on the contents of this >> information is strictly prohibited. >> _______________________________________________ >> 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/ > > LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. > _______________________________________________ > 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 lowen at pari.edu Fri Sep 5 12:53:05 2008 From: lowen at pari.edu (Lamar Owen) Date: Fri, 5 Sep 2008 12:53:05 -0400 Subject: [c-nsp] Surge protection on leased lines In-Reply-To: References: Message-ID: <200809051253.05519.lowen@pari.edu> On Thursday 04 September 2008 22:52:41 Ted Mittelstaedt wrote: > They need a sold ground and suppression such as varistors > connected between that ground and both wires of the pair > that the SHDSL line is on. If you can get the specific > code requirements for your municipality you can threaten > to report your national telco to both the FCC and the > local municipality if they do not install surge suppression. [Previous poster] > > Make sure your nid, smartbox, router are all grounded together and to > > the electrical system ground. I suspect they are not if current is > > flowing in and damaging your wic. Make sure also that the grounding electrode for the telco and the grounding electrode for the electrical are properly and effectively bonded (as in the NEC Article 250 definition). I've seen numerous instances of 'properly' installed and connected lightning arrestors that were not properly bonded to the electrical service ground; if the electrodes are even a few feet apart they can, in the lightning field/current gradient of a strike, easily have 15-50 thousand volts between 'grounds'. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 http://www.pari.edu From ecables at gmail.com Fri Sep 5 12:58:37 2008 From: ecables at gmail.com (Eric Cables) Date: Fri, 5 Sep 2008 09:58:37 -0700 Subject: [c-nsp] FWSM failover transparent mode In-Reply-To: <2F7B70885960AA42BE820036B3A8CDA02AC25B@xmail06.ad.ua.ac.be> References: <2F7B70885960AA42BE820036B3A8CDA02AC25B@xmail06.ad.ua.ac.be> Message-ID: Not to hijack this thread, but what modules are you using for server connectivity in your 6513? We deployed some 6513s as SF switches long ago (bad decision), and are now swapping them out with the 6509-E chassis due to the need for additional performance (6748s in all slots). -- Eric Cables On Fri, Sep 5, 2008 at 1:35 AM, Holemans Wim wrote: > Just upgraded our FWSM to version 3.1.11 after 3 random crashes in a > month. Now we are thinking about buying a second FWSM to do failover in > order to limit downtime and facilitate upgrades : most of our servers > are connected to the 6513 carrying this FWSM. > > We use the 2 standard virtual contexts of the FWSM, both in transparent > mode, 8 bridged vlans on one, 2 bridged vlans on the second. > > > > In the release notes of 3.1.11 I however read under Open Caveats > > "CSCm73157 : Failover is not working in transparent mode..." > > > > Anyone has experience with FWSM failover in transparent mode ? Does this > really doesn't work ? > > Does it work under 3.2 or 4.0 ? > > > > Any info would be appreciated before we invest more than 15K Euros... > > > > Wim Holemans > > Netwerkdienst Universiteit Antwerpen > > > > _______________________________________________ > 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 Fri Sep 5 13:22:19 2008 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Fri, 5 Sep 2008 18:22:19 +0100 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <014b01c90f22$f60cf9c0$e226ed40$@id.au> <0867622C64B50C4B878AB45C95F43F1106150F02@MAILWA01.wesenergy.local> Message-ID: <20080905172219.GB14050@lboro.ac.uk> Hi, > Is anyone out there using Zenoss for network monitoring? How do you like it? I worry that I find myself spending too long trying to get a huge variety of monitoring systems actually working - and then configured to work properly and 'look nice' or be usable by our local community (eg using AD authentication instead of a noddy local pwd file or database password system like so many want...) i feel that I am not alone in missing out on a really cool piece of software simply because of being burnt by so many other tools. - we still run some of the older hardy tools that many would recommend - NAGIOS, NetDISCO, Rancid, MRTG, RTG, + a couple of other random bits. these recent discussions are quite informative but without a nice resource or concensus I feel that many useful ones might get lost in the melee etc. I'm also after somethign that has the fancy gfx that mgmt like eg solarwinds console - but without the price tag - AND with some actually useful stuff under the hood - any further recommendations? alan From sthaug at nethelp.no Fri Sep 5 13:22:50 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 05 Sep 2008 19:22:50 +0200 (CEST) Subject: [c-nsp] disabling 3750 mac address learning In-Reply-To: <48C1608B.3000508@heanet.ie> References: <48C0F619.3090903@heanet.ie> <20080905.133337.74700578.sthaug@nethelp.no> <48C1608B.3000508@heanet.ie> Message-ID: <20080905.192250.74733578.sthaug@nethelp.no> > I think there are a few differences between these. The command docs say > the following about RSPAN VLANs: > - All traffic in the RSPAN VLAN is always flooded. > - No MAC address learning occurs on the RSPAN VLAN. > - RSPAN VLAN traffic only flows on trunk ports. > - RSPAN VLANs must be configured in VLAN configuration mode by using the > remote-span VLAN configuration mode command. > - STP can run on RSPAN VLAN trunks but not on SPAN destination ports. > - An RSPAN VLAN cannot be a private-VLAN primary or secondary VLAN. Absolutely - the commands are not equivalent. What I was trying to say was that the technical ability to disable MAC address learning has existed for a while. I am glad that it can now done explicitly instead of being "hidden away" in the form of RSPAN. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From razor at meganet.net Fri Sep 5 12:36:33 2008 From: razor at meganet.net (Paul A) Date: Fri, 5 Sep 2008 12:36:33 -0400 Subject: [c-nsp] can't ping from router Message-ID: <012001c90f75$8e65db40$ab3191c0$@net> Hi, I have a 7200 terminating some pppoe customers using BBA-GROUP. Everything is working and has been working without any issues. However digging around I came across a weird problem. It seems that from the 7200 terminating router I can't ping any of the pppoe user's ip addresses but I can from outside the 7200. I'm using a BBA-GROUP that references Virtual-Template 1, the weird part is everything is working but my virtual-template shows that its down. stingray-capedsl-gw#sh int virtual-template 1 Virtual-Template1 is down, line protocol is down Should this interface not be showing as up/up? And is this the reason my I can't seem to ping from within the 7200. Thanks P. bba-group pppoe pppoeusers virtual-template 1 service profile pppoeusers sessions per-mac limit 1 sessions auto cleanup interface Virtual-Template1 description xxxx mtu 1492 ip unnumbered Loopback0 no ip redirects no ip unreachables peer default ip address pool pppoeuserspool ppp authentication pap pppoeusers ppp authorization pppoeusers ppp ipcp dns xxxx ppp ipcp address required ppp ipcp address unique interface Loopback0 no ip address no ip redirects no ip unreachables ip local pool pppoeuserspool xxxx.2 xxxx.254 From moua0100 at umn.edu Fri Sep 5 13:37:35 2008 From: moua0100 at umn.edu (Ge Moua) Date: Fri, 5 Sep 2008 12:37:35 -0500 Subject: [c-nsp] FWSM failover transparent mode In-Reply-To: References: <2F7B70885960AA42BE820036B3A8CDA02AC25B@xmail06.ad.ua.ac.be> Message-ID: <032001c90f7e$15948280$31dd5ea0@ad.umn.edu> We experienced the reboots too; there is also bugs in this revision code train for ethertype ACLs. We migrated to 3.2(4) & all is fixed. Regards, Ge Moua | Email: moua0100 at umn.edu Network Design Engineer University of Minnesota | Networking & Telecommunications Services -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Eric Cables Sent: Friday, September 05, 2008 11:59 AM To: Holemans Wim Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] FWSM failover transparent mode Not to hijack this thread, but what modules are you using for server connectivity in your 6513? We deployed some 6513s as SF switches long ago (bad decision), and are now swapping them out with the 6509-E chassis due to the need for additional performance (6748s in all slots). -- Eric Cables On Fri, Sep 5, 2008 at 1:35 AM, Holemans Wim wrote: > Just upgraded our FWSM to version 3.1.11 after 3 random crashes in a > month. Now we are thinking about buying a second FWSM to do failover > in order to limit downtime and facilitate upgrades : most of our > servers are connected to the 6513 carrying this FWSM. > > We use the 2 standard virtual contexts of the FWSM, both in > transparent mode, 8 bridged vlans on one, 2 bridged vlans on the second. > > > > In the release notes of 3.1.11 I however read under Open Caveats > > "CSCm73157 : Failover is not working in transparent mode..." > > > > Anyone has experience with FWSM failover in transparent mode ? Does > this really doesn't work ? > > Does it work under 3.2 or 4.0 ? > > > > Any info would be appreciated before we invest more than 15K Euros... > > > > Wim Holemans > > Netwerkdienst Universiteit Antwerpen > > > > _______________________________________________ > 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 wim.holemans at ua.ac.be Fri Sep 5 13:50:02 2008 From: wim.holemans at ua.ac.be (Holemans Wim) Date: Fri, 5 Sep 2008 19:50:02 +0200 Subject: [c-nsp] FWSM failover transparent mode References: <2F7B70885960AA42BE820036B3A8CDA02AC25B@xmail06.ad.ua.ac.be> Message-ID: <2F7B70885960AA42BE820036B3A8CDA02AC280@xmail06.ad.ua.ac.be> 48 port 10/100/1000mb EtherModule WS-X6148-GE-TX Bought them without knowing about the 8port 1Gig limit ; We plan to replace this construction next year with a VSS solution, type of 65XX not yet chosen. Wim Holemans -----Original Message----- From: Eric Cables [mailto:ecables at gmail.com] Sent: vrijdag 5 september 2008 18:59 To: Holemans Wim Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] FWSM failover transparent mode Not to hijack this thread, but what modules are you using for server connectivity in your 6513? We deployed some 6513s as SF switches long ago (bad decision), and are now swapping them out with the 6509-E chassis due to the need for additional performance (6748s in all slots). -- Eric Cables On Fri, Sep 5, 2008 at 1:35 AM, Holemans Wim wrote: > Just upgraded our FWSM to version 3.1.11 after 3 random crashes in a > month. Now we are thinking about buying a second FWSM to do failover in > order to limit downtime and facilitate upgrades : most of our servers > are connected to the 6513 carrying this FWSM. > > We use the 2 standard virtual contexts of the FWSM, both in transparent > mode, 8 bridged vlans on one, 2 bridged vlans on the second. > > > > In the release notes of 3.1.11 I however read under Open Caveats > > "CSCm73157 : Failover is not working in transparent mode..." > > > > Anyone has experience with FWSM failover in transparent mode ? Does this > really doesn't work ? > > Does it work under 3.2 or 4.0 ? > > > > Any info would be appreciated before we invest more than 15K Euros... > > > > Wim Holemans > > Netwerkdienst Universiteit Antwerpen > > > > _______________________________________________ > 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 jim at tgasolutions.com Fri Sep 5 13:54:07 2008 From: jim at tgasolutions.com (Jim McBurnett) Date: Fri, 5 Sep 2008 13:54:07 -0400 Subject: [c-nsp] latest stable... In-Reply-To: <20080904062352.GQ233@greenie.muc.de> References: <20080904062352.GQ233@greenie.muc.de> Message-ID: Great... For the G1-- all we need is BGP and Ethernet-- Nothing special.. Metro E fiber inbound and FIBER out... Thanks, Jim -----Original Message----- From: Gert Doering [mailto:gert at greenie.muc.de] Sent: Thursday, September 04, 2008 2:24 AM To: Jim McBurnett Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] latest stable... Hi, On Thu, Sep 04, 2008 at 12:05:22AM -0400, Jim McBurnett wrote: > Now for the question-with these 2 bugs, and the other 389 BGP relate bugs on this release-what are all of you having the best success on for a sup 720 on a 7606? I'd go for SXF14. > How about an NPE-G1 on a 7206? Depending on your feature requirements - 12.3 main or 12.2SB. 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 r.engehausen at gmail.com Fri Sep 5 14:18:16 2008 From: r.engehausen at gmail.com (Roy) Date: Fri, 05 Sep 2008 11:18:16 -0700 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: <20080905172219.GB14050@lboro.ac.uk> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <014b01c90f22$f60cf9c0$e226ed40$@id.au> <0867622C64B50C4B878AB45C95F43F1106150F02@MAILWA01.wesenergy.local> <20080905172219.GB14050@lboro.ac.uk> Message-ID: <48C177E8.4070105@gmail.com> A.L.M.Buxey at lboro.ac.uk wrote: > Hi, > > >> Is anyone out there using Zenoss for network monitoring? How do you like it? >> > > I worry that I find myself spending too long trying to get > a huge variety of monitoring systems actually working - and > then configured to work properly and 'look nice' or be usable > by our local community (eg using AD authentication instead > of a noddy local pwd file or database password system like > so many want...) i feel that I am not alone in missing out > on a really cool piece of software simply because of being > burnt by so many other tools. - we still run some of the older > hardy tools that many would recommend - NAGIOS, NetDISCO, > Rancid, MRTG, RTG, + a couple of other random bits. > > these recent discussions are quite informative but without > a nice resource or concensus I feel that many useful ones > might get lost in the melee etc. > > I'm also after somethign that has the fancy gfx that mgmt like > eg solarwinds console - but without the price tag - AND with some > actually useful stuff under the hood - any further recommendations? > > alan > Opsview (http://www.opsview.org) From rodunn at cisco.com Fri Sep 5 14:42:03 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Fri, 5 Sep 2008 14:42:03 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> Message-ID: <20080905184202.GD20054@rtp-cse-489.cisco.com> On Fri, Sep 05, 2008 at 04:36:08PM +0200, Nic Tjirkalli wrote: > howdy ho, > > >But make sure you do: > > > >config t > >int null 0 > >no ip unreachables > > > >The ACL drops are, last I checked, rate limit punts. > this is interesting - there is a good article detailing cef and CPU > punting at :- > http://searchnetworkingchannel.techtarget.com/generic/0,295582,sid100_gci1261924,00.html > > > > Reading that and this posting begs the question > - if there is a lrage amount of ACL drops and these packets are punted to > cPU and the CPU rate-limit for punted packets has been exceeded, then > possible packets that need to be CPU processed will be dropped in favour > of ACL denied packets That's not true. The packets are dropped under interrupt that match the ACL deny other than punting some to generate the unreachable. You will always deny them. - this seems a bit ridiculous. > > Any way to get acl dropped packets not to be CPU punted or to use > control-plane policing to discard them before they hit the CPU? > > thanx > > > > > >If it's high CPU at IP Input really need 12.4(20)T and get > >a sniffer trace in the punt path to see what traffic it really is. > > > >Rodney > > > >On Thu, Sep 04, 2008 at 03:46:23PM -0400, Stephen Kratzer wrote: > >>On Thursday 04 September 2008 15:12:12 Mateusz B??aszczyk wrote: > >>>2008/9/4 Stephen Kratzer : > >>>>The 'log' keyword will cause matching packets to not be CEF switched. > >>> > >>>nope, log is not present. > >>> > >>>>Also, if > >>>>you're denying a lot of traffic from a certain source, you might want to > >>>>just bit-bucket it rather than sending ICMP responses. > >>> > >>>you mean - "no ip unreachables"? > >> > >>You could match the access list in a route map and set the outbound > >>interface > >>to Null0. > >>_______________________________________________ > >>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/ > > > > > --------------------------------------------------------------------- > It's hard to be nostalgic when you can't remember anything good. > > Nic Tjirkalli > Verizon Business South Africa > Network Strategy Team > > Verizon Business is a brand of Verizon South Africa (Pty) Ltd. This e-mail > is strictly confidential and intended only for use by the addressee unless > otherwise indicated. > > Company Information:http:// www.verizonbusiness.com/za/contact/legal/ > > This e-mail is strictly confidential and intended only for use by the > addressee unless otherwise indicated. From tvarriale at comcast.net Fri Sep 5 14:57:56 2008 From: tvarriale at comcast.net (Tony Varriale) Date: Fri, 5 Sep 2008 13:57:56 -0500 Subject: [c-nsp] FWSM failover transparent mode References: <2F7B70885960AA42BE820036B3A8CDA02AC25B@xmail06.ad.ua.ac.be> Message-ID: <001601c90f89$4f29b780$f211a8c0@flamadam> 6748s here. The customer was considering VSS but it didn't/doesn't support FWSM and ACE. So, he's stuck for a bit. tv ----- Original Message ----- From: "Eric Cables" To: "Holemans Wim" Cc: Sent: Friday, September 05, 2008 11:58 AM Subject: Re: [c-nsp] FWSM failover transparent mode > Not to hijack this thread, but what modules are you using for server > connectivity in your 6513? We deployed some 6513s as SF switches long > ago (bad decision), and are now swapping them out with the 6509-E > chassis due to the need for additional performance (6748s in all > slots). > > -- > Eric Cables > > > > On Fri, Sep 5, 2008 at 1:35 AM, Holemans Wim > wrote: >> Just upgraded our FWSM to version 3.1.11 after 3 random crashes in a >> month. Now we are thinking about buying a second FWSM to do failover in >> order to limit downtime and facilitate upgrades : most of our servers >> are connected to the 6513 carrying this FWSM. >> >> We use the 2 standard virtual contexts of the FWSM, both in transparent >> mode, 8 bridged vlans on one, 2 bridged vlans on the second. >> >> >> >> In the release notes of 3.1.11 I however read under Open Caveats >> >> "CSCm73157 : Failover is not working in transparent mode..." >> >> >> >> Anyone has experience with FWSM failover in transparent mode ? Does this >> really doesn't work ? >> >> Does it work under 3.2 or 4.0 ? >> >> >> >> Any info would be appreciated before we invest more than 15K Euros... >> >> >> >> Wim Holemans >> >> Netwerkdienst Universiteit Antwerpen >> >> >> >> _______________________________________________ >> 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 jcartier at acs.on.ca Fri Sep 5 15:15:11 2008 From: jcartier at acs.on.ca (Jeff Cartier) Date: Fri, 5 Sep 2008 15:15:11 -0400 Subject: [c-nsp] Service-Policy on 1800 SVI Message-ID: Hey Everyone, I'm running into an issue on a 1841 router where I have an internet feed coming into one of the integrated switchports....I have the vlan that the switchport is configured in as a EtherSVI with a public IP address. I need to configure a policy-map with QoS but it appears you cannot configure a service-policy on a EtherSVI...Is this correct? After finding that heartbreaker out I then tried applying the service-policy to the switchport...it takes, but of course doesn't show any matches and rates using 'show policy-map interface Fa0/9'. So my question would be...how do I configure QoS on a 1841 Router when my interface is a EtherSVI? Sincerely, Jeff From christian at broknrobot.com Fri Sep 5 15:45:50 2008 From: christian at broknrobot.com (Christian Koch) Date: Fri, 5 Sep 2008 15:45:50 -0400 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> Message-ID: you can also try a weather map like below... http://www.network-weathermap.com/ http://netmon.grnet.gr/weathermap/#docs On Thu, Sep 4, 2008 at 9:00 PM, Aaron Riemer wrote: > Hi Guys, > > > > Is anyone out there using any open source or free dashboard network > monitoring software? I would like to have a map background with our > sites and possibly blink the sites RED if the site stopped responding to > pings or SNMP queries etc? I know Solarwinds and HP Openview are good > but we are not willing to shell out the money just for a dashboard. > > > > Cheers, > > > > Aaron. > > > > > > > > > > > LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. > _______________________________________________ > 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 kratzers at pa.net Fri Sep 5 15:47:09 2008 From: kratzers at pa.net (Stephen Kratzer) Date: Fri, 5 Sep 2008 15:47:09 -0400 Subject: [c-nsp] can't ping from router In-Reply-To: <012001c90f75$8e65db40$ab3191c0$@net> References: <012001c90f75$8e65db40$ab3191c0$@net> Message-ID: <200809051547.09702.kratzers@pa.net> On Friday 05 September 2008 12:36:33 Paul A wrote: > Hi, I have a 7200 terminating some pppoe customers using BBA-GROUP. > Everything is working and has been working without any issues. However > digging around I came across a weird problem. It seems that from the 7200 > terminating router I can't ping any of the pppoe user's ip addresses but I > can from outside the 7200. > > I'm using a BBA-GROUP that references Virtual-Template 1, the weird part is > everything is working but my virtual-template shows that its down. > > stingray-capedsl-gw#sh int virtual-template 1 > Virtual-Template1 is down, line protocol is down > > Should this interface not be showing as up/up? And is this the reason my I > can't seem to ping from within the 7200. > > Thanks P. > > > bba-group pppoe pppoeusers > virtual-template 1 > service profile pppoeusers > sessions per-mac limit 1 > sessions auto cleanup > > > interface Virtual-Template1 > description xxxx > mtu 1492 > ip unnumbered Loopback0 > no ip redirects > no ip unreachables > peer default ip address pool pppoeuserspool > ppp authentication pap pppoeusers > ppp authorization pppoeusers > ppp ipcp dns xxxx > ppp ipcp address required > ppp ipcp address unique > > interface Loopback0 > no ip address > no ip redirects > no ip unreachables > > ip local pool pppoeuserspool xxxx.2 xxxx.254 > > _______________________________________________ > 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/ The Virtual-Template interface should be down/down. Since it's not a real interface, and it's not associated with a real interface with a real status, it won't have L1/L2 statuses. Maybe try sourcing the pings from Loop0. From pdavis at i2k.com Fri Sep 5 15:05:15 2008 From: pdavis at i2k.com (Phil Davis) Date: Fri, 05 Sep 2008 15:05:15 -0400 Subject: [c-nsp] can't ping from router In-Reply-To: <012001c90f75$8e65db40$ab3191c0$@net> References: <012001c90f75$8e65db40$ab3191c0$@net> Message-ID: <48C182EB.6030201@i2k.com> Hello, Paul A wrote: > Hi, I have a 7200 terminating some pppoe customers using BBA-GROUP. > Everything is working and has been working without any issues. However > digging around I came across a weird problem. It seems that from the 7200 > terminating router I can't ping any of the pppoe user's ip addresses but I > can from outside the 7200. > > I'm using a BBA-GROUP that references Virtual-Template 1, the weird part is > everything is working but my virtual-template shows that its down. > > stingray-capedsl-gw#sh int virtual-template 1 > Virtual-Template1 is down, line protocol is down > > Should this interface not be showing as up/up? And is this the reason my I > can't seem to ping from within the 7200. > > Thanks P. > > > bba-group pppoe pppoeusers > virtual-template 1 > service profile pppoeusers > sessions per-mac limit 1 > sessions auto cleanup > > > interface Virtual-Template1 > description xxxx > mtu 1492 > ip unnumbered Loopback0 > no ip redirects > no ip unreachables > peer default ip address pool pppoeuserspool > ppp authentication pap pppoeusers > ppp authorization pppoeusers > ppp ipcp dns xxxx > ppp ipcp address required > ppp ipcp address unique > > interface Loopback0 > no ip address > no ip redirects > no ip unreachables > > ip local pool pppoeuserspool xxxx.2 xxxx.254 > > _______________________________________________ > 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/ > You've defined a helper interface for the Virtual-Template, but that interface does not have an IP address, so it's trying to send pings from an unnumbered address. If you put an address on Loopback0, pings will work. Phil From razor at meganet.net Fri Sep 5 16:05:50 2008 From: razor at meganet.net (Paul A) Date: Fri, 5 Sep 2008 16:05:50 -0400 Subject: [c-nsp] can't ping from router In-Reply-To: <200809051547.09702.kratzers@pa.net> References: <012001c90f75$8e65db40$ab3191c0$@net> <200809051547.09702.kratzers@pa.net> Message-ID: <017901c90f92$cb2d3830$6187a890$@net> Gotcha, I guess the interface showing down/down was weird to me because I have used other virtual-templates that were always up, but looking back its because they were ip unnumbered from a real interface this L1/L2 stats. As for the pings I sourced them from multiple ips/interfaces and I still get no replies from within the router which is just weird maybe it's the version of IOS im using? Version 12.4(10)FC1 Paul -----Original Message----- From: Stephen Kratzer [mailto:kratzers at pa.net] Sent: Friday, September 05, 2008 3:47 PM To: cisco-nsp at puck.nether.net Cc: Paul A Subject: Re: [c-nsp] can't ping from router On Friday 05 September 2008 12:36:33 Paul A wrote: > Hi, I have a 7200 terminating some pppoe customers using BBA-GROUP. > Everything is working and has been working without any issues. However > digging around I came across a weird problem. It seems that from the 7200 > terminating router I can't ping any of the pppoe user's ip addresses but I > can from outside the 7200. > > I'm using a BBA-GROUP that references Virtual-Template 1, the weird part is > everything is working but my virtual-template shows that its down. > > stingray-capedsl-gw#sh int virtual-template 1 > Virtual-Template1 is down, line protocol is down > > Should this interface not be showing as up/up? And is this the reason my I > can't seem to ping from within the 7200. > > Thanks P. > > > bba-group pppoe pppoeusers > virtual-template 1 > service profile pppoeusers > sessions per-mac limit 1 > sessions auto cleanup > > > interface Virtual-Template1 > description xxxx > mtu 1492 > ip unnumbered Loopback0 > no ip redirects > no ip unreachables > peer default ip address pool pppoeuserspool > ppp authentication pap pppoeusers > ppp authorization pppoeusers > ppp ipcp dns xxxx > ppp ipcp address required > ppp ipcp address unique > > interface Loopback0 > no ip address > no ip redirects > no ip unreachables > > ip local pool pppoeuserspool xxxx.2 xxxx.254 > > _______________________________________________ > 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/ The Virtual-Template interface should be down/down. Since it's not a real interface, and it's not associated with a real interface with a real status, it won't have L1/L2 statuses. Maybe try sourcing the pings from Loop0. No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.6.16/1651 - Release Date: 9/4/2008 6:57 AM From razor at meganet.net Fri Sep 5 16:59:17 2008 From: razor at meganet.net (Paul A) Date: Fri, 5 Sep 2008 16:59:17 -0400 Subject: [c-nsp] can't ping from router In-Reply-To: <48C182EB.6030201@i2k.com> References: <012001c90f75$8e65db40$ab3191c0$@net> <48C182EB.6030201@i2k.com> Message-ID: <019c01c90f9a$42addac0$c8099040$@net> Phil, I was thinking that might be the issue and once I assigned an ip it worked and now I can ping. I was testing from a source interface that was up with an ip and wasn't getting replies but that's because it was sending replies to the helper interface. Thanks for pointing that out to me. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Phil Davis Sent: Friday, September 05, 2008 3:05 PM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] can't ping from router Hello, Paul A wrote: > Hi, I have a 7200 terminating some pppoe customers using BBA-GROUP. > Everything is working and has been working without any issues. However > digging around I came across a weird problem. It seems that from the 7200 > terminating router I can't ping any of the pppoe user's ip addresses but I > can from outside the 7200. > > I'm using a BBA-GROUP that references Virtual-Template 1, the weird part is > everything is working but my virtual-template shows that its down. > > stingray-capedsl-gw#sh int virtual-template 1 > Virtual-Template1 is down, line protocol is down > > Should this interface not be showing as up/up? And is this the reason my I > can't seem to ping from within the 7200. > > Thanks P. > > > bba-group pppoe pppoeusers > virtual-template 1 > service profile pppoeusers > sessions per-mac limit 1 > sessions auto cleanup > > > interface Virtual-Template1 > description xxxx > mtu 1492 > ip unnumbered Loopback0 > no ip redirects > no ip unreachables > peer default ip address pool pppoeuserspool > ppp authentication pap pppoeusers > ppp authorization pppoeusers > ppp ipcp dns xxxx > ppp ipcp address required > ppp ipcp address unique > > interface Loopback0 > no ip address > no ip redirects > no ip unreachables > > ip local pool pppoeuserspool xxxx.2 xxxx.254 > > _______________________________________________ > 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/ > You've defined a helper interface for the Virtual-Template, but that interface does not have an IP address, so it's trying to send pings from an unnumbered address. If you put an address on Loopback0, pings will work. Phil _______________________________________________ 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 - http://www.avg.com Version: 8.0.169 / Virus Database: 270.6.16/1651 - Release Date: 9/4/2008 6:57 AM From lowen at pari.edu Fri Sep 5 17:14:54 2008 From: lowen at pari.edu (Lamar Owen) Date: Fri, 5 Sep 2008 17:14:54 -0400 Subject: [c-nsp] Bridging over GRE tunnels. Message-ID: <200809051714.55143.lowen@pari.edu> Good afternoon. After lots of searching, I found that bridging over GRE tunnels is configurable, but unsupported. (yes, really: +++++++++ cr1-5509-rsfc-1(config)#bridge 1 protocol ieee cr1-5509-rsfc-1(config)#int tu0 cr1-5509-rsfc-1(config-if)#bridge-group 1 1d04h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down % This command is an unreleased and unsupported feature cr1-5509-rsfc-1(config-if)# 1d04h: Note: A random Spanning Tree Bridge Identifier address of 0000.0c92.7210 has been chosen for Bridge Group 1 since there is no mac address associated with the selected interface. 1d04h: Ensure that this address is unique. cr1-5509-rsfc-1(config-if)# +++++++++ Anyone here have experience with this? RSFC in a Catalyst 5509, IOS 12.1 (that's the only IOS on RSFC's). Anyone have comments on stability found or not found? If this works, it means the RSFC's in my 5500's have just gained a new lease on life. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 http://www.pari.edu From gert at greenie.muc.de Fri Sep 5 18:01:53 2008 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 6 Sep 2008 00:01:53 +0200 Subject: [c-nsp] latest stable... In-Reply-To: References: <20080904062352.GQ233@greenie.muc.de> Message-ID: <20080905220153.GL17238@greenie.muc.de> Hi, On Fri, Sep 05, 2008 at 01:54:07PM -0400, Jim McBurnett wrote: > Great... > For the G1-- all we need is BGP and Ethernet-- Nothing special.. > Metro E fiber inbound and FIBER out... I'd go for 12.3(latest) main line. 12.2S/SB/SR will have lots more nice features, as will have 12.4/12.4T, but those usually bring some drawbacks regarding stability. 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: 304 bytes Desc: not available URL: From dudepron at gmail.com Fri Sep 5 18:12:27 2008 From: dudepron at gmail.com (Aaron) Date: Fri, 5 Sep 2008 18:12:27 -0400 Subject: [c-nsp] latest stable... In-Reply-To: <20080905220153.GL17238@greenie.muc.de> References: <20080904062352.GQ233@greenie.muc.de> <20080905220153.GL17238@greenie.muc.de> Message-ID: <480dad640809051512y7b24e62bjf62c75fcba763421@mail.gmail.com> for the 7200 with just bgp why not use 12.0S? On Fri, Sep 5, 2008 at 6:01 PM, Gert Doering wrote: > Hi, > > On Fri, Sep 05, 2008 at 01:54:07PM -0400, Jim McBurnett wrote: > > Great... > > For the G1-- all we need is BGP and Ethernet-- Nothing special.. > > Metro E fiber inbound and FIBER out... > > I'd go for 12.3(latest) main line. 12.2S/SB/SR will have lots more nice > features, as will have 12.4/12.4T, but those usually bring some drawbacks > regarding stability. > > 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 > > _______________________________________________ > 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 arla at rn.dk Fri Sep 5 18:50:25 2008 From: arla at rn.dk (Arne Larsen / Region Nordjylland) Date: Sat, 6 Sep 2008 00:50:25 +0200 Subject: [c-nsp] problem with VPN3002 hardware client Message-ID: <8D68760F464FFD40A01BF2FB374E4A28869444B50D@SRVEXC02.aas.its.nja.dk> Hi All. I?m I just out of luck or is there something pulling my legs. I?ve got 3 vpn3002 hardware clients, and I can?t change the password off the user on any of them. Or rather they won?t save the password for the user right. When I set them up for they connect fine and all works well, I can reboot them this works also. But if I?m pulling the power, it looses the password for the user and only that. I?ve tried to upgrade and downgrade the software whit out any luck. Is there a hidden switch or configuration function that can protect this, or I?m I just looking at 3 that has a defect in nvram. /Arne From sethm at rollernet.us Fri Sep 5 19:07:30 2008 From: sethm at rollernet.us (sethm at rollernet.us) Date: Fri, 5 Sep 2008 16:07:30 -0700 (PDT) Subject: [c-nsp] IPv6 on the 877W Message-ID: I just went back and forth with TAC regarding IPv6 support on an 877W. Ultimately, the problem was that there isn't any support for IPv6 IRB, and IRB is the only way to put the wireless radio on the same segment as the ethernet ports. Boo. I found a bug id in the c-nsp archives (CSCej50923) about this from 2005, and I was told it was closed without a fix. Also of note, I turned the 877W into a brick by doing the following (in order): * Assign IPv6 address to int vlan 1 * do "no bridge-group 1" on int vlan 1 * IPv6 works! no IPv4, though * do "bridge-group 1" on int vlan 1 * ipv6 and ipv4 work! however... * router locks up after a bit, then never boots again after a power cycle Seems IPv6 is pretty buggy (and lacking) on this thing. ~Seth From ben.steele at internode.on.net Fri Sep 5 20:41:33 2008 From: ben.steele at internode.on.net (Ben Steele) Date: Sat, 6 Sep 2008 10:11:33 +0930 Subject: [c-nsp] WebVPN via RADIUS - how to identify by group? In-Reply-To: <48C124DA.5020408@harvard.edu> References: <00d001c90f22$c6f0e2f0$54d2a8d0$@steele@internode.on.net> <48C124DA.5020408@harvard.edu> Message-ID: <002901c90fb9$500e4a50$f02adef0$@steele@internode.on.net> Problem with the group selection method is via a debug radius I don't see it send any attribute about the group to RADIUS(I did try this way at first) and therefore I can't get RADIUS to match on a group as well as user/pass, the username at realm might be an option, have you tried this before by sending back a group attribute to the ASA from RADIUS and it actually acknowledging it and putting the WEBVPN user into that group?. Cheers Ben -----Original Message----- From: LaPorte, David [mailto:david_laporte at harvard.edu] Sent: Friday, 5 September 2008 9:54 PM To: Ben Steele Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] WebVPN via RADIUS - how to identify by group? You could pass the group as a realm to the RADIUS server by having the users log in as USER at GROUP. The RADIUS server could authenticate them and return a Class="OU=GROUP;" attribute to map them properly. You could also provide a group list to the user: http://www.cisco.com/en/US/products/ps6120/products_configuration_example091 86a00808bd83d.shtml I prefer not to do this since it could make enumeration attacks a bit easier, but it has it's place. hope that helps, Dave Ben Steele wrote: > Howdy all, > > > > Anyone know if it's possible to get as ASA to spit out the group name in an > av-pair via radius when authenticating a user? (in this case webvpn). > > > > The issue i'm having is multiple clients on the one ASA authenticating via > IAS/AD and the possibility of overlapping usernames between clients(groups), > I need another identifier from the ASA to auth them against other than > user/pass, ie group would be perfect. > > > > Any ideas? > > > > Cheers > > > > Ben > > > > > > _______________________________________________ > 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/ -- David LaPorte, CISSP, CCNP Security Manager, Network and Server Systems Harvard University Information Systems ----------------------------------------------- Email: david_laporte at harvard.edu PGP: 0x4DC3E508 4A1F058DB2B32FEF10A14F6BD370A6AD4DC3E508 From lists at daniels.id.au Fri Sep 5 22:12:56 2008 From: lists at daniels.id.au (Aaron Daniels - Lists) Date: Sat, 6 Sep 2008 12:12:56 +1000 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: <0867622C64B50C4B878AB45C95F43F1106150F02@MAILWA01.wesenergy.local> References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <014b01c90f22$f60cf9c0$e226ed40$@id.au> <0867622C64B50C4B878AB45C95F43F1106150F02@MAILWA01.wesenergy.local> Message-ID: <00bd01c90fc6$18a8b2a0$49fa17e0$@id.au> Zenoss is open source. But you are able to purchase a support contract if your organisation requires that kind of thing (ours does) Thanks, Aaron > -----Original Message----- > From: Aaron Riemer [mailto:ariemer at wesenergy.com.au] > Sent: Friday, 5 September 2008 6:50 PM > To: Aaron Daniels - Lists; cisco-nsp at puck.nether.net > Subject: RE: [c-nsp] Dashboard Network Monitoring Software > > Zenoss looks cool but it looks like you have to pay for that software > :) > > Cheers for the ideas. > > Aaron. > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Daniels - > Lists > Sent: Friday, 5 September 2008 2:45 PM > To: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Dashboard Network Monitoring Software > > Also take a look at Zenoss > www.zenoss.org > > Aaron > > > -----Original Message----- > > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > > bounces at puck.nether.net] On Behalf Of Daniel Hooper > > Sent: Friday, 5 September 2008 12:55 PM > > To: Aaron Riemer > > Cc: cisco-nsp at puck.nether.net > > Subject: Re: [c-nsp] Dashboard Network Monitoring Software > > > > www.nagios.org > > > > -----Original Message----- > > From: cisco-nsp-bounces at puck.nether.net > > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Riemer > > Sent: Friday, 5 September 2008 9:00 AM > > To: cisco-nsp at puck.nether.net > > Subject: [c-nsp] Dashboard Network Monitoring Software > > > > Hi Guys, > > > > > > > > Is anyone out there using any open source or free dashboard network > > monitoring software? I would like to have a map background with our > > sites and possibly blink the sites RED if the site stopped responding > > to > > pings or SNMP queries etc? I know Solarwinds and HP Openview are good > > but we are not willing to shell out the money just for a dashboard. > > > > > > > > Cheers, > > > > > > > > Aaron. > > > > > > > > > > > > > > > > > > > > > > LEGAL DISCLAIMER: This message contains confidential information and > is > > intended only for the individual named. If you are not the named > > addressee you should not disseminate, distribute or copy this e-mail. > > Please notify the sender immediately by e-mail if you have received > > this > > e-mail by mistake and delete this e-mail from your system. If you are > > not the intended recipient you are notified that disclosing, copying, > > distributing or taking any action in reliance on the contents of this > > information is strictly prohibited. > > _______________________________________________ > > 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/ > > LEGAL DISCLAIMER: This message contains confidential information and is > intended only for the individual named. If you are not the named > addressee you should not disseminate, distribute or copy this e-mail. > Please notify the sender immediately by e-mail if you have received > this e-mail by mistake and delete this e-mail from your system. If you > are not the intended recipient you are notified that disclosing, > copying, distributing or taking any action in reliance on the contents > of this information is strictly prohibited. From aaronis at people.net.au Fri Sep 5 22:21:16 2008 From: aaronis at people.net.au (aaron) Date: Sat, 6 Sep 2008 10:21:16 +0800 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: Message-ID: <200809060221.m862LDuY024759@puck.nether.net> Yep weathermap looks awesome. Do you know if its possible for the map to change the icon of a site if it is down or unreachable? That would be awesome :) Aaron. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Christian Koch Sent: Saturday, September 06, 2008 3:46 AM To: Aaron Riemer Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Dashboard Network Monitoring Software you can also try a weather map like below... http://www.network-weathermap.com/ http://netmon.grnet.gr/weathermap/#docs On Thu, Sep 4, 2008 at 9:00 PM, Aaron Riemer wrote: > Hi Guys, > > > > Is anyone out there using any open source or free dashboard network > monitoring software? I would like to have a map background with our > sites and possibly blink the sites RED if the site stopped responding to > pings or SNMP queries etc? I know Solarwinds and HP Openview are good > but we are not willing to shell out the money just for a dashboard. > > > > Cheers, > > > > Aaron. > > > > > > > > > > > LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. > _______________________________________________ > 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.6.17/1655 - Release Date: 9/5/2008 7:05 PM From david_laporte at harvard.edu Fri Sep 5 22:36:17 2008 From: david_laporte at harvard.edu (LaPorte, David) Date: Fri, 05 Sep 2008 22:36:17 -0400 Subject: [c-nsp] WebVPN via RADIUS - how to identify by group? In-Reply-To: <002901c90fb9$500e4a50$f02adef0$@steele@internode.on.net> References: <00d001c90f22$c6f0e2f0$54d2a8d0$@steele@internode.on.net> <48C124DA.5020408@harvard.edu> <002901c90fb9$500e4a50$f02adef0$@steele@internode.on.net> Message-ID: <48C1ECA1.4050905@harvard.edu> We're doing exactly that, although with Radiator vs IAS. Dave Ben Steele wrote: > Problem with the group selection method is via a debug radius I don't see it > send any attribute about the group to RADIUS(I did try this way at first) > and therefore I can't get RADIUS to match on a group as well as user/pass, > the username at realm might be an option, have you tried this before by sending > back a group attribute to the ASA from RADIUS and it actually acknowledging > it and putting the WEBVPN user into that group?. > > Cheers > > Ben > > -----Original Message----- > From: LaPorte, David [mailto:david_laporte at harvard.edu] > Sent: Friday, 5 September 2008 9:54 PM > To: Ben Steele > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] WebVPN via RADIUS - how to identify by group? > > You could pass the group as a realm to the RADIUS server by having the > users log in as USER at GROUP. The RADIUS server could authenticate them > and return a Class="OU=GROUP;" attribute to map them properly. > > You could also provide a group list to the user: > > http://www.cisco.com/en/US/products/ps6120/products_configuration_example091 > 86a00808bd83d.shtml > > I prefer not to do this since it could make enumeration attacks a bit > easier, but it has it's place. > > hope that helps, > Dave > > Ben Steele wrote: >> Howdy all, >> >> >> >> Anyone know if it's possible to get as ASA to spit out the group name in > an >> av-pair via radius when authenticating a user? (in this case webvpn). >> >> >> >> The issue i'm having is multiple clients on the one ASA authenticating via >> IAS/AD and the possibility of overlapping usernames between > clients(groups), >> I need another identifier from the ASA to auth them against other than >> user/pass, ie group would be perfect. >> >> >> >> Any ideas? >> >> >> >> Cheers >> >> >> >> Ben From sethm at rollernet.us Sat Sep 6 00:36:59 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 05 Sep 2008 21:36:59 -0700 Subject: [c-nsp] Receiving BGP communities Message-ID: <48C208EB.7050109@rollernet.us> Is there a reason why I would not be receiving BGP communities? Upstream says they are sending, but I don't see anything. The only communities I can see are the one from my cymru bogon route server neighbors. Upstream's end is a Juniper, if that makes a difference. I feel like I'm missing something stupid like a "receive community" command. ~Seth From Stuart_Lowes at coffey.com Sat Sep 6 00:39:40 2008 From: Stuart_Lowes at coffey.com (Stuart Lowes) Date: Sat, 6 Sep 2008 14:39:40 +1000 Subject: [c-nsp] WebVPN via RADIUS - how to identify by group? Message-ID: Ben Steele wrote: > Problem with the group selection method is via a debug radius I don't see it > send any attribute about the group to RADIUS(I did try this way at first) > and therefore I can't get RADIUS to match on a group as well as user/pass, > the username at realm might be an option, have you tried this before by sending > back a group attribute to the ASA from RADIUS and it actually acknowledging > it and putting the WEBVPN user into that group?. Ben, If you have two group policies setup on your ASA, "GroupPolicy1" and "GroupPolicy2", you can set the RADIUS "Class" attribute to OU=GroupPolicy1 or OU=GroupPolicy2. In IAS setup two policies, matching AD Security Group "Group1" and "Group2" respectively. Members of Group1 are assigned OU=GroupPolicy1, and Group2 gets OU=GroupPolicy2. The text after OU= then matches the name of the ASA's group policy exactly and will assign that Group Policy to the VPN user's session. If you now also have two Tunnel Groups, "TunnelGroup1" and "TunnelGroup2" on the ASA, you can use the "group-lock xxx" command to lock TunnelGroup1 to GroupPolicy1 and TunnelGroup2 to GroupPolicy2. If a user who is a member of Group1 tries to use the TunnelGroup2 VPN profile, they will get rejected when the ASA compares the OU=GroupPolicy1 (assigned to user by IAS) with the GroupPolicy2 value expected by TunnelGroup2. Cheers Stuart Environmental Notice: Please consider the environment before printing this email.

Confidentiality Notice: The content of this message and any attachments may be privileged, in confidence or sensitive. Any unauthorised use is expressly prohibited. If you have received this email in error please notify the sender, disregard and then delete the email. This email may have been corrupted or interfered with. Coffey International Limited cannot guarantee that the message you receive is the same as the message we sent. At Coffey International Limited's discretion we may send a paper copy for confirmation. In the event of any discrepancy between paper and electronic versions the paper version is to take precedence. No warranty is made that this email and its contents are free from computer viruses or other defects.

CILDISCL0005 From ranmails at gmail.com Sat Sep 6 03:52:02 2008 From: ranmails at gmail.com (Ran Liebermann) Date: Sat, 6 Sep 2008 10:52:02 +0300 Subject: [c-nsp] Receiving BGP communities In-Reply-To: <48C208EB.7050109@rollernet.us> References: <48C208EB.7050109@rollernet.us> Message-ID: <8c19328e0809060052i643202abo3453d54826ad4ae3@mail.gmail.com> Maybe you have an ingress route-map setting new communities without the "additive" suffix? -- Ran. On Sat, Sep 6, 2008 at 7:36 AM, Seth Mattinen wrote: > Is there a reason why I would not be receiving BGP communities? Upstream > says they are sending, but I don't see anything. The only communities I can > see are the one from my cymru bogon route server neighbors. Upstream's end > is a Juniper, if that makes a difference. > > I feel like I'm missing something stupid like a "receive community" command. > > ~Seth From gert at greenie.muc.de Sat Sep 6 04:44:24 2008 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 6 Sep 2008 10:44:24 +0200 Subject: [c-nsp] latest stable... In-Reply-To: <480dad640809051512y7b24e62bjf62c75fcba763421@mail.gmail.com> References: <20080904062352.GQ233@greenie.muc.de> <20080905220153.GL17238@greenie.muc.de> <480dad640809051512y7b24e62bjf62c75fcba763421@mail.gmail.com> Message-ID: <20080906084424.GM17238@greenie.muc.de> Hi, On Fri, Sep 05, 2008 at 06:12:27PM -0400, Aaron wrote: > for the 7200 with just bgp why not use 12.0S? 12.0S has no IPv6 support on the 7200 platform, so I consider this release unsuitable for anything. 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: 304 bytes Desc: not available URL: From blahu77 at gmail.com Sat Sep 6 06:59:24 2008 From: blahu77 at gmail.com (=?ISO-8859-2?Q?Mateusz_B=B3aszczyk?=) Date: Sat, 6 Sep 2008 11:59:24 +0100 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080905184202.GD20054@rtp-cse-489.cisco.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> Message-ID: <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rondey, Nic, >> > >> >config t >> >int null 0 >> >no ip unreachables yes this is configured already. >> > >> >The ACL drops are, last I checked, rate limit punts. >> this is interesting - there is a good article detailing cef and CPU >> punting at :- >> http://searchnetworkingchannel.techtarget.com/generic/0,295582,sid100_gci1261924,00.html >> >> >> >> Reading that and this posting begs the question >> - if there is a lrage amount of ACL drops and these packets are punted to >> cPU and the CPU rate-limit for punted packets has been exceeded, then >> possible packets that need to be CPU processed will be dropped in favour >> of ACL denied packets > > That's not true. The packets are dropped under interrupt that match > the ACL deny other than punting some to generate the unreachable. > You will always deny them. > >> >If it's high CPU at IP Input really need 12.4(20)T and get >> >a sniffer trace in the punt path to see what traffic it really is. This part is interesting. I might try that. Question - there are 2 switching paths on the router 1) process switching which means invoking ip_input for every packet 2) interrupt context switching which is supported by different caching mechanisms - fast switching, CEF etc. If there is marginal utilisation of ip_input process and also most of the CPU utilisation is pointing to interrupts - what does it mean? >> >>>>Also, if >> >>>>you're denying a lot of traffic from a certain source, you might want to >> >>>>just bit-bucket it rather than sending ICMP responses. >> >>> >> >>You could match the access list in a route map and set the outbound >> >>interface >> >>to Null0. The configured ACL follows the example for infrastructure ACLs (here: http://cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml#limitaccess ) Does it mean the NPE-G1 is not enough to process ~400Mbps/60kpps with ACL like above? The other night when traffic was much lower the ACL was removed from the port and overall utilization dropped from 45% to 37%. Is that a lot? 8% decrease is nothing but 1/5th of drop is quite substantial. I am puzzled here. Would a bigger box (as mentioned in the other thread "7600 starter kit") solve the problem? Best Regards, - -- - -mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIwmKMIvBv0k5esR4RAoE3AJ9qwbN70MPfjwjo2cd4JEeROxM3VACdElAw 7ND4V+Okkj2li6ktFVQ4+/Q= =g9Ev -----END PGP SIGNATURE----- From sam_mailinglists at spacething.org Sat Sep 6 09:46:13 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Sat, 06 Sep 2008 14:46:13 +0100 Subject: [c-nsp] FWSM 3.1(9) corrupting TCP SYN-ACKs when timestamps are enabled Message-ID: <48C289A5.5030807@spacething.org> Hi, We do have a TAC case on this, I'm just wondering if anyone here has seen something similar. We upgraded from 3.1(1) to 3.1(9) on our context based L3, FWSMs. Now, if an incoming SYN has timestamps there's a 50% chance that the FWSM generates a bad checksum when it NAT translates the returning SYN-ACK (from the webserver), causing the client to drop the SYN-ACK. SYNs without the timestamp options don't cause a problem. The problem seems to be isolated to two inside interfaces (in two different contexts), but they both NAT translate into the same inside range. Sam From mksmith at adhost.com Sat Sep 6 12:20:29 2008 From: mksmith at adhost.com (Michael K. Smith) Date: Sat, 06 Sep 2008 09:20:29 -0700 Subject: [c-nsp] IPv6 on the 877W In-Reply-To: Message-ID: Hey Seth: On 9/5/08 4:07 PM, "sethm at rollernet.us" wrote: > I just went back and forth with TAC regarding IPv6 support on an 877W. > Ultimately, the problem was that there isn't any support for IPv6 IRB, and > IRB is the only way to put the wireless radio on the same segment as the > ethernet ports. Boo. I found a bug id in the c-nsp archives (CSCej50923) > about this from 2005, and I was told it was closed without a fix. > > Also of note, I turned the 877W into a brick by doing the following (in > order): > > * Assign IPv6 address to int vlan 1 > * do "no bridge-group 1" on int vlan 1 > * IPv6 works! no IPv4, though > * do "bridge-group 1" on int vlan 1 > * ipv6 and ipv4 work! however... > * router locks up after a bit, then never boots again after a power cycle > > Seems IPv6 is pretty buggy (and lacking) on this thing. > You can run both IPv6 and IPv4, but not bridged. So, if you assign a /64 to your VLAN 1 interface and a /64 to the wireless interface, you get connectivity, albeit from two different networks. I've got a sanitized copy of a working config here: http://www.andbobsyouruncle.net/wordpress/?p=11 running 12.3(8r)YI3 Regards, Mike From sethm at rollernet.us Sat Sep 6 13:20:03 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 6 Sep 2008 10:20:03 -0700 (PDT) Subject: [c-nsp] Receiving BGP communities In-Reply-To: <8c19328e0809060052i643202abo3453d54826ad4ae3@mail.gmail.com> References: <48C208EB.7050109@rollernet.us> <8c19328e0809060052i643202abo3453d54826ad4ae3@mail.gmail.com> Message-ID: <4c16f96b03def1ddfd8b827b1aae9bbd.squirrel@webmail.rollernet.us> On Sat, September 6, 2008 00:52, Ran Liebermann wrote: > Maybe you have an ingress route-map setting new communities without > the "additive" suffix? > Here's what my ingress route-map looks like: ip as-path access-list 2 permit ^3561$ route-map set-localpref permit 10 match as-path 2 set local-preference 200 set community 11170:3561 additive ! route-map set-localpref permit 20 set community 11170:3561 additive ! route-map set-localpref permit 30 ! I'll admit I'm quite new to BGP communities, but I *can* see 11170:3561 within my own network, just nothing upstream says they're sending. ~Seth From avayner at cisco.com Sat Sep 6 14:35:42 2008 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Sat, 6 Sep 2008 20:35:42 +0200 Subject: [c-nsp] Receiving BGP communities In-Reply-To: <4c16f96b03def1ddfd8b827b1aae9bbd.squirrel@webmail.rollernet.us> References: <48C208EB.7050109@rollernet.us><8c19328e0809060052i643202abo3453d54826ad4ae3@mail.gmail.com> <4c16f96b03def1ddfd8b827b1aae9bbd.squirrel@webmail.rollernet.us> Message-ID: <67F7C1FAF83A074AA3520D8F155782A501CFF619@xmb-ams-331.emea.cisco.com> Seth, You can use the "debug ip bgp updates" command (if you are getting a big table, you can use an ACL to filter it out...). If you get communities from your upstream, you would see it. If not, just send them the output, and let them worry about it. Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Seth Mattinen Sent: Saturday, September 06, 2008 20:20 PM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Receiving BGP communities On Sat, September 6, 2008 00:52, Ran Liebermann wrote: > Maybe you have an ingress route-map setting new communities without > the "additive" suffix? > Here's what my ingress route-map looks like: ip as-path access-list 2 permit ^3561$ route-map set-localpref permit 10 match as-path 2 set local-preference 200 set community 11170:3561 additive ! route-map set-localpref permit 20 set community 11170:3561 additive ! route-map set-localpref permit 30 ! I'll admit I'm quite new to BGP communities, but I *can* see 11170:3561 within my own network, just nothing upstream says they're sending. ~Seth _______________________________________________ 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 Sat Sep 6 15:48:57 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 06 Sep 2008 12:48:57 -0700 Subject: [c-nsp] Receiving BGP communities In-Reply-To: <67F7C1FAF83A074AA3520D8F155782A501CFF619@xmb-ams-331.emea.cisco.com> References: <48C208EB.7050109@rollernet.us><8c19328e0809060052i643202abo3453d54826ad4ae3@mail.gmail.com> <4c16f96b03def1ddfd8b827b1aae9bbd.squirrel@webmail.rollernet.us> <67F7C1FAF83A074AA3520D8F155782A501CFF619@xmb-ams-331.emea.cisco.com> Message-ID: <48C2DEA9.4080102@rollernet.us> Arie Vayner (avayner) wrote: > Seth, > > You can use the "debug ip bgp updates" command (if you are getting a big > table, you can use an ACL to filter it out...). > If you get communities from your upstream, you would see it. If not, > just send them the output, and let them worry about it. > Thanks. Doesn't look like they are, so I'll give it back to them. I try not to blame someone else when I'm doing something new to me. ;) ~Seth From dr at cluenet.de Sat Sep 6 14:49:36 2008 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 6 Sep 2008 20:49:36 +0200 Subject: [c-nsp] Difference between SPA-nXOC3-ATM and SPA-nXOC3-ATM-V2 Message-ID: <20080906184936.GA29909@srv01.cluenet.de> Hi, there seem to be two generations of ATM OC3 SPAs around: SPA-2XOC3-ATM / SPA-4XOC3-ATM: http://www.cisco.com/en/US/prod/collateral/modules/ps6267/product_data_sheet0900aecd8027cba7.html and SPA-1XOC3-ATM-V2 / SPA-3XOC3-ATM-V2: http://www.cisco.com/en/US/prod/collateral/modules/ps6267/data_sheet_C78-487941.html The differences I found are: 2/4 port: - supported in 6500/7600 - double height SPA => lower density - max 16,000 VCs "(subject to overall configuration limitations)" 1/3 port V2 - supported in CRS1/XR12k - single height SPA => higher density - 2047 VCs per port Did I miss anything relevant? Is the 1/3 really a newer generation of SPAs than the 2/4 port ones? I rarely find more info on the 1/3 port SPAs than the URL above. It's not listed in the Global Price List as well, so I wonder wether it's very very new? Does anyone have list pricing for the 3-port? Given that ASR1k BU is now telling us that the 1/3 V2 SPAs are planned for RLS3, I'm looking into those SPAs in more detail... didn't have them on radar at all and was planning with the 2/4 ports until yesterday... Any feedback appreciated. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From frnkblk at iname.com Sat Sep 6 22:40:17 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 6 Sep 2008 21:40:17 -0500 Subject: [c-nsp] Surge protection on leased lines In-Reply-To: References: <20080904160037.GA21273@saucer.midcoast.com> Message-ID: This is exactly the thing that Verizon was called on the carpet for in NY state. Frank -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ted Mittelstaedt Sent: Thursday, September 04, 2008 9:53 PM To: jp; Brian Turnbow Cc: Cisco Mailing list Subject: Re: [c-nsp] Surge protection on leased lines Here is an explanation of what your SUPPOSED to have: http://www.cermetek.com/Support/APP-Notes/611-0175.pdf with some schematics in case you want to roll your own protectors. According to this, per FCC part 68, your national telephone company is in violation of FCC regs if it is not providing an isolation barrier at the customer handoff, which clearly it is not if your losing WICs to lighting. They may be sliding under the regulation by giving you the handoff via V.35 but I doubt it. Frankly I've never seen a SHDSL line being handed off to the customer on a V.35. I've seen plenty of Telco-owned muxes that took a T1 or SHDSL and handed off to the customer via both POTS and V35, though, but I don't see the point of an NIU that goes from SHDSL to V.35 - it's extra cost for the Telco, and that would require the customer prem equipment to be sitting next to the Dmarc since your not going to run V.35 a hundred or so feet from the dmarc to the network room. This scheme sounds cockamamie to me. You learn something new every day. If I were you I would call your local municipality on this. All the electrical codes I've ever seen require the utility side of any feed into a building to have a solid, low-resistance ground at the entry point. They cannot just connect to a cold water pipe or some such nonsense, they have to drive a copper rod into the ground and ground to that. The fact that your "national telco" is allowing lightning energy to come into your building is a fire hazard and I am quite sure is in violation of your local wiring codes. They need a sold ground and suppression such as varistors connected between that ground and both wires of the pair that the SHDSL line is on. If you can get the specific code requirements for your municipality you can threaten to report your national telco to both the FCC and the local municipality if they do not install surge suppression. Ted PS I am assuming your in the US, here. > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of jp > Sent: Thursday, September 04, 2008 9:01 AM > To: Brian Turnbow > Cc: Cisco Mailing list > Subject: Re: [c-nsp] Surge protection on leased lines > > > Usually our Telco has gas/carbon arrestors at the NID and they differ > for pots or T1 as T1 is higher voltage. > > Make sure your nid, smartbox, router are all grounded together and to > the electrical system ground. I suspect they are not if current is > flowing in and damaging your wic. > > I know APC made some ptel series arrestors for T1/ISDN usage for > protecting the twisted pairs when the rj45/48 interfaces are used. I > have these and they are good. Too bad you don't have access to that. > > On Mon, Aug 25, 2008 at 06:05:07PM +0200, Brian Turnbow wrote: > > Thanks for the response. > > They are external csus but they are "telco property" and they > don't want us to touch them. > > We have asked several times that they install protection > coming into the building but no go... > > They install a remote powered integrated shdsl modem/csu in an > all plastic housing and the only place we > > Have been able to connect a ground is to the v.35 mount on the > integrated csu. No help there. > > Lighting strike= burned modem/csu= burned wic > > The v.35 protector would be a try to at least save our wic > cards and costs of dispatching a Tech > > for every passing storm. > > > > > > Brian > > > > -----Original Message----- > > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jay Hennigan > > Sent: luned? 25 agosto 2008 17.34 > > To: Cisco Mailing list > > Subject: Re: [c-nsp] Surge protection on leased lines > > > > Brian Turnbow wrote: > > > Hello, > > > > > > We have several customers that our having problems every time a storm > > > goes through. > > > Our national telco company seems to offer no lightning protection on > > > their lines, and every storm causes a line outage and burns up the > > > attached wic. > > > We've made sure the chassis are grounded , but would also like to try > > > and install a surge protection detween the v.35 interface of the telco > > > and our CPEs. > > > I see that Cisco offers a surge protection cable for smart serial > > > interfaces, but not for classic serial interfaces. > > > I wanted ask what others would recommend / experiences regarding surge > > > protection on leased lines. > > > > This is an external CSU? > > > > I think you want it between the telco smartjack and the CSU, not on the > > v.35. This should be two pairs of wires. > > > > First thing to do is ensure that the telco smartjack, the CSU, and the > > router are solidly connected to a common ground, as this may be the > > source of the problem if the sneak current is not coming across the > > leased line. > > > > There are a number of companies making lightning protectors for twisted > > pair lines, Reliable Electric and Polyphaser are two. > > > > But, triple-check the grounding first because if it's > common-mode across > > a ground differential the protectors won't help. > > > > -- > > 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/ > > _______________________________________________ > > 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/ > */ > _______________________________________________ > 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 frnkblk at iname.com Sat Sep 6 23:53:42 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 6 Sep 2008 22:53:42 -0500 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <00b901c90f12$3c293010$b47b9030$@steele@internode.on.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <6bb5f5b10809041001q317d4694o8b57be06fcfd54da@mail.gmail.com> <20080904170928.GA23309@mx.ytti.net> <200809051015.06641.mtinka@globaltransit.net> <00b901c90f12$3c293010$b47b9030$@steele@internode.on.net> Message-ID: The first time I went through the ASR materials I was left with the impression that they were launching this product with the minimum software features and hardware support. It's going to be some time before it's as full-featured as it really needs to be. Frank -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ben Steele Sent: Thursday, September 04, 2008 11:46 PM To: mtinka at globaltransit.net; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] c7604 "starter kit" I'm pretty sure it is scheduled for release in an upcoming update, I know there was lots of "hmmm's" when I saw the list of current unsupported technologies during our companies presentation, but I seem to recall most of them set for release in the future, I mean it would be ridiculous to never support mpls-te on the ASR. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mark Tinka Sent: Friday, 5 September 2008 11:45 AM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] c7604 "starter kit" On Friday 05 September 2008 01:09:28 Saku Ytti wrote: > L3 VPN yes, TE no sure. According to FN, MPLS-TE is unsupported. Quite surprising, actually... Mark. _______________________________________________ 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 ranmails at gmail.com Sun Sep 7 00:41:53 2008 From: ranmails at gmail.com (Ran Liebermann) Date: Sun, 7 Sep 2008 07:41:53 +0300 Subject: [c-nsp] Receiving BGP communities In-Reply-To: <4c16f96b03def1ddfd8b827b1aae9bbd.squirrel@webmail.rollernet.us> References: <48C208EB.7050109@rollernet.us> <8c19328e0809060052i643202abo3453d54826ad4ae3@mail.gmail.com> <4c16f96b03def1ddfd8b827b1aae9bbd.squirrel@webmail.rollernet.us> Message-ID: <8c19328e0809062141l37a7f7a7kc367a13725b5f5e7@mail.gmail.com> Hi Seth, Your route-map is ok (although the 3rd sequence - sequence 30 is redundant and you can remove it completely). Seems that Savvis don't send the communities to you. Regards, -- Ran. On Sat, Sep 6, 2008 at 8:20 PM, Seth Mattinen wrote: > On Sat, September 6, 2008 00:52, Ran Liebermann wrote: >> Maybe you have an ingress route-map setting new communities without >> the "additive" suffix? >> > > Here's what my ingress route-map looks like: > > ip as-path access-list 2 permit ^3561$ > > route-map set-localpref permit 10 > match as-path 2 > set local-preference 200 > set community 11170:3561 additive > ! > route-map set-localpref permit 20 > set community 11170:3561 additive > ! > route-map set-localpref permit 30 > ! > > I'll admit I'm quite new to BGP communities, but I *can* see 11170:3561 > within my own network, just nothing upstream says they're sending. > > ~Seth > > _______________________________________________ > 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 zivl at gilat.net Sun Sep 7 03:27:35 2008 From: zivl at gilat.net (Ziv Leyes) Date: Sun, 7 Sep 2008 10:27:35 +0300 Subject: [c-nsp] latest stable... In-Reply-To: <480dad640809051512y7b24e62bjf62c75fcba763421@mail.gmail.com> References: <20080904062352.GQ233@greenie.muc.de> <20080905220153.GL17238@greenie.muc.de> <480dad640809051512y7b24e62bjf62c75fcba763421@mail.gmail.com> Message-ID: I have a few 7206 VXR NPE-G1 running IS-MZ 12.4(13b) for a few months now and so far (touch wood) no problems... They mostly hold an STM and another GE Link circuits and two main uplink peers and a dozen of customers peers. Throughput of each is around 150-200Mb on and off. Hope this info helps. Ziv -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Sent: Saturday, September 06, 2008 1:12 AM To: Gert Doering Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] latest stable... for the 7200 with just bgp why not use 12.0S? On Fri, Sep 5, 2008 at 6:01 PM, Gert Doering wrote: > Hi, > > On Fri, Sep 05, 2008 at 01:54:07PM -0400, Jim McBurnett wrote: > > Great... > > For the G1-- all we need is BGP and Ethernet-- Nothing special.. > > Metro E fiber inbound and FIBER out... > > I'd go for 12.3(latest) main line. 12.2S/SB/SR will have lots more nice > features, as will have 12.4/12.4T, but those usually bring some drawbacks > regarding stability. > > 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 > > _______________________________________________ > 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/ ************************************************************************************ 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 saku+cisco-nsp at ytti.fi Sun Sep 7 03:57:06 2008 From: saku+cisco-nsp at ytti.fi (Saku Ytti) Date: Sun, 7 Sep 2008 10:57:06 +0300 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: References: <20080904112344.GA2758@whitechalk.dfinet.ch> <6bb5f5b10809041001q317d4694o8b57be06fcfd54da@mail.gmail.com> <20080904170928.GA23309@mx.ytti.net> <200809051015.06641.mtinka@globaltransit.net> Message-ID: <20080907075706.GA7640@mx.ytti.net> On (2008-09-06 22:53 -0500), Frank Bulk wrote: > The first time I went through the ASR materials I was left with the > impression that they were launching this product with the minimum software > features and hardware support. It's going to be some time before it's as > full-featured as it really needs to be. Just out of curiosity what were main points that left you wanting? For me (PE usage), it was pretty much only EoMPLS, had that been in FCS, I would have definitely EFT'd it. -- ++ytti From ecralar at hotmail.com Sun Sep 7 06:46:09 2008 From: ecralar at hotmail.com (Alex) Date: Sun, 7 Sep 2008 11:46:09 +0100 Subject: [c-nsp] free WAN emulation software References: <70bb1b8f0809050900j2adf0cb1ide6f91d6519cf71@mail.gmail.com> Message-ID: Hi there, M0n0wall http://m0n0.ch/wall/ is pretty good, you can insert predefined delay/BW/packet loss on the link if you want to. All it takes is a cheap PC and bootable CD(+floppy to save the config). In terms of physical connectivity, you are restricted to Ethernet only. Rgds Alex ----- Original Message ----- From: "Andrew Gristina" To: "Sergey Voropaev" Cc: Sent: Friday, September 05, 2008 5:00 PM Subject: Re: [c-nsp] free WAN emulation software > The opensource options are dummynet on BSD: > > http://info.iet.unipi.it/~luigi/ip_dummynet/ > > Which is good for emulating links 100Mb or slower, I think it needs > patches if you are going to emulate long fat pipes. I used the boot > floppy, it is easier to use if you have some unix experience. > > or > > Nistnet on linux (the traffic shaping stuff is now in kernel). > > But I find it is old, and that netem is is better in linux- basically > the tc commands: > > http://www.linuxfoundation.org/en/Net:Netem > > > On Fri, Sep 5, 2008 at 7:38 AM, Sergey Voropaev > wrote: >> Hi guys, >> >> Could anyone advise free WAN (wide area network) emulator software. I >> need to find solution for the following reason. We have some network >> application and we want to know how good this applications work over >> the WAN with predefined parameters. The better emulator must support >> operations with more parameters. The main parameters is delay, jitter, >> throughput, bit errors, packets lost, resequencing etc. >> >> I think that this should be server with two NIC and installed soft, so >> such soft I'm looking for. >> _______________________________________________ >> 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 felixnkansah at gmail.com Sun Sep 7 08:27:57 2008 From: felixnkansah at gmail.com (Felix Nkansah) Date: Sun, 7 Sep 2008 12:27:57 +0000 Subject: [c-nsp] free WAN emulation software In-Reply-To: References: Message-ID: <18dba4e50809070527q7cd451a1scdc80d29b351d4a3@mail.gmail.com> Hi, Cisco NIST Net Wan Emulation Software. http://www.cisco.com/en/US/docs/app_ntwk_services/waas/wafs/v30/nistnet/NIST.html Regards, Felix From howie at thingy.com Sun Sep 7 11:51:16 2008 From: howie at thingy.com (Howard Jones) Date: Sun, 07 Sep 2008 16:51:16 +0100 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: <200809060221.m862LDuY024759@puck.nether.net> References: <200809060221.m862LDuY024759@puck.nether.net> Message-ID: <48C3F874.3040005@thingy.com> aaron wrote: > Yep weathermap looks awesome. Do you know if its possible for the map to > change the icon of a site if it is down or unreachable? That would be > awesome :) > This is definitely possible on network-weathermap.com weathermap, assuming you have either some exisiting monitoring tool that it can get data from, or fping (experimental support). Data access is via plugins, so it's relatively easy to lash up something with your existing tools, if necessary. grnet weathermap does only link throughput, as far as I know. Howie (aka howie at network-weathermap.com :-) ) From lists at quux.de Sun Sep 7 16:18:53 2008 From: lists at quux.de (Jens Link) Date: Sun, 07 Sep 2008 22:18:53 +0200 Subject: [c-nsp] Dashboard Network Monitoring Software In-Reply-To: <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> (Aaron Riemer's message of "Fri, 5 Sep 2008 10:33:27 +0800") References: <0867622C64B50C4B878AB45C95F43F1106150B8D@MAILWA01.wesenergy.local> <64396C74FCE435468BE2AF5A73F9C2FD869209@chmaexch.chelmer.co.nz> <0867622C64B50C4B878AB45C95F43F1106150C86@MAILWA01.wesenergy.local> Message-ID: <87bpyzn1zm.fsf@laphroiag.quux.de> "Aaron Riemer" writes: > Hi James, > > Yes I thought about nagios. Is it possible to put your own background > map in and then position nodes on the map? Take a look at nagviz, http://sourceforge.net/projects/nagvis/ ,---- | NagVis is a visualization addon for the well known network managment | system Nagios. NagVis can be used to visualize Nagios Data, e.g. to | display IT processes like a mail system or a network infrastructure. `---- cheers Jens -- Berlin, Germany | http://www.quux.de | jabber: jenslink at guug.de sage at guug Berlin: http://www.guug.de/lokal/berlin/index.html From brett at looney.id.au Sun Sep 7 21:47:45 2008 From: brett at looney.id.au (Brett Looney) Date: Mon, 8 Sep 2008 09:47:45 +0800 Subject: [c-nsp] Service-Policy on 1800 SVI In-Reply-To: References: Message-ID: <0d5501c91154$e3ff8a70$abfe9f50$@id.au> > I'm running into an issue on a 1841 router where I have an internet > feed coming into one of the integrated switchports....I have the vlan > that the switchport is configured in as a EtherSVI with a public IP > address. I need to configure a policy-map with QoS but it appears > you cannot configure a service-policy on a EtherSVI...Is this correct? That's pretty much correct. You need to put the service policy on a routed port - either one of the two onboard Ethernets or get one of the routed HWIC cards (such as a HWIC-1FE) which are (of course) much more expensive than the HWIC switch cards. Putting a service policy on a SVI just doesn't work. On some platforms you can do it but you are severely limited in what you can do in that policy. B. From rubensk at gmail.com Sun Sep 7 22:17:49 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Sun, 7 Sep 2008 23:17:49 -0300 Subject: [c-nsp] Service-Policy on 1800 SVI In-Reply-To: <0d5501c91154$e3ff8a70$abfe9f50$@id.au> References: <0d5501c91154$e3ff8a70$abfe9f50$@id.au> Message-ID: <6bb5f5b10809071917u402e209fh9b2473da67ad1d8e@mail.gmail.com> Does the same apply to Cisco 881 ? Rubens On Sun, Sep 7, 2008 at 10:47 PM, Brett Looney wrote: >> I'm running into an issue on a 1841 router where I have an internet >> feed coming into one of the integrated switchports....I have the vlan >> that the switchport is configured in as a EtherSVI with a public IP >> address. I need to configure a policy-map with QoS but it appears >> you cannot configure a service-policy on a EtherSVI...Is this correct? > > That's pretty much correct. You need to put the service policy on a routed > port - either one of the two onboard Ethernets or get one of the routed HWIC > cards (such as a HWIC-1FE) which are (of course) much more expensive than > the HWIC switch cards. > > Putting a service policy on a SVI just doesn't work. On some platforms you > can do it but you are severely limited in what you can do in that policy. > > B. > _______________________________________________ > 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 brett at looney.id.au Sun Sep 7 22:35:20 2008 From: brett at looney.id.au (Brett Looney) Date: Mon, 8 Sep 2008 10:35:20 +0800 Subject: [c-nsp] Service-Policy on 1800 SVI In-Reply-To: <6bb5f5b10809071917u402e209fh9b2473da67ad1d8e@mail.gmail.com> References: <0d5501c91154$e3ff8a70$abfe9f50$@id.au> <6bb5f5b10809071917u402e209fh9b2473da67ad1d8e@mail.gmail.com> Message-ID: <0d5e01c9115b$89f65c50$9de314f0$@id.au> > Does the same apply to Cisco 881 ? Unknown - haven't seen one yet. But guessing: certainly the "WAN" Ethernet port on the 881 should be able to have a service policy applied but the SVI - probably not. B. From networking.stuff at googlemail.com Mon Sep 8 02:19:24 2008 From: networking.stuff at googlemail.com (Chintan Shah) Date: Mon, 8 Sep 2008 11:49:24 +0530 Subject: [c-nsp] BGP Next-hope convergance Message-ID: <1e7e04890809072319i10e4843fm17e2e82f4391901a@mail.gmail.com> Hi Guys, I have 6509 (PE3) switch learning VPNV4 routes from two PE1 & PE2 and select best path PE1 ( based on IGP metric). Now, PE-1 uplink to core failes and CR(P) find that PE1 not reachable based on IGP dead time = 9 sec and PEe learn that PE1 no more reachable now ( another 6 sec) so totatl IGP convegance =15 sec. howerver PE3 take another 5-6 sec to select best path is PE2 now for remote VPNV4 routes and total i get 21 sec....Why PE3 doesn't select PE2 afer 15 sec (IGP convergance) and wait another 5-6 ...what is that 5-6 can cause overvall convergance 21 sec ?? Can some one help me to understand ? Regards, Chintan From swmike at swm.pp.se Mon Sep 8 03:06:21 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 8 Sep 2008 09:06:21 +0200 (CEST) Subject: [c-nsp] BGP Next-hope convergance In-Reply-To: <1e7e04890809072319i10e4843fm17e2e82f4391901a@mail.gmail.com> References: <1e7e04890809072319i10e4843fm17e2e82f4391901a@mail.gmail.com> Message-ID: On Mon, 8 Sep 2008, Chintan Shah wrote: > Hi Guys, > > I have 6509 (PE3) switch learning VPNV4 routes from two PE1 & PE2 and > select > best path PE1 ( based on IGP metric). > Now, PE-1 uplink to core failes and CR(P) find that PE1 not reachable > based > on IGP dead time = 9 sec and PEe learn that PE1 no more reachable now ( > another 6 sec) so totatl IGP convegance =15 sec. howerver PE3 take > another > 5-6 sec to select best path is PE2 now for remote VPNV4 routes and total > i > get 21 sec....Why PE3 doesn't select PE2 afer 15 sec (IGP convergance) > and > wait another 5-6 ...what is that 5-6 can cause overvall convergance 21 > sec > ?? > Can some one help me to understand ? First of all, what are your RD values? You need to make sure RD values are unique for each PE (use the IP:value format, instead of the AS:value format commonly used). Also, do the VPNv4 BGP sessions go down promptly when the next-hop becomes unreachable? If the platform supports BFD, you should use that to make the IGP session go down quicker. An easy way around this is also to make sure PE1-PE2 are connected somehow, so a PE never becomes unreachable due to a single link failing. With proper design you will be able to reach 0-2 second convergence time... -- Mikael Abrahamsson email: swmike at swm.pp.se From cisco-nsp at tracker.fire-world.de Mon Sep 8 04:42:50 2008 From: cisco-nsp at tracker.fire-world.de (Sebastian Wiesinger) Date: Mon, 8 Sep 2008 10:42:50 +0200 Subject: [c-nsp] Why do I have to specify "allow-default" uRPF option on 4500-E? Message-ID: <20080908084250.GA28509@danton.fire-world.de> Hello, I have a Cisco 4500-E / SUP6-E switch on which I want to configure uRPF. I tried to enable it and got the following message: re1-new(config-if)#ip verify unicast source reachable-via rx % ip verify configuration not supported on interface Vl13 - must specify allow-default With the allow-default option no problem: re1-new(config-if)#ip verify unicast source reachable-via rx allow-default re1-new(config-if)# Any idea why I have to enable allow-default? In the configuration guide for the 4500-E the command is printed with the allow-default option but without any explanation why it has to be specified. And what *exactly* does the allow-default option do? In the Cisco paper it says: The allow-default option may be used with either the rx or any option to include IP addresses not specifically contained in the routing table. Am I right that this would only affect uRPF in the case that I point a default 0.0.0.0/0 towards the interface? Regards, Sebastian -- 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 peter at rathlev.dk Mon Sep 8 05:24:45 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Mon, 08 Sep 2008 11:24:45 +0200 Subject: [c-nsp] BGP Next-hope convergance In-Reply-To: References: <1e7e04890809072319i10e4843fm17e2e82f4391901a@mail.gmail.com> Message-ID: <1220865885.3896.1.camel@abehat> On Mon, 2008-09-08 at 09:06 +0200, Mikael Abrahamsson wrote: > First of all, what are your RD values? You need to make sure RD values > are unique for each PE (use the IP:value format, instead of the > AS:value format commonly used). Does this have an effect on the convergence times? I seem to remember having been told that this is a good idea generally, but never really understood why. Can anybody shed light on why this is? Regards, Peter From saku+cisco-nsp at ytti.fi Mon Sep 8 05:55:53 2008 From: saku+cisco-nsp at ytti.fi (Saku Ytti) Date: Mon, 8 Sep 2008 12:55:53 +0300 Subject: [c-nsp] BGP Next-hope convergance In-Reply-To: <1220865885.3896.1.camel@abehat> References: <1e7e04890809072319i10e4843fm17e2e82f4391901a@mail.gmail.com> <1220865885.3896.1.camel@abehat> Message-ID: <20080908095553.GA27602@mx.ytti.net> On (2008-09-08 11:24 +0200), Peter Rathlev wrote: > On Mon, 2008-09-08 at 09:06 +0200, Mikael Abrahamsson wrote: > > First of all, what are your RD values? You need to make sure RD values > > are unique for each PE (use the IP:value format, instead of the > > AS:value format commonly used). > > Does this have an effect on the convergence times? I seem to remember > having been told that this is a good idea generally, but never really > understood why. Can anybody shed light on why this is? I'm not sure what you're asking. 1) why IP instead AS - purely non-technical reasons. With IP you can do loop0:SAME 2) why multiple RD's - so that RR best path algorithm doesn't kill your redundant or load-balancing route. So that PE can install two or more routes. -- ++ytti From david.freedman at uk.clara.net Mon Sep 8 06:21:27 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 8 Sep 2008 11:21:27 +0100 Subject: [c-nsp] 12.40(20T), pppoe woes Message-ID: Have just moved to testing 12.4(20)T for the HQF functionality, have now hit another stumbling point. Was previously doing multiple pppoe sessions (multiple pppoe client feature) using the HWIC-4ESW which mandates that the pppoe-client functionality *must* come from SVI, in 12.4(20)T this no longer works: router(config)# interface Vlan2 router(config-if)# pppoe-client dial-pool-number 2 %PPPoE-Client not supported on vlan interfaces Placing the client on the actual interface does not work (either PADI does not get transmitted or PADO is not interpreted correctly , either way, timeout occurs) Has this feature been removed? can't find any reference in 12.4T release notes against feature documentation or caveats nor does bugtool come back with anything useful. Many thanks, Dave. ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net From oboehmer at cisco.com Mon Sep 8 06:43:32 2008 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Mon, 8 Sep 2008 12:43:32 +0200 Subject: [c-nsp] 12.40(20T), pppoe woes In-Reply-To: References: Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED78405F80226@xmb-ams-333.emea.cisco.com> David Freedman <> wrote on Monday, September 08, 2008 12:21 PM: > Have just moved to testing 12.4(20)T for the HQF functionality, have > now hit another stumbling point. > > Was previously doing multiple pppoe sessions (multiple pppoe client > feature) using the HWIC-4ESW > which mandates that the pppoe-client functionality *must* come from > SVI, > in 12.4(20)T this no longer works: > > router(config)# interface Vlan2 > router(config-if)# pppoe-client dial-pool-number 2 > %PPPoE-Client not supported on vlan interfaces > > Placing the client on the actual interface does not work (either PADI > does not get transmitted > or PADO is not interpreted correctly , either way, timeout occurs) > > Has this feature been removed? can't find any reference in 12.4T > release notes against feature documentation or caveats nor does > bugtool come back with anything useful. David, please check CSCsu35584, it will be fixed in the upcoming 12.4(20)T1 rebuild and the above restriction will be removed.. oli From david.freedman at uk.clara.net Mon Sep 8 06:45:10 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 8 Sep 2008 11:45:10 +0100 Subject: [c-nsp] 12.40(20T), pppoe woes References: <70B7A1CCBFA5C649BD562B6D9F7ED78405F80226@xmb-ams-333.emea.cisco.com> Message-ID: Ah wonderful ollie, thought I was going mad! Thanks again ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com] Sent: Mon 9/8/2008 11:43 To: David Freedman; cisco-nsp at puck.nether.net Subject: RE: [c-nsp] 12.40(20T), pppoe woes David Freedman <> wrote on Monday, September 08, 2008 12:21 PM: > Have just moved to testing 12.4(20)T for the HQF functionality, have > now hit another stumbling point. > > Was previously doing multiple pppoe sessions (multiple pppoe client > feature) using the HWIC-4ESW > which mandates that the pppoe-client functionality *must* come from > SVI, > in 12.4(20)T this no longer works: > > router(config)# interface Vlan2 > router(config-if)# pppoe-client dial-pool-number 2 > %PPPoE-Client not supported on vlan interfaces > > Placing the client on the actual interface does not work (either PADI > does not get transmitted > or PADO is not interpreted correctly , either way, timeout occurs) > > Has this feature been removed? can't find any reference in 12.4T > release notes against feature documentation or caveats nor does > bugtool come back with anything useful. David, please check CSCsu35584, it will be fixed in the upcoming 12.4(20)T1 rebuild and the above restriction will be removed.. oli From swmike at swm.pp.se Mon Sep 8 06:56:33 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 8 Sep 2008 12:56:33 +0200 (CEST) Subject: [c-nsp] BGP Next-hope convergance In-Reply-To: <1220865885.3896.1.camel@abehat> References: <1e7e04890809072319i10e4843fm17e2e82f4391901a@mail.gmail.com> <1220865885.3896.1.camel@abehat> Message-ID: On Mon, 8 Sep 2008, Peter Rathlev wrote: > Does this have an effect on the convergence times? I seem to remember > having been told that this is a good idea generally, but never really > understood why. Can anybody shed light on why this is? What Ytti said, and let me give you an example: PE1 and PE2 uplinks a redundantly connected customer. PE3 has another customer connection in the same VPN. Using unique RDs per PE, will ensure that PE3 has routes to both PE1 and PE2 in a route reflector structure, and if PE1 goes away then PE3 will have PE2 route in RIB and can update FIB without RR involvement. In case PE1 customer link goes down, it can change FIB to point to PE2 without RR involvement meaning packets will be forwarded continously as soon as the link-down is detected and FIB is updated, instead of the RR noticing it and sending updates. So yes, you want to use PE unique RDs, there little downside apart from a bit higher memory usage. -- Mikael Abrahamsson email: swmike at swm.pp.se From p.mayers at imperial.ac.uk Mon Sep 8 07:08:56 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Mon, 08 Sep 2008 12:08:56 +0100 Subject: [c-nsp] BGP Next-hope convergance In-Reply-To: References: <1e7e04890809072319i10e4843fm17e2e82f4391901a@mail.gmail.com> <1220865885.3896.1.camel@abehat> Message-ID: <48C507C8.5040002@imperial.ac.uk> Mikael Abrahamsson wrote: > On Mon, 8 Sep 2008, Peter Rathlev wrote: > >> Does this have an effect on the convergence times? I seem to remember >> having been told that this is a good idea generally, but never really >> understood why. Can anybody shed light on why this is? > > What Ytti said, and let me give you an example: > > PE1 and PE2 uplinks a redundantly connected customer. > PE3 has another customer connection in the same VPN. > > Using unique RDs per PE, will ensure that PE3 has routes to both PE1 and > PE2 in a route reflector structure, and if PE1 goes away then PE3 will > have PE2 route in RIB and can update FIB without RR involvement. > > In case PE1 customer link goes down, it can change FIB to point to PE2 > without RR involvement meaning packets will be forwarded continously as > soon as the link-down is detected and FIB is updated, instead of the RR > noticing it and sending updates. > > So yes, you want to use PE unique RDs, there little downside apart from > a bit higher memory usage. > Can someone clarify that RD versus route-target are unrelated, i.e. that I can have: PE1: ip vrf BLAH rd PE1-loop:1 route-target both 65000:1 ip vrf FOO rd PE1-loop:2 route-target both 65000:2 PE2: ip vrf BLAH rd PE2-loop:1 route-target both 65000:1 ip vrf FOO rd PE2-loop:2 route-target both 65000:2 From swmike at swm.pp.se Mon Sep 8 07:30:37 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 8 Sep 2008 13:30:37 +0200 (CEST) Subject: [c-nsp] BGP Next-hope convergance In-Reply-To: <48C507C8.5040002@imperial.ac.uk> References: <1e7e04890809072319i10e4843fm17e2e82f4391901a@mail.gmail.com> <1220865885.3896.1.camel@abehat> <48C507C8.5040002@imperial.ac.uk> Message-ID: On Mon, 8 Sep 2008, Phil Mayers wrote: > Can someone clarify that RD versus route-target are unrelated, i.e. that I > can have: Yes, RT is an extended BGP-community used for filtering routes, RD is a route DISTINGUISHER, it makes two identical prefixes unique because they come from different sources. So make RD:s unique per PE, and of course make RTs identical within the VPN. -- Mikael Abrahamsson email: swmike at swm.pp.se From saku+cisco-nsp at ytti.fi Mon Sep 8 07:32:33 2008 From: saku+cisco-nsp at ytti.fi (Saku Ytti) Date: Mon, 8 Sep 2008 14:32:33 +0300 Subject: [c-nsp] BGP Next-hope convergance In-Reply-To: <48C507C8.5040002@imperial.ac.uk> References: <1e7e04890809072319i10e4843fm17e2e82f4391901a@mail.gmail.com> <1220865885.3896.1.camel@abehat> <48C507C8.5040002@imperial.ac.uk> Message-ID: <20080908113233.GA28285@mx.ytti.net> On (2008-09-08 12:08 +0100), Phil Mayers wrote: > Can someone clarify that RD versus route-target are unrelated, i.e. that > I can have: RD is just hack to allow two or more e.g. 10.0.0.0/8 routes exist in BGP. How to make these different routes? Prefix some junk in front of them, done. RD does not decide which vrf gets which route. There might just as well be some 'auto RD ' chassis wide option which ensures unique RD in each VRF, and you never manually configure RD anywhere. RT otoh, is normal extended bgp community, which decides which VRF gets which route. -- ++ytti From peter at rathlev.dk Mon Sep 8 08:20:44 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Mon, 08 Sep 2008 14:20:44 +0200 Subject: [c-nsp] BGP Next-hope convergance In-Reply-To: References: <1e7e04890809072319i10e4843fm17e2e82f4391901a@mail.gmail.com> <1220865885.3896.1.camel@abehat> Message-ID: <1220876444.3896.4.camel@abehat> On Mon, 2008-09-08 at 12:56 +0200, Mikael Abrahamsson wrote: > On Mon, 8 Sep 2008, Peter Rathlev wrote: > > Does this have an effect on the convergence times? I seem to remember > > having been told that this is a good idea generally, but never really > > understood why. Can anybody shed light on why this is? > > What Ytti said, and let me give you an example: Thank you very much, both of you. Now I know exactly why we would do this. :-) Regards, Peter From brett at looney.id.au Mon Sep 8 08:32:09 2008 From: brett at looney.id.au (Brett Looney) Date: Mon, 8 Sep 2008 20:32:09 +0800 Subject: [c-nsp] IOS, IPSEC and hairpinned traffic Message-ID: <000001c911ae$e9ad7310$bd085930$@id.au> Greets, Got an odd problem and I just want to make sure that what I'm trying to do is possible - basically, hairpin traffic through a router where both remote endpoints are IPSEC-based. Three devices: A, B, C. A is a Cisco router with a dynamic IP address behind some NAT box. B is a Cisco router with a static IP address. C is a non-Cisco firewall with a static IP address. There are working IPSEC tunnels between A and B; and between B and C. The IPSEC tunnel between A and B isn't using DMVPN because that doesn't play nicely with the NAT in question so we're doing dynamic IPSEC stuff - no worries so far. The tunnel between B and C is standard LAN-to-LAN stuff. Now, I'd like users at A to be able to communicate with a server at C. I can't establish a direct tunnel because C doesn't support LAN-to-LAN endpoints with dynamic IP addresses. So, I thought I'd hairpin the traffic through B. Easy, right - just add some access list entries to the existing ACLs and away we go. Well, no. It doesn't appear to work that way. Traffic from A to C hits B and I see it hit the outbound IPSEC access list but there is no crypto happening. Nothing. Similarly with traffic from C to A - it hits B, gets decrypted, hits the outbound IPSEC access list to A but no crypto to A - packets don't leave B and certainly don't arrive at A. No error messages anywhere on any debug I can see. I've also tried doing "set ip access-group out" to check what is happening and I get no matches at all. I know the access lists are correct because if I put a loopback interface on B with the IP addresses of A (or C) then I can ping across happily. So it definitely has to do with the hairpin. For the record, I've checked the NAT tables and they don't contain any entries for the A/B/C IP addresses in question but given that I'm hairpinning through an "ip nat outside" interface I didn't expect that anyway. Is this actually supported? I know there are restrictions with the ASA/Pixen but I thought this would work with IOS. Am I missing some hidden (or unknown to me) command (like "crypto allow same-interface traffic")? Finally, yes, I realise one solution is to replace C with an IOS box and I have suggested that (my preferred option)... I also realise I could replace the router and NAT box at A with a router that also does NAT and I'm working on that too. TIA. Sorry for the long story. ;-) B. From alaerte.vidali at nsn.com Mon Sep 8 09:15:53 2008 From: alaerte.vidali at nsn.com (Vidali, Alaerte (NSN - BR/Rio de Janeiro)) Date: Mon, 8 Sep 2008 08:15:53 -0500 Subject: [c-nsp] Fragmentation on SUP720 In-Reply-To: References: Message-ID: <27C3D43D640FE947A3BDEB7077A373FE015C6850@USCHEXC006.nsn-intra.net> Hi, Any reference about fragmentation x CPU usage on SUP720? Tks, Alaerte From rodunn at cisco.com Mon Sep 8 09:28:08 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Mon, 8 Sep 2008 09:28:08 -0400 Subject: [c-nsp] Fragmentation on SUP720 In-Reply-To: <27C3D43D640FE947A3BDEB7077A373FE015C6850@USCHEXC006.nsn-intra.net> References: <27C3D43D640FE947A3BDEB7077A373FE015C6850@USCHEXC006.nsn-intra.net> Message-ID: <20080908132808.GK19347@rtp-cse-489.cisco.com> Why are you doing it? There are some whacky issues it can cause. ie: it will break PMTUD if it's an MPLS core and it's sup720s on each end of the LSP. Rodney On Mon, Sep 08, 2008 at 08:15:53AM -0500, Vidali, Alaerte (NSN - BR/Rio de Janeiro) wrote: > > Hi, > > Any reference about fragmentation x CPU usage on SUP720? > > Tks, > Alaerte > _______________________________________________ > 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 alaerte.vidali at nsn.com Mon Sep 8 09:52:14 2008 From: alaerte.vidali at nsn.com (Vidali, Alaerte (NSN - BR/Rio de Janeiro)) Date: Mon, 8 Sep 2008 08:52:14 -0500 Subject: [c-nsp] Fragmentation on SUP720 In-Reply-To: <20080908132808.GK19347@rtp-cse-489.cisco.com> References: <27C3D43D640FE947A3BDEB7077A373FE015C6850@USCHEXC006.nsn-intra.net> <20080908132808.GK19347@rtp-cse-489.cisco.com> Message-ID: <27C3D43D640FE947A3BDEB7077A373FE015C6886@USCHEXC006.nsn-intra.net> Hi Rodney, My advice is also to avoid it. Customer says they are out of option and due to issue on system they want to see if Cisco can handle fragmentation for some time until get definitive solution. Do you know if fragmentation is done in SUP720, no matter what interface module is installed? Br, Alaerte -----Original Message----- From: ext Rodney Dunn [mailto:rodunn at cisco.com] Sent: segunda-feira, 8 de setembro de 2008 10:28 To: Vidali, Alaerte (NSN - BR/Rio de Janeiro) Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Fragmentation on SUP720 Why are you doing it? There are some whacky issues it can cause. ie: it will break PMTUD if it's an MPLS core and it's sup720s on each end of the LSP. Rodney On Mon, Sep 08, 2008 at 08:15:53AM -0500, Vidali, Alaerte (NSN - BR/Rio de Janeiro) wrote: > > Hi, > > Any reference about fragmentation x CPU usage on SUP720? > > Tks, > Alaerte > _______________________________________________ > 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 rodunn at cisco.com Mon Sep 8 09:56:22 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Mon, 8 Sep 2008 09:56:22 -0400 Subject: [c-nsp] Fragmentation on SUP720 In-Reply-To: <27C3D43D640FE947A3BDEB7077A373FE015C6886@USCHEXC006.nsn-intra.net> References: <27C3D43D640FE947A3BDEB7077A373FE015C6850@USCHEXC006.nsn-intra.net> <20080908132808.GK19347@rtp-cse-489.cisco.com> <27C3D43D640FE947A3BDEB7077A373FE015C6886@USCHEXC006.nsn-intra.net> Message-ID: <20080908135622.GR19347@rtp-cse-489.cisco.com> On Mon, Sep 08, 2008 at 08:52:14AM -0500, Vidali, Alaerte (NSN - BR/Rio de Janeiro) wrote: > Hi Rodney, > > My advice is also to avoid it. Customer says they are out of option and > due to issue on system they want to see if Cisco can handle > fragmentation for some time until get definitive solution. > > Do you know if fragmentation is done in SUP720, no matter what interface > module is installed? IIRC it's punted and dune under interrupt on the RP CPU. I don't know the performance numbers because it's not advised so we do little to no testing on those setups. Rodney > > Br, > Alaerte > > -----Original Message----- > From: ext Rodney Dunn [mailto:rodunn at cisco.com] > Sent: segunda-feira, 8 de setembro de 2008 10:28 > To: Vidali, Alaerte (NSN - BR/Rio de Janeiro) > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Fragmentation on SUP720 > > Why are you doing it? > > There are some whacky issues it can cause. ie: it will break PMTUD if > it's an MPLS core and it's sup720s on each end of the LSP. > > Rodney > > > On Mon, Sep 08, 2008 at 08:15:53AM -0500, Vidali, Alaerte (NSN - BR/Rio > de Janeiro) wrote: > > > > Hi, > > > > Any reference about fragmentation x CPU usage on SUP720? > > > > Tks, > > Alaerte > > _______________________________________________ > > 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 rodunn at cisco.com Mon Sep 8 09:59:35 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Mon, 8 Sep 2008 09:59:35 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> Message-ID: <20080908135935.GS19347@rtp-cse-489.cisco.com> On Sat, Sep 06, 2008 at 11:59:24AM +0100, Mateusz B?aszczyk wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rondey, Nic, > >> > > >> >config t > >> >int null 0 > >> >no ip unreachables > > yes this is configured already. > > >> > > >> >The ACL drops are, last I checked, rate limit punts. > >> this is interesting - there is a good article detailing cef and CPU > >> punting at :- > >> > http://searchnetworkingchannel.techtarget.com/generic/0,295582,sid100_gci1261924,00.html > >> > >> > >> > >> Reading that and this posting begs the question > >> - if there is a lrage amount of ACL drops and these packets are punted to > >> cPU and the CPU rate-limit for punted packets has been exceeded, then > >> possible packets that need to be CPU processed will be dropped in favour > >> of ACL denied packets > > > > That's not true. The packets are dropped under interrupt that match > > the ACL deny other than punting some to generate the unreachable. > > You will always deny them. > > > > >> >If it's high CPU at IP Input really need 12.4(20)T and get > >> >a sniffer trace in the punt path to see what traffic it really is. > > This part is interesting. I might try that. > Question - there are 2 switching paths on the router > 1) process switching which means invoking ip_input for every packet That is if you have CEF disabled. Let's forget the "ip fastswitching" discussion because after 12.4(20)T it's gone. It's process or CEF only. > 2) interrupt context switching which is supported by different caching > mechanisms - fast switching, CEF etc. If there is marginal utilisation > of ip_input process and also most of the CPU utilisation is pointing > to interrupts - what does it mean? That means you have a lot of interrupt traffic transit the box and some is getting punted to process level after a lookup in the rx CEF routines or either further down the CEF switching vector due to a feature punt. > > >> >>>>Also, if > >> >>>>you're denying a lot of traffic from a certain source, you might want to > >> >>>>just bit-bucket it rather than sending ICMP responses. > >> >>> > >> >>You could match the access list in a route map and set the outbound > >> >>interface > >> >>to Null0. > > The configured ACL follows the example for infrastructure ACLs (here: > http://cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml#limitaccess > ) > > Does it mean the NPE-G1 is not enough to process ~400Mbps/60kpps with > ACL like above? Depends on the exact ACL and other features configured. > The other night when traffic was much lower the ACL was removed from > the port and overall utilization dropped from 45% to 37%. Is that a > lot? 8% decrease is nothing but 1/5th of drop is quite substantial. I > am puzzled here. Probably normal. I'd suggest looking at the new ASR1000 that can do ACL's in hardware. > > Would a bigger box (as mentioned in the other thread "7600 starter > kit") solve the problem? Yes as long as your process level traffic isn't the main issue. Rodney > > Best Regards, > > - -- > - -mat > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIwmKMIvBv0k5esR4RAoE3AJ9qwbN70MPfjwjo2cd4JEeROxM3VACdElAw > 7ND4V+Okkj2li6ktFVQ4+/Q= > =g9Ev > -----END PGP SIGNATURE----- From asturluismi at gmail.com Mon Sep 8 10:12:19 2008 From: asturluismi at gmail.com (luismi) Date: Mon, 08 Sep 2008 16:12:19 +0200 Subject: [c-nsp] Possible new bug in a 3750 stack Message-ID: <1220883139.8814.6.camel@dsba-ipso> Hi all, Is there anyone there with the same problem? I have a 3750 stack with 2 switches running flash:/c3750-ipservicesk9-mz.122-44.SE1.bin, the configuration is pretty simple, just several port-channels. I can see... STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Quite fine, isn't it? I did a "clear counters" last friday and they seems to appear and dissapear as they want. Is there anyone there with the same problem? I checked Bug Toolkit for this release and I didn't see a bug for that yet. From jcartier at acs.on.ca Mon Sep 8 10:28:55 2008 From: jcartier at acs.on.ca (Jeff Cartier) Date: Mon, 8 Sep 2008 10:28:55 -0400 Subject: [c-nsp] Cisco 1800 - Service-Policy SVI Message-ID: I've been trying to figure out how to configure QoS on a Cisco 1841 router under a SVI...it doesn't appear to have the option to place a service-policy under the vlan SVI. Any suggestions? Jeff Cartier Network Engineer Applied Computer Solutions *(519) 944-4300 ext. 233 *jcartier at acs.on.ca www.acs.on.ca From greg at ip-man.net Mon Sep 8 10:32:58 2008 From: greg at ip-man.net (Gregoire Huet) Date: Mon, 08 Sep 2008 16:32:58 +0200 Subject: [c-nsp] Moving Sup720 from cat6k to 7600 In-Reply-To: References: <48BFFC15.2020200@ip-man.net> <48C00F4F.2040505@ip-man.net> Message-ID: <48C5379A.5030008@ip-man.net> Hello, I want first to thank all the people who helped. The problem is solved, it was indeed a monlib issue. I can only boot my Sup720s on a CF which was formatted in the right slot on this blade. That's weird... If i format on disk1: (from a cat6k) then the 7604 will only boot it from disk1: and not from disk0: ! Thank you very much Best regards Greg Church, Charles a ?crit : > I would think that should support an 7604 chassis. Any chance the IOS > is corrupt on the flash? Or the Monlib isn't right. Can you put the > card in a working 6500 and verify the IOS image (MD5) and verify via > 'show disk0 all' that the monlib stuff is right? > > Chuck > > -----Original Message----- > From: Gregoire Huet [mailto:greg at ip-man.net] > Sent: Thursday, September 04, 2008 12:40 PM > To: Church, Charles > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Moving Sup720 from cat6k to 7600 > > > Church, Charles wrote : >> Is it possible you're trying to boot an IOS version that doesn't > support >> that chassis? I'm sure there is a minimum version for a 7604, and I'm >> sure it's more recent than the minimum for the 6500 it came out of. > > I'm trying to boot c7600s72033-advipservicesk9-mz.122-33.SRC1.bin > > By the way, i have the trace of the booting process : > > rommon 7 > reset > > System Bootstrap, Version 8.5(2) > Copyright (c) 1994-2007 by cisco Systems, Inc. > Cat6k-Sup720/SP processor with 1048576 Kbytes of main memory > > rommon 1 > boot disk0: > > Initializing ATA monitor library... > string is disk0:c7600s72033-advipservicesk9-mz.122-33.SRC1.bin > Loading image, please wait ... > > > Initializing ATA monitor library... > > *** Illegal Opcode Exception *** > PC = 0x80102ae4, Cause = 0x28, Status Reg = 0x30409003 > > monitor: command "boot" aborted due to exception > rommon 2 > > > > Thank you > > Greg > > From isplists at duracom.net Mon Sep 8 11:01:08 2008 From: isplists at duracom.net (Rhino Lists) Date: Mon, 8 Sep 2008 10:01:08 -0500 Subject: [c-nsp] PPPOE Static IP Message-ID: <002001c911c3$b9bdd310$2d397930$@net> I have a cisco 7206 terminating PPPOE DSL connections via Radius. I have a user who wants a static IP. Do I need to create another ip pool and how do I assign the IP in radius? K From Oliver.Dewdney at LBi.com Mon Sep 8 11:06:36 2008 From: Oliver.Dewdney at LBi.com (Oliver Dewdney) Date: Mon, 8 Sep 2008 16:06:36 +0100 Subject: [c-nsp] Possible new bug in a 3750 stack In-Reply-To: <1220883139.8814.6.camel@dsba-ipso> References: <1220883139.8814.6.camel@dsba-ipso> Message-ID: Yes, different numbers, different IOS, and not on a port channel... System image file is "flash:c3750-ipbasek9-mz.122-44.SE2/c3750-ipbasek9-mz.122-44.SE2.bin" switch#show int g 1/0/12 | i drop Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 15443990 switch #show int g 1/0/12 | i drop Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 23165985 Oli -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of luismi Sent: 08 September 2008 15:12 To: cisco-nsp at puck.nether.net Subject: [c-nsp] Possible new bug in a 3750 stack Hi all, Is there anyone there with the same problem? I have a 3750 stack with 2 switches running flash:/c3750-ipservicesk9-mz.122-44.SE1.bin, the configuration is pretty simple, just several port-channels. I can see... STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4294952019 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 STACK02# sh int Gi2/0/10 | i drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Quite fine, isn't it? I did a "clear counters" last friday and they seems to appear and dissapear as they want. Is there anyone there with the same problem? I checked Bug Toolkit for this release and I didn't see a bug for that yet. _______________________________________________ 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/ LBi. The global marketing and technology agency. Winner: Media Guardian Design Innovation Award 2008 LBi Ltd is registered in England and Wales, the registered number and address are 03080409, Truman Brewery, 146 Brick Lane, London, E1 6RU. This email may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From networking.stuff at googlemail.com Mon Sep 8 11:21:34 2008 From: networking.stuff at googlemail.com (Chintan Shah) Date: Mon, 8 Sep 2008 20:51:34 +0530 Subject: [c-nsp] Population of MLS cef entry Message-ID: <1e7e04890809080821x21ad4bfi74b8036584480b3a@mail.gmail.com> Hi Guys, Does any one knows once ip cef table update the routes , how much time it take to populate the entry in mls cef table ? I see that when my primary IGP path fails , ip cef table change the path to backup but mls cef table take some time and that makes my overall convgance double than IGP convergance. The box is 6509/sup720 running 12.(18)SXF12a Regards, Chintan From jcartier at acs.on.ca Mon Sep 8 11:45:41 2008 From: jcartier at acs.on.ca (Jeff Cartier) Date: Mon, 8 Sep 2008 11:45:41 -0400 Subject: [c-nsp] iBGP Multi-link question Message-ID: I'm in a scenario where I have two routers, configured with two loopbacks, connected together via two links. I'm in the process of transitioning from one loopback to the other and I was wondering if there are any caveats to having two sessions up...one BGP session to the first lookback (existing), then another BGP session up to the second loopback (new). I don't believe their should be any issues with this...and I don't see any documentation suggesting otherwise...just thought I'd ask to be certain :-) ROUTER1============ROUTER2 Lo1:10.1.1.1/32 Lo1:10.1.2.1/32 Lo2:10.1.1.2/32 Lo2:10.1.2.2/32 From kratzers at pa.net Mon Sep 8 12:39:51 2008 From: kratzers at pa.net (Stephen Kratzer) Date: Mon, 8 Sep 2008 12:39:51 -0400 Subject: [c-nsp] PPPOE Static IP In-Reply-To: <002001c911c3$b9bdd310$2d397930$@net> References: <002001c911c3$b9bdd310$2d397930$@net> Message-ID: <200809081239.52604.kratzers@pa.net> On Monday 08 September 2008 11:01:08 Rhino Lists wrote: > I have a cisco 7206 terminating PPPOE DSL connections via Radius. I have a > user who wants a static IP. Do I need to create another ip pool and how do > I assign the IP in radius? > > > > K Set Framed-IP-Address := x.x.x.x and Framed-IP-Netmask := x.x.x.x or Cisco-AVPair += ip:addr=x.x.x.x. Stephen Kratzer Network Engineer CTI Networks, Inc. From Drikus.Brits at is.co.za Mon Sep 8 12:58:09 2008 From: Drikus.Brits at is.co.za (Drikus Brits) Date: Mon, 8 Sep 2008 18:58:09 +0200 Subject: [c-nsp] PPPOE Static IP Message-ID: <89D2AE9E4EAAB34FABDBF2913867C62F182EEDFD@ZABRYSVISEX04.af.didata.local> Your basis of radius attributes will most likely be : Framed-Protocol := PPP Framed-MTU := 1500 Framed-IP-Address := 192.168.1.100 Framed-IP-Netmask := 255.255.255.255 Service-Type := Framed-User And the required Cisco-AVPair attribute. and you shouldn't require a second pool on your 7206. The pool would only serve a function if you were assigning on a per-authentication basis, were it would take a new ip from the pool for each new connection. You can use either a sql db or flatfile for the commands. Regards, -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Rhino Lists Sent: Monday, September 08, 2008 5:01 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] PPPOE Static IP I have a cisco 7206 terminating PPPOE DSL connections via Radius. I have a user who wants a static IP. Do I need to create another ip pool and how do I assign the IP in radius? K _______________________________________________ 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/ Please note: This email and its content are subject to the disclaimer as displayed at the following link http://www.is.co.za/legal/E-mail+Confidentiality+Notice+and+Disclaimer.htm. Should you not have Web access, send a mail to disclaimers at is.co.za and a copy will be emailed to you. From jfitz at Princeton.EDU Mon Sep 8 15:07:58 2008 From: jfitz at Princeton.EDU (Jeff Fitzwater) Date: Mon, 8 Sep 2008 15:07:58 -0400 Subject: [c-nsp] FWSM shun stats counter wrap Message-ID: <552765BB-21BB-4934-83D1-C6D5A7E52625@princeton.edu> Can anyone confirm that the counter for "show shun statistics" on a FWSM, is a 16 bit counter wrapping at 65K entries? If so is there any way to change it (which I doubt)? We are running 4.02 code and use the SHUN heavily. Thanks for any info. Jeff Fitzwater OIT Network Systems Princeton University From jfitz at Princeton.EDU Mon Sep 8 15:21:03 2008 From: jfitz at Princeton.EDU (Jeff Fitzwater) Date: Mon, 8 Sep 2008 15:21:03 -0400 Subject: [c-nsp] FWSM shun stats counter wrap In-Reply-To: <552765BB-21BB-4934-83D1-C6D5A7E52625@princeton.edu> References: <552765BB-21BB-4934-83D1-C6D5A7E52625@princeton.edu> Message-ID: Small correction to question. The counter in question, is a per host counter not the overall shun stats counter. If I have 20 hosts as SHUNed Inever see the counter per host go over 65K. Jeff On Sep 8, 2008, at 3:07 PM, Jeff Fitzwater wrote: > Can anyone confirm that the counter for "show shun statistics" on a > FWSM, is a 16 bit counter wrapping at 65K entries? If so is there > any way to change it (which I doubt)? > > We are running 4.02 code and use the SHUN heavily. > > > Thanks for any info. > > > 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 blahu77 at gmail.com Mon Sep 8 16:10:58 2008 From: blahu77 at gmail.com (=?ISO-8859-2?Q?Mateusz_B=B3aszczyk?=) Date: Mon, 8 Sep 2008 21:10:58 +0100 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080908135935.GS19347@rtp-cse-489.cisco.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> Message-ID: <383357750809081310t21fe1193rd07859b9571cc120@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rodney, >> 1) process switching which means invoking ip_input for every packet > > That is if you have CEF disabled. Let's forget the "ip fastswitching" > discussion because after 12.4(20)T it's gone. It's process or CEF only. That was a recall. It wasn't my intention to go to deep into this. > That means you have a lot of interrupt traffic transit the box and some > is getting punted to process level after a lookup in the rx CEF routines > or either further down the CEF switching vector due to a feature punt. [...] All right, My understanding of CEF mechanism was corrent. And you are saying the best way to actually check what these packets are is to push 12.4(20)T on to the box and start sniffing? >> Does it mean the NPE-G1 is not enough to process ~400Mbps/60kpps with >> ACL like above? > > Depends on the exact ACL and other features configured. Or by looking at the ACL you are able to pin point the "bad" acl statements? The acl (extended) looks like this (from memory-dump) ! deny rogue IPs (it is interesting how many catches are here) deny ip 10.0.0.0 .... any deny ip 192... any deny ip host 0.0.0.0 any etc.... ! deny spoofing us... deny ip any deny ip any ! pings and traceroute permit icmp any any permit udp any any range 32xxx 34xxx ! transit providers permit tcp host host eg bgp permit tcp host eq bgp host ! Internet eXchanges - bgp/msdp permit tcp host eg bgp permit tcp eq bgp host deny ip any deny ip any ! some legacy stuff permit ip any host ! deny access to infrastructure deny ip any ... deny ip any permit ip any any also (maybe worth noting) we got CAR for icmp packets enabled on the port on (input). > Probably normal. I'd suggest looking at the new ASR1000 that can do > ACL's in hardware. any significant advantage over entry-level 6500/7600? - -- - -mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIxYbSIvBv0k5esR4RAgksAJ0XKkxBNTLzTQ0/MbG/pBYU5YdkFQCgpU4j 5aVcJsL7GI0+aWXUoXKAPlk= =Bmcv -----END PGP SIGNATURE----- From blahu77 at gmail.com Mon Sep 8 16:15:31 2008 From: blahu77 at gmail.com (=?ISO-8859-2?Q?Mateusz_B=B3aszczyk?=) Date: Mon, 8 Sep 2008 21:15:31 +0100 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080908135935.GS19347@rtp-cse-489.cisco.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> Message-ID: <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 REPOST again as firegpg removed some important bits from acl.. Rodney, >> 1) process switching which means invoking ip_input for every packet > > That is if you have CEF disabled. Let's forget the "ip fastswitching" > discussion because after 12.4(20)T it's gone. It's process or CEF only. That was a recall. It wasn't my intention to go to deep into this. > That means you have a lot of interrupt traffic transit the box and some > is getting punted to process level after a lookup in the rx CEF routines > or either further down the CEF switching vector due to a feature punt. [...] All right, My understanding of CEF mechanism was corrent. And you are saying the best way to actually check what these packets are is to push 12.4(20)T on to the box and start sniffing? >> Does it mean the NPE-G1 is not enough to process ~400Mbps/60kpps with >> ACL like above? > > Depends on the exact ACL and other features configured. Or by looking at the ACL you are able to pin point the "bad" acl statements? The acl (extended) looks like this (from memory-dump) ! deny rogue IPs (it is interesting how many catches are here) deny ip 10.0.0.0 .... any deny ip 192... any deny ip host 0.0.0.0 any etc.... ! deny spoofing us... deny ip OURBLOCK1 any deny ip OURBLOCK2 any ! pings and traceroute permit icmp any any permit udp any any range 32xxx 34xxx ! transit providers permit tcp host THEM1 host US1 eg bgp permit tcp host THEM1 eq bgp host US1 ! Internet eXchanges - bgp/msdp permit tcp THEM2 WCARD2 host US2 eg bgp permit tcp THEM2 WCARD2 eq bgp host US2 deny ip any US1 deny ip any US2 ! some legacy stuff permit ip any host XXX ! deny access to infrastructure deny ip any NETWORK_1 ... deny ip any NETWORK_N permit ip any any also (maybe worth noting) we got CAR for icmp packets enabled on the port on (input). > Probably normal. I'd suggest looking at the new ASR1000 that can do > ACL's in hardware. any significant advantage over entry-level 6500/7600? - -- - -mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIxYfiIvBv0k5esR4RAhZOAKDNjB8soD4o7+JXpEeq4w8/y5Z9AACfXwO4 aykwTNGqUnKd8w/Ag3GBTug= =97La -----END PGP SIGNATURE----- From rodunn at cisco.com Mon Sep 8 16:35:49 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Mon, 8 Sep 2008 16:35:49 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> Message-ID: <20080908203549.GG23073@rtp-cse-489.cisco.com> > > > Probably normal. I'd suggest looking at the new ASR1000 that can do > > ACL's in hardware. > > any significant advantage over entry-level 6500/7600? You will see more midrange features moving forward with it most likely. Rodney > > > > - -- > - -mat > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIxYfiIvBv0k5esR4RAhZOAKDNjB8soD4o7+JXpEeq4w8/y5Z9AACfXwO4 > aykwTNGqUnKd8w/Ag3GBTug= > =97La > -----END PGP SIGNATURE----- From billf at mu.org Mon Sep 8 16:50:46 2008 From: billf at mu.org (bill fumerola) Date: Mon, 8 Sep 2008 13:50:46 -0700 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> Message-ID: <20080908205046.GK29172@elvis.mu.org> [ reading through quickly, just some ACL pointers.. ] On Mon, Sep 08, 2008 at 09:15:31PM +0100, Mateusz B?aszczyk wrote: > ! deny rogue IPs (it is interesting how many catches are here) > deny ip 10.0.0.0 .... any > deny ip 192... any > deny ip host 0.0.0.0 any this breaks PMTUD. icmp messages from poorly addressed routers still need to get back to your hosts. > etc.... > ! deny spoofing us... > deny ip OURBLOCK1 any > deny ip OURBLOCK2 any move to the top. > ! pings and traceroute > permit icmp any any either permit the specific ICMPs required for end to end communication to work and permit the rest after your anti-spoof, or just move this towards the top. > permit udp any any range 32xxx 34xxx rarely used, moved towards the bottom. > ! transit providers > permit tcp host THEM1 host US1 eg bgp > permit tcp host THEM1 eq bgp host US1 > ! Internet eXchanges - bgp/msdp > permit tcp THEM2 WCARD2 host US2 eg bgp > permit tcp THEM2 WCARD2 eq bgp host US2 > deny ip any US1 > deny ip any US2 rarely used, move towards bottom. consider removing the port-specific portions and see if you can get your ISP to use the TTL hack. > ! some legacy stuff > permit ip any host XXX move towards the top. > ! deny access to infrastructure > deny ip any NETWORK_1 > ... > deny ip any NETWORK_N sometimes, you can null route these blocks and use policy route-maps that set next-hop for your local device and/or management networks that allow the forwarding plane take care of discarding these > permit ip any any and here's where the majority of your traffic matches - at the bottom. this will kill performance. consider the trade-off of adding a: permit tcp any any established towards the top of your config. that rule will catch the majority of most networks' traffic. your deny rules below will still prevent SYN packets from getting through to your infrastructure space. yes, your 'infrastructure' will be open to ACK floods and other such things, but you can deploy other measures to assist with that. for example: ACLs on the interfaces facing your management network instead. also, if you run a service that represents the bulk of your traffic on that device, add a short-circuit rule for that service higher at the top, even if a rule with wider reach allows the same later. > any significant advantage over entry-level 6500/7600? 6500/7600 will be way less order dependent and you'll be able to have much longer ACLs. in my experience, on software platforms 99% of your traffic should either be permitted or denied in the first 5 or so rules or you're going to see serious performance problems. consider using 'access-list compiled' if your platform/IOS support it. distribute your ACLs as much as possible. take a multi layered approach. know your device's strengths and weaknesses when it comes to filtering and exploit those. -- bill From blahu77 at gmail.com Mon Sep 8 17:14:12 2008 From: blahu77 at gmail.com (=?ISO-8859-2?Q?Mateusz_B=B3aszczyk?=) Date: Mon, 8 Sep 2008 22:14:12 +0100 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080908205046.GK29172@elvis.mu.org> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> Message-ID: <383357750809081414t77efb2v7a0acb130a671e46@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill, very much thanks for that. It looks that I need a special ACL with 1 entry at the top covering half of the original :) I will work on it and report the results accordingly. 2008/9/8 bill fumerola : > [ reading through quickly, just some ACL pointers.. ] > > On Mon, Sep 08, 2008 at 09:15:31PM +0100, Mateusz B?aszczyk wrote: >> ! deny rogue IPs (it is interesting how many catches are here) >> deny ip 10.0.0.0 .... any >> deny ip 192... any >> deny ip host 0.0.0.0 any > > this breaks PMTUD. icmp messages from poorly addressed routers still > need to get back to your hosts. > >> etc.... >> ! deny spoofing us... >> deny ip OURBLOCK1 any >> deny ip OURBLOCK2 any > > move to the top. > >> ! pings and traceroute >> permit icmp any any > > either permit the specific ICMPs required for end to end communication > to work and permit the rest after your anti-spoof, or just move this > towards the top. > >> permit udp any any range 32xxx 34xxx > > rarely used, moved towards the bottom. > >> ! transit providers >> permit tcp host THEM1 host US1 eg bgp >> permit tcp host THEM1 eq bgp host US1 >> ! Internet eXchanges - bgp/msdp >> permit tcp THEM2 WCARD2 host US2 eg bgp >> permit tcp THEM2 WCARD2 eq bgp host US2 >> deny ip any US1 >> deny ip any US2 > > rarely used, move towards bottom. consider removing the port-specific > portions and see if you can get your ISP to use the TTL hack. > >> ! some legacy stuff >> permit ip any host XXX > > move towards the top. > >> ! deny access to infrastructure >> deny ip any NETWORK_1 >> ... >> deny ip any NETWORK_N > > > sometimes, you can null route these blocks and use policy route-maps > that set next-hop for your local device and/or management networks > that allow the forwarding plane take care of discarding these > > >> permit ip any any > > and here's where the majority of your traffic matches - at the bottom. > this will kill performance. consider the trade-off of adding a: > > permit tcp any any established > > towards the top of your config. that rule will catch the majority of > most networks' traffic. your deny rules below will still prevent SYN > packets from getting through to your infrastructure space. yes, your > 'infrastructure' will be open to ACK floods and other such things, but > you can deploy other measures to assist with that. for example: ACLs on > the interfaces facing your management network instead. > > also, if you run a service that represents the bulk of your traffic on > that device, add a short-circuit rule for that service higher at the > top, even if a rule with wider reach allows the same later. > >> any significant advantage over entry-level 6500/7600? > > 6500/7600 will be way less order dependent and you'll be able to have > much longer ACLs. in my experience, on software platforms 99% of your > traffic should either be permitted or denied in the first 5 or so rules > or you're going to see serious performance problems. > > consider using 'access-list compiled' if your platform/IOS support it. > > distribute your ACLs as much as possible. take a multi layered approach. > know your device's strengths and weaknesses when it comes to filtering > and exploit those. > > -- bill > - -- - -mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIxZWkIvBv0k5esR4RAi5bAJ9P4+P3+rWK46LV3U2Jf7E8whwN8wCfemqA I/nuXWZh52qSpiCq/uiPYnk= =b5nR -----END PGP SIGNATURE----- From mb at adv.gcomm.com.au Mon Sep 8 19:47:41 2008 From: mb at adv.gcomm.com.au (mb at adv.gcomm.com.au) Date: Tue, 09 Sep 2008 09:47:41 +1000 Subject: [c-nsp] Possible new bug in a 3750 stack In-Reply-To: <1220883139.8814.6.camel@dsba-ipso> References: <1220883139.8814.6.camel@dsba-ipso> Message-ID: <20080909094741.97k6t01qcin4cgs8@webmail.datafx.com.au> Quoting luismi : > Hi all, > > Is there anyone there with the same problem? > I have a 3750 stack with 2 switches running > flash:/c3750-ipservicesk9-mz.122-44.SE1.bin, the configuration is pretty > simple, just several port-channels. Hi, Running 2 x WS-C3750E-24TD-S in stack w/ c3750e-universal-mz.122-44.SE2.bin, and am not seeing this issue. MB ------------------------------------------------------------------------- This e-mail was sent via Data FX Online WebMail http://www.datafx.com.au/ From mb at adv.gcomm.com.au Mon Sep 8 19:35:57 2008 From: mb at adv.gcomm.com.au (mb at adv.gcomm.com.au) Date: Tue, 09 Sep 2008 09:35:57 +1000 Subject: [c-nsp] Tool(free?) to extract vlan+trunk info from Cat4003 Message-ID: <20080909093557.6dijkup7xdea88sk@webmail.datafx.com.au> Hi, We have a few old Cat4003's that we need to get all L2 Info from(All vlans/trunks etc) - Was hoping there was a tool(free) that could automate the task? Had a look at Cisco Network Assist, and enabled http server on the 4ks, but it looks like CNA is requesting info that does not exist on the 4003's: 2008 Sep 08 19:39:18 aest +10:00 %MGMT-5-HTTP_URINOTFOUND:Request for /exec/show/version/CR from client 0.0.0.0 not found 2008 Sep 08 19:39:18 aest +10:00 %MGMT-5-HTTP_URINOTFOUND:Request for /exec/show/version/CR from client 0.0.0.0 not found 2008 Sep 08 19:39:18 aest +10:00 %MGMT-5-HTTP_URINOTFOUND:Request for /exec/show/version/CR from client 0.0.0.0 not found 2008 Sep 08 19:39:19 aest +10:00 %MGMT-5-HTTP_URINOTFOUND:Request for /exec/show/version/CR from client 0.0.0.0 not found 2008 Sep 08 19:39:19 aest +10:00 %MGMT-5-HTTP_URINOTFOUND:Request for /screens/base/hw_info.html from client 0.0.0.0 not found 2008 Sep 08 19:39:19 aest +10:00 %MGMT-5-HTTP_URINOTFOUND:Request for /screens/base/hw_info.html from client 0.0.0.0 not found 2008 Sep 08 19:39:19 aest +10:00 %MGMT-5-HTTP_URINOTFOUND:Request for /screens/base/hw_info.html from client 0.0.0.0 not found ... Thanks in advance. ------------------------------------------------------------------------- This e-mail was sent via Data FX Online WebMail http://www.datafx.com.au/ From abalashov at evaristesys.com Tue Sep 9 00:31:13 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Tue, 09 Sep 2008 00:31:13 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080908205046.GK29172@elvis.mu.org> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> Message-ID: <48C5FC11.2020109@evaristesys.com> Are you _sure_ that order is important in these ACLs? I ask because I honestly don't know, so don't get me wrong. It just seems rather unlikely. Organising data like that into structures where matching and access can happen at more or less an O(1) formal computational complexity is a basic skill that is taught at the beginning of any undergraduate curriculum in computer science. Students are taught to understand that large amounts of random (non-sorted) data cannot be stored in a linear structure, and that even linear structures with comparatively few elements (such as an access list) can be very slow if the lookup is repeated with very great frequency. That's why such data gets stored in multidimensional and relational data structures: things like binary trees (and their innumerable permutations), undirected string vector graphs for heavy lexical token matching, hash tables, and various relational mechanisms for forming bindings or indices from a quick and superficial glimpse at the data. It's how every firewall/packet filtering engine (such as Linux netfilter, or the FreeBSD packet filter) is implemented, so packets are matched using a hashing strategy rather than linear, iterative comparisons. What you appear to be suggesting in your dwelling upon the significance of rules being at the bottom or top of an access list definition would also imply that these basic algorithmic innovations and elements of the software engineering canon have somehow managed, with great finesse, to escape the notice of the people who wrote IOS. I refuse to believe that. bill fumerola wrote: > [ reading through quickly, just some ACL pointers.. ] > > On Mon, Sep 08, 2008 at 09:15:31PM +0100, Mateusz B?aszczyk wrote: >> ! deny rogue IPs (it is interesting how many catches are here) >> deny ip 10.0.0.0 .... any >> deny ip 192... any >> deny ip host 0.0.0.0 any > > this breaks PMTUD. icmp messages from poorly addressed routers still > need to get back to your hosts. > >> etc.... >> ! deny spoofing us... >> deny ip OURBLOCK1 any >> deny ip OURBLOCK2 any > > move to the top. > >> ! pings and traceroute >> permit icmp any any > > either permit the specific ICMPs required for end to end communication > to work and permit the rest after your anti-spoof, or just move this > towards the top. > >> permit udp any any range 32xxx 34xxx > > rarely used, moved towards the bottom. > >> ! transit providers >> permit tcp host THEM1 host US1 eg bgp >> permit tcp host THEM1 eq bgp host US1 >> ! Internet eXchanges - bgp/msdp >> permit tcp THEM2 WCARD2 host US2 eg bgp >> permit tcp THEM2 WCARD2 eq bgp host US2 >> deny ip any US1 >> deny ip any US2 > > rarely used, move towards bottom. consider removing the port-specific > portions and see if you can get your ISP to use the TTL hack. > >> ! some legacy stuff >> permit ip any host XXX > > move towards the top. > >> ! deny access to infrastructure >> deny ip any NETWORK_1 >> ... >> deny ip any NETWORK_N > > > sometimes, you can null route these blocks and use policy route-maps > that set next-hop for your local device and/or management networks > that allow the forwarding plane take care of discarding these > > >> permit ip any any > > and here's where the majority of your traffic matches - at the bottom. > this will kill performance. consider the trade-off of adding a: > > permit tcp any any established > > towards the top of your config. that rule will catch the majority of > most networks' traffic. your deny rules below will still prevent SYN > packets from getting through to your infrastructure space. yes, your > 'infrastructure' will be open to ACK floods and other such things, but > you can deploy other measures to assist with that. for example: ACLs on > the interfaces facing your management network instead. > > also, if you run a service that represents the bulk of your traffic on > that device, add a short-circuit rule for that service higher at the > top, even if a rule with wider reach allows the same later. > >> any significant advantage over entry-level 6500/7600? > > 6500/7600 will be way less order dependent and you'll be able to have > much longer ACLs. in my experience, on software platforms 99% of your > traffic should either be permitted or denied in the first 5 or so rules > or you're going to see serious performance problems. > > consider using 'access-list compiled' if your platform/IOS support it. > > distribute your ACLs as much as possible. take a multi layered approach. > know your device's strengths and weaknesses when it comes to filtering > and exploit those. > > -- bill > _______________________________________________ > 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 Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From adrian at creative.net.au Tue Sep 9 00:32:31 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 9 Sep 2008 12:32:31 +0800 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <48C5FC11.2020109@evaristesys.com> References: <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> Message-ID: <20080909043231.GF16324@skywalker.creative.net.au> Bill is practically right. The semantics for Cisco ACLs aren't "here's a set of IP ranges, apply this behaviour", they're a linear walk of rules from top to bottom applying behaviour at each step. Collapsing that into the smallest set of possible operations is -not- taught at first/second year computer science. Eg: * permit ssh 1.2.3.0/24 * deny ssh 1.2.4.8/30 * permit ssh 1.2.0.0/16 * deny ssh 1.0.0.0/8 Please yank the first year computer science curriculum bit which provides the student with the clue required to algorithmically determine the smallest set of permit/deny's keeping the above semantics correct. Then do some basic analysis to find out what the resource bounds are on determining that. Oh, then prove that you can evaluate it in "more or less O(1) time". Go on, I dare you :) (Note: I -think- the TCAM ACL rule programming in later IOSes can do that? Perhaps Rodney or someone else from Cisco can comment.. :) There's some rule folding (and compiling?) stuff that I've heard about in later software-forwarding IOSes which attempt to mitigate this somewhat but I've never really sat down and (ab)used it. Now, I suggest you go back and read how iptables / ipfw / pf rules are actually -parsed- and -handled- in the various *NIXes you speak of. I've done this exercise and I'll give you a hint - rules are evaluated much the same as they are on the Cisco, except in some cases the evaluation doesn't stop at first hit and there are other gotchas (like "match X goto rule Y"). Go figure out why. I'll give you an even bigger hint - the best way to get a speedup under *NIX packet filters is to build "sets" of IP addresses to apply your policies rather than individual rules for each network you want to allow SSH for. The difference between one rule w/ a 200,000 network IP set versus 200,000 entries is pretty staggering - and the latter depends on the rule ordering. Just like Bill said. :) Adrian On Tue, Sep 09, 2008, Alex Balashov wrote: > Are you _sure_ that order is important in these ACLs? I ask because I > honestly don't know, so don't get me wrong. > > It just seems rather unlikely. Organising data like that into > structures where matching and access can happen at more or less an O(1) > formal computational complexity is a basic skill that is taught at the > beginning of any undergraduate curriculum in computer science. Students > are taught to understand that large amounts of random (non-sorted) data > cannot be stored in a linear structure, and that even linear structures > with comparatively few elements (such as an access list) can be very > slow if the lookup is repeated with very great frequency. > > That's why such data gets stored in multidimensional and relational data > structures: things like binary trees (and their innumerable > permutations), undirected string vector graphs for heavy lexical token > matching, hash tables, and various relational mechanisms for forming > bindings or indices from a quick and superficial glimpse at the data. > > It's how every firewall/packet filtering engine (such as Linux > netfilter, or the FreeBSD packet filter) is implemented, so packets are > matched using a hashing strategy rather than linear, iterative comparisons. > > What you appear to be suggesting in your dwelling upon the significance > of rules being at the bottom or top of an access list definition would > also imply that these basic algorithmic innovations and elements of the > software engineering canon have somehow managed, with great finesse, to > escape the notice of the people who wrote IOS. I refuse to believe that. > > bill fumerola wrote: > > >[ reading through quickly, just some ACL pointers.. ] > > > >On Mon, Sep 08, 2008 at 09:15:31PM +0100, Mateusz B?aszczyk wrote: > >>! deny rogue IPs (it is interesting how many catches are here) > >>deny ip 10.0.0.0 .... any > >>deny ip 192... any > >>deny ip host 0.0.0.0 any > > > >this breaks PMTUD. icmp messages from poorly addressed routers still > >need to get back to your hosts. > > > >>etc.... > >>! deny spoofing us... > >>deny ip OURBLOCK1 any > >>deny ip OURBLOCK2 any > > > >move to the top. > > > >>! pings and traceroute > >>permit icmp any any > > > >either permit the specific ICMPs required for end to end communication > >to work and permit the rest after your anti-spoof, or just move this > >towards the top. > > > >>permit udp any any range 32xxx 34xxx > > > >rarely used, moved towards the bottom. > > > >>! transit providers > >>permit tcp host THEM1 host US1 eg bgp > >>permit tcp host THEM1 eq bgp host US1 > >>! Internet eXchanges - bgp/msdp > >>permit tcp THEM2 WCARD2 host US2 eg bgp > >>permit tcp THEM2 WCARD2 eq bgp host US2 > >>deny ip any US1 > >>deny ip any US2 > > > >rarely used, move towards bottom. consider removing the port-specific > >portions and see if you can get your ISP to use the TTL hack. > > > >>! some legacy stuff > >>permit ip any host XXX > > > >move towards the top. > > > >>! deny access to infrastructure > >>deny ip any NETWORK_1 > >>... > >>deny ip any NETWORK_N > > > > > >sometimes, you can null route these blocks and use policy route-maps > >that set next-hop for your local device and/or management networks > >that allow the forwarding plane take care of discarding these > > > > > >>permit ip any any > > > >and here's where the majority of your traffic matches - at the bottom. > >this will kill performance. consider the trade-off of adding a: > > > >permit tcp any any established > > > >towards the top of your config. that rule will catch the majority of > >most networks' traffic. your deny rules below will still prevent SYN > >packets from getting through to your infrastructure space. yes, your > >'infrastructure' will be open to ACK floods and other such things, but > >you can deploy other measures to assist with that. for example: ACLs on > >the interfaces facing your management network instead. > > > >also, if you run a service that represents the bulk of your traffic on > >that device, add a short-circuit rule for that service higher at the > >top, even if a rule with wider reach allows the same later. > > > >>any significant advantage over entry-level 6500/7600? > > > >6500/7600 will be way less order dependent and you'll be able to have > >much longer ACLs. in my experience, on software platforms 99% of your > >traffic should either be permitted or denied in the first 5 or so rules > >or you're going to see serious performance problems. > > > >consider using 'access-list compiled' if your platform/IOS support it. > > > >distribute your ACLs as much as possible. take a multi layered approach. > >know your device's strengths and weaknesses when it comes to filtering > >and exploit those. > > > >-- bill > >_______________________________________________ > >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 > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (706) 338-8599 > _______________________________________________ > 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/ -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA - From abalashov at evaristesys.com Tue Sep 9 01:07:57 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Tue, 09 Sep 2008 01:07:57 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080909043231.GF16324@skywalker.creative.net.au> References: <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> <20080909043231.GF16324@skywalker.creative.net.au> Message-ID: <48C604AD.7080500@evaristesys.com> Are you serious? Well, I unhappily and disappointedly stand corrected, then. Indeed, Cisco documentation appears to confirm what you and Bill are saying. There are a variety of known algorithms for traversing hashed structures while taking order of precedence into account. I am, quite frankly, astonished that they are not used, or that it takes some sort of ASIC or TCAM enhancement to make that happen. Adrian Chadd wrote: > Bill is practically right. The semantics for Cisco ACLs aren't "here's a set > of IP ranges, apply this behaviour", they're a linear walk of rules from > top to bottom applying behaviour at each step. Collapsing that into the > smallest set of possible operations is -not- taught at first/second year > computer science. Eg: > > * permit ssh 1.2.3.0/24 > * deny ssh 1.2.4.8/30 > * permit ssh 1.2.0.0/16 > * deny ssh 1.0.0.0/8 > > Please yank the first year computer science curriculum bit which provides > the student with the clue required to algorithmically determine the smallest > set of permit/deny's keeping the above semantics correct. Then do some basic > analysis to find out what the resource bounds are on determining that. > Oh, then prove that you can evaluate it in "more or less O(1) time". Go on, > I dare you :) (Note: I -think- the TCAM ACL rule programming in later IOSes > can do that? Perhaps Rodney or someone else from Cisco can comment.. :) > > There's some rule folding (and compiling?) stuff that I've heard about in > later software-forwarding IOSes which attempt to mitigate this somewhat but > I've never really sat down and (ab)used it. > > Now, I suggest you go back and read how iptables / ipfw / pf rules > are actually -parsed- and -handled- in the various *NIXes you speak of. > I've done this exercise and I'll give you a hint - rules are evaluated > much the same as they are on the Cisco, except in some cases the evaluation > doesn't stop at first hit and there are other gotchas (like "match X goto rule > Y"). Go figure out why. > > I'll give you an even bigger hint - the best way to get a speedup under > *NIX packet filters is to build "sets" of IP addresses to apply your policies > rather than individual rules for each network you want to allow SSH for. > The difference between one rule w/ a 200,000 network IP set versus 200,000 > entries is pretty staggering - and the latter depends on the rule ordering. > Just like Bill said. :) > > > > > Adrian > > On Tue, Sep 09, 2008, Alex Balashov wrote: >> Are you _sure_ that order is important in these ACLs? I ask because I >> honestly don't know, so don't get me wrong. >> >> It just seems rather unlikely. Organising data like that into >> structures where matching and access can happen at more or less an O(1) >> formal computational complexity is a basic skill that is taught at the >> beginning of any undergraduate curriculum in computer science. Students >> are taught to understand that large amounts of random (non-sorted) data >> cannot be stored in a linear structure, and that even linear structures >> with comparatively few elements (such as an access list) can be very >> slow if the lookup is repeated with very great frequency. >> >> That's why such data gets stored in multidimensional and relational data >> structures: things like binary trees (and their innumerable >> permutations), undirected string vector graphs for heavy lexical token >> matching, hash tables, and various relational mechanisms for forming >> bindings or indices from a quick and superficial glimpse at the data. >> >> It's how every firewall/packet filtering engine (such as Linux >> netfilter, or the FreeBSD packet filter) is implemented, so packets are >> matched using a hashing strategy rather than linear, iterative comparisons. >> >> What you appear to be suggesting in your dwelling upon the significance >> of rules being at the bottom or top of an access list definition would >> also imply that these basic algorithmic innovations and elements of the >> software engineering canon have somehow managed, with great finesse, to >> escape the notice of the people who wrote IOS. I refuse to believe that. >> >> bill fumerola wrote: >> >>> [ reading through quickly, just some ACL pointers.. ] >>> >>> On Mon, Sep 08, 2008 at 09:15:31PM +0100, Mateusz B?aszczyk wrote: >>>> ! deny rogue IPs (it is interesting how many catches are here) >>>> deny ip 10.0.0.0 .... any >>>> deny ip 192... any >>>> deny ip host 0.0.0.0 any >>> this breaks PMTUD. icmp messages from poorly addressed routers still >>> need to get back to your hosts. >>> >>>> etc.... >>>> ! deny spoofing us... >>>> deny ip OURBLOCK1 any >>>> deny ip OURBLOCK2 any >>> move to the top. >>> >>>> ! pings and traceroute >>>> permit icmp any any >>> either permit the specific ICMPs required for end to end communication >>> to work and permit the rest after your anti-spoof, or just move this >>> towards the top. >>> >>>> permit udp any any range 32xxx 34xxx >>> rarely used, moved towards the bottom. >>> >>>> ! transit providers >>>> permit tcp host THEM1 host US1 eg bgp >>>> permit tcp host THEM1 eq bgp host US1 >>>> ! Internet eXchanges - bgp/msdp >>>> permit tcp THEM2 WCARD2 host US2 eg bgp >>>> permit tcp THEM2 WCARD2 eq bgp host US2 >>>> deny ip any US1 >>>> deny ip any US2 >>> rarely used, move towards bottom. consider removing the port-specific >>> portions and see if you can get your ISP to use the TTL hack. >>> >>>> ! some legacy stuff >>>> permit ip any host XXX >>> move towards the top. >>> >>>> ! deny access to infrastructure >>>> deny ip any NETWORK_1 >>>> ... >>>> deny ip any NETWORK_N >>> >>> sometimes, you can null route these blocks and use policy route-maps >>> that set next-hop for your local device and/or management networks >>> that allow the forwarding plane take care of discarding these >>> >>> >>>> permit ip any any >>> and here's where the majority of your traffic matches - at the bottom. >>> this will kill performance. consider the trade-off of adding a: >>> >>> permit tcp any any established >>> >>> towards the top of your config. that rule will catch the majority of >>> most networks' traffic. your deny rules below will still prevent SYN >>> packets from getting through to your infrastructure space. yes, your >>> 'infrastructure' will be open to ACK floods and other such things, but >>> you can deploy other measures to assist with that. for example: ACLs on >>> the interfaces facing your management network instead. >>> >>> also, if you run a service that represents the bulk of your traffic on >>> that device, add a short-circuit rule for that service higher at the >>> top, even if a rule with wider reach allows the same later. >>> >>>> any significant advantage over entry-level 6500/7600? >>> 6500/7600 will be way less order dependent and you'll be able to have >>> much longer ACLs. in my experience, on software platforms 99% of your >>> traffic should either be permitted or denied in the first 5 or so rules >>> or you're going to see serious performance problems. >>> >>> consider using 'access-list compiled' if your platform/IOS support it. >>> >>> distribute your ACLs as much as possible. take a multi layered approach. >>> know your device's strengths and weaknesses when it comes to filtering >>> and exploit those. >>> >>> -- bill >>> _______________________________________________ >>> 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 >> Evariste Systems >> Web : http://www.evaristesys.com/ >> Tel : (+1) (678) 954-0670 >> Direct : (+1) (678) 954-0671 >> Mobile : (+1) (706) 338-8599 >> _______________________________________________ >> 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 Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From adrian at creative.net.au Tue Sep 9 02:10:45 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 9 Sep 2008 14:10:45 +0800 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <72D7D15A-D2B7-4FC8-97C3-C788AD760DD2@bitgravity.com> References: <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> <20080909043231.GF16324@skywalker.creative.net.au> <72D7D15A-D2B7-4FC8-97C3-C788AD760DD2@bitgravity.com> Message-ID: <20080909061044.GI16324@skywalker.creative.net.au> On Mon, Sep 08, 2008, David Hawthorne wrote: > btw, one of the surprising tricks we learned was that the range > start_port end_port specification won't fill up TCAM on the 6500/7600 > IFF your port ranges fall on bit boundaries just like networks do. I'm sure I've read that documented somewhere. which isn't surprising if "port range" in TCAM is implemented using mask/eval like IP address matching - I guess it'd have to create one mask and multiple match entries to represent your non-contig bit port boundaries. (That may be the motivation behind the earlier TCAM of "limited masks/lots more matches" .. ?) Anyway, too much armchair conjecture from this non-neteng.. back to coding. :) Adrian From rubensk at gmail.com Tue Sep 9 02:21:18 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Tue, 9 Sep 2008 03:21:18 -0300 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <48C604AD.7080500@evaristesys.com> References: <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> <20080909043231.GF16324@skywalker.creative.net.au> <48C604AD.7080500@evaristesys.com> Message-ID: <6bb5f5b10809082321w4069eb8fj735b712ea31840fa@mail.gmail.com> Such algorithms are indeed used, as you can see at the IOS reference for the "access-list compiled" command where the ACL is converted to a data structure that is O(1). I don't know which algorithm they use in IOS nowadays, but for a very good reference on all of those algorithms (using RAM or CAM), I recommend this paper: "Survey and Taxonomy of Packet Classification Techniques" by David E. Taylor: http://www.cse.seas.wustl.edu/Research/FileDownload.asp?334 Rubens On Tue, Sep 9, 2008 at 2:07 AM, Alex Balashov wrote: > Are you serious? > > Well, I unhappily and disappointedly stand corrected, then. Indeed, Cisco > documentation appears to confirm what you and Bill are saying. > > There are a variety of known algorithms for traversing hashed structures > while taking order of precedence into account. I am, quite frankly, > astonished that they are not used, or that it takes some sort of ASIC or > TCAM enhancement to make that happen. > > > > Adrian Chadd wrote: > >> Bill is practically right. The semantics for Cisco ACLs aren't "here's a >> set >> of IP ranges, apply this behaviour", they're a linear walk of rules from >> top to bottom applying behaviour at each step. Collapsing that into the >> smallest set of possible operations is -not- taught at first/second year >> computer science. Eg: >> >> * permit ssh 1.2.3.0/24 >> * deny ssh 1.2.4.8/30 >> * permit ssh 1.2.0.0/16 >> * deny ssh 1.0.0.0/8 >> >> Please yank the first year computer science curriculum bit which provides >> the student with the clue required to algorithmically determine the >> smallest >> set of permit/deny's keeping the above semantics correct. Then do some >> basic >> analysis to find out what the resource bounds are on determining that. >> Oh, then prove that you can evaluate it in "more or less O(1) time". Go >> on, >> I dare you :) (Note: I -think- the TCAM ACL rule programming in later >> IOSes >> can do that? Perhaps Rodney or someone else from Cisco can comment.. :) >> >> There's some rule folding (and compiling?) stuff that I've heard about in >> later software-forwarding IOSes which attempt to mitigate this somewhat >> but >> I've never really sat down and (ab)used it. >> >> Now, I suggest you go back and read how iptables / ipfw / pf rules >> are actually -parsed- and -handled- in the various *NIXes you speak of. >> I've done this exercise and I'll give you a hint - rules are evaluated >> much the same as they are on the Cisco, except in some cases the >> evaluation >> doesn't stop at first hit and there are other gotchas (like "match X goto >> rule >> Y"). Go figure out why. >> >> I'll give you an even bigger hint - the best way to get a speedup under >> *NIX packet filters is to build "sets" of IP addresses to apply your >> policies >> rather than individual rules for each network you want to allow SSH for. >> The difference between one rule w/ a 200,000 network IP set versus 200,000 >> entries is pretty staggering - and the latter depends on the rule >> ordering. >> Just like Bill said. :) >> >> >> >> >> Adrian >> >> On Tue, Sep 09, 2008, Alex Balashov wrote: >>> >>> Are you _sure_ that order is important in these ACLs? I ask because I >>> honestly don't know, so don't get me wrong. >>> >>> It just seems rather unlikely. Organising data like that into structures >>> where matching and access can happen at more or less an O(1) formal >>> computational complexity is a basic skill that is taught at the beginning of >>> any undergraduate curriculum in computer science. Students are taught to >>> understand that large amounts of random (non-sorted) data cannot be stored >>> in a linear structure, and that even linear structures with comparatively >>> few elements (such as an access list) can be very slow if the lookup is >>> repeated with very great frequency. >>> >>> That's why such data gets stored in multidimensional and relational data >>> structures: things like binary trees (and their innumerable permutations), >>> undirected string vector graphs for heavy lexical token matching, hash >>> tables, and various relational mechanisms for forming bindings or indices >>> from a quick and superficial glimpse at the data. >>> >>> It's how every firewall/packet filtering engine (such as Linux netfilter, >>> or the FreeBSD packet filter) is implemented, so packets are matched using a >>> hashing strategy rather than linear, iterative comparisons. >>> >>> What you appear to be suggesting in your dwelling upon the significance >>> of rules being at the bottom or top of an access list definition would also >>> imply that these basic algorithmic innovations and elements of the software >>> engineering canon have somehow managed, with great finesse, to escape the >>> notice of the people who wrote IOS. I refuse to believe that. >>> >>> bill fumerola wrote: >>> >>>> [ reading through quickly, just some ACL pointers.. ] >>>> >>>> On Mon, Sep 08, 2008 at 09:15:31PM +0100, Mateusz B?aszczyk wrote: >>>>> >>>>> ! deny rogue IPs (it is interesting how many catches are here) >>>>> deny ip 10.0.0.0 .... any >>>>> deny ip 192... any >>>>> deny ip host 0.0.0.0 any >>>> >>>> this breaks PMTUD. icmp messages from poorly addressed routers still >>>> need to get back to your hosts. >>>> >>>>> etc.... >>>>> ! deny spoofing us... >>>>> deny ip OURBLOCK1 any >>>>> deny ip OURBLOCK2 any >>>> >>>> move to the top. >>>> >>>>> ! pings and traceroute >>>>> permit icmp any any >>>> >>>> either permit the specific ICMPs required for end to end communication >>>> to work and permit the rest after your anti-spoof, or just move this >>>> towards the top. >>>> >>>>> permit udp any any range 32xxx 34xxx >>>> >>>> rarely used, moved towards the bottom. >>>> >>>>> ! transit providers >>>>> permit tcp host THEM1 host US1 eg bgp >>>>> permit tcp host THEM1 eq bgp host US1 >>>>> ! Internet eXchanges - bgp/msdp >>>>> permit tcp THEM2 WCARD2 host US2 eg bgp >>>>> permit tcp THEM2 WCARD2 eq bgp host US2 >>>>> deny ip any US1 >>>>> deny ip any US2 >>>> >>>> rarely used, move towards bottom. consider removing the port-specific >>>> portions and see if you can get your ISP to use the TTL hack. >>>> >>>>> ! some legacy stuff >>>>> permit ip any host XXX >>>> >>>> move towards the top. >>>> >>>>> ! deny access to infrastructure >>>>> deny ip any NETWORK_1 >>>>> ... >>>>> deny ip any NETWORK_N >>>> >>>> >>>> sometimes, you can null route these blocks and use policy route-maps >>>> that set next-hop for your local device and/or management networks >>>> that allow the forwarding plane take care of discarding these >>>> >>>> >>>>> permit ip any any >>>> >>>> and here's where the majority of your traffic matches - at the bottom. >>>> this will kill performance. consider the trade-off of adding a: >>>> >>>> permit tcp any any established >>>> >>>> towards the top of your config. that rule will catch the majority of >>>> most networks' traffic. your deny rules below will still prevent SYN >>>> packets from getting through to your infrastructure space. yes, your >>>> 'infrastructure' will be open to ACK floods and other such things, but >>>> you can deploy other measures to assist with that. for example: ACLs on >>>> the interfaces facing your management network instead. >>>> >>>> also, if you run a service that represents the bulk of your traffic on >>>> that device, add a short-circuit rule for that service higher at the >>>> top, even if a rule with wider reach allows the same later. >>>> >>>>> any significant advantage over entry-level 6500/7600? >>>> >>>> 6500/7600 will be way less order dependent and you'll be able to have >>>> much longer ACLs. in my experience, on software platforms 99% of your >>>> traffic should either be permitted or denied in the first 5 or so rules >>>> or you're going to see serious performance problems. >>>> >>>> consider using 'access-list compiled' if your platform/IOS support it. >>>> >>>> distribute your ACLs as much as possible. take a multi layered approach. >>>> know your device's strengths and weaknesses when it comes to filtering >>>> and exploit those. >>>> >>>> -- bill >>>> _______________________________________________ >>>> 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 >>> Evariste Systems >>> Web : http://www.evaristesys.com/ >>> Tel : (+1) (678) 954-0670 >>> Direct : (+1) (678) 954-0671 >>> Mobile : (+1) (706) 338-8599 >>> _______________________________________________ >>> 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 > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (706) 338-8599 > _______________________________________________ > 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 reuben-cisco-nsp at reub.net Tue Sep 9 01:50:10 2008 From: reuben-cisco-nsp at reub.net (Reuben Farrelly) Date: Tue, 09 Sep 2008 15:50:10 +1000 Subject: [c-nsp] 12.40(20T), pppoe woes In-Reply-To: <70B7A1CCBFA5C649BD562B6D9F7ED78405F80226@xmb-ams-333.emea.cisco.com> References: <70B7A1CCBFA5C649BD562B6D9F7ED78405F80226@xmb-ams-333.emea.cisco.com> Message-ID: <48C60E92.3000600@reub.net> On 8/09/2008 8:43 PM, Oliver Boehmer (oboehmer) wrote: > David, > > please check CSCsu35584, it will be fixed in the upcoming 12.4(20)T1 > rebuild and the above restriction will be removed.. > > oli Hi Oli, What is the approximate timeframe on 12.4(20)T1? I'm asking because I'd really like to upgrade to 12.4(20)T but when I did all manner of things broke badly - most notably Zone Based Firewall (CSCsq43934 and CSCsr58052) and SIP registration (CSCsq85615, CSCsr00711). ie it wasn't a pleasant experience. Fortunately 12.4(15)T7 is pretty good now so that's my downgrade path but still... Reuben From dhawth at bitgravity.com Tue Sep 9 02:06:28 2008 From: dhawth at bitgravity.com (David Hawthorne) Date: Mon, 8 Sep 2008 23:06:28 -0700 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080909043231.GF16324@skywalker.creative.net.au> References: <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> <20080909043231.GF16324@skywalker.creative.net.au> Message-ID: <72D7D15A-D2B7-4FC8-97C3-C788AD760DD2@bitgravity.com> On Sep 8, 2008, at 9:32 PM, Adrian Chadd wrote: > Bill is practically right. The semantics for Cisco ACLs aren't > "here's a set > of IP ranges, apply this behaviour", they're a linear walk of rules > from > top to bottom applying behaviour at each step. Collapsing that into > the > smallest set of possible operations is -not- taught at first/second > year > computer science. Eg: > > * permit ssh 1.2.3.0/24 > * deny ssh 1.2.4.8/30 > * permit ssh 1.2.0.0/16 > * deny ssh 1.0.0.0/8 > > Please yank the first year computer science curriculum bit which > provides > the student with the clue required to algorithmically determine the > smallest > set of permit/deny's keeping the above semantics correct. Then do > some basic > analysis to find out what the resource bounds are on determining that. > Oh, then prove that you can evaluate it in "more or less O(1) time". > Go on, > I dare you :) (Note: I -think- the TCAM ACL rule programming in > later IOSes > can do that? Perhaps Rodney or someone else from Cisco can > comment.. :) > > There's some rule folding (and compiling?) stuff that I've heard > about in > later software-forwarding IOSes which attempt to mitigate this > somewhat but > I've never really sat down and (ab)used it. > Nice. I actually worked at $big_company during and after Bill's tenure there, and I had to step into his rather large boots developing the ACL system after he left. By the time I was done, we actually had all of that, because we has run into issues with filling up TCAM on those 6500s and needed to get some aggregation and cruft-removal done. TCAM is used for quite a few things in IOS, as you're probably aware. I couldn't get it any better than O(n!), and it took forever and a day to run against all of the ACLs, although that was due in part to the fact that Junipers allow multiple source and destination subnets and port ranges and protocols to have to test against. The ACLs were also mind-bogglingly huge. Cisco rules were like very skinny Juniper terms, so they went pretty quick. It's surprisingly simple once you can get the ACLs parsed into a consistent data structure, assuming you're dealing primarily with the common case as given above and not dealing with special actions. So it *has* been done. Just not at Cisco. Necessity is the mother of invention. :p btw, one of the surprising tricks we learned was that the range start_port end_port specification won't fill up TCAM on the 6500/7600 IFF your port ranges fall on bit boundaries just like networks do. From thotta at gmail.com Tue Sep 9 02:59:40 2008 From: thotta at gmail.com (Takao Hotta) Date: Tue, 9 Sep 2008 15:59:40 +0900 Subject: [c-nsp] changing the number of equal-cost paths Message-ID: <5a2269f70809082359h36562fe2h7340df992a749fb6@mail.gmail.com> Hi, I would like to change the number of ospf ecmp by using the maximum-paths command for up to six equal-cost paths on Cisco 12406. But I am worried about the impacts on routing/cef/connection for spf recalculation. Things is it has 6 links now, but ecmp number was like default (four). Anyone know any ideas for configuration change without packet loss/drops as much as possible? Thanks in advance. Takao From matt at iseek.com.au Tue Sep 9 02:35:55 2008 From: matt at iseek.com.au (Matt Carter) Date: Tue, 9 Sep 2008 16:35:55 +1000 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <48C604AD.7080500@evaristesys.com> References: <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> <20080909043231.GF16324@skywalker.creative.net.au> <48C604AD.7080500@evaristesys.com> Message-ID: <7FEDD455961B164D8C4EEA60E22914205B78D56F50@EXCHANGE1.intranet.iseek.com.au> > Are you serious? > > Well, I unhappily and disappointedly stand corrected, then. Indeed, > Cisco documentation appears to confirm what you and Bill are saying. > > There are a variety of known algorithms for traversing hashed > structures > while taking order of precedence into account. I am, quite frankly, > astonished that they are not used, or that it takes some sort of ASIC > or > TCAM enhancement to make that happen. Turbo (compiled) ACL's was previously mentioned in this thread - have you looked at those ?? The Turbo ACL feature compiles the ACLs into a set of lookup tables, while maintaining the first match requirements. Packet headers are used to access these tables in a small, fixed number of lookups, independently of the existing number of ACL entries. The benefits of this feature include: *For ACLs longer than three entries, the CPU load required to match the packet to the predetermined packet-matching rule is lessened. The CPU load is fixed, regardless of the size of the ACL, allowing for larger ACLs without incurring any CPU overhead penalties. The larger the ACL, the greater the benefit. *The time taken to match the packet is fixed, so that latency of the packets is smaller (substantially in the case of large ACLs) and more importantly, consistent, allowing better network stability and more accurate transit times. From matt at iseek.com.au Tue Sep 9 02:32:00 2008 From: matt at iseek.com.au (Matt Carter) Date: Tue, 9 Sep 2008 16:32:00 +1000 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <48C5FC11.2020109@evaristesys.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> Message-ID: <7FEDD455961B164D8C4EEA60E22914205B78D56F4F@EXCHANGE1.intranet.iseek.com.au> > Are you _sure_ that order is important in these ACLs? I ask because I > honestly don't know, so don't get me wrong. yes it is.. i have seen software based platforms knock 10-20% cpu off by reworking very poorly laid out ACL's in a "top down" fashion. > > It just seems rather unlikely. Organising data like that into > structures where matching and access can happen at more or less an O(1) > formal computational complexity is a basic skill that is taught at the > beginning of any undergraduate curriculum in computer science. > Students > are taught to understand that large amounts of random (non-sorted) data > cannot be stored in a linear structure, and that even linear structures > with comparatively few elements (such as an access list) can be very > slow if the lookup is repeated with very great frequency. aren't we doing some kind of eval on our current lists before applying a new one? like i'm thinking 1) fire up the ACL leave it running for a while, look at the number of hits per ACL entry, and rework the ACL such that the maximum number of hits is at the top. 2) shortcut ACL's as bill mentioned eg, consider the following ACL 5 deny udp host 10 deny udp host 20 deny udp host 25 permit ip any presume that 60% of your traffic is TCP. all of this traffic is having to drop through 3 denies before it gets permitted. you could save a significant amount of processing by simply putting 1 permit tcp 5 deny udp host 10 deny udp host 20 deny udp host 25 permit ip any sure, you are doubling up in what is permitted because the TCP would have hit the permit ip any at the bottom anyway, but you are saving a considerable amount of processing by having 60% of your traffic match the first ACL entry. sure, oversimplified, but if you can't permit tcp outright, consider a permit established before you start denying other tcp bits and pieces, because more often than not the majority of traffic being forwarded is established. so in regards to having IOS reorganise the ACL for you that would have to make the assumption that the IOS has the capability to work out what is the ACL entries that are getting the most matches, in order to reorganise them, it isnt going to be able to predict this for you. in regards to shortcut ACL's i seriously doubt any time in the near future IOS is going to help you in this regard. do some netflow analysis and work out your traffic mix, look at your security requirements and develop an ACL that encompasses both considerations. From abalashov at evaristesys.com Tue Sep 9 04:04:46 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Tue, 09 Sep 2008 04:04:46 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <7FEDD455961B164D8C4EEA60E22914205B78D56F4F@EXCHANGE1.intranet.iseek.com.au> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> <7FEDD455961B164D8C4EEA60E22914205B78D56F4F@EXCHANGE1.intranet.iseek.com.au> Message-ID: <48C62E1E.2080805@evaristesys.com> Just to be clear, in case it isn't, I was not referring to how the ACLs are organised from the user perspective, presentation-wise, but rather I was surprised that they are not all put into an optimised data structure on the back side by IOS by default so that matching can happen with somewhere between O(1) and O(n) performance. Thank you all for the enlightenment on compiled/turbo ACLs. It makes me wonder whether the reason why routers are generally considered a poorer solution for extensive ACL duty than PIXs or ASAs. Does the PIX use compiled ACLs by default? Or perhaps there is some sort of extremely helpful ACIC-driven optimisation that they provide? Matt Carter wrote: >> Are you _sure_ that order is important in these ACLs? I ask because I >> honestly don't know, so don't get me wrong. > > yes it is.. i have seen software based platforms knock 10-20% cpu off by reworking very poorly laid out ACL's in a "top down" fashion. > >> It just seems rather unlikely. Organising data like that into >> structures where matching and access can happen at more or less an O(1) >> formal computational complexity is a basic skill that is taught at the >> beginning of any undergraduate curriculum in computer science. >> Students >> are taught to understand that large amounts of random (non-sorted) data >> cannot be stored in a linear structure, and that even linear structures >> with comparatively few elements (such as an access list) can be very >> slow if the lookup is repeated with very great frequency. > > aren't we doing some kind of eval on our current lists before applying a new one? like i'm thinking > > 1) fire up the ACL leave it running for a while, look at the number of hits per ACL entry, and rework the ACL such that the maximum number of hits is at the top. > > 2) shortcut ACL's as bill mentioned > eg, consider the following ACL > > 5 deny udp host > 10 deny udp host > 20 deny udp host > 25 permit ip any > > presume that 60% of your traffic is TCP. all of this traffic is having to drop through 3 denies before it gets permitted. you could save a significant amount of processing by simply putting > > 1 permit tcp > 5 deny udp host > 10 deny udp host > 20 deny udp host > 25 permit ip any > > sure, you are doubling up in what is permitted because the TCP would have hit the permit ip any at the bottom anyway, but you are saving a considerable amount of processing by having 60% of your traffic match the first ACL entry. sure, oversimplified, but if you can't permit tcp outright, consider a permit established before you start denying other tcp bits and pieces, because more often than not the majority of traffic being forwarded is established. > > so in regards to having IOS reorganise the ACL for you that would have to make the assumption that the IOS has the capability to work out what is the ACL entries that are getting the most matches, in order to reorganise them, it isnt going to be able to predict this for you. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From abalashov at evaristesys.com Tue Sep 9 04:28:27 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Tue, 09 Sep 2008 04:28:27 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080909043231.GF16324@skywalker.creative.net.au> References: <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> <20080909043231.GF16324@skywalker.creative.net.au> Message-ID: <48C633AB.1010209@evaristesys.com> Adrian Chadd wrote: > Please yank the first year computer science curriculum bit which provides > the student with the clue required to algorithmically determine the smallest > set of permit/deny's keeping the above semantics correct. Then do some basic > analysis to find out what the resource bounds are on determining that. > Oh, then prove that you can evaluate it in "more or less O(1) time". Go on, > I dare you :) You're right - point definitely taken. :) Without wanting to get into a discussion about the relative merits of sundry CS curricula: I didn't mean that the solution to this exact problem, or close variants of it, are taught in introductory CS. What I meant was more that the underlying, formal methodological intuitions are taught, or at least should be taught, as far as I know, as a key pedagogical point. In other words, it ought to occur to someone doing this type of implementation that subjecting thousands to tens of thousands of packets per second to one or more sets of linear evaluations of arbitrary size is going to be murderously inefficient, and that a different approach should be taken. I don't know a lot about the hardware anatomy of a lot of these devices, and especially the ASIC-assisted software components. But I do know their overall processing power is not typically very much, in the grand scheme of things, as compared to commodity PC hardware, so if they are handling some of the PPS loads we're discussing every day, then surely the data structures in which these endless webs of ACLs are stored and which are traversed when matching ACL criteria are not simple, naive linear lists. I haven't done a detailed study, of course, and that seems impossible to do without some access to IOS internals, but from an intuitive perspective as a systems developer it seems computationally impossible. Of course, the fact that I, personally, find something counterintuitive is no testament of any scientific credibility to its impossibility or nonexistence. :) > Now, I suggest you go back and read how iptables / ipfw / pf rules > are actually -parsed- and -handled- in the various *NIXes you speak of. > I've done this exercise and I'll give you a hint - rules are evaluated > much the same as they are on the Cisco, except in some cases the evaluation > doesn't stop at first hit and there are other gotchas (like "match X goto rule > Y"). Go figure out why. I know how they are parsed and evaluated from a superficial perspective. Our observational language and our ontology about these rules is founded to a great extent on the linear form and order of precedence that those rules take in the user interface and the state machine that is described to us. What I was taking for granted is that in the back end of the packet filter, implemented inside the cavernous interior of the kernel beyond the reach of various APIs, libraries and state databases, these rules take a very different form than what is handed to the user or accessor in the representational realm. It seems fairly obvious that there must be some very erudite, learned hashing or tree-building going on. -- Alex -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From ross at kallisti.us Tue Sep 9 09:07:32 2008 From: ross at kallisti.us (Ross Vandegrift) Date: Tue, 9 Sep 2008 09:07:32 -0400 Subject: [c-nsp] Tool(free?) to extract vlan+trunk info from Cat4003 In-Reply-To: <20080909093557.6dijkup7xdea88sk@webmail.datafx.com.au> References: <20080909093557.6dijkup7xdea88sk@webmail.datafx.com.au> Message-ID: <20080909130732.GA26295@kallisti.us> On Tue, Sep 09, 2008 at 09:35:57AM +1000, mb at adv.gcomm.com.au wrote: > Hi, > > We have a few old Cat4003's that we need to get all L2 Info from(All > vlans/trunks etc) - Was hoping there was a tool(free) that could > automate the task? > > Had a look at Cisco Network Assist, and enabled http server on the 4ks, > but it looks like CNA is requesting info that does not exist on the > 4003's: Is SNMP an option? You can look at CISCO-VTP-MIB::vlanTrunkPortDynamicStatus to find out the trunking status of an interface. vlanTrunkPortVlansEnabled* will give you a bitmask of the vlans that are permitted on a trunk. vtpVlanName and vtpVlanState will tell you the basic info on a given vlan. CISCO-VLAN-MEMBERSHIP-MIB::vmVlan will show you vlans assigned to access ports. -- Ross Vandegrift ross at kallisti.us "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 From maillist at webjogger.net Tue Sep 9 09:41:54 2008 From: maillist at webjogger.net (Adam Greene) Date: Tue, 9 Sep 2008 09:41:54 -0400 Subject: [c-nsp] iBGP Multi-link question References: Message-ID: <3D1D76D4036E45069BC1820B6548FBE0@GINKGO> Jeff, in my experience having multiple BGP sessions between two routers, with different end-points for each session, works fine ... ----- Original Message ----- From: "Jeff Cartier" To: Sent: Monday, September 08, 2008 11:45 AM Subject: [c-nsp] iBGP Multi-link question > I'm in a scenario where I have two routers, configured with two > loopbacks, connected together via two links. I'm in the process of > transitioning from one loopback to the other and I was wondering if > there are any caveats to having two sessions up...one BGP session to the > first lookback (existing), then another BGP session up to the second > loopback (new). > > > > I don't believe their should be any issues with this...and I don't see > any documentation suggesting otherwise...just thought I'd ask to be > certain :-) > > > > ROUTER1============ROUTER2 > > Lo1:10.1.1.1/32 Lo1:10.1.2.1/32 > > Lo2:10.1.1.2/32 Lo2:10.1.2.2/32 > > _______________________________________________ > 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 rodunn at cisco.com Tue Sep 9 09:48:34 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 9 Sep 2008 09:48:34 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <7FEDD455961B164D8C4EEA60E22914205B78D56F50@EXCHANGE1.intranet.iseek.com.au> References: <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> <20080909043231.GF16324@skywalker.creative.net.au> <48C604AD.7080500@evaristesys.com> <7FEDD455961B164D8C4EEA60E22914205B78D56F50@EXCHANGE1.intranet.iseek.com.au> Message-ID: <20080909134834.GB624@rtp-cse-489.cisco.com> Don't use TACL's on the software platforms. It has been removed from the CLI for the ISR's (it shouldn't have slipped in to begin with). There are very difficult challenges to handle for things such as updating the ACL on configuration change, memory usage, etc. Most HW forwarding platforms merge the ACL's in some fashion to reduce the footprint size. In IOS there is a Trie based ACL now over the linear format. It's on by default and you can't change it. Rodney On Tue, Sep 09, 2008 at 04:35:55PM +1000, Matt Carter wrote: > > Are you serious? > > > > Well, I unhappily and disappointedly stand corrected, then. Indeed, > > Cisco documentation appears to confirm what you and Bill are saying. > > > > There are a variety of known algorithms for traversing hashed > > structures > > while taking order of precedence into account. I am, quite frankly, > > astonished that they are not used, or that it takes some sort of ASIC > > or > > TCAM enhancement to make that happen. > > Turbo (compiled) ACL's was previously mentioned in this thread - have you looked at those ?? > > The Turbo ACL feature compiles the ACLs into a set of lookup tables, while maintaining the first match requirements. Packet headers are used to access these tables in a small, fixed number of lookups, independently of the existing number of ACL entries. The benefits of this feature include: > > *For ACLs longer than three entries, the CPU load required to match the packet to the predetermined packet-matching rule is lessened. The CPU load is fixed, regardless of the size of the ACL, allowing for larger ACLs without incurring any CPU overhead penalties. The larger the ACL, the greater the benefit. > > *The time taken to match the packet is fixed, so that latency of the packets is smaller (substantially in the case of large ACLs) and more importantly, consistent, allowing better network stability and more accurate transit times. > > > > > _______________________________________________ > 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 rodunn at cisco.com Tue Sep 9 09:50:59 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 9 Sep 2008 09:50:59 -0400 Subject: [c-nsp] changing the number of equal-cost paths In-Reply-To: <5a2269f70809082359h36562fe2h7340df992a749fb6@mail.gmail.com> References: <5a2269f70809082359h36562fe2h7340df992a749fb6@mail.gmail.com> Message-ID: <20080909135058.GC624@rtp-cse-489.cisco.com> The packet loss would be very very minimal. Users most likely will not even notice it. Your biggest worry in these environments is the hw programming resources and memory usage when you go with so many dual paths. Just be aware of that and make sure your hw programming LC's can support it. Rodney On Tue, Sep 09, 2008 at 03:59:40PM +0900, Takao Hotta wrote: > Hi, > > I would like to change the number of ospf ecmp by using the > maximum-paths command for up to six equal-cost paths on Cisco 12406. > But I am worried about the impacts on routing/cef/connection for spf > recalculation. Things is it has 6 links now, but ecmp number was like > default (four). Anyone know any ideas for configuration change > without packet loss/drops as much as possible? > > Thanks in advance. > Takao > _______________________________________________ > 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 rens at autempspourmoi.be Tue Sep 9 10:01:52 2008 From: rens at autempspourmoi.be (Rens) Date: Tue, 9 Sep 2008 16:01:52 +0200 Subject: [c-nsp] Errors before boot loader Message-ID: <81FF162258F4476DAC6190201B439281@EU.corp.clearwire.com> Hi, Should I worry about errors that are sent from the boot loader? %SYS-4-CONFIG_NEWER: Configuration from version 12.4 may not be correctly understood %AAAA-4-SERVUNDEF: The server-group "tacacs+" is not defined. Please define it. %AAAA-4-SERVUNDEF: The server-group "tacacs+" is not defined. Please define it. %AAAA-4-SERVUNDEF: The server-group "tacacs+" is not defined. Please define it. % CEF not enabled. Enable first % CEF not enabled. Enable first % CEF not enabled. Enable first % CEF not enabled. Enable first %SYS-6-BOOT_MESSAGES: Messages above this line are from the boot loader. Regards, Rens From blahu77 at gmail.com Tue Sep 9 10:26:18 2008 From: blahu77 at gmail.com (=?ISO-8859-2?Q?Mateusz_B=B3aszczyk?=) Date: Tue, 9 Sep 2008 15:26:18 +0100 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080909134834.GB624@rtp-cse-489.cisco.com> References: <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> <20080909043231.GF16324@skywalker.creative.net.au> <48C604AD.7080500@evaristesys.com> <7FEDD455961B164D8C4EEA60E22914205B78D56F50@EXCHANGE1.intranet.iseek.com.au> <20080909134834.GB624@rtp-cse-489.cisco.com> Message-ID: <383357750809090726l452f8837wfdc8b55d59c20b3f@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rodney 2008/9/9 Rodney Dunn : > Don't use TACL's on the software platforms. It has been removed > from the CLI for the ISR's (it shouldn't have slipped in to begin with). > edge2#sh ver | in IOS Cisco IOS Software, 7301 Software (C7301-K91P-M), Version 12.2(28)SB6, RELEASE SOFTWARE (fc1) edge2(config)#access-list compiled ? reuse Reuse tables when compiling (for reduced memory requirements) So, it is NOT recommended to use this feature on that router? > There are very difficult challenges to handle for things such > as updating the ACL on configuration change, memory usage, etc. > and if we made a policy that each ACL update would consist of: 1) remove access-group from the port 2) remove acl 3) create new acl 4) put access-group on the port Would the above apply as well? > Most HW forwarding platforms merge the ACL's in some fashion to > reduce the footprint size. So when using TACL is recommended? On software-based it is not, on hardware-based we got other mechanisms... I am confused. > In IOS there is a Trie based ACL now over the linear format. > It's on by default and you can't change it. now - meaning 12.4T ? - -- - -mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIxoeIIvBv0k5esR4RAuhvAJ0W5Mcn38E7kM20gz2AaWOMKs4htwCgg/ep RaIQcLoM3P2Mc8NhQuL1vG8= =Y+MU -----END PGP SIGNATURE----- From rodunn at cisco.com Tue Sep 9 10:34:44 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 9 Sep 2008 10:34:44 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <383357750809090726l452f8837wfdc8b55d59c20b3f@mail.gmail.com> References: <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> <20080909043231.GF16324@skywalker.creative.net.au> <48C604AD.7080500@evaristesys.com> <7FEDD455961B164D8C4EEA60E22914205B78D56F50@EXCHANGE1.intranet.iseek.com.au> <20080909134834.GB624@rtp-cse-489.cisco.com> <383357750809090726l452f8837wfdc8b55d59c20b3f@mail.gmail.com> Message-ID: <20080909143444.GM624@rtp-cse-489.cisco.com> On Tue, Sep 09, 2008 at 03:26:18PM +0100, Mateusz B?aszczyk wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rodney > > 2008/9/9 Rodney Dunn : > > Don't use TACL's on the software platforms. It has been removed > > from the CLI for the ISR's (it shouldn't have slipped in to begin with). > > > > edge2#sh ver | in IOS > Cisco IOS Software, 7301 Software (C7301-K91P-M), Version 12.2(28)SB6, > RELEASE SOFTWARE (fc1) > > edge2(config)#access-list compiled ? > reuse Reuse tables when compiling (for reduced memory requirements) > > > So, it is NOT recommended to use this feature on that router? They didn't remove it on the 72xx, 7301, and 75xx from what I remember because they had the distributed or CPU/memory to handle them and there were so many customers already using them. If your ACL's are static you will probably be ok. But if it were my network I'd be on code that used Trie based ACL's and get away from TACL's given the problems I worked on with them. When they work they work well but when there are problems with a lot of updates and size they get pretty messy. If you want speed on them with long ACL's you really should look at something that can do them in hardware. s> > > > There are very difficult challenges to handle for things such > > as updating the ACL on configuration change, memory usage, etc. > > > > and if we made a policy that each ACL update would consist of: > 1) remove access-group from the port > 2) remove acl > 3) create new acl > 4) put access-group on the port > > Would the above apply as well? Removing it form an interface no. Removing the ACL not as much. It's more about modifying the ACL. > > > Most HW forwarding platforms merge the ACL's in some fashion to > > reduce the footprint size. > > So when using TACL is recommended? On software-based it is not, on > hardware-based we got other mechanisms... > I am confused. In genearl it's not advised to use them at all anymore. > > > In IOS there is a Trie based ACL now over the linear format. > > It's on by default and you can't change it. > > > now - meaning 12.4T ? Yes...12.4M got it too. > > - -- > - -mat > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIxoeIIvBv0k5esR4RAuhvAJ0W5Mcn38E7kM20gz2AaWOMKs4htwCgg/ep > RaIQcLoM3P2Mc8NhQuL1vG8= > =Y+MU > -----END PGP SIGNATURE----- From rodunn at cisco.com Tue Sep 9 10:35:01 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 9 Sep 2008 10:35:01 -0400 Subject: [c-nsp] Errors before boot loader In-Reply-To: <81FF162258F4476DAC6190201B439281@EU.corp.clearwire.com> References: <81FF162258F4476DAC6190201B439281@EU.corp.clearwire.com> Message-ID: <20080909143501.GN624@rtp-cse-489.cisco.com> No. Rodney On Tue, Sep 09, 2008 at 04:01:52PM +0200, Rens wrote: > Hi, > > > > Should I worry about errors that are sent from the boot loader? > > > > %SYS-4-CONFIG_NEWER: Configuration from version 12.4 may not be correctly > understood > > %AAAA-4-SERVUNDEF: The server-group "tacacs+" is not defined. Please define > it. > > %AAAA-4-SERVUNDEF: The server-group "tacacs+" is not defined. Please define > it. > > %AAAA-4-SERVUNDEF: The server-group "tacacs+" is not defined. Please define > it. > > % CEF not enabled. Enable first > > % CEF not enabled. Enable first > > % CEF not enabled. Enable first > > % CEF not enabled. Enable first > > %SYS-6-BOOT_MESSAGES: Messages above this line are from the boot loader. > > > > Regards, > > > > Rens > > _______________________________________________ > 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-kell at utc.edu Tue Sep 9 10:41:31 2008 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 09 Sep 2008 10:41:31 -0400 Subject: [c-nsp] 10G Xenpak 'virgin' question Message-ID: <48C68B1B.4010705@utc.edu> We're trying to light up our first 10G Xenpak link, so far without success, so I'm looking for a quick sanity check. 3750G-16TD switch with an LR Xenpak [ours], trying to link to a Ciena [not ours] add/drop ONS. We had some marginal power levels trying to backhaul the circuit across campus, so we relocated the 3750 next to the fiber ingress and trying to get the link up directly connected with no luck. No link light (ever), not even a noise packet in the interface stats. The interface isn't shutdown. I've tried it P2P (no switchport) and trunk (switchport) and still nothing. Is there something obvious about a 10G interface configuration that I'm overlooking to get the thing to "speak" ? Jeff From colin at netech.ie Tue Sep 9 11:19:02 2008 From: colin at netech.ie (Colin Whittaker) Date: Tue, 9 Sep 2008 16:19:02 +0100 Subject: [c-nsp] 10G Xenpak 'virgin' question In-Reply-To: <48C68B1B.4010705@utc.edu> References: <48C68B1B.4010705@utc.edu> Message-ID: <20080909151902.GA23977@infiltrator.gizzard.com> The Ciena is probably not doing auto negotiation. try "speed nonegotiate" on the interface and once it sees light it should bring the interface up. On Tue, Sep 09, 2008 at 10:41:31AM -0400, Jeff Kell wrote: > We're trying to light up our first 10G Xenpak link, so far without > success, so I'm looking for a quick sanity check. > > 3750G-16TD switch with an LR Xenpak [ours], trying to link to a Ciena > [not ours] add/drop ONS. > > We had some marginal power levels trying to backhaul the circuit across > campus, so we relocated the 3750 next to the fiber ingress and trying to > get the link up directly connected with no luck. > > No link light (ever), not even a noise packet in the interface stats. > The interface isn't shutdown. I've tried it P2P (no switchport) and > trunk (switchport) and still nothing. > > Is there something obvious about a 10G interface configuration that I'm > overlooking to get the thing to "speak" ? > > 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/ > -- Colin Whittaker +353 (0)86 8211 965 http://colin.netech.ie colin at netech.ie From rodunn at cisco.com Tue Sep 9 12:13:04 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 9 Sep 2008 12:13:04 -0400 Subject: [c-nsp] 12.40(20T), pppoe woes In-Reply-To: <48C60E92.3000600@reub.net> References: <70B7A1CCBFA5C649BD562B6D9F7ED78405F80226@xmb-ams-333.emea.cisco.com> <48C60E92.3000600@reub.net> Message-ID: <20080909161304.GR624@rtp-cse-489.cisco.com> Around 10/17. On Tue, Sep 09, 2008 at 03:50:10PM +1000, Reuben Farrelly wrote: > > > On 8/09/2008 8:43 PM, Oliver Boehmer (oboehmer) wrote: > >David, > > > >please check CSCsu35584, it will be fixed in the upcoming 12.4(20)T1 > >rebuild and the above restriction will be removed.. > > > > oli > > Hi Oli, > > What is the approximate timeframe on 12.4(20)T1? > > I'm asking because I'd really like to upgrade to 12.4(20)T but when I did > all manner of things broke badly - most notably Zone Based Firewall > (CSCsq43934 and CSCsr58052) and SIP registration (CSCsq85615, CSCsr00711). > > ie it wasn't a pleasant experience. Fortunately 12.4(15)T7 is pretty good > now so that's my downgrade path but still... > > Reuben > _______________________________________________ > 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 Sep 9 14:44:06 2008 From: gsgranados at comcast.net (Scott Granados) Date: Tue, 9 Sep 2008 11:44:06 -0700 Subject: [c-nsp] Buffer Tuning pointer? Message-ID: <028801c912ac$0df6e910$1b0310ac@ccntd1.covad.com> I'm using a 7206 NPE-G1 and noticing a lot of buffer misses. Everything that I find via Google points me to opening a support case but provides very little background information. There's also a "buffer tune automatic" command but little listed about it's proper use. Does anyone have a good buffer tuning pointer or pointer for good fundamental / n00by information concerning buffers? Thank you Scott From jason.plank at comcast.net Tue Sep 9 14:50:20 2008 From: jason.plank at comcast.net (jason.plank at comcast.net) Date: Tue, 09 Sep 2008 18:50:20 +0000 Subject: [c-nsp] Buffer Tuning pointer? Message-ID: <090920081850.13139.48C6C56B000C390500003353220073407605020E049FD202019C0E06@comcast.net> Scott, Review: http://www.cisco.com/en/US/products/hw/modules/ps2643/products_tech_note09186a0080093fc5.shtml This URL is good for getting an understanding on what a buffer miss actually is. I usually look at what the buffers are currently set to and increase in varying increments. -- Regards, Jason Plank CCIE #16560 e: jason.plank at comcast.net -------------- Original message ---------------------- From: "Scott Granados" > I'm using a 7206 NPE-G1 and noticing a lot of buffer misses. Everything > that I find via Google points me to opening a support case but provides very > little background information. There's also a "buffer tune automatic" > command but little listed about it's proper use. Does anyone have a good > buffer tuning pointer or pointer for good fundamental / n00by information > concerning buffers? > > 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 streiner at cluebyfour.org Tue Sep 9 15:02:09 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 9 Sep 2008 15:02:09 -0400 (EDT) Subject: [c-nsp] 10G Xenpak 'virgin' question In-Reply-To: <48C68B1B.4010705@utc.edu> References: <48C68B1B.4010705@utc.edu> Message-ID: On Tue, 9 Sep 2008, Jeff Kell wrote: > We're trying to light up our first 10G Xenpak link, so far without > success, so I'm looking for a quick sanity check. > > 3750G-16TD switch with an LR Xenpak [ours], trying to link to a Ciena > [not ours] add/drop ONS. What type of optics are in use on both ends? Note that LX4 will not talk to SR/LR/ER/ZR. Are you using singlemode or multimode fiber? When you say "across campus" I'm assuming singlemode, but I've been wrong before :) Also, do OTDR tests show a clean link all through the span? jms > We had some marginal power levels trying to backhaul the circuit across > campus, so we relocated the 3750 next to the fiber ingress and trying to > get the link up directly connected with no luck. > > No link light (ever), not even a noise packet in the interface stats. > The interface isn't shutdown. I've tried it P2P (no switchport) and > trunk (switchport) and still nothing. > > Is there something obvious about a 10G interface configuration that I'm > overlooking to get the thing to "speak" ? > > 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 scubacuda at gmail.com Tue Sep 9 15:03:39 2008 From: scubacuda at gmail.com (Rogelio) Date: Tue, 09 Sep 2008 12:03:39 -0700 Subject: [c-nsp] can cisco pix "boomerang" mail traffic? Message-ID: <48C6C88B.7030001@gmail.com> Can a Cisco PIX "boomerang" a packet--i.e. route a packet coming from the internal network that is destined for an Internet host back into the internal network via NAT? I ask because I have have email clients pointing to mail.domain.com, and unless I do a split DNS with my mail A record pointing to a 192 address inside and an external mail A record pointing to my public IP address, I'm not quite sure how to do it. Users using Microsoft Outlook + Exchange don't have a problem getting their email. But users using other email clients (Thunderbird, Outlook Express, etc) obviously cannot resolve the host name if they are on the wrong side of the network. Thunderbird has different identities for each email account, but that's too much work for some of the users. From r.nevot at gmail.com Tue Sep 9 15:20:23 2008 From: r.nevot at gmail.com (Raul Lopez Nevot) Date: Tue, 9 Sep 2008 21:20:23 +0200 Subject: [c-nsp] can cisco pix "boomerang" mail traffic? In-Reply-To: <48C6C88B.7030001@gmail.com> References: <48C6C88B.7030001@gmail.com> Message-ID: Hello, On Tue, Sep 9, 2008 at 9:03 PM, Rogelio wrote: > Can a Cisco PIX "boomerang" a packet--i.e. route a packet coming from the > internal network that is destined for an Internet host back into > the internal network via NAT? > > I ask because I have have email clients pointing to mail.domain.com, and > unless I do a split DNS with my mail A record pointing to a 192 address > inside and an external mail A record pointing to my public IP address, I'm > not quite sure how to do it. > If I have understood your scenario, sure you will do split DNS, but you can let the PIX work for you. Take a look to http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml regards From Gregori.Parker at theplatform.com Tue Sep 9 15:24:48 2008 From: Gregori.Parker at theplatform.com (Gregori Parker) Date: Tue, 9 Sep 2008 12:24:48 -0700 Subject: [c-nsp] can cisco pix "boomerang" mail traffic? In-Reply-To: <48C6C88B.7030001@gmail.com> References: <48C6C88B.7030001@gmail.com> Message-ID: <1A9866F953006D45AEE0166066114E09131EC10E@TPMAIL02.corp.theplatform.com> Had a similar problem, and dns-doctoring wasn't the right solution (it might work for you if your resolver is external) http://www.cisco.com/en/US/products/ps6120/products_configuration_exampl e09186a00807968d1.shtml The alternate solution, 'hairpinning', did the job (same link)... just don't forget the global statement on the outside interface. HTH - Gregori -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Rogelio Sent: Tuesday, September 09, 2008 12:04 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] can cisco pix "boomerang" mail traffic? Can a Cisco PIX "boomerang" a packet--i.e. route a packet coming from the internal network that is destined for an Internet host back into the internal network via NAT? I ask because I have have email clients pointing to mail.domain.com, and unless I do a split DNS with my mail A record pointing to a 192 address inside and an external mail A record pointing to my public IP address, I'm not quite sure how to do it. Users using Microsoft Outlook + Exchange don't have a problem getting their email. But users using other email clients (Thunderbird, Outlook Express, etc) obviously cannot resolve the host name if they are on the wrong side of the network. Thunderbird has different identities for each email account, but that's too much work for some of the users. _______________________________________________ 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 kristian at spritelink.net Tue Sep 9 16:10:06 2008 From: kristian at spritelink.net (Kristian Larsson) Date: Tue, 9 Sep 2008 22:10:06 +0200 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <48C62E1E.2080805@evaristesys.com> References: <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> <7FEDD455961B164D8C4EEA60E22914205B78D56F4F@EXCHANGE1.intranet.iseek.com.au> <48C62E1E.2080805@evaristesys.com> Message-ID: <20080909201006.GC43091@spritelink.se> On Tue, Sep 09, 2008 at 04:04:46AM -0400, Alex Balashov wrote: > Just to be clear, in case it isn't, I was not referring to how the ACLs are > organised from the user perspective, presentation-wise, but rather I was > surprised that they are not all put into an optimised data structure on the > back side by IOS by default so that matching can happen with somewhere > between O(1) and O(n) performance. > > Thank you all for the enlightenment on compiled/turbo ACLs. > > It makes me wonder whether the reason why routers are generally considered > a poorer solution for extensive ACL duty than PIXs or ASAs. Does the PIX > use compiled ACLs by default? Or perhaps there is some sort of extremely > helpful ACIC-driven optimisation that they provide? Cisco IOS (without the firewall feature set) doesn't really support stateful firewalls, but is rather a fixed set of filters applied to packets. PIX / ASA does stateful packet inspection and some other mumbo jumbo that security people like to have. I think that would be the #1 reason of why one would choose a PIX over an IOS device. I have no clue whether they're actually faster or not at filtering packets. -K >>> Are you _sure_ that order is important in these ACLs? I ask because I >>> honestly don't know, so don't get me wrong. >> yes it is.. i have seen software based platforms knock 10-20% cpu off by >> reworking very poorly laid out ACL's in a "top down" fashion. >>> It just seems rather unlikely. Organising data like that into >>> structures where matching and access can happen at more or less an O(1) >>> formal computational complexity is a basic skill that is taught at the >>> beginning of any undergraduate curriculum in computer science. >>> Students >>> are taught to understand that large amounts of random (non-sorted) data >>> cannot be stored in a linear structure, and that even linear structures >>> with comparatively few elements (such as an access list) can be very >>> slow if the lookup is repeated with very great frequency. >> aren't we doing some kind of eval on our current lists before applying a >> new one? like i'm thinking >> 1) fire up the ACL leave it running for a while, look at the number of >> hits per ACL entry, and rework the ACL such that the maximum number of >> hits is at the top. >> 2) shortcut ACL's as bill mentioned >> eg, consider the following ACL >> 5 deny udp host >> 10 deny udp host >> 20 deny udp host >> 25 permit ip any >> presume that 60% of your traffic is TCP. all of this traffic is having to >> drop through 3 denies before it gets permitted. you could save a >> significant amount of processing by simply putting >> 1 permit tcp >> 5 deny udp host >> 10 deny udp host >> 20 deny udp host >> 25 permit ip any >> sure, you are doubling up in what is permitted because the TCP would have >> hit the permit ip any at the bottom anyway, but you are saving a >> considerable amount of processing by having 60% of your traffic match the >> first ACL entry. sure, oversimplified, but if you can't permit tcp >> outright, consider a permit established before you start denying other tcp >> bits and pieces, because more often than not the majority of traffic being >> forwarded is established. >> so in regards to having IOS reorganise the ACL for you that would have to >> make the assumption that the IOS has the capability to work out what is >> the ACL entries that are getting the most matches, in order to reorganise >> them, it isnt going to be able to predict this for you. > > > -- > Alex Balashov > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (706) 338-8599 > _______________________________________________ > 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/ -- Kristian Larsson KLL-RIPE Network Engineer / Internet Core Tele2 / SWIPnet [AS1257] +46 704 910401 kll at spritelink.net From jfitz at Princeton.EDU Tue Sep 9 16:33:52 2008 From: jfitz at Princeton.EDU (Jeff Fitzwater) Date: Tue, 9 Sep 2008 16:33:52 -0400 Subject: [c-nsp] Monitoring CPU punted traffic Message-ID: I am running 720CXL with SXH code and am trying to monitor the punted traffic to the RP so that I can confirm what actually gets punted to it. It appears to show packets but not positive I have configured it correctly. Has anyone else used this tool? The doc states that when using the RP CPU as SOURCE that the traffic is seen from the viewpoint of the ASIC, as shown in snippet below... ------------ Source CPUs A source CPU is a CPU monitored for traffic analysis. With Release 12.2(33)SXH and later releases, you can configure both the SP CPU and the RP CPU as SPAN sources. These are examples of what you can do with the data generated by CPU monitoring: ?Develop baseline information about CPU traffic. ?Develop information to use when creating CoPP policies. ?Troubleshoot CPU-related issues (for example, high CPU utilization). Note?CPU SPAN monitors CPU traffic from the perspective of the ASICs that send and receive the CPU traffic, rather than from on board the CPUs themselves. ?Traffic to and from the CPU is tagged with VLAN IDs. You can configure source VLAN filtering of the CPU traffic. ------------- This is how I configured the SPAN port.... (config) monitor ses 1 local (This puts me in config-mon-local mode) (config-mon-local) destination interface gi13/17 (THIS PORT HAS TCPDUMP HOST ATTACHED) (config-mon-local) source cpu rp tx (As stated in doc traffic is from viewpoint of ASIC, so I used TX assuming transmitted traffic to RP CPU.) (config-mon-local)no shutdown (This is needed to turn on monitor) (config-mon-local) exit (Must exit in order for no shutdown to take effect) Thanks for any advise on this config. Jeff Fitzwater OIT Network Systems Princeton University From maillist at webjogger.net Tue Sep 9 16:38:31 2008 From: maillist at webjogger.net (Adam Greene) Date: Tue, 9 Sep 2008 16:38:31 -0400 Subject: [c-nsp] iBGP Multi-link question References: <3D1D76D4036E45069BC1820B6548FBE0@GINKGO> Message-ID: Jeff, it just occurred to me that I did this in an eBGP environment, not iBGP as you were asking ... ----- Original Message ----- From: "Adam Greene" To: "Jeff Cartier" ; Sent: Tuesday, September 09, 2008 9:41 AM Subject: Re: [c-nsp] iBGP Multi-link question > Jeff, in my experience having multiple BGP sessions between two routers, > with different end-points for each session, works fine ... > > ----- Original Message ----- > From: "Jeff Cartier" > To: > Sent: Monday, September 08, 2008 11:45 AM > Subject: [c-nsp] iBGP Multi-link question > > >> I'm in a scenario where I have two routers, configured with two >> loopbacks, connected together via two links. I'm in the process of >> transitioning from one loopback to the other and I was wondering if >> there are any caveats to having two sessions up...one BGP session to the >> first lookback (existing), then another BGP session up to the second >> loopback (new). >> >> >> >> I don't believe their should be any issues with this...and I don't see >> any documentation suggesting otherwise...just thought I'd ask to be >> certain :-) >> >> >> >> ROUTER1============ROUTER2 >> >> Lo1:10.1.1.1/32 Lo1:10.1.2.1/32 >> >> Lo2:10.1.1.2/32 Lo2:10.1.2.2/32 >> >> _______________________________________________ >> 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 lukasz at bromirski.net Tue Sep 9 16:39:38 2008 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Tue, 09 Sep 2008 22:39:38 +0200 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080909201006.GC43091@spritelink.se> References: <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> <7FEDD455961B164D8C4EEA60E22914205B78D56F4F@EXCHANGE1.intranet.iseek.com.au> <48C62E1E.2080805@evaristesys.com> <20080909201006.GC43091@spritelink.se> Message-ID: <48C6DF0A.70709@bromirski.net> Kristian Larsson wrote: > Cisco IOS (without the firewall feature set) > doesn't really support stateful firewalls, but is > rather a fixed set of filters applied to packets. > PIX / ASA does stateful packet inspection and some > other mumbo jumbo that security people like to > have. I think that would be the #1 reason of why > one would choose a PIX over an IOS device. > I have no clue whether they're actually faster or > not at filtering packets. They are. Statefully filtering and inspecting packets requires a lot of horsepower, and CPUs in ASAs are much beefier than the ones You can spot on ISRs or 7200. NAT and CBAC/ZBFW are features hitting CPUs in routers a lot. -- "Don't expect me to cry for all the | ?ukasz Bromirski reasons you had to die" -- Kurt Cobain | http://lukasz.bromirski.net From sthaug at nethelp.no Tue Sep 9 17:01:50 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 09 Sep 2008 23:01:50 +0200 (CEST) Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080909201006.GC43091@spritelink.se> References: <7FEDD455961B164D8C4EEA60E22914205B78D56F4F@EXCHANGE1.intranet.iseek.com.au> <48C62E1E.2080805@evaristesys.com> <20080909201006.GC43091@spritelink.se> Message-ID: <20080909.230150.74703307.sthaug@nethelp.no> > I have no clue whether they're actually faster or > not at filtering packets. Can PIX/ASA filter 10 Gig minimum sized packets at line rate (like many core routers can)? I notice the data sheet for the ASA 5580-40 claims 10 Gbps (real-world HTTP), 20 Gbps (jumbo frames) - but there's no mention of minimum sized packets. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From lukasz at bromirski.net Tue Sep 9 17:51:19 2008 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Tue, 09 Sep 2008 23:51:19 +0200 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080909.230150.74703307.sthaug@nethelp.no> References: <7FEDD455961B164D8C4EEA60E22914205B78D56F4F@EXCHANGE1.intranet.iseek.com.au> <48C62E1E.2080805@evaristesys.com> <20080909201006.GC43091@spritelink.se> <20080909.230150.74703307.sthaug@nethelp.no> Message-ID: <48C6EFD7.9010003@bromirski.net> sthaug at nethelp.no wrote: >> I have no clue whether they're actually faster or >> not at filtering packets. > > Can PIX/ASA filter 10 Gig minimum sized packets at line rate (like many > core routers can)? I notice the data sheet for the ASA 5580-40 claims 10 > Gbps (real-world HTTP), 20 Gbps (jumbo frames) - but there's no mention > of minimum sized packets. As You're propably know - not. Filtering packets without keeping state for session is a lot simpler and implemented for years in hardware. With NPs like those used in ASA5580 and FWSM you can accelerate inspection of some of the traffic, but not all of course. -- "Don't expect me to cry for all the | ?ukasz Bromirski reasons you had to die" -- Kurt Cobain | http://lukasz.bromirski.net From lukasz at bromirski.net Tue Sep 9 17:55:25 2008 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Tue, 09 Sep 2008 23:55:25 +0200 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <48C6DF0A.70709@bromirski.net> References: <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <48C5FC11.2020109@evaristesys.com> <7FEDD455961B164D8C4EEA60E22914205B78D56F4F@EXCHANGE1.intranet.iseek.com.au> <48C62E1E.2080805@evaristesys.com> <20080909201006.GC43091@spritelink.se> <48C6DF0A.70709@bromirski.net> Message-ID: <48C6F0CD.8040606@bromirski.net> ?ukasz Bromirski wrote: > Kristian Larsson wrote: >> I have no clue whether they're actually faster or >> not at filtering packets. > They are. Statefully filtering and inspecting packets requires a lot > of horsepower, and CPUs in ASAs are much beefier than the ones You can > spot on ISRs or 7200. NAT and CBAC/ZBFW are features hitting CPUs > in routers a lot. Uh, sorry, I thought it was 'at firewalling', not 'filtering packets'. Still, ISRs and 7200 will be slower than ASA 5510 and higher models with simple packet filtering (stateless that is). For stateful - way slower. -- "Don't expect me to cry for all the | ?ukasz Bromirski reasons you had to die" -- Kurt Cobain | http://lukasz.bromirski.net From jonvoip at gmail.com Tue Sep 9 22:07:43 2008 From: jonvoip at gmail.com (Jonathan Charles) Date: Tue, 9 Sep 2008 21:07:43 -0500 Subject: [c-nsp] WLC 4402 routing Message-ID: <5d093f9a0809091907g70632769j6d7e9d651c316352@mail.gmail.com> I have a 4402 with two subnets, voice and data... and a management interface. This is a remote site and the AAA server is at the HQ... There is no IP address on the service port, but the WLC will not let me add a route to get to the AAA server... I do not have another subnet to use... Why can't I use the in-band management interface to route back to my AAA Server? Jonathan From damin at nacs.net Tue Sep 9 23:44:45 2008 From: damin at nacs.net (Gregory Boehnlein) Date: Tue, 9 Sep 2008 23:44:45 -0400 Subject: [c-nsp] BGP Route Selection Message-ID: <16af01c912f7$910a6750$b31f35f0$@net> Cisco RSP4+ (R5000) processor with 262144K/2072K bytes of memory. Slave in slot 3 is running Cisco IOS Software, RSP Software (RSP-IK91SV-M), Version 12.2(25)S12, RELEASE SOFTWARE (fc1) Hello, I'm bringing up a new BGP peer and am working at tweaking our BGP routing configuration. In doing so, I'm noticing something weird about a particular path, and since I'm rather tired at the moment, wanted to have a fresh set of eyes take a look at it. Can someone explain to me the reason why Path #3 is being chosen over the lower AS-Path #1 and #2 routing choices? core1#show ip bgp 4.68.95.11 BGP routing table entry for 4.0.0.0/9, version 6 Paths: (4 available, best #3, table Default-IP-Routing-Table) Multipath: eBGP Not advertised to any peer 3356, (aggregated by 3356 4.69.130.12) 4.53.194.5 from 4.53.194.5 (4.69.181.195) Origin IGP, metric 1000, localpref 100, valid, external, atomic-aggregate Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2006 3356, (aggregated by 3356 4.69.130.12), (received-only) 4.53.194.5 from 4.53.194.5 (4.69.181.195) Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2006 2828 3356, (aggregated by 3356 4.69.130.12) 67.106.93.233 (metric 20) from 207.166.219.2 (207.166.219.2) Origin IGP, metric 1000, localpref 150, valid, internal, atomic-aggregate, best 2828 3356, (aggregated by 3356 4.69.130.12), (received-only) 67.106.93.233 (metric 20) from 207.166.219.2 (207.166.219.2) Origin IGP, metric 3, localpref 150, valid, internal, atomic-aggregate From mtinka at globaltransit.net Wed Sep 10 00:35:05 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 10 Sep 2008 12:35:05 +0800 Subject: [c-nsp] BGP Route Selection In-Reply-To: <16af01c912f7$910a6750$b31f35f0$@net> References: <16af01c912f7$910a6750$b31f35f0$@net> Message-ID: <200809101235.09688.mtinka@globaltransit.net> On Wednesday 10 September 2008 11:44:45 Gregory Boehnlein wrote: > Can someone explain > to me the reason why Path #3 is being chosen over the > lower AS-Path #1 and #2 routing choices? Path 3 is the best because it has a higher LOCAL_PREF value (150) vs. that from paths 1 and 2. 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 jlewis at lewis.org Wed Sep 10 00:40:35 2008 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 10 Sep 2008 00:40:35 -0400 (EDT) Subject: [c-nsp] BGP Route Selection In-Reply-To: <16af01c912f7$910a6750$b31f35f0$@net> References: <16af01c912f7$910a6750$b31f35f0$@net> Message-ID: On Tue, 9 Sep 2008, Gregory Boehnlein wrote: > I'm bringing up a new BGP peer and am working at tweaking our BGP > routing configuration. In doing so, I'm noticing something weird about a > particular path, and since I'm rather tired at the moment, wanted to have a > fresh set of eyes take a look at it. Can someone explain to me the reason > why Path #3 is being chosen over the lower AS-Path #1 and #2 routing > choices? Path 3 has localpref 150, which "overrules" the shorter as path at localpref 100. You're probably using an input route-map and setting this. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From frnkblk at iname.com Wed Sep 10 01:13:12 2008 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 10 Sep 2008 00:13:12 -0500 Subject: [c-nsp] can cisco pix "boomerang" mail traffic? In-Reply-To: References: <48C6C88B.7030001@gmail.com> Message-ID: We use that, works like a charm. Frank -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Raul Lopez Nevot Sent: Tuesday, September 09, 2008 2:20 PM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] can cisco pix "boomerang" mail traffic? Hello, On Tue, Sep 9, 2008 at 9:03 PM, Rogelio wrote: > Can a Cisco PIX "boomerang" a packet--i.e. route a packet coming from the > internal network that is destined for an Internet host back into > the internal network via NAT? > > I ask because I have have email clients pointing to mail.domain.com, and > unless I do a split DNS with my mail A record pointing to a 192 address > inside and an external mail A record pointing to my public IP address, I'm > not quite sure how to do it. > If I have understood your scenario, sure you will do split DNS, but you can let the PIX work for you. Take a look to http://www.cisco.com/en/US/products/ps6120/products_configuration_example091 86a00807968d1.shtml 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 andy.saykao at staff.netspace.net.au Wed Sep 10 01:34:48 2008 From: andy.saykao at staff.netspace.net.au (Andy Saykao) Date: Wed, 10 Sep 2008 15:34:48 +1000 Subject: [c-nsp] Can the PE router take on multiple roles? Message-ID: <56F211C5E3F24F47B103EA1B253822BE036548CC@vic-cr-ex1.staff.netspace.net.au> Hi All, We have a few spare 7301's out the back and I was thinking of using one of them to be a NAT-PE router. No biggie with doing this but I was wondering if the NAT-PE router could also take on other roles which would be beneficial in a MPLS VPN environment such as using it to act as a SSL VPN Gateway for remote access. Could the same unit also be used to act as a Route Reflector to reflect VPNv4 routes? Or am I putting too much load on the router and/or putting all my eggs in one basket? At present, we don't have many MPLS VPN customers yet but the hope is to make things scalable so we can grow comfortable as the number of VPN customers grow. In summary, is it a good idea to use the 7301 to preform the following roles: - NAT-PE / Internet Gateway - SSL VPN Gateway - BGP Route Reflector Ideas, comments, personal experiences, etc most welcomed. 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 tseveendorj at gmail.com Wed Sep 10 02:38:42 2008 From: tseveendorj at gmail.com (Tseveendorj Ochirlantuu) Date: Wed, 10 Sep 2008 14:38:42 +0800 Subject: [c-nsp] dial-peer related question Message-ID: <62c908120809092338o4b7d7760p81967622626fb42e@mail.gmail.com> Hi guys I have 5350 gateway and gateway connected to internet via gigenthernet, connected to ISDN by 2 E1 ports via PRI. Dial peer looks like this : dial-peer voice 4002 voip voice-class codec 1 session target ipv4:61.250.94.66 incoming called-number 0301T dtmf-relay rtp-nte h245-signal h245-alphanumeric fax-relay ecm disable fax rate 9600 fax protocol t38 ls-redundancy 2 hs-redundancy 2 fallback none ! dial-peer voice 4003 pots destination-pattern 0301T progress_ind alert enable 8 direct-inward-dial port 2/0:D ! dial-peer voice 4006 pots destination-pattern 0301T progress_ind alert enable 8 direct-inward-dial port 2/3:D ! The call coming from dial-peer 4002 and outgoing to 4003, 4006. 30 calls came from 4002 to 4003 and 4006 it can handle when 31th call came it couldn't. I think 2E1 card can handle 60 calls. but it didn't. I think problem in configuration. How to solve it? Thanks for any help Sincerely, Tseveen. From peter at rathlev.dk Wed Sep 10 04:28:35 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Wed, 10 Sep 2008 10:28:35 +0200 Subject: [c-nsp] Errors before boot loader In-Reply-To: <81FF162258F4476DAC6190201B439281@EU.corp.clearwire.com> References: <81FF162258F4476DAC6190201B439281@EU.corp.clearwire.com> Message-ID: <1221035315.23943.5.camel@abehat> On Tue, 2008-09-09 at 16:01 +0200, Rens wrote: > Hi, > > Should I worry about errors that are sent from the boot loader? If Rodney says no, you probably shouldn't. :-) > %SYS-4-CONFIG_NEWER: Configuration from version 12.4 may not be correctly > understood > %AAAA-4-SERVUNDEF: The server-group "tacacs+" is not defined. Please define > it. > %AAAA-4-SERVUNDEF: The server-group "tacacs+" is not defined. Please define > it. > %AAAA-4-SERVUNDEF: The server-group "tacacs+" is not defined. Please define > it. > % CEF not enabled. Enable first > % CEF not enabled. Enable first > % CEF not enabled. Enable first > % CEF not enabled. Enable first > %SYS-6-BOOT_MESSAGES: Messages above this line are from the boot loader. If it's a platform with seperate boot-image (like 7200) you could update this boot loader. I don't know exactly why one would/wouldn't do that, but the first line seems to indicate that boot-image and IOS-image are different versions. We have several routers running different versions of boot and IOS, apparantly with no problems, but we've begun upgrading the boot code to match the IOS though, if not for anything else then for the looks. Any reason not to do this? Or to do it? Regards, Peter From rootnet08 at gmail.com Wed Sep 10 04:32:03 2008 From: rootnet08 at gmail.com (root net) Date: Wed, 10 Sep 2008 03:32:03 -0500 Subject: [c-nsp] NBAR & QoS Message-ID: <89944ef40809100132g387f47c2qcef4f0a2aa91598d@mail.gmail.com> Hello, I am looking into running NBAR along side with QoS in our network. I was wondering what the list was doing if running NBAR. I want to protect against excessive file sharing customers or at least throttle those specific applications. Some suggestions as the best place to configure this in a network or what you all are doing is appreciated? Maybe even running on a mirror port? My thoughts are placing on Cisco 7206 NPE-225/256MB box but am not sure if we should upgrade to a 7204VXR NPE-400/512Mb or not. This box runs terminates static (no PPPoE) DSL customers and about 20 to 30 subinterfaces. Although may move to PPPoE in the future. CPU usage is light and memory operates around 120MB free give or take. Thanks in advanced! RootNet08 From mtinka at globaltransit.net Wed Sep 10 04:51:03 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 10 Sep 2008 16:51:03 +0800 Subject: [c-nsp] Errors before boot loader In-Reply-To: <1221035315.23943.5.camel@abehat> References: <81FF162258F4476DAC6190201B439281@EU.corp.clearwire.com> <1221035315.23943.5.camel@abehat> Message-ID: <200809101651.07516.mtinka@globaltransit.net> On Wednesday 10 September 2008 16:28:35 Peter Rathlev wrote: > If it's a platform with seperate boot-image (like 7200) > you could update this boot loader. I don't know exactly > why one would/wouldn't do that, but the first line seems > to indicate that boot-image and IOS-image are different > versions. We see these kinds of logs from the boot loader on various 7200's we have in production, e.g., it says the 'mtu' command configured on one or more of the interfaces named is not supported, e.t.c., and yet we know the full IOS image supports it. It doesn't bother us, since we know the full image will have the full feature support we need. 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 zivl at gilat.net Wed Sep 10 05:16:21 2008 From: zivl at gilat.net (Ziv Leyes) Date: Wed, 10 Sep 2008 12:16:21 +0300 Subject: [c-nsp] Errors before boot loader In-Reply-To: <200809101651.07516.mtinka@globaltransit.net> References: <81FF162258F4476DAC6190201B439281@EU.corp.clearwire.com> <1221035315.23943.5.camel@abehat> <200809101651.07516.mtinka@globaltransit.net> Message-ID: I had a similar problem then updated the boot loader to a newer one and the problem was solved. To this I must ask, what's the most important reason I'd want to use a boot loader AND an IOS while I can just use IOS that can boot-load too? Ziv -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mark Tinka Sent: Wednesday, September 10, 2008 11:51 AM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Errors before boot loader On Wednesday 10 September 2008 16:28:35 Peter Rathlev wrote: > If it's a platform with seperate boot-image (like 7200) you could > update this boot loader. I don't know exactly why one would/wouldn't > do that, but the first line seems to indicate that boot-image and > IOS-image are different versions. We see these kinds of logs from the boot loader on various 7200's we have in production, e.g., it says the 'mtu' command configured on one or more of the interfaces named is not supported, e.t.c., and yet we know the full IOS image supports it. It doesn't bother us, since we know the full image will have the full feature support we need. Cheers, Mark. ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ From peter at rathlev.dk Wed Sep 10 05:16:42 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Wed, 10 Sep 2008 11:16:42 +0200 Subject: [c-nsp] Monitoring CPU punted traffic In-Reply-To: References: Message-ID: <1221038202.23943.18.camel@abehat> On Tue, 2008-09-09 at 16:33 -0400, Jeff Fitzwater wrote: > I am running 720CXL with SXH code and am trying to monitor the punted > traffic to the RP so that I can confirm what actually gets punted to > it. > > It appears to show packets but not positive I have configured it > correctly. Has anyone else used this tool? What kind of traffic do you see? What do you expect to see, i.e. what's missing? I don't know the SXH way (sounds fancy though) but there's the "good old" RP-inband/SP-inband way, described here: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note 09186a00804916e0.shtml#span_inband http://tinyurl.com/5hx7pb Docs says you "have" to use the new semantics on SXH though, just like you did. You might not be able to use the above on SXH, or it might be unsupported. > This is how I configured the SPAN port.... > > (config) monitor ses 1 local (This puts me in config-mon-local mode) > > (config-mon-local) destination interface gi13/17 (THIS PORT HAS > TCPDUMP HOST ATTACHED) > > (config-mon-local) source cpu rp tx (As stated in doc traffic is from > viewpoint of ASIC, so I used TX assuming transmitted traffic to RP > CPU.) > > (config-mon-local)no shutdown (This is needed to turn on monitor) > > (config-mon-local) exit (Must exit in order for no shutdown to take > effect) Small point: According to the docs, you should rather use "local-tx" type than "local" when it's just for TX. It's apparently a matter resources and not functionality though. Regards, Peter From nimal at fnbs.net Wed Sep 10 05:24:21 2008 From: nimal at fnbs.net (Nimal David Sirimanne) Date: Wed, 10 Sep 2008 17:24:21 +0800 Subject: [c-nsp] VPN Failover Message-ID: <48C79245.8030707@fnbs.net> Hi guys, We have 2 major offices (SITEA,SITEB)running site-2-site VPN connection between them. We are now setting up a new DR site (DRSITE) for SITEB However, our constraint is that SITEB internal network addressing and DRSITE internal network addressing has to be exactly the same. If internal network addressing for SITEB is 10.10.10.0/24, then internal network addressing for DRSITE is also 10.10.10.0/24. As i understand, it is not possible to for SITEA to have 2 active vpn links to sites with the same internal network addressing. Is it then possible, if SITEA -- vpn -- SITEB fails, that it will failover to SITEA -- vpn -- DRSITE? Hope i explained that properly. Thanks! Nimal From p.mayers at imperial.ac.uk Wed Sep 10 05:36:09 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Wed, 10 Sep 2008 10:36:09 +0100 Subject: [c-nsp] VACL capture versus OAL on 6500s Message-ID: <48C79509.5010708@imperial.ac.uk> All, I know that VACL capture is mutually exclusive with OAL on 6500s. We have a chassis which currently has OAL configured i.e. logging ip access-list cache rate-limit 300 int VlanX logging ip access-list cache in logging ip access-list cache out I now need to use VACL capture; can I just disable the "logging ip" commands, and then enable VACL capture, or do I need a reboot? From sidney.boumendil at gmail.com Wed Sep 10 05:52:22 2008 From: sidney.boumendil at gmail.com (Sidney Boumendil) Date: Wed, 10 Sep 2008 11:52:22 +0200 Subject: [c-nsp] VPN Failover In-Reply-To: <48C79245.8030707@fnbs.net> References: <48C79245.8030707@fnbs.net> Message-ID: <41522e900809100252s36006053o24e262991f386ce4@mail.gmail.com> On Wed, Sep 10, 2008 at 11:24 AM, Nimal David Sirimanne wrote: > Hi guys, > Is it then possible, if SITEA -- vpn -- SITEB fails, that it will failover > to SITEA -- vpn -- DRSITE? > Hi, Have a look at DPD and RRI features. Cisco design guides: http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a0080739e7c.pdf http://www-search.cisco.com/univercd/cc/td/doc/solution/ipsecovr.pdf HTH Sidney From gert at greenie.muc.de Wed Sep 10 06:31:47 2008 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 10 Sep 2008 12:31:47 +0200 Subject: [c-nsp] BGP Route Selection In-Reply-To: <16af01c912f7$910a6750$b31f35f0$@net> References: <16af01c912f7$910a6750$b31f35f0$@net> Message-ID: <20080910103147.GG17238@greenie.muc.de> Hi, On Tue, Sep 09, 2008 at 11:44:45PM -0400, Gregory Boehnlein wrote: > 3356, (aggregated by 3356 4.69.130.12) > 4.53.194.5 from 4.53.194.5 (4.69.181.195) > Origin IGP, metric 1000, localpref 100, valid, external, > atomic-aggregate > Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2006 > 3356, (aggregated by 3356 4.69.130.12), (received-only) > 4.53.194.5 from 4.53.194.5 (4.69.181.195) > Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate > Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2006 > 2828 3356, (aggregated by 3356 4.69.130.12) > 67.106.93.233 (metric 20) from 207.166.219.2 (207.166.219.2) > Origin IGP, metric 1000, localpref 150, valid, internal, > atomic-aggregate, best "localpref 150" means "ignore path length, force this path to win". (default localpref is 100, larger numbers = better) 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: 304 bytes Desc: not available URL: From peterkcc2001 at gmail.com Wed Sep 10 07:08:24 2008 From: peterkcc2001 at gmail.com (kcc) Date: Wed, 10 Sep 2008 07:08:24 -0400 Subject: [c-nsp] jumbo frame Message-ID: Hi Do I need to enable the jumbo frame in cisco eg: mtu 9000 or it can automatically learn? Thank you From mtinka at globaltransit.net Wed Sep 10 07:30:35 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 10 Sep 2008 19:30:35 +0800 Subject: [c-nsp] jumbo frame In-Reply-To: References: Message-ID: <200809101930.39160.mtinka@globaltransit.net> On Wednesday 10 September 2008 19:08:24 kcc wrote: > Do I need to enable the jumbo frame in cisco eg: mtu 9000 > or it can automatically learn? The biggest problems operators have faced with PMTUd is filtering. If this is for your backbone, this is in your control. That said, we hard-set jumbo frame MTU on all our kit. We prefer the predictability of some of these things :-). 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 cchurc05 at harris.com Wed Sep 10 07:57:04 2008 From: cchurc05 at harris.com (Church, Charles) Date: Wed, 10 Sep 2008 06:57:04 -0500 Subject: [c-nsp] NBAR & QoS In-Reply-To: <89944ef40809100132g387f47c2qcef4f0a2aa91598d@mail.gmail.com> References: <89944ef40809100132g387f47c2qcef4f0a2aa91598d@mail.gmail.com> Message-ID: We're using it on a 2821 for the same purpose - QOS to 2 upstreams, and file sharing shaping. Currently running about 10% CPU when pushing about 9mb through it. It's probably good for almost a full DS-3 on the 2821, at least in our application. If you can run 12.4 on the NPE225, I'd say enable it on a couple subints (protocol discovery) at a time, and keep an eye on the cpu. If CPU stays low, keep adding to it. I seem to remember having some weird NBAR issues with 12.3. How much traffic are you pushing through it currently? 20 to 30 customers doesn't sound like it'd be a problem. Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net Sent: Wednesday, September 10, 2008 4:32 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] NBAR & QoS Hello, I am looking into running NBAR along side with QoS in our network. I was wondering what the list was doing if running NBAR. I want to protect against excessive file sharing customers or at least throttle those specific applications. Some suggestions as the best place to configure this in a network or what you all are doing is appreciated? Maybe even running on a mirror port? My thoughts are placing on Cisco 7206 NPE-225/256MB box but am not sure if we should upgrade to a 7204VXR NPE-400/512Mb or not. This box runs terminates static (no PPPoE) DSL customers and about 20 to 30 subinterfaces. Although may move to PPPoE in the future. CPU usage is light and memory operates around 120MB free give or take. Thanks in advanced! RootNet08 _______________________________________________ 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 gary.ciscomail at gmail.com Wed Sep 10 09:00:50 2008 From: gary.ciscomail at gmail.com (Gary Roberton) Date: Wed, 10 Sep 2008 14:00:50 +0100 Subject: [c-nsp] CLI Restricted Flag Override Message-ID: We have CUCM6.1 with a Q.931 connection from a Cisco voice gateway to a TDM PBX network. On some PBX's in the network, the CLI restricted flag is set, and this is transmitted across the Q.931 link. I can see the calling number on the gateway, but the IP Phone displays "Unknown Number". Is there any way this can be overridden either on the gateway or CUCM? Thanks From peter at rathlev.dk Wed Sep 10 09:00:45 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Wed, 10 Sep 2008 15:00:45 +0200 Subject: [c-nsp] jumbo frame In-Reply-To: References: Message-ID: <1221051645.3762.3.camel@abehat> On Wed, 2008-09-10 at 07:08 -0400, kcc wrote: > Do I need to enable the jumbo frame in cisco eg: mtu 9000 > or it can automatically learn? If you're asking whether the switch/router can automatically "sense" that it need to use a 9000 byte MTU, then the answer is no. Packets exceeding the configured (or default) MTU are discarded as errors. Default MTU is 1500 bytes, most interfaces allowing "baby giants" AFAIK, up to 1530 bytes or so. You can configure it with the config-if command "mtu X". Beware: The "small" L3 switches (e.g. 3750) needs a "system mtu jumbo X" global config command and a reload. Regards, Peter From rodunn at cisco.com Wed Sep 10 09:47:54 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Wed, 10 Sep 2008 09:47:54 -0400 Subject: [c-nsp] Can the PE router take on multiple roles? In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE036548CC@vic-cr-ex1.staff.netspace.net.au> References: <56F211C5E3F24F47B103EA1B253822BE036548CC@vic-cr-ex1.staff.netspace.net.au> Message-ID: <20080910134754.GE11984@rtp-cse-489.cisco.com> It would work fine. Watch the CPU and memory to gauge scalability as you grow. Rodney On Wed, Sep 10, 2008 at 03:34:48PM +1000, Andy Saykao wrote: > Hi All, > > We have a few spare 7301's out the back and I was thinking of using one > of them to be a NAT-PE router. No biggie with doing this but I was > wondering if the NAT-PE router could also take on other roles which > would be beneficial in a MPLS VPN environment such as using it to act as > a SSL VPN Gateway for remote access. Could the same unit also be used to > act as a Route Reflector to reflect VPNv4 routes? Or am I putting too > much load on the router and/or putting all my eggs in one basket? > > At present, we don't have many MPLS VPN customers yet but the hope is to > make things scalable so we can grow comfortable as the number of VPN > customers grow. > > In summary, is it a good idea to use the 7301 to preform the following > roles: > > - NAT-PE / Internet Gateway > - SSL VPN Gateway > - BGP Route Reflector > > Ideas, comments, personal experiences, etc most welcomed. > > 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. > > _______________________________________________ > 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 rodunn at cisco.com Wed Sep 10 09:48:27 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Wed, 10 Sep 2008 09:48:27 -0400 Subject: [c-nsp] Errors before boot loader In-Reply-To: References: <81FF162258F4476DAC6190201B439281@EU.corp.clearwire.com> <1221035315.23943.5.camel@abehat> <200809101651.07516.mtinka@globaltransit.net> Message-ID: <20080910134827.GF11984@rtp-cse-489.cisco.com> If the main IOS image fails so you have tftpboot ability. On Wed, Sep 10, 2008 at 12:16:21PM +0300, Ziv Leyes wrote: > I had a similar problem then updated the boot loader to a newer one and the problem was solved. > To this I must ask, what's the most important reason I'd want to use a boot loader AND an IOS while I can just use IOS that can boot-load too? > Ziv > > > > > > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mark Tinka > Sent: Wednesday, September 10, 2008 11:51 AM > To: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Errors before boot loader > > On Wednesday 10 September 2008 16:28:35 Peter Rathlev wrote: > > > If it's a platform with seperate boot-image (like 7200) you could > > update this boot loader. I don't know exactly why one would/wouldn't > > do that, but the first line seems to indicate that boot-image and > > IOS-image are different versions. > > We see these kinds of logs from the boot loader on various 7200's we have in production, e.g., it says the 'mtu' > command configured on one or more of the interfaces named is not supported, e.t.c., and yet we know the full IOS image supports it. > > It doesn't bother us, since we know the full image will have the full feature support we need. > > Cheers, > > Mark. > > > > > > ************************************************************************************ > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. > ************************************************************************************ > > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ From david at davidcoulson.net Wed Sep 10 09:59:12 2008 From: david at davidcoulson.net (David Coulson) Date: Wed, 10 Sep 2008 09:59:12 -0400 Subject: [c-nsp] BGP Route Selection In-Reply-To: <16af01c912f7$910a6750$b31f35f0$@net> References: <16af01c912f7$910a6750$b31f35f0$@net> Message-ID: <48C7D2B0.6080403@davidcoulson.net> You could fix it with a route-map and as-path. ip as-path access-list 98 permit ^3356$ route-map as-3356-inbound permit 5 match as-path 98 set local-preference 200 Then in the router bgp section, add this: neighbour 4.53.194.5 route-map as-3356-inbound in This will solve the problem for the specific route, however it may not do what you intend with all of the routes on your network. David Gregory Boehnlein wrote: > Cisco RSP4+ (R5000) processor with 262144K/2072K bytes of memory. Slave in > slot 3 is running Cisco IOS Software, RSP Software (RSP-IK91SV-M), Version > 12.2(25)S12, RELEASE SOFTWARE (fc1) > > Hello, > I'm bringing up a new BGP peer and am working at tweaking our BGP > routing configuration. In doing so, I'm noticing something weird about a > particular path, and since I'm rather tired at the moment, wanted to have a > fresh set of eyes take a look at it. Can someone explain to me the reason > why Path #3 is being chosen over the lower AS-Path #1 and #2 routing > choices? > > core1#show ip bgp 4.68.95.11 > BGP routing table entry for 4.0.0.0/9, version 6 > Paths: (4 available, best #3, table Default-IP-Routing-Table) > Multipath: eBGP > Not advertised to any peer > 3356, (aggregated by 3356 4.69.130.12) > 4.53.194.5 from 4.53.194.5 (4.69.181.195) > Origin IGP, metric 1000, localpref 100, valid, external, > atomic-aggregate > Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2006 > 3356, (aggregated by 3356 4.69.130.12), (received-only) > 4.53.194.5 from 4.53.194.5 (4.69.181.195) > Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate > Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2006 > 2828 3356, (aggregated by 3356 4.69.130.12) > 67.106.93.233 (metric 20) from 207.166.219.2 (207.166.219.2) > Origin IGP, metric 1000, localpref 150, valid, internal, > atomic-aggregate, best > 2828 3356, (aggregated by 3356 4.69.130.12), (received-only) > 67.106.93.233 (metric 20) from 207.166.219.2 (207.166.219.2) > Origin IGP, metric 3, localpref 150, valid, internal, atomic-aggregate > > _______________________________________________ > 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 Wed Sep 10 10:04:05 2008 From: jfitz at Princeton.EDU (Jeff Fitzwater) Date: Wed, 10 Sep 2008 10:04:05 -0400 Subject: [c-nsp] FWSM shun counters followup Message-ID: <334184A0-3EAA-40DB-902A-05B64E971127@princeton.edu> This is a followup of my previous question about FWSM "show shun statistics" and the counter value being only 64K. I sent the problem to CISCO tech which returned the following response... ---------- > I have confirmed with our developers that the hit count is a two > byte counter in the NPs so the limit is actually 64K. Currently we > do not have a way to increase it beyond that. --------- My followup question to the list is.... On an ASA or PIX is the counter larger than 64K, 2 bytes? In reading a CISCO book on ASA PIX and FWSM, they show an example that has a host counter value of 21277328 which is clearly over 64K. I am guessing that maybe a PIX or ASA has a larger counter. If the FWSM truly only has 64k, which is what I see on my FWSM running 4.02, this is almost useless especially when counter wraps multiple times or even wraps to the same value (unlikely as that may be). We do some calculations on the counter to determine how long to keep the shun in place, but as we found out it is only 64K which with certain scans hits 64k quickly and wraps. Does anybody see the same problem or can you confirm the counter size on PIX ASA or FWSM? Thanks for any help. Jeff Fitzwater OIT Network Systems Princeton University From nasir.shaikh at bt.com Wed Sep 10 10:07:27 2008 From: nasir.shaikh at bt.com (nasir.shaikh at bt.com) Date: Wed, 10 Sep 2008 15:07:27 +0100 Subject: [c-nsp] Using CA certificates and pre-shared keys on the same box Message-ID: Hi, I have a 2851 working as a hub for remote VPN sites using CA certificates. I want to add other remotes which are using pre-shared keys as their authentication method. Is it possible to configure the hub router to support both the CA trustpoint and per-shared keys? Kind regards Nasir Shaikh From rens at autempspourmoi.be Wed Sep 10 10:11:09 2008 From: rens at autempspourmoi.be (Rens) Date: Wed, 10 Sep 2008 16:11:09 +0200 Subject: [c-nsp] Router reloads on it's own Message-ID: Can anyone help me with the following? How can I get more info regarding this error message?: System returned to ROM by bus error at PC 0x60995708, address 0x60995708 at 12:09:02 CET Mon Sep 8 2008 System restarted at 12:10:43 CET Mon Sep 8 2008 System image file is "disk0:c7200-p-mz.122-25.S11.bin" Cisco 7206VXR (NPE400) processor (revision A) with 491520K/32768K bytes of memory. Processor board ID 23690131 R7000 CPU at 350Mhz, Implementation 39, Rev 3.2, 256KB L2 Cache 6 slot VXR midplane, Version 2.3 Last reset from watchdog reset From damin at nacs.net Wed Sep 10 10:03:01 2008 From: damin at nacs.net (Gregory Boehnlein) Date: Wed, 10 Sep 2008 10:03:01 -0400 Subject: [c-nsp] BGP Route Selection In-Reply-To: <20080910103147.GG17238@greenie.muc.de> References: <16af01c912f7$910a6750$b31f35f0$@net> <20080910103147.GG17238@greenie.muc.de> Message-ID: <17de01c9134d$f0104f20$d030ed60$@net> Thanks to everyone that replied.. indeed, I typoed on my route-map.. core1#show route-map as-3356-incoming route-map as-3356-incoming, permit, sequence 5 Match clauses: as-path (as-path filter): 99 Set clauses: local-preference 150 Policy routing matches: 0 packets, 0 bytes route-map as-3356-incoming, permit, sequence 10 Match clauses: Set clauses: metric 1000 local-preference 100 Policy routing matches: 0 packets, 0 bytes That the as-path filter should be 97, not 99. > -----Original Message----- > From: Gert Doering [mailto:gert at greenie.muc.de] > Sent: Wednesday, September 10, 2008 6:32 AM > To: Gregory Boehnlein > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] BGP Route Selection > > Hi, > > On Tue, Sep 09, 2008 at 11:44:45PM -0400, Gregory Boehnlein wrote: > > 3356, (aggregated by 3356 4.69.130.12) > > 4.53.194.5 from 4.53.194.5 (4.69.181.195) > > Origin IGP, metric 1000, localpref 100, valid, external, > > atomic-aggregate > > Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2006 > > 3356, (aggregated by 3356 4.69.130.12), (received-only) > > 4.53.194.5 from 4.53.194.5 (4.69.181.195) > > Origin IGP, metric 0, localpref 100, valid, external, atomic- > aggregate > > Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2006 > > 2828 3356, (aggregated by 3356 4.69.130.12) > > 67.106.93.233 (metric 20) from 207.166.219.2 (207.166.219.2) > > Origin IGP, metric 1000, localpref 150, valid, internal, > > atomic-aggregate, best > > "localpref 150" means "ignore path length, force this path to win". > > (default localpref is 100, larger numbers = better) > > 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 rodunn at cisco.com Wed Sep 10 11:26:51 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Wed, 10 Sep 2008 11:26:51 -0400 Subject: [c-nsp] Router reloads on it's own In-Reply-To: References: Message-ID: <20080910152651.GQ11984@rtp-cse-489.cisco.com> What does 'sh region' say? It's a bus error where the PC and address match. Either it's bad memory if the PC value is out of valid text space or it's a stack corruption type issue which is a software bug. 12.2(25)S throttls is end of engineering. You would need to upgrade to 12.2(33)SRC1. Rodney On Wed, Sep 10, 2008 at 04:11:09PM +0200, Rens wrote: > Can anyone help me with the following? How can I get more info regarding > this error message?: > > > > System returned to ROM by bus error at PC 0x60995708, address 0x60995708 at > 12:09:02 CET Mon Sep 8 2008 > > System restarted at 12:10:43 CET Mon Sep 8 2008 > > System image file is "disk0:c7200-p-mz.122-25.S11.bin" > > > > Cisco 7206VXR (NPE400) processor (revision A) with 491520K/32768K bytes of > memory. > > Processor board ID 23690131 > > R7000 CPU at 350Mhz, Implementation 39, Rev 3.2, 256KB L2 Cache > > 6 slot VXR midplane, Version 2.3 > > > > Last reset from watchdog reset > > _______________________________________________ > 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 rootnet08 at gmail.com Wed Sep 10 11:28:06 2008 From: rootnet08 at gmail.com (root net) Date: Wed, 10 Sep 2008 10:28:06 -0500 Subject: [c-nsp] NBAR & QoS In-Reply-To: References: <89944ef40809100132g387f47c2qcef4f0a2aa91598d@mail.gmail.com> Message-ID: <89944ef40809100828y2a9105d5v8bca0d7901e185ad@mail.gmail.com> Chuck, I am pushing about 13Mbit with the small DSL base and sub interfaces. I expect to push more here by the end of Oct and wanted to make sure we are throttling the file sharing before it gets bad. I am running 12.2 SB what advantages do I have for running 12.4? Also what does your memory look like? rootnet On Wed, Sep 10, 2008 at 6:57 AM, Church, Charles wrote: > We're using it on a 2821 for the same purpose - QOS to 2 upstreams, and > file sharing shaping. Currently running about 10% CPU when pushing > about 9mb through it. It's probably good for almost a full DS-3 on the > 2821, at least in our application. If you can run 12.4 on the NPE225, > I'd say enable it on a couple subints (protocol discovery) at a time, > and keep an eye on the cpu. If CPU stays low, keep adding to it. I > seem to remember having some weird NBAR issues with 12.3. How much > traffic are you pushing through it currently? 20 to 30 customers > doesn't sound like it'd be a problem. > > Chuck > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net > Sent: Wednesday, September 10, 2008 4:32 AM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] NBAR & QoS > > > Hello, > > I am looking into running NBAR along side with QoS in our network. I > was > wondering what the list was doing if running NBAR. I want to protect > against excessive file sharing customers or at least throttle those > specific > applications. Some suggestions as the best place to configure this in a > network or what you all are doing is appreciated? Maybe even running on > a > mirror port? > > My thoughts are placing on Cisco 7206 NPE-225/256MB box but am not sure > if > we should upgrade to a 7204VXR NPE-400/512Mb or not. This box runs > terminates static (no PPPoE) DSL customers and about 20 to 30 > subinterfaces. Although may move to PPPoE in the future. CPU usage is > light > and memory operates around 120MB free give or take. > > Thanks in advanced! > > RootNet08 > _______________________________________________ > 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 rens at autempspourmoi.be Wed Sep 10 11:33:38 2008 From: rens at autempspourmoi.be (Rens) Date: Wed, 10 Sep 2008 17:33:38 +0200 Subject: [c-nsp] Router reloads on it's own In-Reply-To: <20080910152651.GQ11984@rtp-cse-489.cisco.com> References: <20080910152651.GQ11984@rtp-cse-489.cisco.com> Message-ID: <66DE9E928CAA445183946A2F39465B4A@EU.corp.clearwire.com> Here is sh region: show region Region Manager: Start End Size(b) Class Media Name 0x0E000000 0x0FFFFFFF 33554432 Iomem R/W iomem 0x60000000 0x7DFFFFFF 503316480 Local R/W main 0x60008DE0 0x6183C02F 25375312 IText R/O main:text 0x6183E000 0x6280387F 16537728 IData R/W main:data 0x62803880 0x62AFB89F 3112992 IBss R/W main:bss 0x62AFB8A0 0x63AFB89F 16777216 Local R/W main:heap 0x63AFB8F8 0x64AFB8F3 16777212 Local R/W main:heap 0x7E000000 0x7FFFFFFF 33554432 Iomem R/W iomem:(iomem_cwt) 0x80000000 0x8DFFFFFF 234881024 Local R/W main:(main_k0) 0xA0000000 0xADFFFFFF 234881024 Local R/W main:(main_k1) Free Region Manager: Start End Size(b) Class Media Name 0x64AFB948 0x7DFFFFFF 424691384 Local R/W heap -----Original Message----- From: Rodney Dunn [mailto:rodunn at cisco.com] Sent: mercredi 10 septembre 2008 17:27 To: Rens Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Router reloads on it's own What does 'sh region' say? It's a bus error where the PC and address match. Either it's bad memory if the PC value is out of valid text space or it's a stack corruption type issue which is a software bug. 12.2(25)S throttls is end of engineering. You would need to upgrade to 12.2(33)SRC1. Rodney On Wed, Sep 10, 2008 at 04:11:09PM +0200, Rens wrote: > Can anyone help me with the following? How can I get more info regarding > this error message?: > > > > System returned to ROM by bus error at PC 0x60995708, address 0x60995708 at > 12:09:02 CET Mon Sep 8 2008 > > System restarted at 12:10:43 CET Mon Sep 8 2008 > > System image file is "disk0:c7200-p-mz.122-25.S11.bin" > > > > Cisco 7206VXR (NPE400) processor (revision A) with 491520K/32768K bytes of > memory. > > Processor board ID 23690131 > > R7000 CPU at 350Mhz, Implementation 39, Rev 3.2, 256KB L2 Cache > > 6 slot VXR midplane, Version 2.3 > > > > Last reset from watchdog reset > > _______________________________________________ > 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 Wed Sep 10 11:28:35 2008 From: leonardo.souza at nec.com.br (Leonardo Gama Souza) Date: Wed, 10 Sep 2008 12:28:35 -0300 Subject: [c-nsp] RES: Using CA certificates and pre-shared keys on the same box References: Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E36@spsrvmail03.nec.br> Yes. Just add another isakmp policy statement using the pre-shared authentication mode. Cheers, Leonardo Gama. ________________________________ De: cisco-nsp-bounces at puck.nether.net em nome de nasir.shaikh at bt.com Enviada: qua 10/9/2008 11:07 Para: cisco-nsp at puck.nether.net Assunto: [c-nsp] Using CA certificates and pre-shared keys on the same box Hi, I have a 2851 working as a hub for remote VPN sites using CA certificates. I want to add other remotes which are using pre-shared keys as their authentication method. Is it possible to configure the hub router to support both the CA trustpoint and per-shared keys? Kind regards Nasir Shaikh _______________________________________________ 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 Wed Sep 10 11:40:28 2008 From: cchurc05 at harris.com (Church, Charles) Date: Wed, 10 Sep 2008 10:40:28 -0500 Subject: [c-nsp] NBAR & QoS In-Reply-To: <89944ef40809100828y2a9105d5v8bca0d7901e185ad@mail.gmail.com> References: <89944ef40809100132g387f47c2qcef4f0a2aa91598d@mail.gmail.com> <89944ef40809100828y2a9105d5v8bca0d7901e185ad@mail.gmail.com> Message-ID: >From what I've seen, NBAR doesn't use a whole lot of memory, it'll grab a small amount off the bat when you enable it, and that's it. Maybe 10 megs. I'm not familiar with 12.2SB though. I think you'd have to read the release notes for NBAR in the two trains. They've added more protocol support in the newer trains, that might be reason enough. Unless you can add the PDLMs to 12.2SB. I think 12.4 would be the most troublefree path though. Chuck ________________________________ From: root net [mailto:rootnet08 at gmail.com] Sent: Wednesday, September 10, 2008 11:28 AM To: Church, Charles Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] NBAR & QoS Chuck, I am pushing about 13Mbit with the small DSL base and sub interfaces. I expect to push more here by the end of Oct and wanted to make sure we are throttling the file sharing before it gets bad. I am running 12.2 SB what advantages do I have for running 12.4? Also what does your memory look like? rootnet On Wed, Sep 10, 2008 at 6:57 AM, Church, Charles wrote: We're using it on a 2821 for the same purpose - QOS to 2 upstreams, and file sharing shaping. Currently running about 10% CPU when pushing about 9mb through it. It's probably good for almost a full DS-3 on the 2821, at least in our application. If you can run 12.4 on the NPE225, I'd say enable it on a couple subints (protocol discovery) at a time, and keep an eye on the cpu. If CPU stays low, keep adding to it. I seem to remember having some weird NBAR issues with 12.3. How much traffic are you pushing through it currently? 20 to 30 customers doesn't sound like it'd be a problem. Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net Sent: Wednesday, September 10, 2008 4:32 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] NBAR & QoS Hello, I am looking into running NBAR along side with QoS in our network. I was wondering what the list was doing if running NBAR. I want to protect against excessive file sharing customers or at least throttle those specific applications. Some suggestions as the best place to configure this in a network or what you all are doing is appreciated? Maybe even running on a mirror port? My thoughts are placing on Cisco 7206 NPE-225/256MB box but am not sure if we should upgrade to a 7204VXR NPE-400/512Mb or not. This box runs terminates static (no PPPoE) DSL customers and about 20 to 30 subinterfaces. Although may move to PPPoE in the future. CPU usage is light and memory operates around 120MB free give or take. Thanks in advanced! RootNet08 _______________________________________________ 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 rootnet08 at gmail.com Wed Sep 10 12:02:08 2008 From: rootnet08 at gmail.com (root net) Date: Wed, 10 Sep 2008 11:02:08 -0500 Subject: [c-nsp] NBAR & QoS In-Reply-To: References: <89944ef40809100132g387f47c2qcef4f0a2aa91598d@mail.gmail.com> <89944ef40809100828y2a9105d5v8bca0d7901e185ad@mail.gmail.com> Message-ID: <89944ef40809100902m3608bab2t69874bacf8a45ebc@mail.gmail.com> Ok. I will read up on it for the IOS release. I hate to upgrade since this would involve taking the router down and it has been up for over year. That's great about the memory. I will test it out and let you know my findings. rootnet On Wed, Sep 10, 2008 at 10:40 AM, Church, Charles wrote: > From what I've seen, NBAR doesn't use a whole lot of memory, it'll grab a > small amount off the bat when you enable it, and that's it. Maybe 10 megs. > I'm not familiar with 12.2SB though. I think you'd have to read the release > notes for NBAR in the two trains. They've added more protocol support in > the newer trains, that might be reason enough. Unless you can add the PDLMs > to 12.2SB. I think 12.4 would be the most troublefree path though. > > Chuck > ------------------------------ > *From:* root net [mailto:rootnet08 at gmail.com] > *Sent:* Wednesday, September 10, 2008 11:28 AM > *To:* Church, Charles > *Cc:* cisco-nsp at puck.nether.net > *Subject:* Re: [c-nsp] NBAR & QoS > > Chuck, > > I am pushing about 13Mbit with the small DSL base and sub interfaces. I > expect to push more here by the end of Oct and wanted to make sure we are > throttling the file sharing before it gets bad. I am running 12.2 SB what > advantages do I have for running 12.4? Also what does your memory look > like? > > rootnet > > On Wed, Sep 10, 2008 at 6:57 AM, Church, Charles wrote: > >> We're using it on a 2821 for the same purpose - QOS to 2 upstreams, and >> file sharing shaping. Currently running about 10% CPU when pushing >> about 9mb through it. It's probably good for almost a full DS-3 on the >> 2821, at least in our application. If you can run 12.4 on the NPE225, >> I'd say enable it on a couple subints (protocol discovery) at a time, >> and keep an eye on the cpu. If CPU stays low, keep adding to it. I >> seem to remember having some weird NBAR issues with 12.3. How much >> traffic are you pushing through it currently? 20 to 30 customers >> doesn't sound like it'd be a problem. >> >> Chuck >> >> -----Original Message----- >> From: cisco-nsp-bounces at puck.nether.net >> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net >> Sent: Wednesday, September 10, 2008 4:32 AM >> To: cisco-nsp at puck.nether.net >> Subject: [c-nsp] NBAR & QoS >> >> >> Hello, >> >> I am looking into running NBAR along side with QoS in our network. I >> was >> wondering what the list was doing if running NBAR. I want to protect >> against excessive file sharing customers or at least throttle those >> specific >> applications. Some suggestions as the best place to configure this in a >> network or what you all are doing is appreciated? Maybe even running on >> a >> mirror port? >> >> My thoughts are placing on Cisco 7206 NPE-225/256MB box but am not sure >> if >> we should upgrade to a 7204VXR NPE-400/512Mb or not. This box runs >> terminates static (no PPPoE) DSL customers and about 20 to 30 >> subinterfaces. Although may move to PPPoE in the future. CPU usage is >> light >> and memory operates around 120MB free give or take. >> >> Thanks in advanced! >> >> RootNet08 >> _______________________________________________ >> 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 luan at netcraftsmen.net Wed Sep 10 12:21:02 2008 From: luan at netcraftsmen.net (Luan Nguyen) Date: Wed, 10 Sep 2008 12:21:02 -0400 Subject: [c-nsp] Using CA certificates and pre-shared keys on the same box In-Reply-To: References: Message-ID: <003901c91361$37eaa5d0$a7bff170$@net> You could try to configure 2 ISAKMP profiles: one use CA, one use pre-shared. Then configure 2 IPSEC profiles accordingly. -Luan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of nasir.shaikh at bt.com Sent: Wednesday, September 10, 2008 10:07 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Using CA certificates and pre-shared keys on the same box Hi, I have a 2851 working as a hub for remote VPN sites using CA certificates. I want to add other remotes which are using pre-shared keys as their authentication method. Is it possible to configure the hub router to support both the CA trustpoint and per-shared keys? Kind regards Nasir Shaikh _______________________________________________ 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 ASikkema at office.unet.nl Wed Sep 10 11:28:29 2008 From: ASikkema at office.unet.nl (Andreas Sikkema) Date: Wed, 10 Sep 2008 17:28:29 +0200 Subject: [c-nsp] AS5350 and ENUM, what happens when DNS gives no results? Message-ID: Hi, We've got a Cisco AS5350 with a reasonably complex configuration with several inbound dialpeers that involve calling TCL applications. For various reasons we want to route some calls around all this configuration and send them directly to a SIP server. We've thought of doing this with ENUM because those calls are (as I mentioned before in my question about hairpins) are only recognizable by their Called Number. What I would really like to do is to lookup the destination in ENUm and when there's nothing in the DNS server for that number to use the existing configuration. Is there a way or should I just forget about this? -- Andreas Sikkema From christian at broknrobot.com Wed Sep 10 12:41:05 2008 From: christian at broknrobot.com (Christian Koch) Date: Wed, 10 Sep 2008 12:41:05 -0400 Subject: [c-nsp] Setting the Remote Syslog Port in IOS Message-ID: I know i can set the remote syslog port on ASA/PIX's, but i don't seem to see that it is possible in IOS. I wanted to segregate logs by sending them from certain devices to separate syslog ports Can anyone confirm this behavior? Has anyone had the need to do something similar? Thanks Christian From rodunn at cisco.com Wed Sep 10 12:42:48 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Wed, 10 Sep 2008 12:42:48 -0400 Subject: [c-nsp] Router reloads on it's own In-Reply-To: <66DE9E928CAA445183946A2F39465B4A@EU.corp.clearwire.com> References: <20080910152651.GQ11984@rtp-cse-489.cisco.com> <66DE9E928CAA445183946A2F39465B4A@EU.corp.clearwire.com> Message-ID: <20080910164248.GX11984@rtp-cse-489.cisco.com> It's in the text region. Almost surely a software bug. I decoded the PC and it's in the arp command code. Did you do a clear arp or any other arp commmand? If so you will see it in the command history of the crashinfo file. The code is old so it's probably already fixed. Was a crashinfo file saved in bootflash? That might give a bit more information or if you can post On Wed, Sep 10, 2008 at 05:33:38PM +0200, Rens wrote: > Here is sh region: > > show region > Region Manager: > > Start End Size(b) Class Media Name > 0x0E000000 0x0FFFFFFF 33554432 Iomem R/W iomem > 0x60000000 0x7DFFFFFF 503316480 Local R/W main > 0x60008DE0 0x6183C02F 25375312 IText R/O main:text > 0x6183E000 0x6280387F 16537728 IData R/W main:data > 0x62803880 0x62AFB89F 3112992 IBss R/W main:bss > 0x62AFB8A0 0x63AFB89F 16777216 Local R/W main:heap > 0x63AFB8F8 0x64AFB8F3 16777212 Local R/W main:heap > 0x7E000000 0x7FFFFFFF 33554432 Iomem R/W iomem:(iomem_cwt) > 0x80000000 0x8DFFFFFF 234881024 Local R/W main:(main_k0) > 0xA0000000 0xADFFFFFF 234881024 Local R/W main:(main_k1) > > > Free Region Manager: > > Start End Size(b) Class Media Name > 0x64AFB948 0x7DFFFFFF 424691384 Local R/W heap > > -----Original Message----- > From: Rodney Dunn [mailto:rodunn at cisco.com] > Sent: mercredi 10 septembre 2008 17:27 > To: Rens > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Router reloads on it's own > > What does 'sh region' say? > > It's a bus error where the PC and address match. > Either it's bad memory if the PC value is out of valid text space > or it's a stack corruption type issue which is a software bug. > > 12.2(25)S throttls is end of engineering. > > You would need to upgrade to 12.2(33)SRC1. > > Rodney > > > On Wed, Sep 10, 2008 at 04:11:09PM +0200, Rens wrote: > > Can anyone help me with the following? How can I get more info regarding > > this error message?: > > > > > > > > System returned to ROM by bus error at PC 0x60995708, address 0x60995708 > at > > 12:09:02 CET Mon Sep 8 2008 > > > > System restarted at 12:10:43 CET Mon Sep 8 2008 > > > > System image file is "disk0:c7200-p-mz.122-25.S11.bin" > > > > > > > > Cisco 7206VXR (NPE400) processor (revision A) with 491520K/32768K bytes of > > memory. > > > > Processor board ID 23690131 > > > > R7000 CPU at 350Mhz, Implementation 39, Rev 3.2, 256KB L2 Cache > > > > 6 slot VXR midplane, Version 2.3 > > > > > > > > Last reset from watchdog reset > > > > _______________________________________________ > > 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 coloccia at geneseo.edu Wed Sep 10 13:45:00 2008 From: coloccia at geneseo.edu (Rick Coloccia) Date: Wed, 10 Sep 2008 13:45:00 -0400 Subject: [c-nsp] Setting the Remote Syslog Port in IOS In-Reply-To: References: Message-ID: <48C8079C.7020208@geneseo.edu> Interesting approach. I installed syslog-ng on my syslog server (CentOS 5.2) and am filtering very extensively based on source host and pattern matching inside the trap. I have lots of different files in place now based on what cisco device created the trap and what the message in the trap is. But they are all the same facility. You might find that a lot more useful. Take a look at syslog-ng, and don't let it overwhelm you - it's not as bad as it looks to set up. Assuming a linux box, you can leave your existing syslog in place, and just add this to a system to receive syslogs from over the network. Very, very configurable. -Rick Christian Koch wrote: > I know i can set the remote syslog port on ASA/PIX's, but i don't seem > to see that it is possible in IOS. > > I wanted to segregate logs by sending them from certain devices to > separate syslog ports > > Can anyone confirm this behavior? > > Has anyone had the need to do something similar? > > Thanks > > > Christian > _______________________________________________ > 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/ > -- Rick Coloccia, Jr. Network Manager State University of NY College at Geneseo 1 College Circle, 119 South Hall Geneseo, NY 14454 V: 585-245-5577 F: 585-245-5579 From steve.mcnamara at gmail.com Wed Sep 10 14:36:54 2008 From: steve.mcnamara at gmail.com (Steve McNamara) Date: Wed, 10 Sep 2008 19:36:54 +0100 Subject: [c-nsp] 4900M 10/100/1000 management interfaces Message-ID: <494a4f80809101136u7ef0593eg8d7376842b845724@mail.gmail.com> Hi, This is going is be something every embarrasing I feel :-) I've got a Cisco 4900M running 12.2(46)SG, it has a 10/100/1000 mgt interface on the back of the switch that I want to use to manage the switch, but when I boot it up I do not see an interface corresponding to this. I see the 20x Gig interfaces from Slot 2 and the 8x 10Gig interface from Slot 1.... any ideas how to configure the 10/100/1000 mgt interface? Cheers Steve From perc69 at gmail.com Wed Sep 10 14:46:55 2008 From: perc69 at gmail.com (Pelle) Date: Wed, 10 Sep 2008 20:46:55 +0200 Subject: [c-nsp] Setting the Remote Syslog Port in IOS In-Reply-To: References: Message-ID: <746ca6da0809101146w40692ffo97e6ab49e0386eb2@mail.gmail.com> On Wed, Sep 10, 2008 at 18:41, Christian Koch wrote: > I wanted to segregate logs by sending them from certain devices to > separate syslog ports Why not simply use different facilities? -- Pelle From clane1875 at gmail.com Wed Sep 10 14:58:16 2008 From: clane1875 at gmail.com (Chris Lane) Date: Wed, 10 Sep 2008 14:58:16 -0400 Subject: [c-nsp] GSR12008 Error Message-ID: <2e1cd850809101158v27cd4427tc3d73c0bcdac6cf2@mail.gmail.com> All, GSR question, appears Cisco finally got around to updating the IOS train on 12.0.32.S ? we have been running S8 for a while but S11 just came out and it appears to have many new features! One of my routers is running 12.0.32.S6 ? its been so for 2years. I had a bad 8 port FastE lc a while back so I replaced just recently with a known good lc tested in the lab, So I sent it to replace the failed one ~ after 2 days I started getting these errors. %FABRIC-3-ERR_HANDLE: %RP-3-FABRIC_UNI %FIA-3-HALT L%LC-6-BMACMDRPLY >From what I gather this is the RP is having trouble communicating with the LC. One of these errors suggests upgrading IOS ~ but S6 to S8 isn't that big of a deal and couldn't possibly be the culprit could it? Is this RP related? And if so I could easily flip to the backup RP. Any suggestions would be super appreciative. -- //CL From christian at broknrobot.com Wed Sep 10 14:03:39 2008 From: christian at broknrobot.com (Christian Koch) Date: Wed, 10 Sep 2008 14:03:39 -0400 Subject: [c-nsp] Setting the Remote Syslog Port in IOS In-Reply-To: <48C8079C.7020208@geneseo.edu> References: <48C8079C.7020208@geneseo.edu> Message-ID: This is actually what i do now, but we are moving away from syslog-ng to splunk, basically for the ease of searching and report generation, especially for the lower tiered noc techs, so in splunk you can create multiple "virtual" instances, so what we wanted to do was separate say customer logging to its own port, sec logs to its own port and associated with the splunk instance configured to accept syslog messages on port x/y/z etc. Otherwise, I agree, syslog-ng can be very good if configured correctly and extensively Christian On Wed, Sep 10, 2008 at 1:45 PM, Rick Coloccia wrote: > Interesting approach. I installed syslog-ng on my syslog server (CentOS > 5.2) and am filtering very extensively based on source host and pattern > matching inside the trap. I have lots of different files in place now based > on what cisco device created the trap and what the message in the trap is. > But they are all the same facility. You might find that a lot more useful. > Take a look at syslog-ng, and don't let it overwhelm you - it's not as bad > as it looks to set up. Assuming a linux box, you can leave your existing > syslog in place, and just add this to a system to receive syslogs from over > the network. Very, very configurable. > > -Rick > > Christian Koch wrote: >> >> I know i can set the remote syslog port on ASA/PIX's, but i don't seem >> to see that it is possible in IOS. >> >> I wanted to segregate logs by sending them from certain devices to >> separate syslog ports >> >> Can anyone confirm this behavior? >> >> Has anyone had the need to do something similar? >> >> Thanks >> >> >> Christian >> _______________________________________________ >> 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/ >> > > -- > Rick Coloccia, Jr. > Network Manager > State University of NY College at Geneseo > 1 College Circle, 119 South Hall > Geneseo, NY 14454 > V: 585-245-5577 > F: 585-245-5579 > > From jfitz at Princeton.EDU Wed Sep 10 15:14:06 2008 From: jfitz at Princeton.EDU (Jeff Fitzwater) Date: Wed, 10 Sep 2008 15:14:06 -0400 Subject: [c-nsp] 4900M 10/100/1000 management interfaces In-Reply-To: <494a4f80809101136u7ef0593eg8d7376842b845724@mail.gmail.com> References: <494a4f80809101136u7ef0593eg8d7376842b845724@mail.gmail.com> Message-ID: The interface is Fa1 and has a fixed config name of mgmtVrf What they did was set up a VRF interface so that you can have an isolated management port that resides in a separate routing domain. One problem i found is that you need the latest code that supports the new interface (12.2-46SG). I had to load it on the flash card and then boot from flash. The other trick is the default route must be entered as follows... ip route vrf mgmtVrf 0.0.0.0 0.0.0.0 n.n.n.n Also... ntp server vrf mgmtVrf Jeff Fitzwater OIT Network Systems Princeton University On Sep 10, 2008, at 2:36 PM, Steve McNamara wrote: > Hi, > > This is going is be something every embarrasing I feel :-) > > I've got a Cisco 4900M running 12.2(46)SG, it has a 10/100/1000 mgt > interface on the back of the switch that I want to use to manage the > switch, but when I boot it up I do not see an interface corresponding > to this. I see the 20x Gig interfaces from Slot 2 and the 8x 10Gig > interface from Slot 1.... any ideas how to configure the 10/100/1000 > mgt interface? > > Cheers > Steve > _______________________________________________ > 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 isplists at duracom.net Wed Sep 10 15:33:03 2008 From: isplists at duracom.net (Rhino Lists) Date: Wed, 10 Sep 2008 14:33:03 -0500 Subject: [c-nsp] Configure Backup Radius Server Message-ID: <036f01c9137c$0b0fff40$212ffdc0$@net> I have a 7206 terminating DSL connections currently I only have it pointed to my primary RADIUS server. I am now wanting to also point it to my backup RADIUS server for the obvious reasons. I have the following in mind: radius-server dead-criteria time 5 tries 4 radius-server host aaa.bbb.ccc.5 auth-port 1812 acct-port 1813 radius-server host aaa.bbb.ccc.6 auth-port 1812 acct-port 1813 radius-server deadtime 1 With this current config how long can the primary be down or will it always try the secondary when the primary is down? From achatz at forthnet.gr Wed Sep 10 15:55:50 2008 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Wed, 10 Sep 2008 22:55:50 +0300 Subject: [c-nsp] Setting the Remote Syslog Port in IOS In-Reply-To: References: Message-ID: <48C82646.7040402@forthnet.gr> Have you tried "logging host XXX transport udp port Y"? -- Tassos Christian Koch wrote on 10/09/2008 19:41: > I know i can set the remote syslog port on ASA/PIX's, but i don't seem > to see that it is possible in IOS. > > I wanted to segregate logs by sending them from certain devices to > separate syslog ports > > Can anyone confirm this behavior? > > Has anyone had the need to do something similar? > > Thanks > > > Christian > _______________________________________________ > 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 steve.mcnamara at gmail.com Wed Sep 10 16:01:03 2008 From: steve.mcnamara at gmail.com (Steve McNamara) Date: Wed, 10 Sep 2008 21:01:03 +0100 Subject: [c-nsp] 4900M 10/100/1000 management interfaces In-Reply-To: References: <494a4f80809101136u7ef0593eg8d7376842b845724@mail.gmail.com> Message-ID: <494a4f80809101301q55545e11n1839102b84676c5@mail.gmail.com> Thanks Jeff I thought I was running 12.2(46)SG, but I forgot to change the config-register.. so it was kind of embarrasing after all :-) I now see the interface, thanks for your help. One more question though. The interface says 10/100/1000 MGT, yet it is "interface FastEthernet1" and will only let me configure the speed as 100 - but my laptop connects at 1Gig. The show interface also shows it as 100m.... any ideas on if it is definitely a 1Gig interface? Thanks again On Wed, Sep 10, 2008 at 20:14, Jeff Fitzwater wrote: > The interface is Fa1 and has a fixed config name of mgmtVrf > What they did was set up a VRF interface so that you can have an isolated > management port that resides in a separate routing domain. One problem i > found is that you need the latest code that supports the new interface > (12.2-46SG). I had to load it on the flash card and then boot from > flash. > > The other trick is the default route must be entered as follows... > > > ip route vrf mgmtVrf 0.0.0.0 0.0.0.0 n.n.n.n > > Also... ntp server vrf mgmtVrf > > > > Jeff Fitzwater > OIT Network Systems > Princeton University > > On Sep 10, 2008, at 2:36 PM, Steve McNamara wrote: > >> Hi, >> >> This is going is be something every embarrasing I feel :-) >> >> I've got a Cisco 4900M running 12.2(46)SG, it has a 10/100/1000 mgt >> interface on the back of the switch that I want to use to manage the >> switch, but when I boot it up I do not see an interface corresponding >> to this. I see the 20x Gig interfaces from Slot 2 and the 8x 10Gig >> interface from Slot 1.... any ideas how to configure the 10/100/1000 >> mgt interface? >> >> Cheers >> Steve >> _______________________________________________ >> 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 Wed Sep 10 16:10:04 2008 From: leonardo.souza at nec.com.br (Leonardo Gama Souza) Date: Wed, 10 Sep 2008 17:10:04 -0300 Subject: [c-nsp] RES: GSR12008 Error References: <2e1cd850809101158v27cd4427tc3d73c0bcdac6cf2@mail.gmail.com> Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E39@spsrvmail03.nec.br> Hi, Look for errors in "show controller fia". Maybe the LC was badly seated... Maybe you have a bad SFC... There are a lot of possibilities. Cheers, Leonardo Gama. ________________________________ De: cisco-nsp-bounces at puck.nether.net em nome de Chris Lane Enviada: qua 10/9/2008 15:58 Para: cisco-nsp at puck.nether.net Assunto: [c-nsp] GSR12008 Error All, GSR question, appears Cisco finally got around to updating the IOS train on 12.0.32.S - we have been running S8 for a while but S11 just came out and it appears to have many new features! One of my routers is running 12.0.32.S6 - its been so for 2years. I had a bad 8 port FastE lc a while back so I replaced just recently with a known good lc tested in the lab, So I sent it to replace the failed one ~ after 2 days I started getting these errors. %FABRIC-3-ERR_HANDLE: %RP-3-FABRIC_UNI %FIA-3-HALT L%LC-6-BMACMDRPLY >From what I gather this is the RP is having trouble communicating with the LC. One of these errors suggests upgrading IOS ~ but S6 to S8 isn't that big of a deal and couldn't possibly be the culprit could it? Is this RP related? And if so I could easily flip to the backup RP. Any suggestions would be super appreciative. -- //CL _______________________________________________ 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 christian at broknrobot.com Wed Sep 10 16:22:02 2008 From: christian at broknrobot.com (Christian Koch) Date: Wed, 10 Sep 2008 16:22:02 -0400 Subject: [c-nsp] Setting the Remote Syslog Port in IOS In-Reply-To: <746ca6da0809101146w40692ffo97e6ab49e0386eb2@mail.gmail.com> References: <746ca6da0809101146w40692ffo97e6ab49e0386eb2@mail.gmail.com> Message-ID: because that is not how splunk works, we want to create separate splunk instances, each instance has its own syslog port... On Wed, Sep 10, 2008 at 2:46 PM, Pelle wrote: > On Wed, Sep 10, 2008 at 18:41, Christian Koch wrote: > >> I wanted to segregate logs by sending them from certain devices to >> separate syslog ports > > Why not simply use different facilities? > > -- > Pelle > _______________________________________________ > 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 christian at broknrobot.com Wed Sep 10 16:24:34 2008 From: christian at broknrobot.com (Christian Koch) Date: Wed, 10 Sep 2008 16:24:34 -0400 Subject: [c-nsp] Setting the Remote Syslog Port in IOS In-Reply-To: <48C82646.7040402@forthnet.gr> References: <48C82646.7040402@forthnet.gr> Message-ID: checked for any switches after the inputting the ip address on logging host command but nothing was available #logging host 1.1.1.1 transport ? % Unrecognized command On Wed, Sep 10, 2008 at 3:55 PM, Tassos Chatzithomaoglou wrote: > Have you tried "logging host XXX transport udp port Y"? > > -- > Tassos > > Christian Koch wrote on 10/09/2008 19:41: >> >> I know i can set the remote syslog port on ASA/PIX's, but i don't seem >> to see that it is possible in IOS. >> >> I wanted to segregate logs by sending them from certain devices to >> separate syslog ports >> >> Can anyone confirm this behavior? >> >> Has anyone had the need to do something similar? >> >> Thanks >> >> >> Christian >> _______________________________________________ >> 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 lesmith at ecsis.net Wed Sep 10 16:19:15 2008 From: lesmith at ecsis.net (Larry Smith) Date: Wed, 10 Sep 2008 15:19:15 -0500 Subject: [c-nsp] Configure Backup Radius Server In-Reply-To: <036f01c9137c$0b0fff40$212ffdc0$@net> References: <036f01c9137c$0b0fff40$212ffdc0$@net> Message-ID: <200809101519.15107.lesmith@ecsis.net> On Wed September 10 2008 14:33, Rhino Lists wrote: > I have a 7206 terminating DSL connections currently I only have it pointed > to my primary RADIUS server. I am now wanting to also point it to my > backup RADIUS server for the obvious reasons. I have the following in > mind: > > > > radius-server dead-criteria time 5 tries 4 > > radius-server host aaa.bbb.ccc.5 auth-port 1812 acct-port 1813 > > radius-server host aaa.bbb.ccc.6 auth-port 1812 acct-port 1813 > > radius-server deadtime 1 > > With this current config how long can the primary be down or will it always > try the secondary when the primary is down? Believe the "deadtime" tells the router how long to "ignore" a non-responsive radius server. The default is 0, which says always check the servers in the order given. With a deadtime of 1 (minute) your router should "ignore" that server for 1 minute if it is not responsive, and then try it again (and ignore another minute if still not responding). -- Larry Smith lesmith at ecsis.net From clane1875 at gmail.com Wed Sep 10 16:25:46 2008 From: clane1875 at gmail.com (Chris Lane) Date: Wed, 10 Sep 2008 16:25:46 -0400 Subject: [c-nsp] GSR12008 Error In-Reply-To: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E39@spsrvmail03.nec.br> References: <2e1cd850809101158v27cd4427tc3d73c0bcdac6cf2@mail.gmail.com> <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E39@spsrvmail03.nec.br> Message-ID: <2e1cd850809101325q419cb595k16ef2c039e27d941@mail.gmail.com> No errors as you can see. cr.la1.ca#sh controller fia Fabric configuration: 2.4Gbps bandwidth, redundant fabric Master Scheduler: Slot 17 Backup Scheduler: Slot 16 >From Fabric FIA Errors ----------------------- redund fifo parity 0 redund overflow 0 cell drops 0 crc32 lkup parity 0 cell parity 0 crc32 0 Switch cards present 0x001F Slots 16 17 18 19 20 Switch cards monitored 0x001F Slots 16 17 18 19 20 Slot: 16 17 18 19 20 Name: csc0 csc1 sfc0 sfc1 sfc2 -------- -------- -------- -------- -------- los 0 0 0 0 0 state Off Off Off Off Off crc16 0 0 0 0 0 To Fabric FIA Errors ----------------------- sca not pres 0 req error 0 uni fifo overflow 0 grant parity 0 multi req 0 uni fifo undrflow 0 cntrl parity 0 uni req 0 crc32 lkup parity 0 multi fifo 0 empty dst req 0 handshake error 0 On Wed, Sep 10, 2008 at 4:10 PM, Leonardo Gama Souza < leonardo.souza at nec.com.br> wrote: > Hi, > > Look for errors in "show controller fia". > Maybe the LC was badly seated... > Maybe you have a bad SFC... > There are a lot of possibilities. > > Cheers, > Leonardo Gama. > > ------------------------------ > *De:* cisco-nsp-bounces at puck.nether.net em nome de Chris Lane > *Enviada:* qua 10/9/2008 15:58 > *Para:* cisco-nsp at puck.nether.net > *Assunto:* [c-nsp] GSR12008 Error > > All, > > GSR question, appears Cisco finally got around to updating the IOS train on > 12.0.32.S ? we have been running S8 for a while but S11 just came out and > it > appears to have many new features! One of my routers is running 12.0.32.S6 > ? > its been so for 2years. I had a bad 8 port FastE lc a while back so I > replaced just recently with a known good lc tested in the lab, So I sent > it > to replace the failed one ~ after 2 days I started getting these errors. > > %FABRIC-3-ERR_HANDLE: > > %RP-3-FABRIC_UNI > > %FIA-3-HALT > > L%LC-6-BMACMDRPLY > > > > >From what I gather this is the RP is having trouble communicating with the > LC. One of these errors suggests upgrading IOS ~ but S6 to S8 isn't that > big of a deal and couldn't possibly be the culprit could it? Is this RP > related? And if so I could easily flip to the backup RP. > > Any suggestions would be super appreciative. > > -- > //CL > _______________________________________________ > 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/ > -- //CL From leonardo.souza at nec.com.br Wed Sep 10 16:23:50 2008 From: leonardo.souza at nec.com.br (Leonardo Gama Souza) Date: Wed, 10 Sep 2008 17:23:50 -0300 Subject: [c-nsp] RES: GSR12008 Error References: <2e1cd850809101158v27cd4427tc3d73c0bcdac6cf2@mail.gmail.com><9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E39@spsrvmail03.nec.br> <2e1cd850809101325q419cb595k16ef2c039e27d941@mail.gmail.com> Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3A@spsrvmail03.nec.br> Oh. I forgot one thing. You must issue this command on all LC as well. ________________________________ De: Chris Lane [mailto:clane1875 at gmail.com] Enviada: qua 10/9/2008 17:25 Para: Leonardo Gama Souza Cc: cisco-nsp at puck.nether.net Assunto: Re: [c-nsp] GSR12008 Error No errors as you can see. cr.la1.ca#sh controller fia Fabric configuration: 2.4Gbps bandwidth, redundant fabric Master Scheduler: Slot 17 Backup Scheduler: Slot 16 >From Fabric FIA Errors ----------------------- redund fifo parity 0 redund overflow 0 cell drops 0 crc32 lkup parity 0 cell parity 0 crc32 0 Switch cards present 0x001F Slots 16 17 18 19 20 Switch cards monitored 0x001F Slots 16 17 18 19 20 Slot: 16 17 18 19 20 Name: csc0 csc1 sfc0 sfc1 sfc2 -------- -------- -------- -------- -------- los 0 0 0 0 0 state Off Off Off Off Off crc16 0 0 0 0 0 To Fabric FIA Errors ----------------------- sca not pres 0 req error 0 uni fifo overflow 0 grant parity 0 multi req 0 uni fifo undrflow 0 cntrl parity 0 uni req 0 crc32 lkup parity 0 multi fifo 0 empty dst req 0 handshake error 0 On Wed, Sep 10, 2008 at 4:10 PM, Leonardo Gama Souza wrote: Hi, Look for errors in "show controller fia". Maybe the LC was badly seated... Maybe you have a bad SFC... There are a lot of possibilities. Cheers, Leonardo Gama. ________________________________ De: cisco-nsp-bounces at puck.nether.net em nome de Chris Lane Enviada: qua 10/9/2008 15:58 Para: cisco-nsp at puck.nether.net Assunto: [c-nsp] GSR12008 Error All, GSR question, appears Cisco finally got around to updating the IOS train on 12.0.32.S - we have been running S8 for a while but S11 just came out and it appears to have many new features! One of my routers is running 12.0.32.S6 - its been so for 2years. I had a bad 8 port FastE lc a while back so I replaced just recently with a known good lc tested in the lab, So I sent it to replace the failed one ~ after 2 days I started getting these errors. %FABRIC-3-ERR_HANDLE: %RP-3-FABRIC_UNI %FIA-3-HALT L%LC-6-BMACMDRPLY >From what I gather this is the RP is having trouble communicating with the LC. One of these errors suggests upgrading IOS ~ but S6 to S8 isn't that big of a deal and couldn't possibly be the culprit could it? Is this RP related? And if so I could easily flip to the backup RP. Any suggestions would be super appreciative. -- //CL _______________________________________________ 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/ -- //CL From sethm at rollernet.us Wed Sep 10 16:43:01 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 10 Sep 2008 13:43:01 -0700 Subject: [c-nsp] IPv6 on the 877W In-Reply-To: <39F9A41A-29AF-4E51-B246-AE05264B4DA2@adhost.com> References: <8d05923216242716731b96c772f2ce0d.squirrel@webmail.rollernet.us> <39F9A41A-29AF-4E51-B246-AE05264B4DA2@adhost.com> Message-ID: <48C83155.1030006@rollernet.us> Well, I got my replacement 877W and tried all the helpful hints I recieved. Sadly, the Dot11Radio0 interface *does not* seem to support any "ipv6 ..." command, although it can be assigned an IPv4 address in the same manner. No problem for the wired segment, as the vlan 1 interface behaves as expected and it can be dual-stacked. I had kind of hoped this thing would have some very basic IPv6 support on it, but no such luck it seems for the wireless interface. ~Seth From clane1875 at gmail.com Wed Sep 10 16:44:33 2008 From: clane1875 at gmail.com (Chris Lane) Date: Wed, 10 Sep 2008 16:44:33 -0400 Subject: [c-nsp] GSR12008 Error In-Reply-To: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3B@spsrvmail03.nec.br> References: <2e1cd850809101158v27cd4427tc3d73c0bcdac6cf2@mail.gmail.com> <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E39@spsrvmail03.nec.br> <2e1cd850809101325q419cb595k16ef2c039e27d941@mail.gmail.com> <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3A@spsrvmail03.nec.br> <2e1cd850809101334u3ef1363duc755c91869434db5@mail.gmail.com> <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3B@spsrvmail03.nec.br> Message-ID: <2e1cd850809101344s3df471dv9150ea821c4a511c@mail.gmail.com> Darn, problem for me is i removed the 8 port FastE card that was causing all the grief last night because it kept reloading. I removed the one connection i had in LC and LC still continued to bounce.Here is the output anyways. ----------------------------------------- On Wed, Sep 10, 2008 at 4:33 PM, Leonardo Gama Souza < leonardo.souza at nec.com.br> wrote: > The same command. > execute-on all show controller fia > > Rgds. > > ------------------------------ > *De:* Chris Lane [mailto:clane1875 at gmail.com] > *Enviada:* qua 10/9/2008 17:34 > *Para:* Leonardo Gama Souza > > *Assunto:* Re: [c-nsp] GSR12008 Error > > You didn't add command ~ > Thanks > > On Wed, Sep 10, 2008 at 4:23 PM, Leonardo Gama Souza < > leonardo.souza at nec.com.br> wrote: > >> Oh. I forgot one thing. >> You must issue this command on all LC as well. >> >> >> ------------------------------ >> *De:* Chris Lane [mailto:clane1875 at gmail.com] >> *Enviada:* qua 10/9/2008 17:25 >> *Para:* Leonardo Gama Souza >> *Cc:* cisco-nsp at puck.nether.net >> *Assunto:* Re: [c-nsp] GSR12008 Error >> >> No errors as you can see. >> cr.la1.ca#sh controller fia >> Fabric configuration: 2.4Gbps bandwidth, redundant fabric >> Master Scheduler: Slot 17 Backup Scheduler: Slot 16 >> >> From Fabric FIA Errors >> ----------------------- >> redund fifo parity 0 redund overflow 0 cell drops 0 >> >> crc32 lkup parity 0 cell parity 0 crc32 0 >> >> Switch cards present 0x001F Slots 16 17 18 19 20 >> Switch cards monitored 0x001F Slots 16 17 18 19 20 >> Slot: 16 17 18 19 20 >> Name: csc0 csc1 sfc0 sfc1 sfc2 >> -------- -------- -------- -------- -------- >> los 0 0 0 0 0 >> state Off Off Off Off Off >> crc16 0 0 0 0 0 >> >> To Fabric FIA Errors >> ----------------------- >> sca not pres 0 req error 0 uni fifo overflow 0 >> >> grant parity 0 multi req 0 uni fifo undrflow 0 >> >> cntrl parity 0 uni req 0 crc32 lkup parity 0 >> >> multi fifo 0 empty dst req 0 handshake error 0 >> On Wed, Sep 10, 2008 at 4:10 PM, Leonardo Gama Souza < >> leonardo.souza at nec.com.br> wrote: >> >>> Hi, >>> >>> Look for errors in "show controller fia". >>> Maybe the LC was badly seated... >>> Maybe you have a bad SFC... >>> There are a lot of possibilities. >>> >>> Cheers, >>> Leonardo Gama. >>> >>> ------------------------------ >>> *De:* cisco-nsp-bounces at puck.nether.net em nome de Chris Lane >>> *Enviada:* qua 10/9/2008 15:58 >>> *Para:* cisco-nsp at puck.nether.net >>> *Assunto:* [c-nsp] GSR12008 Error >>> >>> All, >>> >>> GSR question, appears Cisco finally got around to updating the IOS train >>> on >>> 12.0.32.S ? we have been running S8 for a while but S11 just came out and >>> it >>> appears to have many new features! One of my routers is running >>> 12.0.32.S6 ? >>> its been so for 2years. I had a bad 8 port FastE lc a while back so I >>> replaced just recently with a known good lc tested in the lab, So I sent >>> it >>> to replace the failed one ~ after 2 days I started getting these errors. >>> >>> %FABRIC-3-ERR_HANDLE: >>> >>> %RP-3-FABRIC_UNI >>> >>> %FIA-3-HALT >>> >>> L%LC-6-BMACMDRPLY >>> >>> >>> >>> >From what I gather this is the RP is having trouble communicating with >>> the >>> LC. One of these errors suggests upgrading IOS ~ but S6 to S8 isn't that >>> big of a deal and couldn't possibly be the culprit could it? Is this RP >>> related? And if so I could easily flip to the backup RP. >>> >>> Any suggestions would be super appreciative. >>> >>> -- >>> //CL >>> _______________________________________________ >>> 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/ >>> >>> >> >> >> -- >> //CL >> > > > > -- > //CL > -- //CL From clane1875 at gmail.com Wed Sep 10 16:45:32 2008 From: clane1875 at gmail.com (Chris Lane) Date: Wed, 10 Sep 2008 16:45:32 -0400 Subject: [c-nsp] GSR12008 Error In-Reply-To: <2e1cd850809101344s3df471dv9150ea821c4a511c@mail.gmail.com> References: <2e1cd850809101158v27cd4427tc3d73c0bcdac6cf2@mail.gmail.com> <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E39@spsrvmail03.nec.br> <2e1cd850809101325q419cb595k16ef2c039e27d941@mail.gmail.com> <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3A@spsrvmail03.nec.br> <2e1cd850809101334u3ef1363duc755c91869434db5@mail.gmail.com> <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3B@spsrvmail03.nec.br> <2e1cd850809101344s3df471dv9150ea821c4a511c@mail.gmail.com> Message-ID: <2e1cd850809101345m243e623an130c04ef8d5faecf@mail.gmail.com> Here is output. cr.la1.ca#execute-on all show controller fia ========= Line Card (Slot 3) ========= >From Fabric FIA Errors ----------------------- redund overflow 0 cell drops 0 cell parity 0 Switch cards present 0x001F Slots 16 17 18 19 20 Switch cards monitored 0x001F Slots 16 17 18 19 20 Slot: 16 17 18 19 20 Name: csc0 csc1 sfc0 sfc1 sfc2 -------- -------- -------- -------- -------- los 0 0 0 0 0 state Off Off Off Off Off crc16 0 0 0 0 0 To Fabric FIA Errors ----------------------- sca not pres 0 req error 0 uni fifo overflow 0 grant parity 0 multi req 0 uni fifo undrflow 0 cntrl parity 0 uni req 0 multi fifo 0 empty dst req 0 handshake error 0 cell parity 0 ========= Line Card (Slot 4) ========= >From Fabric FIA Errors ----------------------- redund overflow 0 cell drops 0 cell parity 0 Switch cards present 0x001F Slots 16 17 18 19 20 Switch cards monitored 0x001F Slots 16 17 18 19 20 Slot: 16 17 18 19 20 Name: csc0 csc1 sfc0 sfc1 sfc2 -------- -------- -------- -------- -------- los 0 0 0 0 0 state Off Off Off Off Off crc16 0 0 0 0 0 To Fabric FIA Errors ----------------------- sca not pres 0 req error 0 uni fifo overflow 0 grant parity 0 multi req 0 uni fifo undrflow 0 cntrl parity 0 uni req 0 multi fifo 0 empty dst req 0 handshake error 0 cell parity 0 ========= Line Card (Slot 5) ========= >From Fabric FIA Errors ----------------------- redund overflow 0 cell drops 0 cell parity 0 Switch cards present 0x001F Slots 16 17 18 19 20 Switch cards monitored 0x001F Slots 16 17 18 19 20 Slot: 16 17 18 19 20 Name: csc0 csc1 sfc0 sfc1 sfc2 -------- -------- -------- -------- -------- los 0 0 0 0 0 state Off Off Off Off Off crc16 0 0 0 0 0 To Fabric FIA Errors ----------------------- sca not pres 0 req error 0 uni fifo overflow 0 grant parity 0 multi req 0 uni fifo undrflow 0 cntrl parity 0 uni req 0 multi fifo 0 empty dst req 0 handshake error 0 cell parity 0 ========= Line Card (Slot 6) ========= >From Fabric FIA Errors ----------------------- redund overflow 0 cell drops 0 cell parity 0 Switch cards present 0x001F Slots 16 17 18 19 20 Switch cards monitored 0x001F Slots 16 17 18 19 20 Slot: 16 17 18 19 20 Name: csc0 csc1 sfc0 sfc1 sfc2 -------- -------- -------- -------- -------- los 0 0 0 0 0 state Off Off Off Off Off crc16 0 0 0 0 0 To Fabric FIA Errors ----------------------- sca not pres 0 req error 0 uni fifo overflow 0 grant parity 0 multi req 0 uni fifo undrflow 0 cntrl parity 0 uni req 0 multi fifo 0 empty dst req 0 handshake error 0 cell parity 0 On Wed, Sep 10, 2008 at 4:44 PM, Chris Lane wrote: > Darn, problem for me is i removed the 8 port FastE card that was causing > all the grief last night because it kept reloading. I removed the one > connection i had in LC and LC still continued to bounce.Here is the output > anyways. > > ----------------------------------------- > > > > On Wed, Sep 10, 2008 at 4:33 PM, Leonardo Gama Souza < > leonardo.souza at nec.com.br> wrote: > >> The same command. >> execute-on all show controller fia >> >> Rgds. >> >> ------------------------------ >> *De:* Chris Lane [mailto:clane1875 at gmail.com] >> *Enviada:* qua 10/9/2008 17:34 >> *Para:* Leonardo Gama Souza >> >> *Assunto:* Re: [c-nsp] GSR12008 Error >> >> You didn't add command ~ >> Thanks >> >> On Wed, Sep 10, 2008 at 4:23 PM, Leonardo Gama Souza < >> leonardo.souza at nec.com.br> wrote: >> >>> Oh. I forgot one thing. >>> You must issue this command on all LC as well. >>> >>> >>> ------------------------------ >>> *De:* Chris Lane [mailto:clane1875 at gmail.com] >>> *Enviada:* qua 10/9/2008 17:25 >>> *Para:* Leonardo Gama Souza >>> *Cc:* cisco-nsp at puck.nether.net >>> *Assunto:* Re: [c-nsp] GSR12008 Error >>> >>> No errors as you can see. >>> cr.la1.ca#sh controller fia >>> Fabric configuration: 2.4Gbps bandwidth, redundant fabric >>> Master Scheduler: Slot 17 Backup Scheduler: Slot 16 >>> >>> From Fabric FIA Errors >>> ----------------------- >>> redund fifo parity 0 redund overflow 0 cell drops 0 >>> >>> crc32 lkup parity 0 cell parity 0 crc32 0 >>> >>> Switch cards present 0x001F Slots 16 17 18 19 20 >>> Switch cards monitored 0x001F Slots 16 17 18 19 20 >>> Slot: 16 17 18 19 20 >>> Name: csc0 csc1 sfc0 sfc1 sfc2 >>> -------- -------- -------- -------- -------- >>> los 0 0 0 0 0 >>> state Off Off Off Off Off >>> crc16 0 0 0 0 0 >>> >>> To Fabric FIA Errors >>> ----------------------- >>> sca not pres 0 req error 0 uni fifo overflow 0 >>> >>> grant parity 0 multi req 0 uni fifo undrflow 0 >>> >>> cntrl parity 0 uni req 0 crc32 lkup parity 0 >>> >>> multi fifo 0 empty dst req 0 handshake error 0 >>> On Wed, Sep 10, 2008 at 4:10 PM, Leonardo Gama Souza < >>> leonardo.souza at nec.com.br> wrote: >>> >>>> Hi, >>>> >>>> Look for errors in "show controller fia". >>>> Maybe the LC was badly seated... >>>> Maybe you have a bad SFC... >>>> There are a lot of possibilities. >>>> >>>> Cheers, >>>> Leonardo Gama. >>>> >>>> ------------------------------ >>>> *De:* cisco-nsp-bounces at puck.nether.net em nome de Chris Lane >>>> *Enviada:* qua 10/9/2008 15:58 >>>> *Para:* cisco-nsp at puck.nether.net >>>> *Assunto:* [c-nsp] GSR12008 Error >>>> >>>> All, >>>> >>>> GSR question, appears Cisco finally got around to updating the IOS train >>>> on >>>> 12.0.32.S ? we have been running S8 for a while but S11 just came out >>>> and it >>>> appears to have many new features! One of my routers is running >>>> 12.0.32.S6 ? >>>> its been so for 2years. I had a bad 8 port FastE lc a while back so I >>>> replaced just recently with a known good lc tested in the lab, So I >>>> sent it >>>> to replace the failed one ~ after 2 days I started getting these >>>> errors. >>>> >>>> %FABRIC-3-ERR_HANDLE: >>>> >>>> %RP-3-FABRIC_UNI >>>> >>>> %FIA-3-HALT >>>> >>>> L%LC-6-BMACMDRPLY >>>> >>>> >>>> >>>> >From what I gather this is the RP is having trouble communicating with >>>> the >>>> LC. One of these errors suggests upgrading IOS ~ but S6 to S8 isn't >>>> that >>>> big of a deal and couldn't possibly be the culprit could it? Is this RP >>>> related? And if so I could easily flip to the backup RP. >>>> >>>> Any suggestions would be super appreciative. >>>> >>>> -- >>>> //CL >>>> _______________________________________________ >>>> 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/ >>>> >>>> >>> >>> >>> -- >>> //CL >>> >> >> >> >> -- >> //CL >> > > > > -- > //CL > -- //CL From leonardo.souza at nec.com.br Wed Sep 10 17:00:27 2008 From: leonardo.souza at nec.com.br (Leonardo Gama Souza) Date: Wed, 10 Sep 2008 18:00:27 -0300 Subject: [c-nsp] RES: GSR12008 Error References: <2e1cd850809101158v27cd4427tc3d73c0bcdac6cf2@mail.gmail.com><9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E39@spsrvmail03.nec.br><2e1cd850809101325q419cb595k16ef2c039e27d941@mail.gmail.com><9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3A@spsrvmail03.nec.br><2e1cd850809101334u3ef1363duc755c91869434db5@mail.gmail.com><9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3B@spsrvmail03.nec.br> <2e1cd850809101344s3df471dv9150ea821c4a511c@mail.gmail.com> Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3C@spsrvmail03.nec.br> You can try to insert that LC into another slot and collect those commands if the issue come back. ________________________________ De: Chris Lane [mailto:clane1875 at gmail.com] Enviada: qua 10/9/2008 17:44 Para: Leonardo Gama Souza Cc: cisco-nsp at puck.nether.net Assunto: Re: [c-nsp] GSR12008 Error Darn, problem for me is i removed the 8 port FastE card that was causing all the grief last night because it kept reloading. I removed the one connection i had in LC and LC still continued to bounce. Here is the output anyways. ----------------------------------------- On Wed, Sep 10, 2008 at 4:33 PM, Leonardo Gama Souza wrote: The same command. execute-on all show controller fia Rgds. ________________________________ De: Chris Lane [mailto:clane1875 at gmail.com] Enviada: qua 10/9/2008 17:34 Para: Leonardo Gama Souza Assunto: Re: [c-nsp] GSR12008 Error You didn't add command ~ Thanks On Wed, Sep 10, 2008 at 4:23 PM, Leonardo Gama Souza wrote: Oh. I forgot one thing. You must issue this command on all LC as well. ________________________________ De: Chris Lane [mailto:clane1875 at gmail.com] Enviada: qua 10/9/2008 17:25 Para: Leonardo Gama Souza Cc: cisco-nsp at puck.nether.net Assunto: Re: [c-nsp] GSR12008 Error No errors as you can see. cr.la1.ca#sh controller fia Fabric configuration: 2.4Gbps bandwidth, redundant fabric Master Scheduler: Slot 17 Backup Scheduler: Slot 16 From Fabric FIA Errors ----------------------- redund fifo parity 0 redund overflow 0 cell drops 0 crc32 lkup parity 0 cell parity 0 crc32 0 Switch cards present 0x001F Slots 16 17 18 19 20 Switch cards monitored 0x001F Slots 16 17 18 19 20 Slot: 16 17 18 19 20 Name: csc0 csc1 sfc0 sfc1 sfc2 -------- -------- -------- -------- -------- los 0 0 0 0 0 state Off Off Off Off Off crc16 0 0 0 0 0 To Fabric FIA Errors ----------------------- sca not pres 0 req error 0 uni fifo overflow 0 grant parity 0 multi req 0 uni fifo undrflow 0 cntrl parity 0 uni req 0 crc32 lkup parity 0 multi fifo 0 empty dst req 0 handshake error 0 On Wed, Sep 10, 2008 at 4:10 PM, Leonardo Gama Souza wrote: Hi, Look for errors in "show controller fia". Maybe the LC was badly seated... Maybe you have a bad SFC... There are a lot of possibilities. Cheers, Leonardo Gama. ________________________________ De: cisco-nsp-bounces at puck.nether.net em nome de Chris Lane Enviada: qua 10/9/2008 15:58 Para: cisco-nsp at puck.nether.net Assunto: [c-nsp] GSR12008 Error All, GSR question, appears Cisco finally got around to updating the IOS train on 12.0.32.S - we have been running S8 for a while but S11 just came out and it appears to have many new features! One of my routers is running 12.0.32.S6 - its been so for 2years. I had a bad 8 port FastE lc a while back so I replaced just recently with a known good lc tested in the lab, So I sent it to replace the failed one ~ after 2 days I started getting these errors. %FABRIC-3-ERR_HANDLE: %RP-3-FABRIC_UNI %FIA-3-HALT L%LC-6-BMACMDRPLY >From what I gather this is the RP is having trouble communicating with the LC. One of these errors suggests upgrading IOS ~ but S6 to S8 isn't that big of a deal and couldn't possibly be the culprit could it? Is this RP related? And if so I could easily flip to the backup RP. Any suggestions would be super appreciative. -- //CL _______________________________________________ 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/ -- //CL -- //CL -- //CL From fbako at africaonline.co.ke Wed Sep 10 16:00:00 2008 From: fbako at africaonline.co.ke (Felix Bako) Date: Wed, 10 Sep 2008 23:00:00 +0300 Subject: [c-nsp] Route selection in VRF Message-ID: <48C82740.3090207@africaonline.co.ke> Hey Guys, I have two routers each terminating my upstream providers.on each i have configured Internet on a VRF and doing ebgp with my providers on the the VRF. Customers connected to The PEs are importing the Internet VRFs RTs for Internet Access. The two routers are also doing IBP between them so both routers are fully aware of each other routes The challange is traffic from the customers connecting to PEs always follows the default route of each Internet PEs and i can only use one uplink at a time hence cant load share. the Internet VRF has all routes and also a default route. Any assistance on this will be highly appreciated -- Felix Bako *Ag. TECHNICAL MANAGER* Africa Online (K) LTD Tel: + 254 (20) 2792000 Fax: + 254 (20) 2710010 Email: _fbako at africaonline.co.ke <>_ AIM: felixbako * * A MEMBER OF TELKOM SOUTH AFRICA GROUP *Africa Online Disclaimer and Confidentiality Note* This e-mail, its attachments and any rights attaching hereto are, unless the context clearly indicates otherwise, the property of Africa Online Holdings (Kenya) Limited and / or its subsidiaries ("the Group"). It is confidential and intended for the addressee only. Should you not be the addressee and have received this e-mail by mistake, kindly notify the sender, delete this e-mail immediately and do not disclose or use the same in any manner whatsoever. Views and opinions expressed in this e-mail are those of the sender unless clearly stated as those of the Group. The Group accepts no liability whatsoever for any loss or damages, however incurred, resulting from the use of this e-mail or its attachments. The Group does not warrant the integrity of this e-mail, nor that it is free of errors, viruses, interception or interference. For more information about Africa Online, please visit our website at _http://www.africaonline.com _ From blahu77 at gmail.com Wed Sep 10 17:10:55 2008 From: blahu77 at gmail.com (=?ISO-8859-2?Q?Mateusz_B=B3aszczyk?=) Date: Wed, 10 Sep 2008 22:10:55 +0100 Subject: [c-nsp] Setting the Remote Syslog Port in IOS In-Reply-To: References: <48C82646.7040402@forthnet.gr> Message-ID: <383357750809101410u51a10dc9kee2a3c1c2cf3e1ba@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 2008/9/10 Christian Koch : > checked for any switches after the inputting the ip address on logging > host command but nothing was available > > > #logging host 1.1.1.1 transport ? > % Unrecognized command How about some sort of port-forwarding? - -- - -mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIyDffIvBv0k5esR4RAvkUAJ9SAK+xELVl5L6ZjZnqQTTYgee2FACgiFrU ocLmsrqQ0vOF5fU6mZUb4JU= =twdB -----END PGP SIGNATURE----- From clane1875 at gmail.com Wed Sep 10 17:12:35 2008 From: clane1875 at gmail.com (Chris Lane) Date: Wed, 10 Sep 2008 17:12:35 -0400 Subject: [c-nsp] GSR12008 Error In-Reply-To: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3C@spsrvmail03.nec.br> References: <2e1cd850809101158v27cd4427tc3d73c0bcdac6cf2@mail.gmail.com> <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E39@spsrvmail03.nec.br> <2e1cd850809101325q419cb595k16ef2c039e27d941@mail.gmail.com> <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3A@spsrvmail03.nec.br> <2e1cd850809101334u3ef1363duc755c91869434db5@mail.gmail.com> <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3B@spsrvmail03.nec.br> <2e1cd850809101344s3df471dv9150ea821c4a511c@mail.gmail.com> <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3C@spsrvmail03.nec.br> Message-ID: <2e1cd850809101412w3f34666cq3a5102bb9e939c18@mail.gmail.com> I think its safe to say its the LC. Issue is resolved with LC removed. Site is remote across country, i will get a maintenance window and get more info in the near future. Regards, Chris On Wed, Sep 10, 2008 at 5:00 PM, Leonardo Gama Souza < leonardo.souza at nec.com.br> wrote: > You can try to insert that LC into another slot and collect those > commands if the issue come back. > > > ------------------------------ > *De:* Chris Lane [mailto:clane1875 at gmail.com] > *Enviada:* qua 10/9/2008 17:44 > > *Para:* Leonardo Gama Souza > *Cc:* cisco-nsp at puck.nether.net > *Assunto:* Re: [c-nsp] GSR12008 Error > > Darn, problem for me is i removed the 8 port FastE card that was causing > all the grief last night because it kept reloading. I removed the one > connection i had in LC and LC still continued to bounce. Here is the > output anyways. > > ----------------------------------------- > > > > On Wed, Sep 10, 2008 at 4:33 PM, Leonardo Gama Souza < > leonardo.souza at nec.com.br> wrote: > >> The same command. >> execute-on all show controller fia >> >> Rgds. >> >> ------------------------------ >> *De:* Chris Lane [mailto:clane1875 at gmail.com] >> *Enviada:* qua 10/9/2008 17:34 >> *Para:* Leonardo Gama Souza >> >> *Assunto:* Re: [c-nsp] GSR12008 Error >> >> You didn't add command ~ >> Thanks >> >> On Wed, Sep 10, 2008 at 4:23 PM, Leonardo Gama Souza < >> leonardo.souza at nec.com.br> wrote: >> >>> Oh. I forgot one thing. >>> You must issue this command on all LC as well. >>> >>> >>> ------------------------------ >>> *De:* Chris Lane [mailto:clane1875 at gmail.com] >>> *Enviada:* qua 10/9/2008 17:25 >>> *Para:* Leonardo Gama Souza >>> *Cc:* cisco-nsp at puck.nether.net >>> *Assunto:* Re: [c-nsp] GSR12008 Error >>> >>> No errors as you can see. >>> cr.la1.ca#sh controller fia >>> Fabric configuration: 2.4Gbps bandwidth, redundant fabric >>> Master Scheduler: Slot 17 Backup Scheduler: Slot 16 >>> >>> From Fabric FIA Errors >>> ----------------------- >>> redund fifo parity 0 redund overflow 0 cell drops 0 >>> >>> crc32 lkup parity 0 cell parity 0 crc32 0 >>> >>> Switch cards present 0x001F Slots 16 17 18 19 20 >>> Switch cards monitored 0x001F Slots 16 17 18 19 20 >>> Slot: 16 17 18 19 20 >>> Name: csc0 csc1 sfc0 sfc1 sfc2 >>> -------- -------- -------- -------- -------- >>> los 0 0 0 0 0 >>> state Off Off Off Off Off >>> crc16 0 0 0 0 0 >>> >>> To Fabric FIA Errors >>> ----------------------- >>> sca not pres 0 req error 0 uni fifo overflow 0 >>> >>> grant parity 0 multi req 0 uni fifo undrflow 0 >>> >>> cntrl parity 0 uni req 0 crc32 lkup parity 0 >>> >>> multi fifo 0 empty dst req 0 handshake error 0 >>> On Wed, Sep 10, 2008 at 4:10 PM, Leonardo Gama Souza < >>> leonardo.souza at nec.com.br> wrote: >>> >>>> Hi, >>>> >>>> Look for errors in "show controller fia". >>>> Maybe the LC was badly seated... >>>> Maybe you have a bad SFC... >>>> There are a lot of possibilities. >>>> >>>> Cheers, >>>> Leonardo Gama. >>>> >>>> ------------------------------ >>>> *De:* cisco-nsp-bounces at puck.nether.net em nome de Chris Lane >>>> *Enviada:* qua 10/9/2008 15:58 >>>> *Para:* cisco-nsp at puck.nether.net >>>> *Assunto:* [c-nsp] GSR12008 Error >>>> >>>> All, >>>> >>>> GSR question, appears Cisco finally got around to updating the IOS train >>>> on >>>> 12.0.32.S ? we have been running S8 for a while but S11 just came out >>>> and it >>>> appears to have many new features! One of my routers is running >>>> 12.0.32.S6 ? >>>> its been so for 2years. I had a bad 8 port FastE lc a while back so I >>>> replaced just recently with a known good lc tested in the lab, So I >>>> sent it >>>> to replace the failed one ~ after 2 days I started getting these >>>> errors. >>>> >>>> %FABRIC-3-ERR_HANDLE: >>>> >>>> %RP-3-FABRIC_UNI >>>> >>>> %FIA-3-HALT >>>> >>>> L%LC-6-BMACMDRPLY >>>> >>>> >>>> >>>> >From what I gather this is the RP is having trouble communicating with >>>> the >>>> LC. One of these errors suggests upgrading IOS ~ but S6 to S8 isn't >>>> that >>>> big of a deal and couldn't possibly be the culprit could it? Is this RP >>>> related? And if so I could easily flip to the backup RP. >>>> >>>> Any suggestions would be super appreciative. >>>> >>>> -- >>>> //CL >>>> _______________________________________________ >>>> 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/ >>>> >>>> >>> >>> >>> -- >>> //CL >>> >> >> >> >> -- >> //CL >> > > > > -- > //CL > -- //CL From leonardo.souza at nec.com.br Wed Sep 10 17:31:15 2008 From: leonardo.souza at nec.com.br (Leonardo Gama Souza) Date: Wed, 10 Sep 2008 18:31:15 -0300 Subject: [c-nsp] RES: GSR12008 Error References: <2e1cd850809101158v27cd4427tc3d73c0bcdac6cf2@mail.gmail.com><9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E39@spsrvmail03.nec.br><2e1cd850809101325q419cb595k16ef2c039e27d941@mail.gmail.com><9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3A@spsrvmail03.nec.br><2e1cd850809101334u3ef1363duc755c91869434db5@mail.gmail.com><9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3B@spsrvmail03.nec.br><2e1cd850809101344s3df471dv9150ea821c4a511c@mail.gmail.com><9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3C@spsrvmail03.nec.br> <2e1cd850809101412w3f34666cq3a5102bb9e939c18@mail.gmail.com> Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E3D@spsrvmail03.nec.br> Most likely so. Could be occurred an ESD. But on other hand the LC might have been bad seated....or there is a problem with that specific slot... Cheers, Leonardo. ________________________________ De: Chris Lane [mailto:clane1875 at gmail.com] Enviada: qua 10/9/2008 18:12 Para: Leonardo Gama Souza Cc: cisco-nsp at puck.nether.net Assunto: Re: [c-nsp] GSR12008 Error I think its safe to say its the LC. Issue is resolved with LC removed. Site is remote across country, i will get a maintenance window and get more info in the near future. Regards, Chris On Wed, Sep 10, 2008 at 5:00 PM, Leonardo Gama Souza wrote: You can try to insert that LC into another slot and collect those commands if the issue come back. ________________________________ De: Chris Lane [mailto:clane1875 at gmail.com] Enviada: qua 10/9/2008 17:44 Para: Leonardo Gama Souza Cc: cisco-nsp at puck.nether.net Assunto: Re: [c-nsp] GSR12008 Error Darn, problem for me is i removed the 8 port FastE card that was causing all the grief last night because it kept reloading. I removed the one connection i had in LC and LC still continued to bounce. Here is the output anyways. ----------------------------------------- On Wed, Sep 10, 2008 at 4:33 PM, Leonardo Gama Souza wrote: The same command. execute-on all show controller fia Rgds. ________________________________ De: Chris Lane [mailto:clane1875 at gmail.com] Enviada: qua 10/9/2008 17:34 Para: Leonardo Gama Souza Assunto: Re: [c-nsp] GSR12008 Error You didn't add command ~ Thanks On Wed, Sep 10, 2008 at 4:23 PM, Leonardo Gama Souza wrote: Oh. I forgot one thing. You must issue this command on all LC as well. ________________________________ De: Chris Lane [mailto:clane1875 at gmail.com] Enviada: qua 10/9/2008 17:25 Para: Leonardo Gama Souza Cc: cisco-nsp at puck.nether.net Assunto: Re: [c-nsp] GSR12008 Error No errors as you can see. cr.la1.ca#sh controller fia Fabric configuration: 2.4Gbps bandwidth, redundant fabric Master Scheduler: Slot 17 Backup Scheduler: Slot 16 From Fabric FIA Errors ----------------------- redund fifo parity 0 redund overflow 0 cell drops 0 crc32 lkup parity 0 cell parity 0 crc32 0 Switch cards present 0x001F Slots 16 17 18 19 20 Switch cards monitored 0x001F Slots 16 17 18 19 20 Slot: 16 17 18 19 20 Name: csc0 csc1 sfc0 sfc1 sfc2 -------- -------- -------- -------- -------- los 0 0 0 0 0 state Off Off Off Off Off crc16 0 0 0 0 0 To Fabric FIA Errors ----------------------- sca not pres 0 req error 0 uni fifo overflow 0 grant parity 0 multi req 0 uni fifo undrflow 0 cntrl parity 0 uni req 0 crc32 lkup parity 0 multi fifo 0 empty dst req 0 handshake error 0 On Wed, Sep 10, 2008 at 4:10 PM, Leonardo Gama Souza wrote: Hi, Look for errors in "show controller fia". Maybe the LC was badly seated... Maybe you have a bad SFC... There are a lot of possibilities. Cheers, Leonardo Gama. ________________________________ De: cisco-nsp-bounces at puck.nether.net em nome de Chris Lane Enviada: qua 10/9/2008 15:58 Para: cisco-nsp at puck.nether.net Assunto: [c-nsp] GSR12008 Error All, GSR question, appears Cisco finally got around to updating the IOS train on 12.0.32.S - we have been running S8 for a while but S11 just came out and it appears to have many new features! One of my routers is running 12.0.32.S6 - its been so for 2years. I had a bad 8 port FastE lc a while back so I replaced just recently with a known good lc tested in the lab, So I sent it to replace the failed one ~ after 2 days I started getting these errors. %FABRIC-3-ERR_HANDLE: %RP-3-FABRIC_UNI %FIA-3-HALT L%LC-6-BMACMDRPLY >From what I gather this is the RP is having trouble communicating with the LC. One of these errors suggests upgrading IOS ~ but S6 to S8 isn't that big of a deal and couldn't possibly be the culprit could it? Is this RP related? And if so I could easily flip to the backup RP. Any suggestions would be super appreciative. -- //CL _______________________________________________ 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/ -- //CL -- //CL -- //CL -- //CL From RTeller at deltadentalwa.com Wed Sep 10 18:38:09 2008 From: RTeller at deltadentalwa.com (Teller, Robert) Date: Wed, 10 Sep 2008 15:38:09 -0700 Subject: [c-nsp] (no subject) In-Reply-To: References: Message-ID: <06C1E76E03FE9C4B85BFA9C75365D9DA0FC01295@tiger.deltadentalwa.com> Are the routers connected to gig switches? And do the duplex and speed settings match up? -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of hawk98 TheHawk Sent: Thursday, September 04, 2008 1:04 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] (no subject) Hello All, We're noticing a large number of input errors on multiple GigE interfaces on various C720X NPE-G1 routers. These input errors match exactly with the number of overruns on those interfaces. There are a couple strange things that we've noticed: 1. this problem happens on more than 1 router (similar configuration on all routers) 2. all routers affected began exhibiting these errors roughly around the same time (same early morning) 3. All routers are G1 and ran the same IOS code 4. One of the routers was rebooted and upgraded to a different code however the problem still persists 5. we suspect it directly affects the functionality of the router as we see random lockups of the units 6. All routers are connected to redundant switches and cabling/switches have been ruled out. Below is a sample output of the show interface on one of the routers: GigabitEthernet0/1 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 00b0.c2ee.b81b (bia 00b0.c2ee.b81b) Description: XXXXXXXX MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 2/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of 'show interface' counters never Input queue: 1/75/499528/97 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 8539000 bits/sec, 10996 packets/sec 5 minute output rate 1905000 bits/sec, 807 packets/sec 139728650 packets input, 10628478461 bytes, 92 no buffer Received 487174 broadcasts, 0 runts, 0 giants, 0 throttles 171399 input errors, 0 CRC, 0 frame, 171399 overrun, 0 ignored 0 watchdog, 1904930 multicast, 0 pause input 0 input packets with dribble condition detected 8125773 packets output, 2521690484 bytes, 0 underruns 2 output errors, 0 collisions, 1 interface resets 3842 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 2 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out Does anyone have any idea what might be going on? I initially suspected an IOS bug (since all devices were affected) however after the upgrade the problem still persists. Any help is appreciated. Adrian _________________________________________________________________ _______________________________________________ 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/ ######################################################### The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended for the sole use of the individual and entity to whom it is addressed. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. ######################################################### From tbaranski at mail.com Wed Sep 10 20:12:52 2008 From: tbaranski at mail.com (Terry Baranski) Date: Wed, 10 Sep 2008 20:12:52 -0400 Subject: [c-nsp] VPN Failover In-Reply-To: <48C79245.8030707@fnbs.net> Message-ID: <000101c913a3$226d3870$0200000a@pleth0ra> You can have multiple "set peer" statements in a given crypto map. Use the "default" keyword (http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gt_ipspp.ht ml) along with Dead Peer Detection to have redundancy between SITEB and DRSITE. -Terry > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Nimal > David Sirimanne > Sent: Wednesday, September 10, 2008 5:24 AM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] VPN Failover > > > Hi guys, > > We have 2 major offices (SITEA,SITEB)running site-2-site VPN > connection > between them. We are now setting up a new DR site (DRSITE) for SITEB > > However, our constraint is that SITEB internal network addressing and > DRSITE internal network addressing has to be exactly the same. If > internal network addressing for SITEB is 10.10.10.0/24, then internal > network addressing for DRSITE is also 10.10.10.0/24. As i > understand, it > is not possible to for SITEA to have 2 active vpn links to sites with > the same internal network addressing. > > Is it then possible, if SITEA -- vpn -- SITEB fails, that it will > failover to SITEA -- vpn -- DRSITE? > > Hope i explained that properly. Thanks! > > Nimal > > > _______________________________________________ > 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-kell at utc.edu Wed Sep 10 21:58:59 2008 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 10 Sep 2008 21:58:59 -0400 Subject: [c-nsp] 10G Xenpak 'virgin' question In-Reply-To: <48C68B1B.4010705@utc.edu> References: <48C68B1B.4010705@utc.edu> Message-ID: <48C87B63.6010200@utc.edu> Jeff Kell wrote: > We're trying to light up our first 10G Xenpak link, so far without > success, so I'm looking for a quick sanity check. > > 3750G-16TD switch with an LR Xenpak [ours], trying to link to a Ciena > [not ours] add/drop ONS. Just to "close this thread" -- the Ciena end was a Corestream with an "LR" XFP (in Ciena terminology), but that's ER in Cisco terminology (1550nm vs 1310nm). Will try again when we get our ER Xenpak. Jeff From bennetb at gmail.com Thu Sep 11 00:03:52 2008 From: bennetb at gmail.com (Brandon Bennett) Date: Wed, 10 Sep 2008 22:03:52 -0600 Subject: [c-nsp] Setting the Remote Syslog Port in IOS In-Reply-To: References: <746ca6da0809101146w40692ffo97e6ab49e0386eb2@mail.gmail.com> Message-ID: > because that is not how splunk works, we want to create separate > splunk instances, each instance has its own syslog port... You can use syslog-ng filters to dump out named pipes and have splunk read the named pipes. That way you can still filter on facility but have seperate splunk instances. syslog-ng to the win again! -Brandon From christian at broknrobot.com Thu Sep 11 00:18:49 2008 From: christian at broknrobot.com (Christian Koch) Date: Thu, 11 Sep 2008 00:18:49 -0400 Subject: [c-nsp] Setting the Remote Syslog Port in IOS In-Reply-To: References: <746ca6da0809101146w40692ffo97e6ab49e0386eb2@mail.gmail.com> Message-ID: interesting! i will try this out... thanks Brandon! Christian On Thu, Sep 11, 2008 at 12:03 AM, Brandon Bennett wrote: >> because that is not how splunk works, we want to create separate >> splunk instances, each instance has its own syslog port... > You can use syslog-ng filters to dump out named pipes and have splunk > read the named pipes. That way you can still filter on facility but > have seperate splunk instances. syslog-ng to the win again! > > -Brandon > From chale99 at gmail.com Thu Sep 11 00:34:48 2008 From: chale99 at gmail.com (Chris Hale) Date: Thu, 11 Sep 2008 00:34:48 -0400 Subject: [c-nsp] how to accomplish multiple 'native' vlans Message-ID: All - We are converting our L2 network from Riverstone to Cisco. One problem I have not been able to solve yet is the way the Riverstone and Cisco units handle untagged traffic entering a physical port. We have many connections to customers whereby we have equipment we would like to manage with management VIDs inline with untagged customer traffic. When it enters the Ethernet trunk port on the Riverstone, we are able to assign the untagged traffic to a VID and it traverses the trunk ports where allowed as tagged traffic. It doesn't seem like the Cisco switches have this ability - only one native VLAN per switch. Is there some way to accept multiple ports of untagged traffic and tag each ports' untagged traffic with separate VIDs? Example: fa0/1 - mgmt VID 10, customer traffic untagged (needs to be tagged with VID 100 for L3 routing) fa0/2 - mgmt VID 10, customer traffic untagged (needs to be tagged with VID 101 for L3 routing) etc. fa0/24 - trunk port to L3 device We are using 2960 and 3560 switches. Any other ideas are welcome, but we would prefer to minimize any CPE equipment at customer site to tag their traffic with the appropriate customer VID. It's a matter of additional cost, additional management devices, and additional points of failure. Thanks, Chris -- ------------------ Chris Hale chale99 at gmail.com From dcp at dcptech.com Thu Sep 11 00:43:50 2008 From: dcp at dcptech.com (David Prall) Date: Thu, 11 Sep 2008 00:43:50 -0400 Subject: [c-nsp] how to accomplish multiple 'native' vlans In-Reply-To: References: Message-ID: <002601c913c8$fe260020$ae0b740a@cisco.com> interface x 0/y switchport trunk native vlan Z -- http://dcp.dcptech.com > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Chris Hale > Sent: Thursday, September 11, 2008 12:35 AM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] how to accomplish multiple 'native' vlans > > All - > > We are converting our L2 network from Riverstone to Cisco. One > problem I have not been able to solve yet is the way the Riverstone > and Cisco units handle untagged traffic entering a physical port. We > have many connections to customers whereby we have equipment we would > like to manage with management VIDs inline with untagged customer > traffic. When it enters the Ethernet trunk port on the Riverstone, we > are able to assign the untagged traffic to a VID and it traverses the > trunk ports where allowed as tagged traffic. It doesn't seem like the > Cisco switches have this ability - only one native VLAN per switch. > Is there some way to accept multiple ports of untagged traffic and tag > each ports' untagged traffic with separate VIDs? > > Example: > > fa0/1 - mgmt VID 10, customer traffic untagged (needs to be tagged > with VID 100 for L3 routing) > fa0/2 - mgmt VID 10, customer traffic untagged (needs to be tagged > with VID 101 for L3 routing) > etc. > fa0/24 - trunk port to L3 device > > We are using 2960 and 3560 switches. Any other ideas are welcome, but > we would prefer to minimize any CPE equipment at customer site to tag > their traffic with the appropriate customer VID. It's a matter of > additional cost, additional management devices, and additional points > of failure. > > Thanks, > Chris > > -- > ------------------ > Chris Hale > chale99 at gmail.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 hank at efes.iucc.ac.il Thu Sep 11 01:17:24 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 11 Sep 2008 08:17:24 +0300 Subject: [c-nsp] Cisco pushes 'network memory' to alleviate high-speed bottlenecks Message-ID: <5.1.0.14.2.20080911081222.00b1ef40@efes.iucc.ac.il> "On a 10Gbps link, for example, packets can arrive approximately every 50ns, while commodity memory ? for example, DRAM memory -- can only be accessed once every 50ns. Packets can also arrive in any order and require unpredictable, or random access to memory. Yet it takes two memory operations per packet every 50ns on a 10Gbps link: one to write the packet, another to read. If the memory can only do one operation every 50ns, it can?t keep up; and as link rates increase, the router vs. memory performance gap widens and the problem only becomes worse. Then end result is that routers cannot support the needs of real-time applications such as voice, video conferencing, multimedia and gaming that require guaranteed performance because it cannot ensure that packets can be written to or read from memory on time, at high line rates. But adding memory capacity in the form of specialized 10Gbps SRAMs or reduced latency DRAMs are ?extremely high in cost and unwieldy? in the number of components and power required per system, Iyer says. They also are unable to keep up with 40Gbps rates, he says." ... "The solution, according to Iyer, are network memory algorithms that combine load balancing and caching algorithms on commodity memory. Load balancing distributes the load over slower memories, and guarantee that memory is available when data needs to be accessed; caching guarantees that data is available in cache memory 100% of the time. ?They provide hard guarantees, mathematical guarantees that performance would never fail,? Iyer says. Applications for network memory include buffering, NetFlow accounting and quality-of-service (QoS). For buffering, routers must make sure that the packets it needs are always in the cache. With a small SRAM cache inside a packet processing ASIC and a slow commodity DRAM, it is possible to build a huge, fast, low power packet buffer using network memory algorithms, Iyer says. For QoS, network memory enables routers to better provide strict performance guarantees for critical applications, such as remote surgery and supercomputing. And they help maintain state for applications such as NetFlow, which collects IP traffic information for monitoring purposes. Network memory techniques are currently being designed in Cisco?s next generation port speeds of 10G and 40Gbps, Ethernet switches and enterprise routers, Iyer says." -Hank From sforcejr at yahoo.com Thu Sep 11 00:21:21 2008 From: sforcejr at yahoo.com (John Ramz) Date: Wed, 10 Sep 2008 21:21:21 -0700 (PDT) Subject: [c-nsp] Datacenter network design Message-ID: <531305.64887.qm@web110404.mail.gq1.yahoo.com> We are looking into start hosting our customers' apps and data and would like for you to provide me link to internet resources (or books) to get me started on a network design that includes: - 3rd party Compliance (security for example) - Redundancy (routers, firewalls, switches) - load balancing - VLANS - Virtual servers - Backup- SANs- - Disaster recovery - How to keep customers separated from our regular network? - How to keep customers totally isolated from each other? - Access from our network to the Datacenter network for our developers to work with our customers? Also for our IT people to service, monitor and maintain that network I have thought of getting an Internet pipe just for the Datacenter network and with all the above mentioned components and then figure out the way and procedures to connect our company network with that one for the different items I already mentioned. Has anyone been involved in a project like that could elaborate as much as possible on the subject? Please shed some light with me on where to start and build from there? Thanks From sforcejr at yahoo.com Thu Sep 11 00:58:38 2008 From: sforcejr at yahoo.com (John Ramz) Date: Wed, 10 Sep 2008 21:58:38 -0700 (PDT) Subject: [c-nsp] Datacenter Network Design Message-ID: <415492.56211.qm@web110415.mail.gq1.yahoo.com> We are looking into start hosting our customers' apps and data and would like for you to provide me link to internet resources (or books) to get me started on a network design that includes: - 3rd party Compliance (security for example) - Redundancy (routers, firewalls, switches) - load balancing - VLANS - Virtual servers - Backup- SANs- - Disaster recovery - How to keep customers separated from our regular network? - How to keep customers totally isolated from each other? - Access from our network to the Datacenter network for our developers to work with our customers? Also for our IT people to service, monitor and maintain that network I have thought of getting an Internet pipe just for the Datacenter network and with all the above mentioned components and then figure out the way and procedures to connect our company network with that one for the different items I already mentioned. Has anyone been involved in a project like that could elaborate as much as possible on the subject? Please shed some light with me on where to start and build from there? Thanks From junaid.x86 at gmail.com Thu Sep 11 02:06:25 2008 From: junaid.x86 at gmail.com (Junaid) Date: Thu, 11 Sep 2008 12:06:25 +0600 Subject: [c-nsp] EoMPLS between C7206 and C3845 In-Reply-To: References: Message-ID: Hi, I have narrowed the problem. Now EoMPLS is working between the two routers - the change is that instead of connecting CE2 to the EtherSwitch module of C3845, I have connected it on an external 2950 switch which is then dot1q trunked to C3845. The problem appears when I connect the host on the EtherSwitch port. The configuration on the routing portion of C3845 is exactly same in both cases and the config on the 2950 and EtherSwitch is similar. Does anyone has any experience of running EoMPLS on C3845 with a host on an EtherSwitch module port? Is there any special consideration that needs to be catered for in such a scenario? Will appreciate any help. Regards, Junaid On Thu, Aug 7, 2008 at 2:15 AM, Junaid wrote: > Hi, > > I am trying to make EoMPLS (VLAN mode) to work between a 7206VXR > (NPE400) running c7200-jk9s-mz.123-21.bin and a 3845 running > c3845-advipservicesk9-mz.124-15.T.bin. These two PE routers are > connected back-to-back via FastEthernet. The customers are connected > via a switch connected to each PE: > > CE1 --- Switch --- PE1 --- PE2 --- Switch --- CE2 > > The control place comes up without any issue: > > C7200-PE1#sh mpls l2transport vc de > Local interface: Fa0/0.3 up, line protocol up, Eth VLAN 3 up > Destination address: XXXXX (loopback ip of PE2), VC ID: 100, VC status: up > Next hop: XXXXXX (ip of PE2's interface connected with PE1) > Output interface: Fa3/0, imposed label stack {234} > Create time: 04:55:52, last status change time: 04:22:07 > Signaling protocol: LDP, peer XXXXX (loopback ip of PE2):0 up > MPLS VC labels: local 2207, remote 234 > Group ID: local 0, remote 0 > MTU: local 1500, remote 1500 > Remote interface description: MPLS TEST > Sequencing: receive disabled, send disabled > VC statistics: > packet totals: receive 658, send 558 > byte totals: receive 61117, send 57759 > packet drops: receive 0, send 0 > > > C3845-PE2#sh mpls l2transport vc de > Local interface: Gi4/0.3 up, line protocol up, Eth VLAN 3 up > Destination address: XXXXX (loopback ip of PE1), VC ID: 100, VC status: up > Next hop: XXXXXX (ip of PE1's interface connected with PE2) > Output interface: Gi0/0, imposed label stack {2207} > Create time: 05:06:06, last status change time: 04:42:00 > Signaling protocol: LDP, peer XXXXX (loopback ip of PE1):0 up > MPLS VC labels: local 234, remote 2207 > Group ID: local 0, remote 0 > MTU: local 1500, remote 1500 > Remote interface description: MPLS test > Sequencing: receive disabled, send disabled > VC statistics: > packet totals: receive 807, send 697 > byte totals: receive 81235, send 63925 > packet drops: receive 0, seq error 0, send 0 > > > But the data plane is having severe issue. I cannot ping end-to-end > from the CEs. It seems that when I ping CE1 from CE2 (i.e. from the CE > connected to 3845), ARP works and I am able to send a ping packet to > CE1. But CE1 never receives it. On the other side, CE2 does not get > replies to its own ARP requests. Once I statically bind the mac > address of CE2 on CE1, CE1 sends an ICMP packet to CE2 and CE2 replies > to it but CE1 never receives the reply. It seem that the communication > is one way, from CE1 (one behind C7206) to CE2 (one behind C3845) and > not the other way round. I replaced C3845 with C7206 and there was not > issue in the data plane. > > My question is with the IOS I used for C3845, is EoMPLS not supported > on it? As per Cisco's documentation, EoMPLS is supported on the IOS I > used for C3845. Any one any experience in running EoMPLS on C3845? > > Another thing I noted was in the following output from C3845, it shows > MRU=0 and also there was no outgoing interface attached: > > C3845-PE2#sh mpls forwarding-table labels 234 detail > Local Outgoing Prefix Bytes tag Outgoing Next Hop > tag tag or VC or Tunnel Id switched interface > 234 l2ckt(100) 50732 none point2point > MAC/Encaps=0/0, MRU=0, Tag Stack{} > No output feature configured > > While on C7206, the output was as it should be: > > C7200-PE1#sh mpls forwarding-table labels 2207 detail > Local Outgoing Prefix Bytes tag Outgoing Next Hop > tag tag or VC or Tunnel Id switched interface > 2207 Untagged l2ckt(100) 55853 Fa0/0.3 point2point > MAC/Encaps=0/0, MRU=1500, Tag Stack{} > No output feature configured > > > Any explanations/solutions? > > > > Regards, > > Junaid > From oboehmer at cisco.com Thu Sep 11 02:26:43 2008 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Thu, 11 Sep 2008 08:26:43 +0200 Subject: [c-nsp] Route selection in VRF In-Reply-To: <48C82740.3090207@africaonline.co.ke> References: <48C82740.3090207@africaonline.co.ke> Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED78405FD2E9B@xmb-ams-333.emea.cisco.com> Felix Bako <> wrote on Wednesday, September 10, 2008 10:00 PM: > Hey Guys, > > I have two routers each terminating my upstream providers.on each i > have configured Internet on a VRF and doing ebgp with my providers on > the the VRF. > Customers connected to The PEs are importing the Internet VRFs RTs for > Internet Access. Do you carry full table in the Internet VRFs? This can be very expensive as routes are duplicated on the importing PE. > The two routers are also doing IBP between them so both routers are > fully aware of each other routes Not sure I understand this. Aren't the two routers PEs? The iBGP you're referring to is the "normal" vpnv4 iBGP between PEs? This could acually be an issue if you have traffic like customer-PE -(MPLS)-> internet-PE1 -(MPLS)-> internet-PE2 --> Internet where customer-PE is following the default-route. A network diagram could help. > The challange is traffic from the customers connecting to PEs always > follows the default route of each Internet PEs and i can only use one > uplink at a time hence cant load share. have you investigated iBGP load-sharing (i.e. maximum-paths ibgp 2) to load-share across two egress PEs? oli From rootnet08 at gmail.com Thu Sep 11 03:15:35 2008 From: rootnet08 at gmail.com (root net) Date: Thu, 11 Sep 2008 02:15:35 -0500 Subject: [c-nsp] Datacenter Network Design In-Reply-To: <415492.56211.qm@web110415.mail.gq1.yahoo.com> References: <415492.56211.qm@web110415.mail.gq1.yahoo.com> Message-ID: <89944ef40809110015k28ea0ca7k219da9a68a02b374@mail.gmail.com> John, If you are going to build a Cisco network you should spend some time on www.cisco.com and look at all of their configuration examples and whitepapers for specific gear you are looking at or working on. Here are some books I would suggest: Cisco Press: Data Center Fundamentals End-to-End QoS Network Design Designing for Cisco Internetwork Solutions Designing Cisco Network Architectures Network Management Fundamentals www.cisco.com: (Research) HSRP STP InterVLAN routing IEEE Bridging BGP OSPF L2TPV3 MPLS / VPN IOS information Others: Administering Data Centers APC Data Center University (online classes) Some are FREE some are not. This is all I could think of since it's so late. DR will come when you start digging into the protocols and other information. Far as storage/backup iSCSI is your friend so build a GbE network. OpenFiler, NetApp, MyIVault. >From the start your facility will need to handle your immediate needs and growth or at least have the ability to scale (I would say maybe 10-20% growth for small budgets). Look at evironmentals, power, fire protection: HVAC (spot coolers vs. ductless split systems vs. ducted systems, chilled water vs. air cooled), Power Requirements (Single Phase, Three Phase 208V /480V, UPS, Transfer switches, portable generators, generator), Raised Flooring vs. Anti-Static VCT, Security monitoring, water monitoring, temperature monitoring, and lastly Pre-action vs. plain wet system. Getting a seperate Internet feed would be wise unless it's just cost prohibitive. Start out with maybe 10Mbit pipe and go from there. This all depends your customer's applications and servers. What they will be transfering and etc. Look into open source products as these are FREE and can help you. (e.g. nagios, jffnms, cacti, mrtg, syslog, linux, RT, rancid, and others) Rule of thumb: A good data center will have proactive measures and policies in place to monitor, maintain, and procure. With that said monitor everything (I mean everything) and have all staff alerted on all levels SMS, e-mail, phone if possible automatically. It's not about downtime so much it's how you procure the situation in a specific time frame. Customer serivce is a must. You will need to make the call on the gear you use but I use a mixture of Cisco, Extreme, and Juniper. For data centers it's a must for hot swappable gear so look in to carrier class gear with redundant process, power supplies, hot swappable line cards. I would recommend Cisco 6500 Series, Cisco 7200 Series, Cisco ASA or Pix. I am not to fond of the Juniper firewall licensing. BTW, Cisco 2800/3600 Series may even work. Depends on your throughput capabilities you are needing. Research all aspects of your gear from ram, flash, processor speeds, to throughput, modules, IOS, and hot swappable needs. The above will get you started. rootnet08 On 9/10/08, John Ramz wrote: > > We are looking into start hosting our customers' apps and data and would > like for you to provide me link to internet resources (or books) to get me > started on a network design that includes: > > - 3rd party Compliance (security for example) > - Redundancy (routers, firewalls, switches) > - load balancing > - VLANS > - Virtual servers > - Backup- SANs- > - Disaster recovery > - How to keep customers separated from our regular network? > - How to keep customers totally isolated from each other? > - Access from our network to the Datacenter network for our developers to > work with our customers? Also for our IT people to service, monitor and > maintain that network I have thought of getting an Internet pipe just for the Datacenter network > and with all the above mentioned components and then figure out the way and > procedures to connect our company network with that one for the different > items I already mentioned. > > Has anyone been involved in a project like that could elaborate as much as > possible on the subject? > Please shed some light with me on where to start and build from there? > > 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 rens at autempspourmoi.be Thu Sep 11 04:41:55 2008 From: rens at autempspourmoi.be (Rens) Date: Thu, 11 Sep 2008 10:41:55 +0200 Subject: [c-nsp] Router reloads on it's own In-Reply-To: <20080910164248.GX11984@rtp-cse-489.cisco.com> References: <20080910152651.GQ11984@rtp-cse-489.cisco.com> <66DE9E928CAA445183946A2F39465B4A@EU.corp.clearwire.com> <20080910164248.GX11984@rtp-cse-489.cisco.com> Message-ID: <3B3DD4E54BA049DBAB07245748B8B462@EU.corp.clearwire.com> Nobody performed any commands. Would you need the whole crashinfo and how do you actually decode all this stuff? -----Original Message----- From: Rodney Dunn [mailto:rodunn at cisco.com] Sent: mercredi 10 septembre 2008 18:43 To: Rens Cc: 'Rodney Dunn'; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Router reloads on it's own It's in the text region. Almost surely a software bug. I decoded the PC and it's in the arp command code. Did you do a clear arp or any other arp commmand? If so you will see it in the command history of the crashinfo file. The code is old so it's probably already fixed. Was a crashinfo file saved in bootflash? That might give a bit more information or if you can post On Wed, Sep 10, 2008 at 05:33:38PM +0200, Rens wrote: > Here is sh region: > > show region > Region Manager: > > Start End Size(b) Class Media Name > 0x0E000000 0x0FFFFFFF 33554432 Iomem R/W iomem > 0x60000000 0x7DFFFFFF 503316480 Local R/W main > 0x60008DE0 0x6183C02F 25375312 IText R/O main:text > 0x6183E000 0x6280387F 16537728 IData R/W main:data > 0x62803880 0x62AFB89F 3112992 IBss R/W main:bss > 0x62AFB8A0 0x63AFB89F 16777216 Local R/W main:heap > 0x63AFB8F8 0x64AFB8F3 16777212 Local R/W main:heap > 0x7E000000 0x7FFFFFFF 33554432 Iomem R/W iomem:(iomem_cwt) > 0x80000000 0x8DFFFFFF 234881024 Local R/W main:(main_k0) > 0xA0000000 0xADFFFFFF 234881024 Local R/W main:(main_k1) > > > Free Region Manager: > > Start End Size(b) Class Media Name > 0x64AFB948 0x7DFFFFFF 424691384 Local R/W heap > > -----Original Message----- > From: Rodney Dunn [mailto:rodunn at cisco.com] > Sent: mercredi 10 septembre 2008 17:27 > To: Rens > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Router reloads on it's own > > What does 'sh region' say? > > It's a bus error where the PC and address match. > Either it's bad memory if the PC value is out of valid text space > or it's a stack corruption type issue which is a software bug. > > 12.2(25)S throttls is end of engineering. > > You would need to upgrade to 12.2(33)SRC1. > > Rodney > > > On Wed, Sep 10, 2008 at 04:11:09PM +0200, Rens wrote: > > Can anyone help me with the following? How can I get more info regarding > > this error message?: > > > > > > > > System returned to ROM by bus error at PC 0x60995708, address 0x60995708 > at > > 12:09:02 CET Mon Sep 8 2008 > > > > System restarted at 12:10:43 CET Mon Sep 8 2008 > > > > System image file is "disk0:c7200-p-mz.122-25.S11.bin" > > > > > > > > Cisco 7206VXR (NPE400) processor (revision A) with 491520K/32768K bytes of > > memory. > > > > Processor board ID 23690131 > > > > R7000 CPU at 350Mhz, Implementation 39, Rev 3.2, 256KB L2 Cache > > > > 6 slot VXR midplane, Version 2.3 > > > > > > > > Last reset from watchdog reset > > > > _______________________________________________ > > 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 dgranzer at gmail.com Thu Sep 11 08:12:27 2008 From: dgranzer at gmail.com (David Granzer) Date: Thu, 11 Sep 2008 14:12:27 +0200 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080905120724.GI15736@rtp-cse-489.cisco.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> Message-ID: <844ef89c0809110512r5ce679b4i8c7cd83c78015077@mail.gmail.com> Hello, On 9/5/08, Rodney Dunn wrote: > But make sure you do: > > config t > int null 0 > no ip unreachables > > The ACL drops are, last I checked, rate limit punts. > > If it's high CPU at IP Input really need 12.4(20)T and get > a sniffer trace in the punt path to see what traffic it really is. How to sniff traffic punted to CPU (control-plane) on 7200/7301 platform ? Is there something like rp-inband/sp-inband for 6500 ? Thanks, David On the 6500 is available SPAN RP-Inband and SP-Inband > > > Rodney > > > On Thu, Sep 04, 2008 at 03:46:23PM -0400, Stephen Kratzer wrote: > > On Thursday 04 September 2008 15:12:12 Mateusz B??aszczyk wrote: > > > 2008/9/4 Stephen Kratzer : > > > > The 'log' keyword will cause matching packets to not be CEF switched. > > > > > > nope, log is not present. > > > > > > > Also, if > > > > you're denying a lot of traffic from a certain source, you might want to > > > > just bit-bucket it rather than sending ICMP responses. > > > > > > you mean - "no ip unreachables"? > > > > You could match the access list in a route map and set the outbound interface > > to Null0. > > _______________________________________________ > > 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 Sep 11 08:19:07 2008 From: blahu77 at gmail.com (=?ISO-8859-2?Q?Mateusz_B=B3aszczyk?=) Date: Thu, 11 Sep 2008 13:19:07 +0100 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <844ef89c0809110512r5ce679b4i8c7cd83c78015077@mail.gmail.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <844ef89c0809110512r5ce679b4i8c7cd83c78015077@mail.gmail.com> Message-ID: <383357750809110519p3fb19f3at2754a9b197130af@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> If it's high CPU at IP Input really need 12.4(20)T and get >> a sniffer trace in the punt path to see what traffic it really is. > > How to sniff traffic punted to CPU (control-plane) on 7200/7301 > platform ? Is there something like rp-inband/sp-inband for 6500 ? > I am not sure how, but I read the Release notes for 12.4.20T and they have some sort of packet dumper that can be attached to the punted path. - -- - -mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIyQy6IvBv0k5esR4RAvzFAJ9syLTK4/i+6+JHAcvJW7lkp8W51gCgwZbg tQRptD54RcRxdhTqxsPEBDU= =Ft9Z -----END PGP SIGNATURE----- From blahu77 at gmail.com Thu Sep 11 08:23:49 2008 From: blahu77 at gmail.com (=?ISO-8859-2?Q?Mateusz_B=B3aszczyk?=) Date: Thu, 11 Sep 2008 13:23:49 +0100 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <383357750809110519p3fb19f3at2754a9b197130af@mail.gmail.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <844ef89c0809110512r5ce679b4i8c7cd83c78015077@mail.gmail.com> <383357750809110519p3fb19f3at2754a9b197130af@mail.gmail.com> Message-ID: <383357750809110523j3c43f2ebnf2f4c17f37b71f9d@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I am not sure how, but I read the Release notes for 12.4.20T and they > have some sort of packet dumper that can be attached to the punted > path. the presentation: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps6968/ps6441/ps9497/prod_presentation_12_4_20T.pdf - -- - -mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIyQ3UIvBv0k5esR4RApR/AKC//Q5CewDipxzj/UKSmY26e3yt0ACgvIb1 JYton0T0TshQxKXnbcTyVOo= =EzOY -----END PGP SIGNATURE----- From blahu77 at gmail.com Thu Sep 11 08:29:05 2008 From: blahu77 at gmail.com (=?ISO-8859-2?Q?Mateusz_B=B3aszczyk?=) Date: Thu, 11 Sep 2008 13:29:05 +0100 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <844ef89c0809110512r5ce679b4i8c7cd83c78015077@mail.gmail.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <844ef89c0809110512r5ce679b4i8c7cd83c78015077@mail.gmail.com> Message-ID: <383357750809110529y67490054j95b48a53b56d8d1@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > How to sniff traffic punted to CPU (control-plane) on 7200/7301 > platform ? Is there something like rp-inband/sp-inband for 6500 ? seems 7301 is not "there yet" http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps6968/ps6441/product_bulletin_c25-409474.html#wp9002099 - -> supported hardware = Cisco Integrated Services Routers, Cisco 7200 Series Routers - -- - -mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIyQ8PIvBv0k5esR4RAgbqAKCCsuNAoMvXfalc3lux6uUEjXd9EQCdFEJ4 +nA2PXfs/XbNHAaUgAXQ/GQ= =1+wU -----END PGP SIGNATURE----- From branto at branto.com Thu Sep 11 09:00:04 2008 From: branto at branto.com (Brant I. Stevens) Date: Thu, 11 Sep 2008 09:00:04 -0400 Subject: [c-nsp] Datacenter Network Design In-Reply-To: <89944ef40809110015k28ea0ca7k219da9a68a02b374@mail.gmail.com> Message-ID: The Solutions Reference Network Design page on Cisco's site is a good resource for network designs. http://www.cisco.com/go/srnd -Brant On 9/11/08 3:15 AM, "root net" wrote: > John, > > If you are going to build a Cisco network you should spend some time on > www.cisco.com and look at all of their configuration examples and > whitepapers for specific gear you are looking at or working on. Here are > some books I would suggest: > > Cisco Press: > Data Center Fundamentals > End-to-End QoS Network Design > Designing for Cisco Internetwork Solutions > Designing Cisco Network Architectures > Network Management Fundamentals > > www.cisco.com: (Research) > > HSRP > STP > InterVLAN routing > IEEE Bridging > BGP > OSPF > L2TPV3 > MPLS / VPN > IOS information > > Others: > Administering Data Centers > > APC Data Center University (online classes) Some are FREE some are not. > > This is all I could think of since it's so late. DR will come when you > start digging into the protocols and other information. Far as > storage/backup iSCSI is your friend so build a GbE network. OpenFiler, > NetApp, MyIVault. > >> From the start your facility will need to handle your immediate needs and > growth or at least have the ability to scale (I would say maybe 10-20% > growth for small budgets). Look at evironmentals, power, fire protection: > HVAC (spot coolers vs. ductless split systems vs. ducted systems, chilled > water vs. air cooled), Power Requirements (Single Phase, Three Phase 208V > /480V, UPS, Transfer switches, portable generators, generator), Raised > Flooring vs. Anti-Static VCT, Security monitoring, water monitoring, > temperature monitoring, and lastly Pre-action vs. plain wet system. > > Getting a seperate Internet feed would be wise unless it's just cost > prohibitive. Start out with maybe 10Mbit pipe and go from there. This all > depends your customer's applications and servers. What they will be > transfering and etc. > > Look into open source products as these are FREE and can help you. (e.g. > nagios, jffnms, cacti, mrtg, syslog, linux, RT, rancid, and others) > > Rule of thumb: A good data center will have proactive measures and policies > in place to monitor, maintain, and procure. With that said monitor > everything (I mean everything) and have all staff alerted on all levels SMS, > e-mail, phone if possible automatically. It's not about downtime so much > it's how you procure the situation in a specific time frame. Customer > serivce is a must. > > You will need to make the call on the gear you use but I use a mixture of > Cisco, Extreme, and Juniper. For data centers it's a must for hot swappable > gear so look in to carrier class gear with redundant process, power > supplies, hot swappable line cards. I would recommend Cisco 6500 Series, > Cisco 7200 Series, Cisco ASA or Pix. I am not to fond of the Juniper > firewall licensing. BTW, Cisco 2800/3600 Series may even work. Depends on > your throughput capabilities you are needing. Research all aspects of your > gear from ram, flash, processor speeds, to throughput, modules, IOS, and hot > swappable needs. > > > The above will get you started. > > rootnet08 > > On 9/10/08, John Ramz wrote: >> >> We are looking into start hosting our customers' apps and data and would >> like for you to provide me link to internet resources (or books) to get me >> started on a network design that includes: >> >> - 3rd party Compliance (security for example) >> - Redundancy (routers, firewalls, switches) >> - load balancing >> - VLANS >> - Virtual servers >> - Backup- SANs- >> - Disaster recovery >> - How to keep customers separated from our regular network? >> - How to keep customers totally isolated from each other? >> - Access from our network to the Datacenter network for our developers to >> work with our customers? Also for our IT people to service, monitor and >> maintain that network > > I have thought of getting an Internet pipe just for the Datacenter network >> and with all the above mentioned components and then figure out the way and >> procedures to connect our company network with that one for the different >> items I already mentioned. >> >> Has anyone been involved in a project like that could elaborate as much as >> possible on the subject? >> > Please shed some light with me on where to start and build from there? >> >> 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/ >> > _______________________________________________ > 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 rodunn at cisco.com Thu Sep 11 09:03:30 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Thu, 11 Sep 2008 09:03:30 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <844ef89c0809110512r5ce679b4i8c7cd83c78015077@mail.gmail.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <844ef89c0809110512r5ce679b4i8c7cd83c78015077@mail.gmail.com> Message-ID: <20080911130330.GB23118@rtp-cse-489.cisco.com> You go to 12.4(20)T and do an EPC capture on the punt path. I'm going to type up a wiki showing some examples today I hope. I'll try to post it back out. Rodney On Thu, Sep 11, 2008 at 02:12:27PM +0200, David Granzer wrote: > Hello, > > On 9/5/08, Rodney Dunn wrote: > > But make sure you do: > > > > config t > > int null 0 > > no ip unreachables > > > > The ACL drops are, last I checked, rate limit punts. > > > > If it's high CPU at IP Input really need 12.4(20)T and get > > a sniffer trace in the punt path to see what traffic it really is. > > How to sniff traffic punted to CPU (control-plane) on 7200/7301 > platform ? Is there something like rp-inband/sp-inband for 6500 ? > > Thanks, > David > > > > On the 6500 is available SPAN RP-Inband and SP-Inband > > > > > > > Rodney > > > > > > On Thu, Sep 04, 2008 at 03:46:23PM -0400, Stephen Kratzer wrote: > > > On Thursday 04 September 2008 15:12:12 Mateusz B??aszczyk wrote: > > > > 2008/9/4 Stephen Kratzer : > > > > > The 'log' keyword will cause matching packets to not be CEF switched. > > > > > > > > nope, log is not present. > > > > > > > > > Also, if > > > > > you're denying a lot of traffic from a certain source, you might want to > > > > > just bit-bucket it rather than sending ICMP responses. > > > > > > > > you mean - "no ip unreachables"? > > > > > > You could match the access list in a route map and set the outbound interface > > > to Null0. > > > _______________________________________________ > > > 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 rodunn at cisco.com Thu Sep 11 09:06:26 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Thu, 11 Sep 2008 09:06:26 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <383357750809110529y67490054j95b48a53b56d8d1@mail.gmail.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041456.01591.kratzers@pa.net> <383357750809041212h2e17aaa2i967ba4ffc3e4c3de@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <844ef89c0809110512r5ce679b4i8c7cd83c78015077@mail.gmail.com> <383357750809110529y67490054j95b48a53b56d8d1@mail.gmail.com> Message-ID: <20080911130626.GC23118@rtp-cse-489.cisco.com> That's wrong. The 7301 is basically a 1RU 72xx/G2 combo. It's there so try it. The code is on Cisco.com as I just checked. Rodney On Thu, Sep 11, 2008 at 01:29:05PM +0100, Mateusz B?aszczyk wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > > > How to sniff traffic punted to CPU (control-plane) on 7200/7301 > > platform ? Is there something like rp-inband/sp-inband for 6500 ? > > seems 7301 is not "there yet" > > http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps6968/ps6441/product_bulletin_c25-409474.html#wp9002099 > > - -> supported hardware = Cisco Integrated Services Routers, Cisco 7200 > Series Routers > > - -- > - -mat > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIyQ8PIvBv0k5esR4RAgbqAKCCsuNAoMvXfalc3lux6uUEjXd9EQCdFEJ4 > +nA2PXfs/XbNHAaUgAXQ/GQ= > =1+wU > -----END PGP SIGNATURE----- From Kevin.X.White at corusgroup.com Thu Sep 11 09:20:03 2008 From: Kevin.X.White at corusgroup.com (Kevin.X.White at corusgroup.com) Date: Thu, 11 Sep 2008 14:20:03 +0100 Subject: [c-nsp] 100FX Ports or Media Convertors? In-Reply-To: Message-ID: Hi, we have quite a lot of 100Mb fibre distribution but it is spread across many locations so 24 fibre ports out from any location is just about enough. My question is now, the 3550-FX has gone and I need to replace some units the way forward with integrated ports is the 3750 with 24FX + 4 SFP @ ~ $7000 A 3650 with 24x Media convertors with dual PSU shelves @ ~ $5000 We have had quite a few 3550 MTRJ 100FX ports partially fail (high RX drops) in the past causing all kinds of fun and games with STP So even with the extra points of failure the Media convertors are looking tempting as failed units can be simply replaced. Any comments welcomed. Kevin ********************************************************************** This transmission is confidential and must not be used or disclosed by anyone other than the intended recipient. Neither Tata Steel UK Limited nor any of its subsidiaries can accept any responsibility for any use or misuse of the transmission by anyone. For address and company registration details of certain entities within the Corus group of companies, please visit http://www.corusgroup.com/entities ********************************************************************** From justin at justinshore.com Thu Sep 11 09:39:39 2008 From: justin at justinshore.com (Justin Shore) Date: Thu, 11 Sep 2008 08:39:39 -0500 Subject: [c-nsp] Setting the Remote Syslog Port in IOS In-Reply-To: References: <48C82646.7040402@forthnet.gr> Message-ID: <48C91F9B.90606@justinshore.com> I have it on a 7206VXR running 12.4(15)T2. 7206-1.clr(config)#logging host ? Hostname or A.B.C.D IP address of the syslog server ipv6 Configure IPv6 syslog server 7206-1.clr(config)#logging host 1.2.3.4 ? discriminator Specify a message discriminator indentifier for this logging session filtered Enable filtered logging sequence-num-session Include session sequence number tag in syslog message session-id Specify syslog message session ID tagging transport Specify the transport protocol (default=UDP) vrf Set VRF option xml Enable logging in XML 7206-1.clr(config)#logging host 1.2.3.4 tr 7206-1.clr(config)#logging host 1.2.3.4 transport ? beep Blocks Extensible Exchange Protocol tcp Transport Control Protocol udp User Datagram Protocol 7206-1.clr(config)#logging host 1.2.3.4 transport udp ? discriminator Specify a message discriminator indentifier for this logging session filtered Enable filtered logging port Specify the UDP port number (default=514) sequence-num-session Include session sequence number tag in syslog message session-id Specify syslog message session ID tagging xml Enable logging in XML 7206-1.clr(config)#logging host 1.2.3.4 transport udp port ? <1-65535> Port number I also see the command on a 3660 running 12.3(14)T7. I have it on a 3560E running 12.2(44)SE2 but not on a 3750 running 12.2(25)SEB. I do however have it on a 3560G and a basic 3560 running 12.2(44)SE2. I also have it on a Sup720-3BXL in a 7600 running SRB1. Looks like it's available for the older platforms with the right IOS. Justin Christian Koch wrote: > checked for any switches after the inputting the ip address on logging > host command but nothing was available > > > #logging host 1.1.1.1 transport ? > % Unrecognized command > > > On Wed, Sep 10, 2008 at 3:55 PM, Tassos Chatzithomaoglou > wrote: >> Have you tried "logging host XXX transport udp port Y"? >> >> -- >> Tassos >> >> Christian Koch wrote on 10/09/2008 19:41: >>> I know i can set the remote syslog port on ASA/PIX's, but i don't seem >>> to see that it is possible in IOS. >>> >>> I wanted to segregate logs by sending them from certain devices to >>> separate syslog ports >>> >>> Can anyone confirm this behavior? >>> >>> Has anyone had the need to do something similar? >>> >>> Thanks >>> >>> >>> Christian >>> _______________________________________________ >>> 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-kell at utc.edu Thu Sep 11 09:50:51 2008 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 11 Sep 2008 09:50:51 -0400 Subject: [c-nsp] 100FX Ports or Media Convertors? In-Reply-To: References: Message-ID: <48C9223B.5030502@utc.edu> Kevin.X.White at corusgroup.com wrote: > Hi, we have quite a lot of 100Mb fibre distribution but it is spread across > many locations so 24 fibre ports out from any location is just about > enough. > > My question is now, the 3550-FX has gone and I need to replace some units > the way forward with integrated ports is the 3750 with 24FX + 4 SFP There is the SFP-only version WS-C3750G-12S. Or find some used 2912MF-XLs :-) Jeff From streiner at cluebyfour.org Thu Sep 11 09:58:38 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 11 Sep 2008 09:58:38 -0400 (EDT) Subject: [c-nsp] 100FX Ports or Media Convertors? In-Reply-To: References: Message-ID: On Thu, 11 Sep 2008, Kevin.X.White at corusgroup.com wrote: > My question is now, the 3550-FX has gone and I need to replace some units > the way forward with integrated ports is the 3750 with 24FX + 4 SFP @ ~ > $7000 > A 3650 with 24x Media convertors with dual PSU shelves @ ~ $5000 > > We have had quite a few 3550 MTRJ 100FX ports partially fail (high RX > drops) in the past causing all kinds of fun and games with STP > So even with the extra points of failure the Media convertors are looking > tempting as failed units can be simply replaced. I have a few devices and buildings on campus that I feed at 100FX, both from 4500s with MTRJ blades and from 3750s with the 100FX SFPs and both seem to be pretty reliable. I haven't seen the 'live' failure rates on the 100FX SFPs to be much better or worse than the GE SFPs we use all over the place. My personal choice is to go with the SFPs, rather than something that requires additional external pieces of gear, however I've never used the 3650 + media converters, so I can't speak to their reliability. jms From s00664233 at gmail.com Thu Sep 11 09:57:47 2008 From: s00664233 at gmail.com (cc loo) Date: Thu, 11 Sep 2008 21:57:47 +0800 Subject: [c-nsp] Inter VRF Routing help needed Message-ID: <49999c420809110657k2b66807dqa670b30e1c01a3ef@mail.gmail.com> Hi All, im pretty new to networking and require some assistance here with VRF-lite Scenario : i would like to establish a hub-and-spoke topology with multiple VRFs. vrf_Hub is created, with interface fa0/0 and ip address of 10.0.0.1/24 vrf_customer_A is created with interface fa0/1.1 and ip address of 192.168.1.1/24 vrf_customer_B is created with interface fa0/1.2 and ip address of 192.168.2.1/24 I would like vrf_customer_A to exchange routes with vrf_HUB but not vrf_customer_B, and vrf_customer_B with vrf_Hub but not vrf_customerA. Basically, each customer vrf can only see the hub, but not each other. I tried following the guide at http://www.cisco.com/univercd/cc/td/doc/product/ong/15400/r60docs/r60ethgd/546vrf.htm i created afew instances of vrf, tried import/export the RDs but my routing table still only show routes that are "connected" in the vrf only. I've heard that i require ospf or bgp to exchange routes between vrf (within the same router). What is the simplest method to achieve my desired scenario ? From rootnet08 at gmail.com Thu Sep 11 10:12:24 2008 From: rootnet08 at gmail.com (root net) Date: Thu, 11 Sep 2008 09:12:24 -0500 Subject: [c-nsp] 100FX Ports or Media Convertors? In-Reply-To: <48C9223B.5030502@utc.edu> References: <48C9223B.5030502@utc.edu> Message-ID: <89944ef40809110712h6fe21165w615ae8fafefdd5ed@mail.gmail.com> I seconded the 2912MF...or Catalyst 5500 with fiber cards. I am sure you can pick up dirt cheap. rootnet On Thu, Sep 11, 2008 at 8:50 AM, Jeff Kell wrote: > Kevin.X.White at corusgroup.com wrote: > > Hi, we have quite a lot of 100Mb fibre distribution but it is spread > across > > many locations so 24 fibre ports out from any location is just about > > enough. > > > > My question is now, the 3550-FX has gone and I need to replace some units > > the way forward with integrated ports is the 3750 with 24FX + 4 SFP > > There is the SFP-only version WS-C3750G-12S. Or find some used > 2912MF-XLs :-) > > 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 philxor at gmail.com Thu Sep 11 10:39:54 2008 From: philxor at gmail.com (Phil Bedard) Date: Thu, 11 Sep 2008 10:39:54 -0400 Subject: [c-nsp] Datacenter Network Design In-Reply-To: References: Message-ID: This is a good guide from Cisco. http://www.cisco.com/univercd/cc/td/doc/solution/dcidg21.pdf Phil On Sep 11, 2008, at 9:00 AM, Brant I. Stevens wrote: > The Solutions Reference Network Design page on Cisco's site is a good > resource for network designs. http://www.cisco.com/go/srnd > > -Brant > > On 9/11/08 3:15 AM, "root net" wrote: > >> John, >> >> If you are going to build a Cisco network you should spend some >> time on >> www.cisco.com and look at all of their configuration examples and >> whitepapers for specific gear you are looking at or working on. >> Here are >> some books I would suggest: >> >> Cisco Press: >> Data Center Fundamentals >> End-to-End QoS Network Design >> Designing for Cisco Internetwork Solutions >> Designing Cisco Network Architectures >> Network Management Fundamentals >> >> www.cisco.com: (Research) >> >> HSRP >> STP >> InterVLAN routing >> IEEE Bridging >> BGP >> OSPF >> L2TPV3 >> MPLS / VPN >> IOS information >> >> Others: >> Administering Data Centers >> >> APC Data Center University (online classes) Some are FREE some are >> not. >> >> This is all I could think of since it's so late. DR will come when >> you >> start digging into the protocols and other information. Far as >> storage/backup iSCSI is your friend so build a GbE network. >> OpenFiler, >> NetApp, MyIVault. >> >>> From the start your facility will need to handle your immediate >>> needs and >> growth or at least have the ability to scale (I would say maybe >> 10-20% >> growth for small budgets). Look at evironmentals, power, fire >> protection: >> HVAC (spot coolers vs. ductless split systems vs. ducted systems, >> chilled >> water vs. air cooled), Power Requirements (Single Phase, Three >> Phase 208V >> /480V, UPS, Transfer switches, portable generators, generator), >> Raised >> Flooring vs. Anti-Static VCT, Security monitoring, water monitoring, >> temperature monitoring, and lastly Pre-action vs. plain wet system. >> >> Getting a seperate Internet feed would be wise unless it's just cost >> prohibitive. Start out with maybe 10Mbit pipe and go from there. >> This all >> depends your customer's applications and servers. What they will be >> transfering and etc. >> >> Look into open source products as these are FREE and can help you. >> (e.g. >> nagios, jffnms, cacti, mrtg, syslog, linux, RT, rancid, and others) >> >> Rule of thumb: A good data center will have proactive measures and >> policies >> in place to monitor, maintain, and procure. With that said monitor >> everything (I mean everything) and have all staff alerted on all >> levels SMS, >> e-mail, phone if possible automatically. It's not about downtime >> so much >> it's how you procure the situation in a specific time frame. >> Customer >> serivce is a must. >> >> You will need to make the call on the gear you use but I use a >> mixture of >> Cisco, Extreme, and Juniper. For data centers it's a must for hot >> swappable >> gear so look in to carrier class gear with redundant process, power >> supplies, hot swappable line cards. I would recommend Cisco 6500 >> Series, >> Cisco 7200 Series, Cisco ASA or Pix. I am not to fond of the Juniper >> firewall licensing. BTW, Cisco 2800/3600 Series may even work. >> Depends on >> your throughput capabilities you are needing. Research all aspects >> of your >> gear from ram, flash, processor speeds, to throughput, modules, >> IOS, and hot >> swappable needs. >> >> >> The above will get you started. >> >> rootnet08 >> >> On 9/10/08, John Ramz wrote: >>> >>> We are looking into start hosting our customers' apps and data and >>> would >>> like for you to provide me link to internet resources (or books) >>> to get me >>> started on a network design that includes: >>> >>> - 3rd party Compliance (security for example) >>> - Redundancy (routers, firewalls, switches) >>> - load balancing >>> - VLANS >>> - Virtual servers >>> - Backup- SANs- >>> - Disaster recovery >>> - How to keep customers separated from our regular network? >>> - How to keep customers totally isolated from each other? >>> - Access from our network to the Datacenter network for our >>> developers to >>> work with our customers? Also for our IT people to service, >>> monitor and >>> maintain that network >> >> I have thought of getting an Internet pipe just for the Datacenter >> network >>> and with all the above mentioned components and then figure out >>> the way and >>> procedures to connect our company network with that one for the >>> different >>> items I already mentioned. >>> >>> Has anyone been involved in a project like that could elaborate as >>> much as >>> possible on the subject? >>> >> Please shed some light with me on where to start and build from >> there? >>> >>> 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/ >>> >> _______________________________________________ >> 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 oboehmer at cisco.com Thu Sep 11 10:41:36 2008 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Thu, 11 Sep 2008 16:41:36 +0200 Subject: [c-nsp] Inter VRF Routing help needed In-Reply-To: <49999c420809110657k2b66807dqa670b30e1c01a3ef@mail.gmail.com> References: <49999c420809110657k2b66807dqa670b30e1c01a3ef@mail.gmail.com> Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED784060258F9@xmb-ams-333.emea.cisco.com> cc loo <> wrote on Thursday, September 11, 2008 3:58 PM: > Hi All, > im pretty new to networking and require some assistance here with > VRF-lite > > Scenario : > > i would like to establish a hub-and-spoke topology with multiple VRFs. > ... > > I would like vrf_customer_A to exchange routes with vrf_HUB but not > vrf_customer_B, > and vrf_customer_B with vrf_Hub but not vrf_customerA. > > Basically, each customer vrf can only see the hub, but not each other. > I tried following the guide at > http://www.cisco.com/univercd/cc/td/doc/product/ong/15400/r60docs/r60eth gd/546vrf.htm > > i created afew instances of vrf, tried import/export the RDs but my > routing table still only show routes that are "connected" in the vrf > only. > I've heard that i require ospf or bgp to exchange routes between vrf > (within the same router). > > What is the simplest method to achieve my desired scenario ? > I guess you are talking about vrf-lite (i.e. no mpls involved). you can do it like that: ip vrf customer_A rd 1:1 route-target export 1:100 route-target import 1:900 ! ip vrf customer_B rd 1:2 route-target export 1:200 route-target import 1:900 ! ip vrf Hub rd 1:9 route-target export 1:900 route-target import 1:100 route-target import 1:200 ! router bgp 65000 address-fam ipv4 vrf customer_A redistribute static redistribute connected address-fam ipv4 vrf customer_B redistribute static redistribute connected address-fam ipv4 vrf Hub redistribute static redistribute connected If you add routing protocols to it, you also need to redistribute those into BGP. all the import/export stuff is done via BGP.. oli From s00664233 at gmail.com Thu Sep 11 11:05:18 2008 From: s00664233 at gmail.com (cc loo) Date: Thu, 11 Sep 2008 23:05:18 +0800 Subject: [c-nsp] Inter VRF Routing help needed In-Reply-To: <70B7A1CCBFA5C649BD562B6D9F7ED784060258F9@xmb-ams-333.emea.cisco.com> References: <49999c420809110657k2b66807dqa670b30e1c01a3ef@mail.gmail.com> <70B7A1CCBFA5C649BD562B6D9F7ED784060258F9@xmb-ams-333.emea.cisco.com> Message-ID: <49999c420809110805s23458537j90da85133d06790a@mail.gmail.com> Hi Oliver, Thanks for the quick reply. Indeed i was referring to VRF-LITE In the cisco.com example, they gave this Router(config)# *ip vrf customer_a* Router(config-vrf)# *rd 1:1 <----* Router(config-vrf)# *route-target both 1:1 <----* Router(config)# *interface fastEthernet 0.1* Router(config-subif)# ip vrf forwarding customer_a is there any specific reason why cisco recommends using "both" (export/import) for its own RD ? Oliver's example is here, but i would like to confirm if 1:100 is a typo or should it be 1:1 (like its own RD?): ip vrf customer_A rd 1:1 <----- route-target export 1:100 <---- route-target import 1:900 I wonder wondering if this is the correct place to post newbie questions like these ? Im a junior engineer in a singaporean isp, hoping to learn more tricks and tips in the field of IP planning :D On Thu, Sep 11, 2008 at 10:41 PM, Oliver Boehmer (oboehmer) < oboehmer at cisco.com> wrote: > cc loo <> wrote on Thursday, September 11, 2008 3:58 PM: > > > Hi All, > > im pretty new to networking and require some assistance here with > > VRF-lite > > > > Scenario : > > > > i would like to establish a hub-and-spoke topology with multiple VRFs. > > > ... > > > > I would like vrf_customer_A to exchange routes with vrf_HUB but not > > vrf_customer_B, > > and vrf_customer_B with vrf_Hub but not vrf_customerA. > > > > Basically, each customer vrf can only see the hub, but not each other. > > I tried following the guide at > > > http://www.cisco.com/univercd/cc/td/doc/product/ong/15400/r60docs/r60eth > gd/546vrf.htm > > > > i created afew instances of vrf, tried import/export the RDs but my > > routing table still only show routes that are "connected" in the vrf > > only. > > I've heard that i require ospf or bgp to exchange routes between vrf > > (within the same router). > > > > What is the simplest method to achieve my desired scenario ? > > > > I guess you are talking about vrf-lite (i.e. no mpls involved). you can > do it like that: > > ip vrf customer_A > rd 1:1 > route-target export 1:100 > route-target import 1:900 > ! > ip vrf customer_B > rd 1:2 > route-target export 1:200 > route-target import 1:900 > ! > ip vrf Hub > rd 1:9 > route-target export 1:900 > route-target import 1:100 > route-target import 1:200 > ! > router bgp 65000 > address-fam ipv4 vrf customer_A > redistribute static > redistribute connected > address-fam ipv4 vrf customer_B > redistribute static > redistribute connected > address-fam ipv4 vrf Hub > redistribute static > redistribute connected > > > If you add routing protocols to it, you also need to redistribute those > into BGP. all the import/export stuff is done via BGP.. > > oli > From oboehmer at cisco.com Thu Sep 11 11:14:24 2008 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Thu, 11 Sep 2008 17:14:24 +0200 Subject: [c-nsp] Inter VRF Routing help needed In-Reply-To: <49999c420809110805s23458537j90da85133d06790a@mail.gmail.com> References: <49999c420809110657k2b66807dqa670b30e1c01a3ef@mail.gmail.com> <70B7A1CCBFA5C649BD562B6D9F7ED784060258F9@xmb-ams-333.emea.cisco.com> <49999c420809110805s23458537j90da85133d06790a@mail.gmail.com> Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED78406025945@xmb-ams-333.emea.cisco.com> cc loo wrote on Thursday, September 11, 2008 5:05 PM: > Hi Oliver, > > Thanks for the quick reply. > > Indeed i was referring to VRF-LITE > > In the cisco.com example, they gave this > Router(config)# ip vrf customer_a > Router(config-vrf)# rd 1:1 <---- > Router(config-vrf)# route-target both 1:1 <---- > Router(config)# interface fastEthernet 0.1 > Router(config-subif)# ip vrf forwarding customer_a > > is there any specific reason why cisco recommends using "both" > (export/import) for its own RD ? the RD is not exported, the RT is. see answer to next question. Well, the "import" is not really needed in this specific case as there is no other VRF exporting routes with this route-target (so no point importing it). > > Oliver's example is here, but i would like to confirm if 1:100 is a > typo or should it be 1:1 (like its own RD?): ip vrf customer_A > rd 1:1 <----- > route-target export 1:100 <---- > route-target import 1:900 RD and route-target are different things. They can be the same, but they must not be (in an mpls-vpn, they usually aren't the same as the RD is unique per PE per VRF). > I wonder wondering if this is the correct place to post newbie > questions like these ? > Im a junior engineer in a singaporean isp, hoping to learn more > tricks and tips in the field of IP planning :D well, I guess it's like all lists where folks help each other: If people see that you haven't done your homework, you might not get a reply. oli From claes at gastabud.com Thu Sep 11 10:57:29 2008 From: claes at gastabud.com (Claes Jansson) Date: Thu, 11 Sep 2008 16:57:29 +0200 Subject: [c-nsp] 100FX Ports or Media Convertors? In-Reply-To: References: Message-ID: <200809111457.m8BEvaRj013107@ns.gastabud.com> Hi, i highly recommend using the ME-3400-24FS-A with GLC-FE-100FX SFPs. Swtich cost about 1500$ and the SFPs about 65$ a piece. The 3550s lack some features that the me3400 series has. And it handles 'ip arp inspection' much better... Using media converters has several disadvantages. More complex installation, uses more rack-space, more power and generates quite a lot of heat... And some switching media-converters also "hides" packet errors on the fiber side. And some generate not-wanted pause frames, disrupting traffic... //Claes At 15:20 2008-09-11, you wrote: >Hi, we have quite a lot of 100Mb fibre distribution but it is spread across >many locations so 24 fibre ports out from any location is just about >enough. > >My question is now, the 3550-FX has gone and I need to replace some units >the way forward with integrated ports is the 3750 with 24FX + 4 SFP @ ~ >$7000 >A 3650 with 24x Media convertors with dual PSU shelves @ ~ $5000 > >We have had quite a few 3550 MTRJ 100FX ports partially fail (high RX >drops) in the past causing all kinds of fun and games with STP >So even with the extra points of failure the Media convertors are looking >tempting as failed units can be simply replaced. > >Any comments welcomed. > >Kevin >********************************************************************** >This transmission is confidential and must not be used or disclosed by >anyone other than the intended recipient. Neither Tata Steel UK Limited nor >any of its subsidiaries can accept any responsibility for any use or >misuse of the transmission by anyone. > >For address and company registration details of certain entities >within the Corus group of companies, please visit >http://www.corusgroup.com/entities > >********************************************************************** > >_______________________________________________ >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 Sep 11 11:28:50 2008 From: justin at justinshore.com (Justin Shore) Date: Thu, 11 Sep 2008 10:28:50 -0500 Subject: [c-nsp] EoMPLS between C7206 and C3845 In-Reply-To: References: Message-ID: <48C93932.4080308@justinshore.com> Is that an EtherSwitch "Network" module or "Service" module? They are very different beasts. I'd imagine that you were using the Network module and that the problem could have been avoided with a Service module. http://tinyurl.com/2ok8ox The Service module literally acts as an independent switch that happens to be mounted inside the ISR chassis. I don't have a solution for your EoMPLS problem when using the Network module unfortunately. Maybe someone from Cisco can chime in on that one. Justin Junaid wrote: > Hi, > > I have narrowed the problem. Now EoMPLS is working between the two > routers - the change is that instead of connecting CE2 to the > EtherSwitch module of C3845, I have connected it on an external 2950 > switch which is then dot1q trunked to C3845. The problem appears when > I connect the host on the EtherSwitch port. The configuration on the > routing portion of C3845 is exactly same in both cases and the config > on the 2950 and EtherSwitch is similar. Does anyone has any experience > of running EoMPLS on C3845 with a host on an EtherSwitch module port? > Is there any special consideration that needs to be catered for in > such a scenario? > > Will appreciate any help. > > Regards, > Junaid > > > On Thu, Aug 7, 2008 at 2:15 AM, Junaid wrote: >> Hi, >> >> I am trying to make EoMPLS (VLAN mode) to work between a 7206VXR >> (NPE400) running c7200-jk9s-mz.123-21.bin and a 3845 running >> c3845-advipservicesk9-mz.124-15.T.bin. These two PE routers are >> connected back-to-back via FastEthernet. The customers are connected >> via a switch connected to each PE: >> >> CE1 --- Switch --- PE1 --- PE2 --- Switch --- CE2 >> >> The control place comes up without any issue: >> >> C7200-PE1#sh mpls l2transport vc de >> Local interface: Fa0/0.3 up, line protocol up, Eth VLAN 3 up >> Destination address: XXXXX (loopback ip of PE2), VC ID: 100, VC status: up >> Next hop: XXXXXX (ip of PE2's interface connected with PE1) >> Output interface: Fa3/0, imposed label stack {234} >> Create time: 04:55:52, last status change time: 04:22:07 >> Signaling protocol: LDP, peer XXXXX (loopback ip of PE2):0 up >> MPLS VC labels: local 2207, remote 234 >> Group ID: local 0, remote 0 >> MTU: local 1500, remote 1500 >> Remote interface description: MPLS TEST >> Sequencing: receive disabled, send disabled >> VC statistics: >> packet totals: receive 658, send 558 >> byte totals: receive 61117, send 57759 >> packet drops: receive 0, send 0 >> >> >> C3845-PE2#sh mpls l2transport vc de >> Local interface: Gi4/0.3 up, line protocol up, Eth VLAN 3 up >> Destination address: XXXXX (loopback ip of PE1), VC ID: 100, VC status: up >> Next hop: XXXXXX (ip of PE1's interface connected with PE2) >> Output interface: Gi0/0, imposed label stack {2207} >> Create time: 05:06:06, last status change time: 04:42:00 >> Signaling protocol: LDP, peer XXXXX (loopback ip of PE1):0 up >> MPLS VC labels: local 234, remote 2207 >> Group ID: local 0, remote 0 >> MTU: local 1500, remote 1500 >> Remote interface description: MPLS test >> Sequencing: receive disabled, send disabled >> VC statistics: >> packet totals: receive 807, send 697 >> byte totals: receive 81235, send 63925 >> packet drops: receive 0, seq error 0, send 0 >> >> >> But the data plane is having severe issue. I cannot ping end-to-end >> from the CEs. It seems that when I ping CE1 from CE2 (i.e. from the CE >> connected to 3845), ARP works and I am able to send a ping packet to >> CE1. But CE1 never receives it. On the other side, CE2 does not get >> replies to its own ARP requests. Once I statically bind the mac >> address of CE2 on CE1, CE1 sends an ICMP packet to CE2 and CE2 replies >> to it but CE1 never receives the reply. It seem that the communication >> is one way, from CE1 (one behind C7206) to CE2 (one behind C3845) and >> not the other way round. I replaced C3845 with C7206 and there was not >> issue in the data plane. >> >> My question is with the IOS I used for C3845, is EoMPLS not supported >> on it? As per Cisco's documentation, EoMPLS is supported on the IOS I >> used for C3845. Any one any experience in running EoMPLS on C3845? >> >> Another thing I noted was in the following output from C3845, it shows >> MRU=0 and also there was no outgoing interface attached: >> >> C3845-PE2#sh mpls forwarding-table labels 234 detail >> Local Outgoing Prefix Bytes tag Outgoing Next Hop >> tag tag or VC or Tunnel Id switched interface >> 234 l2ckt(100) 50732 none point2point >> MAC/Encaps=0/0, MRU=0, Tag Stack{} >> No output feature configured >> >> While on C7206, the output was as it should be: >> >> C7200-PE1#sh mpls forwarding-table labels 2207 detail >> Local Outgoing Prefix Bytes tag Outgoing Next Hop >> tag tag or VC or Tunnel Id switched interface >> 2207 Untagged l2ckt(100) 55853 Fa0/0.3 point2point >> MAC/Encaps=0/0, MRU=1500, Tag Stack{} >> No output feature configured >> >> >> Any explanations/solutions? >> >> >> >> Regards, >> >> Junaid >> > _______________________________________________ > 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 jlewis at lewis.org Thu Sep 11 11:50:44 2008 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 11 Sep 2008 11:50:44 -0400 (EDT) Subject: [c-nsp] 6500 netflow export and the switch cpu Message-ID: I've got a 6509 with sup720-3bxl running 12.2(18)SXD7b. It's forwarding several hundred mbit/s across a number of gig ports on WS-X6416-GBIC cards. I've noticed it's gotten very slow at certain things (like write mem), and when looking at the switch (remote command switch show proc cpu), I was kind of shocked to see 85% CPU utilization or higher across all time avgs. The biggest CPU eating process seems to be netflow export 223 2563111984 126342970 20287 38.27% 42.39% 42.03% 0 NDE - IPV4 Other than disabling export or moving traffic off this device, are there things I can do to tone this down? The couple hundred mbit/s this switch is forwarding is supposed to be no big deal for this platform. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From p.mayers at imperial.ac.uk Thu Sep 11 12:28:23 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Thu, 11 Sep 2008 17:28:23 +0100 Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: References: Message-ID: <48C94727.4030002@imperial.ac.uk> Jon Lewis wrote: > I've got a 6509 with sup720-3bxl running 12.2(18)SXD7b. It's forwarding > several hundred mbit/s across a number of gig ports on WS-X6416-GBIC cards. That's an old IOS. You should probably consider an upgrade to the later SXF release (e.g. 10, 11, 14) There are a number of netflow related bugs referenced in the release notes. > > I've noticed it's gotten very slow at certain things (like write mem), > and when looking at the switch (remote command switch show proc cpu), I > was kind of shocked to see 85% CPU utilization or higher across all time > avgs. The biggest CPU eating process seems to be netflow export > > 223 2563111984 126342970 20287 38.27% 42.39% 42.03% 0 NDE - IPV4 > > Other than disabling export or moving traffic off this device, are there > things I can do to tone this down? The couple hundred mbit/s this > switch is forwarding is supposed to be no big deal for this platform. It's likely number of flows, rather than bit rate. What do the following say: sh mls netflow table-contention detailed sh mls netflow flowmask sh mls nde sh platform hardware capacity netflow From asadh at comcast.net Thu Sep 11 12:38:48 2008 From: asadh at comcast.net (Asad) Date: Thu, 11 Sep 2008 16:38:48 +0000 Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: References: Message-ID: <1836781474-1221151128-cardhu_decombobulator_blackberry.rim.net-959829273-@bxe252.bisx.prod.on.blackberry> You can enable sampling if it is not enabled. It should help some. Asad Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Jon Lewis Date: Thu, 11 Sep 2008 11:50:44 To: Subject: [c-nsp] 6500 netflow export and the switch cpu I've got a 6509 with sup720-3bxl running 12.2(18)SXD7b. It's forwarding several hundred mbit/s across a number of gig ports on WS-X6416-GBIC cards. I've noticed it's gotten very slow at certain things (like write mem), and when looking at the switch (remote command switch show proc cpu), I was kind of shocked to see 85% CPU utilization or higher across all time avgs. The biggest CPU eating process seems to be netflow export 223 2563111984 126342970 20287 38.27% 42.39% 42.03% 0 NDE - IPV4 Other than disabling export or moving traffic off this device, are there things I can do to tone this down? The couple hundred mbit/s this switch is forwarding is supposed to be no big deal for this platform. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From jlewis at lewis.org Thu Sep 11 12:51:17 2008 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 11 Sep 2008 12:51:17 -0400 (EDT) Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: <48C94727.4030002@imperial.ac.uk> References: <48C94727.4030002@imperial.ac.uk> Message-ID: On Thu, 11 Sep 2008, Phil Mayers wrote: > What do the following say: > > sh mls netflow table-contention detailed Earl in Module 5 Detailed Netflow CAM (TCAM and ICAM) Utilization ================================================ TCAM Utilization : 100% ICAM Utilization : 7% Netflow TCAM count : 262026 Netflow ICAM count : 10 Netflow Creation Failures : 456680 Netflow CAM aliases : 0 I guess I need to get more aggressive on the flow aging. I've been using mls aging fast time 8 threshold 3 mls aging long 480 mls aging normal 32 > sh mls netflow flowmask current ip flowmask for unicast: if-full current ipv6 flowmask for unicast: null > sh mls nde Netflow Data Export enabled Exporting flows to [removed] Exporting flows from [removed] Version: 5 Include Filter not configured Exclude Filter not configured Total Netflow Data Export Packets are: 3738467024 packets, 0 no packets, 1041361295 records Total Netflow Data Export Send Errors: IPWRITE_NO_FIB = 0 IPWRITE_ADJ_FAILED = 0 IPWRITE_PROCESS = 0 IPWRITE_ENQUEUE_FAILED = 0 IPWRITE_IPC_FAILED = 0 IPWRITE_OUTPUT_FAILED = 0 IPWRITE_MTU_FAILED = 0 IPWRITE_ENCAPFIX_FAILED = 0 Netflow Aggregation Disabled > sh platform hardware capacity netflow #sh platform hardware capacity netflow ^ % Invalid input detected at '^' marker. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From s00664233 at gmail.com Thu Sep 11 13:09:05 2008 From: s00664233 at gmail.com (cc loo) Date: Fri, 12 Sep 2008 01:09:05 +0800 Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: References: Message-ID: <49999c420809111009ga56f9a1ie60f163c4b87748e@mail.gmail.com> I was wondering if mirroring the traffic into a server with Netflow probes (such as fprobe) to help relieving the stress on router's CPU would be a wise move ? Is this move common in ISP environments or do most of the big guys just leave the exporting from routers to collectors ? On Thu, Sep 11, 2008 at 11:50 PM, Jon Lewis wrote: > I've got a 6509 with sup720-3bxl running 12.2(18)SXD7b. It's forwarding > several hundred mbit/s across a number of gig ports on WS-X6416-GBIC cards. > > I've noticed it's gotten very slow at certain things (like write mem), and > when looking at the switch (remote command switch show proc cpu), I was kind > of shocked to see 85% CPU utilization or higher across all time avgs. The > biggest CPU eating process seems to be netflow export > > 223 2563111984 126342970 20287 38.27% 42.39% 42.03% 0 NDE - IPV4 > > Other than disabling export or moving traffic off this device, are there > things I can do to tone this down? The couple hundred mbit/s this switch is > forwarding is supposed to be no big deal for this platform. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > _______________________________________________ > cisco-nsp mailing list cisco-nsp 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 Sep 11 13:09:57 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Thu, 11 Sep 2008 18:09:57 +0100 Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: References: <48C94727.4030002@imperial.ac.uk> Message-ID: <48C950E5.902@imperial.ac.uk> Jon Lewis wrote: > On Thu, 11 Sep 2008, Phil Mayers wrote: > >> What do the following say: >> >> sh mls netflow table-contention detailed > > Earl in Module 5 > Detailed Netflow CAM (TCAM and ICAM) Utilization > ================================================ > TCAM Utilization : 100% > ICAM Utilization : 7% > Netflow TCAM count : 262026 > Netflow ICAM count : 10 > Netflow Creation Failures : 456680 > Netflow CAM aliases : 0 Ah. Yes, you're overflowing quite considerably. There's probably not a lot you can do about this other than drop the flowmask. > > I guess I need to get more aggressive on the flow aging. I've been using > mls aging fast time 8 threshold 3 > mls aging long 480 > mls aging normal 32 > > >> sh mls netflow flowmask > > current ip flowmask for unicast: if-full > current ipv6 flowmask for unicast: null Do you need the full mask? It includes tcp/udp ports. Dropping to destination-source may save you a lot of flows (but obviously lose you a lot of info) > >> sh mls nde > > Netflow Data Export enabled > Exporting flows to [removed] > Exporting flows from [removed] > Version: 5 > Include Filter not configured > Exclude Filter not configured > Total Netflow Data Export Packets are: > 3738467024 packets, 0 no packets, 1041361295 records > Total Netflow Data Export Send Errors: > IPWRITE_NO_FIB = 0 > IPWRITE_ADJ_FAILED = 0 > IPWRITE_PROCESS = 0 > IPWRITE_ENQUEUE_FAILED = 0 > IPWRITE_IPC_FAILED = 0 > IPWRITE_OUTPUT_FAILED = 0 > IPWRITE_MTU_FAILED = 0 > IPWRITE_ENCAPFIX_FAILED = 0 > Netflow Aggregation Disabled > >> sh platform hardware capacity netflow > #sh platform hardware capacity netflow > ^ Come to think of it, that's an SXF command. From sthaug at nethelp.no Thu Sep 11 13:34:36 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 11 Sep 2008 19:34:36 +0200 (CEST) Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: <1836781474-1221151128-cardhu_decombobulator_blackberry.rim.net-959829273-@bxe252.bisx.prod.on.blackberry> References: <1836781474-1221151128-cardhu_decombobulator_blackberry.rim.net-959829273-@bxe252.bisx.prod.on.blackberry> Message-ID: <20080911.193436.41659240.sthaug@nethelp.no> > You can enable sampling if it is not enabled. It should help some. Highly unlikely. Sampling on the 6500 is performed interely in software, *after* the full set of flows has been received. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jlewis at lewis.org Thu Sep 11 13:52:57 2008 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 11 Sep 2008 13:52:57 -0400 (EDT) Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: <48C950E5.902@imperial.ac.uk> References: <48C94727.4030002@imperial.ac.uk> <48C950E5.902@imperial.ac.uk> Message-ID: On Thu, 11 Sep 2008, Phil Mayers wrote: >> current ip flowmask for unicast: if-full >> current ipv6 flowmask for unicast: null > > Do you need the full mask? It includes tcp/udp ports. Dropping to > destination-source may save you a lot of flows (but obviously lose you a lot > of info) I'd really like to keep ip-full. It's quite handy when tracking down what an IP has been up to (like when trying to verify infection/scanning complaints). ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From vikassharmas at gmail.com Thu Sep 11 14:08:08 2008 From: vikassharmas at gmail.com (Vikas Sharma) Date: Thu, 11 Sep 2008 23:38:08 +0530 Subject: [c-nsp] F5 BIG IP and FWSM Message-ID: Hi, Did any one have worked on F5 BIG IP and FWSM? If yes please help me. As this point I wanted to know BIG IP and how it should be conected to fwsm, specially in routed mode. My understanding - 6509 (MSFC) --> outside interface of LB --> Inside interface of LB -> FWSM context (multiple context) How bigip will be able to do loadbalancing, when it is not directly connected to servers. All servers d/g is fwsm context. Regards, Vikas Sharma From Gregori.Parker at theplatform.com Thu Sep 11 14:28:40 2008 From: Gregori.Parker at theplatform.com (Gregori Parker) Date: Thu, 11 Sep 2008 11:28:40 -0700 Subject: [c-nsp] F5 BIG IP and FWSM In-Reply-To: References: Message-ID: <1A9866F953006D45AEE0166066114E09131ECC3F@TPMAIL02.corp.theplatform.com> That looks backwards...why not have the DG for internal hosts be the BigIP, and DG the BigIP to the inside of the FWSM? The BigIP does a good job of performing NAT, and doesn't need to be directly connected to the nodes in its pools...in fact, I would highly recommend against connecting nodes directly to the BigIP - you should utilize a core switch block for that and default route to a floating internal ip on the BigIP, from there, upstream to the FWSM and let it handle security out front. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Vikas Sharma Sent: Thursday, September 11, 2008 11:08 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] F5 BIG IP and FWSM Hi, Did any one have worked on F5 BIG IP and FWSM? If yes please help me. As this point I wanted to know BIG IP and how it should be conected to fwsm, specially in routed mode. My understanding - 6509 (MSFC) --> outside interface of LB --> Inside interface of LB -> FWSM context (multiple context) How bigip will be able to do loadbalancing, when it is not directly connected to servers. All servers d/g is fwsm context. Regards, Vikas Sharma _______________________________________________ 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 jloiacon at csc.com Thu Sep 11 14:41:52 2008 From: jloiacon at csc.com (Joe Loiacono) Date: Thu, 11 Sep 2008 14:41:52 -0400 Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: Message-ID: I wonder if it is not something in the config, rather than the traffic. I collect netflow from an old 6509 with upwards of 800M out one interface and I haven't seen any problems.Using if-full too. Granted a lot of our flows are data set transfers though. (I can't get the IOS version right now as it is managed by a different group - but it is probably fairly vanilla.) The number of flows was mentioned, is there alot of VoIP going through your switch, or something like that? What happens if you reduce the aging values? The 'long' one looks high. It just seems that with the load you are quoting, you should be able to get everything... Joe Jon Lewis Sent by: cisco-nsp-bounces at puck.nether.net 09/11/2008 01:52 PM To Phil Mayers cc cisco-nsp at puck.nether.net Subject Re: [c-nsp] 6500 netflow export and the switch cpu On Thu, 11 Sep 2008, Phil Mayers wrote: >> current ip flowmask for unicast: if-full >> current ipv6 flowmask for unicast: null > > Do you need the full mask? It includes tcp/udp ports. Dropping to > destination-source may save you a lot of flows (but obviously lose you a lot > of info) I'd really like to keep ip-full. It's quite handy when tracking down what an IP has been up to (like when trying to verify infection/scanning complaints). ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ From paul at paulstewart.org Thu Sep 11 15:10:33 2008 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 11 Sep 2008 15:10:33 -0400 Subject: [c-nsp] IPv6 Subnetting - Service Provider Message-ID: <004401c91442$1170c510$34524f30$@org> Hi there... In a SP environment, what's common practice so far with subnetting? Typically, in IPv4 today we use a /30 or /29 for point to point and each device has a /32 loopback... I've been reading a lot of different opinions and everyone seems to recommend a /64 for each link (router) or a server - why so large? I'd love to see a layout of a few routers in a SP core network and how they've subnetted them....;) Appreciate it, Paul From rodunn at cisco.com Thu Sep 11 15:25:49 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Thu, 11 Sep 2008 15:25:49 -0400 Subject: [c-nsp] 12.4(20)T packet capture feature example Message-ID: <20080911192549.GT23118@rtp-cse-489.cisco.com> I showed a troubleshooting example on the support wiki: http://supportwiki.cisco.com/wiki/index.php/Tech_Insights:Utilizing_the_New_Packet_Capture_Feature If you want the capture in the punt path for process level you set the capture point to: monitor capture point ip process-switched .... Rodney From mohacsi at niif.hu Thu Sep 11 15:36:54 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 11 Sep 2008 21:36:54 +0200 (CEST) Subject: [c-nsp] IPv6 Subnetting - Service Provider In-Reply-To: <004401c91442$1170c510$34524f30$@org> References: <004401c91442$1170c510$34524f30$@org> Message-ID: On Thu, 11 Sep 2008, Paul Stewart wrote: > Hi there... > > In a SP environment, what's common practice so far with subnetting? > Typically, in IPv4 today we use a /30 or /29 for point to point and each > device has a /32 loopback... > > I've been reading a lot of different opinions and everyone seems to > recommend a /64 for each link (router) or a server - why so large? I'd love > to see a layout of a few routers in a SP core network and how they've > subnetted them....;) - /64 if you have any chance that you want to use autoconfiguration (may be in the future) - for subnets containing lots of computers I definitiely would go for /64 - /126 you got similar to /30 - /122 in between /64 and /126 - with nice : boundary - or nothing if you are satisfied by link locals - OSPFv3, IS-IS can work without global IPv6 address (even BGP can work on Cisco) Regards, Janos Mohacsi > > > Appreciate it, > > Paul > > > _______________________________________________ > 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 streiner at cluebyfour.org Thu Sep 11 16:05:17 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 11 Sep 2008 16:05:17 -0400 (EDT) Subject: [c-nsp] IPv6 Subnetting - Service Provider In-Reply-To: <004401c91442$1170c510$34524f30$@org> References: <004401c91442$1170c510$34524f30$@org> Message-ID: On Thu, 11 Sep 2008, Paul Stewart wrote: > In a SP environment, what's common practice so far with subnetting? > Typically, in IPv4 today we use a /30 or /29 for point to point and each > device has a /32 loopback... > > I've been reading a lot of different opinions and everyone seems to > recommend a /64 for each link (router) or a server - why so large? I'd love > to see a layout of a few routers in a SP core network and how they've > subnetted them....;) This debate rolled on NANOG a few weeks ago. People generally broke into two camps - one advocated using /64s on point-to-point links, and the other advocated smaller subnets such as /126 for point-to-points and /128s for loopbacks. So, I guess the consensus is that there isn't one :) jms From paul at paulstewart.org Thu Sep 11 16:11:20 2008 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 11 Sep 2008 16:11:20 -0400 Subject: [c-nsp] IPv6 Subnetting - Service Provider In-Reply-To: References: <004401c91442$1170c510$34524f30$@org> Message-ID: <004501c9144a$8e4d0f00$aae72d00$@org> Thanks for the replies... Yeah, I'm getting various pieces of feedback - I'm going with the /126 for point to point and /128 for loopback on core devices at this point. I don't trust the autoconfiguration ideas at this point (call it old school) anyways...;) Paul -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Justin M. Streiner Sent: Thursday, September 11, 2008 4:05 PM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] IPv6 Subnetting - Service Provider On Thu, 11 Sep 2008, Paul Stewart wrote: > In a SP environment, what's common practice so far with subnetting? > Typically, in IPv4 today we use a /30 or /29 for point to point and each > device has a /32 loopback... > > I've been reading a lot of different opinions and everyone seems to > recommend a /64 for each link (router) or a server - why so large? I'd love > to see a layout of a few routers in a SP core network and how they've > subnetted them....;) This debate rolled on NANOG a few weeks ago. People generally broke into two camps - one advocated using /64s on point-to-point links, and the other advocated smaller subnets such as /126 for point-to-points and /128s for loopbacks. So, I guess the consensus is that there isn't one :) 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/ From rsnyder at toontown.erial.nj.us Thu Sep 11 16:27:27 2008 From: rsnyder at toontown.erial.nj.us (Bob Snyder) Date: Thu, 11 Sep 2008 16:27:27 -0400 Subject: [c-nsp] IPv6 Subnetting - Service Provider In-Reply-To: <004501c9144a$8e4d0f00$aae72d00$@org> References: <004401c91442$1170c510$34524f30$@org> <004501c9144a$8e4d0f00$aae72d00$@org> Message-ID: <20080911202727.GA9212@toontown.erial.nj.us> On Thu, Sep 11, 2008 at 04:11:20PM -0400, Paul Stewart wrote: > Thanks for the replies... > > Yeah, I'm getting various pieces of feedback - I'm going with the /126 for > point to point and /128 for loopback on core devices at this point. I don't > trust the autoconfiguration ideas at this point (call it old school) > anyways...;) One issue we ran into was that not all the networking gear we had could support /126. The vendor's (not Cisco) immature support for IPv6 could only understand the concept of /128 loopbacks and /64 subnets. Device in question was a CMTS. Bob From paul at paulstewart.org Thu Sep 11 16:39:54 2008 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 11 Sep 2008 16:39:54 -0400 Subject: [c-nsp] IPv6 Subnetting - Service Provider In-Reply-To: <20080911202727.GA9212@toontown.erial.nj.us> References: <004401c91442$1170c510$34524f30$@org> <004501c9144a$8e4d0f00$aae72d00$@org> <20080911202727.GA9212@toontown.erial.nj.us> Message-ID: <004a01c9144e$8c30c1e0$a49245a0$@org> Thanks .. so far we've only ventured into 7600/6500 core equipment but we do have CMTS to look at in the future .... ;) -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Bob Snyder Sent: Thursday, September 11, 2008 4:27 PM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] IPv6 Subnetting - Service Provider On Thu, Sep 11, 2008 at 04:11:20PM -0400, Paul Stewart wrote: > Thanks for the replies... > > Yeah, I'm getting various pieces of feedback - I'm going with the /126 for > point to point and /128 for loopback on core devices at this point. I don't > trust the autoconfiguration ideas at this point (call it old school) > anyways...;) One issue we ran into was that not all the networking gear we had could support /126. The vendor's (not Cisco) immature support for IPv6 could only understand the concept of /128 loopbacks and /64 subnets. Device in question was a CMTS. 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 christian at broknrobot.com Thu Sep 11 16:43:16 2008 From: christian at broknrobot.com (Christian Koch) Date: Thu, 11 Sep 2008 16:43:16 -0400 Subject: [c-nsp] Setting the Remote Syslog Port in IOS In-Reply-To: <48C91F9B.90606@justinshore.com> References: <48C82646.7040402@forthnet.gr> <48C91F9B.90606@justinshore.com> Message-ID: hmm interesting darn, im out of luck i dont have it on on my 12ks running 12.0(32)SY4 i do have it on a rsp720/7600 runnng 12.2(33)SRB2 dont have it on sup720/7600 runnin SX7 either just not enough boxes have it, to do what i want i guess.. christian On Thu, Sep 11, 2008 at 9:39 AM, Justin Shore wrote: > I have it on a 7206VXR running 12.4(15)T2. > > 7206-1.clr(config)#logging host ? > Hostname or A.B.C.D IP address of the syslog server > ipv6 Configure IPv6 syslog server > > 7206-1.clr(config)#logging host 1.2.3.4 ? > discriminator Specify a message discriminator indentifier for this > logging session > filtered Enable filtered logging > sequence-num-session Include session sequence number tag in syslog message > session-id Specify syslog message session ID tagging > transport Specify the transport protocol (default=UDP) > vrf Set VRF option > xml Enable logging in XML > > > 7206-1.clr(config)#logging host 1.2.3.4 tr > 7206-1.clr(config)#logging host 1.2.3.4 transport ? > beep Blocks Extensible Exchange Protocol > tcp Transport Control Protocol > udp User Datagram Protocol > > 7206-1.clr(config)#logging host 1.2.3.4 transport udp ? > discriminator Specify a message discriminator indentifier for this > logging session > filtered Enable filtered logging > port Specify the UDP port number (default=514) > sequence-num-session Include session sequence number tag in syslog message > session-id Specify syslog message session ID tagging > xml Enable logging in XML > > > 7206-1.clr(config)#logging host 1.2.3.4 transport udp port ? > <1-65535> Port number > > > I also see the command on a 3660 running 12.3(14)T7. I have it on a 3560E > running 12.2(44)SE2 but not on a 3750 running 12.2(25)SEB. I do however > have it on a 3560G and a basic 3560 running 12.2(44)SE2. I also have it on > a Sup720-3BXL in a 7600 running SRB1. > > Looks like it's available for the older platforms with the right IOS. > > Justin > > Christian Koch wrote: >> >> checked for any switches after the inputting the ip address on logging >> host command but nothing was available >> >> >> #logging host 1.1.1.1 transport ? >> % Unrecognized command >> >> >> On Wed, Sep 10, 2008 at 3:55 PM, Tassos Chatzithomaoglou >> wrote: >>> >>> Have you tried "logging host XXX transport udp port Y"? >>> >>> -- >>> Tassos >>> >>> Christian Koch wrote on 10/09/2008 19:41: >>>> >>>> I know i can set the remote syslog port on ASA/PIX's, but i don't seem >>>> to see that it is possible in IOS. >>>> >>>> I wanted to segregate logs by sending them from certain devices to >>>> separate syslog ports >>>> >>>> Can anyone confirm this behavior? >>>> >>>> Has anyone had the need to do something similar? >>>> >>>> Thanks >>>> >>>> >>>> Christian >>>> _______________________________________________ >>>> 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 sethm at rollernet.us Thu Sep 11 17:21:22 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 11 Sep 2008 14:21:22 -0700 Subject: [c-nsp] IPv6 Subnetting - Service Provider In-Reply-To: <004401c91442$1170c510$34524f30$@org> References: <004401c91442$1170c510$34524f30$@org> Message-ID: <48C98BD2.9010800@rollernet.us> Paul Stewart wrote: > Hi there... > > In a SP environment, what's common practice so far with subnetting? > Typically, in IPv4 today we use a /30 or /29 for point to point and each > device has a /32 loopback... > > I've been reading a lot of different opinions and everyone seems to > recommend a /64 for each link (router) or a server - why so large? I'd love > to see a layout of a few routers in a SP core network and how they've > subnetted them....;) > I just ran into an issue in my network (testing a 3750) where an IPv6 ACL only accepts down to a /64 for matching and only EUI-64 hosts. And there's my 877W I've mentioned a few times this week that has its own exciting quirks. Other than that, I use /64 for subnets and /128 loopbacks out of a /64 reserved for loopbacks. Using /64 and /128 is almost guaranteed to be safe at this early stage; plenty of IPv6 support just isn't that mature yet. There's an RFC or something out there (too lazy to look it up) that says use /64 for subnets, so it's the magic number for a lot of IPv6 implementations. ~Seth From A.L.M.Buxey at lboro.ac.uk Thu Sep 11 17:29:55 2008 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Thu, 11 Sep 2008 22:29:55 +0100 Subject: [c-nsp] IPv6 Subnetting - Service Provider In-Reply-To: <48C98BD2.9010800@rollernet.us> References: <004401c91442$1170c510$34524f30$@org> <48C98BD2.9010800@rollernet.us> Message-ID: <20080911212955.GA2486@lboro.ac.uk> Hi, > yet. There's an RFC or something out there (too lazy to look it up) that > says use /64 for subnets, so it's the magic number for a lot of IPv6 > implementations. my initial (and, i guess, current) IPv6 deployment plan was based on /64 subnets. yes, thats a ridiculous amount of hosts per subnet...nasty software coded in 'the old style' might make these very big collision domains and i do worry about how ISC DHCPv6 will handle such large numbers of leases - recalling how it deals with /16's in IPv4 land. however, for router likn-link, non IP-based routing protocols - as mentioned IS-IS or OSPFv3 on the link-layer avoids the legacy issue (and wasting /64's for such trivialities) alan From max.reid at saikonetworks.com Thu Sep 11 18:06:18 2008 From: max.reid at saikonetworks.com (Max Reid) Date: Thu, 11 Sep 2008 15:06:18 -0700 (PDT) Subject: [c-nsp] F5 BIG IP and FWSM In-Reply-To: <1A9866F953006D45AEE0166066114E09131ECC3F@TPMAIL02.corp.theplatform.co m> References: <1A9866F953006D45AEE0166066114E09131ECC3F@TPMAIL02.corp.theplatform.com> Message-ID: <38521.64.122.164.5.1221170778.squirrel@webmail-devel.integra.net> > That looks backwards...why not have the DG for internal hosts be the > BigIP, and DG the BigIP to the inside of the FWSM? > > The BigIP does a good job of performing NAT, and doesn't need to be > directly connected to the nodes in its pools...in fact, I would highly > recommend against connecting nodes directly to the BigIP - you should > utilize a core switch block for that and default route to a floating > internal ip on the BigIP, from there, upstream to the FWSM and let it > handle security out front. I concur with this advice, esp. the note about having an L3 connected network between the back end hosts and the 'Inside' interface of the big IP. Main Benefit is failover (no arp issues on clients or F5); when dealing with large load balanced farms. ~Max > > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Vikas Sharma > Sent: Thursday, September 11, 2008 11:08 AM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] F5 BIG IP and FWSM > > Hi, > > Did any one have worked on F5 BIG IP and FWSM? If yes please help me. As > this point I wanted to know BIG IP and how it should be conected to > fwsm, > specially in routed mode. > > My understanding - > > 6509 (MSFC) --> outside interface of LB --> Inside interface of LB -> > FWSM > context (multiple context) > > How bigip will be able to do loadbalancing, when it is not directly > connected to servers. All servers d/g is fwsm context. > > Regards, > Vikas Sharma > _______________________________________________ > 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 daltons at panix.com Thu Sep 11 18:26:22 2008 From: daltons at panix.com (dalton) Date: Thu, 11 Sep 2008 18:26:22 -0400 (EDT) Subject: [c-nsp] site to site and remote access on pix 506e Message-ID: <54756.66.27.68.33.1221171982.squirrel@mail.panix.com> Hi, I'm wondering if anyone has a working config for a pix 506e running 6.3 or so, to do both site to site and remote access vpn. I assume this is possible? I have a pix running a few site to sites, however when i added the remote access config, it caused the tunnels to fail leaving them in a state of Xauth config or something of the like (don't have the exact error). Things fail when I add these 2 lines to the crypto map crypto map toCLIENT client configuration address initiate crypto map toCLIENT client authentication LOCAL config is below, thanks. -dalton PIX Version 6.3(4) interface ethernet0 auto interface ethernet1 auto nameif ethernet0 outside security0 nameif ethernet1 inside security100 hostname client-pix domain-name client.logicworks.net 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 no fixup protocol sip 5060 no fixup protocol sip udp 5060 fixup protocol skinny 2000 fixup protocol smtp 25 fixup protocol sqlnet 1521 fixup protocol tftp 69 names access-list toCLIENT permit ip host 10.10.1.49 host 205.200.125.1 access-list toCLIENT permit ip host 10.10.1.49 host 205.200.125.2 access-list toCLIENT permit ip host 10.10.1.60 host 205.200.125.1 access-list toCLIENT permit ip host 10.10.1.60 host 205.200.125.2 access-list toCLIENT permit ip host 10.10.1.51 host 205.200.125.1 access-list toCLIENT permit ip host 10.10.1.51 host 205.200.125.2 access-list DENY-NAT permit ip 10.10.1.0 255.255.255.0 10.177.187.0 255.255.255.0 access-list DENY-NAT permit ip host 10.10.1.49 host 205.200.125.1 access-list DENY-NAT permit ip host 10.10.1.49 host 205.200.125.2 access-list DENY-NAT permit ip host 10.10.1.60 host 205.200.125.1 access-list DENY-NAT permit ip host 10.10.1.60 host 205.200.125.2 access-list DENY-NAT permit ip host 10.10.1.51 host 205.200.125.1 access-list DENY-NAT permit ip host 10.10.1.51 host 205.200.125.2 access-list DENY-NAT permit ip 10.10.1.0 255.255.255.0 10.254.10.0 255.255.255.0 access-list splittunnelACL permit ip 10.10.1.0 255.255.255.0 10.254.10.0 255.255.255.0 pager lines 24 logging on logging timestamp logging standby logging console alerts logging monitor alerts logging buffered debugging logging history alerts mtu outside 1500 mtu inside 1500 ip audit info action alarm ip audit attack action alarm ip local pool REMOTEPOOL 10.254.10.10-10.254.10.20 mask 255.255.255.0 pdm history enable arp timeout 14400 nat (inside) 0 access-list DENY-NAT conduit permit ip any any 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 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 no snmp-server location no snmp-server contact no snmp-server enable traps floodguard enable sysopt connection permit-ipsec crypto ipsec transform-set strong esp-3des esp-sha-hmac crypto ipsec transform-set mytrans esp-aes esp-sha-hmac crypto dynamic-map dynmap 10 set transform-set mytrans crypto map toCLIENT 20 ipsec-isakmp crypto map toCLIENT 20 match address toCLIENT crypto map toCLIENT 20 set peer x.x.x.x crypto map toCLIENT 20 set transform-set strong crypto map toCLIENT 999 ipsec-isakmp dynamic dynmap crypto map toCLIENT client configuration address initiate crypto map toCLIENT client authentication LOCAL crypto map toCLIENT interface outside isakmp enable outside isakmp key ******** address x.x.x.x netmask 255.255.255.255 isakmp identity address isakmp policy 8 authentication pre-share isakmp policy 8 encryption 3des isakmp policy 8 hash sha isakmp policy 8 group 2 isakmp policy 8 lifetime 86400 vpngroup client address-pool REMOTEPOOL vpngroup client dns-server x.x.x.x vpngroup client default-domain client.logicworks.net vpngroup client split-tunnel splittunnelACL vpngroup client split-dns logicworks.net vpngroup client idle-time 3600 vpngroup client password ******** vpngroup idle-time idle-time 1800 From mksmith at adhost.com Thu Sep 11 18:43:26 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 11 Sep 2008 15:43:26 -0700 Subject: [c-nsp] site to site and remote access on pix 506e In-Reply-To: <54756.66.27.68.33.1221171982.squirrel@mail.panix.com> References: <54756.66.27.68.33.1221171982.squirrel@mail.panix.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031604A63F5B@ad-exh01.adhost.lan> Hello Dalton: Here are a couple of ideas. 1) Change: isakmp key ******** address x.x.x.x netmask 255.255.255.255 to isakmp key ******** address x.x.x.x netmask 255.255.255.255 no-xauth no-config-mode 2) You might want to add: isakmp nat-traversal 20 3) I'm assuming you have a LOCAL username specified? Regards, Mike > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of dalton > Sent: Thursday, September 11, 2008 3:26 PM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] site to site and remote access on pix 506e > > > Hi, > > I'm wondering if anyone has a working config for a pix 506e running 6.3 or > so, to do both site to site > and remote access vpn. I assume this is possible? > > I have a pix running a few site to sites, however when i added the remote > access config, it caused > the tunnels to fail leaving them in a state of Xauth config or something > of the like (don't have the exact error). > > Things fail when I add these 2 lines to the crypto map > > crypto map toCLIENT client configuration address initiate > crypto map toCLIENT client authentication LOCAL > > > config is below, thanks. > > -dalton > > PIX Version 6.3(4) > interface ethernet0 auto > interface ethernet1 auto > nameif ethernet0 outside security0 > nameif ethernet1 inside security100 > hostname client-pix > domain-name client.logicworks.net > 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 > no fixup protocol sip 5060 > no fixup protocol sip udp 5060 > fixup protocol skinny 2000 > fixup protocol smtp 25 > fixup protocol sqlnet 1521 > fixup protocol tftp 69 > names > access-list toCLIENT permit ip host 10.10.1.49 host 205.200.125.1 > access-list toCLIENT permit ip host 10.10.1.49 host 205.200.125.2 > access-list toCLIENT permit ip host 10.10.1.60 host 205.200.125.1 > access-list toCLIENT permit ip host 10.10.1.60 host 205.200.125.2 > access-list toCLIENT permit ip host 10.10.1.51 host 205.200.125.1 > access-list toCLIENT permit ip host 10.10.1.51 host 205.200.125.2 > access-list DENY-NAT permit ip 10.10.1.0 255.255.255.0 10.177.187.0 > 255.255.255.0 > access-list DENY-NAT permit ip host 10.10.1.49 host 205.200.125.1 > access-list DENY-NAT permit ip host 10.10.1.49 host 205.200.125.2 > access-list DENY-NAT permit ip host 10.10.1.60 host 205.200.125.1 > access-list DENY-NAT permit ip host 10.10.1.60 host 205.200.125.2 > access-list DENY-NAT permit ip host 10.10.1.51 host 205.200.125.1 > access-list DENY-NAT permit ip host 10.10.1.51 host 205.200.125.2 > access-list DENY-NAT permit ip 10.10.1.0 255.255.255.0 10.254.10.0 > 255.255.255.0 > access-list splittunnelACL permit ip 10.10.1.0 255.255.255.0 10.254.10.0 > 255.255.255.0 > pager lines 24 > logging on > logging timestamp > logging standby > logging console alerts > logging monitor alerts > logging buffered debugging > logging history alerts > mtu outside 1500 > mtu inside 1500 > ip audit info action alarm > ip audit attack action alarm > ip local pool REMOTEPOOL 10.254.10.10-10.254.10.20 mask 255.255.255.0 > pdm history enable > arp timeout 14400 > nat (inside) 0 access-list DENY-NAT > conduit permit ip any any > 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 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 > no snmp-server location > no snmp-server contact > no snmp-server enable traps > floodguard enable > sysopt connection permit-ipsec > crypto ipsec transform-set strong esp-3des esp-sha-hmac > crypto ipsec transform-set mytrans esp-aes esp-sha-hmac > crypto dynamic-map dynmap 10 set transform-set mytrans > crypto map toCLIENT 20 ipsec-isakmp > crypto map toCLIENT 20 match address toCLIENT > crypto map toCLIENT 20 set peer x.x.x.x > crypto map toCLIENT 20 set transform-set strong > crypto map toCLIENT 999 ipsec-isakmp dynamic dynmap > crypto map toCLIENT client configuration address initiate > crypto map toCLIENT client authentication LOCAL > crypto map toCLIENT interface outside > isakmp enable outside > isakmp key ******** address x.x.x.x netmask 255.255.255.255 > isakmp identity address > isakmp policy 8 authentication pre-share > isakmp policy 8 encryption 3des > isakmp policy 8 hash sha > isakmp policy 8 group 2 > isakmp policy 8 lifetime 86400 > vpngroup client address-pool REMOTEPOOL > vpngroup client dns-server x.x.x.x > vpngroup client default-domain client.logicworks.net > vpngroup client split-tunnel splittunnelACL > vpngroup client split-dns logicworks.net > vpngroup client idle-time 3600 > vpngroup client password ******** > vpngroup idle-time idle-time 1800 > > > _______________________________________________ > 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 474 bytes Desc: not available URL: From andy.saykao at staff.netspace.net.au Thu Sep 11 18:48:15 2008 From: andy.saykao at staff.netspace.net.au (Andy Saykao) Date: Fri, 12 Sep 2008 08:48:15 +1000 Subject: [c-nsp] Inter VRF Routing help needed Message-ID: <56F211C5E3F24F47B103EA1B253822BE036548D4@vic-cr-ex1.staff.netspace.net.au> Hi cc loo - It took me a while to understand the difference between RD and RT's too. Most literature will have examples of where the RD and RT are exactly the same and you can't help but be confused when you see them being different and you'll start to ask yourself "what's the point of having this RT statement when it's identicle to the RD - seems like a waste of time". But they do play a very important role when you start moving away from simple VRF design. What's most important to remember is that the RD and RT can be the same or can be totally different and that they both serve completely different purposes. Generally, in a very simple VRF set up (eg: one customer with 3 sites all being able to talk with each other and exchange data), the RD and RT will be the same because you probably won't be leaking routes between VRF's because this isn't a requirement. The RD is basically a way to allow overlapping IP addresses to exist. If we take the example of vrf_customer_A (RD 1:1) and vrf_customer_B (RD 1:2) - both can choose to use 192.168.1.0/24 and the address space will be completely unique because the RD is combined with the IPv4 address to produce the VPNv4 address like so - RD:192.168.1.1. The RT on the other hand is a BGP extended-community attribute that is also tagged onto the VPNv4 address to allow you to be able to import/export these routes to other VRF's. ip vrf customer_A rd 1:1 route-target export 1:100 route-target import 1:900 ! ip vrf customer_B rd 1:2 route-target export 1:200 route-target import 1:900 ! ip vrf Hub rd 1:9 route-target export 1:900 route-target import 1:100 route-target import 1:200 So in Oli's example, a host of vrf_customer_A might have a VPNv4 addresses of 1:1:192.168.1.1 and RT 1:100. Likewise a host of vrf_customer_B might have the VPNv4 address of 1:2:192.168.2.1 and RT 1:200. The routes with the corresponding RT's of 1:100 (vrf_customer_A) and 1:200 (vrf_customer_B) are imported by the Hub and so the Hub will end up with the routes of 192.168.1.1 and 192.168.2.1 in it's own routing table and will be able to reach these two hosts eventhough they are in different VRF's. Similarly, vrf_customer_A and vrf_customer_B need to import the RT that the Hub is exporting (1:900) so they too can reach the Hub. I've deliberately used different IP space for customer_A and customer_B. Just be careful if you plan to import/export route's between different VRF's because you'll need to make sure the routes are unique in this case. Imagine if customer_A and customer_B were both using 192.168.1.0/24. How would the Hub be able to distinguish if it should be sending to customer_A or customer_B - hence why you need to do some planning so as not to run into this problem. Sorry if it was a bit long winded. I'm new to all this too ;) Cheers. Andy cc loo wrote on Thursday, September 11, 2008 5:05 PM: > Hi Oliver, > > Thanks for the quick reply. > > Indeed i was referring to VRF-LITE > > In the cisco.com example, they gave this Router(config)# ip vrf > customer_a > Router(config-vrf)# rd 1:1 <---- > Router(config-vrf)# route-target both 1:1 <---- Router(config)# > interface fastEthernet 0.1 Router(config-subif)# ip vrf forwarding > customer_a > > is there any specific reason why cisco recommends using "both" > (export/import) for its own RD ? the RD is not exported, the RT is. see answer to next question. Well, the "import" is not really needed in this specific case as there is no other VRF exporting routes with this route-target (so no point importing it). > > Oliver's example is here, but i would like to confirm if 1:100 is a > typo or should it be 1:1 (like its own RD?): ip vrf customer_A > rd 1:1 <----- > route-target export 1:100 <---- > route-target import 1:900 RD and route-target are different things. They can be the same, but they must not be (in an mpls-vpn, they usually aren't the same as the RD is unique per PE per VRF). > I wonder wondering if this is the correct place to post newbie > questions like these ? > Im a junior engineer in a singaporean isp, hoping to learn more tricks > and tips in the field of IP planning :D well, I guess it's like all lists where folks help each other: If people see that you haven't done your homework, you might not get a reply. oli ------------------------------ _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp End of cisco-nsp Digest, Vol 70, Issue 57 ***************************************** ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ 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 jlewis at lewis.org Thu Sep 11 19:01:38 2008 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 11 Sep 2008 19:01:38 -0400 (EDT) Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: References: <48C94727.4030002@imperial.ac.uk> Message-ID: On Thu, 11 Sep 2008, Jon Lewis wrote: > On Thu, 11 Sep 2008, Phil Mayers wrote: > >> What do the following say: >> >> sh mls netflow table-contention detailed > > Earl in Module 5 > Detailed Netflow CAM (TCAM and ICAM) Utilization > ================================================ > TCAM Utilization : 100% > ICAM Utilization : 7% > Netflow TCAM count : 262026 > Netflow ICAM count : 10 > Netflow Creation Failures : 456680 > Netflow CAM aliases : 0 > > I guess I need to get more aggressive on the flow aging. I've been using > mls aging fast time 8 threshold 3 > mls aging long 480 > mls aging normal 32 It looks like the fix was to enable flow-sampling. mls sampling time-based 64 has our cpu usage back down to about nothing and tcam usage down around 50%. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rootnet08 at gmail.com Thu Sep 11 20:54:45 2008 From: rootnet08 at gmail.com (root net) Date: Thu, 11 Sep 2008 19:54:45 -0500 Subject: [c-nsp] Check bandwidth on router Message-ID: <89944ef40809111754s49466f26w38d25fc90df0b4f5@mail.gmail.com> Hi List, Is there some sort of tool you can load into the IOS on a router to check bandwidth? Or if not what are you all doing these days in this situation. Like for example things are running slow and you think the Internet feed may be the problem is there a way to do speed tests on the router itself? rootnet From ben.steele at internode.on.net Thu Sep 11 20:56:00 2008 From: ben.steele at internode.on.net (Ben Steele) Date: Fri, 12 Sep 2008 10:26:00 +0930 Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: References: <48C94727.4030002@imperial.ac.uk> Message-ID: <001b01c91472$5398cd40$faca67c0$@steele@internode.on.net> "It looks like the fix was to enable flow-sampling." Out of curiosity what are you using your netflow for? I'm asking because sampling obviously isn't ideal when you are trying to get completely accurate data for accounting. I am interested in hearing people's opinion on their methods of accounting when data hits well beyond the TCAM limit(and you're already on DFC's) and you are in an all Ethernet switched world (ie not broadband ppp radius accounting), do you try and distribute the netflow onto multiple boxes closer to the edge or do you opt for another method? There is the easy option of byte counting switchports via snmp, but if people are wanting statistics of who's been where(possible legal reasons) or where the majority of traffic is coming from then that is not enough, maybe a mix of sampled netflow and switchport byte counting? It feels a shame using DFC's for a margin of their capacity purely because you need the TCAM space to produce netflow. Ben From sforcejr at yahoo.com Thu Sep 11 21:47:23 2008 From: sforcejr at yahoo.com (John Ramz) Date: Thu, 11 Sep 2008 18:47:23 -0700 (PDT) Subject: [c-nsp] Datacenter Network Design In-Reply-To: Message-ID: <384477.9224.qm@web110414.mail.gq1.yahoo.com> Thanks guys for your replies. I sure have a lot to chew on. I am sure I will post back more questions once I get into it John --- On Thu, 9/11/08, Phil Bedard wrote: > From: Phil Bedard > Subject: Re: [c-nsp] Datacenter Network Design > To: "Brant I. Stevens" > Cc: "root net" , sforcejr at yahoo.com, cisco-nsp at puck.nether.net > Date: Thursday, September 11, 2008, 9:39 AM > This is a good guide from Cisco. > > http://www.cisco.com/univercd/cc/td/doc/solution/dcidg21.pdf > > Phil > > > On Sep 11, 2008, at 9:00 AM, Brant I. Stevens wrote: > > > The Solutions Reference Network Design page on > Cisco's site is a good > > resource for network designs. > http://www.cisco.com/go/srnd > > > > -Brant > > > > On 9/11/08 3:15 AM, "root net" > wrote: > > > >> John, > >> > >> If you are going to build a Cisco network you > should spend some > >> time on > >> www.cisco.com and look at all of their > configuration examples and > >> whitepapers for specific gear you are looking at > or working on. > >> Here are > >> some books I would suggest: > >> > >> Cisco Press: > >> Data Center Fundamentals > >> End-to-End QoS Network Design > >> Designing for Cisco Internetwork Solutions > >> Designing Cisco Network Architectures > >> Network Management Fundamentals > >> > >> www.cisco.com: (Research) > >> > >> HSRP > >> STP > >> InterVLAN routing > >> IEEE Bridging > >> BGP > >> OSPF > >> L2TPV3 > >> MPLS / VPN > >> IOS information > >> > >> Others: > >> Administering Data Centers > >> > >> APC Data Center University (online classes) Some > are FREE some are > >> not. > >> > >> This is all I could think of since it's so > late. DR will come when > >> you > >> start digging into the protocols and other > information. Far as > >> storage/backup iSCSI is your friend so build a GbE > network. > >> OpenFiler, > >> NetApp, MyIVault. > >> > >>> From the start your facility will need to > handle your immediate > >>> needs and > >> growth or at least have the ability to scale (I > would say maybe > >> 10-20% > >> growth for small budgets). Look at evironmentals, > power, fire > >> protection: > >> HVAC (spot coolers vs. ductless split systems vs. > ducted systems, > >> chilled > >> water vs. air cooled), Power Requirements (Single > Phase, Three > >> Phase 208V > >> /480V, UPS, Transfer switches, portable > generators, generator), > >> Raised > >> Flooring vs. Anti-Static VCT, Security monitoring, > water monitoring, > >> temperature monitoring, and lastly Pre-action vs. > plain wet system. > >> > >> Getting a seperate Internet feed would be wise > unless it's just cost > >> prohibitive. Start out with maybe 10Mbit pipe and > go from there. > >> This all > >> depends your customer's applications and > servers. What they will be > >> transfering and etc. > >> > >> Look into open source products as these are FREE > and can help you. > >> (e.g. > >> nagios, jffnms, cacti, mrtg, syslog, linux, RT, > rancid, and others) > >> > >> Rule of thumb: A good data center will have > proactive measures and > >> policies > >> in place to monitor, maintain, and procure. With > that said monitor > >> everything (I mean everything) and have all staff > alerted on all > >> levels SMS, > >> e-mail, phone if possible automatically. It's > not about downtime > >> so much > >> it's how you procure the situation in a > specific time frame. > >> Customer > >> serivce is a must. > >> > >> You will need to make the call on the gear you use > but I use a > >> mixture of > >> Cisco, Extreme, and Juniper. For data centers > it's a must for hot > >> swappable > >> gear so look in to carrier class gear with > redundant process, power > >> supplies, hot swappable line cards. I would > recommend Cisco 6500 > >> Series, > >> Cisco 7200 Series, Cisco ASA or Pix. I am not to > fond of the Juniper > >> firewall licensing. BTW, Cisco 2800/3600 Series > may even work. > >> Depends on > >> your throughput capabilities you are needing. > Research all aspects > >> of your > >> gear from ram, flash, processor speeds, to > throughput, modules, > >> IOS, and hot > >> swappable needs. > >> > >> > >> The above will get you started. > >> > >> rootnet08 > >> > >> On 9/10/08, John Ramz > wrote: > >>> > >>> We are looking into start hosting our > customers' apps and data and > >>> would > >>> like for you to provide me link to internet > resources (or books) > >>> to get me > >>> started on a network design that includes: > >>> > >>> - 3rd party Compliance (security for example) > >>> - Redundancy (routers, firewalls, switches) > >>> - load balancing > >>> - VLANS > >>> - Virtual servers > >>> - Backup- SANs- > >>> - Disaster recovery > >>> - How to keep customers separated from our > regular network? > >>> - How to keep customers totally isolated from > each other? > >>> - Access from our network to the Datacenter > network for our > >>> developers to > >>> work with our customers? Also for our IT > people to service, > >>> monitor and > >>> maintain that network > >> > >> I have thought of getting an Internet pipe just > for the Datacenter > >> network > >>> and with all the above mentioned components > and then figure out > >>> the way and > >>> procedures to connect our company network with > that one for the > >>> different > >>> items I already mentioned. > >>> > >>> Has anyone been involved in a project like > that could elaborate as > >>> much as > >>> possible on the subject? > >>> > >> Please shed some light with me on where to start > and build from > >> there? > >>> > >>> 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/ > >>> > >> _______________________________________________ > >> 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 adriankok2000 at yahoo.com.hk Thu Sep 11 21:23:51 2008 From: adriankok2000 at yahoo.com.hk (adrian kok) Date: Fri, 12 Sep 2008 09:23:51 +0800 (CST) Subject: [c-nsp] console port Message-ID: <539377.98418.qm@web33306.mail.mud.yahoo.com> Hi I want to connect to the console port but my laptop is only having the USB without the com (serial port) Now i try to use the usb to serial port cable + serial to console cable to connect this console box of the router does it work? Thank you Send instant messages to your online friends http://uk.messenger.yahoo.com From danletkeman at gmail.com Thu Sep 11 21:51:34 2008 From: danletkeman at gmail.com (Dan Letkeman) Date: Thu, 11 Sep 2008 20:51:34 -0500 Subject: [c-nsp] load-sharing round robin time? Message-ID: Hello, I'm doing load-sharing on a 2621 router with ios 12.3(26). ip route 0.0.0.0 0.0.0.0 192.168.11.251 ip route 0.0.0.0 0.0.0.0 192.168.11.252 ip route 0.0.0.0 0.0.0.0 192.168.11.253 This was working just fine, but now we implemented a squid cache just behind the router and it strips the source ip, so all of the requests through the router all look like they are coming from the squid box now. What is happening now is the squid box is randomly switching from route to route, but it's taking about 10 minutes to switch from each route. So watching the graphs on the three routers and its only really using one route at a time. Is there a way to change the time limit for switching routes to make it switch faster? Thanks, Dan. From john at fluidhosting.com Thu Sep 11 22:02:48 2008 From: john at fluidhosting.com (John T. Yocum) Date: Thu, 11 Sep 2008 19:02:48 -0700 Subject: [c-nsp] console port In-Reply-To: <539377.98418.qm@web33306.mail.mud.yahoo.com> References: <539377.98418.qm@web33306.mail.mud.yahoo.com> Message-ID: <48C9CDC8.6050205@fluidhosting.com> A USB to Serial adapter will work. I've used them without any problems. --John adrian kok wrote: > Hi > > I want to connect to the console port > > but my laptop is only having the USB without the com > (serial port) > > Now i try to use the usb to serial port cable > + serial to console cable > > to connect this console box of the router > > does it work? > > Thank you > > Send instant messages to your online friends http://uk.messenger.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 david at davidcoulson.net Thu Sep 11 22:12:05 2008 From: david at davidcoulson.net (David Coulson) Date: Thu, 11 Sep 2008 22:12:05 -0400 Subject: [c-nsp] load-sharing round robin time? In-Reply-To: References: Message-ID: <48C9CFF5.8060907@davidcoulson.net> You can set it to use per-packet load balancing instead, assuming all of the paths are essentially the same (otherwise you get out of order packets, which may not be what you want). Is the squid box on the 192.168.11.x subnet? If you have ip redirects enabled, then the squid box will actually route directly to one of the gateways, rather than through the 2621... Not sure how your environment is build - Maybe a routing table and some other interface configs would help? Dan Letkeman wrote: > Hello, > > I'm doing load-sharing on a 2621 router with ios 12.3(26). > > ip route 0.0.0.0 0.0.0.0 192.168.11.251 > ip route 0.0.0.0 0.0.0.0 192.168.11.252 > ip route 0.0.0.0 0.0.0.0 192.168.11.253 > > This was working just fine, but now we implemented a squid cache just > behind the router and it strips the source ip, so all of the requests > through the router all look like they are coming from the squid box > now. What is happening now is the squid box is randomly switching > from route to route, but it's taking about 10 minutes to switch from > each route. So watching the graphs on the three routers and its only > really using one route at a time. Is there a way to change the time > limit for switching routes to make it switch faster? > > Thanks, > Dan. > _______________________________________________ > 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 adriankok2000 at yahoo.com.hk Thu Sep 11 21:16:34 2008 From: adriankok2000 at yahoo.com.hk (adrian kok) Date: Fri, 12 Sep 2008 09:16:34 +0800 (CST) Subject: [c-nsp] console port Message-ID: <454720.94740.qm@web33306.mail.mud.yahoo.com> Hi I want to connect to the console port but my laptop is only having the USB without the com (serial port) Now i try to use the usb to serial port cable + serial to console cable to connect this console box of the router does it work? Thank you Send instant messages to your online friends http://uk.messenger.yahoo.com From s00664233 at gmail.com Thu Sep 11 22:43:35 2008 From: s00664233 at gmail.com (cc loo) Date: Fri, 12 Sep 2008 10:43:35 +0800 Subject: [c-nsp] console port In-Reply-To: <539377.98418.qm@web33306.mail.mud.yahoo.com> References: <539377.98418.qm@web33306.mail.mud.yahoo.com> Message-ID: <49999c420809111943j566d0b01j30cc70959b9d8f24@mail.gmail.com> Hi Adrain, Yup im on OSX / ubuntu as well and a RS232-USB converter will work fine once you install the drivers On Fri, Sep 12, 2008 at 9:23 AM, adrian kok wrote: > Hi > > I want to connect to the console port > > but my laptop is only having the USB without the com > (serial port) > > Now i try to use the usb to serial port cable > + serial to console cable > > to connect this console box of the router > > does it work? > > Thank you > > Send instant messages to your online friends http://uk.messenger.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 s00664233 at gmail.com Thu Sep 11 22:50:15 2008 From: s00664233 at gmail.com (cc loo) Date: Fri, 12 Sep 2008 10:50:15 +0800 Subject: [c-nsp] Inter VRF Routing help needed In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE036548D4@vic-cr-ex1.staff.netspace.net.au> References: <56F211C5E3F24F47B103EA1B253822BE036548D4@vic-cr-ex1.staff.netspace.net.au> Message-ID: <49999c420809111950x2c064a67ifed632b09b0296bc@mail.gmail.com> Hi, Thanks for all the replies, i will go do more homework/reading up and practice in my work place :D On Fri, Sep 12, 2008 at 6:48 AM, Andy Saykao < andy.saykao at staff.netspace.net.au> wrote: > Hi cc loo - It took me a while to understand the difference between RD > and RT's too. > > Most literature will have examples of where the RD and RT are exactly > the same and you can't help but be confused when you see them being > different and you'll start to ask yourself "what's the point of having > this RT statement when it's identicle to the RD - seems like a waste of > time". But they do play a very important role when you start moving away > from simple VRF design. > > What's most important to remember is that the RD and RT can be the same > or can be totally different and that they both serve completely > different purposes. Generally, in a very simple VRF set up (eg: one > customer with 3 sites all being able to talk with each other and > exchange data), the RD and RT will be the same because you probably > won't be leaking routes between VRF's because this isn't a requirement. > The RD is basically a way to allow overlapping IP addresses to exist. If > we take the example of vrf_customer_A (RD 1:1) and vrf_customer_B (RD > 1:2) - both can choose to use 192.168.1.0/24 and the address space will > be completely unique because the RD is combined with the IPv4 address to > produce the VPNv4 address like so - RD:192.168.1.1. > > The RT on the other hand is a BGP extended-community attribute that is > also tagged onto the VPNv4 address to allow you to be able to > import/export these routes to other VRF's. > > ip vrf customer_A > rd 1:1 > route-target export 1:100 > route-target import 1:900 > ! > ip vrf customer_B > rd 1:2 > route-target export 1:200 > route-target import 1:900 > ! > ip vrf Hub > rd 1:9 > route-target export 1:900 > route-target import 1:100 > route-target import 1:200 > > So in Oli's example, a host of vrf_customer_A might have a VPNv4 > addresses of 1:1:192.168.1.1 and RT 1:100. Likewise a host of > vrf_customer_B might have the VPNv4 address of 1:2:192.168.2.1 and RT > 1:200. The routes with the corresponding RT's of 1:100 (vrf_customer_A) > and 1:200 (vrf_customer_B) are imported by the Hub and so the Hub will > end up with the routes of 192.168.1.1 and 192.168.2.1 in it's own > routing table and will be able to reach these two hosts eventhough they > are in different VRF's. Similarly, vrf_customer_A and vrf_customer_B > need to import the RT that the Hub is exporting (1:900) so they too can > reach the Hub. > > I've deliberately used different IP space for customer_A and customer_B. > Just be careful if you plan to import/export route's between different > VRF's because you'll need to make sure the routes are unique in this > case. Imagine if customer_A and customer_B were both using > 192.168.1.0/24. How would the Hub be able to distinguish if it should be > sending to customer_A or customer_B - hence why you need to do some > planning so as not to run into this problem. > > Sorry if it was a bit long winded. I'm new to all this too ;) > > Cheers. > > Andy > > cc loo wrote on Thursday, September 11, > 2008 5:05 PM: > > > Hi Oliver, > > > > Thanks for the quick reply. > > > > Indeed i was referring to VRF-LITE > > > > In the cisco.com example, they gave this Router(config)# ip vrf > > customer_a > > Router(config-vrf)# rd 1:1 <---- > > Router(config-vrf)# route-target both 1:1 <---- Router(config)# > > interface fastEthernet 0.1 Router(config-subif)# ip vrf forwarding > > customer_a > > > > is there any specific reason why cisco recommends using "both" > > (export/import) for its own RD ? > > the RD is not exported, the RT is. see answer to next question. > > Well, the "import" is not really needed in this specific case as there > is no other VRF exporting routes with this route-target (so no point > importing it). > > > > > Oliver's example is here, but i would like to confirm if 1:100 is a > > typo or should it be 1:1 (like its own RD?): ip vrf customer_A > > rd 1:1 <----- > > route-target export 1:100 <---- > > route-target import 1:900 > > RD and route-target are different things. They can be the same, but they > must not be (in an mpls-vpn, they usually aren't the same as the RD is > unique per PE per VRF). > > > I wonder wondering if this is the correct place to post newbie > > questions like these ? > > Im a junior engineer in a singaporean isp, hoping to learn more tricks > > > and tips in the field of IP planning :D > > well, I guess it's like all lists where folks help each other: If people > see that you haven't done your homework, you might not get a reply. > > oli > > > ------------------------------ > > _______________________________________________ > cisco-nsp mailing list > cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > > End of cisco-nsp Digest, Vol 70, Issue 57 > ***************************************** > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > 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 david at davidcoulson.net Thu Sep 11 22:54:22 2008 From: david at davidcoulson.net (David Coulson) Date: Thu, 11 Sep 2008 22:54:22 -0400 Subject: [c-nsp] console port In-Reply-To: <454720.94740.qm@web33306.mail.mud.yahoo.com> References: <454720.94740.qm@web33306.mail.mud.yahoo.com> Message-ID: <48C9D9DE.6080008@davidcoulson.net> Yep, but remember, if you move the serial port adaptor from one USB port to another, it will end up with a different COM port name - At least on Windows. adrian kok wrote: > Hi > > I want to connect to the console port > > but my laptop is only having the USB without the com > (serial port) > > Now i try to use the usb to serial port cable > + serial to console cable > > to connect this console box of the router > > does it work? > > Thank you > > Send instant messages to your online friends http://uk.messenger.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 danletkeman at gmail.com Thu Sep 11 23:18:57 2008 From: danletkeman at gmail.com (Dan Letkeman) Date: Thu, 11 Sep 2008 22:18:57 -0500 Subject: [c-nsp] load-sharing round robin time? In-Reply-To: <48C9CFF5.8060907@davidcoulson.net> References: <48C9CFF5.8060907@davidcoulson.net> Message-ID: I have tried enabling per-packet load balancing, but if I do that then no pages come up in the browser. So I did a tcp-mss adjust on the interface and still no difference. topology: lan----squid box----2621 router-------4 827 modem's(nat & adsl) Dan. On Thu, Sep 11, 2008 at 9:12 PM, David Coulson wrote: > You can set it to use per-packet load balancing instead, assuming all of the > paths are essentially the same (otherwise you get out of order packets, > which may not be what you want). > > Is the squid box on the 192.168.11.x subnet? If you have ip redirects > enabled, then the squid box will actually route directly to one of the > gateways, rather than through the 2621... Not sure how your environment is > build - Maybe a routing table and some other interface configs would help? > > Dan Letkeman wrote: >> >> Hello, >> >> I'm doing load-sharing on a 2621 router with ios 12.3(26). >> >> ip route 0.0.0.0 0.0.0.0 192.168.11.251 >> ip route 0.0.0.0 0.0.0.0 192.168.11.252 >> ip route 0.0.0.0 0.0.0.0 192.168.11.253 >> >> This was working just fine, but now we implemented a squid cache just >> behind the router and it strips the source ip, so all of the requests >> through the router all look like they are coming from the squid box >> now. What is happening now is the squid box is randomly switching >> from route to route, but it's taking about 10 minutes to switch from >> each route. So watching the graphs on the three routers and its only >> really using one route at a time. Is there a way to change the time >> limit for switching routes to make it switch faster? >> >> Thanks, >> Dan. >> _______________________________________________ >> 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 mylists at battleop.com Thu Sep 11 23:38:18 2008 From: mylists at battleop.com (Richey) Date: Thu, 11 Sep 2008 23:38:18 -0400 Subject: [c-nsp] 7206vxr npe300 throughput Message-ID: <071c01c91489$006da2f0$0148e8d0$@com> I've got a 7206VXR with an NPE 300. It does not run BGP. The majority of the traffic on this router will be is streaming media. The only ACLs on this router are there to protect the router it's self. We are talking about switching the full DS3 that is in this router out for a 100Mb FE feed. Should I worry about this router being able to handle 80 to 100mb of traffic? Richey From mtinka at globaltransit.net Fri Sep 12 00:16:02 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 12 Sep 2008 12:16:02 +0800 Subject: [c-nsp] IPv6 Subnetting - Service Provider In-Reply-To: <20080911212955.GA2486@lboro.ac.uk> References: <004401c91442$1170c510$34524f30$@org> <48C98BD2.9010800@rollernet.us> <20080911212955.GA2486@lboro.ac.uk> Message-ID: <200809121216.06089.mtinka@globaltransit.net> On Friday 12 September 2008 05:29:55 A.L.M.Buxey at lboro.ac.uk wrote: > my initial (and, i guess, current) IPv6 deployment plan > was based on /64 subnets. yes, thats a ridiculous amount > of hosts per subnet...nasty software coded in 'the old > style' might make these very big collision domains and i > do worry about how ISC DHCPv6 will handle such large > numbers of leases - recalling how it deals with /16's in > IPv4 land. As has been mentioned by some others on the list, we use: * /112 - for subnets * /126 - for point-to-points * /128 - for Loopbacks. We don't believe in using /64's for point-to-points, as some of the peering/transit we do on v6 has shown (the other party's assignment) - I simply fail to understand how many other hosts you could possibly have on a point-to-point link, between 2 routers, to warrant a /64. We are not big on /64's ability for autoconf, like someone else has mentioned. There's a certain satisfaction to be had when I go to bed knowing that the v6 address I coded onto the router/server interface will still be the same one when I wake up the following day. 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 Sep 12 00:22:19 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 12 Sep 2008 12:22:19 +0800 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <20080911130626.GC23118@rtp-cse-489.cisco.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <383357750809110529y67490054j95b48a53b56d8d1@mail.gmail.com> <20080911130626.GC23118@rtp-cse-489.cisco.com> Message-ID: <200809121222.19526.mtinka@globaltransit.net> On Thursday 11 September 2008 21:06:26 Rodney Dunn wrote: > That's wrong. > > The 7301 is basically a 1RU 72xx/G2 combo. I thought that's the 72xx/NPE-G1 combo; the 7201 would be the -G2 combo, right? 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 avayner at cisco.com Fri Sep 12 00:32:05 2008 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Fri, 12 Sep 2008 06:32:05 +0200 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <200809121222.19526.mtinka@globaltransit.net> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com><383357750809110529y67490054j95b48a53b56d8d1@mail.gmail.com><20080911130626.GC23118@rtp-cse-489.cisco.com> <200809121222.19526.mtinka@globaltransit.net> Message-ID: <67F7C1FAF83A074AA3520D8F155782A501D79780@xmb-ams-331.emea.cisco.com> Yes. The 1RU version for 7200/NPE-G1 is called 7301 Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mark Tinka Sent: Friday, September 12, 2008 07:22 AM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] NPE G1, CEF and ACLs and high CPU On Thursday 11 September 2008 21:06:26 Rodney Dunn wrote: > That's wrong. > > The 7301 is basically a 1RU 72xx/G2 combo. I thought that's the 72xx/NPE-G1 combo; the 7201 would be the -G2 combo, right? Mark. From avayner at cisco.com Fri Sep 12 00:35:31 2008 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Fri, 12 Sep 2008 06:35:31 +0200 Subject: [c-nsp] Datacenter Network Design In-Reply-To: References: <89944ef40809110015k28ea0ca7k219da9a68a02b374@mail.gmail.com> Message-ID: <67F7C1FAF83A074AA3520D8F155782A501D79781@xmb-ams-331.emea.cisco.com> Another very relevant resource (relatively new one) is: www.cisco.com/go/designzone Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Brant I. Stevens Sent: Thursday, September 11, 2008 16:00 PM To: root net; sforcejr at yahoo.com Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Datacenter Network Design The Solutions Reference Network Design page on Cisco's site is a good resource for network designs. http://www.cisco.com/go/srnd -Brant On 9/11/08 3:15 AM, "root net" wrote: > John, > > If you are going to build a Cisco network you should spend some time > on www.cisco.com and look at all of their configuration examples and > whitepapers for specific gear you are looking at or working on. Here > are some books I would suggest: > > Cisco Press: > Data Center Fundamentals > End-to-End QoS Network Design > Designing for Cisco Internetwork Solutions Designing Cisco Network > Architectures Network Management Fundamentals > > www.cisco.com: (Research) > > HSRP > STP > InterVLAN routing > IEEE Bridging > BGP > OSPF > L2TPV3 > MPLS / VPN > IOS information > > Others: > Administering Data Centers > > APC Data Center University (online classes) Some are FREE some are not. > > This is all I could think of since it's so late. DR will come when > you start digging into the protocols and other information. Far as > storage/backup iSCSI is your friend so build a GbE network. > OpenFiler, NetApp, MyIVault. > >> From the start your facility will need to handle your immediate needs >> and > growth or at least have the ability to scale (I would say maybe 10-20% > growth for small budgets). Look at evironmentals, power, fire protection: > HVAC (spot coolers vs. ductless split systems vs. ducted systems, > chilled water vs. air cooled), Power Requirements (Single Phase, Three > Phase 208V /480V, UPS, Transfer switches, portable generators, > generator), Raised Flooring vs. Anti-Static VCT, Security monitoring, > water monitoring, temperature monitoring, and lastly Pre-action vs. plain wet system. > > Getting a seperate Internet feed would be wise unless it's just cost > prohibitive. Start out with maybe 10Mbit pipe and go from there. > This all depends your customer's applications and servers. What they > will be transfering and etc. > > Look into open source products as these are FREE and can help you. (e.g. > nagios, jffnms, cacti, mrtg, syslog, linux, RT, rancid, and others) > > Rule of thumb: A good data center will have proactive measures and > policies in place to monitor, maintain, and procure. With that said > monitor everything (I mean everything) and have all staff alerted on > all levels SMS, e-mail, phone if possible automatically. It's not > about downtime so much it's how you procure the situation in a > specific time frame. Customer serivce is a must. > > You will need to make the call on the gear you use but I use a mixture > of Cisco, Extreme, and Juniper. For data centers it's a must for hot > swappable gear so look in to carrier class gear with redundant > process, power supplies, hot swappable line cards. I would recommend > Cisco 6500 Series, Cisco 7200 Series, Cisco ASA or Pix. I am not to > fond of the Juniper firewall licensing. BTW, Cisco 2800/3600 Series > may even work. Depends on your throughput capabilities you are > needing. Research all aspects of your gear from ram, flash, processor > speeds, to throughput, modules, IOS, and hot swappable needs. > > > The above will get you started. > > rootnet08 > > On 9/10/08, John Ramz wrote: >> >> We are looking into start hosting our customers' apps and data and >> would like for you to provide me link to internet resources (or >> books) to get me started on a network design that includes: >> >> - 3rd party Compliance (security for example) >> - Redundancy (routers, firewalls, switches) >> - load balancing >> - VLANS >> - Virtual servers >> - Backup- SANs- >> - Disaster recovery >> - How to keep customers separated from our regular network? >> - How to keep customers totally isolated from each other? >> - Access from our network to the Datacenter network for our >> developers to work with our customers? Also for our IT people to >> service, monitor and maintain that network > > I have thought of getting an Internet pipe just for the Datacenter > network >> and with all the above mentioned components and then figure out the >> way and procedures to connect our company network with that one for >> the different items I already mentioned. >> >> Has anyone been involved in a project like that could elaborate as >> much as possible on the subject? >> > Please shed some light with me on where to start and build from there? >> >> 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/ >> > _______________________________________________ > 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 gkg at gmx.de Thu Sep 11 23:51:39 2008 From: gkg at gmx.de (Garry) Date: Fri, 12 Sep 2008 05:51:39 +0200 Subject: [c-nsp] load-sharing round robin time? In-Reply-To: References: <48C9CFF5.8060907@davidcoulson.net> Message-ID: <48C9E74B.6050205@gmx.de> Dan Letkeman wrote: > I have tried enabling per-packet load balancing, but if I do that then > no pages come up in the browser. So I did a tcp-mss adjust on the > interface and still no difference. With every line being a separate NAT (I assume) your outgoing packets streams are more or less torn up now, resulting already in the initial TCP handshake being impossible ... (SYN goes out with IP1, SYN ACK returns on that line, ACK goes out with IP2 ...) The delay in switching links comes from the router setting up a traffic flow and remembering the IP-to-line assignment for a while ... Only thing I could suggest for now is using three squids (could be done on that single machine) with three different outgoing IPs, which in turn can be routed statically to one line each through route maps ... then use a fourth squid instance (towards the users) to use the other three round-robin ... -garry From vikassharmas at gmail.com Fri Sep 12 01:11:18 2008 From: vikassharmas at gmail.com (Vikas Sharma) Date: Fri, 12 Sep 2008 10:41:18 +0530 Subject: [c-nsp] F5 BIG IP and FWSM In-Reply-To: <38521.64.122.164.5.1221170778.squirrel@webmail-devel.integra.net> References: <1A9866F953006D45AEE0166066114E09131ECC3F@TPMAIL02.corp.theplatform.com> <38521.64.122.164.5.1221170778.squirrel@webmail-devel.integra.net> Message-ID: Hi, Thanks for the quick reply. I agree with your advice. But it might be required to loadbalance other devices those are sitting somewhere in my MPLS network. To do this mandatory condition is - LB internal interface should be able to ping / reach that. If I am using first DG to LB VIP and from LB 2nd DG to fwsm context failover ip, how can I achieve reachability from LB internal interface to servers somewhere in my MPLS network as to reach LB one have to pass through FWSM. Do i need to create a separate context for LB reachability to servers outside in MPLS network? Regards, Vikas Sharma On 9/12/08, Max Reid wrote: > > > That looks backwards...why not have the DG for internal hosts be the > > BigIP, and DG the BigIP to the inside of the FWSM? > > > > The BigIP does a good job of performing NAT, and doesn't need to be > > directly connected to the nodes in its pools...in fact, I would highly > > recommend against connecting nodes directly to the BigIP - you should > > utilize a core switch block for that and default route to a floating > > internal ip on the BigIP, from there, upstream to the FWSM and let it > > handle security out front. > > I concur with this advice, esp. the note about having an L3 connected > network between the back end hosts and the 'Inside' interface of the big > IP. > > > Main Benefit is failover (no arp issues on clients or F5); when dealing > with large load balanced farms. > > ~Max > > > > > > > > -----Original Message----- > > From: cisco-nsp-bounces at puck.nether.net > > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Vikas Sharma > > Sent: Thursday, September 11, 2008 11:08 AM > > To: cisco-nsp at puck.nether.net > > Subject: [c-nsp] F5 BIG IP and FWSM > > > > Hi, > > > > Did any one have worked on F5 BIG IP and FWSM? If yes please help me. As > > this point I wanted to know BIG IP and how it should be conected to > > fwsm, > > specially in routed mode. > > > > My understanding - > > > > 6509 (MSFC) --> outside interface of LB --> Inside interface of LB -> > > FWSM > > context (multiple context) > > > > How bigip will be able to do loadbalancing, when it is not directly > > connected to servers. All servers d/g is fwsm context. > > > > Regards, > > Vikas Sharma > > _______________________________________________ > > 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 swmike at swm.pp.se Fri Sep 12 02:06:45 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 12 Sep 2008 08:06:45 +0200 (CEST) Subject: [c-nsp] 7206vxr npe300 throughput In-Reply-To: <071c01c91489$006da2f0$0148e8d0$@com> References: <071c01c91489$006da2f0$0148e8d0$@com> Message-ID: On Thu, 11 Sep 2008, Richey wrote: > I've got a 7206VXR with an NPE 300. It does not run BGP. The majority of > the traffic on this router will be is streaming media. The only ACLs on > this router are there to protect the router it's self. We are talking > about switching the full DS3 that is in this router out for a 100Mb FE feed. > Should I worry about this router being able to handle 80 to 100mb of > traffic? NPE300 will do bidir approximately OC3 with i-mix traffic in my experience. So unless the traffic consists of really small packets only, you should be fine with quite a lot of headroom to do DS3. -- Mikael Abrahamsson email: swmike at swm.pp.se From adrian at creative.net.au Fri Sep 12 02:13:55 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Fri, 12 Sep 2008 14:13:55 +0800 Subject: [c-nsp] load-sharing round robin time? In-Reply-To: <48C9E74B.6050205@gmx.de> References: <48C9CFF5.8060907@davidcoulson.net> <48C9E74B.6050205@gmx.de> Message-ID: <20080912061355.GL15118@skywalker.creative.net.au> On Fri, Sep 12, 2008, Garry wrote: > Only thing I could suggest for now is using three squids (could be done > on that single machine) with three different outgoing IPs, which in turn > can be routed statically to one line each through route maps ... then > use a fourth squid instance (towards the users) to use the other three > round-robin ... You can tell Squid to use >1 outgoing address, and if you asked me -really- nicely I could probably even write up some code to round-robin load balance between them.. Adrian (My favourite beer is ...) From dmitry at dmitry.net Fri Sep 12 02:25:44 2008 From: dmitry at dmitry.net (Dmitry Kiselev) Date: Fri, 12 Sep 2008 09:25:44 +0300 Subject: [c-nsp] IPv6 Subnetting - Service Provider In-Reply-To: <20080911212955.GA2486@lboro.ac.uk> References: <004401c91442$1170c510$34524f30$@org> <48C98BD2.9010800@rollernet.us> <20080911212955.GA2486@lboro.ac.uk> Message-ID: <20080912062544.GQ14724@f17.dmitry.net> Hello! On Thu, Sep 11, 2008 at 10:29:55PM +0100, A.L.M.Buxey at lboro.ac.uk wrote: > my initial (and, i guess, current) IPv6 deployment plan > was based on /64 subnets. yes, thats a ridiculous amount > of hosts per subnet...nasty software coded in 'the old style' > might make these very big collision domains and i do worry about > how ISC DHCPv6 will handle such large numbers of leases - > recalling how it deals with /16's in IPv4 land. Don't worry. :) ISC made pretty well dhcp server. We run it to serve huge amount of IPv4 hosts without significant performance patches. Fast and rock-stable. $ cat dhcpd.leases | grep ^lease | wc -l 756910 $ -- Dmitry Kiselev From fweimer at bfk.de Fri Sep 12 03:50:33 2008 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 12 Sep 2008 09:50:33 +0200 Subject: [c-nsp] IPv6 Subnetting - Service Provider In-Reply-To: <20080911202727.GA9212@toontown.erial.nj.us> (Bob Snyder's message of "Thu, 11 Sep 2008 16:27:27 -0400") References: <004401c91442$1170c510$34524f30$@org> <004501c9144a$8e4d0f00$aae72d00$@org> <20080911202727.GA9212@toontown.erial.nj.us> Message-ID: <82sks5x0om.fsf@mid.bfk.de> * Bob Snyder: > One issue we ran into was that not all the networking gear we had > could support /126. The vendor's (not Cisco) immature support for > IPv6 could only understand the concept of /128 loopbacks and /64 > subnets. Subnets smaller than /64 containing (conceptually) global unicast addresses are not allowed per the IPv6 addressing architecture RFC. So it's just another case of vendors got bitten by RFCs that don't match customer requirements. 8-/ -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From avayner at cisco.com Fri Sep 12 04:19:21 2008 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Fri, 12 Sep 2008 10:19:21 +0200 Subject: [c-nsp] Check bandwidth on router In-Reply-To: <89944ef40809111754s49466f26w38d25fc90df0b4f5@mail.gmail.com> References: <89944ef40809111754s49466f26w38d25fc90df0b4f5@mail.gmail.com> Message-ID: <67F7C1FAF83A074AA3520D8F155782A501D79823@xmb-ams-331.emea.cisco.com> Dear rootnet, Not a direct solution to what you want, but did you consider using IP SLA for constant performance monitoring? You can setup a few IP SLA HTTP probes to well known sites and monitor the performance trend. This would give you a real indication of the "quality of experience". Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net Sent: Friday, September 12, 2008 03:55 AM To: cisco-nsp Subject: [c-nsp] Check bandwidth on router Hi List, Is there some sort of tool you can load into the IOS on a router to check bandwidth? Or if not what are you all doing these days in this situation. Like for example things are running slow and you think the Internet feed may be the problem is there a way to do speed tests on the router itself? rootnet _______________________________________________ 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 Fri Sep 12 04:58:42 2008 From: lists at memetic.org (Adam Armstrong) Date: Fri, 12 Sep 2008 09:58:42 +0100 Subject: [c-nsp] Can the PE router take on multiple roles? In-Reply-To: <20080910134754.GE11984@rtp-cse-489.cisco.com> References: <56F211C5E3F24F47B103EA1B253822BE036548CC@vic-cr-ex1.staff.netspace.net.au> <20080910134754.GE11984@rtp-cse-489.cisco.com> Message-ID: <48CA2F42.5050605@memetic.org> Yeah, and be aware that the more things you put on a device, the more likely it is to die. I've heard some scary things about the NAT-PT implementation on cisco kit, it's apparently very very slow and a bit unstable. Make sure you don't mind if all of the services on that device go down because of NAT-PT (i'm assuming this is *not* the case with BGP-RR!) adam. > It would work fine. Watch the CPU and memory to gauge scalability > as you grow. > > > Rodney > > On Wed, Sep 10, 2008 at 03:34:48PM +1000, Andy Saykao wrote: > >> Hi All, >> >> We have a few spare 7301's out the back and I was thinking of using one >> of them to be a NAT-PE router. No biggie with doing this but I was >> wondering if the NAT-PE router could also take on other roles which >> would be beneficial in a MPLS VPN environment such as using it to act as >> a SSL VPN Gateway for remote access. Could the same unit also be used to >> act as a Route Reflector to reflect VPNv4 routes? Or am I putting too >> much load on the router and/or putting all my eggs in one basket? >> >> At present, we don't have many MPLS VPN customers yet but the hope is to >> make things scalable so we can grow comfortable as the number of VPN >> customers grow. >> >> In summary, is it a good idea to use the 7301 to preform the following >> roles: >> >> - NAT-PE / Internet Gateway >> - SSL VPN Gateway >> - BGP Route Reflector >> >> Ideas, comments, personal experiences, etc most welcomed. >> >> 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. >> >> _______________________________________________ >> 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 SamHall at wiseman-dairies.co.uk Fri Sep 12 05:01:40 2008 From: SamHall at wiseman-dairies.co.uk (Sam Hall) Date: Fri, 12 Sep 2008 10:01:40 +0100 Subject: [c-nsp] Sam Hall is out of the office. Message-ID: I will be out of the office starting 05/09/2008 and will not return until 18/09/2008. I will respond to your message when I return. Kind Regards ********************************************************************************* Disclaimer: This electronic mail, together with any attachments, is for the exclusive and confidential use of the recipient addressee. Any other distribution, use or reproduction without our prior consent is unauthorised and strictly prohibited. If you have received this message in error, please delete it immediately and contact the sender directly or the Robert Wiseman & Sons Ltd IT Helpdesk on +44 (0)1355 270634. Any views or opinions expressed in this message are those of the author and do not necessarily represent those of Robert Wiseman & Sons Ltd or of any of its associated companies. No reliance may be placed on this message without written confirmation from an authorised representative of the company. Robert Wiseman & Sons Limited reserves the right to monitor all e-mail communications through its network. This message has been checked for viruses but the recipient is strongly advised to re-scan the message before opening any attachments or attached executable files. ROBERT WISEMAN & SONS LIMITED Registered Number: 87376 Scotland Registered Office: 159 Glasgow Road, East Kilbride, Glasgow, G74 4PA ******************************************************************************** From julien.leroiso at gmail.com Fri Sep 12 07:20:01 2008 From: julien.leroiso at gmail.com (julien leroiso) Date: Fri, 12 Sep 2008 13:20:01 +0200 Subject: [c-nsp] do I need acl on wan bgp port ? Message-ID: Hi, I blocked BGP bogons announces[1] like many other admins (I hope). I want to know if it's common that ISP add an ACL to the wan port to block at least rfc1918 IP addresses. And in the contrary ACL to prevent outgoing spoofing. [1] http://www.cymru.com/Documents/secure-bgp-template.html From mailinglist at bangky.net Fri Sep 12 07:39:27 2008 From: mailinglist at bangky.net (Ang Kah Yik) Date: Fri, 12 Sep 2008 19:39:27 +0800 Subject: [c-nsp] do I need acl on wan bgp port ? In-Reply-To: References: Message-ID: <2ad168fd0809120439n778bdd18jd8d354e9bcf11450@mail.gmail.com> Hi Julien, This topic may actually be more suited to other mailing lists such as NANOG rather than a Cisco specific list. Anyway, I believe it is more common that ISPs deploy the use of uRPF (unicast reverse path forwarding) rather than ACLs. At the very least, the use of loose mode RPF ensures that the prefix from which a packet is sourced exists within the routing table. Thus, packets sourced from RFC1918 addresses ought to be blocked since they should not be appearing in the routing tables of most BGP routers. This also applies to packets that you are null routing (such as the bogon prefixes that you have mentioned). In terms of performance, there are specific performance gains if RPF is used rather than a long ACL to block prefixes. The more experienced members on this list may wish to share their opinion and correct me if I'm wrong. Cheers. On Fri, Sep 12, 2008 at 7:20 PM, julien leroiso wrote: > Hi, > > I blocked BGP bogons announces[1] like many other admins (I hope). > > I want to know if it's common that ISP add an ACL to the wan port to block > at least rfc1918 IP addresses. > And in the contrary ACL to prevent outgoing spoofing. > > > [1] http://www.cymru.com/Documents/secure-bgp-template.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/ > -- Ang Kah Yik (bangky) - http://blog.bangky.net From rodunn at cisco.com Fri Sep 12 07:57:01 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Fri, 12 Sep 2008 07:57:01 -0400 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <200809121222.19526.mtinka@globaltransit.net> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <383357750809110529y67490054j95b48a53b56d8d1@mail.gmail.com> <20080911130626.GC23118@rtp-cse-489.cisco.com> <200809121222.19526.mtinka@globaltransit.net> Message-ID: <20080912115701.GC3386@rtp-cse-489.cisco.com> Yep...typo. On Fri, Sep 12, 2008 at 12:22:19PM +0800, Mark Tinka wrote: > On Thursday 11 September 2008 21:06:26 Rodney Dunn wrote: > > > That's wrong. > > > > The 7301 is basically a 1RU 72xx/G2 combo. > > I thought that's the 72xx/NPE-G1 combo; the 7201 would be > the -G2 combo, right? > > Mark. From adriankok2000 at yahoo.com.hk Fri Sep 12 07:14:35 2008 From: adriankok2000 at yahoo.com.hk (adrian kok) Date: Fri, 12 Sep 2008 19:14:35 +0800 (CST) Subject: [c-nsp] console port In-Reply-To: <48C9D769.60903@altzman.com> Message-ID: <69219.34362.qm@web33308.mail.mud.yahoo.com> Great. but my winxp is showing ? in the usb of the system. It needs the driver. Do you know any realiable site to download this driver Thank you again --- "Jerry B. Altzman" wrote: > on 2008-09-11 21:23 adrian kok said the following: > > I want to connect to the console port > > but my laptop is only having the USB without the > com > > (serial port) > > Now i try to use the usb to serial port cable > > + serial to console cable > > to connect this console box of the router > > does it work? > > I do it all the time. It works a charm! > > //jbaltz > -- > jerry b. altzman jbaltz at altzman.com > www.jbaltz.com > thank you for contributing to the heat death of the > universe. > > Send instant messages to your online friends http://uk.messenger.yahoo.com From doon.bulk at inoc.net Fri Sep 12 08:27:19 2008 From: doon.bulk at inoc.net (Patrick Muldoon) Date: Fri, 12 Sep 2008 08:27:19 -0400 Subject: [c-nsp] console port In-Reply-To: <69219.34362.qm@web33308.mail.mud.yahoo.com> References: <69219.34362.qm@web33308.mail.mud.yahoo.com> Message-ID: On Sep 12, 2008, at 7:14 AM, adrian kok wrote: > Great. but my winxp is showing ? in the usb of the > system. It needs the driver. > > Do you know any realiable site to download this driver As there are probably hundreds (if not more) random USB2Serial Devices, not knowing which one you have will make it rough to help. Try google? FWIW: I've been happy with my keyspan.. http://www.keyspan.com/products/usa19hs/ Use it all the time, and have had zero issues with it.. -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C Mac OS X. Because making Unix user-friendly is easier than debugging Windows. From maillist at webjogger.net Fri Sep 12 09:17:25 2008 From: maillist at webjogger.net (Adam Greene) Date: Fri, 12 Sep 2008 09:17:25 -0400 Subject: [c-nsp] console port References: <69219.34362.qm@web33308.mail.mud.yahoo.com> Message-ID: <074672C37DDB4EDDA544301AE3D000EC@GINKGO> I can second the good results with the Keyspan ... ----- Original Message ----- From: "Patrick Muldoon" To: "adrian kok" Cc: Sent: Friday, September 12, 2008 8:27 AM Subject: Re: [c-nsp] console port > On Sep 12, 2008, at 7:14 AM, adrian kok wrote: > >> Great. but my winxp is showing ? in the usb of the >> system. It needs the driver. >> >> Do you know any realiable site to download this driver > > As there are probably hundreds (if not more) random USB2Serial > Devices, not knowing which one you have will make it rough to help. > Try google? > > FWIW: > I've been happy with my keyspan.. > > http://www.keyspan.com/products/usa19hs/ > > Use it all the time, and have had zero issues with it.. > > -Patrick > > -- > Patrick Muldoon > Network/Software Engineer > INOC (http://www.inoc.net) > PGPKEY (http://www.inoc.net/~doon) > Key ID: 0x370D752C > > Mac OS X. Because making Unix user-friendly is easier than debugging > Windows. > > _______________________________________________ > 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 chale99 at gmail.com Fri Sep 12 09:36:14 2008 From: chale99 at gmail.com (Chris Hale) Date: Fri, 12 Sep 2008 09:36:14 -0400 Subject: [c-nsp] how to accomplish multiple 'native' vlans In-Reply-To: References: Message-ID: Thanks Frank. This looks almost exactly what I was looking for, but the VLANs would be switched around: VID 10 would come through tagged (i.e. equipment mgmt VID) and VID 100/101 (i.e. customer VID) would come through untagged. Is this only on the newer switches? I seem to remember I had to carry the native vlan throughout the uplinks on an older 3550. Thanks, Chris On Thu, Sep 11, 2008 at 12:54 AM, Frank Bulk wrote: > Chris: > > Each port can be assigned a unique untagged VLAN (switchport trunk native > vlan xx). You can limit which VLANs are trunked by assigning the allowed > VLANs (switchport trunk allowed vlan yy). You can then create an uplink > port with all those trunks. > > I think this is what you're looking for. > > Here's an example: > > interface FastEthernet0/1 > description Customer A > switchport mode trunk > switchport nonegotiate > switchport trunk native vlan 10 > switchport trunk allowed vlan 100 > ! > interface FastEthernet0/2 > description Customer B > switchport mode trunk > switchport nonegotiate > switchport trunk native vlan 10 > switchport trunk allowed vlan 101 > ! > interface FastEthernet0/24 > description Uplink > switchport mode trunk > switchport nonegotiate > switchport trunk allowed vlan 10, 100, 101 > ! > > Frank > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Chris Hale > Sent: Wednesday, September 10, 2008 11:35 PM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] how to accomplish multiple 'native' vlans > > All - > > We are converting our L2 network from Riverstone to Cisco. One > problem I have not been able to solve yet is the way the Riverstone > and Cisco units handle untagged traffic entering a physical port. We > have many connections to customers whereby we have equipment we would > like to manage with management VIDs inline with untagged customer > traffic. When it enters the Ethernet trunk port on the Riverstone, we > are able to assign the untagged traffic to a VID and it traverses the > trunk ports where allowed as tagged traffic. It doesn't seem like the > Cisco switches have this ability - only one native VLAN per switch. > Is there some way to accept multiple ports of untagged traffic and tag > each ports' untagged traffic with separate VIDs? > > Example: > > fa0/1 - mgmt VID 10, customer traffic untagged (needs to be tagged > with VID 100 for L3 routing) > fa0/2 - mgmt VID 10, customer traffic untagged (needs to be tagged > with VID 101 for L3 routing) > etc. > fa0/24 - trunk port to L3 device > > We are using 2960 and 3560 switches. Any other ideas are welcome, but > we would prefer to minimize any CPE equipment at customer site to tag > their traffic with the appropriate customer VID. It's a matter of > additional cost, additional management devices, and additional points > of failure. > > Thanks, > Chris > > -- > ------------------ > Chris Hale > chale99 at gmail.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/ > > -- ------------------ Chris Hale chale99 at gmail.com From schmid at dfn.de Fri Sep 12 09:14:44 2008 From: schmid at dfn.de (Thomas Schmid) Date: Fri, 12 Sep 2008 15:14:44 +0200 Subject: [c-nsp] BFD on 12.2.33 SRA and SRB Message-ID: <48CA6B44.7010204@dfn.de> Hi, since we're in a situation where we may have to implement BFD soon on a number of links, I did a test with 12.2(33)SRA4 in a half-test environment. The result was that after max. 5 min the router (SUP720-3BXL) crashed without memory (small buffers) left. This was easily reproducible by just turning on BFD for a eBGP session. Even though I provided lots of crashinfo files and logs to the TAC, they were not able to reproduce it in the lab and nail down the problem or find the trigger for the mem leaks. The closest they came up with was CSCsh37272. Recommendation was to go for SRB and see if the problem is also there. Well, I tried SRB4 and wasn't yet able to reproduce the crashes. While this is a strong hint that we won't see the crashes with SRB, I'm not 100% conviced and so my question is if someone saw any memory related problems with SRB and BFD recently? Thanks, Thomas From rootnet08 at gmail.com Fri Sep 12 09:53:08 2008 From: rootnet08 at gmail.com (root net) Date: Fri, 12 Sep 2008 08:53:08 -0500 Subject: [c-nsp] Check bandwidth on router In-Reply-To: <67F7C1FAF83A074AA3520D8F155782A501D79823@xmb-ams-331.emea.cisco.com> References: <89944ef40809111754s49466f26w38d25fc90df0b4f5@mail.gmail.com> <67F7C1FAF83A074AA3520D8F155782A501D79823@xmb-ams-331.emea.cisco.com> Message-ID: <89944ef40809120653i59281e97h22d206ca3b6092e6@mail.gmail.com> IP SLA seems to be the best option at present. Although we monitor with some open source tools. I would like to have a way to check that I am getting what (bandwidth) I am paying for if this makes sense. It seems to me that these programs only monitor the circuits not test throughput. I want to be able to test throughput on the circuit. These third party sites are ok but I am sure there is someway providers are doing this with out using speedtest sites? rootnet On Fri, Sep 12, 2008 at 3:19 AM, Arie Vayner (avayner) wrote: > Dear rootnet, > > Not a direct solution to what you want, but did you consider using IP > SLA for constant performance monitoring? > You can setup a few IP SLA HTTP probes to well known sites and monitor > the performance trend. This would give you a real indication of the > "quality of experience". > > Arie > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net > Sent: Friday, September 12, 2008 03:55 AM > To: cisco-nsp > Subject: [c-nsp] Check bandwidth on router > > Hi List, > > Is there some sort of tool you can load into the IOS on a router to > check bandwidth? Or if not what are you all doing these days in this > situation. > Like for example things are running slow and you think the Internet feed > may be the problem is there a way to do speed tests on the router > itself? > > rootnet > _______________________________________________ > 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 Robert.Smales at cw.com Fri Sep 12 09:56:37 2008 From: Robert.Smales at cw.com (Smales, Robert) Date: Fri, 12 Sep 2008 14:56:37 +0100 Subject: [c-nsp] do I need acl on wan bgp port ? In-Reply-To: <2ad168fd0809120439n778bdd18jd8d354e9bcf11450@mail.gmail.com> Message-ID: <602ACF092EFFB044931BD8746C19AD2F8427E2@gbcwswiem006.ad.plc.cwintra.com> Hi All > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Ang Kah Yik > Sent: 12 September 2008 12:39 > To: julien leroiso > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] do I need acl on wan bgp port ? > > > Hi Julien, > > This topic may actually be more suited to other mailing lists such as > NANOG rather than a Cisco specific list. > Anyway, I believe it is more common that ISPs deploy the use of uRPF > (unicast reverse path forwarding) rather than ACLs. > We use route-maps/prefix-lists to filter incoming BGP, that is more manageable than having to rewrite a single access-list when the bogons list changes, for example. Robert Robert Smales IP Provide Engineer Cable&Wireless Europe, Asia & US www.cw.com This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable and Wireless plc Registered in England and Wales.Company Number 238525 Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ From eric at atlantech.net Fri Sep 12 09:58:46 2008 From: eric at atlantech.net (Eric Van Tol) Date: Fri, 12 Sep 2008 09:58:46 -0400 Subject: [c-nsp] ME3750 Shaping Message-ID: <2C05E949E19A9146AF7BDF9D44085B86350AECC47E@exchange.aoihq.local> Hi all, Does anyone know if the ME3750 can do egress shaping of a particular queue to a limit of >40Mb/s? If so, any examples anyone can share? The goal is to not only police on ingress at a certain limit (25M, 50M, 75M), but also to egress shape at the same limit. I've got the inbound policing just fine, but it seems that the method I found to shape will only do a limit of about 40-50Mb/s. I need to do this on not only non-ES routed ports, but also on non-ES ports that have two VLANs assigned to them, one of which is rate-limited/shaped and one that has WRR with priority queuing. Thanks, evt From s00664233 at gmail.com Fri Sep 12 10:26:46 2008 From: s00664233 at gmail.com (cc loo) Date: Fri, 12 Sep 2008 22:26:46 +0800 Subject: [c-nsp] console port In-Reply-To: <69219.34362.qm@web33308.mail.mud.yahoo.com> References: <48C9D769.60903@altzman.com> <69219.34362.qm@web33308.mail.mud.yahoo.com> Message-ID: <49999c420809120726q48b45593m6d25ea68dbd3140d@mail.gmail.com> I use ATEN brand RS232/USB adapter and windows update was able to get the driver for itFYI :) Try googling brand of your adapter, you might find something On Fri, Sep 12, 2008 at 7:14 PM, adrian kok wrote: > Great. but my winxp is showing ? in the usb of the > system. It needs the driver. > > Do you know any realiable site to download this driver > > Thank you again > > > --- "Jerry B. Altzman" wrote: > > > on 2008-09-11 21:23 adrian kok said the following: > > > I want to connect to the console port > > > but my laptop is only having the USB without the > > com > > > (serial port) > > > Now i try to use the usb to serial port cable > > > + serial to console cable > > > to connect this console box of the router > > > does it work? > > > > I do it all the time. It works a charm! > > > > //jbaltz > > -- > > jerry b. altzman jbaltz at altzman.com > > www.jbaltz.com > > thank you for contributing to the heat death of the > > universe. > > > > > > > Send instant messages to your online friends http://uk.messenger.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 dhooper at emerge.net.au Fri Sep 12 10:37:46 2008 From: dhooper at emerge.net.au (Daniel Hooper) Date: Fri, 12 Sep 2008 22:37:46 +0800 Subject: [c-nsp] Check bandwidth on router In-Reply-To: <89944ef40809120653i59281e97h22d206ca3b6092e6@mail.gmail.com> References: <89944ef40809111754s49466f26w38d25fc90df0b4f5@mail.gmail.com><67F7C1FAF83A074AA3520D8F155782A501D79823@xmb-ams-331.emea.cisco.com> <89944ef40809120653i59281e97h22d206ca3b6092e6@mail.gmail.com> Message-ID: You can use netperf to test bandwidth, cron it to run daily for 10 seconds and it will report the bandwidth on your circuits. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net Sent: Friday, 12 September 2008 9:53 PM To: Arie Vayner (avayner) Cc: cisco-nsp Subject: Re: [c-nsp] Check bandwidth on router IP SLA seems to be the best option at present. Although we monitor with some open source tools. I would like to have a way to check that I am getting what (bandwidth) I am paying for if this makes sense. It seems to me that these programs only monitor the circuits not test throughput. I want to be able to test throughput on the circuit. These third party sites are ok but I am sure there is someway providers are doing this with out using speedtest sites? rootnet On Fri, Sep 12, 2008 at 3:19 AM, Arie Vayner (avayner) wrote: > Dear rootnet, > > Not a direct solution to what you want, but did you consider using IP > SLA for constant performance monitoring? > You can setup a few IP SLA HTTP probes to well known sites and monitor > the performance trend. This would give you a real indication of the > "quality of experience". > > Arie > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net > Sent: Friday, September 12, 2008 03:55 AM > To: cisco-nsp > Subject: [c-nsp] Check bandwidth on router > > Hi List, > > Is there some sort of tool you can load into the IOS on a router to > check bandwidth? Or if not what are you all doing these days in this > situation. > Like for example things are running slow and you think the Internet feed > may be the problem is there a way to do speed tests on the router > itself? > > rootnet > _______________________________________________ > 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 tom at snnap.net Fri Sep 12 10:46:04 2008 From: tom at snnap.net (Tom Storey) Date: Sat, 13 Sep 2008 00:16:04 +0930 Subject: [c-nsp] console port In-Reply-To: <074672C37DDB4EDDA544301AE3D000EC@GINKGO> References: <69219.34362.qm@web33308.mail.mud.yahoo.com> <074672C37DDB4EDDA544301AE3D000EC@GINKGO> Message-ID: <9D077D04-A1CD-465F-A6B7-A720A7606254@snnap.net> My vote for Keyspan aswell, though I have seen some very strange things happen with them. Personally, mine is working flawless, and it gets a good workout... I use a Mac with Minicom, doesnt matter which USB port I have it plugged into, it always works. Tom On 12/09/2008, at 10:47 PM, Adam Greene wrote: > I can second the good results with the Keyspan ... > > ----- Original Message ----- From: "Patrick Muldoon" > > To: "adrian kok" > Cc: > Sent: Friday, September 12, 2008 8:27 AM > Subject: Re: [c-nsp] console port > > >> On Sep 12, 2008, at 7:14 AM, adrian kok wrote: >>> Great. but my winxp is showing ? in the usb of the >>> system. It needs the driver. >>> >>> Do you know any realiable site to download this driver >> As there are probably hundreds (if not more) random USB2Serial >> Devices, not knowing which one you have will make it rough to >> help. Try google? >> FWIW: >> I've been happy with my keyspan.. >> http://www.keyspan.com/products/usa19hs/ >> Use it all the time, and have had zero issues with it.. >> -Patrick >> -- >> Patrick Muldoon >> Network/Software Engineer >> INOC (http://www.inoc.net) >> PGPKEY (http://www.inoc.net/~doon) >> Key ID: 0x370D752C >> Mac OS X. Because making Unix user-friendly is easier than >> debugging Windows. >> _______________________________________________ >> 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 doon.bulk at inoc.net Fri Sep 12 10:55:40 2008 From: doon.bulk at inoc.net (Patrick Muldoon) Date: Fri, 12 Sep 2008 10:55:40 -0400 Subject: [c-nsp] console port In-Reply-To: <9D077D04-A1CD-465F-A6B7-A720A7606254@snnap.net> References: <69219.34362.qm@web33308.mail.mud.yahoo.com> <074672C37DDB4EDDA544301AE3D000EC@GINKGO> <9D077D04-A1CD-465F-A6B7-A720A7606254@snnap.net> Message-ID: <9A95A1F8-94BF-4ED7-B9D8-68E964D1AECD@inoc.net> On Sep 12, 2008, at 10:46 AM, Tom Storey wrote: > My vote for Keyspan aswell, though I have seen some very strange > things happen with them. > > Personally, mine is working flawless, and it gets a good workout... > > I use a Mac with Minicom, doesnt matter which USB port I have it > plugged into, it always works. > > Tom Same Here, using a Mac With Minicom.. Drivers default to creating /dev/cu.KeySerial1 for the first on you plug-in. (they used to not, so you always had to use the same USB port, or manual adjust symlink, etc...) I cannot speak to how they work on windows though... -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C NOTICE: alloc: /dev/null: filesystem full From gert at greenie.muc.de Fri Sep 12 10:56:19 2008 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 12 Sep 2008 16:56:19 +0200 Subject: [c-nsp] IPv6 Subnetting - Service Provider In-Reply-To: <82sks5x0om.fsf@mid.bfk.de> References: <004401c91442$1170c510$34524f30$@org> <004501c9144a$8e4d0f00$aae72d00$@org> <20080911202727.GA9212@toontown.erial.nj.us> <82sks5x0om.fsf@mid.bfk.de> Message-ID: <20080912145619.GS17238@greenie.muc.de> Hi, On Fri, Sep 12, 2008 at 09:50:33AM +0200, Florian Weimer wrote: > Subnets smaller than /64 containing (conceptually) global unicast > addresses are not allowed per the IPv6 addressing architecture RFC. > So it's just another case of vendors got bitten by RFCs that don't > match customer requirements. 8-/ I can't really see what's "customer requirements" here, except "we don't like the RFC, so we decide to ignore it, and then we're surprised that the result is not what we expect". It's not like anybody being short on IPv6 addresses. 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: 304 bytes Desc: not available URL: From rodunn at cisco.com Fri Sep 12 10:59:49 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Fri, 12 Sep 2008 10:59:49 -0400 Subject: [c-nsp] BFD on 12.2.33 SRA and SRB In-Reply-To: <48CA6B44.7010204@dfn.de> References: <48CA6B44.7010204@dfn.de> Message-ID: <20080912145949.GA4860@rtp-cse-489.cisco.com> I'd strongly encourage anyone to go for SRB3 and later. We had a huge bug fix push on the SRB throttle after SRB2 and it's been extremely stable and that is where we are enouraging customers to go. There were a lot of changes to BFD in the SRB timeframe for a lot of bugs. Rodney On Fri, Sep 12, 2008 at 03:14:44PM +0200, Thomas Schmid wrote: > Hi, > > since we're in a situation where we may have to implement BFD soon on > a number of links, I did a test with 12.2(33)SRA4 in a half-test environment. > > The result was that after max. 5 min the router (SUP720-3BXL) crashed > without memory (small buffers) left. This was easily reproducible > by just turning on BFD for a eBGP session. > > Even though I provided lots of crashinfo files and logs to the TAC, they were > not able to reproduce it in the lab and nail down the problem or find the > trigger for the mem leaks. The closest they came up with was CSCsh37272. > > Recommendation was to go for SRB and see if the problem is also there. > > Well, I tried SRB4 and wasn't yet able to reproduce the crashes. While > this is a strong hint that we won't see the crashes with SRB, I'm not > 100% conviced and so my question is if someone saw any memory related > problems with SRB and BFD recently? > > Thanks, > > Thomas > > _______________________________________________ > 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 ivan at ig.sk Fri Sep 12 10:12:15 2008 From: ivan at ig.sk (Ivan Gasparik) Date: Fri, 12 Sep 2008 16:12:15 +0200 Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: <20080911.193436.41659240.sthaug@nethelp.no> References: <1836781474-1221151128-cardhu_decombobulator_blackberry.rim.net-959829273-@bxe252.bisx.prod.on.blackberry> <20080911.193436.41659240.sthaug@nethelp.no> Message-ID: <200809121612.16093.ivan@ig.sk> On Thursday 11 September 2008, sthaug at nethelp.no wrote: > > You can enable sampling if it is not enabled. It should help > > some. > > Highly unlikely. Sampling on the 6500 is performed interely in > software, *after* the full set of flows has been received. You have to distinguish between the cpu load seen as interrupt load (caused mostly by walking through the TCAM, collecting statistics and storing them in netflow cache) and the cpu load caused by NDE process (packet generation). Enabling netflow sampling you can decrease the second part of the load - the cpu will generate significantly less packets of export statistics. Ivan From benny+usenet at amorsen.dk Fri Sep 12 10:22:43 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Fri, 12 Sep 2008 16:22:43 +0200 Subject: [c-nsp] IPv6 Subnetting - Service Provider In-Reply-To: <82sks5x0om.fsf@mid.bfk.de> (Florian Weimer's message of "Fri\, 12 Sep 2008 09\:50\:33 +0200") References: <004401c91442$1170c510$34524f30$@org> <004501c9144a$8e4d0f00$aae72d00$@org> <20080911202727.GA9212@toontown.erial.nj.us> <82sks5x0om.fsf@mid.bfk.de> Message-ID: Florian Weimer writes: > * Bob Snyder: > >> One issue we ran into was that not all the networking gear we had >> could support /126. The vendor's (not Cisco) immature support for >> IPv6 could only understand the concept of /128 loopbacks and /64 >> subnets. > > Subnets smaller than /64 containing (conceptually) global unicast > addresses are not allowed per the IPv6 addressing architecture RFC. > So it's just another case of vendors got bitten by RFCs that don't > match customer requirements. 8-/ You could also call it unreasonable customer requirements. If you spend a /40 on linknets you can have 2^24 of them. A /40 is nothing to an ISP. An enterprise would be a bit more cramped, but any enterprise needing more than say 10000 linknets should probably get an AS-number and some provider-independent space -- and then there's plenty of space again. /Benny From clayton at MNSi.Net Fri Sep 12 12:50:29 2008 From: clayton at MNSi.Net (Clayton Zekelman) Date: Fri, 12 Sep 2008 12:50:29 -0400 Subject: [c-nsp] NPE-G2 Gigabit Ignored Errors Message-ID: <200809121649.m8CGngEV013138@e450.mnsi.net> I'm running a Cisco 7206/VXR with an NPE G2, Version 12.4(4)XD4 acting as an LNS. I'm getting input errors consistently incrementing on the Gig interface (ignored errors) Any way to fix this? I saw some discussion a while back about this, and it seemed to have to do with buffers - but I can't find any definitive recommendations on what the settings should be. GigabitEthernet0/1 is up, line protocol is up Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia 001a.6d30.091b) Description: to gig-fastiron Ethernet11 MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 22/255, rxload 46/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 00:22:17 Input queue: 0/75/1191/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 181384000 bits/sec, 29001 packets/sec 30 second output rate 86319000 bits/sec, 26045 packets/sec 38605963 packets input, 4274358612 bytes, 1 no buffer Received 230 broadcasts, 0 runts, 0 giants, 0 throttles 2677 input errors, 0 CRC, 0 frame, 0 overrun, 2677 ignored 0 watchdog, 2196 multicast, 0 pause input 0 input packets with dribble condition detected 34556615 packets output, 1656923135 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 344-300 Tecumseh Rd. E. Windsor, Ontario N8X 5E8 tel. 519-985-8410 fax. 519-985-8409 From leonardo.souza at nec.com.br Fri Sep 12 12:51:50 2008 From: leonardo.souza at nec.com.br (Leonardo Gama Souza) Date: Fri, 12 Sep 2008 13:51:50 -0300 Subject: [c-nsp] ELAM capture on SRB Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E42@spsrvmail03.nec.br> Hi... Does anyone know if it's feasible to use ELAM capture on SRB throttle? I haven't been able to find it. I'd appreciate if someone can share additional information about it. Thanks much! From sthaug at nethelp.no Fri Sep 12 12:53:51 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 12 Sep 2008 18:53:51 +0200 (CEST) Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: <200809121612.16093.ivan@ig.sk> References: <1836781474-1221151128-cardhu_decombobulator_blackberry.rim.net-959829273-@bxe252.bisx.prod.on.blackberry> <20080911.193436.41659240.sthaug@nethelp.no> <200809121612.16093.ivan@ig.sk> Message-ID: <20080912.185351.74695090.sthaug@nethelp.no> > > Highly unlikely. Sampling on the 6500 is performed interely in > > software, *after* the full set of flows has been received. > > You have to distinguish between the cpu load seen as interrupt load > (caused mostly by walking through the TCAM, collecting statistics and > storing them in netflow cache) and the cpu load caused by NDE process > (packet generation). Enabling netflow sampling you can decrease the > second part of the load - the cpu will generate significantly less > packets of export statistics. Good point. And it doesn't help, of course, that the CPU in question is severely underpowered... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From abalashov at evaristesys.com Fri Sep 12 14:14:32 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Fri, 12 Sep 2008 14:14:32 -0400 Subject: [c-nsp] 7206vxr npe300 throughput In-Reply-To: <071c01c91489$006da2f0$0148e8d0$@com> References: <071c01c91489$006da2f0$0148e8d0$@com> Message-ID: <48CAB188.5020004@evaristesys.com> Richey wrote: > I've got a 7206VXR with an NPE 300. It does not run BGP. The majority of > the traffic on this router will be is streaming media. The only ACLs on > this router are there to protect the router it's self. We are talking > about switching the full DS3 that is in this router out for a 100Mb FE feed. > Should I worry about this router being able to handle 80 to 100mb of > traffic? Based on my experience using the same for an edge router of a fairly large company pushing a lot of web traffic and VoIP (well over 100 mbps), no. Just make sure you have CEF enabled and such. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From rodunn at cisco.com Fri Sep 12 14:16:07 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Fri, 12 Sep 2008 14:16:07 -0400 Subject: [c-nsp] NPE-G2 Gigabit Ignored Errors In-Reply-To: <200809121649.m8CGngEV013138@e450.mnsi.net> References: <200809121649.m8CGngEV013138@e450.mnsi.net> Message-ID: <20080912181607.GR4860@rtp-cse-489.cisco.com> Can you bump up your input queue depth: hold-queue 4096 in and see if they stop. I don't suspect that is going to help because the ignores are not increasing that would point to: CSCse05447 Externally found moderate defect: Resolved (R) 7200 ethernet interfaces should not throttle on input queue full drops Most likely you are seeing micro burst that are coming in faster than the CPU can drain the rx ring. Rodney On Fri, Sep 12, 2008 at 12:50:29PM -0400, Clayton Zekelman wrote: > > I'm running a Cisco 7206/VXR with an NPE G2, Version 12.4(4)XD4 > acting as an LNS. > > I'm getting input errors consistently incrementing on the Gig > interface (ignored errors) > > Any way to fix this? I saw some discussion a while back about this, > and it seemed to have to do with buffers - but I can't find any > definitive recommendations on what the settings should be. > > > > GigabitEthernet0/1 is up, line protocol is up > Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia > 001a.6d30.091b) > Description: to gig-fastiron Ethernet11 > MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, > reliability 255/255, txload 22/255, rxload 46/255 > Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set > Keepalive set (10 sec) > Full-duplex, 1000Mb/s, media type is RJ45 > output flow-control is XON, input flow-control is XON > ARP type: ARPA, ARP Timeout 04:00:00 > Last input 00:00:00, output 00:00:00, output hang never > Last clearing of "show interface" counters 00:22:17 > Input queue: 0/75/1191/0 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: fifo > Output queue: 0/40 (size/max) > 30 second input rate 181384000 bits/sec, 29001 packets/sec > 30 second output rate 86319000 bits/sec, 26045 packets/sec > 38605963 packets input, 4274358612 bytes, 1 no buffer > Received 230 broadcasts, 0 runts, 0 giants, 0 throttles > 2677 input errors, 0 CRC, 0 frame, 0 overrun, 2677 ignored > 0 watchdog, 2196 multicast, 0 pause input > 0 input packets with dribble condition detected > 34556615 packets output, 1656923135 bytes, 0 underruns > 0 output errors, 0 collisions, 0 interface resets > 0 babbles, 0 late collision, 0 deferred > 0 lost carrier, 0 no carrier, 0 pause output > 0 output buffer failures, 0 output buffers swapped > out > > > > --- > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 344-300 Tecumseh Rd. E. > Windsor, Ontario > N8X 5E8 > > tel. 519-985-8410 > fax. 519-985-8409 > > _______________________________________________ > 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 rodunn at cisco.com Fri Sep 12 14:17:05 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Fri, 12 Sep 2008 14:17:05 -0400 Subject: [c-nsp] ELAM capture on SRB In-Reply-To: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E42@spsrvmail03.nec.br> References: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E42@spsrvmail03.nec.br> Message-ID: <20080912181705.GS4860@rtp-cse-489.cisco.com> Yes. We use it all the time to match on ingress ip/mpls frames and see what the rewrites are. The complexity comes when you have to understand all the internal dst_indx and internal VLAN allocation details. Rodney On Fri, Sep 12, 2008 at 01:51:50PM -0300, Leonardo Gama Souza wrote: > Hi... > > Does anyone know if it's feasible to use ELAM capture on SRB throttle? > I haven't been able to find it. > I'd appreciate if someone can share additional information about it. > > Thanks much! > _______________________________________________ > 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 Sep 12 14:32:50 2008 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Fri, 12 Sep 2008 20:32:50 +0200 Subject: [c-nsp] Check bandwidth on router In-Reply-To: References: <89944ef40809111754s49466f26w38d25fc90df0b4f5@mail.gmail.com><67F7C1FAF83A074AA3520D8F155782A501D79823@xmb-ams-331.emea.cisco.com> <89944ef40809120653i59281e97h22d206ca3b6092e6@mail.gmail.com> Message-ID: <67F7C1FAF83A074AA3520D8F155782A501D79ACD@xmb-ams-331.emea.cisco.com> Actually, you can use IP SLA for bandwidth testing too. You just need to find some file which can be pulled off the internet via HTTP/FTP, and use IP SLA to get it. The only thing is that you would be killing your user's access to the net at the time of the test, so testing during peak hours would be out of the question, while testing the bandwidth in off-peak hours does not mean much, as the ISP would have extra BW... I would monitor the response time for HTTP for small web sites, and just monitor the trend. The bottom line is that your end users do not really care about the raw amount of bandwidth, but are really looking for good response time and consistent service level. Its called "Quality of Experience" as opposed to "Quality of Service". http://en.wikipedia.org/wiki/Quality_of_Experience Arie -----Original Message----- From: Daniel Hooper [mailto:dhooper at emerge.net.au] Sent: Friday, September 12, 2008 17:38 PM To: root net; Arie Vayner (avayner) Cc: cisco-nsp Subject: RE: [c-nsp] Check bandwidth on router You can use netperf to test bandwidth, cron it to run daily for 10 seconds and it will report the bandwidth on your circuits. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net Sent: Friday, 12 September 2008 9:53 PM To: Arie Vayner (avayner) Cc: cisco-nsp Subject: Re: [c-nsp] Check bandwidth on router IP SLA seems to be the best option at present. Although we monitor with some open source tools. I would like to have a way to check that I am getting what (bandwidth) I am paying for if this makes sense. It seems to me that these programs only monitor the circuits not test throughput. I want to be able to test throughput on the circuit. These third party sites are ok but I am sure there is someway providers are doing this with out using speedtest sites? rootnet On Fri, Sep 12, 2008 at 3:19 AM, Arie Vayner (avayner) wrote: > Dear rootnet, > > Not a direct solution to what you want, but did you consider using IP > SLA for constant performance monitoring? > You can setup a few IP SLA HTTP probes to well known sites and monitor > the performance trend. This would give you a real indication of the > "quality of experience". > > Arie > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net > Sent: Friday, September 12, 2008 03:55 AM > To: cisco-nsp > Subject: [c-nsp] Check bandwidth on router > > Hi List, > > Is there some sort of tool you can load into the IOS on a router to > check bandwidth? Or if not what are you all doing these days in this > situation. > Like for example things are running slow and you think the Internet feed > may be the problem is there a way to do speed tests on the router > itself? > > rootnet > _______________________________________________ > 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 avayner at cisco.com Fri Sep 12 14:38:17 2008 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Fri, 12 Sep 2008 20:38:17 +0200 Subject: [c-nsp] ME3750 Shaping In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B86350AECC47E@exchange.aoihq.local> References: <2C05E949E19A9146AF7BDF9D44085B86350AECC47E@exchange.aoihq.local> Message-ID: <67F7C1FAF83A074AA3520D8F155782A501D79ACF@xmb-ams-331.emea.cisco.com> Eric, This should be possible. Take a look here: http://www.cisco.com/en/US/docs/switches/metro/catalyst3750m/software/re lease/12.2_46_se/configuration/guide/swqos.html Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Eric Van Tol Sent: Friday, September 12, 2008 16:59 PM To: 'cisco-nsp at puck.nether.net' Subject: [c-nsp] ME3750 Shaping Hi all, Does anyone know if the ME3750 can do egress shaping of a particular queue to a limit of >40Mb/s? If so, any examples anyone can share? The goal is to not only police on ingress at a certain limit (25M, 50M, 75M), but also to egress shape at the same limit. I've got the inbound policing just fine, but it seems that the method I found to shape will only do a limit of about 40-50Mb/s. I need to do this on not only non-ES routed ports, but also on non-ES ports that have two VLANs assigned to them, one of which is rate-limited/shaped and one that has WRR with priority queuing. Thanks, evt _______________________________________________ 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 clayton at MNSi.Net Fri Sep 12 14:40:04 2008 From: clayton at MNSi.Net (Clayton Zekelman) Date: Fri, 12 Sep 2008 14:40:04 -0400 Subject: [c-nsp] NPE-G2 Gigabit Ignored Errors In-Reply-To: <20080912181607.GR4860@rtp-cse-489.cisco.com> References: <200809121649.m8CGngEV013138@e450.mnsi.net> <20080912181607.GR4860@rtp-cse-489.cisco.com> Message-ID: <200809121839.m8CIdHD3029666@e450.mnsi.net> No luck... didn't fix it. Is it fixed in a subsequent release? Are there any other parameters I can tune? GigabitEthernet0/1 is up, line protocol is up Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia 001a.6d30.091b) Description: to gig-fastiron Ethernet11 MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 23/255, rxload 48/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 00:10:09 Input queue: 0/4096/533/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 189692000 bits/sec, 30246 packets/sec 30 second output rate 91448000 bits/sec, 27197 packets/sec 18432915 packets input, 1555851456 bytes, 0 no buffer Received 65 broadcasts, 0 runts, 0 giants, 0 throttles 1117 input errors, 0 CRC, 0 frame, 0 overrun, 1117 ignored 0 watchdog, 1034 multicast, 0 pause input 0 input packets with dribble condition detected At 02:16 PM 9/12/2008, Rodney Dunn wrote: >Can you bump up your input queue depth: > >hold-queue 4096 in > >and see if they stop. > >I don't suspect that is going to help because the ignores >are not increasing that would point to: > >CSCse05447 >Externally found moderate defect: Resolved (R) >7200 ethernet interfaces should not throttle on input queue full drops > >Most likely you are seeing micro burst that are coming in faster >than the CPU can drain the rx ring. > >Rodney > > > >On Fri, Sep 12, 2008 at 12:50:29PM -0400, Clayton Zekelman wrote: > > > > I'm running a Cisco 7206/VXR with an NPE G2, Version 12.4(4)XD4 > > acting as an LNS. > > > > I'm getting input errors consistently incrementing on the Gig > > interface (ignored errors) > > > > Any way to fix this? I saw some discussion a while back about this, > > and it seemed to have to do with buffers - but I can't find any > > definitive recommendations on what the settings should be. > > > > > > > > GigabitEthernet0/1 is up, line protocol is up > > Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia > > 001a.6d30.091b) > > Description: to gig-fastiron Ethernet11 > > MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, > > reliability 255/255, txload 22/255, rxload 46/255 > > Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set > > Keepalive set (10 sec) > > Full-duplex, 1000Mb/s, media type is RJ45 > > output flow-control is XON, input flow-control is XON > > ARP type: ARPA, ARP Timeout 04:00:00 > > Last input 00:00:00, output 00:00:00, output hang never > > Last clearing of "show interface" counters 00:22:17 > > Input queue: 0/75/1191/0 (size/max/drops/flushes); Total output drops: 0 > > Queueing strategy: fifo > > Output queue: 0/40 (size/max) > > 30 second input rate 181384000 bits/sec, 29001 packets/sec > > 30 second output rate 86319000 bits/sec, 26045 packets/sec > > 38605963 packets input, 4274358612 bytes, 1 no buffer > > Received 230 broadcasts, 0 runts, 0 giants, 0 throttles > > 2677 input errors, 0 CRC, 0 frame, 0 overrun, 2677 ignored > > 0 watchdog, 2196 multicast, 0 pause input > > 0 input packets with dribble condition detected > > 34556615 packets output, 1656923135 bytes, 0 underruns > > 0 output errors, 0 collisions, 0 interface resets > > 0 babbles, 0 late collision, 0 deferred > > 0 lost carrier, 0 no carrier, 0 pause output > > 0 output buffer failures, 0 output buffers swapped > > out > > > > > > > > --- > > Clayton Zekelman > > Managed Network Systems Inc. (MNSi) > > 344-300 Tecumseh Rd. E. > > Windsor, Ontario > > N8X 5E8 > > > > tel. 519-985-8410 > > fax. 519-985-8409 > > > > _______________________________________________ > > 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/ --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 344-300 Tecumseh Rd. E. Windsor, Ontario N8X 5E8 tel. 519-985-8410 fax. 519-985-8409 From rodunn at cisco.com Fri Sep 12 14:43:04 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Fri, 12 Sep 2008 14:43:04 -0400 Subject: [c-nsp] NPE-G2 Gigabit Ignored Errors In-Reply-To: <200809121839.m8CIdHD3029666@e450.mnsi.net> References: <200809121649.m8CGngEV013138@e450.mnsi.net> <20080912181607.GR4860@rtp-cse-489.cisco.com> <200809121839.m8CIdHD3029666@e450.mnsi.net> Message-ID: <20080912184304.GA4860@rtp-cse-489.cisco.com> On Fri, Sep 12, 2008 at 02:40:04PM -0400, Clayton Zekelman wrote: > > No luck... didn't fix it. Is it fixed in a subsequent release? Are > there any other parameters I can tune? Not really because you can't tune the rx ring depth. Check 'sh controller'. What does 'sh proc cpu sort | excl 0.00' say? Can you post the configuration..I'm curious what your features look like because the more you have the less pps you get through this box..it's all done in software and can't do all features at line rate during a microburst. sh int stat Rodney > > GigabitEthernet0/1 is up, line protocol is up > Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia > 001a.6d30.091b) > Description: to gig-fastiron Ethernet11 > MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, > reliability 255/255, txload 23/255, rxload 48/255 > Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set > Keepalive set (10 sec) > Full-duplex, 1000Mb/s, media type is RJ45 > output flow-control is XON, input flow-control is XON > ARP type: ARPA, ARP Timeout 04:00:00 > Last input 00:00:00, output 00:00:00, output hang never > Last clearing of "show interface" counters 00:10:09 > Input queue: 0/4096/533/0 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: fifo > Output queue: 0/40 (size/max) > 30 second input rate 189692000 bits/sec, 30246 packets/sec > 30 second output rate 91448000 bits/sec, 27197 packets/sec > 18432915 packets input, 1555851456 bytes, 0 no buffer > Received 65 broadcasts, 0 runts, 0 giants, 0 throttles > 1117 input errors, 0 CRC, 0 frame, 0 overrun, 1117 ignored > 0 watchdog, 1034 multicast, 0 pause input > 0 input packets with dribble condition detected > > > > At 02:16 PM 9/12/2008, Rodney Dunn wrote: > >Can you bump up your input queue depth: > > > >hold-queue 4096 in > > > >and see if they stop. > > > >I don't suspect that is going to help because the ignores > >are not increasing that would point to: > > > >CSCse05447 > >Externally found moderate defect: Resolved (R) > >7200 ethernet interfaces should not throttle on input queue full drops > > > >Most likely you are seeing micro burst that are coming in faster > >than the CPU can drain the rx ring. > > > >Rodney > > > > > > > >On Fri, Sep 12, 2008 at 12:50:29PM -0400, Clayton Zekelman wrote: > >> > >> I'm running a Cisco 7206/VXR with an NPE G2, Version 12.4(4)XD4 > >> acting as an LNS. > >> > >> I'm getting input errors consistently incrementing on the Gig > >> interface (ignored errors) > >> > >> Any way to fix this? I saw some discussion a while back about this, > >> and it seemed to have to do with buffers - but I can't find any > >> definitive recommendations on what the settings should be. > >> > >> > >> > >> GigabitEthernet0/1 is up, line protocol is up > >> Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia > >> 001a.6d30.091b) > >> Description: to gig-fastiron Ethernet11 > >> MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, > >> reliability 255/255, txload 22/255, rxload 46/255 > >> Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set > >> Keepalive set (10 sec) > >> Full-duplex, 1000Mb/s, media type is RJ45 > >> output flow-control is XON, input flow-control is XON > >> ARP type: ARPA, ARP Timeout 04:00:00 > >> Last input 00:00:00, output 00:00:00, output hang never > >> Last clearing of "show interface" counters 00:22:17 > >> Input queue: 0/75/1191/0 (size/max/drops/flushes); Total output drops: > >0 > >> Queueing strategy: fifo > >> Output queue: 0/40 (size/max) > >> 30 second input rate 181384000 bits/sec, 29001 packets/sec > >> 30 second output rate 86319000 bits/sec, 26045 packets/sec > >> 38605963 packets input, 4274358612 bytes, 1 no buffer > >> Received 230 broadcasts, 0 runts, 0 giants, 0 throttles > >> 2677 input errors, 0 CRC, 0 frame, 0 overrun, 2677 ignored > >> 0 watchdog, 2196 multicast, 0 pause input > >> 0 input packets with dribble condition detected > >> 34556615 packets output, 1656923135 bytes, 0 underruns > >> 0 output errors, 0 collisions, 0 interface resets > >> 0 babbles, 0 late collision, 0 deferred > >> 0 lost carrier, 0 no carrier, 0 pause output > >> 0 output buffer failures, 0 output buffers swapped > >> out > >> > >> > >> > >> --- > >> Clayton Zekelman > >> Managed Network Systems Inc. (MNSi) > >> 344-300 Tecumseh Rd. E. > >> Windsor, Ontario > >> N8X 5E8 > >> > >> tel. 519-985-8410 > >> fax. 519-985-8409 > >> > >> _______________________________________________ > >> 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/ > > --- > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 344-300 Tecumseh Rd. E. > Windsor, Ontario > N8X 5E8 > > tel. 519-985-8410 > fax. 519-985-8409 From jackson.tim at gmail.com Fri Sep 12 14:46:08 2008 From: jackson.tim at gmail.com (Tim Jackson) Date: Fri, 12 Sep 2008 13:46:08 -0500 Subject: [c-nsp] ELAM capture on SRB In-Reply-To: <20080912181705.GS4860@rtp-cse-489.cisco.com> References: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E42@spsrvmail03.nec.br> <20080912181705.GS4860@rtp-cse-489.cisco.com> Message-ID: <4407932e0809121146y52d9781dpe3deba769dc7988c@mail.gmail.com> The ELAM syntax that worked on SXF doesn't work on SRB though... Mind sharing how to do captures in SRB? -- Tim On Fri, Sep 12, 2008 at 1:17 PM, Rodney Dunn wrote: > Yes. We use it all the time to match on ingress ip/mpls frames and see > what the rewrites are. > > The complexity comes when you have to understand all the internal > dst_indx and internal VLAN allocation details. > > > Rodney > > On Fri, Sep 12, 2008 at 01:51:50PM -0300, Leonardo Gama Souza wrote: > > Hi... > > > > Does anyone know if it's feasible to use ELAM capture on SRB throttle? > > I haven't been able to find it. > > I'd appreciate if someone can share additional information about it. > > > > Thanks much! > > _______________________________________________ > > 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 clayton at MNSi.Net Fri Sep 12 15:02:07 2008 From: clayton at MNSi.Net (Clayton Zekelman) Date: Fri, 12 Sep 2008 15:02:07 -0400 Subject: [c-nsp] NPE-G2 Gigabit Ignored Errors In-Reply-To: <20080912184304.GA4860@rtp-cse-489.cisco.com> References: <200809121649.m8CGngEV013138@e450.mnsi.net> <20080912181607.GR4860@rtp-cse-489.cisco.com> <200809121839.m8CIdHD3029666@e450.mnsi.net> <20080912184304.GA4860@rtp-cse-489.cisco.com> Message-ID: <200809121901.m8CJ1KFO022297@e450.mnsi.net> Here are the sh controller and sh proc results. I'll send the config directly - too much to sanitize ... Thanks! Hardware is MV64460 Internal MAC (Revision MV64460-Ethernet) network link is up Config is 1Gbps, Full Duplex Selected media-type is RJ45 GBIC is not present Ethernet Unit Global Registers: PHY Address = 0x00000820 SMI (PHY Control) = 0x0C001000 Default Address (Err) = 0xFE200000 Default ID (Err) = 0x000001D1 Interrupt Cause = 0x00000210 Interrupt Mask = 0x0000108E Error Address = 0xD7FC6000 Internal Addr Error = 0x00000000 Port Pad Calibration = 0x0013000B Base Address 0 = 0xD7FC0002 Size (BA0) = 0x00030000 Base Address 1 = 0x38002E00 Size (BA1) = 0x03FF0000 Base Address 2 = 0x00000000 Size (BA2) = 0x00000000 Base Address 3 = 0x00000000 Size (BA3) = 0x00000000 Base Address 4 = 0x00000000 Size (BA4) = 0x00000000 Base Address 5 = 0x00000000 Size (BA5) = 0x00000000 Header Retarget Base = 0x00000000 Header Retarget Ctrl = 0x00000000 High Address Remap 0 = 0x00000000 High Address Remap 1 = 0x00000000 Base Address Enable = 0x0000003C Port Access Protect 0 = 0x0000000F Port Access Protect 1 = 0x0000000F Port Access Protect 2 = 0x0000000F MAC Specific Registers: Port Cfg PxC = 0x00000000 Port Cfg Extd PxCX = 0x00000000 MII Serial Params = 0x00218823 GMII Serial Params = 0x00000006 VLAN EtherType EVLANE = 0x00000000 MAC Addr Low MACAL = 0x0000091B MAC Addr High MACAH = 0x001A6D30 SDMA Config SDC = 0x01002005 PORT SERIAL CTRL PSC = 0x00A2A60D PORT STATUS PS = 0x00001C16 TX Queue Cmd TQC = 0x00000000 TxQ Fixed Prio TQFPC = 0x00000001 MTU (Token-Bucket) MTU = 0x00000000 INTR CAUSE IC = 0x80000007 INTR CAUSE EXT ICE = 0x80000001 Intr Mask PIM = 0x00080804 Extend Intr Mask PEIM = 0x00000101 RXQ Desc Ptr 0 CRDP0 = 0xD7FC0F80 RX Queue Cmd RQC = 0x0003FE01 TXQ Desc Ptr 0 TCQDP0 = 0xD7FC1100 TX Curr Desc TCSDP = 0xD7FC1100 MAC Serial Port is ENABLED MAC Autoneg Capability: [Speed] [Duplex] [Flow Control] MAC Status: Link is UP, Speed is 1000Mbps, Duplex is Full, Interface: GMII RX Queue [0] is ENABLED PHY Registers: PHY is Marvell 88E1146C (Rev D0), address 0x0 Control = 0x1000 Status = 0x796D PHY ID 1 = 0x0141 PHY ID 2 = 0x0CD4 Auto Neg Advertisement = 0x0000 Link Partner Ability = 0xCDE1 Auto Neg Expansion = 0x000D Next Page Tx = 0x2001 Link Partner Next Page = 0x4773 1000BaseT Control = 0x0200 1000BaseT Status = 0x3C00 Extended Status = 0x3000 PHY Specific Control = 0x0008 PHY Specific Status = 0xAC00 Interrupt Enable = 0x6C00 Interrupt Status = 0x0000 Ext PHY Spec Control = 0x0CE2 Receive Error Counter = 0x0000 LED Control = 0x4101 Ext PHY Spec Control 2 = 0x000A Ext PHY Spec Status = 0x800B PHY says Link is UP, Speed 1000Mbps, Full-Duplex [AUTONEG Done] AUTONEG - Our ability is 1000M/FD AUTONEG - Partner ability is 1000M/FD 1000M/HD 100M/FD 100M/HD 10M/FD 10M/HD IDB Information: lc_ip_turbo_fs = 0xAB7F4, ip_routecache = 0x11 (dfs = 0/mdfs = 0) rx cache size = 1000, rx cache end = 849 max_mtu = 1528 Software MAC address filter(hash:length/addr/mask/hits): need_af_check = 0 0x00: 0 ffff.ffff.ffff 0000.0000.0000 0 0x5B: 0 0100.5e00.0005 0000.0000.0000 0 0xC0: 0 0100.0ccc.cccc 0000.0000.0000 0 Internal Driver Information: RX Ring base: 0xD7FC0000 TX Ring base: 0xD7FC1000 Software RX Head: 0xD7FC0F40 Hardware RX Head: 0xD7FC0800 Software TX Head: 0xD7FC1080 Hardware TX Head: 0xD7FC2F00 ring sizes: RX = 128, TX = 256 rx_particle_size: 512 rx_pak = 0x0444F908 rx_head = 122 rx_discard = FALSE tx_head = 4, tx_count = 0 chip_state = 2, ds->tx_limited = 0 throttled = 0, enabled = 0, disabled = 11 reset=5(init=1, restart=4), auto_restart=6 tx_underflow = 0, tx_overflow = 0, tx_end_count = 51049471 rx_nobuffer = 0, rx_overrun = 0 rx_no_descriptors = 2115, rx_interrupt_count = 41996968 rx_crc_error = 0, rx_too_big = 0, rx_resource_error = 4629 rx_sop_eop_error = 0 tqc = 0xF1002448, cause = 0xF1002460, cause_ext = 0xF1002464 Address Filter: Promiscuous mode OFF (All other entries are empty) Statistics: Receive and Transmit Statistics: RX Good Octets 45879122062 TX Good Octets 22423886055 RX Good Packets 58699012 TX Good Packets 52765087 RX Bad Octets 0 RX Bad Packets 0 RX Broadcast Packets 289 TX Broadcast Packets 25 RX Multicast Packets 3255 TX Multicast Packets 336 Error Statistics: TX MAC Error 0 TX Excess Collisions 0 RX Bad MAC Ctrl Frame 0 RX Good Flow Control 0 RX Bad Flow Control 0 RX Undersize Paks 0 RX Oversize Paks 0 RX Fragments 0 RX Jabber Paks 0 RX MAC Error Events 0 RX Bad CRC Events 0 RX Collisions 0 RX Late Collisions 0 RX MAC Discard Frame 283215 RX MAC Overrun Frame 0 Total Packets (RX and TX), including errors: 0 -> 64 30696290 65 -> 127 22210681 128 -> 255 9294449 256 -> 511 4627758 512 -> 1023 6428675 1024 -> max 38947325 lns3-Windsor>sh proc cpu sort | excl 0.00 CPU utilization for five seconds: 57%/51%; one minute: 59%; five minutes: 58% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 191 943061842068783944 45 1.80% 1.77% 1.79% 0 PPP Events 150 133733268 50856299 2629 1.06% 1.26% 1.21% 0 AAA SEND STOP EV 58 3289317521961441484 167 0.65% 0.66% 0.65% 0 ATM OAM Input 84 167482244 113323165 1477 0.57% 0.62% 0.64% 0 CEF process 181 9657704-1355730504 0 0.32% 0.37% 0.35% 0 L2X Data Daemon 80 40515732 130839022 309 0.24% 0.24% 0.24% 0 L2TP mgmt daemon 203 35772716 92421692 387 0.24% 0.11% 0.12% 0 OSPF-1 Router 199 388871201904317329 20 0.16% 0.16% 0.16% 0 RADIUS 79 20652720 155060775 133 0.16% 0.12% 0.13% 0 L2X SSS manager 2 355544 10795823 32 0.08% 0.03% 0.02% 0 Load Meter 190 18684041721110574 1 0.08% 0.09% 0.08% 0 PPP manager 66 1206876561422016980 84 0.08% 0.22% 0.19% 0 IP Input 120 7097564 43773086 162 0.08% 0.03% 0.02% 0 PPP Bind 43 4238636 55478504 76 0.08% 0.08% 0.08% 0 Per-Second Jobs 16 198394500 979392997 202 0.08% 0.29% 0.14% 0 EnvMon 82 9579436 68673081 139 0.08% 0.02% 0.01% 0 IP Background 177 328704 541870926 0 0.08% 0.03% 0.02% 0 CCPROXY_CT 173 244061721459348569 16 0.08% 0.04% 0.06% 0 Net Input 73 21365328 131389120 162 0.08% 0.08% 0.08% 0 SSS Manager 62 12653484 48028054 263 0.08% 0.04% 0.06% 0 AAA Server 186 19462048 591135940 32 0.08% 0.06% 0.09% 0 PPPoE Background At 02:43 PM 9/12/2008, Rodney Dunn wrote: >On Fri, Sep 12, 2008 at 02:40:04PM -0400, Clayton Zekelman wrote: > > > > No luck... didn't fix it. Is it fixed in a subsequent release? Are > > there any other parameters I can tune? > >Not really because you can't tune the rx ring depth. > >Check 'sh controller'. > >What does 'sh proc cpu sort | excl 0.00' say? > >Can you post the configuration..I'm curious what your features >look like because the more you have the less pps you get through >this box..it's all done in software and can't do all features at line >rate during a microburst. > >sh int stat > > >Rodney > > > > > > GigabitEthernet0/1 is up, line protocol is up > > Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia > > 001a.6d30.091b) > > Description: to gig-fastiron Ethernet11 > > MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, > > reliability 255/255, txload 23/255, rxload 48/255 > > Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set > > Keepalive set (10 sec) > > Full-duplex, 1000Mb/s, media type is RJ45 > > output flow-control is XON, input flow-control is XON > > ARP type: ARPA, ARP Timeout 04:00:00 > > Last input 00:00:00, output 00:00:00, output hang never > > Last clearing of "show interface" counters 00:10:09 > > Input queue: 0/4096/533/0 (size/max/drops/flushes); Total output drops: 0 > > Queueing strategy: fifo > > Output queue: 0/40 (size/max) > > 30 second input rate 189692000 bits/sec, 30246 packets/sec > > 30 second output rate 91448000 bits/sec, 27197 packets/sec > > 18432915 packets input, 1555851456 bytes, 0 no buffer > > Received 65 broadcasts, 0 runts, 0 giants, 0 throttles > > 1117 input errors, 0 CRC, 0 frame, 0 overrun, 1117 ignored > > 0 watchdog, 1034 multicast, 0 pause input > > 0 input packets with dribble condition detected > > > > > > > > At 02:16 PM 9/12/2008, Rodney Dunn wrote: > > >Can you bump up your input queue depth: > > > > > >hold-queue 4096 in > > > > > >and see if they stop. > > > > > >I don't suspect that is going to help because the ignores > > >are not increasing that would point to: > > > > > >CSCse05447 > > >Externally found moderate defect: Resolved (R) > > >7200 ethernet interfaces should not throttle on input queue full drops > > > > > >Most likely you are seeing micro burst that are coming in faster > > >than the CPU can drain the rx ring. > > > > > >Rodney > > > > > > > > > > > >On Fri, Sep 12, 2008 at 12:50:29PM -0400, Clayton Zekelman wrote: > > >> > > >> I'm running a Cisco 7206/VXR with an NPE G2, Version 12.4(4)XD4 > > >> acting as an LNS. > > >> > > >> I'm getting input errors consistently incrementing on the Gig > > >> interface (ignored errors) > > >> > > >> Any way to fix this? I saw some discussion a while back about this, > > >> and it seemed to have to do with buffers - but I can't find any > > >> definitive recommendations on what the settings should be. > > >> > > >> > > >> > > >> GigabitEthernet0/1 is up, line protocol is up > > >> Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia > > >> 001a.6d30.091b) > > >> Description: to gig-fastiron Ethernet11 > > >> MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, > > >> reliability 255/255, txload 22/255, rxload 46/255 > > >> Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set > > >> Keepalive set (10 sec) > > >> Full-duplex, 1000Mb/s, media type is RJ45 > > >> output flow-control is XON, input flow-control is XON > > >> ARP type: ARPA, ARP Timeout 04:00:00 > > >> Last input 00:00:00, output 00:00:00, output hang never > > >> Last clearing of "show interface" counters 00:22:17 > > >> Input queue: 0/75/1191/0 (size/max/drops/flushes); Total > output drops: > > >0 > > >> Queueing strategy: fifo > > >> Output queue: 0/40 (size/max) > > >> 30 second input rate 181384000 bits/sec, 29001 packets/sec > > >> 30 second output rate 86319000 bits/sec, 26045 packets/sec > > >> 38605963 packets input, 4274358612 bytes, 1 no buffer > > >> Received 230 broadcasts, 0 runts, 0 giants, 0 throttles > > >> 2677 input errors, 0 CRC, 0 frame, 0 overrun, 2677 ignored > > >> 0 watchdog, 2196 multicast, 0 pause input > > >> 0 input packets with dribble condition detected > > >> 34556615 packets output, 1656923135 bytes, 0 underruns > > >> 0 output errors, 0 collisions, 0 interface resets > > >> 0 babbles, 0 late collision, 0 deferred > > >> 0 lost carrier, 0 no carrier, 0 pause output > > >> 0 output buffer failures, 0 output buffers swapped > > >> out > > >> > > >> > > >> > > >> --- > > >> Clayton Zekelman > > >> Managed Network Systems Inc. (MNSi) > > >> 344-300 Tecumseh Rd. E. > > >> Windsor, Ontario > > >> N8X 5E8 > > >> > > >> tel. 519-985-8410 > > >> fax. 519-985-8409 > > >> > > >> _______________________________________________ > > >> 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/ > > > > --- > > Clayton Zekelman > > Managed Network Systems Inc. (MNSi) > > 344-300 Tecumseh Rd. E. > > Windsor, Ontario > > N8X 5E8 > > > > tel. 519-985-8410 > > fax. 519-985-8409 --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 344-300 Tecumseh Rd. E. Windsor, Ontario N8X 5E8 tel. 519-985-8410 fax. 519-985-8409 From rodunn at cisco.com Fri Sep 12 15:07:46 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Fri, 12 Sep 2008 15:07:46 -0400 Subject: [c-nsp] NPE-G2 Gigabit Ignored Errors In-Reply-To: <200809121901.m8CJ1KFO022297@e450.mnsi.net> References: <200809121649.m8CGngEV013138@e450.mnsi.net> <20080912181607.GR4860@rtp-cse-489.cisco.com> <200809121839.m8CIdHD3029666@e450.mnsi.net> <20080912184304.GA4860@rtp-cse-489.cisco.com> <200809121901.m8CJ1KFO022297@e450.mnsi.net> Message-ID: <20080912190746.GC4860@rtp-cse-489.cisco.com> ring sizes: RX = 128, TX = 256 rx_particle_size: 512 rx_pak = 0x0444F908 rx_head = 122 rx_discard = FALSE tx_head = 4, tx_count = 0 chip_state = 2, ds->tx_limited = 0 throttled = 0, enabled = 0, disabled = 11 reset=5(init=1, restart=4), auto_restart=6 tx_underflow = 0, tx_overflow = 0, tx_end_count = 51049471 rx_nobuffer = 0, rx_overrun = 0 rx_no_descriptors = 2115, rx_interrupt_count = 41996968 rx_crc_error = 0, rx_too_big = 0, rx_resource_error = 4629 128 rx ring depth. rx_resource and rx_no_descriptors errors. Whenever there is lack of descriptor to store the incoming packet in the RX ring an ignored/resource error will be reported for the native gige interfaces. Resource error indicates the number of instances when the DMA ran out of Rx descriptors. Ignored indicates the number of packets when the DMA ran out of Rx descriptors. On Fri, Sep 12, 2008 at 03:02:07PM -0400, Clayton Zekelman wrote: > > Here are the sh controller and sh proc results. > > I'll send the config directly - too much to sanitize ... > > Thanks! > > Hardware is MV64460 Internal MAC (Revision MV64460-Ethernet) > network link is up > Config is 1Gbps, Full Duplex > Selected media-type is RJ45 > GBIC is not present > Ethernet Unit Global Registers: > PHY Address = 0x00000820 SMI (PHY Control) = 0x0C001000 > Default Address (Err) = 0xFE200000 Default ID (Err) = 0x000001D1 > Interrupt Cause = 0x00000210 Interrupt Mask = 0x0000108E > Error Address = 0xD7FC6000 Internal Addr Error = 0x00000000 > Port Pad Calibration = 0x0013000B Base Address 0 = 0xD7FC0002 > Size (BA0) = 0x00030000 Base Address 1 = 0x38002E00 > Size (BA1) = 0x03FF0000 Base Address 2 = 0x00000000 > Size (BA2) = 0x00000000 Base Address 3 = 0x00000000 > Size (BA3) = 0x00000000 Base Address 4 = 0x00000000 > Size (BA4) = 0x00000000 Base Address 5 = 0x00000000 > Size (BA5) = 0x00000000 Header Retarget Base = 0x00000000 > Header Retarget Ctrl = 0x00000000 High Address Remap 0 = 0x00000000 > High Address Remap 1 = 0x00000000 Base Address Enable = 0x0000003C > Port Access Protect 0 = 0x0000000F Port Access Protect 1 = 0x0000000F > Port Access Protect 2 = 0x0000000F > > MAC Specific Registers: > Port Cfg PxC = 0x00000000 Port Cfg Extd PxCX = 0x00000000 > MII Serial Params = 0x00218823 GMII Serial Params = 0x00000006 > VLAN EtherType EVLANE = 0x00000000 MAC Addr Low MACAL = 0x0000091B > MAC Addr High MACAH = 0x001A6D30 SDMA Config SDC = 0x01002005 > PORT SERIAL CTRL PSC = 0x00A2A60D PORT STATUS PS = 0x00001C16 > TX Queue Cmd TQC = 0x00000000 TxQ Fixed Prio TQFPC = 0x00000001 > MTU (Token-Bucket) MTU = 0x00000000 INTR CAUSE IC = 0x80000007 > INTR CAUSE EXT ICE = 0x80000001 Intr Mask PIM = 0x00080804 > Extend Intr Mask PEIM = 0x00000101 RXQ Desc Ptr 0 CRDP0 = 0xD7FC0F80 > RX Queue Cmd RQC = 0x0003FE01 TXQ Desc Ptr 0 TCQDP0 = 0xD7FC1100 > TX Curr Desc TCSDP = 0xD7FC1100 > > MAC Serial Port is ENABLED > MAC Autoneg Capability: [Speed] [Duplex] [Flow Control] > MAC Status: Link is UP, Speed is 1000Mbps, Duplex is Full, Interface: GMII > > RX Queue [0] is ENABLED > > PHY Registers: > PHY is Marvell 88E1146C (Rev D0), address 0x0 > Control = 0x1000 Status = 0x796D > PHY ID 1 = 0x0141 PHY ID 2 = > 0x0CD4 > Auto Neg Advertisement = 0x0000 Link Partner Ability = 0xCDE1 > Auto Neg Expansion = 0x000D Next Page Tx = 0x2001 > Link Partner Next Page = 0x4773 1000BaseT Control = 0x0200 > 1000BaseT Status = 0x3C00 Extended Status = 0x3000 > PHY Specific Control = 0x0008 PHY Specific Status = 0xAC00 > Interrupt Enable = 0x6C00 Interrupt Status = 0x0000 > Ext PHY Spec Control = 0x0CE2 Receive Error Counter = 0x0000 > LED Control = 0x4101 > Ext PHY Spec Control 2 = 0x000A Ext PHY Spec Status = 0x800B > PHY says Link is UP, Speed 1000Mbps, Full-Duplex [AUTONEG Done] > > AUTONEG - Our ability is 1000M/FD > AUTONEG - Partner ability is 1000M/FD 1000M/HD 100M/FD 100M/HD 10M/FD > 10M/HD > > IDB Information: > lc_ip_turbo_fs = 0xAB7F4, ip_routecache = 0x11 (dfs = 0/mdfs = 0) > rx cache size = 1000, rx cache end = 849 > max_mtu = 1528 > Software MAC address filter(hash:length/addr/mask/hits): > need_af_check = 0 > 0x00: 0 ffff.ffff.ffff 0000.0000.0000 0 > 0x5B: 0 0100.5e00.0005 0000.0000.0000 0 > 0xC0: 0 0100.0ccc.cccc 0000.0000.0000 0 > > Internal Driver Information: > RX Ring base: 0xD7FC0000 > TX Ring base: 0xD7FC1000 > Software RX Head: 0xD7FC0F40 > Hardware RX Head: 0xD7FC0800 > Software TX Head: 0xD7FC1080 > Hardware TX Head: 0xD7FC2F00 > ring sizes: RX = 128, TX = 256 > rx_particle_size: 512 > rx_pak = 0x0444F908 > rx_head = 122 > rx_discard = FALSE > tx_head = 4, tx_count = 0 > chip_state = 2, ds->tx_limited = 0 > throttled = 0, enabled = 0, disabled = 11 > reset=5(init=1, restart=4), auto_restart=6 > tx_underflow = 0, tx_overflow = 0, tx_end_count = 51049471 > rx_nobuffer = 0, rx_overrun = 0 > rx_no_descriptors = 2115, rx_interrupt_count = 41996968 > rx_crc_error = 0, rx_too_big = 0, rx_resource_error = 4629 > rx_sop_eop_error = 0 > tqc = 0xF1002448, cause = 0xF1002460, cause_ext = 0xF1002464 > Address Filter: > Promiscuous mode OFF > (All other entries are empty) > > Statistics: > > Receive and Transmit Statistics: > RX Good Octets 45879122062 TX Good Octets > 22423886055 > RX Good Packets 58699012 TX Good Packets > 52765087 > RX Bad Octets 0 > RX Bad Packets 0 > RX Broadcast Packets 289 TX Broadcast Packets > 25 > RX Multicast Packets 3255 TX Multicast Packets > 336 > > > Error Statistics: > TX MAC Error 0 > TX Excess Collisions 0 > RX Bad MAC Ctrl Frame 0 > RX Good Flow Control 0 > RX Bad Flow Control 0 > RX Undersize Paks 0 > RX Oversize Paks 0 > RX Fragments 0 > RX Jabber Paks 0 > RX MAC Error Events 0 > RX Bad CRC Events 0 > RX Collisions 0 > RX Late Collisions 0 > RX MAC Discard Frame 283215 > RX MAC Overrun Frame 0 > > Total Packets (RX and TX), including errors: > 0 -> 64 30696290 > 65 -> 127 22210681 > 128 -> 255 9294449 > 256 -> 511 4627758 > 512 -> 1023 6428675 > 1024 -> > max 38947325 > > > > > > > > > lns3-Windsor>sh proc cpu sort | excl 0.00 > CPU utilization for five seconds: 57%/51%; one minute: 59%; five minutes: > 58% > PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process > 191 943061842068783944 45 1.80% 1.77% 1.79% 0 PPP Events > 150 133733268 50856299 2629 1.06% 1.26% 1.21% 0 AAA > SEND STOP EV > 58 3289317521961441484 167 0.65% 0.66% 0.65% 0 ATM OAM Input > 84 167482244 113323165 1477 0.57% 0.62% 0.64% 0 CEF process > 181 9657704-1355730504 0 0.32% 0.37% 0.35% 0 L2X > Data Daemon > > 80 40515732 130839022 309 0.24% 0.24% 0.24% 0 L2TP > mgmt daemon > 203 35772716 92421692 387 0.24% 0.11% 0.12% 0 OSPF-1 Router > 199 388871201904317329 20 0.16% 0.16% 0.16% 0 RADIUS > 79 20652720 155060775 133 0.16% 0.12% 0.13% 0 L2X SSS > manager > 2 355544 10795823 32 0.08% 0.03% 0.02% 0 Load Meter > 190 18684041721110574 1 0.08% 0.09% 0.08% 0 PPP manager > 66 1206876561422016980 84 0.08% 0.22% 0.19% 0 IP Input > 120 7097564 43773086 162 0.08% 0.03% 0.02% 0 PPP Bind > 43 4238636 55478504 76 0.08% 0.08% 0.08% 0 Per-Second > Jobs > 16 198394500 979392997 202 0.08% 0.29% 0.14% 0 EnvMon > 82 9579436 68673081 139 0.08% 0.02% 0.01% 0 IP Background > 177 328704 541870926 0 0.08% 0.03% 0.02% 0 CCPROXY_CT > 173 244061721459348569 16 0.08% 0.04% 0.06% 0 Net Input > 73 21365328 131389120 162 0.08% 0.08% 0.08% 0 SSS Manager > 62 12653484 48028054 263 0.08% 0.04% 0.06% 0 AAA > Server > 186 19462048 591135940 32 0.08% 0.06% 0.09% 0 PPPoE > Background > > > At 02:43 PM 9/12/2008, Rodney Dunn wrote: > >On Fri, Sep 12, 2008 at 02:40:04PM -0400, Clayton Zekelman wrote: > >> > >> No luck... didn't fix it. Is it fixed in a subsequent release? Are > >> there any other parameters I can tune? > > > >Not really because you can't tune the rx ring depth. > > > >Check 'sh controller'. > > > >What does 'sh proc cpu sort | excl 0.00' say? > > > >Can you post the configuration..I'm curious what your features > >look like because the more you have the less pps you get through > >this box..it's all done in software and can't do all features at line > >rate during a microburst. > > > >sh int stat > > > > > >Rodney > > > > > >> > >> GigabitEthernet0/1 is up, line protocol is up > >> Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia > >> 001a.6d30.091b) > >> Description: to gig-fastiron Ethernet11 > >> MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, > >> reliability 255/255, txload 23/255, rxload 48/255 > >> Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set > >> Keepalive set (10 sec) > >> Full-duplex, 1000Mb/s, media type is RJ45 > >> output flow-control is XON, input flow-control is XON > >> ARP type: ARPA, ARP Timeout 04:00:00 > >> Last input 00:00:00, output 00:00:00, output hang never > >> Last clearing of "show interface" counters 00:10:09 > >> Input queue: 0/4096/533/0 (size/max/drops/flushes); Total output > >drops: 0 > >> Queueing strategy: fifo > >> Output queue: 0/40 (size/max) > >> 30 second input rate 189692000 bits/sec, 30246 packets/sec > >> 30 second output rate 91448000 bits/sec, 27197 packets/sec > >> 18432915 packets input, 1555851456 bytes, 0 no buffer > >> Received 65 broadcasts, 0 runts, 0 giants, 0 throttles > >> 1117 input errors, 0 CRC, 0 frame, 0 overrun, 1117 ignored > >> 0 watchdog, 1034 multicast, 0 pause input > >> 0 input packets with dribble condition detected > >> > >> > >> > >> At 02:16 PM 9/12/2008, Rodney Dunn wrote: > >> >Can you bump up your input queue depth: > >> > > >> >hold-queue 4096 in > >> > > >> >and see if they stop. > >> > > >> >I don't suspect that is going to help because the ignores > >> >are not increasing that would point to: > >> > > >> >CSCse05447 > >> >Externally found moderate defect: Resolved (R) > >> >7200 ethernet interfaces should not throttle on input queue full drops > >> > > >> >Most likely you are seeing micro burst that are coming in faster > >> >than the CPU can drain the rx ring. > >> > > >> >Rodney > >> > > >> > > >> > > >> >On Fri, Sep 12, 2008 at 12:50:29PM -0400, Clayton Zekelman wrote: > >> >> > >> >> I'm running a Cisco 7206/VXR with an NPE G2, Version 12.4(4)XD4 > >> >> acting as an LNS. > >> >> > >> >> I'm getting input errors consistently incrementing on the Gig > >> >> interface (ignored errors) > >> >> > >> >> Any way to fix this? I saw some discussion a while back about this, > >> >> and it seemed to have to do with buffers - but I can't find any > >> >> definitive recommendations on what the settings should be. > >> >> > >> >> > >> >> > >> >> GigabitEthernet0/1 is up, line protocol is up > >> >> Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia > >> >> 001a.6d30.091b) > >> >> Description: to gig-fastiron Ethernet11 > >> >> MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, > >> >> reliability 255/255, txload 22/255, rxload 46/255 > >> >> Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set > >> >> Keepalive set (10 sec) > >> >> Full-duplex, 1000Mb/s, media type is RJ45 > >> >> output flow-control is XON, input flow-control is XON > >> >> ARP type: ARPA, ARP Timeout 04:00:00 > >> >> Last input 00:00:00, output 00:00:00, output hang never > >> >> Last clearing of "show interface" counters 00:22:17 > >> >> Input queue: 0/75/1191/0 (size/max/drops/flushes); Total > >output drops: > >> >0 > >> >> Queueing strategy: fifo > >> >> Output queue: 0/40 (size/max) > >> >> 30 second input rate 181384000 bits/sec, 29001 packets/sec > >> >> 30 second output rate 86319000 bits/sec, 26045 packets/sec > >> >> 38605963 packets input, 4274358612 bytes, 1 no buffer > >> >> Received 230 broadcasts, 0 runts, 0 giants, 0 throttles > >> >> 2677 input errors, 0 CRC, 0 frame, 0 overrun, 2677 ignored > >> >> 0 watchdog, 2196 multicast, 0 pause input > >> >> 0 input packets with dribble condition detected > >> >> 34556615 packets output, 1656923135 bytes, 0 underruns > >> >> 0 output errors, 0 collisions, 0 interface resets > >> >> 0 babbles, 0 late collision, 0 deferred > >> >> 0 lost carrier, 0 no carrier, 0 pause output > >> >> 0 output buffer failures, 0 output buffers swapped > >> >> out > >> >> > >> >> > >> >> > >> >> --- > >> >> Clayton Zekelman > >> >> Managed Network Systems Inc. (MNSi) > >> >> 344-300 Tecumseh Rd. E. > >> >> Windsor, Ontario > >> >> N8X 5E8 > >> >> > >> >> tel. 519-985-8410 > >> >> fax. 519-985-8409 > >> >> > >> >> _______________________________________________ > >> >> 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/ > >> > >> --- > >> Clayton Zekelman > >> Managed Network Systems Inc. (MNSi) > >> 344-300 Tecumseh Rd. E. > >> Windsor, Ontario > >> N8X 5E8 > >> > >> tel. 519-985-8410 > >> fax. 519-985-8409 > > --- > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 344-300 Tecumseh Rd. E. > Windsor, Ontario > N8X 5E8 > > tel. 519-985-8410 > fax. 519-985-8409 From eric at atlantech.net Fri Sep 12 15:29:54 2008 From: eric at atlantech.net (Eric Van Tol) Date: Fri, 12 Sep 2008 15:29:54 -0400 Subject: [c-nsp] ME3750 Shaping In-Reply-To: <67F7C1FAF83A074AA3520D8F155782A501D79ACF@xmb-ams-331.emea.cisco.com> References: <2C05E949E19A9146AF7BDF9D44085B86350AECC47E@exchange.aoihq.local> <67F7C1FAF83A074AA3520D8F155782A501D79ACF@xmb-ams-331.emea.cisco.com> Message-ID: <2C05E949E19A9146AF7BDF9D44085B86350AECC484@exchange.aoihq.local> > From: Arie Vayner (avayner) [mailto:avayner at cisco.com] > > Eric, > > This should be possible. > Take a look here: > http://www.cisco.com/en/US/docs/switches/metro/catalyst3750m/software/re > lease/12.2_46_se/configuration/guide/swqos.html > > Arie Hi Arie, Thanks for the response. I've read this a bunch of times and it seems to me that the proper (and possibly only?) way to do egress shaping is by using the 'srr-queue bandwidth shape' command, which gives you options to set different weights for the queues. The formula for the weights indicates that the weight is a fractional number of the total amount of bandwidth for the port. For a 100M port, a weight of 8 would equal 12.5 percent, or 12.5Mb/s. So, using that formula, if I want to get 50Mb/s shaping on a queue, I use 2 as the number. What about 75Mb/s, or even something else between 50M and 99M? I can't use a floating point, so it looks like I'm pretty much stuck at 1/2 of the bandwidth of the port. Or am I misunderstanding the srr-queue settings entirely (which could certainly be the case)? Thanks, evt From ivan at ig.sk Fri Sep 12 15:32:02 2008 From: ivan at ig.sk (Ivan Gasparik) Date: Fri, 12 Sep 2008 21:32:02 +0200 Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: <49999c420809111009ga56f9a1ie60f163c4b87748e@mail.gmail.com> References: <49999c420809111009ga56f9a1ie60f163c4b87748e@mail.gmail.com> Message-ID: <20080912193202.GI4986@hq.ig.sk> It depends on the amount of traffic you are planning to analyze. In my experience from ISP environment a 3BXL with 256000 netflow entries can handle about 3Gb/s of average internet traffic without overrunning the netflow cache. But you have to use really aggressive timers to force flows time out very quickly and to make space for newly created flow entries. Big guys would say, move to CRS with 1024000 netflow entries per slot and more powerful CPU's ;-) I plan to try the way mentioned by you - mirroring traffic to some fprobe server. Is here somebody running external server for netflow analysis? I would be interrested in your experiences, especially what hardware is needed for processing 10Gb/s of traffic? Ivan On Fri, Sep 12, 2008 at 01:09:05AM +0800, cc loo wrote: > I was wondering if mirroring the traffic into a server with Netflow probes > (such as fprobe) to help relieving the stress on router's CPU would be a > wise move ? > Is this move common in ISP environments or do most of the big guys just > leave the exporting from routers to collectors ? > > > > On Thu, Sep 11, 2008 at 11:50 PM, Jon Lewis wrote: > > > I've got a 6509 with sup720-3bxl running 12.2(18)SXD7b. It's forwarding > > several hundred mbit/s across a number of gig ports on WS-X6416-GBIC cards. > > > > I've noticed it's gotten very slow at certain things (like write mem), and > > when looking at the switch (remote command switch show proc cpu), I was kind > > of shocked to see 85% CPU utilization or higher across all time avgs. The > > biggest CPU eating process seems to be netflow export > > > > 223 2563111984 126342970 20287 38.27% 42.39% 42.03% 0 NDE - IPV4 > > > > Other than disabling export or moving traffic off this device, are there > > things I can do to tone this down? The couple hundred mbit/s this switch is > > forwarding is supposed to be no big deal for this platform. > > > > ---------------------------------------------------------------------- > > Jon Lewis | I route > > Senior Network Engineer | therefore you are > > Atlantic Net | > > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > _______________________________________________ > > cisco-nsp mailing list cisco-nsp 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 ross at kallisti.us Fri Sep 12 16:46:29 2008 From: ross at kallisti.us (Ross Vandegrift) Date: Fri, 12 Sep 2008 16:46:29 -0400 Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: <20080912193202.GI4986@hq.ig.sk> References: <49999c420809111009ga56f9a1ie60f163c4b87748e@mail.gmail.com> <20080912193202.GI4986@hq.ig.sk> Message-ID: <20080912204629.GA30228@kallisti.us> On Fri, Sep 12, 2008 at 09:32:02PM +0200, Ivan Gasparik wrote: > I plan to try the way mentioned by you - mirroring traffic to > some fprobe server. Is here somebody running external server for > netflow analysis? I would be interrested in your experiences, > especially what hardware is needed for processing 10Gb/s of > traffic? I haven't done anything up to 10G, but I've mirrored transit interfaces to servers for netflow collection as a demo. I'd say it was around 500M of live traffic. I was using pmacctd to generate netflow v9 records with src/dest IP, proto, ports, and src/dest AS. A quad-core 2GHz Xeon could just about keep up with a 500M mirror session per cpu, running one instance per mirror session. -- Ross Vandegrift ross at kallisti.us "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 From troy at i2bnetworks.com Fri Sep 12 20:24:47 2008 From: troy at i2bnetworks.com (Troy Beisigl) Date: Fri, 12 Sep 2008 17:24:47 -0700 Subject: [c-nsp] Filter Material Message-ID: <993C93CA-E710-4148-9BE1-A27AE9C071D1@i2bnetworks.com> This may sound like a dumb question, but does anyone know where the filter material can be acquired that is used on the 7500 and 12008 routers chassis? Thanks, -Troy From jlewis at lewis.org Fri Sep 12 20:57:33 2008 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 12 Sep 2008 20:57:33 -0400 (EDT) Subject: [c-nsp] 6500 netflow export and the switch cpu In-Reply-To: <001b01c91472$5398cd40$faca67c0$@steele@internode.on.net> References: <48C94727.4030002@imperial.ac.uk> <001b01c91472$5398cd40$faca67c0$@steele@internode.on.net> Message-ID: On Fri, 12 Sep 2008, Ben Steele wrote: > "It looks like the fix was to enable flow-sampling." > > Out of curiosity what are you using your netflow for? I'm asking because > sampling obviously isn't ideal when you are trying to get completely > accurate data for accounting. Mostly for abuse tracking/corroboration. For this purpose, sampled should be good enough in most cases. If I could have full netflow, I'd like it, but it looks as if we've hit another unanticipated hardware limitation with our cisco gear. > It feels a shame using DFC's for a margin of their capacity purely because > you need the TCAM space to produce netflow. Kind of like using Sup720-3bxls to handle a few hundred mbit/s of traffic just to be able to take full routes. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From frnkblk at iname.com Sat Sep 13 00:48:31 2008 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 12 Sep 2008 23:48:31 -0500 Subject: [c-nsp] Cisco 2955T-12 at 12 VDC? Message-ID: The specs say it requires 24 VDC, but I'm wondering if anyone has successfully operated the 2955T-12 at 12 VDC? Frank From frnkblk at iname.com Sat Sep 13 00:55:08 2008 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 12 Sep 2008 23:55:08 -0500 Subject: [c-nsp] how to accomplish multiple 'native' vlans In-Reply-To: References: Message-ID: Chris: Your initial e-mail indicated the tagging opposite to what you said in this latest e-mail. =) I think these commands are supported in most switches/software releases. Frank -----Original Message----- From: Chris Hale [mailto:chale99 at gmail.com] Sent: Friday, September 12, 2008 8:36 AM To: Frank Bulk; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] how to accomplish multiple 'native' vlans Thanks Frank. This looks almost exactly what I was looking for, but the VLANs would be switched around: VID 10 would come through tagged (i.e. equipment mgmt VID) and VID 100/101 (i.e. customer VID) would come through untagged. Is this only on the newer switches? I seem to remember I had to carry the native vlan throughout the uplinks on an older 3550. Thanks, Chris On Thu, Sep 11, 2008 at 12:54 AM, Frank Bulk wrote: > Chris: > > Each port can be assigned a unique untagged VLAN (switchport trunk native > vlan xx). You can limit which VLANs are trunked by assigning the allowed > VLANs (switchport trunk allowed vlan yy). You can then create an uplink > port with all those trunks. > > I think this is what you're looking for. > > Here's an example: > > interface FastEthernet0/1 > description Customer A > switchport mode trunk > switchport nonegotiate > switchport trunk native vlan 10 > switchport trunk allowed vlan 100 > ! > interface FastEthernet0/2 > description Customer B > switchport mode trunk > switchport nonegotiate > switchport trunk native vlan 10 > switchport trunk allowed vlan 101 > ! > interface FastEthernet0/24 > description Uplink > switchport mode trunk > switchport nonegotiate > switchport trunk allowed vlan 10, 100, 101 > ! > > Frank > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Chris Hale > Sent: Wednesday, September 10, 2008 11:35 PM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] how to accomplish multiple 'native' vlans > > All - > > We are converting our L2 network from Riverstone to Cisco. One > problem I have not been able to solve yet is the way the Riverstone > and Cisco units handle untagged traffic entering a physical port. We > have many connections to customers whereby we have equipment we would > like to manage with management VIDs inline with untagged customer > traffic. When it enters the Ethernet trunk port on the Riverstone, we > are able to assign the untagged traffic to a VID and it traverses the > trunk ports where allowed as tagged traffic. It doesn't seem like the > Cisco switches have this ability - only one native VLAN per switch. > Is there some way to accept multiple ports of untagged traffic and tag > each ports' untagged traffic with separate VIDs? > > Example: > > fa0/1 - mgmt VID 10, customer traffic untagged (needs to be tagged > with VID 100 for L3 routing) > fa0/2 - mgmt VID 10, customer traffic untagged (needs to be tagged > with VID 101 for L3 routing) > etc. > fa0/24 - trunk port to L3 device > > We are using 2960 and 3560 switches. Any other ideas are welcome, but > we would prefer to minimize any CPE equipment at customer site to tag > their traffic with the appropriate customer VID. It's a matter of > additional cost, additional management devices, and additional points > of failure. > > Thanks, > Chris > > -- > ------------------ > Chris Hale > chale99 at gmail.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/ > > -- ------------------ Chris Hale chale99 at gmail.com From iam at st-andrews.ac.uk Sat Sep 13 04:04:02 2008 From: iam at st-andrews.ac.uk (Ian McDonald) Date: Sat, 13 Sep 2008 09:04:02 +0100 Subject: [c-nsp] Cisco 2955T-12 at 12 VDC? In-Reply-To: References: Message-ID: <48CB73F2.8060308@st-andrews.ac.uk> Frank Bulk wrote: > The specs say it requires 24 VDC, but I'm wondering if anyone has > successfully operated the 2955T-12 at 12 VDC? > > Frank > > _______________________________________________ > 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/ > > The spec sheet does say 18V minimum. However, you could use one of the magic devices people buy so they can use their 18-24V accessories in their 12V motor cars. Total output load by Cisco's spec sheet is 23W maximum, which is just under an Amp at 24V. Hence this regulated 2.5A model would be plenty sufficient to make it work from 12V. http://www.quasarelectronics.com/cva540.htm I'm sure you can find similar wherever in the world you are. HTH -- ian From will at harg.net Sat Sep 13 04:12:32 2008 From: will at harg.net (Will Hargrave) Date: Sat, 13 Sep 2008 09:12:32 +0100 Subject: [c-nsp] 100FX Ports or Media Convertors? In-Reply-To: References: Message-ID: <48CB75F0.9070805@harg.net> Justin M. Streiner wrote: > I have a few devices and buildings on campus that I feed at 100FX, both > from 4500s with MTRJ blades and from 3750s with the 100FX SFPs and both > seem to be pretty reliable. I haven't seen the 'live' failure rates on > the 100FX SFPs to be much better or worse than the GE SFPs we use all > over the place. We have been using 3750G-12 + 100FX SFPs for 100FX distribution out there at sites. Although it's expensive at the start the advantage is a very easy upgrade to gigabit. Previous to that we did use 3550+6-way 100FX media convertors, specifically the 6-in-1u allied telesyn things, which worked well enough. We have had some problems with the 3750G+100FX SFP combination insofar as the 100FX SFPs get very hot in those boxes and in less well specified locations have a tendency to overheat and fail. This accelerated our upgrade plan in one location to upgrade the edge (Cat 1900 -> Extreme x250e in fact) and I think the 1000SX SFPs run a lot cooler. In the area of larger sites where we have 6500s, especially given the lack of 100FX support in newer edge switches, we are just trying to get links up to gigabit. The length constraints can be a major pain, we're using a combination of replacement with singlemode or 1000LX + mode conditioning cables (550m over 62.5/125). We don't really want to buy 100FX stuff for the 6500 due to the limited benefit and lifetime. Will From eric at atlantech.net Sat Sep 13 09:07:11 2008 From: eric at atlantech.net (Eric Van Tol) Date: Sat, 13 Sep 2008 09:07:11 -0400 Subject: [c-nsp] ME3750 Shaping In-Reply-To: <8B25B862BC09784B9B74FB950D4F64D401F7B4@qcnapp01.corp.qcn> References: <2C05E949E19A9146AF7BDF9D44085B86350AECC47E@exchange.aoihq.local><67F7C1FAF83A074AA3520D8F155782A501D79ACF@xmb-ams-331.emea.cisco.com> <2C05E949E19A9146AF7BDF9D44085B86350AECC484@exchange.aoihq.local> <8B25B862BC09784B9B74FB950D4F64D401F7B4@qcnapp01.corp.qcn> Message-ID: <2C05E949E19A9146AF7BDF9D44085B86350AECC489@exchange.aoihq.local> >From: Brad Henshaw [mailto:brad.henshaw at qcn.com.au] >Sent: Saturday, September 13, 2008 8:58 AM >To: Eric Van Tol; Arie Vayner (avayner); cisco-nsp at puck.nether.net >Subject: RE: [c-nsp] ME3750 Shaping > >You can also do egress rate limitation - 'srr-queue bandwidth limit ><10..90>' > >This limits the egress rate to a percentage of the physical port speed. > >Regards, >Brad Yes, but this is a limit for all 4 queues combined. It may work for the layer 3 ports, but not meet the requirements of the layer 2 trunk port with 2 VLANs on it. -evt From dogbohn at gmail.com Sat Sep 13 09:40:29 2008 From: dogbohn at gmail.com (dog bone) Date: Sat, 13 Sep 2008 09:40:29 -0400 Subject: [c-nsp] DHCP snooping and DAI Message-ID: <2d3f58800809130640o4f290e24od6f6d5d521176cb4@mail.gmail.com> Hello, I have been researching defenses against so-called 'man-in-the-middle' attacks at layer 2. We tried this around three years ago with 3550-48 smi image using dhcp snooping and dynamic arp inspection. After a time the switch stopped passing dhcp requests. This was in production, (though thankfully on only one switch) so we didn't have time to troubleshoot the precise nature of the problem, and gave up on the feature as being 'not ready for prime-time.' Since that time, Cisco seems to have changed the approach slightly. Cisco documentation regarding the dhcp database states : "Because both NVRAM and the flash memory have limited storage capacities, we recommend that you store a binding file on a TFTP server. You must create an empty file at the configured URL on network-based URLs (such as TFTP and FTP) before the switch can first write bindings to the binding file at that URL." AhhHaaa, I had suspected that the switch ran out of memory. Now we would like to try it again. Our network is pretty standard, 6500's at core, 4500 distribution and we will upgrade to either 3560's or 3750's at the edge (around 200 edge switches.) I would appreciate hearing from anyone who has used these features. My concerns to start out with are: 1. What will happen if the switch loses communication with the database server for some reason? Will the switch stop passing traffic entirely? 2. How much traffic will the checking generate? Is the switch going to reach out to the database for each flow? If not, how does the switch use the databas I am sure there are many more questions and concerns, I simply don't know what I don't know :-) Thanks, dennis From brad.henshaw at qcn.com.au Sat Sep 13 08:58:03 2008 From: brad.henshaw at qcn.com.au (Brad Henshaw) Date: Sat, 13 Sep 2008 22:58:03 +1000 Subject: [c-nsp] ME3750 Shaping References: <2C05E949E19A9146AF7BDF9D44085B86350AECC47E@exchange.aoihq.local><67F7C1FAF83A074AA3520D8F155782A501D79ACF@xmb-ams-331.emea.cisco.com> <2C05E949E19A9146AF7BDF9D44085B86350AECC484@exchange.aoihq.local> Message-ID: <8B25B862BC09784B9B74FB950D4F64D401F7B4@qcnapp01.corp.qcn> Eric Van Tol wrote: > it seems to me that the proper (and possibly only?) way to do > egress shaping is by using the 'srr-queue bandwidth shape' command You can also do egress rate limitation - 'srr-queue bandwidth limit <10..90>' This limits the egress rate to a percentage of the physical port speed. Regards, Brad From lowen at pari.edu Sat Sep 13 11:04:25 2008 From: lowen at pari.edu (Lamar Owen) Date: Sat, 13 Sep 2008 11:04:25 -0400 Subject: [c-nsp] 100FX Ports or Media Convertors? In-Reply-To: <48CB75F0.9070805@harg.net> References: Message-ID: <200809131104.25816.lowen@pari.edu> On Saturday 13 September 2008 04:12:32 Will Hargrave wrote: > In the area of larger sites where we have 6500s, especially given the > lack of 100FX support in newer edge switches, we are just trying to get > links up to gigabit. The length constraints can be a major pain, we're > using a combination of replacement with singlemode or 1000LX + mode > conditioning cables (550m over 62.5/125). We don't really want to buy > 100FX stuff for the 6500 due to the limited benefit and lifetime. The length issues for 1000BaseSX and LX have hit us, too. We have a number of older 62.5/125 multimode runs that are beyond the reach of LX (600-900 meters) but work great at 100BFX. Since we're using older gear anyway, I was ble to find 24 port 100BFX cards for our Catalyst 550x's and 85x0's that works very well for this sort of run. Until I can get those locations upgraded to singlemode fiber (which is going to be a while; no pressing bandwidth need for those sites, since they only have a half dozen or less endpoints at each location) we'll be running the 5505's and 5509 with 100bFX links. Honestly, I've not found a feature the 6500 provides other tha QoS that would make a very expensive upgrade like that worth it. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 http://www.pari.edu From brad.henshaw at qcn.com.au Sat Sep 13 11:22:30 2008 From: brad.henshaw at qcn.com.au (Brad Henshaw) Date: Sun, 14 Sep 2008 01:22:30 +1000 Subject: [c-nsp] ME3750 Shaping References: <2C05E949E19A9146AF7BDF9D44085B86350AECC47E@exchange.aoihq.local><67F7C1FAF83A074AA3520D8F155782A501D79ACF@xmb-ams-331.emea.cisco.com> <2C05E949E19A9146AF7BDF9D44085B86350AECC484@exchange.aoihq.local> <8B25B862BC09784B9B74FB950D4F64D401F7B4@qcnapp01.corp.qcn> <2C05E949E19A9146AF7BDF9D44085B86350AECC489@exchange.aoihq.local> Message-ID: <8B25B862BC09784B9B74FB950D4F64D401F7B5@qcnapp01.corp.qcn> Eric Van Tol wrote: >>You can also do egress rate limitation - 'srr-queue bandwidth limit ><10..90>' >> >>This limits the egress rate to a percentage of the physical port speed. > > Yes, but this is a limit for all 4 queues combined. It may work for the > layer 3 ports, but not meet the requirements of the layer 2 trunk port with > 2 VLANs on it. Ah. I didn't notice the requirement to shape only one queue. In that case, then yes I believe your understanding of WRR shaping is correct. What exactly are you trying to achieve on the trunk ports? A separate rate for each VLAN? (with associated CoS or DSCP hacking on ingress)? If this is the case you're probably better off wasting a port per VLAN or otherwise freeing up an ES port. (if only the stackwise ports on the ME's were functional) Regards, Brad From dudepron at gmail.com Sat Sep 13 13:02:01 2008 From: dudepron at gmail.com (Aaron) Date: Sat, 13 Sep 2008 13:02:01 -0400 Subject: [c-nsp] Filter Material In-Reply-To: <993C93CA-E710-4148-9BE1-A27AE9C071D1@i2bnetworks.com> References: <993C93CA-E710-4148-9BE1-A27AE9C071D1@i2bnetworks.com> Message-ID: <480dad640809131002o56d24b29t124749e0348c09ae@mail.gmail.com> Cisco. The replacement parts are cheap. On Fri, Sep 12, 2008 at 8:24 PM, Troy Beisigl wrote: > This may sound like a dumb question, but does anyone know where the filter > material can be acquired that is used on the 7500 and 12008 routers chassis? > > Thanks, > > -Troy > > > > _______________________________________________ > 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 paul at paulstewart.org Sat Sep 13 13:01:57 2008 From: paul at paulstewart.org (Paul Stewart) Date: Sat, 13 Sep 2008 13:01:57 -0400 Subject: [c-nsp] igp / ebgp problem ipv6 Message-ID: <000901c915c2$8c1a6ab0$a44f4010$@org> Hi there. We have our first IPv6 block advertising to the world (for quite a while now) and have started to actually route some small blocks of it internally via OSPF. Our /32 is advertised via eBGP no problem and the world can see it.. Internally, we have a series of /128 loopbacks, /126 point to points, and a /64 block setup for some servers. Obviously all small chunks of the /32 assignment. My problem is that the world can reach our border routers but traffic will not route beyond the border. Internally, we can route traffic no problem.. Config looks basically like this: router bgp 00000 address-family ipv6 no synchronization network 0000:0000::/32 ipv6 route 0000:0000::/32 Null0 ipv6 router ospf 1 log-adjacency-changes default-information originate redistribute connected Then the applicable nei statements and ospf for IPv6 is enabled on certain interfaces... Could post more config but hopefully this triggers someone with an answer ;) The block is showing fine as a /32 to the world and internally everything is reachable via ospf.. I know it has something to do with the small subnets inside of the /32 but drawing a blank.. Thanks ;) Paul From gert at greenie.muc.de Sat Sep 13 13:48:25 2008 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 13 Sep 2008 19:48:25 +0200 Subject: [c-nsp] igp / ebgp problem ipv6 In-Reply-To: <000901c915c2$8c1a6ab0$a44f4010$@org> References: <000901c915c2$8c1a6ab0$a44f4010$@org> Message-ID: <20080913174825.GA17238@greenie.muc.de> Hi, On Sat, Sep 13, 2008 at 01:01:57PM -0400, Paul Stewart wrote: > My problem is that the world can reach our border routers but traffic will > not route beyond the border. Internally, we can route traffic no problem.. Have you turned on IPv6 *forwarding* on the box? You need "ipv6 unicast-routing" - otherwise IOS will speak IPv6 just fine, but not forward packets (behave as an IPv6 Host). 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: 304 bytes Desc: not available URL: From berni at birkenwald.de Sat Sep 13 13:51:50 2008 From: berni at birkenwald.de (Bernhard Schmidt) Date: Sat, 13 Sep 2008 17:51:50 +0000 (UTC) Subject: [c-nsp] igp / ebgp problem ipv6 References: <000901c915c2$8c1a6ab0$a44f4010$@org> Message-ID: Paul Stewart wrote: Hello Paul, > We have our first IPv6 block advertising to the world (for quite a while > now) and have started to actually route some small blocks of it internally > via OSPF. Our /32 is advertised via eBGP no problem and the world can see > it.. > > Internally, we have a series of /128 loopbacks, /126 point to points, and a > /64 block setup for some servers. Obviously all small chunks of the /32 > assignment. > > My problem is that the world can reach our border routers but traffic will > not route beyond the border. Internally, we can route traffic no problem.. My first guess would be that your inbound traffic is routed just fine, but your internal routers have no route back. This looks like blackholing in a traceroute from an external host. Check both "sh ipv6 route " and "sh ipv6 route " on all routers in the path, I guess the first one will return a valid route on all your routers but the second one only on your edge. You need to tell your internal routers how to get out of your network. If you only have one edge router you can put a default route into OSPF. You have "default-information originate" in there already, this will only work if your edge router really has an exact ::/0 route in his table. Check for that and add "default-information originate always" if it doesn't. Bernhard From paul at paulstewart.org Sat Sep 13 13:54:05 2008 From: paul at paulstewart.org (Paul Stewart) Date: Sat, 13 Sep 2008 13:54:05 -0400 Subject: [c-nsp] igp / ebgp problem ipv6 In-Reply-To: <20080913174825.GA17238@greenie.muc.de> References: <000901c915c2$8c1a6ab0$a44f4010$@org> <20080913174825.GA17238@greenie.muc.de> Message-ID: <002801c915c9$bdb11a40$39134ec0$@org> Thank you.. yes, we have enabled it everywhere.... Basically a pair of 6509's and a pair of 7606's and they all talk back and forth. It's in the "linkage" on the 7606's between BGP and OSPF where the problem seems to lie....;) I can run traceroutes and ping IP's across the internal network no problem.... Best regards, Paul -----Original Message----- From: Gert Doering [mailto:gert at greenie.muc.de] Sent: September 13, 2008 1:48 PM To: Paul Stewart Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] igp / ebgp problem ipv6 Hi, On Sat, Sep 13, 2008 at 01:01:57PM -0400, Paul Stewart wrote: > My problem is that the world can reach our border routers but traffic > will not route beyond the border. Internally, we can route traffic no problem.. Have you turned on IPv6 *forwarding* on the box? You need "ipv6 unicast-routing" - otherwise IOS will speak IPv6 just fine, but not forward packets (behave as an IPv6 Host). 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 avayner at cisco.com Sat Sep 13 13:54:25 2008 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Sat, 13 Sep 2008 19:54:25 +0200 Subject: [c-nsp] ME3750 Shaping In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B86350AECC484@exchange.aoihq.local> References: <2C05E949E19A9146AF7BDF9D44085B86350AECC47E@exchange.aoihq.local> <67F7C1FAF83A074AA3520D8F155782A501D79ACF@xmb-ams-331.emea.cisco.com> <2C05E949E19A9146AF7BDF9D44085B86350AECC484@exchange.aoihq.local> Message-ID: <67F7C1FAF83A074AA3520D8F155782A501D79B57@xmb-ams-331.emea.cisco.com> Eric, Take a 2nd look here: http://www.cisco.com/en/US/docs/switches/metro/catalyst3750m/software/re lease/12.2_46_se/configuration/guide/swqos.html#wp1282429 Arie -----Original Message----- From: Eric Van Tol [mailto:eric at atlantech.net] Sent: Friday, September 12, 2008 22:30 PM To: Arie Vayner (avayner); cisco-nsp at puck.nether.net Subject: RE: [c-nsp] ME3750 Shaping > From: Arie Vayner (avayner) [mailto:avayner at cisco.com] > > Eric, > > This should be possible. > Take a look here: > http://www.cisco.com/en/US/docs/switches/metro/catalyst3750m/software/ > re lease/12.2_46_se/configuration/guide/swqos.html > > Arie Hi Arie, Thanks for the response. I've read this a bunch of times and it seems to me that the proper (and possibly only?) way to do egress shaping is by using the 'srr-queue bandwidth shape' command, which gives you options to set different weights for the queues. The formula for the weights indicates that the weight is a fractional number of the total amount of bandwidth for the port. For a 100M port, a weight of 8 would equal 12.5 percent, or 12.5Mb/s. So, using that formula, if I want to get 50Mb/s shaping on a queue, I use 2 as the number. What about 75Mb/s, or even something else between 50M and 99M? I can't use a floating point, so it looks like I'm pretty much stuck at 1/2 of the bandwidth of the port. Or am I misunderstanding the srr-queue settings entirely (which could certainly be the case)? Thanks, evt From Jaime at ulima.edu.pe Sat Sep 13 14:30:04 2008 From: Jaime at ulima.edu.pe (Velasquez Venegas Jaime Omar) Date: Sat, 13 Sep 2008 13:30:04 -0500 Subject: [c-nsp] NTP not synchronizing Message-ID: <8DD1F4B50477AC45A35AB5F8C03B62C4018567AB@sauce.ulima.ul> Hi there. I'm having a problem trying to synchronize a Cisco Router across a wan link with a NTP Server (No-Cisco router).So far i've ruled out packet filering or firewall blocking as a cause of this.Some other equipments at the local side of this router actually synchronize with the ntp server at our LAN.What strikes me is the fact that router does reach ntp server via other protocols other than ntp tough. This is what i get from the out-of-sync router: #Show ntp assoc address ref clock st when poll reach delay offset disp ~<> 0.0.0.0 16 - 64 0 0.0 0.00 16000. * master (synced), # master (unsynced), + selected, - candidate, ~ configured I've set debugging for the ntp packets and for all the traffic getting out of the serial interface which got "NTP: xmit packet to NTP.Server" events.However there 's absolutely no attempt whatsoever of packet being transmitted to NTP Server at the serial interface. I've also configured this router as a ntp master and tried to get the hosts on its local ethernet to synchronize with it to no avail. Any insight? Thanks From paul at paulstewart.org Sat Sep 13 15:12:28 2008 From: paul at paulstewart.org (Paul Stewart) Date: Sat, 13 Sep 2008 15:12:28 -0400 Subject: [c-nsp] igp / ebgp problem ipv6 In-Reply-To: References: <000901c915c2$8c1a6ab0$a44f4010$@org> Message-ID: <002901c915d4$b19bfd50$14d3f7f0$@org> Thank you very much Bernhard.... the lack of "always" was it... damn, should have it know from Ipv4..;) Works perfect now, have a linux box up on IPv6 and looks good.. [paul at netops ~]$ traceroute6 www.he.net traceroute to www.he.net (2001:470:0:76::2), 30 hops max, 40 byte packets 1 (2607:f1f0:0:1::1) 0.945 ms 1.004 ms 1.093 ms 2 (2607:f1f0::d) 2.183 ms 2.214 ms 2.242 ms 3 (2607:f1f0::9) 4.497 ms 4.528 ms 4.604 ms 4 (2607:f1f0::2) 4.534 ms 4.610 ms 4.639 ms 5 2001:470:1f0d:89::1 (2001:470:1f0d:89::1) 32.940 ms 32.971 ms 33.056 ms 6 v104.core1.ash1.he.net (2001:470:0:40::2) 32.414 ms 41.266 ms 31.780 ms 7 10gigabitethernet1-4.core1.pao1.he.net (2001:470:0:35::1) 107.852 ms 107.872 ms 107.897 ms 8 gige-g1-2.core1.fmt1.he.net (2001:470:0:2e::1) 107.188 ms 107.907 ms 107.956 ms 9 he.net (2001:470:0:76::2) 106.569 ms 106.609 ms 106.754 ms Best regards, Paul -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Bernhard Schmidt Sent: September 13, 2008 1:52 PM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] igp / ebgp problem ipv6 Paul Stewart wrote: Hello Paul, > We have our first IPv6 block advertising to the world (for quite a while > now) and have started to actually route some small blocks of it internally > via OSPF. Our /32 is advertised via eBGP no problem and the world can see > it.. > > Internally, we have a series of /128 loopbacks, /126 point to points, and a > /64 block setup for some servers. Obviously all small chunks of the /32 > assignment. > > My problem is that the world can reach our border routers but traffic will > not route beyond the border. Internally, we can route traffic no problem.. My first guess would be that your inbound traffic is routed just fine, but your internal routers have no route back. This looks like blackholing in a traceroute from an external host. Check both "sh ipv6 route " and "sh ipv6 route " on all routers in the path, I guess the first one will return a valid route on all your routers but the second one only on your edge. You need to tell your internal routers how to get out of your network. If you only have one edge router you can put a default route into OSPF. You have "default-information originate" in there already, this will only work if your edge router really has an exact ::/0 route in his table. Check for that and add "default-information originate always" if it doesn't. Bernhard _______________________________________________ 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 risnaini at indo.net.id Sat Sep 13 22:07:02 2008 From: risnaini at indo.net.id (a. rahman isnaini r.sutan) Date: Sun, 14 Sep 2008 09:07:02 +0700 Subject: [c-nsp] igp / ebgp problem ipv6 In-Reply-To: <000901c915c2$8c1a6ab0$a44f4010$@org> References: <000901c915c2$8c1a6ab0$a44f4010$@org> Message-ID: <48CC71C6.8080203@indo.net.id> check ipv6 unicast-routing a. rahman isnaini r.sutan Paul Stewart wrote: > Hi there. > > > > We have our first IPv6 block advertising to the world (for quite a while > now) and have started to actually route some small blocks of it internally > via OSPF. Our /32 is advertised via eBGP no problem and the world can see > it.. > > > > Internally, we have a series of /128 loopbacks, /126 point to points, and a > /64 block setup for some servers. Obviously all small chunks of the /32 > assignment. > > > > My problem is that the world can reach our border routers but traffic will > not route beyond the border. Internally, we can route traffic no problem.. > > > > Config looks basically like this: > > > > router bgp 00000 > > > > address-family ipv6 > > no synchronization > > network 0000:0000::/32 > > > > ipv6 route 0000:0000::/32 Null0 > > ipv6 router ospf 1 > > log-adjacency-changes > > default-information originate > > redistribute connected > > > > > > Then the applicable nei statements and ospf for IPv6 is enabled on certain > interfaces... Could post more config but hopefully this triggers someone > with an answer ;) The block is showing fine as a /32 to the world and > internally everything is reachable via ospf.. I know it has something to do > with the small subnets inside of the /32 but drawing a blank.. > > > > Thanks ;) > > > > Paul > > > > _______________________________________________ > 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 zivl at gilat.net Sun Sep 14 02:32:33 2008 From: zivl at gilat.net (Ziv Leyes) Date: Sun, 14 Sep 2008 09:32:33 +0300 Subject: [c-nsp] console port In-Reply-To: <9A95A1F8-94BF-4ED7-B9D8-68E964D1AECD@inoc.net> References: <69219.34362.qm@web33308.mail.mud.yahoo.com> <074672C37DDB4EDDA544301AE3D000EC@GINKGO> <9D077D04-A1CD-465F-A6B7-A720A7606254@snnap.net> <9A95A1F8-94BF-4ED7-B9D8-68E964D1AECD@inoc.net> Message-ID: 99% of those USB to Serial adaptors are using the same chipset, called "Prolific" something, it doesn't matter too much which vendor driver you use, it may work anyway. If you want I can send you a "generic" driver I've got once that I used on a cable that I've got from the office and didn't have any names on it, I've found it by digging into the digital ID on the "unrecognized" device. Anyway, here's a couple of links you may find useful: http://www.prolific.com.tw/eng/downloads.asp?ID=31 http://support.gateway.com/support/drivers/ddaStep.asp?Tab=All 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 Patrick Muldoon Sent: Friday, September 12, 2008 5:56 PM To: Tom Storey Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] console port On Sep 12, 2008, at 10:46 AM, Tom Storey wrote: > My vote for Keyspan aswell, though I have seen some very strange > things happen with them. > > Personally, mine is working flawless, and it gets a good workout... > > I use a Mac with Minicom, doesnt matter which USB port I have it > plugged into, it always works. > > Tom Same Here, using a Mac With Minicom.. Drivers default to creating /dev/cu.KeySerial1 for the first on you plug-in. (they used to not, so you always had to use the same USB port, or manual adjust symlink, etc...) I cannot speak to how they work on windows though... -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C NOTICE: alloc: /dev/null: filesystem full _______________________________________________ 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 hank at efes.iucc.ac.il Sun Sep 14 02:38:26 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 14 Sep 2008 09:38:26 +0300 Subject: [c-nsp] NPE-G2 Gigabit Ignored Errors In-Reply-To: <20080912184304.GA4860@rtp-cse-489.cisco.com> References: <200809121839.m8CIdHD3029666@e450.mnsi.net> <200809121649.m8CGngEV013138@e450.mnsi.net> <20080912181607.GR4860@rtp-cse-489.cisco.com> <200809121839.m8CIdHD3029666@e450.mnsi.net> Message-ID: <5.1.0.14.2.20080914093133.00ac0990@efes.iucc.ac.il> At 02:43 PM 12-09-08 -0400, Rodney Dunn wrote: Rodney, On a related note, we are seeing input overruns on almost all native GigaE ports on the NPE-G1. Example on 12.4(21): GigabitEthernet0/2 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 0009.446d.ac1a (bia 0009.446d.ac1a) MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 23/255, rxload 13/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, link type is force-up, media type is SX output flow-control is unsupported, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 52874000 bits/sec, 13178 packets/sec 30 second output rate 92696000 bits/sec, 14626 packets/sec 13055246077 packets input, 7473426491146 bytes, 0 no buffer Received 48343 broadcasts, 0 runts, 0 giants, 0 throttles 315 input errors, 0 CRC, 0 frame, 315 overrun, 0 ignored 0 watchdog, 2937496 multicast, 0 pause input 0 input packets with dribble condition detected On 12.4(18): GigabitEthernet0/1 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 0009.449b.2c1b (bia 0009.449b.2c1b) MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 29/255, rxload 41/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 00:04:00 Last input 00:00:01, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/2048/0/3 (size/max/drops/flushes); Total output drops: 139963 Queueing strategy: fifo Output queue: 0/1024 (size/max) 30 second input rate 163604000 bits/sec, 25284 packets/sec 30 second output rate 113775000 bits/sec, 23142 packets/sec 138829558726 packets input, 110625630435301 bytes, 0 no buffer Received 1170089 broadcasts, 0 runts, 0 giants, 0 throttles 42963 input errors, 0 CRC, 0 frame, 42963 overrun, 0 ignored 0 watchdog, 2939379 multicast, 0 pause input 0 input packets with dribble condition detected On 12.4(9)T2: GigabitEthernet0/2 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 0009.449b.441a (bia 0009.449b.441a) MTU 1500 bytes, BW 450000 Kbit, DLY 10 usec, reliability 255/255, txload 21/255, rxload 60/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/1024/369/79002147 (size/max/drops/flushes); Total output drops: 82 Queueing strategy: fifo Output queue: 0/1024 (size/max) 30 second input rate 105976000 bits/sec, 13665 packets/sec 30 second output rate 38207000 bits/sec, 11394 packets/sec 2996785111 packets input, 3073612701 bytes, 2279 no buffer Received 500907287 broadcasts, 0 runts, 0 giants, 2483 throttles 8348 input errors, 0 CRC, 0 frame, 8348 overrun, 0 ignored 0 watchdog, 497602409 multicast, 0 pause input 0 input packets with dribble condition detected Any ideas why? -Hank >On Fri, Sep 12, 2008 at 02:40:04PM -0400, Clayton Zekelman wrote: > > > > No luck... didn't fix it. Is it fixed in a subsequent release? Are > > there any other parameters I can tune? > >Not really because you can't tune the rx ring depth. > >Check 'sh controller'. > >What does 'sh proc cpu sort | excl 0.00' say? > >Can you post the configuration..I'm curious what your features >look like because the more you have the less pps you get through >this box..it's all done in software and can't do all features at line >rate during a microburst. > >sh int stat > > >Rodney > > > > > > GigabitEthernet0/1 is up, line protocol is up > > Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia > > 001a.6d30.091b) > > Description: to gig-fastiron Ethernet11 > > MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, > > reliability 255/255, txload 23/255, rxload 48/255 > > Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set > > Keepalive set (10 sec) > > Full-duplex, 1000Mb/s, media type is RJ45 > > output flow-control is XON, input flow-control is XON > > ARP type: ARPA, ARP Timeout 04:00:00 > > Last input 00:00:00, output 00:00:00, output hang never > > Last clearing of "show interface" counters 00:10:09 > > Input queue: 0/4096/533/0 (size/max/drops/flushes); Total output drops: 0 > > Queueing strategy: fifo > > Output queue: 0/40 (size/max) > > 30 second input rate 189692000 bits/sec, 30246 packets/sec > > 30 second output rate 91448000 bits/sec, 27197 packets/sec > > 18432915 packets input, 1555851456 bytes, 0 no buffer > > Received 65 broadcasts, 0 runts, 0 giants, 0 throttles > > 1117 input errors, 0 CRC, 0 frame, 0 overrun, 1117 ignored > > 0 watchdog, 1034 multicast, 0 pause input > > 0 input packets with dribble condition detected > > > > > > > > At 02:16 PM 9/12/2008, Rodney Dunn wrote: > > >Can you bump up your input queue depth: > > > > > >hold-queue 4096 in > > > > > >and see if they stop. > > > > > >I don't suspect that is going to help because the ignores > > >are not increasing that would point to: > > > > > >CSCse05447 > > >Externally found moderate defect: Resolved (R) > > >7200 ethernet interfaces should not throttle on input queue full drops > > > > > >Most likely you are seeing micro burst that are coming in faster > > >than the CPU can drain the rx ring. > > > > > >Rodney > > > > > > > > > > > >On Fri, Sep 12, 2008 at 12:50:29PM -0400, Clayton Zekelman wrote: > > >> > > >> I'm running a Cisco 7206/VXR with an NPE G2, Version 12.4(4)XD4 > > >> acting as an LNS. > > >> > > >> I'm getting input errors consistently incrementing on the Gig > > >> interface (ignored errors) > > >> > > >> Any way to fix this? I saw some discussion a while back about this, > > >> and it seemed to have to do with buffers - but I can't find any > > >> definitive recommendations on what the settings should be. > > >> > > >> > > >> > > >> GigabitEthernet0/1 is up, line protocol is up > > >> Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia > > >> 001a.6d30.091b) > > >> Description: to gig-fastiron Ethernet11 > > >> MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, > > >> reliability 255/255, txload 22/255, rxload 46/255 > > >> Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set > > >> Keepalive set (10 sec) > > >> Full-duplex, 1000Mb/s, media type is RJ45 > > >> output flow-control is XON, input flow-control is XON > > >> ARP type: ARPA, ARP Timeout 04:00:00 > > >> Last input 00:00:00, output 00:00:00, output hang never > > >> Last clearing of "show interface" counters 00:22:17 > > >> Input queue: 0/75/1191/0 (size/max/drops/flushes); Total output > drops: > > >0 > > >> Queueing strategy: fifo > > >> Output queue: 0/40 (size/max) > > >> 30 second input rate 181384000 bits/sec, 29001 packets/sec > > >> 30 second output rate 86319000 bits/sec, 26045 packets/sec > > >> 38605963 packets input, 4274358612 bytes, 1 no buffer > > >> Received 230 broadcasts, 0 runts, 0 giants, 0 throttles > > >> 2677 input errors, 0 CRC, 0 frame, 0 overrun, 2677 ignored > > >> 0 watchdog, 2196 multicast, 0 pause input > > >> 0 input packets with dribble condition detected > > >> 34556615 packets output, 1656923135 bytes, 0 underruns > > >> 0 output errors, 0 collisions, 0 interface resets > > >> 0 babbles, 0 late collision, 0 deferred > > >> 0 lost carrier, 0 no carrier, 0 pause output > > >> 0 output buffer failures, 0 output buffers swapped > > >> out > > >> > > >> > > >> > > >> --- > > >> Clayton Zekelman > > >> Managed Network Systems Inc. (MNSi) > > >> 344-300 Tecumseh Rd. E. > > >> Windsor, Ontario > > >> N8X 5E8 > > >> > > >> tel. 519-985-8410 > > >> fax. 519-985-8409 > > >> > > >> _______________________________________________ > > >> 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/ > > > > --- > > Clayton Zekelman > > Managed Network Systems Inc. (MNSi) > > 344-300 Tecumseh Rd. E. > > Windsor, Ontario > > N8X 5E8 > > > > tel. 519-985-8410 > > fax. 519-985-8409 >_______________________________________________ >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 hank at efes.iucc.ac.il Sun Sep 14 03:21:41 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 14 Sep 2008 10:21:41 +0300 Subject: [c-nsp] NPE-G2 Gigabit Ignored Errors In-Reply-To: <20080912181607.GR4860@rtp-cse-489.cisco.com> References: <200809121649.m8CGngEV013138@e450.mnsi.net> <200809121649.m8CGngEV013138@e450.mnsi.net> Message-ID: <5.1.0.14.2.20080914102031.00b20ea0@efes.iucc.ac.il> At 02:16 PM 12-09-08 -0400, Rodney Dunn wrote: >I don't suspect that is going to help because the ignores >are not increasing that would point to: > >CSCse05447 >Externally found moderate defect: Resolved (R) >7200 ethernet interfaces should not throttle on input queue full drops > >Most likely you are seeing micro burst that are coming in faster >than the CPU can drain the rx ring. > >Rodney Can't view it: "Information contained within bug ID CSCse05447 is only available to Cisco employees. It is our policy to make all externally-facing bugs available in Bug Toolkit so the system administrators have been automatically alerted to the problem. By choosing to save this bug, you may be notified when the decision to make this bug available to you has been made. Note: Some product enhancement requests and documentation error bugs may not be available in Bug Toolkit." -Hank From kgraham at industrial-marshmallow.com Sun Sep 14 12:57:32 2008 From: kgraham at industrial-marshmallow.com (Kevin Graham) Date: Sun, 14 Sep 2008 09:57:32 -0700 (PDT) Subject: [c-nsp] NPE-G2 Gigabit Ignored Errors Message-ID: <538003.45211.qm@web904.biz.mail.mud.yahoo.com> > On a related note, we are seeing input overruns on almost all native GigaE > ports on the NPE-G1. Example on 12.4(21): On the other side, of those NPE-G1 ports, do you see any flow control from them? I've never seen a G1's counters show pause frame that it sends, but even watching them indirectly, they're always several orders of magnitude less than the number of overruns... From tomas.hlavacek at elfove.cz Sun Sep 14 17:48:45 2008 From: tomas.hlavacek at elfove.cz (Tomas Hlavacek) Date: Sun, 14 Sep 2008 23:48:45 +0200 Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) Message-ID: <48CD86BD.4050604@elfove.cz> Greetings! I am thinking about a scenario, which is maybe quite common, but I do not know how to make that work. Say that an AS1 is receiving full BGP table from multiple upstreams, for example AS100 and AS200. AS1 has a customer, say AS2. There is one Ethernet physical connection between border routers of AS1 and AS2. AS2 is paying to AS1 for upstream and receives full BGP feed. AS1 has another customer AS3, paying for upstream also. Besides that AS1 and AS2 has a peering via some IX. AS2 is stub, so it is announcing only prefixes with as-path ^2$. AS1 is announcing ^1$ and ^1 3$ prefixes to its peers in the IX. AS1 preferres paths via IX by local-preferrence. The point is how to make packets traveling from upstreams of AS1 to AS2 not to take path via IX, but via direct Ethernet connection while traffic originating in AS1 and traffic from AS3 traveling trough AS1 take path via IX? I have two ideas: 1) policy based routing, bind some route-map to AS1's upstream-facing interfaces and set ip next-hop or set interface... But it does not scale well of course. 2) put transit neighbors (upstream and customers also) into vrf, for example: ip vrf transit rd 1:100 export map EXPORT_ALL import map IMPORT_ALL ! router bgp 1 network 1.1.1.0 mask 255.255.255.0 neighbor 2.2.2.1 remote-as 2 neighbor 2.2.2.1 route-map SET_IX_LOCPREF in neighbor 2.2.2.1 filter-list 1 ! address-family ipv4 vrf transit neighbor 1.1.0.1 remote-as 100 neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.1 description UPSTREAM1 neighbor 1.1.0.2 remote-as 200 neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.2 description UPSTREAM2 neighbor 2.2.2.2 remote-as 2 neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in neighbor 2.2.2.2 description CUSTOMER AS2 neighbor 3.3.3.1 remote-as 3 neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in neighbor 3.3.3.1 description CUSTOMER AS3 ! ! route-map SET_IX_LOCPREF permit 10 set local-preference 200 ! route-map SET_TRANSIT_LOCPREF permit 10 set local-preference 100 ! route-map EXPORT_ALL permit 10 ! route-map IMPORT_ALL permit 10 ! I spent few hours in lab experimenting with this configuration. I am using old Cisco 1600, so there is possibility that issues I had could come from some bug in this EoL platform... For reference, I used IOS (tm) 1600 Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) for experiments. Problems: 1) routes in vrf transit are learned to into vrf routing table and are announced in both directions from AS100 to AS2 and AS3 and vice-versa, as expected. But routes from vrf transit are not exported into global routing table nor imported from global into vrf. I tried everything (I put some prefix- or access-list to match ip address clause in IMPORT_ALL and EXPORT_ALL maps,...), but nothing appeared in the global table. It should be some misconfiguration over there but I do not see that. Any help would be appreciated. 2) Let's assume that the import and export works, so I have all transit routes in my global table and route 1.1.1.0/24 inside vrf transit (this is a route originated in AS2). Those routes are therefore in fact duplicated... Is there any mechanism or chance to overcome that? Something like default route in global table pointing into transit VRF and triggering one extra routing decission inside VRF? Or is the duplication somehow optimized and it won't be any problem even for full BGP table? (O course I mean full table on real routers... 7200 or 7600.) Is there any best-practice or common approach to that? Maybe something completly different which I am not aware of? Tomas -- Tom?? Hlav??ek From ben.steele at internode.on.net Sun Sep 14 18:30:15 2008 From: ben.steele at internode.on.net (Ben Steele) Date: Mon, 15 Sep 2008 08:00:15 +0930 Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) In-Reply-To: <48CD86BD.4050604@elfove.cz> References: <48CD86BD.4050604@elfove.cz> Message-ID: <000001c916b9$76458c40$62d0a4c0$@steele@internode.on.net> Is your network MPLS enabled? You could do TE from your bdr of YOUR upstreams to your PE that connects to AS1 and set a bgp weight (not local pref) on that router to prefer the directly connected Ethernet bgp peer, this solution will also give you some redundancy in should the TE tunnel go down or the bgp relationship over the ethernet it will just take the natural path of the IX. More static options like policy route-maps and static routing next hops etc have the consequence of leaving your neighbour with a broken network in the event of a failure through that policy, sure you can add sla tracking to your next hop but you mentioned scalability etc. So you don't want to be configuring ip sla all over the place and route-maps. Ben -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tomas Hlavacek Sent: Monday, 15 September 2008 7:19 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) Greetings! I am thinking about a scenario, which is maybe quite common, but I do not know how to make that work. Say that an AS1 is receiving full BGP table from multiple upstreams, for example AS100 and AS200. AS1 has a customer, say AS2. There is one Ethernet physical connection between border routers of AS1 and AS2. AS2 is paying to AS1 for upstream and receives full BGP feed. AS1 has another customer AS3, paying for upstream also. Besides that AS1 and AS2 has a peering via some IX. AS2 is stub, so it is announcing only prefixes with as-path ^2$. AS1 is announcing ^1$ and ^1 3$ prefixes to its peers in the IX. AS1 preferres paths via IX by local-preferrence. The point is how to make packets traveling from upstreams of AS1 to AS2 not to take path via IX, but via direct Ethernet connection while traffic originating in AS1 and traffic from AS3 traveling trough AS1 take path via IX? I have two ideas: 1) policy based routing, bind some route-map to AS1's upstream-facing interfaces and set ip next-hop or set interface... But it does not scale well of course. 2) put transit neighbors (upstream and customers also) into vrf, for example: ip vrf transit rd 1:100 export map EXPORT_ALL import map IMPORT_ALL ! router bgp 1 network 1.1.1.0 mask 255.255.255.0 neighbor 2.2.2.1 remote-as 2 neighbor 2.2.2.1 route-map SET_IX_LOCPREF in neighbor 2.2.2.1 filter-list 1 ! address-family ipv4 vrf transit neighbor 1.1.0.1 remote-as 100 neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.1 description UPSTREAM1 neighbor 1.1.0.2 remote-as 200 neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.2 description UPSTREAM2 neighbor 2.2.2.2 remote-as 2 neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in neighbor 2.2.2.2 description CUSTOMER AS2 neighbor 3.3.3.1 remote-as 3 neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in neighbor 3.3.3.1 description CUSTOMER AS3 ! ! route-map SET_IX_LOCPREF permit 10 set local-preference 200 ! route-map SET_TRANSIT_LOCPREF permit 10 set local-preference 100 ! route-map EXPORT_ALL permit 10 ! route-map IMPORT_ALL permit 10 ! I spent few hours in lab experimenting with this configuration. I am using old Cisco 1600, so there is possibility that issues I had could come from some bug in this EoL platform... For reference, I used IOS (tm) 1600 Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) for experiments. Problems: 1) routes in vrf transit are learned to into vrf routing table and are announced in both directions from AS100 to AS2 and AS3 and vice-versa, as expected. But routes from vrf transit are not exported into global routing table nor imported from global into vrf. I tried everything (I put some prefix- or access-list to match ip address clause in IMPORT_ALL and EXPORT_ALL maps,...), but nothing appeared in the global table. It should be some misconfiguration over there but I do not see that. Any help would be appreciated. 2) Let's assume that the import and export works, so I have all transit routes in my global table and route 1.1.1.0/24 inside vrf transit (this is a route originated in AS2). Those routes are therefore in fact duplicated... Is there any mechanism or chance to overcome that? Something like default route in global table pointing into transit VRF and triggering one extra routing decission inside VRF? Or is the duplication somehow optimized and it won't be any problem even for full BGP table? (O course I mean full table on real routers... 7200 or 7600.) Is there any best-practice or common approach to that? Maybe something completly different which I am not aware of? Tomas -- Tom?? Hlav??ek _______________________________________________ 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 hojmark.org Sun Sep 14 16:52:40 2008 From: lists at hojmark.org (Asbjorn Hojmark - Lists) Date: Sun, 14 Sep 2008 22:52:40 +0200 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <200809051003.32163.mtinka@globaltransit.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch><20080904170928.GA23309@mx.ytti.net><014301c90ef9$5a698480$500a10ac@ranma> <200809051003.32163.mtinka@globaltransit.net> Message-ID: <3BCF18EC09C04243A7CE06F0A419364E@hojmark.net> > AFAIK, Cisco don't have a 3-slot model of the ASR1000. The x in 100x is not the number of slots, but simply the RU size. -A From lists at hojmark.org Sun Sep 14 16:50:51 2008 From: lists at hojmark.org (Asbjorn Hojmark - Lists) Date: Sun, 14 Sep 2008 22:50:51 +0200 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <20080907075706.GA7640@mx.ytti.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch><6bb5f5b10809041001q317d4694o8b57be06fcfd54da@mail.gmail.com><20080904170928.GA23309@mx.ytti.net><200809051015.06641.mtinka@globaltransit.net> <20080907075706.GA7640@mx.ytti.net> Message-ID: > Just out of curiosity what were main points that left you > wanting? QinQ termination, EoMPLS, VPLS. -A From lists at hojmark.org Sun Sep 14 17:03:05 2008 From: lists at hojmark.org (Asbjorn Hojmark - Lists) Date: Sun, 14 Sep 2008 23:03:05 +0200 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: <20080904082459.GC17238@greenie.muc.de> References: <1220470004.32656.7.camel@abehat><20080904061039.GM233@greenie.muc.de> <20080904082459.GC17238@greenie.muc.de> Message-ID: <6550537E033840739814CA89075B7EEF@hojmark.net> > On a 7600, you can use Sup720 or RSP720, but you can't use > Sup720-10Gs, which are quite nice... But you can use RSP720-10G, which IMO are even more nice, because they have the MSFC4. -A From rubensk at gmail.com Sun Sep 14 19:00:12 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Sun, 14 Sep 2008 20:00:12 -0300 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: References: <20080904112344.GA2758@whitechalk.dfinet.ch> <6bb5f5b10809041001q317d4694o8b57be06fcfd54da@mail.gmail.com> <20080904170928.GA23309@mx.ytti.net> <200809051015.06641.mtinka@globaltransit.net> <20080907075706.GA7640@mx.ytti.net> Message-ID: <6bb5f5b10809141600v6b8b4f2dqb3aba1e743230178@mail.gmail.com> Does simple MPLS-TE would need to wait to for RLS3, or just MPLS-TE FRR ? Rubens On Sun, Sep 14, 2008 at 5:50 PM, Asbjorn Hojmark - Lists wrote: >> Just out of curiosity what were main points that left you >> wanting? > > QinQ termination, EoMPLS, VPLS. > > -A > > _______________________________________________ > 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 christian at broknrobot.com Sun Sep 14 19:31:20 2008 From: christian at broknrobot.com (Christian Koch) Date: Sun, 14 Sep 2008 19:31:20 -0400 Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) In-Reply-To: <48CD86BD.4050604@elfove.cz> References: <48CD86BD.4050604@elfove.cz> Message-ID: use meds On Sun, Sep 14, 2008 at 5:48 PM, Tomas Hlavacek wrote: > Greetings! > > I am thinking about a scenario, which is maybe quite common, but I do not > know how to make that work. > > Say that an AS1 is receiving full BGP table from multiple upstreams, for > example AS100 and AS200. AS1 has a customer, say AS2. There is one Ethernet > physical connection between border routers of AS1 and AS2. AS2 is paying to > AS1 for upstream and receives full BGP feed. AS1 has another customer AS3, > paying for upstream also. Besides that AS1 and AS2 has a peering via some > IX. AS2 is stub, so it is announcing only prefixes with as-path ^2$. AS1 is > announcing ^1$ and ^1 3$ prefixes to its peers in the IX. AS1 preferres > paths via IX by local-preferrence. > > The point is how to make packets traveling from upstreams of AS1 to AS2 not > to take path via IX, but via direct Ethernet connection while traffic > originating in AS1 and traffic from AS3 traveling trough AS1 take path via > IX? > > I have two ideas: > > 1) policy based routing, bind some route-map to AS1's upstream-facing > interfaces and set ip next-hop or set interface... But it does not scale > well of course. > > 2) put transit neighbors (upstream and customers also) into vrf, for > example: > > ip vrf transit > rd 1:100 > export map EXPORT_ALL > import map IMPORT_ALL > ! > router bgp 1 > network 1.1.1.0 mask 255.255.255.0 > neighbor 2.2.2.1 remote-as 2 > neighbor 2.2.2.1 route-map SET_IX_LOCPREF in > neighbor 2.2.2.1 filter-list 1 > ! > address-family ipv4 vrf transit > neighbor 1.1.0.1 remote-as 100 > neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in > neighbor 1.1.0.1 description UPSTREAM1 > neighbor 1.1.0.2 remote-as 200 > neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in > neighbor 1.1.0.2 description UPSTREAM2 > neighbor 2.2.2.2 remote-as 2 > neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in > neighbor 2.2.2.2 description CUSTOMER AS2 > neighbor 3.3.3.1 remote-as 3 > neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in > neighbor 3.3.3.1 description CUSTOMER AS3 > ! > ! > route-map SET_IX_LOCPREF permit 10 > set local-preference 200 > ! > route-map SET_TRANSIT_LOCPREF permit 10 > set local-preference 100 > ! > route-map EXPORT_ALL permit 10 > ! > route-map IMPORT_ALL permit 10 > ! > > I spent few hours in lab experimenting with this configuration. I am using > old Cisco 1600, so there is possibility that issues I had could come from > some bug in this EoL platform... For reference, I used IOS (tm) 1600 > Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) for > experiments. Problems: > > 1) routes in vrf transit are learned to into vrf routing table and are > announced in both directions from AS100 to AS2 and AS3 and vice-versa, as > expected. But routes from vrf transit are not exported into global routing > table nor imported from global into vrf. I tried everything (I put some > prefix- or access-list to match ip address clause in IMPORT_ALL and > EXPORT_ALL maps,...), but nothing appeared in the global table. It should be > some misconfiguration over there but I do not see that. Any help would be > appreciated. > > 2) Let's assume that the import and export works, so I have all transit > routes in my global table and route 1.1.1.0/24 inside vrf transit (this is a > route originated in AS2). Those routes are therefore in fact duplicated... > Is there any mechanism or chance to overcome that? Something like default > route in global table pointing into transit VRF and triggering one extra > routing decission inside VRF? Or is the duplication somehow optimized and it > won't be any problem even for full BGP table? (O course I mean full table on > real routers... 7200 or 7600.) > > Is there any best-practice or common approach to that? Maybe something > completly different which I am not aware of? > > Tomas > > -- > Tom?? Hlav??ek > > _______________________________________________ > 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 tomas.hlavacek at elfove.cz Sun Sep 14 19:36:55 2008 From: tomas.hlavacek at elfove.cz (Tomas Hlavacek) Date: Mon, 15 Sep 2008 01:36:55 +0200 Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) In-Reply-To: <000001c916b9$76458c40$62d0a4c0$@steele@internode.on.net> References: <48CD86BD.4050604@elfove.cz> <000001c916b9$76458c40$62d0a4c0$@steele@internode.on.net> Message-ID: <48CDA017.6060405@elfove.cz> Hello Ben and all, thanks for reply. First thing is that I am only trying to set up a proof-of-concept using small old boxes which are not doing MPLS at all. In my lab scenario one box stays for one AS. When it comes to deployment of the solution - whatever it is - to my real network, it will be all done by a single 7600, which has connected upstreams, peerings and customers into one single box. In real life my network will stay for AS2. As I am new to MPLS (I only did several labs and read theory) I could be wrong, but I think that sice I have only one box involved, I have only one RIB and so I can not use your solution now. And yes, you are right. I don't like solution with policy based routing despite that I know how to achive what I need using PBR. But I am scared by eventual future expanding of PBR for more customers and more sites. Tomas Ben Steele wrote: > Is your network MPLS enabled? You could do TE from your bdr of YOUR upstreams to your PE that connects to AS1 and set a bgp weight (not local pref) on that router to prefer the directly connected Ethernet bgp peer, this solution will also give you some redundancy in should the TE tunnel go down or the bgp relationship over the ethernet it will just take the natural path of the IX. > > More static options like policy route-maps and static routing next hops etc have the consequence of leaving your neighbour with a broken network in the event of a failure through that policy, sure you can add sla tracking to your next hop but you mentioned scalability etc. So you don't want to be configuring ip sla all over the place and route-maps. > > Ben > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tomas Hlavacek > Sent: Monday, 15 September 2008 7:19 AM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) > > Greetings! > > I am thinking about a scenario, which is maybe quite common, but I do > not know how to make that work. > > Say that an AS1 is receiving full BGP table from multiple upstreams, for > example AS100 and AS200. AS1 has a customer, say AS2. There is one > Ethernet physical connection between border routers of AS1 and AS2. AS2 > is paying to AS1 for upstream and receives full BGP feed. AS1 has > another customer AS3, paying for upstream also. Besides that AS1 and AS2 > has a peering via some IX. AS2 is stub, so it is announcing only > prefixes with as-path ^2$. AS1 is announcing ^1$ and ^1 3$ prefixes to > its peers in the IX. AS1 preferres paths via IX by local-preferrence. > > The point is how to make packets traveling from upstreams of AS1 to AS2 > not to take path via IX, but via direct Ethernet connection while > traffic originating in AS1 and traffic from AS3 traveling trough AS1 > take path via IX? > > I have two ideas: > > 1) policy based routing, bind some route-map to AS1's upstream-facing > interfaces and set ip next-hop or set interface... But it does not scale > well of course. > > 2) put transit neighbors (upstream and customers also) into vrf, for > example: > > ip vrf transit > rd 1:100 > export map EXPORT_ALL > import map IMPORT_ALL > ! > router bgp 1 > network 1.1.1.0 mask 255.255.255.0 > neighbor 2.2.2.1 remote-as 2 > neighbor 2.2.2.1 route-map SET_IX_LOCPREF in > neighbor 2.2.2.1 filter-list 1 > ! > address-family ipv4 vrf transit > neighbor 1.1.0.1 remote-as 100 > neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in > neighbor 1.1.0.1 description UPSTREAM1 > neighbor 1.1.0.2 remote-as 200 > neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in > neighbor 1.1.0.2 description UPSTREAM2 > neighbor 2.2.2.2 remote-as 2 > neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in > neighbor 2.2.2.2 description CUSTOMER AS2 > neighbor 3.3.3.1 remote-as 3 > neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in > neighbor 3.3.3.1 description CUSTOMER AS3 > ! > ! > route-map SET_IX_LOCPREF permit 10 > set local-preference 200 > ! > route-map SET_TRANSIT_LOCPREF permit 10 > set local-preference 100 > ! > route-map EXPORT_ALL permit 10 > ! > route-map IMPORT_ALL permit 10 > ! > > I spent few hours in lab experimenting with this configuration. I am > using old Cisco 1600, so there is possibility that issues I had could > come from some bug in this EoL platform... For reference, I used IOS > (tm) 1600 Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) > for experiments. Problems: > > 1) routes in vrf transit are learned to into vrf routing table and are > announced in both directions from AS100 to AS2 and AS3 and vice-versa, > as expected. But routes from vrf transit are not exported into global > routing table nor imported from global into vrf. I tried everything (I > put some prefix- or access-list to match ip address clause in IMPORT_ALL > and EXPORT_ALL maps,...), but nothing appeared in the global table. It > should be some misconfiguration over there but I do not see that. Any > help would be appreciated. > > 2) Let's assume that the import and export works, so I have all transit > routes in my global table and route 1.1.1.0/24 inside vrf transit (this > is a route originated in AS2). Those routes are therefore in fact > duplicated... Is there any mechanism or chance to overcome that? > Something like default route in global table pointing into transit VRF > and triggering one extra routing decission inside VRF? Or is the > duplication somehow optimized and it won't be any problem even for full > BGP table? (O course I mean full table on real routers... 7200 or 7600.) > > Is there any best-practice or common approach to that? Maybe something > completly different which I am not aware of? > > Tomas > > -- Tom?? Hlav??ek From tomas.hlavacek at elfove.cz Sun Sep 14 19:41:47 2008 From: tomas.hlavacek at elfove.cz (Tomas Hlavacek) Date: Mon, 15 Sep 2008 01:41:47 +0200 Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) Message-ID: <48CDA13B.7090508@elfove.cz> Sorry... In real life my network will stay for AS1. Not AS2. -------- Original Message -------- Subject: Re: [c-nsp] separation of transit, peerings and this-AS traffic (long) Date: Mon, 15 Sep 2008 01:36:55 +0200 From: Tomas Hlavacek To: Ben Steele , cisco-nsp at puck.nether.net References: <48CD86BD.4050604 at elfove.cz> <000001c916b9$76458c40$62d0a4c0$@steele at internode.on.net> When it comes to deployment of the solution - whatever it is - to my real network, it will be all done by a single 7600, which has connected upstreams, peerings and customers into one single box. In real life my network will stay for AS2. -- Tom?? Hlav??ek From tomas.hlavacek at elfove.cz Sun Sep 14 20:01:08 2008 From: tomas.hlavacek at elfove.cz (Tomas Hlavacek) Date: Mon, 15 Sep 2008 02:01:08 +0200 Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) In-Reply-To: References: <48CD86BD.4050604@elfove.cz> Message-ID: <48CDA5C4.1090005@elfove.cz> Hello Christian, thanks for reply! Maybe I do not see some obvious solution with MED... The point is, that I need to route traffic from all of my upstreams to my customer AS2 via one path and any other traffic from my AS or from my other customers via another path facing AS2 too. So the problem is not which of two routes with the same prefix and different next-hops should be installed into routing table - that is, what the MED solves, AFAIK. The problem is how to use concurrently on a one single box two routes with the same prefix and different next-hops and select which of routes is to be used based on where the traffic comes from (not src IP address but interface). Tomas Christian Koch wrote: > use meds > > On Sun, Sep 14, 2008 at 5:48 PM, Tomas Hlavacek > wrote: > >> Greetings! >> >> I am thinking about a scenario, which is maybe quite common, but I do not >> know how to make that work. >> >> Say that an AS1 is receiving full BGP table from multiple upstreams, for >> example AS100 and AS200. AS1 has a customer, say AS2. There is one Ethernet >> physical connection between border routers of AS1 and AS2. AS2 is paying to >> AS1 for upstream and receives full BGP feed. AS1 has another customer AS3, >> paying for upstream also. Besides that AS1 and AS2 has a peering via some >> IX. AS2 is stub, so it is announcing only prefixes with as-path ^2$. AS1 is >> announcing ^1$ and ^1 3$ prefixes to its peers in the IX. AS1 preferres >> paths via IX by local-preferrence. >> >> The point is how to make packets traveling from upstreams of AS1 to AS2 not >> to take path via IX, but via direct Ethernet connection while traffic >> originating in AS1 and traffic from AS3 traveling trough AS1 take path via >> IX? >> >> I have two ideas: >> >> 1) policy based routing, bind some route-map to AS1's upstream-facing >> interfaces and set ip next-hop or set interface... But it does not scale >> well of course. >> >> 2) put transit neighbors (upstream and customers also) into vrf, for >> example: >> >> ip vrf transit >> rd 1:100 >> export map EXPORT_ALL >> import map IMPORT_ALL >> ! >> router bgp 1 >> network 1.1.1.0 mask 255.255.255.0 >> neighbor 2.2.2.1 remote-as 2 >> neighbor 2.2.2.1 route-map SET_IX_LOCPREF in >> neighbor 2.2.2.1 filter-list 1 >> ! >> address-family ipv4 vrf transit >> neighbor 1.1.0.1 remote-as 100 >> neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in >> neighbor 1.1.0.1 description UPSTREAM1 >> neighbor 1.1.0.2 remote-as 200 >> neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in >> neighbor 1.1.0.2 description UPSTREAM2 >> neighbor 2.2.2.2 remote-as 2 >> neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in >> neighbor 2.2.2.2 description CUSTOMER AS2 >> neighbor 3.3.3.1 remote-as 3 >> neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in >> neighbor 3.3.3.1 description CUSTOMER AS3 >> ! >> ! >> route-map SET_IX_LOCPREF permit 10 >> set local-preference 200 >> ! >> route-map SET_TRANSIT_LOCPREF permit 10 >> set local-preference 100 >> ! >> route-map EXPORT_ALL permit 10 >> ! >> route-map IMPORT_ALL permit 10 >> ! >> >> I spent few hours in lab experimenting with this configuration. I am using >> old Cisco 1600, so there is possibility that issues I had could come from >> some bug in this EoL platform... For reference, I used IOS (tm) 1600 >> Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) for >> experiments. Problems: >> >> 1) routes in vrf transit are learned to into vrf routing table and are >> announced in both directions from AS100 to AS2 and AS3 and vice-versa, as >> expected. But routes from vrf transit are not exported into global routing >> table nor imported from global into vrf. I tried everything (I put some >> prefix- or access-list to match ip address clause in IMPORT_ALL and >> EXPORT_ALL maps,...), but nothing appeared in the global table. It should be >> some misconfiguration over there but I do not see that. Any help would be >> appreciated. >> >> 2) Let's assume that the import and export works, so I have all transit >> routes in my global table and route 1.1.1.0/24 inside vrf transit (this is a >> route originated in AS2). Those routes are therefore in fact duplicated... >> Is there any mechanism or chance to overcome that? Something like default >> route in global table pointing into transit VRF and triggering one extra >> routing decission inside VRF? Or is the duplication somehow optimized and it >> won't be any problem even for full BGP table? (O course I mean full table on >> real routers... 7200 or 7600.) >> >> Is there any best-practice or common approach to that? Maybe something >> completly different which I am not aware of? >> >> Tomas >> >> -- >> Tom?? Hlav??ek >> >> _______________________________________________ >> 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/ >> -- Tom?? Hlav??ek From rubensk at gmail.com Sun Sep 14 20:04:45 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Sun, 14 Sep 2008 21:04:45 -0300 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: <6bb5f5b10809141704r2bd3683ei420c0c874b9885e@mail.gmail.com> References: <4841.72918.qm@web905.biz.mail.mud.yahoo.com> <20080904061158.GN233@greenie.muc.de> <6bb5f5b10809141704r2bd3683ei420c0c874b9885e@mail.gmail.com> Message-ID: <6bb5f5b10809141704q1b4147a6ldef67da42b887075@mail.gmail.com> >> It's minimal, but RSP720-3CXL is going to require a "7600", though if you >> are willing to trade the MSFC4 for VSS, you can go with a VS-Sup720-3CXL. >> Either one is going to force you off of 12.2SXF. > > Since the difference between 3B and 3C mainly seems to be "number of MAC > addresses", a Sup720-3BXL will usually do the job well enough. PFC-3BXL is a fine EARL, but MSFC4 has much more memory and processing power, which is something that the years to come might prove useful. Rubens From rubensk at gmail.com Sun Sep 14 20:11:34 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Sun, 14 Sep 2008 21:11:34 -0300 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: References: Message-ID: <6bb5f5b10809141711n63cff137r9de2682c317f4f2f@mail.gmail.com> On Wed, Sep 3, 2008 at 2:58 PM, Rick Kunkel wrote: > Well, I've hit the dreaded error message on my Sup2: > > %MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries will be > software switched 1) Try filtering on anything less than /24s and pointing default routes to your providers, see if that helps. 2) Try filtering on RIR boundaries, if (1) has failed. 3) Try filtering on overlapping prefixes (will need software to find those), if (2) has failed 4) Try filtering on longer AS paths, which means you are likely to be very far off to do useful traffic engineering, if (3) or (2) failed Beware that pointing a defaul-route might do some damage if you use uRPF, but you use uRPF, you would have probably posted this message some years ago... :-) Rubens From rubensk at gmail.com Sun Sep 14 20:23:51 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Sun, 14 Sep 2008 21:23:51 -0300 Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) In-Reply-To: <48CDA017.6060405@elfove.cz> References: <48CD86BD.4050604@elfove.cz> <48CDA017.6060405@elfove.cz> Message-ID: <6bb5f5b10809141723w21f2a7bj11252176208b2f3b@mail.gmail.com> > As I am new to MPLS (I only did several labs and read theory) I could be > wrong, but I think that sice I have only one box involved, I have only one > RIB and so I can not use your solution now. One box can have multiple FIB/RIBs if it's VRF or VRF-Lite capable. One doesn't need MPLS to do VRF-Lite. Rubens From ben.steele at internode.on.net Sun Sep 14 20:44:23 2008 From: ben.steele at internode.on.net (Ben Steele) Date: Mon, 15 Sep 2008 10:14:23 +0930 Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) In-Reply-To: <48CDA017.6060405@elfove.cz> References: <48CD86BD.4050604@elfove.cz> <000001c916b9$76458c40$62d0a4c0$@steele@internode.on.net> <48CDA017.6060405@elfove.cz> Message-ID: <000001c916cc$330f9b10$992ed130$@steele@internode.on.net> The main reason I didn't like the sound of PBR was me thinking you have a service provider style network with quite a large internal routing infrastructure having to work this on a hop by hop basis, if it's just one box connecting everything then pbr with verify next hop will do the job. -----Original Message----- From: Tomas Hlavacek [mailto:tomas.hlavacek at elfove.cz] Sent: Monday, 15 September 2008 9:07 AM To: Ben Steele; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] separation of transit, peerings and this-AS traffic (long) Hello Ben and all, thanks for reply. First thing is that I am only trying to set up a proof-of-concept using small old boxes which are not doing MPLS at all. In my lab scenario one box stays for one AS. When it comes to deployment of the solution - whatever it is - to my real network, it will be all done by a single 7600, which has connected upstreams, peerings and customers into one single box. In real life my network will stay for AS2. As I am new to MPLS (I only did several labs and read theory) I could be wrong, but I think that sice I have only one box involved, I have only one RIB and so I can not use your solution now. And yes, you are right. I don't like solution with policy based routing despite that I know how to achive what I need using PBR. But I am scared by eventual future expanding of PBR for more customers and more sites. Tomas Ben Steele wrote: > Is your network MPLS enabled? You could do TE from your bdr of YOUR upstreams to your PE that connects to AS1 and set a bgp weight (not local pref) on that router to prefer the directly connected Ethernet bgp peer, this solution will also give you some redundancy in should the TE tunnel go down or the bgp relationship over the ethernet it will just take the natural path of the IX. > > More static options like policy route-maps and static routing next hops etc have the consequence of leaving your neighbour with a broken network in the event of a failure through that policy, sure you can add sla tracking to your next hop but you mentioned scalability etc. So you don't want to be configuring ip sla all over the place and route-maps. > > Ben > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tomas Hlavacek > Sent: Monday, 15 September 2008 7:19 AM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) > > Greetings! > > I am thinking about a scenario, which is maybe quite common, but I do > not know how to make that work. > > Say that an AS1 is receiving full BGP table from multiple upstreams, for > example AS100 and AS200. AS1 has a customer, say AS2. There is one > Ethernet physical connection between border routers of AS1 and AS2. AS2 > is paying to AS1 for upstream and receives full BGP feed. AS1 has > another customer AS3, paying for upstream also. Besides that AS1 and AS2 > has a peering via some IX. AS2 is stub, so it is announcing only > prefixes with as-path ^2$. AS1 is announcing ^1$ and ^1 3$ prefixes to > its peers in the IX. AS1 preferres paths via IX by local-preferrence. > > The point is how to make packets traveling from upstreams of AS1 to AS2 > not to take path via IX, but via direct Ethernet connection while > traffic originating in AS1 and traffic from AS3 traveling trough AS1 > take path via IX? > > I have two ideas: > > 1) policy based routing, bind some route-map to AS1's upstream-facing > interfaces and set ip next-hop or set interface... But it does not scale > well of course. > > 2) put transit neighbors (upstream and customers also) into vrf, for > example: > > ip vrf transit > rd 1:100 > export map EXPORT_ALL > import map IMPORT_ALL > ! > router bgp 1 > network 1.1.1.0 mask 255.255.255.0 > neighbor 2.2.2.1 remote-as 2 > neighbor 2.2.2.1 route-map SET_IX_LOCPREF in > neighbor 2.2.2.1 filter-list 1 > ! > address-family ipv4 vrf transit > neighbor 1.1.0.1 remote-as 100 > neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in > neighbor 1.1.0.1 description UPSTREAM1 > neighbor 1.1.0.2 remote-as 200 > neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in > neighbor 1.1.0.2 description UPSTREAM2 > neighbor 2.2.2.2 remote-as 2 > neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in > neighbor 2.2.2.2 description CUSTOMER AS2 > neighbor 3.3.3.1 remote-as 3 > neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in > neighbor 3.3.3.1 description CUSTOMER AS3 > ! > ! > route-map SET_IX_LOCPREF permit 10 > set local-preference 200 > ! > route-map SET_TRANSIT_LOCPREF permit 10 > set local-preference 100 > ! > route-map EXPORT_ALL permit 10 > ! > route-map IMPORT_ALL permit 10 > ! > > I spent few hours in lab experimenting with this configuration. I am > using old Cisco 1600, so there is possibility that issues I had could > come from some bug in this EoL platform... For reference, I used IOS > (tm) 1600 Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) > for experiments. Problems: > > 1) routes in vrf transit are learned to into vrf routing table and are > announced in both directions from AS100 to AS2 and AS3 and vice-versa, > as expected. But routes from vrf transit are not exported into global > routing table nor imported from global into vrf. I tried everything (I > put some prefix- or access-list to match ip address clause in IMPORT_ALL > and EXPORT_ALL maps,...), but nothing appeared in the global table. It > should be some misconfiguration over there but I do not see that. Any > help would be appreciated. > > 2) Let's assume that the import and export works, so I have all transit > routes in my global table and route 1.1.1.0/24 inside vrf transit (this > is a route originated in AS2). Those routes are therefore in fact > duplicated... Is there any mechanism or chance to overcome that? > Something like default route in global table pointing into transit VRF > and triggering one extra routing decission inside VRF? Or is the > duplication somehow optimized and it won't be any problem even for full > BGP table? (O course I mean full table on real routers... 7200 or 7600.) > > Is there any best-practice or common approach to that? Maybe something > completly different which I am not aware of? > > Tomas > > -- Tom?? Hlav??ek From ben.steele at internode.on.net Sun Sep 14 20:45:39 2008 From: ben.steele at internode.on.net (Ben Steele) Date: Mon, 15 Sep 2008 10:15:39 +0930 Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) In-Reply-To: References: <48CD86BD.4050604@elfove.cz> Message-ID: <000101c916cc$5fec9750$1fc5c5f0$@steele@internode.on.net> MED isn't going to solve this problem. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Christian Koch Sent: Monday, 15 September 2008 9:01 AM To: Tomas Hlavacek Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] separation of transit, peerings and this-AS traffic (long) use meds On Sun, Sep 14, 2008 at 5:48 PM, Tomas Hlavacek wrote: > Greetings! > > I am thinking about a scenario, which is maybe quite common, but I do not > know how to make that work. > > Say that an AS1 is receiving full BGP table from multiple upstreams, for > example AS100 and AS200. AS1 has a customer, say AS2. There is one Ethernet > physical connection between border routers of AS1 and AS2. AS2 is paying to > AS1 for upstream and receives full BGP feed. AS1 has another customer AS3, > paying for upstream also. Besides that AS1 and AS2 has a peering via some > IX. AS2 is stub, so it is announcing only prefixes with as-path ^2$. AS1 is > announcing ^1$ and ^1 3$ prefixes to its peers in the IX. AS1 preferres > paths via IX by local-preferrence. > > The point is how to make packets traveling from upstreams of AS1 to AS2 not > to take path via IX, but via direct Ethernet connection while traffic > originating in AS1 and traffic from AS3 traveling trough AS1 take path via > IX? > > I have two ideas: > > 1) policy based routing, bind some route-map to AS1's upstream-facing > interfaces and set ip next-hop or set interface... But it does not scale > well of course. > > 2) put transit neighbors (upstream and customers also) into vrf, for > example: > > ip vrf transit > rd 1:100 > export map EXPORT_ALL > import map IMPORT_ALL > ! > router bgp 1 > network 1.1.1.0 mask 255.255.255.0 > neighbor 2.2.2.1 remote-as 2 > neighbor 2.2.2.1 route-map SET_IX_LOCPREF in > neighbor 2.2.2.1 filter-list 1 > ! > address-family ipv4 vrf transit > neighbor 1.1.0.1 remote-as 100 > neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in > neighbor 1.1.0.1 description UPSTREAM1 > neighbor 1.1.0.2 remote-as 200 > neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in > neighbor 1.1.0.2 description UPSTREAM2 > neighbor 2.2.2.2 remote-as 2 > neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in > neighbor 2.2.2.2 description CUSTOMER AS2 > neighbor 3.3.3.1 remote-as 3 > neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in > neighbor 3.3.3.1 description CUSTOMER AS3 > ! > ! > route-map SET_IX_LOCPREF permit 10 > set local-preference 200 > ! > route-map SET_TRANSIT_LOCPREF permit 10 > set local-preference 100 > ! > route-map EXPORT_ALL permit 10 > ! > route-map IMPORT_ALL permit 10 > ! > > I spent few hours in lab experimenting with this configuration. I am using > old Cisco 1600, so there is possibility that issues I had could come from > some bug in this EoL platform... For reference, I used IOS (tm) 1600 > Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) for > experiments. Problems: > > 1) routes in vrf transit are learned to into vrf routing table and are > announced in both directions from AS100 to AS2 and AS3 and vice-versa, as > expected. But routes from vrf transit are not exported into global routing > table nor imported from global into vrf. I tried everything (I put some > prefix- or access-list to match ip address clause in IMPORT_ALL and > EXPORT_ALL maps,...), but nothing appeared in the global table. It should be > some misconfiguration over there but I do not see that. Any help would be > appreciated. > > 2) Let's assume that the import and export works, so I have all transit > routes in my global table and route 1.1.1.0/24 inside vrf transit (this is a > route originated in AS2). Those routes are therefore in fact duplicated... > Is there any mechanism or chance to overcome that? Something like default > route in global table pointing into transit VRF and triggering one extra > routing decission inside VRF? Or is the duplication somehow optimized and it > won't be any problem even for full BGP table? (O course I mean full table on > real routers... 7200 or 7600.) > > Is there any best-practice or common approach to that? Maybe something > completly different which I am not aware of? > > Tomas > > -- > Tom?? Hlav??ek > > _______________________________________________ > 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 Sun Sep 14 21:07:26 2008 From: cchurc05 at harris.com (Church, Charles) Date: Sun, 14 Sep 2008 20:07:26 -0500 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: <6bb5f5b10809141711n63cff137r9de2682c317f4f2f@mail.gmail.com> References: <6bb5f5b10809141711n63cff137r9de2682c317f4f2f@mail.gmail.com> Message-ID: I got curious last week when I saw this thread. From my (AS 26296) point of view, there aren't a whole lot of routes in the /25 to /29 range, maybe a couple hundred total when I looked at it last week. The /24s were huge, about 142,000. I'm curious how many of those /24s are covered by larger aggregates. Might be a fun experiment figuring out a safe way to filter those. Probably involve AS path length, maybe RIR allocations. Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Rubens Kuhl Jr. Sent: Sunday, September 14, 2008 8:12 PM To: Rick Kunkel Cc: Cisco-nsp Subject: Re: [c-nsp] Dreaded FIB Exception on Sup2 On Wed, Sep 3, 2008 at 2:58 PM, Rick Kunkel wrote: > Well, I've hit the dreaded error message on my Sup2: > > %MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries will be > software switched 1) Try filtering on anything less than /24s and pointing default routes to your providers, see if that helps. 2) Try filtering on RIR boundaries, if (1) has failed. 3) Try filtering on overlapping prefixes (will need software to find those), if (2) has failed 4) Try filtering on longer AS paths, which means you are likely to be very far off to do useful traffic engineering, if (3) or (2) failed Beware that pointing a defaul-route might do some damage if you use uRPF, but you use uRPF, you would have probably posted this message some years ago... :-) Rubens _______________________________________________ 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 christian at broknrobot.com Sun Sep 14 21:18:46 2008 From: christian at broknrobot.com (Christian Koch) Date: Sun, 14 Sep 2008 21:18:46 -0400 Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) In-Reply-To: <48CDA5C4.1090005@elfove.cz> References: <48CD86BD.4050604@elfove.cz> <48CDA5C4.1090005@elfove.cz> Message-ID: my apologies, i seem to have read through your original to quickly 2008/9/14 Tomas Hlavacek : > Hello Christian, > > thanks for reply! Maybe I do not see some obvious solution with MED... > > The point is, that I need to route traffic from all of my upstreams to my > customer AS2 via one path and any other traffic from my AS or from my other > customers via another path facing AS2 too. So the problem is not which of > two routes with the same prefix and different next-hops should be installed > into routing table - that is, what the MED solves, AFAIK. The problem is how > to use concurrently on a one single box two routes with the same prefix and > different next-hops and select which of routes is to be used based on where > the traffic comes from (not src IP address but interface). > > Tomas > > Christian Koch wrote: >> >> use meds >> >> On Sun, Sep 14, 2008 at 5:48 PM, Tomas Hlavacek >> wrote: >> >>> >>> Greetings! >>> >>> I am thinking about a scenario, which is maybe quite common, but I do not >>> know how to make that work. >>> >>> Say that an AS1 is receiving full BGP table from multiple upstreams, for >>> example AS100 and AS200. AS1 has a customer, say AS2. There is one >>> Ethernet >>> physical connection between border routers of AS1 and AS2. AS2 is paying >>> to >>> AS1 for upstream and receives full BGP feed. AS1 has another customer >>> AS3, >>> paying for upstream also. Besides that AS1 and AS2 has a peering via some >>> IX. AS2 is stub, so it is announcing only prefixes with as-path ^2$. AS1 >>> is >>> announcing ^1$ and ^1 3$ prefixes to its peers in the IX. AS1 preferres >>> paths via IX by local-preferrence. >>> >>> The point is how to make packets traveling from upstreams of AS1 to AS2 >>> not >>> to take path via IX, but via direct Ethernet connection while traffic >>> originating in AS1 and traffic from AS3 traveling trough AS1 take path >>> via >>> IX? >>> >>> I have two ideas: >>> >>> 1) policy based routing, bind some route-map to AS1's upstream-facing >>> interfaces and set ip next-hop or set interface... But it does not scale >>> well of course. >>> >>> 2) put transit neighbors (upstream and customers also) into vrf, for >>> example: >>> >>> ip vrf transit >>> rd 1:100 >>> export map EXPORT_ALL >>> import map IMPORT_ALL >>> ! >>> router bgp 1 >>> network 1.1.1.0 mask 255.255.255.0 >>> neighbor 2.2.2.1 remote-as 2 >>> neighbor 2.2.2.1 route-map SET_IX_LOCPREF in >>> neighbor 2.2.2.1 filter-list 1 >>> ! >>> address-family ipv4 vrf transit >>> neighbor 1.1.0.1 remote-as 100 >>> neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in >>> neighbor 1.1.0.1 description UPSTREAM1 >>> neighbor 1.1.0.2 remote-as 200 >>> neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in >>> neighbor 1.1.0.2 description UPSTREAM2 >>> neighbor 2.2.2.2 remote-as 2 >>> neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in >>> neighbor 2.2.2.2 description CUSTOMER AS2 >>> neighbor 3.3.3.1 remote-as 3 >>> neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in >>> neighbor 3.3.3.1 description CUSTOMER AS3 >>> ! >>> ! >>> route-map SET_IX_LOCPREF permit 10 >>> set local-preference 200 >>> ! >>> route-map SET_TRANSIT_LOCPREF permit 10 >>> set local-preference 100 >>> ! >>> route-map EXPORT_ALL permit 10 >>> ! >>> route-map IMPORT_ALL permit 10 >>> ! >>> >>> I spent few hours in lab experimenting with this configuration. I am >>> using >>> old Cisco 1600, so there is possibility that issues I had could come from >>> some bug in this EoL platform... For reference, I used IOS (tm) 1600 >>> Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) for >>> experiments. Problems: >>> >>> 1) routes in vrf transit are learned to into vrf routing table and are >>> announced in both directions from AS100 to AS2 and AS3 and vice-versa, as >>> expected. But routes from vrf transit are not exported into global >>> routing >>> table nor imported from global into vrf. I tried everything (I put some >>> prefix- or access-list to match ip address clause in IMPORT_ALL and >>> EXPORT_ALL maps,...), but nothing appeared in the global table. It should >>> be >>> some misconfiguration over there but I do not see that. Any help would be >>> appreciated. >>> >>> 2) Let's assume that the import and export works, so I have all transit >>> routes in my global table and route 1.1.1.0/24 inside vrf transit (this >>> is a >>> route originated in AS2). Those routes are therefore in fact >>> duplicated... >>> Is there any mechanism or chance to overcome that? Something like default >>> route in global table pointing into transit VRF and triggering one extra >>> routing decission inside VRF? Or is the duplication somehow optimized and >>> it >>> won't be any problem even for full BGP table? (O course I mean full table >>> on >>> real routers... 7200 or 7600.) >>> >>> Is there any best-practice or common approach to that? Maybe something >>> completly different which I am not aware of? >>> >>> Tomas >>> >>> -- >>> Tom?? Hlav??ek >>> >>> _______________________________________________ >>> 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/ >>> > > -- > Tom?? Hlav??ek > > From mtinka at globaltransit.net Sun Sep 14 22:48:41 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Mon, 15 Sep 2008 10:48:41 +0800 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <3BCF18EC09C04243A7CE06F0A419364E@hojmark.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <200809051003.32163.mtinka@globaltransit.net> <3BCF18EC09C04243A7CE06F0A419364E@hojmark.net> Message-ID: <200809151048.42373.mtinka@globaltransit.net> On Monday 15 September 2008 04:52:40 Asbjorn Hojmark - Lists wrote: > > AFAIK, Cisco don't have a 3-slot model of the ASR1000. > > The x in 100x is not the number of slots, but simply the > RU size. Not sure what you're getting at. 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 Sun Sep 14 22:56:03 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Mon, 15 Sep 2008 10:56:03 +0800 Subject: [c-nsp] c7604 "starter kit" - Update! In-Reply-To: <200809151048.42373.mtinka@globaltransit.net> References: <20080904112344.GA2758@whitechalk.dfinet.ch> <3BCF18EC09C04243A7CE06F0A419364E@hojmark.net> <200809151048.42373.mtinka@globaltransit.net> Message-ID: <200809151056.04016.mtinka@globaltransit.net> On Monday 15 September 2008 10:48:41 Mark Tinka wrote: > > The x in 100x is not the number of slots, but simply > > the RU size. > > Not sure what you're getting at. Disregard. 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 rootnet08 at gmail.com Mon Sep 15 00:16:32 2008 From: rootnet08 at gmail.com (root net) Date: Sun, 14 Sep 2008 23:16:32 -0500 Subject: [c-nsp] NTP not synchronizing In-Reply-To: <8DD1F4B50477AC45A35AB5F8C03B62C4018567AB@sauce.ulima.ul> References: <8DD1F4B50477AC45A35AB5F8C03B62C4018567AB@sauce.ulima.ul> Message-ID: <89944ef40809142116jf1957e7jba0d52a226f8b5ad@mail.gmail.com> What NTP server are you using? Are you trying to use the Cisco router as the NTP server for your clients/hosts on your network or what? My bet is the NTP server is overwhelmed you are trying to connect to. I had this issue before and changed NTP servers worked like a charm. Check the NIST listing for an updated listing of NTP servers that are free or with little users. rootnet On Sat, Sep 13, 2008 at 1:30 PM, Velasquez Venegas Jaime Omar < Jaime at ulima.edu.pe> wrote: > Hi there. > > I'm having a problem trying to synchronize a Cisco Router across a wan > link with a NTP Server (No-Cisco router).So far i've ruled out packet > filering or firewall blocking as a cause of this.Some other equipments > at the local side of this router actually synchronize with the ntp > server at our LAN.What strikes me is the fact that router does reach ntp > server via other protocols other than ntp tough. > > > This is what i get from the out-of-sync router: > #Show ntp assoc > address ref clock st when poll reach delay offset > disp > ~<> 0.0.0.0 16 - 64 0 0.0 0.00 > 16000. > * master (synced), # master (unsynced), + selected, - candidate, ~ > configured > > I've set debugging for the ntp packets and for all the traffic getting > out of the serial interface which got "NTP: xmit packet to NTP.Server" > events.However there 's absolutely no attempt whatsoever of packet being > transmitted to NTP Server at the serial interface. > I've also configured this router as a ntp master and tried to get the > hosts on its local ethernet to synchronize with it to no avail. > > Any insight? > > 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 mrz at velvet.org Sun Sep 14 23:30:52 2008 From: mrz at velvet.org (matthew zeier) Date: Sun, 14 Sep 2008 20:30:52 -0700 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: References: <6bb5f5b10809141711n63cff137r9de2682c317f4f2f@mail.gmail.com> Message-ID: <48CDD6EC.4070300@velvet.org> I would be interested in the results of such an experiment (I was about to research this this week myself). Church, Charles wrote: > I got curious last week when I saw this thread. From my (AS 26296) > point of view, there aren't a whole lot of routes in the /25 to /29 > range, maybe a couple hundred total when I looked at it last week. The > /24s were huge, about 142,000. I'm curious how many of those /24s are > covered by larger aggregates. Might be a fun experiment figuring out a > safe way to filter those. Probably involve AS path length, maybe RIR > allocations. From roddy.strachan at staff.netspace.net.au Mon Sep 15 00:46:14 2008 From: roddy.strachan at staff.netspace.net.au (Roddy Strachan) Date: Mon, 15 Sep 2008 14:46:14 +1000 Subject: [c-nsp] ASR Netflow Query Message-ID: Hey all, Been playing around with an ASR1004 for terminating L2TP sessions. One thing I?ve noticed that shows up in a cache flow output is the following : gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 17 gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 17 gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 608 gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 17 gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 198 That in turn fills up our flow files on the collectors with data looking like this : 1221452253 x.x.x.x x.x.x.x 0 224.0.0.5 0 12740 2 0 0 0 1221452255 x.x.x.x x.x.x.x 0 224.0.0.5 0 11648 2 0 0 0 1221452259 x.x.x.x x.x.x.x 0 224.0.0.5 0 12740 2 0 0 0 1221452260 x.x.x.x x.x.x.x 0 224.0.0.5 0 12740 2 0 0 0 I don?t see this type of behaviour on the 7200/7300 platform doing the same type of thing for L2TP sessions. >From what I understand its a multicast broadcast for OSPF (correct me if I?m wrong). Is there anyone to turn this off so it doesn?t show up in the ?sh ip cache flow? output ? Therefor not filling up out collector with unnecessary information Thanks 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 claes at gastabud.com Mon Sep 15 02:37:30 2008 From: claes at gastabud.com (Claes Jansson) Date: Mon, 15 Sep 2008 08:37:30 +0200 Subject: [c-nsp] DHCP snooping and DAI In-Reply-To: <2d3f58800809130640o4f290e24od6f6d5d521176cb4@mail.gmail.co m> References: <2d3f58800809130640o4f290e24od6f6d5d521176cb4@mail.gmail.com> Message-ID: <200809150637.m8F6bbLo022177@ns.gastabud.com> Hello! Can't other than agree with you that the 3550 + arp-inspection fails completely :-) But i have been running dhcp-snooping + dai on 3750 for quite some time now, and it works just great! Even better if you add the "ip verify source port-security" on each user interface aswell (eliminating mac-spoofing and loopback problems)... Just be sure to verify the setup so you have option82 running through the network. AFAIK, the switch does not constantly poll the "url database source". It syncronizes the database, writing changes to the database on certain intervals. And the database on the switch is kept only in RAM. If the switch looses communication with the server it will continue to use the in-memory database, until it is connected again. Then it will download the database from the source and syncronize it with the memory-version. What could be a problem is if you reload a switch and your clients have very long dhcp-leases, and the database source is not available. Clients will loose contact until they renew their dhcp-leases. c3750-001#sh ip dhcp snooping database Agent URL : ftp://user:pass at 10.1.1.111/c3750-001.db Write delay Timer : 300 seconds Abort Timer : 300 seconds best regards. //Claes Jansson >Hello, > >I have been researching defenses against so-called 'man-in-the-middle' >attacks at layer 2. We tried this around three years ago with 3550-48 smi >image using dhcp snooping and dynamic arp inspection. After a time the >switch stopped passing dhcp requests. This was in production, (though >thankfully on only one switch) so we didn't have time to troubleshoot the >precise nature of the problem, and gave up on the feature as being 'not >ready for prime-time.' > >Since that time, Cisco seems to have changed the approach slightly. > >Cisco documentation regarding the dhcp database states : >"Because both NVRAM and the flash memory have limited storage capacities, we >recommend that you store a binding file on a TFTP server. You must create an >empty file at the configured URL on network-based URLs (such as TFTP and >FTP) before the switch can first write bindings to the binding file at that >URL." > >AhhHaaa, I had suspected that the switch ran out of memory. > >Now we would like to try it again. Our network is pretty standard, 6500's at >core, 4500 distribution and we will upgrade to either 3560's or 3750's at >the edge (around 200 edge switches.) I would appreciate hearing from anyone >who has used these features. My concerns to start out with are: > > 1. > > What will happen if the switch loses communication with the database > server for some reason? Will the switch stop passing traffic entirely? > 2. > > How much traffic will the checking generate? Is the switch going to reach > out to the database for each flow? If not, how does the switch use the > databas > I am sure there are many more questions and concerns, I simply don't know > what I don't know :-) > >Thanks, >dennis >_______________________________________________ >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 saku+cisco-nsp at ytti.fi Mon Sep 15 02:50:26 2008 From: saku+cisco-nsp at ytti.fi (Saku Ytti) Date: Mon, 15 Sep 2008 09:50:26 +0300 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: References: <20080907075706.GA7640@mx.ytti.net> Message-ID: <20080915065026.GA18822@mx.ytti.net> On (2008-09-14 22:50 +0200), Asbjorn Hojmark - Lists wrote: Hey, > > Just out of curiosity what were main points that left you > > wanting? > > QinQ termination, EoMPLS, VPLS. EoMPLS was show stopper for me, would have EFT'n it to see more closely otherwise. VPLS I don't care, EoMPLS + 7600 as 'vpls hub' is fine for my somewhat rare VPLS needs. QinQ would definitely be show stopper for me too. Are you sure it's not there? At least it can be configured, but couldn't find anyone with ASR1k who could test it on this short notice. -- ++ytti From adrian at creative.net.au Mon Sep 15 03:13:52 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 15 Sep 2008 15:13:52 +0800 Subject: [c-nsp] Dreaded FIB Exception on Sup2 In-Reply-To: <48CDD6EC.4070300@velvet.org> References: <6bb5f5b10809141711n63cff137r9de2682c317f4f2f@mail.gmail.com> <48CDD6EC.4070300@velvet.org> Message-ID: <20080915071352.GE15118@skywalker.creative.net.au> On Sun, Sep 14, 2008, matthew zeier wrote: > I would be interested in the results of such an experiment (I was about > to research this this week myself). > > Church, Charles wrote: > >I got curious last week when I saw this thread. From my (AS 26296) > >point of view, there aren't a whole lot of routes in the /25 to /29 > >range, maybe a couple hundred total when I looked at it last week. The > >/24s were huge, about 142,000. I'm curious how many of those /24s are > >covered by larger aggregates. Might be a fun experiment figuring out a > >safe way to filter those. Probably involve AS path length, maybe RIR > >allocations. If your trust your upstream to get your outbound packets to their eventual destination, then you don't -need- a full table; it just makes outbound TE easier. If you have a lot of peering and unreliable transit (!) then sure, full table is a win. You -can- do differential outbound TE without needing a full BGP table. You just need to find a way to get traffic metrics for flows -to- destinations (netflow? on a sup2? surely you jest Adrian..) and then you can craft temporary injected routes into your Sup2 to do traffic balancing without anywhere near a full table. (Of course, this all falls apart the moment your upstreams start doing dumb stuff like feeding gigabits of traffic through a hacky Sup2 + route injection + filtering, but hey, you're paying -transit- so you don't necessarily need to do all of those wonderful BGP tricks with massively high end kit being pushed to its performance/bug limit, right? :) Adrian From rootnet08 at gmail.com Mon Sep 15 04:46:40 2008 From: rootnet08 at gmail.com (root net) Date: Mon, 15 Sep 2008 03:46:40 -0500 Subject: [c-nsp] Check bandwidth on router In-Reply-To: <67F7C1FAF83A074AA3520D8F155782A501D79ACD@xmb-ams-331.emea.cisco.com> References: <89944ef40809111754s49466f26w38d25fc90df0b4f5@mail.gmail.com> <67F7C1FAF83A074AA3520D8F155782A501D79823@xmb-ams-331.emea.cisco.com> <89944ef40809120653i59281e97h22d206ca3b6092e6@mail.gmail.com> <67F7C1FAF83A074AA3520D8F155782A501D79ACD@xmb-ams-331.emea.cisco.com> Message-ID: <89944ef40809150146w242fbeadi967e23e0803d5098@mail.gmail.com> Thanks to all who have replied I will look into all options. I think Iperf and Netperf are the great tests for PTP links. root net On 9/12/08, Arie Vayner (avayner) wrote: > > Actually, you can use IP SLA for bandwidth testing too. You just need to > find some file which can be pulled off the internet via HTTP/FTP, and > use IP SLA to get it. > The only thing is that you would be killing your user's access to the > net at the time of the test, so testing during peak hours would be out > of the question, while testing the bandwidth in off-peak hours does not > mean much, as the ISP would have extra BW... > > I would monitor the response time for HTTP for small web sites, and just > monitor the trend. The bottom line is that your end users do not really > care about the raw amount of bandwidth, but are really looking for good > response time and consistent service level. > > Its called "Quality of Experience" as opposed to "Quality of Service". > http://en.wikipedia.org/wiki/Quality_of_Experience > > > Arie > > > -----Original Message----- > From: Daniel Hooper [mailto:dhooper at emerge.net.au] > Sent: Friday, September 12, 2008 17:38 PM > To: root net; Arie Vayner (avayner) > Cc: cisco-nsp > > Subject: RE: [c-nsp] Check bandwidth on router > > You can use netperf to test bandwidth, cron it to run daily for 10 > seconds and it will report the bandwidth on your circuits. > > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net > Sent: Friday, 12 September 2008 9:53 PM > To: Arie Vayner (avayner) > Cc: cisco-nsp > Subject: Re: [c-nsp] Check bandwidth on router > > IP SLA seems to be the best option at present. Although we monitor with > some open source tools. I would like to have a way to check that I am > getting what (bandwidth) I am paying for if this makes sense. > > It seems to me that these programs only monitor the circuits not test > throughput. I want to be able to test throughput on the circuit. These > third party sites are ok but I am sure there is someway providers are > doing this with out using speedtest sites? > > rootnet > > On Fri, Sep 12, 2008 at 3:19 AM, Arie Vayner (avayner) > wrote: > > > Dear rootnet, > > > > Not a direct solution to what you want, but did you consider using IP > > SLA for constant performance monitoring? > > You can setup a few IP SLA HTTP probes to well known sites and monitor > > > the performance trend. This would give you a real indication of the > > "quality of experience". > > > > Arie > > > > -----Original Message----- > > From: cisco-nsp-bounces at puck.nether.net > > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net > > Sent: Friday, September 12, 2008 03:55 AM > > To: cisco-nsp > > Subject: [c-nsp] Check bandwidth on router > > > > Hi List, > > > > Is there some sort of tool you can load into the IOS on a router to > > check bandwidth? Or if not what are you all doing these days in this > > situation. > > Like for example things are running slow and you think the Internet > feed > > may be the problem is there a way to do speed tests on the router > > itself? > > > > rootnet > > _______________________________________________ > > 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 s00664233 at gmail.com Mon Sep 15 05:37:01 2008 From: s00664233 at gmail.com (cc loo) Date: Mon, 15 Sep 2008 17:37:01 +0800 Subject: [c-nsp] VRF/ VRF-lite RD and Route-target MAX SIZE Message-ID: <49999c420809150237j14b0af0btbfaa38afef3d9e73@mail.gmail.com> Hi all, while practicing with VRF-lite recently, i seem to have encounter with a nasty problem. I typed in manually this sample config, it works (credits to oliver from cisco): !---------------------------------- ip vrf customer_A rd 1:1 route-target export 1:100 route-target import 1:900 ! ip vrf customer_B rd 1:2 route-target export 1:200 route-target import 1:900 ! ip vrf Hub rd 1:9 route-target export 1:900 route-target import 1:100 route-target import 1:200 ! router bgp 65000 address-fam ipv4 vrf customer_A redistribute static redistribute connected address-fam ipv4 vrf customer_B redistribute static redistribute connected address-fam ipv4 vrf Hub redistribute static redistribute connected !---------------------------------- So i went off to experiment more numbers, such as rd 1:0 rd 1:9999 etc After the usual configuration, i realise my inter-vrf routes did not propagate through and couldnt figure out whats going on. I also did clear ip vrf * and waited for BGP to advertise itself, but still no show. Last move : Write erase and reconfig again but tis time with smaller numbers RD 1:99 This time it work properly. I was wondering if this is due to me using some illegal numbers such as zero or 9999. I have went through articles that RD are meant to be 8bytes (ip:NN or asn:NN), so i assume NN = 4bytes or 32bits , hence the max value should be 65535 ? Cisco IOS tabbing recommends the syntax as ASN:NN , does it properly reflect 2 digits only ? I find it wierd that only 99 vpns are supported if so. Do you have any experience on this ? From swmike at swm.pp.se Mon Sep 15 06:32:06 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 15 Sep 2008 12:32:06 +0200 (CEST) Subject: [c-nsp] VRF/ VRF-lite RD and Route-target MAX SIZE In-Reply-To: <49999c420809150237j14b0af0btbfaa38afef3d9e73@mail.gmail.com> References: <49999c420809150237j14b0af0btbfaa38afef3d9e73@mail.gmail.com> Message-ID: On Mon, 15 Sep 2008, cc loo wrote: > Cisco IOS tabbing recommends the syntax as ASN:NN , does it properly > reflect 2 digits only ? I find it wierd that only 99 vpns are supported > if so. I have successfully configured RT as both ASN:number (where ASN was presumed to be 16bit and number was 32bit (as per RT standards)) and as IP:number (where IP was 32 bits and number was 16 bit), so that much should work anyway. I've also run into trouble where RT was configured as IP:number and the number was higher than 16 bit would tolerate, so I know for a fact this is troublesome on at least one platform. -- Mikael Abrahamsson email: swmike at swm.pp.se From eric at atlantech.net Mon Sep 15 07:11:24 2008 From: eric at atlantech.net (Eric Van Tol) Date: Mon, 15 Sep 2008 07:11:24 -0400 Subject: [c-nsp] ME3750 Shaping In-Reply-To: <67F7C1FAF83A074AA3520D8F155782A501D79B57@xmb-ams-331.emea.cisco.com> References: <2C05E949E19A9146AF7BDF9D44085B86350AECC47E@exchange.aoihq.local> <67F7C1FAF83A074AA3520D8F155782A501D79ACF@xmb-ams-331.emea.cisco.com> <2C05E949E19A9146AF7BDF9D44085B86350AECC484@exchange.aoihq.local> <67F7C1FAF83A074AA3520D8F155782A501D79B57@xmb-ams-331.emea.cisco.com> Message-ID: <2C05E949E19A9146AF7BDF9D44085B86350AECC48D@exchange.aoihq.local> > -----Original Message----- > From: Arie Vayner (avayner) [mailto:avayner at cisco.com] > Sent: Saturday, September 13, 2008 1:54 PM > To: Eric Van Tol; cisco-nsp at puck.nether.net > Subject: RE: [c-nsp] ME3750 Shaping > > Eric, > > Take a 2nd look here: > http://www.cisco.com/en/US/docs/switches/metro/catalyst3750m/software/re > lease/12.2_46_se/configuration/guide/swqos.html#wp1282429 > > Arie > Hi again Arie, This appears to only apply to ES ports, which is not what I'm looking for. The idea here is very simple - there are ports that receive a data-only service and a ports that receive both data and voice. Rather than burn up additional ports for voice, it makes sense to me to take advantage of the technology and use a single port with proper policing/shaping/queuing to provide two services over a single non-ES port. Is this kind of service delivery really that...out there? -evt From MLouis at nwnit.com Mon Sep 15 07:39:59 2008 From: MLouis at nwnit.com (Mike Louis) Date: Mon, 15 Sep 2008 07:39:59 -0400 Subject: [c-nsp] NTP not synchronizing In-Reply-To: <89944ef40809142116jf1957e7jba0d52a226f8b5ad@mail.gmail.com> References: <8DD1F4B50477AC45A35AB5F8C03B62C4018567AB@sauce.ulima.ul> <89944ef40809142116jf1957e7jba0d52a226f8b5ad@mail.gmail.com> Message-ID: What source interface is the cisco client router using for NTP requests? If its not configured it will use the outbound interface used to reach the server. I saw an issue the other day where the external interface on the WAN was not reachable by the NTP server at the home office and thus they could not sync time. They changed the source interface to "ntp source-interface Fax/x" (for their lan which was reachable) and were able to get sync'd. HTH Mike -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net Sent: Monday, September 15, 2008 12:17 AM To: Velasquez Venegas Jaime Omar Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] NTP not synchronizing What NTP server are you using? Are you trying to use the Cisco router as the NTP server for your clients/hosts on your network or what? My bet is the NTP server is overwhelmed you are trying to connect to. I had this issue before and changed NTP servers worked like a charm. Check the NIST listing for an updated listing of NTP servers that are free or with little users. rootnet On Sat, Sep 13, 2008 at 1:30 PM, Velasquez Venegas Jaime Omar < Jaime at ulima.edu.pe> wrote: > Hi there. > > I'm having a problem trying to synchronize a Cisco Router across a wan > link with a NTP Server (No-Cisco router).So far i've ruled out packet > filering or firewall blocking as a cause of this.Some other equipments > at the local side of this router actually synchronize with the ntp > server at our LAN.What strikes me is the fact that router does reach ntp > server via other protocols other than ntp tough. > > > This is what i get from the out-of-sync router: > #Show ntp assoc > address ref clock st when poll reach delay offset > disp > ~<> 0.0.0.0 16 - 64 0 0.0 0.00 > 16000. > * master (synced), # master (unsynced), + selected, - candidate, ~ > configured > > I've set debugging for the ntp packets and for all the traffic getting > out of the serial interface which got "NTP: xmit packet to NTP.Server" > events.However there 's absolutely no attempt whatsoever of packet being > transmitted to NTP Server at the serial interface. > I've also configured this router as a ntp master and tried to get the > hosts on its local ethernet to synchronize with it to no avail. > > Any insight? > > 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/ > _______________________________________________ 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. From aaronis at people.net.au Mon Sep 15 08:11:50 2008 From: aaronis at people.net.au (Aaron R) Date: Mon, 15 Sep 2008 20:11:50 +0800 Subject: [c-nsp] NTP not synchronizing In-Reply-To: Message-ID: <200809151211.m8FCBrPQ061496@puck.nether.net> I have had similar problems in the past. I have found if your clock / date are not set properly the router will refuse to accept the NTP update as the offset is too large. Also as suggested try multiple NTP servers. The fact that you are unable to see the configured NTP servers' ref clock / stratum most likely indicates some kind of comms issue. Cheers, Aaron. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mike Louis Sent: Monday, September 15, 2008 7:40 PM To: root net; Velasquez Venegas Jaime Omar Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] NTP not synchronizing What source interface is the cisco client router using for NTP requests? If its not configured it will use the outbound interface used to reach the server. I saw an issue the other day where the external interface on the WAN was not reachable by the NTP server at the home office and thus they could not sync time. They changed the source interface to "ntp source-interface Fax/x" (for their lan which was reachable) and were able to get sync'd. HTH Mike -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net Sent: Monday, September 15, 2008 12:17 AM To: Velasquez Venegas Jaime Omar Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] NTP not synchronizing What NTP server are you using? Are you trying to use the Cisco router as the NTP server for your clients/hosts on your network or what? My bet is the NTP server is overwhelmed you are trying to connect to. I had this issue before and changed NTP servers worked like a charm. Check the NIST listing for an updated listing of NTP servers that are free or with little users. rootnet On Sat, Sep 13, 2008 at 1:30 PM, Velasquez Venegas Jaime Omar < Jaime at ulima.edu.pe> wrote: > Hi there. > > I'm having a problem trying to synchronize a Cisco Router across a wan > link with a NTP Server (No-Cisco router).So far i've ruled out packet > filering or firewall blocking as a cause of this.Some other equipments > at the local side of this router actually synchronize with the ntp > server at our LAN.What strikes me is the fact that router does reach ntp > server via other protocols other than ntp tough. > > > This is what i get from the out-of-sync router: > #Show ntp assoc > address ref clock st when poll reach delay offset > disp > ~<> 0.0.0.0 16 - 64 0 0.0 0.00 > 16000. > * master (synced), # master (unsynced), + selected, - candidate, ~ > configured > > I've set debugging for the ntp packets and for all the traffic getting > out of the serial interface which got "NTP: xmit packet to NTP.Server" > events.However there 's absolutely no attempt whatsoever of packet being > transmitted to NTP Server at the serial interface. > I've also configured this router as a ntp master and tried to get the > hosts on its local ethernet to synchronize with it to no avail. > > Any insight? > > 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/ > _______________________________________________ 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. _______________________________________________ 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 - http://www.avg.com Version: 8.0.169 / Virus Database: 270.6.21/1670 - Release Date: 9/14/2008 7:16 AM From Andrew.Cheng at aapt.com.au Mon Sep 15 08:13:38 2008 From: Andrew.Cheng at aapt.com.au (Andrew Cheng) Date: Mon, 15 Sep 2008 22:13:38 +1000 Subject: [c-nsp] Time based netflow sampling on 7600 Message-ID: Hi Everybody Has anybody had any real world experiences running time based sampling on a 7600 as a way to still be able to extrapolate traffic through the box even if the TCAM cache fills up? From what I've read in the documentation, if you configure say a time based sampling rate of 1024, it simply exports the first 4ms of every 4096ms window (router actually says 8 in 8192). Hence, if the cache fills up within the export interval, you can still multiple by the sampling rate and get something rather accurate. I've tested this in a lab environment with 25kflows/sec of non-bursty traffic, (ie, not even filling the TCAM in the 8192ms window) and the netflow records are way way out. However if I change to packet based sampling, they're 99% accurate (That is until flows/sec increase and fill the TCAM of course..) Thanks Andrew This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. From rodunn at cisco.com Mon Sep 15 10:22:37 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Mon, 15 Sep 2008 10:22:37 -0400 Subject: [c-nsp] ASR Netflow Query In-Reply-To: References: Message-ID: <20080915142237.GB4112@rtp-cse-489.cisco.com> Roddy, Do you see a corresponding match for the frame mapped to the VAI for the user? Or are those OSPF hellos coming from OSPF neighbors directly attached to the g0/1/0.1 subinterface? Can you provide the output with the column headers? Rodney On Mon, Sep 15, 2008 at 02:46:14PM +1000, Roddy Strachan wrote: > Hey all, > > Been playing around with an ASR1004 for terminating L2TP sessions. > > One thing I?ve noticed that shows up in a cache flow output is the following > : > > gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 17 > gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 17 > gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 608 > gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 17 > gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 198 > > That in turn fills up our flow files on the collectors with data looking > like this : > > 1221452253 x.x.x.x x.x.x.x 0 224.0.0.5 0 12740 2 0 0 0 > 1221452255 x.x.x.x x.x.x.x 0 224.0.0.5 0 11648 2 0 0 0 > 1221452259 x.x.x.x x.x.x.x 0 224.0.0.5 0 12740 2 0 0 0 > 1221452260 x.x.x.x x.x.x.x 0 224.0.0.5 0 12740 2 0 0 0 > > > I don?t see this type of behaviour on the 7200/7300 platform doing the same > type of thing for L2TP sessions. > > >From what I understand its a multicast broadcast for OSPF (correct me if I?m > wrong). > > Is there anyone to turn this off so it doesn?t show up in the ?sh ip cache > flow? output ? Therefor not filling up out collector with unnecessary > information > > Thanks > > > > 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/ From serge.devorop at gmail.com Mon Sep 15 10:39:44 2008 From: serge.devorop at gmail.com (Sergey Voropaev) Date: Mon, 15 Sep 2008 18:39:44 +0400 Subject: [c-nsp] Full meshed corporate network, QoS - best practices Message-ID: Hi members, I would like to know best practices in the following network design. We are some company with distributed office location all over the world. We lease IP/MPLS service on our service provider, but in some offices we buy 10Mb/s and in another 1Mb/s. The aim is to configure our CE-routers such that all shaping and traffic prioritisation will performing on its and no data was lost at the SP core. As I understand SP use policer to inbound and outbound traffic. It is not acceptable use common shaping to the outbound interface. For example OFFICE_1 buy 10Mb/s and OFFICE_2 only 1Mb/s. If we configure shaping on the outbound interface on OFFICE_1's router there will be congestion on the OFFICE_2's PE-router and traffic will be dropped by SP. We can configure shaping for every single class. For example we can create class "OFFICE_1<--->OFFICE_2" and shape it to 1Mb/s. And then shape all this classes by parent shaper applied to outbound interface. But this is also unacceptable because of if traffic to OFFICE_2 will be forwarded from TWO sites like as OFFICE_1 there will congestion on OFFICE_2's PE-router. Is there QOS solution for such design? Thanks in advance. From gert at greenie.muc.de Mon Sep 15 10:50:13 2008 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 15 Sep 2008 16:50:13 +0200 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <48BD78D4.6010405@gmail.com> References: <48B5602E.7010705@imperial.ac.uk> <079b01c90970$092d2330$f211a8c0@flamadam> <20080829072040.GD27310@lboro.ac.uk> <48BC0B53.4040000@imperial.ac.uk> <20080901154700.GB24224@lboro.ac.uk> <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> <20080902062732.GU233@greenie.muc.de> <48BD6380.6050309@gmail.com> <20080902171259.GB233@greenie.muc.de> <48BD78D4.6010405@gmail.com> Message-ID: <20080915145013.GA2245@greenie.muc.de> Hi, following up on this: On Tue, Sep 02, 2008 at 08:33:08PM +0300, Adrian Minta wrote: > Gert Doering wrote: > >On Tue, Sep 02, 2008 at 07:02:08PM +0300, Adrian Minta wrote: > >>> - the BGP ghost bug is back :-( I have now managed to open a TAC case on this - in case you want to open your own case and attach to it, it's "SR 609533003". We have no BugID yet, TAC is trying to reproduce it. In our network, reproducing the problem is fairly straightforward (and I have demonstrated it to the TAC engineer, who then mumbled something like "I think you have found a bug here" - surprise, surprise :) ): Host H, AS 65500 ------ Router A, AS 5539 ---- Router B, AS 5539 Host H announces a single prefix via eBGP to Router A. Router A has a "bog standard" iBGP session to Router B. No(!) filters of any kind between A and B. Now "inject instabilities" -> tear down the BGP session H<->A, bring it up again, wait a few minutes, tear it down again, and so on. After somewhat between 2 and 10 "session down", the following happens: - on Router A, the prefix completely drops from the BGP table Cisco-A#sh ip b 193.31.7.1/32 % Network not in table - on Router B, the prefix is still visible, via "A": Cisco-B#sh ip b 193.31.7.1/32 BGP routing table entry for 193.31.7.1/32, version 16726560 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x820 Advertised to update-groups: 4 65500 195.30.H.H (metric 3584) from 193.149.A.A (194.97.A.A) Origin IGP, metric 0, localpref 100, valid, internal, best it doesn't matter whether "next-hop-self" is used or whether "B" is a normal iBGP peer or a route-reflector-client (or whether a mixture of "normal peers and RR clients" exists). "A" just forgets - occasionally - to send withdraws if it doesn't have the prefix any longer. Of course A and B have full BGP tables - and as there is instability and withdraws out there, we see this happen to about 5-20 prefixes per day. It might have to do with the amount of "normal" updates going on in parallel - "if there is lots of updates, then there is a propability that things will get lost". But maybe not. (I have not yet tested in a "pure lab" environment, with no other BGP updates between A and B). 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: 304 bytes Desc: not available URL: From gert at greenie.muc.de Mon Sep 15 11:12:10 2008 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 15 Sep 2008 17:12:10 +0200 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <20080915145013.GA2245@greenie.muc.de> References: <079b01c90970$092d2330$f211a8c0@flamadam> <20080829072040.GD27310@lboro.ac.uk> <48BC0B53.4040000@imperial.ac.uk> <20080901154700.GB24224@lboro.ac.uk> <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> <20080902062732.GU233@greenie.muc.de> <48BD6380.6050309@gmail.com> <20080902171259.GB233@greenie.muc.de> <48BD78D4.6010405@gmail.com> <20080915145013.GA2245@greenie.muc.de> Message-ID: <20080915151210.GB2245@greenie.muc.de> Hi, On Mon, Sep 15, 2008 at 04:50:13PM +0200, Gert Doering wrote: > Cisco-A#sh ip b 193.31.7.1/32 > % Network not in table > > Cisco-B#sh ip b 193.31.7.1/32 > BGP routing table entry for 193.31.7.1/32, version 16726560 > Paths: (1 available, best #1, table Default-IP-Routing-Table) > Flag: 0x820 > Advertised to update-groups: > 4 > 65500 > 195.30.H.H (metric 3584) from 193.149.A.A (194.97.A.A) > Origin IGP, metric 0, localpref 100, valid, internal, best Oh, and I've found a workaround what to do in this case - since doing a "clear ip bgp * soft" doesn't work, and a and hard clear of all the iBGP sessions is a bit disturbative... What you need to do is: - insert a static route for that prefix which gets distributed into BGP - remove static route for us, this is straightfoward - we are redistributing static routes -> bgp based on route tags, so it's just "ip route $prefix $mask tag NNNN" and remove the route again, 5 seconds later. 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: 304 bytes Desc: not available URL: From loui at renater.fr Mon Sep 15 10:45:31 2008 From: loui at renater.fr (Frederic LOUI) Date: Mon, 15 Sep 2008 16:45:31 +0200 Subject: [c-nsp] Check bandwidth on router In-Reply-To: <89944ef40809150146w242fbeadi967e23e0803d5098@mail.gmail.com> References: <89944ef40809111754s49466f26w38d25fc90df0b4f5@mail.gmail.com> <67F7C1FAF83A074AA3520D8F155782A501D79823@xmb-ams-331.emea.cisco.com> <89944ef40809120653i59281e97h22d206ca3b6092e6@mail.gmail.com> <67F7C1FAF83A074AA3520D8F155782A501D79ACD@xmb-ams-331.emea.cisco.com> <89944ef40809150146w242fbeadi967e23e0803d5098@mail.gmail.com> Message-ID: <48CE750B.9060209@renater.fr> Hi, > Thanks to all who have replied I will look into all options. > I think Iperf and Netperf are the great tests for PTP links. Maybe you could have a look at that page :http://kb.pert.geant2.net/PERTKB/BandwidthMeasurementTools that extensively use IPPERF/BWCTL so as to troubleshoot TCP window issue. Basically, PERT (Performance Enhancement Response Team) is mainly focused on Performance issue. Hope this help, Cheers/Fred -- Frederic LOUI / GIP RENATER Service de Suivi Operationnel / Metrologie & QoS Network Operations Service / Metrology & QoS Tel: +33 1 53 94 20 82 / Fax: +33 1 53 94 20 31 frederic.loui at renater.fr http://www.renater.fr root net a ?crit : > Thanks to all who have replied I will look into all options. I think Iperf > and Netperf are the great tests for PTP links. > > root net > > On 9/12/08, Arie Vayner (avayner) wrote: >> Actually, you can use IP SLA for bandwidth testing too. You just need to >> find some file which can be pulled off the internet via HTTP/FTP, and >> use IP SLA to get it. >> The only thing is that you would be killing your user's access to the >> net at the time of the test, so testing during peak hours would be out >> of the question, while testing the bandwidth in off-peak hours does not >> mean much, as the ISP would have extra BW... >> >> I would monitor the response time for HTTP for small web sites, and just >> monitor the trend. The bottom line is that your end users do not really >> care about the raw amount of bandwidth, but are really looking for good >> response time and consistent service level. >> >> Its called "Quality of Experience" as opposed to "Quality of Service". >> http://en.wikipedia.org/wiki/Quality_of_Experience >> >> >> Arie >> >> >> -----Original Message----- >> From: Daniel Hooper [mailto:dhooper at emerge.net.au] >> Sent: Friday, September 12, 2008 17:38 PM >> To: root net; Arie Vayner (avayner) >> Cc: cisco-nsp >> >> Subject: RE: [c-nsp] Check bandwidth on router >> >> You can use netperf to test bandwidth, cron it to run daily for 10 >> seconds and it will report the bandwidth on your circuits. >> >> >> -----Original Message----- >> From: cisco-nsp-bounces at puck.nether.net >> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net >> Sent: Friday, 12 September 2008 9:53 PM >> To: Arie Vayner (avayner) >> Cc: cisco-nsp >> Subject: Re: [c-nsp] Check bandwidth on router >> >> IP SLA seems to be the best option at present. Although we monitor with >> some open source tools. I would like to have a way to check that I am >> getting what (bandwidth) I am paying for if this makes sense. >> >> It seems to me that these programs only monitor the circuits not test >> throughput. I want to be able to test throughput on the circuit. These >> third party sites are ok but I am sure there is someway providers are >> doing this with out using speedtest sites? >> >> rootnet >> >> On Fri, Sep 12, 2008 at 3:19 AM, Arie Vayner (avayner) >> wrote: >> >>> Dear rootnet, >>> >>> Not a direct solution to what you want, but did you consider using IP >>> SLA for constant performance monitoring? >>> You can setup a few IP SLA HTTP probes to well known sites and monitor >>> the performance trend. This would give you a real indication of the >>> "quality of experience". >>> >>> Arie >>> >>> -----Original Message----- >>> From: cisco-nsp-bounces at puck.nether.net >>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net >>> Sent: Friday, September 12, 2008 03:55 AM >>> To: cisco-nsp >>> Subject: [c-nsp] Check bandwidth on router >>> >>> Hi List, >>> >>> Is there some sort of tool you can load into the IOS on a router to >>> check bandwidth? Or if not what are you all doing these days in this >>> situation. >>> Like for example things are running slow and you think the Internet >> feed >>> may be the problem is there a way to do speed tests on the router >>> itself? >>> >>> rootnet >>> _______________________________________________ >>> 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 benny+usenet at amorsen.dk Mon Sep 15 11:43:43 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Mon, 15 Sep 2008 17:43:43 +0200 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <20080915065026.GA18822@mx.ytti.net> (Saku Ytti's message of "Mon\, 15 Sep 2008 09\:50\:26 +0300") References: <20080907075706.GA7640@mx.ytti.net> <20080915065026.GA18822@mx.ytti.net> Message-ID: Feature Navigator says that "IEEE 802.1Q-in-Q VLAN Tag Termination" is available in asr1000rp1-ipbase.02.01.00.122-33.XNA.bin. I was certainly worried for a minute there :) /Benny From MLouis at nwnit.com Mon Sep 15 14:00:30 2008 From: MLouis at nwnit.com (Mike Louis) Date: Mon, 15 Sep 2008 14:00:30 -0400 Subject: [c-nsp] OT - Wireshark Export Message-ID: List, Does anyone know of a way to export the statistics in the SMB service response time window from within wireshark? I am using wireshark to analyze some Cisco WAAS traffic and I can generate the SMB stats but I can't get them out of Wireshark into Excel where I need to them? Any ideas? ________________________________ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. From dr at cluenet.de Mon Sep 15 15:23:38 2008 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 15 Sep 2008 21:23:38 +0200 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <20080915065026.GA18822@mx.ytti.net> References: <20080907075706.GA7640@mx.ytti.net> <20080915065026.GA18822@mx.ytti.net> Message-ID: <20080915192338.GA2897@srv01.cluenet.de> On Mon, Sep 15, 2008 at 09:50:26AM +0300, Saku Ytti wrote: > > > Just out of curiosity what were main points that left you > > > wanting? > > > > QinQ termination, EoMPLS, VPLS. > > EoMPLS was show stopper for me, would have EFT'n it to see > more closely otherwise. > VPLS I don't care, EoMPLS + 7600 as 'vpls hub' is fine > for my somewhat rare VPLS needs. > > QinQ would definitely be show stopper for me too. Are you > sure it's not there? At least it can be configured, but > couldn't find anyone with ASR1k who could test it on this > short notice. We did some basic testing today on 2.1.1 and it worked fine so far (basic pinging): interface GigabitEthernet0/3/1.1 encapsulation dot1Q 500 second-dot1q 199 ip address 10.199.0.2 255.255.255.252 ! interface GigabitEthernet0/3/1.2 encapsulation dot1Q 500 second-dot1q 200 ip address 10.200.0.2 255.255.255.252 Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From insan_katob at yahoo.com Mon Sep 15 15:51:28 2008 From: insan_katob at yahoo.com (insan praja) Date: Mon, 15 Sep 2008 12:51:28 -0700 (PDT) Subject: [c-nsp] [cisco-nsp] [OOT] Getting help to get the network acceptable Message-ID: <335055.82205.qm@web50308.mail.re2.yahoo.com> Hi, My company recently bought 202[dot]90[dot]194[dot]0/23 IPs, and since we start using this IPs, I can't access several site on the net. When check through robtex.com, a company in India seem to still include these IPs into their RADB database. I can't email them, browse their sites, maybe because of some antispoof things. We asked our upstream to include this IPs to their radb accounts, but it seem nothing changed, as we check to robtex.com, these IPs still originated as AS9829 route-object. I really appreciate if anyone in the list could help me getting these IPs to be correctly accepted to browse the internet. Best Regards, Insan From chrismcc at pricegrabber.com Mon Sep 15 15:56:08 2008 From: chrismcc at pricegrabber.com (Christopher McCrory) Date: Mon, 15 Sep 2008 12:56:08 -0700 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <20080915145013.GA2245@greenie.muc.de> References: <48B5602E.7010705@imperial.ac.uk> <079b01c90970$092d2330$f211a8c0@flamadam> <20080829072040.GD27310@lboro.ac.uk> <48BC0B53.4040000@imperial.ac.uk> <20080901154700.GB24224@lboro.ac.uk> <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> <20080902062732.GU233@greenie.muc.de> <48BD6380.6050309@gmail.com> <20080902171259.GB233@greenie.muc.de> <48BD78D4.6010405@gmail.com> <20080915145013.GA2245@greenie.muc.de> Message-ID: <1221508568.7357.15.camel@localhost> Hello... I'm curious, is bgp dampening on or off? On Mon, 2008-09-15 at 16:50 +0200, Gert Doering wrote: > Hi, > > following up on this: > > On Tue, Sep 02, 2008 at 08:33:08PM +0300, Adrian Minta wrote: > > Gert Doering wrote: > > >On Tue, Sep 02, 2008 at 07:02:08PM +0300, Adrian Minta wrote: > > >>> - the BGP ghost bug is back :-( > > I have now managed to open a TAC case on this - in case you want to > open your own case and attach to it, it's "SR 609533003". We have no > BugID yet, TAC is trying to reproduce it. > > > In our network, reproducing the problem is fairly straightforward (and > I have demonstrated it to the TAC engineer, who then mumbled something > like "I think you have found a bug here" - surprise, surprise :) ): > > > Host H, AS 65500 ------ Router A, AS 5539 ---- Router B, AS 5539 > > Host H announces a single prefix via eBGP to Router A. > > Router A has a "bog standard" iBGP session to Router B. No(!) filters > of any kind between A and B. > > > Now "inject instabilities" -> tear down the BGP session H<->A, bring it > up again, wait a few minutes, tear it down again, and so on. After > somewhat between 2 and 10 "session down", the following happens: > > - on Router A, the prefix completely drops from the BGP table > > Cisco-A#sh ip b 193.31.7.1/32 > % Network not in table > > - on Router B, the prefix is still visible, via "A": > > Cisco-B#sh ip b 193.31.7.1/32 > BGP routing table entry for 193.31.7.1/32, version 16726560 > Paths: (1 available, best #1, table Default-IP-Routing-Table) > Flag: 0x820 > Advertised to update-groups: > 4 > 65500 > 195.30.H.H (metric 3584) from 193.149.A.A (194.97.A.A) > Origin IGP, metric 0, localpref 100, valid, internal, best > > > it doesn't matter whether "next-hop-self" is used or whether "B" is > a normal iBGP peer or a route-reflector-client (or whether a mixture of > "normal peers and RR clients" exists). "A" just forgets - occasionally - > to send withdraws if it doesn't have the prefix any longer. > > Of course A and B have full BGP tables - and as there is instability and > withdraws out there, we see this happen to about 5-20 prefixes per day. > > It might have to do with the amount of "normal" updates going on in > parallel - "if there is lots of updates, then there is a propability > that things will get lost". But maybe not. (I have not yet tested in > a "pure lab" environment, with no other BGP updates between A and B). > > > 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/ -- Christopher McCrory "The guy that keeps the servers running" To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be. From A.L.M.Buxey at lboro.ac.uk Mon Sep 15 16:05:38 2008 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Mon, 15 Sep 2008 21:05:38 +0100 Subject: [c-nsp] [cisco-nsp] [OOT] Getting help to get the network acceptable In-Reply-To: <335055.82205.qm@web50308.mail.re2.yahoo.com> References: <335055.82205.qm@web50308.mail.re2.yahoo.com> Message-ID: <20080915200538.GA27083@lboro.ac.uk> Hi, > Hi, > My company recently bought 202[dot]90[dot]194[dot]0/23 IPs, and since we start using this IPs, I can't access several site on the net. When check through robtex.com, a company in India seem to still include these IPs into their RADB database. I can't email them, browse their sites, maybe because of some antispoof things. We asked our upstream to include this IPs to their radb accounts, but it seem nothing changed, as we check to robtex.com, these IPs still originated as AS9829 route-object. > I really appreciate if anyone in the list could help me getting these IPs to be correctly accepted to browse the internet. > Best Regards, > Insan this address range is from APNIC and all looks okay from the usual records: inetnum: 202.90.194.0 - 202.90.195.255 netname: GREENLINKS-ID descr: PT. Bandung Sinergi Akses Teknologi descr: Graha Bumiputera, Suite 401-403 descr: Jalan Asia Afrika 141 - 149 descr: Bandung 40112, Indonesia country: ID admin-c: IW104-AP tech-c: IW104-AP remarks: Send Spam & Abuse report to: remarks: abuse at mygreenlinks.net mnt-by: MNT-APJII-ID mnt-routes: MAINT-ID-GREENLINKS status: ASSIGNED PORTABLE changed: hm-changed at apnic.net 20080716 source: APNIC person: Insan Praja Setya Wibawa nic-hdl: IW104-AP e-mail: insan at mygreenlinks.net address: Graha Bumiputera suite 401,203 4th Floor phone: +62-22-4242024 fax-no: +62-22-4242025 country: ID changed: adi at arsen.co.id 20080703 mnt-by: MAINT-NEW source: APNIC who are you peered with - are they doing the correct routing? where does it break down? a traceroute from here stops at Pishon: 7 if-15-0-0.mcore3.LDN-London.as6453.net (195.219.195.85) 4.534 ms 4.527 ms 4.524 ms 8 if-1-0-1.core1.MLV-Mumbai.as6453.net (195.219.195.58) 138.515 ms 138.522 ms 138.529 ms 9 if-13-0-0.core2.MLV-Mumbai.as6453.net (209.58.105.42) 142.259 ms 142.129 ms 142.167 ms 10 if-2-0-0.core1.CFO-Chennai.as6453.net (216.6.13.54) 168.261 ms 168.160 ms 168.181 ms 11 if-13-0-0.core1.S9R-Singapore.as6453.net (116.0.79.6) 204.100 ms 204.096 ms 204.093 ms 12 119.110.112.201 (119.110.112.201) 207.798 ms 207.791 ms 207.789 ms 13 119.110.112.250 (119.110.112.250) 207.711 ms 207.807 ms 207.986 ms 14 119.110.126.2 (119.110.126.2) 264.800 ms 264.794 ms 264.790 ms 15 121.52.128.105 (121.52.128.105) 216.981 ms 216.980 ms 217.245 ms alan From dan at beanfield.com Mon Sep 15 16:09:51 2008 From: dan at beanfield.com (Dan Armstrong) Date: Mon, 15 Sep 2008 16:09:51 -0400 Subject: [c-nsp] L2PT on Trunk Ports Message-ID: <48CEC10F.7030904@beanfield.com> Has anybody worked extensively with L2PT on Trunk ports on Cisco's ME platforms? The documentation on their site is weak... This may seem like a dumb question, but is L2PT "vlan aware" on a trunk port? (yes, I realize how dumb that sounds) Specifically, with per vlan spanning tree, (or rstp, or mst) would it 'broadcast' the stp packets received from say, vlan 10 on a trunk to all other vlan 10s on trunk ports? and keep them separate from other VLANs? Is there such a thing as per VLAN CDP?! I thought CDP was pretty primitive and couldn't really be vlan aware, so how does that get tunneled across a trunk? On all VLANs? Just One? Which one? What if I have a dozen remote access ports all tunneling cdp (or not per vlan stp?) back to a single trunk - which cdp do we believe? Which stp do we believe? What if some of these remote sites are running old not per vlan spanning tree, and some are? From paul.cosgrove at heanet.ie Mon Sep 15 16:14:21 2008 From: paul.cosgrove at heanet.ie (Paul Cosgrove) Date: Mon, 15 Sep 2008 21:14:21 +0100 Subject: [c-nsp] [cisco-nsp] [OOT] Getting help to get the network acceptable In-Reply-To: <335055.82205.qm@web50308.mail.re2.yahoo.com> References: <335055.82205.qm@web50308.mail.re2.yahoo.com> Message-ID: <48CEC21D.1060608@heanet.ie> insan praja wrote: > Hi, > My company recently bought 202[dot]90[dot]194[dot]0/23 IPs, and since we start using this IPs, I can't access several site on the net. When check through robtex.com, a company in India seem to still include these IPs into their RADB database. I can't email them, browse their sites, maybe because of some antispoof things. We asked our upstream to include this IPs to their radb accounts, but it seem nothing changed, as we check to robtex.com, these IPs still originated as AS9829 route-object. > I really appreciate if anyone in the list could help me getting these IPs to be correctly accepted to browse the internet. > Best Regards, > Insan > > > > _______________________________________________ > 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/ > > Can't you email them from the same account you are using here? If you send them an email from your yahoo web account it should not be affected by any antispoofing. You realise this seems a very perculiar request when you do not include your company name or any verifiable contact information. Paul. From jhigham at epri.com Mon Sep 15 15:47:27 2008 From: jhigham at epri.com (Higham, Josh) Date: Mon, 15 Sep 2008 12:47:27 -0700 Subject: [c-nsp] Full meshed corporate network, QoS - best practices In-Reply-To: References: Message-ID: <4C3B8C75B5899943AEC675BA6DD46273012D541D@uspalex02.epri.com> > Sergey Voropaev > > We can configure shaping for every single class. For example we can > create class "OFFICE_1<--->OFFICE_2" and shape it to 1Mb/s. And then > shape all this classes by parent shaper applied to outbound interface. > But this is also unacceptable because of if traffic to OFFICE_2 will > be forwarded from TWO sites like as OFFICE_1 there will congestion on > OFFICE_2's PE-router. > > Is there QOS solution for such design? The only way to do this (that I know about) is to purchase QoS of some sort from the SP. You configure your routers to send the correct markings to the SP, and they will shape at the point of contention. They will have some limitations on the number of classes and queue allocation, but the queue/drop/forward decision will be made at the point of congestion so you don't have to worry about doing any of that on your end. Thanks, Josh From tik at lufttransport.no Mon Sep 15 15:29:59 2008 From: tik at lufttransport.no (Tor-Ivar Kristoffersen) Date: Mon, 15 Sep 2008 21:29:59 +0200 Subject: [c-nsp] Cisco Unified Communications Manager v6.1 - Set-up Message-ID: <441C449160381D49A93241C6EE5B80160BC7E78FA0@ltexchange.lufttransport.no> Hi everyone I was just wondering if anyone have got a cookbook sort of document for Call Manager v6.1. One that steps you through a setup of calling search spaces, partitions, route liste and so on. I had this for CCM 4.1, but I lost It somewhere, and now we have moved on to 6.1. After this I have decided to start some housekeeping inside call manager, but there are to many things that can go wrong. Also I have not worked too much with the old CCM 4.1, so I'm kinda "feeling" my way forward. Therefore I have createt a test server to practice on, but some cookbooks would be gladly appreciatet. The main issues, if someone wants to comment on them, are these. - We have 2 companies inside the CCM, When it was made it was supposed to be separatet in 2 partitons, 2 dp and so on. This was made, but did not work as expected. So the supplier put all in on Partition and 1 device pool. But we have different numbers. Also it appears we use the same RouteGroup, - The Next issue I'm beginning to think has to do with the first one. If we set a phone to redirect every incomming call to a cell phone, that cell phone sees only the number from which we forwarded(i.e the office phone number) not the number of the one actually calling. - Also we have lost our dialing tone when forwarding calls, it's just totally silent until the cell phone picks up the call. This Cisco belives to be a bug in IOS or a compatibility problem with the ip2ipgw and MTP on the same device, so they are working on that. IOS on ip2ip gw is 12.4.18 (cisco 2801) <- This is just for info if someone has seen something similar and solved it :) I recon Cisco will figure it out If someone has any info on any of the issues I gladly take some advice. Best regards Tor-Ivar Kristoffersen From pete at bytemark.co.uk Mon Sep 15 16:11:14 2008 From: pete at bytemark.co.uk (Peter Taphouse) Date: Mon, 15 Sep 2008 21:11:14 +0100 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <1221508568.7357.15.camel@localhost> References: <48B5602E.7010705@imperial.ac.uk> <079b01c90970$092d2330$f211a8c0@flamadam> <20080829072040.GD27310@lboro.ac.uk> <48BC0B53.4040000@imperial.ac.uk> <20080901154700.GB24224@lboro.ac.uk> <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> <20080902062732.GU233@greenie.muc.de> <48BD6380.6050309@gmail.com> <20080902171259.GB233@greenie.muc.de> <48BD78D4.6010405@gmail.com> <20080915145013.GA2245@greenie.muc.de> <1221508568.7357.15.camel@localhost> Message-ID: <48CEC162.5000105@bytemark.co.uk> Hello, > I'm curious, is bgp dampening on or off? Just to second (or third?) this bug. We've got four 7600s on SXH3 which are afflicted by this - they were upgraded from 2a on tac's advise (to avoid netflow bug related spontaneous reloads) - and we don't use dampening. It doesn't seem to matter if the prefixes that get withdrawn are i or ebgp, they get still "ghosted" to other ibgp peers. I don't have any evidence whether or not the prefixes get withdrawn to ebgp peers as we don't transit that many. I've got a case open with tac, but it's causing us enough grief that I'm moving back to SXF until things calm down. Would love the new netflow stuff in SXH if it gets stable enough... -- Peter Taphouse Bytemark Hosting http://www.bytemark-hosting.co.uk tel. +44 (0) 845 004 3 004 From cchurc05 at harris.com Mon Sep 15 17:50:28 2008 From: cchurc05 at harris.com (Church, Charles) Date: Mon, 15 Sep 2008 16:50:28 -0500 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <48CEC162.5000105@bytemark.co.uk> References: <48B5602E.7010705@imperial.ac.uk> <079b01c90970$092d2330$f211a8c0@flamadam> <20080829072040.GD27310@lboro.ac.uk><48BC0B53.4040000@imperial.ac.uk> <20080901154700.GB24224@lboro.ac.uk> <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> <20080902062732.GU233@greenie.muc.de><48BD6380.6050309@gmail.com> <20080902171259.GB233@greenie.muc.de><48BD78D4.6010405@gmail.com> <20080915145013.GA2245@greenie.muc.de><1221508568.7357.15.camel@localhost> <48CEC162.5000105@bytemark.co.uk> Message-ID: >From what I hear from our account people, SXF is considered a 'dead' train, and you should move to SXH or SXI. We've got a serious NAT bug in SXF14 that they're claiming won't be fixed in SXF. Sucks for our huge Sup2 base. Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Taphouse Sent: Monday, September 15, 2008 4:11 PM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] SXH3 ghost bugs - more details Hello, > I'm curious, is bgp dampening on or off? Just to second (or third?) this bug. We've got four 7600s on SXH3 which are afflicted by this - they were upgraded from 2a on tac's advise (to avoid netflow bug related spontaneous reloads) - and we don't use dampening. It doesn't seem to matter if the prefixes that get withdrawn are i or ebgp, they get still "ghosted" to other ibgp peers. I don't have any evidence whether or not the prefixes get withdrawn to ebgp peers as we don't transit that many. I've got a case open with tac, but it's causing us enough grief that I'm moving back to SXF until things calm down. Would love the new netflow stuff in SXH if it gets stable enough... -- Peter Taphouse Bytemark Hosting http://www.bytemark-hosting.co.uk tel. +44 (0) 845 004 3 004 _______________________________________________ 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 mksmith at adhost.com Mon Sep 15 17:52:35 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 15 Sep 2008 14:52:35 -0700 Subject: [c-nsp] [cisco-nsp] [OOT] Getting help to get the network acceptable In-Reply-To: <335055.82205.qm@web50308.mail.re2.yahoo.com> References: <335055.82205.qm@web50308.mail.re2.yahoo.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031604A641D0@ad-exh01.adhost.lan> > Hi, > My company recently bought 202[dot]90[dot]194[dot]0/23 IPs, and since we start > using this IPs, I can't access several site on the net. When check through > robtex.com, a company in India seem to still include these IPs into their RADB > database. I can't email them, browse their sites, maybe because of some > antispoof things. We asked our upstream to include this IPs to their radb > accounts, but it seem nothing changed, as we check to robtex.com, these IPs > still originated as AS9829 route-object. > I really appreciate if anyone in the list could help me getting these IPs to > be correctly accepted to browse the internet. > Best Regards, > Insan > Is this you? If so, I only see this entry and one for the 202.90.194.0/24 subnet in the RADB. How, exactly, did you "buy" these addresses? $ whois -h whois.apnic.net 202.90.194.0 % [whois.apnic.net node-2] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html inetnum: 202.90.194.0 - 202.90.195.255 netname: GREENLINKS-ID descr: PT. Bandung Sinergi Akses Teknologi descr: Graha Bumiputera, Suite 401-403 descr: Jalan Asia Afrika 141 - 149 descr: Bandung 40112, Indonesia country: ID admin-c: IW104-AP tech-c: IW104-AP remarks: Send Spam & Abuse report to: remarks: abuse at mygreenlinks.net mnt-by: MNT-APJII-ID mnt-routes: MAINT-ID-GREENLINKS status: ASSIGNED PORTABLE changed: hm-changed at apnic.net 20080716 source: APNIC person: Insan Praja Setya Wibawa nic-hdl: IW104-AP e-mail: insan at mygreenlinks.net address: Graha Bumiputera suite 401,203 4th Floor phone: +62-22-4242024 fax-no: +62-22-4242025 country: ID changed: adi at arsen.co.id 20080703 mnt-by: MAINT-NEW source: APNIC Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 474 bytes Desc: not available URL: From roddy.strachan at staff.netspace.net.au Mon Sep 15 18:10:29 2008 From: roddy.strachan at staff.netspace.net.au (Roddy Strachan) Date: Tue, 16 Sep 2008 08:10:29 +1000 Subject: [c-nsp] ASR Netflow Query In-Reply-To: <20080915142237.GB4112@rtp-cse-489.cisco.com> Message-ID: Rodney, Thanks for the reply. Yes I can see a corresponding match to the VAI for the user, that side of it is fine. Here is an output you requested : Router(ASR1004)#sh ip cache flow IP packet size distribution (1987515 total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .001 .132 .175 .047 .068 .028 .019 .007 .010 .003 .004 .002 .001 .001 .000 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .001 .001 .001 .058 .430 .000 .000 .000 .000 .000 .000 IP Flow Switching Cache, 0 bytes 44 active, 4052 inactive, 19326 added 61218 ager polls, 0 flow alloc failures Active flows timeout in 15 minutes Inactive flows timeout in 15 seconds IP Sub Flow Cache, 33992 bytes 0 active, 1024 inactive, 0 added, 0 added to flow 0 alloc failures, 0 force free 1 chunk, 0 chunks added last clearing of statistics 17:00:38 Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 318 0.0 43 91 0.2 5.7 30.8 TCP-WWW 259 0.0 2576 814 10.8 7.9 31.0 TCP-SMTP 8 0.0 7 142 0.0 2.5 31.2 TCP-X 130 0.0 14 40 0.0 0.0 31.0 TCP-BGP 6436 0.1 3 120 0.3 6.1 30.9 TCP-other 1501 0.0 28 127 0.6 6.7 30.8 UDP-DNS 170 0.0 57 68 0.1 7.4 31.1 UDP-NTP 1914 0.0 1 76 0.0 0.0 31.0 UDP-other 3723 0.0 35 75 2.1 126.5 27.1 ICMP 1242 0.0 18 110 0.3 1.8 30.9 IP-other 3635 0.0 296 580 17.5 538.0 15.6 Total: 19336 0.3 102 598 32.5 128.4 27.3 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 16 gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 49 gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 2225 gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 69 gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 745 The OSPF hellos are coming from other neighbours within that network. I mentioned in my original post that I wasn't seeing this from the 7301 platform, I did an IOS upgrade to 12.2(31)SB13 and I now see the same type of output on the 7301 platform. Ie : Router(7301)#sh ip cache flow IP packet size distribution (2135663 total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .143 .191 .039 .073 .032 .024 .009 .012 .007 .005 .003 .001 .002 .002 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .001 .001 .001 .049 .396 .000 .000 .000 .000 .000 .000 IP Flow Switching Cache, 4456704 bytes 31 active, 65505 inactive, 11924 added 4159489 ager polls, 0 flow alloc failures Active flows timeout in 15 minutes Inactive flows timeout in 15 seconds IP Sub Flow Cache, 270472 bytes 31 active, 16353 inactive, 11904 added, 11904 added to flow 0 alloc failures, 0 force free 1 chunk, 1 chunk added last clearing of statistics never Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 170 0.0 40 42 0.0 4.6 12.3 TCP-FTP 8 0.0 1 60 0.0 0.3 15.5 TCP-WWW 300 0.0 2434 817 9.4 9.1 9.2 TCP-SMTP 54 0.0 4 128 0.0 3.1 10.3 TCP-X 580 0.0 1 40 0.0 0.9 15.4 TCP-BGP 5077 0.0 1 52 0.0 2.0 15.4 TCP-other 705 0.0 106 387 0.9 19.6 12.1 UDP-DNS 46 0.0 13 71 0.0 5.7 15.5 UDP-NTP 1062 0.0 1 76 0.0 0.0 15.5 UDP-other 516 0.0 3 184 0.0 0.6 15.5 ICMP 599 0.0 2 132 0.0 0.9 15.5 IP-other 2776 0.0 469 575 16.8 824.2 3.5 Total: 11893 0.1 178 647 27.5 194.8 12.2 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Gi0/0.11 x.x.x.x Null 224.0.0.6 59 0000 0000 553 Gi0/0.11 x.x.x.x Null 224.0.0.5 59 0000 0000 27 Gi0/0.11 x.x.x.x Null 224.0.0.6 59 0000 0000 497 Gi0/0.11 x.x.x.x Null 224.0.0.5 59 0000 0000 29 On 16/09/08 12:22 AM, "Rodney Dunn" wrote: > Roddy, > > Do you see a corresponding match for the frame mapped to the VAI > for the user? > > Or are those OSPF hellos coming from OSPF neighbors directly > attached to the g0/1/0.1 subinterface? > > Can you provide the output with the column headers? > > > Rodney > > On Mon, Sep 15, 2008 at 02:46:14PM +1000, Roddy Strachan wrote: >> Hey all, >> >> Been playing around with an ASR1004 for terminating L2TP sessions. >> >> One thing I?ve noticed that shows up in a cache flow output is the following >> : >> >> gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 17 >> gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 17 >> gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 608 >> gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 17 >> gi0/1/0.1 x.x.x.x RP0_Punt 224.0.0.5 59 0000 0000 198 >> >> That in turn fills up our flow files on the collectors with data looking >> like this : >> >> 1221452253 x.x.x.x x.x.x.x 0 224.0.0.5 0 12740 2 0 0 0 >> 1221452255 x.x.x.x x.x.x.x 0 224.0.0.5 0 11648 2 0 0 0 >> 1221452259 x.x.x.x x.x.x.x 0 224.0.0.5 0 12740 2 0 0 0 >> 1221452260 x.x.x.x x.x.x.x 0 224.0.0.5 0 12740 2 0 0 0 >> >> >> I don?t see this type of behaviour on the 7200/7300 platform doing the same >> type of thing for L2TP sessions. >> >>> From what I understand its a multicast broadcast for OSPF (correct me if I?m >> wrong). >> >> Is there anyone to turn this off so it doesn?t show up in the ?sh ip cache >> flow? output ? Therefor not filling up out collector with unnecessary >> information >> >> Thanks >> >> >> >> 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/ > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ -- Regards, Roddy Strachan Sysadmin Team Leader Netspace Online Systems Ph : 03-9811-0016 Mob : 0416-116-291 Fax : 03-9811-0044 Email: roddy.strachan at staff.netspace.net.au From Michael.Balasko at cityofhenderson.com Mon Sep 15 18:36:02 2008 From: Michael.Balasko at cityofhenderson.com (Michael Balasko) Date: Mon, 15 Sep 2008 15:36:02 -0700 Subject: [c-nsp] OT - 802.3an - 10Gig over Cat 6a In-Reply-To: References: <20080915142237.GB4112@rtp-cse-489.cisco.com> Message-ID: <9AF22D15085E7D409ED5710CBC779E9307687DC0@COHNTCS09.ci.henderson.nv.us> We are starting to look at migration to 10gig and I was wondering if anyone knows of any networking gear that actually supports 10GBaseT. Intel has nic's available, I just wonder what you plug them into. The all knowing, all powerful google seems to be no help here. Thanks! Michael Balasko CCSP,MCSE,MCNE,SCP Network Specialist II City of Henderson From brad.henshaw at qcn.com.au Mon Sep 15 20:22:01 2008 From: brad.henshaw at qcn.com.au (Brad Henshaw) Date: Tue, 16 Sep 2008 10:22:01 +1000 Subject: [c-nsp] OT - Wireshark Export Message-ID: <8B25B862BC09784B9B74FB950D4F64D406C93C@qcnapp01.corp.qcn> Mike Louis wrote: > Does anyone know of a way to export the statistics in the SMB service > response time window from within wireshark? I haven't needed to do this but you might want to look at whether any of the stats tshark can generate are of any use to you. Manpage here: http://www.wireshark.org/docs/man-pages/tshark.html (check the -z option) Regards, Brad From sjhwilkes at gmail.com Mon Sep 15 20:26:52 2008 From: sjhwilkes at gmail.com (Simon Hamilton-Wilkes) Date: Mon, 15 Sep 2008 17:26:52 -0700 Subject: [c-nsp] OT - 802.3an - 10Gig over Cat 6a Message-ID: SMC Tigerswitch 10g is the only thing I can see out there, $23 K for 20 ports in 1U. Not much considering NICs seem pretty widely available. Simon From brad.henshaw at qcn.com.au Mon Sep 15 20:30:39 2008 From: brad.henshaw at qcn.com.au (Brad Henshaw) Date: Tue, 16 Sep 2008 10:30:39 +1000 Subject: [c-nsp] ME3750 Shaping Message-ID: <8B25B862BC09784B9B74FB950D4F64D406C93D@qcnapp01.corp.qcn> Eric Van Tol wrote: > The idea here is very simple - there are ports that receive > a data-only service and a ports that receive both data and voice. What do you /really/ need to achieve here? Priority for voice? Rate limitation of voice, data or both to a certain rate? Also how do you identify data vs. voice? VLAN? DSCP/CoS? Regards, Brad From jonvoip at gmail.com Mon Sep 15 20:34:47 2008 From: jonvoip at gmail.com (Jonathan Charles) Date: Mon, 15 Sep 2008 19:34:47 -0500 Subject: [c-nsp] ASA rule, SSH thru ASA 5505 v8.0.3 Message-ID: <5d093f9a0809151734k6adc69d0n613b8e9408a75d4@mail.gmail.com> I have an SSH server on the inside of a network, and the ASA is blocking SSH requests even tho I have an ACL permitting them and a static NAT to the SSH server. The ASA says it is blocked by the outside ACL even tho SSH (TCP 22) is specifically permitted... any ideas? Jonathan From ltd at cisco.com Mon Sep 15 23:03:01 2008 From: ltd at cisco.com (Lincoln Dale) Date: Tue, 16 Sep 2008 13:03:01 +1000 Subject: [c-nsp] OT - 802.3an - 10Gig over Cat 6a In-Reply-To: <9AF22D15085E7D409ED5710CBC779E9307687DC0@COHNTCS09.ci.henderson.nv.us> References: <20080915142237.GB4112@rtp-cse-489.cisco.com> <9AF22D15085E7D409ED5710CBC779E9307687DC0@COHNTCS09.ci.henderson.nv.us> Message-ID: <48CF21E5.1050407@cisco.com> hi Michael, Michael Balasko wrote: > We are starting to look at migration to 10gig and I was wondering if > anyone knows of any networking gear that actually supports 10GBaseT. > Intel has nic's available, I just wonder what you plug them into. The > all knowing, all powerful google seems to be no help here. > Cisco will have 10GBase-T switches available, however i strongly suggest you look into the various pros/cons of different transceiver options. 10GBase-T with its current power/heat (& latency) probably doesn't make sense from a 'green' perspective. if you're considering 10G to the host within a data center, suggest you talk to your Cisco account team & get an update on what options are available. cheers, lincoln. From waqqasahmed at gmail.com Mon Sep 15 23:09:36 2008 From: waqqasahmed at gmail.com (Syed Waqqas Ahmed) Date: Tue, 16 Sep 2008 09:09:36 +0600 Subject: [c-nsp] ME3750 Shaping In-Reply-To: <8B25B862BC09784B9B74FB950D4F64D406C93D@qcnapp01.corp.qcn> References: <8B25B862BC09784B9B74FB950D4F64D406C93D@qcnapp01.corp.qcn> Message-ID: <5893c85a0809152009x17276516o92fab12eccfaa9da@mail.gmail.com> just an example i found rate-limiting the traffic use policy map. policy-map BE-6mbps class RATELIMIT police cir 6144000 bc 128000 be 128000 conform-action set-dscp-transmit default exceed-action drop violate-action drop interface GigabitEthernet13/47 service-policy input BE-6mbps service-policy output BE-6mbps you can prioritize cetrian traffic using dscp bit value.. Regards Waqqas Ahmed. On Tue, Sep 16, 2008 at 6:30 AM, Brad Henshaw wrote: > Eric Van Tol wrote: > > > The idea here is very simple - there are ports that receive > > a data-only service and a ports that receive both data and voice. > > What do you /really/ need to achieve here? Priority for voice? Rate > limitation of voice, data or both to a certain rate? > > Also how do you identify data vs. voice? VLAN? DSCP/CoS? > > Regards, > Brad > _______________________________________________ > 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 waqqasahmed at gmail.com Mon Sep 15 23:19:58 2008 From: waqqasahmed at gmail.com (Syed Waqqas Ahmed) Date: Tue, 16 Sep 2008 09:19:58 +0600 Subject: [c-nsp] ME3750 Shaping In-Reply-To: <5893c85a0809152009x17276516o92fab12eccfaa9da@mail.gmail.com> References: <8B25B862BC09784B9B74FB950D4F64D406C93D@qcnapp01.corp.qcn> <5893c85a0809152009x17276516o92fab12eccfaa9da@mail.gmail.com> Message-ID: <5893c85a0809152019n6a39cda9t62132d7a0bee46a9@mail.gmail.com> just another example we are using on ME 3400 series switches. policy-map BE-test-in class rate-limit police cir 1024000 bc 16000 conform-action set-cos-transmit 0 exceed-action drop ! Regards, Waqqas Ahmed On Tue, Sep 16, 2008 at 9:09 AM, Syed Waqqas Ahmed wrote: > just an example i found rate-limiting the traffic use policy map. > > policy-map BE-6mbps > class RATELIMIT > police cir 6144000 bc 128000 be 128000 conform-action > set-dscp-transmit default exceed-action drop violate-action drop > > interface GigabitEthernet13/47 > service-policy input BE-6mbps > service-policy output BE-6mbps > > you can prioritize cetrian traffic using dscp bit value.. > > > Regards > > Waqqas Ahmed. > On Tue, Sep 16, 2008 at 6:30 AM, Brad Henshaw wrote: > >> Eric Van Tol wrote: >> >> > The idea here is very simple - there are ports that receive >> > a data-only service and a ports that receive both data and voice. >> >> What do you /really/ need to achieve here? Priority for voice? Rate >> limitation of voice, data or both to a certain rate? >> >> Also how do you identify data vs. voice? VLAN? DSCP/CoS? >> >> Regards, >> Brad >> _______________________________________________ >> 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 Mon Sep 15 23:51:18 2008 From: brad.henshaw at qcn.com.au (Brad Henshaw) Date: Tue, 16 Sep 2008 13:51:18 +1000 Subject: [c-nsp] OT - 802.3an - 10Gig over Cat 6a Message-ID: <8B25B862BC09784B9B74FB950D4F64D406C949@qcnapp01.corp.qcn> Simon Hamilton-Wilkes wrote: > SMC Tigerswitch 10g is the only thing I can see out there, $23 K for 20 ports in 1U. Extreme also have the X650. Not sure about availability. Regards, Brad From gert at greenie.muc.de Tue Sep 16 00:08:58 2008 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 16 Sep 2008 06:08:58 +0200 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <48CEC162.5000105@bytemark.co.uk> References: <48BC0B53.4040000@imperial.ac.uk> <20080901154700.GB24224@lboro.ac.uk> <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> <20080902062732.GU233@greenie.muc.de> <48BD6380.6050309@gmail.com> <20080902171259.GB233@greenie.muc.de> <48BD78D4.6010405@gmail.com> <20080915145013.GA2245@greenie.muc.de> <1221508568.7357.15.camel@localhost> <48CEC162.5000105@bytemark.co.uk> Message-ID: <20080916040858.GA17256@greenie.muc.de> Hi, On Mon, Sep 15, 2008 at 09:11:14PM +0100, Peter Taphouse wrote: > Just to second (or third?) this bug. We've got four 7600s on SXH3 which > are afflicted by this - they were upgraded from 2a on tac's advise (to > avoid netflow bug related spontaneous reloads) - and we don't use > dampening. It doesn't seem to matter if the prefixes that get withdrawn > are i or ebgp, they get still "ghosted" to other ibgp peers. For iBGP->iBGP ghosts, our current setup is not suitable (read: no route-reflector setup, so iBGP->iBGP announcements would not take place), thus I have no evidence on whether this would also trigger the bug for us. But I think it's quite likely indeed, given that this seems to happen on sending *out* the withdraw... > I've got a case open with tac, Would you mind sharing the case number with me? I could forward this to our TAC engineer so they know "this is not just us". Do you have a bug ID? > but it's causing us enough grief that I'm moving back to SXF until > things calm down. *grumble* - I would love to do that, given that we're quite happy with SXF since about two years now. But we were unlucky/stupid enough to get Sup720-10Gs for these new boxes, and they only run SHX... > Would love the new netflow stuff in SXH if it gets stable enough... We're quite happy with the SHX3 netflow. No crashes (yet, knock wood) and the load on everything is indeed much lower. There are some other funnies in SXH3, but these are just annoyances and not service impacting (we're not using scp). gert -- Gert Doering Mobile communications ... right now writing from * Munich Airport * From gert at greenie.muc.de Mon Sep 15 23:50:14 2008 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 16 Sep 2008 05:50:14 +0200 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <1221508568.7357.15.camel@localhost> References: <20080829072040.GD27310@lboro.ac.uk> <48BC0B53.4040000@imperial.ac.uk> <20080901154700.GB24224@lboro.ac.uk> <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> <20080902062732.GU233@greenie.muc.de> <48BD6380.6050309@gmail.com> <20080902171259.GB233@greenie.muc.de> <48BD78D4.6010405@gmail.com> <20080915145013.GA2245@greenie.muc.de> <1221508568.7357.15.camel@localhost> Message-ID: <20080916035014.GA17120@greenie.muc.de> Hi, On Mon, Sep 15, 2008 at 12:56:08PM -0700, Christopher McCrory wrote: > I'm curious, is bgp dampening on or off? BGP dampening is off. gert -- Gert Doering Mobile communications ... right now writing from * Munich Airport * From jonvoip at gmail.com Tue Sep 16 00:59:30 2008 From: jonvoip at gmail.com (Jonathan Charles) Date: Mon, 15 Sep 2008 23:59:30 -0500 Subject: [c-nsp] ASA rule, SSH thru ASA 5505 v8.0.3 In-Reply-To: References: <5d093f9a0809151734k6adc69d0n613b8e9408a75d4@mail.gmail.com> Message-ID: <5d093f9a0809152159k2ef77f07wdf66de527aaee936@mail.gmail.com> Turned out it was an ACL on the SSH Server that was blocking me... wow, that was silly. Curious tho... if I enable proxy arp I break the connection to their AS400 server, if I disable it, I kill the VPN... Jonathan On Mon, Sep 15, 2008 at 10:58 PM, D W wrote: > I haven't encountered an issue in the past doing this. Can you send out > configs? Your ACL is set to allow ssh traffic to the pre-NAT (outside) IP > address, correct? > > > > Date: Mon, 15 Sep 2008 19:34:47 -0500 > > From: jonvoip at gmail.com > > To: cisco-nsp at puck.nether.net > > Subject: [c-nsp] ASA rule, SSH thru ASA 5505 v8.0.3 > > > > > I have an SSH server on the inside of a network, and the ASA is blocking > SSH > > requests even tho I have an ACL permitting them and a static NAT to the > SSH > > server. > > > > The ASA says it is blocked by the outside ACL even tho SSH (TCP 22) is > > specifically permitted... any ideas? > > > > > > > > Jonathan > > _______________________________________________ > > 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/ > > ------------------------------ > See how Windows connects the people, information, and fun that are part of > your life. See Now > From oliver.gorwits at oucs.ox.ac.uk Tue Sep 16 01:08:00 2008 From: oliver.gorwits at oucs.ox.ac.uk (Oliver Gorwits) Date: Tue, 16 Sep 2008 06:08:00 +0100 Subject: [c-nsp] Cisco Unified Communications Manager v6.1 - Set-up In-Reply-To: <441C449160381D49A93241C6EE5B80160BC7E78FA0@ltexchange.lufttransport.no> References: <441C449160381D49A93241C6EE5B80160BC7E78FA0@ltexchange.lufttransport.no> Message-ID: <48CF3F30.5010007@oucs.ox.ac.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tor-Ivar Kristoffersen wrote: > I was just wondering if anyone have got a cookbook sort of > document for Call Manager v6.1. There's a sister mail list to this one, on the same server, for Cisco VoIP, where you might get a better response: http://puck.nether.net/mailman/listinfo/cisco-voip HTH, regards, oliver. - -- Oliver Gorwits, Network and Telecommunications Group, Oxford University Computing Services -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIzz8w2NPq7pwWBt4RAo9yAKCFlVFKKUDWhd3QhOkWi5eiaXJqHgCgleRs KPHBwVF6WN9gd9qStm3HKVg= =EMdf -----END PGP SIGNATURE----- From lists at hojmark.org Tue Sep 16 01:10:53 2008 From: lists at hojmark.org (Asbjorn Hojmark - Lists) Date: Tue, 16 Sep 2008 07:10:53 +0200 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <20080915065026.GA18822@mx.ytti.net> References: <20080907075706.GA7640@mx.ytti.net> <20080915065026.GA18822@mx.ytti.net> Message-ID: <8F0E0A9232AB433DBB064C1E0A0B8075@hojmark.net> > QinQ would definitely be show stopper for me too. Are you > sure it's not there? At least it can be configured, but > couldn't find anyone with ASR1k who could test it on this > short notice. I got it directly from the BU that it wouldn't be supported until RLS2, and a customer configured it just to find it Almost Worked(TM) (there were issues with DHCP relay). However, I had a meeting with the (a?) PM yesterday, and he assured me it is in RLS1. The other thing is probably a bug then. -A From brad.henshaw at qcn.com.au Tue Sep 16 01:39:13 2008 From: brad.henshaw at qcn.com.au (Brad Henshaw) Date: Tue, 16 Sep 2008 15:39:13 +1000 Subject: [c-nsp] ME3750 Shaping Message-ID: <8B25B862BC09784B9B74FB950D4F64D406C94F@qcnapp01.corp.qcn> Syed Waqqas Ahmed wrote: > service-policy output BE-6mbps The ME3750 doesn't support egress policy maps on standard ports. Regards, Brad From jonvoip at gmail.com Tue Sep 16 02:16:54 2008 From: jonvoip at gmail.com (Jonathan Charles) Date: Tue, 16 Sep 2008 01:16:54 -0500 Subject: [c-nsp] Proxy ARP and the ASA 5505 Message-ID: <5d093f9a0809152316j2f71c60ds4b1b67cc8742ea6@mail.gmail.com> Got an ASA 5505... if I enable proxy arp, users lose connections to their AS400... If I disable it, my VPN clients can't connect anywhere... Any idea why, and how to fix? Jonathan From mtinka at globaltransit.net Tue Sep 16 02:33:35 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 16 Sep 2008 14:33:35 +0800 Subject: [c-nsp] IS-IS for IPv6: Passive Loopback Interface Address Not Propagated Message-ID: <200809161433.40044.mtinka@globaltransit.net> Hi all. Has anyone experienced failure of the v6 address on a (dual-stacked) Loopback interface from being propagated into IS-IS? We're seeing this on 12.2(33)SRC1 deployed on NPE-G2's, NPE-G1's and 7201's. IS-IS is running in multi-topology mode, v6 infrastructure addresses are propagated fine, it's just that v6 addresses on the Loopback interface won't be. Our pseudonodes (DIS's) are running on SUP720-3BXL's with 12.2(33)SXH3. These are able to propagate their v6 Loopback interface addresses to the network, including to the 7200's. v4 is unaffected. We have a case open with TAC, but it's been a while since they gave us any feedback. All help appreciated. 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 saku+cisco-nsp at ytti.fi Tue Sep 16 03:06:46 2008 From: saku+cisco-nsp at ytti.fi (Saku Ytti) Date: Tue, 16 Sep 2008 10:06:46 +0300 Subject: [c-nsp] c7604 "starter kit" In-Reply-To: <8F0E0A9232AB433DBB064C1E0A0B8075@hojmark.net> References: <20080915065026.GA18822@mx.ytti.net> <8F0E0A9232AB433DBB064C1E0A0B8075@hojmark.net> Message-ID: <20080916070646.GA10501@mx.ytti.net> On (2008-09-16 07:10 +0200), Asbjorn Hojmark - Lists wrote: > However, I had a meeting with the (a?) PM yesterday, and he > assured me it is in RLS1. The other thing is probably a bug > then. Ok so far we've listed EoMPLS and VPLS as definitely missing software features, I still wonder what the 'OP' (Frank Bulk) ment by 'minimum software features', perhaps something else that I'm not seeing. -- ++ytti From twelcome at mobileemail.vodafonesa.co.za Tue Sep 16 03:39:17 2008 From: twelcome at mobileemail.vodafonesa.co.za (twelcome at mobileemail.vodafonesa.co.za) Date: Tue, 16 Sep 2008 07:39:17 +0000 Subject: [c-nsp] Data destinations for cisco sce 2000 devices Message-ID: <1551321422-1221550760-cardhu_decombobulator_blackberry.rim.net-1738507736-@bxe056.bisx.produk.on.blackberry> Hi All We currently use a cisco sce2000 appliance to provision international bandwidth to our customers and to export traffic flows (in the form of RDR packets) to a single flow collection server ("data destination"), which stores the flows in a sql database. Recently we've needed to add some redundancy and failover to this data collection and it turns out (as stated in the sce documentation) that the sce will support multiple destinations for rdr packets and that it will use those destinations in 3 modes: 1. Redundant data collection servers with failover to the next destination if one is unreachable. 2. Multicast to several destinations 3. Round robin to several destinations My question is this: Does anyone know if this actually works in practice as a mechansism for making the data collection database redundant? I.e despite what the sce documentation states, is there any reason why the sce using Redundant data collectors with failover would not be a viable way of adding redundancy to the data collection database? Thanks in advance! Traiano Sent via my BlackBerry from Vodacom - let your email find you! From vikassharmas at gmail.com Tue Sep 16 04:39:32 2008 From: vikassharmas at gmail.com (Vikas Sharma) Date: Tue, 16 Sep 2008 14:09:32 +0530 Subject: [c-nsp] logging server in MPLS VRF Message-ID: Hi, I am curious to know whether we should put snmp logging servers part of MPLS vpn (as this has to reveive logs from all servers across the network) or it should be the part of global routing table. If we can do ti with mpls vpn, is there any benefit? Regards, Vikas Sharma From andy at bourges.de Tue Sep 16 03:56:29 2008 From: andy at bourges.de (Andreas Bourges) Date: Tue, 16 Sep 2008 09:56:29 +0200 Subject: [c-nsp] Data destinations for cisco sce 2000 devices In-Reply-To: <1551321422-1221550760-cardhu_decombobulator_blackberry.rim.net-1738507736-@bxe056.bisx.produk.on.blackberry> References: <1551321422-1221550760-cardhu_decombobulator_blackberry.rim.net-1738507736-@bxe056.bisx.produk.on.blackberry> Message-ID: <200809160956.30588.andy@bourges.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Traiano, On Tuesday 16 September 2008, twelcome at mobileemail.vodafonesa.co.za wrote: > 1. Redundant data collection servers with failover to the next destination > if one is unreachable. 2. Multicast to several destinations > 3. Round robin to several destinations > > My question is this: Does anyone know if this actually works in practice as > a mechansism for making the data collection database redundant? I.e despite > what the sce documentation states, is there any reason why the sce using > Redundant data collectors with failover would not be a viable way of adding > redundancy to the data collection database? I'm not sure if I understand you correctly, but as far as I know is the redundant collection server only used if the primary fails. If you want real redundancy you should configure the "multicast" option, which means that every collector receives the same data and in case one fails, you still got another one having full data. Regards, Andreas - -- BOFH excuse #278: The Dilithium Crystals need to be rotated. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjPZq4ACgkQRrny/uOBVy7X3ACeOVKu8NYu0dCvUJPZ4+l5AakM lg4AnAjq+bnPdLihvZejgUTuVp4peHLf =lte2 -----END PGP SIGNATURE----- From famz at hotmail.com Tue Sep 16 05:52:19 2008 From: famz at hotmail.com (Faisal Muzammil) Date: Tue, 16 Sep 2008 14:52:19 +0500 Subject: [c-nsp] cisco 7507 vs ssg 550 Message-ID: Hi, We have a cisco 7507 router for our wan and are thinking of replacing it with juniper ssg 550. Currently we have 1 GEIP interface on the lan side of 7507 and 1 POS(STM/OC3) interface on the wan side. We have a few IP IP tunnels established and are running BGP over the wan and OSPF on the lan side. We also have the need of using PBRs. The main reason behind this change is that we are going to outgrow our STM capacity and need to upgrade to higher bandwidth on the wan side. hence similarly we will need to have a better option on the lan side instead of GEIP due to the limitation of 200mbps aggregate throughput on it. Thanks in advance for your suggestions regards Famz _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx From sfischer1967 at gmail.com Tue Sep 16 06:28:54 2008 From: sfischer1967 at gmail.com (Steve Fischer) Date: Tue, 16 Sep 2008 06:28:54 -0400 Subject: [c-nsp] Cisco NAC Message-ID: <008701c917e7$05437140$0fca53c0$@com> Does anyone here use the Cisco NAC product? Is there a mailing list of which anyone knows specifically for Cisco NAC? User's group? Online community? Any assistance in directing me toward any of these resources would be genuinely appreciated. From p.mayers at imperial.ac.uk Tue Sep 16 06:56:43 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Tue, 16 Sep 2008 11:56:43 +0100 Subject: [c-nsp] 6500 acl log & cpu hit Message-ID: <48CF90EB.3010107@imperial.ac.uk> All, We've recently disabled OAL because we had to enable VACL capture. Without OAL, can I ensure a stray "log" ACL statement won't kill the box? Can I use one of the MLS rate limiters to throttle it? The obvious ones seem to be: ACL VACL LOG - set to "on, 2000pps" ICMP UNREAC. ACL-DROP - set to "on, 0pps" as OAL wanted this Or does ACL "log" traffic hit the CoPP limiters? From eric at atlantech.net Tue Sep 16 07:14:12 2008 From: eric at atlantech.net (Eric Van Tol) Date: Tue, 16 Sep 2008 07:14:12 -0400 Subject: [c-nsp] ME3750 Shaping In-Reply-To: <8B25B862BC09784B9B74FB950D4F64D406C93D@qcnapp01.corp.qcn> References: <8B25B862BC09784B9B74FB950D4F64D406C93D@qcnapp01.corp.qcn> Message-ID: <2C05E949E19A9146AF7BDF9D44085B86350AECC4A9@exchange.aoihq.local> > -----Original Message----- > From: Brad Henshaw [mailto:brad.henshaw at qcn.com.au] > Sent: Monday, September 15, 2008 8:31 PM > To: Eric Van Tol; Arie Vayner (avayner); cisco-nsp at puck.nether.net > Subject: RE: [c-nsp] ME3750 Shaping > > Eric Van Tol wrote: > > > The idea here is very simple - there are ports that receive > > a data-only service and a ports that receive both data and voice. > > What do you /really/ need to achieve here? Priority for voice? Rate > limitation of voice, data or both to a certain rate? > > Also how do you identify data vs. voice? VLAN? DSCP/CoS? > > Regards, > Brad I've explained the situation to both Arie and my local SE. It looks like the 3750 is simply not able to provide what we need it to do today. To answer your question, though, I need the switch to perform bi-directional bandwidth limiting on data-only ports at speeds of 5M, 10M, 25M, 50M, and 75M. This can easily be accomplished with a policing configuration and using the 'srr-queue' interface option on egress. No problems there. The problem comes when I need to add voice to a port - one VLAN is for data and one VLAN is for voice (802.1q trunk). I can easily perform ingress policing at any rate I need for the data VLAN. However, I am unable to provide any bandwidth shaping on egress at speeds higher than 50Mb/s due to the limitations of the 'srr-queue bandwidth shaping' interface option, which was my original question. You get the option to specify a weight from 0 through 65535, which correlates to a percentage of the bandwidth. A weight of 20 will limit the queue to 5Mb/s. A weight of 50 will limit the queue to 2Mb/s. A weight of 2 will limit the queue to 50Mb/s. I have nowhere to go from '2'. I understand that I can accomplish what I need by policing upon ingress from one of the uplink GE ports. That's not what I would call an easy and scalable solution, though. Thanks to everyone for all the suggestions, though. Onward I must go to test more equipment. -evt From techconfig at yahoo.com Tue Sep 16 07:12:55 2008 From: techconfig at yahoo.com (Mark Tech) Date: Tue, 16 Sep 2008 04:12:55 -0700 (PDT) Subject: [c-nsp] Cisco 12406 Etherchannel Message-ID: <47151.61434.qm@web44815.mail.sp1.yahoo.com> Hi I am trying to configure Ethernchannel/link bundling on a 12406. The port channel seems to be accepted, however when I try and add a channel-group to my GE interfaces, it says its not supported? I am using SPA-10X1GE-V2 line cards with c12kprp-p-mz.120-32.SY6.bin IOS interface Port-channel1 ?ip address?x.x.x.x 255.255.255.252 ?no ip directed-broadcast ?channel-group minimum active 1 ?no channel-group bandwidth control-propagation router(config-if)#channel-group 1 Error: not supported on GigabitEthernet0/0/0. Is there a way to bundle more that 1GE port on a 12406? Regards ?Mark From loui at renater.fr Tue Sep 16 08:36:00 2008 From: loui at renater.fr (Frederic LOUI) Date: Tue, 16 Sep 2008 14:36:00 +0200 Subject: [c-nsp] IS-IS for IPv6: Passive Loopback Interface Address Not Propagated In-Reply-To: <200809161433.40044.mtinka@globaltransit.net> References: <200809161433.40044.mtinka@globaltransit.net> Message-ID: <48CFA830.8070708@renater.fr> Mark Tinka a ?crit : > Hi all. > > Has anyone experienced failure of the v6 address on a > (dual-stacked) Loopback interface from being propagated > into IS-IS? We have the same setup and no particular issue with that. > > We're seeing this on 12.2(33)SRC1 deployed on NPE-G2's, > NPE-G1's and 7201's. > My version is : IOS 124-11.T2 > IS-IS is running in multi-topology mode, v6 infrastructure > addresses are propagated fine, it's just that v6 addresses > on the Loopback interface won't be. > Did you try ISIS debug command in order to see what's happening ? When you inject your loopback ? > Our pseudonodes (DIS's) are running on SUP720-3BXL's with > 12.2(33)SXH3. These are able to propagate their v6 Loopback > interface addresses to the network, including to the > 7200's. > > v4 is unaffected. > > We have a case open with TAC, but it's been a while since > they gave us any feedback. > > All help appreciated. I record that there was some issues related to ISIS in multi-topology environment. "metric style wide" command was needed and also the interface command "ipv6 enable" is sometimes mandatory. (depending on the IOS vesion) Please fin herewith this mail a snipset of config related to ISIS for IPv6: ! interface Loopback0 ip address 192.168.1.2 255.255.255.255 ipv6 address 2001:DB8:2200:11::1/128 ipv6 enable ! interface Loopback1 ip address 192.168.2.2 255.255.255.255 ipv6 address 2001:DB8:2200:11::2/128 ipv6 enable ! interface Loopback2 ip address 192.168.3.2 255.255.255.255 ipv6 address 2001:DB8:2200:11::3/128 ipv6 enable ! ! router isis net 49.0001.2222.2222.2222.00 metric-style wide fast-flood 15 max-lsp-lifetime 65535 spf-interval 1 1 10 prc-interval 1 1 10 lsp-gen-interval 5 1 50 no hello padding log-adjacency-changes passive-interface Loopback0 passive-interface Loopback1 passive-interface Loopback2 bfd all-interfaces ! address-family ipv6 multi-topology exit-address-family ! GSR-2#sh ipv6 protocols IPv6 Routing Protocol is "connected" IPv6 Routing Protocol is "static" IPv6 Routing Protocol is "isis" Interfaces: FastEthernet1/0 FastEthernet2/0 Loopback0 (Passive) Loopback1 (Passive) Loopback2 (Passive) Redistribution: None IPv6 Routing Protocol is "bgp 65200" Route Reflector for address family IPv6 Unicast, 2 clients IGP synchronization is disabled Redistribution: None Neighbor(s): Address FiltIn FiltOut Weight RoutemapIn RoutemapOut 2001:DB8:2100:11::2 2001:DB8:2300:11::2 IPv6 Routing Protocol is "bgp multicast" Route Reflector for address family IPv6 Unicast, 2 clients IGP synchronization is disabled Redistribution: None Neighbor(s): Address FiltIn FiltOut Weight RoutemapIn RoutemapOut 2001:DB8:2100:11::2 2001:DB8:2300:11::2 Just my 2 cents, Hope this helps (Sorry if not), but I'm curious about the answer... At the sounds like it is a issue with the IOS version. (Any possibility to try an other one ?) Bgrds/Fred -- Frederic LOUI / GIP RENATER Service de Suivi Operationnel / Metrologie & QoS Network Operations Service / Metrology & QoS Tel: +33 1 53 94 20 82 / Fax: +33 1 53 94 20 31 frederic.loui at renater.fr http://www.renater.fr From luan at netcraftsmen.net Tue Sep 16 09:01:43 2008 From: luan at netcraftsmen.net (Luan Nguyen) Date: Tue, 16 Sep 2008 09:01:43 -0400 Subject: [c-nsp] Cisco NAC In-Reply-To: <008701c917e7$05437140$0fca53c0$@com> References: <008701c917e7$05437140$0fca53c0$@com> Message-ID: <012001c917fc$5e383870$1aa8a950$@net> First try Cisco: http://www.cisco.com/en/US/products/ps6128/tsd_products_support_series_home. html http://cisconac.blogspot.com/ One of my coworker's blog - he's excellent with NAC deployment. http://cnc-networksecurity.blogspot.com/ Mailing list: http://listserv.muohio.edu/scripts/wa.exe?A0=cleanaccess -Luan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Steve Fischer Sent: Tuesday, September 16, 2008 6:29 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Cisco NAC Does anyone here use the Cisco NAC product? Is there a mailing list of which anyone knows specifically for Cisco NAC? User's group? Online community? Any assistance in directing me toward any of these resources would be genuinely appreciated. _______________________________________________ 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 tstevens at cisco.com Tue Sep 16 09:10:16 2008 From: tstevens at cisco.com (Tim Stevenson) Date: Tue, 16 Sep 2008 06:10:16 -0700 Subject: [c-nsp] 6500 acl log & cpu hit In-Reply-To: <48CF90EB.3010107@imperial.ac.uk> References: <48CF90EB.3010107@imperial.ac.uk> Message-ID: You should use ACL BRIDGED IN/OUT to control that rate: mls rate unicast acl input|output Tim At 03:56 AM 9/16/2008, Phil Mayers observed: >All, > >We've recently disabled OAL because we had to enable VACL capture. > >Without OAL, can I ensure a stray "log" ACL statement won't kill the >box? Can I use one of the MLS rate limiters to throttle it? > >The obvious ones seem to be: > >ACL VACL LOG - set to "on, 2000pps" > >ICMP UNREAC. ACL-DROP - set to "on, 0pps" as OAL wanted this > >Or does ACL "log" traffic hit the CoPP limiters? >_______________________________________________ >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 Stevenson, tstevens at cisco.com Routing & Switching CCIE #5561 Technical Marketing Engineer, Data Center BU Cisco Systems, http://www.cisco.com IP Phone: 408-526-6759 ******************************************************** The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. From blahu77 at gmail.com Tue Sep 16 09:22:44 2008 From: blahu77 at gmail.com (=?ISO-8859-2?Q?Mateusz_B=B3aszczyk?=) Date: Tue, 16 Sep 2008 14:22:44 +0100 Subject: [c-nsp] NPE G1, CEF and ACLs and high CPU In-Reply-To: <383357750809081414t77efb2v7a0acb130a671e46@mail.gmail.com> References: <383357750809041000uad21b4ag386233e3b2ea4fde@mail.gmail.com> <200809041546.23959.kratzers@pa.net> <20080905120724.GI15736@rtp-cse-489.cisco.com> <20080905184202.GD20054@rtp-cse-489.cisco.com> <383357750809060359w5b204530qe491c7adf048a8cf@mail.gmail.com> <20080908135935.GS19347@rtp-cse-489.cisco.com> <383357750809081315p58423820vef081acdbe858b21@mail.gmail.com> <20080908205046.GK29172@elvis.mu.org> <383357750809081414t77efb2v7a0acb130a671e46@mail.gmail.com> Message-ID: <383357750809160622v4808549chb381cf5dd6e6f081@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 List, > I will work on it and report the results accordingly. > As promised - here comes the report.... 1) I have reworked the ACL to introduce the "shortcuts" like "permit tcp any any established" and permiting all traffic to customer pools upfront. It looks like the majority of traffic is now permited and about 8% of is matched for the last "permit ip any any" (vs 77%) with previous ACL. 2) Also I noticed that I haven't got "no ip unreachables" on the port so I have enabled that. Since then the "RP PAS Features" punts stopped increasing.... 3) Finally - the CPU load - there is no significant drop of CPU load (no immediate effect). I will monitor the CPU for longer periods to see if there is at least any trend (up, down, no change). (box is pushing 480Mbps/90kps of input traffic #sh ver | in IOS|processo Cisco IOS Software, 7301 Software (C7301-K91P-M), Version 12.2(28)SB6, RELEASE SOFTWARE (fc1) Cisco 7301 (NPE) processor (revision D) with 983040K/65536K bytes of memory.) Seems I need a HW upgrade anyway. Also I will try to upgrade to 12.4.20T but not now. Best Regards, - -- - -mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIz7MjIvBv0k5esR4RAkUoAKCVREfOGZZ/tQhLm3jM264kpReHPwCeJLrm 8Le8SjzUB3xNIQnufd7Ycaw= =c2Ct -----END PGP SIGNATURE----- From mliotta at r337.com Tue Sep 16 10:26:09 2008 From: mliotta at r337.com (Matt Liotta) Date: Tue, 16 Sep 2008 10:26:09 -0400 Subject: [c-nsp] 3750ME-7609 ES interface problem Message-ID: I currently have a 3750ME connected via one of its ES interfaces to a 6509 on one of the OSM (GE-WAN) interfaces and things work fine. However, when I try to connect the other ES port on the same 3750ME to a 7609 GigE interface the port won't come up. What is strange is that the 3750ME shows the port as up/up, but the 7609 shows it as down/ down. Interestingly, if I shut the 7609 port the 3750's port then goes down as well. What am I missing? -Matt From leonardo.souza at nec.com.br Tue Sep 16 10:49:54 2008 From: leonardo.souza at nec.com.br (Leonardo Gama Souza) Date: Tue, 16 Sep 2008 11:49:54 -0300 Subject: [c-nsp] RES: Cisco 12406 Etherchannel References: <47151.61434.qm@web44815.mail.sp1.yahoo.com> Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E4C@spsrvmail03.nec.br> There are some restrictions... Take a look: http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/lnkbndl.html Cheers. ________________________________ De: cisco-nsp-bounces at puck.nether.net em nome de Mark Tech Enviada: ter 16/9/2008 08:12 Para: cisco-nsp at puck.nether.net Assunto: [c-nsp] Cisco 12406 Etherchannel Hi I am trying to configure Ethernchannel/link bundling on a 12406. The port channel seems to be accepted, however when I try and add a channel-group to my GE interfaces, it says its not supported? I am using SPA-10X1GE-V2 line cards with c12kprp-p-mz.120-32.SY6.bin IOS interface Port-channel1 ip address x.x.x.x 255.255.255.252 no ip directed-broadcast channel-group minimum active 1 no channel-group bandwidth control-propagation router(config-if)#channel-group 1 Error: not supported on GigabitEthernet0/0/0. Is there a way to bundle more that 1GE port on a 12406? Regards Mark _______________________________________________ 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 pete at bytemark.co.uk Tue Sep 16 10:24:03 2008 From: pete at bytemark.co.uk (Peter Taphouse) Date: Tue, 16 Sep 2008 15:24:03 +0100 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <20080916040858.GA17256@greenie.muc.de> References: <48BC0B53.4040000@imperial.ac.uk> <20080901154700.GB24224@lboro.ac.uk> <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> <20080902062732.GU233@greenie.muc.de> <48BD6380.6050309@gmail.com> <20080902171259.GB233@greenie.muc.de> <48BD78D4.6010405@gmail.com> <20080915145013.GA2245@greenie.muc.de> <1221508568.7357.15.camel@localhost> <48CEC162.5000105@bytemark.co.uk> <20080916040858.GA17256@greenie.muc.de> Message-ID: <48CFC183.4060401@bytemark.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Would you mind sharing the case number with me? I could forward this to > our TAC engineer so they know "this is not just us". > > Do you have a bug ID? I've got no bug ID, but it's on case SR 609537689. SXH3 introduced another new bgp bug too - the output of show ip bgp neigh xx.xxx.xx.xx advertised-routes produced badly wrong output. For example it showed us announcing zero prefixes to one of our transit providers, even though their looking glass showed them receiving them just fine :-/ That's why I opened the case originally, the ghosting bug I noticed afterwards and then I quickly moved to SXF since it was causing too much grief. >> but it's causing us enough grief that I'm moving back to SXF until >> things calm down. > > *grumble* - I would love to do that, given that we're quite happy with > SXF since about two years now. But we were unlucky/stupid enough to > get Sup720-10Gs for these new boxes, and they only run SHX... Just to make you feel better, the 7604 I reloaded yesterday with SXF15 just spontaneously reloaded... - -- Peter Taphouse Bytemark Hosting http://www.bytemark.co.uk/ tel. +44 (0) 845 004 3 004 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIz8GDIAZ7OKeBB58RAi3zAKCaUsJbYjy6yRwx4796Yv9ko+hXTQCePYEB UaQrHjlsOaFCeXKrjz7yTag= =WgJ0 -----END PGP SIGNATURE----- From techconfig at yahoo.com Tue Sep 16 11:57:38 2008 From: techconfig at yahoo.com (Mark Tech) Date: Tue, 16 Sep 2008 08:57:38 -0700 (PDT) Subject: [c-nsp] RES: Cisco 12406 Etherchannel Message-ID: <255784.49437.qm@web44808.mail.sp1.yahoo.com> Hi, thanks for that. Just had a look at my inventory sh inventory NAME: "slot 0", DESCR: "ISE 10G Modular Services Card v2" PID: 12000-SIP-601???? , VID: V04, SN: SAD12340460 Looks like I have an ISE card installed. If I look at the restrictions for the ISE, seems like only the following cards are supported: IP Service Engine (ISE): ?4-port Gigabit Ethernet ISE line card ?4-port OC-3c/STM-1c POS/SDH ISE line card ?8-port OC-3c/STM-1c POS/SDH ISE line card ?16-port OC-3c/STM-1c POS/SDH ISE line card ?4-port OC-12c/STM-4c POS/SDH ISE line card ?1-port OC-48c/STM-16c POS/SDH ISE line card However it then goes to mention that the following cards support it. Engine 5 SPA Interface Processors (SIPs): ?10G Engine 5 SPA Interface Processor (12000-SIP-600) ?2.5G multiservice engine SPA Interface Processor (12000-SIP-401) ?5G multiservice engine SPA Interface Processor (12000-SIP-501) ?10G multiservice engine SPA Interface Processor (12000-SIP-601) The GE cards are installed in a 12000-SIP-601, or is that I don't have an'Engine 5' within the 601installed? Regards Mark ----- Original Message ---- From: Leonardo Gama Souza To: Mark Tech Cc: cisco-nsp at puck.nether.net Sent: Tuesday, September 16, 2008 3:49:54 PM Subject: RES: [c-nsp] Cisco 12406 Etherchannel There are some restrictions... Take a look: http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/lnkbndl.html ? Cheers. ________________________________ De: cisco-nsp-bounces at puck.nether.net em nome de Mark Tech Enviada: ter 16/9/2008 08:12 Para: cisco-nsp at puck.nether.net Assunto: [c-nsp] Cisco 12406 Etherchannel Hi I am trying to configure Ethernchannel/link bundling on a 12406. The port channel seems to be accepted, however when I try and add a channel-group to my GE interfaces, it says its not supported? I am using SPA-10X1GE-V2 line cards with c12kprp-p-mz.120-32.SY6.bin IOS interface Port-channel1 ?ip address?x.x.x.x 255.255.255.252 ?no ip directed-broadcast ?channel-group minimum active 1 ?no channel-group bandwidth control-propagation router(config-if)#channel-group 1 Error: not supported on GigabitEthernet0/0/0. Is there a way to bundle more that 1GE port on a 12406? Regards ?Mark ????? _______________________________________________ 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 Tue Sep 16 10:45:48 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 16 Sep 2008 22:45:48 +0800 Subject: [c-nsp] IS-IS for IPv6: Passive Loopback Interface Address Not Propagated In-Reply-To: <48CFA830.8070708@renater.fr> References: <200809161433.40044.mtinka@globaltransit.net> <48CFA830.8070708@renater.fr> Message-ID: <200809162245.53672.mtinka@globaltransit.net> On Tuesday 16 September 2008 20:36:00 Frederic LOUI wrote: > My version is : IOS 124-11.T2 We haven't tested other releases on these boxes yet. 12.2(33)SXH3 does work on our SUP720-3BXL's, though. > Did you try ISIS debug command in order to see what's > happening ? When you inject your loopback ? We did; nothing came up - all other interfaces are added into IS-IS with the exception of the Loopbacks. > I record that there was some issues related to ISIS in > multi-topology environment. Actually, we found MT very useful when dual-stacking v4 and v6. > "metric style wide" command > was needed... We use wide metrics by default on all our IS's. > and also the interface command "ipv6 enable" > is sometimes mandatory. (depending on the IOS vesion) We haven't had to do this for our v6 deployment (even when I run v6 under 12.3 mainline at my previous employer). However, we did try enabling this command without much success in resolving this particular issue. > Please fin herewith this mail a snipset of config related > to ISIS for IPv6: Pretty straight forward. > At the sounds like it is a issue with the IOS > version. Agree. Will work it and hope TAC can reproduce the issue. 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 gert at greenie.muc.de Tue Sep 16 12:58:49 2008 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 16 Sep 2008 18:58:49 +0200 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <48CFC183.4060401@bytemark.co.uk> References: <50f158990809012015r32c2880ei9622a731a6acdf0a@mail.gmail.com> <20080902062732.GU233@greenie.muc.de> <48BD6380.6050309@gmail.com> <20080902171259.GB233@greenie.muc.de> <48BD78D4.6010405@gmail.com> <20080915145013.GA2245@greenie.muc.de> <1221508568.7357.15.camel@localhost> <48CEC162.5000105@bytemark.co.uk> <20080916040858.GA17256@greenie.muc.de> <48CFC183.4060401@bytemark.co.uk> Message-ID: <20080916165849.GA20288@greenie.muc.de> Hi, On Tue, Sep 16, 2008 at 03:24:03PM +0100, Peter Taphouse wrote: > > Would you mind sharing the case number with me? I could forward this to > > our TAC engineer so they know "this is not just us". > > I've got no bug ID, but it's on case SR 609537689. Thanks. I'll forward this - and let's see what will happen. [..] > Just to make you feel better, the 7604 I reloaded yesterday with SXF15 > just spontaneously reloaded... Hooray :( gert -- Gert Doering Mobile communications ... right now writing from * Sardegna, Italy * From kristian at spritelink.net Tue Sep 16 13:05:47 2008 From: kristian at spritelink.net (Kristian Larsson) Date: Tue, 16 Sep 2008 19:05:47 +0200 Subject: [c-nsp] Check bandwidth on router In-Reply-To: <89944ef40809111754s49466f26w38d25fc90df0b4f5@mail.gmail.com> References: <89944ef40809111754s49466f26w38d25fc90df0b4f5@mail.gmail.com> Message-ID: <20080916170547.GA16557@spritelink.se> On Thu, Sep 11, 2008 at 07:54:45PM -0500, root net wrote: > Hi List, > > Is there some sort of tool you can load into the IOS on a router to check > bandwidth? Or if not what are you all doing these days in this situation. > Like for example things are running slow and you think the Internet feed may > be the problem is there a way to do speed tests on the router itself? You can use ttcp directly from your router, it's a bit like iperf. It's a hidden commmand but works basically like the unix version, just type 'ttcp' at your IOS prompt and follow the "guide". STH1#ttcp transmit or receive [receive]: ... -K -- Kristian Larsson KLL-RIPE Network Engineer / Internet Core Tele2 / SWIPnet [AS1257] +46 704 910401 kll at spritelink.net From ranmails at gmail.com Tue Sep 16 13:50:50 2008 From: ranmails at gmail.com (Ran Liebermann) Date: Tue, 16 Sep 2008 20:50:50 +0300 Subject: [c-nsp] SRC2? In-Reply-To: <48A2FF3B.5030104@gatlan.nl> References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <48A2FF3B.5030104@gatlan.nl> Message-ID: <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com> Hi All, On Wed, Aug 13, 2008 at 6:35 PM, Bas Roos wrote: >> Anyone know when 12.2(33)SRC2 is supposed to be released, specifically >> for the 7600. I had heard by the end of July, but so far no release. > The latest statement we got from them was end-september. Anyone from Cisco perhaps would comment on this? CSCso45720 makes it really problematic to go into production stage with the SRC train. Cheers, -- Ran. From daniel.dib at reaper.nu Tue Sep 16 14:54:39 2008 From: daniel.dib at reaper.nu (Daniel Dib) Date: Tue, 16 Sep 2008 20:54:39 +0200 Subject: [c-nsp] 3750ME-7609 ES interface problem In-Reply-To: Message-ID: <001e01c9182d$aca88510$8119fea9@reap> On Tue, 16 Sep 2008, Matt Liotta wrote: I currently have a 3750ME connected via one of its ES interfaces to a 6509 on one of the OSM (GE-WAN) interfaces and things work fine. However, when I try to connect the other ES port on the same 3750ME to a 7609 GigE interface the port won't come up. What is strange is that the 3750ME shows the port as up/up, but the 7609 shows it as down/ down. Interestingly, if I shut the 7609 port the 3750's port then goes down as well. What am I missing? -Matt Hi. Do you have the same autonegotiate settings on the 7609 and the 3750. On the 3750 do you have speed nonegotiate and the same goes for the 7609. If you haven't configured it specifically it will be autonegotiated. This can lead to one port being up and the other down I've been bitten by this myself. This might not be your issue but it's just a hunch. See the link below: http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SXF/configuration/guide /intrface.html#wp1040549 /Daniel __________ Information from ESET NOD32 Antivirus, version of virus signature database 3446 (20080916) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From hank at efes.iucc.ac.il Tue Sep 16 15:37:02 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 16 Sep 2008 22:37:02 +0300 (IDT) Subject: [c-nsp] Check bandwidth on router In-Reply-To: <20080916170547.GA16557@spritelink.se> References: <89944ef40809111754s49466f26w38d25fc90df0b4f5@mail.gmail.com> <20080916170547.GA16557@spritelink.se> Message-ID: On Tue, 16 Sep 2008, Kristian Larsson wrote: > On Thu, Sep 11, 2008 at 07:54:45PM -0500, root net wrote: >> Hi List, >> >> Is there some sort of tool you can load into the IOS on a router to check >> bandwidth? Or if not what are you all doing these days in this situation. >> Like for example things are running slow and you think the Internet feed may >> be the problem is there a way to do speed tests on the router itself? > > You can use ttcp directly from your router, it's a > bit like iperf. It's a hidden commmand but works > basically like the unix version, just type 'ttcp' > at your IOS prompt and follow the "guide". Not all IOS versions have it. For example on 7200, IOS 12.4 - it doesn't work. http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080094694.shtml -Hank > > STH1#ttcp > transmit or receive [receive]: > ... > > -K > > -- > Kristian Larsson KLL-RIPE > Network Engineer / Internet Core Tele2 / SWIPnet [AS1257] > +46 704 910401 kll at spritelink.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 rodunn at cisco.com Tue Sep 16 16:17:57 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 16 Sep 2008 16:17:57 -0400 Subject: [c-nsp] SRC2? In-Reply-To: <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com> References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <48A2FF3B.5030104@gatlan.nl> <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com> Message-ID: <20080916201757.GE14932@rtp-cse-489.cisco.com> 9/30 'ish On Tue, Sep 16, 2008 at 08:50:50PM +0300, Ran Liebermann wrote: > Hi All, > > On Wed, Aug 13, 2008 at 6:35 PM, Bas Roos wrote: > > >> Anyone know when 12.2(33)SRC2 is supposed to be released, specifically > >> for the 7600. I had heard by the end of July, but so far no release. > > > The latest statement we got from them was end-september. > > Anyone from Cisco perhaps would comment on this? > CSCso45720 makes it really problematic to go into production stage > with the SRC train. > > Cheers, > -- > Ran. > _______________________________________________ > 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 rinse.kloek at isp.solcon.nl Tue Sep 16 15:07:16 2008 From: rinse.kloek at isp.solcon.nl (Rinse Kloek (Solcon)) Date: Tue, 16 Sep 2008 21:07:16 +0200 Subject: [c-nsp] SRC2? In-Reply-To: <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com> References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <48A2FF3B.5030104@gatlan.nl> <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com> Message-ID: <48D003E4.7000005@isp.solcon.nl> We are also running in some bug ( CSCsk27643 ) and are hoping to see this fixed in SRC2. Anybody some tips to get PBR using set vrf working on a 12.2 release ? regards Rinse cisco-nsp at puck.nether.net > Hi All, > > On Wed, Aug 13, 2008 at 6:35 PM, Bas Roos wrote: > > >>> Anyone know when 12.2(33)SRC2 is supposed to be released, specifically >>> for the 7600. I had heard by the end of July, but so far no release. >>> > > >> The latest statement we got from them was end-september. >> > > Anyone from Cisco perhaps would comment on this? > CSCso45720 makes it really problematic to go into production stage > with the SRC train. > > Cheers, > -- > Ran. > _______________________________________________ > 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_mark_99 at yahoo.com Tue Sep 16 17:24:31 2008 From: steven_mark_99 at yahoo.com (Steven Mark) Date: Tue, 16 Sep 2008 14:24:31 -0700 (PDT) Subject: [c-nsp] MX960 vs Cisco 7600 Message-ID: <169205.49326.qm@web63406.mail.re1.yahoo.com> hello, We are a small ISP based out of Asia and we are considering above two products for carrier ethernet deployment. If anyone has done a comparitive study or have experience (support, feature-richness, IOS/JUNOS stability etc.). Thanks Steve From achatz at forthnet.gr Tue Sep 16 17:32:29 2008 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Wed, 17 Sep 2008 00:32:29 +0300 Subject: [c-nsp] SRC2? In-Reply-To: <20080916201757.GE14932@rtp-cse-489.cisco.com> References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <48A2FF3B.5030104@gatlan.nl> <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com> <20080916201757.GE14932@rtp-cse-489.cisco.com> Message-ID: <48D025ED.4000600@forthnet.gr> I believe SRD (plus the new ES cards) are supposed to come out at that time too... -- Tassos Rodney Dunn wrote on 16/09/2008 23:17: > 9/30 'ish > > On Tue, Sep 16, 2008 at 08:50:50PM +0300, Ran Liebermann wrote: >> Hi All, >> >> On Wed, Aug 13, 2008 at 6:35 PM, Bas Roos wrote: >> >>>> Anyone know when 12.2(33)SRC2 is supposed to be released, specifically >>>> for the 7600. I had heard by the end of July, but so far no release. >>> The latest statement we got from them was end-september. >> Anyone from Cisco perhaps would comment on this? >> CSCso45720 makes it really problematic to go into production stage >> with the SRC train. >> >> Cheers, >> -- >> Ran. >> _______________________________________________ >> 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 roddy.strachan at staff.netspace.net.au Tue Sep 16 19:15:27 2008 From: roddy.strachan at staff.netspace.net.au (Roddy Strachan) Date: Wed, 17 Sep 2008 09:15:27 +1000 Subject: [c-nsp] ISG/Radius MQOS Rate Limiting Message-ID: Hey all, I?m playing around with assigning MQOS policy maps to users when they login, this is working fine via radius. Has anyone got any suggestions/ideas on how to assign them an ?unshaped? policy so once their allocated usage has reset, assign them the ?unshaped? policy via ISG on the fly ? I?ve had a look at some Cisco doco, but it doesn?t seem to have what I want, I can manually assign the unshaped policy to the virtual-template interface and it does what I want, but I want to be able to do this from say a database, so once usage resets it send an av-pair to the relevant session and gives them their full speed back again.... Thanks. 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 nitzan.tzelniker at gmail.com Tue Sep 16 21:06:58 2008 From: nitzan.tzelniker at gmail.com (Nitzan Tzelniker) Date: Wed, 17 Sep 2008 04:06:58 +0300 Subject: [c-nsp] RES: Cisco 12406 Etherchannel In-Reply-To: <255784.49437.qm@web44808.mail.sp1.yahoo.com> References: <255784.49437.qm@web44808.mail.sp1.yahoo.com> Message-ID: <6d72a2a10809161806o434b47bbra20616720566fae@mail.gmail.com> You need 12.0(33)S1 Starting in Cisco IOS Release 12.0(33)S, Engine 5 line cards are also supported as the egress interface on which you can configure a virtual interface (EtherChannel or POS channel) for a link bundle. For a list of supported Engine 5 interfaces, see Line Cards Supported on the Cisco 12000 Router. Nitzan On Tue, Sep 16, 2008 at 18:57, Mark Tech wrote: > Hi, thanks for that. Just had a look at my inventory > > sh inventory > NAME: "slot 0", DESCR: "ISE 10G Modular Services Card v2" > PID: 12000-SIP-601 , VID: V04, SN: SAD12340460 > > Looks like I have an ISE card installed. If I look at the restrictions for > the ISE, seems like only the following cards are supported: > > IP Service Engine (ISE): > ?4-port Gigabit Ethernet ISE line card > ?4-port OC-3c/STM-1c POS/SDH ISE line card > ?8-port OC-3c/STM-1c POS/SDH ISE line card > ?16-port OC-3c/STM-1c POS/SDH ISE line card > ?4-port OC-12c/STM-4c POS/SDH ISE line card > ?1-port OC-48c/STM-16c POS/SDH ISE line card > > However it then goes to mention that the following cards support it. > > Engine 5 SPA Interface Processors (SIPs): > ?10G Engine 5 SPA Interface Processor (12000-SIP-600) > ?2.5G multiservice engine SPA Interface Processor (12000-SIP-401) > ?5G multiservice engine SPA Interface Processor (12000-SIP-501) > ?10G multiservice engine SPA Interface Processor (12000-SIP-601) > > The GE cards are installed in a 12000-SIP-601, or is that I don't have > an'Engine 5' within the 601installed? > > Regards > > Mark > > > > ----- Original Message ---- > From: Leonardo Gama Souza > To: Mark Tech > Cc: cisco-nsp at puck.nether.net > Sent: Tuesday, September 16, 2008 3:49:54 PM > Subject: RES: [c-nsp] Cisco 12406 Etherchannel > > > There are some restrictions... > Take a look: > http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/lnkbndl.html > > Cheers. > > ________________________________ > De: cisco-nsp-bounces at puck.nether.net em nome de Mark Tech > Enviada: ter 16/9/2008 08:12 > Para: cisco-nsp at puck.nether.net > Assunto: [c-nsp] Cisco 12406 Etherchannel > > > Hi > I am trying to configure Ethernchannel/link bundling on a 12406. The port > channel seems to be accepted, however when I try and add a channel-group to > my GE interfaces, it says its not supported? I am using SPA-10X1GE-V2 line > cards with c12kprp-p-mz.120-32.SY6.bin IOS > > > interface Port-channel1 > ip address x.x.x.x 255.255.255.252 > no ip directed-broadcast > channel-group minimum active 1 > no channel-group bandwidth control-propagation > > router(config-if)#channel-group 1 > Error: not supported on GigabitEthernet0/0/0. > > Is there a way to bundle more that 1GE port on a 12406? > > Regards > > Mark > > > > > _______________________________________________ > 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 rubensk at gmail.com Tue Sep 16 21:24:13 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Tue, 16 Sep 2008 22:24:13 -0300 Subject: [c-nsp] MX960 vs Cisco 7600 In-Reply-To: <169205.49326.qm@web63406.mail.re1.yahoo.com> References: <169205.49326.qm@web63406.mail.re1.yahoo.com> Message-ID: <6bb5f5b10809161824s307dd8famca5b9ec248ad5106@mail.gmail.com> Cisco 7600 + ES20 are way too expensive on a price/port perspective. Consider distributing smaller Cisco ME6524 boxes (which is not as cheap as it used to be, but it is still lot less than 7600) instead of large boxes like MX 960; if you really have the density to buy MX 960 instead of MX 240, I don't think there is anything on Cisco-land that can match that. Rubens On Tue, Sep 16, 2008 at 6:24 PM, Steven Mark wrote: > hello, > > We are a small ISP based out of Asia and we are considering above two products for carrier ethernet deployment. If anyone has done a comparitive study or have experience (support, feature-richness, IOS/JUNOS stability etc.). > > Thanks > Steve > > > > _______________________________________________ > 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 Tue Sep 16 21:33:58 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 17 Sep 2008 09:33:58 +0800 Subject: [c-nsp] MX960 vs Cisco 7600 In-Reply-To: <6bb5f5b10809161824s307dd8famca5b9ec248ad5106@mail.gmail.com> References: <169205.49326.qm@web63406.mail.re1.yahoo.com> <6bb5f5b10809161824s307dd8famca5b9ec248ad5106@mail.gmail.com> Message-ID: <200809170934.03481.mtinka@globaltransit.net> On Wednesday 17 September 2008 09:24:13 Rubens Kuhl Jr. wrote: > Cisco 7600 + ES20 are way too expensive on a price/port > perspective. Consider distributing smaller Cisco ME6524 > boxes (which is not as cheap as it used to be, but it is > still lot less than 7600)... In our consideration for a "small" box capable of handling a large number of EoMPLS VC's, the ME6524 came up - but sadly, we can only think of it in that function, and not a combined L2VPN + IP termination device. This is because it can only support 256,000 v4 routing entries (PFC-3C). Would advise the OP to look at this if he's thinking of carrying full routes on it. If 0/0 is good enough, then no worries. 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 rubensk at gmail.com Tue Sep 16 21:45:09 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Tue, 16 Sep 2008 22:45:09 -0300 Subject: [c-nsp] MX960 vs Cisco 7600 In-Reply-To: <200809170934.03481.mtinka@globaltransit.net> References: <169205.49326.qm@web63406.mail.re1.yahoo.com> <6bb5f5b10809161824s307dd8famca5b9ec248ad5106@mail.gmail.com> <200809170934.03481.mtinka@globaltransit.net> Message-ID: <6bb5f5b10809161845q56efd65dy2f256188395dbc9f@mail.gmail.com> Mark, Even with no full-routing capability, one can still do L3 or L2 VPN so the customer can reach a central Internet router with half million/one million routes if it`s a BGP customer, or follow default if it's a single-homed customer. That works if such a BGP customer are in the few percent exception, not on 90%+ rule... which is the case for our market, but might not be the case for the original poster. Good point. Rubens On Tue, Sep 16, 2008 at 10:33 PM, Mark Tinka wrote: > On Wednesday 17 September 2008 09:24:13 Rubens Kuhl Jr. > wrote: > >> Cisco 7600 + ES20 are way too expensive on a price/port >> perspective. Consider distributing smaller Cisco ME6524 >> boxes (which is not as cheap as it used to be, but it is >> still lot less than 7600)... > > In our consideration for a "small" box capable of handling a > large number of EoMPLS VC's, the ME6524 came up - but > sadly, we can only think of it in that function, and not a > combined L2VPN + IP termination device. > > This is because it can only support 256,000 v4 routing > entries (PFC-3C). > > Would advise the OP to look at this if he's thinking of > carrying full routes on it. If 0/0 is good enough, then no > worries. > > Mark. > From Jaime at ulima.edu.pe Tue Sep 16 22:23:04 2008 From: Jaime at ulima.edu.pe (Velasquez Venegas Jaime Omar) Date: Tue, 16 Sep 2008 21:23:04 -0500 Subject: [c-nsp] NTP not synchronizing In-Reply-To: <200809151211.m8FCBrPQ061496@puck.nether.net> Message-ID: <8DD1F4B50477AC45A35AB5F8C03B62C4018567AF@sauce.ulima.ul> I kept working on this ntp issue.It's a fact that there's no packet going out of the serial interface of the router even when NTP debugging says "NTP xmit packet".NTP Server is reacheable from the router through any protocol. Did some attempts like swapping ntp server ,changing ntp versions,changing ntp server software,adding ntp broadcast delay in the router.Heck I even disabled ntp so I can get a different message other than Clock is unsynchronized. Last time I restarted the router I removed all the ntp configuration in the hope that it recalculates "ntp clock-period" parameter as cisco documentation states but it didn't so now it's working with the previous clock-period parameter. These are detailed outputs of ntp status commands: R1>show ntp assoc de configured, insane, invalid, unsynced, stratum 16 ref ID 0.0.0.0, time 00000000.00000000 (19:00:00.000 Thu Dec 31 1899) our mode client, peer mode unspec, our poll intvl 64, peer poll intvl 64 root delay 0.00 msec, root disp 0.00, reach 0, sync dist 0.000 delay 0.00 msec, offset 0.0000 msec, dispersion 16000.00 precision 2**5, version 3 org time 00000000.00000000 (19:00:00.000 Thu Dec 31 1899) rcv time 00000000.00000000 (19:00:00.000 Thu Dec 31 1899) xmt time CC7AC750.449B3CCC (19:01:20.267 Tue Sep 16 2008) filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 filterror = 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 R1>show ntp stat Clock is unsynchronized, stratum 16, no reference clock nominal freq is 249.5901 Hz, actual freq is 249.5906 Hz, precision is 2**16 reference time is CC7553E4.FE3E6D2D (15:47:32.993 Fri Sep 12 2008) clock offset is 0.0000 msec, root delay is 0.00 msec root dispersion is 0.02 msec, peer dispersion is 0.02 msec I may try to restart it one more time before I suspect a faulty ntp service. -----Mensaje original----- De: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] En nombre de Aaron R Enviado el: Monday, September 15, 2008 7:12 AM Para: 'Mike Louis'; 'root net'; Velasquez Venegas Jaime Omar CC: cisco-nsp at puck.nether.net Asunto: Re: [c-nsp] NTP not synchronizing I have had similar problems in the past. I have found if your clock / date are not set properly the router will refuse to accept the NTP update as the offset is too large. Also as suggested try multiple NTP servers. The fact that you are unable to see the configured NTP servers' ref clock / stratum most likely indicates some kind of comms issue. Cheers, Aaron. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mike Louis Sent: Monday, September 15, 2008 7:40 PM To: root net; Velasquez Venegas Jaime Omar Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] NTP not synchronizing What source interface is the cisco client router using for NTP requests? If its not configured it will use the outbound interface used to reach the server. I saw an issue the other day where the external interface on the WAN was not reachable by the NTP server at the home office and thus they could not sync time. They changed the source interface to "ntp source-interface Fax/x" (for their lan which was reachable) and were able to get sync'd. HTH Mike -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net Sent: Monday, September 15, 2008 12:17 AM To: Velasquez Venegas Jaime Omar Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] NTP not synchronizing What NTP server are you using? Are you trying to use the Cisco router as the NTP server for your clients/hosts on your network or what? My bet is the NTP server is overwhelmed you are trying to connect to. I had this issue before and changed NTP servers worked like a charm. Check the NIST listing for an updated listing of NTP servers that are free or with little users. rootnet On Sat, Sep 13, 2008 at 1:30 PM, Velasquez Venegas Jaime Omar < Jaime at ulima.edu.pe> wrote: > Hi there. > > I'm having a problem trying to synchronize a Cisco Router across a wan > link with a NTP Server (No-Cisco router).So far i've ruled out packet > filering or firewall blocking as a cause of this.Some other equipments > at the local side of this router actually synchronize with the ntp > server at our LAN.What strikes me is the fact that router does reach > ntp server via other protocols other than ntp tough. > > > This is what i get from the out-of-sync router: > #Show ntp assoc > address ref clock st when poll reach delay offset > disp > ~<> 0.0.0.0 16 - 64 0 0.0 0.00 > 16000. > * master (synced), # master (unsynced), + selected, - candidate, ~ > configured > > I've set debugging for the ntp packets and for all the traffic getting > out of the serial interface which got "NTP: xmit packet to NTP.Server" > events.However there 's absolutely no attempt whatsoever of packet > being transmitted to NTP Server at the serial interface. > I've also configured this router as a ntp master and tried to get the > hosts on its local ethernet to synchronize with it to no avail. > > Any insight? > > 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/ > _______________________________________________ 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. _______________________________________________ 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 - http://www.avg.com Version: 8.0.169 / Virus Database: 270.6.21/1670 - Release Date: 9/14/2008 7:16 AM _______________________________________________ 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 Tue Sep 16 22:38:03 2008 From: cchurc05 at harris.com (Church, Charles) Date: Tue, 16 Sep 2008 21:38:03 -0500 Subject: [c-nsp] NTP not synchronizing In-Reply-To: <8DD1F4B50477AC45A35AB5F8C03B62C4018567AF@sauce.ulima.ul> References: <200809151211.m8FCBrPQ061496@puck.nether.net> <8DD1F4B50477AC45A35AB5F8C03B62C4018567AF@sauce.ulima.ul> Message-ID: Is the NTP you're trying to sync to synchronized itself? NTP (unlike SNTP) requires that. The 'insane' and 'invalid' debug messages seem to indicate that, I believe. Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Velasquez Venegas Jaime Omar Sent: Tuesday, September 16, 2008 10:23 PM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] NTP not synchronizing I kept working on this ntp issue.It's a fact that there's no packet going out of the serial interface of the router even when NTP debugging says "NTP xmit packet".NTP Server is reacheable from the router through any protocol. Did some attempts like swapping ntp server ,changing ntp versions,changing ntp server software,adding ntp broadcast delay in the router.Heck I even disabled ntp so I can get a different message other than Clock is unsynchronized. Last time I restarted the router I removed all the ntp configuration in the hope that it recalculates "ntp clock-period" parameter as cisco documentation states but it didn't so now it's working with the previous clock-period parameter. These are detailed outputs of ntp status commands: R1>show ntp assoc de configured, insane, invalid, unsynced, stratum 16 ref ID 0.0.0.0, time 00000000.00000000 (19:00:00.000 Thu Dec 31 1899) our mode client, peer mode unspec, our poll intvl 64, peer poll intvl 64 root delay 0.00 msec, root disp 0.00, reach 0, sync dist 0.000 delay 0.00 msec, offset 0.0000 msec, dispersion 16000.00 precision 2**5, version 3 org time 00000000.00000000 (19:00:00.000 Thu Dec 31 1899) rcv time 00000000.00000000 (19:00:00.000 Thu Dec 31 1899) xmt time CC7AC750.449B3CCC (19:01:20.267 Tue Sep 16 2008) filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 filterror = 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 R1>show ntp stat Clock is unsynchronized, stratum 16, no reference clock nominal freq is 249.5901 Hz, actual freq is 249.5906 Hz, precision is 2**16 reference time is CC7553E4.FE3E6D2D (15:47:32.993 Fri Sep 12 2008) clock offset is 0.0000 msec, root delay is 0.00 msec root dispersion is 0.02 msec, peer dispersion is 0.02 msec I may try to restart it one more time before I suspect a faulty ntp service. -----Mensaje original----- De: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] En nombre de Aaron R Enviado el: Monday, September 15, 2008 7:12 AM Para: 'Mike Louis'; 'root net'; Velasquez Venegas Jaime Omar CC: cisco-nsp at puck.nether.net Asunto: Re: [c-nsp] NTP not synchronizing I have had similar problems in the past. I have found if your clock / date are not set properly the router will refuse to accept the NTP update as the offset is too large. Also as suggested try multiple NTP servers. The fact that you are unable to see the configured NTP servers' ref clock / stratum most likely indicates some kind of comms issue. Cheers, Aaron. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mike Louis Sent: Monday, September 15, 2008 7:40 PM To: root net; Velasquez Venegas Jaime Omar Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] NTP not synchronizing What source interface is the cisco client router using for NTP requests? If its not configured it will use the outbound interface used to reach the server. I saw an issue the other day where the external interface on the WAN was not reachable by the NTP server at the home office and thus they could not sync time. They changed the source interface to "ntp source-interface Fax/x" (for their lan which was reachable) and were able to get sync'd. HTH Mike -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of root net Sent: Monday, September 15, 2008 12:17 AM To: Velasquez Venegas Jaime Omar Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] NTP not synchronizing What NTP server are you using? Are you trying to use the Cisco router as the NTP server for your clients/hosts on your network or what? My bet is the NTP server is overwhelmed you are trying to connect to. I had this issue before and changed NTP servers worked like a charm. Check the NIST listing for an updated listing of NTP servers that are free or with little users. rootnet On Sat, Sep 13, 2008 at 1:30 PM, Velasquez Venegas Jaime Omar < Jaime at ulima.edu.pe> wrote: > Hi there. > > I'm having a problem trying to synchronize a Cisco Router across a wan > link with a NTP Server (No-Cisco router).So far i've ruled out packet > filering or firewall blocking as a cause of this.Some other equipments > at the local side of this router actually synchronize with the ntp > server at our LAN.What strikes me is the fact that router does reach > ntp server via other protocols other than ntp tough. > > > This is what i get from the out-of-sync router: > #Show ntp assoc > address ref clock st when poll reach delay offset > disp > ~<> 0.0.0.0 16 - 64 0 0.0 0.00 > 16000. > * master (synced), # master (unsynced), + selected, - candidate, ~ > configured > > I've set debugging for the ntp packets and for all the traffic getting > out of the serial interface which got "NTP: xmit packet to NTP.Server" > events.However there 's absolutely no attempt whatsoever of packet > being transmitted to NTP Server at the serial interface. > I've also configured this router as a ntp master and tried to get the > hosts on its local ethernet to synchronize with it to no avail. > > Any insight? > > 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/ > _______________________________________________ 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. _______________________________________________ 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 - http://www.avg.com Version: 8.0.169 / Virus Database: 270.6.21/1670 - Release Date: 9/14/2008 7:16 AM _______________________________________________ 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 Tue Sep 16 23:23:38 2008 From: brad.henshaw at qcn.com.au (Brad Henshaw) Date: Wed, 17 Sep 2008 13:23:38 +1000 Subject: [c-nsp] ME3750 Shaping Message-ID: <8B25B862BC09784B9B74FB950D4F64D406C959@qcnapp01.corp.qcn> Eric Van Tol wrote: > I've explained the situation to both Arie and my local SE. > It looks like the 3750 is simply not able to provide what we need it to do today. Oh I'm sure it can do what you need - but only on 2 out of the 28 ports :-/ (which is obviously insufficient) When I've hit this situation I've ended up using multiple ME3750s but this isn't really scalable beyond 2 units. 7600+OSM or 7600+SIP400+GE SPA's are just (for our application) too expensive. ASR might be a viable option depending on required throughput. Regards, Brad From alex.wilkinson at dsto.defence.gov.au Wed Sep 17 00:05:42 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Wed, 17 Sep 2008 12:05:42 +0800 Subject: [c-nsp] Check bandwidth on router In-Reply-To: <20080916170547.GA16557@spritelink.se> References: <89944ef40809111754s49466f26w38d25fc90df0b4f5@mail.gmail.com> <20080916170547.GA16557@spritelink.se> Message-ID: <20080917040542.GZ61978@stlux503.dsto.defence.gov.au> 0n Tue, Sep 16, 2008 at 07:05:47PM +0200, Kristian Larsson wrote: >On Thu, Sep 11, 2008 at 07:54:45PM -0500, root net wrote: >> Hi List, >> >> Is there some sort of tool you can load into the IOS on a router to check >> bandwidth? Or if not what are you all doing these days in this situation. >> Like for example things are running slow and you think the Internet feed may >> be the problem is there a way to do speed tests on the router itself? > >You can use ttcp directly from your router, it's a >bit like iperf. It's a hidden commmand but works >basically like the unix version, just type 'ttcp' >at your IOS prompt and follow the "guide". Why on earth is it a hidden command I wonder ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From brad.henshaw at qcn.com.au Wed Sep 17 01:02:44 2008 From: brad.henshaw at qcn.com.au (Brad Henshaw) Date: Wed, 17 Sep 2008 15:02:44 +1000 Subject: [c-nsp] Check bandwidth on router Message-ID: <8B25B862BC09784B9B74FB950D4F64D406C95A@qcnapp01.corp.qcn> Wilkinson, Alex wrote: > Why on earth is [ttcp] a hidden command I wonder ? It's an unsupported command. If only Cisco would remove (not just hide) other unsupported commands across the various platforms. I've seen the performance of ttcp vary across platforms and IOS versions - in some instances it demonstrates inconsistent and low throughput where no such problem really exists, so don't assume the results from ttcp run from routers/switches are necessarily accurate or rely on the results for fault diagnosis. Regards, Brad From roddy.strachan at staff.netspace.net.au Wed Sep 17 01:06:51 2008 From: roddy.strachan at staff.netspace.net.au (Roddy Strachan) Date: Wed, 17 Sep 2008 15:06:51 +1000 Subject: [c-nsp] ISG/Radius MQOS Rate Limiting In-Reply-To: Message-ID: Nevermind folks, actually managed to get this happening now. Thanks anyway :) On 17/09/08 9:15 AM, "Roddy Strachan" wrote: > Hey all, > > I?m playing around with assigning MQOS policy maps to users when they login, > this is working fine via radius. > > Has anyone got any suggestions/ideas on how to assign them an ?unshaped? > policy so once their allocated usage has reset, assign them the ?unshaped? > policy via ISG on the fly ? > > I?ve had a look at some Cisco doco, but it doesn?t seem to have what I want, > I can manually assign the unshaped policy to the virtual-template interface > and it does what I want, but I want to be able to do this from say a > database, so once usage resets it send an av-pair to the relevant session > and gives them their full speed back again.... > > Thanks. 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 alex.wilkinson at dsto.defence.gov.au Wed Sep 17 02:36:20 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Wed, 17 Sep 2008 14:36:20 +0800 Subject: [c-nsp] Cisco NAC In-Reply-To: <008701c917e7$05437140$0fca53c0$@com> References: <008701c917e7$05437140$0fca53c0$@com> Message-ID: <20080917063620.GD61978@stlux503.dsto.defence.gov.au> 0n Tue, Sep 16, 2008 at 06:28:54AM -0400, Steve Fischer wrote: >Does anyone here use the Cisco NAC product? Is there a mailing list of >which anyone knows specifically for Cisco NAC? User's group? Online >community? Any assistance in directing me toward any of these resources >would be genuinely appreciated. You may find this useful: "Introduction to Cisco Network Admission Control" By Dr. Peter J. Welcher (CCIE #1773, CCSI #94014, CCIP)" [http://www.netcraftsmen.net/welcher/papers/cnac01.html] -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From avayner at cisco.com Wed Sep 17 03:02:40 2008 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Wed, 17 Sep 2008 09:02:40 +0200 Subject: [c-nsp] cisco 7507 vs ssg 550 In-Reply-To: References: Message-ID: <67F7C1FAF83A074AA3520D8F155782A501DD1BEA@xmb-ams-331.emea.cisco.com> Faisal, Why don't you take a look at a 7200/NPE-G2 (or even a 7201, which is a 1RU version of it). http://www.cisco.com/en/US/products/hw/routers/ps341/index.html http://www.cisco.com/en/US/prod/collateral/routers/ps341/product_data_sh eet0900aecd8047177b.html http://www.cisco.com/en/US/products/ps7253/index.html The advantage of changing to this kind of device is that it would be a natural upgrade from 7500 (which is a very old model...). All the configs should most likely transfer as a simple copy paste. Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Faisal Muzammil Sent: Tuesday, September 16, 2008 12:52 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] cisco 7507 vs ssg 550 Hi, We have a cisco 7507 router for our wan and are thinking of replacing it with juniper ssg 550. Currently we have 1 GEIP interface on the lan side of 7507 and 1 POS(STM/OC3) interface on the wan side. We have a few IP IP tunnels established and are running BGP over the wan and OSPF on the lan side. We also have the need of using PBRs. The main reason behind this change is that we are going to outgrow our STM capacity and need to upgrade to higher bandwidth on the wan side. hence similarly we will need to have a better option on the lan side instead of GEIP due to the limitation of 200mbps aggregate throughput on it. Thanks in advance for your suggestions regards Famz _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.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 steven_mark_99 at yahoo.com Wed Sep 17 03:35:46 2008 From: steven_mark_99 at yahoo.com (Steven Mark) Date: Wed, 17 Sep 2008 00:35:46 -0700 (PDT) Subject: [c-nsp] MX960 vs Cisco 7600 In-Reply-To: <6bb5f5b10809161824s307dd8famca5b9ec248ad5106@mail.gmail.com> Message-ID: <868814.81313.qm@web63407.mail.re1.yahoo.com> Thanks Rubens, We need a good pricing on 10Gbps ports (who doesnt!) and also oversubscription support. Moreover, we would like to see 100Gbps backplane/chassis capability (We are still evaluating both products). We like the fact that 7600 has richer interface variety (non ethernet ports) but we get concerned about software stability vis-a-vis JUNOS. Also, in our experience finding junos-certified personnel has been a tougher task than ios-certified personnel (something that would affect opex in a significant way). Steve --- On Tue, 9/16/08, Rubens Kuhl Jr. wrote: > From: Rubens Kuhl Jr. > Subject: Re: [c-nsp] MX960 vs Cisco 7600 > To: steven_mark_99 at yahoo.com > Cc: cisco-nsp at puck.nether.net > Date: Tuesday, September 16, 2008, 6:24 PM > Cisco 7600 + ES20 are way too expensive on a price/port > perspective. > Consider distributing smaller Cisco ME6524 boxes (which is > not as > cheap as it used to be, but it is still lot less than 7600) > instead of > large boxes like MX 960; if you really have the density to > buy MX 960 > instead of MX 240, I don't think there is anything on > Cisco-land that > can match that. > > > > Rubens > > On Tue, Sep 16, 2008 at 6:24 PM, Steven Mark > wrote: > > hello, > > > > We are a small ISP based out of Asia and we are > considering above two products for carrier ethernet > deployment. If anyone has done a comparitive study or have > experience (support, feature-richness, IOS/JUNOS stability > etc.). > > > > Thanks > > Steve > > > > > > > > _______________________________________________ > > 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 oboehmer at cisco.com Wed Sep 17 03:26:16 2008 From: oboehmer at cisco.com (Oliver Boehmer (oboehmer)) Date: Wed, 17 Sep 2008 09:26:16 +0200 Subject: [c-nsp] RES: Cisco 12406 Etherchannel In-Reply-To: <255784.49437.qm@web44808.mail.sp1.yahoo.com> References: <255784.49437.qm@web44808.mail.sp1.yahoo.com> Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED7840607ABC5@xmb-ams-333.emea.cisco.com> Mark, you need 12.0(33)S to add SIP601 (it's an Engine5) GigE ports to a bundle.. take a look at the "Feature History" table in the link Leonardo quoted.. oli Mark Tech <> wrote on Tuesday, September 16, 2008 5:58 PM: > Hi, thanks for that. Just had a look at my inventory > > sh inventory > NAME: "slot 0", DESCR: "ISE 10G Modular Services Card v2" > PID: 12000-SIP-601???? , VID: V04, SN: SAD12340460 > > Looks like I have an ISE card installed. If I look at the > restrictions for the ISE, seems like only the following cards are > supported: > > IP Service Engine (ISE): > -4-port Gigabit Ethernet ISE line card > -4-port OC-3c/STM-1c POS/SDH ISE line card > -8-port OC-3c/STM-1c POS/SDH ISE line card > -16-port OC-3c/STM-1c POS/SDH ISE line card > -4-port OC-12c/STM-4c POS/SDH ISE line card > -1-port OC-48c/STM-16c POS/SDH ISE line card > > However it then goes to mention that the following cards support it. > > Engine 5 SPA Interface Processors (SIPs): > -10G Engine 5 SPA Interface Processor (12000-SIP-600) > -2.5G multiservice engine SPA Interface Processor (12000-SIP-401) > -5G multiservice engine SPA Interface Processor (12000-SIP-501) > -10G multiservice engine SPA Interface Processor (12000-SIP-601) > > The GE cards are installed in a 12000-SIP-601, or is that I don't > have an'Engine 5' within the 601installed? > > Regards > > Mark > > > > ----- Original Message ---- > From: Leonardo Gama Souza > To: Mark Tech > Cc: cisco-nsp at puck.nether.net > Sent: Tuesday, September 16, 2008 3:49:54 PM > Subject: RES: [c-nsp] Cisco 12406 Etherchannel > > > There are some restrictions... > Take a look: > http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/lnkbndl.html > > Cheers. > > ________________________________ > De: cisco-nsp-bounces at puck.nether.net em nome de Mark Tech > Enviada: ter 16/9/2008 08:12 > Para: cisco-nsp at puck.nether.net > Assunto: [c-nsp] Cisco 12406 Etherchannel > > > Hi > I am trying to configure Ethernchannel/link bundling on a 12406. The > port channel seems to be accepted, however when I try and add a > channel-group to my GE interfaces, it says its not supported? I am > using SPA-10X1GE-V2 line cards with c12kprp-p-mz.120-32.SY6.bin IOS > > > interface Port-channel1 > ?ip address?x.x.x.x 255.255.255.252 > ?no ip directed-broadcast > ?channel-group minimum active 1 > ?no channel-group bandwidth control-propagation > > router(config-if)#channel-group 1 > Error: not supported on GigabitEthernet0/0/0. > > Is there a way to bundle more that 1GE port on a 12406? > > Regards > > ?Mark > > > > > _______________________________________________ > 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 swmike at swm.pp.se Wed Sep 17 04:03:52 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 17 Sep 2008 10:03:52 +0200 (CEST) Subject: [c-nsp] RES: Cisco 12406 Etherchannel In-Reply-To: <255784.49437.qm@web44808.mail.sp1.yahoo.com> References: <255784.49437.qm@web44808.mail.sp1.yahoo.com> Message-ID: On Tue, 16 Sep 2008, Mark Tech wrote: > The GE cards are installed in a 12000-SIP-601, or is that I don't have > an'Engine 5' within the 601installed? SIP-600 and SIP-601 are both "Engine 5" linecards. It can be seen in "show diag", it will show the "Engine" number for each linecard. It's basically just the version of the hardware, there are everything from "engine 0" (for instance the 4 port OC3 card) to "engine 6" (the 2 port OC192 card). Engine 3 and Engine 5 are "ISE", they do more features than the others. -- Mikael Abrahamsson email: swmike at swm.pp.se From blahu77 at gmail.com Wed Sep 17 05:36:18 2008 From: blahu77 at gmail.com (=?ISO-8859-2?Q?Mateusz_B=B3aszczyk?=) Date: Wed, 17 Sep 2008 10:36:18 +0100 Subject: [c-nsp] MX960 vs Cisco 7600 In-Reply-To: <6bb5f5b10809161845q56efd65dy2f256188395dbc9f@mail.gmail.com> References: <169205.49326.qm@web63406.mail.re1.yahoo.com> <6bb5f5b10809161824s307dd8famca5b9ec248ad5106@mail.gmail.com> <200809170934.03481.mtinka@globaltransit.net> <6bb5f5b10809161845q56efd65dy2f256188395dbc9f@mail.gmail.com> Message-ID: <383357750809170236h5ad57605t54b0261ad6dae315@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rubens, > Even with no full-routing capability, one can still do L3 or L2 VPN Me6524 can't do L2VPN (VPLS), ATOM is supported though. Best Regards, - -- - -mat pgp-key 0x4E5EB11E -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI0M+SIvBv0k5esR4RAg/9AJ4yn0Dl6SXSNZwxhweP3ucLGG6r1ACeM/Z0 O5Yb8UDb7uAiUswEKYEzK3Y= =FmD6 -----END PGP SIGNATURE----- From eric at atlantech.net Wed Sep 17 06:41:27 2008 From: eric at atlantech.net (Eric Van Tol) Date: Wed, 17 Sep 2008 06:41:27 -0400 Subject: [c-nsp] ME3750 Shaping In-Reply-To: <8B25B862BC09784B9B74FB950D4F64D406C959@qcnapp01.corp.qcn> References: <8B25B862BC09784B9B74FB950D4F64D406C959@qcnapp01.corp.qcn> Message-ID: <2C05E949E19A9146AF7BDF9D44085B86350AECC4C0@exchange.aoihq.local> > -----Original Message----- > From: Brad Henshaw [mailto:brad.henshaw at qcn.com.au] > Sent: Tuesday, September 16, 2008 11:24 PM > To: Eric Van Tol > Cc: cisco-nsp at puck.nether.net > Subject: RE: [c-nsp] ME3750 Shaping > > Oh I'm sure it can do what you need - but only on 2 out of the 28 ports > :-/ > (which is obviously insufficient) > Yes, very frustrating. Other vendors seem to be able to support full functionality on all ports, so I'm not sure why Cisco continues to rely on either outdated technology or bad BU decisions to cripple boxes. I'm pretty sure that it's the hardware that's the problem, though. > When I've hit this situation I've ended up using multiple ME3750s but > this isn't > really scalable beyond 2 units. 7600+OSM or 7600+SIP400+GE SPA's are > just (for our > application) too expensive. ASR might be a viable option depending on > required > throughput. 7600/ME4900/ME6500/ASR - None are either very cost effective or are simply too big and use too much power for what we are doing. We don't really have an upgrade to 10/100/1000 on this switch anyway, so that's also going to play a big role in our decision. -evt From famz at hotmail.com Wed Sep 17 07:03:02 2008 From: famz at hotmail.com (Faisal Muzammil) Date: Wed, 17 Sep 2008 16:03:02 +0500 Subject: [c-nsp] cisco 7507 vs ssg 550 In-Reply-To: <67F7C1FAF83A074AA3520D8F155782A501DD1BEA@xmb-ams-331.emea.cisco.com> References: <67F7C1FAF83A074AA3520D8F155782A501DD1BEA@xmb-ams-331.emea.cisco.com> Message-ID: Thanks Arie. We will definetly take that inconsideration. > Subject: RE: [c-nsp] cisco 7507 vs ssg 550> Date: Wed, 17 Sep 2008 09:02:40 +0200> From: avayner at cisco.com> To: famz at hotmail.com; cisco-nsp at puck.nether.net> > Faisal,> > Why don't you take a look at a 7200/NPE-G2 (or even a 7201, which is a> 1RU version of it).> > http://www.cisco.com/en/US/products/hw/routers/ps341/index.html> http://www.cisco.com/en/US/prod/collateral/routers/ps341/product_data_sh> eet0900aecd8047177b.html> http://www.cisco.com/en/US/products/ps7253/index.html > > The advantage of changing to this kind of device is that it would be a> natural upgrade from 7500 (which is a very old model...). All the> configs should most likely transfer as a simple copy paste.> > Arie> > -----Original Message-----> From: cisco-nsp-bounces at puck.nether.net> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Faisal Muzammil> Sent: Tuesday, September 16, 2008 12:52 PM> To: cisco-nsp at puck.nether.net> Subject: [c-nsp] cisco 7507 vs ssg 550> > > Hi,> We have a cisco 7507 router for our wan and are thinking of replacing it> with juniper ssg 550. Currently we have 1 GEIP interface on the lan side> of 7507 and 1 POS(STM/OC3) interface on the wan side. We have a few IP> IP tunnels established and are running BGP over the wan and OSPF on the> lan side. We also have the need of using PBRs. The main reason behind> this change is that we are going to outgrow our STM capacity and need to> upgrade to higher bandwidth on the wan side. hence similarly we will> need to have a better option on the lan side instead of GEIP due to the> limitation of 200mbps aggregate throughput on it.> > Thanks in advance for your suggestions> > regards> Famz> > _________________________________________________________________> News, entertainment and everything you care about at Live.com. Get it> now!> http://www.live.com/getstarted.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/ _________________________________________________________________ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE From rodunn at cisco.com Wed Sep 17 07:59:53 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Wed, 17 Sep 2008 07:59:53 -0400 Subject: [c-nsp] SRC2? In-Reply-To: <48D003E4.7000005@isp.solcon.nl> References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <48A2FF3B.5030104@gatlan.nl> <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com> <48D003E4.7000005@isp.solcon.nl> Message-ID: <20080917115953.GD23151@rtp-cse-489.cisco.com> It's already fixed in SRC and SRB4. That bug was only an issue in SRA throttle. Have you tried SRB4? On Tue, Sep 16, 2008 at 09:07:16PM +0200, Rinse Kloek (Solcon) wrote: > We are also running in some bug ( CSCsk27643 ) and are hoping to see > this fixed in SRC2. Anybody some tips to get PBR using set vrf working > on a 12.2 release ? > > regards Rinse > cisco-nsp at puck.nether.net > >Hi All, > > > >On Wed, Aug 13, 2008 at 6:35 PM, Bas Roos wrote: > > > > > >>>Anyone know when 12.2(33)SRC2 is supposed to be released, specifically > >>>for the 7600. I had heard by the end of July, but so far no release. > >>> > > > > > >>The latest statement we got from them was end-september. > >> > > > >Anyone from Cisco perhaps would comment on this? > >CSCso45720 makes it really problematic to go into production stage > >with the SRC train. > > > >Cheers, > >-- > >Ran. > >_______________________________________________ > >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 paul at paulstewart.org Wed Sep 17 11:42:10 2008 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 17 Sep 2008 11:42:10 -0400 Subject: [c-nsp] Weird SSH/Scheduler Error Message-ID: <000001c918db$f4e6a330$deb3e990$@org> Anyone seen this before? Just starting showing up on a 7206VXR w/NPE-2G running Advanced Enterprise Version 12.4(20)T Sep 17 11:40:23: %SCHED-7-WATCH: Attempt to enqueue uninitialized watched queue (address 0). -Process= "SSH Process", ipl= 0, pid= 216, -Traceback= 0x14C4818 0x31F0B20 0x2E5F23C 0x2EBCBD8 0x2EA3058 0x28C858 0x15169C0 0x14D5798 0x14D5BC0 0x14D58B0 0x15418AC 0x1519AD4 0x1518C10 0x1545CA0 0x3AE4B2C 0x3AD069C Thanks, Paul From david.freedman at uk.clara.net Wed Sep 17 12:06:21 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 17 Sep 2008 17:06:21 +0100 Subject: [c-nsp] Cisco 12406 Etherchannel In-Reply-To: <47151.61434.qm@web44815.mail.sp1.yahoo.com> References: <47151.61434.qm@web44815.mail.sp1.yahoo.com> Message-ID: Yes, I've been waiting for link-agg on these SPA modules for AGES I don't even have any dates for when it will be available, its a major pain Use ECMP if you can... Dave,. Mark Tech wrote: > Hi > I am trying to configure Ethernchannel/link bundling on a 12406. The port channel seems to be accepted, however when I try and add a channel-group to my GE interfaces, it says its not supported? I am using SPA-10X1GE-V2 line cards with c12kprp-p-mz.120-32.SY6.bin IOS > > > interface Port-channel1 > ip address x.x.x.x 255.255.255.252 > no ip directed-broadcast > channel-group minimum active 1 > no channel-group bandwidth control-propagation > > router(config-if)#channel-group 1 > Error: not supported on GigabitEthernet0/0/0. > > Is there a way to bundle more that 1GE port on a 12406? > > Regards > > Mark > > > > > _______________________________________________ > 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 Sep 17 12:22:58 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 17 Sep 2008 17:22:58 +0100 Subject: [c-nsp] IS-IS for IPv6: Passive Loopback Interface Address Not Propagated In-Reply-To: <200809162245.53672.mtinka@globaltransit.net> References: <200809161433.40044.mtinka@globaltransit.net> <48CFA830.8070708@renater.fr> <200809162245.53672.mtinka@globaltransit.net> Message-ID: Yes, I came across this on an upgrade from SB to SRC1 on 7200 didn't work until I configured "ipv6 enable" and "ipv6 router isis" on the loopback and then I was able to backtrack and do "passive int lo0" in is-is to make it passive again, I thought it was just me! Dave. Mark Tinka wrote: > On Tuesday 16 September 2008 20:36:00 Frederic LOUI wrote: > >> My version is : IOS 124-11.T2 > > We haven't tested other releases on these boxes yet. > > 12.2(33)SXH3 does work on our SUP720-3BXL's, though. > >> Did you try ISIS debug command in order to see what's >> happening ? When you inject your loopback ? > > We did; nothing came up - all other interfaces are added > into IS-IS with the exception of the Loopbacks. > >> I record that there was some issues related to ISIS in >> multi-topology environment. > > Actually, we found MT very useful when dual-stacking v4 and > v6. > >> "metric style wide" command >> was needed... > > We use wide metrics by default on all our IS's. > >> and also the interface command "ipv6 enable" >> is sometimes mandatory. (depending on the IOS vesion) > > We haven't had to do this for our v6 deployment (even when I > run v6 under 12.3 mainline at my previous employer). > > However, we did try enabling this command without much > success in resolving this particular issue. > >> Please fin herewith this mail a snipset of config related >> to ISIS for IPv6: > > Pretty straight forward. > >> At the sounds like it is a issue with the IOS >> version. > > Agree. > > Will work it and hope TAC can reproduce the issue. > > Cheers, > > Mark. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Wed Sep 17 12:31:18 2008 From: justin at justinshore.com (Justin Shore) Date: Wed, 17 Sep 2008 11:31:18 -0500 Subject: [c-nsp] Weird SSH/Scheduler Error In-Reply-To: <000001c918db$f4e6a330$deb3e990$@org> References: <000001c918db$f4e6a330$deb3e990$@org> Message-ID: <48D130D6.8090004@justinshore.com> http://puck.nether.net/pipermail/cisco-nsp/2008-August/053776.html I ran into that traceback and some others when I upgraded to 20T. I ended up rolling back to 15T7. That actually caused me some problems too. On the 9-port HWIC I had a voice vlan configured on some devices that didn't need it (printers, standalone computers). Previously with the 9T that I was running (and every other IOS device on our network) it wouldn't matter. However with 15T7 having a voice vlan configured stopped the link from passing traffic. Anyway, I digress. Yes, I've seen weird tracebacks with 20T. SSH from SecureCRT was also broken by IOS SSH daemon changes. SCRT 6.1 fixed or worked around the issue. I don't know which party was at fault there. I'm going to wait for a 20T1 or later before I try it again. Justin Paul Stewart wrote: > Anyone seen this before? Just starting showing up on a 7206VXR w/NPE-2G > running Advanced Enterprise Version 12.4(20)T > > Sep 17 11:40:23: %SCHED-7-WATCH: Attempt to enqueue uninitialized watched > queue (address 0). -Process= "SSH Process", ipl= 0, pid= 216, -Traceback= > 0x14C4818 0x31F0B20 0x2E5F23C 0x2EBCBD8 0x2EA3058 0x28C858 0x15169C0 > 0x14D5798 0x14D5BC0 0x14D58B0 0x15418AC 0x1519AD4 0x1518C10 0x1545CA0 > 0x3AE4B2C 0x3AD069C > > Thanks, > > Paul > > > > _______________________________________________ > 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 masood at nexlinx.net.pk Wed Sep 17 13:47:18 2008 From: masood at nexlinx.net.pk (Masood Ahmad Shah) Date: Wed, 17 Sep 2008 22:47:18 +0500 Subject: [c-nsp] OT - 802.3an - 10Gig over Cat 6a In-Reply-To: <8B25B862BC09784B9B74FB950D4F64D406C949@qcnapp01.corp.qcn> References: <8B25B862BC09784B9B74FB950D4F64D406C949@qcnapp01.corp.qcn> Message-ID: <05b101c918ed$7331d050$599570f0$@net.pk> I would recommended Juniper MX or EX Switches; it's time to enjoy line rate along with stable network operating system (JUNOS) + application/services ( MPLS, VPLS, QiQ etc) :) Regards, Masood BLOG: http://www.weblogs.com.pk/jahil/ -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Brad Henshaw Sent: Tuesday, September 16, 2008 8:51 AM To: Simon Hamilton-Wilkes; cisco-nsp at puck.nether.net Cc: michael.balasco at cityofhenderson.com Subject: Re: [c-nsp] OT - 802.3an - 10Gig over Cat 6a Simon Hamilton-Wilkes wrote: > SMC Tigerswitch 10g is the only thing I can see out there, $23 K for 20 ports in 1U. Extreme also have the X650. Not sure about availability. Regards, Brad _______________________________________________ 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 Wed Sep 17 11:48:42 2008 From: awain567 at yahoo.com (Alex Wa) Date: Wed, 17 Sep 2008 08:48:42 -0700 (PDT) Subject: [c-nsp] boot sytem issue Message-ID: <120321.25267.qm@web58004.mail.re3.yahoo.com> helo guys, ? We ran into a problem with a 3570 switch. we are trying to update IOS, keeping the current as second option , it accepts both boot system commands but doesn't update running-config and overwrites the existing entry in bootvar. here is the command output ... ? ? Router(config)#boot system flash:c3750-ipbasek9-mz.122-44.SE2.bin?????????????????????? Router(config)# Router#sh boot BOOT path-list????? : flash:c3750-ipbasek9-mz.122-44.SE2.bin Config file???????? : flash:/config.text Private Config file : flash:/private-config.text Enable Break??????? : no Manual Boot???????? : no HELPER path-list??? : Auto upgrade??????? : yes Router(config)#boot system flash:c3750-ipbase-mz.122-25.SEB4/c3750-ipbase-mz.122-25.SEB4.bin Router#sh boot? BOOT path-list????? : flash:c3750-ipbase-mz.122-25.SEB4/c3750-ipbase-mz.122-25.SEB4.bin Config file???????? : flash:/config.text Private Config file : flash:/private-config.text Enable Break??????? : no Manual Boot???????? : no HELPER path-list??? : Auto upgrade??????? : yes ? any hint or suggestion? ? thanks in advance Alejandro wainshtok? ? From awain567 at yahoo.com Wed Sep 17 12:17:03 2008 From: awain567 at yahoo.com (Alex Wa) Date: Wed, 17 Sep 2008 09:17:03 -0700 (PDT) Subject: [c-nsp] boot sytem issue Message-ID: <842584.57794.qm@web58002.mail.re3.yahoo.com> helo guys, ? We ran into a problem with a 3570 switch. we are trying to update IOS, keeping the current as second option , it accepts both boot system commands but doesn't update running-config and overwrites the existing entry in bootvar. here is the command output ... ? ? Router(config)#boot system flash:c3750-ipbasek9-mz.122-44.SE2.bin?????????????????????? Router(config)# Router#sh boot BOOT path-list????? : flash:c3750-ipbasek9-mz.122-44.SE2.bin Config file???????? : flash:/config.text Private Config file : flash:/private-config.text Enable Break??????? : no Manual Boot???????? : no HELPER path-list??? : Auto upgrade??????? : yes Router(config)#boot system flash:c3750-ipbase-mz.122-25.SEB4/c3750-ipbase-mz.122-25.SEB4.bin Router#sh boot? BOOT path-list????? : flash:c3750-ipbase-mz.122-25.SEB4/c3750-ipbase-mz.122-25.SEB4.bin Config file???????? : flash:/config.text Private Config file : flash:/private-config.text Enable Break??????? : no Manual Boot???????? : no HELPER path-list??? : Auto upgrade??????? : yes ? any hint or suggestion? ? thanks in advance Alejandro wainshtok? ? From cisco-nsp at jacobsson.nu Wed Sep 17 13:52:38 2008 From: cisco-nsp at jacobsson.nu (Fredrik Jacobsson) Date: Wed, 17 Sep 2008 19:52:38 +0200 Subject: [c-nsp] boot sytem issue In-Reply-To: <120321.25267.qm@web58004.mail.re3.yahoo.com> References: <120321.25267.qm@web58004.mail.re3.yahoo.com> Message-ID: <940dabcc0809171052i5756fe6cs4baa9d2fddd950e7@mail.gmail.com> You might need to specify both boot-files on the same row. I think they should be separated by a semicolon, just do a "?" to verify. boot system flash flash:/first-option;flash:/second-option Regards /Fredrik 2008/9/17, Alex Wa : > helo guys, > > We ran into a problem with a 3570 switch. we are trying to update IOS, keeping the current as second option , it accepts both boot system commands but doesn't update running-config and overwrites the existing entry in bootvar. here is the command output ... > > > Router(config)#boot system flash:c3750-ipbasek9-mz.122-44.SE2.bin > Router(config)# > Router#sh boot > BOOT path-list : flash:c3750-ipbasek9-mz.122-44.SE2.bin > Config file : flash:/config.text > Private Config file : flash:/private-config.text > Enable Break : no > Manual Boot : no > HELPER path-list : > Auto upgrade : yes > > Router(config)#boot system flash:c3750-ipbase-mz.122-25.SEB4/c3750-ipbase-mz.122-25.SEB4.bin > Router#sh boot > BOOT path-list : flash:c3750-ipbase-mz.122-25.SEB4/c3750-ipbase-mz.122-25.SEB4.bin > Config file : flash:/config.text > Private Config file : flash:/private-config.text > Enable Break : no > Manual Boot : no > HELPER path-list : > Auto upgrade : yes > > any hint or suggestion? > > thanks in advance > Alejandro wainshtok > > > > > _______________________________________________ > 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 masood at nexlinx.net.pk Wed Sep 17 16:47:54 2008 From: masood at nexlinx.net.pk (Masood Ahmad Shah) Date: Thu, 18 Sep 2008 01:47:54 +0500 Subject: [c-nsp] cisco 7507 vs ssg 550 In-Reply-To: <67F7C1FAF83A074AA3520D8F155782A501DD1BEA@xmb-ams-331.emea.cisco.com> References: <67F7C1FAF83A074AA3520D8F155782A501DD1BEA@xmb-ams-331.emea.cisco.com> Message-ID: <05eb01c91906$aef2b690$0cd823b0$@net.pk> You can't replace Cisco 7500 with SSG550 (Firewall); Coz POS (OC3) is currently not available for SSG platform; Second SSG can run screenos only not JUNOS; screenos is the operating system for integrated Firewall/IPSec VPN solutions. Third SSG purpose-built security appliance, I would definitely not recommend SSG. T1, E1, Serial, DS3, Fe and SFP (copper or fiber) the only available interfaces for SSG devices. I would also recommend not replacing 7500 with just another idiot 7200 (software router, policy (route-maps), access-list, tunnels or a simple debugging will "hang up" the router). If you really need Gig throughput along with tunnels and policy routing; you need to consider line/wire rate router; it can be Cisco 76XX (be careful while selecting modules) or all juniper M/T Series routers along with AS PIC (go 4 M7i or M10i). Regards, Masood -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Arie Vayner (avayner Sent: Wednesday, September 17, 2008 12:03 PM To: Faisal Muzammil; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] cisco 7507 vs ssg 550 Faisal, Why don't you take a look at a 7200/NPE-G2 (or even a 7201, which is a 1RU version of it). http://www.cisco.com/en/US/products/hw/routers/ps341/index.html http://www.cisco.com/en/US/prod/collateral/routers/ps341/product_data_sh eet0900aecd8047177b.html http://www.cisco.com/en/US/products/ps7253/index.html The advantage of changing to this kind of device is that it would be a natural upgrade from 7500 (which is a very old model...). All the configs should most likely transfer as a simple copy paste. Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Faisal Muzammil Sent: Tuesday, September 16, 2008 12:52 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] cisco 7507 vs ssg 550 Hi, We have a cisco 7507 router for our wan and are thinking of replacing it with juniper ssg 550. Currently we have 1 GEIP interface on the lan side of 7507 and 1 POS(STM/OC3) interface on the wan side. We have a few IP IP tunnels established and are running BGP over the wan and OSPF on the lan side. We also have the need of using PBRs. The main reason behind this change is that we are going to outgrow our STM capacity and need to upgrade to higher bandwidth on the wan side. hence similarly we will need to have a better option on the lan side instead of GEIP due to the limitation of 200mbps aggregate throughput on it. Thanks in advance for your suggestions regards Famz _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.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/ _______________________________________________ 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 rinse.kloek at isp.solcon.nl Wed Sep 17 15:59:19 2008 From: rinse.kloek at isp.solcon.nl (Rinse Kloek (Solcon)) Date: Wed, 17 Sep 2008 21:59:19 +0200 Subject: [c-nsp] SRC2? In-Reply-To: <20080917115953.GD23151@rtp-cse-489.cisco.com> References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <48A2FF3B.5030104@gatlan.nl> <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com> <48D003E4.7000005@isp.solcon.nl> <20080917115953.GD23151@rtp-cse-489.cisco.com> Message-ID: <48D16197.2080302@isp.solcon.nl> I tried this feature on a 7200 with SRC1 (also on SB6). (SRB does not run on 7200). regards Rinse Rodney Dunn schreef: > It's already fixed in SRC and SRB4. > > That bug was only an issue in SRA throttle. > > Have you tried SRB4? > > On Tue, Sep 16, 2008 at 09:07:16PM +0200, Rinse Kloek (Solcon) wrote: > >> We are also running in some bug ( CSCsk27643 ) and are hoping to see >> this fixed in SRC2. Anybody some tips to get PBR using set vrf working >> on a 12.2 release ? >> >> regards Rinse >> cisco-nsp at puck.nether.net >> >>> Hi All, >>> >>> On Wed, Aug 13, 2008 at 6:35 PM, Bas Roos wrote: >>> >>> >>> >>>>> Anyone know when 12.2(33)SRC2 is supposed to be released, specifically >>>>> for the 7600. I had heard by the end of July, but so far no release. >>>>> >>>>> >>> >>> >>>> The latest statement we got from them was end-september. >>>> >>>> >>> Anyone from Cisco perhaps would comment on this? >>> CSCso45720 makes it really problematic to go into production stage >>> with the SRC train. >>> >>> Cheers, >>> -- >>> Ran. >>> _______________________________________________ >>> 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 tvarriale at comcast.net Wed Sep 17 17:41:59 2008 From: tvarriale at comcast.net (Tony Varriale) Date: Wed, 17 Sep 2008 16:41:59 -0500 Subject: [c-nsp] OT - 802.3an - 10Gig over Cat 6a References: <8B25B862BC09784B9B74FB950D4F64D406C949@qcnapp01.corp.qcn> <05b101c918ed$7331d050$599570f0$@net.pk> Message-ID: <002601c9190e$379ea470$0100fea9@flamadam> How are the multicast issues doing on the Juniper platforms? tv ----- Original Message ----- From: "Masood Ahmad Shah" To: "'Brad Henshaw'" ; "'Simon Hamilton-Wilkes'" ; Cc: Sent: Wednesday, September 17, 2008 12:47 PM Subject: Re: [c-nsp] OT - 802.3an - 10Gig over Cat 6a >I would recommended Juniper MX or EX Switches; it's time to enjoy line rate > along with stable network operating system (JUNOS) + application/services > ( > MPLS, VPLS, QiQ etc) :) > > > Regards, > Masood > BLOG: http://www.weblogs.com.pk/jahil/ > > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Brad Henshaw > Sent: Tuesday, September 16, 2008 8:51 AM > To: Simon Hamilton-Wilkes; cisco-nsp at puck.nether.net > Cc: michael.balasco at cityofhenderson.com > Subject: Re: [c-nsp] OT - 802.3an - 10Gig over Cat 6a > > Simon Hamilton-Wilkes wrote: > >> SMC Tigerswitch 10g is the only thing I can see out there, $23 K for > 20 ports in 1U. > > Extreme also have the X650. Not sure about availability. > > Regards, > Brad > _______________________________________________ > 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 jay at west.net Wed Sep 17 18:09:36 2008 From: jay at west.net (Jay Hennigan) Date: Wed, 17 Sep 2008 15:09:36 -0700 Subject: [c-nsp] 5350XM ip-ip gateway problem handling 302 message Message-ID: <48D18020.7050401@west.net> Scenario: AS5350XM running 12.4.15(T)7 with UBE (ip-ip gateway) code. This box is acting as a gateway supporting PRI trunks, a hosted VOIP provider, and some users connected by IP with SIP IADs. The hosted VoIP provider uses a hostname as the SIP peer for load-balancing and redundancy. When it receives an INVITE, it returns a 302 redirecting the call to a contact of the IP address of the actual gateway for that call. Calls from the PRI trunks to the 5350 properly handle the 302 and send a second INVITE to the IP, the call completes normally. Calls originating from a SIP IAD (sip-to-sip) go through the same initial scenario, but the 5350 fails to honor the 302 and sends another INVITE to the hostname, resulting in another 302, looping and not completing. I can't find anything in bug tool, have tried several options under the voice service voip config section with no luck. Anyone else seen this or have any ideas? -- 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 dancaescu at yahoo.com Wed Sep 17 19:14:33 2008 From: dancaescu at yahoo.com (Dan Caescu) Date: Wed, 17 Sep 2008 16:14:33 -0700 (PDT) Subject: [c-nsp] lots of flushes on interface Message-ID: <602065.49123.qm@web50402.mail.re2.yahoo.com> Hello, I'm trying to sort this out somehow but don't know where the problem is: The router is a 3845, ip cef enabled : C22#sh int gi0/0 | inc Input Input queue: 22/2000/0/3609 (size/max/drops/flushes); Total output drops: 0 C22# interface GigabitEthernet0/0 ip address xxx.xxx.xxx.xx3 255.255.255.0 ip route-cache same-interface duplex auto speed auto media-type rj45 h323-gateway voip interface h323-gateway voip id XXXXXXXXXXXXXXXXX h323-gateway voip h323-id XXXXXXXXXXXXXX hold-queue 2000 in end Interface stats: GigabitEthernet0/0 Switching path Pkts In Chars In Pkts Out Chars Out Processor 1309875 253342315 67166 28730186 Route cache 1697741 308082616 1679201 327736640 Total 3007616 561424931 1746367 356466826 C22#sh int gi0/0 switching GigabitEthernet0/0 C22 Throttle count 1398209 Drops RP 1766888 SP 0 SPD Flushes Fast 62028 SSE 0 SPD Aggress Fast 0 SPD Priority Inputs 524905 Drops 0 Protocol IP Switching path Pkts In Chars In Pkts Out Chars Out Process 35066884 2288987921 2420143 756779814 Cache misses 0 - - - Fast 208387831 736889555 204015502 3215606163 Auton/SSE 0 0 0 0 C22#show processes CPU | i ^PID|Input 18 31380 509095 61 0.00% 0.00% 0.00% 0 ARP Input 47 360 14736 24 0.00% 0.00% 0.00% 0 Net Input 102 2492796 25994107 95 9.66% 8.13% 8.88% 0 IP Input 156 0 2 0 0.00% 0.00% 0.00% 0 ATM OAM Input 159 0 1 0 0.00% 0.00% 0.00% 0 RARP Input Any ideeas? Dan From brett at looney.id.au Wed Sep 17 18:35:19 2008 From: brett at looney.id.au (Brett Looney) Date: Thu, 18 Sep 2008 06:35:19 +0800 Subject: [c-nsp] Voice VLAN oddity (was Weird SSH/Scheduler Error) In-Reply-To: <48D130D6.8090004@justinshore.com> References: <000001c918db$f4e6a330$deb3e990$@org> <48D130D6.8090004@justinshore.com> Message-ID: <001501c91915$b73bd890$25b389b0$@id.au> > I ran into that traceback and some others when I upgraded to 20T. > I ended up rolling back to 15T7. That actually caused me some > problems too. On the 9-port HWIC I had a voice vlan configured > on some devices that didn't need it (printers, standalone > computers). Previously with the 9T that I was running (and > every other IOS device on our network) it wouldn't matter. > However with 15T7 having a voice vlan configured stopped the > link from passing traffic. Yup, I've seen that too on a few different types of devices - most notable routers with embedded switch ports. My solution ATM is to configure the port as a trunk port as well as configuring the voice VLAN. B. From Loc.Pham at ucsfmedctr.org Wed Sep 17 19:21:03 2008 From: Loc.Pham at ucsfmedctr.org (Pham, Loc) Date: Wed, 17 Sep 2008 16:21:03 -0700 Subject: [c-nsp] Got this error on console today !!! 6506-SUP720. Message-ID: <81EB7EB41E41834BA4C9EDE1F56980A30305303F@exmcb03.ucsfmedicalcenter.org> Failed to read process memory of sbin/pcmcia_driver.proc Failed to read process memory of sbin/bflash_driver.proc Failed to read process memory of sbin/mqueue Failed to read process memory of sbin/flashfs_hes.proc Failed to read process memory of sbin/dfs_bootdisk.proc Failed to read process memory of sbin/ldcache.proc Failed to read process memory of sbin/watchdog.proc Failed to read process memory of sbin/syslogd.proc Failed to read process memory of sbin/name_svr.proc Failed to read process memory of sbin/wdsysmon.proc XXXXX-test #sh ver | inc IOS Cisco IOS Software, s72033_rp Software (s72033_rp-IPSERVICESK9_WAN-VM), Version 12.2(33)SXH3, RELEASE SOFTWARE (fc1) Regards, Loc Pham, CCIE # 17030 - Sr. Network Staff, IT Network Architecture & Security, UCSF Medical Center From jonvoip at gmail.com Wed Sep 17 20:14:30 2008 From: jonvoip at gmail.com (Jonathan Charles) Date: Wed, 17 Sep 2008 19:14:30 -0500 Subject: [c-nsp] Using generic Compact Flash in Cisco Routers... Message-ID: <5d093f9a0809171714s23ba6f7ck9f04a3112fac0850@mail.gmail.com> So, does it work? Jonathan From jared at puck.nether.net Wed Sep 17 20:26:39 2008 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 17 Sep 2008 20:26:39 -0400 Subject: [c-nsp] Using generic Compact Flash in Cisco Routers... In-Reply-To: <5d093f9a0809171714s23ba6f7ck9f04a3112fac0850@mail.gmail.com> References: <5d093f9a0809171714s23ba6f7ck9f04a3112fac0850@mail.gmail.com> Message-ID: <20080918002638.GB18592@puck.nether.net> On Wed, Sep 17, 2008 at 07:14:30PM -0500, Jonathan Charles wrote: > So, does it work? In general, yes. Some cards do not work properly depending on software/hardware combinations. YMMV. I recommend testing to validate your cards work in your environment. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From mtinka at globaltransit.net Wed Sep 17 21:36:00 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 18 Sep 2008 09:36:00 +0800 Subject: [c-nsp] OT - 802.3an - 10Gig over Cat 6a In-Reply-To: <05b101c918ed$7331d050$599570f0$@net.pk> References: <8B25B862BC09784B9B74FB950D4F64D406C949@qcnapp01.corp.qcn> <05b101c918ed$7331d050$599570f0$@net.pk> Message-ID: <200809180936.01328.mtinka@globaltransit.net> On Thursday 18 September 2008 01:47:18 Masood Ahmad Shah wrote: > I would recommended Juniper MX or EX Switches; it's time > to enjoy line rate along with stable network operating > system (JUNOS) + application/services ( MPLS, VPLS, QiQ > etc) :) Juniper's EX-series won't do MPLS (and it's associated features). 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 Wed Sep 17 21:43:52 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 18 Sep 2008 09:43:52 +0800 Subject: [c-nsp] IS-IS for IPv6: Passive Loopback Interface Address Not Propagated In-Reply-To: References: <200809161433.40044.mtinka@globaltransit.net> <200809162245.53672.mtinka@globaltransit.net> Message-ID: <200809180943.53187.mtinka@globaltransit.net> On Thursday 18 September 2008 00:22:58 David Freedman wrote: > Yes, I came across this on an upgrade from SB to SRC1 on > 7200 didn't work until I configured "ipv6 enable" and > "ipv6 router isis" on the loopback and then I was able to > backtrack and do "passive int lo0" in is-is to make it > passive again, Right, because, in IOS, explicitly enabling IS-IS processing on an interface configured as passive under IS-IS effectively disables the passive-ness of said interface. Actually, TAC managed to locate a bug ID for this issue: CSCsm64643 (IPv6 passive interface address not in the isis database). Thing is, this was first discovered in SRC on the RSP720, but fixed in SRC1. I suspect the fix was made and tested on the RSP720, and not the 7200, as TAC have received other reports from customers running SRC1 about this issue on the 7200's. If TAC do confirm it's a bug, unlikely a fix will make it into SRC2. We'd be looking at SRC3 - so workarounds until then. 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 paul at paulstewart.org Wed Sep 17 22:24:43 2008 From: paul at paulstewart.org (Paul Stewart) Date: Wed, 17 Sep 2008 22:24:43 -0400 Subject: [c-nsp] Static Route based on next hop reachable Message-ID: <004901c91935$bdd16e70$39744b50$@org> Hi there.. This is a bit of a long story .. But what we are looking for is to create a static route only if the next hop is reachable and directly connected. is this possible? I seem to remember there is a way to do this via IP SLA statements where if a condition is met then do X Can anyone enlighten me on this? We have some clients connecting via PPPOE to a 7206VXR but now want to move towards load balancing where the client could connect to multiple devices in a round robin format. The more obvious answer would be to create the routes via Radius but this has proven difficult due to a proprietary system in use to create the radius users file. Thanks, Paul From ariemer at wesenergy.com.au Wed Sep 17 22:39:41 2008 From: ariemer at wesenergy.com.au (Aaron Riemer) Date: Thu, 18 Sep 2008 10:39:41 +0800 Subject: [c-nsp] Static Route based on next hop reachable In-Reply-To: <004901c91935$bdd16e70$39744b50$@org> References: <004901c91935$bdd16e70$39744b50$@org> Message-ID: <0867622C64B50C4B878AB45C95F43F11061B944C@MAILWA01.wesenergy.local> Hi Paul, Take a look at Policy based routing with object tracking. http://www.cisco.com/en/US/tech/tk364/technologies_configuration_example 09186a0080211f5c.shtml Cheers, Aaron -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Paul Stewart Sent: Thursday, 18 September 2008 10:25 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Static Route based on next hop reachable Hi there.. This is a bit of a long story .. But what we are looking for is to create a static route only if the next hop is reachable and directly connected. is this possible? I seem to remember there is a way to do this via IP SLA statements where if a condition is met then do X Can anyone enlighten me on this? We have some clients connecting via PPPOE to a 7206VXR but now want to move towards load balancing where the client could connect to multiple devices in a round robin format. The more obvious answer would be to create the routes via Radius but this has proven difficult due to a proprietary system in use to create the radius users file. Thanks, Paul _______________________________________________ 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/ LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From gkg at gmx.de Thu Sep 18 02:04:30 2008 From: gkg at gmx.de (Garry) Date: Thu, 18 Sep 2008 08:04:30 +0200 Subject: [c-nsp] Using generic Compact Flash in Cisco Routers... In-Reply-To: <5d093f9a0809171714s23ba6f7ck9f04a3112fac0850@mail.gmail.com> References: <5d093f9a0809171714s23ba6f7ck9f04a3112fac0850@mail.gmail.com> Message-ID: <48D1EF6E.1010503@gmx.de> Jonathan Charles wrote: > So, does it work? > Short answer: Yes Long Answer: May depend on your HW (both Router and CF cards) - For several 3825 and 7200 NPE-G1 I've bought some (more or less) no-name (they're called "extreMEmory") 1GB cards, they seem to work just fine ... With the low prices they usually go for, just get one or two, plug 'em in and see if they work for you ... fill 'em up, boot a couple times, and see if the IOS loads ... it has checksums, so if there's a problem, it should notice it during boot ... -gg From zivl at gilat.net Thu Sep 18 02:48:40 2008 From: zivl at gilat.net (Ziv Leyes) Date: Thu, 18 Sep 2008 09:48:40 +0300 Subject: [c-nsp] Static Route based on next hop reachable In-Reply-To: <0867622C64B50C4B878AB45C95F43F11061B944C@MAILWA01.wesenergy.local> References: <004901c91935$bdd16e70$39744b50$@org> <0867622C64B50C4B878AB45C95F43F11061B944C@MAILWA01.wesenergy.local> Message-ID: Hi Paul, This is the most simple and straight forward example, no need to use PBR or anything else. I use this for routing traffic through management tunnels based on reachability of the next hop. ip sla monitor 1 type echo protocol ipIcmpEcho 1.1.1.1 timeout 3000 track 1 rtr 1 reachability ip route 2.2.2.2 255.255.255.0 1.1.1.1 track 1 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 Aaron Riemer Sent: Thursday, September 18, 2008 5:40 AM To: Paul Stewart; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Static Route based on next hop reachable Hi Paul, Take a look at Policy based routing with object tracking. http://www.cisco.com/en/US/tech/tk364/technologies_configuration_example 09186a0080211f5c.shtml Cheers, Aaron -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Paul Stewart Sent: Thursday, 18 September 2008 10:25 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Static Route based on next hop reachable Hi there.. This is a bit of a long story .. But what we are looking for is to create a static route only if the next hop is reachable and directly connected. is this possible? I seem to remember there is a way to do this via IP SLA statements where if a condition is met then do X Can anyone enlighten me on this? We have some clients connecting via PPPOE to a 7206VXR but now want to move towards load balancing where the client could connect to multiple devices in a round robin format. The more obvious answer would be to create the routes via Radius but this has proven difficult due to a proprietary system in use to create the radius users file. Thanks, Paul _______________________________________________ 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/ LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ 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 vikassharmas at gmail.com Thu Sep 18 04:08:49 2008 From: vikassharmas at gmail.com (Vikas Sharma) Date: Thu, 18 Sep 2008 13:38:49 +0530 Subject: [c-nsp] police rate percent vs. police CIR percent Message-ID: Hi, Need help to understand the difference between these commands, I searched the net, but could not find the difference. 1- police rate percent 2- police CIR percent Regards, Vikas Sharma From Zoeteweij at carrier2carrier.com Thu Sep 18 05:19:25 2008 From: Zoeteweij at carrier2carrier.com (Mike Zoeteweij) Date: Thu, 18 Sep 2008 11:19:25 +0200 Subject: [c-nsp] Strange VPN problem Message-ID: <42F0C766A9A8DB47B5E86CA64738DC8B0148C0E4@bilbo.bdhz.c2c.local> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Guys, We've quite a few VPN running to different customers location on multiple routers. They all work fine but with one of the we are from time to time experiencing problems. For whatever reason the VPN goes down and does not come up unless I reset the router itself. All the clear crypto commands do not seem to work Unfortunately I do not have access to the remote ASA we use a 2801 with a crypto map on the nat outside interface. The only thing I've not tried so far is re-enter the pre-shared keys. But that also does not explain why the VPN goes down in the first place. It really happens on a irregular basis. Sometimes is happens twice a week and sometimes we are without problems for a over half a year. It looks like the problem is in the ISAKMP see attached debugging. Does anybody have any idea what is causing this issue? Regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFI0h0dwyjwCtsMkuMRAsJ6AKCk31AHy/gU1SvyzWWWFMkIQNiqJgCbB016 aB8Jr/90F6/eh6nrfJGtIyo= =mLuQ -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vpn_debugging.txt URL: From tdurack at gmail.com Thu Sep 18 08:15:38 2008 From: tdurack at gmail.com (Tim Durack) Date: Thu, 18 Sep 2008 08:15:38 -0400 Subject: [c-nsp] Using generic Compact Flash in Cisco Routers... In-Reply-To: <48D1EF6E.1010503@gmx.de> References: <5d093f9a0809171714s23ba6f7ck9f04a3112fac0850@mail.gmail.com> <48D1EF6E.1010503@gmx.de> Message-ID: <9e246b4d0809180515nfe48c6fnb0bd19a23af364d7@mail.gmail.com> My recent experience with a selection of SUP720-3B and VS-S720-10G-3C suggest it is hit-n-miss. Some CF that worked in all of the VS-S720s would not work in the SUP720s. My investigation suggested it is down to the Manufacturer ID burned on the CF. If the SUP recognizes that ID as a valid CF, you are good to go. If not the card won't even be recognized. I have had mixed success with Kingston - old cards work fine, newer cards have a "Kingston" ID which the SUP720 doesn't recognise. Generic cards seem to work, as they usually program some known ID, like Toshiba. So buy a bunch and see what works. Tim:> On Thu, Sep 18, 2008 at 2:04 AM, Garry wrote: > Jonathan Charles wrote: > > So, does it work? > > > Short answer: Yes > > Long Answer: May depend on your HW (both Router and CF cards) - For > several 3825 and 7200 NPE-G1 I've bought some (more or less) no-name > (they're called "extreMEmory") 1GB cards, they seem to work just fine ... > > With the low prices they usually go for, just get one or two, plug 'em > in and see if they work for you ... fill 'em up, boot a couple times, > and see if the IOS loads ... it has checksums, so if there's a problem, > it should notice it during boot ... > > -gg > _______________________________________________ > 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 techconfig at yahoo.com Thu Sep 18 09:38:34 2008 From: techconfig at yahoo.com (Mark Tech) Date: Thu, 18 Sep 2008 06:38:34 -0700 (PDT) Subject: [c-nsp] Cisco 12406 Etherchannel Message-ID: <936800.45916.qm@web44812.mail.sp1.yahoo.com> Hi After rechecking I have upgraded to c12kprp-p-mz.120-33.S1 Now Link Bundling is working Regards Mark ----- Original Message ---- From: David Freedman To: cisco-nsp at puck.nether.net Sent: Wednesday, September 17, 2008 5:06:21 PM Subject: Re: [c-nsp] Cisco 12406 Etherchannel Yes, I've been waiting for link-agg on these SPA modules for AGES I don't even have any dates for when it will be available, its a major pain Use ECMP if you can... Dave,. Mark Tech wrote: > Hi > I am trying to configure Ethernchannel/link bundling on a 12406. The port channel seems to be accepted, however when I try and add a channel-group to my GE interfaces, it says its not supported? I am using SPA-10X1GE-V2 line cards with c12kprp-p-mz.120-32.SY6.bin IOS > > > interface Port-channel1 >? ip address x.x.x..x 255.255.255.252 >? no ip directed-broadcast >? channel-group minimum active 1 >? no channel-group bandwidth control-propagation > > router(config-if)#channel-group 1 > Error: not supported on GigabitEthernet0/0/0. > > Is there a way to bundle more that 1GE port on a 12406? > > Regards > >? Mark > > > >? ? ? > _______________________________________________ > 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 Thu Sep 18 10:02:27 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Thu, 18 Sep 2008 15:02:27 +0100 Subject: [c-nsp] Cisco 12406 Etherchannel In-Reply-To: <936800.45916.qm@web44812.mail.sp1.yahoo.com> References: <936800.45916.qm@web44812.mail.sp1.yahoo.com> Message-ID: <48D25F73.9030006@uk.clara.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh, the release notes (http://www.cisco.com/en/US/docs/ios/12_0s/release/ntes/120SNEWF.html) make no mention of the SPA-10X1GE-V2 being supported in (S), I thought you needed SY? Dave. Mark Tech wrote: > Hi > After rechecking I have upgraded to c12kprp-p-mz.120-33.S1 > Now Link Bundling is working > > Regards > > Mark > > > > > ----- Original Message ---- > From: David Freedman > To: cisco-nsp at puck.nether.net > Sent: Wednesday, September 17, 2008 5:06:21 PM > Subject: Re: [c-nsp] Cisco 12406 Etherchannel > > Yes, I've been waiting for link-agg on these SPA modules for AGES > > I don't even have any dates for when it will be available, its a major pain > > Use ECMP if you can... > > Dave,. > > > Mark Tech wrote: >> Hi >> I am trying to configure Ethernchannel/link bundling on a 12406. The port channel seems to be accepted, however when I try and add a channel-group to my GE interfaces, it says its not supported? I am using SPA-10X1GE-V2 line cards with c12kprp-p-mz.120-32.SY6.bin IOS >> >> >> interface Port-channel1 >> ip address x.x.x..x 255.255.255.252 >> no ip directed-broadcast >> channel-group minimum active 1 >> no channel-group bandwidth control-propagation >> >> router(config-if)#channel-group 1 >> Error: not supported on GigabitEthernet0/0/0. >> >> Is there a way to bundle more that 1GE port on a 12406? >> >> Regards >> >> Mark >> >> >> >> >> _______________________________________________ >> 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/ > > > > - -- David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI0l9ztFWeqpgEZrIRAtXcAJ9+pq4DKlKJI2Kr9S0qw0N1XAYp4ACghuaz 10mNpXuaVy4pgulMXy1a4Yo= =tC2o -----END PGP SIGNATURE----- From rodunn at cisco.com Thu Sep 18 12:11:06 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Thu, 18 Sep 2008 12:11:06 -0400 Subject: [c-nsp] SRC2? In-Reply-To: <48D16197.2080302@isp.solcon.nl> References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <48A2FF3B.5030104@gatlan.nl> <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com> <48D003E4.7000005@isp.solcon.nl> <20080917115953.GD23151@rtp-cse-489.cisco.com> <48D16197.2080302@isp.solcon.nl> Message-ID: <20080918161106.GH4819@rtp-cse-489.cisco.com> What I'm saying is if you are seeing the problem on SRC1 it can't be CSCsk27643. On Wed, Sep 17, 2008 at 09:59:19PM +0200, Rinse Kloek (Solcon) wrote: > I tried this feature on a 7200 with SRC1 (also on SB6). (SRB does not > run on 7200). > > regards Rinse > > Rodney Dunn schreef: > >It's already fixed in SRC and SRB4. > > > >That bug was only an issue in SRA throttle. > > > >Have you tried SRB4? > > > >On Tue, Sep 16, 2008 at 09:07:16PM +0200, Rinse Kloek (Solcon) wrote: > > > >>We are also running in some bug ( CSCsk27643 ) and are hoping to see > >>this fixed in SRC2. Anybody some tips to get PBR using set vrf working > >>on a 12.2 release ? > >> > >>regards Rinse > >>cisco-nsp at puck.nether.net > >> > >>>Hi All, > >>> > >>>On Wed, Aug 13, 2008 at 6:35 PM, Bas Roos wrote: > >>> > >>> > >>> > >>>>>Anyone know when 12.2(33)SRC2 is supposed to be released, specifically > >>>>>for the 7600. I had heard by the end of July, but so far no release. > >>>>> > >>>>> > >>> > >>> > >>>>The latest statement we got from them was end-september. > >>>> > >>>> > >>>Anyone from Cisco perhaps would comment on this? > >>>CSCso45720 makes it really problematic to go into production stage > >>>with the SRC train. > >>> > >>>Cheers, > >>>-- > >>>Ran. > >>>_______________________________________________ > >>>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 rodunn at cisco.com Thu Sep 18 12:12:24 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Thu, 18 Sep 2008 12:12:24 -0400 Subject: [c-nsp] lots of flushes on interface In-Reply-To: <602065.49123.qm@web50402.mail.re2.yahoo.com> References: <602065.49123.qm@web50402.mail.re2.yahoo.com> Message-ID: <20080918161224.GI4819@rtp-cse-489.cisco.com> config t no spd enable end sh buff input-interface gig 0/0 packet decode the packets and see what they are and why they are not CEF switched throught he box. I suspect it's got to do with that h32 type configuration. On Wed, Sep 17, 2008 at 04:14:33PM -0700, Dan Caescu wrote: > Hello, > I'm trying to sort this out somehow but don't know where the problem is: > > The router is a 3845, ip cef enabled : > > C22#sh int gi0/0 | inc Input > Input queue: 22/2000/0/3609 (size/max/drops/flushes); Total output drops: 0 > C22# > > interface GigabitEthernet0/0 > ip address xxx.xxx.xxx.xx3 255.255.255.0 > ip route-cache same-interface > duplex auto > speed auto > media-type rj45 > h323-gateway voip interface > h323-gateway voip id XXXXXXXXXXXXXXXXX > h323-gateway voip h323-id XXXXXXXXXXXXXX > hold-queue 2000 in > end > > Interface stats: > GigabitEthernet0/0 > Switching path Pkts In Chars In Pkts Out Chars Out > Processor 1309875 253342315 67166 28730186 > Route cache 1697741 308082616 1679201 327736640 > Total 3007616 561424931 1746367 356466826 > > C22#sh int gi0/0 switching > GigabitEthernet0/0 C22 > Throttle count 1398209 > Drops RP 1766888 SP 0 > SPD Flushes Fast 62028 SSE 0 > SPD Aggress Fast 0 > SPD Priority Inputs 524905 Drops 0 > > Protocol IP > Switching path Pkts In Chars In Pkts Out Chars Out > Process 35066884 2288987921 2420143 756779814 > Cache misses 0 - - - > Fast 208387831 736889555 204015502 3215606163 > Auton/SSE 0 0 0 0 > > > C22#show processes CPU | i ^PID|Input > 18 31380 509095 61 0.00% 0.00% 0.00% 0 ARP Input > 47 360 14736 24 0.00% 0.00% 0.00% 0 Net Input > 102 2492796 25994107 95 9.66% 8.13% 8.88% 0 IP Input > 156 0 2 0 0.00% 0.00% 0.00% 0 ATM OAM Input > 159 0 1 0 0.00% 0.00% 0.00% 0 RARP Input > > > Any ideeas? > > Dan > > > > > _______________________________________________ > 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 daldworth at teliax.com Thu Sep 18 14:43:19 2008 From: daldworth at teliax.com (David Aldworth) Date: Thu, 18 Sep 2008 12:43:19 -0600 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI Message-ID: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> We are looking for a fully channelized OC3 interface for a Cisco 7200 VXR. Something that we can break individual T1's off of. In researching this there are two routes: PA-POS-1OC3 or PA-A3-OC3SMI. The first is SONET and the second is ATM. Other than price what is the difference? Which is needed? Thanks for any and all advice. David From djweis at internetsolver.com Thu Sep 18 14:50:55 2008 From: djweis at internetsolver.com (Dave Weis) Date: Thu, 18 Sep 2008 13:50:55 -0500 (CDT) Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> Message-ID: On Thu, 18 Sep 2008, David Aldworth wrote: > We are looking for a fully channelized OC3 interface for a Cisco 7200 VXR. > Something that we can break individual T1's off of. In researching this there > are two routes: PA-POS-1OC3 or PA-A3-OC3SMI. The first is SONET and the > second is ATM. I am pretty sure that the PA-A3-OC3SMI won't do any channelization, it's a clear channel ATM OC3. -- Dave Weis djweis at internetsolver.com http://www.internetsolver.com/ From streiner at cluebyfour.org Thu Sep 18 14:58:46 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 18 Sep 2008 14:58:46 -0400 (EDT) Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> Message-ID: On Thu, 18 Sep 2008, David Aldworth wrote: > We are looking for a fully channelized OC3 interface for a Cisco 7200 VXR. > Something that we can break individual T1's off of. In researching this there > are two routes: PA-POS-1OC3 or PA-A3-OC3SMI. The first is SONET and the > second is ATM. > > Other than price what is the difference? Which is needed? I don't believe either interface supports anything other than concatenated operation, i.e. a full 155 Mb/s interface; you can't break the OC3 into its component STS slots to break out DS3, CT3, T1, etc... Also, the interface you'd buy would be determined by the transport type. A POS OC3 interface might be able to physicall terminate a ATM OC3, but it won't be able do any of the ATM stuff. jms From dcp at dcptech.com Thu Sep 18 15:06:09 2008 From: dcp at dcptech.com (David Prall) Date: Thu, 18 Sep 2008 15:06:09 -0400 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> Message-ID: <009401c919c1$9c661c90$1dfe200a@cisco.com> I'm pretty sure this is how it would be. You would need a frame-relay switch in front of the POS interface, it isn't a CHOC interface. The ATM would need an ATM switch in front of it to support ATM T1's. There is a PA-MC-2T3+ that is channelized for the 7200. With this you could put a MUX in front of it. David -- http://dcp.dcptech.com > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Aldworth > Sent: Thursday, September 18, 2008 2:43 PM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI > > We are looking for a fully channelized OC3 interface for a > Cisco 7200 > VXR. Something that we can break individual T1's off of. In > researching this there are two routes: PA-POS-1OC3 or PA-A3-OC3SMI. > The first is SONET and the second is ATM. > > Other than price what is the difference? Which is needed? > > Thanks for any and all advice. > > 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 daldworth at teliax.com Thu Sep 18 15:07:20 2008 From: daldworth at teliax.com (David Aldworth) Date: Thu, 18 Sep 2008 13:07:20 -0600 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> Message-ID: Hmm. Okay, so the PA-MC-T3 breaks the DS3 down to individual DS1's (T1's). Is there nothing equivalent at the OC3 level? David On Sep 18, 2008, at 12:58 PM, Justin M. Streiner wrote: > On Thu, 18 Sep 2008, David Aldworth wrote: > >> We are looking for a fully channelized OC3 interface for a Cisco >> 7200 VXR. Something that we can break individual T1's off of. In >> researching this there are two routes: PA-POS-1OC3 or PA-A3-OC3SMI. >> The first is SONET and the second is ATM. >> >> Other than price what is the difference? Which is needed? > > I don't believe either interface supports anything other than > concatenated operation, i.e. a full 155 Mb/s interface; you can't > break the OC3 into its component STS slots to break out DS3, CT3, > T1, etc... > > Also, the interface you'd buy would be determined by the transport > type. A POS OC3 interface might be able to physicall terminate a ATM > OC3, but it won't be able do any of the ATM stuff. > > jms From streiner at cluebyfour.org Thu Sep 18 15:22:08 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 18 Sep 2008 15:22:08 -0400 (EDT) Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> Message-ID: On Thu, 18 Sep 2008, David Aldworth wrote: > Hmm. Okay, so the PA-MC-T3 breaks the DS3 down to individual DS1's (T1's). Is > there nothing equivalent at the OC3 level? Not on a 7200, that I'm aware of. jms From nobleton at mercurypay.com Thu Sep 18 15:01:18 2008 From: nobleton at mercurypay.com (Natambu Obleton) Date: Thu, 18 Sep 2008 13:01:18 -0600 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> Message-ID: <6AAAED801816A44DA99F430E28665BE20B0FFFA8@yttrium.mercurypay.com> In channelized, do you mean the ability to has 3 separate DS3 interfaces? Neither will do this. PA-POS-1OC3 = For terminating a PTP OC-3 connection. Like a PA-T3, but an OC-3 level PA-A3-OC3SMI = ATM interface with single mode fiber connection... you will know if you need ATM -- Natambu Obleton Information Technology Mercury Payment Systems Direct: (970)335-4203 TollFree: (800)846-4472 x4203 nobleton at MercuryPay.com http://www.mercurypay.com -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Aldworth Sent: Thursday, September 18, 2008 12:43 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI We are looking for a fully channelized OC3 interface for a Cisco 7200 VXR. Something that we can break individual T1's off of. In researching this there are two routes: PA-POS-1OC3 or PA-A3-OC3SMI. The first is SONET and the second is ATM. Other than price what is the difference? Which is needed? Thanks for any and all advice. 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 dcp at dcptech.com Thu Sep 18 15:37:54 2008 From: dcp at dcptech.com (David Prall) Date: Thu, 18 Sep 2008 15:37:54 -0400 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> Message-ID: <009501c919c6$0c88f110$1dfe200a@cisco.com> Not a PA. There are SPA's but this would mean 7600/ASR/12k -- http://dcp.dcptech.com > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Aldworth > Sent: Thursday, September 18, 2008 3:07 PM > To: Justin M. Streiner > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI > > Hmm. Okay, so the PA-MC-T3 breaks the DS3 down to individual DS1's > (T1's). Is there nothing equivalent at the OC3 level? > > David > > On Sep 18, 2008, at 12:58 PM, Justin M. Streiner wrote: > > > On Thu, 18 Sep 2008, David Aldworth wrote: > > > >> We are looking for a fully channelized OC3 interface for a Cisco > >> 7200 VXR. Something that we can break individual T1's off of. In > >> researching this there are two routes: PA-POS-1OC3 or > PA-A3-OC3SMI. > >> The first is SONET and the second is ATM. > >> > >> Other than price what is the difference? Which is needed? > > > > I don't believe either interface supports anything other than > > concatenated operation, i.e. a full 155 Mb/s interface; you can't > > break the OC3 into its component STS slots to break out DS3, CT3, > > T1, etc... > > > > Also, the interface you'd buy would be determined by the transport > > type. A POS OC3 interface might be able to physicall > terminate a ATM > > OC3, but it won't be able do any of the ATM stuff. > > > > 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/ From ryanclambert at gmail.com Thu Sep 18 15:43:37 2008 From: ryanclambert at gmail.com (Ryan) Date: Thu, 18 Sep 2008 15:43:37 -0400 Subject: [c-nsp] terminating many l2l tunnels on an ASA Message-ID: <001501c919c6$d8b9bd00$8a2d3700$@com> Hey everyone, question for those of you who may have already suffered this unfortunate fate - Background: I have about 150 site to site VPN tunnels I need to terminate for an ASA. Zero (yes, zero) of the remote end devices are Cisco. I do not have any control over these devices. Everything is the same except for the remote subnets, and obviously the peer IPs. Encryption, PSK, etc. all matching. One of the requirements is that the tunnel is able to be brought up by generating traffic from my side (kind of shoots down a dynamic L2L I -think-) I am using a Cisco ASA 5520 with a VPN Plus license. I don't have the option of purchasing anything else to help with this. The actual question: Does anyone know of a decent way to bring these up without cluttering my config with 1000+ lines of ACL, tunnel-group config, etc? From colin at netech.ie Thu Sep 18 16:00:25 2008 From: colin at netech.ie (Colin Whittaker) Date: Thu, 18 Sep 2008 21:00:25 +0100 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> Message-ID: <20080918200025.GA20689@infiltrator.gizzard.com> On Thu, Sep 18, 2008 at 01:07:20PM -0600, David Aldworth wrote: > Hmm. Okay, so the PA-MC-T3 breaks the DS3 down to individual DS1's > (T1's). Is there nothing equivalent at the OC3 level? The PA-MC-STM-1 does it for stm-1 and E1 circuits. not sure if there is an OC3 version > > David > > On Sep 18, 2008, at 12:58 PM, Justin M. Streiner wrote: > > >On Thu, 18 Sep 2008, David Aldworth wrote: > > > >>We are looking for a fully channelized OC3 interface for a Cisco > >>7200 VXR. Something that we can break individual T1's off of. In > >>researching this there are two routes: PA-POS-1OC3 or PA-A3-OC3SMI. > >>The first is SONET and the second is ATM. > >> > >>Other than price what is the difference? Which is needed? > > > >I don't believe either interface supports anything other than > >concatenated operation, i.e. a full 155 Mb/s interface; you can't > >break the OC3 into its component STS slots to break out DS3, CT3, > >T1, etc... > > > >Also, the interface you'd buy would be determined by the transport > >type. A POS OC3 interface might be able to physicall terminate a ATM > >OC3, but it won't be able do any of the ATM stuff. > > > >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/ > -- Colin Whittaker +353 (0)86 8211 965 http://colin.netech.ie colin at netech.ie From justin at justinshore.com Thu Sep 18 16:02:34 2008 From: justin at justinshore.com (Justin Shore) Date: Thu, 18 Sep 2008 15:02:34 -0500 Subject: [c-nsp] Using generic Compact Flash in Cisco Routers... In-Reply-To: <5d093f9a0809171714s23ba6f7ck9f04a3112fac0850@mail.gmail.com> References: <5d093f9a0809171714s23ba6f7ck9f04a3112fac0850@mail.gmail.com> Message-ID: <48D2B3DA.30506@justinshore.com> Jonathan Charles wrote: > So, does it work? Search the list archives for the thread on CF cards titles "SUP720-3B / 3rd party CF". It was around 9/3/08. I bought dozens of the cheapest Kingston 1GB CF cards and have been using them in everything from ISRs to ASAs to Sup720-3BXLs and they've worked in all of them. Specifically I've bought model "CF/1GB". It runs about $10. Avoid the ones that advertise faster write speeds and other frilly fancy features. Those are the ones giving people problems. Justin From gert at greenie.muc.de Thu Sep 18 16:13:16 2008 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 18 Sep 2008 22:13:16 +0200 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <20080916165849.GA20288@greenie.muc.de> References: <20080902062732.GU233@greenie.muc.de> <48BD6380.6050309@gmail.com> <20080902171259.GB233@greenie.muc.de> <48BD78D4.6010405@gmail.com> <20080915145013.GA2245@greenie.muc.de> <1221508568.7357.15.camel@localhost> <48CEC162.5000105@bytemark.co.uk> <20080916040858.GA17256@greenie.muc.de> <48CFC183.4060401@bytemark.co.uk> <20080916165849.GA20288@greenie.muc.de> Message-ID: <20080918201316.GD20288@greenie.muc.de> Hi, On Tue, Sep 16, 2008 at 06:58:49PM +0200, Gert Doering wrote: > > I've got no bug ID, but it's on case SR 609537689. > Thanks. I'll forward this - and let's see what will happen. Updates. I now have a bug ID, CSCsu59917, which turns out to be a duplicate of an internal bug ID ("ID not known because it's internal"), which is supposed to be fixed in SXH4 "to be released in 4-5 weeks". We'll raise a stink about this since it's seriously impacting our routing and I'm not really willing to wait for 4 weeks of daily routing loops... gert -- Gert Doering Mobile communications ... right now writing from * Sardegna, Italy * From daldworth at teliax.com Thu Sep 18 17:17:42 2008 From: daldworth at teliax.com (David Aldworth) Date: Thu, 18 Sep 2008 15:17:42 -0600 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: <009401c919c1$9c661c90$1dfe200a@cisco.com> References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> <009401c919c1$9c661c90$1dfe200a@cisco.com> Message-ID: <6DCA46CC-43AD-4F1B-BC29-6FFD83F12D0D@teliax.com> A vendor suggested the following configuration: 15454 Chassis and Fan Dual TCC+ cards Dual Cross Connect Cards 1 DS3 card (12 DS3s) 1 DS3 backplane (24 DS3 Backplane) 1 OC3 card (4 port OC3) 1310 fiber only Seems like it is a big mux and I would still need to punch into a pa- mc-t3 or some such in order manage things at the T1 level. David On Sep 18, 2008, at 1:06 PM, David Prall wrote: > I'm pretty sure this is how it would be. You would need a frame- > relay switch > in front of the POS interface, it isn't a CHOC interface. The ATM > would need > an ATM switch in front of it to support ATM T1's. There is a PA- > MC-2T3+ that > is channelized for the 7200. With this you could put a MUX in front > of it. > > David > > -- > http://dcp.dcptech.com > > >> -----Original Message----- >> From: cisco-nsp-bounces at puck.nether.net >> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David >> Aldworth >> Sent: Thursday, September 18, 2008 2:43 PM >> To: cisco-nsp at puck.nether.net >> Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI >> >> We are looking for a fully channelized OC3 interface for a >> Cisco 7200 >> VXR. Something that we can break individual T1's off of. In >> researching this there are two routes: PA-POS-1OC3 or PA-A3-OC3SMI. >> The first is SONET and the second is ATM. >> >> Other than price what is the difference? Which is needed? >> >> Thanks for any and all advice. >> >> 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 samuel-petreski at uiowa.edu Thu Sep 18 17:19:26 2008 From: samuel-petreski at uiowa.edu (Petreski, Samuel) Date: Thu, 18 Sep 2008 16:19:26 -0500 Subject: [c-nsp] Cisco ASA VPN Active/Standby - license requirements Message-ID: <0AF2BA9F8063B34AA9A2201D34DFC7B44E9D770E1B@IOWAEVS07.iowa.uiowa.edu> Hi everyone, I was wondering if any of you are running Cisco ASA 5500 in a VPN failover mode and if you would be willing to share the license requirements. I am thinking of running two boxes in Active/Standby mode and was wondering if I need to purchase the same number of SSLVPN licenses for both boxes or only for one. Also if you have any comments about the ASA 5550 vs. ASA 5540 I would greatly appreciate it. Thanks. --Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3094 bytes Desc: not available URL: From ptimmins at clearrate.com Thu Sep 18 17:45:06 2008 From: ptimmins at clearrate.com (Paul G. Timmins) Date: Thu, 18 Sep 2008 17:45:06 -0400 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: <6DCA46CC-43AD-4F1B-BC29-6FFD83F12D0D@teliax.com> References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com><009401c919c1$9c661c90$1dfe200a@cisco.com> <6DCA46CC-43AD-4F1B-BC29-6FFD83F12D0D@teliax.com> Message-ID: If you want to do 1:1 DS3, that'd work. If you want to rearrange individual DS1s, you need a TransMux card > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Aldworth > Sent: Thursday, September 18, 2008 5:18 PM > To: David Prall > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI > > A vendor suggested the following configuration: > > 15454 Chassis and Fan > Dual TCC+ cards > Dual Cross Connect Cards > 1 DS3 card (12 DS3s) > 1 DS3 backplane (24 DS3 Backplane) > 1 OC3 card (4 port OC3) 1310 fiber only > > Seems like it is a big mux and I would still need to punch into a pa- > mc-t3 or some such in order manage things at the T1 level. > > David > > > On Sep 18, 2008, at 1:06 PM, David Prall wrote: > > > I'm pretty sure this is how it would be. You would need a frame- > > relay switch > > in front of the POS interface, it isn't a CHOC interface. The ATM > > would need > > an ATM switch in front of it to support ATM T1's. There is a PA- > > MC-2T3+ that > > is channelized for the 7200. With this you could put a MUX > in front > > of it. > > > > David > > > > -- > > http://dcp.dcptech.com > > > > > >> -----Original Message----- > >> From: cisco-nsp-bounces at puck.nether.net > >> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David > >> Aldworth > >> Sent: Thursday, September 18, 2008 2:43 PM > >> To: cisco-nsp at puck.nether.net > >> Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI > >> > >> We are looking for a fully channelized OC3 interface for a > >> Cisco 7200 > >> VXR. Something that we can break individual T1's off of. In > >> researching this there are two routes: PA-POS-1OC3 or PA-A3-OC3SMI. > >> The first is SONET and the second is ATM. > >> > >> Other than price what is the difference? Which is needed? > >> > >> Thanks for any and all advice. > >> > >> 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/ > > > > _______________________________________________ > 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 daldworth at teliax.com Thu Sep 18 17:58:09 2008 From: daldworth at teliax.com (David Aldworth) Date: Thu, 18 Sep 2008 15:58:09 -0600 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com><009401c919c1$9c661c90$1dfe200a@cisco.com> <6DCA46CC-43AD-4F1B-BC29-6FFD83F12D0D@teliax.com> Message-ID: <5A1CC4EC-08F3-4377-8DAA-7B38D0E2DF8B@teliax.com> So the below config will get break the OC3 into DS3's but to get from each DS3 to the individual DS1's I need to add a TransMux card into the chassis. This would negate the need for the DS3's to be plugged into a VXR with a pa-mc-t3 card. Would one TransMux card be sufficient? What about for an OC12? On Sep 18, 2008, at 3:45 PM, Paul G. Timmins wrote: > If you want to do 1:1 DS3, that'd work. If you want to rearrange > individual DS1s, you need a TransMux card > >> -----Original Message----- >> From: cisco-nsp-bounces at puck.nether.net >> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David >> Aldworth >> Sent: Thursday, September 18, 2008 5:18 PM >> To: David Prall >> Cc: cisco-nsp at puck.nether.net >> Subject: Re: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI >> >> A vendor suggested the following configuration: >> >> 15454 Chassis and Fan >> Dual TCC+ cards >> Dual Cross Connect Cards >> 1 DS3 card (12 DS3s) >> 1 DS3 backplane (24 DS3 Backplane) >> 1 OC3 card (4 port OC3) 1310 fiber only >> >> Seems like it is a big mux and I would still need to punch into a pa- >> mc-t3 or some such in order manage things at the T1 level. >> >> David >> >> >> On Sep 18, 2008, at 1:06 PM, David Prall wrote: >> >>> I'm pretty sure this is how it would be. You would need a frame- >>> relay switch >>> in front of the POS interface, it isn't a CHOC interface. The ATM >>> would need >>> an ATM switch in front of it to support ATM T1's. There is a PA- >>> MC-2T3+ that >>> is channelized for the 7200. With this you could put a MUX >> in front >>> of it. >>> >>> David >>> >>> -- >>> http://dcp.dcptech.com >>> >>> >>>> -----Original Message----- >>>> From: cisco-nsp-bounces at puck.nether.net >>>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David >>>> Aldworth >>>> Sent: Thursday, September 18, 2008 2:43 PM >>>> To: cisco-nsp at puck.nether.net >>>> Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI >>>> >>>> We are looking for a fully channelized OC3 interface for a >>>> Cisco 7200 >>>> VXR. Something that we can break individual T1's off of. In >>>> researching this there are two routes: PA-POS-1OC3 or PA-A3-OC3SMI. >>>> The first is SONET and the second is ATM. >>>> >>>> Other than price what is the difference? Which is needed? >>>> >>>> Thanks for any and all advice. >>>> >>>> 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/ >>> >> >> _______________________________________________ >> 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 marco at linuxgoeroe.dhs.org Thu Sep 18 17:25:50 2008 From: marco at linuxgoeroe.dhs.org (Marco van den Bovenkamp) Date: Thu, 18 Sep 2008 23:25:50 +0200 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> Message-ID: <48D2C75E.10500@linuxgoeroe.dhs.org> David Aldworth wrote: > Hmm. Okay, so the PA-MC-T3 breaks the DS3 down to individual DS1's > (T1's). Is there nothing equivalent at the OC3 level? Yep. The PA-MC-STM-1: http://www.cisco.com/en/US/prod/collateral/modules/ps2033/ps2762/product_data_sheet09186a008007d6c0.html Regards, Marco. From rshughes at gmail.com Thu Sep 18 18:18:40 2008 From: rshughes at gmail.com (Ryan Hughes) Date: Thu, 18 Sep 2008 15:18:40 -0700 Subject: [c-nsp] Cisco ASA VPN Active/Standby - license requirements In-Reply-To: <0AF2BA9F8063B34AA9A2201D34DFC7B44E9D770E1B@IOWAEVS07.iowa.uiowa.edu> References: <0AF2BA9F8063B34AA9A2201D34DFC7B44E9D770E1B@IOWAEVS07.iowa.uiowa.edu> Message-ID: You have to buy licenses for both boxes in order to do SSLVPN in Active/Standby failover. ASA 5550 is a nice box; read the getting started guide as you'll want to understand the caveats of having a dual bus for the interfaces (link below). http://www.cisco.com/en/US/docs/security/asa/asa72/getting_started/asa5550/quick/guide/thru_n.html On Thu, Sep 18, 2008 at 2:19 PM, Petreski, Samuel wrote: > Hi everyone, > > I was wondering if any of you are running Cisco ASA 5500 in a VPN failover > mode and if you would be willing to share the license requirements. I am > thinking of running two boxes in Active/Standby mode and was wondering if I > need to purchase the same number of SSLVPN licenses for both boxes or only > for one. > > Also if you have any comments about the ASA 5550 vs. ASA 5540 I would > greatly appreciate it. > > Thanks. > > --Samuel > > _______________________________________________ > 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 ptimmins at clearrate.com Thu Sep 18 18:27:34 2008 From: ptimmins at clearrate.com (Paul G. Timmins) Date: Thu, 18 Sep 2008 18:27:34 -0400 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: <5A1CC4EC-08F3-4377-8DAA-7B38D0E2DF8B@teliax.com> References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com><009401c919c1$9c661c90$1dfe200a@cisco.com><6DCA46CC-43AD-4F1B-BC29-6FFD83F12D0D@teliax.com> <5A1CC4EC-08F3-4377-8DAA-7B38D0E2DF8B@teliax.com> Message-ID: The transmux would allow you to cross connect the DS1s and rearrange them, in case you had each DS3 going to different routers and wanted to move a T1 around between them. Without it, it's just a mux that does a 1:1 relationship between STS-1 payloads and DS3 outputs. Either way you'd need a PA-MC-T3 card. The Transmux cards are DS3 output, just like the normal DS3 card, but have the ability to rearrange the T1s within the payload. You'd also need a pair of 15454-XC-VT rather than just the 15454-XC, and vt 1.5 framing on the STS-1s coming to you. I am not sure if you need to move DS1s around - if you don't - the earlier solution is easier but it still handles DS3s, not OC3s. (Also note that the XC-VT has a limit of 12 DS3s of VT1.5 payloads going through it, so there are limitations even with that) > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Aldworth > Sent: Thursday, September 18, 2008 5:58 PM > To: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI > > So the below config will get break the OC3 into DS3's but to > get from > each DS3 to the individual DS1's I need to add a TransMux card into > the chassis. This would negate the need for the DS3's to be plugged > into a VXR with a pa-mc-t3 card. Would one TransMux card be > sufficient? What about for an OC12? > > > On Sep 18, 2008, at 3:45 PM, Paul G. Timmins wrote: > > > If you want to do 1:1 DS3, that'd work. If you want to rearrange > > individual DS1s, you need a TransMux card > > > >> -----Original Message----- > >> From: cisco-nsp-bounces at puck.nether.net > >> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David > >> Aldworth > >> Sent: Thursday, September 18, 2008 5:18 PM > >> To: David Prall > >> Cc: cisco-nsp at puck.nether.net > >> Subject: Re: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI > >> > >> A vendor suggested the following configuration: > >> > >> 15454 Chassis and Fan > >> Dual TCC+ cards > >> Dual Cross Connect Cards > >> 1 DS3 card (12 DS3s) > >> 1 DS3 backplane (24 DS3 Backplane) > >> 1 OC3 card (4 port OC3) 1310 fiber only > >> > >> Seems like it is a big mux and I would still need to punch > into a pa- > >> mc-t3 or some such in order manage things at the T1 level. > >> > >> David > >> > >> > >> On Sep 18, 2008, at 1:06 PM, David Prall wrote: > >> > >>> I'm pretty sure this is how it would be. You would need a frame- > >>> relay switch > >>> in front of the POS interface, it isn't a CHOC interface. The ATM > >>> would need > >>> an ATM switch in front of it to support ATM T1's. There is a PA- > >>> MC-2T3+ that > >>> is channelized for the 7200. With this you could put a MUX > >> in front > >>> of it. > >>> > >>> David > >>> > >>> -- > >>> http://dcp.dcptech.com > >>> > >>> > >>>> -----Original Message----- > >>>> From: cisco-nsp-bounces at puck.nether.net > >>>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David > >>>> Aldworth > >>>> Sent: Thursday, September 18, 2008 2:43 PM > >>>> To: cisco-nsp at puck.nether.net > >>>> Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI > >>>> > >>>> We are looking for a fully channelized OC3 interface for a > >>>> Cisco 7200 > >>>> VXR. Something that we can break individual T1's off of. In > >>>> researching this there are two routes: PA-POS-1OC3 or > PA-A3-OC3SMI. > >>>> The first is SONET and the second is ATM. > >>>> > >>>> Other than price what is the difference? Which is needed? > >>>> > >>>> Thanks for any and all advice. > >>>> > >>>> 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/ > >>> > >> > >> _______________________________________________ > >> 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 ptimmins at clearrate.com Thu Sep 18 18:29:13 2008 From: ptimmins at clearrate.com (Paul G. Timmins) Date: Thu, 18 Sep 2008 18:29:13 -0400 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: <48D2C75E.10500@linuxgoeroe.dhs.org> References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> <48D2C75E.10500@linuxgoeroe.dhs.org> Message-ID: That card handles E1s, not T1s. > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Marco > van den Bovenkamp > Sent: Thursday, September 18, 2008 5:26 PM > To: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI > > David Aldworth wrote: > > > Hmm. Okay, so the PA-MC-T3 breaks the DS3 down to individual DS1's > > (T1's). Is there nothing equivalent at the OC3 level? > > Yep. The PA-MC-STM-1: > http://www.cisco.com/en/US/prod/collateral/modules/ps2033/ps27 > 62/product_data_sheet09186a008007d6c0.html > > Regards, > > Marco. > _______________________________________________ > 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 streiner at cluebyfour.org Thu Sep 18 19:01:04 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 18 Sep 2008 19:01:04 -0400 (EDT) Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: <48D2C75E.10500@linuxgoeroe.dhs.org> References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> <48D2C75E.10500@linuxgoeroe.dhs.org> Message-ID: On Thu, 18 Sep 2008, Marco van den Bovenkamp wrote: > David Aldworth wrote: > >> Hmm. Okay, so the PA-MC-T3 breaks the DS3 down to individual DS1's (T1's). >> Is there nothing equivalent at the OC3 level? > > Yep. The PA-MC-STM-1: > http://www.cisco.com/en/US/prod/collateral/modules/ps2033/ps2762/product_data_sheet09186a008007d6c0.html This card looks like it's more at home on the Europe side of the pond, i.e. handling STM1s, and breaking service down to E1s. jms From bryan.phillips at cybera.net Thu Sep 18 19:00:27 2008 From: bryan.phillips at cybera.net (Bryan Phillips) Date: Thu, 18 Sep 2008 18:00:27 -0500 Subject: [c-nsp] Inter VRF Routing help needed In-Reply-To: <49999c420809111950x2c064a67ifed632b09b0296bc@mail.gmail.com> References: <56F211C5E3F24F47B103EA1B253822BE036548D4@vic-cr-ex1.staff.netspace.net.au> <49999c420809111950x2c064a67ifed632b09b0296bc@mail.gmail.com> Message-ID: <48FAC036AD7B7642BB2944FB9AE674A3037119B8@EXCHANGE.nashville.cybera.net> Cc loo VRF-Lite cannot share routes internally in the router. You will need to do BGP/VPNv4 or loop out and back in some physical interfaces on your router and run a routing protocol between all of the VRF-lites over those interfaces. An RD will just define the VRF and the RD will stay the same in all your PE routers in a BGP/VPNv4 network. The RT's are really extended BGP communities to allow export and import of BGP/VPNv4 routes. Doing what Andy was showing is also known as overlapping VPNs. All VRF's will have a unique RT also but you can add other RT's to them to overlap other VRF routes. Bryan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of cc loo Sent: Thursday, September 11, 2008 9:50 PM To: Andy Saykao Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Inter VRF Routing help needed Hi, Thanks for all the replies, i will go do more homework/reading up and practice in my work place :D On Fri, Sep 12, 2008 at 6:48 AM, Andy Saykao < andy.saykao at staff.netspace.net.au> wrote: > Hi cc loo - It took me a while to understand the difference between RD > and RT's too. > > Most literature will have examples of where the RD and RT are exactly > the same and you can't help but be confused when you see them being > different and you'll start to ask yourself "what's the point of having > this RT statement when it's identicle to the RD - seems like a waste of > time". But they do play a very important role when you start moving away > from simple VRF design. > > What's most important to remember is that the RD and RT can be the same > or can be totally different and that they both serve completely > different purposes. Generally, in a very simple VRF set up (eg: one > customer with 3 sites all being able to talk with each other and > exchange data), the RD and RT will be the same because you probably > won't be leaking routes between VRF's because this isn't a requirement. > The RD is basically a way to allow overlapping IP addresses to exist. If > we take the example of vrf_customer_A (RD 1:1) and vrf_customer_B (RD > 1:2) - both can choose to use 192.168.1.0/24 and the address space will > be completely unique because the RD is combined with the IPv4 address to > produce the VPNv4 address like so - RD:192.168.1.1. > > The RT on the other hand is a BGP extended-community attribute that is > also tagged onto the VPNv4 address to allow you to be able to > import/export these routes to other VRF's. > > ip vrf customer_A > rd 1:1 > route-target export 1:100 > route-target import 1:900 > ! > ip vrf customer_B > rd 1:2 > route-target export 1:200 > route-target import 1:900 > ! > ip vrf Hub > rd 1:9 > route-target export 1:900 > route-target import 1:100 > route-target import 1:200 > > So in Oli's example, a host of vrf_customer_A might have a VPNv4 > addresses of 1:1:192.168.1.1 and RT 1:100. Likewise a host of > vrf_customer_B might have the VPNv4 address of 1:2:192.168.2.1 and RT > 1:200. The routes with the corresponding RT's of 1:100 (vrf_customer_A) > and 1:200 (vrf_customer_B) are imported by the Hub and so the Hub will > end up with the routes of 192.168.1.1 and 192.168.2.1 in it's own > routing table and will be able to reach these two hosts eventhough they > are in different VRF's. Similarly, vrf_customer_A and vrf_customer_B > need to import the RT that the Hub is exporting (1:900) so they too can > reach the Hub. > > I've deliberately used different IP space for customer_A and customer_B. > Just be careful if you plan to import/export route's between different > VRF's because you'll need to make sure the routes are unique in this > case. Imagine if customer_A and customer_B were both using > 192.168.1.0/24. How would the Hub be able to distinguish if it should be > sending to customer_A or customer_B - hence why you need to do some > planning so as not to run into this problem. > > Sorry if it was a bit long winded. I'm new to all this too ;) > > Cheers. > > Andy > > cc loo wrote on Thursday, September 11, > 2008 5:05 PM: > > > Hi Oliver, > > > > Thanks for the quick reply. > > > > Indeed i was referring to VRF-LITE > > > > In the cisco.com example, they gave this Router(config)# ip vrf > > customer_a > > Router(config-vrf)# rd 1:1 <---- > > Router(config-vrf)# route-target both 1:1 <---- Router(config)# > > interface fastEthernet 0.1 Router(config-subif)# ip vrf forwarding > > customer_a > > > > is there any specific reason why cisco recommends using "both" > > (export/import) for its own RD ? > > the RD is not exported, the RT is. see answer to next question. > > Well, the "import" is not really needed in this specific case as there > is no other VRF exporting routes with this route-target (so no point > importing it). > > > > > Oliver's example is here, but i would like to confirm if 1:100 is a > > typo or should it be 1:1 (like its own RD?): ip vrf customer_A > > rd 1:1 <----- > > route-target export 1:100 <---- > > route-target import 1:900 > > RD and route-target are different things. They can be the same, but they > must not be (in an mpls-vpn, they usually aren't the same as the RD is > unique per PE per VRF). > > > I wonder wondering if this is the correct place to post newbie > > questions like these ? > > Im a junior engineer in a singaporean isp, hoping to learn more tricks > > > and tips in the field of IP planning :D > > well, I guess it's like all lists where folks help each other: If people > see that you haven't done your homework, you might not get a reply. > > oli > > > ------------------------------ > > _______________________________________________ > cisco-nsp mailing list > cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > > End of cisco-nsp Digest, Vol 70, Issue 57 > ***************************************** > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > 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/ From jared at puck.nether.net Thu Sep 18 20:36:43 2008 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 18 Sep 2008 20:36:43 -0400 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <20080918201316.GD20288@greenie.muc.de> References: <48BD6380.6050309@gmail.com> <20080902171259.GB233@greenie.muc.de> <48BD78D4.6010405@gmail.com> <20080915145013.GA2245@greenie.muc.de> <1221508568.7357.15.camel@localhost> <48CEC162.5000105@bytemark.co.uk> <20080916040858.GA17256@greenie.muc.de> <48CFC183.4060401@bytemark.co.uk> <20080916165849.GA20288@greenie.muc.de> <20080918201316.GD20288@greenie.muc.de> Message-ID: <20080919003643.GB79009@puck.nether.net> On Thu, Sep 18, 2008 at 10:13:16PM +0200, Gert Doering wrote: > Hi, > > On Tue, Sep 16, 2008 at 06:58:49PM +0200, Gert Doering wrote: > > > I've got no bug ID, but it's on case SR 609537689. > > Thanks. I'll forward this - and let's see what will happen. > > Updates. I now have a bug ID, CSCsu59917, which turns out to be a > duplicate of an internal bug ID ("ID not known because it's internal"), > which is supposed to be fixed in SXH4 "to be released in 4-5 weeks". If it's experienced in a customer network, they should change the bug to found-in: customer-use and make the bug available on CCO. If they do not, escalate the case. > We'll raise a stink about this since it's seriously impacting our > routing and I'm not really willing to wait for 4 weeks of daily routing > loops... Your bug (CSCsu59917) should also be listed on CCO. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From chris at k7sle.com Thu Sep 18 23:20:19 2008 From: chris at k7sle.com (Chris Gauthier) Date: Thu, 18 Sep 2008 20:20:19 -0700 Subject: [c-nsp] console port In-Reply-To: <074672C37DDB4EDDA544301AE3D000EC@GINKGO> References: <69219.34362.qm@web33308.mail.mud.yahoo.com> <074672C37DDB4EDDA544301AE3D000EC@GINKGO> Message-ID: <48D31A73.3010300@k7sle.com> As Homer Simpson would say, "mmmmm....Keyspan" ;-) Chris Adam Greene wrote: > I can second the good results with the Keyspan ... > > ----- Original Message ----- From: "Patrick Muldoon" > To: "adrian kok" > Cc: > Sent: Friday, September 12, 2008 8:27 AM > Subject: Re: [c-nsp] console port > > >> On Sep 12, 2008, at 7:14 AM, adrian kok wrote: >> >>> Great. but my winxp is showing ? in the usb of the >>> system. It needs the driver. >>> >>> Do you know any realiable site to download this driver >> >> As there are probably hundreds (if not more) random USB2Serial >> Devices, not knowing which one you have will make it rough to help. >> Try google? >> >> FWIW: >> I've been happy with my keyspan.. >> >> http://www.keyspan.com/products/usa19hs/ >> >> Use it all the time, and have had zero issues with it.. >> >> -Patrick >> >> -- >> Patrick Muldoon >> Network/Software Engineer >> INOC (http://www.inoc.net) >> PGPKEY (http://www.inoc.net/~doon) >> Key ID: 0x370D752C >> >> Mac OS X. Because making Unix user-friendly is easier than debugging >> Windows. >> >> _______________________________________________ >> 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 rubensk at gmail.com Fri Sep 19 00:12:20 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Fri, 19 Sep 2008 01:12:20 -0300 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> Message-ID: <6bb5f5b10809182112n42acbce9n58067333fdc634a4@mail.gmail.com> PE-1CHOC3-SMIR-QPP PIC for the Juniper M7i, perhaps ? Rubens On Thu, Sep 18, 2008 at 3:43 PM, David Aldworth wrote: > We are looking for a fully channelized OC3 interface for a Cisco 7200 VXR. > Something that we can break individual T1's off of. In researching this > there are two routes: PA-POS-1OC3 or PA-A3-OC3SMI. The first is SONET and > the second is ATM. > > Other than price what is the difference? Which is needed? > > Thanks for any and all advice. > > 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 rubensk at gmail.com Fri Sep 19 01:45:48 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Fri, 19 Sep 2008 02:45:48 -0300 Subject: [c-nsp] Weird OSPF meltdown Message-ID: <6bb5f5b10809182245s3256abe7p8d0b931097632395@mail.gmail.com> Every once in a while one of ME6524 routers starts getting hammered by one customer or the other... the symptom is that all adjacencies go down and stay stuck at EXCHANGE phase. CPU doesn't go up, and CoPP is applied; OSPF is authenticated on every adjacency (which are all point-to-point on SVIs), and we don't see any strange neighbors. It occurs more often with Internet access static connected route customers, but has now happened on a VRF as well. The only solution is disconnecting the customer; provisioning the customer on SVI or on routerport doesn't seem to have any effect. IOS is 12.2(18)ZU2; Sham-Link on this IOS is vulnerable but we are not using it. Any thoughts ? Rubens From abalashov at evaristesys.com Fri Sep 19 01:46:59 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Fri, 19 Sep 2008 01:46:59 -0400 Subject: [c-nsp] terminating many l2l tunnels on an ASA In-Reply-To: <001501c919c6$d8b9bd00$8a2d3700$@com> References: <001501c919c6$d8b9bd00$8a2d3700$@com> Message-ID: <48D33CD3.8060607@evaristesys.com> Well, the ASAs do have a nice Java GUI with a high level of sophistication similar to the PIX's and VPN Concentrators. That can definitely help cut down on management clutter, and is the easier way to manage an ASA anyhow, seeing as its config format is just as abstruse and different from everything IOS as PIX. Ryan wrote: > Hey everyone, question for those of you who may have already suffered this > unfortunate fate - > > > > Background: > > > > I have about 150 site to site VPN tunnels I need to terminate for an ASA. > Zero (yes, zero) of the remote end devices are Cisco. I do not have any > control over these devices. Everything is the same except for the remote > subnets, and obviously the peer IPs. Encryption, PSK, etc. all matching. > > > > One of the requirements is that the tunnel is able to be brought up by > generating traffic from my side (kind of shoots down a dynamic L2L I > -think-) > > > > I am using a Cisco ASA 5520 with a VPN Plus license. I don't have the option > of purchasing anything else to help with this. > > > > The actual question: > > > > Does anyone know of a decent way to bring these up without cluttering my > config with 1000+ lines of ACL, tunnel-group config, etc? > > _______________________________________________ > 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 Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From gkg at gmx.de Fri Sep 19 01:52:01 2008 From: gkg at gmx.de (Garry) Date: Fri, 19 Sep 2008 07:52:01 +0200 Subject: [c-nsp] Cisco ASA VPN Active/Standby - license requirements In-Reply-To: <0AF2BA9F8063B34AA9A2201D34DFC7B44E9D770E1B@IOWAEVS07.iowa.uiowa.edu> References: <0AF2BA9F8063B34AA9A2201D34DFC7B44E9D770E1B@IOWAEVS07.iowa.uiowa.edu> Message-ID: <48D33E01.9080204@gmx.de> Petreski, Samuel wrote: > Hi everyone, > > I was wondering if any of you are running Cisco ASA 5500 in a VPN failover > mode and if you would be willing to share the license requirements. I am > thinking of running two boxes in Active/Standby mode and was wondering if I > need to purchase the same number of SSLVPN licenses for both boxes or only > for one. > My understanding is that apart from the Security Plus license (which is required for smaller ASAs at least), both boxes need to be identically, which would include the user/ip limits, SSLVPN licenses, etc ...so in contrast to "old times", where you'd have a cheaper second box PIX, you now basically have twice the price in order to have HA ... makes sense especially for Active/Active standby, as it's more or less load balancing, too ...as for Active/Passive, which most of our customers would require, I personally would have liked to see an "old option" with lower additional cost ... -garry From marco at linuxgoeroe.dhs.org Fri Sep 19 03:06:33 2008 From: marco at linuxgoeroe.dhs.org (marco at linuxgoeroe.dhs.org) Date: Fri, 19 Sep 2008 09:06:33 +0200 (CEST) Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> <48D2C75E.10500@linuxgoeroe.dhs.org> Message-ID: <50339.212.142.33.197.1221807993.squirrel@www.vive-id.nl> >> Yep. The PA-MC-STM-1: >> http://www.cisco.com/en/US/prod/collateral/modules/ps2033/ps2762/product_data_sheet09186a008007d6c0.html > > This card looks like it's more at home on the Europe side of the pond, > i.e. handling STM1s, and breaking service down to E1s. You're absolutely right, of course. Mea culpa. Odd, though, that this card exists and its -OC3 brother doesn't... From eric at atlantech.net Fri Sep 19 06:45:37 2008 From: eric at atlantech.net (Eric Van Tol) Date: Fri, 19 Sep 2008 06:45:37 -0400 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: <6bb5f5b10809182112n42acbce9n58067333fdc634a4@mail.gmail.com> References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> <6bb5f5b10809182112n42acbce9n58067333fdc634a4@mail.gmail.com> Message-ID: <2C05E949E19A9146AF7BDF9D44085B86350C3DA45D@exchange.aoihq.local> > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Rubens Kuhl Jr. > Sent: Friday, September 19, 2008 12:12 AM > To: David Aldworth > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI > > PE-1CHOC3-SMIR-QPP PIC for the Juniper M7i, perhaps ? > > > Rubens > This is what I was going to suggest. We use the 1CHOC12-SMIR-QPP to break out T1s from an OC12 and it works great. You can channelize all the way to DS0 with these PICs, running full QoS on individual channels if you want. Full QoS means marking, queuing, scheduling, PLP, etc. on individual channels down to a DS0, without a performance hit to the box or *anything* being punted to software. Beware - only the 'QPP' PICs can do this. If you try and go cheap-o and get an old style CHOC3-SMIR PIC, (or DS3, or OC12, or GE), your QoS capabilities are severely limited. Unfortunately, I am not aware of a Cisco counterpart to this type of solution. -evt From nasir.shaikh at bt.com Fri Sep 19 07:07:39 2008 From: nasir.shaikh at bt.com (nasir.shaikh at bt.com) Date: Fri, 19 Sep 2008 12:07:39 +0100 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: <50339.212.142.33.197.1221807993.squirrel@www.vive-id.nl> References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com><48D2C75E.10500@linuxgoeroe.dhs.org> <50339.212.142.33.197.1221807993.squirrel@www.vive-id.nl> Message-ID: Sorry for cutting in into this thread but from the responses looks like my question would fit here too. We are about to provide a customer with a price for upgrading one of the STM-1 ISP links to an STM-4 link with a 200 Mb port. The router we have in place is a 7206 VXR NPE G1. What card would be suitable in this router to do the trick? I can't find an OC12 card using the configurator. The card I find that fits the 7206 is the PA-SRP-OC12. But this is not available in the configurator. Can anyone help me out with this one? Thank you and with best regards Nasir Shaikh -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of marco at linuxgoeroe.dhs.org Sent: vrijdag 19 september 2008 9:07 To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI >> Yep. The PA-MC-STM-1: >> http://www.cisco.com/en/US/prod/collateral/modules/ps2033/ps2762/product _data_sheet09186a008007d6c0.html > > This card looks like it's more at home on the Europe side of the pond, > i.e. handling STM1s, and breaking service down to E1s. You're absolutely right, of course. Mea culpa. Odd, though, that this card exists and its -OC3 brother doesn't... _______________________________________________ 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 Fri Sep 19 08:11:07 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 19 Sep 2008 14:11:07 +0200 (CEST) Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: References: <50339.212.142.33.197.1221807993.squirrel@www.vive-id.nl> Message-ID: <20080919.141107.74721080.sthaug@nethelp.no> > We are about to provide a customer with a price for upgrading one of the > STM-1 ISP links to an STM-4 link with a 200 Mb port. The router we have > in place is a 7206 VXR NPE G1. What card would be suitable in this > router to do the trick? I can't find an OC12 card using the > configurator. The card I find that fits the 7206 is the PA-SRP-OC12. But > this is not available in the configurator. Can anyone help me out with > this one? Sorry, there is no STM-4 for the 7200. You'll need a different box... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From tvarriale at comcast.net Fri Sep 19 07:40:47 2008 From: tvarriale at comcast.net (Tony Varriale) Date: Fri, 19 Sep 2008 06:40:47 -0500 Subject: [c-nsp] Cisco ASA VPN Active/Standby - license requirements References: <0AF2BA9F8063B34AA9A2201D34DFC7B44E9D770E1B@IOWAEVS07.iowa.uiowa.edu> <48D33E01.9080204@gmx.de> Message-ID: <000c01c91a50$c16027e0$0100fea9@flamadam> Garry is correct. Both boxes must be the same, including licenses. Unfortunately, it doesn't work like the ol' days. I brought this up (amongst other items) to the ASA PM recently. tv ----- Original Message ----- From: "Garry" To: "Petreski, Samuel" Cc: Sent: Friday, September 19, 2008 12:52 AM Subject: Re: [c-nsp] Cisco ASA VPN Active/Standby - license requirements > Petreski, Samuel wrote: >> Hi everyone, >> >> I was wondering if any of you are running Cisco ASA 5500 in a VPN >> failover >> mode and if you would be willing to share the license requirements. I am >> thinking of running two boxes in Active/Standby mode and was wondering if >> I >> need to purchase the same number of SSLVPN licenses for both boxes or >> only >> for one. >> > My understanding is that apart from the Security Plus license (which is > required for smaller ASAs at least), both boxes need to be identically, > which would include the user/ip limits, SSLVPN licenses, etc ...so in > contrast to "old times", where you'd have a cheaper second box PIX, you > now basically have twice the price in order to have HA ... makes sense > especially for Active/Active standby, as it's more or less load > balancing, too ...as for Active/Passive, which most of our customers > would require, I personally would have liked to see an "old option" with > lower additional cost ... > > -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 ahmedazim at gmail.com Fri Sep 19 08:45:11 2008 From: ahmedazim at gmail.com (Ahmed Mohamed) Date: Fri, 19 Sep 2008 14:45:11 +0200 Subject: [c-nsp] Switch Module Message-ID: Hello , i have CS65013 switches with some new modules installed on it due to a documentation problem, i don't know which module was installed recently is there any command that can give me the uptime of the module? From lowen at pari.edu Fri Sep 19 09:31:23 2008 From: lowen at pari.edu (Lamar Owen) Date: Fri, 19 Sep 2008 09:31:23 -0400 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> Message-ID: <200809190931.23338.lowen@pari.edu> On Thursday 18 September 2008 14:43:19 David Aldworth wrote: > We are looking for a fully channelized OC3 interface for a Cisco 7200 > VXR. Something that we can break individual T1's off of. In > researching this there are two routes: PA-POS-1OC3 or PA-A3-OC3SMI. > The first is SONET and the second is ATM. Neither are channelized, as you've already found out. You could, however, pop something like a Fujitsu FLM-150 (can be had used inexpensively) and use the channelized DS-3 cards in the 7200 to connect to DS-3's that the FLM-150 (or other vendor's equivalent) would mux into an OC-3. The nice thing there is the FLM-150 and its brethren have great optics selections and full APS capability. Channelized OC-3's are available for 12000 series; lots of rack space, but a 12008 or 12012 can be had inexpensively, or you can get the smaller ones from Cisco. Depends on how much touchy-feely your router needs to do on the packets; 12000's are very aloof in that regard. - Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 http://www.pari.edu From robert at tellurian.com Fri Sep 19 09:38:58 2008 From: robert at tellurian.com (Robert Boyle) Date: Fri, 19 Sep 2008 09:38:58 -0400 Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com> Message-ID: <1221831545_56056@mail1.tellurian.net> At 02:43 PM 9/18/2008, David Aldworth wrote: >We are looking for a fully channelized OC3 interface for a Cisco 7200 >VXR. Something that we can break individual T1's off of. In >researching this there are two routes: PA-POS-1OC3 or PA-A3-OC3SMI. >The first is SONET and the second is ATM. > >Other than price what is the difference? Which is needed? The easiest and most cost effective option for a 7200 series is an Adtran Opti-3 OC3-DS3 mux. It is available with one controller card (unprotected) or two (protected) and will give you three DS3s via BNC connectors on the back. It is -48VDC power, but you can buy two little 1A -48VDC power supplies from Adtran if you don't have -48VDC at your POP. The box is 1U and they are rock solid reliable and can be found new for $3k to $4k. You will also need PA-MC-T3 or PA-MC-2T3 cards to break down the DS3s into T1s. We use this solution all over the US and it works great. -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin From jeff-kell at utc.edu Fri Sep 19 09:42:55 2008 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 19 Sep 2008 09:42:55 -0400 Subject: [c-nsp] Cisco ASA VPN Active/Standby - license requirements In-Reply-To: <48D33E01.9080204@gmx.de> References: <0AF2BA9F8063B34AA9A2201D34DFC7B44E9D770E1B@IOWAEVS07.iowa.uiowa.edu> <48D33E01.9080204@gmx.de> Message-ID: <48D3AC5F.1020705@utc.edu> Garry wrote: > ... makes sense > especially for Active/Active standby, as it's more or less load > balancing, too Bzzzttt! You can't do VPN in active/active mode, at least with 7.x and under. If you can, please tell me how! Jeff From streiner at cluebyfour.org Fri Sep 19 09:48:04 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 19 Sep 2008 09:48:04 -0400 (EDT) Subject: [c-nsp] PA-POS-1OC3 vs. PA-A3-OC3SMI In-Reply-To: References: <6E312BD8-A439-48C0-A505-609735083076@teliax.com><48D2C75E.10500@linuxgoeroe.dhs.org> <50339.212.142.33.197.1221807993.squirrel@www.vive-id.nl> Message-ID: On Fri, 19 Sep 2008, nasir.shaikh at bt.com wrote: > Sorry for cutting in into this thread but from the responses looks like > my question would fit here too. > > We are about to provide a customer with a price for upgrading one of the > STM-1 ISP links to an STM-4 link with a 200 Mb port. The router we have > in place is a 7206 VXR NPE G1. What card would be suitable in this > router to do the trick? I can't find an OC12 card using the > configurator. The card I find that fits the 7206 is the PA-SRP-OC12. But > this is not available in the configurator. Can anyone help me out with > this one? While you can physically land an OC12 on a 7200, that's likely reaching a point where you need to start thinking about a bigger router. jms From loui at renater.fr Fri Sep 19 09:49:38 2008 From: loui at renater.fr (Frederic LOUI) Date: Fri, 19 Sep 2008 15:49:38 +0200 Subject: [c-nsp] ISIS and CoPP on 760X Message-ID: <48D3ADF2.8020508@renater.fr> Hi all, We're currently using Receive-ACL(s) in order to protect as much as possible, ingress traffic coming to any router's interface. Actually, this is possible on 12K IOS 12.0(32)S8. As far as I can see in CCO documentation, there is no equivalent to receive-acl for 760X... In terms of "Control Plane Protection", it seems that CoPP is the way to go ... In all kind of documentation it is easy to match ospf packet type through ACL or the "match protocol ospf" statement. However, I'm wondering how to match ISIS packet. (rACL do not filter ISIS packet) There are several available commands under class-map statement: "match protocol clns" "match protocol clns_is" "match protocol clns_es" But because of various reasons I can't test these commands. (I don't have a 760x test box yet ... ;-) ) Anyone had any experience with CoPP and ISIS on 760x box ? (Target IOS is 122-33.SRC1) I've seen in the forum's archive that this issue has already discussed, but the conclusion is a bit outdated. (Maybe the platform has considerably evolved ?? Apology if the question is obvious...) on Anyway, Thanks all in advance for your help, Bgrds/Frederic -- Frederic LOUI / GIP RENATER Service de Suivi Operationnel / Metrologie & QoS Network Operations Service / Metrology & QoS Tel: +33 1 53 94 20 82 / Fax: +33 1 53 94 20 31 frederic.loui at renater.fr http://www.renater.fr From justin at justinshore.com Fri Sep 19 10:28:22 2008 From: justin at justinshore.com (Justin Shore) Date: Fri, 19 Sep 2008 09:28:22 -0500 Subject: [c-nsp] ISIS and CoPP on 760X In-Reply-To: <48D3ADF2.8020508@renater.fr> References: <48D3ADF2.8020508@renater.fr> Message-ID: <48D3B706.9040501@justinshore.com> My understanding is that you have to use class-default to match IS-IS and a bunch of other things. The Press book "Router Security Strategies" has a good amount of info on CoPP, complete with sample config. Justin Frederic LOUI wrote: > > Hi all, > > We're currently using Receive-ACL(s) in order to protect as much as > possible, ingress traffic coming to any router's interface. Actually, > this is possible on 12K IOS 12.0(32)S8. > > As far as I can see in CCO documentation, there is no equivalent to > receive-acl for 760X... In terms of "Control Plane Protection", it > seems that CoPP is the way to go ... > > In all kind of documentation it is easy to match ospf packet type > through ACL or the "match protocol ospf" statement. However, I'm > wondering how to match ISIS packet. (rACL do not filter ISIS packet) > > There are several available commands under class-map statement: > "match protocol clns" > "match protocol clns_is" > "match protocol clns_es" > > But because of various reasons I can't test these commands. > (I don't have a 760x test box yet ... ;-) ) > > Anyone had any experience with CoPP and ISIS on 760x box ? (Target IOS > is 122-33.SRC1) > > I've seen in the forum's archive that this issue has already > discussed, but the conclusion is a bit outdated. (Maybe the platform > has considerably evolved ?? Apology if the question is obvious...) on > > Anyway, > Thanks all in advance for your help, > > Bgrds/Frederic > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 frederic.loui at renater.fr Fri Sep 19 10:38:11 2008 From: frederic.loui at renater.fr (Frederic LOUI) Date: Fri, 19 Sep 2008 16:38:11 +0200 Subject: [c-nsp] ISIS and CoPP on 760X In-Reply-To: <48D3B706.9040501@justinshore.com> References: <48D3ADF2.8020508@renater.fr> <48D3B706.9040501@justinshore.com> Message-ID: <48D3B953.7040907@renater.fr> Hi, > My understanding is that you have to use class-default to match IS-IS > and a bunch of other things. The Press book "Router Security In terms of security, I prefer to have a strict policy so that in class-default section, I'd rather drop everything that "I'm not aware of". > Strategies" has a good amount of info on CoPP, complete with sample config. I'll try to have a quick look. The cornerstone for me is to identify if "match protocol clns|clns_is|clns_es" is available and can be applied on 760X using 122-33SRC1 so that I can match ISIS pack in my "IGP class" and finally drop/apply low rate to everything in "class-default" Thanks anyway for your pointer. Bgrds/Frederic > > Justin > > Frederic LOUI wrote: >> >> Hi all, >> >> We're currently using Receive-ACL(s) in order to protect as much as >> possible, ingress traffic coming to any router's interface. Actually, >> this is possible on 12K IOS 12.0(32)S8. >> >> As far as I can see in CCO documentation, there is no equivalent to >> receive-acl for 760X... In terms of "Control Plane Protection", it >> seems that CoPP is the way to go ... >> >> In all kind of documentation it is easy to match ospf packet type >> through ACL or the "match protocol ospf" statement. However, I'm >> wondering how to match ISIS packet. (rACL do not filter ISIS packet) >> >> There are several available commands under class-map statement: >> "match protocol clns" >> "match protocol clns_is" >> "match protocol clns_es" >> >> But because of various reasons I can't test these commands. >> (I don't have a 760x test box yet ... ;-) ) >> >> Anyone had any experience with CoPP and ISIS on 760x box ? (Target IOS >> is 122-33.SRC1) >> >> I've seen in the forum's archive that this issue has already >> discussed, but the conclusion is a bit outdated. (Maybe the platform >> has considerably evolved ?? Apology if the question is obvious...) on >> >> Anyway, >> Thanks all in advance for your help, >> >> Bgrds/Frederic >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 saku+cisco-nsp at ytti.fi Fri Sep 19 11:15:53 2008 From: saku+cisco-nsp at ytti.fi (Saku Ytti) Date: Fri, 19 Sep 2008 18:15:53 +0300 Subject: [c-nsp] ISIS and CoPP on 760X In-Reply-To: <48D3B706.9040501@justinshore.com> References: <48D3ADF2.8020508@renater.fr> <48D3B706.9040501@justinshore.com> Message-ID: <20080919151553.GA16874@mx.ytti.net> On (2008-09-19 09:28 -0500), Justin Shore wrote: > My understanding is that you have to use class-default to match IS-IS > and a bunch of other things. The Press book "Router Security > Strategies" has a good amount of info on CoPP, complete with sample > config. I would recommend against using class-default in pfc3b or pfc3c if you are running L3 MPLS VPN's in same box, as this will increase your internal VLAN usage and decrease pps performance for L3 MPLS VPN's due to disabling VPN-CAM. Just make last rule of your CoPP catch all IP, which is deny,deny,deny policed. Non matching traffic (such as CLNS) will jut flow through. -- ++ytti From saku+cisco-nsp at ytti.fi Fri Sep 19 11:16:57 2008 From: saku+cisco-nsp at ytti.fi (Saku Ytti) Date: Fri, 19 Sep 2008 18:16:57 +0300 Subject: [c-nsp] ISIS and CoPP on 760X In-Reply-To: <48D3B953.7040907@renater.fr> References: <48D3ADF2.8020508@renater.fr> <48D3B706.9040501@justinshore.com> <48D3B953.7040907@renater.fr> Message-ID: <20080919151657.GB16874@mx.ytti.net> On (2008-09-19 16:38 +0200), Frederic LOUI wrote: > The cornerstone for me is to identify if "match protocol > clns|clns_is|clns_es" is available and can be applied on 760X using > 122-33SRC1 so that I can match ISIS pack in my "IGP class" and finally > drop/apply low rate to everything in "class-default" Unfortunately this match is not supported by PFC3B/PFC3C platforms. -- ++ytti From daniele at orlandi.com Fri Sep 19 12:24:00 2008 From: daniele at orlandi.com (Daniele Orlandi) Date: Fri, 19 Sep 2008 18:24:00 +0200 Subject: [c-nsp] 6500 WS-SUP32-GE-3B failure In-Reply-To: <0867622C64B50C4B878AB45C95F43F1106124A09@MAILWA01.wesenergy.local> References: <0867622C64B50C4B878AB45C95F43F1106124A09@MAILWA01.wesenergy.local> Message-ID: <200809191824.00564.daniele@orlandi.com> On Wednesday 03 September 2008 11:05:31 Aaron Riemer wrote: > > We currently have a WS-SUP32-GE-3B where the SFP ports are not coming > online. Is there a test that can be run from the switch to detect if > there is a hardware failure? A sh module indicates that the SUP is ok.. Are you sure you are connecting them to Gigabit equipment? AFAIK, the ports only work at 1000 Mbps. Cheers, From gert at greenie.muc.de Thu Sep 18 16:41:59 2008 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 18 Sep 2008 22:41:59 +0200 Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) In-Reply-To: <48CD86BD.4050604@elfove.cz> References: <48CD86BD.4050604@elfove.cz> Message-ID: <20080918204159.GG20288@greenie.muc.de> Hi, On Sun, Sep 14, 2008 at 11:48:45PM +0200, Tomas Hlavacek wrote: > The point is how to make packets traveling from upstreams of AS1 to AS2 not > to take path via IX, but via direct Ethernet connection while traffic > originating in AS1 and traffic from AS3 traveling trough AS1 take path via > IX? I'd actually just not peer with AS2, then... "don't peer with customers". (Yes, this is not exactly what you wanted to hear - but everything else that I could think of sounds horribly complicated, prone to fail, or likely to burn lots of router memory for dubious gains). If only AS3 and AS2 are involved, maybe a direct peering AS2<->AS3 could be arranged, to achieve the goal of traffic from AS3 reaching AS2 without paying for uplink costs? gert -- Gert Doering Mobile communications ... right now writing from * Sardegna, Italy * From gert at greenie.muc.de Fri Sep 19 12:51:26 2008 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 19 Sep 2008 18:51:26 +0200 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <20080919003643.GB79009@puck.nether.net> References: <20080902171259.GB233@greenie.muc.de> <48BD78D4.6010405@gmail.com> <20080915145013.GA2245@greenie.muc.de> <1221508568.7357.15.camel@localhost> <48CEC162.5000105@bytemark.co.uk> <20080916040858.GA17256@greenie.muc.de> <48CFC183.4060401@bytemark.co.uk> <20080916165849.GA20288@greenie.muc.de> <20080918201316.GD20288@greenie.muc.de> <20080919003643.GB79009@puck.nether.net> Message-ID: <20080919165126.GA11635@greenie.muc.de> Hi, On Thu, Sep 18, 2008 at 08:36:43PM -0400, Jared Mauch wrote: > On Thu, Sep 18, 2008 at 10:13:16PM +0200, Gert Doering wrote: > > On Tue, Sep 16, 2008 at 06:58:49PM +0200, Gert Doering wrote: > > > > I've got no bug ID, but it's on case SR 609537689. > > > Thanks. I'll forward this - and let's see what will happen. > > > > Updates. I now have a bug ID, CSCsu59917, which turns out to be a > > duplicate of an internal bug ID ("ID not known because it's internal"), > > which is supposed to be fixed in SXH4 "to be released in 4-5 weeks". > > If it's experienced in a customer network, they should change the bug > to found-in: customer-use and make the bug available on CCO. I agree... > If they do not, escalate the case. ... but this is a bit difficult right now - I'm on vacation, technically, and thus I'm a bit handicapped regarding escalation things. So this will have to wait a few days. Hopefully they will at least be able to do a SXH3 interim rebuild in the mean time. ("I'll check with the developers"). > > We'll raise a stink about this since it's seriously impacting our > > routing and I'm not really willing to wait for 4 weeks of daily routing > > loops... > Your bug (CSCsu59917) should also be listed on CCO. What does CCO say about it, right now? (Don't want to check - $very expensive GPRS link...) gert -- Gert Doering Mobile communications ... right now writing from * Sardegna, Italy * From peter at rathlev.dk Fri Sep 19 13:09:26 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Fri, 19 Sep 2008 19:09:26 +0200 Subject: [c-nsp] Switch Module In-Reply-To: References: Message-ID: <1221844166.11349.8.camel@abehat> On Fri, 2008-09-19 at 14:45 +0200, Ahmed Mohamed wrote: > i have CS65013 switches with some new modules installed on it due to a > documentation problem, i don't know which module was installed > recently > > is there any command that can give me the uptime of the module? You could try "remote command module X show version", but not all modules support it -- AFAIK they have to have a CFC or DFC. The WS-X6700 modules seem to support it (WS-X6748-GE-TX, WS-X6724-SFP, WS-X6708-10GE do at least). Otherwise you could look at the diagnostics, with "show diagnostics result module X detail". Tests like TestLoopback are not "non-destructive", and thus only performed at bootup (unless you ask for it yourself of course). Looking at when the test was performed can tell you when the module booted. The diagnostics are performed on all switch modules. Regards, Peter From peter at rathlev.dk Fri Sep 19 13:23:36 2008 From: peter at rathlev.dk (Peter Rathlev) Date: Fri, 19 Sep 2008 19:23:36 +0200 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <20080919165126.GA11635@greenie.muc.de> References: <20080902171259.GB233@greenie.muc.de> <48BD78D4.6010405@gmail.com> <20080915145013.GA2245@greenie.muc.de> <1221508568.7357.15.camel@localhost> <48CEC162.5000105@bytemark.co.uk> <20080916040858.GA17256@greenie.muc.de> <48CFC183.4060401@bytemark.co.uk> <20080916165849.GA20288@greenie.muc.de> <20080918201316.GD20288@greenie.muc.de> <20080919003643.GB79009@puck.nether.net> <20080919165126.GA11635@greenie.muc.de> Message-ID: <1221845016.11349.15.camel@abehat> On Fri, 2008-09-19 at 18:51 +0200, Gert Doering wrote: > On Thu, Sep 18, 2008 at 08:36:43PM -0400, Jared Mauch wrote: > > Your bug (CSCsu59917) should also be listed on CCO. > What does CCO say about it, right now? (Don't want to check - $very > expensive GPRS link...) Probably not totally legal to post this, but here goes. :-) CSCsu59917 SXF15: IPv4/v6 BGP routes not cleared when source routes is gone Severity: 1 - catastrophic. Status: Fixed. Fixed-In 12.2(18)SXF15 12.2(33.3.11)SXH 12.2(32.8.11)SX206 Regards, Peter (And then a 256-line .sig...) From twinders at southplainscollege.edu Fri Sep 19 13:46:47 2008 From: twinders at southplainscollege.edu (Winders, Timothy A) Date: Fri, 19 Sep 2008 12:46:47 -0500 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <1221845016.11349.15.camel@abehat> Message-ID: On 9/19/08 12:23 PM, "Peter Rathlev" wrote: > On Fri, 2008-09-19 at 18:51 +0200, Gert Doering wrote: >> On Thu, Sep 18, 2008 at 08:36:43PM -0400, Jared Mauch wrote: >>> Your bug (CSCsu59917) should also be listed on CCO. > >> What does CCO say about it, right now? (Don't want to check - $very >> expensive GPRS link...) > > Probably not totally legal to post this, but here goes. :-) > > CSCsu59917 > SXF15: IPv4/v6 BGP routes not cleared when source routes is gone > Severity: 1 - catastrophic. > Status: Fixed. > Fixed-In > 12.2(18)SXF15 > 12.2(33.3.11)SXH > 12.2(32.8.11)SX206 I don't understand. How can this show up in SXF15 and be fixed in SXF15? Or, am I reading this wrong? Tim Winders | Associate Dean of Information Technology | South Plains College From rinse.kloek at isp.solcon.nl Fri Sep 19 14:55:46 2008 From: rinse.kloek at isp.solcon.nl (Rinse Kloek (Solcon)) Date: Fri, 19 Sep 2008 20:55:46 +0200 Subject: [c-nsp] SRC2? In-Reply-To: <20080918161106.GH4819@rtp-cse-489.cisco.com> References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <48A2FF3B.5030104@gatlan.nl> <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com> <48D003E4.7000005@isp.solcon.nl> <20080917115953.GD23151@rtp-cse-489.cisco.com> <48D16197.2080302@isp.solcon.nl> <20080918161106.GH4819@rtp-cse-489.cisco.com> Message-ID: <48D3F5B2.3070408@isp.solcon.nl> This puzzles me. I do policy routing met set VRF. However it looks like still the global routing table is used: Sep 19 20:48:12.439: IP: s=192.168.0.2 (GigabitEthernet0/2), d=192.168.10.1, len 84, PBR Counted Sep 19 20:48:12.439: IP: s=192.168.0.2 (GigabitEthernet0/2), d=192.168.10.1, len 84, FIB policy routed set vrf Sep 19 20:48:12.439: IP: s=192.168.0.2 (GigabitEthernet0/2), d=192.168.10.1, len 84, FIB policy match Sep 19 20:48:12.439: IP: s=192.168.0.2 (GigabitEthernet0/2), d=192.168.10.1, len 84, FIB policy routed set vrf Sep 19 20:48:12.439: IP: s=192.168.0.2 (GigabitEthernet0/2), d=192.168.10.1, len 84, input feature, Policy Routing(49), rtype 0, forus FALSE, sendself FALSE0 Sep 19 20:48:12.439: IP: tableid=0, s=192.168.0.2 (GigabitEthernet0/2), d=192.168.10.1 (GigabitEthernet0/1), routed via FIB First messages say that set vrf is matched. However the last line just implies it goes throug the global routing table. GigabitEthernet0/1 is the default gateway of the global routing table. kind regards Rinse Rodney Dunn schreef: > What I'm saying is if you are seeing the problem on SRC1 it can't > be CSCsk27643. > > On Wed, Sep 17, 2008 at 09:59:19PM +0200, Rinse Kloek (Solcon) wrote: > >> I tried this feature on a 7200 with SRC1 (also on SB6). (SRB does not >> run on 7200). >> >> regards Rinse >> >> Rodney Dunn schreef: >> >>> It's already fixed in SRC and SRB4. >>> >>> That bug was only an issue in SRA throttle. >>> >>> Have you tried SRB4? >>> >>> On Tue, Sep 16, 2008 at 09:07:16PM +0200, Rinse Kloek (Solcon) wrote: >>> >>> >>>> We are also running in some bug ( CSCsk27643 ) and are hoping to see >>>> this fixed in SRC2. Anybody some tips to get PBR using set vrf working >>>> on a 12.2 release ? >>>> >>>> regards Rinse >>>> cisco-nsp at puck.nether.net >>>> >>>> >>>>> Hi All, >>>>> >>>>> On Wed, Aug 13, 2008 at 6:35 PM, Bas Roos wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>> Anyone know when 12.2(33)SRC2 is supposed to be released, specifically >>>>>>> for the 7600. I had heard by the end of July, but so far no release. >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>>> The latest statement we got from them was end-september. >>>>>> >>>>>> >>>>>> >>>>> Anyone from Cisco perhaps would comment on this? >>>>> CSCso45720 makes it really problematic to go into production stage >>>>> with the SRC train. >>>>> >>>>> Cheers, >>>>> -- >>>>> Ran. >>>>> _______________________________________________ >>>>> 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 leonardo.souza at nec.com.br Fri Sep 19 15:20:13 2008 From: leonardo.souza at nec.com.br (Leonardo Gama Souza) Date: Fri, 19 Sep 2008 16:20:13 -0300 Subject: [c-nsp] RES: Switch Module References: Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E64@spsrvmail03.nec.br> attach show ver Cheers, Leonardo Gama. ________________________________ De: cisco-nsp-bounces at puck.nether.net em nome de Ahmed Mohamed Enviada: sex 19/9/2008 09:45 Para: cisco-nsp at puck.nether.net Assunto: [c-nsp] Switch Module Hello , i have CS65013 switches with some new modules installed on it due to a documentation problem, i don't know which module was installed recently is there any command that can give me the uptime of the module? _______________________________________________ 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 Fri Sep 19 15:41:58 2008 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Fri, 19 Sep 2008 22:41:58 +0300 Subject: [c-nsp] RES: Switch Module In-Reply-To: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E64@spsrvmail03.nec.br> References: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E64@spsrvmail03.nec.br> Message-ID: <48D40086.1090602@forthnet.gr> Or the one-liner: remote command module sh ver | i uptime -- Tassos Leonardo Gama Souza wrote on 19/09/2008 22:20: > attach > show ver > > Cheers, > Leonardo Gama. > > ________________________________ > > De: cisco-nsp-bounces at puck.nether.net em nome de Ahmed Mohamed > Enviada: sex 19/9/2008 09:45 > Para: cisco-nsp at puck.nether.net > Assunto: [c-nsp] Switch Module > > > > Hello , > > i have CS65013 switches with some new modules installed on it > due to a documentation problem, i don't know which module was installed > recently > > is there any command that can give me the uptime of the module? > _______________________________________________ > 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 Jesse.Fields at wesd.org Fri Sep 19 16:24:17 2008 From: Jesse.Fields at wesd.org (Fields, Jesse) Date: Fri, 19 Sep 2008 13:24:17 -0700 Subject: [c-nsp] Cisco ZX and HP LH Message-ID: <06D9FD985A42704BB0E8F483ACA3FE2E3EE3243618@miranda.wesd.org> Hello, we have a customer with limited funds that has about an eleven mile fiber run with a Cisco 3750 at one end and a HP 2510-48 at the other. They would like us to try Cisco ZX fiber module to a HP LH (HP's version of ZX) fiber module. I know SX - SX works but would like to know if anyone has successfully gone ZX to LH? Thank you. From svemulap at cisco.com Fri Sep 19 16:31:06 2008 From: svemulap at cisco.com (Shankar Vemulapalli (svemulap)) Date: Fri, 19 Sep 2008 13:31:06 -0700 Subject: [c-nsp] ISIS and CoPP on 760X In-Reply-To: <48D3B953.7040907@renater.fr> References: <48D3ADF2.8020508@renater.fr> <48D3B706.9040501@justinshore.com> <48D3B953.7040907@renater.fr> Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E066C9D6F@xmb-sjc-234.amer.cisco.com> Take a look at the release note of the CSCsb96106 on CCO which offers good config. info. Also, you need to have 'mls qos protocol isis pass-through' global command. http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_m2.html#wp 1014614 Hope it helps. /Shankar -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Frederic LOUI Sent: Friday, September 19, 2008 7:38 AM To: Justin Shore Cc: cisco-nsp Subject: Re: [c-nsp] ISIS and CoPP on 760X Hi, > My understanding is that you have to use class-default to match IS-IS > and a bunch of other things. The Press book "Router Security In terms of security, I prefer to have a strict policy so that in class-default section, I'd rather drop everything that "I'm not aware of". > Strategies" has a good amount of info on CoPP, complete with sample config. I'll try to have a quick look. The cornerstone for me is to identify if "match protocol clns|clns_is|clns_es" is available and can be applied on 760X using 122-33SRC1 so that I can match ISIS pack in my "IGP class" and finally drop/apply low rate to everything in "class-default" Thanks anyway for your pointer. Bgrds/Frederic > > Justin > > Frederic LOUI wrote: >> >> Hi all, >> >> We're currently using Receive-ACL(s) in order to protect as much as >> possible, ingress traffic coming to any router's interface. Actually, >> this is possible on 12K IOS 12.0(32)S8. >> >> As far as I can see in CCO documentation, there is no equivalent to >> receive-acl for 760X... In terms of "Control Plane Protection", it >> seems that CoPP is the way to go ... >> >> In all kind of documentation it is easy to match ospf packet type >> through ACL or the "match protocol ospf" statement. However, I'm >> wondering how to match ISIS packet. (rACL do not filter ISIS packet) >> >> There are several available commands under class-map statement: >> "match protocol clns" >> "match protocol clns_is" >> "match protocol clns_es" >> >> But because of various reasons I can't test these commands. >> (I don't have a 760x test box yet ... ;-) ) >> >> Anyone had any experience with CoPP and ISIS on 760x box ? (Target IOS >> is 122-33.SRC1) >> >> I've seen in the forum's archive that this issue has already >> discussed, but the conclusion is a bit outdated. (Maybe the platform >> has considerably evolved ?? Apology if the question is obvious...) on >> >> Anyway, >> Thanks all in advance for your help, >> >> Bgrds/Frederic >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 Sep 19 16:36:33 2008 From: tdurack at gmail.com (Tim Durack) Date: Fri, 19 Sep 2008 16:36:33 -0400 Subject: [c-nsp] Cisco ZX and HP LH In-Reply-To: <06D9FD985A42704BB0E8F483ACA3FE2E3EE3243618@miranda.wesd.org> References: <06D9FD985A42704BB0E8F483ACA3FE2E3EE3243618@miranda.wesd.org> Message-ID: <9e246b4d0809191336i5c2bec30nfe2603bf13ba866e@mail.gmail.com> Should work - they are both 1550 optics. You might need some attenuators on either side. HP says: "Maximum distance: - 10-70,000 m (singlemode fiber) *Notes* For distances less than 20km, a 10dB attenuator must be used. For distances between 20km and 40km, a 5dB attenuator must be used. Attenuators can be purchased from most cable vendors." Tim:> On Fri, Sep 19, 2008 at 4:24 PM, Fields, Jesse wrote: > Hello, we have a customer with limited funds that has about an eleven mile > fiber run with a Cisco 3750 at one end and a HP 2510-48 at the other. They > would like us to try Cisco ZX fiber module to a HP LH (HP's version of ZX) > fiber module. I know SX - SX works but would like to know if anyone has > successfully gone ZX to LH? > > Thank 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 eric at atlantech.net Fri Sep 19 16:39:29 2008 From: eric at atlantech.net (Eric Van Tol) Date: Fri, 19 Sep 2008 16:39:29 -0400 Subject: [c-nsp] Cisco ZX and HP LH In-Reply-To: <06D9FD985A42704BB0E8F483ACA3FE2E3EE3243618@miranda.wesd.org> References: <06D9FD985A42704BB0E8F483ACA3FE2E3EE3243618@miranda.wesd.org> Message-ID: <2C05E949E19A9146AF7BDF9D44085B86350C3DA478@exchange.aoihq.local> > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Fields, Jesse > Sent: Friday, September 19, 2008 4:24 PM > To: 'cisco-nsp at puck.nether.net' > Subject: [c-nsp] Cisco ZX and HP LH > > Hello, we have a customer with limited funds that has about an eleven mile > fiber run with a Cisco 3750 at one end and a HP 2510-48 at the other. > They would like us to try Cisco ZX fiber module to a HP LH (HP's version > of ZX) fiber module. I know SX - SX works but would like to know if > anyone has successfully gone ZX to LH? > > Thank you. LH/ZX should work fine, assuming the LH *is* really the counterpart to Cisco's ZX. It's best to double-check the specs of each and ensure that they both run at 1550nm. A short distance of 11 miles on a ZX will likely require a 5-10dB attenuator on the receive side of each link, depending on the total optical loss. Someone please correct me if I'm wrong, but I believe you'll want to get your levels down to between -15dB and -20dB. One of the most useful investments you can ever make will be to purchase an optical power meter so you can test the light levels coming in prior to plugging the fiber into your optics. -evt From rekordmeister at gmail.com Fri Sep 19 16:56:25 2008 From: rekordmeister at gmail.com (MKS) Date: Fri, 19 Sep 2008 20:56:25 +0000 Subject: [c-nsp] VPLS and cisco Message-ID: Which cisco boxes do VPLS "out of the box" ? I know about the 7600 uplink line card issues. What about 7200 / 7300 / ASR / GSR etc. Is there any combo of hw / sw that runs VPLS sufficiently stable for an SP and without the mirard of bugs (unlike SRB1/2 for 7600) regards MKS From justin at justinshore.com Fri Sep 19 17:04:26 2008 From: justin at justinshore.com (Justin Shore) Date: Fri, 19 Sep 2008 16:04:26 -0500 Subject: [c-nsp] GRE over IPSec Message-ID: <48D413DA.5010203@justinshore.com> I'm trying to figure out if a router can push a GRE tunnel over top of an IPSec tunnel that's originated on the same router, through an ASA terminating the other end of the IPSec tunnel and to another IOS router behind the ASA. I've seen this done with an ASA at both sites in front of the local router but I've never seen it done with the router originating the IPsec tunnel. Is this possible? Any tips on how to accomplish this? I'm thinking that the tunnel destination should be IOS router at the remote site which should also match the ACL for traffic to a given destination (the remote end of the tunnel). I'm not sure what the order of operations would be though so I'm not sure if the GRE tunnel would end up in the IPSec tunnel. I want to deploy 800-series wifi routers at remote sites (COs, large cabinets, etc) and have them VPN back to our HQ's ASAs and a second backup site. I'd like to run a routing protocol out to them to give them 2 paths into our network over hte 2 tunnels, preferably OSPF in this case. My thought was a simple pair of GRE tunnels through the IPSec tunnels. I could always place an IOS router at the HQ and use it to terminate IPSec-encrypted GRE tunnels. That would add more cost though. I already have one at the backup site though. Suggestions? Thanks Justin From Crist.Clark at globalstar.com Fri Sep 19 17:54:07 2008 From: Crist.Clark at globalstar.com (Crist Clark) Date: Fri, 19 Sep 2008 14:54:07 -0700 Subject: [c-nsp] Cisco 2820 Password Recovery Message-ID: <48D3BD0D.8C45.0097.0@globalstar.com> First off, yes, I know. This is an ancient piece of hardware. No, we're not going to use it in production anywhere. Just a few more ports in the lab already installed nicely in a rack. Yes, it is ancient, so ancient Cisco TAC doesn't seem to want to or is not able to help us with password recovery. But all of the documentation I've found at Cisco and other places says that's what we need to do. The procedure for the "newer" firmware versions (i.e. after 1997 or so) does not seem to work so I'm assuming this is an earlier version that they say requires a call to Cisco. So, am I SOOL, and it's a dumb switch, or is there a way to get in there without Cisco TAC? -- Crist J. Clark crist.clark at globalstar.com Globalstar Communications (408) 933-4387 B?information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster at globalstar.com From dhooper at emerge.net.au Fri Sep 19 19:38:58 2008 From: dhooper at emerge.net.au (Daniel Hooper) Date: Sat, 20 Sep 2008 07:38:58 +0800 Subject: [c-nsp] Cisco 2820 Password Recovery In-Reply-To: <48D3BD0D.8C45.0097.0@globalstar.com> References: <48D3BD0D.8C45.0097.0@globalstar.com> Message-ID: Don?t you mean 2620? 28xx isn?t "ancient" by any means. Sending a break to the console during the router booting is the only way I've known to recover from a lost password. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Crist Clark Sent: Saturday, 20 September 2008 5:54 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Cisco 2820 Password Recovery First off, yes, I know. This is an ancient piece of hardware. No, we're not going to use it in production anywhere. Just a few more ports in the lab already installed nicely in a rack. Yes, it is ancient, so ancient Cisco TAC doesn't seem to want to or is not able to help us with password recovery. But all of the documentation I've found at Cisco and other places says that's what we need to do. The procedure for the "newer" firmware versions (i.e. after 1997 or so) does not seem to work so I'm assuming this is an earlier version that they say requires a call to Cisco. So, am I SOOL, and it's a dumb switch, or is there a way to get in there without Cisco TAC? -- Crist J. Clark crist.clark at globalstar.com Globalstar Communications (408) 933-4387 B?information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster at globalstar.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 cchurc05 at harris.com Fri Sep 19 19:52:53 2008 From: cchurc05 at harris.com (Church, Charles) Date: Fri, 19 Sep 2008 18:52:53 -0500 Subject: [c-nsp] Cisco 2820 Password Recovery In-Reply-To: <48D3BD0D.8C45.0097.0@globalstar.com> References: <48D3BD0D.8C45.0097.0@globalstar.com> Message-ID: Not sure what version you've got, but they talk about it here: http://www.cisco.com/en/US/products/hw/switches/ps574/products_password_recovery09186a00800a6c79.shtml Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Crist Clark Sent: Friday, September 19, 2008 5:54 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Cisco 2820 Password Recovery First off, yes, I know. This is an ancient piece of hardware. No, we're not going to use it in production anywhere. Just a few more ports in the lab already installed nicely in a rack. Yes, it is ancient, so ancient Cisco TAC doesn't seem to want to or is not able to help us with password recovery. But all of the documentation I've found at Cisco and other places says that's what we need to do. The procedure for the "newer" firmware versions (i.e. after 1997 or so) does not seem to work so I'm assuming this is an earlier version that they say requires a call to Cisco. So, am I SOOL, and it's a dumb switch, or is there a way to get in there without Cisco TAC? -- Crist J. Clark crist.clark at globalstar.com Globalstar Communications (408) 933-4387 B?information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster at globalstar.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 Crist.Clark at globalstar.com Fri Sep 19 19:59:47 2008 From: Crist.Clark at globalstar.com (Crist Clark) Date: Fri, 19 Sep 2008 16:59:47 -0700 Subject: [c-nsp] Cisco 2820 Password Recovery In-Reply-To: References: <48D3BD0D.8C45.0097.0@globalstar.com> Message-ID: <48D3DA81.8C45.0097.0@globalstar.com> >>> On 9/19/2008 at 4:38 PM, "Daniel Hooper" wrote: > Don?t you mean 2620? No, I mean Catalyst 2820, http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps597/prod_end-of-life_notice0900aecd8055eb4d.html > Sending a break to the console during the router booting is the only way > I've known to recover from a lost password. The procedure for the later versions involves holding the "MODE" button down on the front of the chassis while doing a cold boot. For the earlier versions, call TAC, http://www.cisco.com/en/US/products/hw/switches/ps574/products_password_recovery09186a00800a6c79.shtml As I said in the original message, this appears to be an earlier version. > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Crist Clark > Sent: Saturday, 20 September 2008 5:54 AM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] Cisco 2820 Password Recovery > > First off, yes, I know. This is an ancient piece of hardware. > No, we're not going to use it in production anywhere. Just a > few more ports in the lab already installed nicely in a rack. > > Yes, it is ancient, so ancient Cisco TAC doesn't seem to want to > or is not able to help us with password recovery. But all of > the documentation I've found at Cisco and other places says > that's what we need to do. The procedure for the "newer" > firmware versions (i.e. after 1997 or so) does not seem to work > so I'm assuming this is an earlier version that they say > requires a call to Cisco. > > So, am I SOOL, and it's a dumb switch, or is there a way to > get in there without Cisco TAC? > -- > > Crist J. Clark > crist.clark at globalstar.com > Globalstar Communications (408) > 933-4387 > > > B?information contained in this e-mail message is confidential, intended > only for the use of the individual or entity named above. If the reader > of this e-mail is not the intended recipient, or the employee or agent > responsible to deliver it to the intended recipient, you are hereby > notified that any review, dissemination, distribution or copying of this > communication is strictly prohibited. If you have received this e-mail > in error, please contact postmaster at globalstar.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/ B?information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster at globalstar.com From christian at broknrobot.com Fri Sep 19 20:53:56 2008 From: christian at broknrobot.com (Christian Koch) Date: Fri, 19 Sep 2008 20:53:56 -0400 Subject: [c-nsp] terminating many l2l tunnels on an ASA In-Reply-To: <48D33CD3.8060607@evaristesys.com> References: <001501c919c6$d8b9bd00$8a2d3700$@com> <48D33CD3.8060607@evaristesys.com> Message-ID: I don't believe that is what he is asking.. The way I interperted his question was If there is a way to consolidate his configuration... Something like using peer-groups and peer-templates with BGP to group identical-configuration-items... If so, I don't know of anyway to do so..but if there is one, would love to know Christian On 9/19/08, Alex Balashov wrote: > Well, the ASAs do have a nice Java GUI with a high level of > sophistication similar to the PIX's and VPN Concentrators. That can > definitely help cut down on management clutter, and is the easier way to > manage an ASA anyhow, seeing as its config format is just as abstruse > and different from everything IOS as PIX. > > Ryan wrote: > >> Hey everyone, question for those of you who may have already suffered this >> unfortunate fate - >> >> >> >> Background: >> >> >> >> I have about 150 site to site VPN tunnels I need to terminate for an ASA. >> Zero (yes, zero) of the remote end devices are Cisco. I do not have any >> control over these devices. Everything is the same except for the remote >> subnets, and obviously the peer IPs. Encryption, PSK, etc. all matching. >> >> >> >> One of the requirements is that the tunnel is able to be brought up by >> generating traffic from my side (kind of shoots down a dynamic L2L I >> -think-) >> >> >> >> I am using a Cisco ASA 5520 with a VPN Plus license. I don't have the >> option >> of purchasing anything else to help with this. >> >> >> >> The actual question: >> >> >> >> Does anyone know of a decent way to bring these up without cluttering my >> config with 1000+ lines of ACL, tunnel-group config, etc? >> >> _______________________________________________ >> 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 > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (706) 338-8599 > _______________________________________________ > 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/ > -- Sent from my mobile device From luan at netcraftsmen.net Fri Sep 19 21:41:22 2008 From: luan at netcraftsmen.net (Luan Nguyen) Date: Fri, 19 Sep 2008 21:41:22 -0400 Subject: [c-nsp] GRE over IPSec In-Reply-To: <48D413DA.5010203@justinshore.com> References: <48D413DA.5010203@justinshore.com> Message-ID: <00bd01c91ac1$fc766e40$f5634ac0$@net> Justin, You could try the following: crypto isakmp policy 10 encr 3des authentication pre-share group 2 crypto isakmp key cisco address j.j.j.j ! ! crypto ipsec transform-set 3dessha esp-3des esp-sha-hmac ! crypto map vpn 10 ipsec-isakmp set peer j.j.j.j set transform-set 3dessha set pfs group1 match address remote ! ip access-list extended remote permit gre host y.y.y.y host z.z.z.z ! interface tunnel0 ip address x.x.x.x tunnel source y.y.y.y tunnel destination z.z.z.z ! interface WAN ip address y.y.y.y crypto map vpn ! router eigrp 1 network x.x.x.x network LAN Where j.j.j.j is the ASA address and z.z.z.z is your router behind it. -Luan ---------------------------------------------------------------------------- ------------------------------------------------------------------------- Luan Nguyen Chesapeake NetCraftsmen, LLC. www.NetCraftsmen.net ---------------------------------------------------------------------------- ------------------------------------------------------------------------ -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Justin Shore Sent: Friday, September 19, 2008 5:04 PM To: 'Cisco-nsp' Subject: [c-nsp] GRE over IPSec I'm trying to figure out if a router can push a GRE tunnel over top of an IPSec tunnel that's originated on the same router, through an ASA terminating the other end of the IPSec tunnel and to another IOS router behind the ASA. I've seen this done with an ASA at both sites in front of the local router but I've never seen it done with the router originating the IPsec tunnel. Is this possible? Any tips on how to accomplish this? I'm thinking that the tunnel destination should be IOS router at the remote site which should also match the ACL for traffic to a given destination (the remote end of the tunnel). I'm not sure what the order of operations would be though so I'm not sure if the GRE tunnel would end up in the IPSec tunnel. I want to deploy 800-series wifi routers at remote sites (COs, large cabinets, etc) and have them VPN back to our HQ's ASAs and a second backup site. I'd like to run a routing protocol out to them to give them 2 paths into our network over hte 2 tunnels, preferably OSPF in this case. My thought was a simple pair of GRE tunnels through the IPSec tunnels. I could always place an IOS router at the HQ and use it to terminate IPSec-encrypted GRE tunnels. That would add more cost though. I already have one at the backup site though. Suggestions? 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 farhan at cyber.net.pk Fri Sep 19 23:35:32 2008 From: farhan at cyber.net.pk (Farhan Ali Khan) Date: Sat, 20 Sep 2008 08:35:32 +0500 Subject: [c-nsp] Cisco 2820 Password Recovery In-Reply-To: <48D3DA81.8C45.0097.0@globalstar.com> Message-ID: <0K7H00GRM37V2G30@smtp.cyber.net.pk> Clark Go through with following http://www-tss.cisco.com/eservice/compass/common/activities/password_cat_190 0.htm For both firmware 1.09 & 1.10 v. Regards Farhan Ali Khan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Crist Clark Sent: 20 September, 2008 5:00 AM To: Daniel Hooper; cisco-nsp Subject: Re: [c-nsp] Cisco 2820 Password Recovery >>> On 9/19/2008 at 4:38 PM, "Daniel Hooper" wrote: > Don?t you mean 2620? No, I mean Catalyst 2820, http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps597/prod_end-of -life_notice0900aecd8055eb4d.html > Sending a break to the console during the router booting is the only way > I've known to recover from a lost password. The procedure for the later versions involves holding the "MODE" button down on the front of the chassis while doing a cold boot. For the earlier versions, call TAC, http://www.cisco.com/en/US/products/hw/switches/ps574/products_password_reco very09186a00800a6c79.shtml As I said in the original message, this appears to be an earlier version. > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Crist Clark > Sent: Saturday, 20 September 2008 5:54 AM > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] Cisco 2820 Password Recovery > > First off, yes, I know. This is an ancient piece of hardware. > No, we're not going to use it in production anywhere. Just a > few more ports in the lab already installed nicely in a rack. > > Yes, it is ancient, so ancient Cisco TAC doesn't seem to want to > or is not able to help us with password recovery. But all of > the documentation I've found at Cisco and other places says > that's what we need to do. The procedure for the "newer" > firmware versions (i.e. after 1997 or so) does not seem to work > so I'm assuming this is an earlier version that they say > requires a call to Cisco. > > So, am I SOOL, and it's a dumb switch, or is there a way to > get in there without Cisco TAC? > -- > > Crist J. Clark > crist.clark at globalstar.com > Globalstar Communications (408) > 933-4387 > > > B?information contained in this e-mail message is confidential, intended > only for the use of the individual or entity named above. If the reader > of this e-mail is not the intended recipient, or the employee or agent > responsible to deliver it to the intended recipient, you are hereby > notified that any review, dissemination, distribution or copying of this > communication is strictly prohibited. If you have received this e-mail > in error, please contact postmaster at globalstar.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/ B?information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster at globalstar.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 farhan at cyber.net.pk Fri Sep 19 23:39:48 2008 From: farhan at cyber.net.pk (Farhan Ali Khan) Date: Sat, 20 Sep 2008 08:39:48 +0500 Subject: [c-nsp] VPLS and cisco In-Reply-To: Message-ID: <0K7H00GBY3EZ2G40@smtp.cyber.net.pk> 7206 and above Regards Farhan Ali Khan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of MKS Sent: 20 September, 2008 1:56 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] VPLS and cisco Which cisco boxes do VPLS "out of the box" ? I know about the 7600 uplink line card issues. What about 7200 / 7300 / ASR / GSR etc. Is there any combo of hw / sw that runs VPLS sufficiently stable for an SP and without the mirard of bugs (unlike SRB1/2 for 7600) regards MKS _______________________________________________ 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 ryanclambert at gmail.com Fri Sep 19 23:27:10 2008 From: ryanclambert at gmail.com (Ryan) Date: Fri, 19 Sep 2008 23:27:10 -0400 Subject: [c-nsp] terminating many l2l tunnels on an ASA In-Reply-To: References: <001501c919c6$d8b9bd00$8a2d3700$@com> <48D33CD3.8060607@evaristesys.com> Message-ID: <001801c91ad0$c575ef10$5061cd30$@com> Yep -- it was a two in one, really. Maybe with a configuration as involved as 150 tunnels and 1000+ lines of text, it's just not feasible to use the CLI without going insane. I've used ASDM a few times and I really just didn't get into it. I suppose it could just be my lack of experience in the GUI, and personal bias toward the CLI in general -- I find it faster to work with in almost all situations. Also, if there is any clever solution, I'd love to hear a way to actually drop this configuration down to something less bloated since the sites are almost identical, albeit not on Cisco hardware. -Ryan -----Original Message----- From: Christian Koch [mailto:christian at broknrobot.com] Sent: Friday, September 19, 2008 8:54 PM To: Alex Balashov; Ryan; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] terminating many l2l tunnels on an ASA I don't believe that is what he is asking.. The way I interperted his question was If there is a way to consolidate his configuration... Something like using peer-groups and peer-templates with BGP to group identical-configuration-items... If so, I don't know of anyway to do so..but if there is one, would love to know Christian On 9/19/08, Alex Balashov wrote: > Well, the ASAs do have a nice Java GUI with a high level of > sophistication similar to the PIX's and VPN Concentrators. That can > definitely help cut down on management clutter, and is the easier way to > manage an ASA anyhow, seeing as its config format is just as abstruse > and different from everything IOS as PIX. > > Ryan wrote: > >> Hey everyone, question for those of you who may have already suffered this >> unfortunate fate - >> >> >> >> Background: >> >> >> >> I have about 150 site to site VPN tunnels I need to terminate for an ASA. >> Zero (yes, zero) of the remote end devices are Cisco. I do not have any >> control over these devices. Everything is the same except for the remote >> subnets, and obviously the peer IPs. Encryption, PSK, etc. all matching. >> >> >> >> One of the requirements is that the tunnel is able to be brought up by >> generating traffic from my side (kind of shoots down a dynamic L2L I >> -think-) >> >> >> >> I am using a Cisco ASA 5520 with a VPN Plus license. I don't have the >> option >> of purchasing anything else to help with this. >> >> >> >> The actual question: >> >> >> >> Does anyone know of a decent way to bring these up without cluttering my >> config with 1000+ lines of ACL, tunnel-group config, etc? >> >> _______________________________________________ >> 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 > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (706) 338-8599 > _______________________________________________ > 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/ > -- Sent from my mobile device From farhan at cyber.net.pk Sat Sep 20 00:43:57 2008 From: farhan at cyber.net.pk (Farhan Ali Khan) Date: Sat, 20 Sep 2008 09:43:57 +0500 Subject: [c-nsp] Switch Module In-Reply-To: <1221844166.11349.8.camel@abehat> Message-ID: <0K7H001AW6DWKF20@smtp.cyber.net.pk> Am not sure but I don't think so there is command in CAT 6513 for module uptime, however MAY BE " sh hw-module slot XX logging" command will work IF CWAN card installed. Cards are hot-swapable check the logs maybe you will get the status from there -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev Sent: 19 September, 2008 10:09 PM To: Ahmed Mohamed Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Switch Module On Fri, 2008-09-19 at 14:45 +0200, Ahmed Mohamed wrote: > i have CS65013 switches with some new modules installed on it due to a > documentation problem, i don't know which module was installed > recently > > is there any command that can give me the uptime of the module? You could try "remote command module X show version", but not all modules support it -- AFAIK they have to have a CFC or DFC. The WS-X6700 modules seem to support it (WS-X6748-GE-TX, WS-X6724-SFP, WS-X6708-10GE do at least). Otherwise you could look at the diagnostics, with "show diagnostics result module X detail". Tests like TestLoopback are not "non-destructive", and thus only performed at bootup (unless you ask for it yourself of course). Looking at when the test was performed can tell you when the module booted. The diagnostics are performed on all switch modules. Regards, Peter _______________________________________________ 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 abalashov at evaristesys.com Sat Sep 20 04:01:43 2008 From: abalashov at evaristesys.com (Alex Balashov) Date: Sat, 20 Sep 2008 04:01:43 -0400 Subject: [c-nsp] terminating many l2l tunnels on an ASA In-Reply-To: <001801c91ad0$c575ef10$5061cd30$@com> References: <001501c919c6$d8b9bd00$8a2d3700$@com> <48D33CD3.8060607@evaristesys.com> <001801c91ad0$c575ef10$5061cd30$@com> Message-ID: <48D4ADE7.2030308@evaristesys.com> I share your bias toward the CLI very strongly and with equal fervour and conviction, for the same reasons. However, the GUI is the only way to maintain very large amounts of rules or tunnels in PIXs or ASAs without wanting to shoot yourself in the face from the sheer length of the config. That is why I advise it. Ryan wrote: > Yep -- it was a two in one, really. > > Maybe with a configuration as involved as 150 tunnels and 1000+ lines of > text, it's just not feasible to use the CLI without going insane. I've used > ASDM a few times and I really just didn't get into it. I suppose it could > just be my lack of experience in the GUI, and personal bias toward the CLI > in general -- I find it faster to work with in almost all situations. > > Also, if there is any clever solution, I'd love to hear a way to actually > drop this configuration down to something less bloated since the sites are > almost identical, albeit not on Cisco hardware. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 From swmike at swm.pp.se Sat Sep 20 06:00:15 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 20 Sep 2008 12:00:15 +0200 (CEST) Subject: [c-nsp] Cisco ZX and HP LH In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B86350C3DA478@exchange.aoihq.local> References: <06D9FD985A42704BB0E8F483ACA3FE2E3EE3243618@miranda.wesd.org> <2C05E949E19A9146AF7BDF9D44085B86350C3DA478@exchange.aoihq.local> Message-ID: On Fri, 19 Sep 2008, Eric Van Tol wrote: > LH/ZX should work fine, assuming the LH *is* really the counterpart to > Cisco's ZX. It'll work with a 1310nm LH towards a 1550nm ZX for shorter distances (usually up to 30km). Just make sure each end has light received within specs and you'll be fine. Receivers are wideband and will take both 1310 and 1550nm light. -- Mikael Abrahamsson email: swmike at swm.pp.se From ranmails at gmail.com Sat Sep 20 06:40:42 2008 From: ranmails at gmail.com (Ran Liebermann) Date: Sat, 20 Sep 2008 13:40:42 +0300 Subject: [c-nsp] Blackholing in MPLS VPNs Message-ID: <8c19328e0809200340h1cb675f6oaf477695c8d69716@mail.gmail.com> Hi All, Common blackholing mechanisms (such as RFC 3882) rely on the next-hop attribute of BGP, such that the next-hop of the announced prefix will remain the same as the static route even through the BGP prefix is locally originated via the redistribute command. This of course works well when the mechanism is operating in the global routing table of the routers. However when trying to operate the mechanism in an MPLS VPN (for example a VPN for internet traffic instead of the global routing table), then the mechanism breaks down becuase the prefixes are announced with the next-hop as the local router. (output examples at the end of the email). Does anyone have a nice and elegant solution to this? Thanks, -- Ran. For example here is the view of the prefix in the announcing router: ANNOUNCING_ROUTER#show ip bgp vpnv4 vrf INTERNET 2.2.2.2 BGP routing table entry for 64512:100:2.2.2.2/32, version 153 Paths: (1 available, best #1, table INTERNET) Flag: 0x820 Advertised to update-groups: 1 Local 192.168.255.255 from 0.0.0.0 (172.17.17.1) Origin IGP, metric 0, localpref 50, weight 32768, valid, sourced, best Community: 64512:65535 Extended Community: RT:64512:100 mpls labels in/out 33/nolabel And here is the view of the prefix in the receiving router: RECEIVING_ROUTER#show ip bgp vpnv4 vrf INTERNET 2.2.2.2 BGP routing table entry for 64512:100:2.2.2.2/32, version 24 Paths: (1 available, best #1, table INTERNET) Flag: 0x820 Not advertised to any peer Local 172.17.17.1 (metric 20) from 172.17.17.1 (172.17.17.1) Origin IGP, metric 0, localpref 50, valid, internal, best Community: 64512:65535 Extended Community: RT:64512:100 mpls labels in/out nolabel/33 -- Ran Liebermann, VP Engineering, PurePeak ranl at purepeak.com http://purepeak.com From cisco-nsp at tracker.fire-world.de Sat Sep 20 11:05:16 2008 From: cisco-nsp at tracker.fire-world.de (Sebastian Wiesinger) Date: Sat, 20 Sep 2008 17:05:16 +0200 Subject: [c-nsp] CoPP Hardware Counters on RSP720/7600 Message-ID: <20080920150516.GA12916@danton.fire-world.de> Hello, I'm implementing a control plane policy for a 7600/RSP720 box. In this policy I have a class-map which matches icmp packets and polices them. That works fine, when I flood-ping the box there are icmp packets lost when the policer drops packets. The only thing that bothers me is that the hardware counters do not count up, only the software counters display an accurate packet count. The box is running 12.2SRC Is there a way to be sure that the packets are policed/dropped in hardware? These are the counters from "show policy-map control-plane input": Hardware Counters: class-map: copp-monitoring (match-any) Match: access-group name copp-monitoring police : 248000 bps 45000 limit 45000 extended limit Earl in slot 5 : 562294 bytes 5 minute offered rate 0 bps aggregate-forwarded 562294 bytes action: transmit exceeded 0 bytes action: drop aggregate-forward 0 bps exceed 0 bps Software Counters: Class-map: copp-monitoring (match-any) 217841 packets, 17517388 bytes 5 minute offered rate 1000 bps, drop rate 0 bps Match: access-group name copp-monitoring 217841 packets, 17517388 bytes 5 minute rate 1000 bps police: cir 250000 bps, bc 45000 bytes, be 45000 bytes conformed 215999 packets, 17336692 bytes; actions: transmit exceeded 459 packets, 44982 bytes; actions: drop violated 1395 packets, 136650 bytes; actions: drop conformed 1000 bps, exceed 0 bps, violate 0 bps #sh class-map copp-monitoring Class Map match-any copp-monitoring (id 3) Match access-group name copp-monitoring #sh access-lists copp-monitoring Extended IP access list copp-monitoring 10 permit icmp any any ttl-exceeded (1 match) 20 permit icmp any any port-unreachable (2 matches) 30 permit icmp any any echo-reply (78 matches) 40 permit icmp any any echo (310459 matches) #sh mls qos ip QoS Summary [IPv4]: (* - shared aggregates, Mod - switch module) Int Mod Dir Class-map DSCP Agg Trust Fl AgForward-By AgPoliced-By Id Id ------------------------------------------------------------------------------- CPP 5 In copp-manag 0 0* No 0 n/a n/a CPP 5 In copp-bgp 0 0* No 0 n/a n/a CPP 5 In copp-ospf 0 0* No 0 n/a n/a CPP 5 In copp-crit- 0 0* No 0 n/a n/a CPP 5 In copp-tunne 0 0* No 0 n/a n/a CPP 5 In copp-monit 0 1 dscp 0 566066 0 CPP 5 In class-defa 0 2 dscp 0 122496813 0 All 5 - Default 0 0* No 0 69655086564 0 Regards, Sebastian -- 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 mtinka at globaltransit.net Sat Sep 20 11:27:42 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Sat, 20 Sep 2008 23:27:42 +0800 Subject: [c-nsp] IS-IS for IPv6: Passive Loopback Interface Address Not Propagated - Update! In-Reply-To: <200809180943.53187.mtinka@globaltransit.net> References: <200809161433.40044.mtinka@globaltransit.net> <200809180943.53187.mtinka@globaltransit.net> Message-ID: <200809202327.47511.mtinka@globaltransit.net> So just an update on this issue; it turned out to be a bug. Bug ID CSCsu67637 has been filed. The problem basically occurs if a v6 address is applied to the Loopback interface ALREADY configured with 'passive-interface Loopback0' under IS-IS (perhaps from a v4 deployment). The workaround is to remove the 'passive-interface Loopback0' after the v6 address is applied, and then re-enter it. This workaround survives reloads, as the v6 address would already exist on the Loopback interface prior to the IS-IS process initializing. 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 avayner at cisco.com Sat Sep 20 12:23:47 2008 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Sat, 20 Sep 2008 18:23:47 +0200 Subject: [c-nsp] Blackholing in MPLS VPNs In-Reply-To: <8c19328e0809200340h1cb675f6oaf477695c8d69716@mail.gmail.com> References: <8c19328e0809200340h1cb675f6oaf477695c8d69716@mail.gmail.com> Message-ID: <67F7C1FAF83A074AA3520D8F155782A501E22B70@xmb-ams-331.emea.cisco.com> Ran, Did you try adding a community to the prefix, and then try to match on it and set next hop locally on the PE? I did not try it, but can try it later in the lab. Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ran Liebermann Sent: Saturday, September 20, 2008 13:41 PM To: cisco-nsp Subject: [c-nsp] Blackholing in MPLS VPNs Hi All, Common blackholing mechanisms (such as RFC 3882) rely on the next-hop attribute of BGP, such that the next-hop of the announced prefix will remain the same as the static route even through the BGP prefix is locally originated via the redistribute command. This of course works well when the mechanism is operating in the global routing table of the routers. However when trying to operate the mechanism in an MPLS VPN (for example a VPN for internet traffic instead of the global routing table), then the mechanism breaks down becuase the prefixes are announced with the next-hop as the local router. (output examples at the end of the email). Does anyone have a nice and elegant solution to this? Thanks, -- Ran. For example here is the view of the prefix in the announcing router: ANNOUNCING_ROUTER#show ip bgp vpnv4 vrf INTERNET 2.2.2.2 BGP routing table entry for 64512:100:2.2.2.2/32, version 153 Paths: (1 available, best #1, table INTERNET) Flag: 0x820 Advertised to update-groups: 1 Local 192.168.255.255 from 0.0.0.0 (172.17.17.1) Origin IGP, metric 0, localpref 50, weight 32768, valid, sourced, best Community: 64512:65535 Extended Community: RT:64512:100 mpls labels in/out 33/nolabel And here is the view of the prefix in the receiving router: RECEIVING_ROUTER#show ip bgp vpnv4 vrf INTERNET 2.2.2.2 BGP routing table entry for 64512:100:2.2.2.2/32, version 24 Paths: (1 available, best #1, table INTERNET) Flag: 0x820 Not advertised to any peer Local 172.17.17.1 (metric 20) from 172.17.17.1 (172.17.17.1) Origin IGP, metric 0, localpref 50, valid, internal, best Community: 64512:65535 Extended Community: RT:64512:100 mpls labels in/out nolabel/33 -- Ran Liebermann, VP Engineering, PurePeak ranl at purepeak.com http://purepeak.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 mtinka at globaltransit.net Sat Sep 20 12:30:53 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Sun, 21 Sep 2008 00:30:53 +0800 Subject: [c-nsp] VPLS and cisco In-Reply-To: <0K7H00GBY3EZ2G40@smtp.cyber.net.pk> References: <0K7H00GBY3EZ2G40@smtp.cyber.net.pk> Message-ID: <200809210031.26344.mtinka@globaltransit.net> On Saturday 20 September 2008 11:39:48 Farhan Ali Khan wrote: > 7206 and above AFAIK, the 7206-VXR doesn't support VPLS. What it does support is the l2vpn AFI for BGP in SRC, although our SE advised us to be careful with it as it's new code in this train. We haven't had to use it yet. 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 david.freedman at uk.clara.net Sat Sep 20 13:26:46 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Sat, 20 Sep 2008 18:26:46 +0100 Subject: [c-nsp] IS-IS for IPv6: Passive Loopback Interface Address Not Propagated - Update! References: <200809161433.40044.mtinka@globaltransit.net> <200809180943.53187.mtinka@globaltransit.net> <200809202327.47511.mtinka@globaltransit.net> Message-ID: Yes, this is exactly what happened to me, I was converting a node, I had to remove it from passive and re-make it passive again to make it work, thanks for getting the bug details. Dave. ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: Mark Tinka [mailto:mtinka at globaltransit.net] Sent: Sat 9/20/2008 16:27 To: cisco-nsp at puck.nether.net Cc: David Freedman Subject: Re: [c-nsp] IS-IS for IPv6: Passive Loopback Interface Address Not Propagated - Update! So just an update on this issue; it turned out to be a bug. Bug ID CSCsu67637 has been filed. The problem basically occurs if a v6 address is applied to the Loopback interface ALREADY configured with 'passive-interface Loopback0' under IS-IS (perhaps from a v4 deployment). The workaround is to remove the 'passive-interface Loopback0' after the v6 address is applied, and then re-enter it. This workaround survives reloads, as the v6 address would already exist on the Loopback interface prior to the IS-IS process initializing. Cheers, Mark. From sthaug at nethelp.no Sat Sep 20 13:47:23 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 20 Sep 2008 19:47:23 +0200 (CEST) Subject: [c-nsp] VPLS and cisco In-Reply-To: <200809210031.26344.mtinka@globaltransit.net> References: <0K7H00GBY3EZ2G40@smtp.cyber.net.pk> <200809210031.26344.mtinka@globaltransit.net> Message-ID: <20080920.194723.74736105.sthaug@nethelp.no> > > 7206 and above > > AFAIK, the 7206-VXR doesn't support VPLS. > > What it does support is the l2vpn AFI for BGP in SRC, > although our SE advised us to be careful with it as it's > new code in this train. We haven't had to use it yet. If you want stable VPLS, over a range of router models, you'll probably have to look at other vendors than Cisco. Personally, I believe VPLS is the wrong solution to most problems it has been proposed for - but that may be just me... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From avayner at cisco.com Sat Sep 20 15:18:15 2008 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Sat, 20 Sep 2008 21:18:15 +0200 Subject: [c-nsp] Blackholing in MPLS VPNs In-Reply-To: <67F7C1FAF83A074AA3520D8F155782A501E22B70@xmb-ams-331.emea.cisco.com> References: <8c19328e0809200340h1cb675f6oaf477695c8d69716@mail.gmail.com> <67F7C1FAF83A074AA3520D8F155782A501E22B70@xmb-ams-331.emea.cisco.com> Message-ID: <67F7C1FAF83A074AA3520D8F155782A501E22B7B@xmb-ams-331.emea.cisco.com> Ran, I just ran it through in my lab. The trick was to set a route-map on the outgoing BGP session for VPNv4 on the originating PE (the one that generates the Null route). On this route-map I matched on an ext-community (I guess it could be a regular one too), and did a set ip next-hop to 192.168.2.1 Then, I have created a static route to 192.168.2.1 on the remote PE both in the global routing table (or else it does not get imported) and then also in the VRF (both pointing to Null0) This is my VRF routing table: R102#show ip route vrf v1 200.1.1.0/32 is subnetted, 2 subnets B 200.1.1.1 [200/0] via 192.168.2.1, 00:03:58 B 200.1.1.2 [200/0] via 1.1.1.2, 00:03:58 192.168.2.0/32 is subnetted, 1 subnets S 192.168.2.1 is directly connected, Null0 Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Arie Vayner (avayner) Sent: Saturday, September 20, 2008 19:24 PM To: ranl at purepeak.com; cisco-nsp Subject: Re: [c-nsp] Blackholing in MPLS VPNs Ran, Did you try adding a community to the prefix, and then try to match on it and set next hop locally on the PE? I did not try it, but can try it later in the lab. Arie -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ran Liebermann Sent: Saturday, September 20, 2008 13:41 PM To: cisco-nsp Subject: [c-nsp] Blackholing in MPLS VPNs Hi All, Common blackholing mechanisms (such as RFC 3882) rely on the next-hop attribute of BGP, such that the next-hop of the announced prefix will remain the same as the static route even through the BGP prefix is locally originated via the redistribute command. This of course works well when the mechanism is operating in the global routing table of the routers. However when trying to operate the mechanism in an MPLS VPN (for example a VPN for internet traffic instead of the global routing table), then the mechanism breaks down becuase the prefixes are announced with the next-hop as the local router. (output examples at the end of the email). Does anyone have a nice and elegant solution to this? Thanks, -- Ran. For example here is the view of the prefix in the announcing router: ANNOUNCING_ROUTER#show ip bgp vpnv4 vrf INTERNET 2.2.2.2 BGP routing table entry for 64512:100:2.2.2.2/32, version 153 Paths: (1 available, best #1, table INTERNET) Flag: 0x820 Advertised to update-groups: 1 Local 192.168.255.255 from 0.0.0.0 (172.17.17.1) Origin IGP, metric 0, localpref 50, weight 32768, valid, sourced, best Community: 64512:65535 Extended Community: RT:64512:100 mpls labels in/out 33/nolabel And here is the view of the prefix in the receiving router: RECEIVING_ROUTER#show ip bgp vpnv4 vrf INTERNET 2.2.2.2 BGP routing table entry for 64512:100:2.2.2.2/32, version 24 Paths: (1 available, best #1, table INTERNET) Flag: 0x820 Not advertised to any peer Local 172.17.17.1 (metric 20) from 172.17.17.1 (172.17.17.1) Origin IGP, metric 0, localpref 50, valid, internal, best Community: 64512:65535 Extended Community: RT:64512:100 mpls labels in/out nolabel/33 -- Ran Liebermann, VP Engineering, PurePeak ranl at purepeak.com http://purepeak.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 alexmoya at bellsouth.net Sat Sep 20 16:04:41 2008 From: alexmoya at bellsouth.net (Alex Moya) Date: Sat, 20 Sep 2008 16:04:41 -0400 Subject: [c-nsp] Switch Module In-Reply-To: <0K7H001AW6DWKF20@smtp.cyber.net.pk> References: <0K7H001AW6DWKF20@smtp.cyber.net.pk> Message-ID: <59A511F5-01F1-4567-B235-B657A33726B7@bellsouth.net> Show hardware Sent from my iPhone On Sep 20, 2008, at 12:43 AM, Farhan Ali Khan wrote: > Am not sure but I don't think so there is command in CAT 6513 for > module > uptime, however MAY BE " sh hw-module slot XX logging" command will > work IF > CWAN card installed. > > Cards are hot-swapable check the logs maybe you will get the status > from > there > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev > Sent: 19 September, 2008 10:09 PM > To: Ahmed Mohamed > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Switch Module > > On Fri, 2008-09-19 at 14:45 +0200, Ahmed Mohamed wrote: >> i have CS65013 switches with some new modules installed on it due >> to a >> documentation problem, i don't know which module was installed >> recently >> >> is there any command that can give me the uptime of the module? > > You could try "remote command module X show version", but not all > modules support it -- AFAIK they have to have a CFC or DFC. The WS- > X6700 > modules seem to support it (WS-X6748-GE-TX, WS-X6724-SFP, WS- > X6708-10GE > do at least). > > Otherwise you could look at the diagnostics, with "show diagnostics > result module X detail". Tests like TestLoopback are not > "non-destructive", and thus only performed at bootup (unless you ask > for > it yourself of course). Looking at when the test was performed can > tell > you when the module booted. > > The diagnostics are performed on all switch modules. > > Regards, > Peter > > > _______________________________________________ > 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 paul at gtcomm.net Sat Sep 20 16:08:04 2008 From: paul at gtcomm.net (Paul) Date: Sat, 20 Sep 2008 16:08:04 -0400 Subject: [c-nsp] sup720 / 6704 RELIABILITY DRIVER / weird ASIC msg (12.2.18 SXF2) In-Reply-To: References: Message-ID: <48D55824.1030304@gtcomm.net> I'm getting the following messages when inserting a WS-X6704-10GE module into a 6509 running 12.2.18 SXF2 sup720-3bxl 00:00:04: %SYS-CFC9-5-RESTART: System restarted -- Cisco Internetwork Operating System Software IOS (tm) c6lc2 Software (c6lc2-SP-M), Version 12.2(18)SXF2, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2006 by cisco Systems, Inc. Compiled Thu 19-Jan-06 04:37 by dchih *Nov 30 00:00:02.723: CFC9: Currently running ROMMON from S (Gold) region - RELIABILITY DRIVER: wrong signature on NVFLASH Sep 20 13:11:49: %DIAG-SP-6-RUN_MINIMUM: Module 9: Running Minimal Diagnostics... Sep 20 13:11:55: %DIAG-SP-6-DIAG_OK: Module 9: Passed Online Diagnostics Sep 20 13:11:55: %OIR-SP-6-INSCARD: Card inserted in slot 9, interfaces are now online Sep 20 13:19:21: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 9 is experiencing the following error: Port Asic 0: 2 important event Sep 20 14:02:51: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 9 is experiencing the following error: Port Asic 0: 1 important event Is this a bug in SXF2? I put the same module into another running SXH3 and I don't get the reliability driver message. Also this ASIC message does not look good but again it doesn't happen on SXH3.. Thanks From ranmails at gmail.com Sat Sep 20 16:35:00 2008 From: ranmails at gmail.com (Ran Liebermann) Date: Sat, 20 Sep 2008 23:35:00 +0300 Subject: [c-nsp] Blackholing in MPLS VPNs In-Reply-To: <67F7C1FAF83A074AA3520D8F155782A501E22B7B@xmb-ams-331.emea.cisco.com> References: <8c19328e0809200340h1cb675f6oaf477695c8d69716@mail.gmail.com> <67F7C1FAF83A074AA3520D8F155782A501E22B70@xmb-ams-331.emea.cisco.com> <67F7C1FAF83A074AA3520D8F155782A501E22B7B@xmb-ams-331.emea.cisco.com> Message-ID: <8c19328e0809201335l67af5483k47b26c30db348f6e@mail.gmail.com> Seems good. I'll try this in my deployment. You know why it's required to make the static route in the receiving router both in the vrf and the global table? Seems a bit odd... Also, I noticed that the announcing router always has this prefix with the 0x820 flag set on, even after a while when all announcements should have been stabalized. Thanks, -- Ran. On Sat, Sep 20, 2008 at 10:18 PM, Arie Vayner (avayner) wrote: > Ran, > > I just ran it through in my lab. > The trick was to set a route-map on the outgoing BGP session for VPNv4 > on the originating PE (the one that generates the Null route). > On this route-map I matched on an ext-community (I guess it could be a > regular one too), and did a set ip next-hop to 192.168.2.1 > > Then, I have created a static route to 192.168.2.1 on the remote PE both > in the global routing table (or else it does not get imported) and then > also in the VRF (both pointing to Null0) > > This is my VRF routing table: > > R102#show ip route vrf v1 > > 200.1.1.0/32 is subnetted, 2 subnets > B 200.1.1.1 [200/0] via 192.168.2.1, 00:03:58 > B 200.1.1.2 [200/0] via 1.1.1.2, 00:03:58 > 192.168.2.0/32 is subnetted, 1 subnets > S 192.168.2.1 is directly connected, Null0 > > Arie > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Arie Vayner > (avayner) > Sent: Saturday, September 20, 2008 19:24 PM > To: ranl at purepeak.com; cisco-nsp > Subject: Re: [c-nsp] Blackholing in MPLS VPNs > > Ran, > > Did you try adding a community to the prefix, and then try to match on > it and set next hop locally on the PE? > I did not try it, but can try it later in the lab. > > Arie > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ran Liebermann > Sent: Saturday, September 20, 2008 13:41 PM > To: cisco-nsp > Subject: [c-nsp] Blackholing in MPLS VPNs > > Hi All, > > Common blackholing mechanisms (such as RFC 3882) rely on the next-hop > attribute of BGP, such that the next-hop of the announced prefix will > remain the same as the static route even through the BGP prefix is > locally originated via the redistribute command. This of course works > well when the mechanism is operating in the global routing table of the > routers. > > However when trying to operate the mechanism in an MPLS VPN (for example > a VPN for internet traffic instead of the global routing table), then > the mechanism breaks down becuase the prefixes are announced with the > next-hop as the local router. (output examples at the end of the email). > > Does anyone have a nice and elegant solution to this? > > Thanks, > -- > Ran. > > > > For example here is the view of the prefix in the announcing router: > > ANNOUNCING_ROUTER#show ip bgp vpnv4 vrf INTERNET 2.2.2.2 BGP routing > table entry for 64512:100:2.2.2.2/32, version 153 > Paths: (1 available, best #1, table INTERNET) > Flag: 0x820 > Advertised to update-groups: > 1 > Local > 192.168.255.255 from 0.0.0.0 (172.17.17.1) > Origin IGP, metric 0, localpref 50, weight 32768, valid, sourced, > best > Community: 64512:65535 > Extended Community: RT:64512:100 > mpls labels in/out 33/nolabel > > And here is the view of the prefix in the receiving router: > > RECEIVING_ROUTER#show ip bgp vpnv4 vrf INTERNET 2.2.2.2 BGP routing > table entry for 64512:100:2.2.2.2/32, version 24 > Paths: (1 available, best #1, table INTERNET) > Flag: 0x820 > Not advertised to any peer > Local > 172.17.17.1 (metric 20) from 172.17.17.1 (172.17.17.1) > Origin IGP, metric 0, localpref 50, valid, internal, best > Community: 64512:65535 > Extended Community: RT:64512:100 > mpls labels in/out nolabel/33 > > > -- > Ran Liebermann, > VP Engineering, PurePeak > ranl at purepeak.com > http://purepeak.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/ > _______________________________________________ > 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/ > -- Ran Liebermann VP Engineering, PurePeak ranl at purepeak.com http://purepeak.com From chunt at reachone.com Sat Sep 20 17:11:43 2008 From: chunt at reachone.com (Christopher Hunt) Date: Sat, 20 Sep 2008 14:11:43 -0700 Subject: [c-nsp] VPLS and cisco Message-ID: <48D5670F.5010604@reachone.com> I'm not aware of the 7206 supporting VPLS (point-to-mulitpoint). They do supprt EoMPLS, which is a point-to-point design. -- Christopher Hunt ------------------------------ Message: 5 Date: Sat, 20 Sep 2008 08:39:48 +0500 From: Farhan Ali Khan Subject: Re: [c-nsp] VPLS and cisco To: "'MKS'" , cisco-nsp at puck.nether.net Message-ID: <0K7H00GBY3EZ2G40 at smtp.cyber.net.pk> Content-Type: text/plain; charset=US-ASCII 7206 and above Regards Farhan Ali Khan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of MKS Sent: 20 September, 2008 1:56 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] VPLS and cisco Which cisco boxes do VPLS "out of the box" ? I know about the 7600 uplink line card issues. What about 7200 / 7300 / ASR / GSR etc. Is there any combo of hw / sw that runs VPLS sufficiently stable for an SP and without the mirard of bugs (unlike SRB1/2 for 7600) regards MKS _______________________________________________ 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 frnkblk at iname.com Sat Sep 20 22:57:15 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 20 Sep 2008 21:57:15 -0500 Subject: [c-nsp] Need 2611 image that support DHCP server and PPPoE client runs on 48 MB DRMA/16 MB flash Message-ID: You would think it would be easy, but I can't find a software load 48 MB or less that contains both DCHP server AND PPPoE client support. Any chance the Software Advisor is wrong and there is such a thing? Frank From avayner at cisco.com Sun Sep 21 03:14:41 2008 From: avayner at cisco.com (Arie Vayner (avayner)) Date: Sun, 21 Sep 2008 09:14:41 +0200 Subject: [c-nsp] Blackholing in MPLS VPNs In-Reply-To: <8c19328e0809201335l67af5483k47b26c30db348f6e@mail.gmail.com> References: <8c19328e0809200340h1cb675f6oaf477695c8d69716@mail.gmail.com> <67F7C1FAF83A074AA3520D8F155782A501E22B70@xmb-ams-331.emea.cisco.com> <67F7C1FAF83A074AA3520D8F155782A501E22B7B@xmb-ams-331.emea.cisco.com> <8c19328e0809201335l67af5483k47b26c30db348f6e@mail.gmail.com> Message-ID: <67F7C1FAF83A074AA3520D8F155782A501E22B9D@xmb-ams-331.emea.cisco.com> Ran, I would assume that the next-hop has to be available through the global routing table, as with any other regular L3 VPN router, as the next-hop is the loopback of the originating PE. If its not reachable, the route is not being imported into the VRF. Arie -----Original Message----- From: Ran Liebermann [mailto:ranmails at gmail.com] Sent: Saturday, September 20, 2008 23:35 PM To: Arie Vayner (avayner) Cc: cisco-nsp Subject: Re: [c-nsp] Blackholing in MPLS VPNs Seems good. I'll try this in my deployment. You know why it's required to make the static route in the receiving router both in the vrf and the global table? Seems a bit odd... Also, I noticed that the announcing router always has this prefix with the 0x820 flag set on, even after a while when all announcements should have been stabalized. Thanks, -- Ran. On Sat, Sep 20, 2008 at 10:18 PM, Arie Vayner (avayner) wrote: > Ran, > > I just ran it through in my lab. > The trick was to set a route-map on the outgoing BGP session for VPNv4 > on the originating PE (the one that generates the Null route). > On this route-map I matched on an ext-community (I guess it could be a > regular one too), and did a set ip next-hop to 192.168.2.1 > > Then, I have created a static route to 192.168.2.1 on the remote PE > both in the global routing table (or else it does not get imported) > and then also in the VRF (both pointing to Null0) > > This is my VRF routing table: > > R102#show ip route vrf v1 > > 200.1.1.0/32 is subnetted, 2 subnets > B 200.1.1.1 [200/0] via 192.168.2.1, 00:03:58 > B 200.1.1.2 [200/0] via 1.1.1.2, 00:03:58 > 192.168.2.0/32 is subnetted, 1 subnets > S 192.168.2.1 is directly connected, Null0 > > Arie > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Arie Vayner > (avayner) > Sent: Saturday, September 20, 2008 19:24 PM > To: ranl at purepeak.com; cisco-nsp > Subject: Re: [c-nsp] Blackholing in MPLS VPNs > > Ran, > > Did you try adding a community to the prefix, and then try to match on > it and set next hop locally on the PE? > I did not try it, but can try it later in the lab. > > Arie > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ran Liebermann > Sent: Saturday, September 20, 2008 13:41 PM > To: cisco-nsp > Subject: [c-nsp] Blackholing in MPLS VPNs > > Hi All, > > Common blackholing mechanisms (such as RFC 3882) rely on the next-hop > attribute of BGP, such that the next-hop of the announced prefix will > remain the same as the static route even through the BGP prefix is > locally originated via the redistribute command. This of course works > well when the mechanism is operating in the global routing table of > the routers. > > However when trying to operate the mechanism in an MPLS VPN (for > example a VPN for internet traffic instead of the global routing > table), then the mechanism breaks down becuase the prefixes are > announced with the next-hop as the local router. (output examples at the end of the email). > > Does anyone have a nice and elegant solution to this? > > Thanks, > -- > Ran. > > > > For example here is the view of the prefix in the announcing router: > > ANNOUNCING_ROUTER#show ip bgp vpnv4 vrf INTERNET 2.2.2.2 BGP routing > table entry for 64512:100:2.2.2.2/32, version 153 > Paths: (1 available, best #1, table INTERNET) > Flag: 0x820 > Advertised to update-groups: > 1 > Local > 192.168.255.255 from 0.0.0.0 (172.17.17.1) > Origin IGP, metric 0, localpref 50, weight 32768, valid, sourced, > best > Community: 64512:65535 > Extended Community: RT:64512:100 > mpls labels in/out 33/nolabel > > And here is the view of the prefix in the receiving router: > > RECEIVING_ROUTER#show ip bgp vpnv4 vrf INTERNET 2.2.2.2 BGP routing > table entry for 64512:100:2.2.2.2/32, version 24 > Paths: (1 available, best #1, table INTERNET) > Flag: 0x820 > Not advertised to any peer > Local > 172.17.17.1 (metric 20) from 172.17.17.1 (172.17.17.1) > Origin IGP, metric 0, localpref 50, valid, internal, best > Community: 64512:65535 > Extended Community: RT:64512:100 > mpls labels in/out nolabel/33 > > > -- > Ran Liebermann, > VP Engineering, PurePeak > ranl at purepeak.com > http://purepeak.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/ > _______________________________________________ > 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/ > -- Ran Liebermann VP Engineering, PurePeak ranl at purepeak.com http://purepeak.com From p.mayers at imperial.ac.uk Sun Sep 21 06:17:40 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Sun, 21 Sep 2008 11:17:40 +0100 Subject: [c-nsp] sup720 / 6704 RELIABILITY DRIVER / weird ASIC msg (12.2.18 SXF2) In-Reply-To: <48D55824.1030304@gtcomm.net> References: <48D55824.1030304@gtcomm.net> Message-ID: <20080921101740.GB408@wildfire.net.ic.ac.uk> On Sat, Sep 20, 2008 at 04:08:04PM -0400, Paul wrote: >I'm getting the following messages when inserting a WS-X6704-10GE module >into a 6509 >running 12.2.18 SXF2 sup720-3bxl > >00:00:04: %SYS-CFC9-5-RESTART: System restarted -- >Cisco Internetwork Operating System Software >IOS (tm) c6lc2 Software (c6lc2-SP-M), Version 12.2(18)SXF2, RELEASE >SOFTWARE (fc1) >Technical Support: http://www.cisco.com/techsupport >Copyright (c) 1986-2006 by cisco Systems, Inc. >Compiled Thu 19-Jan-06 04:37 by dchih >*Nov 30 00:00:02.723: CFC9: Currently running ROMMON from S (Gold) region >- RELIABILITY DRIVER: wrong signature on NVFLASH > >Sep 20 13:11:49: %DIAG-SP-6-RUN_MINIMUM: Module 9: Running Minimal >Diagnostics... >Sep 20 13:11:55: %DIAG-SP-6-DIAG_OK: Module 9: Passed Online Diagnostics >Sep 20 13:11:55: %OIR-SP-6-INSCARD: Card inserted in slot 9, interfaces >are now online >Sep 20 13:19:21: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 9 is >experiencing the following error: Port Asic 0: 2 important event > >Sep 20 14:02:51: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 9 is >experiencing the following error: Port Asic 0: 1 important event > > >Is this a bug in SXF2? I put the same module into another running SXH3 >and I don't get the reliability driver message. Could be the slot; have you tried a different card in the same slot? >Also this ASIC message does not look good but again it doesn't happen on >SXH3.. > >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 Rijas.Ali at dubaiholding.com Sun Sep 21 05:51:07 2008 From: Rijas.Ali at dubaiholding.com (Rijas Ali) Date: Sun, 21 Sep 2008 13:51:07 +0400 Subject: [c-nsp] Cisco CSS 11501 Help Message-ID: <4B4C6EF88DE69842AA91CE78E826F8A8011731BC97@DHLDVEX02.dubai-holding.ezone> Hello Friends, I am trying to get the CSS 11501 to act like a "BUMP" in wire to load balance (BRIDGING) 8 VLANs . In this scenario I am expecting TRUNK configuration ( INSIDE and OUTSIDE Trunk ) on the CSS to make this happen , not the ONE arm configuration . Has anyone a clear clarity on this. I read that ACE appliance can do this . Rijas Ali From perc69 at gmail.com Sun Sep 21 07:02:38 2008 From: perc69 at gmail.com (Pelle) Date: Sun, 21 Sep 2008 13:02:38 +0200 Subject: [c-nsp] Need 2611 image that support DHCP server and PPPoE client runs on 48 MB DRMA/16 MB flash In-Reply-To: References: Message-ID: <746ca6da0809210402j1248d742m1a7e5e517c8aa0ce@mail.gmail.com> Hi. On Sun, Sep 21, 2008 at 04:57, Frank Bulk wrote: > You would think it would be easy, but I can't find a software load 48 MB or > less that contains both DCHP server AND PPPoE client support. > > Any chance the Software Advisor is wrong and there is such a thing? Feature Navigator (www.cisco.com/go/fn) says that 12.3M with "Remote Access Server" feature set should fit (32M RAM/8M Flash). -- Pelle From mack at exchange.alphared.com Sun Sep 21 07:59:06 2008 From: mack at exchange.alphared.com (mack) Date: Sun, 21 Sep 2008 06:59:06 -0500 Subject: [c-nsp] sup720 / 6704 RELIABILITY DRIVER / weird ASIC msg In-Reply-To: References: Message-ID: <6F2FFD7C10F788479E354B84294036C459425769@EXCH-MBX.exchange.alphared.local> It could be a bug in SXF2. It could be a bad port asic 0 or bad fabric channel. It could even be the card is incorrectly seating. It could also be an incompatible ROMMON version. 12.2(18r)S1 is recommended for SXH. SXF2 would not recognize this signature as the ROMMON wasn't released when SXF2 was. 12.2(14r)S5 is probably better for SXF2. >From what you show the module is running with the default ROMMON version. You can determine the ROMMON version with 'show module' The first thing TACS will tell you is upgrade your IOS version. SXF2 is ancient and buggy. -- LR Mack McBride Network Administrator Alpha Red, Inc. > > Message: 1 > Date: Sat, 20 Sep 2008 16:08:04 -0400 > From: Paul > Subject: [c-nsp] sup720 / 6704 RELIABILITY DRIVER / weird ASIC msg > (12.2.18 SXF2) > To: cisco-nsp at puck.nether.net > Message-ID: <48D55824.1030304 at gtcomm.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I'm getting the following messages when inserting a WS-X6704-10GE > module > into a 6509 > running 12.2.18 SXF2 sup720-3bxl > > 00:00:04: %SYS-CFC9-5-RESTART: System restarted -- > Cisco Internetwork Operating System Software > IOS (tm) c6lc2 Software (c6lc2-SP-M), Version 12.2(18)SXF2, RELEASE > SOFTWARE (fc1) > Technical Support: http://www.cisco.com/techsupport > Copyright (c) 1986-2006 by cisco Systems, Inc. > Compiled Thu 19-Jan-06 04:37 by dchih > *Nov 30 00:00:02.723: CFC9: Currently running ROMMON from S (Gold) > region > - RELIABILITY DRIVER: wrong signature on NVFLASH > > Sep 20 13:11:49: %DIAG-SP-6-RUN_MINIMUM: Module 9: Running Minimal > Diagnostics... > Sep 20 13:11:55: %DIAG-SP-6-DIAG_OK: Module 9: Passed Online > Diagnostics > Sep 20 13:11:55: %OIR-SP-6-INSCARD: Card inserted in slot 9, interfaces > are now online > Sep 20 13:19:21: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 9 is > experiencing the following error: Port Asic 0: 2 important event > > Sep 20 14:02:51: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 9 is > experiencing the following error: Port Asic 0: 1 important event > > > Is this a bug in SXF2? I put the same module into another running SXH3 > and I don't get the reliability driver message. > Also this ASIC message does not look good but again it doesn't happen > on > SXH3.. > > Thanks > > From eric at atlantech.net Sun Sep 21 08:33:35 2008 From: eric at atlantech.net (Eric Van Tol) Date: Sun, 21 Sep 2008 08:33:35 -0400 Subject: [c-nsp] Cisco ZX and HP LH In-Reply-To: References: <06D9FD985A42704BB0E8F483ACA3FE2E3EE3243618@miranda.wesd.org> <2C05E949E19A9146AF7BDF9D44085B86350C3DA478@exchange.aoihq.local> Message-ID: <2C05E949E19A9146AF7BDF9D44085B86350C3DA47A@exchange.aoihq.local> > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] > Sent: Saturday, September 20, 2008 6:00 AM > To: Eric Van Tol > Cc: 'Fields, Jesse'; 'cisco-nsp at puck.nether.net' > Subject: Re: [c-nsp] Cisco ZX and HP LH > > On Fri, 19 Sep 2008, Eric Van Tol wrote: > > > LH/ZX should work fine, assuming the LH *is* really the counterpart to > > Cisco's ZX. > > It'll work with a 1310nm LH towards a 1550nm ZX for shorter distances > (usually up to 30km). Just make sure each end has light received within > specs and you'll be fine. Receivers are wideband and will take both 1310 > and 1550nm light. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se That's all fine and dandy, but I'm not sure I would trust this in a production environment. Perhaps in a pinch, but not long term. Not only is it not "officially supported", but trying to troubleshoot or replace parts if one of the SFPs fails, might get...confusing. -evt From simon.leinen at switch.ch Sun Sep 21 08:52:04 2008 From: simon.leinen at switch.ch (Simon Leinen) Date: Sun, 21 Sep 2008 14:52:04 +0200 Subject: [c-nsp] SRC2? In-Reply-To: <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com> (Ran Liebermann's message of "Tue, 16 Sep 2008 20:50:50 +0300") References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <48A2FF3B.5030104@gatlan.nl> <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com> Message-ID: SRC2 just appeared on CCO. Release notes: http://www.cisco.com/en/US/docs/ios/12_2sr/release/notes/122SRrn.html -- Simon. From frnkblk at iname.com Sun Sep 21 09:46:33 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 21 Sep 2008 08:46:33 -0500 Subject: [c-nsp] Need 2611 image that support DHCP server and PPPoE client runs on 48 MB DRMA/16 MB flash In-Reply-To: <746ca6da0809210402j1248d742m1a7e5e517c8aa0ce@mail.gmail.com> References: <746ca6da0809210402j1248d742m1a7e5e517c8aa0ce@mail.gmail.com> Message-ID: Thanks! When I used the Software Advisor by specifying the hardware platform and two features, it never listed the "Remote Access Server", just "Enterprise Plus". One of the many foibles of the SA. Frank -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Pelle Sent: Sunday, September 21, 2008 6:03 AM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Need 2611 image that support DHCP server and PPPoE client runs on 48 MB DRMA/16 MB flash Hi. On Sun, Sep 21, 2008 at 04:57, Frank Bulk wrote: > You would think it would be easy, but I can't find a software load 48 MB or > less that contains both DCHP server AND PPPoE client support. > > Any chance the Software Advisor is wrong and there is such a thing? Feature Navigator (www.cisco.com/go/fn) says that 12.3M with "Remote Access Server" feature set should fit (32M RAM/8M Flash). -- Pelle _______________________________________________ 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 Sun Sep 21 10:29:17 2008 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Sun, 21 Sep 2008 15:29:17 +0100 Subject: [c-nsp] sup720 / 6704 RELIABILITY DRIVER / weird ASIC msg In-Reply-To: <6F2FFD7C10F788479E354B84294036C459425769@EXCH-MBX.exchange.alphared.local> References: <6F2FFD7C10F788479E354B84294036C459425769@EXCH-MBX.exchange.alphared.local> Message-ID: <20080921142917.GB23149@lboro.ac.uk> Hi, > The first thing TACS will tell you is upgrade your IOS version. > SXF2 is ancient and buggy. aye. and SXH3 is new and buggy 8-) alan From rubensk at gmail.com Sun Sep 21 10:44:56 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Sun, 21 Sep 2008 11:44:56 -0300 Subject: [c-nsp] SRC2? In-Reply-To: References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <48A2FF3B.5030104@gatlan.nl> <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com> Message-ID: <6bb5f5b10809210744y3a2c13a9k9654cef31963df6f@mail.gmail.com> But no SXH3a or SHX4 yet... :-( Is SRC2 available to download or just the release notes ? SXHn has been recently released weeks after it appeared on release notes. Rubens On Sun, Sep 21, 2008 at 9:52 AM, Simon Leinen wrote: > SRC2 just appeared on CCO. Release notes: > > http://www.cisco.com/en/US/docs/ios/12_2sr/release/notes/122SRrn.html > -- > Simon. > _______________________________________________ > 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 spinthiras.mario at gmail.com Sun Sep 21 13:36:07 2008 From: spinthiras.mario at gmail.com (Mario Spinthiras) Date: Sun, 21 Sep 2008 20:36:07 +0300 Subject: [c-nsp] IPV6 IPAM Message-ID: <4f890e580809211036q1c3a2ddwc8593f3e775050ca@mail.gmail.com> Greetings, First off forgive me if I am a bit off topic but I needed a list where people from the ISP/NSP sector reside and what better place than the cisco mailing list. I am currently in the works of developing an open source ipv6 IPAM with extensive features aimed at the ISP/NSP userbase. Working in ISPs mostly in my career I understand the needs that have to be addressed in such a piece of software however I would like to hear what you need from such an IPAM. Some of the features I am targetting are: - IPv6 addreess management - Automated retrieval of networks from network devices. - Device Inventory - Basic monitoring - Visual representation of address database - Statistics generation for RIPE/ARIN (Im sure youve needed these before) - Special associations per network (e.g , vrfs , vlans) - Multi Level authentication - IPv4 management (still thinking about this one) - DNS management (bind and powerdns) - DHCP management (ISC and Cisco) - VTP/CDP/LLDP/GARP aware. - Modular design to allow plugins The software is currently in the works and I am happy to say that it also includes an easy navigation , extensive search , clean UI and clever suggestions on action. Can anyone from the ISP/NSP sector tell me what else they would like to see in such an IPAM or what they feel would be a feature suited ? Your extensive feedback is greatly apreciated. Regards, Mario From gert at greenie.muc.de Sat Sep 20 15:29:53 2008 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 20 Sep 2008 21:29:53 +0200 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <1221845016.11349.15.camel@abehat> References: <20080915145013.GA2245@greenie.muc.de> <1221508568.7357.15.camel@localhost> <48CEC162.5000105@bytemark.co.uk> <20080916040858.GA17256@greenie.muc.de> <48CFC183.4060401@bytemark.co.uk> <20080916165849.GA20288@greenie.muc.de> <20080918201316.GD20288@greenie.muc.de> <20080919003643.GB79009@puck.nether.net> <20080919165126.GA11635@greenie.muc.de> <1221845016.11349.15.camel@abehat> Message-ID: <20080920192953.GD7160@greenie.muc.de> Hi, On Fri, Sep 19, 2008 at 07:23:36PM +0200, Peter Rathlev wrote: > CSCsu59917 > SXF15: IPv4/v6 BGP routes not cleared when source routes is gone > Severity: 1 - catastrophic. Indeed... makes me wonder why they are not doing an SXH rebuild on their own, instead of making us wait 4-6 weeks for a bugfix for a *catastrophic* (!!) bug. (No news from our case yet regarding an interim rebuild) thanks, gert -- Gert Doering Mobile communications ... right now writing from * Sardegna, Italy * From paul at paulstewart.org Sun Sep 21 19:21:29 2008 From: paul at paulstewart.org (Paul Stewart) Date: Sun, 21 Sep 2008 19:21:29 -0400 Subject: [c-nsp] IPV6 IPAM In-Reply-To: <4f890e580809211036q1c3a2ddwc8593f3e775050ca@mail.gmail.com> References: <4f890e580809211036q1c3a2ddwc8593f3e775050ca@mail.gmail.com> Message-ID: <000001c91c40$cd75e4b0$6861ae10$@org> Hi there.... I think IPv4 management in the same tool is important if you're looking for opinions. The other nice thing would be automated handling of ARIN SWIP's .. the DNS/DHCP management is a nice tool but not something in our setup we'd use. The basic monitoring and device inventory is handled by other packages today.... Just some constructive feedback - we've been looking for an IPv6 IPAM for a while now..;) Paul -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mario Spinthiras Sent: September 21, 2008 1:36 PM To: cisco-nsp Subject: [c-nsp] IPV6 IPAM Greetings, First off forgive me if I am a bit off topic but I needed a list where people from the ISP/NSP sector reside and what better place than the cisco mailing list. I am currently in the works of developing an open source ipv6 IPAM with extensive features aimed at the ISP/NSP userbase. Working in ISPs mostly in my career I understand the needs that have to be addressed in such a piece of software however I would like to hear what you need from such an IPAM. Some of the features I am targetting are: - IPv6 addreess management - Automated retrieval of networks from network devices. - Device Inventory - Basic monitoring - Visual representation of address database - Statistics generation for RIPE/ARIN (Im sure youve needed these before) - Special associations per network (e.g , vrfs , vlans) - Multi Level authentication - IPv4 management (still thinking about this one) - DNS management (bind and powerdns) - DHCP management (ISC and Cisco) - VTP/CDP/LLDP/GARP aware. - Modular design to allow plugins The software is currently in the works and I am happy to say that it also includes an easy navigation , extensive search , clean UI and clever suggestions on action. Can anyone from the ISP/NSP sector tell me what else they would like to see in such an IPAM or what they feel would be a feature suited ? Your extensive feedback is greatly apreciated. Regards, Mario _______________________________________________ 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 ross at kallisti.us Sun Sep 21 19:36:28 2008 From: ross at kallisti.us (Ross Vandegrift) Date: Sun, 21 Sep 2008 19:36:28 -0400 Subject: [c-nsp] sup720 / 6704 RELIABILITY DRIVER / weird ASIC msg (12.2.18 SXF2) In-Reply-To: <48D55824.1030304@gtcomm.net> References: <48D55824.1030304@gtcomm.net> Message-ID: <20080921233628.GA29185@kallisti.us> On Sat, Sep 20, 2008 at 04:08:04PM -0400, Paul wrote: > I'm getting the following messages when inserting a WS-X6704-10GE module > into a 6509 > running 12.2.18 SXF2 sup720-3bxl > > 00:00:04: %SYS-CFC9-5-RESTART: System restarted -- > Cisco Internetwork Operating System Software > IOS (tm) c6lc2 Software (c6lc2-SP-M), Version 12.2(18)SXF2, RELEASE > SOFTWARE (fc1) > Technical Support: http://www.cisco.com/techsupport > Copyright (c) 1986-2006 by cisco Systems, Inc. > Compiled Thu 19-Jan-06 04:37 by dchih > *Nov 30 00:00:02.723: CFC9: Currently running ROMMON from S (Gold) region > - RELIABILITY DRIVER: wrong signature on NVFLASH A co-worker reported the same message to me on Friday from a lab switch running SXD7b when he inserted a 6704-10GE w/dfc3bxl. Do you have redundant sups in the switch? This message is in our logs: 00:00:24: %SYS-DFC4-5-RESTART: System restarted -- Cisco Internetwork Operating System Software IOS (tm) c6lc2 Software (c6lc2-SP-M), Version 12.2(18)SXD7b, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2006 by cisco Systems, Inc. Compiled Fri 08-Dec-06 12:34 by ccai 00:00:24: DFC4: Currently running ROMMON from S (Gold) region - RELIABILITY DRIVER: wrong signature on NVFLASH 00:18:40: SP: Disabling standby fabric in slot 6 and allowing module in slot 4 to go ONLINE as it's fabric channels could not sync with the standby but synced with the active fabric 00:18:40: %OIR-SP-3-PWRCYCLE: Card in module 6, is being power-cycled off (Fabric channel errors) 00:18:42: %PFREDUN-SP-6-ACTIVE: Standby processor removed or reloaded, changing to Simplex mode 00:18:43: %DIAG-SP-6-RUN_MINIMUM: Module 4: Running Minimum Diagnostics... 00:18:54: %DIAG-SP-6-DIAG_OK: Module 4: Passed Online Diagnostics > Sep 20 13:19:21: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 9 is > experiencing the following error: Port Asic 0: 2 important event > > Sep 20 14:02:51: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 9 is > experiencing the following error: Port Asic 0: 1 important event I don't see any instances of this, so it could be different. > Is this a bug in SXF2? I put the same module into another running SXH3 > and I don't get the reliability driver message. > Also this ASIC message does not look good but again it doesn't happen on > SXH3.. > > 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/ -- Ross Vandegrift ross at kallisti.us "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 From mtinka at globaltransit.net Sun Sep 21 12:55:32 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Mon, 22 Sep 2008 00:55:32 +0800 Subject: [c-nsp] SRC2? In-Reply-To: <6bb5f5b10809210744y3a2c13a9k9654cef31963df6f@mail.gmail.com> References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <6bb5f5b10809210744y3a2c13a9k9654cef31963df6f@mail.gmail.com> Message-ID: <200809220055.38375.mtinka@globaltransit.net> On Sunday 21 September 2008 22:44:56 Rubens Kuhl Jr. wrote: > Is SRC2 available to download or just the release notes ? Yes. 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 ray at oneunified.net Sun Sep 21 20:42:18 2008 From: ray at oneunified.net (Ray Burkholder) Date: Sun, 21 Sep 2008 21:42:18 -0300 Subject: [c-nsp] IPV6 IPAM In-Reply-To: <000001c91c40$cd75e4b0$6861ae10$@org> References: <4f890e580809211036q1c3a2ddwc8593f3e775050ca@mail.gmail.com> <000001c91c40$cd75e4b0$6861ae10$@org> Message-ID: <003f01c91c4c$11d2a700$0202fea9@oneunified.local> > The software is currently in the works and I am happy to say > that it also includes an easy navigation , extensive search , > clean UI and clever suggestions on action. > Is a preview available? -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean. From paul at gtcomm.net Sun Sep 21 22:26:20 2008 From: paul at gtcomm.net (Paul) Date: Sun, 21 Sep 2008 22:26:20 -0400 Subject: [c-nsp] sup720 / 6704 RELIABILITY DRIVER / weird ASIC msg (12.2.18 SXF2) In-Reply-To: <20080921233628.GA29185@kallisti.us> References: <48D55824.1030304@gtcomm.net> <20080921233628.GA29185@kallisti.us> Message-ID: <48D7024C.6040306@gtcomm.net> Single sup720-3bxl. Tried different slot, even tried an entire different 6509 with same IOS SXF2.. Maybe something with the IOS, or a hardware revision of the chassis or sup module? Looking it up on the search gets no results :/ I got the same message you got, except it didn't contain the fabric channel sync error, just the power off error, and this was with ANOTHER 6704 module.. So two 6704 modules I tried , each different errors, would not work in either 6509 I have running SXF2. I got no errors putting it in a 6513, with SXH3 on it.. Will try SXF14, but I'm getting some TCAM errors with it which I'm about to post about :) Paul Ross Vandegrift wrote: > On Sat, Sep 20, 2008 at 04:08:04PM -0400, Paul wrote: > >> I'm getting the following messages when inserting a WS-X6704-10GE module >> into a 6509 >> running 12.2.18 SXF2 sup720-3bxl >> >> 00:00:04: %SYS-CFC9-5-RESTART: System restarted -- >> Cisco Internetwork Operating System Software >> IOS (tm) c6lc2 Software (c6lc2-SP-M), Version 12.2(18)SXF2, RELEASE >> SOFTWARE (fc1) >> Technical Support: http://www.cisco.com/techsupport >> Copyright (c) 1986-2006 by cisco Systems, Inc. >> Compiled Thu 19-Jan-06 04:37 by dchih >> *Nov 30 00:00:02.723: CFC9: Currently running ROMMON from S (Gold) region >> - RELIABILITY DRIVER: wrong signature on NVFLASH >> > > A co-worker reported the same message to me on Friday from a lab > switch running SXD7b when he inserted a 6704-10GE w/dfc3bxl. > > Do you have redundant sups in the switch? This message is in our > logs: > > 00:00:24: %SYS-DFC4-5-RESTART: System restarted -- > Cisco Internetwork Operating System Software > IOS (tm) c6lc2 Software (c6lc2-SP-M), Version 12.2(18)SXD7b, RELEASE SOFTWARE (fc1) > Technical Support: http://www.cisco.com/techsupport > Copyright (c) 1986-2006 by cisco Systems, Inc. > Compiled Fri 08-Dec-06 12:34 by ccai > 00:00:24: DFC4: Currently running ROMMON from S (Gold) region > - RELIABILITY DRIVER: wrong signature on NVFLASH > > 00:18:40: SP: Disabling standby fabric in slot 6 and allowing module in slot 4 to go ONLINE as it's fabric channels could not sync with the standby but synced with the active fabric > > 00:18:40: %OIR-SP-3-PWRCYCLE: Card in module 6, is being power-cycled off (Fabric channel errors) > 00:18:42: %PFREDUN-SP-6-ACTIVE: Standby processor removed or reloaded, changing to Simplex mode > 00:18:43: %DIAG-SP-6-RUN_MINIMUM: Module 4: Running Minimum Diagnostics... > 00:18:54: %DIAG-SP-6-DIAG_OK: Module 4: Passed Online Diagnostics > > > >> Sep 20 13:19:21: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 9 is >> experiencing the following error: Port Asic 0: 2 important event >> >> Sep 20 14:02:51: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 9 is >> experiencing the following error: Port Asic 0: 1 important event >> > > I don't see any instances of this, so it could be different. > > >> Is this a bug in SXF2? I put the same module into another running SXH3 >> and I don't get the reliability driver message. >> Also this ASIC message does not look good but again it doesn't happen on >> SXH3.. >> >> 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/ >> > > -- GloboTech Communications Phone: 1-514-907-0050 Toll Free: 1-(888)-GTCOMM1 Fax: 1-(514)-907-0750 paul at gtcomm.net http://www.gtcomm.net From swmike at swm.pp.se Mon Sep 22 00:57:43 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 22 Sep 2008 06:57:43 +0200 (CEST) Subject: [c-nsp] Cisco ZX and HP LH In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B86350C3DA47A@exchange.aoihq.local> References: <06D9FD985A42704BB0E8F483ACA3FE2E3EE3243618@miranda.wesd.org> <2C05E949E19A9146AF7BDF9D44085B86350C3DA478@exchange.aoihq.local> <2C05E949E19A9146AF7BDF9D44085B86350C3DA47A@exchange.aoihq.local> Message-ID: On Sun, 21 Sep 2008, Eric Van Tol wrote: > That's all fine and dandy, but I'm not sure I would trust this in a > production environment. Perhaps in a pinch, but not long term. Not > only is it not "officially supported", but trying to troubleshoot or > replace parts if one of the SFPs fails, might get...confusing. That's all up to you and your organization. And about it being officially supported, it all depends on whether the receiver is specced by the support holder as 1300-1600nm, or whether they're specced more tightly. If indeed specced 1300-1600nm at both ends, I don't see what's unsupported in it. -- Mikael Abrahamsson email: swmike at swm.pp.se From brad.henshaw at qcn.com.au Mon Sep 22 01:39:47 2008 From: brad.henshaw at qcn.com.au (Brad Henshaw) Date: Mon, 22 Sep 2008 15:39:47 +1000 Subject: [c-nsp] Cisco ZX and HP LH Message-ID: <8B25B862BC09784B9B74FB950D4F64D406C985@qcnapp01.corp.qcn> Mikael Abrahamsson wrote: > If indeed specced 1300-1600nm at both ends, I don't see what's > unsupported in it. The thought of trying to explain this to the TAC when they notice discrepancies in some 'show tech-support' output or similar is enough to make me retreat to a quiet corner to whimper. And not do this. (except maybe _temporarily_ when in a bind) Regards, Brad From gulerozgur at yahoo.co.uk Mon Sep 22 08:31:03 2008 From: gulerozgur at yahoo.co.uk (Ozgur Guler) Date: Mon, 22 Sep 2008 12:31:03 +0000 (GMT) Subject: [c-nsp] CoPP Hardware Counters on RSP720/7600 In-Reply-To: <20080920150516.GA12916@danton.fire-world.de> Message-ID: <269424.43452.qm@web25503.mail.ukl.yahoo.com> Hi Sebastian, Have you confirmed that mls qos is enabled globally? CoPP needs mls qos in order to work in HW. Thanks Ozgur --- On Sat, 20/9/08, Sebastian Wiesinger wrote: From: Sebastian Wiesinger Subject: [c-nsp] CoPP Hardware Counters on RSP720/7600 To: cisco-nsp at puck.nether.net Date: Saturday, 20 September, 2008, 4:05 PM Hello, I'm implementing a control plane policy for a 7600/RSP720 box. In this policy I have a class-map which matches icmp packets and polices them. That works fine, when I flood-ping the box there are icmp packets lost when the policer drops packets. The only thing that bothers me is that the hardware counters do not count up, only the software counters display an accurate packet count. The box is running 12.2SRC Is there a way to be sure that the packets are policed/dropped in hardware? These are the counters from "show policy-map control-plane input": Hardware Counters: class-map: copp-monitoring (match-any) Match: access-group name copp-monitoring police : 248000 bps 45000 limit 45000 extended limit Earl in slot 5 : 562294 bytes 5 minute offered rate 0 bps aggregate-forwarded 562294 bytes action: transmit exceeded 0 bytes action: drop aggregate-forward 0 bps exceed 0 bps Software Counters: Class-map: copp-monitoring (match-any) 217841 packets, 17517388 bytes 5 minute offered rate 1000 bps, drop rate 0 bps Match: access-group name copp-monitoring 217841 packets, 17517388 bytes 5 minute rate 1000 bps police: cir 250000 bps, bc 45000 bytes, be 45000 bytes conformed 215999 packets, 17336692 bytes; actions: transmit exceeded 459 packets, 44982 bytes; actions: drop violated 1395 packets, 136650 bytes; actions: drop conformed 1000 bps, exceed 0 bps, violate 0 bps #sh class-map copp-monitoring Class Map match-any copp-monitoring (id 3) Match access-group name copp-monitoring #sh access-lists copp-monitoring Extended IP access list copp-monitoring 10 permit icmp any any ttl-exceeded (1 match) 20 permit icmp any any port-unreachable (2 matches) 30 permit icmp any any echo-reply (78 matches) 40 permit icmp any any echo (310459 matches) #sh mls qos ip QoS Summary [IPv4]: (* - shared aggregates, Mod - switch module) Int Mod Dir Class-map DSCP Agg Trust Fl AgForward-By AgPoliced-By Id Id ------------------------------------------------------------------------------- CPP 5 In copp-manag 0 0* No 0 n/a n/a CPP 5 In copp-bgp 0 0* No 0 n/a n/a CPP 5 In copp-ospf 0 0* No 0 n/a n/a CPP 5 In copp-crit- 0 0* No 0 n/a n/a CPP 5 In copp-tunne 0 0* No 0 n/a n/a CPP 5 In copp-monit 0 1 dscp 0 566066 0 CPP 5 In class-defa 0 2 dscp 0 122496813 0 All 5 - Default 0 0* No 0 69655086564 0 Regards, Sebastian -- 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 _______________________________________________ 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 dgranzer at gmail.com Mon Sep 22 08:54:37 2008 From: dgranzer at gmail.com (David Granzer) Date: Mon, 22 Sep 2008 14:54:37 +0200 Subject: [c-nsp] CoPP Hardware Counters on RSP720/7600 In-Reply-To: <269424.43452.qm@web25503.mail.ukl.yahoo.com> References: <20080920150516.GA12916@danton.fire-world.de> <269424.43452.qm@web25503.mail.ukl.yahoo.com> Message-ID: <844ef89c0809220554l2cd34a40y290de75ec9d36b2e@mail.gmail.com> Hello, I have the same output on RSP720-3CXL with mls qos enabled. RSP720#sh mls qos QoS is enabled globally RSP720#sh policy-map control-plane input class copp-management Control Plane Service-policy input: control-plane-in Hardware Counters: class-map: copp-management (match-any) Match: access-group name coppacl-management-in Software Counters: Class-map: copp-management (match-any) 470321 packets, 31043704 bytes 5 minute offered rate 0 bps Match: access-group name coppacl-management-in 470321 packets, 31043704 bytes 5 minute rate 0 bps Regards, David On 9/22/08, Ozgur Guler wrote: > Hi Sebastian, > > Have you confirmed that mls qos is enabled globally? > CoPP needs mls qos in order to work in HW. > > Thanks > Ozgur > > --- On Sat, 20/9/08, Sebastian Wiesinger wrote: > From: Sebastian Wiesinger > Subject: [c-nsp] CoPP Hardware Counters on RSP720/7600 > To: cisco-nsp at puck.nether.net > Date: Saturday, 20 September, 2008, 4:05 PM > > > Hello, > > I'm implementing a control plane policy for a 7600/RSP720 box. In this > policy I have a class-map which matches icmp packets and polices them. > That works fine, when I flood-ping the box there are icmp packets lost > when the policer drops packets. The only thing that bothers me is that > the hardware counters do not count up, only the software counters > display an accurate packet count. The box is running 12.2SRC > > Is there a way to be sure that the packets are policed/dropped in > hardware? > > These are the counters from "show policy-map control-plane input": > > Hardware Counters: > > > > class-map: copp-monitoring (match-any) > > Match: access-group name copp-monitoring > > police : > > 248000 bps 45000 limit 45000 extended limit > > Earl in slot 5 : > > 562294 bytes > > 5 minute offered rate 0 bps > > aggregate-forwarded 562294 bytes action: transmit > > exceeded 0 bytes action: drop > > aggregate-forward 0 bps exceed 0 bps > > > > Software Counters: > > > > Class-map: copp-monitoring (match-any) > > 217841 packets, 17517388 bytes > > 5 minute offered rate 1000 bps, drop rate 0 bps > > Match: access-group name copp-monitoring > > 217841 packets, 17517388 bytes > > 5 minute rate 1000 bps > > police: > > cir 250000 bps, bc 45000 bytes, be 45000 bytes > > conformed 215999 packets, 17336692 bytes; actions: > > transmit > > exceeded 459 packets, 44982 bytes; actions: > > drop > > violated 1395 packets, 136650 bytes; actions: > > drop > > conformed 1000 bps, exceed 0 bps, violate 0 bps > > > > #sh class-map copp-monitoring > > Class Map match-any copp-monitoring (id 3) > Match access-group name copp-monitoring > > #sh access-lists copp-monitoring > Extended IP access list copp-monitoring > 10 permit icmp any any ttl-exceeded (1 match) > 20 permit icmp any any port-unreachable (2 matches) > 30 permit icmp any any echo-reply (78 matches) > 40 permit icmp any any echo (310459 matches) > > #sh mls qos ip > QoS Summary [IPv4]: (* - shared aggregates, Mod - switch module) > > Int Mod Dir Class-map DSCP Agg Trust Fl AgForward-By AgPoliced-By > Id Id > ------------------------------------------------------------------------------- > CPP 5 In copp-manag 0 0* No 0 n/a n/a > CPP 5 In copp-bgp 0 0* No 0 n/a n/a > CPP 5 In copp-ospf 0 0* No 0 n/a n/a > CPP 5 In copp-crit- 0 0* No 0 n/a n/a > CPP 5 In copp-tunne 0 0* No 0 n/a n/a > CPP 5 In copp-monit 0 1 dscp 0 566066 0 > CPP 5 In class-defa 0 2 dscp 0 122496813 0 > > All 5 - Default 0 0* No 0 69655086564 0 > > Regards, > > Sebastian > > -- > 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 > _______________________________________________ > 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 rodunn at cisco.com Mon Sep 22 09:04:03 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Mon, 22 Sep 2008 09:04:03 -0400 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: References: <1221845016.11349.15.camel@abehat> Message-ID: <20080922130403.GA12859@rtp-cse-489.cisco.com> On Fri, Sep 19, 2008 at 12:46:47PM -0500, Winders, Timothy A wrote: > On 9/19/08 12:23 PM, "Peter Rathlev" wrote: > > > On Fri, 2008-09-19 at 18:51 +0200, Gert Doering wrote: > >> On Thu, Sep 18, 2008 at 08:36:43PM -0400, Jared Mauch wrote: > >>> Your bug (CSCsu59917) should also be listed on CCO. > > > >> What does CCO say about it, right now? (Don't want to check - $very > >> expensive GPRS link...) > > > > Probably not totally legal to post this, but here goes. :-) > > > > CSCsu59917 > > SXF15: IPv4/v6 BGP routes not cleared when source routes is gone > > Severity: 1 - catastrophic. > > Status: Fixed. > > Fixed-In > > 12.2(18)SXF15 > > 12.2(33.3.11)SXH > > 12.2(32.8.11)SX206 > > I don't understand. How can this show up in SXF15 and be fixed in SXF15? Because when we pull the label there are a few more test cycles that run pre-CCO post. If they find something catastrophic at the last minute they will fix it if at all possible. That appears to be what happened here with the SXF15 build and the bug that caused it. They are pushing for a faster rebuild on SXH to get the fix also. Rodney > Or, am I reading this wrong? > > Tim Winders | Associate Dean of Information Technology | South Plains > College > > _______________________________________________ > 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 rodunn at cisco.com Mon Sep 22 09:04:45 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Mon, 22 Sep 2008 09:04:45 -0400 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <20080920192953.GD7160@greenie.muc.de> References: <1221508568.7357.15.camel@localhost> <48CEC162.5000105@bytemark.co.uk> <20080916040858.GA17256@greenie.muc.de> <48CFC183.4060401@bytemark.co.uk> <20080916165849.GA20288@greenie.muc.de> <20080918201316.GD20288@greenie.muc.de> <20080919003643.GB79009@puck.nether.net> <20080919165126.GA11635@greenie.muc.de> <1221845016.11349.15.camel@abehat> <20080920192953.GD7160@greenie.muc.de> Message-ID: <20080922130445.GB12859@rtp-cse-489.cisco.com> They are Gert. Let me check on it... On Sat, Sep 20, 2008 at 09:29:53PM +0200, Gert Doering wrote: > Hi, > > On Fri, Sep 19, 2008 at 07:23:36PM +0200, Peter Rathlev wrote: > > CSCsu59917 > > SXF15: IPv4/v6 BGP routes not cleared when source routes is gone > > Severity: 1 - catastrophic. > > Indeed... makes me wonder why they are not doing an SXH rebuild on their > own, instead of making us wait 4-6 weeks for a bugfix for a *catastrophic* > (!!) bug. > > (No news from our case yet regarding an interim rebuild) > > thanks, > > gert > > -- > Gert Doering > Mobile communications ... right now writing from * Sardegna, Italy * > _______________________________________________ > 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 rodunn at cisco.com Mon Sep 22 09:06:09 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Mon, 22 Sep 2008 09:06:09 -0400 Subject: [c-nsp] SRC2? In-Reply-To: <48D3F5B2.3070408@isp.solcon.nl> References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <48A2FF3B.5030104@gatlan.nl> <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com> <48D003E4.7000005@isp.solcon.nl> <20080917115953.GD23151@rtp-cse-489.cisco.com> <48D16197.2080302@isp.solcon.nl> <20080918161106.GH4819@rtp-cse-489.cisco.com> <48D3F5B2.3070408@isp.solcon.nl> Message-ID: <20080922130609.GD12859@rtp-cse-489.cisco.com> Show me your configuration. On Fri, Sep 19, 2008 at 08:55:46PM +0200, Rinse Kloek (Solcon) wrote: > This puzzles me. I do policy routing met set VRF. However it looks like > still the global routing table is used: > > Sep 19 20:48:12.439: IP: s=192.168.0.2 (GigabitEthernet0/2), > d=192.168.10.1, len 84, PBR Counted > Sep 19 20:48:12.439: IP: s=192.168.0.2 (GigabitEthernet0/2), > d=192.168.10.1, len 84, FIB policy routed set vrf > Sep 19 20:48:12.439: IP: s=192.168.0.2 (GigabitEthernet0/2), > d=192.168.10.1, len 84, FIB policy match > Sep 19 20:48:12.439: IP: s=192.168.0.2 (GigabitEthernet0/2), > d=192.168.10.1, len 84, FIB policy routed set vrf > Sep 19 20:48:12.439: IP: s=192.168.0.2 (GigabitEthernet0/2), > d=192.168.10.1, len 84, input feature, Policy Routing(49), rtype 0, > forus FALSE, sendself FALSE0 > Sep 19 20:48:12.439: IP: tableid=0, s=192.168.0.2 (GigabitEthernet0/2), > d=192.168.10.1 (GigabitEthernet0/1), routed via FIB > > First messages say that set vrf is matched. However the last line just > implies it goes throug the global routing table. > GigabitEthernet0/1 is the default gateway of the global routing table. > > kind regards Rinse > > Rodney Dunn schreef: > >What I'm saying is if you are seeing the problem on SRC1 it can't > >be CSCsk27643. > > > >On Wed, Sep 17, 2008 at 09:59:19PM +0200, Rinse Kloek (Solcon) wrote: > > > >>I tried this feature on a 7200 with SRC1 (also on SB6). (SRB does not > >>run on 7200). > >> > >>regards Rinse > >> > >>Rodney Dunn schreef: > >> > >>>It's already fixed in SRC and SRB4. > >>> > >>>That bug was only an issue in SRA throttle. > >>> > >>>Have you tried SRB4? > >>> > >>>On Tue, Sep 16, 2008 at 09:07:16PM +0200, Rinse Kloek (Solcon) wrote: > >>> > >>> > >>>>We are also running in some bug ( CSCsk27643 ) and are hoping to see > >>>>this fixed in SRC2. Anybody some tips to get PBR using set vrf working > >>>>on a 12.2 release ? > >>>> > >>>>regards Rinse > >>>>cisco-nsp at puck.nether.net > >>>> > >>>> > >>>>>Hi All, > >>>>> > >>>>>On Wed, Aug 13, 2008 at 6:35 PM, Bas Roos wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>>Anyone know when 12.2(33)SRC2 is supposed to be released, > >>>>>>>specifically > >>>>>>>for the 7600. I had heard by the end of July, but so far no release. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>>>>The latest statement we got from them was end-september. > >>>>>> > >>>>>> > >>>>>> > >>>>>Anyone from Cisco perhaps would comment on this? > >>>>>CSCso45720 makes it really problematic to go into production stage > >>>>>with the SRC train. > >>>>> > >>>>>Cheers, > >>>>>-- > >>>>>Ran. > >>>>>_______________________________________________ > >>>>>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 twinders at southplainscollege.edu Mon Sep 22 09:10:55 2008 From: twinders at southplainscollege.edu (Winders, Timothy A) Date: Mon, 22 Sep 2008 08:10:55 -0500 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <20080922130403.GA12859@rtp-cse-489.cisco.com> Message-ID: On 9/22/08 8:04 AM, "Rodney Dunn" wrote: > On Fri, Sep 19, 2008 at 12:46:47PM -0500, Winders, Timothy A wrote: >> On 9/19/08 12:23 PM, "Peter Rathlev" wrote: >> >>> On Fri, 2008-09-19 at 18:51 +0200, Gert Doering wrote: >>>> On Thu, Sep 18, 2008 at 08:36:43PM -0400, Jared Mauch wrote: >>>>> Your bug (CSCsu59917) should also be listed on CCO. >>> >>>> What does CCO say about it, right now? (Don't want to check - $very >>>> expensive GPRS link...) >>> >>> Probably not totally legal to post this, but here goes. :-) >>> >>> CSCsu59917 >>> SXF15: IPv4/v6 BGP routes not cleared when source routes is gone >>> Severity: 1 - catastrophic. >>> Status: Fixed. >>> Fixed-In >>> 12.2(18)SXF15 >>> 12.2(33.3.11)SXH >>> 12.2(32.8.11)SX206 >> >> I don't understand. How can this show up in SXF15 and be fixed in SXF15? > > Because when we pull the label there are a few more test cycles that > run pre-CCO post. If they find something catastrophic at the last minute > they will fix it if at all possible. That appears to be what happened here > with the SXF15 build and the bug that caused it. > > They are pushing for a faster rebuild on SXH to get the fix also. Thanks for the answer Rodney. So, it was found in SXF15, but corrected before SXF15 was pushed out the door. Gotcha. Tim Winders | Associate Dean of Information Technology | South Plains College From gert at greenie.muc.de Mon Sep 22 09:17:15 2008 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 22 Sep 2008 15:17:15 +0200 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <20080922130403.GA12859@rtp-cse-489.cisco.com> References: <1221845016.11349.15.camel@abehat> <20080922130403.GA12859@rtp-cse-489.cisco.com> Message-ID: <20080922131715.GE10226@greenie.muc.de> Hi, On Mon, Sep 22, 2008 at 09:04:03AM -0400, Rodney Dunn wrote: > They are pushing for a faster rebuild on SXH to get the fix also. Cool! Thank you very much (if you have been involved in this - if not, at least for giving us some more background info). gert -- Gert Doering Mobile communications ... right now writing from * Sardegna, Italy * From tdurack at gmail.com Mon Sep 22 10:19:12 2008 From: tdurack at gmail.com (Tim Durack) Date: Mon, 22 Sep 2008 10:19:12 -0400 Subject: [c-nsp] 12.2(33)SXI Message-ID: <9e246b4d0809220719ld6f7b9em34cb0886f4d190fd@mail.gmail.com> Docs are starting to appear for 12.2(33)SXI: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/qa_c67_494606_ns780_Networking_Solutions_Q_and_A.html *"Q.* What is the first customer ship date for Cisco IOS Software Release 12.2(33)SXI? * A.* First customer ship is expected in September 2008." Tim:> From mcgrath at fas.harvard.edu Mon Sep 22 10:33:25 2008 From: mcgrath at fas.harvard.edu (Scott McGrath) Date: Mon, 22 Sep 2008 10:33:25 -0400 Subject: [c-nsp] Cisco ASA VPN Active/Standby - license requirements In-Reply-To: <48D3AC5F.1020705@utc.edu> References: <0AF2BA9F8063B34AA9A2201D34DFC7B44E9D770E1B@IOWAEVS07.iowa.uiowa.edu> <48D33E01.9080204@gmx.de> <48D3AC5F.1020705@utc.edu> Message-ID: <48D7ACB5.4010400@fas.harvard.edu> Think LBSSP - Although Cisco making everything a 'Revenue Enhancement' opportunity puts my teeth on edge Cisco seems to have forgotten how they got to their dominant position mediocre products with GREAT support and reasonable licensing terms. They still have mediocre products but now support is expensive and delivered by call center drones reading from a script and unreasonable licensing terms. It used to be that Cisco was a compromise you could get all your support under one roof and the commonality of the products made the compromise worthwhile now more and more it seems the 'best of breed' approach is called for once again. The ASA is nowhere near the product the VPN3000 was I can see Cisco not wanting 3 separate hardware platforms for boxes with similar computational capabilities but at least come up with 3 separate images which are optimized for the task at hand NOT this LAME firewall with some VPN stuff thrown in. Case in point we use RRI on our VPN 3000's on the 3000's the RRI modifies the ospf routing table directly. in the ASA the RRI is handled by creating STATIC's so much for 'no redistribute static' if you have a out of band management network and want to handle that routing statically now what was a simple elegant solution which worked for years (7 in our case) now will become a science project with route maps from here to infinity and one that junior engineers will no longer be able to support. - Jeff Kell wrote: > Garry wrote: > >> ... makes sense >> especially for Active/Active standby, as it's more or less load >> balancing, too >> > > Bzzzttt! You can't do VPN in active/active mode, at least with 7.x and > under. If you can, please tell me how! > > 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 p.mayers at imperial.ac.uk Mon Sep 22 10:57:57 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Mon, 22 Sep 2008 15:57:57 +0100 Subject: [c-nsp] 12.2(33)SXI In-Reply-To: <9e246b4d0809220719ld6f7b9em34cb0886f4d190fd@mail.gmail.com> References: <9e246b4d0809220719ld6f7b9em34cb0886f4d190fd@mail.gmail.com> Message-ID: <48D7B275.50700@imperial.ac.uk> Tim Durack wrote: > Docs are starting to appear for 12.2(33)SXI: > > http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/qa_c67_494606_ns780_Networking_Solutions_Q_and_A.html Interesting. They don't have long... > > *"Q.* What is the first customer ship date for Cisco IOS Software Release > 12.2(33)SXI? > * A.* First customer ship is expected in September 2008." Documents like this have been appearing for a little while, google "site:Cisco.com sxi" e.g. the FWSM4 release notes reference SXI as a pre-requisite for the flow acceleration. http://www.cisco.com/en/US/docs/security/fwsm/fwsm40/release/notes/fwsmrn40.html That particular document doesn't talk about release dates, but I was reasonably sure I'd seen another. From tdurack at gmail.com Mon Sep 22 11:04:21 2008 From: tdurack at gmail.com (Tim Durack) Date: Mon, 22 Sep 2008 11:04:21 -0400 Subject: [c-nsp] 12.2(33)SXI In-Reply-To: <48D7B275.50700@imperial.ac.uk> References: <9e246b4d0809220719ld6f7b9em34cb0886f4d190fd@mail.gmail.com> <48D7B275.50700@imperial.ac.uk> Message-ID: <9e246b4d0809220804q55786f3eh11242a50c90d6353@mail.gmail.com> Yeah, I noticed the same thing. First time I saw a date though. Now I can start looking forward to the 6500 NX-OS migration (come on, the MDS-9000 is just a 6500 in sheep's clothing, and even the current iteration of the Nexus looks like it inherits technology from the 6500. I'd quite like my 6500s to be running a linux based control-plane...) Tim:> On Mon, Sep 22, 2008 at 10:57 AM, Phil Mayers wrote: > Tim Durack wrote: > >> Docs are starting to appear for 12.2(33)SXI: >> >> >> http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/qa_c67_494606_ns780_Networking_Solutions_Q_and_A.html >> > > Interesting. They don't have long... > > >> *"Q.* What is the first customer ship date for Cisco IOS Software Release >> 12.2(33)SXI? >> * A.* First customer ship is expected in September 2008." >> > > Documents like this have been appearing for a little while, google > "site:Cisco.com sxi" > > e.g. the FWSM4 release notes reference SXI as a pre-requisite for the flow > acceleration. > > > http://www.cisco.com/en/US/docs/security/fwsm/fwsm40/release/notes/fwsmrn40.html > > That particular document doesn't talk about release dates, but I was > reasonably sure I'd seen another. > From ahmedazim at gmail.com Mon Sep 22 11:35:57 2008 From: ahmedazim at gmail.com (Ahmed Mohamed) Date: Mon, 22 Sep 2008 17:35:57 +0200 Subject: [c-nsp] WLC 4404 - Wirelss Lan Controller (DHCP issue) Message-ID: Hello, A WLC4404 was configured with DHCP pool, Access nodes should get an IP from it every time it negotiates with the controller what happens is an intermittent problem where sometimes the access node does not negotiate an IP and give alert of "limited or no connectivity" any suggestions of what coult be the problem ? Note: the problem is intermittent, it sometimes happens , and other just simply go fine .. Thanks in advance From dan-wilson at sbcglobal.net Mon Sep 22 12:25:17 2008 From: dan-wilson at sbcglobal.net (Dan Wilson) Date: Mon, 22 Sep 2008 11:25:17 -0500 Subject: [c-nsp] WLC 4404 - Wirelss Lan Controller (DHCP issue) In-Reply-To: References: Message-ID: <000001c91ccf$cd76c210$68644630$@net> By access node, do you mean wireless access point, or wireless user? -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ahmed Mohamed Sent: Monday, September 22, 2008 10:36 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] WLC 4404 - Wirelss Lan Controller (DHCP issue) Hello, A WLC4404 was configured with DHCP pool, Access nodes should get an IP from it every time it negotiates with the controller what happens is an intermittent problem where sometimes the access node does not negotiate an IP and give alert of "limited or no connectivity" any suggestions of what coult be the problem ? Note: the problem is intermittent, it sometimes happens , and other just simply go fine .. Thanks in advance _______________________________________________ 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 kyled at noelcomm.com Mon Sep 22 13:16:16 2008 From: kyled at noelcomm.com (Kyle Duren) Date: Mon, 22 Sep 2008 10:16:16 -0700 Subject: [c-nsp] Cisco 10720 Router? Message-ID: <8F6157EC24F5417C8B5C5EE46FAE951F@noelcomm.local> I have an opportunity to get a Cisco 10720 router for very cheap, but I'm rather unfamiliar with this model, I have some questions that I can't seem to find the answer for. Has anyone used this model router, if so, have you used it with BGP and such? The IOS limitations are rather odd, only having the 12.0 series (with somewhat recent updates) also makes me wonder? The unit can have 512mb of ram, and mentions only being able to handle ~ 250k routes, but is this in reference to the older model that only had 256 mb of ram? This router looks pretty good, being able to do 2mil pps though. Let me know off-list or on if you have any info! Thanks, Kyle Duren Network Coordinator Noel Communications, Inc. Office: (509) 575-4780 Fax: (509) 457-5008 From rogelio.gamino at dc.gov Mon Sep 22 14:20:40 2008 From: rogelio.gamino at dc.gov (Gamino, Rogelio (OCTO-Contractor)) Date: Mon, 22 Sep 2008 14:20:40 -0400 Subject: [c-nsp] WLC 4404 - Wirelss Lan Controller (DHCP issue) References: <000001c91ccf$cd76c210$68644630$@net> Message-ID: <3D0CAA914364E34E9B5D80B53547EE6239D77D@emo-exch2k3-s32.dcgov.priv> I'm guessing it is wireless users. I have not seen an AP give the "limited or no connectivity" alert he mentions. How big is your dhcp scope? Maybe you're running out of IP's? What is your lease time? -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dan Wilson Sent: Monday, September 22, 2008 12:25 PM To: 'Ahmed Mohamed'; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] WLC 4404 - Wirelss Lan Controller (DHCP issue) By access node, do you mean wireless access point, or wireless user? -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ahmed Mohamed Sent: Monday, September 22, 2008 10:36 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] WLC 4404 - Wirelss Lan Controller (DHCP issue) Hello, A WLC4404 was configured with DHCP pool, Access nodes should get an IP from it every time it negotiates with the controller what happens is an intermittent problem where sometimes the access node does not negotiate an IP and give alert of "limited or no connectivity" any suggestions of what coult be the problem ? Note: the problem is intermittent, it sometimes happens , and other just simply go fine .. Thanks in advance _______________________________________________ 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 ross at kallisti.us Mon Sep 22 14:29:23 2008 From: ross at kallisti.us (Ross Vandegrift) Date: Mon, 22 Sep 2008 14:29:23 -0400 Subject: [c-nsp] sup720 / 6704 RELIABILITY DRIVER / weird ASIC msg (12.2.18 SXF2) In-Reply-To: <48D7024C.6040306@gtcomm.net> References: <48D55824.1030304@gtcomm.net> <20080921233628.GA29185@kallisti.us> <48D7024C.6040306@gtcomm.net> Message-ID: <20080922182923.GC2921@kallisti.us> On Sun, Sep 21, 2008 at 10:26:20PM -0400, Paul wrote: > Single sup720-3bxl. Tried different slot, even tried an entire > different 6509 with same IOS SXF2.. > Maybe something with the IOS, or a hardware revision of the chassis or > sup module? > > Looking it up on the search gets no results :/ > > I got the same message you got, except it didn't contain the fabric > channel sync error, just the power off error, and this was with ANOTHER > 6704 module.. > So two 6704 modules I tried , each different errors, would not work in > either 6509 I have running SXF2. > > I got no errors putting it in a 6513, with SXH3 on it.. > > Will try SXF14, but I'm getting some TCAM errors with it which I'm about > to post about :) I asked my coworker to upgrade the lab switch to SXF15 and try the 10G card again - mysterious NVRAM error goes away. Definitely related to older IOS thinking something was weird on the new one. The failed diagnostics on the other hand, well that appears to be a real problem - our line cards worked in spite of the NVRAM error. Ross > > Paul > > Ross Vandegrift wrote: > >On Sat, Sep 20, 2008 at 04:08:04PM -0400, Paul wrote: > > > >>I'm getting the following messages when inserting a WS-X6704-10GE module > >>into a 6509 > >>running 12.2.18 SXF2 sup720-3bxl > >> > >>00:00:04: %SYS-CFC9-5-RESTART: System restarted -- > >>Cisco Internetwork Operating System Software > >>IOS (tm) c6lc2 Software (c6lc2-SP-M), Version 12.2(18)SXF2, RELEASE > >>SOFTWARE (fc1) > >>Technical Support: http://www.cisco.com/techsupport > >>Copyright (c) 1986-2006 by cisco Systems, Inc. > >>Compiled Thu 19-Jan-06 04:37 by dchih > >>*Nov 30 00:00:02.723: CFC9: Currently running ROMMON from S (Gold) region > >>- RELIABILITY DRIVER: wrong signature on NVFLASH > >> > > > >A co-worker reported the same message to me on Friday from a lab > >switch running SXD7b when he inserted a 6704-10GE w/dfc3bxl. > > > >Do you have redundant sups in the switch? This message is in our > >logs: > > > >00:00:24: %SYS-DFC4-5-RESTART: System restarted -- > >Cisco Internetwork Operating System Software > >IOS (tm) c6lc2 Software (c6lc2-SP-M), Version 12.2(18)SXD7b, RELEASE > >SOFTWARE (fc1) > >Technical Support: http://www.cisco.com/techsupport > >Copyright (c) 1986-2006 by cisco Systems, Inc. > >Compiled Fri 08-Dec-06 12:34 by ccai > >00:00:24: DFC4: Currently running ROMMON from S (Gold) region > >- RELIABILITY DRIVER: wrong signature on NVFLASH > > > >00:18:40: SP: Disabling standby fabric in slot 6 and allowing module in > >slot 4 to go ONLINE as it's fabric channels could not sync with the > >standby but synced with the active fabric > > > >00:18:40: %OIR-SP-3-PWRCYCLE: Card in module 6, is being power-cycled off > >(Fabric channel errors) > >00:18:42: %PFREDUN-SP-6-ACTIVE: Standby processor removed or reloaded, > >changing to Simplex mode > >00:18:43: %DIAG-SP-6-RUN_MINIMUM: Module 4: Running Minimum Diagnostics... > >00:18:54: %DIAG-SP-6-DIAG_OK: Module 4: Passed Online Diagnostics > > > > > > > >>Sep 20 13:19:21: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 9 is > >>experiencing the following error: Port Asic 0: 2 important event > >> > >>Sep 20 14:02:51: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 9 is > >>experiencing the following error: Port Asic 0: 1 important event > >> > > > >I don't see any instances of this, so it could be different. > > > > > >>Is this a bug in SXF2? I put the same module into another running SXH3 > >>and I don't get the reliability driver message. > >>Also this ASIC message does not look good but again it doesn't happen on > >>SXH3.. > >> > >>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/ > >> > > > > > > -- > GloboTech Communications > Phone: 1-514-907-0050 > Toll Free: 1-(888)-GTCOMM1 > Fax: 1-(514)-907-0750 > paul at gtcomm.net > http://www.gtcomm.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/ -- Ross Vandegrift ross at kallisti.us "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 From cisco-nsp at tracker.fire-world.de Mon Sep 22 15:05:08 2008 From: cisco-nsp at tracker.fire-world.de (Sebastian Wiesinger) Date: Mon, 22 Sep 2008 21:05:08 +0200 Subject: [c-nsp] CoPP Hardware Counters on RSP720/7600 In-Reply-To: <269424.43452.qm@web25503.mail.ukl.yahoo.com> References: <20080920150516.GA12916@danton.fire-world.de> <269424.43452.qm@web25503.mail.ukl.yahoo.com> Message-ID: <20080922190508.GA16204@danton.fire-world.de> * Ozgur Guler [2008-09-22 14:31]: > Hi Sebastian, > > Have you confirmed that mls qos is enabled globally? > CoPP needs mls qos in order to work in HW. Yes, "mls qos" is enabled. I tried doing a flood-ping with hping3 and have around 30-40% of CPU usage. This seems a little bit high, but I heard from others that without CoPP the session to the RSP720 would just freeze. With my CoPP enabled I was able to work without delay on the RSP720. I couldn't test the situation without CoPP but I hope I can do so tonight. Regards, Sebastian -- 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 dean at eatworms.org.uk Mon Sep 22 15:44:44 2008 From: dean at eatworms.org.uk (Dean Smith) Date: Mon, 22 Sep 2008 20:44:44 +0100 Subject: [c-nsp] Cisco 10720 Router? In-Reply-To: <8F6157EC24F5417C8B5C5EE46FAE951F@noelcomm.local> References: <8F6157EC24F5417C8B5C5EE46FAE951F@noelcomm.local> Message-ID: <01c201c91ceb$aa2232b0$fe669810$@org.uk> We have several hundred and are quite happy. Pre-7201/ASR it was about the only option for a cost effective 4 gig box for proper Hqos. You're right though its 12.0S based and cant be far from EOL now (The ASR 1002 is the natural successor.). Dont expect to use it like a 7200 with every feature under the sun but if you need Ethernet, routing, QOS and maybe a few acls its great. Typical use for us is as Customer router for high bandwidth MPLS solutions (100Mbs to 750+) delivered on Gig. Route tables of 50K (large enterprise) rather than a full internet table. It only does sampled netflow which may or may not be an issue for you. Dean -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Kyle Duren Sent: 22 September 2008 18:16 To: cisco-nsp at puck.nether.net Subject: [c-nsp] Cisco 10720 Router? I have an opportunity to get a Cisco 10720 router for very cheap, but I'm rather unfamiliar with this model, I have some questions that I can't seem to find the answer for. Has anyone used this model router, if so, have you used it with BGP and such? The IOS limitations are rather odd, only having the 12.0 series (with somewhat recent updates) also makes me wonder? The unit can have 512mb of ram, and mentions only being able to handle ~ 250k routes, but is this in reference to the older model that only had 256 mb of ram? This router looks pretty good, being able to do 2mil pps though. Let me know off-list or on if you have any info! Thanks, Kyle Duren Network Coordinator Noel Communications, Inc. Office: (509) 575-4780 Fax: (509) 457-5008 _______________________________________________ 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 Mon Sep 22 17:36:43 2008 From: cchurc05 at harris.com (Church, Charles) Date: Mon, 22 Sep 2008 16:36:43 -0500 Subject: [c-nsp] OSM memory Message-ID: Can any confirm for me if the memory for a 6500/7600 OSM is the same as the memory modules for the Sup2 or MSFC2? Just found out our 64MB OSMs don't like SXF14, no one thought to look at the OSM. Thanks, Chuck From oliver.gorwits at oucs.ox.ac.uk Mon Sep 22 17:43:38 2008 From: oliver.gorwits at oucs.ox.ac.uk (Oliver Gorwits) Date: Mon, 22 Sep 2008 22:43:38 +0100 Subject: [c-nsp] IPV6 IPAM In-Reply-To: <4f890e580809211036q1c3a2ddwc8593f3e775050ca@mail.gmail.com> References: <4f890e580809211036q1c3a2ddwc8593f3e775050ca@mail.gmail.com> Message-ID: <48D8118A.1050006@oucs.ox.ac.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mario Spinthiras wrote: > Can anyone from the ISP/NSP sector tell me what else they would > like to see in such an IPAM or what they feel would be a feature > suited ? Some kind of out of band access to the system, such as XML/SOAP API over HTTP, would be useful. This could be for provisioning, import/export of data, 3rd party system (cron job) integration, and so on. The system sounds good - best of luck! - -- Oliver Gorwits, Network and Telecommunications Group, Oxford University Computing Services -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI2BGJ2NPq7pwWBt4RAiQaAKDc+HnHuvdJHH/hCXENABS3ujgh4QCeMeJH 9aGExeP8fG/1QP3aYFN1XEY= =52OX -----END PGP SIGNATURE----- From jason at lixfeld.ca Mon Sep 22 18:52:21 2008 From: jason at lixfeld.ca (Jason Lixfeld) Date: Mon, 22 Sep 2008 18:52:21 -0400 Subject: [c-nsp] debugging all incoming traffic on an interface Message-ID: <32434F30-95B4-4D45-8735-4246C1BF649F@lixfeld.ca> I'm trying to give a local ILEC an idea on where to look to troubleshoot an issue on a bridged DSL circuit. It terminates directly onto a WIC-1ADSL interface in a 2651 on the one side and a VLAN on the other side. Can't pass traffic over it, but the inbound packet counters are incrementing on the 2651 side, however I have no idea what kind of traffic is actually hitting the interface, nor do I know what the source or destination of the traffic is. My question in all of this is what's the best way to see all the traffic coming into this interface? Attaching a access-list 100 permit ip any any log-input to the interface and/or subinterface via ip access-group didn't show anything - the interface counters incremented while the access-list counter didn't. I can't debug the ATM (sub)interface, nor can I configure a SPAN port on an ATM (sub)interface. Anyone know how I might go about this? I suppose in a worst case scenario, I could hook up a DSL modem to the line and plug that into a wireshark box, but I'm hoping there's a more localized solution. Thanks in advance. From jason at lixfeld.ca Mon Sep 22 19:23:11 2008 From: jason at lixfeld.ca (Jason Lixfeld) Date: Mon, 22 Sep 2008 19:23:11 -0400 Subject: [c-nsp] debugging all incoming traffic on an interface In-Reply-To: <64396C74FCE435468BE2AF5A73F9C2FD8692D3@chmaexch.chelmer.co.nz> References: <32434F30-95B4-4D45-8735-4246C1BF649F@lixfeld.ca> <64396C74FCE435468BE2AF5A73F9C2FD8692D3@chmaexch.chelmer.co.nz> Message-ID: <4A454D4E-2445-4220-A333-A9A41F841375@lixfeld.ca> Hi James, It's bridged, so no. Regardless, an ACL works fine on the ATM subinterface, except the traffic isn't anything that is matched by an access-list, from what I can see based on what I've tried so far. In retrospect, I should have clarified that better initially. Sorry for the confusion. On 22-Sep-08, at 7:17 PM, James Baker wrote: > Do you have a Dialer interface defined and attached to the ATM > interfaces? > > If you do, try the ACL on that. > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jason Lixfeld > Sent: Tuesday, 23 September 2008 10:52 a.m. > To: cisco-nsp at puck.nether.net > Subject: [c-nsp] debugging all incoming traffic on an interface > > I'm trying to give a local ILEC an idea on where to look to > troubleshoot > an issue on a bridged DSL circuit. It terminates directly onto a > WIC-1ADSL interface in a 2651 on the one side and a VLAN on the other > side. Can't pass traffic over it, but the inbound packet counters are > incrementing on the 2651 side, however I have no idea what kind of > traffic is actually hitting the interface, nor do I know what the > source > or destination of the traffic is. > > My question in all of this is what's the best way to see all the > traffic > coming into this interface? Attaching a access-list 100 permit ip any > any log-input to the interface and/or subinterface via ip access-group > didn't show anything - the interface counters incremented while the > access-list counter didn't. I can't debug the ATM (sub)interface, nor > can I configure a SPAN port on an ATM (sub)interface. > > Anyone know how I might go about this? I suppose in a worst case > scenario, I could hook up a DSL modem to the line and plug that into a > wireshark box, but I'm hoping there's a more localized solution. > > Thanks in advance. > ---------- > > The information contained in this e-mail and any attachments is > confidential > and is intended for the attention and use of the named addressee(s) > only. > Any views expressed in this message are those of the individual > sender and > may not necessarily reflect the views of Chelmer Limited. > > ##################################################################################### > This e-mail message has been scanned for Viruses and Content and > cleared > by NetIQ MailMarshal > ##################################################################################### From adriankok2000 at yahoo.com.hk Mon Sep 22 18:59:02 2008 From: adriankok2000 at yahoo.com.hk (adrian kok) Date: Tue, 23 Sep 2008 06:59:02 +0800 (CST) Subject: [c-nsp] c4000 Message-ID: <510587.56451.qm@web33303.mail.mud.yahoo.com> Hi all ls any different to setup vlan between catalyst 4000 and 2960? I need to setup the cisco2800 to have vlan this 4000 switch ls it easy? how setup the trunk port in 4000 switch? Thank you Send instant messages to your online friends http://uk.messenger.yahoo.com From James.Baker at chelmer.co.nz Mon Sep 22 19:17:58 2008 From: James.Baker at chelmer.co.nz (James Baker) Date: Tue, 23 Sep 2008 11:17:58 +1200 Subject: [c-nsp] debugging all incoming traffic on an interface In-Reply-To: <32434F30-95B4-4D45-8735-4246C1BF649F@lixfeld.ca> References: <32434F30-95B4-4D45-8735-4246C1BF649F@lixfeld.ca> Message-ID: <64396C74FCE435468BE2AF5A73F9C2FD8692D3@chmaexch.chelmer.co.nz> Do you have a Dialer interface defined and attached to the ATM interfaces? If you do, try the ACL on that. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jason Lixfeld Sent: Tuesday, 23 September 2008 10:52 a.m. To: cisco-nsp at puck.nether.net Subject: [c-nsp] debugging all incoming traffic on an interface I'm trying to give a local ILEC an idea on where to look to troubleshoot an issue on a bridged DSL circuit. It terminates directly onto a WIC-1ADSL interface in a 2651 on the one side and a VLAN on the other side. Can't pass traffic over it, but the inbound packet counters are incrementing on the 2651 side, however I have no idea what kind of traffic is actually hitting the interface, nor do I know what the source or destination of the traffic is. My question in all of this is what's the best way to see all the traffic coming into this interface? Attaching a access-list 100 permit ip any any log-input to the interface and/or subinterface via ip access-group didn't show anything - the interface counters incremented while the access-list counter didn't. I can't debug the ATM (sub)interface, nor can I configure a SPAN port on an ATM (sub)interface. Anyone know how I might go about this? I suppose in a worst case scenario, I could hook up a DSL modem to the line and plug that into a wireshark box, but I'm hoping there's a more localized solution. Thanks in advance. ---------- The information contained in this e-mail and any attachments is confidential and is intended for the attention and use of the named addressee(s) only. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Chelmer Limited. ##################################################################################### This e-mail message has been scanned for Viruses and Content and cleared by NetIQ MailMarshal ##################################################################################### From spinthiras.mario at gmail.com Mon Sep 22 22:39:24 2008 From: spinthiras.mario at gmail.com (Mario Spinthiras) Date: Tue, 23 Sep 2008 03:39:24 +0100 Subject: [c-nsp] c4000 In-Reply-To: <510587.56451.qm@web33303.mail.mud.yahoo.com> References: <510587.56451.qm@web33303.mail.mud.yahoo.com> Message-ID: <4f890e580809221939x5e8e3997q76a135cc3adcf996@mail.gmail.com> I presume the only difference in setting up vlans would show in CatOS which I haven't used and not sure people do today compared to IOS. If I remember correctly through my Cisco training CatOS is something like set vlan %x while as it should be straight forward with IOS using vlan %x in global config. I do however remember a mishap I used to do sometimes. I used to create virtual interfaces e.g Vlan401 and they wouldnt work for the simple fact that I didnt create the l2 vlan. Trunking should be fairly straight forward too. Int X/X/X switchport mode trunk switchport encap dot1q no shut thats about it. From adrian at creative.net.au Mon Sep 22 23:00:07 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 23 Sep 2008 11:00:07 +0800 Subject: [c-nsp] c4000 In-Reply-To: <510587.56451.qm@web33303.mail.mud.yahoo.com> References: <510587.56451.qm@web33303.mail.mud.yahoo.com> Message-ID: <20080923030007.GC8054@skywalker.creative.net.au> On Tue, Sep 23, 2008, adrian kok wrote: > Hi all > > ls any different to setup vlan between catalyst 4000 > and 2960? > > I need to setup the cisco2800 to have vlan this 4000 > switch > > ls it easy? > > how setup the trunk port in 4000 switch? I'd suggest finding the catalyst OS (catos) configuration guide on the Cisco website for the rough model / CatOS version you're using. It is all very well documented. Knowing where the docs are and reading them will probably enlighten you. Adrian From spinthiras.mario at gmail.com Mon Sep 22 23:12:13 2008 From: spinthiras.mario at gmail.com (Mario Spinthiras) Date: Tue, 23 Sep 2008 04:12:13 +0100 Subject: [c-nsp] c4000 In-Reply-To: <20080923030007.GC8054@skywalker.creative.net.au> References: <510587.56451.qm@web33303.mail.mud.yahoo.com> <20080923030007.GC8054@skywalker.creative.net.au> Message-ID: <4f890e580809222012k7b8eb8a5ha6a4c85c421a890d@mail.gmail.com> Wouldn't it be a lot wiser to migrate to IOS ? I know this is possible and I'm sure it's a step forward than anything else. Can anyone shed some light on the worthiness of migrating to IOS other than the obvious (consistency , easier) Regards, Mario From adrian at creative.net.au Mon Sep 22 23:17:54 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 23 Sep 2008 11:17:54 +0800 Subject: [c-nsp] c4000 In-Reply-To: <4f890e580809222012k7b8eb8a5ha6a4c85c421a890d@mail.gmail.com> References: <510587.56451.qm@web33303.mail.mud.yahoo.com> <20080923030007.GC8054@skywalker.creative.net.au> <4f890e580809222012k7b8eb8a5ha6a4c85c421a890d@mail.gmail.com> Message-ID: <20080923031754.GD8054@skywalker.creative.net.au> On Tue, Sep 23, 2008, Mario Spinthiras wrote: > Wouldn't it be a lot wiser to migrate to IOS ? I know this is possible and > I'm sure it's a step forward than anything else. Can anyone shed some light > on the worthiness of migrating to IOS other than the obvious (consistency , > easier) I believe only the very later Cat4000 Sup's can run IOS; the earlier ones (Sup1/Sup2 I think?) only run CatOS. CatOS mostly "just works" for a lot of switching environments and honestly isn't that scary. :) Adrian From dudepron at gmail.com Mon Sep 22 23:36:48 2008 From: dudepron at gmail.com (Aaron) Date: Mon, 22 Sep 2008 23:36:48 -0400 Subject: [c-nsp] Cisco 10720 Router? In-Reply-To: <8F6157EC24F5417C8B5C5EE46FAE951F@noelcomm.local> References: <8F6157EC24F5417C8B5C5EE46FAE951F@noelcomm.local> Message-ID: <480dad640809222036y43adcf06r36fe9ca3ad9e898c@mail.gmail.com> There was a kit to upgrade to 512mb which also requires a IOS upgrade. We used it for gige and fe access in some pops. Aaron On Mon, Sep 22, 2008 at 1:16 PM, Kyle Duren wrote: > I have an opportunity to get a Cisco 10720 router for very cheap, but I'm > rather unfamiliar with this model, I have some questions that I can't seem > to find the answer for. > > Has anyone used this model router, if so, have you used it with BGP and > such? > > The IOS limitations are rather odd, only having the 12.0 series (with > somewhat recent updates) also makes me wonder? > > The unit can have 512mb of ram, and mentions only being able to handle ~ > 250k routes, but is this in reference to the older model that only had 256 > mb of ram? This router looks pretty good, being able to do 2mil pps though. > > Let me know off-list or on if you have any info! > > Thanks, > Kyle Duren > Network Coordinator > Noel Communications, Inc. > Office: (509) 575-4780 > Fax: (509) 457-5008 > > _______________________________________________ > 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 dgranzer at gmail.com Tue Sep 23 03:15:29 2008 From: dgranzer at gmail.com (David Granzer) Date: Tue, 23 Sep 2008 09:15:29 +0200 Subject: [c-nsp] CoPP Hardware Counters on RSP720/7600 In-Reply-To: <20080922190508.GA16204@danton.fire-world.de> References: <20080920150516.GA12916@danton.fire-world.de> <269424.43452.qm@web25503.mail.ukl.yahoo.com> <20080922190508.GA16204@danton.fire-world.de> Message-ID: <844ef89c0809230015g2abbadbcl75283bf86ef71c49@mail.gmail.com> Hello, with CoPP enabled and flood ping to the RSP720 I don't have higher CPU utilization than is normal on my box. Without CoPP and ICMP flood (ping -f -s 1400) the CPU util goes to 90% - 99%. CPU utilization for five seconds: 96%/21%; one minute: 44%; five minutes: 20% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 194 23910192 426932747 56 46.38% 20.81% 5.12% 0 IP Input The CPU utilization with CoPP enabled is depend on what rate you doing policing for particular class, e.g. how many ICMP packet you are conforming to the RSP. Regards, David On 9/22/08, Sebastian Wiesinger wrote: > * Ozgur Guler [2008-09-22 14:31]: > > > Hi Sebastian, > > > > Have you confirmed that mls qos is enabled globally? > > CoPP needs mls qos in order to work in HW. > > > Yes, "mls qos" is enabled. I tried doing a flood-ping with hping3 and > have around 30-40% of CPU usage. This seems a little bit high, but I > heard from others that without CoPP the session to the RSP720 would > just freeze. With my CoPP enabled I was able to work without delay on > the RSP720. > > I couldn't test the situation without CoPP but I hope I can do so > tonight. > > > > Regards, > > Sebastian > > -- > 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 > _______________________________________________ > 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 rekordmeister at gmail.com Tue Sep 23 04:02:48 2008 From: rekordmeister at gmail.com (MKS) Date: Tue, 23 Sep 2008 08:02:48 +0000 Subject: [c-nsp] X2 and WAN PHY Message-ID: Hi list According to http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/installation/note/78_16705.html the X2 family is missing DWDM transceivers and WAN PHY transceivers. Does someone know if/when WAN PHY will be available in X2 formfactor? Or is there a third party that works in the 6708 module?+ //MKS From arla at rn.dk Tue Sep 23 06:05:10 2008 From: arla at rn.dk (Arne Larsen / Region Nordjylland) Date: Tue, 23 Sep 2008 12:05:10 +0200 Subject: [c-nsp] vs wism modules Message-ID: <8D68760F464FFD40A01BF2FB374E4A2886948A67ED@SRVEXC02.aas.its.nja.dk> Hi Folks. Does anyone know if there is a whitepaper available that describes exactly what wism module does and work regarding packet flows tunnel setups and so on. What impact has it on a cat6500's performance. /Arne From tdurack at gmail.com Tue Sep 23 08:07:00 2008 From: tdurack at gmail.com (Tim Durack) Date: Tue, 23 Sep 2008 08:07:00 -0400 Subject: [c-nsp] X2 and WAN PHY In-Reply-To: References: Message-ID: <9e246b4d0809230507o27ba25e1vca5c813cc2a032d7@mail.gmail.com> The only X2 DWDM optics I have seen are: http://www.ghipsystems.com/en/Products/X2-en/X2-en.html Website says: "*X2 Modules for 10G-Ethernet, 10G-Fibre Channel, and OC192/STM-64"* so I assume they will work for WAN PHY. (I have no experience with these, just found them when googling.) Tim:> On Tue, Sep 23, 2008 at 4:02 AM, MKS wrote: > Hi list > > According to > http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/installation/note/78_16705.html > the X2 family is missing DWDM transceivers and WAN PHY transceivers. > > Does someone know if/when WAN PHY will be available in X2 formfactor? > Or is there a third party that works in the 6708 module?+ > > //MKS > _______________________________________________ > 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.wilkinson at dsto.defence.gov.au Tue Sep 23 08:27:29 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Tue, 23 Sep 2008 20:27:29 +0800 Subject: [c-nsp] Debugging Cisco VPN Client Software ... Is it even possible ? Message-ID: <20080923122729.GC3152@stlux503.dsto.defence.gov.au> Hi all, >From the _client_ perspective can anyone recommend any tools/techniques to debug Cisco VPN client problems ? (they drive me mad). These are mostly Windows based clients connecting to a cisco vpn concentrator. I tend to trawl through event logs and client vpn logs and really have no real success with debugging. The VPN client really feels like a black box :( Any hot tips with how to debug VPN clients not being able to connect into a vpn concentrator (from the _client_ perspective) ? Thanks! -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From paul at paulstewart.org Tue Sep 23 08:37:56 2008 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 23 Sep 2008 08:37:56 -0400 Subject: [c-nsp] Conditional BGP Message-ID: <002401c91d79$3adb7900$b0926b00$@org> Hi folks.. We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. Thanks for your input. Paul From kratzers at pa.net Tue Sep 23 08:59:56 2008 From: kratzers at pa.net (Stephen Kratzer) Date: Tue, 23 Sep 2008 08:59:56 -0400 Subject: [c-nsp] Conditional BGP In-Reply-To: <002401c91d79$3adb7900$b0926b00$@org> References: <002401c91d79$3adb7900$b0926b00$@org> Message-ID: <200809230859.56291.kratzers@pa.net> On Tuesday 23 September 2008 08:37:56 Paul Stewart wrote: > Hi folks.. > > > > We have a couple of customers that are looking to purchase an Internet > connection from us - this will be a BGP feed to each customer as they are > multihomed today etc. > > > > Normally, we would just supply a full table and let them decide what to do > with it. In this scenario, they both wish to use us as a backup provider > and wish to ONLY use our network if their primary provider (Cogent) is > down. > > > > What is common practice for this scenario? We would still prefer to just > send a full table and put the control into their hands but I'm also > concerned if they will have the technical expertise to accomplish this.. > On their side, what would be common practice? I've been looking at > conditional BGP advertisements using route-maps but don't believe that's > the best solution.. > > > > Thanks for your input. > > > > Paul Paul, Most providers offer three options: full routes, partial (customer) routes, and default route only. Allowing the customer to select from these options allows them to choose the option that they can best support. To implement these options, you can create as-path access list and prefix list templates and apply them outbound as needed. Stephen Kratzer Network Engineer CTI Networks, Inc. From gulerozgur at yahoo.co.uk Tue Sep 23 09:03:18 2008 From: gulerozgur at yahoo.co.uk (Ozgur Guler) Date: Tue, 23 Sep 2008 13:03:18 +0000 (GMT) Subject: [c-nsp] debugging all incoming traffic on an interface In-Reply-To: <32434F30-95B4-4D45-8735-4246C1BF649F@lixfeld.ca> Message-ID: <765087.96249.qm@web25502.mail.ukl.yahoo.com> Have you tried using debug ip packet or debug packet with debug condition interface? --- On Mon, 22/9/08, Jason Lixfeld wrote: From: Jason Lixfeld Subject: [c-nsp] debugging all incoming traffic on an interface To: cisco-nsp at puck.nether.net Date: Monday, 22 September, 2008, 11:52 PM I'm trying to give a local ILEC an idea on where to look to troubleshoot an issue on a bridged DSL circuit. It terminates directly onto a WIC-1ADSL interface in a 2651 on the one side and a VLAN on the other side. Can't pass traffic over it, but the inbound packet counters are incrementing on the 2651 side, however I have no idea what kind of traffic is actually hitting the interface, nor do I know what the source or destination of the traffic is. My question in all of this is what's the best way to see all the traffic coming into this interface? Attaching a access-list 100 permit ip any any log-input to the interface and/or subinterface via ip access-group didn't show anything - the interface counters incremented while the access-list counter didn't. I can't debug the ATM (sub)interface, nor can I configure a SPAN port on an ATM (sub)interface. Anyone know how I might go about this? I suppose in a worst case scenario, I could hook up a DSL modem to the line and plug that into a wireshark box, but I'm hoping there's a more localized solution. Thanks in advance._______________________________________________ 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 kratzers at pa.net Tue Sep 23 09:03:58 2008 From: kratzers at pa.net (Stephen Kratzer) Date: Tue, 23 Sep 2008 09:03:58 -0400 Subject: [c-nsp] Conditional BGP In-Reply-To: <002401c91d79$3adb7900$b0926b00$@org> References: <002401c91d79$3adb7900$b0926b00$@org> Message-ID: <200809230903.58827.kratzers@pa.net> On Tuesday 23 September 2008 08:37:56 Paul Stewart wrote: > Hi folks.. > > > > We have a couple of customers that are looking to purchase an Internet > connection from us - this will be a BGP feed to each customer as they are > multihomed today etc. > > > > Normally, we would just supply a full table and let them decide what to do > with it. In this scenario, they both wish to use us as a backup provider > and wish to ONLY use our network if their primary provider (Cogent) is > down. > > > > What is common practice for this scenario? We would still prefer to just > send a full table and put the control into their hands but I'm also > concerned if they will have the technical expertise to accomplish this.. > On their side, what would be common practice? I've been looking at > conditional BGP advertisements using route-maps but don't believe that's > the best solution.. > > > > Thanks for your input. > > > > Paul Forgot to mention that they'll still need to set local pref to always prefer the primary provider. Stephen Kratzer Network Engineer CTI Networks, Inc. From alex.wilkinson at dsto.defence.gov.au Tue Sep 23 09:07:18 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Tue, 23 Sep 2008 21:07:18 +0800 Subject: [c-nsp] debugging all incoming traffic on an interface In-Reply-To: <32434F30-95B4-4D45-8735-4246C1BF649F@lixfeld.ca> References: <32434F30-95B4-4D45-8735-4246C1BF649F@lixfeld.ca> Message-ID: <20080923130718.GE3152@stlux503.dsto.defence.gov.au> 0n Mon, Sep 22, 2008 at 06:52:21PM -0400, Jason Lixfeld wrote: >Attaching a access-list 100 permit ip any any log-input to the >interface and/or subinterface via ip access-group didn't show >anything - the interface counters Curious ... since I dont have the luxury to play with cisco kit all day (jack of trades ...) can someone please give me a quick explanation as to how creating an ACL on an interface helps with debugging that interface ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From paul at paulstewart.org Tue Sep 23 09:13:25 2008 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 23 Sep 2008 09:13:25 -0400 Subject: [c-nsp] Conditional BGP In-Reply-To: <200809230859.56291.kratzers@pa.net> References: <002401c91d79$3adb7900$b0926b00$@org> <200809230859.56291.kratzers@pa.net> Message-ID: <002c01c91d7e$2a376cd0$7ea64670$@org> Thank you ... so really the best solution for us to offer is what we already do - full table. Also, since we support a full list of communities the customer has complete control over when/where they get advertised. Or a simple approach for the customers would be heavy prepending and low local-pref (which would keep the traffic down but not zero due to our peering etc). Thanks very much, Paul -----Original Message----- From: Stephen Kratzer [mailto:kratzers at pa.net] Sent: September 23, 2008 9:00 AM To: cisco-nsp at puck.nether.net Cc: Paul Stewart Subject: Re: [c-nsp] Conditional BGP On Tuesday 23 September 2008 08:37:56 Paul Stewart wrote: > Hi folks.. > > > > We have a couple of customers that are looking to purchase an Internet > connection from us - this will be a BGP feed to each customer as they are > multihomed today etc. > > > > Normally, we would just supply a full table and let them decide what to do > with it. In this scenario, they both wish to use us as a backup provider > and wish to ONLY use our network if their primary provider (Cogent) is > down. > > > > What is common practice for this scenario? We would still prefer to just > send a full table and put the control into their hands but I'm also > concerned if they will have the technical expertise to accomplish this.. > On their side, what would be common practice? I've been looking at > conditional BGP advertisements using route-maps but don't believe that's > the best solution.. > > > > Thanks for your input. > > > > Paul Paul, Most providers offer three options: full routes, partial (customer) routes, and default route only. Allowing the customer to select from these options allows them to choose the option that they can best support. To implement these options, you can create as-path access list and prefix list templates and apply them outbound as needed. Stephen Kratzer Network Engineer CTI Networks, Inc. From cchurc05 at harris.com Tue Sep 23 09:18:47 2008 From: cchurc05 at harris.com (Church, Charles) Date: Tue, 23 Sep 2008 08:18:47 -0500 Subject: [c-nsp] Conditional BGP In-Reply-To: <002401c91d79$3adb7900$b0926b00$@org> References: <002401c91d79$3adb7900$b0926b00$@org> Message-ID: Wouldn't having them prepend their AS enough times for prefixes towards you and a low local preference for routes from you (on their end) solve this? That way all the configuration is on their end. Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Paul Stewart Sent: Tuesday, September 23, 2008 8:38 AM To: 'cisco-nsp' Subject: [c-nsp] Conditional BGP Hi folks.. We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. Thanks for your input. Paul _______________________________________________ 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 at davidcoulson.net Tue Sep 23 09:33:25 2008 From: david at davidcoulson.net (David Coulson) Date: Tue, 23 Sep 2008 09:33:25 -0400 Subject: [c-nsp] Conditional BGP In-Reply-To: <002401c91d79$3adb7900$b0926b00$@org> References: <002401c91d79$3adb7900$b0926b00$@org> Message-ID: <48D8F025.7080006@davidcoulson.net> Paul, They would need to do two things. 1) AS prepend on the routes they advertise to you, so the AS path is longer than their path through Cogent. This will force most of their inbound traffic via Cogent. 2) Local pref setting for routes received from you to make them less desirable than the routes from Cogent. The default is 100, so they could set your routes to 90 or something. Both of these are set using a route-map on their side. I'm assuming that there isn't anything they would want to prefer to route through you (your peers/customers - Or if Level3 or someone de-peers Cogent again), but that can be tweaked with route-maps and prefix-list filters. David Paul Stewart wrote: > Hi folks.. > > > > We have a couple of customers that are looking to purchase an Internet > connection from us - this will be a BGP feed to each customer as they are > multihomed today etc. > > > > Normally, we would just supply a full table and let them decide what to do > with it. In this scenario, they both wish to use us as a backup provider > and wish to ONLY use our network if their primary provider (Cogent) is down. > > > > What is common practice for this scenario? We would still prefer to just > send a full table and put the control into their hands but I'm also > concerned if they will have the technical expertise to accomplish this.. On > their side, what would be common practice? I've been looking at conditional > BGP advertisements using route-maps but don't believe that's the best > solution.. > > > > Thanks for your input. > > > > Paul > > > > > > > > _______________________________________________ > 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 adrian at creative.net.au Tue Sep 23 09:35:41 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 23 Sep 2008 21:35:41 +0800 Subject: [c-nsp] debugging all incoming traffic on an interface In-Reply-To: <20080923130718.GE3152@stlux503.dsto.defence.gov.au> References: <32434F30-95B4-4D45-8735-4246C1BF649F@lixfeld.ca> <20080923130718.GE3152@stlux503.dsto.defence.gov.au> Message-ID: <20080923133541.GG8054@skywalker.creative.net.au> On Tue, Sep 23, 2008, Wilkinson, Alex wrote: > 0n Mon, Sep 22, 2008 at 06:52:21PM -0400, Jason Lixfeld wrote: > > >Attaching a access-list 100 permit ip any any log-input to the > >interface and/or subinterface via ip access-group didn't show > >anything - the interface counters > > Curious ... since I dont have the luxury to play with cisco kit all day (jack of > trades ...) can someone please give me a quick explanation as to how creating an > ACL on an interface helps with debugging that interface ? Assuming your platform is "compatible", it'll log stuff in the logging area. Just sure you've got a larger logging buffer and its set to debug (I think?) so it captures all of your packets. Adrian From rekordmeister at gmail.com Tue Sep 23 09:49:02 2008 From: rekordmeister at gmail.com (MKS) Date: Tue, 23 Sep 2008 13:49:02 +0000 Subject: [c-nsp] SIP-600 Message-ID: If I have a SIP-600 in a 7600 and SPA 1 port 10GbE. Lets say I have 5 gig of traffic on the 10 gig card, can I also have a 5 port GeE and thus oversubscribe the SIP-600? or will the 5 port card be disabled? Thanks //MKS From tim at pelican.org Tue Sep 23 09:49:23 2008 From: tim at pelican.org (Tim Franklin) Date: Tue, 23 Sep 2008 14:49:23 +0100 (BST) Subject: [c-nsp] debugging all incoming traffic on an interface In-Reply-To: <20080923130718.GE3152@stlux503.dsto.defence.gov.au> References: <32434F30-95B4-4D45-8735-4246C1BF649F@lixfeld.ca> <20080923130718.GE3152@stlux503.dsto.defence.gov.au> Message-ID: <7af07ba02fb3f7d066673fdedff17f8a.squirrel@webmail.pelican.org> On Tue, September 23, 2008 2:07 pm, Wilkinson, Alex wrote: > Curious ... since I dont have the luxury to play with cisco kit all day > (jack of > trades ...) can someone please give me a quick explanation as to how > creating an > ACL on an interface helps with debugging that interface ? access-list 100 permit ip any any log Will dump everything to the log. Eventually. Don't try this on busy interfaces, kids! :) Seriously, it's useful if you don't seem to be sending or receiving anything at all, or for proving which side of a device the problem lies, for example an ACL both inbound and outbound: permit icmp any any log permit ip any any on a customer-facing interface, then pinging into the customer's network from the other side of your own network can show that routing is working, that packets traverse your network into the customer's network, but that nothing comes back from the customer. Regards, Tim. From jlewis at lewis.org Tue Sep 23 09:49:27 2008 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 23 Sep 2008 09:49:27 -0400 (EDT) Subject: [c-nsp] Conditional BGP In-Reply-To: <002401c91d79$3adb7900$b0926b00$@org> References: <002401c91d79$3adb7900$b0926b00$@org> Message-ID: On Tue, 23 Sep 2008, Paul Stewart wrote: > We have a couple of customers that are looking to purchase an Internet > connection from us - this will be a BGP feed to each customer as they are > multihomed today etc. > > Normally, we would just supply a full table and let them decide what to do > with it. In this scenario, they both wish to use us as a backup provider > and wish to ONLY use our network if their primary provider (Cogent) is down. I wouldn't call this conditional BGP. We have a few customers doing this, and in most cases they do this because they don't have big enough routers to handle multiple full bgp tables. The typical setup is to use route-maps to set localpref on received routes (making the primary provider's route(s) preferred) and on sent routes to do several prepends to make the backup path less preferable to the internet. In such a setup, the customer probably doesn't need more than default routes from each provider. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From risnaini at indo.net.id Tue Sep 23 09:18:31 2008 From: risnaini at indo.net.id (a. rahman isnaini r.sutan) Date: Tue, 23 Sep 2008 20:18:31 +0700 Subject: [c-nsp] Conditional BGP In-Reply-To: <002401c91d79$3adb7900$b0926b00$@org> References: <002401c91d79$3adb7900$b0926b00$@org> Message-ID: <48D8ECA7.3050004@indo.net.id> Hi, My choice : Inject them a default route & ask them to prepend their prefixes to you rgs a. rahman isnaini rangkayo sutan Paul Stewart wrote: > Hi folks.. > > > > We have a couple of customers that are looking to purchase an Internet > connection from us - this will be a BGP feed to each customer as they are > multihomed today etc. > > > > Normally, we would just supply a full table and let them decide what to do > with it. In this scenario, they both wish to use us as a backup provider > and wish to ONLY use our network if their primary provider (Cogent) is down. > > > > What is common practice for this scenario? We would still prefer to just > send a full table and put the control into their hands but I'm also > concerned if they will have the technical expertise to accomplish this.. On > their side, what would be common practice? I've been looking at conditional > BGP advertisements using route-maps but don't believe that's the best > solution.. > > > > Thanks for your input. > > > > Paul > > > > > > > > _______________________________________________ > 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 Tue Sep 23 09:51:06 2008 From: cchurc05 at harris.com (Church, Charles) Date: Tue, 23 Sep 2008 08:51:06 -0500 Subject: [c-nsp] Conditional BGP In-Reply-To: <002c01c91d7e$2a376cd0$7ea64670$@org> References: <002401c91d79$3adb7900$b0926b00$@org><200809230859.56291.kratzers@pa.net> <002c01c91d7e$2a376cd0$7ea64670$@org> Message-ID: If you want to only give them a default, they could use static object tracking to override your default with their own provider. If that provider drops, the static that's tracked (with an AD lower than BGP) will go away, and your default would now be used. Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Paul Stewart Sent: Tuesday, September 23, 2008 9:13 AM To: kratzers at pa.net; cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Conditional BGP Thank you ... so really the best solution for us to offer is what we already do - full table. Also, since we support a full list of communities the customer has complete control over when/where they get advertised. Or a simple approach for the customers would be heavy prepending and low local-pref (which would keep the traffic down but not zero due to our peering etc). Thanks very much, Paul -----Original Message----- From: Stephen Kratzer [mailto:kratzers at pa.net] Sent: September 23, 2008 9:00 AM To: cisco-nsp at puck.nether.net Cc: Paul Stewart Subject: Re: [c-nsp] Conditional BGP On Tuesday 23 September 2008 08:37:56 Paul Stewart wrote: > Hi folks.. > > > > We have a couple of customers that are looking to purchase an Internet > connection from us - this will be a BGP feed to each customer as they are > multihomed today etc. > > > > Normally, we would just supply a full table and let them decide what to do > with it. In this scenario, they both wish to use us as a backup provider > and wish to ONLY use our network if their primary provider (Cogent) is > down. > > > > What is common practice for this scenario? We would still prefer to just > send a full table and put the control into their hands but I'm also > concerned if they will have the technical expertise to accomplish this.. > On their side, what would be common practice? I've been looking at > conditional BGP advertisements using route-maps but don't believe that's > the best solution.. > > > > Thanks for your input. > > > > Paul Paul, Most providers offer three options: full routes, partial (customer) routes, and default route only. Allowing the customer to select from these options allows them to choose the option that they can best support. To implement these options, you can create as-path access list and prefix list templates and apply them outbound as needed. Stephen Kratzer Network Engineer CTI Networks, Inc. _______________________________________________ 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 kratzers at pa.net Tue Sep 23 10:00:00 2008 From: kratzers at pa.net (Stephen Kratzer) Date: Tue, 23 Sep 2008 10:00:00 -0400 Subject: [c-nsp] Conditional BGP In-Reply-To: <002c01c91d7e$2a376cd0$7ea64670$@org> References: <002401c91d79$3adb7900$b0926b00$@org> <200809230859.56291.kratzers@pa.net> <002c01c91d7e$2a376cd0$7ea64670$@org> Message-ID: <200809231000.00572.kratzers@pa.net> IMHO, it's best to offer three options to the customer, full routes, partial routes, or a default route only. That is, say "Here are three possible configurations, which one do you want?" On Tuesday 23 September 2008 09:13:25 Paul Stewart wrote: > Thank you ... so really the best solution for us to offer is what we > already do - full table. > > Also, since we support a full list of communities the customer has complete > control over when/where they get advertised. Or a simple approach for the > customers would be heavy prepending and low local-pref (which would keep > the traffic down but not zero due to our peering etc). > > Thanks very much, > > Paul > > > -----Original Message----- > From: Stephen Kratzer [mailto:kratzers at pa.net] > Sent: September 23, 2008 9:00 AM > To: cisco-nsp at puck.nether.net > Cc: Paul Stewart > Subject: Re: [c-nsp] Conditional BGP > > On Tuesday 23 September 2008 08:37:56 Paul Stewart wrote: > > Hi folks.. > > > > > > > > We have a couple of customers that are looking to purchase an Internet > > connection from us - this will be a BGP feed to each customer as they are > > multihomed today etc. > > > > > > > > Normally, we would just supply a full table and let them decide what to > > do with it. In this scenario, they both wish to use us as a backup > > provider and wish to ONLY use our network if their primary provider > > (Cogent) is down. > > > > > > > > What is common practice for this scenario? We would still prefer to just > > send a full table and put the control into their hands but I'm also > > concerned if they will have the technical expertise to accomplish this.. > > On their side, what would be common practice? I've been looking at > > conditional BGP advertisements using route-maps but don't believe that's > > the best solution.. > > > > > > > > Thanks for your input. > > > > > > > > Paul > > Paul, > > Most providers offer three options: full routes, partial (customer) routes, > and default route only. Allowing the customer to select from these options > allows them to choose the option that they can best support. To implement > these options, you can create as-path access list and prefix list templates > and apply them outbound as needed. > > Stephen Kratzer > Network Engineer > CTI Networks, Inc. From lowen at pari.edu Tue Sep 23 10:03:09 2008 From: lowen at pari.edu (Lamar Owen) Date: Tue, 23 Sep 2008 10:03:09 -0400 Subject: [c-nsp] c4000 In-Reply-To: <510587.56451.qm@web33303.mail.mud.yahoo.com> References: <510587.56451.qm@web33303.mail.mud.yahoo.com> Message-ID: <200809231003.10060.lowen@pari.edu> On Monday 22 September 2008 18:59:02 adrian kok wrote: > Hi all > > ls any different to setup vlan between catalyst 4000 > and 2960? > > I need to setup the cisco2800 to have vlan this 4000 > switch > > ls it easy? > > how setup the trunk port in 4000 switch? I still have CatOS switches in my LAN; they work, work well, and there's no need to upgrade what isn't broken. It IS a different interface, though. The two best books I have on the subject are Kennedy Clark's "Cisco LAN Switching" (which is old enough to still deal with the older Catalysts) and "Cisco Field Manual: Catalyst Switch Configuration." I personally, for VLAN and trunking 'things' find the CatOS interface more intuitive and more powerful than the IOS interface; and I have switches with both, incidentally. Although none of my IOS switches have interface range capabilities; when dealing with lots of ports, the CatOS port ranging capability is very handy, and less error-prone in typing (repetitive typing of bridge-group or switchport commands is both a drag and an error center). In my LAN, I have all switches set to VTP transparent mode, and I've not yet needed to prune VLANs from trunks, so my setup is fairly simple. In that environment, setting up trunks is very simple. The only thing you need to think hard about is getting the native VLAN right. All my trunks are 802.1Q, so take the following config snippets in that context: [snip] #vtp set vtp mode transparent set vlan 1 name default type ethernet mtu 1500 said 100001 state active set vlan 101 name erc-10-250-130-link type ethernet mtu 1500 said 100101 state active set vlan 103 name smiley type ethernet mtu 1500 said 100103 state active set vlan 105 name erc-72 type ethernet mtu 1500 said 100105 state active set vlan 192 name old-internal type ethernet mtu 1500 said 100192 state active set vlan 201 name 12012-uplink type ethernet mtu 1500 said 100201 state active [snip] #standby ports set standbyports enable [snip] #module 1 : 2-port 1000BaseX Supervisor IIIG set vlan 192 1/2 set vlan 201 1/1 set trunk 1/2 on dot1q 1-1005 ! #module 2 : 2-port 1000BaseX Supervisor IIIG set vlan 192 2/1-2 set trunk 2/2 on dot1q 1-1005 ! #module 3 : 3-port 1000BaseX Ethernet set vlan 192 3/1-3 set trunk 3/1 on dot1q 1-1005 set trunk 3/2 on dot1q 1-1005 set trunk 3/3 on dot1q 1-1005 ! [snip] Hope that helps. Like I said, my setup is fairly simple, and vlan pruning on trunks has not yet become an issue, so none are pruned currently. Your mileage may vary; your setup may be complex enough to think carefully about what vlans propagate over which trunks. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 http://www.pari.edu From cisco-nsp at slepicka.net Tue Sep 23 10:23:16 2008 From: cisco-nsp at slepicka.net (James Slepicka) Date: Tue, 23 Sep 2008 09:23:16 -0500 Subject: [c-nsp] Conditional BGP In-Reply-To: <002401c91d79$3adb7900$b0926b00$@org> References: <002401c91d79$3adb7900$b0926b00$@org> Message-ID: <48D8FBD4.10003@slepicka.net> >>they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. I'm currently doing this with Cogent and another provider. I get default routes from both and simply prepend my AS a few times on the backup connection. In your situation this would mean that all of the config is on the customer side. e.g.: router bgp xxxx ... neighbor backup route-map prepend_outbound out neighbor x.x.x.x peer-group backup ... route-map prepend_outbound permit 10 set as-path prepend xxxx xxxx xxxx James Paul Stewart wrote: > Hi folks.. > > > > We have a couple of customers that are looking to purchase an Internet > connection from us - this will be a BGP feed to each customer as they are > multihomed today etc. > > > > Normally, we would just supply a full table and let them decide what to do > with it. In this scenario, they both wish to use us as a backup provider > and wish to ONLY use our network if their primary provider (Cogent) is down. > > > > What is common practice for this scenario? We would still prefer to just > send a full table and put the control into their hands but I'm also > concerned if they will have the technical expertise to accomplish this.. On > their side, what would be common practice? I've been looking at conditional > BGP advertisements using route-maps but don't believe that's the best > solution.. > > > > Thanks for your input. > > > > Paul > > > > > > > > _______________________________________________ > 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 jason at lixfeld.ca Tue Sep 23 10:42:00 2008 From: jason at lixfeld.ca (Jason Lixfeld) Date: Tue, 23 Sep 2008 10:42:00 -0400 Subject: [c-nsp] debugging all incoming traffic on an interface In-Reply-To: <765087.96249.qm@web25502.mail.ukl.yahoo.com> References: <765087.96249.qm@web25502.mail.ukl.yahoo.com> Message-ID: I have. There are no interface conditions on either of those debug [ip] packet commands. Also, debug interface doesn't allow me the option of my ATM interface(s). On 23-Sep-08, at 9:03 AM, Ozgur Guler wrote: > > Have you tried using > debug ip packet or > debug packet with > debug condition interface? > > > > --- On Mon, 22/9/08, Jason Lixfeld wrote: > From: Jason Lixfeld > Subject: [c-nsp] debugging all incoming traffic on an interface > To: cisco-nsp at puck.nether.net > Date: Monday, 22 September, 2008, 11:52 PM > > I'm trying to give a local ILEC an idea on where to look to > troubleshoot an issue on a bridged DSL circuit. It terminates > directly onto a WIC-1ADSL interface in a 2651 on the one side and a > VLAN on the other side. Can't pass traffic over it, but the inbound > packet counters are incrementing on the 2651 side, however I have no > idea what kind of > traffic is actually hitting the interface, nor do I > know what the source or destination of the traffic is. > > My question in all of this is what's the best way to see all the > traffic coming into this interface? Attaching a access-list 100 > permit ip any any log-input to the interface and/or subinterface via > ip access-group didn't show anything - the interface counters > incremented while the access-list counter didn't. I can't debug the > ATM (sub)interface, nor can I configure a SPAN port on an ATM > (sub)interface. > > Anyone know how I might go about this? I suppose in a worst case > scenario, I could hook up a DSL modem to the line and plug that into a > wireshark box, but I'm hoping there's a more localized solution. > > Thanks in advance. > _______________________________________________ > 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 luan at netcraftsmen.net Tue Sep 23 10:45:41 2008 From: luan at netcraftsmen.net (Luan Nguyen) Date: Tue, 23 Sep 2008 10:45:41 -0400 Subject: [c-nsp] Debugging Cisco VPN Client Software ... Is it even possible ? In-Reply-To: <20080923122729.GC3152@stlux503.dsto.defence.gov.au> References: <20080923122729.GC3152@stlux503.dsto.defence.gov.au> Message-ID: <02dc01c91d8b$0cfd0d20$26f72760$@net> Usually I find that client VPN log along with Concentrator log are enough. You could try to use Wireshark on the client machine for more detail information. Luan ---------------------------------------------------------------------------- ------------------------------------------------------------------------- Luan Nguyen Chesapeake NetCraftsmen, LLC. www.NetCraftsmen.net ---------------------------------------------------------------------------- ------------------------------------------------------------------------ -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Wilkinson, Alex Sent: Tuesday, September 23, 2008 8:27 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Debugging Cisco VPN Client Software ... Is it even possible ? Hi all, >From the _client_ perspective can anyone recommend any tools/techniques to debug Cisco VPN client problems ? (they drive me mad). These are mostly Windows based clients connecting to a cisco vpn concentrator. I tend to trawl through event logs and client vpn logs and really have no real success with debugging. The VPN client really feels like a black box :( Any hot tips with how to debug VPN clients not being able to connect into a vpn concentrator (from the _client_ perspective) ? Thanks! -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the 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 Simon.Fawcett at uk.fujitsu.com Tue Sep 23 11:28:09 2008 From: Simon.Fawcett at uk.fujitsu.com (Fawcett Simon) Date: Tue, 23 Sep 2008 16:28:09 +0100 Subject: [c-nsp] Conditional BGP In-Reply-To: <48D8ECA7.3050004@indo.net.id> References: <002401c91d79$3adb7900$b0926b00$@org> <48D8ECA7.3050004@indo.net.id> Message-ID: My choice would be full routing tables from both ISP's, the customer to change his local pref on the backup link. if done correctly his own address space will not be advertised to the backup ISP as it would be advertised from the the backup ISP to the client. When the primary link fails the backup BGP link would see its own prefix's disappear and start advertising its own prefix's out the backup link with a 60 sec delay of course. Thus avoiding problems with private peering arrangements, where asymetric routing happens. Good luck have fun Simon -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of a. rahman isnaini r.sutan Sent: 23 September 2008 14:19 To: Paul Stewart Cc: 'cisco-nsp' Subject: Re: [c-nsp] Conditional BGP Hi, My choice : Inject them a default route & ask them to prepend their prefixes to you rgs a. rahman isnaini rangkayo sutan Paul Stewart wrote: > Hi folks.. > > > > We have a couple of customers that are looking to purchase an Internet > connection from us - this will be a BGP feed to each customer as they > are multihomed today etc. > > > > Normally, we would just supply a full table and let them decide what > to do with it. In this scenario, they both wish to use us as a backup > provider and wish to ONLY use our network if their primary provider (Cogent) is down. > > > > What is common practice for this scenario? We would still prefer to > just send a full table and put the control into their hands but I'm > also concerned if they will have the technical expertise to accomplish > this.. On their side, what would be common practice? I've been > looking at conditional BGP advertisements using route-maps but don't > believe that's the best solution.. > > > > Thanks for your input. > > > > Paul > > > > > > > > _______________________________________________ > 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 paul at paulstewart.org Tue Sep 23 11:32:40 2008 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 23 Sep 2008 11:32:40 -0400 Subject: [c-nsp] Conditional BGP In-Reply-To: References: <002401c91d79$3adb7900$b0926b00$@org> Message-ID: <000001c91d91$a4db7900$ee926b00$@org> Thanks to everyone for all the replies both offlist and onlist... quite a few of them! ;) Anyways, we're going to offer all three options to these customers - I want to put the control in their court which as Stephen and others have suggested. Then the responsibility is on the customer which "route" they prefer (sorry, bad pun). Currently these customers are both getting full tables and could handle an additional table with no issues at all. Appreciate the feedback from everyone.. Paul -----Original Message----- From: Church, Charles [mailto:cchurc05 at harris.com] Sent: Tuesday, September 23, 2008 9:19 AM To: Paul Stewart; cisco-nsp Subject: RE: [c-nsp] Conditional BGP Wouldn't having them prepend their AS enough times for prefixes towards you and a low local preference for routes from you (on their end) solve this? That way all the configuration is on their end. Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Paul Stewart Sent: Tuesday, September 23, 2008 8:38 AM To: 'cisco-nsp' Subject: [c-nsp] Conditional BGP Hi folks.. We have a couple of customers that are looking to purchase an Internet connection from us - this will be a BGP feed to each customer as they are multihomed today etc. Normally, we would just supply a full table and let them decide what to do with it. In this scenario, they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. What is common practice for this scenario? We would still prefer to just send a full table and put the control into their hands but I'm also concerned if they will have the technical expertise to accomplish this.. On their side, what would be common practice? I've been looking at conditional BGP advertisements using route-maps but don't believe that's the best solution.. Thanks for your input. Paul _______________________________________________ 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 Kevin.X.White at corusgroup.com Tue Sep 23 12:03:10 2008 From: Kevin.X.White at corusgroup.com (Kevin.X.White at corusgroup.com) Date: Tue, 23 Sep 2008 17:03:10 +0100 Subject: [c-nsp] Kevin White is out of the office. Message-ID: I will be out of the office starting 23/09/2008 and will not return until 02/10/2008. Please contact Marcus Burbidge x2510 or Peter Smith x6501 for any urgent issues ********************************************************************** This transmission is confidential and must not be used or disclosed by anyone other than the intended recipient. Neither Tata Steel UK Limited nor any of its subsidiaries can accept any responsibility for any use or misuse of the transmission by anyone. For address and company registration details of certain entities within the Corus group of companies, please visit http://www.corusgroup.com/entities ********************************************************************** From billf at mu.org Tue Sep 23 12:25:52 2008 From: billf at mu.org (bill fumerola) Date: Tue, 23 Sep 2008 09:25:52 -0700 Subject: [c-nsp] Conditional BGP In-Reply-To: <48D8FBD4.10003@slepicka.net> References: <002401c91d79$3adb7900$b0926b00$@org> <48D8FBD4.10003@slepicka.net> Message-ID: <20080923162552.GG29172@elvis.mu.org> On Tue, Sep 23, 2008 at 09:23:16AM -0500, James Slepicka wrote: > >>they both wish to use us as a backup provider and wish to ONLY use > our network if their primary provider (Cogent) is down. > > I'm currently doing this with Cogent and another provider. I get > default routes from both and simply prepend my AS a few times on the > backup connection. In your situation this would mean that all of the > config is on the customer side. e.g.: > > router bgp xxxx > ... > neighbor backup route-map prepend_outbound out > neighbor x.x.x.x peer-group backup > ... > > route-map prepend_outbound permit 10 > set as-path prepend xxxx xxxx xxxx avoid manual peer-groups.. templates using 'inherit peer-(session|policy)' are more flexible and easier to change later. if your neighbors have the same outbound policy, they'll get stuffed into the same update group w/o the peer-group. and to answer the OP question: this is a question of local policy for the customer. give them lots of options. let them use weight (and/or localpref, if they have multiple routers in the AS) to determine egress. give them communities if that will help their route selection decision making. i wouldn't go much further than the previous suggestions of 'full routes', 'customer routes', 'default origination' unless $customer is paying you to rig something up or you're feeling particularly nice. finally, 'down' can mean a lot of things and your customer needs to figure out if that means 'interface loss', 'loss across cogent' (frequent occurrence), 'latency spike', etc. in IOS, using IP SLA and a track object is probably the best way to implement those checks. -- bill From paul at paulstewart.org Tue Sep 23 12:34:00 2008 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 23 Sep 2008 12:34:00 -0400 Subject: [c-nsp] Conditional BGP In-Reply-To: <20080923162552.GG29172@elvis.mu.org> References: <002401c91d79$3adb7900$b0926b00$@org> <48D8FBD4.10003@slepicka.net> <20080923162552.GG29172@elvis.mu.org> Message-ID: <001701c91d9a$2fc02360$8f406a20$@org> Thanks Bill... "finally, 'down' can mean a lot of things and your customer needs to figure out if that means 'interface loss', 'loss across cogent' (frequent occurrence), 'latency spike', etc. in IOS, using IP SLA and a track object is probably the best way to implement those checks" This is a very good point - there's a good reason they need backup when using a Cogent feed ;) Sorry, couldn't resist saying that... their viewpoint will be "loss across cogent" I'm sure... I believe they will want a full feed and just look after it all - or we can offer them a managed customer prem router solution and take care of it for them.... Take care, Paul -----Original Message----- From: bill fumerola [mailto:billf at mu.org] Sent: Tuesday, September 23, 2008 12:26 PM To: James Slepicka Cc: Paul Stewart; 'cisco-nsp' Subject: Re: [c-nsp] Conditional BGP On Tue, Sep 23, 2008 at 09:23:16AM -0500, James Slepicka wrote: > >>they both wish to use us as a backup provider and wish to ONLY use > our network if their primary provider (Cogent) is down. > > I'm currently doing this with Cogent and another provider. I get > default routes from both and simply prepend my AS a few times on the > backup connection. In your situation this would mean that all of the > config is on the customer side. e.g.: > > router bgp xxxx > ... > neighbor backup route-map prepend_outbound out > neighbor x.x.x.x peer-group backup > ... > > route-map prepend_outbound permit 10 > set as-path prepend xxxx xxxx xxxx avoid manual peer-groups.. templates using 'inherit peer-(session|policy)' are more flexible and easier to change later. if your neighbors have the same outbound policy, they'll get stuffed into the same update group w/o the peer-group. and to answer the OP question: this is a question of local policy for the customer. give them lots of options. let them use weight (and/or localpref, if they have multiple routers in the AS) to determine egress. give them communities if that will help their route selection decision making. i wouldn't go much further than the previous suggestions of 'full routes', 'customer routes', 'default origination' unless $customer is paying you to rig something up or you're feeling particularly nice. finally, 'down' can mean a lot of things and your customer needs to figure out if that means 'interface loss', 'loss across cogent' (frequent occurrence), 'latency spike', etc. in IOS, using IP SLA and a track object is probably the best way to implement those checks. -- bill From drikus.brits at is.co.za Tue Sep 23 12:44:47 2008 From: drikus.brits at is.co.za (Drikus Brits) Date: Tue, 23 Sep 2008 18:44:47 +0200 Subject: [c-nsp] Debugging Cisco VPN Client Software ... Is it even possible ? In-Reply-To: <20080923122729.GC3152@stlux503.dsto.defence.gov.au> References: <20080923122729.GC3152@stlux503.dsto.defence.gov.au> Message-ID: <1222188287.15485.5.camel@guardian> what kinda issues are you having ?....i've rarely found a problem that required debugging and all... regards, On Tue, 2008-09-23 at 20:27 +0800, Wilkinson, Alex wrote: > Hi all, > > >From the _client_ perspective can anyone recommend any tools/techniques to debug > Cisco VPN client problems ? (they drive me mad). These are mostly Windows based > clients connecting to a cisco vpn concentrator. I tend to trawl through event logs > and client vpn logs and really have no real success with debugging. > > The VPN client really feels like a black box :( > > Any hot tips with how to debug VPN clients not being able to connect into a vpn > concentrator (from the _client_ perspective) ? > > Thanks! > > -aW > > IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the 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/ Please note: This email and its content are subject to the disclaimer as displayed at the following link http://www.is.co.za/legal/E-mail+Confidentiality+Notice+and+Disclaimer.htm. Should you not have Web access, send a mail to disclaimers at is.co.za and a copy will be emailed to you. From petelists at templin.org Tue Sep 23 13:06:26 2008 From: petelists at templin.org (Pete Templin) Date: Tue, 23 Sep 2008 12:06:26 -0500 Subject: [c-nsp] Conditional BGP In-Reply-To: <002401c91d79$3adb7900$b0926b00$@org> References: <002401c91d79$3adb7900$b0926b00$@org> Message-ID: <48D92212.4060607@templin.org> Paul Stewart wrote: > What is common practice for this scenario? We would still prefer to just > send a full table and put the control into their hands but I'm also > concerned if they will have the technical expertise to accomplish this.. On > their side, what would be common practice? I've been looking at conditional > BGP advertisements using route-maps but don't believe that's the best > solution.. They can control their outbound fairly easily. They should make sure they're getting the same level (default-only, partial, full) of routes from you as from Cogent - if they take more from you, those routes are more-specific and would win regardless. I'd suggest they take default-only from you (or more but filter out everything but default so they can change on the fly later) and whatever they wish from Cogent. Controlling inbound is often tougher. Any smart provider sets a higher local pref on customer routes than on transit/peer routes (make money rather than pay money), so if you do this you'll need to make an exception for them (or offer the exception via communities). Otherwise, you'll prefer their announcement no matter how many prepends they do, and if that happens for a minute, your transits will likely prefer your propagation no matter how many prepends they do. Even if you don't do this today, if Cogent goes down, you'll choose the direct link (it's the only one live) and your transits will do the same thing (your routes have customer LP in their network). When Cogent comes up, your transits will ignore the Cogent-propagated route since it's only peer LP. They'd have to bounce the link to you to restore their preferred balance. You'll need to find out how to accomplish the same thing in your providers' networks as well. (Been there, done that, got the t-shirt.) pt From paul at paulstewart.org Tue Sep 23 13:14:42 2008 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 23 Sep 2008 13:14:42 -0400 Subject: [c-nsp] Conditional BGP In-Reply-To: <48D92212.4060607@templin.org> References: <002401c91d79$3adb7900$b0926b00$@org> <48D92212.4060607@templin.org> Message-ID: <001801c91d9f$df280fc0$9d782f40$@org> Thanks Pete.... yeah, thought that through as well - been there done that ;) We'll offer them a full feed (well, all three options but I know they'll want a full feed I believe - that's what they get via Cogent as well) and then they can control everything - with communities as well on our side. We always local-pref customers 300, peers 200, transit 100 and been caught on that before hehe... I'm happy if the decisions are on the customer and we're "just" the provider.... Take care, Paul -----Original Message----- From: Pete Templin [mailto:petelists at templin.org] Sent: Tuesday, September 23, 2008 1:06 PM To: Paul Stewart Cc: 'cisco-nsp' Subject: Re: [c-nsp] Conditional BGP Paul Stewart wrote: > What is common practice for this scenario? We would still prefer to just > send a full table and put the control into their hands but I'm also > concerned if they will have the technical expertise to accomplish this.. On > their side, what would be common practice? I've been looking at conditional > BGP advertisements using route-maps but don't believe that's the best > solution.. They can control their outbound fairly easily. They should make sure they're getting the same level (default-only, partial, full) of routes from you as from Cogent - if they take more from you, those routes are more-specific and would win regardless. I'd suggest they take default-only from you (or more but filter out everything but default so they can change on the fly later) and whatever they wish from Cogent. Controlling inbound is often tougher. Any smart provider sets a higher local pref on customer routes than on transit/peer routes (make money rather than pay money), so if you do this you'll need to make an exception for them (or offer the exception via communities). Otherwise, you'll prefer their announcement no matter how many prepends they do, and if that happens for a minute, your transits will likely prefer your propagation no matter how many prepends they do. Even if you don't do this today, if Cogent goes down, you'll choose the direct link (it's the only one live) and your transits will do the same thing (your routes have customer LP in their network). When Cogent comes up, your transits will ignore the Cogent-propagated route since it's only peer LP. They'd have to bounce the link to you to restore their preferred balance. You'll need to find out how to accomplish the same thing in your providers' networks as well. (Been there, done that, got the t-shirt.) pt From mksmith at adhost.com Tue Sep 23 13:17:01 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 23 Sep 2008 10:17:01 -0700 Subject: [c-nsp] debugging all incoming traffic on an interface In-Reply-To: <20080923130718.GE3152@stlux503.dsto.defence.gov.au> References: <32434F30-95B4-4D45-8735-4246C1BF649F@lixfeld.ca> <20080923130718.GE3152@stlux503.dsto.defence.gov.au> Message-ID: <17838240D9A5544AAA5FF95F8D52031604BE2413@ad-exh01.adhost.lan> Hello Alex: > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp- > bounces at puck.nether.net] On Behalf Of Wilkinson, Alex > Sent: Tuesday, September 23, 2008 6:07 AM > To: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] debugging all incoming traffic on an interface > > 0n Mon, Sep 22, 2008 at 06:52:21PM -0400, Jason Lixfeld wrote: > > >Attaching a access-list 100 permit ip any any log-input to the > >interface and/or subinterface via ip access-group didn't show > >anything - the interface counters > > Curious ... since I dont have the luxury to play with cisco kit all day (jack > of > trades ...) can someone please give me a quick explanation as to how creating > an > ACL on an interface helps with debugging that interface ? > > -aW > > IMPORTANT: This email remains the property of the Australian Defence > Organisation and is subject to the jurisdiction of section 70 of the CRIMES > ACT 1914. If you have received this email in error, you are requested to > contact the sender and delete the email. > AFAIK it doesn't. However, you can apply ACL's to your debug setup as a filter. The filter below would only match traffic from 192.168.1.0/24 to 192.168.2.0/24 debug ip packet 199 access-list 199 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 log Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 474 bytes Desc: not available URL: From rodunn at cisco.com Tue Sep 23 13:27:27 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 23 Sep 2008 13:27:27 -0400 Subject: [c-nsp] debugging all incoming traffic on an interface In-Reply-To: References: <765087.96249.qm@web25502.mail.ukl.yahoo.com> Message-ID: <20080923172727.GY24139@rtp-cse-489.cisco.com> Might this help if you get on 12.4(20)T: http://supportwiki.cisco.com/ViewWiki/index.php/Tech_Insights:Utilizing_the_New_Packet_Capture_Feature On Tue, Sep 23, 2008 at 10:42:00AM -0400, Jason Lixfeld wrote: > I have. There are no interface conditions on either of those debug > [ip] packet commands. Also, debug interface doesn't allow me the > option of my ATM interface(s). > > On 23-Sep-08, at 9:03 AM, Ozgur Guler wrote: > > > > >Have you tried using > >debug ip packet or > >debug packet with > >debug condition interface? > > > > > > > >--- On Mon, 22/9/08, Jason Lixfeld wrote: > >From: Jason Lixfeld > >Subject: [c-nsp] debugging all incoming traffic on an interface > >To: cisco-nsp at puck.nether.net > >Date: Monday, 22 September, 2008, 11:52 PM > > > >I'm trying to give a local ILEC an idea on where to look to > >troubleshoot an issue on a bridged DSL circuit. It terminates > >directly onto a WIC-1ADSL interface in a 2651 on the one side and a > >VLAN on the other side. Can't pass traffic over it, but the inbound > >packet counters are incrementing on the 2651 side, however I have no > >idea what kind of > > traffic is actually hitting the interface, nor do I > >know what the source or destination of the traffic is. > > > >My question in all of this is what's the best way to see all the > >traffic coming into this interface? Attaching a access-list 100 > >permit ip any any log-input to the interface and/or subinterface via > >ip access-group didn't show anything - the interface counters > >incremented while the access-list counter didn't. I can't debug the > >ATM (sub)interface, nor can I configure a SPAN port on an ATM > >(sub)interface. > > > >Anyone know how I might go about this? I suppose in a worst case > >scenario, I could hook up a DSL modem to the line and plug that into a > >wireshark box, but I'm hoping there's a more localized solution. > > > >Thanks in advance. > >_______________________________________________ > >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 dan-wilson at sbcglobal.net Tue Sep 23 12:28:46 2008 From: dan-wilson at sbcglobal.net (Dan Wilson) Date: Tue, 23 Sep 2008 11:28:46 -0500 Subject: [c-nsp] Debugging Cisco VPN Client Software ... Is it even possible ? In-Reply-To: <20080923122729.GC3152@stlux503.dsto.defence.gov.au> References: <20080923122729.GC3152@stlux503.dsto.defence.gov.au> Message-ID: <002d01c91d99$74190b90$5c4b22b0$@net> C'mon Alex. You turn logging on on the client. Worst case you can look up the error messages on cisco.com -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Wilkinson, Alex Sent: Tuesday, September 23, 2008 7:27 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Debugging Cisco VPN Client Software ... Is it even possible ? Hi all, >From the _client_ perspective can anyone recommend any tools/techniques to debug Cisco VPN client problems ? (they drive me mad). These are mostly Windows based clients connecting to a cisco vpn concentrator. I tend to trawl through event logs and client vpn logs and really have no real success with debugging. The VPN client really feels like a black box :( Any hot tips with how to debug VPN clients not being able to connect into a vpn concentrator (from the _client_ perspective) ? Thanks! -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the 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 christian.macnevin at gmail.com Tue Sep 23 14:01:16 2008 From: christian.macnevin at gmail.com (Christian MacNevin) Date: Tue, 23 Sep 2008 11:01:16 -0700 Subject: [c-nsp] Best bet 65 IOS for mcast? Message-ID: Hi Got a client running 33SXH1 in their network. Is SXF still the best bet for stable mcast? Or are there necessary widgets in SXH nowadays? It's a pair of 3BXLs with DFC'ed 6708s and 6748. Merci beaucoup Christian From rodunn at cisco.com Tue Sep 23 14:40:06 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 23 Sep 2008 14:40:06 -0400 Subject: [c-nsp] Weird OSPF meltdown In-Reply-To: <6bb5f5b10809182245s3256abe7p8d0b931097632395@mail.gmail.com> References: <6bb5f5b10809182245s3256abe7p8d0b931097632395@mail.gmail.com> Message-ID: <20080923184006.GG24139@rtp-cse-489.cisco.com> On Fri, Sep 19, 2008 at 02:45:48AM -0300, Rubens Kuhl Jr. wrote: > Every once in a while one of ME6524 routers starts getting hammered by > one customer or the other... the symptom is that all adjacencies go > down and stay stuck at EXCHANGE phase. hammered by what? > CPU doesn't go up, and CoPP is applied; OSPF is authenticated on every > adjacency (which are all point-to-point on SVIs), and we don't see any > strange neighbors. Why are the neighbors going down? Hold time expired? If so you have to figure out why those frames are dropped. > > It occurs more often with Internet access static connected route > customers, but has now happened on a VRF as well. > > The only solution is disconnecting the customer; provisioning the > customer on SVI or on routerport doesn't seem to have any effect. Is it OSPF going down on an interface other than where this "hammering" is coming from? I'm assuming you mean it's a flood of traffic. > > IOS is 12.2(18)ZU2; Sham-Link on this IOS is vulnerable but we are not > using it. > > > Any thoughts ? > > > Rubens > _______________________________________________ > 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 Sep 23 14:47:05 2008 From: justin at justinshore.com (Justin Shore) Date: Tue, 23 Sep 2008 13:47:05 -0500 Subject: [c-nsp] Debugging Cisco VPN Client Software ... Is it even possible ? In-Reply-To: <20080923122729.GC3152@stlux503.dsto.defence.gov.au> References: <20080923122729.GC3152@stlux503.dsto.defence.gov.au> Message-ID: <48D939A9.4060900@justinshore.com> Wilkinson, Alex wrote: > Any hot tips with how to debug VPN clients not being able to connect into a vpn > concentrator (from the _client_ perspective) ? Yes. Don't mix Vista with Cisco's VPN client. Justin From gert at greenie.muc.de Tue Sep 23 04:56:39 2008 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 23 Sep 2008 10:56:39 +0200 Subject: [c-nsp] c4000 In-Reply-To: <4f890e580809222012k7b8eb8a5ha6a4c85c421a890d@mail.gmail.com> References: <510587.56451.qm@web33303.mail.mud.yahoo.com> <20080923030007.GC8054@skywalker.creative.net.au> <4f890e580809222012k7b8eb8a5ha6a4c85c421a890d@mail.gmail.com> Message-ID: <20080923085638.GJ10226@greenie.muc.de> Hi, On Tue, Sep 23, 2008 at 04:12:13AM +0100, Mario Spinthiras wrote: > Wouldn't it be a lot wiser to migrate to IOS ? I know this is possible and > I'm sure it's a step forward than anything else. Can anyone shed some light > on the worthiness of migrating to IOS other than the obvious (consistency , > easier) On the cat4000 (as far as I know), you have no choice - it depends on the Supervisor version in use. Older ones are catos-only, newer ones are IOS-only. Only on the cat6500, you can choose. gert -- Gert Doering Mobile communications ... right now writing from * Sardegna, Italy * From spinthiras.mario at gmail.com Tue Sep 23 16:15:49 2008 From: spinthiras.mario at gmail.com (Mario Spinthiras) Date: Tue, 23 Sep 2008 21:15:49 +0100 Subject: [c-nsp] GVRP implementation Message-ID: <4f890e580809231315r720463b8y3c0179679ef5e5d1@mail.gmail.com> Hello All, Before planning a small deployment I wanted to know if any of you had made use of GVRP (via GARP) on production Cisco machines. Do they provide the same result as does VTP? Regards, Mario. http://www.blupenguin.com/ From rubensk at gmail.com Tue Sep 23 16:46:38 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Tue, 23 Sep 2008 18:46:38 -0200 Subject: [c-nsp] Weird OSPF meltdown In-Reply-To: <20080923184006.GG24139@rtp-cse-489.cisco.com> References: <6bb5f5b10809182245s3256abe7p8d0b931097632395@mail.gmail.com> <20080923184006.GG24139@rtp-cse-489.cisco.com> Message-ID: <6bb5f5b10809231346t285e698eh9e7efec2f5f86136@mail.gmail.com> On Tue, Sep 23, 2008 at 4:40 PM, Rodney Dunn wrote: > On Fri, Sep 19, 2008 at 02:45:48AM -0300, Rubens Kuhl Jr. wrote: >> Every once in a while one of ME6524 routers starts getting hammered by >> one customer or the other... the symptom is that all adjacencies go >> down and stay stuck at EXCHANGE phase. > > hammered by what? We could not get packet traces of all the mishaps, but in one of them there was a flood of mDNS(Multicast DNS) packets. > >> CPU doesn't go up, and CoPP is applied; OSPF is authenticated on every >> adjacency (which are all point-to-point on SVIs), and we don't see any >> strange neighbors. > > Why are the neighbors going down? Hold time expired? If so you have to figure > out why those frames are dropped. Yes, hold time expired. Our current theory is CoPP itself dropping the packets. We have some large ACLs describing critical, normal and undesired traffic; if some OSPF frames don't flow thru the critical ACL, the normal category would only fill up during floods. There are terms on the critical ACL to match OSPF packets, but may be it's not matching all of them. >> It occurs more often with Internet access static connected route >> customers, but has now happened on a VRF as well. >> >> The only solution is disconnecting the customer; provisioning the >> customer on SVI or on routerport doesn't seem to have any effect. > > Is it OSPF going down on an interface other than where this "hammering" > is coming from? I'm assuming you mean it's a flood of traffic. The inbound interface for the flood doesn't run OSPF, only the upstream links to other routers. Rubens From rodunn at cisco.com Tue Sep 23 16:46:38 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 23 Sep 2008 16:46:38 -0400 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <20080922130445.GB12859@rtp-cse-489.cisco.com> References: <48CEC162.5000105@bytemark.co.uk> <20080916040858.GA17256@greenie.muc.de> <48CFC183.4060401@bytemark.co.uk> <20080916165849.GA20288@greenie.muc.de> <20080918201316.GD20288@greenie.muc.de> <20080919003643.GB79009@puck.nether.net> <20080919165126.GA11635@greenie.muc.de> <1221845016.11349.15.camel@abehat> <20080920192953.GD7160@greenie.muc.de> <20080922130445.GB12859@rtp-cse-489.cisco.com> Message-ID: <20080923204638.GM24139@rtp-cse-489.cisco.com> Gert, Seems they are not planning a special rebuild for this unfortunately. We are trying to get them to build a engineering special generally available for TAC if you have a SR open they should be able to get it. Sorry... Rodney On Mon, Sep 22, 2008 at 09:04:45AM -0400, Rodney Dunn wrote: > They are Gert. > > Let me check on it... > > On Sat, Sep 20, 2008 at 09:29:53PM +0200, Gert Doering wrote: > > Hi, > > > > On Fri, Sep 19, 2008 at 07:23:36PM +0200, Peter Rathlev wrote: > > > CSCsu59917 > > > SXF15: IPv4/v6 BGP routes not cleared when source routes is gone > > > Severity: 1 - catastrophic. > > > > Indeed... makes me wonder why they are not doing an SXH rebuild on their > > own, instead of making us wait 4-6 weeks for a bugfix for a *catastrophic* > > (!!) bug. > > > > (No news from our case yet regarding an interim rebuild) > > > > thanks, > > > > gert > > > > -- > > Gert Doering > > Mobile communications ... right now writing from * Sardegna, Italy * > > _______________________________________________ > > 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 rodunn at cisco.com Tue Sep 23 16:47:32 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 23 Sep 2008 16:47:32 -0400 Subject: [c-nsp] NPE-G2 Gigabit Ignored Errors In-Reply-To: <5.1.0.14.2.20080914093133.00ac0990@efes.iucc.ac.il> References: <200809121839.m8CIdHD3029666@e450.mnsi.net> <200809121649.m8CGngEV013138@e450.mnsi.net> <20080912181607.GR4860@rtp-cse-489.cisco.com> <200809121839.m8CIdHD3029666@e450.mnsi.net> <5.1.0.14.2.20080914093133.00ac0990@efes.iucc.ac.il> Message-ID: <20080923204732.GN24139@rtp-cse-489.cisco.com> Hank, Every time I've ever worked on this it's microburst. The only real way to fix it is a hardware forwarding box that can do packets at line rate gige. Rodney On Sun, Sep 14, 2008 at 09:38:26AM +0300, Hank Nussbacher wrote: > At 02:43 PM 12-09-08 -0400, Rodney Dunn wrote: > > Rodney, > > On a related note, we are seeing input overruns on almost all native GigaE > ports on the NPE-G1. Example on 12.4(21): > > GigabitEthernet0/2 is up, line protocol is up > Hardware is BCM1250 Internal MAC, address is 0009.446d.ac1a (bia > 0009.446d.ac1a) > MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, > reliability 255/255, txload 23/255, rxload 13/255 > Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set > Keepalive set (10 sec) > Full-duplex, 1000Mb/s, link type is force-up, media type is SX > output flow-control is unsupported, input flow-control is XON > ARP type: ARPA, ARP Timeout 04:00:00 > Last input 00:00:00, output 00:00:00, output hang never > Last clearing of "show interface" counters never > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: fifo > Output queue: 0/40 (size/max) > 30 second input rate 52874000 bits/sec, 13178 packets/sec > 30 second output rate 92696000 bits/sec, 14626 packets/sec > 13055246077 packets input, 7473426491146 bytes, 0 no buffer > Received 48343 broadcasts, 0 runts, 0 giants, 0 throttles > 315 input errors, 0 CRC, 0 frame, 315 overrun, 0 ignored > 0 watchdog, 2937496 multicast, 0 pause input > 0 input packets with dribble condition detected > > On 12.4(18): > GigabitEthernet0/1 is up, line protocol is up > Hardware is BCM1250 Internal MAC, address is 0009.449b.2c1b (bia > 0009.449b.2c1b) > MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec, > reliability 255/255, txload 29/255, rxload 41/255 > Encapsulation ARPA, loopback not set > Keepalive set (10 sec) > Full-duplex, 1000Mb/s, media type is RJ45 > output flow-control is XON, input flow-control is XON > ARP type: ARPA, ARP Timeout 00:04:00 > Last input 00:00:01, output 00:00:00, output hang never > Last clearing of "show interface" counters never > Input queue: 0/2048/0/3 (size/max/drops/flushes); Total output drops: > 139963 > Queueing strategy: fifo > Output queue: 0/1024 (size/max) > 30 second input rate 163604000 bits/sec, 25284 packets/sec > 30 second output rate 113775000 bits/sec, 23142 packets/sec > 138829558726 packets input, 110625630435301 bytes, 0 no buffer > Received 1170089 broadcasts, 0 runts, 0 giants, 0 throttles > 42963 input errors, 0 CRC, 0 frame, 42963 overrun, 0 ignored > 0 watchdog, 2939379 multicast, 0 pause input > 0 input packets with dribble condition detected > > On 12.4(9)T2: > GigabitEthernet0/2 is up, line protocol is up > Hardware is BCM1250 Internal MAC, address is 0009.449b.441a (bia > 0009.449b.441a) > MTU 1500 bytes, BW 450000 Kbit, DLY 10 usec, > reliability 255/255, txload 21/255, rxload 60/255 > Encapsulation ARPA, loopback not set > Keepalive set (10 sec) > Full-duplex, 1000Mb/s, media type is RJ45 > output flow-control is XON, input flow-control is XON > ARP type: ARPA, ARP Timeout 04:00:00 > Last input 00:00:00, output 00:00:00, output hang never > Last clearing of "show interface" counters never > Input queue: 0/1024/369/79002147 (size/max/drops/flushes); Total output > drops: 82 > Queueing strategy: fifo > Output queue: 0/1024 (size/max) > 30 second input rate 105976000 bits/sec, 13665 packets/sec > 30 second output rate 38207000 bits/sec, 11394 packets/sec > 2996785111 packets input, 3073612701 bytes, 2279 no buffer > Received 500907287 broadcasts, 0 runts, 0 giants, 2483 throttles > 8348 input errors, 0 CRC, 0 frame, 8348 overrun, 0 ignored > 0 watchdog, 497602409 multicast, 0 pause input > 0 input packets with dribble condition detected > > Any ideas why? > > -Hank > > >On Fri, Sep 12, 2008 at 02:40:04PM -0400, Clayton Zekelman wrote: > >> > >> No luck... didn't fix it. Is it fixed in a subsequent release? Are > >> there any other parameters I can tune? > > > >Not really because you can't tune the rx ring depth. > > > >Check 'sh controller'. > > > >What does 'sh proc cpu sort | excl 0.00' say? > > > >Can you post the configuration..I'm curious what your features > >look like because the more you have the less pps you get through > >this box..it's all done in software and can't do all features at line > >rate during a microburst. > > > >sh int stat > > > > > >Rodney > > > > > >> > >> GigabitEthernet0/1 is up, line protocol is up > >> Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia > >> 001a.6d30.091b) > >> Description: to gig-fastiron Ethernet11 > >> MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, > >> reliability 255/255, txload 23/255, rxload 48/255 > >> Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set > >> Keepalive set (10 sec) > >> Full-duplex, 1000Mb/s, media type is RJ45 > >> output flow-control is XON, input flow-control is XON > >> ARP type: ARPA, ARP Timeout 04:00:00 > >> Last input 00:00:00, output 00:00:00, output hang never > >> Last clearing of "show interface" counters 00:10:09 > >> Input queue: 0/4096/533/0 (size/max/drops/flushes); Total output > >drops: 0 > >> Queueing strategy: fifo > >> Output queue: 0/40 (size/max) > >> 30 second input rate 189692000 bits/sec, 30246 packets/sec > >> 30 second output rate 91448000 bits/sec, 27197 packets/sec > >> 18432915 packets input, 1555851456 bytes, 0 no buffer > >> Received 65 broadcasts, 0 runts, 0 giants, 0 throttles > >> 1117 input errors, 0 CRC, 0 frame, 0 overrun, 1117 ignored > >> 0 watchdog, 1034 multicast, 0 pause input > >> 0 input packets with dribble condition detected > >> > >> > >> > >> At 02:16 PM 9/12/2008, Rodney Dunn wrote: > >> >Can you bump up your input queue depth: > >> > > >> >hold-queue 4096 in > >> > > >> >and see if they stop. > >> > > >> >I don't suspect that is going to help because the ignores > >> >are not increasing that would point to: > >> > > >> >CSCse05447 > >> >Externally found moderate defect: Resolved (R) > >> >7200 ethernet interfaces should not throttle on input queue full drops > >> > > >> >Most likely you are seeing micro burst that are coming in faster > >> >than the CPU can drain the rx ring. > >> > > >> >Rodney > >> > > >> > > >> > > >> >On Fri, Sep 12, 2008 at 12:50:29PM -0400, Clayton Zekelman wrote: > >> >> > >> >> I'm running a Cisco 7206/VXR with an NPE G2, Version 12.4(4)XD4 > >> >> acting as an LNS. > >> >> > >> >> I'm getting input errors consistently incrementing on the Gig > >> >> interface (ignored errors) > >> >> > >> >> Any way to fix this? I saw some discussion a while back about this, > >> >> and it seemed to have to do with buffers - but I can't find any > >> >> definitive recommendations on what the settings should be. > >> >> > >> >> > >> >> > >> >> GigabitEthernet0/1 is up, line protocol is up > >> >> Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia > >> >> 001a.6d30.091b) > >> >> Description: to gig-fastiron Ethernet11 > >> >> MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, > >> >> reliability 255/255, txload 22/255, rxload 46/255 > >> >> Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set > >> >> Keepalive set (10 sec) > >> >> Full-duplex, 1000Mb/s, media type is RJ45 > >> >> output flow-control is XON, input flow-control is XON > >> >> ARP type: ARPA, ARP Timeout 04:00:00 > >> >> Last input 00:00:00, output 00:00:00, output hang never > >> >> Last clearing of "show interface" counters 00:22:17 > >> >> Input queue: 0/75/1191/0 (size/max/drops/flushes); Total output > >drops: > >> >0 > >> >> Queueing strategy: fifo > >> >> Output queue: 0/40 (size/max) > >> >> 30 second input rate 181384000 bits/sec, 29001 packets/sec > >> >> 30 second output rate 86319000 bits/sec, 26045 packets/sec > >> >> 38605963 packets input, 4274358612 bytes, 1 no buffer > >> >> Received 230 broadcasts, 0 runts, 0 giants, 0 throttles > >> >> 2677 input errors, 0 CRC, 0 frame, 0 overrun, 2677 ignored > >> >> 0 watchdog, 2196 multicast, 0 pause input > >> >> 0 input packets with dribble condition detected > >> >> 34556615 packets output, 1656923135 bytes, 0 underruns > >> >> 0 output errors, 0 collisions, 0 interface resets > >> >> 0 babbles, 0 late collision, 0 deferred > >> >> 0 lost carrier, 0 no carrier, 0 pause output > >> >> 0 output buffer failures, 0 output buffers swapped > >> >> out > >> >> > >> >> > >> >> > >> >> --- > >> >> Clayton Zekelman > >> >> Managed Network Systems Inc. (MNSi) > >> >> 344-300 Tecumseh Rd. E. > >> >> Windsor, Ontario > >> >> N8X 5E8 > >> >> > >> >> tel. 519-985-8410 > >> >> fax. 519-985-8409 > >> >> > >> >> _______________________________________________ > >> >> 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/ > >> > >> --- > >> Clayton Zekelman > >> Managed Network Systems Inc. (MNSi) > >> 344-300 Tecumseh Rd. E. > >> Windsor, Ontario > >> N8X 5E8 > >> > >> tel. 519-985-8410 > >> fax. 519-985-8409 > >_______________________________________________ > >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 rodunn at cisco.com Tue Sep 23 16:49:36 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 23 Sep 2008 16:49:36 -0400 Subject: [c-nsp] Weird OSPF meltdown In-Reply-To: <6bb5f5b10809231346t285e698eh9e7efec2f5f86136@mail.gmail.com> References: <6bb5f5b10809182245s3256abe7p8d0b931097632395@mail.gmail.com> <20080923184006.GG24139@rtp-cse-489.cisco.com> <6bb5f5b10809231346t285e698eh9e7efec2f5f86136@mail.gmail.com> Message-ID: <20080923204936.GP24139@rtp-cse-489.cisco.com> If it's a lot of punts and the hardware rate limiters don't catch them you would overrun the RP cpu or the ibc interface going up to the RP. Rodney On Tue, Sep 23, 2008 at 06:46:38PM -0200, Rubens Kuhl Jr. wrote: > On Tue, Sep 23, 2008 at 4:40 PM, Rodney Dunn wrote: > > On Fri, Sep 19, 2008 at 02:45:48AM -0300, Rubens Kuhl Jr. wrote: > >> Every once in a while one of ME6524 routers starts getting hammered by > >> one customer or the other... the symptom is that all adjacencies go > >> down and stay stuck at EXCHANGE phase. > > > > hammered by what? > > We could not get packet traces of all the mishaps, but in one of them > there was a flood of mDNS(Multicast DNS) packets. > > > > >> CPU doesn't go up, and CoPP is applied; OSPF is authenticated on every > >> adjacency (which are all point-to-point on SVIs), and we don't see any > >> strange neighbors. > > > > Why are the neighbors going down? Hold time expired? If so you have to figure > > out why those frames are dropped. > > Yes, hold time expired. > Our current theory is CoPP itself dropping the packets. We have some > large ACLs describing critical, normal and undesired traffic; if some > OSPF frames don't flow thru the critical ACL, the normal category > would only fill up during floods. There are terms on the critical ACL > to match OSPF packets, but may be it's not matching all of them. > > > >> It occurs more often with Internet access static connected route > >> customers, but has now happened on a VRF as well. > >> > >> The only solution is disconnecting the customer; provisioning the > >> customer on SVI or on routerport doesn't seem to have any effect. > > > > Is it OSPF going down on an interface other than where this "hammering" > > is coming from? I'm assuming you mean it's a flood of traffic. > > The inbound interface for the flood doesn't run OSPF, only the > upstream links to other routers. > > > Rubens From jhigham at epri.com Tue Sep 23 16:51:09 2008 From: jhigham at epri.com (Higham, Josh) Date: Tue, 23 Sep 2008 13:51:09 -0700 Subject: [c-nsp] Virtualization in an enterprise Message-ID: <4C3B8C75B5899943AEC675BA6DD4627301347156@uspalex02.epri.com> I am currently investigating using vrf-lite within our company to support some research requests. I have some hesitation about maintaining it, though, especially in a smaller enterprise environment (4 network techs, ~10 branches). I am comfortable with the technology, but don't want to increase the complexity of the network without significant advantages. More importantly, I don't want to limit the applicant pool if we need to hire someone down the road. Does anyone here have input on support and maintenance of this within an enterprise environment? We have sites connected by MPLS (BGP with the provider, but no other MPLS or vrf type features) with redundancy through an IPSEC VPN over our internet links. Thanks for any input that you can provide. Josh From jhigham at epri.com Tue Sep 23 16:51:09 2008 From: jhigham at epri.com (Higham, Josh) Date: Tue, 23 Sep 2008 13:51:09 -0700 Subject: [c-nsp] Virtualization in an enterprise Message-ID: <4C3B8C75B5899943AEC675BA6DD4627301347157@uspalex02.epri.com> I am currently investigating using vrf-lite within our company to support some research requests. I have some hesitation about maintaining it, though, especially in a smaller enterprise environment (4 network techs, ~10 branches). I am comfortable with the technology, but don't want to increase the complexity of the network without significant advantages. More importantly, I don't want to limit the applicant pool if we need to hire someone down the road. Does anyone here have input on support and maintenance of this within an enterprise environment? We have sites connected by MPLS (BGP with the provider, but no other MPLS or vrf type features) with redundancy through an IPSEC VPN over our internet links. Thanks for any input that you can provide. Josh From rodunn at cisco.com Tue Sep 23 16:48:18 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 23 Sep 2008 16:48:18 -0400 Subject: [c-nsp] NPE-G2 Gigabit Ignored Errors In-Reply-To: <5.1.0.14.2.20080914102031.00b20ea0@efes.iucc.ac.il> References: <200809121649.m8CGngEV013138@e450.mnsi.net> <200809121649.m8CGngEV013138@e450.mnsi.net> <5.1.0.14.2.20080914102031.00b20ea0@efes.iucc.ac.il> Message-ID: <20080923204818.GO24139@rtp-cse-489.cisco.com> That's only applicable if you have a lot of process switched traffic and you see input drops in 'sh int'. If you do see input queue drops and the "throttle" count in 'sh int' is going up you might be impacted by that bug. Rodney On Sun, Sep 14, 2008 at 10:21:41AM +0300, Hank Nussbacher wrote: > At 02:16 PM 12-09-08 -0400, Rodney Dunn wrote: > > >I don't suspect that is going to help because the ignores > >are not increasing that would point to: > > > >CSCse05447 > >Externally found moderate defect: Resolved (R) > >7200 ethernet interfaces should not throttle on input queue full drops > > > >Most likely you are seeing micro burst that are coming in faster > >than the CPU can drain the rx ring. > > > >Rodney > > Can't view it: > > "Information contained within bug ID CSCse05447 is only available to Cisco > employees. It is our policy to make all externally-facing bugs available in > Bug Toolkit so the system administrators have been automatically alerted to > the problem. By choosing to save this bug, you may be notified when the > decision to make this bug available to you has been made. Note: Some > product enhancement requests and documentation error bugs may not be > available in Bug Toolkit." > > -Hank > > > From rubensk at gmail.com Tue Sep 23 16:56:25 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Tue, 23 Sep 2008 18:56:25 -0200 Subject: [c-nsp] Weird OSPF meltdown In-Reply-To: <20080923204936.GP24139@rtp-cse-489.cisco.com> References: <6bb5f5b10809182245s3256abe7p8d0b931097632395@mail.gmail.com> <20080923184006.GG24139@rtp-cse-489.cisco.com> <6bb5f5b10809231346t285e698eh9e7efec2f5f86136@mail.gmail.com> <20080923204936.GP24139@rtp-cse-489.cisco.com> Message-ID: <6bb5f5b10809231356m591934d6ucb6570b7bc8875b8@mail.gmail.com> The problem with rate limiters is they will drop critical traffic (multicast OSPF) alongside multicast garbage from the customers. There is no hardware CoPP on the path of multicast traffic, so it's up to the CPU to survive such a flooding. Rubens On Tue, Sep 23, 2008 at 6:49 PM, Rodney Dunn wrote: > If it's a lot of punts and the hardware rate limiters don't catch > them you would overrun the RP cpu or the ibc interface going up to the > RP. > > Rodney > > On Tue, Sep 23, 2008 at 06:46:38PM -0200, Rubens Kuhl Jr. wrote: >> On Tue, Sep 23, 2008 at 4:40 PM, Rodney Dunn wrote: >> > On Fri, Sep 19, 2008 at 02:45:48AM -0300, Rubens Kuhl Jr. wrote: >> >> Every once in a while one of ME6524 routers starts getting hammered by >> >> one customer or the other... the symptom is that all adjacencies go >> >> down and stay stuck at EXCHANGE phase. >> > >> > hammered by what? >> >> We could not get packet traces of all the mishaps, but in one of them >> there was a flood of mDNS(Multicast DNS) packets. >> >> > >> >> CPU doesn't go up, and CoPP is applied; OSPF is authenticated on every >> >> adjacency (which are all point-to-point on SVIs), and we don't see any >> >> strange neighbors. >> > >> > Why are the neighbors going down? Hold time expired? If so you have to figure >> > out why those frames are dropped. >> >> Yes, hold time expired. >> Our current theory is CoPP itself dropping the packets. We have some >> large ACLs describing critical, normal and undesired traffic; if some >> OSPF frames don't flow thru the critical ACL, the normal category >> would only fill up during floods. There are terms on the critical ACL >> to match OSPF packets, but may be it's not matching all of them. >> >> >> >> It occurs more often with Internet access static connected route >> >> customers, but has now happened on a VRF as well. >> >> >> >> The only solution is disconnecting the customer; provisioning the >> >> customer on SVI or on routerport doesn't seem to have any effect. >> > >> > Is it OSPF going down on an interface other than where this "hammering" >> > is coming from? I'm assuming you mean it's a flood of traffic. >> >> The inbound interface for the flood doesn't run OSPF, only the >> upstream links to other routers. >> >> >> Rubens > From lowen at pari.edu Tue Sep 23 17:37:27 2008 From: lowen at pari.edu (Lamar Owen) Date: Tue, 23 Sep 2008 17:37:27 -0400 Subject: [c-nsp] c4000 Message-ID: <5958873.1411222205847171.JavaMail.root@scalix.pari.edu> From: Gert Doering gert at greenie.muc.de >On the cat4000 (as far as I know), you have no choice - it depends on the >Supervisor version in use. Older ones are catos-only, newer ones are >IOS-only. >Only on the cat6500, you can choose. Another pointer: http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a0080094713.shtml This is the best practices document for CatOS switches. Incidentally, even non-fabric Cat6K's can do native IOS mode, as it's a Supervisor/MSFC combo deal that goes back all the way to Sup1 and MSFC1. Sup2/MSFC2 without the fabric cards work well in Cat6K non-fabric chassis. Which begs the point: there should have been no technical reason Native IOS mode could not have been done with Catalyst 5500 with SupIIIG/RSFC or SupIII/RSM (although the RSM/Supervisor coupling is looser); or am I missing something the MSFC/ Cat6K supervisor has in the way of linkage? RSM of course being based on 7500 RSP technology, and RSFC based on 7200 NPE200 technology, may have been part of the difference (RSFC has more features, even with an older IOS, at least per feature navigator and it's wildly accurate assessments (no feature lists yet for 12.0(32)S11 on 12000 GRP...)). I know, moot point as RSFC/RSM and the whole Cat5K series is EOL'ed, but a guy can dream. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 828-862-5554 www.pari.edu From andy.saykao at staff.netspace.net.au Tue Sep 23 19:57:12 2008 From: andy.saykao at staff.netspace.net.au (Andy Saykao) Date: Wed, 24 Sep 2008 09:57:12 +1000 Subject: [c-nsp] How does the egress PE determine which VRF the VPN label is for? Message-ID: <56F211C5E3F24F47B103EA1B253822BE0365490F@vic-cr-ex1.staff.netspace.net.au> Given the scenario in which the packet has reached the egress PE, how does the router then determine which VRF the packet is destined for based on the remaining VPN label? I understand the concept of there being two labels, an IGP label and a VPN label. I'm just not sure how the egress PE is able to deduce that the VPN label is for a particular VRF. Eg: PE1 -> P1 -> P2 -> PE2 *** First, a CEF lookup is performed on PE1 at the time the IP packet enters the ingress PE from an interface belonging to VRF TEST and shows that the following tags/labels {4771 44169} are pushed onto the IP packet. PE1#sh ip cef vrf TEST 172.16.66.2 172.16.66.2/32, version 58, epoch 0, cached adjacency 203.10.x.x 0 packets, 0 bytes tag information set local tag: VPN-route-head fast tag rewrite with Gi0/0.11, 203.10.x.x, tags imposed: {4771 44169} Flow: Origin AS 0, Peer AS 0, mask 32 via 210.15.x.x, 0 dependencies, recursive next hop 203.10.x.x, GigabitEthernet0/0.11 via 210.15.x.x/32 valid cached adjacency tag rewrite with Gi0/0.11, 203.10.x.x, tags imposed: {4771 44169} *** The label packet then uses the IGP label to determine the LSP and ends up at PE2 with just the VPN label left {44169}. *** PE2 checks it's mpls forwarding table and finds the following entry: PE2#sh mpls forwarding-table label 44169 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 44169 Aggregate 172.16.66.2/32[V] 5752 *** From the book "MPLS Fundamentals", it says - "Aggregate means that the aggregating LSR needs to remove the label of the incoming packet and must do an IP lookup to determine the more specific prefix to use for forwarding this IP packet." What I don't get from that explaination is: - What is involved in doing an "IP lookup" as the next step? - How does the router figure out that the prefix 172.16.66.2 is a route belonging to VRF TEST? - Is it something to do with MP-BGP because when I do a BGP lookup on the prefix, I see the word "aggregate" followed by the VRF name. How does this information then tie in with what's contained in the mpls forwarding table to deduce that it's VRF TEST we want. PE2#sh ip bgp vpnv4 rd 4854:100660 172.16.66.2 BGP routing table entry for 4854:100660:172.16.66.2/32, version 811 Paths: (1 available, best #1, table TEST) Advertised to peer-groups: NS-MPLS-VPN Local 0.0.0.0 from 0.0.0.0 (203.17.x.x) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:4854:100660, mpls labels in/out 44169/aggregate(TEST) Everything is working fine - I'm just trying to understand the little intricate details of MPLS VPN's that make them work, so I can picture it in my mind. Thanks. Andy Probably an easy question, but what is the next step that a router takes to find the next interface or next hop it needs to send the VPN label to? 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 RTeller at deltadentalwa.com Tue Sep 23 20:05:22 2008 From: RTeller at deltadentalwa.com (Teller, Robert) Date: Tue, 23 Sep 2008 17:05:22 -0700 Subject: [c-nsp] Configure Cisco Ace using XML Message-ID: <06C1E76E03FE9C4B85BFA9C75365D9DA0FC0137C@tiger.deltadentalwa.com> I know it was possible to configure Cisco CSS devices by posting an xml file to them. After migrating from the CSS to the ACE module I will need to do the same thing but I am having problems finding example xml files. Anyone have anything that I could use to get started? Robert Teller Washington Dental Service Network Administrator (206) 528-2371 RTeller at DeltaDentalWa.com ######################################################### The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended for the sole use of the individual and entity to whom it is addressed. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. ######################################################### From brandon at sterling.net Tue Sep 23 19:34:54 2008 From: brandon at sterling.net (Brandon Price) Date: Tue, 23 Sep 2008 16:34:54 -0700 Subject: [c-nsp] Conditional BGP In-Reply-To: <001801c91d9f$df280fc0$9d782f40$@org> References: <002401c91d79$3adb7900$b0926b00$@org><48D92212.4060607@templin.org> <001801c91d9f$df280fc0$9d782f40$@org> Message-ID: Could you guys recommend some good books or other documentation on some of these BGP "best practice" methodologies? I am a BGP novice but would like to get myself more up to speed on BGP kung fu. I found this current thread somewhat fascinating. Thanks Brandon -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Paul Stewart Sent: Tuesday, September 23, 2008 10:15 AM To: 'Pete Templin' Cc: 'cisco-nsp' Subject: Re: [c-nsp] Conditional BGP Thanks Pete.... yeah, thought that through as well - been there done that ;) We'll offer them a full feed (well, all three options but I know they'll want a full feed I believe - that's what they get via Cogent as well) and then they can control everything - with communities as well on our side. We always local-pref customers 300, peers 200, transit 100 and been caught on that before hehe... I'm happy if the decisions are on the customer and we're "just" the provider.... Take care, Paul -----Original Message----- From: Pete Templin [mailto:petelists at templin.org] Sent: Tuesday, September 23, 2008 1:06 PM To: Paul Stewart Cc: 'cisco-nsp' Subject: Re: [c-nsp] Conditional BGP Paul Stewart wrote: > What is common practice for this scenario? We would still prefer to just > send a full table and put the control into their hands but I'm also > concerned if they will have the technical expertise to accomplish this.. On > their side, what would be common practice? I've been looking at conditional > BGP advertisements using route-maps but don't believe that's the best > solution.. They can control their outbound fairly easily. They should make sure they're getting the same level (default-only, partial, full) of routes from you as from Cogent - if they take more from you, those routes are more-specific and would win regardless. I'd suggest they take default-only from you (or more but filter out everything but default so they can change on the fly later) and whatever they wish from Cogent. Controlling inbound is often tougher. Any smart provider sets a higher local pref on customer routes than on transit/peer routes (make money rather than pay money), so if you do this you'll need to make an exception for them (or offer the exception via communities). Otherwise, you'll prefer their announcement no matter how many prepends they do, and if that happens for a minute, your transits will likely prefer your propagation no matter how many prepends they do. Even if you don't do this today, if Cogent goes down, you'll choose the direct link (it's the only one live) and your transits will do the same thing (your routes have customer LP in their network). When Cogent comes up, your transits will ignore the Cogent-propagated route since it's only peer LP. They'd have to bounce the link to you to restore their preferred balance. You'll need to find out how to accomplish the same thing in your providers' networks as well. (Been there, done that, got the t-shirt.) pt _______________________________________________ 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 Tue Sep 23 20:50:30 2008 From: petelists at templin.org (Pete Templin) Date: Tue, 23 Sep 2008 19:50:30 -0500 Subject: [c-nsp] Conditional BGP In-Reply-To: References: <002401c91d79$3adb7900$b0926b00$@org><48D92212.4060607@templin.org> <001801c91d9f$df280fc0$9d782f40$@org> Message-ID: <48D98ED6.60403@templin.org> Brandon Price wrote: > Could you guys recommend some good books or other documentation on some > of these BGP "best practice" methodologies? I am a BGP novice but would > like to get myself more up to speed on BGP kung fu. > I found this current thread somewhat fascinating. That's a tough question to answer well. To date, I haven't found many books that give the real-world knowledge needed to "make one a pro". A few recommendations do come to mind though: 1) Ask a few folks for sample configs (I'll ping separately offlist and we'll figure out which ones I can send that'll make sense). 2) View the NANOG presentation archives. Several come to mind; I'll try to compile a list of suggestions, or just browse away. 3) "Be the router." Use 3x5 notecards or something, and think through the BGP decision process for a single prefix sometime, as though you're each relevant router along a particular path. When I have to troubleshoot a problem, I go through this myself router-by-router, and it works (since...it's...what really happens!) quite well. pt From agristina+cisco-nsp at gmail.com Tue Sep 23 20:50:54 2008 From: agristina+cisco-nsp at gmail.com (Andrew Gristina) Date: Tue, 23 Sep 2008 17:50:54 -0700 Subject: [c-nsp] Conditional BGP In-Reply-To: References: <002401c91d79$3adb7900$b0926b00$@org> <48D92212.4060607@templin.org> <001801c91d9f$df280fc0$9d782f40$@org> Message-ID: <70bb1b8f0809231750t2b301655m33a822618098a1ff@mail.gmail.com> The classics on BGP are Routing TCP/IP vol 1 and 2 by Doyle and Internet Routing Architectures by Sam Halabi. If you understand those, you understand enough to have some "BGP kung fu". On Tue, Sep 23, 2008 at 4:34 PM, Brandon Price wrote: > Could you guys recommend some good books or other documentation on some > of these BGP "best practice" methodologies? I am a BGP novice but would > like to get myself more up to speed on BGP kung fu. > I found this current thread somewhat fascinating. > > Thanks > Brandon > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Paul Stewart > Sent: Tuesday, September 23, 2008 10:15 AM > To: 'Pete Templin' > Cc: 'cisco-nsp' > Subject: Re: [c-nsp] Conditional BGP > > Thanks Pete.... yeah, thought that through as well - been there done > that ;) > We'll offer them a full feed (well, all three options but I know they'll > want a full feed I believe - that's what they get via Cogent as well) > and > then they can control everything - with communities as well on our side. > We > always local-pref customers 300, peers 200, transit 100 and been caught > on > that before hehe... I'm happy if the decisions are on the customer and > we're "just" the provider.... > > Take care, > > Paul > > > -----Original Message----- > From: Pete Templin [mailto:petelists at templin.org] > Sent: Tuesday, September 23, 2008 1:06 PM > To: Paul Stewart > Cc: 'cisco-nsp' > Subject: Re: [c-nsp] Conditional BGP > > Paul Stewart wrote: > >> What is common practice for this scenario? We would still prefer to > just >> send a full table and put the control into their hands but I'm also >> concerned if they will have the technical expertise to accomplish > this.. > On >> their side, what would be common practice? I've been looking at > conditional >> BGP advertisements using route-maps but don't believe that's the best >> solution.. > > They can control their outbound fairly easily. They should make sure > they're getting the same level (default-only, partial, full) of routes > from you as from Cogent - if they take more from you, those routes are > more-specific and would win regardless. I'd suggest they take > default-only from you (or more but filter out everything but default so > they can change on the fly later) and whatever they wish from Cogent. > > Controlling inbound is often tougher. Any smart provider sets a higher > local pref on customer routes than on transit/peer routes (make money > rather than pay money), so if you do this you'll need to make an > exception for them (or offer the exception via communities). Otherwise, > > you'll prefer their announcement no matter how many prepends they do, > and if that happens for a minute, your transits will likely prefer your > propagation no matter how many prepends they do. Even if you don't do > this today, if Cogent goes down, you'll choose the direct link (it's the > > only one live) and your transits will do the same thing (your routes > have customer LP in their network). When Cogent comes up, your transits > > will ignore the Cogent-propagated route since it's only peer LP. They'd > > have to bounce the link to you to restore their preferred balance. > You'll need to find out how to accomplish the same thing in your > providers' networks as well. (Been there, done that, got the t-shirt.) > > pt > > _______________________________________________ > 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 rodunn at cisco.com Tue Sep 23 21:01:15 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Tue, 23 Sep 2008 21:01:15 -0400 Subject: [c-nsp] How does the egress PE determine which VRF the VPN label is for? In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE0365490F@vic-cr-ex1.staff.netspace.net.au> References: <56F211C5E3F24F47B103EA1B253822BE0365490F@vic-cr-ex1.staff.netspace.net.au> Message-ID: <20080924010115.GB29877@rtp-cse-489.cisco.com> On Wed, Sep 24, 2008 at 09:57:12AM +1000, Andy Saykao wrote: > Given the scenario in which the packet has reached the egress PE, how > does the router then determine which VRF the packet is destined for > based on the remaining VPN label? I understand the concept of there > being two labels, an IGP label and a VPN label. I'm just not sure how > the egress PE is able to deduce that the VPN label is for a particular > VRF. > > Eg: > > PE1 -> P1 -> P2 -> PE2 > > *** First, a CEF lookup is performed on PE1 at the time the IP packet > enters the ingress PE from an interface belonging to VRF TEST and shows > that the following tags/labels {4771 44169} are pushed onto the IP > packet. > > PE1#sh ip cef vrf TEST 172.16.66.2 > 172.16.66.2/32, version 58, epoch 0, cached adjacency 203.10.x.x > 0 packets, 0 bytes > tag information set > local tag: VPN-route-head > fast tag rewrite with Gi0/0.11, 203.10.x.x, tags imposed: {4771 > 44169} > Flow: Origin AS 0, Peer AS 0, mask 32 > via 210.15.x.x, 0 dependencies, recursive > next hop 203.10.x.x, GigabitEthernet0/0.11 via 210.15.x.x/32 > valid cached adjacency > tag rewrite with Gi0/0.11, 203.10.x.x, tags imposed: {4771 44169} > > *** The label packet then uses the IGP label to determine the LSP and > ends up at PE2 with just the VPN label left {44169}. > > *** PE2 checks it's mpls forwarding table and finds the following entry: > > PE2#sh mpls forwarding-table label 44169 > Local Outgoing Prefix Bytes tag Outgoing Next Hop > tag tag or VC or Tunnel Id switched interface > 44169 Aggregate 172.16.66.2/32[V] 5752 > > *** From the book "MPLS Fundamentals", it says - "Aggregate means that > the aggregating LSR needs to remove the label of the incoming packet and > must do an IP lookup to determine the more specific prefix to use for > forwarding this IP packet." > > What I don't get from that explaination is: > > - What is involved in doing an "IP lookup" as the next step? It means the aggregate just tells the PE that the ip address is connected and in a particular VRF. There are different ways to implement it. per prefix lables, aggregats for only connected in a vrf, etc. > - How does the router figure out that the prefix 172.16.66.2 is a route > belonging to VRF TEST? based on the local VPN label allocated for either all connected or that specific route. A table is maintained to map them. That's why you can do 'sh ip bgp vpnv4 vrf blah and it show the vpnv4 label. > - Is it something to do with MP-BGP because when I do a BGP lookup on > the prefix, I see the word "aggregate" followed by the VRF name. How > does this information then tie in with what's contained in the mpls > forwarding table to deduce that it's VRF TEST we want. Different protocols can insert labels in the lfib. ie: ldp, bgp, etc. BGP can allocate a lable for VPNV4 prefixes and then advertise that to remote PE's to tell them what label to send with. Then ldp sends labels hop by hop to get to the PE's loopback (outer label as we call it). > > PE2#sh ip bgp vpnv4 rd 4854:100660 172.16.66.2 > BGP routing table entry for 4854:100660:172.16.66.2/32, version 811 > Paths: (1 available, best #1, table TEST) > Advertised to peer-groups: > NS-MPLS-VPN > Local > 0.0.0.0 from 0.0.0.0 (203.17.x.x) > Origin incomplete, metric 0, localpref 100, weight 32768, valid, > sourced, best > Extended Community: RT:4854:100660, > mpls labels in/out 44169/aggregate(TEST) > > Everything is working fine - I'm just trying to understand the little > intricate details of MPLS VPN's that make them work, so I can picture it > in my mind. > > Thanks. > > Andy > > > > > > > > > > > Probably an easy question, but what is the next step that a router takes > to find the next interface or next hop it needs to send the VPN label > to? > > > 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/ From andy.saykao at staff.netspace.net.au Tue Sep 23 21:17:27 2008 From: andy.saykao at staff.netspace.net.au (Andy Saykao) Date: Wed, 24 Sep 2008 11:17:27 +1000 Subject: [c-nsp] How does the egress PE determine which VRF the VPN label is for? Message-ID: <56F211C5E3F24F47B103EA1B253822BE03654910@vic-cr-ex1.staff.netspace.net.au> Argh cool. Thanks for that explaination Rodney. You wrote: "based on the local VPN label allocated for either all connected or that specific route. A table is maintained to map them. " Is there a command to view this "table" to check the mappings or is this something internal to the PE router? Thanks. Andy -----Original Message----- From: Rodney Dunn [mailto:rodunn at cisco.com] Sent: Wednesday, 24 September 2008 11:01 AM To: Andy Saykao Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] How does the egress PE determine which VRF the VPN label is for? On Wed, Sep 24, 2008 at 09:57:12AM +1000, Andy Saykao wrote: > Given the scenario in which the packet has reached the egress PE, how > does the router then determine which VRF the packet is destined for > based on the remaining VPN label? I understand the concept of there > being two labels, an IGP label and a VPN label. I'm just not sure how > the egress PE is able to deduce that the VPN label is for a particular > VRF. > > Eg: > > PE1 -> P1 -> P2 -> PE2 > > *** First, a CEF lookup is performed on PE1 at the time the IP packet > enters the ingress PE from an interface belonging to VRF TEST and > shows that the following tags/labels {4771 44169} are pushed onto the > IP packet. > > PE1#sh ip cef vrf TEST 172.16.66.2 > 172.16.66.2/32, version 58, epoch 0, cached adjacency 203.10.x.x 0 > packets, 0 bytes > tag information set > local tag: VPN-route-head > fast tag rewrite with Gi0/0.11, 203.10.x.x, tags imposed: {4771 > 44169} > Flow: Origin AS 0, Peer AS 0, mask 32 > via 210.15.x.x, 0 dependencies, recursive > next hop 203.10.x.x, GigabitEthernet0/0.11 via 210.15.x.x/32 > valid cached adjacency > tag rewrite with Gi0/0.11, 203.10.x.x, tags imposed: {4771 44169} > > *** The label packet then uses the IGP label to determine the LSP and > ends up at PE2 with just the VPN label left {44169}. > > *** PE2 checks it's mpls forwarding table and finds the following entry: > > PE2#sh mpls forwarding-table label 44169 > Local Outgoing Prefix Bytes tag Outgoing Next Hop > tag tag or VC or Tunnel Id switched interface > 44169 Aggregate 172.16.66.2/32[V] 5752 > > *** From the book "MPLS Fundamentals", it says - "Aggregate means that > the aggregating LSR needs to remove the label of the incoming packet > and must do an IP lookup to determine the more specific prefix to use > for forwarding this IP packet." > > What I don't get from that explaination is: > > - What is involved in doing an "IP lookup" as the next step? It means the aggregate just tells the PE that the ip address is connected and in a particular VRF. There are different ways to implement it. per prefix lables, aggregats for only connected in a vrf, etc. > - How does the router figure out that the prefix 172.16.66.2 is a > route belonging to VRF TEST? based on the local VPN label allocated for either all connected or that specific route. A table is maintained to map them. That's why you can do 'sh ip bgp vpnv4 vrf blah and it show the vpnv4 label. > - Is it something to do with MP-BGP because when I do a BGP lookup on > the prefix, I see the word "aggregate" followed by the VRF name. How > does this information then tie in with what's contained in the mpls > forwarding table to deduce that it's VRF TEST we want. Different protocols can insert labels in the lfib. ie: ldp, bgp, etc. BGP can allocate a lable for VPNV4 prefixes and then advertise that to remote PE's to tell them what label to send with. Then ldp sends labels hop by hop to get to the PE's loopback (outer label as we call it). > > PE2#sh ip bgp vpnv4 rd 4854:100660 172.16.66.2 BGP routing table entry > for 4854:100660:172.16.66.2/32, version 811 > Paths: (1 available, best #1, table TEST) > Advertised to peer-groups: > NS-MPLS-VPN > Local > 0.0.0.0 from 0.0.0.0 (203.17.x.x) > Origin incomplete, metric 0, localpref 100, weight 32768, valid, > sourced, best > Extended Community: RT:4854:100660, > mpls labels in/out 44169/aggregate(TEST) > > Everything is working fine - I'm just trying to understand the little > intricate details of MPLS VPN's that make them work, so I can picture > it in my mind. > > 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 tvarriale at comcast.net Tue Sep 23 21:18:11 2008 From: tvarriale at comcast.net (Tony Varriale) Date: Tue, 23 Sep 2008 20:18:11 -0500 Subject: [c-nsp] Conditional BGP References: <002401c91d79$3adb7900$b0926b00$@org><48D92212.4060607@templin.org><001801c91d9f$df280fc0$9d782f40$@org> Message-ID: <002201c91de3$69eb74b0$0100fea9@flamadam> Try BGP Design and Implementation. It's the "new" BGP bible. ISBN: 1-58705-109-5 tv ----- Original Message ----- From: "Brandon Price" To: "Paul Stewart" ; "Pete Templin" Cc: "cisco-nsp" Sent: Tuesday, September 23, 2008 6:34 PM Subject: Re: [c-nsp] Conditional BGP > Could you guys recommend some good books or other documentation on some > of these BGP "best practice" methodologies? I am a BGP novice but would > like to get myself more up to speed on BGP kung fu. > I found this current thread somewhat fascinating. > > Thanks > Brandon > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Paul Stewart > Sent: Tuesday, September 23, 2008 10:15 AM > To: 'Pete Templin' > Cc: 'cisco-nsp' > Subject: Re: [c-nsp] Conditional BGP > > Thanks Pete.... yeah, thought that through as well - been there done > that ;) > We'll offer them a full feed (well, all three options but I know they'll > want a full feed I believe - that's what they get via Cogent as well) > and > then they can control everything - with communities as well on our side. > We > always local-pref customers 300, peers 200, transit 100 and been caught > on > that before hehe... I'm happy if the decisions are on the customer and > we're "just" the provider.... > > Take care, > > Paul > > > -----Original Message----- > From: Pete Templin [mailto:petelists at templin.org] > Sent: Tuesday, September 23, 2008 1:06 PM > To: Paul Stewart > Cc: 'cisco-nsp' > Subject: Re: [c-nsp] Conditional BGP > > Paul Stewart wrote: > >> What is common practice for this scenario? We would still prefer to > just >> send a full table and put the control into their hands but I'm also >> concerned if they will have the technical expertise to accomplish > this.. > On >> their side, what would be common practice? I've been looking at > conditional >> BGP advertisements using route-maps but don't believe that's the best >> solution.. > > They can control their outbound fairly easily. They should make sure > they're getting the same level (default-only, partial, full) of routes > from you as from Cogent - if they take more from you, those routes are > more-specific and would win regardless. I'd suggest they take > default-only from you (or more but filter out everything but default so > they can change on the fly later) and whatever they wish from Cogent. > > Controlling inbound is often tougher. Any smart provider sets a higher > local pref on customer routes than on transit/peer routes (make money > rather than pay money), so if you do this you'll need to make an > exception for them (or offer the exception via communities). Otherwise, > > you'll prefer their announcement no matter how many prepends they do, > and if that happens for a minute, your transits will likely prefer your > propagation no matter how many prepends they do. Even if you don't do > this today, if Cogent goes down, you'll choose the direct link (it's the > > only one live) and your transits will do the same thing (your routes > have customer LP in their network). When Cogent comes up, your transits > > will ignore the Cogent-propagated route since it's only peer LP. They'd > > have to bounce the link to you to restore their preferred balance. > You'll need to find out how to accomplish the same thing in your > providers' networks as well. (Been there, done that, got the t-shirt.) > > pt > > _______________________________________________ > 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 booloo at ucsc.edu Tue Sep 23 21:06:04 2008 From: booloo at ucsc.edu (Mark Boolootian) Date: Tue, 23 Sep 2008 18:06:04 -0700 Subject: [c-nsp] Conditional BGP In-Reply-To: <48D98ED6.60403@templin.org> References: <001801c91d9f$df280fc0$9d782f40$@org> <48D98ED6.60403@templin.org> Message-ID: <20080924010604.GA33338@root.ucsc.edu> > 2) View the NANOG presentation archives. Several come to mind; I'll try to > compile a list of suggestions, or just browse away. Search the presentation archive for Smith and BGP. Philip Smith's BGP tutorials are outstanding. From andy.saykao at staff.netspace.net.au Tue Sep 23 22:36:33 2008 From: andy.saykao at staff.netspace.net.au (Andy Saykao) Date: Wed, 24 Sep 2008 12:36:33 +1000 Subject: [c-nsp] How does the egress PE determine which VRF the VPN label is for? Message-ID: <56F211C5E3F24F47B103EA1B253822BE03654911@vic-cr-ex1.staff.netspace.net.au> Argh worked it out. The VRF is seen if you include the "detail" in the command. PE2#sh mpls forwarding-table detail | begin _44169_ 44169 Aggregate 172.16.66.2/32[V] 5752 MAC/Encaps=0/0, MRU=0, Tag Stack{} VPN route: TEST No output feature configured 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 jason at lixfeld.ca Tue Sep 23 22:52:34 2008 From: jason at lixfeld.ca (Jason Lixfeld) Date: Tue, 23 Sep 2008 22:52:34 -0400 Subject: [c-nsp] debugging all incoming traffic on an interface In-Reply-To: <20080923172727.GY24139@rtp-cse-489.cisco.com> References: <765087.96249.qm@web25502.mail.ukl.yahoo.com> <20080923172727.GY24139@rtp-cse-489.cisco.com> Message-ID: It may, however it doesn't appear 12.4 is supported on the 2651. On 23-Sep-08, at 1:27 PM, Rodney Dunn wrote: > Might this help if you get on 12.4(20)T: > > http://supportwiki.cisco.com/ViewWiki/index.php/Tech_Insights:Utilizing_the_New_Packet_Capture_Feature > > > > On Tue, Sep 23, 2008 at 10:42:00AM -0400, Jason Lixfeld wrote: >> I have. There are no interface conditions on either of those debug >> [ip] packet commands. Also, debug interface doesn't allow me the >> option of my ATM interface(s). >> >> On 23-Sep-08, at 9:03 AM, Ozgur Guler wrote: >> >>> >>> Have you tried using >>> debug ip packet or >>> debug packet with >>> debug condition interface? >>> >>> >>> >>> --- On Mon, 22/9/08, Jason Lixfeld wrote: >>> From: Jason Lixfeld >>> Subject: [c-nsp] debugging all incoming traffic on an interface >>> To: cisco-nsp at puck.nether.net >>> Date: Monday, 22 September, 2008, 11:52 PM >>> >>> I'm trying to give a local ILEC an idea on where to look to >>> troubleshoot an issue on a bridged DSL circuit. It terminates >>> directly onto a WIC-1ADSL interface in a 2651 on the one side and a >>> VLAN on the other side. Can't pass traffic over it, but the inbound >>> packet counters are incrementing on the 2651 side, however I have no >>> idea what kind of >>> traffic is actually hitting the interface, nor do I >>> know what the source or destination of the traffic is. >>> >>> My question in all of this is what's the best way to see all the >>> traffic coming into this interface? Attaching a access-list 100 >>> permit ip any any log-input to the interface and/or subinterface via >>> ip access-group didn't show anything - the interface counters >>> incremented while the access-list counter didn't. I can't debug the >>> ATM (sub)interface, nor can I configure a SPAN port on an ATM >>> (sub)interface. >>> >>> Anyone know how I might go about this? I suppose in a worst case >>> scenario, I could hook up a DSL modem to the line and plug that >>> into a >>> wireshark box, but I'm hoping there's a more localized solution. >>> >>> Thanks in advance. >>> _______________________________________________ >>> 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 farhan at cyber.net.pk Tue Sep 23 23:59:57 2008 From: farhan at cyber.net.pk (Farhan Ali Khan) Date: Wed, 24 Sep 2008 08:59:57 +0500 Subject: [c-nsp] multiple PPPOE sessions Message-ID: <0K7O00IVAJ0NUY20@smtp.cyber.net.pk> Dear All Is there any tester which can make multiple PPPOE sessions, need to test radius max limit concurrent sessions, I was searching for a software base solution for it since last night but I guess there is no software initiate for this purpose if any one knows either software which can accomplished the same task or any hard based solution please reply. Thanks Regards Farhan Ali Khan From farhan at cyber.net.pk Wed Sep 24 00:32:48 2008 From: farhan at cyber.net.pk (Farhan Ali Khan) Date: Wed, 24 Sep 2008 09:32:48 +0500 Subject: [c-nsp] c4000 In-Reply-To: <510587.56451.qm@web33303.mail.mud.yahoo.com> Message-ID: <0K7O00IZ1KJEUX40@smtp.cyber.net.pk> Earlier switches run CATOS There is a difference between set base CLIs [CAT 4K] and normal CLIs commands [2960] For 2960 Vlan 10 Name engineering Interface x/x Switchportt access vlan 10 Or for trunk / Access Switchport mode access / trunk For CAT 4K Run borth cmd from enable mode Set vlan 10 name engineering Set vlan 10 x/x // where x/x is your interface number like fas0/1 Set vlan 10 x/a-b // x is module name and a - b is port range By default, Fast Ethernet and Gigabit Ethernet ports are in auto mode. If the port on the other end of the link is in desirable mode or on, a port in auto mode automatically becomes a trunk port. set trunk x/x desirable dot1q set trunk x/x dot1q verify it by "show trunk" clear -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of adrian kok Sent: 23 September, 2008 3:59 AM To: cisco-nsp at puck.nether.net Subject: [c-nsp] c4000 Hi all ls any different to setup vlan between catalyst 4000 and 2960? I need to setup the cisco2800 to have vlan this 4000 switch ls it easy? how setup the trunk port in 4000 switch? Thank you Send instant messages to your online friends http://uk.messenger.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 zivl at gilat.net Wed Sep 24 02:03:17 2008 From: zivl at gilat.net (Ziv Leyes) Date: Wed, 24 Sep 2008 09:03:17 +0300 Subject: [c-nsp] Debugging Cisco VPN Client Software ... Is it even possible ? In-Reply-To: <48D939A9.4060900@justinshore.com> References: <20080923122729.GC3152@stlux503.dsto.defence.gov.au> <48D939A9.4060900@justinshore.com> Message-ID: I second Justin, just sharper: Don't mix Vista with anything... -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Justin Shore Sent: Tuesday, September 23, 2008 9:47 PM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Debugging Cisco VPN Client Software ... Is it even possible ? Wilkinson, Alex wrote: > Any hot tips with how to debug VPN clients not being able to connect into a vpn > concentrator (from the _client_ perspective) ? Yes. Don't mix Vista with Cisco's VPN client. 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/ ************************************************************************************ 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 Sep 24 03:52:13 2008 From: gkg at gmx.de (Garry) Date: Wed, 24 Sep 2008 09:52:13 +0200 Subject: [c-nsp] Converting OSPF backbone to iBGP Message-ID: <48D9F1AD.8010607@gmx.de> Hi, after years of running very smoothly and without any problems (and not expecting any), we have decided to move our backbone from OSPF (single area) to iBGP as far as "best practice" recommendations go ... I've been trying to find decent write-ups about certain things, but haven't been too successful as far as certain details go ... maybe somebody has some good pointers for me ... OK, so baseline recommendation is to only transport loopback/interface IPs in OSPF, do everything else via iBGP ... Now, we already have two route reflectors running which we use for MPLS VRF connectivity, so moving everything else over to them shouldn't be too much of a problem ... For the basic stuff I'm not worried much, dropping the "redistribute static/connected subnets" isn't much of a problem, neither is adding the connected/static routes to the local BGP network statements ... problem is several devices that do not speak BGP ... e.g. two Ascend MAX routers that terminate ISDN PRI lines - they don't speak BGP, so all I can do is let them continue in OSPF ... what would I need to do to get them into the iBGP setup decently? Please note that apart from the dynamic IPs from a certain pool they also hand out static IPs for ISDN dial backup, so just statically routing certain IP ranges to them isn't an option ... which means I need to do some kind of export from OSPF into iBGP for those boxes by some other boxes (every POP/backbone site has Cisco backbone boxes, so appropriate HW is available) Also, we have CPE devices that speak OSPF to our equipment in order to set up dual uplinks to customer sites ... usually one link is a "regular" leased line to one POP/Backbone site, whereas the second is a DSL link where the terminating LAC (at another POP/Backbone site) currently announces the customer routes into OSPF with lower priority ... so I need a way of getting them OSPF informations into iBGP without it making its way into the OSPF backbone ... Any ideas or pointers? Thanks! From mtinka at globaltransit.net Wed Sep 24 04:19:29 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 24 Sep 2008 16:19:29 +0800 Subject: [c-nsp] Converting OSPF backbone to iBGP In-Reply-To: <48D9F1AD.8010607@gmx.de> References: <48D9F1AD.8010607@gmx.de> Message-ID: <200809241619.34647.mtinka@globaltransit.net> On Wednesday 24 September 2008 15:52:13 Garry wrote: > after years of running very smoothly and without any > problems (and not expecting any), we have decided to move > our backbone from OSPF (single area) to iBGP as far as > "best practice" recommendations go ... This is, indeed, a best practice as far as scaling the autonomous system goes. > I've been trying > to find decent write-ups about certain things, but > haven't been too successful as far as certain details go > ... maybe somebody has some good pointers for me ... Philip Smith (Cisco) has some very good slides on this and other best practice scaling techniques for ISP's that he gives at various workshops and conferences. You can Google to find a lot of these. > OK, so baseline recommendation is to only transport > loopback/interface IPs in OSPF, do everything else via > iBGP ... Correct. > Also, we have CPE devices that speak OSPF to our > equipment in order to set up dual uplinks to customer > sites ... As a friend of mine would say, "I recommend my competitors do that..." But seriously, running an IGP with your customers isn't a good idea (unless you're doing l3vpn's). I'd recommend running eBGP with your customer's CPE, and keep the OSPF "internal". 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 Wed Sep 24 05:03:27 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 24 Sep 2008 17:03:27 +0800 Subject: [c-nsp] Performance Of www.cisco.com Message-ID: <200809241703.33039.mtinka@globaltransit.net> Hi all. Not sure if it's just me but for the past several months, I've found the performance (response times) when browsing www.cisco.com is not all too great. I've tried using different paths to reach the site, and in some cases, there is short-lived improvement, and things go back to not_being_so_good. Is anyone else seeing this, or it's just me? The problem seems to extend to downloading files off of CCO as well. 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 maamoo at gmail.com Wed Sep 24 05:11:58 2008 From: maamoo at gmail.com (S H A N) Date: Wed, 24 Sep 2008 17:11:58 +0800 Subject: [c-nsp] Performance Of www.cisco.com In-Reply-To: <200809241703.33039.mtinka@globaltransit.net> References: <200809241703.33039.mtinka@globaltransit.net> Message-ID: hi, i guess its about time the cco should sit behind akamai or limelight... what do you think? On Wed, Sep 24, 2008 at 5:03 PM, Mark Tinka wrote: > Hi all. > > Not sure if it's just me but for the past several months, > I've found the performance (response times) when browsing > www.cisco.com is not all too great. > > I've tried using different paths to reach the site, and in > some cases, there is short-lived improvement, and things go > back to not_being_so_good. > > Is anyone else seeing this, or it's just me? > > The problem seems to extend to downloading files off of CCO > as well. > > Cheers, > > Mark. > > _______________________________________________ > 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/ > -- Best Regards. From p.mayers at imperial.ac.uk Wed Sep 24 05:39:18 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Wed, 24 Sep 2008 10:39:18 +0100 Subject: [c-nsp] Best bet 65 IOS for mcast? In-Reply-To: References: Message-ID: <48DA0AC6.9070400@imperial.ac.uk> Christian MacNevin wrote: > Hi > > Got a client running 33SXH1 in their network. Is SXF still the best bet > for stable mcast? Or are there necessary widgets in SXH nowadays? Routed or layer2? There are some enhancements in SXH (multicast router guard, IGMP join filtering) which are more relevant at layer2, but IIRC there's nothing especially compelling in SXH versus SXF (unless you need inter-AS MVPN) From gkg at gmx.de Wed Sep 24 05:41:58 2008 From: gkg at gmx.de (Garry) Date: Wed, 24 Sep 2008 11:41:58 +0200 Subject: [c-nsp] Converting OSPF backbone to iBGP In-Reply-To: <200809241619.34647.mtinka@globaltransit.net> References: <48D9F1AD.8010607@gmx.de> <200809241619.34647.mtinka@globaltransit.net> Message-ID: <48DA0B66.6000609@gmx.de> Mark Tinka wrote: >> I've been trying >> to find decent write-ups about certain things, but >> haven't been too successful as far as certain details go >> ... maybe somebody has some good pointers for me ... >> > > Philip Smith (Cisco) has some very good slides on this and > other best practice scaling techniques for ISP's that he > gives at various workshops and conferences. > I'll see what I can find ... >> Also, we have CPE devices that speak OSPF to our >> equipment in order to set up dual uplinks to customer >> sites ... >> > > As a friend of mine would say, "I recommend my competitors > do that..." > > But seriously, running an IGP with your customers isn't a > good idea (unless you're doing l3vpn's). I'd recommend > running eBGP with your customer's CPE, and keep the > OSPF "internal". > Problem is that those links use xDSL equipment like Telindus that don't necessarily speak BGP ... so OSPF is the only dynamic routing protocol I can use (well, unless you'd consider using RIP) ... guess I could still use some ip sla tracking mechanism to create "dynamic" static routes dependent on the availability of the remote router ... that way I'd have a route I can source in iBGP ... -gg From p.mayers at imperial.ac.uk Wed Sep 24 05:51:32 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Wed, 24 Sep 2008 10:51:32 +0100 Subject: [c-nsp] Virtualization in an enterprise In-Reply-To: <4C3B8C75B5899943AEC675BA6DD4627301347157@uspalex02.epri.com> References: <4C3B8C75B5899943AEC675BA6DD4627301347157@uspalex02.epri.com> Message-ID: <48DA0DA4.8010105@imperial.ac.uk> Higham, Josh wrote: > I am currently investigating using vrf-lite within our company to > support some research requests. I have some hesitation about > maintaining it, though, especially in a smaller enterprise environment > (4 network techs, ~10 branches). > > I am comfortable with the technology, but don't want to increase the > complexity of the network without significant advantages. More > importantly, I don't want to limit the applicant pool if we need to hire > someone down the road. > > Does anyone here have input on support and maintenance of this within an > enterprise environment? Yes. What specifically are you asking about? We ran a large-ish VRF-lite core for a year or more before finally converting to L3VPN. My experience was: * vrf lite is basically just >1 routing table; instead of having 1 p2p between routers, you have 1 per VRF using subints/vlans * running the multiple OSPF processes was tedious but easy to understand * vrf lite was supported on 3550/3750 * it's easy to understand - my personal opinion is that if someone can't grasp putting "vrf XXX" into some IOS commands, you shouldn't be hiring them anyway! * You do a *lot* of typing to get a VRF setup - e.g. on our 3550/6500 network you'd have to do: ip vrf NEW rd fake:value description blah int LoopbackN ip vrf forwarding NEW ip address router ospf N vrf NEW router-id network redistribute connected redistribute static # for each neighbouring router vlan XXXX name p2p-router-Y int VlanXXXX ip vrf forwarding NEW ip address blah ip ospf network point-to-point ...etc etc. When you have >10 VRFs and >20 routers, you start to have all kinds of irritating problems like how many subints/vlan tags you burnt just for p2p, how much address space you're burning for loopback and p2p interfaces, and so on Eventually we moved to L3VPN meaning a new VRF is: ip vrf NEW rd loop:N route-target as:nn both description blah router bgp 65000 address-family ipv4 vrf NEW redistribute connected redistribute static The initial cost of the L3VPN setup is higher (have to enable BGP with vpnv4, LDP, MPLS, get the MTUs right, possibly get MVPN setup if you need multicast) and it's obviously a system with more components but my feeling is that the layering is actually conceptually *easier* to understand. In short: I'm sure you'd have no problems with the vrf-lite solution and it served us well initially, but I would at least investigate the L3VPN solution > > We have sites connected by MPLS (BGP with the provider, but no other > MPLS or vrf type features) with redundancy through an IPSEC VPN over our > internet links. > > Thanks for any input that you can provide. > > Josh > _______________________________________________ > 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 Wed Sep 24 05:52:13 2008 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Wed, 24 Sep 2008 12:52:13 +0300 Subject: [c-nsp] multiple PPPOE sessions In-Reply-To: <0K7O00IVAJ0NUY20@smtp.cyber.net.pk> References: <0K7O00IVAJ0NUY20@smtp.cyber.net.pk> Message-ID: <48DA0DCD.70009@forthnet.gr> You might want to try the "test pppoe" ios command, although i don't know its exact usage (i haven't tried it myself). Also there are some devices from Spirent (http://www.spirent.com/analysis/technology.cfm?media=7&WS=325&SS=101&wt=2) that can do all sorts of performance testing, but they DO cost a lot. -- Tassos Farhan Ali Khan wrote on 24/9/2008 6:59 ??: > > > Dear All > > > > Is there any tester which can make multiple PPPOE sessions, need to test > radius max limit concurrent sessions, I was searching for a software base > solution for it since last night but I guess there is no software initiate > for this purpose if any one knows either software which can accomplished the > same task or any hard based solution please reply. > > > > > > > > Thanks > > Regards > > Farhan Ali Khan > > > > _______________________________________________ > 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 zivl at gilat.net Wed Sep 24 05:59:50 2008 From: zivl at gilat.net (Ziv Leyes) Date: Wed, 24 Sep 2008 12:59:50 +0300 Subject: [c-nsp] Performance Of www.cisco.com In-Reply-To: <200809241703.33039.mtinka@globaltransit.net> References: <200809241703.33039.mtinka@globaltransit.net> Message-ID: That's because they use "Huawei" gear in their networks... ;-) -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mark Tinka Sent: Wednesday, September 24, 2008 12:03 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Performance Of www.cisco.com Hi all. Not sure if it's just me but for the past several months, I've found the performance (response times) when browsing www.cisco.com is not all too great. I've tried using different paths to reach the site, and in some cases, there is short-lived improvement, and things go back to not_being_so_good. Is anyone else seeing this, or it's just me? The problem seems to extend to downloading files off of CCO as well. Cheers, Mark. ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ From p.mayers at imperial.ac.uk Wed Sep 24 06:01:00 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Wed, 24 Sep 2008 11:01:00 +0100 Subject: [c-nsp] Converting OSPF backbone to iBGP In-Reply-To: <48DA0B66.6000609@gmx.de> References: <48D9F1AD.8010607@gmx.de> <200809241619.34647.mtinka@globaltransit.net> <48DA0B66.6000609@gmx.de> Message-ID: <48DA0FDC.2020202@imperial.ac.uk> Garry wrote: > Mark Tinka wrote: >>> I've been trying >>> to find decent write-ups about certain things, but >>> haven't been too successful as far as certain details go >>> ... maybe somebody has some good pointers for me ... >>> >> Philip Smith (Cisco) has some very good slides on this and >> other best practice scaling techniques for ISP's that he >> gives at various workshops and conferences. >> > I'll see what I can find ... >>> Also, we have CPE devices that speak OSPF to our >>> equipment in order to set up dual uplinks to customer >>> sites ... >>> >> As a friend of mine would say, "I recommend my competitors >> do that..." >> >> But seriously, running an IGP with your customers isn't a >> good idea (unless you're doing l3vpn's). I'd recommend >> running eBGP with your customer's CPE, and keep the >> OSPF "internal". This is very good advice. >> > Problem is that those links use xDSL equipment like Telindus that don't > necessarily speak BGP ... so OSPF is the only dynamic routing protocol I > can use (well, unless you'd consider using RIP) ... guess I could still In all seriousness: in this case RIP has one distinct advantage - it's not your core IGP, and can't pollute your core IGP (this is one reason some people prefer IS-IS as their core IGP - it leaves OSPF "free" for customer links) You can import from OSPF to BGP, but it has some risks and complexities that are best avoided if at all possible. Much worse is distributing BGP into OSPF - don't do that. One option would be to put a dedicated router between the OSPF and BGP speaking bits of the network and separate it using eBGP and a private AS# i.e. R1 -- eBGP -- R2 -- OSPF -- junk That way R2 can say: router bgp 65001 redistribute ospf neighbour R1 remote-as 65000 ...and R1 can say: router bgp 65000 neighbour R2 remote-as 65001 neighbour R2 route-map OnlyDefault out neighbour R2 route-map VerySecure in From the sounds of it, you've got: core -- xDSL -- customer ...the other option is to make the customer do some of the work for dual attachment. We do this - we're increasingly requiring our attached customer to use eBGP if they want "real" resilience. In this case, some form of eBGP-multihop might be needed if the xDSL kit appears as a routed hop. I realise this has layer8 implications. > use some ip sla tracking mechanism to create "dynamic" static routes > dependent on the availability of the remote router ... that way I'd have > a route I can source in iBGP ... > > -gg > _______________________________________________ > 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.nyamukusa at africaonline.co.tz Wed Sep 24 06:23:58 2008 From: peter.nyamukusa at africaonline.co.tz (Peter Nyamukusa) Date: Wed, 24 Sep 2008 13:23:58 +0300 Subject: [c-nsp] Converting OSPF backbone to iBGP In-Reply-To: <200809241619.34647.mtinka@globaltransit.net> References: <48D9F1AD.8010607@gmx.de> <200809241619.34647.mtinka@globaltransit.net> Message-ID: <057e01c91e2f$a816c310$f8444930$@nyamukusa@africaonline.co.tz> -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mark Tinka Sent: Wednesday, September 24, 2008 11:19 AM To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Converting OSPF backbone to iBGP >On Wednesday 24 September 2008 15:52:13 Garry wrote: > >> after years of running very smoothly and without any problems (and not >> expecting any), we have decided to move our backbone from OSPF (single >> area) to iBGP as far as "best practice" recommendations go ... > >This is, indeed, a best practice as far as scaling the autonomous system goes. > >> I've been trying >> to find decent write-ups about certain things, but haven't been too >> successful as far as certain details go ... maybe somebody has some >> good pointers for me ... > >Philip Smith (Cisco) has some very good slides on this and other best practice scaling techniques for ISP's that he gives at various workshops and >conferences. > >You can Google to find a lot of these. > >> OK, so baseline recommendation is to only transport loopback/interface >> IPs in OSPF, do everything else via iBGP ... > >Correct. > >> Also, we have CPE devices that speak OSPF to our equipment in order to >> set up dual uplinks to customer sites ... > >As a friend of mine would say, "I recommend my competitors do that..." > >But seriously, running an IGP with your customers isn't a good idea (unless you're doing l3vpn's). I'd recommend running eBGP with your customer's CPE, >and keep the OSPF "internal". For me this was one of my considerations (although not the main) for migrating my IGP from OSPF to ISIS before deploying my MPLS network. We have some cases were some of the customers are connecting to the ISP using Linux & Windows as well as other Vendors routers and mainly this is because of cost and asking them to purchase a router which supports BGP or even upgrading the IOS or router hardware (memory) on the ones which have routers is an additional expense. So my plan is to Run IGP as my Core Backbone IGP and let the customers choose their PE to CE routing protocol Just my side of the coin considering the environment I am in Cheers, ___________________________________ Peter Nyamukusa - Technical Manager CCIP, JNCIS, MCSE, Linux+ From dhooper at emerge.net.au Wed Sep 24 06:30:23 2008 From: dhooper at emerge.net.au (Daniel Hooper) Date: Wed, 24 Sep 2008 18:30:23 +0800 Subject: [c-nsp] Performance Of www.cisco.com In-Reply-To: References: <200809241703.33039.mtinka@globaltransit.net> Message-ID: Cisco.com has been slow for me for some time now as well. -Dan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of S H A N Sent: Wednesday, 24 September 2008 5:12 PM To: mtinka at globaltransit.net Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Performance Of www.cisco.com hi, i guess its about time the cco should sit behind akamai or limelight... what do you think? On Wed, Sep 24, 2008 at 5:03 PM, Mark Tinka wrote: > Hi all. > > Not sure if it's just me but for the past several months, > I've found the performance (response times) when browsing > www.cisco.com is not all too great. > > I've tried using different paths to reach the site, and in > some cases, there is short-lived improvement, and things go > back to not_being_so_good. > > Is anyone else seeing this, or it's just me? > > The problem seems to extend to downloading files off of CCO > as well. > > Cheers, > > Mark. > > _______________________________________________ > 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/ > -- Best 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 jared at puck.nether.net Wed Sep 24 06:34:06 2008 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 24 Sep 2008 06:34:06 -0400 Subject: [c-nsp] Performance Of www.cisco.com In-Reply-To: References: <200809241703.33039.mtinka@globaltransit.net> Message-ID: <20080924103406.GA80399@puck.nether.net> I typically have no problem getting at least 2MB/sec from cisco when dowloading software. - Jared On Wed, Sep 24, 2008 at 06:30:23PM +0800, Daniel Hooper wrote: > Cisco.com has been slow for me for some time now as well. > > -Dan > > -----Original Message----- > From: cisco-nsp-bounces at puck.nether.net > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of S H A N > Sent: Wednesday, 24 September 2008 5:12 PM > To: mtinka at globaltransit.net > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] Performance Of www.cisco.com > > hi, i guess its about time the cco should sit behind akamai or > limelight... > what do you think? > > On Wed, Sep 24, 2008 at 5:03 PM, Mark Tinka > wrote: > > > Hi all. > > > > Not sure if it's just me but for the past several months, > > I've found the performance (response times) when browsing > > www.cisco.com is not all too great. > > > > I've tried using different paths to reach the site, and in > > some cases, there is short-lived improvement, and things go > > back to not_being_so_good. > > > > Is anyone else seeing this, or it's just me? > > > > The problem seems to extend to downloading files off of CCO > > as well. > > > > Cheers, > > > > Mark. > > > > _______________________________________________ > > 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/ > > > > > > -- > Best 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/ > _______________________________________________ > 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/ -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From j.varaillon at cosmoline.com Wed Sep 24 08:21:29 2008 From: j.varaillon at cosmoline.com (Varaillon Jean Christophe) Date: Wed, 24 Sep 2008 15:21:29 +0300 Subject: [c-nsp] Layer 2 security issue Message-ID: <006801c91e40$12d3a410$387aec30$%varaillon@cosmoline.com> Hi, We are using Cisco 3550, 3560 for access and 4500 for the core. All the ports of the users are port-secure enabled (switchport port-security mac-address sticky). We have enough cases where their ports get in err-disable status due to a wrong MAC address source. That mac address source is always the same for all cases that is: the mac address of the default gateway of the users (vlan interfaces on 4500). This means that the users are sending packets where the MAC address *source* is the one of their default router. An up to date antivirus scanning on those PCs did not lead anywhere. Has anybody seen this recently? Thank you. Christophe P Please consider your environmental responsibility before printing this e-mail _____ From jasongurtz at npumail.com Wed Sep 24 08:56:00 2008 From: jasongurtz at npumail.com (Jason Gurtz) Date: Wed, 24 Sep 2008 08:56:00 -0400 Subject: [c-nsp] Stability of PIXOS 7.0.8 interim builds Message-ID: I'm looking to mitigate the recursive DNS behind NAT port de-randomization issue and see that 7.0.8-1 and greater have the fix (we're on 7.0.8 GD now). Please comment on the stability of the 7.0 Interim train or 7.0.9 availability if you have experience. Thanks, ~JasonG -- From vijay.ramcharan at verizonbusiness.com Wed Sep 24 09:51:45 2008 From: vijay.ramcharan at verizonbusiness.com (Ramcharan, Vijay A) Date: Wed, 24 Sep 2008 13:51:45 +0000 Subject: [c-nsp] Configure Cisco Ace using XML In-Reply-To: <06C1E76E03FE9C4B85BFA9C75365D9DA0FC0137C@tiger.deltadentalwa.com> References: <06C1E76E03FE9C4B85BFA9C75365D9DA0FC0137C@tiger.deltadentalwa.com> Message-ID: <509A5E22DDC70B4DA85EA7C06C8FDA8F05E57D1C@ASHEVS011.mcilink.com> If you have not yet looked at the Admin guide, (http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_servi ces/ace_appliances/vA1_7_/configuration/administration/guide/xml.html), that would be a good place to start. There's at least one example in there. Supposedly the dtd is available off the ACE. The link is in the admin guide as https://ace_ip_address/cisco_ace.dtd or http://ace_ip_address/cisco_ace.dtd. As far as XML samples go, it doesn't appear that there are any out there for public consumption as yet. Vijay Ramcharan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Teller, Robert Sent: September 23, 2008 20:05 To: cisco-nsp at puck.nether.net Subject: [c-nsp] Configure Cisco Ace using XML I know it was possible to configure Cisco CSS devices by posting an xml file to them. After migrating from the CSS to the ACE module I will need to do the same thing but I am having problems finding example xml files. Anyone have anything that I could use to get started? Robert Teller Washington Dental Service Network Administrator (206) 528-2371 RTeller at DeltaDentalWa.com ######################################################### The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended for the sole use of the individual and entity to whom it is addressed. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. ######################################################### _______________________________________________ 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 Sep 24 10:20:15 2008 From: petelists at templin.org (Pete Templin) Date: Wed, 24 Sep 2008 09:20:15 -0500 Subject: [c-nsp] Converting OSPF backbone to iBGP In-Reply-To: <48D9F1AD.8010607@gmx.de> References: <48D9F1AD.8010607@gmx.de> Message-ID: <48DA4C9F.6060300@templin.org> Garry wrote: > after years of running very smoothly and without any problems (and not > expecting any), we have decided to move our backbone from OSPF (single > area) to iBGP as far as "best practice" recommendations go ... I've been > trying to find decent write-ups about certain things, but haven't been > too successful as far as certain details go ... maybe somebody has some > good pointers for me ... My biggest recommendation is to use the opportunity to add a symbolic community to EVERY route injected into BGP. We use this to streamline our filtering: customer routes, whether redistributed or learned via eBGP, are installed with a community such as 11457:30100 (redist) or 11457:20100 (eBGP). At our upstream edge, we only pass routes marked as 11457:2.... or 11457:3...., so we know that we're only passing routes learned from customers. Reason: we got bit when we had InterNAP and InterNAP as our provider(s). A customer was bringing their own space, so we opened our 'announce' filters to allow the prefix. We were learning the prefix over one of the InterNAP connections, and happily passing it to our other InterNAP connection, since it matched the prefix list. With community-based filtering, that route would have been tagged 11457:6.... and would have been denied for propagation. Our community structure is essentially (ASN):ABCDE, where ABCDE means: A: Type of route (1=internal, 2=customer, 3=redist/agg, 6=transit) BC: POP of origin (01 is first POP, 02, 03...) D: Tuning preference (0=provider, 1=default, 8=maintenance, 9=null) E: Georouting (0=distributed aggregate, 1=cold-potato, 2=hot-potato) We use BC&E to automatically tweak MED towards our transits. pt From cisco-nsp at tracker.fire-world.de Wed Sep 24 10:32:39 2008 From: cisco-nsp at tracker.fire-world.de (Sebastian Wiesinger) Date: Wed, 24 Sep 2008 16:32:39 +0200 Subject: [c-nsp] High CPU on Cisco 4500-E / SUP6-E, K5L3* processes Message-ID: <20080924143239.GA11831@danton.fire-world.de> Hello, we installed a few Cisco 4500-E with SUP6-E supervisors. Now one of them is showing a high CPU load, around 60-70%. I'm unable to find the reason for this. It's running 12.2(46)SG Enterprise Services. sh proc cpu shows that the "Cat4k Mgmt LoPri" process is taking most of the CPU time: 49 136483552 81322405 1678 65.22% 57.86% 58.39% 0 Cat4k Mgmt LoPri a sh platform health then shows the following processes (note the typo): K5L3FlcMan FwdEntry 2.00 14.16 15 10 100 500 16 14 9 332:06 K5L3Unciast IFE Revi 2.00 14.06 15 7 100 500 17 15 10 359:54 K5L3UnicastRpf IFE R 2.00 12.21 15 7 100 500 17 14 10 353:01 They *should* use up to 2.00%, but here they use almost 15% each. On another switch these processes use around 3.8% CPU time (still more then the target of 2%). Does anyone know the reason for this? A quick google shows no trace of these processes, and they are not explained in the Cisco documentation for the Catalyst 4500. Someone told me that K5 is "the FFE/VFE ASIC on the SUP6"? Regards, Sebastian -- 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 Wed Sep 24 10:37:09 2008 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 24 Sep 2008 10:37:09 -0400 Subject: [c-nsp] VRF RD/RT... your preferences? Message-ID: <48DA5095.5090106@utc.edu> The recent discussion of VRFs, RDs, RTs, VPNv4 labels, etc was interesting, and starting to sink in. I've been in early stages of a VRF-lite deployment for some time. Admittedly, from a VRF-lite perspective, a lot of the configuration is essentially cut-and-paste, and most of the values you can just make up as you go along as long as you're consistent. I'm guilty as charged :-) We have essentially one PE, multiple CEs, and no real MPLS going on anywhere; just VRF-lite and dot1q trunks/dedicated vlans to connect them together. However... one never knows what the future holds, and if the current economic crisis doesn't get us all, we might actually have multiple PEs and/or real MPLS one of these days. If that happens, I would prefer not to have to renumber/relabel/etc everything in a fit of "If I had only known better..." musings under my breath. With that said... what should REALLY be used for RDs / RTs? I'm currently using "ASN:vlan-id" for RTs, this identifies our ASN and the vlan ID used in the VRF-lite trunk mesh to carry the VRF into the CEs. I am using the same label for RD at the moment, but I noticed in an earlier discussion that the RD should be unique across the net (where in my case it's common). Should the RD reference the router IP? The global VRF loopback, or an interface address within the VRF? If I get a request to run an MPLS link out to a new research station halfway across the country, will this numbering scheme fit into an MPLS carrier's scheme? Jeff From rodunn at cisco.com Wed Sep 24 10:45:09 2008 From: rodunn at cisco.com (Rodney Dunn) Date: Wed, 24 Sep 2008 10:45:09 -0400 Subject: [c-nsp] How does the egress PE determine which VRF the VPN label is for? In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE03654910@vic-cr-ex1.staff.netspace.net.au> References: <56F211C5E3F24F47B103EA1B253822BE03654910@vic-cr-ex1.staff.netspace.net.au> Message-ID: <20080924144509.GI5475@rtp-cse-489.cisco.com> On Wed, Sep 24, 2008 at 11:17:27AM +1000, Andy Saykao wrote: > Argh cool. Thanks for that explaination Rodney. > > You wrote: "based on the local VPN label allocated for either all > connected or that specific route. A table is maintained to map them. " > > Is there a command to view this "table" to check the mappings or is this > something internal to the PE router? sh mpls for sh ip bgp for the global and VRF. Rodney > > Thanks. > > Andy > > > -----Original Message----- > From: Rodney Dunn [mailto:rodunn at cisco.com] > Sent: Wednesday, 24 September 2008 11:01 AM > To: Andy Saykao > Cc: cisco-nsp at puck.nether.net > Subject: Re: [c-nsp] How does the egress PE determine which VRF the VPN > label is for? > > On Wed, Sep 24, 2008 at 09:57:12AM +1000, Andy Saykao wrote: > > Given the scenario in which the packet has reached the egress PE, how > > does the router then determine which VRF the packet is destined for > > based on the remaining VPN label? I understand the concept of there > > being two labels, an IGP label and a VPN label. I'm just not sure how > > the egress PE is able to deduce that the VPN label is for a particular > > > VRF. > > > > Eg: > > > > PE1 -> P1 -> P2 -> PE2 > > > > *** First, a CEF lookup is performed on PE1 at the time the IP packet > > enters the ingress PE from an interface belonging to VRF TEST and > > shows that the following tags/labels {4771 44169} are pushed onto the > > IP packet. > > > > PE1#sh ip cef vrf TEST 172.16.66.2 > > 172.16.66.2/32, version 58, epoch 0, cached adjacency 203.10.x.x 0 > > packets, 0 bytes > > tag information set > > local tag: VPN-route-head > > fast tag rewrite with Gi0/0.11, 203.10.x.x, tags imposed: {4771 > > 44169} > > Flow: Origin AS 0, Peer AS 0, mask 32 > > via 210.15.x.x, 0 dependencies, recursive > > next hop 203.10.x.x, GigabitEthernet0/0.11 via 210.15.x.x/32 > > valid cached adjacency > > tag rewrite with Gi0/0.11, 203.10.x.x, tags imposed: {4771 44169} > > > > *** The label packet then uses the IGP label to determine the LSP and > > ends up at PE2 with just the VPN label left {44169}. > > > > *** PE2 checks it's mpls forwarding table and finds the following > entry: > > > > PE2#sh mpls forwarding-table label 44169 > > Local Outgoing Prefix Bytes tag Outgoing Next Hop > > tag tag or VC or Tunnel Id switched interface > > 44169 Aggregate 172.16.66.2/32[V] 5752 > > > > *** From the book "MPLS Fundamentals", it says - "Aggregate means that > > > the aggregating LSR needs to remove the label of the incoming packet > > and must do an IP lookup to determine the more specific prefix to use > > for forwarding this IP packet." > > > > What I don't get from that explaination is: > > > > - What is involved in doing an "IP lookup" as the next step? > > It means the aggregate just tells the PE that the ip address is > connected and in a particular VRF. There are different ways to implement > it. per prefix lables, aggregats for only connected in a vrf, etc. > > > > - How does the router figure out that the prefix 172.16.66.2 is a > > route belonging to VRF TEST? > > based on the local VPN label allocated for either all connected or that > specific route. A table is maintained to map them. That's why you can do > 'sh ip bgp vpnv4 vrf blah and it show the vpnv4 label. > > > - Is it something to do with MP-BGP because when I do a BGP lookup on > > the prefix, I see the word "aggregate" followed by the VRF name. How > > does this information then tie in with what's contained in the mpls > > forwarding table to deduce that it's VRF TEST we want. > > Different protocols can insert labels in the lfib. ie: ldp, bgp, etc. > BGP can allocate a lable for VPNV4 prefixes and then advertise that to > remote PE's to tell them what label to send with. Then ldp sends labels > hop by hop to get to the PE's loopback (outer label as we call it). > > > > > PE2#sh ip bgp vpnv4 rd 4854:100660 172.16.66.2 BGP routing table entry > > > for 4854:100660:172.16.66.2/32, version 811 > > Paths: (1 available, best #1, table TEST) > > Advertised to peer-groups: > > NS-MPLS-VPN > > Local > > 0.0.0.0 from 0.0.0.0 (203.17.x.x) > > Origin incomplete, metric 0, localpref 100, weight 32768, valid, > > > sourced, best > > Extended Community: RT:4854:100660, > > mpls labels in/out 44169/aggregate(TEST) > > > > Everything is working fine - I'm just trying to understand the little > > intricate details of MPLS VPN's that make them work, so I can picture > > it in my mind. > > > > 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 sethm at rollernet.us Wed Sep 24 11:20:59 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 24 Sep 2008 08:20:59 -0700 Subject: [c-nsp] Performance Of www.cisco.com In-Reply-To: <200809241703.33039.mtinka@globaltransit.net> References: <200809241703.33039.mtinka@globaltransit.net> Message-ID: <48DA5ADB.5090107@rollernet.us> Mark Tinka wrote: > Hi all. > > Not sure if it's just me but for the past several months, > I've found the performance (response times) when browsing > www.cisco.com is not all too great. > > I've tried using different paths to reach the site, and in > some cases, there is short-lived improvement, and things go > back to not_being_so_good. > > Is anyone else seeing this, or it's just me? It's been slow for me since this current iteration of the design came out. I just attributed it to the tradeoff between flashy and functional. I was stuck on a dialup modem (21k) once during an emergency after my 877 at home failed and trying to access my TAC case online was horribly painful to the point of causing extreme rage. Download speeds are fine, though. ~Seth From mcgrath at fas.harvard.edu Wed Sep 24 11:43:16 2008 From: mcgrath at fas.harvard.edu (Scott McGrath) Date: Wed, 24 Sep 2008 11:43:16 -0400 Subject: [c-nsp] Performance Of www.cisco.com In-Reply-To: References: <200809241703.33039.mtinka@globaltransit.net> Message-ID: <48DA6014.3040602@fas.harvard.edu> How about bringing back the old Mustard and Olive CCO the one which actually worked... S H A N wrote: > hi, i guess its about time the cco should sit behind akamai or limelight... > what do you think? > > On Wed, Sep 24, 2008 at 5:03 PM, Mark Tinka wrote: > > >> Hi all. >> >> Not sure if it's just me but for the past several months, >> I've found the performance (response times) when browsing >> www.cisco.com is not all too great. >> >> I've tried using different paths to reach the site, and in >> some cases, there is short-lived improvement, and things go >> back to not_being_so_good. >> >> Is anyone else seeing this, or it's just me? >> >> The problem seems to extend to downloading files off of CCO >> as well. >> >> Cheers, >> >> Mark. >> >> _______________________________________________ >> 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 Sep 24 11:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Firewall Application Inspection Control Vulnerability Message-ID: <200809241750.iosfw@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Firewall Application Inspection Control Vulnerability Advisory ID: cisco-sa-20080924-iosfw http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco IOS software configured for IOS firewall Application Inspection Control (AIC) with a HTTP configured application-specific policy are vulnerable to a Denial of Service when processing a specific malformed HTTP transit packet. Successful exploitation of the vulnerability may result in a reload of the affected device. Cisco has released free software updates that address this vulnerability. A mitigation for this vulnerability is available. See the "Workarounds" section for details. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= The HTTP AIC feature was introduced in Cisco IOS Software Release 12.4(9)T. The software table in this advisory identifies the affected releases. Vulnerable Products +------------------ Devices that are running a vulnerable version of Cisco IOS software and configured for Cisco IOS firewall AIC for HTTP are affected. To determine the software running on a Cisco IOS product, log in to the device and issue the show version command-line interface (CLI) command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the Cisco IOS release name. Other Cisco devices will not have the show version command, or will give different output. The following example shows output from a device running Cisco IOS image 12.4(15)T2: router#show version Cisco IOS Software, 1841 Software (C1841-ADVSECURITYK9-M), Version 12.4(15)T2, RELEASE SOFTWARE (fc7) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 17-Jan-08 23:12 by prod_rel_team !--- Output truncated. Additional information on the Cisco IOS release naming conventions can be found on the document entitled "White Paper: Cisco IOS Reference Guide", which is available at http://www.cisco.com/warp/public/620/1.html The device is vulnerable if the configuration has a Layer 7 class map and Layer 7 policy map for HTTP deep packet inspection (DPI), and these policies are applied to any firewall zone. To determine whether the device is running a vulnerable configuration of Cisco IOS firewall AIC for HTTP, log in to the device and issue the CLI command show policy-map type inspect zone-pair | section packet inspection. If the output contains Policy: http layer7-policymap name , the device is vulnerable. The following example shows the response from a vulnerable device: Router#show policy-map type inspect zone-pair | section packet inspection Deep packet inspection Policy: http layer7-policymap 1 packets, 28 bytes Router# Products Confirmed Not Vulnerable +-------------------------------- No other Cisco products are currently known to be affected by this vulnerability. IOS releases before 12.4(9)T are not affected by this issue. Products confirmed not vulnerable include: * Cisco PIX * Cisco ASA * Cisco Firewall Services Module (FWSM) * The Virtual Firewall (VFW) application on the multiservice blade (MSB) on the Cisco XR 12000 Series Router Details ======= Firewalls are networking devices that control access to an organization's network assets. Firewalls are often positioned at the entrance points into networks. Cisco IOS software provides a set of security features that enable you to configure a simple or elaborate firewall policy, according to your particular requirements. HTTP uses port 80 by default to transport Internet web services, which are commonly used on the network and rarely challenged with regard to their legitimacy and conformance to standards. Because port 80 traffic is typically allowed through the network without being challenged, many application developers are leveraging HTTP traffic as an alternative transport protocol that will allow their application's traffic to travel through or even bypass the firewall. When the Cisco IOS Firewall is configured with HTTP AIC, it performs packet inspection to detect HTTP connections that are not authorized in the scope of the security policy configuration. It also detects users who are tunneling applications through port 80. If the packet is not in compliance with the HTTP protocol, it will be dropped, the connection will be reset, and a syslog message will be generated, as appropriate. Cisco IOS Software that is configured for IOS firewall AIC with an HTTP application-specific policy is vulnerable to a denial of service condition when it processes a specific malformed HTTP transit packet. Successful exploitation of the vulnerability may result in a reload of the affected device. HTTP runs over TCP. For this vulnerability to be exploited, a full three-way handshake between client and server is required before any malicious traffic would be processed to result in a device reload. Additional information regarding Cisco IOS Firewall AIC with HTTP application-specific policy maps is available at http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124newft/124t/124t6/htzonebp.htm#wp1407906 This vulnerability is documented in Cisco bug ID CSCsh12480 and Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-3812 has been assigned to this vulnerability. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerability 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 CSCsh12480 - IOSFW with HTTP AIC may reload on processing crafted HTTP packet CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability may result in a reload of the affected device. Repeated exploitation attempts may result in a sustained denial of service attack. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major Release | Availability of Repaired Releases | |-----------------+-------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.2 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |-----------------+-----------------------------------+-------------| | 12.4 | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4JA | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4JK | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4JL | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4JMA | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4JMB | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4JMC | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4JX | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4MD | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4MR | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4SW | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | | Releases prior to 12.4(9)T are | | | | not vulnerable. First fixed in: | | | | | | | 12.4T | 12.4(9)T7 | 12.4(15)T7 | | | | | | | 12.4(11)T4 | | | | | | | | 12.4(15)T | | |-----------------+-----------------------------------+-------------| | 12.4XA | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XB | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XC | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XD | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XE | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |-----------------+-----------------------------------+-------------| | 12.4XF | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XG | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XJ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |-----------------+-----------------------------------+-------------| | 12.4XK | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |-----------------+-----------------------------------+-------------| | 12.4XL | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XM | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XN | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XP | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XQ | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XT | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XV | Vulnerable; contact TAC | | |-----------------+-----------------------------------+-------------| | 12.4XW | 12.4(11)XW1 | 12.4(11)XW9 | |-----------------+-----------------------------------+-------------| | 12.4XY | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XZ | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== There are no known workarounds for this vulnerability. The only known action to help counter this vulnerability is to disable AIC HTTP deep packet inspection in the affected device's configuration. Disabling deep packet HTTP inspection will allow the rest of the firewall features to continue to function until a software upgrade can be implemented. All other firewall features will continue to perform normally. Disabling AIC HTTP Deep Packet Inspection +---------------------------------------- To disable AIC HTTP Deep Packet Inspection, remove the linkage between policy-map type inspect layer4-policymap and policy-map type inspect http layer7-policymap. This example shows an existing configuration, followed by how to remove AIC HTTP Deep Packet Inspection: !--- Existing Configuration ! parameter-map type inspect global ! class-map type inspect http match-any layer7-classmap class-map type inspect match-any layer4-classmap match protocol http ! policy-map type inspect http layer7-policymap class type inspect http layer7-classmap allow class class-default policy-map type inspect layer4-policymap class type inspect layer4-classmap inspect global service-policy http layer7-policymap class class-default ! zone security inside description ** Inside Network ** zone security outside description ** Outside Network ** zone-pair security in2out source inside destination outside description ** Zone Pair - inside to outside ** service-policy type inspect layer4-policymap Remove the service-policy from the zone-pair in question: Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#zone-pair security in2out source inside destination outside Router(config-sec-zone-pair)#no service-policy type inspect layer4-policymap Router(config-sec-zone-pair)#exit Remove the linkage between policy-map type inspect layer4-policymap and policy-map type inspect http layer7-policymap: Router(config)#policy-map type inspect layer4-policymap Router(config-pmap)#class type inspect layer4-classmap Router(config-pmap-c)#no service-policy http layer7-policymap Router(config-pmap-c)#exit Router(config-pmap)#exit Reapply the service-policy to the zone-pair in question: Router(config)#zone-pair security in2out source inside destination outside Router(config-sec-zone-pair)#service-policy type inspect layer4-policymap Router(config-sec-zone-pair)#exit Although not required, for completeness of the configuration the policy-map type inspect http layer7-policymap and class-map type inspect http match-any layer7-classmap are recommended to be removed. Router(config)#no policy-map type inspect http layer7-policymap Router(config)#no class-map type inspect http match-any layer7-classmap Router(config)#exit Router# Obtaining Fixed Software ======================== Cisco has released free software updates that address this vulnerability. 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/products/prod_warranties_item09186a008088e31f.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/warp/public/687/Directory/DirTAC.shtml 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. This vulnerability was found by Cisco internal testing. 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-20080924-iosfw.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 | 2008-September-24 | 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----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLbkACgkQ86n/Gc8U/uBSqwCgi7dmsFhp1u9fxWgLqVpMPtV+ fuIAn3f11gNGT/LITk11YI6fjv7W1Q20 =0tmt -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 11:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: [c-nsp] Cisco Security Advisory: Cisco IOS IPS Denial of Service Vulnerability Message-ID: <200809241750.iosips@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS IPS Denial of Service Vulnerability Advisory ID: cisco-sa-20080924-iosips http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= The Cisco IOS Intrusion Prevention System (IPS) feature contains a vulnerability in the processing of certain IPS signatures that use the SERVICE.DNS engine. This vulnerability may cause a router to crash or hang, resulting in a denial of service condition. Cisco has released free software updates that address this vulnerability. There is a workaround for this vulnerability. Note: This vulnerability is not related in any way to CVE-2008-1447 - Cache poisoning attacks. Cisco Systems has published a Cisco Security Advisory for that vulnerability, which can be found at http://www.cisco.com/en/US/products/products_security_advisory09186a00809c2168.shtml This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= Vulnerable Products +------------------ Any Cisco IOS device configured with the Cisco IOS IPS feature is vulnerable, regardless if it is configured to use the built-in signatures or an external signature file. Devices using either version 4 or version 5 signatures are affected by this vulnerability. The Cisco IOS IPS feature is not enabled by default. The command show ip ips interfaces can be used to determine if the Cisco IOS IPS feature has been configured and applied to any interface on the device, as in the following example: Router#show ip ips interfaces Interface Configuration Interface FastEthernet0/0 Inbound IPS rule is ios-ips-incoming Outgoing IPS rule is not set Interface FastEthernet0/1 Inbound IPS rule is not set Outgoing IPS rule is ios-ips-outgoing Router# The output of the show ip ips interfaces command when the Cisco IOS IPS feature has not been configured is dependent on which Cisco IOS release is installed and running on the device. It may be similar to the following example: Router#show ip ips interfaces Router# or it may be similar to the following: Router#show ip ips interfaces Interface Configuration IPS is not configured on any interface Router# Any version of Cisco IOS prior to the versions which are listed in the Software Versions and Fixes section below is vulnerable. To determine the version of the Cisco IOS software running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS". On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the show version command or will give different output. The following example identifies a Cisco product running Cisco IOS Software release 12.3(26) with an installed image name of C2500-IS-L: Router#show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih Router# The next example shows a product running Cisco IOS Software release 12.4(20)T with an image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team Router# Additional information on the Cisco IOS release naming conventions can be found on the document entitled "White Paper: Cisco IOS Reference Guide", which is available at http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- The following Cisco products are confirmed not vulnerable: * Cisco IOS devices running the Intrusion Detection System feature * Cisco ASA Security Appliances running the Intrusion Detection System feature * Cisco PIX 500 Series Security Appliances running the Intrusion Detection System feature * Cisco IPS 4200 Sensors * Cisco AIP-SSM for ASA 5500 Series Adaptive Security Appliances * Cisco Catalyst 6500 Series Intrusion detection System (IDSM-2) Services Module * Cisco IPS Advanced Integration Module for Integrated Services Routers No other Cisco products are currently known to be affected by this vulnerability. Details ======= Cisco IOS Intrusion Prevention System (IPS) is an inline, deep-packet inspection feature that effectively mitigates a wide range of network attacks. A component of the Cisco IOS Integrated Threat Control framework and complemented by Cisco IOS Flexible Packet Matching feature, Cisco IOS IPS provides your network with the intelligence to accurately identify, classify, and stop or block malicious traffic in real time. Additional information on the Cisco IOS IPS feature can be found at http://www.cisco.com/en/US/docs/ios/12_3t/12_3t8/feature/guide/gt_fwids.html Previous to the introduction of the Cisco IOS IPS feature, Cisco IOS provided a similar feature, the Cisco IOS Intrusion Detection System (IDS). The Cisco IOS IDS feature is not affected by this vulnerability. Additional information on the Cisco IOS IDS feature can be found at http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ios_ids.html Certain network traffic can trigger IPS signatures on the SERVICE.DNS signature engine which may cause the Cisco IOS device to crash or hang. This may cause a denial of service that results in disruption of network traffic. This vulnerability is documented in Cisco Bug ID CSCsq13348. This vulnerability has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-2739. 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 CSCsq13348 - Watchdog timeout with IPS configured 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 this vulnerability may cause a Cisco IOS device configured with the Cisco IOS IPS feature to crash or hang, resulting in a denial of service condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.2 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |------------+--------------------------------------+---------------| | 12.3 | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3B | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3BC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3BW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3EU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JEA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JEB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JEC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JX | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.4(15)T7 | | 12.3T | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+--------------------------------------+---------------| | 12.3TPC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3VA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XE | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XI | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XK | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.4(15)T7 | | 12.3XL | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+--------------------------------------+---------------| | | | 12.4(15)T7 | | 12.3XQ | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+--------------------------------------+---------------| | | | 12.4(15)T7 | | 12.3XR | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+--------------------------------------+---------------| | | | 12.4(15)T7 | | 12.3XS | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+--------------------------------------+---------------| | 12.3XU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XW | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.4(15)T7 | | 12.3XX | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+--------------------------------------+---------------| | 12.3XY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.4(15)T7 | | 12.3YA | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+--------------------------------------+---------------| | 12.3YD | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.3YF | Not Vulnerable | | |------------+--------------------------------------+---------------| | | Releases prior to 12.3(8)YG7 are | | | 12.3YG | vulnerable, release 12.3(8)YG7 and | 12.4(15)T7 | | | later are not vulnerable; first | | | | fixed in 12.4T | | |------------+--------------------------------------+---------------| | 12.3YH | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.3YI | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.3YJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YK | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | | | 12.3(14)YM13; | | 12.3YM | 12.3(14)YM13; Available on 30-SEP-08 | Available on | | | | 30-SEP-08 | |------------+--------------------------------------+---------------| | 12.3YQ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YS | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.3YT | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.3YU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YZ | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.3ZA | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |------------+--------------------------------------+---------------| | | 12.4(18b) | | | | | | | 12.4 | 12.4(19a) | 12.4(18c) | | | | | | | 12.4(21) | | |------------+--------------------------------------+---------------| | 12.4JA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4MD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4MR | 12.4(19)MR | 12.4(19)MR | |------------+--------------------------------------+---------------| | 12.4SW | Not Vulnerable | | |------------+--------------------------------------+---------------| | | 12.4(15)T6 | | | 12.4T | | 12.4(15)T7 | | | 12.4(20)T | | |------------+--------------------------------------+---------------| | 12.4XA | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.4XB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XC | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | | | 12.4(4)XD11; | | 12.4XD | 12.4(4)XD11; Available on 26-SEP-08 | Available on | | | | 26-SEP-08 | |------------+--------------------------------------+---------------| | 12.4XE | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.4XF | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.4XG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XJ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.4XK | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.4XL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XM | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XN | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XP | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XQ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XT | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.4XV | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.4XW | 12.4(11)XW9 | 12.4(11)XW9 | |------------+--------------------------------------+---------------| | 12.4XY | 12.4(15)XY4 | 12.4(15)XY4 | |------------+--------------------------------------+---------------| | 12.4XZ | 12.4(15)XZ2 | 12.4(15)XZ2 | |------------+--------------------------------------+---------------| | 12.4YA | 12.4(20)YA1 | 12.4(20)YA1 | +-------------------------------------------------------------------+ Workarounds =========== The workaround consists of adding an Access Control List (ACL) to every Cisco IOS IPS policy configured on the device so that traffic destined to ports 53/udp or 53/tcp is not inspected by the Cisco IOS IPS feature. The following ACL would need to be added to the device configuration: ! deny inspection of traffic with a destination port of 53/udp access-list 177 deny udp any any eq 53 ! deny inspection of traffic with a destination port of 53/tcp access-list 177 deny tcp any any eq 53 ! allow all other traffic to be inspected access-list 177 permit ip any any Every instance of a Cisco IOS IPS policy on the device would then need to be modified in order to reference the previous ACL. In order to determine which Cisco IOS IPS policies are configured on the device, execute the command show running-config | include ip ips name as in the following example: Router#show running-config | include ip ips name ip ips name ios-ips-incoming ip ips name ios-ips-outgoing Router# In the previous example, two Cisco IOS IPS policies are configured on the device. The following example shows the addition of an ACL to each one of the Cisco IOS IPS policies previously identified: Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#ip ips name ios-ips-incoming list 177 Router(config)#ip ips name ios-ips-outgoing list 177 Router(config)#end Router# As a verification step, the command show ip ips interfaces can be executed again to verify the ACL has been properly attached to each one of the Cisco IOS IPS policies: Router#show ip ips interfaces Interface Configuration Interface FastEthernet0/0 Inbound IPS rule is ios-ips-incoming acl list 177 Outgoing IPS rule is not set Interface FastEthernet0/1 Inbound IPS rule is not set Outgoing IPS rule is ios-ips-outgoing acl list 177 Router# Note: Disabling or deleting individual or all signatures using the SERVICE.DNS engine of the Cisco IOS IPS feature is not a recommended workaround. The previous workaround is the only Cisco-recommended workaround for this vulnerability. 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/products/prod_warranties_item09186a008088e31f.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/warp/public/687/Directory/DirTAC.shtml 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. This vulnerability was reported to Cisco by a customer. 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-20080924-iosips.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 | 2008-September-24 | 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----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLb4ACgkQ86n/Gc8U/uCOcQCfVtBrGIC3MJQr9jaPkMlt3ikc XrEAn1XOyW6nTAO/lsY5edWYzRoTuLDe =HgRp -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 11:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: [c-nsp] Cisco Security Advisory: Cisco 10000, uBR10012, uBR7200 Series Devices IPC Vulnerability Message-ID: <200809241750.ipc@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco 10000, uBR10012, uBR7200 Series Devices IPC Vulnerability Advisory ID: cisco-sa-20080924-ipc http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco 10000, uBR10012 and uBR7200 series devices use a User Datagram Protocol (UDP) based Inter-Process Communication (IPC) channel that is externally reachable. An attacker could exploit this vulnerability to cause a denial of service (DoS) condition on affected devices. No other platforms are affected. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS^ software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= Cisco 10000, uBR10012 and uBR7200 series devices that are running an affected version of Cisco IOS are affected. Vulnerable Products +------------------ Devices that are running Cisco IOS can be identified by using the show version command. The following example shows an output taken from a Cisco 10000 series device running Cisco IOS software release 12.2(31)SB10e: c10k#show version | include IOS Cisco IOS Software, 10000 Software (C10K3-P11-M), Version 12.2(31)SB10e, RELEASE SOFTWARE (fc1) c10k# The following example shows an output taken from a Cisco uBR10012 series device running Cisco IOS software release 12.3(17b)BC7: ubr10k#show version | include IOS IOS (tm) 10000 Software (UBR10K-K8P6U2-M), Version 12.3(17b)BC7, RELEASE SOFTWARE (fc1) ubr10k# The following example shows an output taken from a Cisco uBR7200 series device running Cisco IOS software release 12.3(21a)BC2: ubr7200#show version | include IOS IOS (tm) 7200 Software (UBR7200-IK9SU2-M), Version 12.3(21a)BC2, RELEASE SOFTWARE (fc1) ubr7200# Please refer to the document entitled "White Paper: Cisco IOS Reference Guide" for additional information on the Cisco IOS release naming conventions. This document is available at the following link: http://www.cisco.com/warp/public/620/1.html Any version of Cisco IOS prior to the fixed versions listed in the Software Versions and Fixes section below is vulnerable. Products Confirmed Not Vulnerable +-------------------------------- Cisco uBR7100 series devices are not affected. No other Cisco products are currently known to be affected by this vulnerability. Details ======= Cisco 10000, uBR10012 and uBR7200 series devices use a UDP-based IPC channel. This channel uses addresses from the 127.0.0.0/8 range and UDP port 1975. Cisco 10000, uBR10012 and uBR7200 series devices that are running an affected version of Cisco IOS will process IPC messages that are sent to UDP port 1975 from outside of the device. This behavior may be exploited by an attacker to cause a reload of the device, linecards, or both, resulting in a DoS condition. Filtering unauthorized traffic destined to 127.0.0.0/8 or UDP port 1975 will mitigate this vulnerability. This vulnerability is documented in the Cisco Bug IDs CSCsg15342 and CSCsh29217 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-3805. 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 CSCsg15342 - IPC processing needs to be more robust CVSS Base Score - 8.5 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - Partial Availability Impact - Complete CVSS Temporal Score - 7 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsh29217 - IPC processing needs to be more robust CVSS Base Score - 8.5 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - Partial Availability Impact - Complete CVSS Temporal Score - 7 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability may result in a reload of the device, linecards, or both, resulting in a DoS condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |-------------+-----------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------+-------------------------------------+---------------| | 12.0 | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0DA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0DB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0DC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | | Releases prior to 12.0(32)S are | 12.0(32)S11 | | 12.0S | vulnerable, release 12.0(32)S and | | | | later are not vulnerable; | 12.0(33)S1 | |-------------+-------------------------------------+---------------| | 12.0SC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0SL | Vulnerable, migrate to 12.0S, 12.1 | | |-------------+-------------------------------------+---------------| | 12.0SP | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0ST | Vulnerable, migrate to 12.0S, 12.1 | | |-------------+-------------------------------------+---------------| | 12.0SX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0SY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | | | 12.0(32)S11 | | 12.0SZ | 12.0(30)SZ4 | | | | | 12.0(33)S1 | |-------------+-------------------------------------+---------------| | 12.0T | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0W | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0WC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0WT | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XH | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XI | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XJ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XM | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XN | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XQ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XR | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XS | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XT | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XV | Not Vulnerable | | |-------------+-------------------------------------+---------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |-------------+-------------------------------------+---------------| | 12.2 | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2B | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2BC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2BW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2BX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2BY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2BZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2CX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2CY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2CZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2DA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2DD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2DX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2EW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2EWA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2EX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2EY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2EZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2FX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2FY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2FZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2IRB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2IXA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2IXB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2IXC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2IXD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2IXE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2IXF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2IXG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2JA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2JK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2MB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2MC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2S | Not Vulnerable | | |-------------+-------------------------------------+---------------| | | 12.2(31)SB13 | 12.2(33)SB2; | | 12.2SB | | Available on | | | 12.2(33)SB1 | 26-SEP-08 | |-------------+-------------------------------------+---------------| | 12.2SBC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SCA | 12.2(33)SCA1 | 12.2(33)SCA1 | |-------------+-------------------------------------+---------------| | 12.2SE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SEA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SEB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SEC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SED | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SEE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SEF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SEG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SGA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SM | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SO | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SRA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SRB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SRC | 12.2(33)SRC2 | 12.2(33)SRC2 | |-------------+-------------------------------------+---------------| | 12.2SU | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SV | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SVA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SVC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SVD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SXA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SXB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SXD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SXE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SXF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SXH | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2T | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2TPC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XH | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XI | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XJ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XM | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XN | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XNA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XNB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XO | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XQ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XR | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XS | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XT | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XU | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XV | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YH | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YJ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YM | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YN | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YO | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YP | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YQ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YR | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YS | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YT | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YU | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YV | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZH | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZJ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZP | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZU | Not Vulnerable | | |-------------+-------------------------------------+---------------| | | | 12.2(33)SB2; | | 12.2ZX | Vulnerable; first fixed in 12.2SB | Available on | | | | 26-SEP-08 | |-------------+-------------------------------------+---------------| | 12.2ZY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZYA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |-------------+-------------------------------------+---------------| | 12.3 | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3B | Not Vulnerable | | |-------------+-------------------------------------+---------------| | | 12.3(17b)BC6 | | | | | | | 12.3BC | 12.3(21a)BC1 | 12.3(23)BC4 | | | | | | | 12.3(23)BC | | |-------------+-------------------------------------+---------------| | 12.3BW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3EU | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3JA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3JEA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3JEB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3JEC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3JK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3JL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3JX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | | Note: Releases prior to 12.3(14)T3 | 12.4(15)T7 | | 12.3T | are vulnerable, release 12.3(14)T3 | | | | and later are not vulnerable; | 12.4(18c) | |-------------+-------------------------------------+---------------| | 12.3TPC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3VA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | | | 12.2(33)SB2; | | 12.3XI | 12.3(7)XI10a | Available on | | | | 26-SEP-08 | |-------------+-------------------------------------+---------------| | 12.3XJ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XQ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XR | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XS | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XU | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YH | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YI | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YJ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YM | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YQ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YS | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YT | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YU | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3ZA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |-------------+-------------------------------------+---------------| | | Note: Releases prior to 12.4(3) are | | | 12.4 | vulnerable, release 12.4(3) and | 12.4(18c) | | | later are not vulnerable; | | |-------------+-------------------------------------+---------------| | 12.4JA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4JK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4JL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4JMA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4JMB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4JMC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4JX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4MD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4MR | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4SW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4T | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XJ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XM | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XN | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XP | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XQ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XR | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XT | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XV | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== Workarounds consist of filtering packets that are sent to 127.0.0.0/8 range and UDP packets that are sent to port 1975. Using Interface Access Control Lists +----------------------------------- Access lists that filter UDP packets destined to port 1975 can be used to mitigate this vulnerability. UDP port 1975 is a registered port number that can be used by certain applications. However, filtering all packets that are destined to UDP port 1975 may cause some applications to malfunction. Therefore, access lists need to explicitly deny UDP 1975 packets that are sent to any router interface IP addresses and permit transit traffic. Such access lists need to be applied on all interfaces to be effective. Since the IPC channel uses addresses from the 127.0.0.0/8 range, it is also necessary to filter packets that are sourced from or destined to this range. An example is given below: access-list 100 deny udp any host eq 1975 access-list 100 deny udp any host eq 1975 access-list 100 deny udp any host eq 1975 access-list 100 deny ip 127.0.0.0 0.255.255.255 any access-list 100 deny ip any 127.0.0.0 0.255.255.255 access-list 100 permit ip any any interface Serial 0/0 ip access-group 100 in Using Control Plane Policing +--------------------------- Control Plane Policing (CoPP) can be used to block untrusted UDP port 1975 access to the affected device. Cisco IOS software releases 12.2BC and 12.2SCA support the CoPP feature. CoPP may be configured on a device to protect the management and control planes to minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. The following example can be adapted to your network. Note: CoPP is not supported on uBR10012 series devices. !-- Permit all UDP/1975 traffic so that it !-- will be policed and dropped by the CoPP feature ! access-list 111 permit udp any any eq 1975 access-list 111 permit ip any 127.0.0.0 0.255.255.255 access-list 111 permit ip 127.0.0.0 0.255.255.255 any ! !-- Permit (Police or Drop)/Deny (Allow) all other Layer 3 and !-- Layer 4 traffic in accordance with existing security policies !-- and configurations for traffic that is authorized to be sent !-- to infrastructure devices ! !-- Create a Class-Map for traffic to be policed by the CoPP !-- feature ! class-map match-all drop-IPC-class match access-group 111 ! !-- Create a Policy-Map that will be applied to the Control-Plane !-- of the device ! policy-map drop-IPC-traffic class drop-IPC-class drop ! !-- Apply the Policy-Map to the Control-Plane of the device ! control-plane service-policy input drop-IPC-traffic ! In the above CoPP example, the access control list entries (ACEs) which match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Please note that in the Cisco IOS 12.2S and 12.0S trains the policy-map syntax is different: ! policy-map drop-IPC-traffic class drop-IPC-class police 32000 1500 1500 conform-action drop exceed-action drop ! Additional information on the configuration and use of the CoPP feature can be found at http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html, http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html and http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html Using Infrastructure ACLs at Network Boundary +-------------------------------------------- Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. iACLs are a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The iACL example shown below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range: !-- Note: IPC packets sent to UDP destination port 1975 must not !-- be permitted from any trusted source as this traffic !-- should only be sent and received internally by the !-- affected device using an IP address allocated from the !-- 127.0.0.0/8 prefix. !-- !-- IPC that traffic that is internally generated and sent !-- and/or received by the affected device is not subjected !-- to packet filtering by the applied iACL policy. ! !-- Deny IPC (UDP port 1975) packets from all sources destined to !-- all IP addresses configured on the affected device. ! access-list 150 deny udp any host INTERFACE_ADDRESS#1 eq 1975 access-list 150 deny udp any host INTERFACE_ADDRESS#2 eq 1975 access-list 150 deny udp any host INTERFACE_ADDRESS#N eq 1975 ! !-- Deny all IP packets with a source or destination IP address !-- from the 127.0.0.0/8 prefix. ! access-list 150 deny ip 127.0.0.0 0.255.255.255 any access-list 150 deny ip any 127.0.0.0 0.255.255.255 ! !-- Permit/deny all other Layer 3 and Layer 4 traffic in accordance !-- with existing security policies and configurations. ! !-- Permit all other traffic to transit the device. ! access-list 150 permit ip any any ! !-- Apply iACL to interfaces in the ingress direction. ! interface GigabitEthernet0/0 ip access-group 150 in ! Note: iACLs that filter UDP packets destined to port 1975 can be used to mitigate this vulnerability. However, UDP port 1975 is a registered port number that can be used by certain applications. Filtering all packets that are destined to UDP port 1975 may cause some applications to malfunction. Therefore, the iACL policy needs to explicitly deny UDP packets using a destination port of 1975 that are sent to any router interface IP addresses for affected devices, then permit and/or deny all other Layer 3 and Layer 4 traffic in accordance with existing security policies and configurations, and then permit all other traffic to transit the device. iACLs must be applied on all interfaces to be used effectively. Since the IPC channel uses addresses from the 127.0.0.0/8 range, it is also necessary to filter packets that are sourced from or destined to this range as provided in the preceding example. The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained here: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml Additional Mitigation Techniques +------------------------------- Additional mitigation techniques 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-20080924-ipc-and-ubr.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/products/prod_warranties_item09186a008088e31f.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/warp/public/687/Directory/DirTAC.shtml 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. This vulnerability was found internally. 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-20080924-ipc.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 | 2008-Sep-24 | 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----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLcIACgkQ86n/Gc8U/uDLHwCeO1ZYLn/jMCO2qIX5cBhtLo46 uokAn1Q+dApUNnQOJY6Eh1cVegNVXg43 =jP+C -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 11:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Layer 2 Tunneling Protocol (L2TP) Denial of Service Vulnerability Message-ID: <200809241750.l2tp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Layer 2 Tunneling Protocol (L2TP) Denial of Service Vulnerability Advisory ID: cisco-sa-20080924-l2tp http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= A vulnerability exists in the Cisco IOS software implementation of Layer 2 Tunneling Protocol (L2TP), which affects limited Cisco IOS software releases. Several features enable the L2TP mgmt daemon process within Cisco IOS software, including but not limited to Layer 2 virtual private networks (L2VPN), Layer 2 Tunnel Protocol Version 3 (L2TPv3), Stack Group Bidding Protocol (SGBP) and Cisco Virtual Private Dial-Up Networks (VPDN). Once this process is enabled the device is vulnerable. This vulnerability will result in a reload of the device when processing a specially crafted L2TP packet. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml Affected Products ================= All devices running affected versions of 12.2 or 12.4 Cisco IOS system software and that have a vulnerable configuration are affected by this vulnerability. Vulnerable Products +------------------ To determine if a device is vulnerable, first confirm that the device is running an affected version of 12.2 or 12.4 Cisco IOS system software. Then check for the process L2TP mgmt daemon running on the device. To determine the software version running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the show version command or will give different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.4(11)T2: Router#show version Cisco IOS Software, 7200 Software (C7200-ADVSECURITYK9-M), Version 12.4(11)T2, RELEASE SOFTWARE (fc4) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2007 by Cisco Systems, Inc. Compiled Tue 01-May-07 04:19 by prod_rel_team Additional information on the Cisco IOS release naming conventions can be found in the document entitled "White Paper: Cisco IOS Reference Guide," which is available at http://www.cisco.com/warp/public/620/1.html To check if the process L2TP mgmt daemon is running on a device, log into the command line interface (CLI) and issue the command show processes | include L2TP . (NOTE: The command is case sensitive.) If the output returns a line with the process name L2TP mgmt daemon, the device is vulnerable. The following example shows a device running the L2TP mgmt daemon process: Router#show processes | include L2TP 158 Mwe 62590FE4 4 3 133322900/24000 0 L2TP mgmt daemon Router# The L2TP mgmt daemon is started by several different types of configurations that may be deployed in networks that leverage the L2TP protocol. If any of the following commands appear within a device's configuration, show running-config, then the device will have started the L2TP mgmt daemon and is vulnerable. * Device is configured with Virtual Private Dial-Up Networks (VPDN). The command vpdn enable will appear in the device configuration. * Device is configured for L2TP or L2TPv3 Client-Initiated VPDN Tunneling. The command pseudowire peer-ip-address vcid pw-class pw-class-name " appears in the device configuration. * Device is configured with Stack Group Bidding Protocol (SGBP). The command sgbp group group-name will appear in the device configuration. * A L2TP signaling template has been defined. The command l2tp-class l2tp-class name will appear in the device configuration. * Devices configured for Layer 2 Tunnel Protocol Version 3 The commands pseudowire-class pseudowire-class name and a successfully applied interface xconnect command will appear in the device configuration. Products Confirmed Not Vulnerable +-------------------------------- * Devices that are running Cisco IOS versions that are not explicitly listed in the software table below as vulnerable, are not affected. * Cisco IOS XR is not affected. * Cisco IOS XE is not affected. No other Cisco products are currently known to be affected by this vulnerability. Details ======= Documented in RFC2661, L2TP and RFC3931, L2TPv3 are protocols for tunneling network traffic between two peers over an existing network. A device running affected 12.2 and 12.4 versions of Cisco IOS and that has the L2TP mgmt daemon process running will reload when processing a specially crafted L2TP packet. Several features leverage the L2TP protocol and start the L2TP mgmt daemon within Cisco IOS. These features have been outlined in this advisory under the Vulnerable Products section. This vulnerability is documented in Cisco bug ID CSCsh48879 and Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-3813 has been assigned to this vulnerability. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerability 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 CSCsh48879 - Crafted L2TP packet triggers a device reload. CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability will result in a reload of the device. Repeated exploitation may result in an extended denial of service (DoS) condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |--------------+----------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |--------------+-----------------------------------+----------------| | 12.2 | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2B | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2BC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2BW | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2BX | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2BY | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2BZ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2CX | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2CY | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2CZ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2DA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2DD | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2DX | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2EW | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2EWA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2EX | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2EY | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2EZ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2FX | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2FY | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2FZ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2IRB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2IXA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2IXB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2IXC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2IXD | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2IXE | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2IXF | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2IXG | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2JA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2JK | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2MB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2MC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2S | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SBC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SCA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | | Note: Releases prior to 12.2(37) | | | 12.2SE | SE are not vulnerable. First | 12.2(46)SE | | | fixed in 12.2(44)SE | | |--------------+-----------------------------------+----------------| | 12.2SEA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SEB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SEC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SED | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SEE | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SEF | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SEG | Not Vulnerable | | |--------------+-----------------------------------+----------------| | | Note: Releases prior to 12.2(37) | | | 12.2SG | SG are not vulnerable. First | 12.2(46)SG1 | | | Fixed in 12.2(44)SG | | |--------------+-----------------------------------+----------------| | 12.2SGA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SL | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SM | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SO | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SRA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SRB | 12.2(33)SRB1 | 12.2(33)SRB4 | |--------------+-----------------------------------+----------------| | 12.2SRC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SU | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SV | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SVA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SVC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SVD | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SW | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SX | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SXA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SXB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SXD | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SXE | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SXF | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SXH | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SY | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SZ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2T | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2TPC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XD | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XE | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XF | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XG | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XH | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XI | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XJ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XK | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XL | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XM | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XN | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XNA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XNB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XO | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XQ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XR | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XS | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XT | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XU | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XV | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XW | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YD | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YE | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YF | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YG | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YH | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YJ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YK | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YL | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YM | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YN | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YO | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YP | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YQ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YR | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YS | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YT | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YU | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YV | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YW | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YX | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YY | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YZ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZD | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZE | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZF | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZG | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZH | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZJ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZL | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZP | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZU | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZX | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZY | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZYA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |--------------+-----------------------------------+----------------| | 12.4 | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4JA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4JK | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4JL | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4JMA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4JMB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4JMC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4JX | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4MD | Not Vulnerable | | |--------------+-----------------------------------+----------------| | | Note: Releases prior to 12.4(11) | | | 12.4MR | MR are not vulnerable. First | 12.4(19)MR | | | fixed in 12.4(16)MR | | |--------------+-----------------------------------+----------------| | | | 12.4(15)SW2; | | 12.4SW | 12.4(11)SW3 | Available on | | | | 28-SEP-08 | |--------------+-----------------------------------+----------------| | | Note: Releases prior to 12.4(11)T | | | 12.4T | are not vulnerable. First fixed | 12.4(15)T7 | | | in 12.4(15)T | | |--------------+-----------------------------------+----------------| | 12.4XA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XD | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XE | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XF | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XG | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XJ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |--------------+-----------------------------------+----------------| | 12.4XK | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XL | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XM | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XN | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XP | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XQ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XT | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XV | Vulnerable; contact TAC | | |--------------+-----------------------------------+----------------| | 12.4XW | 12.4(11)XW1 | 12.4(11)XW9 | |--------------+-----------------------------------+----------------| | 12.4XY | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XZ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== The following workarounds have been identified for this vulnerability. Note: L2TP implementations will need to allow UDP 1701, from trusted addresses to infrastructure addresses. This does not provide for a full mitigation as the source addresses may be spoofed. Note: L2TPv3 over IP only implementations need to deny all UDP 1701 from anywhere to the infrastructure addresses. * Infrastructure Access Control Lists Although it is often difficult to block traffic that transits a network, it is possible to identify traffic that should never be allowed to target infrastructure devices and block that traffic at the border of networks. Infrastructure Access Control Lists (iACLs) are a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for these specific vulnerabilities. The iACL example below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range: !--- Permit L2TP UDP 1701 packets from all trusted !--- sources destined to infrastructure addresses. !--- NOTE: This does not prevent spoofed attacks. !--- To be a full mitigation, no trusted source !--- addresses should be listed. !--- Omit this line if using a L2TPv3 over IP implementation only. access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES MASK INFRASTRUCTURE_ADDRESSES MASK eq 1701 !--- Deny L2TP UDP 1701 packets from all !--- sources destined to infrastructure addresses. access-list 150 deny udp any INFRASTRUCTURE_ADDRESSES MASK eq 1701 !--- If using a L2TPv3 over IP implementation ensure to allow L2TPv3 access-list 150 permit 115 !--- Permit/deny all other Layer 3 and Layer 4 traffic in accordance !--- with existing security policies and configurations !--- Permit all other traffic to transit the device. access-list 150 permit ip any any !--- Apply access-list to all interfaces (only one example shown) interface serial 2/0 ip access-group 150 in The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained at the following link: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml * Control Plane Policing Control Plane Policing (CoPP) can be used to block L2TP access to the device. Cisco IOS software releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP can be configured on a device to protect the management and control planes and minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic that is sent to infrastructure devices in accordance with existing security policies and configurations. The CoPP example below should be included as part of the deployed CoPP which will protect all devices with IP addresses in the infrastructure IP address range. !--- Deny all trusted source L2TP UDP traffic sent to all IP addresses !--- configured on all interfaces of the affected device so that it !--- will not be policed by the CoPP feature. !--- NOTE: This does not prevent spoofed attacks. !--- To be a full mitigation, no trusted source !--- addresses should be listed. !--- Omit this line if using an L2TPv3 over IP implementation only. access-list 111 deny udp TRUSTED_SOURCE_ADDRESSES MASK INFRASTRUCTURE_ADDRESSES MASK eq 1701 !--- Permit all L2TP UDP traffic sent to all IP addresses !--- configured on all interfaces of the affected device so that it !--- will be policed and dropped by the CoPP feature access-list 111 permit udp any INFRASTRUCTURE_ADDRESSES MASK eq 1701 !--- If using an L2TPv3 over IP implementation ensure not to drop L2TPv3 access-list 111 deny 115 !--- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4 !--- traffic in accordance with existing security policies and !--- configurations for traffic that is authorized to be sent !--- to infrastructure devices !--- Create a Class-Map for traffic to be policed by !--- the CoPP feature class-map match-all drop-l2tp-class match access-group 111 !--- Create a Policy-Map that will be applied to the !--- Control-Plane of the device. policy-map drop-l2tp-traffic class drop-l2tp-class drop !--- Apply the Policy-Map to the !--- Control-Plane of the device control-plane service-policy input drop-l2tp-traffic In the above CoPP example, the access control list entries (ACEs) that match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Please note that the policy-map syntax is different in the 12.2S and 12.0S Cisco IOS trains: policy-map drop-l2tp-traffic class drop-l2tp-class police 32000 1500 1500 conform-action drop exceed-action drop Additional information on the configuration and use of the CoPP feature is available at the following link: http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory: http://www.cisco.com/warp/public/707/cisco-amb-20080924-l2tp.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/products/prod_warranties_item09186a008088e31f.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/warp/public/687/Directory/DirTAC.shtml 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. This vulnerability was found by Cisco through internal testing. 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-20080924-l2tp.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-teams at 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 | 2008-September-24 | 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----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLcgACgkQ86n/Gc8U/uC/CQCfcC70VVLkBqFMyqTqBh9mP0pu BY4AniOvIpCfu1wKu/Zz7USner4MTUnB =jfZd -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 11:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: [c-nsp] Cisco Security Advisory: Cisco IOS MPLS Forwarding Infrastructure Denial of Service Vulnerability Message-ID: <200809241750.mfi@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS MPLS Forwarding Infrastructure Denial of Service Vulnerability Advisory ID: cisco-sa-20080924-mfi http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco IOS Software Multi Protocol Label Switching (MPLS) Forwarding Infrastructure (MFI) is vulnerable to a Denial of Service (DoS) attack from specially crafted packets. Only the MFI is affected by this vulnerability. Older Label Forwarding Information Base (LFIB) implementation, which is replaced by MFI, is not affected. Cisco has released free software updates that address this vulnerability. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml NOTE: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= Devices that run Cisco IOS software (including those that support Cisco IOS Software Modularity) and support MFI are affected if they are configured for MPLS. Vulnerable Products +------------------ A device that runs Cisco IOS software and supports MFI will have mfi_ios in the output of the show subsys command. The following example shows output from a device that supports MFI: Router#show subsys name mfi_ios Class Version mfi_ios Protocol 1.000.001 Router# The following example shows output from a device that is configured for MPLS: Router#show mpls interface Interface IP Tunnel BGP Static Operational Ethernet0/0 Yes (ldp) No No No Yes Router# To determine the software running on a Cisco product, log in to the device and issue the "show version" command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS". On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the "show version" command or will give different output. The following example identifies a Cisco product that is running Cisco IOS release 12.4(11)T2: Router#show version Cisco IOS Software,7200 Software (C7200-ADVSECURITYK9-M), Version 12.4(11)T2, RELEASE SOFTWARE (fc4) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2007 by Cisco Systems, Inc. Compiled Tue 01-May-07 04:19 by prod_rel_team Additional information on the Cisco IOS release naming conventions can be found on the document entitled "White Paper: Cisco IOS Reference Guide", which is available at http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- Devices running Cisco IOS software versions that do not include MFI are not vulnerable. Devices that are not configured for MPLS are not vulnerable. Devices that are running Cisco IOS XR software are not vulnerable. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= In newer versions of Cisco IOS software, a new packet forwarding infrastructure was introduced to improve scalability and performance. This forwarding infrastructure, called MFI, is transparent to the user. MFI manages MPLS data structures used for forwarding and replaces the older implementation, Label Forwarding Information Base (LFIB). Cisco IOS MFI implementation is vulnerable to a DoS attack from specially crafted packets that are handled in the software path, including transit packets that are handled in the software path. Such packets can be sent from the local segment to the interfaces that are configured for MPLS or via tunnel interfaces that are configured for MPLS. To target a remote system in an MPLS network, an attacker needs to have access to the MPLS network through an MPLS-enabled interface. MPLS packets are dropped on interfaces that are not configured for MPLS. Devices that support MFI will have mfi_ios in the output of the show subsys command. Interfaces that are enabled for MPLS can be seen by the show mpls interface command. More information on MFI can be found at the following link: http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_lsc_removed.html This vulnerability is documented in the Cisco Bug ID CSCsk93241 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-3804. 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 CSCsk93241 - Chunk memory corruption on LFDp Input Proc 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 this vulnerability may result in the reload of the device, leading to a DoS condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |------------+--------------------------------------+---------------| | 12.2 | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2B | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2BC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2BW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2BX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2BY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2BZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2CX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2CY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2CZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2DA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2DD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2DX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2EW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2EWA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2EX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2EY | 12.2(44)EY; Available on 16-DEC-08 | | |------------+--------------------------------------+---------------| | 12.2EZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2FX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2FY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2FZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2IRB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2IXA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2IXB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2IXC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2IXD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2IXE | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2IXF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2IXG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2JA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2JK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2MB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2MC | Not Vulnerable | | |------------+--------------------------------------+---------------| | | Releases prior to 12.2(22)S are not | | | | vulnerable. | | | | | 12.2(33)SB2; | | 12.2S | Release 12.2(22)S and later and | Available on | | | prior to 12.2(30)S are vulnerable, | 26-SEP-08 | | | | | | | release 12.2(30)S and later are not | | | | vulnerable | | |------------+--------------------------------------+---------------| | | 12.2(31)SB12 | 12.2(33)SB2; | | 12.2SB | | Available on | | | 12.2(33)SB | 26-SEP-08 | |------------+--------------------------------------+---------------| | | | 12.2(33)SB2; | | 12.2SBC | Vulnerable; first fixed in 12.2SB | Available on | | | | 26-SEP-08 | |------------+--------------------------------------+---------------| | 12.2SCA | 12.2(33)SCA1 | 12.2(33)SCA1 | |------------+--------------------------------------+---------------| | | 12.2(44)SE3; Available on 30-SEP-08 | | | 12.2SE | | 12.2(46)SE | | | 12.2(46)SE | | |------------+--------------------------------------+---------------| | 12.2SEA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SEB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SEC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SED | Vulnerable; first fixed in 12.2SE | 12.2(46)SE | |------------+--------------------------------------+---------------| | 12.2SEE | Vulnerable; first fixed in 12.2SE | 12.2(46)SE | |------------+--------------------------------------+---------------| | 12.2SEF | Not Vulnerable | | |------------+--------------------------------------+---------------| | | Note: Releases prior to 12.2(25)SEG4 | | | 12.2SEG | are vulnerable, release 12.2(25)SEG4 | 12.2(25)SEG6 | | | and later are not vulnerable; | | |------------+--------------------------------------+---------------| | 12.2SG | 12.2(50)SG; Available on 24-NOV-08 | 12.2(46)SG1 | |------------+--------------------------------------+---------------| | 12.2SGA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SM | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SO | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.2(33)SRB4 | | 12.2SRA | Vulnerable; first fixed in 12.2SRB | | | | | 12.2(33)SRC2 | |------------+--------------------------------------+---------------| | 12.2SRB | 12.2(33)SRB4 | 12.2(33)SRB4 | |------------+--------------------------------------+---------------| | 12.2SRC | 12.2(33)SRC1 | 12.2(33)SRC2 | |------------+--------------------------------------+---------------| | 12.2SU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SV | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.2SVA | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.2SVC | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.2SVD | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | | Note: Releases prior to 12.2(25)SW4 | | | 12.2SW | are vulnerable, release 12.2(25)SW4 | 12.2(25)SW12 | | | and later are not vulnerable; | | |------------+--------------------------------------+---------------| | 12.2SX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SXA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SXB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SXD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SXE | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SXF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SXH | 12.2(33)SXH3 | 12.2(33)SXH3 | |------------+--------------------------------------+---------------| | 12.2SY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2T | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2TPC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XE | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XH | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XI | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XM | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.2(33)SB2; | | | | Available on | | | | 26-SEP-08 | | 12.2XN | Vulnerable; first fixed in 12.2SB | | | | | 12.2(33)SRC2 | | | | | | | | 12.2(33)XNA2 | |------------+--------------------------------------+---------------| | 12.2XNA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XNB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XO | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XQ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XR | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XS | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XT | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XV | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YE | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YH | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YM | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YN | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YO | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YP | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YQ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YR | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YS | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YT | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YV | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZE | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZH | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZP | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZU | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.2(33)SB2; | | 12.2ZX | Vulnerable; first fixed in 12.2SB | Available on | | | | 26-SEP-08 | |------------+--------------------------------------+---------------| | 12.2ZY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZYA | Not Vulnerable | | |------------+--------------------------------------+---------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |------------+--------------------------------------+---------------| | 12.4 | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4MD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4MR | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4SW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4T | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XE | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XM | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XN | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XP | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XQ | 12.4(15)XQ1 | 12.4(15)XQ1 | |------------+--------------------------------------+---------------| | 12.4XR | Vulnerable; migrate to any release | 12.4(15)T7 | | | in 12.4T | | |------------+--------------------------------------+---------------| | 12.4XT | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XV | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XY | 12.4(15)XY4 | 12.4(15)XY4 | |------------+--------------------------------------+---------------| | 12.4XZ | 12.4(15)XZ1 | 12.4(15)XZ2 | |------------+--------------------------------------+---------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== MPLS is normally enabled on physical and logical interfaces that are shared with other MPLS-enabled devices. It can be disabled on interfaces where MPLS is not necessary and from which a potential attack can be launched. This action may help to limit the exposure of this vulnerability. If it is not possible to disable MPLS on interfaces from which an attack can be launched, there are no workarounds to mitigate this vulnerability. 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/products/prod_warranties_item09186a008088e31f.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/warp/public/687/Directory/DirTAC.shtml 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. This vulnerability was found internally. 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-20080924-mfi.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 | 2008-Sep-24 | 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----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLcwACgkQ86n/Gc8U/uCKtQCeOUTNVK58br0wqCUQAa506CGJ aWIAn3WBReM3lzWMM/+iT7SVaH6npY3E =7zu4 -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 11:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: [c-nsp] Cisco Security Advisory: Cisco IOS NAT Skinny Call Control Protocol Vulnerability Message-ID: <200809241750.sccp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS NAT Skinny Call Control Protocol Vulnerability Advisory ID: cisco-sa-20080924-sccp http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= A series of segmented Skinny Call Control Protocol (SCCP) messages may cause a Cisco IOS device that is configured with the Network Address Translation (NAT) SCCP Fragmentation Support feature to reload. Cisco has released free software updates that address this vulnerability. A workaround that mitigates this vulnerability is available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml Affected Products ================= Vulnerable Products +------------------ This security advisory applies to all Cisco products that run Cisco IOS Software configured for NAT and that support the NAT SCCP Fragmentation Support feature. This feature was first introduced in Cisco IOS version 12.4(6)T. To verify if NAT is enabled on a Cisco IOS device log into the device and issue the command show ip nat statistics. The following example shows a device configured with NAT: Router# show ip nat statistics Total translations: 2 (0 static, 2 dynamic; 0 extended) Outside interfaces: Serial0 Inside interfaces: Ethernet1 Hits: 135 Misses: 5 Expired translations: 2 Dynamic mappings: -- Inside Source access-list 1 pool mypool refcount 2 pool mypool: netmask 255.255.255.0 start 192.168.10.1 end 192.168.10.254 type generic, total addresses 14, allocated 2 (14%), misses 0 Alternatively, you can use the show running-config | include ip nat command to verify if NAT has been enabled on the router interfaces. Note: With reference to NAT, the term "inside" refers to those networks that will be translated. Inside this domain, hosts will have addresses in one address space, while on the "outside", they will appear to have addresses in another address space when NAT is configured. The first address space is referred to as the local address space and the second is referred to as the global address space. The ip nat inside and ip nat outside interface commands must be present on the corresponding router interfaces in order for NAT to be enabled. In order to determine the software that runs on a Cisco IOS product, log in to the device and issue the show version command to display the system banner. Cisco IOS software identifies itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name displays between parentheses, followed by "Version" and the Cisco IOS release name. Other Cisco devices do not have the show version command or give different output. The following example shows output from a device that runs an IOS image: router>show version Cisco IOS Software, 7200 Software (C7200-ADVSECURITYK9-M), Version 12.4(6)T2, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2006 by Cisco Systems, Inc. Compiled Tue 16-May-06 16:09 by kellythw Products Confirmed Not Vulnerable +-------------------------------- Cisco IOS XR and IOS XE are not affected by this vulnerability. Cisco IOS devices not explicitly configured for NAT are not vulnerable. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= The Skinny Call Control Protocol (SCCP) enables voice communication between an SCCP client and a Call Manager (CM). Typically, the CM provides service to the SCCP clients on TCP Port 2000 by default. Initially, an SCCP client connects to the CM by establishing a TCP connection; the client will also establish a TCP connection with a secondary CM, if available. The NAT SCCP Fragmentation Support feature prevents skinny control message exchanges from failing in a TCP segmentation scenario because the NAT Skinny Application Layer Gateway (ALG) is able to reassemble the skinny control messages. A segmented payload that requires an IP or port translation will no longer be dropped. The NAT SCCP Fragmentation Support feature was introduced in Cisco IOS version 12.4(6)T. A series of fragmented SCCP messages may cause a Cisco IOS router that is running the NAT SCCP Fragmentation Support feature to reload. This vulnerability is documented in Cisco Bug ID CSCsg22426 and CSCsi17020, and has been assigned CVE identifiers CVE-2008-3810 and CVE-2008-3811. 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 CSCsg22426 - Cisco IOS Skinny Call Control Protocol (SCCP) Vulnerability 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 CSCsi17020 - Router may reload after NAT with certain skinny packets 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 this vulnerability may cause the affected device to reload. Repeated exploitation will result in a denial of service (DoS) condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major Release | Availability of Repaired Releases | |-------------------+-----------------------------------------------| | Affected | | | | 12.0-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | | | 12.1-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | | | 12.2-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------+-----------------------+-----------------------| | 12.2 | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2B | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2BC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2BW | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2BX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2BY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2BZ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2CX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2CY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2CZ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2DA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2DD | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2DX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2EW | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2EWA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2EX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2EY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2EZ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2FX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2FY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2FZ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2IRB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2IXA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2IXB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2IXC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2IXD | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2IXE | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2IXF | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2IXG | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2JA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2JK | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2MB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2MC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2S | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SBC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SCA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SE | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SEA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SEB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SEC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SED | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SEE | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SEF | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SEG | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SG | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SGA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SL | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SM | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SO | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SRA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SRB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SRC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SU | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SV | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SVA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SVC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SVD | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SW | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SXA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SXB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SXD | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SXE | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SXF | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | | Not Vulnerable | | | 12.2SXH | | | | | http://www.cisco.com/ | | | | go/pn | | |-------------------+-----------------------+-----------------------| | 12.2SY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SZ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2T | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2TPC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XD | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XE | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XF | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XG | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XH | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XI | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XJ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XK | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XL | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XM | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XN | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XNA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XNB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XO | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XQ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XR | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XS | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XT | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XU | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XV | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XW | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YD | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YE | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YF | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YG | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YH | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YJ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YK | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YL | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YM | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YN | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YO | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YP | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YQ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YR | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YS | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YT | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YU | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YV | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YW | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YZ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZD | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZE | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZF | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZG | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZH | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZJ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZL | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZP | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZU | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZYA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | Affected | | | | 12.3-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected | | | | 12.4-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------+-----------------------+-----------------------| | 12.4 | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JK | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JL | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JMA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JMB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JMC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4MD | 12.4(11)MD4 | 12.4(15)MD1 | |-------------------+-----------------------+-----------------------| | 12.4MR | 12.4(16)MR | 12.4(19)MR | |-------------------+-----------------------+-----------------------| | | 12.4(15)SW2; | 12.4(15)SW2; | | 12.4SW | Available on | Available on | | | 28-SEP-08 | 28-SEP-08 | |-------------------+-----------------------+-----------------------| | | 12.4(11)T4 | | | | | | | | 12.4(15)T2 | | | | | | | 12.4T | 12.4(20)T | 12.4(15)T7 | | | | | | | 12.4(6)T11 | | | | | | | | 12.4(9)T5 | | |-------------------+-----------------------+-----------------------| | 12.4XA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XC | Vulnerable; first | 12.4(15)T7 | | | fixed in 12.4T | | |-------------------+-----------------------+-----------------------| | 12.4XD | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XE | Vulnerable; first | 12.4(15)T7 | | | fixed in 12.4T | | |-------------------+-----------------------+-----------------------| | 12.4XF | Vulnerable; first | 12.4(15)T7 | | | fixed in 12.4T | | |-------------------+-----------------------+-----------------------| | 12.4XG | 12.4(9)XG3 | 12.4(9)XG3 | |-------------------+-----------------------+-----------------------| | 12.4XJ | Vulnerable; first | 12.4(15)T7 | | | fixed in 12.4T | | |-------------------+-----------------------+-----------------------| | 12.4XK | Vulnerable; first | 12.4(15)T7 | | | fixed in 12.4T | | |-------------------+-----------------------+-----------------------| | 12.4XL | 12.4(15)XL2 | 12.4(15)XL2 | |-------------------+-----------------------+-----------------------| | 12.4XM | 12.4(15)XM1 | 12.4(15)XM1 | |-------------------+-----------------------+-----------------------| | 12.4XN | Vulnerable; contact | | | | TAC | | |-------------------+-----------------------+-----------------------| | 12.4XP | Vulnerable; contact | | | | TAC | | |-------------------+-----------------------+-----------------------| | 12.4XQ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XR | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XT | Vulnerable; first | 12.4(15)T7 | | | fixed in 12.4T | | |-------------------+-----------------------+-----------------------| | 12.4XV | Vulnerable; contact | | | | TAC | | |-------------------+-----------------------+-----------------------| | 12.4XW | 12.4(11)XW7 | 12.4(11)XW9 | |-------------------+-----------------------+-----------------------| | 12.4XY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XZ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== As workaround, an administrator can disable SCCP NAT support using the no ip nat service skinny tcp port 2000 command, as shown in the following example: Router(config)# no ip nat service skinny tcp port 2000 Note: If your Cisco CallManager is using a TCP port for skinny signaling different from the default port (2000), you need to adjust this command accordingly. 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/products/prod_warranties_item09186a008088e31f.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/warp/public/687/Directory/DirTAC.shtml 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. 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-20080924-sccp.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-teams at 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 | 2008-September-24 | 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----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLdUACgkQ86n/Gc8U/uBM1ACeMzZ03zyWQhMRkiHOGUi20KeT NAoAnR9OVAOw7st0mwFWyEmatcQIxy2v =CqpX -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 11:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: [c-nsp] Cisco Security Advisory: Vulnerability in Cisco IOS While Processing SSL Packet Message-ID: <200809241750.ssl@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Vulnerability in Cisco IOS While Processing SSL Packet Advisory ID: cisco-sa-20080924-ssl http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= A Cisco IOS device may crash while processing an SSL packet. This can happen during the termination of an SSL-based session. The offending packet is not malformed and is normally received as part of the packet exchange. Cisco has released free software updates that address this vulnerability. Aside from disabling affected services, there are no available workarounds to mitigate an exploit of this vulnerability. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= Vulnerable Products +------------------ Devices running Cisco IOS and using SSL-based services are susceptible to this vulnerability. Some of the services that utilize SSL are: * HTTP server supporting SSL encryption (HTTPS) The following example shows a device that has the standard Cisco IOS HTTP server disabled, but the SSL-enabled Cisco IOS HTTP server enabled: Router#show running-config | include ip http no ip http server ip http secure-server Router# * SSL Virtual Private Network (SSL VPN) also known as AnyConnect VPN The following example shows a device that has the SSL VPN feature enabled: Router#show running-config | include webvpn webvpn enable webvpn Router# * Open Settlement Protocol (OSP) for Packet Telephony feature The following example shows a device that has the OSP feature enabled and uses HTTPS protocol that is vulnerable: Router#show running-config | include url url https://:443/ Router# The Cisco IOS Bug Toolkit may not accurately reflect the affected releases for this advisory. The affected releases are as follows: * 12.4(16)MR, 12.4(16)MR1, 12.4(16)MR2 * 12.4(17) To determine the version of the Cisco IOS software running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS Software will identify itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the show version command or will give different output. Router#show version Cisco IOS Software, 1841 Software (C1841-ADVSECURITYK9-M), Version 12.4(15)T2, RELEASE SOFTWARE (fc7) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 17-Jan-08 23:12 by prod_rel_team Additional information about Cisco IOS software release naming is available at the following link: http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- No other Cisco products and Cisco IOS releases are currently known to be affected by this vulnerability. Details ======= This vulnerability is triggered during the termination of an SSL session. Possession of valid credentials such as a username, password or a certificate is not required. SSL protocol uses TCP as a transport protocol. The requirement of the complete TCP 3-way handshake reduces the probability that this vulnerability will be exploited through the use of spoofed IP addresses. A device running vulnerable Cisco IOS Software with SSL-based service configured will crash while terminating an SSL session. This vulnerability is documented in Cisco Bug ID CSCsj85065 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-3798. 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 CSCsj85065 - Router reload while processing SSL packets 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 ====== A successful exploit of this vulnerability may cause a crash of the affected device. Repeated exploitation may result in a sustained denial of service condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major Release | Availability of Repaired Releases | |---------------------------+---------------------------------------| | Affected 12.0-Based | First Fixed | Recommended | | Releases | Release | Release | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected 12.1-Based | First Fixed | Recommended | | Releases | Release | Release | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected 12.2-Based | First Fixed | Recommended | | Releases | Release | Release | |-------------------------------------------------------------------| | There are no affected 12.2 based releases | |-------------------------------------------------------------------| | Affected 12.3-Based | First Fixed | Recommended | | Releases | Release | Release | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected 12.4-Based | First Fixed | Recommended | | Releases | Release | Release | |---------------------------+-------------------+-------------------| | | 12.4(17a) | | | 12.4 | | 12.4(18c) | | | 12.4(18) | | |---------------------------+-------------------+-------------------| | 12.4JA | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4JK | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4JL | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4JMA | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4JMB | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4JMC | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4JX | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4MD | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4MR | 12.4(19)MR | 12.4(19)MR | |---------------------------+-------------------+-------------------| | 12.4SW | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4T | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XA | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XB | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XC | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XD | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XE | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XF | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XG | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XJ | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XK | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XL | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XM | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XN | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XP | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XQ | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XT | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XV | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XW | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XY | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XZ | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== To prevent an exploit of a vulnerable device, SSL-based services need to be disabled. However, if regular maintenance and operation of the device relies on this service, there is no workaround. The following command will disable the vulnerable HTTPS service: Router(config)#no ip http secure-server The following command will disable the vulnerable SSL VPN service: Router(config)#no webvpn enable The following command will disable the vulnerable OSP service: Router(config)#no settlement Another option is to revert to HTTP protocol instead using HTTPS. The downside of this workaround is that the settlement information will be sent over the network unprotected. It is possible to mitigate this vulnerability by preventing unauthorized hosts from accessing affected devices. Control Plane Policing (CoPP) +---------------------------- Cisco IOS software versions that support Control Plane Policing (CoPP) can be configured to help protect the device from attacks that target the management and control planes. CoPP is available in Cisco IOS release trains 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T. In the following CoPP example, the ACL entries that match the exploit packets with the permit action will be discarded by the policy-map drop function, whereas packets that match a deny action (not shown) are not affected by the policy-map drop function: !-- Include deny statements up front for any protocols/ports/IP addresses that !-- should not be impacted by CoPP !-- Include permit statements for the protocols/ports that will be !-- governed by CoPPaccess-list 100 permit tcp any any eq 443 !-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4 !-- traffic in accordance with existing security policies and !-- configurations for traffic that is authorized to be sent !-- to infrastructure devices. ! !-- Create a Class-Map for traffic to be policed by !-- the CoPP feature. ! class-map match-all drop-SSL-class match access-group 100 ! !-- Create a Policy-Map that will be applied to the !-- Control-Plane of the device. ! policy-map drop-SSL-policy class drop-SSL-class drop !-- Apply the Policy-Map to the Control-Plane of the !-- device. ! control-plane service-policy input drop-SSL-policy Note: In the preceding CoPP example, the ACL entries with the permit action that match the exploit packets will result in the discarding of those packets by the policy-map drop function, whereas packets that match the deny action are not affected by the policy-map drop function. Additional information on the configuration and use of the CoPP feature is available at the following links: http://www.cisco.com/en/US/products/ps6642/products_white_paper0900aecd804fa16a.shtml and http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guide09186a008052446b.html Access Control List (ACL) +------------------------ An Access Control List (ACL) can be used to help mitigate attacks that target this vulnerability. ACLs can specify that only packets from legitimate sources are permitted to reach a device, and all others are to be dropped. The following example shows how to allow legitimate SSL sessions from trusted sources and deny all other SSL sessions: access-list 101 permit tcp host host eq 443 access-list 101 deny tcp any any eq 443 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/products/prod_warranties_item09186a008088e31f.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/warp/public/687/Directory/DirTAC.shtml 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. 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-20080924-ssl.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 | 2008-September-24 | 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 - --------------------------------------------------------------------- Toolbar Contacts & Feedback | Help | Site Map 2007 - 2008 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLeIACgkQ86n/Gc8U/uDvigCfcWXjj9bLlpN4XB1nMsDRt2h6 F5EAnRsZsoyb0638vZK7pU8owyw+Ust5 =gXdE -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 11:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: [c-nsp] Cisco Security Advisory: Cisco uBR10012 Series Devices SNMP Vulnerability Message-ID: <200809241750.ubr@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco uBR10012 Series Devices SNMP Vulnerability Advisory ID: cisco-sa-20080924-ubr http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco uBR10012 series devices automatically enable Simple Network Management Protocol (SNMP) read/write access to the device if configured for linecard redundancy. This can be exploited by an attacker to gain complete control of the device. Only Cisco uBR10012 series devices that are configured for linecard redundancy are affected. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml NOTE: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS^ software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= Vulnerable Products +------------------ Cisco uBR10012 series devices that are running Cisco IOS and configured for linecard redundancy are affected. Cisco uBR10012 series devices can be identified by issuing the show version command. The following example shows output from a Cisco uBR10012 series device running Cisco IOS software release 12.3(17b)BC7: ubr10k#show version | include IOS IOS (tm) 10000 Software (UBR10K-K8P6U2-M), Version 12.3(17b)BC7, RELEASE SOFTWARE (fc1) ubr10k# Please refer to the document entitled "White Paper: Cisco IOS Reference Guide" for additional information on the Cisco IOS release naming conventions. This document is available at the following link: http://www.cisco.com/warp/public/620/1.html A Cisco uBR10012 series device configured for linecard redundancy will have a line similar to the following in the output of show running-config command: member subslot / working or hccp protect Any version of Cisco IOS prior to the versions listed in the Software Versions and Fixes section below is vulnerable. Products Confirmed Not Vulnerable +-------------------------------- Cisco uBR10012 series devices that are not configured for linecard redundancy are not affected. Cisco 10000 series devices are not affected even if they are configured for linecard redundancy. Other uBR platforms are not affected. No other Cisco products are currently known to be affected by this vulnerability. Details ======= Cisco uBR10012 series devices need to communicate with an RF Switch when configured for linecard redundancy. This communication is based on SNMP (Simple Network Management Protocol). When linecard redundancy is enabled on a Cisco uBR10012 series device, SNMP is also automatically enabled with a default community string of private that has read/write privileges. Since there are no access restrictions on this community string, it may be exploited by an attacker to gain complete control of the device. Changing the default community string, adding access restrictions on SNMP or doing both will mitigate this vulnerability. The recommended mitigation is to do both. This vulnerability is documented in the Cisco Bug ID CSCek57932 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-3807. 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 CSCek57932 - SNMP enabled after redundancy is configured CVSS Base Score - 10 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - Complete Integrity Impact - Complete Availability Impact - Complete CVSS Temporal Score - 8.3 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability may allow an attacker to gain complete control of the device. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major Release | Availability of Repaired Releases | |--------------------+----------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |--------------------+------------------------------+---------------| | 12.2 | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2B | Not Vulnerable | | |--------------------+------------------------------+---------------| | | | 12.2(33)SCA1 | | | | | | | Vulnerable; migrate to any | 12.3(23)BC4 | | 12.2BC | release in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |--------------------+------------------------------+---------------| | 12.2BW | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2BX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2BY | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2BZ | Not Vulnerable | | |--------------------+------------------------------+---------------| | | | 12.2(33)SCA1 | | | | | | | Vulnerable; migrate to any | 12.3(23)BC4 | | 12.2CX | release in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |--------------------+------------------------------+---------------| | | | 12.2(33)SCA1 | | | | | | | Vulnerable; migrate to any | 12.3(23)BC4 | | 12.2CY | release in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |--------------------+------------------------------+---------------| | 12.2CZ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2DA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2DD | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2DX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2EW | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2EWA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2EX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2EY | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2EZ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2FX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2FY | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2FZ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2IRB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2IXA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2IXB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2IXC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2IXD | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2IXE | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2IXF | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2IXG | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2JA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2JK | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2MB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2MC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2S | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SBC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SCA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SE | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SEA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SEB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SEC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SED | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SEE | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SEF | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SEG | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SG | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SGA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SL | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SM | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SO | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SRA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SRB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SRC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SU | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SV | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SVA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SVC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SVD | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SW | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SXA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SXB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SXD | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SXE | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SXF | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SXH | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SY | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SZ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2T | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2TPC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XD | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XE | Not Vulnerable | | |--------------------+------------------------------+---------------| | | | 12.2(33)SCA1 | | | | | | | Vulnerable; migrate to any | 12.3(23)BC4 | | 12.2XF | release in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |--------------------+------------------------------+---------------| | 12.2XG | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XH | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XI | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XJ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XK | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XL | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XM | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XN | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XNA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XNB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XO | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XQ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XR | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XS | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XT | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XU | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XV | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XW | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YD | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YE | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YF | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YG | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YH | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YJ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YK | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YL | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YM | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YN | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YO | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YP | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YQ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YR | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YS | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YT | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YU | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YV | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YW | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YY | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YZ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZD | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZE | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZF | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZG | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZH | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZJ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZL | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZP | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZU | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZY | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZYA | Not Vulnerable | | |--------------------+------------------------------+---------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |--------------------+------------------------------+---------------| | 12.3 | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3B | Not Vulnerable | | |--------------------+------------------------------+---------------| | | 12.3(17b)BC8 | | | 12.3BC | | 12.3(23)BC4 | | | 12.3(21)BC | | |--------------------+------------------------------+---------------| | 12.3BW | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3EU | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3JA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3JEA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3JEB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3JEC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3JK | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3JL | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3JX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3T | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3TPC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3VA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XD | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XE | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XF | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XG | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XI | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XJ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XK | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XL | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XQ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XR | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XS | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XU | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XW | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XY | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XZ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YD | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YF | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YG | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YH | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YI | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YJ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YK | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YM | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YQ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YS | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YT | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YU | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YZ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3ZA | Not Vulnerable | | |--------------------+------------------------------+---------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.4 based releases | +-------------------------------------------------------------------+ Workarounds =========== Changing SNMP community string and restricting access +---------------------------------------------------- By default, Cisco uBR10012 series devices that are configured for linecard redundancy use a community string of private. This community string can be changed in Cisco IOS versions 12.3(13)BC and later. It is recommended to change the community string and apply access control restrictions that only permit authorized devices SNMP access to the device. The following configuration example provides operators with information on changing the community string and adding SNMP access control restrictions using an access control list (ACL). access-list 90 permit host access-list 90 permit host access-list 90 permit host access-list 90 deny any redundancy linecard-group 1 cable rf-switch snmp-community snmp-server community rw 90 When the SNMP community is changed on a Cisco uBR10012 device, is must also be changed on the RF Switch. It can be changed by the following command: set SNMP COMMUNITY If there is an up-converter in the network, the SNMP community used by the up-converter must also be changed after changing the community string on the Cisco uBR10012 device. Information on changing the community string used by the up-converter can be found at the following link: http://www.cisco.com/en/US/tech/tk86/tk804/technologies_tech_note09186a00801f7622.shtml#communication If the Cisco IOS version does not support changing the community string, access control restrictions can be applied to the default community string. The following configuration example provides operators with information on applying access control restrictions to the default community string. access-list 90 permit host access-list 90 permit host access-list 90 permit host access-list 90 deny any snmp-server community private rw 90 Using Infrastructure ACLs at Network Boundary +-------------------------------------------- Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. iACLs are a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The iACL example shown below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range: !-- Permit SNMP (UDP port 161) packets from trusted hosts !-- destined to infrastructure addresses. ! access-list 150 permit udp TRUSTED_HOSTS MASK INFRASTRUCTURE_ADDRESSES MASK eq 161 ! !-- Deny SNMP (UDP port 161) packets from all other sources !-- destined to infrastructure addresses. ! access-list 150 deny udp any INFRASTRUCTURE_ADDRESSES MASK eq 161 ! !-- Permit/deny all other Layer 3 and Layer 4 traffic in !-- accordance with existing security policies and !-- configurations. ! !-- Permit all other traffic to transit the device. ! access-list 150 permit ip any any ! !-- Apply iACL to interfaces in the ingress direction. ! interface GigabitEthernet0/0 ip access-group 150 in ! The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained here: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml Additional Mitigation Techniques +------------------------------- Additional mitigation techniques 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-20080924-ipc-and-ubr.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/products/prod_warranties_item09186a008088e31f.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/warp/public/687/Directory/DirTAC.shtml 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. This vulnerability was found internally. 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-20080924-ubr.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 | 2008-Sep-24 | 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----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLecACgkQ86n/Gc8U/uBcmQCggF37DyYthxIC+6vnZJesy8Cy hkAAnicMWS466BM5nAqpG6sDE9d3VTKo =iDxl -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 11:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: [c-nsp] Cisco Security Advisory: Cisco IOS MPLS VPN May Leak Information Message-ID: <200809241750.vpn@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS MPLS VPN May Leak Information Advisory ID: cisco-sa-20080924-vpn http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Devices running Cisco IOS versions 12.0S, 12.2, 12.3 or 12.4 and configured for Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs) or VPN Routing and Forwarding Lite (VRF Lite) and using Border Gateway Protocol (BGP) between Customer Edge (CE) and Provider Edge (PE) devices may permit information to propagate between VPNs. Workarounds are available to help mitigate this vulnerability. This issue is triggered by a logic error when processing extended communities on the PE device. This issue cannot be deterministically exploited by an attacker. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate these vulnerabilities are available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml NOTE: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= Products running Cisco IOS versions 12.0S, 12.2, 12.3 or 12.4 and configured for MPLS VPNs or VRF Lite are potentially affected. Cisco IOS releases based on 12.1 are not affected. Vulnerable Products +------------------ Cisco IOS devices are vulnerable if they are configured for MPLS VPN or VRF Lite and have a BGP session between the CE and PE devices, and process extended communities. If a device is configured for MPLS VPN or VRF Lite the command address-family ipv4 vrf or address-family ipv6 vrf will be present in the device configuration. The following shows a command executed on a device configured for MPLS VPN: router#show running-config | include address-family [ipv4|ipv6] address-family ipv4 vrf The following shows a PE device configured for an IPv4 BGP session between the PE and the CE: router bgp address-family ipv4 vrf one neighbor remote-as < Remote AS> neighbor activate To determine the software running on a Cisco product, log in to the device and issue the "show version" command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS". On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the "show version" command or will give different output. The following example identifies a Cisco product that is running Cisco IOS release 12.4(11)T2: Router#show version Cisco IOS Software, 7200 Software (C7200-ADVSECURITYK9-M), Version 12.4(11)T2, RELEASE SOFTWARE (fc4) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2007 by Cisco Systems, Inc. Compiled Tue 01-May-07 04:19 by prod_rel_team Additional information on the Cisco IOS release naming conventions can be found on the document entitled "White Paper: Cisco IOS Reference Guide", which is available at http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- Cisco products not configured for MPLS VPNs or VRF Lite are unaffected by this vulnerability. Cisco products that do not run IOS are unaffected by this vulnerability. Cisco IOS-XR is not affected. No other Cisco products are currently known to be affected by this vulnerability. Details ======= MPLS VPNs allow for the creation of 'virtual networks' that customers can use to segregate traffic into multiple, isolated VPNs. Traffic within each MPLS VPN is kept separate from the others, thereby maintaining a virtual private network. More information on MPLS and MPLS VPNs is available at the following link: http://www.cisco.com/en/US/products/ps6557/products_ios_technology_home.html A bug exists when processing extended communities with MPLS VPNs. If extended communities are used, MPLS VPN may incorrectly use a corrupted route target (RT) to forward traffic. If this occurs, traffic can leak from one MPLS VPN to another. This vulnerability exists whenever an affected PE device has a BGP session running in the MPLS VPN Virtual Routing and Forwarding (VRF). The following two examples of this scenario are the most common: 1) MPLS VPN configuration with BGP running inside the VRF between the PE and CE devices. 2) MPLS Inter-AS option A with BGP running between the Autonomous System Border Routers (ASBR). The mitigation in the Workarounds section filters extended communities on a PE device, preventing them from being received by devices configured for MPLS VPN. This vulnerability was introduced with Cisco bug ID CSCee83237. Cisco IOS images that do not include CSCee83237 are not vulnerable to this issue. It is important to note that this condition cannot be triggered by an attacker and that the condition does not provide ways to determine the flow of traffic between VPNs. This vulnerability is documented in the Cisco Bug ID CSCec12299 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-3803. 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 CVSS Base Score - 5.1 Access Vector - Network Access Complexity - High Authentication - None Confidentiality Impact - Partial Integrity Impact - Partial Availability Impact - Partial CVSS Temporal Score - 4.2 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== This vulnerability may cause traffic to be improperly routed between MPLS VPNs, which may lead to a breach of confidentiality. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |--------------+----------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |--------------+----------------------------------+-----------------| | 12.0 | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0DA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0DB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0DC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | 12.0(30)S5 | | | | | 12.0(32)S11 | | 12.0S | 12.0(31)S3 | | | | | 12.0(33)S1 | | | 12.0(32)S | | |--------------+----------------------------------+-----------------| | 12.0SC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0SL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0SP | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0ST | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | | 12.0(32)S11 | | 12.0SX | Vulnerable; first fixed in 12.0S | | | | | 12.0(33)S1 | |--------------+----------------------------------+-----------------| | 12.0SY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | | 12.0(32)S11 | | 12.0SZ | 12.0(30)SZ4 | | | | | 12.0(33)S1 | |--------------+----------------------------------+-----------------| | 12.0T | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0W | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0WC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0WT | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XE | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XF | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XG | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XH | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XI | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XJ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XK | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XM | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XN | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XQ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XR | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XS | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XT | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XV | Not Vulnerable | | |--------------+----------------------------------+-----------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |--------------+----------------------------------+-----------------| | 12.2 | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2B | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2BC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2BW | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2BX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2BY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2BZ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2CX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2CY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2CZ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2DA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2DD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2DX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2EW | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2EWA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2EX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2EY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2EZ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2FX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2FY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2FZ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2IRB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2IXA | Vulnerable; migrate to any | 12.2(18)IXG | | | release in 12.2IXD | | |--------------+----------------------------------+-----------------| | 12.2IXB | Vulnerable; migrate to any | 12.2(18)IXG | | | release in 12.2IXD | | |--------------+----------------------------------+-----------------| | 12.2IXC | Vulnerable; migrate to any | 12.2(18)IXG | | | release in 12.2IXD | | |--------------+----------------------------------+-----------------| | 12.2IXD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2IXE | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2IXF | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2IXG | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2JA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2JK | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2MB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2MC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | 12.2(30)S and later are | 12.2(33)SB2; | | 12.2S | vulnerable. 12.2(25)S and before | Available on | | | are not vulnerable | 26-SEP-08 | |--------------+----------------------------------+-----------------| | | 12.2(28)SB5 | | | | | 12.2(33)SB2; | | 12.2SB | 12.2(31)SB2 | Available on | | | | 26-SEP-08 | | | 12.2(31)SB3x | | |--------------+----------------------------------+-----------------| | | Vulnerable; first fixed in | 12.2(33)SB2; | | 12.2SBC | 12.2SB | Available on | | | | 26-SEP-08 | |--------------+----------------------------------+-----------------| | 12.2SCA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SE | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SEA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SEB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SEC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SED | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SEE | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SEF | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SEG | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SG | 12.2(37)SG | 12.2(46)SG1 | |--------------+----------------------------------+-----------------| | 12.2SGA | 12.2(31)SGA8 | 12.2(31)SGA8 | |--------------+----------------------------------+-----------------| | 12.2SL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SM | 12.2(29)SM2 | 12.2(29)SM4 | |--------------+----------------------------------+-----------------| | 12.2SO | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SRA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SRB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SRC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SU | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SV | 12.2(29b)SV1 | | |--------------+----------------------------------+-----------------| | 12.2SVA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SVC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SVD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SW | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SXA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SXB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SXD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SXE | Vulnerable; first fixed in | 12.2(18)SXF15 | | | 12.2SXF | | |--------------+----------------------------------+-----------------| | 12.2SXF | 12.2(18)SXF3 | 12.2(18)SXF15 | |--------------+----------------------------------+-----------------| | 12.2SXH | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SZ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2T | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2TPC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XE | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XF | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XG | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XH | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XI | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XJ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XK | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XM | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XN | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XNA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XNB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XO | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XQ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XR | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XS | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XT | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XU | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XV | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XW | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YE | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YF | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YG | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YH | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YJ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YK | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YM | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YN | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YO | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YP | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YQ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YR | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YS | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YT | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YU | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YV | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YW | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YZ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZE | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZF | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZG | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZH | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZJ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZP | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZU | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | Vulnerable; first fixed in | 12.2(33)SB2; | | 12.2ZX | 12.2SB | Available on | | | | 26-SEP-08 | |--------------+----------------------------------+-----------------| | 12.2ZY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZYA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |--------------+----------------------------------+-----------------| | 12.3 | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3B | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3BC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3BW | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3EU | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3JA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3JEA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3JEB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3JEC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3JK | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3JL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3JX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | | 12.4(15)T7 | | 12.3T | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |--------------+----------------------------------+-----------------| | 12.3TPC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3VA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XE | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XF | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XG | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XI | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XJ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XK | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | | 12.4(15)T7 | | 12.3XL | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |--------------+----------------------------------+-----------------| | 12.3XQ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XR | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XS | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XU | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XW | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XZ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3YA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3YD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | Vulnerable; first fixed in | 12.3(14)YX13 | | 12.3YF | 12.3YX | | | | | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.3YG | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3YH | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3YI | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3YJ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.3YK | 12.3(11)YK3 | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | | | 12.3(14)YM13; | | 12.3YM | 12.3(14)YM10 | Available on | | | | 30-SEP-08 | |--------------+----------------------------------+-----------------| | 12.3YQ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.3YS | 12.3(11)YS2 | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.3YT | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | | | 12.4(2)XB10 | | | Vulnerable; first fixed in | | | 12.3YU | 12.4XB | 12.4(9)XG3 | | | | | | | | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.3YX | 12.3(14)YX7 | 12.3(14)YX13 | |--------------+----------------------------------+-----------------| | 12.3YZ | 12.3(11)YZ2 | | |--------------+----------------------------------+-----------------| | 12.3ZA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |--------------+----------------------------------+-----------------| | | 12.4(10c) | | | | | | | | 12.4(12a) | | | | | | | | 12.4(13) | | | | | | | 12.4 | 12.4(3h) | 12.4(18c) | | | | | | | 12.4(5c) | | | | | | | | 12.4(7e) | | | | | | | | 12.4(8d) | | |--------------+----------------------------------+-----------------| | 12.4JA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4JK | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4JL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4JMA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4JMB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4JMC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4JX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4MD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4MR | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | | 12.4(15)SW2; | | 12.4SW | 12.4(11)SW1 | Available on | | | | 28-SEP-08 | |--------------+----------------------------------+-----------------| | | 12.4(11)T2 | | | | | | | | 12.4(15)T | | | | | | | | 12.4(2)T6 | | | 12.4T | | 12.4(15)T7 | | | 12.4(4)T8 | | | | | | | | 12.4(6)T7 | | | | | | | | 12.4(9)T3 | | |--------------+----------------------------------+-----------------| | 12.4XA | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.4XB | 12.4(2)XB6 | 12.4(2)XB10 | |--------------+----------------------------------+-----------------| | 12.4XC | 12.4(4)XC7 | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | | | 12.4(4)XD11; | | 12.4XD | 12.4(4)XD7 | Available on | | | | 26-SEP-08 | |--------------+----------------------------------+-----------------| | 12.4XE | 12.4(6)XE3 | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.4XF | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XG | 12.4(9)XG2 | 12.4(9)XG3 | |--------------+----------------------------------+-----------------| | 12.4XJ | 12.4(11)XJ2 | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.4XK | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.4XL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XM | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XN | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XP | Vulnerable; contact TAC | | |--------------+----------------------------------+-----------------| | 12.4XQ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XR | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XT | 12.4(6)XT1 | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.4XV | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XW | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XZ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== Customers running versions of Cisco IOS that support filtering of extended communities can prevent the corruption of the route target (RT) by applying a BGP route-map that removes RT entries on inbound BGP sessions. The following configuration example applied in the ipv4 address family of a PE device removes extended communities from the CE router: router bgp address-family ipv4 vrf one neighbor remote-as neighbor activate neighbor route-map FILTER in exit-address-family ! ip extcommunity-list 100 permit _RT.*_ ! ! route-map FILTER permit 10 set extcomm-list 100 delete ! The following configuration example applied in the ipv6 address family of a PE device removes extended communities from the CE router: router bgp address-family ipv6 vrf one neighbor remote-as neighbor activate neighbor route-map FILTER in exit-address-family ! ip extcommunity-list 100 permit _RT.*_ ! ! route-map FILTER permit 10 set extcomm-list 100 delete ! Note: The capability of filtering extended communities is only available in certain 12.0S and 12.2S based Cisco IOS releases. BGP session between the PE and the CE needs to cleared to make this configuration change effective. 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/products/prod_warranties_item09186a008088e31f.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/warp/public/687/Directory/DirTAC.shtml 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. This vulnerability was reported to Cisco by a customer. This vulnerability cannot be deterministically triggered by an attacker. 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-20080924-vpn.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 | 2008-Sep-24 | 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----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLeoACgkQ86n/Gc8U/uCNwQCdEOd3v5A+paECb9s2gMBUr0JH DEwAnRtvu3aQrECRin/QmElp7oudHZJX =EVLU -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 11:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: [c-nsp] Cisco Security Advisory: Cisco Unified Communications Manager Session Initiation Protocol Denial of Service Vulnerabilities Message-ID: <200809241750.cucm@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco Unified Communications Manager Session Initiation Protocol Denial of Service Vulnerabilities Advisory ID: cisco-sa-20080924-cucm http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco Unified Communications Manager, formerly Cisco Unified CallManager, contains two denial of service (DoS) vulnerabilities in the Session Initiation Protocol (SIP) service. An exploit of these vulnerabilities may cause an interruption in voice services. Cisco will release free software updates that address these vulnerabilities and this advisory will be updated as fixed software becomes available. There are no workarounds for these vulnerabilities. Note: Cisco IOS software is also affected by the vulnerabilities described in this advisory. A companion advisory for Cisco IOS software is available at http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml Affected Products ================= The vulnerabilities described in this document apply to the Cisco Unified Communications Manager. Vulnerable Products +------------------ The following Cisco Unified Communications Manager versions are affected: * Cisco Unified CallManager 4.1 versions prior to 4.1.3SR8 * Cisco Unified CallManager 4.2 versions prior to 4.2(3)SR4b * Cisco Unified CallManager 4.3 versions prior to 4.3(2)SR1a * Cisco Unified Communications Manager 5.x versions prior to 5.1 (3d) * Cisco Unified Communications Manager 6.x versions prior to 6.1(2) su1 Administrators of systems running Cisco Unified CallManager version 4.x can determine the software version by navigating to Help > About Cisco Unified CallManager and selecting the Details button via the Cisco Unified Communications Manager Administration interface. Administrators of systems that are running Cisco Unified Communications Manager versions 5.x and 6.x can determine the software version by viewing the main page of the Cisco Unified Communications Manager Administration interface. The software version can also be determined by running the command show version active via the command line interface. In Cisco Unified CallManager version 4.x, the use of SIP as a call signaling protocol is not enabled by default, and for the Cisco Unified CallManager server to start listening for SIP messages on TCP and UDP ports 5060 and 5061 a SIP trunk needs to be configured. In Cisco Unified Communications Manager versions 5.x and later, the use of SIP as a call signaling protocol is enabled by default in Cisco Unified Communications Manager and cannot be disabled. Cisco IOS software is also affected by these vulnerabilities, although they are tracked by different Cisco bug IDs. A companion security advisory for Cisco IOS software is available at http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml Products Confirmed Not Vulnerable +-------------------------------- With the exception of Cisco IOS software, no other Cisco products are currently known to be vulnerable to the issues described in this advisory. Cisco Unified Communications Manager version 7.x is not affected by these vulnerabilities. Cisco Unified CallManager version 4.x is not affected by these vulnerabilities if it does not have any SIP trunks configured. Details ======= Cisco Unified Communications Manager is the call processing component of the Cisco IP Telephony solution that extends enterprise telephony features and functions to packet telephony network devices, such as IP phones, media processing devices, voice-over-IP gateways, and multimedia applications. SIP is a popular signaling protocol that is used to manage voice and video calls across IP networks such as the Internet. SIP is responsible for handling all aspects of call setup and termination. Voice and video are the most popular types of sessions that SIP handles, but the protocol is flexible to accommodate for other applications that require call setup and termination. SIP call signaling can use UDP (port 5060), TCP (port 5060), or TLS (TCP port 5061) as the underlying transport protocol. Two DoS vulnerabilities exist in the SIP implementation of the Cisco Unified Communications Manager. These vulnerabilities can be triggered while processing specific and valid SIP messages and can lead to a reload of the main Cisco Unified Communications Manager process. Version 4.x of Cisco Unified CallManager do not have SIP enabled by default unless a SIP trunk is configured. Versions 5.x and later of the Cisco Unified Communications Manager have SIP is enabled by default and cannot be disabled. The vulnerabilities are being tracked by the following Cisco bug IDs: * CSCsu38644, assigned CVE ID CVE-2008-3800 * CSCsm46064, assigned CVE ID CVE-2008-3801 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 CSCsu38644 - Valid SIP message can cause CCM process to crash CVSS Base Score - 7.1 Access Vector - Network Access Complexity - Medium Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 5.9 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsm46064 - Problem when CUCM sends out SIP message with valid header CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerabilities described in this advisory may result in a reload of the Cisco Unified Communications Manager process, which could result in the interruption of voice 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. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Cisco Unified CallManager version 4.1(3)SR8 contains fixes for all vulnerabilities affecting Cisco Unified CallManager version 4.1 listed in this advisory, and is scheduled to be released in early October 2008. Cisco Unified CallManager version 4.2(3)SR4b contains fixes for all vulnerabilities affecting Cisco Unified Communications Manager version 4.2.x listed in this advisory, and is scheduled to be released in early November 2008. Cisco Unified CallManager version 4.3(2)SR1a contains fixes for all vulnerabilities affecting Cisco Unified Communications Manager version 4.3.x listed in this advisory, and is scheduled to be released in early October 2008. Cisco Unified Communications Manager version 5.1(3d) contains fixes for all vulnerabilities affecting Cisco Unified Communications Manager version 5.x listed in this advisory, and is scheduled to be released in mid October 2008. Cisco Unified Communications Manager version 6.1(2)SU1 contains fixes for all vulnerabilities affecting Cisco Unified Communications Manager version 6.x listed in this advisory, and is scheduled to be released in mid October 2008. Downloading Cisco Unified Communications Manager Software +-------------------------------------------------------- To download Cisco Unified Communications Manager Software go to the Voice Software Downloads section of the Software Center on cisco.com at http://tools.cisco.com/support/downloads/go/Redirect.x?mdfid=278875240 then navigate to IP Telephony > Call Control > Cisco Unified Communications Manager (CallManager) and select the appropriate version of Cisco Unified Communications Manager. Workarounds =========== There are no workarounds for these vulnerabilities. It is possible to mitigate the vulnerabilities by implementing filtering on screening devices. Permit TCP/UDP access to ports 5060 and 5061 from only networks that need SIP access to Cisco Unified Communications Manager servers. If the Cisco Unified Communications Manager does not need to provide SIP services, the ports on which the Cisco Unified Communications Manager listens for SIP messages can be moved to non-standard ports. To change the ports from their default values, log into the Cisco Unified CallManager Administration web interface, go to System > Cisco Unified CM, locate the appropriate Cisco Unified Communications Manager, change the fields SIP Phone Port and SIP Phone Secure Port to a non-standard port, then click Save. SIP Phone Port, by default 5060, refers to the TCP and UDP ports where the Cisco Unified Communications Manager listens for normal SIP messages, and SIP Phone Secure Port, by default 5061, refers to the TCP and UDP ports where the Cisco Unified Communications Manager listens for SIP over TLS messages. For additional information about this procedure, refer to the "Updating a Cisco Unified Communications Manager" section of the "Cisco Unified Communications Manager Administration Guide" at http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/admin/7_0_1/ccmcfg/b02ccm.html#wp1057513. Note: For a change of the SIP ports to take effect, the Cisco CallManager Service needs to be restarted. For information on how to accomplish this, refer to "Restarting the Cisco CallManager Service" at http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/admin/7_0_1/ccmcfg/b03dpi.html#wp1075124 Additional 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-20080924-sip.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/products/prod_warranties_item09186a008088e31f.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/warp/public/687/Directory/DirTAC.shtml 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 internal testing and during handling of customer service requests. Status of this Notice: INTERIM ============================== 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. CISCO EXPECTS TO UPDATE THIS DOCUMENT AS NEW INFORMATION BECOMES AVAILABLE. 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-20080924-cucm.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 | 2008-September-24 | 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----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaR1gACgkQ86n/Gc8U/uCAAQCfW5xFaGdt0C6ubIIW2kVj37Ak znYAn12eZ9BJNa4m6ia6Di1o+CQ4FAr3 =0Yk+ -----END PGP SIGNATURE----- From ross at kallisti.us Wed Sep 24 12:12:11 2008 From: ross at kallisti.us (Ross Vandegrift) Date: Wed, 24 Sep 2008 12:12:11 -0400 Subject: [c-nsp] GVRP implementation In-Reply-To: <4f890e580809231315r720463b8y3c0179679ef5e5d1@mail.gmail.com> References: <4f890e580809231315r720463b8y3c0179679ef5e5d1@mail.gmail.com> Message-ID: <20080924161211.GA21402@kallisti.us> On Tue, Sep 23, 2008 at 09:15:49PM +0100, Mario Spinthiras wrote: > Before planning a small deployment I wanted to know if any of you had made > use of GVRP (via GARP) on production Cisco machines. Do they provide the > same result as does VTP? I have been unable to test it since Cisco doesn't implement GVRP on IOS. If you run CatOS, I've heard it works fine. -- Ross Vandegrift ross at kallisti.us "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 From ross at kallisti.us Wed Sep 24 12:15:38 2008 From: ross at kallisti.us (Ross Vandegrift) Date: Wed, 24 Sep 2008 12:15:38 -0400 Subject: [c-nsp] Performance Of www.cisco.com In-Reply-To: <200809241703.33039.mtinka@globaltransit.net> References: <200809241703.33039.mtinka@globaltransit.net> Message-ID: <20080924161538.GB21402@kallisti.us> On Wed, Sep 24, 2008 at 05:03:27PM +0800, Mark Tinka wrote: > Not sure if it's just me but for the past several months, > I've found the performance (response times) when browsing > www.cisco.com is not all too great. I've found issues with my browser - I use Mozilla Seamonkey, the continuation of the suite version of Mozilla. Interactive tools like Bug Toolkit and the IOS Feature Navigator do not load in Seamonkey. Browsing them with Firefox is a much better experience. It's a bit perplexing, since they are both Gecko based, but hey, it's not enough of a headache for me to really care. -- Ross Vandegrift ross at kallisti.us "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 From RTeller at deltadentalwa.com Wed Sep 24 12:11:44 2008 From: RTeller at deltadentalwa.com (Teller, Robert) Date: Wed, 24 Sep 2008 09:11:44 -0700 Subject: [c-nsp] Configure Cisco Ace using XML In-Reply-To: <509A5E22DDC70B4DA85EA7C06C8FDA8F05E57D1C@ASHEVS011.mcilink.com> References: <06C1E76E03FE9C4B85BFA9C75365D9DA0FC0137C@tiger.deltadentalwa.com> <509A5E22DDC70B4DA85EA7C06C8FDA8F05E57D1C@ASHEVS011.mcilink.com> Message-ID: <06C1E76E03FE9C4B85BFA9C75365D9DA0FC0137D@tiger.deltadentalwa.com> I took a look at those and couldn't make heads or tails of the cisco_ace.dtd file -----Original Message----- From: Ramcharan, Vijay A [mailto:vijay.ramcharan at verizonbusiness.com] Sent: Wednesday, September 24, 2008 6:52 AM To: Teller, Robert; cisco-nsp at puck.nether.net Subject: RE: [c-nsp] Configure Cisco Ace using XML If you have not yet looked at the Admin guide, (http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_servi ces/ace_appliances/vA1_7_/configuration/administration/guide/xml.html), that would be a good place to start. There's at least one example in there. Supposedly the dtd is available off the ACE. The link is in the admin guide as https://ace_ip_address/cisco_ace.dtd or http://ace_ip_address/cisco_ace.dtd. As far as XML samples go, it doesn't appear that there are any out there for public consumption as yet. Vijay Ramcharan -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Teller, Robert Sent: September 23, 2008 20:05 To: cisco-nsp at puck.nether.net Subject: [c-nsp] Configure Cisco Ace using XML I know it was possible to configure Cisco CSS devices by posting an xml file to them. After migrating from the CSS to the ACE module I will need to do the same thing but I am having problems finding example xml files. Anyone have anything that I could use to get started? Robert Teller Washington Dental Service Network Administrator (206) 528-2371 RTeller at DeltaDentalWa.com ######################################################### The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended for the sole use of the individual and entity to whom it is addressed. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. ######################################################### _______________________________________________ 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 spinthiras.mario at gmail.com Wed Sep 24 12:39:03 2008 From: spinthiras.mario at gmail.com (Mario Spinthiras) Date: Wed, 24 Sep 2008 17:39:03 +0100 Subject: [c-nsp] GVRP implementation In-Reply-To: <20080924161211.GA21402@kallisti.us> References: <4f890e580809231315r720463b8y3c0179679ef5e5d1@mail.gmail.com> <20080924161211.GA21402@kallisti.us> Message-ID: <4f890e580809240939w547f74b4h36021832c5e311b3@mail.gmail.com> So if I wanted my VLAN db to be on a server , i.e a nice web interface implemented in an IPAM , are you saying I cant run a software that generates VTP messages for propagation simply because VTP is proprietary? Do all IOS not implement GVRP ? From justin at justinshore.com Wed Sep 24 14:43:18 2008 From: justin at justinshore.com (Justin Shore) Date: Wed, 24 Sep 2008 13:43:18 -0500 Subject: [c-nsp] Performance Of www.cisco.com In-Reply-To: <48DA5ADB.5090107@rollernet.us> References: <200809241703.33039.mtinka@globaltransit.net> <48DA5ADB.5090107@rollernet.us> Message-ID: <48DA8A46.7000003@justinshore.com> Seth Mattinen wrote: > It's been slow for me since this current iteration of the design came > out. I just attributed it to the tradeoff between flashy and functional. > I was stuck on a dialup modem (21k) once during an emergency after my > 877 at home failed and trying to access my TAC case online was horribly > painful to the point of causing extreme rage. > > Download speeds are fine, though. My download speeds are fine too. My biggest gripe is how things keep changing and how fancy the pages are getting. I can understand some bling on the product and marketing pages but the support pages should be downright blah in my opinion. I should be able to load up the support site in lynx if I have to and find what I'm looking for. Today we have to deal with all those damn style sheets, indirect linking through CGIs, flash and javascript crap, having to (re)authenticate at every turn, and timeouts that are way too short (can you say Dynamic Config Tool?). Like I said earlier, give the product and marketing pages the shiny bling and give the support pages the look, feel and function of what a professional Cisco engineer would except and need. After all, we use the command line all day long. We don't need a stinking GUI. Justin From ploopster at gmail.com Wed Sep 24 14:44:43 2008 From: ploopster at gmail.com (Sridhar Ayengar) Date: Wed, 24 Sep 2008 14:44:43 -0400 Subject: [c-nsp] Performance Of www.cisco.com In-Reply-To: <20080924161538.GB21402@kallisti.us> References: <200809241703.33039.mtinka@globaltransit.net> <20080924161538.GB21402@kallisti.us> Message-ID: <48DA8A9B.8010605@gmail.com> Ross Vandegrift wrote: > On Wed, Sep 24, 2008 at 05:03:27PM +0800, Mark Tinka wrote: >> Not sure if it's just me but for the past several months, >> I've found the performance (response times) when browsing >> www.cisco.com is not all too great. > > I've found issues with my browser - I use Mozilla Seamonkey, the > continuation of the suite version of Mozilla. Interactive tools like > Bug Toolkit and the IOS Feature Navigator do not load in Seamonkey. > Browsing them with Firefox is a much better experience. > > It's a bit perplexing, since they are both Gecko based, but hey, it's > not enough of a headache for me to really care. They work fine in SeaMonkey here. Peace... Sridhar From scaner at global-one.by Wed Sep 24 14:03:38 2008 From: scaner at global-one.by (Eugene Vedistchev) Date: Wed, 24 Sep 2008 21:03:38 +0300 Subject: [c-nsp] GVRP implementation In-Reply-To: <20080924161211.GA21402@kallisti.us> References: <4f890e580809231315r720463b8y3c0179679ef5e5d1@mail.gmail.com> <20080924161211.GA21402@kallisti.us> Message-ID: <48DA80FA.9010303@global-one.by> http://www.cisco.com/en/US/docs/ios/12_2sr/12_2srb/feature/guide/srbcgvrp.html Eugene. Ross Vandegrift wrote: > On Tue, Sep 23, 2008 at 09:15:49PM +0100, Mario Spinthiras wrote: > >> Before planning a small deployment I wanted to know if any of you had made >> use of GVRP (via GARP) on production Cisco machines. Do they provide the >> same result as does VTP? >> > > I have been unable to test it since Cisco doesn't implement GVRP on > IOS. > > If you run CatOS, I've heard it works fine. > > From A.L.M.Buxey at lboro.ac.uk Wed Sep 24 13:43:51 2008 From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk) Date: Wed, 24 Sep 2008 18:43:51 +0100 Subject: [c-nsp] securely sending a trunk link In-Reply-To: <200809241750.ubr@psirt.cisco.com> References: <200809241750.ubr@psirt.cisco.com> Message-ID: <20080924174351.GB23567@lboro.ac.uk> hi, just a qucik question to see if theres some simple option. For operational reasons we have to send a trunk link down to a customer location...in this case we are wary (as they may move..with the kit that was at the other end..and someone else will connect to the link and get themselves a nice trunk link with various VLANs etc. we will restrict the VLANs going to the switch (to their service VLAN and the switch management VLAN) but I was wondering if there was an alternative way of delivering their service VLAN (2950t series switch) or of securing the setup a bit more.... a basic MAC ACL for the management VLAN is a given. alan From lists at hojmark.org Wed Sep 24 15:42:47 2008 From: lists at hojmark.org (Asbjorn Hojmark - Lists) Date: Wed, 24 Sep 2008 21:42:47 +0200 Subject: [c-nsp] 12.2(33)SXI In-Reply-To: <9e246b4d0809220719ld6f7b9em34cb0886f4d190fd@mail.gmail.com> References: <9e246b4d0809220719ld6f7b9em34cb0886f4d190fd@mail.gmail.com> Message-ID: <2514097524594E9DBEB516AB48730787@hojmark.net> > * A.* First customer ship is expected in September 2008." I just heard that's been postponed to 'end of October'. -A From mliotta at r337.com Wed Sep 24 16:08:33 2008 From: mliotta at r337.com (Matt Liotta) Date: Wed, 24 Sep 2008 16:08:33 -0400 Subject: [c-nsp] OSM-2OC12 question Message-ID: I am having trouble finding specific information about the GigE ports on the OSM-2OC12 card. Are those regular GigE ports or the GE-WAN ports like one would find on the OSM-4GBIC card? -Matt From lists at hojmark.org Wed Sep 24 16:18:59 2008 From: lists at hojmark.org (Asbjorn Hojmark - Lists) Date: Wed, 24 Sep 2008 22:18:59 +0200 Subject: [c-nsp] Performance Of www.cisco.com In-Reply-To: <200809241703.33039.mtinka@globaltransit.net> References: <200809241703.33039.mtinka@globaltransit.net> Message-ID: > Not sure if it's just me but for the past several months, > I've found the performance (response times) when browsing > www.cisco.com is not all too great. "Not all too great"?! It's been my experience that anything more or less 'static' (like normal web pages or downloads) perform OK, but anything related to applications (Failure Navigator, Conflicturation Tool, Buggy Navigator, (Re)ordering Tool etc) is extremely slow... and buggy. Impressively, the maketing people have managed to make the 'static' part worse too, by filling it with stuff like video data sheets, ads for other products or places on the site, JavaScripts for simple stuff like opening windows (breaking stuff like Ctrl + click) and buttons etc etc. Previously, at least we had www.cisco.com/univercd, but that must have been too useful, 'cause that's being phased out. -A From lists at hojmark.org Wed Sep 24 16:24:14 2008 From: lists at hojmark.org (Asbjorn Hojmark - Lists) Date: Wed, 24 Sep 2008 22:24:14 +0200 Subject: [c-nsp] SRC2? In-Reply-To: <48D025ED.4000600@forthnet.gr> References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <48A2FF3B.5030104@gatlan.nl> <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com><20080916201757.GE14932@rtp-cse-489.cisco.com> <48D025ED.4000600@forthnet.gr> Message-ID: > I believe SRD (plus the new ES cards) are supposed to come > out at that time too... I believe SRD has been delayed for quite some time, and most certainly will *not* ship before 30sep08. -A From sgranger at randfinancial.com Wed Sep 24 16:35:00 2008 From: sgranger at randfinancial.com (Sean Granger) Date: Wed, 24 Sep 2008 15:35:00 -0500 Subject: [c-nsp] Performance Of www.cisco.com Message-ID: Seconded. In fact, it's a common sense thing that since it's not being done, is brilliant. >>> Justin Shore 09/24/08 01:43PM >>> Seth Mattinen wrote: > It's been slow for me since this current iteration of the design came > out. I just attributed it to the tradeoff between flashy and functional. > I was stuck on a dialup modem (21k) once during an emergency after my > 877 at home failed and trying to access my TAC case online was horribly > painful to the point of causing extreme rage. > > Download speeds are fine, though. My download speeds are fine too. My biggest gripe is how things keep changing and how fancy the pages are getting. I can understand some bling on the product and marketing pages but the support pages should be downright blah in my opinion. I should be able to load up the support site in lynx if I have to and find what I'm looking for. Today we have to deal with all those damn style sheets, indirect linking through CGIs, flash and javascript crap, having to (re)authenticate at every turn, and timeouts that are way too short (can you say Dynamic Config Tool?). Like I said earlier, give the product and marketing pages the shiny bling and give the support pages the look, feel and function of what a professional Cisco engineer would except and need. After all, we use the command line all day long. We don't need a stinking GUI. 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 jcdarby at usgs.gov Wed Sep 24 16:43:27 2008 From: jcdarby at usgs.gov (Justin C. Darby) Date: Wed, 24 Sep 2008 15:43:27 -0500 Subject: [c-nsp] Layer 2 security issue In-Reply-To: <006801c91e40$12d3a410$387aec30$%varaillon@cosmoline.com> References: <006801c91e40$12d3a410$387aec30$%varaillon@cosmoline.com> Message-ID: <48DAA66F.1090704@usgs.gov> I don't know if this is possible for you to do or not, but have you considered using static assignments for MAC<->Port mappings (e.g. specify a mac address instead of sticky)? I only use port security on an N7K at the moment, and we had to use static mappings due to an outstanding bug related to due to the port security mac-address sticky not propigating in the event of a sup failover. After doing some reading it seems like it's a good idea to use static assignments anyway, since I've seen a lot of reports of problems similar to yours (generally, there seem to be a lot of bugs in the whole L2 security suite on every platform). Justin Varaillon Jean Christophe wrote: > Hi, > > > > We are using Cisco 3550, 3560 for access and 4500 for the core. > > > > All the ports of the users are port-secure enabled (switchport port-security > mac-address sticky). > > > > We have enough cases where their ports get in err-disable status due to a > wrong MAC address source. > > > > That mac address source is always the same for all cases that is: the mac > address of the default gateway of the users (vlan interfaces on 4500). > > > > This means that the users are sending packets where the MAC address *source* > is the one of their default router. > > > > An up to date antivirus scanning on those PCs did not lead anywhere. > > > > Has anybody seen this recently? > > > > Thank you. > > > > Christophe > > P Please consider your environmental responsibility before printing this > e-mail > > _____ > > > > _______________________________________________ > 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 Wed Sep 24 16:45:32 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 24 Sep 2008 22:45:32 +0200 (CEST) Subject: [c-nsp] OSM-2OC12 question In-Reply-To: References: Message-ID: <20080924.224532.74729369.sthaug@nethelp.no> > I am having trouble finding specific information about the GigE ports > on the OSM-2OC12 card. Are those regular GigE ports or the GE-WAN > ports like one would find on the OSM-4GBIC card? They are GE-WAN ports. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From cchurc05 at harris.com Wed Sep 24 16:44:04 2008 From: cchurc05 at harris.com (Church, Charles) Date: Wed, 24 Sep 2008 15:44:04 -0500 Subject: [c-nsp] securely sending a trunk link In-Reply-To: <20080924174351.GB23567@lboro.ac.uk> References: <200809241750.ubr@psirt.cisco.com> <20080924174351.GB23567@lboro.ac.uk> Message-ID: Depending on what's at the other end, port security might be able to be used. Chuck -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of A.L.M.Buxey at lboro.ac.uk Sent: Wednesday, September 24, 2008 1:44 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] securely sending a trunk link hi, just a qucik question to see if theres some simple option. For operational reasons we have to send a trunk link down to a customer location...in this case we are wary (as they may move..with the kit that was at the other end..and someone else will connect to the link and get themselves a nice trunk link with various VLANs etc. we will restrict the VLANs going to the switch (to their service VLAN and the switch management VLAN) but I was wondering if there was an alternative way of delivering their service VLAN (2950t series switch) or of securing the setup a bit more.... a basic MAC ACL for the management VLAN is a given. alan _______________________________________________ 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 mksmith at adhost.com Wed Sep 24 16:53:23 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 24 Sep 2008 13:53:23 -0700 Subject: [c-nsp] OSM-2OC12 question In-Reply-To: References: Message-ID: <17838240D9A5544AAA5FF95F8D52031604BE2606@ad-exh01.adhost.lan> Hi Matt: > > I am having trouble finding specific information about the GigE ports > on the OSM-2OC12 card. Are those regular GigE ports or the GE-WAN > ports like one would find on the OSM-4GBIC card? > Check out http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_6981.html It looks like the usual suspects are supported (SX,LX,ZX). Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 474 bytes Desc: not available URL: From will at harg.net Wed Sep 24 16:58:57 2008 From: will at harg.net (Will Hargrave) Date: Wed, 24 Sep 2008 21:58:57 +0100 Subject: [c-nsp] securely sending a trunk link In-Reply-To: <20080924174351.GB23567@lboro.ac.uk> References: <200809241750.ubr@psirt.cisco.com> <20080924174351.GB23567@lboro.ac.uk> Message-ID: <48DAAA11.8000004@harg.net> A.L.M.Buxey at lboro.ac.uk wrote: > just a qucik question to see if theres some simple > option. For operational reasons we have to send > a trunk link down to a customer location...in this case > we are wary (as they may move..with the kit that was at > the other end..and someone else will connect to the link > and get themselves a nice trunk link with various > VLANs etc. we will restrict the VLANs going to > the switch (to their service VLAN and the switch management > VLAN) but I was wondering if there was an alternative > way of delivering their service VLAN (2950t series switch) > or of securing the setup a bit more.... a basic > MAC ACL for the management VLAN is a given. You could put port security with action shutdown on the management vlan (assuming it is native/untagged) - if someone plugs in something else the port will be shut. Or similarly, 802.1x, although i'm not sure if you can send multiple vlans with that on 2950s. From psirt at cisco.com Wed Sep 24 11:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: [c-nsp] Cisco Security Advisory: Multiple Multicast Vulnerabilities in Cisco IOS Software Message-ID: <200809241750.multicast@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Multiple Multicast Vulnerabilities in Cisco IOS Software Advisory ID: cisco-sa-20080924-multicast http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Two crafted Protocol Independent Multicast (PIM) packet vulnerabilities exist in Cisco IOS software that may lead to a denial of service (DoS) condition. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate these vulnerabilities are available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= Vulnerable Products +------------------ Devices that are running Cisco IOS Software and configured for PIM have a vulnerability related to a specially crafted PIM packet. In addition, Cisco 12000 Series (GSR) routers running Cisco IOS Software have a second vulnerability related to a crafted PIM packet. The show running-config | include ip pim command can be issued to verify that a Cisco IOS device is configured for PIM. In the following example, the Cisco IOS router is configured for PIM sparse-dense mode. Router#show running-config | include ip pim ip pim sparse-dense-mode Note that available PIM modes on a Cisco IOS device are dense mode, sparse mode, or sparse-dense mode. A device that is configured for any of these modes is affected by these vulnerabilities. The mode determines how the device populates its multicast routing table and how multicast packets are forwarded. PIM must be enabled in one of these modes for an interface to perform IP multicast routing. More information on the configuration of each mode is in the "Details" section. Additionally, To display information about interfaces configured for Protocol Independent Multicast (PIM), use the show ip pim interface command in user EXEC or privileged EXEC mode, as shown in the following example: Router# show ip pim interface Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior 10.1.0.1 GigabitEthernet0/0 v2/SD 0 30 1 10.1.0.1 10.6.0.1 GigabitEthernet0/1 v2/SD 1 30 1 10.6.0.2 In order to determine the software that runs on a Cisco IOS product, log in to the device and issue the show version command to display the system banner. Cisco IOS software identifies itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name displays between parentheses, followed by "Version" and the Cisco IOS release name. Other Cisco devices do not have the show version command or give different output. The following example shows output from a device that runs an IOS image: router>show version Cisco IOS Software, 7200 Software (C7200-ADVSECURITYK9-M), Version 12.4(6)T2, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2006 by Cisco Systems, Inc. Compiled Tue 16-May-06 16:09 by kellythw Products Confirmed Not Vulnerable +-------------------------------- Cisco IOS devices that are not configured for PIM are not vulnerable. Cisco IOS XR Software is not affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details ======= Two crafted Protocol Independent Multicast (PIM) packet vulnerabilities exist in Cisco IOS Software that may lead to a denial of service (DoS) condition. Devices that run Cisco IOS Software and are configured for PIM are affected by the first vulnerability. Only Cisco 12000 Series (GSR) routers that are configured for PIM are affected by the second vulnerability. Available PIM modes on a Cisco IOS device are dense mode, sparse mode, or sparse-dense mode. The mode determines how the device populates its multicast routing table and how multicast packets are forwarded. PIM must be enabled in one of these modes for an interface to perform IP multicast routing. Note: There is no default mode setting. By default, multicast routing is disabled on an interface. To configure PIM on an interface to be in dense mode, use the following command in interface configuration mode: Router(config-if)# ip pim dense-mode To configure PIM on an interface to be in sparse mode, use the following command in interface configuration mode: Router(config-if)# ip pim sparse-mode To configure PIM on an interface to be in sparse-dense mode, use the following command in interface configuration mode: Router(config-if)# ip pim sparse-dense-mode These vulnerabilities are documented in the following Cisco Bug IDs: * CSCsd95616 - Crafted PIM packets may cause an IOS device to reload * CSCsl34355 - GSR may crash with malformed PIM packets These vulnerabilities have been assigned the Common Vulnerabilities and Exposures (CVE) identifiers CVE-2008-3808 and CVE-2008-3809. 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 CSCsd95616 - Crafted PIM packets may cause an IOS device to reload 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 CSCsl34355 - GSR may crash with malformed PIM packets 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 may cause a reload of the affected device. Repeated exploitation could result in a sustained denial of service (DoS) condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0 | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | Releases prior to 12.0(8)DA3 are | 12.2(12)DA13 | | | vulnerable, release 12.0(8)DA3 and | | | 12.0DA | later are not vulnerable; first fixed | 12.4(15)T7 | | | in 12.2DA | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0DB | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0DC | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | 12.0(32)S8 | 12.0(32)S11 | | 12.0S | | | | | 12.0(33)S | 12.0(33)S1 | |------------+---------------------------------------+--------------| | | | 12.0(32)S11 | | 12.0SC | Vulnerable; first fixed in 12.0S | | | | | 12.0(33)S1 | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0SL | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0SP | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.0(32)S11 | | 12.0ST | Vulnerable; first fixed in 12.0S | | | | | 12.0(33)S1 | |------------+---------------------------------------+--------------| | | | 12.0(32)S11 | | 12.0SX | Vulnerable; first fixed in 12.0S | | | | | 12.0(33)S1 | |------------+---------------------------------------+--------------| | | | 12.0(32)SY7; | | 12.0SY | 12.0(32)SY5 | Available on | | | | 29-SEP-08 | |------------+---------------------------------------+--------------| | | | 12.0(32)S11 | | 12.0SZ | 12.0(30)SZ4 | | | | | 12.0(33)S1 | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0T | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.0W | Vulnerable; first fixed in 12.2 | 12.0(3c)W5 | | | | (8) | |------------+---------------------------------------+--------------| | | Releases prior to 12.0(5)WC10 are | 12.4(15)T7 | | 12.0WC | vulnerable, release 12.0(5)WC10 and | | | | later are not vulnerable; first fixed | 12.4(18c) | | | in 12.2 | | |------------+---------------------------------------+--------------| | 12.0WT | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XA | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XB | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | Releases prior to 12.0(2)XC2 are | 12.4(15)T7 | | 12.0XC | vulnerable, release 12.0(2)XC2 and | | | | later are not vulnerable; first fixed | 12.4(18c) | | | in 12.2 | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XD | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XE | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.0XF | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XG | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XH | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | Releases prior to 12.0(4)XI2 are | 12.4(15)T7 | | 12.0XI | vulnerable, release 12.0(4)XI2 and | | | | later are not vulnerable; first fixed | 12.4(18c) | | | in 12.2 | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XJ | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XK | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XL | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XM | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XN | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XQ | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XR | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.0XS | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XT | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XV | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1 | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1AA | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.1AX | Vulnerable; first fixed in 12.2EY | 12.2(46)SE | |------------+---------------------------------------+--------------| | | Releases prior to 12.1(22)AY1 are | 12.1(22)EA12 | | 12.1AY | vulnerable, release 12.1(22)AY1 and | | | | later are not vulnerable; first fixed | 12.2(46)SE | | | in 12.1EA | | |------------+---------------------------------------+--------------| | 12.1AZ | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1CX | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(12)DA13 | | | | | | 12.1DA | Vulnerable; first fixed in 12.2DA | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1DB | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1DC | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.1E | 12.1(27b)E2 | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | 12.1EA | 12.1(22)EA10 | 12.1(22)EA12 | |------------+---------------------------------------+--------------| | 12.1EB | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.2(33)SCA1 | | 12.1EC | Vulnerable; first fixed in 12.3BC | | | | | 12.3(23)BC4 | |------------+---------------------------------------+--------------| | 12.1EO | Vulnerable; first fixed in 12.2SV | | |------------+---------------------------------------+--------------| | | | 12.2(25) | | | | EWA14 | | 12.1EU | Vulnerable; first fixed in 12.2EWA | | | | | 12.2(31)SGA8 | | | | | | | | 12.2(46)SG1 | |------------+---------------------------------------+--------------| | 12.1EV | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.2(25) | | | | EWA14 | | | | | | | | 12.2(31)SGA8 | | 12.1EW | Vulnerable; first fixed in 12.2 | | | | | 12.2(46)SG1 | | | | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1EX | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.1EY | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.2(18) | | | | SXF15 | | 12.1EZ | Vulnerable; first fixed in 12.1E | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1GA | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1GB | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1T | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XA | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XB | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XC | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XD | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XE | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XF | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XG | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XH | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XI | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XJ | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XL | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XM | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XP | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XQ | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XR | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XS | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XT | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XU | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XV | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XW | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XX | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XY | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XZ | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1YA | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1YB | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1YC | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1YD | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | Releases prior to 12.1(5)YE6 are | 12.4(15)T7 | | 12.1YE | vulnerable, release 12.1(5)YE6 and | | | | later are not vulnerable; first fixed | 12.4(18c) | | | in 12.2 | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1YF | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1YH | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.1YI | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.1YJ | Not Vulnerable | | |------------+---------------------------------------+--------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | | 12.2(26c) | | | | | | | | 12.2(27c) | | | | | 12.4(15)T7 | | 12.2 | 12.2(28d) | | | | | 12.4(18c) | | | 12.2(29b) | | | | | | | | 12.2(46) | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2B | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SCA1 | | | | | | | | 12.3(23)BC4 | | 12.2BC | Vulnerable; first fixed in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2BW | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | | | Available on | | | | 26-SEP-08 | | 12.2BX | Vulnerable; first fixed in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2BY | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2BZ | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SCA1 | | | | | | | | 12.3(23)BC4 | | 12.2CX | Vulnerable; first fixed in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SCA1 | | | | | | | | 12.3(23)BC4 | | 12.2CY | Vulnerable; first fixed in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | 12.2CZ | Vulnerable; first fixed in 12.2S | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | | 12.2(10)DA9 | | | 12.2DA | | 12.2(12)DA13 | | | 12.2(12)DA13 | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2DD | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2DX | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(25) | | | | EWA14 | | 12.2EW | Vulnerable; first fixed in 12.2EWA | | | | | 12.2(31)SGA8 | | | | | | | | 12.2(46)SG1 | |------------+---------------------------------------+--------------| | | 12.2(25)EWA10 | 12.2(25) | | 12.2EWA | | EWA14 | | | 12.2(25)EWA11 | | |------------+---------------------------------------+--------------| | 12.2EX | 12.2(37)EX | 12.2(35)EX2 | |------------+---------------------------------------+--------------| | 12.2EY | 12.2(37)EY | | |------------+---------------------------------------+--------------| | 12.2EZ | Vulnerable; first fixed in 12.2SEE | 12.2(46)SE | |------------+---------------------------------------+--------------| | 12.2FX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2FY | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2FZ | Vulnerable; first fixed in 12.2SE | 12.2(46)SE | |------------+---------------------------------------+--------------| | 12.2IRB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2IXA | Vulnerable; migrate to any release in | 12.2(18)IXG | | | 12.2IXE | | |------------+---------------------------------------+--------------| | 12.2IXB | Vulnerable; migrate to any release in | 12.2(18)IXG | | | 12.2IXE | | |------------+---------------------------------------+--------------| | 12.2IXC | Vulnerable; migrate to any release in | 12.2(18)IXG | | | 12.2IXE | | |------------+---------------------------------------+--------------| | 12.2IXD | Vulnerable; migrate to any release in | 12.2(18)IXG | | | 12.2IXE | | |------------+---------------------------------------+--------------| | 12.2IXE | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2IXF | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2IXG | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2JA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2JK | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.2(25)SW12 | | | | | | 12.2MB | Vulnerable; first fixed in 12.2SW | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2MC | 12.2(15)MC2i | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | 12.2(14)S18 | | | | | | | | 12.2(18)S13 | 12.2(33)SB2; | | 12.2S | | Available on | | | 12.2(20)S13 | 26-SEP-08 | | | | | | | 12.2(25)S13 | | |------------+---------------------------------------+--------------| | | 12.2(28)SB7 | | | | | 12.2(33)SB2; | | 12.2SB | 12.2(31)SB5 | Available on | | | | 26-SEP-08 | | | 12.2(33)SB | | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | 12.2SBC | Vulnerable; first fixed in 12.2SB | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | 12.2SCA | Not Vulnerable | | |------------+---------------------------------------+--------------| | | 12.2(35)SE4 | | | 12.2SE | | 12.2(46)SE | | | 12.2(37)SE | | |------------+---------------------------------------+--------------| | 12.2SEA | Vulnerable; first fixed in 12.2SEE | 12.2(46)SE | |------------+---------------------------------------+--------------| | 12.2SEB | Vulnerable; first fixed in 12.2SEE | 12.2(46)SE | |------------+---------------------------------------+--------------| | 12.2SEC | Vulnerable; first fixed in 12.2SEE | 12.2(46)SE | |------------+---------------------------------------+--------------| | 12.2SED | Vulnerable; first fixed in 12.2SEE | 12.2(46)SE | |------------+---------------------------------------+--------------| | 12.2SEE | 12.2(25)SEE4 | 12.2(46)SE | |------------+---------------------------------------+--------------| | 12.2SEF | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SEG | 12.2(25)SEG3 | 12.2(25)SEG6 | |------------+---------------------------------------+--------------| | | 12.2(25)SG3 | | | | | | | 12.2SG | 12.2(31)SG3 | 12.2(46)SG1 | | | | | | | 12.2(37)SG | | |------------+---------------------------------------+--------------| | 12.2SGA | 12.2(31)SGA2 | 12.2(31)SGA8 | |------------+---------------------------------------+--------------| | 12.2SL | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SM | 12.2(29)SM3 | 12.2(29)SM4 | |------------+---------------------------------------+--------------| | 12.2SO | Vulnerable; first fixed in 12.2SV | | |------------+---------------------------------------+--------------| | | | 12.2(33)SRB4 | | 12.2SRA | 12.2(33)SRA4 | | | | | 12.2(33)SRC2 | |------------+---------------------------------------+--------------| | 12.2SRB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SRC | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2SU | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2SV | 12.2(29b)SV1 | | |------------+---------------------------------------+--------------| | 12.2SVA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SVC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SVD | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SW | 12.2(25)SW12 | 12.2(25)SW12 | |------------+---------------------------------------+--------------| | 12.2SX | Vulnerable; first fixed in 12.2SXF | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | 12.2SXA | Vulnerable; first fixed in 12.2SXF | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | 12.2SXB | Vulnerable; first fixed in 12.2SXF | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | 12.2SXD | Vulnerable; first fixed in 12.2SXF | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | 12.2SXE | Vulnerable; first fixed in 12.2SXF | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | 12.2SXF | 12.2(18)SXF9 | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | | Not Vulnerable | | | 12.2SXH | | | | | http://www.cisco.com/go/pn | | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | 12.2SY | Vulnerable; first fixed in 12.2S | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | 12.2SZ | Vulnerable; first fixed in 12.2S | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2T | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2TPC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XA | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XB | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XC | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XD | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XE | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SCA1 | | | | | | | | 12.3(23)BC4 | | 12.2XF | Vulnerable; first fixed in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | Releases prior to 12.2(2)XG1 are | 12.4(15)T7 | | 12.2XG | vulnerable, release 12.2(2)XG1 and | | | | later are not vulnerable; first fixed | 12.4(18c) | | | in 12.3 | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XH | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XI | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XJ | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XK | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XL | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XM | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | | | Available on | | | | 26-SEP-08 | | 12.2XN | 12.2(33)XN1 | | | | | 12.2(33)SRC2 | | | | | | | | 12.2(33)XNA2 | |------------+---------------------------------------+--------------| | 12.2XNA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XNB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XO | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XQ | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | Releases prior to 12.2(15)XR are | 12.3(8)JEA3 | | | vulnerable, release 12.2(15)XR and | | | 12.2XR | later are not vulnerable; first fixed | 12.4(15)T7 | | | in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XS | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XT | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XU | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XV | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XW | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2YA | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2YB | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YD | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YE | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YF | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YG | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YH | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YJ | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YK | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YL | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2YM | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2YN | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YO | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2YP | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2YQ | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YR | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YS | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YT | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YU | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YV | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YW | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YX | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YY | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YZ | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZA | Vulnerable; first fixed in 12.2SXF | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | 12.2ZB | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZD | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2ZE | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2ZF | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2ZG | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2ZH | 12.2(13)ZH9 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2ZJ | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZL | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZP | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZU | Vulnerable; migrate to any release in | 12.2(33)SXH3 | | | 12.2SXH | | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | 12.2ZX | Vulnerable; first fixed in 12.2SB | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | 12.2ZY | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2ZYA | Not Vulnerable | | |------------+---------------------------------------+--------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | | 12.3(17c) | | | | | | | | 12.3(18a) | | | | | 12.4(15)T7 | | 12.3 | 12.3(19a) | | | | | 12.4(18c) | | | 12.3(20a) | | | | | | | | 12.3(21) | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3B | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | 12.3(17b)BC6 | | | 12.3BC | | 12.3(23)BC4 | | | 12.3(21)BC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3BW | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3EU | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3JA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3JEA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3JEB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3JEC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3JK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3JL | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3JX | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3T | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3TPC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.3VA | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XA | 12.3(2)XA7 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3XB | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XC | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XD | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XE | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3XF | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XG | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | 12.3XI | 12.3(7)XI10 | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | | | 12.3(14)YX13 | | 12.3XJ | Vulnerable; first fixed in 12.3YX | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XK | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XL | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XQ | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XR | 12.3(7)XR7 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XS | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3XU | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.3(14)YX13 | | 12.3XW | Vulnerable; first fixed in 12.3YX | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XX | 12.3(8)XX2d | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XY | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XZ | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3YA | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3YD | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.3(14)YX13 | | 12.3YF | Vulnerable; first fixed in 12.3YX | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YG | 12.3(8)YG6 | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YH | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YI | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YJ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YK | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.3(14) | | 12.3YM | 12.3(14)YM10 | YM13; | | | | Available on | | | | 30-SEP-08 | |------------+---------------------------------------+--------------| | 12.3YQ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YS | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YT | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(2)XB10 | | | | | | 12.3YU | Vulnerable; first fixed in 12.4XB | 12.4(9)XG3 | | | | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YX | 12.3(14)YX8 | 12.3(14)YX13 | |------------+---------------------------------------+--------------| | 12.3YZ | 12.3(11)YZ3 | | |------------+---------------------------------------+--------------| | 12.3ZA | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | | 12.4(10c) | | | | | | | | 12.4(12) | | | | | | | | 12.4(3h) | | | 12.4 | | 12.4(18c) | | | 12.4(5c) | | | | | | | | 12.4(7e) | | | | | | | | 12.4(8d) | | |------------+---------------------------------------+--------------| | 12.4JA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JL | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JMA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JMB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JMC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4MD | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4MR | 12.4(11)MR | 12.4(19)MR | |------------+---------------------------------------+--------------| | 12.4SW | Not Vulnerable | | |------------+---------------------------------------+--------------| | | 12.4(11)T | | | | | | | | 12.4(2)T6 | | | | | | | 12.4T | 12.4(4)T8 | 12.4(15)T7 | | | | | | | 12.4(6)T7 | | | | | | | | 12.4(9)T3 | | |------------+---------------------------------------+--------------| | 12.4XA | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.4XB | 12.4(2)XB6 | 12.4(2)XB10 | |------------+---------------------------------------+--------------| | 12.4XC | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(4)XD11; | | 12.4XD | 12.4(4)XD8 | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | 12.4XE | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.4XF | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XG | 12.4(9)XG2 | 12.4(9)XG3 | |------------+---------------------------------------+--------------| | 12.4XJ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XL | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XM | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XN | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XP | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.4XQ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XR | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XT | 12.4(6)XT2 | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.4XV | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XW | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XY | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XZ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== Specifying trusted PIM neighbors is a workaround for both vulnerabilities. A PIM router must receive PIM Hellos to establish PIM neighborship. PIM neighborship is also the basis for designated router (DR) election, DR failover, and accepting/sending PIM Join/ Prune/Assert messages. To specify trusted PIM neighbors, use the ip pim neighbor-filter command, as shown in the following example: Router(config)#access-list 1 permit host 10.10.10.123 !-- An access control list is created to allow a trusted PIM neighbor !-- in this example the neighbor is 10.10.10.123 ! Router(config)#interface fastEthernet 0/0 Router(config-if)#ip pim neighbor-filter 1 !-- The PIM neighbor filter is then applied to the respective interface(s) The ip pim neighbor-filter command filters PIM packets from untrusted devices including Hellos, Join/Prune, and BSR packets. Note: The vulnerabilities described in this document can be exploited by spoofed IP packets if the attacker knows the IP address of the trusted PIM neighbors listed in the ip pim neighbor-filter implementation. To protect infrastructure devices and minimize the risk, impact, and effectiveness of direct infrastructure attacks, administrators are advised to deploy ACLs to perform policy enforcement of traffic sent to core infrastructure equipment. PIM is IP protocol 103. As an additional workaround, administrators can explicitly permit only authorized PIM (IP protocol 103) traffic sent to infrastructure devices in accordance with existing security policies and configurations. An ACL can be deployed as shown in the following example: ip access-list extended Infrastructure-ACL-Policy ! !-- When applicable, include explicit permit statements for trusted !-- sources that require access on the vulnerable protocol !-- PIM routers need to communicate with the rendezvous point (RP). !-- In this example, 192.168.100.1 is the IP address of the !-- rendezvous point, which is a trusted host that requires access !-- to and from the affected PIM devices. ! permit pim host 192.168.100.1 192.168.60.0 0.0.0.255 permit pim 192.168.60.0 0.0.0.255 host 192.168.100.1 ! !-- Permit PIM segment traffic, packets have destination of: !-- 224.0.0.13 (PIMv2) !-- 224.0.0.2 (Required only by legacy PIMv1) ! permit pim 192.168.60.0 0.0.0.255 host 224.0.0.13 permit pim 192.168.60.0 0.0.0.255 host 224.0.0.2 ! !-- The following vulnerability-specific access control entries !-- (ACEs) can aid in identification of attacks ! deny pim any 192.168.60.0 0.0.0.255 ! !-- Explicit deny ACE for traffic sent to addresses configured within !-- the infrastructure address space ! deny ip any 192.168.60.0 0.0.0.255 ! !-- Permit/deny all other Layer 3 and Layer 4 traffic in accordance !-- with existing security policies and configurations ! !-- Apply iACL to interfaces in the ingress direction ! interface GigabitEthernet0/0 ip access-group Infrastructure-ACL-Policy in 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/products/prod_warranties_item09186a008088e31f.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/warp/public/687/Directory/DirTAC.shtml 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 vulnerabilities described in this advisory. These vulnerabilities were found during internal testing. 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-20080924-multicast.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 | 2008-September-24 | 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----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLdEACgkQ86n/Gc8U/uBLYQCfbFNaZROaq5OZX5KzZAVwv0gr oBwAoJeb3PdxAWcVg3sBKladJgqbb1oy =f4p/ -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 11:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: [c-nsp] Cisco Security Advisory: Multiple Cisco IOS Session Initiation Protocol Denial of Service Vulnerabilities Message-ID: <200809241750.sip@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Multiple Cisco IOS Session Initiation Protocol Denial of Service Vulnerabilities Advisory ID: cisco-sa-20080924-sip http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Multiple vulnerabilities exist in the Session Initiation Protocol (SIP) implementation in Cisco IOS that can be exploited remotely to trigger a memory leak or to cause a reload of the IOS device. Cisco has released free software updates that address these vulnerabilities. Fixed Cisco IOS software listed in the Software Versions and Fixes section contains fixes for all vulnerabilities addressed in this advisory. There are no workarounds available to mitigate the effects of any of the vulnerabilities apart from disabling the protocol or feature itself, if administrators do not require the Cisco IOS device to provide voice over IP services. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= These vulnerabilities only affect devices running Cisco IOS that have SIP voice services enabled. Vulnerable Products +------------------ Cisco devices running affected Cisco IOS versions and that may process SIP messages are affected. The only requirement for these vulnerabilities is that the Cisco IOS device processes SIP messages as part of configured voice over IP (VoIP) functionality (this does not apply to processing of SIP messages as part of the NAT and firewall feature sets.) Recent versions of Cisco IOS do not process SIP messages by default, but creating a "dial peer" via the command dial-peer voice will start the SIP processes and cause Cisco IOS to start processing SIP messages. An example of an affected configuration is as follows: dial-peer voice voip ... ! Note that older versions of Cisco IOS were affected by a bug that caused Cisco IOS to process SIP messages even without being configured for SIP operation. Please refer to http://www.cisco.com/warp/public/707/cisco-sa-20070131-sip.shtml for additional information on Cisco bug ID CSCsb25337. In addition to inspecting the Cisco IOS device configuration for a dial-peer command that causes the device to process SIP messages, administrators can also use some show commands to determine if the Cisco IOS device is running processes that handle SIP messages, or if the device is listening on the SIP ports. The command show processes | include SIP can be used to determine whether Cisco IOS is running the processes that handle SIP messages. In the following example, the presence of the processes CCSIP_UDP_SOCKET and CCSIP_TCP_SOCKET indicates that the Cisco IOS device is processing SIP messages: Router#show processes | include SIP 147 Mwe 40F46DF4 12 2 600023468/24000 0 CCSIP_SPI_CONTRO 148 Mwe 40F21244 0 1 0 5524/6000 0 CCSIP_DNS 149 Mwe 40F48254 4 1 400023108/24000 0 CCSIP_UDP_SOCKET 150 Mwe 40F48034 4 1 400023388/24000 0 CCSIP_TCP_SOCKET Different versions of Cisco IOS have different ways of verifying whether the Cisco IOS device is listening for SIP messages. The show ip sockets, show udp, show tcp brief all, and show control-plane host open-ports commands can be used to determine this, although not all of these commands work on all IOS releases. Since it is not practical in this document to provide a list of commands corresponding to the various releases, users should try the aforementioned commands to determine which ones work for their device. The following is one example of one command that shows a router listening on port 5060 (the SIP port): router#show control-plane host open-ports Active internet connections (servers and established) Prot Local Address Foreign Address Service State tcp *:5060 *:0 SIP LISTEN udp *:5060 *:0 SIP LISTEN In order to determine the software that runs on a Cisco IOS product, log in to the device and issue the show version command to display the system banner. Cisco IOS software identifies itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name displays between parentheses, followed by "Version" and the Cisco IOS release name. Other Cisco devices do not have the show version command or give different output. The following example shows output from a device that runs an IOS image: router>show version Cisco IOS Software, 7200 Software (C7200-ADVSECURITYK9-M), Version 12.4(6)T2, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2006 by Cisco Systems, Inc. Compiled Tue 16-May-06 16:09 by kellythw Additional information on the Cisco IOS release naming conventions can be found on the document entitled "White Paper: Cisco IOS Reference Guide", which is available at http://www.cisco.com/warp/public/620/1.html Cisco Unified Communications Manager is also affected by some of these vulnerabilities, although they are tracked by different Cisco bug IDs. A companion security advisory for Cisco Unified Communications Manager is available at http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml Products Confirmed Not Vulnerable +-------------------------------- The SIP Application Layer Gateway (ALG), which is used by the IOS Network Address Translation (NAT) and firewall features of Cisco IOS, is not affected by these vulnerabilities. Cisco devices that are running Cisco IOS XR are not affected. With the exception of the Cisco Unified Communications Manager, no other Cisco products are currently known to be vulnerable to the issues described in this advisory. Details ======= SIP is a popular signaling protocol used to manage voice and video calls across IP networks such as the Internet. SIP is responsible for handling all aspects of call setup and termination. Voice and video are the most popular types of sessions that SIP handles, but the protocol is flexible to accommodate for other applications that require call setup and termination. SIP call signaling can use UDP (port 5060), TCP (port 5060), or TLS (TCP port 5061) as the underlying transport protocol. Multiple denial of service vulnerabilities exist in the SIP implementation in Cisco IOS. In all cases vulnerabilities can be triggered by processing valid SIP messages. Memory Leak Vulnerability +------------------------ CSCse56800 causes a memory leak in affected devices. The memory leak is caused by the processing of a specific type of valid SIP messages and may eventually disrupt the availability of all voice services, even if the Cisco IOS device is still running. This vulnerability has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-3799. Device Reload Vulnerabilities +---------------------------- The following vulnerabilities can lead to a reload of the Cisco IOS device while processing some specific and valid SIP messages: * CSCsg91306, assigned CVE ID CVE-2008-3800 * CSCsl62609, assigned CVE ID CVE-2008-3801 * CSCsk42759, assigned CVE ID CVE-2008-3802 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 CSCse56800 - SIP-3-BADPAIR register timer expiry causes slow memory leak 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 CSCsg91306 - processor pool memory corruption in CCSIP_SPI_CONTROL 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 CSCsk42759 - Voice Gateway reloads on receiving a valid SIP packet 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 CSCsl62609 - Router crash due to presence of valid SIP header CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerabilities described in this document may result in a reload of the device. The issue could be repeatedly exploited to result in an extended Denial Of Service (DoS) condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | 12.2 | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2B | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2BC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2BW | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | | | Available on | | | | 26-SEP-08 | | 12.2BX | Vulnerable; first fixed in 12.4 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2BY | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2BZ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2CX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2CY | Not Vulnerable | | |------------+---------------------------------------+--------------| | | Vulnerable; migrate to any release in | 12.2(33)SB2; | | 12.2CZ | 12.2S | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | 12.2DA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2DD | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2DX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2EW | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2EWA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2EX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2EY | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2EZ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2FX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2FY | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2FZ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2IRB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2IXA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2IXB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2IXC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2IXD | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2IXE | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2IXF | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2IXG | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2JA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2JK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2MB | Not Vulnerable | | |------------+---------------------------------------+--------------| | | Releases prior to 12.2(15)MC2c are | 12.4(15)T7 | | 12.2MC | vulnerable, release 12.2(15)MC2c and | | | | later are not vulnerable; first fixed | 12.4(18c) | | | in 12.4 | | |------------+---------------------------------------+--------------| | 12.2S | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SBC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SCA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SE | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SEA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SEB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SEC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SED | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SEE | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SEF | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SEG | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SG | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SGA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SL | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SM | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SO | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SRA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SRB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SRC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SU | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SV | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SVA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SVC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SVD | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SW | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SXA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SXB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SXD | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SXE | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SXF | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SXH | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SY | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SZ | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2T | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2TPC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2XA | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XB | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2XC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XD | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XE | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XF | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XG | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XH | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XI | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XJ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XL | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XM | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2XN | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XNA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XNB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XO | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XQ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XR | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XS | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XT | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XU | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2XV | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XW | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2YA | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2YB | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YD | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YE | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YF | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YG | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YH | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YJ | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YL | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2YM | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2YN | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YO | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YP | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YQ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YR | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YS | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YT | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YU | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | Releases prior to 12.2(11)YV1 are | | | 12.2YV | vulnerable, release 12.2(11)YV1 and | | | | later are not vulnerable; | | |------------+---------------------------------------+--------------| | 12.2YW | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YY | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YZ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2ZA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2ZB | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZD | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2ZE | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2ZF | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2ZG | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2ZH | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2ZJ | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZL | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZP | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZU | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2ZX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2ZY | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2ZYA | Not Vulnerable | | |------------+---------------------------------------+--------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3 | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3B | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3BC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3BW | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3EU | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3JA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3JEA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3JEB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3JEC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3JK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3JL | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3JX | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3T | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3TPC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.3VA | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | Releases prior to 12.3(2)XA7 are | 12.4(15)T7 | | 12.3XA | vulnerable, release 12.3(2)XA7 and | | | | later are not vulnerable; first fixed | 12.4(18c) | | | in 12.4 | | |------------+---------------------------------------+--------------| | 12.3XB | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XC | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XD | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XE | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3XF | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XG | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | Vulnerable; migrate to any release in | 12.2(33)SB2; | | 12.3XI | 12.2SB | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | | | 12.3(14)YX13 | | 12.3XJ | Vulnerable; first fixed in 12.3YX | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XK | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XL | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XQ | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XR | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3XS | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3XU | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.3(14)YX13 | | 12.3XW | Vulnerable; first fixed in 12.3YX | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XX | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XY | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XZ | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3YA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3YD | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.3(14)YX13 | | 12.3YF | Vulnerable; first fixed in 12.3YX | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YG | 12.3(8)YG7; Available on 01-OCT-08 | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YH | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3YI | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3YJ | Not Vulnerable | | |------------+---------------------------------------+--------------| | | Releases prior to 12.3(11)YK3 are | | | 12.3YK | vulnerable, release 12.3(11)YK3 and | 12.4(15)T7 | | | later are not vulnerable; first fixed | | | | in 12.4T | | |------------+---------------------------------------+--------------| | | | 12.3(14) | | 12.3YM | 12.3(14)YM13; Available on 30-SEP-08 | YM13; | | | | Available on | | | | 30-SEP-08 | |------------+---------------------------------------+--------------| | 12.3YQ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YS | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YT | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(2)XB10 | | | | | | 12.3YU | Vulnerable; first fixed in 12.4XB | 12.4(9)XG3 | | | | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YX | 12.3(14)YX12 | 12.3(14)YX13 | |------------+---------------------------------------+--------------| | 12.3YZ | 12.3(11)YZ3 | | |------------+---------------------------------------+--------------| | 12.3ZA | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | | 12.4(13f) | | | | | | | 12.4 | 12.4(17b) | 12.4(18c) | | | | | | | 12.4(18) | | |------------+---------------------------------------+--------------| | 12.4JA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JL | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JMA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JMB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JMC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4MD | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4MR | 12.4(19)MR | 12.4(19)MR | |------------+---------------------------------------+--------------| | 12.4SW | Not Vulnerable | | |------------+---------------------------------------+--------------| | | 12.4(15)T4 | | | | | | | 12.4T | 12.4(20)T | 12.4(15)T7 | | | | | | | 12.4(6)T11 | | |------------+---------------------------------------+--------------| | 12.4XA | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.4XB | 12.4(2)XB10 | 12.4(2)XB10 | |------------+---------------------------------------+--------------| | 12.4XC | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(4)XD11; | | 12.4XD | 12.4(4)XD11; Available on 26-SEP-08 | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | 12.4XE | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.4XF | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XG | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XJ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.4XK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XL | 12.4(15)XL2 | 12.4(15)XL2 | |------------+---------------------------------------+--------------| | 12.4XM | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XN | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XP | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.4XQ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XR | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XT | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.4XV | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.4XW | 12.4(11)XW7 | 12.4(11)XW9 | |------------+---------------------------------------+--------------| | 12.4XY | 12.4(15)XY3 | 12.4(15)XY4 | |------------+---------------------------------------+--------------| | 12.4XZ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== If the affected Cisco IOS device needs to provide voice over IP services and therefore SIP cannot be disabled then none of the listed vulnerabilities have workarounds. Users are advised to apply mitigation techniques to limit exposure to the listed vulnerabilities. Mitigation consists of only allowing legitimate devices to connect to the routers. To increase effectiveness, the mitigation must be coupled with anti-spoofing measures on the network edge. This action is required because SIP can use UDP as the transport protocol. Additional 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-20080924-sip.shtml Disable SIP Listening Ports +-------------------------- For devices that do not require SIP to be enabled, the simplest and most effective workaround is to disable SIP processing on the device. Some versions of Cisco IOS allow administrators to accomplish this with the following commands: sip-ua no transport udp no transport tcp Warning: When applying this workaround to devices processing MGCP or H.323 calls, the device will not allow you to stop SIP processing while active calls are being processed. Under these circumstances, this workaround should be implemented during a maintenance window when active calls can be briefly stopped. It is recommended that after applying this workaround, the show commands discussed in the Vulnerable Products section be used to confirm that the Cisco IOS device is no longer processing SIP messages. Control Plane Policing +--------------------- For devices that need to offer SIP services it is possible to use Control Plane Policing (CoPP) to block SIP traffic to the device from untrusted sources. Cisco IOS software releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP may be configured on a device to protect the management and control planes to minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. The following example can be adapted to your network: !-- The 192.168.1.0/24 network and the 172.16.1.1 host are trusted. !-- Everything else is not trusted. The following access list is used !-- to determine what traffic needs to be dropped by a control plane !-- policy (the CoPP feature.) If the access list matches (permit) !-- then traffic will be dropped and if the access list does not !-- match (deny) then traffic will be processed by the router. access-list 100 deny udp 192.168.1.0 0.0.0.255 any eq 5060 access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5060 access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5061 access-list 100 deny udp host 172.16.1.1 any eq 5060 access-list 100 deny tcp host 172.16.1.1 any eq 5060 access-list 100 deny tcp host 172.16.1.1 any eq 5061 access-list 100 permit udp any any eq 5060 access-list 100 permit tcp any any eq 5060 access-list 100 permit tcp any any eq 5061 !-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4 !-- traffic in accordance with existing security policies and !-- configurations for traffic that is authorized to be sent !-- to infrastructure devices. !-- Create a Class-Map for traffic to be policed by !-- the CoPP feature. class-map match-all drop-sip-class match access-group 100 !-- Create a Policy-Map that will be applied to the !-- Control-Plane of the device. policy-map drop-sip-traffic class drop-sip-class drop !-- Apply the Policy-Map to the Control-Plane of the !-- device. control-plane service-policy input drop-sip-traffic Warning: Because SIP can utilize UDP as a transport protocol, it is possible to easily spoof the sender's IP address, which may defeat ACLs that permit communication to these ports from trusted IP addresses. In the above CoPP example, the access control list entries (ACEs) that match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Additional information on the configuration and use of the CoPP feature can be found at http://www.cisco.com/en/US/products/ps6642/products_white_paper0900aecd804fa16a.shtml and http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guide09186a008052446b.html 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/products/prod_warranties_item09186a008088e31f.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/warp/public/687/Directory/DirTAC.shtml 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 internal testing and during handling of customer service requests. 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-20080924-sip.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 | 2008-September-24 | 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----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLd0ACgkQ86n/Gc8U/uDWJwCdHEe8XwtX0kKmTHf2T6/Nm02U 3N8AnjG1IaW/GWg78gj6k0NGXre3Mggr =4nzw -----END PGP SIGNATURE----- From icox at cisco.com Wed Sep 24 19:11:12 2008 From: icox at cisco.com (Ian Cox) Date: Wed, 24 Sep 2008 16:11:12 -0700 Subject: [c-nsp] OSM-2OC12 question In-Reply-To: <20080924.224532.74729369.sthaug@nethelp.no> References: <20080924.224532.74729369.sthaug@nethelp.no> Message-ID: <48DAC910.8010004@cisco.com> The 4 ports of Gig on the OSM-OC12 module are gig x/y ports, same feature set as the supervisor 720 gig ports or WS-X6516. They show up as "int gig x/y". Only OSM-GEWAN module has fancy features enabled for GE. Ian sthaug at nethelp.no wrote: >> I am having trouble finding specific information about the GigE ports >> on the OSM-2OC12 card. Are those regular GigE ports or the GE-WAN >> ports like one would find on the OSM-4GBIC card? > > They are GE-WAN ports. > > 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 r.engehausen at gmail.com Wed Sep 24 21:46:06 2008 From: r.engehausen at gmail.com (Roy) Date: Wed, 24 Sep 2008 18:46:06 -0700 Subject: [c-nsp] Throttles on an interface Message-ID: <48DAED5E.8020400@gmail.com> I have a PA-FE on a 7206VXR. "show int" gives Received 7798 broadcasts, 0 runts, 0 giants, 17 throttles 393 input errors, 0 CRC, 0 frame, 0 overrun, 393 ignored The throttles seems to be related to the input errors. I also see throttles with no input errors. We have double checked (and replaced) the cable and the ports without success. Is there some sort of buffer tuning that would affect this? Roy From achatz at forthnet.gr Wed Sep 24 22:29:22 2008 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Thu, 25 Sep 2008 05:29:22 +0300 Subject: [c-nsp] SRC2? In-Reply-To: References: <1218555162.2004.15.camel@empacher.cns.ufl.edu> <48A2FF3B.5030104@gatlan.nl> <8c19328e0809161050m3478ab36gda3bd7c9cf63d39b@mail.gmail.com><20080916201757.GE14932@rtp-cse-489.cisco.com> <48D025ED.4000600@forthnet.gr> Message-ID: <48DAF782.2070700@forthnet.gr> Yep, i got informed from our AM too :( -- Tassos Asbjorn Hojmark - Lists wrote on 24/09/2008 23:24: >> I believe SRD (plus the new ES cards) are supposed to come >> out at that time too... > > I believe SRD has been delayed for quite some time, and most > certainly will *not* ship before 30sep08. > > -A > > From mrz at velvet.org Wed Sep 24 22:50:59 2008 From: mrz at velvet.org (matthew zeier) Date: Wed, 24 Sep 2008 19:50:59 -0700 Subject: [c-nsp] replacing failed 3750 stackwise member Message-ID: <48DAFC93.9020902@velvet.org> Am I overthinking this? After yesterday's CRG failure (blog.mozilla.com/it/) I was left with a failed 3750 and got the RMA this evening. Is it as simple as replacing the dead unit with this one? I've already made sure the replacement is running the same IOS image as the stackwise master. From adrian at creative.net.au Wed Sep 24 22:54:20 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 25 Sep 2008 10:54:20 +0800 Subject: [c-nsp] replacing failed 3750 stackwise member In-Reply-To: <48DAFC93.9020902@velvet.org> References: <48DAFC93.9020902@velvet.org> Message-ID: <20080925025420.GA31714@skywalker.creative.net.au> On Wed, Sep 24, 2008, matthew zeier wrote: > Am I overthinking this? After yesterday's CRG failure > (blog.mozilla.com/it/) I was left with a failed 3750 and got the RMA > this evening. > > Is it as simple as replacing the dead unit with this one? I've already > made sure the replacement is running the same IOS image as the stackwise > master. For extra joy, make sure you set its stack member ID to match the failed one. That way the config that gets placed on the unit should match the config from the failed unit, rather than it being assigned a new ID. Do this before you plug it into the stack, or it'll get a new ID, the config will be updated with even more ports, and you'll be left scratching your head for a few minutes. :) Uhm, I think it also inherits the SDM template from the master, but just to be on the safe side "show sdm prefer" on the stack and make sure your new switch matches that? (I -think- the SDM template only matters on aggregate switches entering non-aggregate switch stacks; just keep it in mind if you see weird stuff.) Adrian From mrz at velvet.org Wed Sep 24 23:01:19 2008 From: mrz at velvet.org (matthew zeier) Date: Wed, 24 Sep 2008 20:01:19 -0700 Subject: [c-nsp] replacing failed 3750 stackwise member In-Reply-To: <20080925025420.GA31714@skywalker.creative.net.au> References: <48DAFC93.9020902@velvet.org> <20080925025420.GA31714@skywalker.creative.net.au> Message-ID: <48DAFEFF.7070501@velvet.org> On 9/24/08 7:54 PM, Adrian Chadd wrote: > On Wed, Sep 24, 2008, matthew zeier wrote: >> Am I overthinking this? After yesterday's CRG failure >> (blog.mozilla.com/it/) I was left with a failed 3750 and got the RMA >> this evening. >> >> Is it as simple as replacing the dead unit with this one? I've already >> made sure the replacement is running the same IOS image as the stackwise >> master. > > For extra joy, make sure you set its stack member ID to match the failed one. > That way the config that gets placed on the unit should match the config from > the failed unit, rather than it being assigned a new ID. How's that done? From adrian at creative.net.au Wed Sep 24 23:14:21 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 25 Sep 2008 11:14:21 +0800 Subject: [c-nsp] replacing failed 3750 stackwise member In-Reply-To: <48DAFEFF.7070501@velvet.org> References: <48DAFC93.9020902@velvet.org> <20080925025420.GA31714@skywalker.creative.net.au> <48DAFEFF.7070501@velvet.org> Message-ID: <20080925031421.GB31714@skywalker.creative.net.au> On Wed, Sep 24, 2008, matthew zeier wrote: > How's that done? in conf mode: switch 1 renumber Then reload. Make sure you've provisioned the right switch type in the stack (switch provision ). (Have you read the 3750 stacking chapters in the IOS config guide? They cover a whole lot of this stuff well enough.) Adrian From rubensk at gmail.com Wed Sep 24 23:51:14 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Thu, 25 Sep 2008 00:51:14 -0300 Subject: [c-nsp] 12.2(33)SXI In-Reply-To: <2514097524594E9DBEB516AB48730787@hojmark.net> References: <9e246b4d0809220719ld6f7b9em34cb0886f4d190fd@mail.gmail.com> <2514097524594E9DBEB516AB48730787@hojmark.net> Message-ID: <6bb5f5b10809242051gf0fa847l3ef5596e59cd6a11@mail.gmail.com> Not only postponed, but the feature matrix has been changed, so some roadmapped features won't show up in SXI. Rubens On Wed, Sep 24, 2008 at 4:42 PM, Asbjorn Hojmark - Lists wrote: >> * A.* First customer ship is expected in September 2008." > > I just heard that's been postponed to 'end of October'. > > -A > > _______________________________________________ > 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 Thu Sep 25 01:59:30 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 25 Sep 2008 07:59:30 +0200 (CEST) Subject: [c-nsp] OSM-2OC12 question In-Reply-To: <48DAC910.8010004@cisco.com> References: <20080924.224532.74729369.sthaug@nethelp.no> <48DAC910.8010004@cisco.com> Message-ID: <20080925.075930.74653385.sthaug@nethelp.no> > The 4 ports of Gig on the OSM-OC12 module are gig x/y ports, same > feature set as the supervisor 720 gig ports or WS-X6516. They show up as > "int gig x/y". Only OSM-GEWAN module has fancy features enabled for GE. Ah yes, I remembered wrong. Been too long since I worked with those beasts... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From vikassharmas at gmail.com Thu Sep 25 02:12:41 2008 From: vikassharmas at gmail.com (Vikas Sharma) Date: Thu, 25 Sep 2008 11:42:41 +0530 Subject: [c-nsp] SRB on 6500 Message-ID: Hi, Is it possible to run SRB3 on 6500-E chassis. I am sure this can be done by using 6509-NEB-A, but not sure about 6509-E. Regards, Vikas Sharma From aaronis at people.net.au Thu Sep 25 02:15:14 2008 From: aaronis at people.net.au (aaron) Date: Thu, 25 Sep 2008 14:15:14 +0800 Subject: [c-nsp] Weird Port Loopback Issues with 3750 and ESX 3.5 Message-ID: <200809250615.m8P6FJhF051017@puck.nether.net> Hey Guys, I am hoping some of you out there may have experienced this problem in the past. We have a spare NIC on a DELL X445 (Broadcom NetXtreme BCM5793 1000Base-T) running ESX 3.5. No matter what I do I cannot seem to get this NIC working properly. I have it connected to a 3750 switch GIG GLC-T SFP port and I am getting err-disable loopback issues where the switch is actually receiving its own keep alives on the same port. I have messed with the various duplex / speed settings at both ends and this doesn't seem to resolve the issue. I have turned off inline power and mdix auto. The cable is CAT5E UTP. Several cables have been tested and the length is no longer than 10m. I have connected this NIC to a 3550 series switch and the exact same thing happens. I have come to the conclusion that the NIC must be faulty or musn't have the correct drivers installed. Any ideas? Thanks, Aaron. From dgranzer at gmail.com Thu Sep 25 03:59:31 2008 From: dgranzer at gmail.com (David Granzer) Date: Thu, 25 Sep 2008 09:59:31 +0200 Subject: [c-nsp] Maximum number of class-map supported Message-ID: <844ef89c0809250059t5373c838jefa47496bd4d71e0@mail.gmail.com> Hello, I can't find information about maximum number of class-map supported on a particular platfom (e.g. 2800, 3800, NPE-G1) in one policy-map. Does anyone have link to any documentation or does anyone know how many class-map are supported in one policy-map ? Regards, David From ariemer at wesenergy.com.au Thu Sep 25 04:06:10 2008 From: ariemer at wesenergy.com.au (Aaron Riemer) Date: Thu, 25 Sep 2008 16:06:10 +0800 Subject: [c-nsp] Maximum number of class-map supported In-Reply-To: <844ef89c0809250059t5373c838jefa47496bd4d71e0@mail.gmail.com> References: <844ef89c0809250059t5373c838jefa47496bd4d71e0@mail.gmail.com> Message-ID: <0867622C64B50C4B878AB45C95F43F1106220F8F@MAILWA01.wesenergy.local> AFIAK it's 256 mate. Could be different for the different IOS versions though. Cheers, Aaron. -----Original Message----- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Granzer Sent: Thursday, 25 September 2008 4:00 PM To: cisco-nsp at puck.nether.net Subject: [c-nsp] Maximum number of class-map supported Hello, I can't find information about maximum number of class-map supported on a particular platfom (e.g. 2800, 3800, NPE-G1) in one policy-map. Does anyone have link to any documentation or does anyone know how many class-map are supported in one policy-map ? 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/ LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From blahu77 at gmail.com Thu Sep 25 04:38:23 2008 From: blahu77 at gmail.com (=?ISO-8859-2?Q?Mateusz_B=B3aszczyk?=) Date: Thu, 25 Sep 2008 09:38:23 +0100 Subject: [c-nsp] Weird Port Loopback Issues with 3750 and ESX 3.5 In-Reply-To: <200809250615.m8P6FJhF051017@puck.nether.net> References: <200809250615.m8P6FJhF051017@puck.nether.net> Message-ID: <383357750809250138t2c286efdt344b630d7996f526@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I am hoping some of you out there may have experienced this problem in the > past. We have a spare NIC on a DELL X445 (Broadcom NetXtreme BCM5793 > 1000Base-T) running ESX 3.5. No matter what I do I cannot seem to get this > NIC working properly. I have it connected to a 3750 switch GIG GLC-T SFP > port and I am getting err-disable loopback issues where the switch is > actually receiving its own keep alives on the same port. does it work when you set "no keepalive" on 3750's port - -- - -mat pgp-key 0x4E5EB11E -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI203+IvBv0k5esR4RAtBVAKDC+2ljZT4e/nyB2ayCKok8mip1wgCfdPGZ iP2KqZkMpDsmll9J3Rl+E4A= =xCo5 -----END PGP SIGNATURE----- From gert at greenie.muc.de Wed Sep 24 14:01:38 2008 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 24 Sep 2008 20:01:38 +0200 Subject: [c-nsp] SXH3 ghost bugs - more details In-Reply-To: <20080923204638.GM24139@rtp-cse-489.cisco.com> References: <20080916040858.GA17256@greenie.muc.de> <48CFC183.4060401@bytemark.co.uk> <20080916165849.GA20288@greenie.muc.de> <20080918201316.GD20288@greenie.muc.de> <20080919003643.GB79009@puck.nether.net> <20080919165126.GA11635@greenie.muc.de> <1221845016.11349.15.camel@abehat> <20080920192953.GD7160@greenie.muc.de> <20080922130445.GB12859@rtp-cse-489.cisco.com> <20080923204638.GM24139@rtp-cse-489.cisco.com> Message-ID: <20080924180137.GD6014@greenie.muc.de> Hi, On Tue, Sep 23, 2008 at 04:46:38PM -0400, Rodney Dunn wrote: > Seems they are not planning a special rebuild for this unfortunately. Mmmh, bad news. > We are trying to get them to build a engineering special > generally available for TAC if you have a SR open they should > be able to get it. That would work fine for us, though. Thanks, gert -- Gert Doering Mobile communications ... right now writing from * Sardegna, Italy * From p.mayers at imperial.ac.uk Thu Sep 25 05:20:28 2008 From: p.mayers at imperial.ac.uk (Phil Mayers) Date: Thu, 25 Sep 2008 10:20:28 +0100 Subject: [c-nsp] 12.2(33)SXI In-Reply-To: <6bb5f5b10809242051gf0fa847l3ef5596e59cd6a11@mail.gmail.com> References: <9e246b4d0809220719ld6f7b9em34cb0886f4d190fd@mail.gmail.com> <2514097524594E9DBEB516AB48730787@hojmark.net> <6bb5f5b10809242051gf0fa847l3ef5596e59cd6a11@mail.gmail.com> Message-ID: <48DB57DC.5030300@imperial.ac.uk> Rubens Kuhl Jr. wrote: > Not only postponed, but the feature matrix has been changed, so some > roadmapped features won't show up in SXI. Any idea which ones? From achatz at forthnet.gr Thu Sep 25 05:37:22 2008 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Thu, 25 Sep 2008 12:37:22 +0300 Subject: [c-nsp] Performance Of www.cisco.com In-Reply-To: References: Message-ID: <48DB5BD2.4040602@forthnet.gr> Someone heard all of you and made www.cisco.com extra-light! -- Tassos Sean Granger wrote on 24/9/2008 11:35 ??: > Seconded. > > In fact, it's a common sense thing that since it's not being done, is brilliant. > >>>> Justin Shore 09/24/08 01:43PM >>> > Seth Mattinen wrote: >> It's been slow for me since this current iteration of the design came >> out. I just attributed it to the tradeoff between flashy and functional. >> I was stuck on a dialup modem (21k) once during an emergency after my >> 877 at home failed and trying to access my TAC case online was horribly >> painful to the point of causing extreme rage. >> >> Download speeds are fine, though. > > My download speeds are fine too. My biggest gripe is how things keep > changing and how fancy the pages are getting. I can understand some > bling on the product and marketing pages but the support pages should be > downright blah in my opinion. I should be able to load up the support > site in lynx if I have to and find what I'm looking for. Today we have > to deal with all those damn style sheets, indirect linking through CGIs, > flash and javascript crap, having to (re)authenticate at every turn, and > timeouts that are way too short (can you say Dynamic Config Tool?). > > Like I said earlier, give the product and marketing pages the shiny > bling and give the support pages the look, feel and function of what a > professional Cisco engineer would except and need. After all, we use > the command line all day long. We don't need a stinking GUI. > > 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/ > > _______________________________________________ > 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 Thu Sep 25 05:42:18 2008 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Thu, 25 Sep 2008 10:42:18 +0100 Subject: [c-nsp] Performance Of www.cisco.com In-Reply-To: <48DB5BD2.4040602@forthnet.gr> References: <48DB5BD2.4040602@forthnet.gr> Message-ID: <48DB5CFA.4090405@poggs.co.uk> Tassos Chatzithomaoglou wrote: > Someone heard all of you and made www.cisco.com extra-light! You mean extra-igh. www.cisco.com in "missing the letter 't'" shocker :-) Peter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From irenna at gmail.com Thu Sep 25 05:46:39 2008 From: irenna at gmail.com (Irena Nikolova) Date: Thu, 25 Sep 2008 11:46:39 +0200 Subject: [c-nsp] Performance Of www.cisco.com In-Reply-To: <48DB5BD2.4040602@forthnet.gr> References: <48DB5BD2.4040602@forthnet.gr> Message-ID: <938a20760809250246u3a8b2296s597b35d45bde074a@mail.gmail.com> And also without "t"s for some reason :) Irena 2008/9/25 Tassos Chatzithomaoglou > Someone heard all of you and made www.cisco.com extra-light! > > -- > Tassos > > Sean Granger wrote on 24/9/2008 11:35 ??: > > Seconded. >> >> In fact, it's a common sense thing that since it's not being done, is >> brilliant. >> >> Justin Shore 09/24/08 01:43PM >>> >>>>> >>>> Seth Mattinen wrote: >> >>> It's been slow for me since this current iteration of the design came >>> out. I just attributed it to the tradeoff between flashy and functional. >>> I was stuck on a dialup modem (21k) once during an emergency after my >>> 877 at home failed and trying to access my TAC case online was horribly >>> painful to the point of causing extreme rage. >>> >>> Download speeds are fine, though. >>> >> >> My download speeds are fine too. My biggest gripe is how things keep >> changing and how fancy the pages are getting. I can understand some bling >> on the product and marketing pages but the support pages should be downright >> blah in my opinion. I should be able to load up the support site in lynx if >> I have to and find what I'm looking for. Today we have to deal with all >> those damn style sheets, indirect linking through CGIs, flash and javascript >> crap, having to (re)authenticate at every turn, and timeouts that are way >> too short (can you say Dynamic Config Tool?). >> >> Like I said earlier, give the product and marketing pages the shiny bling >> and give the support pages the look, feel and function of what a >> professional Cisco engineer would except and need. After all, we use the >> command line all day long. We don't need a stinking GUI. >> >> 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/ >> >> _______________________________________________ >> 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 r.nevot at gmail.com Thu Sep 25 05:58:41 2008 From: r.nevot at gmail.com (Raul Lopez Nevot) Date: Thu, 25 Sep 2008 11:58:41 +0200 Subject: [c-nsp] Performance Of www.cisco.com In-Reply-To: <938a20760809250246u3a8b2296s597b35d45bde074a@mail.gmail.com> References: <48DB5BD2.4040602@forthnet.gr> <938a20760809250246u3a8b2296s597b35d45bde074a@mail.gmail.com> Message-ID: Suspicious... I can't believe that... maybe 'defaced' ? 2008/9/25 Irena Nikolova > And also without "t"s for some reason :) > > I