Re: [c-nsp] slow down VTY speed
Hi,
--- On Tue, 1/9/09, Pierfrancesco Caci p.c...@seabone.net wrote:
We had a situation in the past where rancid would cause
some 72xx and
75xx to crawl and sometime crash when accessing the disks..
You
may want to check if that's the case and comment out the
offending
command in @commandtable (around line 1700 of
/usr/lib/rancid/bin/rancid)
Thanks for the pointer. I had a look and the @commandtable array contains the
following three lines:
{'more system:running-config' = 'WriteTerm'},
{'show running-config' = 'WriteTerm'},
{'write term' = 'WriteTerm'},
Which I assume are to make sure it can get the config from multiple different
types and versions of Cisco devices. All of these commands work on a 7204
(which means it was getting the config three times I think), so I've commented
out two of them so it's only executing a single show run command.
This seems to have helped quite a lot with the OSPF timeouts. I've cranked up
RANCID to run every 10 minutes to flog the poor box to death and see if it will
definitely not interfere with OSPF now. If it still does then I'll have to drop
back to 2 second hello intervals which should definitely resolve all of the
problems.
Thanks for the suggestion of changing the scheduler allocate parameters Gert.
I went and read some documentation and tried changing it around a bit but it
didn't appear to have any beneficial effects at all ?
One thing that I've just discovered that puzzles me is that the OSPF neighbour
drops are only on ONE of the links that come into this 7204. It has neighbours
on the interfaces Fa0/0.3, Atm1/0.2 Atm1/0..3. It is only the neighbour on
the Fa0/0.3 interface that is dropping, the two connected via ATM are not
dropping at all. Is there any logical reason for this ? Is it because I'm using
the 10/100 port on the I/O module ? Would it be any different if the ethernet
interface was on a PA instead ?
Thanks,
Tony.
__
Find local businesses and services in your area with Yahoo!7 Local.
Get started: http://local.yahoo.com.au
___
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] MCS7816 Communication Manager
Hello all, I need your support on this if you may came across it. Company is planing to deploy IP telephony in the network covering 2 remote sites and head quarter. here is my plan: 85pcs x CP-3911 (Cisco SIP Phone 3911) 1pcs x MCS7816H3-K9-CMB1 (Unified CM 6.0 7816-H3 Appliance, 0 Seats) 2pcs x LIC-CM-DL-100= 1pcs x LIC-CM6.0-7816= (License Unified CM 6.0 7816 Appliance, 500 seats) My question is this: 1. What is the DLU for CP-3911 (Cisco SIP Phone 3911) device? Based on that I can calculate number of LIC-CM-DL-100= license 2. What is LIC-CM6.0-7816=(License Unified CM 6.0 7816 Appliance, 500 seats) license, is it the one for CM application software license. Because I got this line from the Communication Manager v6.0 documentation. Application and phone software licenses are enforced. 3. Is there any other LIC-CM6.0-7816= license which has few seats, maybe around 100. By the way, what is a seat here. Seat, does that mean the total number that Comunication manager can manage upto? 4. If I go for Unified CM v7.1 then what is the part number for that with MCS appliance? thank you in advance. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Leaking specific routes from a VRF
Hi all, I am interested too in this issue. Can you send some code as an example to see how it works? ___ 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] Leaking specific routes from a VRF
Hi all, ip vrf 1204 rd 11:1157 export map EXPORT route-target export 111:1048 ip prefix-list EXPORTseq 5 deny 0.0.0.0/0 ip prefix-list EXPORT seq 10 permit 84.233.160.160/30 route-map EXPORT permit 10 match ip address prefix-list EXPORT set extcommunity rt 111:1 additive Regards Tomas Dne 02/09/2009 11:05, luismi napsal(a): Hi all, I am interested too in this issue. Can you send some code as an example to see how it works? ___ 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] Leaking specific routes from a VRF
Many thanks :-D ___ 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 877w - Unable to NAT traffic for remote IPSec Sites
Hello All, I am trying to configure a Cisco 877w to act as a IPSec tunnel concentrator and provide Internet breakout for the remote sites.The router is running c870-advsecurityk9-mz.124-15.T5.bin. The solution currently comprises of seven Speedtouch 608WL routers with the default route set to go over the IPSec tunnel. ST 608wl -IPSec---| | | Cisco 877 | Internet ST 608wl -IPSec---| | I have configured the IPSec tunnel and I am able to get traffic between the sites however the Cisco router is not performing NAT for the remote sites. The relevant sections of the configuration are :- crypto isakmp policy 1 encr 3des hash md5 authentication pre-share group 2 lifetime 3600 crypto isakmp key test123 address 1.1.1.1 crypto isakmp key test123 address 2.2.2.2 crypto isakmp key test123 address 3.3.3.3 crypto isakmp key test123 address 4.4.4.4 crypto isakmp key test123 address 5.5.5.5 crypto isakmp key test123 address 6.6.6.6 crypto isakmp key test123 address 7.7.7.7 ! ! crypto ipsec transform-set TRANSFORM esp-3des esp-md5-hmac ! crypto map VPN 10 ipsec-isakmp set peer 1.1.1.1 set transform-set TRANSFORM set pfs group2 match address 115 crypto map VPN 20 ipsec-isakmp set peer 2.2.2.2 set transform-set TRANSFORM set pfs group2 match address 125 crypto map VPN 30 ipsec-isakmp set peer 3.3.3.3 set transform-set TRANSFORM set pfs group2 match address 135 crypto map VPN 40 ipsec-isakmp set peer 4.4.4.4 set transform-set TRANSFORM set pfs group2 match address 145 crypto map VPN 50 ipsec-isakmp set peer 5.5.5.5 set transform-set TRANSFORM set pfs group2 match address 155 crypto map VPN 60 ipsec-isakmp set peer 6.6.6.6 set transform-set TRANSFORM set pfs group2 match address 165 crypto map VPN 70 ipsec-isakmp set peer 7.7.7.7 set transform-set TRANSFORM set pfs group2 match address 175 ! ! interface Dialer0 ip address negotiated ip nat outside ip virtual-reassembly encapsulation ppp dialer pool 1 dialer idle-timeout 0 dialer persistent dialer-group 1 no cdp enable ppp authentication chap callin ppp chap hostname xyz...@abc ppp chap password 0 xxx crypto map VPN ! ! interface BVI1 description Customer Network ip address 192.168.20.1 255.255.255.0 ip nat inside ip virtual-reassembly ! ! ip route 0.0.0.0 0.0.0.0 Dialer0 ! ! ip nat pool CUST-NATPOOL 82.70.186.30 82.70.186.30 netmask 255.255.255.248 ip nat inside source route-map NONAT pool CUST-NATPOOL overload ! ! route-map NONAT permit 10 match ip address 110 ! ! access-list 110 deny ip 192.168.20.0 0.0.0.255 192.168.1.0 0.0.0.255 access-list 110 deny ip 192.168.20.0 0.0.0.255 192.168.2.0 0.0.0.255 access-list 110 deny ip 192.168.20.0 0.0.0.255 192.168.3.0 0.0.0.255 access-list 110 deny ip 192.168.20.0 0.0.0.255 192.168.4.0 0.0.0.255 access-list 110 deny ip 192.168.20.0 0.0.0.255 192.168.5.0 0.0.0.255 access-list 110 deny ip 192.168.20.0 0.0.0.255 192.168.6.0 0.0.0.255 access-list 110 deny ip 192.168.20.0 0.0.0.255 192.168.7.0 0.0.0.255 access-list 110 deny ip 192.168.20.0 0.0.0.255 10.10.0.0 0.0.1.255 access-list 110 permit ip 192.168.0.0 0.0.255.255 any access-list 115 permit ip any 192.168.1.0 0.0.0.255 access-list 125 permit ip any 192.168.2.0 0.0.0.255 access-list 135 permit ip any 192.168.3.0 0.0.0.255 access-list 145 permit ip any 192.168.4.0 0.0.0.255 access-list 155 permit ip any 192.168.5.0 0.0.0.255 access-list 165 permit ip any 192.168.6.0 0.0.0.255 access-list 175 permit ip any 192.168.7.0 0.0.0.255 I am able see traffic from the spoke sites match ACL 110 permit statement and also 115 but no entries are created in the NAT table . Do you have any ideas on where I might be going wrong ? Regards Christopher Varley ___ 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] do i *need* DFCs on the 6500?
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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] VPN traffic to the Internet ...
After trying to get this to work for a while, I'm somewhat out of ideas ... I have a (otherwise working) VPN-connection from Windows clients (using Cisco VPN client) to an ASA, IP traffic from and to the internal network is working just fine. Now the problem comes up that the clients need to reach a site on the internet that is only accessable from certain IP ranges, which the mobile clients do not fall into. I thought, well, no problem, just extend the split tunneling to the destination IP. So far, so good, the client lists the destination in its list of tunneled IPs, and traffic to the destination is correctly sent through the tunnel. It is also correctly decoded on the ASA, but doesn't seem to go anywhere ... I've made sure that there's an internal rule allowing any access to that certain IP. I've also did a tcpdump on the destination to check if maybe the traffic isn't NATed correctly, but not a single packet is arriving through the ASA ... What am I missing here? Tnx, -garry ___ 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, 2 Sep 2009, Alan Buxey wrote: 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? You're probably thinking of show mls statistics. 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'd say that if you're not hitting over 10MPPS on the CFC, you don't really need DFC. -- 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] VPN traffic to the Internet ...
nat (outside) 1 VPN range and Same-security intrainterface. Sent from handheld. On Sep 2, 2009, at 8:05 AM, Garry g...@gmx.de wrote: After trying to get this to work for a while, I'm somewhat out of ideas ... I have a (otherwise working) VPN-connection from Windows clients (using Cisco VPN client) to an ASA, IP traffic from and to the internal network is working just fine. Now the problem comes up that the clients need to reach a site on the internet that is only accessable from certain IP ranges, which the mobile clients do not fall into. I thought, well, no problem, just extend the split tunneling to the destination IP. So far, so good, the client lists the destination in its list of tunneled IPs, and traffic to the destination is correctly sent through the tunnel. It is also correctly decoded on the ASA, but doesn't seem to go anywhere ... I've made sure that there's an internal rule allowing any access to that certain IP. I've also did a tcpdump on the destination to check if maybe the traffic isn't NATed correctly, but not a single packet is arriving through the ASA ... What am I missing here? Tnx, -garry ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] SXI, TACACS+ in VRF
Hi, anyone using TACACS+ authentication from VRF in SXI successfully? We have login authentication/authorization working, but for enable authentication the box somehow fails to connect to the TACACS+ server. ! aaa group server tacacs+ XXX_tacacs server-private x.x.29.142 key ... ip vrf forwarding mgmt ip tacacs source-interface Loopback1 ! aaa authentication login XXX group XXX_tacacs local aaa authentication enable default group XXX_tacacs enable ... ! ... Aug 28 17:00:37.285: AAA/AUTHOR: auth_need : user= 'user' ruser= 'BA_MN1_CO'rem_addr= 'x.x.251.101' priv= 0 list= '' AUTHOR-TYPE= 'command' Aug 28 17:00:37.285: AAA: parse name=tty2 idb type=-1 tty=-1 Aug 28 17:00:37.285: AAA: name=tty2 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=2 channel=0 Aug 28 17:00:37.285: AAA/MEMORY: create_user (0xF7E8CF8) user='user' ruser='NULL' ds0=0 port='tty2' rem_addr='x.x.251.101' authen_type=ASCII service=ENABLE priv=15 initial_task_id='0', vrf= (id=0) Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): port='tty2' list='XXX' action=LOGIN service=ENABLE Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): using default list Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): Method=XXX_tacacs (tacacs+) Aug 28 17:00:37.285: TAC+: send AUTHEN/START packet ver=192 id=-16528696 Aug 28 17:00:37.285: TAC+: Opening TCP/IP to x.x.29.142/49 timeout=5 Aug 28 17:00:37.289: TAC+: TCP/IP open to x.x.29.142/49 failed -- Destination unreachable; gateway or host down Aug 28 17:00:37.289: AAA/AUTHEN (4278438600): status = ERROR Aug 28 17:00:37.289: AAA/AUTHEN/START (4278438600): Method=ENABLE Aug 28 17:00:37.289: AAA/AUTHEN (4278438600): status = GETPASS Aug 28 17:00:45.021: AAA/AUTHEN/CONT (4278438600): continue_login (user='(undef)') Aug 28 17:00:45.021: AAA/AUTHEN (4278438600): status = GETPASS Aug 28 17:00:45.021: AAA/AUTHEN/CONT (4278438600): Method=ENABLE Aug 28 17:00:45.025: AAA/AUTHEN (4278438600): password incorrect Aug 28 17:00:45.025: AAA/AUTHEN (4278438600): status = FAIL thx -- deejay __ Informacia od ESET NOD32 Antivirus, verzia databazy 4388 (20090902) __ 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?
You eluded to one of my strongest selling points on DFCs though I don't think you made that particular connection yet. DFCs offload QoS to the LC as you said. That also means that CoPP is also handled in hardware if you have DFCs in place since it requires MLS QoS on that platform. Ie, if your 6500/7600 is going to be publicly-accessible on the Internet in any capacity and you want it to be able to use CoPP to withstand a targeted DoS attack then DFCs are not optional, they're critical. The others on the list can probably give you much more in-depth views on the other aspects of the card but I found CoPP to be a big enough selling point. It wouldn't be good is a simple little DoS attack took down my core 7600s. Justin Alan Buxey 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-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] do i *need* DFCs on the 6500?
On Wed, 2009-09-02 at 14:04 +0200, Mikael Abrahamsson wrote: On Wed, 2 Sep 2009, Alan Buxey wrote: 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'd say that if you're not hitting over 10MPPS on the CFC, you don't really need DFC. Agreed, and introducing DFCs can give you some headaches with e.g. policers, since each forwarding engine operates independently from the others. Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
Not to thread hijack here, but speaking of withstanding DoS attacks, has anyone seen any decent published baseline configurations for CoPP to deflect things similar to TTL Expiry attacks and the like? Perhaps some sort of template they use (if they can share it) would be really nice. I would just like to see what others are doing. -Drew -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Justin Shore Sent: Wednesday, September 02, 2009 8:40 AM To: Alan Buxey Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] do i *need* DFCs on the 6500? You eluded to one of my strongest selling points on DFCs though I don't think you made that particular connection yet. DFCs offload QoS to the LC as you said. That also means that CoPP is also handled in hardware if you have DFCs in place since it requires MLS QoS on that platform. Ie, if your 6500/7600 is going to be publicly-accessible on the Internet in any capacity and you want it to be able to use CoPP to withstand a targeted DoS attack then DFCs are not optional, they're critical. The others on the list can probably give you much more in-depth views on the other aspects of the card but I found CoPP to be a big enough selling point. It wouldn't be good is a simple little DoS attack took down my core 7600s. Justin Alan Buxey 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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Monitoring CPU usage on a Sup720-3BXL (BGP)
Actually no, bgp scanner has nothing to do with platform architecture of packet forwarding of any kind (hardware or otherwise). It is an entirely software mechanism which periodically walks the entire bgp table and does things like verify next-hop reachability. Distributing the operations that it performs so that they happen when a prefix or next-hop changes is a much better way to handle things (improves convergence and reduces the periodic cpu spikes), but you'll probably never see it go away completely. :) -- I didn't assume the actual process BGP scanner would go away, I was simply wondering why as everything (Moore's law) gets much, much faster, this process still has such a impact on the even highest end RPs. I would assume that the utilization impact on the RP would go down as the $$$ of the hardware goes up, but I suppose if it all runs in software and isn't using the features of the more expensive RPs then it will just be slow forever ;-) I guess you can liken it to a PC without discrete graphics, you can have the best CPU in the world but if you are rendering polys in software, it's still going to chug. -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] SXI, TACACS+ in VRF
did you tried test aaa command? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Monitoring CPU usage on a Sup720-3BXL (BGP)
e ninja wrote: Richard, On the contrary, as I stated below, the 'impact' of BGP scanner (a housekeeping task executed by the main processor) on 'system' performance will continue to diminish as more platforms become modular (distributed architecture) and/or switch packets in hardware (i.e, independent of RP and LC CPU eg in FPGAs) Nothing in the aforementioned suggests that BGP scanner (a critical process for validating the integrity of the BGP table) will EoL anytime soon. Instead, if you note the quotes, Drew is concerned with the impact of the CPU consumed by BGP scanner on 'system' performance. This concern does not exist on modular platforms with distributed packet switching (c12k, hfr etc.) that switch packets independent of main RP CPU. Put simply, even if BGP scanner maxes out an RP CPU at 100% temporarily on a distributed platform, it will have zero effect on packet switching (a la 'system' perf) through the device. Your thoughts below dwell more on enhancing the mechanism to reduce frequency. - Yes, but the confusion in (my mind, anyway) is that sometimes when the RP is at high CPU utilization forwarding performance is affected. i.e. in the case of a DoS attack, although I suppose that the RP being at high CPU utilization is a 'by-product' of the forwarding hardware punting so much crap to the RP and not vice-versa. So when monitoring the CPU for these kinds of events it can be hard to tell in a programmatic way whether it's just BGP scanner, or something more nefarious like a TTL Expiration attack, or any of the other 700 types of DoS/DDoS style attacks which take place these days. I suppose the real question is, what do you monitor on a modular/distributed system in order to gauge the performance, if not the CPU on the Route Processor? are there OIDs for the discrete switching/forwarding engines? I know at least on the GSR platform each line card has its own CPU/memory statistics available, which is at least ??somewhat?? helpful in quickly identifying a problem. -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] SXI, TACACS+ in VRF
I've managed to work it around in lab by creating a leaked route to the TAC+ server in the GRT via the management interface. Funny enough, the switch does not mind sending its packets out GRT and receiving via VRF. I'll request a ddts tomorrow. -- deejay -Original Message- From: Arne Larsen / Region Nordjylland [mailto:a...@rn.dk] Sent: Wednesday, September 02, 2009 4:05 PM To: Daniska, Tomas; cisco-nsp@puck.nether.net Subject: SV: SXI, TACACS+ in VRF I've got a similar problem with Nexus 5000. /Arne Fra: cisco-nsp-boun...@puck.nether.net [cisco-nsp- boun...@puck.nether.net] P#229; vegne af Daniska, Tomas [to...@soitron.com] Sendt: 2. september 2009 14:20 Til: cisco-nsp@puck.nether.net Emne: [c-nsp] SXI, TACACS+ in VRF Hi, anyone using TACACS+ authentication from VRF in SXI successfully? We have login authentication/authorization working, but for enable authentication the box somehow fails to connect to the TACACS+ server. ! aaa group server tacacs+ XXX_tacacs server-private x.x.29.142 key ... ip vrf forwarding mgmt ip tacacs source-interface Loopback1 ! aaa authentication login XXX group XXX_tacacs local aaa authentication enable default group XXX_tacacs enable ... ! ... Aug 28 17:00:37.285: AAA/AUTHOR: auth_need : user= 'user' ruser= 'BA_MN1_CO'rem_addr= 'x.x.251.101' priv= 0 list= '' AUTHOR-TYPE= 'command' Aug 28 17:00:37.285: AAA: parse name=tty2 idb type=-1 tty=-1 Aug 28 17:00:37.285: AAA: name=tty2 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=2 channel=0 Aug 28 17:00:37.285: AAA/MEMORY: create_user (0xF7E8CF8) user='user' ruser='NULL' ds0=0 port='tty2' rem_addr='x.x.251.101' authen_type=ASCII service=ENABLE priv=15 initial_task_id='0', vrf= (id=0) Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): port='tty2' list='XXX' action=LOGIN service=ENABLE Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): using default list Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): Method=XXX_tacacs (tacacs+) Aug 28 17:00:37.285: TAC+: send AUTHEN/START packet ver=192 id=- 16528696 Aug 28 17:00:37.285: TAC+: Opening TCP/IP to x.x.29.142/49 timeout=5 Aug 28 17:00:37.289: TAC+: TCP/IP open to x.x.29.142/49 failed -- Destination unreachable; gateway or host down Aug 28 17:00:37.289: AAA/AUTHEN (4278438600): status = ERROR Aug 28 17:00:37.289: AAA/AUTHEN/START (4278438600): Method=ENABLE Aug 28 17:00:37.289: AAA/AUTHEN (4278438600): status = GETPASS Aug 28 17:00:45.021: AAA/AUTHEN/CONT (4278438600): continue_login (user='(undef)') Aug 28 17:00:45.021: AAA/AUTHEN (4278438600): status = GETPASS Aug 28 17:00:45.021: AAA/AUTHEN/CONT (4278438600): Method=ENABLE Aug 28 17:00:45.025: AAA/AUTHEN (4278438600): password incorrect Aug 28 17:00:45.025: AAA/AUTHEN (4278438600): status = FAIL thx -- deejay __ Informacia od ESET NOD32 Antivirus, verzia databazy 4388 (20090902) __ 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/ __ Informacia od ESET NOD32 Antivirus, verzia databazy 4389 (20090902) __ Tuto spravu preveril ESET NOD32 Antivirus. http://www.eset.sk __ Informacia od ESET NOD32 Antivirus, verzia databazy 4389 (20090902) __ 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] Multiple power supply failures. Advise needed
What about the fact that most (if not all) power supplies have independent sucking fan and that power supply air flow is separate from the system board flow. Plus all system board I saw are covered with some insulating coating. I've never pulled apart a modern power supply. I'd expect them to have something like that too, but who knows? Plus since PSU is the only part that's dealing with high voltages I expect it to be more sensitive to momentary shorts. Am I wrong? I'm expecting report for provider ordered unintrusive power monitoring. I'm almost positive they won't find anything, though. I'm still looking for advice on independent power analysis source in New York, NY if anyone has this kind of experience. Thanks, Michael On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote: Plain old dust wouldn't be so picky...it has to be ingested past the system board before it hits the power supply in most cases. System boards are WAY more sensitive to this kind of thing. The fact you have ONLY PSU's failing still makes me think you have power issues. -- Randy www.FastServ.com -- Original Message --- From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: Scott Granados gsgrana...@comcast.net, Seth Mattinen se...@rollernet.us, cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 23:21:23 -0400 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed This is my main suspect now. They are doing work in the facility. Not heavy construction, but they do install cages and cabinets for new tenants and they're definitely using tools that produce metal dust. My theory is that because of we've been the 1st customer who moved into that facility we've been collecting that metal dust for longest and so we're having a lot of problems with our equipment. To my knowledge none of our neighbors are having the same problem, but none of them have been in the place long enough. So the question remains: is there any way to fight it/protect from it except from going through the huge-huge-huge headache of undertaking another move? Michael On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote: He mentioned he was one of the first customers in the colo so this might be a possibility -- Randy -- Original Message --- From: Scott Granados gsgrana...@comcast.net To: Seth Mattinen se...@rollernet.us, Michael Ulitskiy mulits...@acedsl.com Cc: cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 17:35:34 -0700 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed Also make sure that the provider isn't doing work in the facility. I'll never forget going to an L3 datacenter and arriving to find workmen in the overhead grinding away and dropping dust and who knows what else in to all the racks below including a rack of Netra T1's that promptly sucked in the dust and kicked out power supplies.;) It was definitely metal shavings because they were using a grinding type tool up in the over head frames. --- 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] do i *need* DFCs on the 6500?
On Sep 2, 2009, at 8:48 AM, Drew Weaver wrote: Not to thread hijack here, but speaking of withstanding DoS attacks, has anyone seen any decent published baseline configurations for CoPP to deflect things similar to TTL Expiry attacks and the like? Perhaps some sort of template they use (if they can share it) would be really nice. ttl expire can be protected with mls rate limiters. 10 100 seems plenty. - jared ___ 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, 2 Sep 2009, Alan Buxey wrote: is this a figure that can be quoted from somewhere? it seems a very useful pointer - I can easily graph this value (i hope!) via SNMP and therefore can see if/when we need the kit :-) 10 MPPS comes from worst case is 15 Mpps (two recycles in the 30Mpps CFC) and upgrade before it gets even close to that. -- 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] Multiple power supply failures. Advise needed
Plain old dust wouldn't be so picky...it has to be ingested past the system board before it hits the power supply in most cases. System boards are WAY more sensitive to this kind of thing. The fact you have ONLY PSU's failing still makes me think you have power issues. -- Randy www.FastServ.com -- Original Message --- From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: Scott Granados gsgrana...@comcast.net, Seth Mattinen se...@rollernet.us, cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 23:21:23 -0400 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed This is my main suspect now. They are doing work in the facility. Not heavy construction, but they do install cages and cabinets for new tenants and they're definitely using tools that produce metal dust. My theory is that because of we've been the 1st customer who moved into that facility we've been collecting that metal dust for longest and so we're having a lot of problems with our equipment. To my knowledge none of our neighbors are having the same problem, but none of them have been in the place long enough. So the question remains: is there any way to fight it/protect from it except from going through the huge-huge-huge headache of undertaking another move? Michael On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote: He mentioned he was one of the first customers in the colo so this might be a possibility -- Randy -- Original Message --- From: Scott Granados gsgrana...@comcast.net To: Seth Mattinen se...@rollernet.us, Michael Ulitskiy mulits...@acedsl.com Cc: cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 17:35:34 -0700 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed Also make sure that the provider isn't doing work in the facility. I'll never forget going to an L3 datacenter and arriving to find workmen in the overhead grinding away and dropping dust and who knows what else in to all the racks below including a rack of Netra T1's that promptly sucked in the dust and kicked out power supplies.;) It was definitely metal shavings because they were using a grinding type tool up in the over head frames. --- 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/
[c-nsp] parser config cache interface - stable/safe?
All, Is anyone running this? Is it stable/safe? How well does it interact with other features e.g. if I scp fragment ad...@router:running-config will it know that the interface cache in the fragment config is expired? Platform of interest is 6500/sup720 running 12.2(33)SXI ___ 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] Multiple power supply failures. Advise needed
You mentioned a couple servers failed -- most if not all servers power supplies blow outward, sucking air from inside the chassis. Many Cisco devices work this way also. I have rarely seen a power supply that sucks air in directly from the outside of the chassis. Given the above, much of the dust would settle on the system board. The extremely high tolerances of a typical system board far outweigh those of a power supply, thus I would expect system instability before the power supply failed. My bet is still on power spikes/dips. -- Randy www.FastServ.com -- Original Message --- From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: cisco-nsp@puck.nether.net Sent: Wed, 2 Sep 2009 11:08:24 -0400 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed What about the fact that most (if not all) power supplies have independent sucking fan and that power supply air flow is separate from the system board flow. Plus all system board I saw are covered with some insulating coating. I've never pulled apart a modern power supply. I'd expect them to have something like that too, but who knows? Plus since PSU is the only part that's dealing with high voltages I expect it to be more sensitive to momentary shorts. Am I wrong? I'm expecting report for provider ordered unintrusive power monitoring. I'm almost positive they won't find anything, though. I'm still looking for advice on independent power analysis source in New York, NY if anyone has this kind of experience. Thanks, Michael On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote: Plain old dust wouldn't be so picky...it has to be ingested past the system board before it hits the power supply in most cases. System boards are WAY more sensitive to this kind of thing. The fact you have ONLY PSU's failing still makes me think you have power issues. -- Randy www.FastServ.com -- Original Message --- From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: Scott Granados gsgrana...@comcast.net, Seth Mattinen se...@rollernet.us, cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 23:21:23 -0400 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed This is my main suspect now. They are doing work in the facility. Not heavy construction, but they do install cages and cabinets for new tenants and they're definitely using tools that produce metal dust. My theory is that because of we've been the 1st customer who moved into that facility we've been collecting that metal dust for longest and so we're having a lot of problems with our equipment. To my knowledge none of our neighbors are having the same problem, but none of them have been in the place long enough. So the question remains: is there any way to fight it/protect from it except from going through the huge-huge-huge headache of undertaking another move? Michael On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote: He mentioned he was one of the first customers in the colo so this might be a possibility -- Randy -- Original Message --- From: Scott Granados gsgrana...@comcast.net To: Seth Mattinen se...@rollernet.us, Michael Ulitskiy mulits...@acedsl.com Cc: cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 17:35:34 -0700 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed Also make sure that the provider isn't doing work in the facility. I'll never forget going to an L3 datacenter and arriving to find workmen in the overhead grinding away and dropping dust and who knows what else in to all the racks below including a rack of Netra T1's that promptly sucked in the dust and kicked out power supplies.;) It was definitely metal shavings because they were using a grinding type tool up in the over head frames. --- End of Original Message --- --- 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] do i *need* DFCs on the 6500?
Hi, On Wed, Sep 02, 2009 at 07:39:34AM -0500, Justin Shore wrote: You eluded to one of my strongest selling points on DFCs though I don't think you made that particular connection yet. DFCs offload QoS to the LC as you said. That also means that CoPP is also handled in hardware if you have DFCs in place since it requires MLS QoS on that platform. Ie, if your 6500/7600 is going to be publicly-accessible on the Internet in any capacity and you want it to be able to use CoPP to withstand a targeted DoS attack then DFCs are not optional, they're critical. Why? Wouldn't the Sup PFC handle CoPP-in-hardware if you have no DFCs? (Assuming that the total incoming packet volume is still inside the bounds that the PFC can handle) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpjz6TOSr74E.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] SXI, TACACS+ in VRF
I’ve got a similar problem with Nexus 5000. /Arne Fra: cisco-nsp-boun...@puck.nether.net [cisco-nsp-boun...@puck.nether.net] P#229; vegne af Daniska, Tomas [to...@soitron.com] Sendt: 2. september 2009 14:20 Til: cisco-nsp@puck.nether.net Emne: [c-nsp] SXI, TACACS+ in VRF Hi, anyone using TACACS+ authentication from VRF in SXI successfully? We have login authentication/authorization working, but for enable authentication the box somehow fails to connect to the TACACS+ server. ! aaa group server tacacs+ XXX_tacacs server-private x.x.29.142 key ... ip vrf forwarding mgmt ip tacacs source-interface Loopback1 ! aaa authentication login XXX group XXX_tacacs local aaa authentication enable default group XXX_tacacs enable ... ! ... Aug 28 17:00:37.285: AAA/AUTHOR: auth_need : user= 'user' ruser= 'BA_MN1_CO'rem_addr= 'x.x.251.101' priv= 0 list= '' AUTHOR-TYPE= 'command' Aug 28 17:00:37.285: AAA: parse name=tty2 idb type=-1 tty=-1 Aug 28 17:00:37.285: AAA: name=tty2 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=2 channel=0 Aug 28 17:00:37.285: AAA/MEMORY: create_user (0xF7E8CF8) user='user' ruser='NULL' ds0=0 port='tty2' rem_addr='x.x.251.101' authen_type=ASCII service=ENABLE priv=15 initial_task_id='0', vrf= (id=0) Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): port='tty2' list='XXX' action=LOGIN service=ENABLE Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): using default list Aug 28 17:00:37.285: AAA/AUTHEN/START (4278438600): Method=XXX_tacacs (tacacs+) Aug 28 17:00:37.285: TAC+: send AUTHEN/START packet ver=192 id=-16528696 Aug 28 17:00:37.285: TAC+: Opening TCP/IP to x.x.29.142/49 timeout=5 Aug 28 17:00:37.289: TAC+: TCP/IP open to x.x.29.142/49 failed -- Destination unreachable; gateway or host down Aug 28 17:00:37.289: AAA/AUTHEN (4278438600): status = ERROR Aug 28 17:00:37.289: AAA/AUTHEN/START (4278438600): Method=ENABLE Aug 28 17:00:37.289: AAA/AUTHEN (4278438600): status = GETPASS Aug 28 17:00:45.021: AAA/AUTHEN/CONT (4278438600): continue_login (user='(undef)') Aug 28 17:00:45.021: AAA/AUTHEN (4278438600): status = GETPASS Aug 28 17:00:45.021: AAA/AUTHEN/CONT (4278438600): Method=ENABLE Aug 28 17:00:45.025: AAA/AUTHEN (4278438600): password incorrect Aug 28 17:00:45.025: AAA/AUTHEN (4278438600): status = FAIL thx -- deejay __ Informacia od ESET NOD32 Antivirus, verzia databazy 4388 (20090902) __ 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/ ___ 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?
The PFC is capable of the same things as a DFC, just in a centralized manner. So, for example, CoPP works just fine in hardware with a PFC - you don't NEED to offload the QoS to the LCs. You need a DFC only if some resources are close to exhaustion (like pps rates supported by centralized forwarding, netflow entries, QoS entries and so on). On Wed, 2 Sep 2009, Justin Shore wrote: You eluded to one of my strongest selling points on DFCs though I don't think you made that particular connection yet. DFCs offload QoS to the LC as you said. That also means that CoPP is also handled in hardware if you have DFCs in place since it requires MLS QoS on that platform. Ie, if your 6500/7600 is going to be publicly-accessible on the Internet in any capacity and you want it to be able to use CoPP to withstand a targeted DoS attack then DFCs are not optional, they're critical. The others on the list can probably give you much more in-depth views on the other aspects of the card but I found CoPP to be a big enough selling point. It wouldn't be good is a simple little DoS attack took down my core 7600s. Justin Alan Buxey 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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Monitoring Techniques ahead of mls rate-limiting
Hello, I want to monitor ipv4 multicast and layer2 pdu counters on a Catalyst 6509 Sup32 running 12.2(17r)SX3, in order to set sensible thresholds for the following special case hardware based rate-limiters; # mls rate-limit multicast ipv4 connected (Pkts/sec) # mls rate-limit layer 2 pdu (Pkts/sec) I also want to monitor ARP hitting MSFC ahead of applying QoS as follows; # mls qos protocol arp police (Bits/sec) Can anyone give me any pointers as to how I can access the specific counters that the rate-limiter and policer threshold will be measured against before dropping packets/bits? TIA Regards, P -- Peter George Lumison t: 0845 1199 900 d: 0131 514 4022 P.S. Lumison have changed the way businesses communicate forever http://www.unified-communications.net/ -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multiple power supply failures. Advise needed
You're correct, depending on the hardware you're using your supplies could be sucking fibers right n to their inner workings. I don't recall if you mentioned so sorry if this is covering old ground but is it only Cisco gear you're having issues with or is it random across platforms / hardware types? - Original Message - From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: cisco-nsp@puck.nether.net Sent: Wednesday, September 02, 2009 8:08 AM Subject: Re: [c-nsp] Multiple power supply failures. Advise needed What about the fact that most (if not all) power supplies have independent sucking fan and that power supply air flow is separate from the system board flow. Plus all system board I saw are covered with some insulating coating. I've never pulled apart a modern power supply. I'd expect them to have something like that too, but who knows? Plus since PSU is the only part that's dealing with high voltages I expect it to be more sensitive to momentary shorts. Am I wrong? I'm expecting report for provider ordered unintrusive power monitoring. I'm almost positive they won't find anything, though. I'm still looking for advice on independent power analysis source in New York, NY if anyone has this kind of experience. Thanks, Michael On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote: Plain old dust wouldn't be so picky...it has to be ingested past the system board before it hits the power supply in most cases. System boards are WAY more sensitive to this kind of thing. The fact you have ONLY PSU's failing still makes me think you have power issues. -- Randy www.FastServ.com -- Original Message --- From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: Scott Granados gsgrana...@comcast.net, Seth Mattinen se...@rollernet.us, cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 23:21:23 -0400 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed This is my main suspect now. They are doing work in the facility. Not heavy construction, but they do install cages and cabinets for new tenants and they're definitely using tools that produce metal dust. My theory is that because of we've been the 1st customer who moved into that facility we've been collecting that metal dust for longest and so we're having a lot of problems with our equipment. To my knowledge none of our neighbors are having the same problem, but none of them have been in the place long enough. So the question remains: is there any way to fight it/protect from it except from going through the huge-huge-huge headache of undertaking another move? Michael On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote: He mentioned he was one of the first customers in the colo so this might be a possibility -- Randy -- Original Message --- From: Scott Granados gsgrana...@comcast.net To: Seth Mattinen se...@rollernet.us, Michael Ulitskiy mulits...@acedsl.com Cc: cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 17:35:34 -0700 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed Also make sure that the provider isn't doing work in the facility. I'll never forget going to an L3 datacenter and arriving to find workmen in the overhead grinding away and dropping dust and who knows what else in to all the racks below including a rack of Netra T1's that promptly sucked in the dust and kicked out power supplies.;) It was definitely metal shavings because they were using a grinding type tool up in the over head frames. --- 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/ ___ 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] NAT Ager CPU Usage
Resolution on this: Changed IOS from 12.4.(19b) to 12.4.(25b) and the NAT Ager Process is now well under 1% with a similar number of translations. Philip Davis wrote: Hello, I have a 2621XM that is using more CPU on the NAT aging process that I would expect. At this moment that process is sitting around 15% with ~1700 entries in the NAT translation table. In comparison I have other 2621XMs at other sites doing 2500+ NAT translations where the NAT ager process is using 1% of the CPU. At times the NAT ager will use 50+% of the CPU still with relatively few translations. This causes problems. Does anyone have any idea why this may be happening? Thanks, Phil ___ 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/ -- Philip Davis Systems Administrator I-2000 Inc. (616) 532-8425 888-234-4254 ___ 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] Multiple power supply failures. Advise needed
One other thing you should check. I'll never forget being the first customer at the 3080 Raymond facility in Santa Clara and coming in one day to find my gear down and sitting in about 2 inches of water. The cleaning folks were spraying all sorts of fluids and cleaning products on the floors and sucking them up again but not realizing that fluids pool.;) Personally, my bet is on some sort of work / maintenance the provider is conducting that's being done baddly or with out consideration for effects like metal dust or water. - Original Message - From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: Scott Granados gsgrana...@comcast.net; Seth Mattinen se...@rollernet.us; cisco-nsp@puck.nether.net Sent: Tuesday, September 01, 2009 8:21 PM Subject: Re: [c-nsp] Multiple power supply failures. Advise needed This is my main suspect now. They are doing work in the facility. Not heavy construction, but they do install cages and cabinets for new tenants and they're definitely using tools that produce metal dust. My theory is that because of we've been the 1st customer who moved into that facility we've been collecting that metal dust for longest and so we're having a lot of problems with our equipment. To my knowledge none of our neighbors are having the same problem, but none of them have been in the place long enough. So the question remains: is there any way to fight it/protect from it except from going through the huge-huge-huge headache of undertaking another move? Michael On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote: He mentioned he was one of the first customers in the colo so this might be a possibility -- Randy -- Original Message --- From: Scott Granados gsgrana...@comcast.net To: Seth Mattinen se...@rollernet.us, Michael Ulitskiy mulits...@acedsl.com Cc: cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 17:35:34 -0700 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed Also make sure that the provider isn't doing work in the facility. I'll never forget going to an L3 datacenter and arriving to find workmen in the overhead grinding away and dropping dust and who knows what else in to all the racks below including a rack of Netra T1's that promptly sucked in the dust and kicked out power supplies.;) It was definitely metal shavings because they were using a grinding type tool up in the over head frames. ___ 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] Multiple power supply failures. Advise needed
Coming from an electrical engineer: Before doing anything else, you need to get someone out there with a recording oscilloscope to verify the input power to your equipment. This is the best way to ensure that you are getting the proper waveform, and that your power is free from transients and sags. A normal managed UPS will not be able to pick up infrequent spikes, harmonic distortion, etc. These are all single phase 120 volt circuits, right? Grounding is unlikely to be the problem. As previously mentioned, the safety ground on the equipment power supply bonds the equipment chassis to the facility ground. This is adequate in a typical data environment that is not in a high lightning exposure zone. If you were in a telephone CO, a site with a communications tower, etc., then it would be worth your while to make sure that each piece of equipment and metal hardware was bonded back to the MGB. But based on the information you've given here, I don't think this is relevant to your power supplies blowing up. I would go ahead and put some double sided tape on the air intakes for your equipment. After a few days, peel the tape off and take a look at it using a microscope or magnifying glass and inspect for metal particles. Robert On Wed, Sep 2, 2009 at 11:08 AM, Michael Ulitskiy mulits...@acedsl.comwrote: What about the fact that most (if not all) power supplies have independent sucking fan and that power supply air flow is separate from the system board flow. Plus all system board I saw are covered with some insulating coating. I've never pulled apart a modern power supply. I'd expect them to have something like that too, but who knows? Plus since PSU is the only part that's dealing with high voltages I expect it to be more sensitive to momentary shorts. Am I wrong? I'm expecting report for provider ordered unintrusive power monitoring. I'm almost positive they won't find anything, though. I'm still looking for advice on independent power analysis source in New York, NY if anyone has this kind of experience. Thanks, Michael On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote: Plain old dust wouldn't be so picky...it has to be ingested past the system board before it hits the power supply in most cases. System boards are WAY more sensitive to this kind of thing. The fact you have ONLY PSU's failing still makes me think you have power issues. -- Randy www.FastServ.com -- Original Message --- From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: Scott Granados gsgrana...@comcast.net, Seth Mattinen se...@rollernet.us, cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 23:21:23 -0400 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed This is my main suspect now. They are doing work in the facility. Not heavy construction, but they do install cages and cabinets for new tenants and they're definitely using tools that produce metal dust. My theory is that because of we've been the 1st customer who moved into that facility we've been collecting that metal dust for longest and so we're having a lot of problems with our equipment. To my knowledge none of our neighbors are having the same problem, but none of them have been in the place long enough. So the question remains: is there any way to fight it/protect from it except from going through the huge-huge-huge headache of undertaking another move? Michael On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote: He mentioned he was one of the first customers in the colo so this might be a possibility -- Randy -- Original Message --- From: Scott Granados gsgrana...@comcast.net To: Seth Mattinen se...@rollernet.us, Michael Ulitskiy mulits...@acedsl.com Cc: cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 17:35:34 -0700 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed Also make sure that the provider isn't doing work in the facility. I'll never forget going to an L3 datacenter and arriving to find workmen in the overhead grinding away and dropping dust and who knows what else in to all the racks below including a rack of Netra T1's that promptly sucked in the dust and kicked out power supplies.;) It was definitely metal shavings because they were using a grinding type tool up in the over head frames. --- 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/ ___ 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, so right now my Pix in the field is pointing at a VPN 3000 so I can't take that path down until after hours but I will to capture the debug data. A show ver on the asa shows device manager V5.0.7 The field pix shows V6.3 I have access to both ends so updating the firmware is definitely an option. Any suggested version? On the ASA side I do not have a no nat statement at all. I never configured NAT because this device isn't beingused for any features other than a VPN access device with split tunneling enabled for the clients. On the NY pix side the nat config and acl are as follows. global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224 global (outside) 1 208.x.x.99 netmask 255.255.255.224 nat (inside) 0 access-list vpn-1 nat (inside) 1 0.0.0.0 0.0.0.0 0 0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0 255.255.240.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0 255.254.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0 255.255.0.0 Thanks Scott - Original Message - From: Ryan West rw...@zyedge.com To: Scott Granados gsgrana...@comcast.net; cisco-nsp@puck.nether.net Sent: Wednesday, September 02, 2009 6:15 AM Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel 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 -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Scott Granados Sent: Tuesday, September 01, 2009 8:29 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi, I have a Pix out in the field and an ASA5520 that I'm trying to configure to pass L2L traffic. I keep getting an error that says IKEV1 IP=a.b.c.d removing peer from peer table failed, no match ip=a.b.c.d unable to remove peer table entry What am I doing wrong? Here are the important config bits asa-5520 crypto map crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac crypto dynamic-map dynmap 10 set transform-set vpn-transform1 vpn-transform2 vpn-transform3 crypto dynamic-map dynmap 10 set reverse-route crypto map vpn-ra-map 10 match address ny-vpn-acl crypto map vpn-ra-map 10 set peer ny-fw-outside crypto map vpn-ra-map 10 set transform-set vpn-transform2 crypto map vpn-ra-map 10 set reverse-route crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap crypto map vpn-ra-map interface outside ISAKMP isakmp enable outside isakmp policy 5 authentication pre-share isakmp policy 5 encryption aes-256 isakmp policy 5 hash sha isakmp policy 5 group 7 isakmp policy 5 lifetime 3600 isakmp policy 10 authentication pre-share isakmp policy 10 encryption aes-256 isakmp policy 10 hash sha isakmp policy 10 group 5 isakmp policy 10 lifetime 3600 isakmp policy 20 authentication pre-share isakmp policy 20 encryption 3des isakmp policy 20 hash sha isakmp policy 20 group 2 isakmp policy 20 lifetime 3600 isakmp policy 30 authentication pre-share isakmp policy 30 encryption aes-192 isakmp policy 30 hash md5 isakmp policy 30 group 2 isakmp policy 30 lifetime 28800 isakmp nat-traversal 20 isakmp reload-wait and the acl access-list ny-vpn-acl extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list ny-vpn-acl extended permit ip 10.18.0.0 255.255.254.0 10.18.15.0 255.255.255.192 access-list ny-vpn-acl extended permit ip 10.14.0.0 255.254.0.0 10.18.15.0 255.255.255.192 access-list ny-vpn-acl extended permit ip 157.254.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list ny-vpn-acl extended permit ip 141.11.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list ny-vpn-acl extended permit ip 10.11.0.0 255.255.0.0 10.18.15.0
Re: [c-nsp] Multiple power supply failures. Advise needed
You made me doubt myself and I went ahead and checked the air flow direction in a couple of servers I have in the office handy. I was under impression that all servers power supplies are sucking air, but I was wrong. Apparently we have servers working both ways. And here I find another clue. All server PSUs that failed were sucking air. Does it mean that I'm now to expect system board problems in those servers with PSUs sucking air from inside the chassis? Oh, come on... Also I'm not sure about air flow direction in cisco power supplies. I'll check it out on my next visit to colo. Michael On Wednesday 02 September 2009 11:49:59 am Randy McAnally wrote: You mentioned a couple servers failed -- most if not all servers power supplies blow outward, sucking air from inside the chassis. Many Cisco devices work this way also. I have rarely seen a power supply that sucks air in directly from the outside of the chassis. Given the above, much of the dust would settle on the system board. The extremely high tolerances of a typical system board far outweigh those of a power supply, thus I would expect system instability before the power supply failed. My bet is still on power spikes/dips. -- Randy www.FastServ.com -- Original Message --- From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: cisco-nsp@puck.nether.net Sent: Wed, 2 Sep 2009 11:08:24 -0400 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed What about the fact that most (if not all) power supplies have independent sucking fan and that power supply air flow is separate from the system board flow. Plus all system board I saw are covered with some insulating coating. I've never pulled apart a modern power supply. I'd expect them to have something like that too, but who knows? Plus since PSU is the only part that's dealing with high voltages I expect it to be more sensitive to momentary shorts. Am I wrong? I'm expecting report for provider ordered unintrusive power monitoring. I'm almost positive they won't find anything, though. I'm still looking for advice on independent power analysis source in New York, NY if anyone has this kind of experience. Thanks, Michael On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote: Plain old dust wouldn't be so picky...it has to be ingested past the system board before it hits the power supply in most cases. System boards are WAY more sensitive to this kind of thing. The fact you have ONLY PSU's failing still makes me think you have power issues. -- Randy www.FastServ.com -- Original Message --- From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: Scott Granados gsgrana...@comcast.net, Seth Mattinen se...@rollernet.us, cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 23:21:23 -0400 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed This is my main suspect now. They are doing work in the facility. Not heavy construction, but they do install cages and cabinets for new tenants and they're definitely using tools that produce metal dust. My theory is that because of we've been the 1st customer who moved into that facility we've been collecting that metal dust for longest and so we're having a lot of problems with our equipment. To my knowledge none of our neighbors are having the same problem, but none of them have been in the place long enough. So the question remains: is there any way to fight it/protect from it except from going through the huge-huge-huge headache of undertaking another move? Michael On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote: He mentioned he was one of the first customers in the colo so this might be a possibility -- Randy -- Original Message --- From: Scott Granados gsgrana...@comcast.net To: Seth Mattinen se...@rollernet.us, Michael Ulitskiy mulits...@acedsl.com Cc: cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 17:35:34 -0700 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed Also make sure that the provider isn't doing work in the facility. I'll never forget going to an L3 datacenter and arriving to find workmen in the overhead grinding away and dropping dust and who knows what else in to all the racks below including a rack of Netra T1's that promptly sucked in the dust and kicked out power supplies.;) It was definitely metal shavings because they were using a grinding type tool up in the over head frames. --- End of Original Message --- --- End of Original Message --- ___
Re: [c-nsp] parser config cache interface - stable/safe?
Is anyone running this? Is it stable/safe? How well does it interact with other features e.g. if I scp fragment ad...@router:running-config will it know that the interface cache in the fragment config is expired? Running SRA/SRB/SRD, we have seen a few instances (5) of the real running config being out of sync with the output of show run interface. Problem was easily cleared by removing/reading the parser cache command. Have not tested the scp results under those circumstances. The benefit of the config cache is significant. Loaded chassis without cache sometimes take maybe 30-60 seconds to begin outputting from a show run. ___ 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] Multiple power supply failures. Advise needed
It's different kind of Cisco power supplies (WS-CAC-2500W, WS-CAC-1300W, AS54HPX-AC-RPS) plus servers power supplies (PWS-0055) Michael On Wednesday 02 September 2009 12:12:33 pm you wrote: You're correct, depending on the hardware you're using your supplies could be sucking fibers right n to their inner workings. I don't recall if you mentioned so sorry if this is covering old ground but is it only Cisco gear you're having issues with or is it random across platforms / hardware types? - Original Message - From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: cisco-nsp@puck.nether.net Sent: Wednesday, September 02, 2009 8:08 AM Subject: Re: [c-nsp] Multiple power supply failures. Advise needed What about the fact that most (if not all) power supplies have independent sucking fan and that power supply air flow is separate from the system board flow. Plus all system board I saw are covered with some insulating coating. I've never pulled apart a modern power supply. I'd expect them to have something like that too, but who knows? Plus since PSU is the only part that's dealing with high voltages I expect it to be more sensitive to momentary shorts. Am I wrong? I'm expecting report for provider ordered unintrusive power monitoring. I'm almost positive they won't find anything, though. I'm still looking for advice on independent power analysis source in New York, NY if anyone has this kind of experience. Thanks, Michael On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote: Plain old dust wouldn't be so picky...it has to be ingested past the system board before it hits the power supply in most cases. System boards are WAY more sensitive to this kind of thing. The fact you have ONLY PSU's failing still makes me think you have power issues. -- Randy www.FastServ.com -- Original Message --- From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: Scott Granados gsgrana...@comcast.net, Seth Mattinen se...@rollernet.us, cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 23:21:23 -0400 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed This is my main suspect now. They are doing work in the facility. Not heavy construction, but they do install cages and cabinets for new tenants and they're definitely using tools that produce metal dust. My theory is that because of we've been the 1st customer who moved into that facility we've been collecting that metal dust for longest and so we're having a lot of problems with our equipment. To my knowledge none of our neighbors are having the same problem, but none of them have been in the place long enough. So the question remains: is there any way to fight it/protect from it except from going through the huge-huge-huge headache of undertaking another move? Michael On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote: He mentioned he was one of the first customers in the colo so this might be a possibility -- Randy -- Original Message --- From: Scott Granados gsgrana...@comcast.net To: Seth Mattinen se...@rollernet.us, Michael Ulitskiy mulits...@acedsl.com Cc: cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 17:35:34 -0700 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed Also make sure that the provider isn't doing work in the facility. I'll never forget going to an L3 datacenter and arriving to find workmen in the overhead grinding away and dropping dust and who knows what else in to all the racks below including a rack of Netra T1's that promptly sucked in the dust and kicked out power supplies.;) It was definitely metal shavings because they were using a grinding type tool up in the over head frames. --- 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/ ___ 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] Multiple power supply failures. Advise needed
The double sided sticky tape method mentioned should work, assuming there are still particles in the air. There is a possibility it came in a short burst while they were doing work in or near the air plenum. I would definitely look for particles inside the servers, if you have any you can take offline temporarily. -- Randy www.FastServ.com -- Original Message --- From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: cisco-nsp@puck.nether.net Sent: Wed, 2 Sep 2009 12:47:57 -0400 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed You made me doubt myself and I went ahead and checked the air flow direction in a couple of servers I have in the office handy. I was under impression that all servers power supplies are sucking air, but I was wrong. Apparently we have servers working both ways. And here I find another clue. All server PSUs that failed were sucking air. Does it mean that I'm now to expect system board problems in those servers with PSUs sucking air from inside the chassis? Oh, come on... Also I'm not sure about air flow direction in cisco power supplies. I'll check it out on my next visit to colo. Michael On Wednesday 02 September 2009 11:49:59 am Randy McAnally wrote: You mentioned a couple servers failed -- most if not all servers power supplies blow outward, sucking air from inside the chassis. Many Cisco devices work this way also. I have rarely seen a power supply that sucks air in directly from the outside of the chassis. Given the above, much of the dust would settle on the system board. The extremely high tolerances of a typical system board far outweigh those of a power supply, thus I would expect system instability before the power supply failed. My bet is still on power spikes/dips. -- Randy www.FastServ.com -- Original Message --- From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: cisco-nsp@puck.nether.net Sent: Wed, 2 Sep 2009 11:08:24 -0400 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed What about the fact that most (if not all) power supplies have independent sucking fan and that power supply air flow is separate from the system board flow. Plus all system board I saw are covered with some insulating coating. I've never pulled apart a modern power supply. I'd expect them to have something like that too, but who knows? Plus since PSU is the only part that's dealing with high voltages I expect it to be more sensitive to momentary shorts. Am I wrong? I'm expecting report for provider ordered unintrusive power monitoring. I'm almost positive they won't find anything, though. I'm still looking for advice on independent power analysis source in New York, NY if anyone has this kind of experience. Thanks, Michael On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote: Plain old dust wouldn't be so picky...it has to be ingested past the system board before it hits the power supply in most cases. System boards are WAY more sensitive to this kind of thing. The fact you have ONLY PSU's failing still makes me think you have power issues. -- Randy www.FastServ.com -- Original Message --- From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: Scott Granados gsgrana...@comcast.net, Seth Mattinen se...@rollernet.us, cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 23:21:23 -0400 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed This is my main suspect now. They are doing work in the facility. Not heavy construction, but they do install cages and cabinets for new tenants and they're definitely using tools that produce metal dust. My theory is that because of we've been the 1st customer who moved into that facility we've been collecting that metal dust for longest and so we're having a lot of problems with our equipment. To my knowledge none of our neighbors are having the same problem, but none of them have been in the place long enough. So the question remains: is there any way to fight it/protect from it except from going through the huge-huge-huge headache of undertaking another move? Michael On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote: He mentioned he was one of the first customers in the colo so this might be a possibility -- Randy -- Original Message --- From: Scott Granados gsgrana...@comcast.net To: Seth Mattinen se...@rollernet.us, Michael Ulitskiy mulits...@acedsl.com Cc: cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 17:35:34 -0700 Subject: Re: [c-nsp] Multiple
Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
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 -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Scott Granados Sent: Tuesday, September 01, 2009 8:29 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi, I have a Pix out in the field and an ASA5520 that I'm trying to configure to pass L2L traffic. I keep getting an error that says IKEV1 IP=a.b.c.d removing peer from peer table failed, no match ip=a.b.c.d unable to remove peer table entry What am I doing wrong? Here are the important config bits asa-5520 crypto map crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac crypto dynamic-map dynmap 10 set transform-set vpn-transform1 vpn-transform2 vpn-transform3 crypto dynamic-map dynmap 10 set reverse-route crypto map vpn-ra-map 10 match address ny-vpn-acl crypto map vpn-ra-map 10 set peer ny-fw-outside crypto map vpn-ra-map 10 set transform-set vpn-transform2 crypto map vpn-ra-map 10 set reverse-route crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap crypto map vpn-ra-map interface outside ISAKMP isakmp enable outside isakmp policy 5 authentication pre-share isakmp policy 5 encryption aes-256 isakmp policy 5 hash sha isakmp policy 5 group 7 isakmp policy 5 lifetime 3600 isakmp policy 10 authentication pre-share isakmp policy 10 encryption aes-256 isakmp policy 10 hash sha isakmp policy 10 group 5 isakmp policy 10 lifetime 3600 isakmp policy 20 authentication pre-share isakmp policy 20 encryption 3des isakmp policy 20 hash sha isakmp policy 20 group 2 isakmp policy 20 lifetime 3600 isakmp policy 30 authentication pre-share isakmp policy 30 encryption aes-192 isakmp policy 30 hash md5 isakmp policy 30 group 2 isakmp policy 30 lifetime 28800 isakmp nat-traversal 20 isakmp reload-wait and the acl access-list ny-vpn-acl extended permit ip 10.1.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list ny-vpn-acl extended permit ip 10.18.0.0 255.255.254.0 10.18.15.0 255.255.255.192 access-list ny-vpn-acl extended permit ip 10.14.0.0 255.254.0.0 10.18.15.0 255.255.255.192 access-list ny-vpn-acl extended permit ip 157.254.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list ny-vpn-acl extended permit ip 141.11.0.0 255.255.0.0 10.18.15.0 255.255.255.192 access-list ny-vpn-acl extended permit ip 10.11.0.0 255.255.0.0 10.18.15.0 255.255.255.192 TUNNEL GROUP tunnel-group 208.37.161.98 type ipsec-l2l tunnel-group 208.37.161.98 general-attributes tunnel-group 208.37.161.98 ipsec-attributes pre-shared-key * peer-id-validate nocheck PIX CRYPTO MAP and ISAKMP crypto ipsec transform-set set1 esp-aes-192 esp-md5-hmac crypto map map1 10 ipsec-isakmp crypto map map1 10 match address vpn-1 crypto map map1 10 set peer vpnc crypto map map1 10 set transform-set set1 crypto map map1 interface outside isakmp enable outside isakmp key * address vpnc netmask 255.255.255.255 isakmp policy 20 authentication pre-share isakmp policy 20 encryption aes isakmp policy 20 hash sha isakmp policy 20 group 2 isakmp policy 20 lifetime 28800 ACL access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0 255.255.240.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0 255.254.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0 255.255.0.0 )note on the ASA I use individual /24's and shortened the ACL for ease of reasing. I do this to exclued 10.18.14.0/24 from the tunnels since that houses the ASA's inside interface and client access) Any pointers would be appreciated. Thanks Scott ___ cisco-nsp mailing list
[c-nsp] MPLS 2 Hub sites with loadsharing, same or separate AS numbers?
Hi I have a question regarding AS numbers, whats the best solution, and pros/cons with the different setups? Let say there is an MPLS provider, and one customer has a HUB-site with dual CPE in the VPN. Each CE router is connected to 2 different PE routers. Behind each CE router the customer has a Juniper router and are using eBGP to peer with us. They want per session loadsharing between the to CPEs. The MPLS provider are not planning to run iBGP between the CE routers. Only eBGP to the PE. Now, should these 2 CE routers belong the the same AS number? Let say, 100. Or should they be in separate? 100, and 200? You should still be able to loadshare with max-path eibgp 2 on the PEs even if they are in different AS numbers right? It is only the AS path lengt that is compared, not the actual number if im not misstaken. Any pros/cons with the different setups, same AS, different AS. Thanks! Roger ___ 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] Multiple power supply failures. Advise needed
please see inline On Wednesday 02 September 2009 12:40:30 pm Robert Johnson wrote: Coming from an electrical engineer: Before doing anything else, you need to get someone out there with a recording oscilloscope to verify the input power to your equipment. This is That's what I have now sitting in my cage. Apparently this is what they call unintrusive power monitoring. Can't wait for the result. the best way to ensure that you are getting the proper waveform, and that your power is free from transients and sags. A normal managed UPS will not be able to pick up infrequent spikes, harmonic distortion, etc. These are all single phase 120 volt circuits, right? Correct Grounding is unlikely to be the problem. As previously mentioned, the safety ground on the equipment power supply bonds the equipment chassis to the facility ground. This is adequate in a typical data environment that is not in a high lightning exposure zone. If you were in a telephone CO, a site with a communications tower, etc., then it would be worth your while to make sure that each piece of equipment and metal hardware was bonded back to the MGB. But based on the information you've given here, I don't think this is relevant to your power supplies blowing up. I would go ahead and put some double sided tape on the air intakes for your equipment. After a few days, peel the tape off and take a look at it using a microscope or magnifying glass and inspect for metal particles. Yes, I'm going to do something like that, thanks. Also I'm going to open a couple of raised floor tiles and see how dirty it is over there. Robert On Wed, Sep 2, 2009 at 11:08 AM, Michael Ulitskiy mulits...@acedsl.comwrote: What about the fact that most (if not all) power supplies have independent sucking fan and that power supply air flow is separate from the system board flow. Plus all system board I saw are covered with some insulating coating. I've never pulled apart a modern power supply. I'd expect them to have something like that too, but who knows? Plus since PSU is the only part that's dealing with high voltages I expect it to be more sensitive to momentary shorts. Am I wrong? I'm expecting report for provider ordered unintrusive power monitoring. I'm almost positive they won't find anything, though. I'm still looking for advice on independent power analysis source in New York, NY if anyone has this kind of experience. Thanks, Michael On Wednesday 02 September 2009 10:29:07 am Randy McAnally wrote: Plain old dust wouldn't be so picky...it has to be ingested past the system board before it hits the power supply in most cases. System boards are WAY more sensitive to this kind of thing. The fact you have ONLY PSU's failing still makes me think you have power issues. -- Randy www.FastServ.com -- Original Message --- From: Michael Ulitskiy mulits...@acedsl.com To: Randy McAnally r...@fast-serv.com Cc: Scott Granados gsgrana...@comcast.net, Seth Mattinen se...@rollernet.us, cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 23:21:23 -0400 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed This is my main suspect now. They are doing work in the facility. Not heavy construction, but they do install cages and cabinets for new tenants and they're definitely using tools that produce metal dust. My theory is that because of we've been the 1st customer who moved into that facility we've been collecting that metal dust for longest and so we're having a lot of problems with our equipment. To my knowledge none of our neighbors are having the same problem, but none of them have been in the place long enough. So the question remains: is there any way to fight it/protect from it except from going through the huge-huge-huge headache of undertaking another move? Michael On Tuesday 01 September 2009 08:48:38 pm Randy McAnally wrote: He mentioned he was one of the first customers in the colo so this might be a possibility -- Randy -- Original Message --- From: Scott Granados gsgrana...@comcast.net To: Seth Mattinen se...@rollernet.us, Michael Ulitskiy mulits...@acedsl.com Cc: cisco-nsp@puck.nether.net Sent: Tue, 1 Sep 2009 17:35:34 -0700 Subject: Re: [c-nsp] Multiple power supply failures. Advise needed Also make sure that the provider isn't doing work in the facility. I'll never forget going to an L3 datacenter and arriving to find workmen in the overhead grinding away and dropping dust and who knows what else in to all the racks below including a rack of Netra T1's that promptly sucked in the dust and kicked out power supplies.;) It was definitely metal shavings because they were using a grinding type tool up in the over head frames.
Re: [c-nsp] MPLS 2 Hub sites with loadsharing, same or separate AS numbers?
Sorry, should be: Each CE router is connected to different PE routers And also, I forgot, pros/cons with running iBGP between the CE routers? I know this is a benefit on the Internet, with two different ISPs, for optimal routing, but in a MPLS cloud with the same provider I dont see that benefit. Thanks! Roger On Wed, Sep 2, 2009 at 7:01 PM, Roger Wiklund co...@xy.org wrote: Hi I have a question regarding AS numbers, whats the best solution, and pros/cons with the different setups? Let say there is an MPLS provider, and one customer has a HUB-site with dual CPE in the VPN. Each CE router is connected to 2 different PE routers. Behind each CE router the customer has a Juniper router and are using eBGP to peer with us. They want per session loadsharing between the to CPEs. The MPLS provider are not planning to run iBGP between the CE routers. Only eBGP to the PE. Now, should these 2 CE routers belong the the same AS number? Let say, 100. Or should they be in separate? 100, and 200? You should still be able to loadshare with max-path eibgp 2 on the PEs even if they are in different AS numbers right? It is only the AS path lengt that is compared, not the actual number if im not misstaken. Any pros/cons with the different setups, same AS, different AS. Thanks! Roger ___ 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] Geographically dispersed ASA failover?
Hello, Does anyone know if the ASA failover feature supports a setup where the ASAs are in geographically different locations? Specifically, I have two data centers about 30 miles apart, connected by a 50Mb metro ethernet link with latency under 10ms. Thanks, Michael Malitsky ___ 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
Hello Ryan: Without the no-nat on the ASA side it will try to NAT the traffic before putting it down the tunnel. So, you're remove side is looking for the 10. Addresses, but it's going to see traffic coming from the static outside, NAT'd address. Thus, the tunnel won't come up because your proposals don't 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: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Scott Granados Sent: Wednesday, September 02, 2009 9:45 AM To: Ryan West; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi, so right now my Pix in the field is pointing at a VPN 3000 so I can't take that path down until after hours but I will to capture the debug data. A show ver on the asa shows device manager V5.0.7 The field pix shows V6.3 I have access to both ends so updating the firmware is definitely an option. Any suggested version? On the ASA side I do not have a no nat statement at all. I never configured NAT because this device isn't beingused for any features other than a VPN access device with split tunneling enabled for the clients. On the NY pix side the nat config and acl are as follows. global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224 global (outside) 1 208.x.x.99 netmask 255.255.255.224 nat (inside) 0 access-list vpn-1 nat (inside) 1 0.0.0.0 0.0.0.0 0 0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0 255.255.240.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0 255.254.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0 255.255.0.0 Thanks Scott - Original Message - From: Ryan West rw...@zyedge.com To: Scott Granados gsgrana...@comcast.net; cisco-nsp@puck.nether.net Sent: Wednesday, September 02, 2009 6:15 AM Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel 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 -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Scott Granados Sent: Tuesday, September 01, 2009 8:29 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi, I have a Pix out in the field and an ASA5520 that I'm trying to configure to pass L2L traffic. I keep getting an error that says IKEV1 IP=a.b.c.d removing peer from peer table failed, no match ip=a.b.c.d unable to remove peer table entry What am I doing wrong? Here are the important config bits asa-5520 crypto map crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac crypto dynamic-map dynmap 10 set transform-set vpn-transform1 vpn-transform2 vpn-transform3 crypto dynamic-map dynmap 10 set reverse-route crypto map vpn-ra-map 10 match address ny-vpn-acl crypto map vpn-ra-map 10 set peer ny-fw-outside crypto map vpn-ra-map 10 set transform-set vpn-transform2 crypto map vpn-ra-map 10 set reverse-route crypto map vpn-ra-map 65535 ipsec-isakmp dynamic dynmap crypto map vpn-ra-map interface outside ISAKMP isakmp enable outside isakmp policy 5 authentication pre-share isakmp policy 5 encryption aes-256 isakmp policy 5 hash sha isakmp policy 5 group 7 isakmp policy 5 lifetime 3600 isakmp policy 10 authentication pre-share isakmp policy 10 encryption aes-256 isakmp policy 10 hash sha isakmp policy 10 group 5 isakmp policy 10 lifetime 3600 isakmp policy 20 authentication pre-share isakmp policy 20 encryption 3des isakmp policy 20
Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
Hi Mike, to follow up on this, I do have existing clients working now. For the nonat rule would I create a sepperate ACL for each target or would a basic acl like I use for the split tunneling do the trick? either access-list ny-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.0 255.255.255.192 or would access-list nonat standard permit 10.18.0.0 255.255.255.0 I have several different targets so how would one define that or is the standard ACL enough? Thanks for the pointers! Scott - Original Message - From: Michael K. Smith - Adhost mksm...@adhost.com To: Scott Granados gsgrana...@comcast.net; Ryan West rw...@zyedge.com; cisco-nsp@puck.nether.net Sent: Wednesday, September 02, 2009 10:33 AM Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hello Ryan: Without the no-nat on the ASA side it will try to NAT the traffic before putting it down the tunnel. So, you're remove side is looking for the 10. Addresses, but it's going to see traffic coming from the static outside, NAT'd address. Thus, the tunnel won't come up because your proposals don't 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: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Scott Granados Sent: Wednesday, September 02, 2009 9:45 AM To: Ryan West; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi, so right now my Pix in the field is pointing at a VPN 3000 so I can't take that path down until after hours but I will to capture the debug data. A show ver on the asa shows device manager V5.0.7 The field pix shows V6.3 I have access to both ends so updating the firmware is definitely an option. Any suggested version? On the ASA side I do not have a no nat statement at all. I never configured NAT because this device isn't beingused for any features other than a VPN access device with split tunneling enabled for the clients. On the NY pix side the nat config and acl are as follows. global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224 global (outside) 1 208.x.x.99 netmask 255.255.255.224 nat (inside) 0 access-list vpn-1 nat (inside) 1 0.0.0.0 0.0.0.0 0 0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0 255.255.240.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0 255.254.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0 255.255.0.0 Thanks Scott - Original Message - From: Ryan West rw...@zyedge.com To: Scott Granados gsgrana...@comcast.net; cisco-nsp@puck.nether.net Sent: Wednesday, September 02, 2009 6:15 AM Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel 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 -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Scott Granados Sent: Tuesday, September 01, 2009 8:29 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi, I have a Pix out in the field and an ASA5520 that I'm trying to configure to pass L2L traffic. I keep getting an error that says IKEV1 IP=a.b.c.d removing peer from peer table failed, no match ip=a.b.c.d unable to remove peer table entry What am I doing wrong? Here are the important config bits asa-5520 crypto map crypto ipsec transform-set vpn-transform1 esp-aes-256 esp-sha-hmac crypto ipsec transform-set vpn-transform2 esp-aes-192 esp-md5-hmac crypto ipsec transform-set vpn-transform3 esp-3des esp-sha-hmac crypto dynamic-map dynmap 10 set transform-set vpn-transform1 vpn-transform2
Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
Hi Scott: No, if you use the no-nat below, *all* traffic from 10.18.0.0/24 will not be NAT'd, regardless of the destination. What you want is: Access-list nonat permit ip 10.18.0.0 255.255.255.0 remote subnet remote mask In looking at your post below, I think that would be: Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.0 255.255.255.192 I should note that the mask on the remote side for the 10.18.0.0 subnet is a /20, not a /24. 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: Wednesday, September 02, 2009 10:44 AM To: Michael K. Smith - Adhost; Ryan West; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi Mike, to follow up on this, I do have existing clients working now. For the nonat rule would I create a sepperate ACL for each target or would a basic acl like I use for the split tunneling do the trick? either access-list ny-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.0 255.255.255.192 or would access-list nonat standard permit 10.18.0.0 255.255.255.0 I have several different targets so how would one define that or is the standard ACL enough? Thanks for the pointers! Scott - Original Message - From: Michael K. Smith - Adhost mksm...@adhost.com To: Scott Granados gsgrana...@comcast.net; Ryan West rw...@zyedge.com; cisco-nsp@puck.nether.net Sent: Wednesday, September 02, 2009 10:33 AM Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hello Ryan: Without the no-nat on the ASA side it will try to NAT the traffic before putting it down the tunnel. So, you're remove side is looking for the 10. Addresses, but it's going to see traffic coming from the static outside, NAT'd address. Thus, the tunnel won't come up because your proposals don't 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: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Scott Granados Sent: Wednesday, September 02, 2009 9:45 AM To: Ryan West; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi, so right now my Pix in the field is pointing at a VPN 3000 so I can't take that path down until after hours but I will to capture the debug data. A show ver on the asa shows device manager V5.0.7 The field pix shows V6.3 I have access to both ends so updating the firmware is definitely an option. Any suggested version? On the ASA side I do not have a no nat statement at all. I never configured NAT because this device isn't beingused for any features other than a VPN access device with split tunneling enabled for the clients. On the NY pix side the nat config and acl are as follows. global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224 global (outside) 1 208.x.x.99 netmask 255.255.255.224 nat (inside) 0 access-list vpn-1 nat (inside) 1 0.0.0.0 0.0.0.0 0 0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0 255.255.240.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0 255.254.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0 255.255.0.0 Thanks Scott - Original Message - From: Ryan West rw...@zyedge.com To: Scott Granados gsgrana...@comcast.net; cisco-nsp@puck.nether.net Sent: Wednesday, September 02, 2009 6:15 AM Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel 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
Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
Hi Michael, thanks but one thing I'm not clear on. Suppose I have destinations of 10.18.15.0/26 10.18.15.192/26 10.18.14.0/24 etc. In other words my possible destinations can be different. If I use your example what happens if traffic has the proper source but a destination of 10.18.15.192/26 or if traffic is destined to a client on 10.18.14.0/24? It won't match the ACL correct? - Original Message - From: Michael K. Smith - Adhost mksm...@adhost.com To: Scott Granados gsgrana...@comcast.net; Ryan West rw...@zyedge.com; cisco-nsp@puck.nether.net Sent: Wednesday, September 02, 2009 10:47 AM Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi Scott: No, if you use the no-nat below, *all* traffic from 10.18.0.0/24 will not be NAT'd, regardless of the destination. What you want is: Access-list nonat permit ip 10.18.0.0 255.255.255.0 remote subnet remote mask In looking at your post below, I think that would be: Access-list nonat permit ip 10.18.0.0 255.255.255.0 10.18.15.0 255.255.255.192 I should note that the mask on the remote side for the 10.18.0.0 subnet is a /20, not a /24. 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: Wednesday, September 02, 2009 10:44 AM To: Michael K. Smith - Adhost; Ryan West; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi Mike, to follow up on this, I do have existing clients working now. For the nonat rule would I create a sepperate ACL for each target or would a basic acl like I use for the split tunneling do the trick? either access-list ny-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.0 255.255.255.192 or would access-list nonat standard permit 10.18.0.0 255.255.255.0 I have several different targets so how would one define that or is the standard ACL enough? Thanks for the pointers! Scott - Original Message - From: Michael K. Smith - Adhost mksm...@adhost.com To: Scott Granados gsgrana...@comcast.net; Ryan West rw...@zyedge.com; cisco-nsp@puck.nether.net Sent: Wednesday, September 02, 2009 10:33 AM Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hello Ryan: Without the no-nat on the ASA side it will try to NAT the traffic before putting it down the tunnel. So, you're remove side is looking for the 10. Addresses, but it's going to see traffic coming from the static outside, NAT'd address. Thus, the tunnel won't come up because your proposals don't 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: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Scott Granados Sent: Wednesday, September 02, 2009 9:45 AM To: Ryan West; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi, so right now my Pix in the field is pointing at a VPN 3000 so I can't take that path down until after hours but I will to capture the debug data. A show ver on the asa shows device manager V5.0.7 The field pix shows V6.3 I have access to both ends so updating the firmware is definitely an option. Any suggested version? On the ASA side I do not have a no nat statement at all. I never configured NAT because this device isn't beingused for any features other than a VPN access device with split tunneling enabled for the clients. On the NY pix side the nat config and acl are as follows. global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224 global (outside) 1 208.x.x.99 netmask 255.255.255.224 nat (inside) 0 access-list vpn-1 nat (inside) 1 0.0.0.0 0.0.0.0 0 0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0 255.255.240.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0 255.254.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0 255.255.0.0 Thanks Scott - Original Message - From: Ryan West rw...@zyedge.com To: Scott Granados gsgrana...@comcast.net; cisco-nsp@puck.nether.net Sent: Wednesday, September 02, 2009 6:15 AM Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel 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
Re: [c-nsp] do i *need* DFCs on the 6500?
Drew, Have a look at using mls rate-limit all ttl-failure Here is a paper I worked on, more with an Enterprise feel. http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper _c11_553261.html David -- http://dcp.dcptech.com -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Drew Weaver Sent: Wednesday, September 02, 2009 8:48 AM To: 'Justin Shore'; Alan Buxey Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] do i *need* DFCs on the 6500? Not to thread hijack here, but speaking of withstanding DoS attacks, has anyone seen any decent published baseline configurations for CoPP to deflect things similar to TTL Expiry attacks and the like? Perhaps some sort of template they use (if they can share it) would be really nice. I would just like to see what others are doing. -Drew -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Justin Shore Sent: Wednesday, September 02, 2009 8:40 AM To: Alan Buxey Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] do i *need* DFCs on the 6500? You eluded to one of my strongest selling points on DFCs though I don't think you made that particular connection yet. DFCs offload QoS to the LC as you said. That also means that CoPP is also handled in hardware if you have DFCs in place since it requires MLS QoS on that platform. Ie, if your 6500/7600 is going to be publicly-accessible on the Internet in any capacity and you want it to be able to use CoPP to withstand a targeted DoS attack then DFCs are not optional, they're critical. The others on the list can probably give you much more in-depth views on the other aspects of the card but I found CoPP to be a big enough selling point. It wouldn't be good is a simple little DoS attack took down my core 7600s. Justin Alan Buxey 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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] Geographically dispersed ASA failover?
As long as your latency is under 10ms, you should be fine. From Cisco's site: For optimum performance when using long distance LAN failover, the latency for the failover link should be less than 10 milliseconds and no more than 250 milliseconds. If latency is more than 10 milliseconds, some performance degradation occurs due to retransmission of failover messages. http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/failover.html#wp1052476 Michael http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/failover.html#wp1052476 On Wed, Sep 2, 2009 at 11:38 AM, Michael Malitsky malit...@netabn.comwrote: Hello, Does anyone know if the ASA failover feature supports a setup where the ASAs are in geographically different locations? Specifically, I have two data centers about 30 miles apart, connected by a 50Mb metro ethernet link with latency under 10ms. Thanks, Michael Malitsky ___ 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] ATM packet loss
On Wed, 2 Sep 2009, James Berwick wrote: works fine. Pinging a customer on our OC3 with any packet larger than 576 bytes intermittently fails. This is the ATM OC3 config: interface ATM1/1/0 mac-address .0c71.1148 bandwidth 155000 no ip address load-interval 30 atm ilmi-keepalive end First thing I'd try here would be to configure some ubr value on the OC3, set it to 120 megabit/s or something like that. If that helps, increase until you get close to wirespeed and see if the problem creeps up the higher the UBR. The behaviour you're seeing is alike to what I've seen when there is a cell policer dropping cells somewhere. -- 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/
[c-nsp] OT - Dark Fiber
I was curious to know if there are different ways to go about purchasing dark fiber. If you have Site A and Site B only a few miles apart and you're happy to provide the light, how do you get the fiber? Not expecting to obtain right-of-way/permits/ditch digger. Do you lease (meaning paying a MRC) or is it 'purchased' (meaning a NRC)? Thanks, -chris ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel
Scott, Ideally, you'll want to use a new ACE for each phase2 tunnel and even though you have a single crypto map L2L interesting traffic ACL, I would still separate them out. For example, have an ACL called vpn_ny and ACL called inside_nonat, then as you add new partners, you'll have a new interesting ACL and a new addition to your nonat ACL. As for versions, if the PIX is a 515, that is a scary upgrade and will most likely require someone onsite to upgrade it from the bootloader. If it's a 515E, the upgrade can be completed with a lot less risk. Either option requires a minimum memory upgrade to 64 Meg. We have a lot of luck with 7.2.4(33) interim release. -ryan -Original Message- From: Scott Granados [mailto:gsgrana...@comcast.net] Sent: Wednesday, September 02, 2009 1:44 PM To: Michael K. Smith - Adhost; Ryan West; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi Mike, to follow up on this, I do have existing clients working now. For the nonat rule would I create a sepperate ACL for each target or would a basic acl like I use for the split tunneling do the trick? either access-list ny-vpn extended permit ip 10.18.0.0 255.255.255.0 10.18.15.0 255.255.255.192 or would access-list nonat standard permit 10.18.0.0 255.255.255.0 I have several different targets so how would one define that or is the standard ACL enough? Thanks for the pointers! Scott - Original Message - From: Michael K. Smith - Adhost mksm...@adhost.com To: Scott Granados gsgrana...@comcast.net; Ryan West rw...@zyedge.com; cisco-nsp@puck.nether.net Sent: Wednesday, September 02, 2009 10:33 AM Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hello Ryan: Without the no-nat on the ASA side it will try to NAT the traffic before putting it down the tunnel. So, you're remove side is looking for the 10. Addresses, but it's going to see traffic coming from the static outside, NAT'd address. Thus, the tunnel won't come up because your proposals don't 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: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Scott Granados Sent: Wednesday, September 02, 2009 9:45 AM To: Ryan West; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel Hi, so right now my Pix in the field is pointing at a VPN 3000 so I can't take that path down until after hours but I will to capture the debug data. A show ver on the asa shows device manager V5.0.7 The field pix shows V6.3 I have access to both ends so updating the firmware is definitely an option. Any suggested version? On the ASA side I do not have a no nat statement at all. I never configured NAT because this device isn't beingused for any features other than a VPN access device with split tunneling enabled for the clients. On the NY pix side the nat config and acl are as follows. global (outside) 1 208.x.x.100-208.x.x.115 netmask 255.255.255.224 global (outside) 1 208.x.x.99 netmask 255.255.255.224 nat (inside) 0 access-list vpn-1 nat (inside) 1 0.0.0.0 0.0.0.0 0 0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.1.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.18.0.0 255.255.240.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.14.0.0 255.254.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 157.254.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 141.11.0.0 255.255.0.0 access-list vpn-1 permit ip 10.18.15.0 255.255.255.192 10.11.0.0 255.255.0.0 Thanks Scott - Original Message - From: Ryan West rw...@zyedge.com To: Scott Granados gsgrana...@comcast.net; cisco-nsp@puck.nether.net Sent: Wednesday, September 02, 2009 6:15 AM Subject: RE: [c-nsp] ASA5520 to Pix can't bring up IPSEC L2L tunnel 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
[c-nsp] Management stuff in VRFs
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/
Re: [c-nsp] OT - Dark Fiber
It's almost always MRC + NRC. In our situation level3 was on site near both locations so we pay them per month for the fiber plus the setup fee. If you don't have the same provider on site or very close to both locations, it gets very expensive both MRC and NRC. -- Randy -- Original Message --- From: ch...@lavin-llc.com To: cisco-nsp@puck.nether.net Sent: Wed, 02 Sep 2009 14:27:32 -0400 Subject: [c-nsp] OT - Dark Fiber I was curious to know if there are different ways to go about purchasing dark fiber. If you have Site A and Site B only a few miles apart and you're happy to provide the light, how do you get the fiber? Not expecting to obtain right-of-way/permits/ditch digger. Do you lease (meaning paying a MRC) or is it 'purchased' (meaning a NRC)? Thanks, -chris ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ --- 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] ATM packet loss
Do you have QOS enabled (mls qos)? -- Randy -- Original Message --- From: Mikael Abrahamsson swm...@swm.pp.se To: James Berwick j...@jamesberwick.com Cc: cisco-nsp@puck.nether.net Sent: Wed, 2 Sep 2009 21:01:15 +0200 (CEST) Subject: Re: [c-nsp] ATM packet loss On Wed, 2 Sep 2009, James Berwick wrote: works fine. Pinging a customer on our OC3 with any packet larger than 576 bytes intermittently fails. This is the ATM OC3 config: interface ATM1/1/0 mac-address .0c71.1148 bandwidth 155000 no ip address load-interval 30 atm ilmi-keepalive end First thing I'd try here would be to configure some ubr value on the OC3, set it to 120 megabit/s or something like that. If that helps, increase until you get close to wirespeed and see if the problem creeps up the higher the UBR. The behaviour you're seeing is alike to what I've seen when there is a cell policer dropping cells somewhere. -- 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/ --- 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] OT - Dark Fiber
On Wed, 2 Sep 2009, ch...@lavin-llc.com wrote: I was curious to know if there are different ways to go about purchasing dark fiber. If you have Site A and Site B only a few miles apart and you're happy to provide the light, how do you get the fiber? Not expecting to obtain right-of-way/permits/ditch digger. Do you lease (meaning paying a MRC) or is it 'purchased' (meaning a NRC)? In a case like this, it's commonplace to lease fiber from a fiber provider. Depending on your location, there might be several who can provide you with the glass you're looking for. In a scenario like this, you're normally leasing the fiber, or possible purchasing a long-term IRU (Indefeasible Right to Use). Charges are normally based on mileage and any necessary construction at either/both ends to get the fiber from their existing plant into your buildings. Some providers will amoritize the construction costs into your monthly contract rate, while others will require you to pay for the construction separately. Depending on the number of strands you need between points A and B and other considerations (multiple routes to provide physical diversity, etc), the provider might be willing to build a path for you, but the cost goes up dramatically. Once the fiber path is completely built, make sure the provider gives you the results of their tests (2-point loss, OTDR graphs, etc) on the whole span. The performance of the fiber and the type of optics you'll need to drive the link over distances of 'a few miles' will normally have much more to do with the quality and number of splices than the length of the span itself. I've driven 1000baseLX/LH signal cleanly over fiber paths that were longer than 10km as long as the 2-point loss is under the link budget for the optics. jms ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ATM packet loss
Nope: er02.penn-nj#show run | i mls er02.penn-nj# er02.penn-nj#show mls rp interface atm 1/1/0 mls not configured on ATM1/1/0 er02.penn-nj#show mls rp interface atm 1/1/0.36 mls not configured on ATM1/1/0.36 er02.penn-nj#show mls rp ip ip multilayer switching is globally disabled Randy McAnally wrote: Do you have QOS enabled (mls qos)? -- Randy -- Original Message --- From: Mikael Abrahamsson swm...@swm.pp.se To: James Berwick j...@jamesberwick.com Cc: cisco-nsp@puck.nether.net Sent: Wed, 2 Sep 2009 21:01:15 +0200 (CEST) Subject: Re: [c-nsp] ATM packet loss On Wed, 2 Sep 2009, James Berwick wrote: works fine. Pinging a customer on our OC3 with any packet larger than 576 bytes intermittently fails. This is the ATM OC3 config: interface ATM1/1/0 mac-address .0c71.1148 bandwidth 155000 no ip address load-interval 30 atm ilmi-keepalive end First thing I'd try here would be to configure some ubr value on the OC3, set it to 120 megabit/s or something like that. If that helps, increase until you get close to wirespeed and see if the problem creeps up the higher the UBR. The behaviour you're seeing is alike to what I've seen when there is a cell policer dropping cells somewhere. -- 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/ --- 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] OT - Dark Fiber
Depending on the city there are fiber providers doing both dark and lit services. In Pittsburgh we currently have two that I deal with that are driving prices down quite nicely. Chuck On Wed, Sep 2, 2009 at 2:27 PM, ch...@lavin-llc.com wrote: I was curious to know if there are different ways to go about purchasing dark fiber. If you have Site A and Site B only a few miles apart and you're happy to provide the light, how do you get the fiber? Not expecting to obtain right-of-way/permits/ditch digger. Do you lease (meaning paying a MRC) or is it 'purchased' (meaning a NRC)? Thanks, -chris ___ 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/ -- = Charles L. Mills Westmoreland Co. ARES EC Amateur Radio Callsign W3YNI Email: w3y...@gmail.com ___ 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] interfaces flapping QinQ and/or spanning tree
On Tue, Sep 1, 2009 at 7:22 AM, Bruno Filipe brun0_fil...@yahoo.com wrote: Something Weird is happening to me...the setup is very simple (there's nothing fancy) but for some reason I do have my switch ports flapping all the time and due to the fact the spanning tree is busy converging whenever that happens causing lot of problems... Syslog OUTPUT Sep 1 11:37:37 cat1.lda2.ao.isp.net 2045: Sep 1 11:37:17.823 GMT+1: %SW_MATM-4-MACFLAP_NOTIF: Host 0023.3314.0420 in vlan 291 is flapping between port Fa0/9 and port Fa0/1 Sep 1 11:37:37 cat1.lda2.isp.net 2046: Sep 1 11:37:17.932 GMT+1: %SW_MATM-4-MACFLAP_NOTIF: Host 0013.8fb8.cb9d in vlan 292 is flapping between port Fa0/9 and port Fa0/11 It isn't clear to me which switch on your diagram is logging this message. Is it a switch that is actually doing QinQ? I have run into problems before where I had a metro-Ethernet link provided to me by a provider that used QinQ. So, none of my switches were speaking QinQ. The problem I ran into is that my 6500 switches use the same MAC address for every interface vlan on the switch. I then had half of my spanning tree roots set to one switch, and the other half set to the other switch. This resulted in the same mac address being transmitted in both directions around my redundant metro-e loop. None of MY switches ever logged the is flapping between... message, but my provider did get that message logged constantly. For me, it just looked like I kept losing connectivity because whenever the mac address went one way, one half of the vlans worked. When it went the other way, the other half of the VLANs worked. Here's an old diagram I prepared years ago explaining the situation: http://www.overloaded.net/pics/qinq.gif You won't run into this problem if a) you never reuse a mac address across VLANs, or b) all your STP roots are the same, or c) you don't have redundant links forming a loop that includes QinQ. The average customer of a QinQ metro-e provider likely won't notice this issue mostly because of C. I suspect most customers of metro-e providers using QinQ probably aren't using the QinQ based link to form a redundant loop. In my case, I almost always need redundant bridging of all VLANs between datacenters. Our solution? We now ask every provider that we might buy metro-e from if they are using QinQ. If they say yes, they are disqualified. Unfortunately, some say no but turn out to be using it after all. It is quite frustrating to spend lots of money and time trying to get a provider to turn a circuit up in time for a big project only to find that once the circuit is delivered, we can't turn up redundancy across it because the circuit is unable to carry reused MAC addresses across different VLANs. ___ 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] Geographically dispersed ASA failover?
On Wed, Sep 2, 2009 at 1:56 PM, Michael Fox michaelfox...@gmail.com wrote: As long as your latency is under 10ms, you should be fine. From Cisco's site: For optimum performance when using long distance LAN failover, the latency for the failover link should be less than 10 milliseconds and no more than 250 milliseconds. If latency is more than 10 milliseconds, some performance degradation occurs due to retransmission of failover messages. http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/failover.html#wp1052476 I have done this (with low latency circuits). I have migrated customers from one city to another nearby city across 5 ms links by bridging their VLANs across the circuit (outer and inner VLANs), then moving one firewall of a failover pair one night (leaving things running for a day or two with failover across datacenters), then the next night failing it over to the firewall in the new DC and moving the 2nd firewall. This lets us do hitless firewall migrations from one DC to another. Downtime for the 1 forced failover required to complete the process is sub-second, and stateful failover allows connections to survive. We haven't ever left it split like that long term, but I haven't noticed any problems in the day-or-two migration situations we've done this for. ___ 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] OT - Dark Fiber
Hello Chris: -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of ch...@lavin-llc.com Sent: Wednesday, September 02, 2009 11:28 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] OT - Dark Fiber I was curious to know if there are different ways to go about purchasing dark fiber. If you have Site A and Site B only a few miles apart and you're happy to provide the light, how do you get the fiber? Not expecting to obtain right-of-way/permits/ditch digger. Do you lease (meaning paying a MRC) or is it 'purchased' (meaning a NRC)? Thanks, -chris You could do a couple of things: 1) If there aren't any providers between buildings you could look for existing conduit or pole rights if you have above-ground electrical service. 2) If there are dark fiber providers: - You could get a standard NRC/MRC deal (as someone said already) - You could get a long-term IRU (Indefensible Right of Use) where you pay a lot up front but very little MRC and you have sole use of the fibers for a period of years. Regards, Mike ___ 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
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? Telcos are doing something similar for ages - they are deploying physically separate networks for management and they know very well why they do so. IP equipment is just getting there, e.g. Nexus has dedicated management ports which are forced into a management VRF. What are the benefits from using a VRF for this? It's kind of mimicking separate control and forwarding planes. Though the separation is virtual, it's still better than none. I assume everyone uses infrastructure ACLs so the VRF thingy shouldn't be any more secure. Or should it? First, ACL is reactive mechanism, management separation is proactive. You prevent unwanted stuff from entering your management network even before you can filter it. Second, you isolate problems - think your IGP not working because of whatever reason (attack, misconfiguration...), but you still can ssh your box via the (quasi) out-of-band management, which you don't touch at the same time, and repair the network. Etc. Many more. ;) -- deejay __ Informacia od ESET NOD32 Antivirus, verzia databazy 4389 (20090902) __ 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] ATM packet loss
Mikael Abrahamsson wrote: On Wed, 2 Sep 2009, James Berwick wrote: works fine. Pinging a customer on our OC3 with any packet larger than 576 bytes intermittently fails. This is the ATM OC3 config: interface ATM1/1/0 mac-address .0c71.1148 bandwidth 155000 no ip address load-interval 30 atm ilmi-keepalive end First thing I'd try here would be to configure some ubr value on the OC3, set it to 120 megabit/s or something like that. If that helps, increase until you get close to wirespeed and see if the problem creeps up the higher the UBR. The behaviour you're seeing is alike to what I've seen when there is a cell policer dropping cells somewhere. I rebuilt a PVC on the circuit to ubr 149760 (full linespeed of our OC3) and observed the same results. Continuous pings of 576 bytes work flawlessly. 577 byte pings show between 1% and 2% packet loss. We don't maintain the ATM network between us and our customers. The LEC that does has gone to two of our customer's facilities and put an ATM test kit on the DS3 and tested sending 45mbit/sec of cells across that particular customer's PVC. We've then looped the OC3 in the router with loopback line on the ATM1/1/0 interface and they saw 45mbit/sec worth of cells returned. I'm not sure where to look for a cell policer. This OC3 comes from the LEC into our 7500 series and we don't have any QoS or rate limiting on the ATM interface itself or any of the PVCs. I'm not sure if this is helpful information or not but if we use something like speedtest.net from a customer's network we end up with results like 5mbit down, 30mbit up. It seems like the throttling is taking place in only one direction, but we aren't (intentionally) doing it on our router and the LEC who handles the ATM cloud swears up and down they aren't doing anything that would cap throughput and none of the switches between us and the customer are oversubscribed. I just tested now by kicking off enough ping -f x.x.x.x -s 548's (Ping flood with 576 byte packets) to push 20mbit/sec worth of ICMP traffic across a PVC with 0% packet loss, while the same test with a 1000 byte ping fails miserably. I'm at a loss as to why either our router, our LEC's ATM network (which according to them is doing no policing at all of our UBR traffic), or a dozen of our customer's Cisco routers have all suddenly decided that packets over 576 bytes need to get dropped on the floor randomly. This is what our interface looks like: ATM1/1/0 is up, line protocol is up Hardware is cyBus ENHANCED ATM PA MTU 4470 bytes, sub MTU 4470, BW 155000 Kbit, DLY 80 usec, reliability 255/255, txload 48/255, rxload 13/255 Encapsulation ATM, loopback not set Encapsulation(s): AAL5 4095 maximum active VCs, 32 current VCCs VC Auto Creation Disabled. VC idle disconnect time: 300 seconds 0 carrier transitions Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 1d05h Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 60 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 8191000 bits/sec, 3544 packets/sec 30 second output rate 29327000 bits/sec, 4090 packets/sec 289263860 packets input, 803308614 bytes, 0 no buffer Received 254286 broadcasts, 0 runts, 6 giants, 0 throttles 7 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 326860666 packets output, 1743804746 bytes, 0 underruns 60 packets late drop, 86107 bytes late drop 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out Interface ATM1/1/0: AAL enabled: AAL5 , Maximum VCs: 4095, Current VCCs: 32 Maximum Transmit Channels: 0 Max. Datagram Size: 4528 PLIM Type: SONET - 155000Kbps, TX clocking: LINE Cell-payload scrambling: ON sts-stream scrambling: ON 178409785 input, 327045383 output, 29153365 IN fast, 109018418 OUT fast, 0 out dropVBR-NRT : 672 Avail bw = 149088 Config. is ACTIVE ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] BGP multihop between two sites
We have two sites advertising unique subnets via the same AS. Since the subnets originate from the same AS they apparently get dropped from the tables at each site. Each site has at least 3 upstreams taking full tables from each with a 6509. Site a has a single border router with dual supervisors. Site b actually has dual border routers. Each router handles different upstreams and trades routes via iBGP. So I think I need to set up a multihop session between the sites. Right now, traffic between sites is taking the floating default route and causes issues between sites when one of our BGP peers is down for whatever reason. What are the things to look out for when setting up this multihop? Are there gotcha's to deal with given one site has dual active routers? Can anyone provide me or point me to an example multihop config to work from? -- Randy ___ 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
You can set your neighbor statements to allow learning from the same AS so the routes won't be dropped. Another good way to do this is to set up a GRE tunnel between the sites and connect your devices using the attached /30 addresses. - Original Message - From: Randy McAnally r...@fast-serv.com To: cisco-nsp@puck.nether.net Sent: Wednesday, September 02, 2009 1:51 PM Subject: [c-nsp] BGP multihop between two sites We have two sites advertising unique subnets via the same AS. Since the subnets originate from the same AS they apparently get dropped from the tables at each site. Each site has at least 3 upstreams taking full tables from each with a 6509. Site a has a single border router with dual supervisors. Site b actually has dual border routers. Each router handles different upstreams and trades routes via iBGP. So I think I need to set up a multihop session between the sites. Right now, traffic between sites is taking the floating default route and causes issues between sites when one of our BGP peers is down for whatever reason. What are the things to look out for when setting up this multihop? Are there gotcha's to deal with given one site has dual active routers? Can anyone provide me or point me to an example multihop config to work from? -- Randy ___ 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] Geographically dispersed ASA failover?
On Wed, 2009-09-02 at 11:38 -0500, Michael Malitsky wrote: Does anyone know if the ASA failover feature supports a setup where the ASAs are in geographically different locations? Specifically, I have two data centers about 30 miles apart, connected by a 50Mb metro ethernet link with latency under 10ms. I think you'll be fine. We're currently running a pair of ASAs in failover with ~40 km LoS between them (RTT ~0.7 ms) without the slightest problems at all. It traverses a mix of 1Gig and 10Gig links. Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Management stuff in VRFs
I have everything splitted. ___ 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
A management VRF is attractive from best practice perspective, but full management support like using the global routing table is lacking in Cisco IOS. I have enhancement CSCsu22476 open to support selecting the syslog source interface when using VRF aware syslog (IOS 12.4T). While not always practical for full Internet routes, I would recommend using the global routing table for mgmt and putting all the customer traffic in a VRF. There are also many Cisco IOS features which only work in the global routing table making a management VRF more attractive. Peter Rathlev wrote: 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? ___ 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?
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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] 6509, Sup2 VRF's
Hey all, In my Googleness I've found some old (2006 and back) comments about SUP2's and not being able to do VRF-Lite on many interfaces. Research has indicated SOME interfaces are supported, loopbacks for example, but I can find no definitive of which ones are supported. Or... in the past 3 years has there been any IOS releases which may have updated it. I saw a brief post which wasn't complete in which someone used a line card to loop the Ethernet back or somesuch to get SVI's into a VRF but I couldn't find anymore. Essentially VLAN's or SVI's is what I want to get into a VRF, and it would be nice for layer 3 interfaces as well... but I will take what I can get. Does anyone have any creative ideas on how one might accomplish this? i.e. using one of the maybe supported WAN cards (is there a list?) in which we could accomplish the same result. Thanks all (and to Ian Cox's earlier comments) -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists ske...@eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are! virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. ___ 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
Randy, By no means an answer to all your questions, but there may be some useful info in this thread regarding routing over the internet between the same ASN: http://www.gossamer-threads.com/lists/nanog/users/115689?#115689 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? John. From: cisco-nsp-boun...@puck.nether.net [cisco-nsp-boun...@puck.nether.net] On Behalf Of Randy McAnally [...@fast-serv.com] Sent: Wednesday, September 02, 2009 16:51 To: cisco-nsp@puck.nether.net Subject: [c-nsp] BGP multihop between two sites We have two sites advertising unique subnets via the same AS. Since the subnets originate from the same AS they apparently get dropped from the tables at each site. Each site has at least 3 upstreams taking full tables from each with a 6509. Site a has a single border router with dual supervisors. Site b actually has dual border routers. Each router handles different upstreams and trades routes via iBGP. So I think I need to set up a multihop session between the sites. Right now, traffic between sites is taking the floating default route and causes issues between sites when one of our BGP peers is down for whatever reason. What are the things to look out for when setting up this multihop? Are there gotcha's to deal with given one site has dual active routers? Can anyone provide me or point me to an example multihop config to work from? -- Randy ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Is Cisco SLB vrf aware?
Does anyone know if Cisco SLB is vrf aware??? Can't seem to find much information on it which is leading me to believe it's not vrf aware. Trying to implement this on Cisco 7301 running 12.2(18)S13. 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@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
Personally, my recommendation is that if you can afford to have a separate management network, do it. It would also be nice if more network devices had truly isolated management ports such that bearer/management traffic never have to cross paths, share routing tables, and so forth. Various IOS versions also do not have syntax to tell the router to send syslog / snmp trap / tacacs via the management VRF, defaulting instead to the global routing table. This can be worked around with some effort, but it's an annoyance. Plus if you have instability in your network environment for any reason, you don't want to be reliant on that unstable network to get access to the routers so you can fix it - you're working on the very transport you're relying on for connectivity. That said, it can be done with some careful planning, and especially if you have out of band console access as a 'back door' in case of bad connectivity issues, you may have a reasonable compromise without having the expense of parallel management infrastructure. John. From: cisco-nsp-boun...@puck.nether.net [cisco-nsp-boun...@puck.nether.net] On Behalf Of Peter Rathlev [pe...@rathlev.dk] Sent: Wednesday, September 02, 2009 15:36 To: cisco-nsp Subject: [c-nsp] Management stuff in VRFs 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/ ___ 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
On Sep 2, 2009, at 1:51 PM, Randy McAnally wrote: We have two sites advertising unique subnets via the same AS. Since the subnets originate from the same AS they apparently get dropped from the tables at each site. Each site has at least 3 upstreams taking full tables from each with a 6509. Site a has a single border router with dual supervisors. Site b actually has dual border routers. Each router handles different upstreams and trades routes via iBGP. So I think I need to set up a multihop session between the sites. Right now, traffic between sites is taking the floating default route and causes issues between sites when one of our BGP peers is down for whatever reason. What are the things to look out for when setting up this multihop? Are there gotcha's to deal with given one site has dual active routers? Multihop BGP is not a good idea in this example. You'll want to use something like neighbor x.x.x.x allowas-in on your eBGP sessions. However, you'll also want to setup a BGP filter to deny your own sourced prefixes to prevent loops/flapping. Meaning, when you allow prefixes from site A into site B, setup a BGP filter on site B denying B's prefixes and vice versa. ___ 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
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 ___ 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
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 http://www.fastserv.com/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6509, Sup2 VRF's
Skeeve, You could try and get an OSM module (it is become obsolete as the Sup2...) This card would allow you to implement not just VRF-Lite but also full blown MPLS/VPN. You would have to use an external trunk from the 6500 to the OSM, and bridge any VLAN you want to use inside a VRF to the OSM, which would perform all the L3 functionality for that VLAN. Arie On Thu, Sep 3, 2009 at 2:20 AM, Skeeve Stevens ske...@eintellego.netwrote: Hey all, In my Googleness I've found some old (2006 and back) comments about SUP2's and not being able to do VRF-Lite on many interfaces. Research has indicated SOME interfaces are supported, loopbacks for example, but I can find no definitive of which ones are supported. Or... in the past 3 years has there been any IOS releases which may have updated it. I saw a brief post which wasn't complete in which someone used a line card to loop the Ethernet back or somesuch to get SVI's into a VRF but I couldn't find anymore. Essentially VLAN's or SVI's is what I want to get into a VRF, and it would be nice for layer 3 interfaces as well... but I will take what I can get. Does anyone have any creative ideas on how one might accomplish this? i.e. using one of the maybe supported WAN cards (is there a list?) in which we could accomplish the same result. Thanks all (and to Ian Cox's earlier comments) -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists ske...@eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are! virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. ___ 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] ATM packet loss
On Wed, 2 Sep 2009, James Berwick wrote: First thing I'd try here would be to configure some ubr value on the OC3, set it to 120 megabit/s or something like that. If that helps, increase until you get close to wirespeed and see if the problem creeps up the higher the UBR. The behaviour you're seeing is alike to what I've seen when there is a cell policer dropping cells somewhere. I rebuilt a PVC on the circuit to ubr 149760 (full linespeed of our OC3) and 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? -- 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/
