Re: [c-nsp] dampening for VPNv4
Thanks Ben for the directions . I enabled the bgp dampening for VPNv4 address-family . It helped to some extent to see the flapped statistics from the CE . I blocked one of the /16 network , which was flapping at a higher rate , coming from CE. Still i do not see significant improvement in the CPU utilisation due to BGP router process. i can see some changes in prefixes recieved for the VPNv4 route reflector session. and there are around 2 prefixes coming from the VPVv4 RR. How do i find the culprit The router is 7206 with NPE-G1 . Could there be a memory or hardware limilitation also or some bug. Thanks, Ved. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ATM packet loss
Mikael Abrahamsson wrote: On Wed, 2 Sep 2009, James Berwick wrote: To re-iterate. Set it to 120 megs and try again. If there is still a problem, lower it and see if it helps. Also, what Cisco hardware are you using exactly? PA-A3-OC3* cards in VIP2-50:s or are you using better gear? Ok, to test I just built a 120 meg ubr pvc. It performed identically to the 45 meg PVC we've been testing with. I also built several other speeds (30, 45, 60, 90) and they all performed identically, packet loss for packets over 576 bytes and download speeds in the 1-5mbit range. The hardware is a Cisco 7507 chassis with an RSP16 with 1GB of RAM. The VIP is a VIP-480 with 256 megs of RAM. The only port adapter in the VIP is a PA-A3-OC3-SMI. The RSP CPU load averages 20% and show proc cpu hist does not show any time period that the max CPU broke 50%. The RSP has approximately 850 MB of free RAM. if-con'd into the VIP, it has about 190 megs of free RAM and shows an average utilization between 0% and 10% over the past 72 hours, no maxes higher than 20%. Our MRTG graphs show that September of last year this same hardware was pushing over 100mbit/sec on our ATM OC3. This chassis only does ATM traffic. We have a Covad ATM DS3 in a VIP2-50 in slot 0. This DS3 is working fine. We have a Verizon OC3 in a VIP-480 in Slot 1. This is our problem OC3. We have VIP-480s in slots 4 and 6 also terminating Verizon ATM DS3s, these are also working fine. We also have a VIP-480 in slot 5 with a gigabit adapter to uplink the router to the rest of our network. I just realized something that may (or may not be) helpful. We use ATM mostly for schools and other educational institutes, but we also receive residential and business DSL traffic over our ATM circuits. We've got around 400 DSL customers on this OC3 who are online right now, with a mixture of PPPoE and statically bridged DSL users and I'm not seeing anything wrong with any of their connections, ie, no packet loss, no performance issues. Please excuse me if I missed something or typed it very poorly, I've been working on this problem for about 18 hours now and I'm fried. Thanks again for the suggestions! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Management stuff in VRFs
On Sep 3, 2009, at 2:36 AM, Peter Rathlev wrote: Is management from a VRF to be considered best practice? Increasingly, for many purposes, yes. Note that you can specify a VRF as the destination for NDE NetFlow telemetry, for example. Also, Cisco's Nexus 7000-series IDC switches allow the control and management planes of the switch to be separated into four Virtual Device Contexts, or VDCs. For the first time, a piece of general- purpose hardware can safely be used to carry both production and OOB management/Data Communications Network (DCN) management-type traffic across the same physical hardware. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Management stuff in VRFs
We went in that direction in our latest deployment and discovered also that many pieces were missing in IOS and IOS-XR to have full management in a dedicated VRF for all our devices. At this stage we have the VRF but not all management goes there... so there is more complexity and network is no more secure... I must admit IOS-XR gives us more troubles as more management features are missing in VRF's. Maybe for a pure IOS network there could be an added value (?) Regards, Jerome Peter Rathlev a écrit : I'm a little curious since there have been so many threads about running management stuff in VRFs. I've until now considered VRFs something for customers only; management is in the global table. Is management from a VRF to be considered best practice? What are the benefits from using a VRF for this? I assume everyone uses infrastructure ACLs so the VRF thingy shouldn't be any more secure. Or should it? Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- - Jerome Durand Responsable des services aux usagers Services operations support manager Réseau National de Télécommunications pour la Technologie, l'Enseignement et la Recherche Tel:+33 (0) 1 53 94 20 40 | GIP RENATER Fax:+33 (0) 1 53 94 20 41 | c/o ENSAM E-mail: jdur...@renater.fr | 151 Boulevard de l'Hôpital http://www.renater.fr | 75013 PARIS -- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] IDS
hey all if i have in a data center a 2 firewall and 1 IDS system what will be the optimal or best topology to make _ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
Ben Steele wrote: Unless you are hitting a cam limit on any of your resources on your SUP(very possible if you are exporting netflow) OR you are congesting the crossbar fabric(sh fabric util) which is pretty unlikely when you are talking a 24G linecard on a 40G fabric connection then you probably won't see any difference putting a DFC on a 6724 That depends completely on what other cards are on the box, what their offered forwarding load is, and whether they have DFCs. Remember these chassis are a hardware only based forwarding solution, so all your doing with a DFC is moving cam/asic resources off the sup, so in regards to your specific questions unless you have filled all your QoS queues on the sup you are going to see nothing more on the DFC, also the sup does (from memory) up to 100-200m pps in ipv6, I don't believe for a moment No. The PFC3 does 30Mpps IPv4 (and 15Mpps IPv6 I think). A DFC3 does 48Mpps IPv4 (and 24Mpps IPv6). http://www.cisco.com/en/US/products/hw/switches/ps708/products_qanda_item09186a00809a7673.shtml A fully-populated and fully-DFCed 6509 does 400Mpps IPv4 or 200Mpps IPv6 (well, actually 192Mpps - 24x8 linecards). In this configuration, the PFC does very little. It's worth noting that a 6724 doing 64-bytes packets on all ports offers ~47Mpps forwarding load - well in excess of the PFC capacity. A chassis full of 6724s without DFCs at 10% load with 64-bytes packets also exceeds the PFC capacity. Obviously these are worst-case numbers but illustrative of the problems you can get yourself into if you don't capacity plan well. It's worth noting that some linecards have different (i.e. more flexible) rx tx queueing methods with a DFC versus the CFC. There's also the bus-stall issues, which go away (supposedly) with a DFC installed since they're not connected to the bus. you are even remotely close to this, and the global ipv6 routing table is no where near the cam limit for that either, by the way is your SUP an XL? does the DFC's on the 10G's match the sup or have they fallen back to the lowest common configuration? I'm not sure why you mention CAM limits, but it's worth noting that DFCs do not help with FIB CAM at all, since they hold a copy of the PFC FIB. Personally we get DFCs on everything since we're using plain -3B (or -3C not) rather than XL, and the cost of the DFC is a pretty minimal percentage of the linecard for the future-proofing. We've also seen software bugs manifest on CFC cards in the past; this implies to me that Cisco prefer DFC chassis. Similarly some of the new linecards e.g. 6708/6716 are DFC-only. I suspect that will be the case going forward. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
On Thu, Sep 3, 2009 at 7:35 PM, Phil Mayers p.may...@imperial.ac.uk wrote: Ben Steele wrote: Unless you are hitting a cam limit on any of your resources on your SUP(very possible if you are exporting netflow) OR you are congesting the crossbar fabric(sh fabric util) which is pretty unlikely when you are talking a 24G linecard on a 40G fabric connection then you probably won't see any difference putting a DFC on a 6724 That depends completely on what other cards are on the box, what their offered forwarding load is, and whether they have DFCs. Hence asking him to check these values, or at least implying from that sentence that he should :) Remember these chassis are a hardware only based forwarding solution, so all your doing with a DFC is moving cam/asic resources off the sup, so in regards to your specific questions unless you have filled all your QoS queues on the sup you are going to see nothing more on the DFC, also the sup does (from memory) up to 100-200m pps in ipv6, I don't believe for a moment No. The PFC3 does 30Mpps IPv4 (and 15Mpps IPv6 I think). A DFC3 does 48Mpps IPv4 (and 24Mpps IPv6). http://www.cisco.com/en/US/products/hw/switches/ps708/products_qanda_item09186a00809a7673.shtml A fully-populated and fully-DFCed 6509 does 400Mpps IPv4 or 200Mpps IPv6 (well, actually 192Mpps - 24x8 linecards). In this configuration, the PFC does very little. Ok my bad, my memory was for the full chassis not the individual PFC, should read docco next time before posting! i'm still quite certain our OP isn't doing 15Mpps of IPv6, if he is then he must be the IPv6 hub of the world. It's worth noting that a 6724 doing 64-bytes packets on all ports offers ~47Mpps forwarding load - well in excess of the PFC capacity. A chassis full of 6724s without DFCs at 10% load with 64-bytes packets also exceeds the PFC capacity. Obviously these are worst-case numbers but illustrative of the problems you can get yourself into if you don't capacity plan well. I think it's safe to say our OP is no where near these limits or he would definitely know about it, in fact I doubt anyone in the world has hit 47Mpps on any 6500 linecard(in a real world situation, no labs), please if someone has feel free to let me know about it. But yes capacity planning is very important. It's worth noting that some linecards have different (i.e. more flexible) rx tx queueing methods with a DFC versus the CFC. True but keep in mind the OP already has some DFC enabled linecards so I would assume he is familiar with what QoS he can and can't schedule on the CFC vs DFC, his particular comment related to performance and offloading of QoS - not features, the same goes for different line cards in general though, like the 4 and 8 port 10Gb line cards, totally different buffering capabilities, you need to choose your line card wisely, our OP already has his in place. There's also the bus-stall issues, which go away (supposedly) with a DFC installed since they're not connected to the bus. Interesting.. i'll take your word for that, can't say i've seen much in the way of bus stalls when working with them(at least in recent times) except the standard OIR one, i'll assume this is an actual performance impacting stall you are referring to, does this apply even if the chassis is in compact mode? you are even remotely close to this, and the global ipv6 routing table is no where near the cam limit for that either, by the way is your SUP an XL? does the DFC's on the 10G's match the sup or have they fallen back to the lowest common configuration? I'm not sure why you mention CAM limits, but it's worth noting that DFCs do not help with FIB CAM at all, since they hold a copy of the PFC FIB. Yeah my ipv6 FIB CAM statement was pretty irrelevant and was more me typing then realising i'm not sure if we are even talking XL or not here, wasn't the greatest sentence. Personally we get DFCs on everything since we're using plain -3B (or -3C not) rather than XL, and the cost of the DFC is a pretty minimal percentage of the linecard for the future-proofing. No doubt it's better to have a DFC than not have a DFC but some companies are tight with money and justifying just a few thousand for something you don't *really* need can be hard, while non XL upgrade might seem trivial I think you'll find to upgrade a 6724 from stock to a 3CXL DFC is around the price of the actual line card itself, that said neither of us know what PFC the OP is running :) We've also seen software bugs manifest on CFC cards in the past; this implies to me that Cisco prefer DFC chassis. Similarly some of the new linecards e.g. 6708/6716 are DFC-only. I suspect that will be the case going forward. Well from a performance point of view it makes sense, but it all equals $$ and companies are being stingier than ever with the GFC in everyones head. I still get the feeling the OP doesn't need the DFC, generally you
Re: [c-nsp] do i *need* DFCs on the 6500?
There's also the bus-stall issues, which go away (supposedly) with a DFC installed since they're not connected to the bus. The chassis bus stall is done by 3 physical pins in the slot, so DFC or not you still stall and potentially reboot the chassis while inserting/removing a card- however DFC enabled line cards are not subject to the packet loss associated with a bus stall [1]. ~Matt 1: http://www.cisco.com/en/US/products/hw/switches/ps708/products_qanda_ite m09186a00809a7673.shtml#qa4 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP multihop between two sites
No, I think you understand it perfectly. The goal is to have 'stateful knowledge' of my own eBGP routes, using the simplest most resilient and cross-platform compatible method. What would be the caveats of the neigbor x.x.x.x allowas-in? It seems too easy, there HAS to be a catch! :) Do I need to change my inbound filters? Right now I am not filtering inbound routes from the directly connected Tier1's. -- Randy -- Original Message --- From: john.herb...@ins.com To: r...@fast-serv.com, cisco-nsp@puck.nether.net Sent: Wed, 2 Sep 2009 21:42:22 -0500 Subject: RE: [c-nsp] BGP multihop between two sites Ah I think I see. Assuming you have no default route learned via eBGP then (given 3 full routing tables, that's probably a fair assumption), the question becomes whether you can intelligently maintain a floating static default based on reachability to the next-hop IP, or if it's better to implement some kind of BGP peering between the two sites. One possibility might be to consider a conditional static default route - use ip sla to test next hop reachability of a provider's router, then use the track command to monitor and apply to a floating default route (and of course, you can do this for more than one provider and provide a predetermined sequence of alternate default routes) I am not personally a fan of iBGP raw over a public network (and that's what it would be since the ASNs are the same on both ends), as most of the protection features in IOS are focused on eBGP. GRE tunnel works, though there may be caveats depending on MTU/fragmentation issues and hardware switching support. Maintaining those BGP peers of course assumes that the remote IP in each case is known in one of the active eBGP sessions at all time. Probably a reasonable assumption if you're using provider-owned IPs to peer; maybe less so if you're using IPs that fall within your own larger block. I may be misunderstanding something about your particular topology, so my apologies if so. John. --- From: Randy McAnally [...@fast-serv.com] Sent: Wednesday, September 02, 2009 21:10 To: Herbert, John; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] BGP multihop between two sites I'm not quite clear on the floating default? What is it floating over? If you are receiving a default in BGP, then are you / can you receive it from multiple providers for resiliency? And if so, under what circumstances is the floating static ever active in your routing tables? It's a high distance static default route in place, to keep packets flowing in case of an eBGP malfunction. In this case, it was routing packets between locations because the prefixes were not in the routing tables. This was not discovered until the provider the default pointed went down. -- Randy --- End of Original Message --- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP multihop between two sites
What would be the caveats of the neigbor x.x.x.x allowas-in? It seems too easy, there HAS to be a catch! :) The catch is that EBGP has admin distance of 20 by default so the prefixes received via EBGP would override anything dynamic in your AS. But that might not be an issue for you as that's what you eventually want to achieve. -- deejay __ Informacia od ESET NOD32 Antivirus, verzia databazy 4391 (20090903) __ Tuto spravu preveril ESET NOD32 Antivirus. http://www.eset.sk ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
congesting the crossbar fabric(sh fabric util) which is pretty unlikely when you are talking a 24G linecard on a 40G fabric connection Just a nitpick or two - the 6724 only has one channel of fabric, so it's a 24G linecard with a 20G fabric connection, thus a slight oversubscription. If you're extremely rigorous about line-rate, leave four of those ports unused. But the DFC issue is more about Mpps than Mbps. As Phil pointed out, you could run them well under their line-rate, but with small packets, and overwhelm the forwarding capacity of the PFC. -Geoff On Wed, Sep 2, 2009 at 5:59 PM, Ben Steeleillcrit...@gmail.com wrote: Unless you are hitting a cam limit on any of your resources on your SUP(very possible if you are exporting netflow) OR you are congesting the crossbar fabric(sh fabric util) which is pretty unlikely when you are talking a 24G linecard on a 40G fabric connection then you probably won't see any difference putting a DFC on a 6724 Remember these chassis are a hardware only based forwarding solution, so all your doing with a DFC is moving cam/asic resources off the sup, so in regards to your specific questions unless you have filled all your QoS queues on the sup you are going to see nothing more on the DFC, also the sup does (from memory) up to 100-200m pps in ipv6, I don't believe for a moment you are even remotely close to this, and the global ipv6 routing table is no where near the cam limit for that either, by the way is your SUP an XL? does the DFC's on the 10G's match the sup or have they fallen back to the lowest common configuration? ...or could it be that DFC's are only really useful to a particular deployment and I just *think* i need them? ;-) - I think you might be on the money here. If you give us the current utilization of your cam resources(from the sup) and the 6724 linecard throughput and what its functions are(netflow/qos/mac/acls etc) then we can tell you for sure. Ben On Wed, Sep 2, 2009 at 9:16 PM, Alan Buxey a.l.m.bu...@lboro.ac.uk wrote: hi, okay, from the background of I know what the DFC is and how it operates etc... i know I want them - however, I need to justify the upgrade/part cost to sort out a couple of 6500's. in some of our 6500's, the 10G blades have DFCs already...but several 6724's dont (they just have CFC). ...as i said, I want them, but need to get some management/funding buy-in - and they dont want the 'what it does' information - they want some hard and fast facts that Cisco dont sem to want to tell me . so, the question is 1) is there any way of showing the sup720 strain/utilisation...particularly is there a way of showing DFC usage on the blades where we have them? 2) it offloads IPv6 and QoS - we're into both of those (and more so over the next year) - any particular insights into QoS performance/issues without DFC ? any throughput figures for IPv6 ? (i know that with CFC we're limited to the backplane (32mpps?) and we get ~ 48mpps per blade with DFC) ...or could it be that DFC's are only really useful to a particular deployment and I just *think* i need them? ;-) alan ___ cisco-nsp mailing list cisco-...@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-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] CIsco ASA processes
Hello Everyone,Does anyone knows what is a Dispatch Unit process in Cisco ASA 5510 ?? And also to check the attached file and understand why my CPU usage has peak of 10 - 20 % in 5 sec intervals. thanks, -- Almog. Cisco-ASA-CLT/act# sh processes PC SP STATE RuntimeSBASE Stack Process Lwe 08051bac d450bac4 09b7aeb4 0 d4509bb0 7920/8192 block_diag Mrd 081727e4 d453c464 09b7a7fc 15010044 d451c5f0 124300/131072 Dispatch Unit Mwe 0835e1f5 d4541614 09b7a5ec 0 d453f820 7496/8192 CF OIR Mwe 08963190 d454382c 09aac950 0 d4541948 7872/8192 lina_int Mwe 08064bc5 d45b235c 09b7a5ec 4 d45b04b8 4448/8192 Reload Control Thread Mwe 08069626 d45bd274 09b7c718582 d45b96c0 12688/16384 aaa Mwe 08092416 d45c408c 09b7c774 0 d45c0198 15712/16384 CMGR Server Process Mwe 08092925 d45c6154 09b7a5ec 0 d45c42c0 7760/8192 CMGR Timer Process Lwe 08171342 d45d078c 09b877a4 0 d45ce888 7376/8192 dbgtrace Msi 083e650c d45d8d7c 09b7a5ec 13257 d45d6e68 7808/8192 557mcfix Msi 083e632e d45daea4 09b7a5ec 3 d45d8f90 7776/8192 557statspoll Mwe 08b5480d d480105c 09b7a5ec 1 d45f69e8 7136/8192 netfs_thread_init Mwe 09144be5 d4604e2c 09b7a5ec 0 d4602fa8 7640/8192 Chunk Manager Msi 087fabee d461020c 09b7a5ec 22610 d460e318 7316/8192 PIX Garbage Collector Mwe 087ee244 d4619e6c 09a9dcac 1 d4617f68 6184/8192 IP Address Assign Mwe 089adaf6 d47ab864 09adf078 0 d47a9960 7904/8192 QoS Support Module Mwe 0886b62f d47ad9c4 09a9ed50 0 d47abac0 7904/8192 Client Update Task Lwe 091845b8 d47b023c 09b7a5ec 175392 d47ae3a8 7696/8192 Checkheaps Mwe 089b0d45 d47b646c 09b7a5ec 0 d47b4808 6624/8192 Quack process Mwe 08a04632 d47ba7a4 09b7a5ec 1847 d47b6930 15504/16384 Session Manager Mwe 08b03785 d47c5204 d50fffd0 9 d47c17b0 14296/16384 uauth Mwe 08aa5795 d47c77dc 09aebdc0 0 d47c58d8 7376/8192 Uauth_Proxy Msp 08adc06c d47cf574 09b7a5ec 1017 d47cd660 7552/8192 SSL Mwe 08b01be6 d47d165c 09af18c4 0 d47cf788 7240/8192 SMTP Mwe 08af6f79 d47d3624 09af1848573 d47d18b0 3080/8192 Logger Mwe 08af359e d47d586c 09b7a5ec 0 d47d39d8 7344/8192 Thread Logger Mwe 08cd1c42 d47e40d4 09b242e8 0 d47e21f0 7040/8192 vpnlb_thread Mwe 0823344d d47eaa7c 09b7a5ec 0 d47e8bf8 7640/8192 TLS Proxy Inspector Msi 08a1d073 d48730d4 09b7a5ec 20871 d48711d0 7792/8192 emweb/cifs_timer Mwe 0860ca27 d48b5b2c 09a948ac 0 d48b3c38 7520/8192 netfs_mount_handler Msi 084c2788 d45ca3e4 09b7a5ec 92385 d45c8510 7168/8192 arp_timer Mwe 084cbc7c d45d6bf4 09b9af68 0 d45d4d40 7824/8192 arp_forward_thread Mwe 0852fb65 d45dcf3c 09b9fd60 3 d45db0b8 7808/8192 Lic TMR Mwe 08b06da1 d4602d74 09af1b40 0 d4600e80 7776/8192 tcp_fast Mwe 08b09f90 d4b3171c 09af1b40 0 d4b2f838 7760/8192 tcp_slow Mwe 08b33bf9 d4b3f40c 09af9a48 0 d4b3d518 7872/8192 udp_timer Mwe 080e6cb8 d45e7fdc 09b7a5ec 0 d45e6148 7760/8192 CTCP Timer process Mwe 08c82503 d45faa2c 09b7a5ec 0 d45f8bb8 7728/8192 L2TP data daemon Mwe 08c832d3 d45fcb14 09b7a5ec 0 d45fac90 7744/8192 L2TP mgmt daemon Mwe 08c6f3db d4e9adcc 09b1e224 4212 d4e96f18 16048/16384 ppp_timer_thread Msi 08cd20a7 d4e9ce14 09b7a5ec 28436 d4e9af40 7744/8192 vpnlb_timer_thread Mwe 080fc9d7 d45cc4dc d45fec50 13 d45ca638 3320/8192 IPsec message handler Msi 0810ecfc d47c98c4 09b7a5ec 446843 d47c7a00 6328/8192 CTM message handler Mwe 088c5a1a d45ce5d4 09b7a5ec 4 d45cc760 5852/8192 NAT security-level reconfiguration Mwe 089daea8 d5085294 09b7a5ec 0 d50833f0 7776/8192 ICMP event handler Mwe 087550b3 d508940c 09b7a5ec 5422 d5085568 14520/16384 IP Background Mwe 08169957 d50f0e7c 09a726f4235 d50d0fb8 122936/131072 tmatch compile thread Mwe 088f1a05 d51c75bc 09b7a5ec 0 d51c3708 15880/16384 Crypto PKI RECV Mwe 088f44fa d51cb6c4 09b7a5ec 0 d51c7830 15848/16384 Crypto CA Lsi 0880aad8 d5203024 09b7a5ec279 d5201110 7808/8192 uauth_urlb clean Lwe 087f3f2f d541381c 09b7a5ec 80809 d54119a8 4228/8192 pm_timer_thread Mwe 084556c5 d5415bf4 09b7a5ec 29445 d5413d60 7624/8192 IKE Timekeeper Mwe 084492eb d541b0ac 09a8fcb4 14416 d54174d8 10408/16384 IKE Daemon Mwe 08ab90da d541eccc 09af04d4 0 d541cde8 7872/8192 RADIUS Proxy Event Daemon Mwe 08a8717b d5420c64 d47d8c60 39 d541eec0 7032/8192 RADIUS Proxy Listener Mwe 08ab7cd7 d5422e2c 09b7a5ec 0 d5420f98 7760/8192 RADIUS Proxy Time Keeper Mwe 084b3a3c d5425bdc 09b9aee8 0 d5423da8 7008/8192 Integrity FW Task Mwe 08186d8b d546066c 096595dc 0 d5440e68 124996/131072 ci/console Mwe 08391745 d5462e24 09b7a5ec 2417 d5460f90 3672/8192 fover_thread Mwe 08c572b5 d5464f4c 09d20850 3912 d54630b8 6192/8192 lu_ctl Msi 0882c89c d5466ee4 09b7a5ec 186241 d54651e0 5992/8192
Re: [c-nsp] CIsco ASA processes
Do you have threat detection stats turned on? That's an easy way to add 10-20% to your CPU usage. Network Engineer, JNCIS-M 214-981-1954 (office) 214-642-4075 (cell) jbrash...@hq.speakeasy.net http://www.speakeasy.net -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of almog ohayon Sent: Thursday, September 03, 2009 9:05 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] CIsco ASA processes Hello Everyone,Does anyone knows what is a Dispatch Unit process in Cisco ASA 5510 ?? And also to check the attached file and understand why my CPU usage has peak of 10 - 20 % in 5 sec intervals. thanks, -- Almog. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] CIsco ASA processes
Hi, On Thu, 3 Sep 2009, almog ohayon wrote: Hello Everyone,Does anyone knows what is a Dispatch Unit process in Cisco ASA 5510 ?? low-level packet forwarding. Don't worry about the high Runtime number there, if that is the underlying question :) And also to check the attached file and understand why my CPU usage has peak of 10 - 20 % in 5 sec intervals. take two show proc and look at the difference of runtimes (except the dispatch unit processes). Otherwise the values are since the last restart. But if your utilisation was steady over all the time, then periodic high volume of logging might have something to do with it. thanks, andrew ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] mpls ldp sync
I'm in middle of a issue , request your help in this issue - We have a GSR 12416 connected to JUNIPER router. We are running OSPF between them. OSPF neighbourship comes up :) BUT now when I enable under ospf mpls ldp sync --- ospf neighbourship goes down and doesn't comes up. Request your help in this. Regards J.Daniels ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
Hi Mike and others, still no love. I wanted to confirm I made the NAT entries properly. I used the example on Cisco.com for the ASA and l2l + clients as an example. Here are the important bits global (outside) 1 206.x.x.234 nat (inside) 0 access-list nonat nat (inside) 1 0.0.0.0 0.0.0.0 And nonat acl access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 192.168.122.0 255.255.255.192 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 157.254.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip host 216.x.x.196 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.0.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.1.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.2.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.3.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.4.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.5.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.6.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.7.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.8.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.9.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.10.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.15.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 192.168.255.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.11.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.12.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.13.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.16.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.192.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.224.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.225.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.226.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.227.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.228.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.229.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.230.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 192.168.122.0 255.255.255.192 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 157.254.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip host 216.x.x.196 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.0.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.1.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.2.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.3.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.4.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.5.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.6.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.7.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.8.0 255.255.255.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.9.0
Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
Hello Scott: That error is something not matching up in the Phase 1 portion. You should look at the ISAKMP values on both sides to make sure they match. Including, but not limited to, proposals, session key, lifetime values, DH Group, etc. Regards, Mike -- Michael K. Smith - CISSP, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) -Original Message- From: Scott Granados [mailto:gsgrana...@comcast.net] Sent: Thursday, September 03, 2009 10:41 AM To: Michael K. Smith - Adhost Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi Mike and others, still no love. I wanted to confirm I made the NAT entries properly. I used the example on Cisco.com for the ASA and l2l + clients as an example. Here are the important bits global (outside) 1 206.x.x.234 nat (inside) 0 access-list nonat nat (inside) 1 0.0.0.0 0.0.0.0 And nonat acl access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 192.168.122.0 255.255.255.192 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 157.254.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip host 216.x.x.196 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.0.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.1.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.2.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.3.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.4.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.5.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.6.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.7.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.8.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.9.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.10.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.15.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 192.168.255.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.11.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.12.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.13.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.16.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.192.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.224.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.225.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.226.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.227.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.228.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.229.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.230.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 192.168.122.0 255.255.255.192 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 157.254.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip host 216.x.x.196 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.18.0.0
Re: [c-nsp] mpls ldp sync
On Thu, 3 Sep 2009, jack daniels wrote: BUT now when I enable under ospf mpls ldp sync --- ospf neighbourship goes down and doesn't comes up. Request your help in this. Is LDP up between them? If not, then that's why. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] mpls ldp sync
Daniels - Did you configure on the Juniper side too ?? [mpls ldp sync] Are you running OSPF as IGP and which release on GSR ? Try changing the holddown timer to see if it makes a change. http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fsldpsyn.html#wp 1100282 /Shankar -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of jack daniels Sent: Thursday, September 03, 2009 10:28 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] mpls ldp sync I'm in middle of a issue , request your help in this issue - We have a GSR 12416 connected to JUNIPER router. We are running OSPF between them. OSPF neighbourship comes up :) BUT now when I enable under ospf mpls ldp sync --- ospf neighbourship goes down and doesn't comes up. Request your help in this. Regards J.Daniels ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Management stuff in VRFs
-Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jerome Durand Subject: Re: [c-nsp] Management stuff in VRFs We went in that direction in our latest deployment and discovered also that many pieces were missing in IOS and IOS-XR to have full management in a dedicated VRF for all our devices. At this stage we have the VRF but not all management goes there... so there is more complexity and network is no more secure... I must admit IOS-XR gives us more troubles as more management features are missing in VRF's. The most effective way to do this I've seen so far essentially turns your network inside out. The Global portion of the router is management, in RFC1918 space, and your internet/public IP's/traffic/etc are all carried in a dedicated VRF. Taking a production network NOT designed that way, and doing the inside-out... well that's every bit as hard as it sounds... ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
On Wed, Sep 02, 2009 at 02:42:31PM +0200, Peter Rathlev wrote: Agreed, and introducing DFCs can give you some headaches with e.g. policers, since each forwarding engine operates independently from the others. I guess here you're referring to the fact that there is no communication of ingress rates between individual DFCs, or back to the PFC? I posed this question to Cisco at a CPOC lab, and have also heard the same from TAC. Consider the following scenario: Two flows are ingress on a 6500, one on Gi1/0 (where slot 1 has a DFC), and one on Gi2/0 (where slot 2 also has a DFC). They are egress on a third port Gi3/0, which also has a DFC. Since the policing is performed by the ingress LC, if Gi3/0 has a 50Mbps policer, and the flows at Gi1/0 and Gi2/0 are both 40Mbps, neither card will drop any packets, and hence the egress rate at port Gi3/0 is 80Mbps, despite having a 50Mbps policer configured. Unfortunately, I don't have the resources to test this - has anyone tried this scenario, and verified this is _actually_ how things work, rather than theoretically? (I think the official answer for this was...This will be fixed in EARL 8) Thanks, Rob -- Rob Shakir r...@eng.gxn.net Network Development EngineerGX Networks/Vialtus Solutions ddi: +44208 587 6077mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
Scott, A pointer for your ACLs, wrap up your secured networks into two object-groups. For example: Object-group network internal Network-object 10.1.0.0 255.255.0.0 Network-object 10.1.0.0 255.255.0.0 . Object-group network ny_nets Network-object 10.18.14.0 255.255.255.0 Then craft your interesting traffic ACL on the ASA to look something like this: Access-list vpn_ny permit ip object-group internal object-group ny_nets Access-list nonat permit ip object-group internal object-group ny_nets Any future changes are done at the object-groups and will be immediately reflected in your interesting traffic ACL and nonat ACL. As Michael has said, the error can be a number of things, I would start with the crypto key though. A lot of the ISAKMP settings (at least in the ASA) are part of the default config and cover just about every common Phase1 setting. From the ASA, issue a 'show cry isa sa detail' and check out the entry that corresponds with your PIX endpoint. Post the results of that once you've got a stream of interesting traffic going from the ASA to the PIX. If possible post the debug results from the PIX to the ASA with the settings that I mentioned earlier, if there is a key mismatch, you'll see that error on the ASA side. In case you're curious, this is the 7.2.4 bug I was referring to as well, it exists through 7.2.4(18): http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetailsbugId=CSCsq91271 -ryan -Original Message- Scott, Can you provide debugs from the ASA, code versions on both devices and your associated no-nat ACLs? Assuming you have nothing else logging to monitor, you can enable 'logging class vpn monitor debug' and throw up a term mon to gather inbound messages to the ASA from the PIX side. You can gather the information on the PIX with a debug cry isa 2 and then initiate interesting traffic from the ASA using the following, the more valuable information will be on the receiving end. It really doesn't matter which side you enable as the receiver, but I try to stay away from pre 7.x code on the PIXes. packet-tracer input inside icmp 10.1.0.10 8 0 10.18.15.10 detailed Phase: 10 or 11 should be subtype encrypt. If it fails the first time, run it again, the negotiation process causes the first packet to fail as the tunnel is being brought. This type of traffic will also give you your debug information and help you figure out where the failure is. -ryan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
Ah interesting. So the lifetimes have to be the same, I thought it negotiated to the lowest value. I will go through and check these. Thank you again! - Original Message - From: Michael K. Smith - Adhost mksm...@adhost.com To: Scott Granados gsgrana...@comcast.net Cc: cisco-nsp@puck.nether.net Sent: Thursday, September 03, 2009 10:57 AM Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hello Scott: That error is something not matching up in the Phase 1 portion. You should look at the ISAKMP values on both sides to make sure they match. Including, but not limited to, proposals, session key, lifetime values, DH Group, etc. Regards, Mike -- Michael K. Smith - CISSP, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) -Original Message- From: Scott Granados [mailto:gsgrana...@comcast.net] Sent: Thursday, September 03, 2009 10:41 AM To: Michael K. Smith - Adhost Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi Mike and others, still no love. I wanted to confirm I made the NAT entries properly. I used the example on Cisco.com for the ASA and l2l + clients as an example. Here are the important bits global (outside) 1 206.x.x.234 nat (inside) 0 access-list nonat nat (inside) 1 0.0.0.0 0.0.0.0 And nonat acl access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 192.168.122.0 255.255.255.192 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 157.254.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip host 216.x.x.196 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.0.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.1.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.2.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.3.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.4.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.5.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.6.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.7.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.8.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.9.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.10.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.15.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 192.168.255.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.11.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.12.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.13.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.16.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.192.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.224.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.225.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.226.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.227.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.228.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.229.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.230.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.15.0
[c-nsp] HWIC-1ADSL-M
Hi, Reading through the specs for the above card Cisco mentions not supporting UK Mask. Does this mean the card doesn't work for ADSL-M (Seemingly often branded as SDSL-M) in the UK? We're looking at getting some SDSL-M circuits to see what they're like, from Spitfire and Nildram (Tiscali), anybody using either HWIC-1ADSL-M or C877-M with those providers Annex M services? Anybody using the above products with any Annex-M products in the UK? Any info would be great, as these products are fairly new Google doesn't turn up anything and the Cisco kit is not on the published lists of compatible CPE equipment. Alex -- This message has been scanned for viruses and dangerous content by AxTech, and is believed to be clean. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
Hi Scott: They will set to the lowest, but it's always a good idea for everything to match. Mike -- Michael K. Smith - CISSP, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) -Original Message- From: Scott Granados [mailto:gsgrana...@comcast.net] Sent: Thursday, September 03, 2009 12:09 PM To: Michael K. Smith - Adhost Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Ah interesting. So the lifetimes have to be the same, I thought it negotiated to the lowest value. I will go through and check these. Thank you again! - Original Message - From: Michael K. Smith - Adhost mksm...@adhost.com To: Scott Granados gsgrana...@comcast.net Cc: cisco-nsp@puck.nether.net Sent: Thursday, September 03, 2009 10:57 AM Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hello Scott: That error is something not matching up in the Phase 1 portion. You should look at the ISAKMP values on both sides to make sure they match. Including, but not limited to, proposals, session key, lifetime values, DH Group, etc. Regards, Mike -- Michael K. Smith - CISSP, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) -Original Message- From: Scott Granados [mailto:gsgrana...@comcast.net] Sent: Thursday, September 03, 2009 10:41 AM To: Michael K. Smith - Adhost Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi Mike and others, still no love. I wanted to confirm I made the NAT entries properly. I used the example on Cisco.com for the ASA and l2l + clients as an example. Here are the important bits global (outside) 1 206.x.x.234 nat (inside) 0 access-list nonat nat (inside) 1 0.0.0.0 0.0.0.0 And nonat acl access-list nonat extended permit ip 10.1.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.11.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.64.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.66.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 141.11.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 192.168.122.0 255.255.255.192 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 157.254.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip host 216.x.x.196 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.0.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.1.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.2.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.3.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.4.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.5.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.6.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.7.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.8.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.9.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.10.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.15.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.15.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.32.0.0 255.240.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 192.168.255.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 172.30.0.0 255.255.0.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.11.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.12.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.13.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.18.16.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.192.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.224.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.225.0 255.255.255.0 10.18.14.0 255.255.255.0 access-list nonat extended permit ip 10.1.226.0 255.255.255.0 10.18.14.0
[c-nsp] Options for customer prefix injection into iBGP at the edge
I'm soliciting suggestions on the pros and cons on the assortment of ways to inject customer routes into iBGP at the edge. One could simply reference prefix-lists in the BGP config on a per-neighbor basis (or peer-group). The downside to this is that prefix-lists can't haven't inline comments for storing information about the individual prefixes. As the prefixes on the edge grow I would think that admin overhead and potential for errors would grow as well. I could reference route-maps in the BGP config as well (per neighbor/peer-group). I'm doing this today, matching against a prefix-list to get my routes. The upside is I add a new sequence to the route-map per customer and create a uniquely-named prefix-list per customer. This of course requires more config and more potential typos but makes changes as customers come and go much more clearcut (ie, there is no question which prefixes belong to which customer). Another upside is that I can also put specific communities on prefixes with a route-map. I'm not doing this today but I plan to in the future as my BGP community design progresses. A third option is redistributing statics into BGP. This gives me the opportunity to tag specific prefixes and filter them with a route-map so I only redistribute the prefixes that I want redistributed. I can also name static routes. I need a static route anyway to tack up the route for outbound advertisement and to prevent loops. The downside is that I hate using redistribution. I'm not a big fan of it. I've been bit too many times to consider redistribution a good method of doing anything. It will also result in higher CPU load as the RIB is frequently parsed for statics and processed with the route-map if I'm not mistaken. Correct? A fourth option would be to use distribute-lists. I can use remarks to label my individual prefixes in the ACL which is good but I end up with one large distribute-list ACL for all my customer prefixes. That means any errors could affect all customers at once. I also don't end up using route-maps so I don't get to set communities on advertised prefixes. And finally I could use a combination of any of the above to accomplish my goals. What methods do my SP colleagues prefer to use when managing the injection of customer routes into iBGP? I'm open to suggestions. I've tried both of the first 2 options and lean towards the 2nd. It's time I get the remaining customer routes out of the IGP but unfortunately I can't see far enough ahead to decide which method is best. I can't help but to think that there must be a better way to accomplish my goals without increasing my work load too much and without increasing the likelihood of making major mistakes. Thanks Justin ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] HWIC-1ADSL-M
On Thu Sep 03, 2009 at 07:16:27PM +0100, Alex Pimperton wrote: Reading through the specs for the above card Cisco mentions not supporting UK Mask. Does this mean the card doesn't work for ADSL-M (Seemingly often branded as SDSL-M) in the UK? ADSL and SDSL are two very different things. HWIC-1ADSL-M will do ADSL2+, but probably not SDSL. We're looking at getting some SDSL-M circuits to see what they're like, from Spitfire and Nildram (Tiscali), anybody using either HWIC-1ADSL-M or C877-M with those providers Annex M services? We sell ADSL2+ services in the UK using Be/O2 LLU tails, and they have approved bother the HWIC-1ADSL-M and the C877-M for their service. I'm using a C877-M right now. Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director|* Domain Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: i...@bogons.net * ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] IDSM-2 Module VS. TippingPoint VS. Other IDS solutions
Does anyone have any real world experience working with the IDSM-2 modules for the 6500 platform? I am specifically trying to find people whom have used both the IDSM-2 vs. TippingPoint and even Vs other IDS products... Any off-list or on-list anecdotes or opinions is highly appreciated. thanks, -Drew ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Options for customer prefix injection into iBGP at the edge
Hi, so if I were you I'd go with options 1-3 inclusive. use prefix lists inside route-maps to set the correct community and then have route-maps that act on these. Also redistribute static, connected, etc through and use a route-map to set the appropriate communities so something like... ip prefix list not-to-specific seq 5 permit 0.0.0.0/0 le 24 route-map transit1-in permit 10 match ip address prefix-list not-to-specific set community as:666 or for a customer ip prefix-list customera seq 5 permit 192.168.0.0/20 route-map customera-in seq 10 permit match ip address prefix-list customera set community as:115 You can also add in functions here to prepend your AS on a community tag, set local pref, etc. you would need to then just build your community lists so that they know what to do with the various tags (666, no export, 115, announce, etc) for your redistribution do the same match against your prefix list with your CIDR for announcements, against another prefix list which allows for longer prefixes for your internals (tag appropriately) and biggity bam you're set. Tag everything differently for example peering prefixes learned differently from transit and use the route-maps to apply the appropriate tag. This also removes the need for network statements in your BGP section and once in place greatly simplifies and I think in the end creates less room for fat finger errors. With the different tags you will find it very simple to provide customers what ever feed they wish whether it's customers only, customers + peers, customers plus peers + transit, full routes, etc. Thanks Scott - Original Message - From: Justin Shore jus...@justinshore.com To: 'Cisco-nsp' cisco-nsp@puck.nether.net Sent: Thursday, September 03, 2009 12:31 PM Subject: [c-nsp] Options for customer prefix injection into iBGP at the edge I'm soliciting suggestions on the pros and cons on the assortment of ways to inject customer routes into iBGP at the edge. One could simply reference prefix-lists in the BGP config on a per-neighbor basis (or peer-group). The downside to this is that prefix-lists can't haven't inline comments for storing information about the individual prefixes. As the prefixes on the edge grow I would think that admin overhead and potential for errors would grow as well. I could reference route-maps in the BGP config as well (per neighbor/peer-group). I'm doing this today, matching against a prefix-list to get my routes. The upside is I add a new sequence to the route-map per customer and create a uniquely-named prefix-list per customer. This of course requires more config and more potential typos but makes changes as customers come and go much more clearcut (ie, there is no question which prefixes belong to which customer). Another upside is that I can also put specific communities on prefixes with a route-map. I'm not doing this today but I plan to in the future as my BGP community design progresses. A third option is redistributing statics into BGP. This gives me the opportunity to tag specific prefixes and filter them with a route-map so I only redistribute the prefixes that I want redistributed. I can also name static routes. I need a static route anyway to tack up the route for outbound advertisement and to prevent loops. The downside is that I hate using redistribution. I'm not a big fan of it. I've been bit too many times to consider redistribution a good method of doing anything. It will also result in higher CPU load as the RIB is frequently parsed for statics and processed with the route-map if I'm not mistaken. Correct? A fourth option would be to use distribute-lists. I can use remarks to label my individual prefixes in the ACL which is good but I end up with one large distribute-list ACL for all my customer prefixes. That means any errors could affect all customers at once. I also don't end up using route-maps so I don't get to set communities on advertised prefixes. And finally I could use a combination of any of the above to accomplish my goals. What methods do my SP colleagues prefer to use when managing the injection of customer routes into iBGP? I'm open to suggestions. I've tried both of the first 2 options and lean towards the 2nd. It's time I get the remaining customer routes out of the IGP but unfortunately I can't see far enough ahead to decide which method is best. I can't help but to think that there must be a better way to accomplish my goals without increasing my work load too much and without increasing the likelihood of making major mistakes. Thanks Justin ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net
Re: [c-nsp] Management stuff in VRFs
Thank you all for the reponses. As many replies point out, and as many previous threads bear witness to, the current implementations of IOS lack full support for a seperate management VRF. This alone made me curious why people still push in that direction. Generally I assume that some kind of OoB management is best practice already; the typical setup where I'm from is a terminal server of some kind (e.g. Cisco 2512) in each PoP and some octopus cables reaching out to all the console ports. This is for emergencies though, not for production, i.e. not for Netflow, TACACS+ and so on. A management network in a seperate VRF will not in itself give anyone emergency access to devices. I could imagine obscure software bugs that would actually hinder this access instead. And even though using seperate physical interfaces is much easier with an isolated VRF it is not a prerequisite, and without that some of the arguments for the VRF fall apart IMHO. Seperating non-business traffic (like Netflow, TACACS+, syslog) from business traffic is idealogically a good idea. If you extend this thought we would actually end up with a seperate set of interfaces for _everything_ which is not customer traffic, including IGP and BGP (and LDP for those so inclined). Or am I crossing a line here? And for the record: Yes, poor me, I have no real SP experience, having only worked with enterprise networks. We use exactly what Donn describes: A lean global table with all user traffic carried as MPLS. /Peter (... off to the purgatory for top posting, sorry. :-)) On Thu, 2009-09-03 at 10:42 -0700, Lasher, Donn wrote: -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jerome Durand Subject: Re: [c-nsp] Management stuff in VRFs We went in that direction in our latest deployment and discovered also that many pieces were missing in IOS and IOS-XR to have full management in a dedicated VRF for all our devices. At this stage we have the VRF but not all management goes there... so there is more complexity and network is no more secure... I must admit IOS-XR gives us more troubles as more management features are missing in VRF's. The most effective way to do this I've seen so far essentially turns your network inside out. The Global portion of the router is management, in RFC1918 space, and your internet/public IP's/traffic/etc are all carried in a dedicated VRF. Taking a production network NOT designed that way, and doing the inside-out... well that's every bit as hard as it sounds... ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Management stuff in VRFs
On Sep 4, 2009, at 4:34 AM, Peter Rathlev wrote: we would actually end up with a seperate set of interfaces for _everything_ which is not customer traffic, including IGP and BGP (and LDP for those so inclined). Divorcing the control plane from dependence upon the data plane would be a huge win in terms of security/availability. It's unfortunate that the routing protocols currently in use weren't designed for this mode of operation from the start. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] (no subject)
___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
