[c-nsp] 11503 ssl redundancy synch
Hi all, I have 2 css11503's in active/passive redundancy config. When using the commit_redundConfig command the ssl does not copy across. I have cleared the standby box and started again, but with no luck. The config guides I have found offer little info on the ssl redundancy, just the normal IP redundancy, the question is should I configure the ssl config and import the certs on both boxes and then commit the redundant config when I have verified the ssl config on the standby unit? Or should it copy all config including all the ssl stuff and I'm missing something? Thanks in advance Toby Burrows Network Engineer Qube Networks :: The Engineer's Choice for Co-Location, Internet Bandwidth, Design Build, and Managed Servers Qube Networks Ltd :: Company Number 04155284 Registered in England and Wales :: VAT Registration No: GB 769 6428 71 This e-mail and the information it contains are confidential. If you have received this e-mail in error please notify the sender immediately. You should not copy it for any purpose, or disclose its contents to any other person. P Please consider the environment - do you really need to print 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] MPLS VPN QoS on a SP core
Hi Mikael, I am not going to do in my Core but i'm just curious how this is done? So i guess if we want to differentiate between VPNs in my core then we need alot of different classes which is not really available and thats what makes it difficult? Thanks, Sam On Mon, Aug 18, 2008 at 8:41 AM, Mikael Abrahamsson [EMAIL PROTECTED]wrote: On Mon, 18 Aug 2008, Sami Joseph wrote: Is there a way to provide QoS for a specific VPN in an MPLS VPN Core? Yes. Depends on what you want, but you can for instance mark MPLS EXP for the traffic in a certain VPN and treat those packets differently in your core. -- Mikael Abrahamssonemail: [EMAIL PROTECTED] ___ 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] Nasty PIX 6.3 bug
If anyone still has PIX's out there running 6.3(5) we had a pair of 525's nailed by this nasty bug: http://tinyurl.com/5wovce We've been running 6.3 for years and only after all the recent DNS exploits did we see this one start hitting us. The only way to fix it is to upgrade to 7.x or get the maint/patch train from TAC. If you have any DNS servers behind your PIX with a lot of clients querying through your firewalls, you might want to get this taken care of ASAP before your PIX's get jammed at 100% CPU load indefinitely. Also stateful failover kindly transfers the 100% load over to the standby box as well. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS VPN QoS on a SP core
On Mon, 18 Aug 2008, Sami Joseph wrote: Hi Mikael, I am not going to do in my Core but i'm just curious how this is done? So i guess if we want to differentiate between VPNs in my core then we need alot of different classes which is not really available and thats what makes it difficult? QoS has many meanings. For me at least, it's implemented by packet marking at ingress and per-hop queuing decisions made by core routers of which the marking influences which queue a packet should be put into. I always recommend a KISS (keep it simple stupid) approach, the fewer classes you can have, the less complicated it is to handle. Best of all, is to make sure your statistical overbooking means you never have lines that are full, thus negating the need for QoS alltogether. I'd say reasonable amount of queues/classes is around 4-6, one for VoIP, one for Video, one for priority data (interactive applications) and then an best effort class. You might want to put all your VPN traffic into priority data and let your Internet uses get a lower SLA if you mix Internet and VPN traffic in your core. -- Mikael Abrahamssonemail: [EMAIL PROTECTED] ___ 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] Fwd: Alternantive to REB(route bridge Encapsulation)-2nd try
On Aug 16, 2008, at 11:09 AM, Hash Aminu wrote: I am trying to find a Feature that will be able to replace Route bridge Encapsulation..because we are migrating to the 12.2S and does not support that feature..any thoughts or Ideas will be useful. Thanks Just what are you trying to accomplish? As previously mentioned the 7500 is EoS. You may want to look at a 7200 NPE-Gx running 12.2SB. Then you can keep RBE. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS VPN QoS on a SP core
Hi, There are ways to do it.. typically 3 mode.. http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hmp_c/part15/hdtmode.htm Basically we cash in the feature of MPLS EXP bits used to mark/classify packet and treat them acc.. Regards, Gaurav Prakash Save our Earth - Original Message From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: cisco-nsp@puck.nether.net Sent: Monday, 18 August, 2008 2:34:58 PM Subject: cisco-nsp Digest, Vol 69, Issue 54 Send cisco-nsp mailing list submissions to cisco-nsp@puck.nether.net To subscribe or unsubscribe via the World Wide Web, visit https://puck.nether.net/mailman/listinfo/cisco-nsp or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of cisco-nsp digest... Today's Topics: 1. MPLS VPN QoS on a SP core (Sami Joseph) 2. content filter placement in data center (Dan Letkeman) 3. Re: content filter placement in data center (Adrian Chadd) 4. Re: IP/MPLS Design Resource (Andy Saykao) 5. IBM CIGESM aggregation and Private VLANs. (Adrian Chung) 6. Re: content filter placement in data center (Dan Letkeman) 7. Re: MPLS VPN QoS on a SP core (Mikael Abrahamsson) 8. 11503 ssl redundancy synch (Toby Burrows (Qube)) 9. Re: MPLS VPN QoS on a SP core (Sami Joseph) -- Message: 1 Date: Mon, 18 Aug 2008 01:41:07 +0300 From: Sami Joseph [EMAIL PROTECTED] Subject: [c-nsp] MPLS VPN QoS on a SP core To: Cisco-nsp cisco-nsp@puck.nether.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hello, Is there a way to provide QoS for a specific VPN in an MPLS VPN Core? Thanks, Sam -- Message: 2 Date: Sun, 17 Aug 2008 18:15:09 -0500 From: Dan Letkeman [EMAIL PROTECTED] Subject: [c-nsp] content filter placement in data center To: cisco-nsp@puck.nether.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hello, I have a few questions regarding content filter placement and routing in the data center. I would like to place our content/spyware/web filter in our data center, but I would like to place it in such a way that if it fails or has problems that it does not take everything down. Currently I have a Cisco router with two fast ethernet interfaces, and I have two internet connections to different ISP's. One of the connections is used for download for all of the users and the other connection is used for services (www, ftp, mail, etc). On the cisco router I am policy routing for those services and for the users. The current content filter is inline with the router and the rest of the network as a default route on the switch. 3560switch---content filter---routerinternet (isp1) | -internet (isp2) Is there a way to connect it to the router and use policy routing, and the verify availability option so that if the content filter is down the system still works with out it? Thanks, Dan. -- Message: 3 Date: Mon, 18 Aug 2008 07:17:33 +0800 From: Adrian Chadd [EMAIL PROTECTED] Subject: Re: [c-nsp] content filter placement in data center To: Dan Letkeman [EMAIL PROTECTED] Cc: cisco-nsp@puck.nether.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii On Sun, Aug 17, 2008, Dan Letkeman wrote: Is there a way to connect it to the router and use policy routing, and the verify availability option so that if the content filter is down the system still works with out it? Yes. * Does the content filter speak WCCPv2? Or can you glue it to Squid? If so, try WCCPv2. * Otherwise, see if your platform/IOS supports object tracking and conditional route maps. You can set things up to use a route-map (or route!) if a destination host is reachable via ICMP. The archives have details on both of these. Adrian -- Message: 4 Date: Mon, 18 Aug 2008 11:09:47 +1000 From: Andy Saykao [EMAIL PROTECTED] Subject: Re: [c-nsp] IP/MPLS Design Resource To: cisco-nsp@puck.nether.net, [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Hi Junaid, Welcome to the world of MPLS. I'm currently going through the same thing and have been designing and fine tuning our MPLS network for the past few months. The guys on NSP are very knowledgable so if you get stuck, try posting on the forum. Special thanks to Oli whose been helping me a fair bit :) Here's a book I recommend. Read the first few chapters to give you a good foundation. * MPLS Fundamentals by Luc De Ghein Also nothing beats some hands on experience and these labs are a great introduction. I used GNS3 to simulate these labs
[c-nsp] aaa local database
Hello! I am thinking about aaa local database. Is there any mechanism to distinguish local users (defined by username ...) or put them into some groups and give them access to only some services? For instance I have two users username alice password xxx username bob password yyy aaa new-model aaa authentication login default local aaa authentication ppp default local aaa authorization network default local Now bob and alice can login to router and also dial ppp. What if I want alice to have right only to login to router and bob only to dial ppp? Thanks, Tomas -- Tomáš Hlaváček [EMAIL PROTECTED] ___ 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] aaa local database
Tomas Hlavacek wrote on Monday, August 18, 2008 1:20 PM: Hello! I am thinking about aaa local database. Is there any mechanism to distinguish local users (defined by username ...) or put them into some groups and give them access to only some services? For instance I have two users username alice password xxx username bob password yyy aaa new-model aaa authentication login default local aaa authentication ppp default local aaa authorization network default local Now bob and alice can login to router and also dial ppp. What if I want alice to have right only to login to router and bob only to dial ppp? the local database is not really very feature-rich, especially when it comes to PPP/network dialin. You could force bob to only do PPP with aaa authorization exec default local and then username bob autocommand exit or username bob autocommand ppp so bob's login shell will exit right away or, if you want to allow async login via modems, spawn ppp.. Not sure if you can prevent alice to dial in via ppp, though. Local DB is mainly used for some last-resort backup when T+/Radius is not available. certainly not a replacement.. Depending on your image/version, you could investigate the Local AAA Server feature and point your network authorization there, so you will then arrive at two different user databases locally configured on the device.. oli ___ 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] aaa local database
I should have told that I want this on 2811 with 12.4(20)T ADVIPSERVICESK9 IOS image. Alasdair Gow wrote: What device are you trying to do this on? I know ASA's have dynamic policies, which you could customise to do this Cheers, Ally Tomas Hlavacek wrote: Hello! I am thinking about aaa local database. Is there any mechanism to distinguish local users (defined by username ...) or put them into some groups and give them access to only some services? For instance I have two users username alice password xxx username bob password yyy aaa new-model aaa authentication login default local aaa authentication ppp default local aaa authorization network default local Now bob and alice can login to router and also dial ppp. What if I want alice to have right only to login to router and bob only to dial ppp? Thanks, Tomas -- Tomáš Hlaváček [EMAIL PROTECTED] ___ 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] multicast bringing big irons to their knees?
Hi I've only got the most superficial of ideas what's going on with this network, but i've been asked if there's any particular reason some Foundry switches would be being brought to their knees every time mcast is switched on in a network. 65s, 3750s and Netscreens all handle it fine. Given Foundry's marketing, they dobrag that everything's handled in port-based ASICs, but obviously it sounds like this stuff is going to the processor. Maybe it's PIM Sniffing not supported in hardware, not sure. Anyway, sorry for the amazing vagary here, but it's all I've got right now. Any thoughts? Cheers Christian ___ 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] ip cef load sharing
My only options for the IP CEF command are as follows: original Original algorithm tunnel Algorithm for use in tunnel only environments universal Algorithm for use in most environments I tried original, and it seems as if it load balances, but it doesn't switch from modem to modem very fast. But in any case there is a lot less problems with this on. I also found out that the content filter that is before the cisco router is also doing NAT. I'm assuming that's a problem as well because now the router doesn't know what the source IP is anymore. Any other ideas on how to make this work better? Thanks, Dan. On Sat, Aug 16, 2008 at 6:35 PM, Ben Steele [EMAIL PROTECTED] wrote: Dan the reason your having issues is not MTU related, it's NAT related, because you have 3 ADSL lines each doing NAT against a different outside IP when you turn on per-packet load sharing you end up with flows to the same destination having different source IP addresses. Your only option is per-destination load balancing (ie the default), one way you can tweak this a little without breaking to much is to change the standard algorithm to include ports. Try adding ip cef load-sharing algorithm include-ports destination into your global config once you've removed your per-packet load sharing and see how you go. You are never going to get perfect load balancing in your scenario but if you have enough hosts on your LAN it should be sufficient enough, one way you can do per-packet is if you get another IP routed down all 3 adsl lines and put it on a loopback and NAT everything against that. Ben - Original Message - From: Dan Letkeman [EMAIL PROTECTED] To: Rodney Dunn [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Saturday, August 16, 2008 3:29 AM Subject: Re: [c-nsp] ip cef load sharing Still seem to have the same problem even with this: interface FastEthernet0/0 ip address 10.1.10.1 255.255.255.0 ip tcp adjust-mss 1300 duplex auto speed auto interface FastEthernet0/1 ip address 192.168.10.1 255.255.255.0 ip load-sharing per-packet duplex auto speed auto Dan. On Fri, Aug 15, 2008 at 12:49 PM, Rodney Dunn [EMAIL PROTECTED] wrote: On Fri, Aug 15, 2008 at 12:35:01PM -0500, Dan Letkeman wrote: ip load-sharing per-packet I tried adding this to F0/1 and the trace route works now(it randomly picks either line), but there seems to be issues with maybe the MTU? If I try to browse websites i get page errors and some of the pictures and pages don't load. Yep...try configuring ip tcp adjust-mss 1300 or so on the ingress interface from the LAN. Any ideas? Thanks, Dan. On Fri, Aug 15, 2008 at 12:12 PM, Rodney Dunn [EMAIL PROTECTED] wrote: Try ip load-sharing per-packet on both egress interfaces. On Fri, Aug 15, 2008 at 12:00:46PM -0500, Dan Letkeman wrote: Hello, I have a 2621 router running 12.3(26) and I would like to setup load sharing to multiple adsl lines. When I do a traceroute on the router it randomly picks a dsl line and seems to work fine. But when I do traceroute tests from a workstation it always seems to take the same adsl line. Is there something else I need to add to the configuration to make it pick random lines, or is there a timeout of some sorts before it will select the next ip route Here is my config: ! interface FastEthernet0/0 ip address 10.1.10.1 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 ip address 192.168.10.1 255.255.255.0 duplex auto speed auto ! ip http server ip classless ip route 0.0.0.0 0.0.0.0 192.168.10.10 ip route 0.0.0.0 0.0.0.0 192.168.10.11 ! The two adsl modem/routers I have are 192.168.10.10, and 192.168.10.11 Thanks, Dan. ___ 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] multicast bringing big irons to their knees?
I suggest posting on foundry-nsp instead of cisco-nsp. - jared On Mon, Aug 18, 2008 at 09:03:05AM -0700, Christian MacNevin wrote: Hi I've only got the most superficial of ideas what's going on with this network, but i've been asked if there's any particular reason some Foundry switches would be being brought to their knees every time mcast is switched on in a network. 65s, 3750s and Netscreens all handle it fine. Given Foundry's marketing, they dobrag that everything's handled in port-based ASICs, but obviously it sounds like this stuff is going to the processor. Maybe it's PIM Sniffing not supported in hardware, not sure. Anyway, sorry for the amazing vagary here, but it's all I've got right now. Any thoughts? Cheers Christian___ 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/ -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ 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] multicast bringing big irons to their knees?
Hi Christian, You will need to explain more about the topology, your multicast setup and the traffic flows, for instance: - Are the foundary switches acting as your RPs? - Have you any other commands applied which will cause multicasts to be process switched? - Do you have high rates of multicast on the network? - Are you using any multicast groups which will appear the same as well known multicast groups at Layer 2 (e.g. x.0.0.1, x.0.0.2 etc)? If the Foundary switches are your RPs, the requirement to decapsulate register messages could explain why these are affected much more than your 6500s, 3750s and netscreens. 'ip pim register-rate-limit 5' applied to the cisco designated routers will help if that is the problem (not sure about equivalent netscreeen command). Paul. Christian MacNevin wrote: Hi I've only got the most superficial of ideas what's going on with this network, but i've been asked if there's any particular reason some Foundry switches would be being brought to their knees every time mcast is switched on in a network. 65s, 3750s and Netscreens all handle it fine. Given Foundry's marketing, they dobrag that everything's handled in port-based ASICs, but obviously it sounds like this stuff is going to the processor. Maybe it's PIM Sniffing not supported in hardware, not sure. Anyway, sorry for the amazing vagary here, but it's all I've got right now. Any thoughts? Cheers Christian___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] Fwd: Alternantive to REB(route bridge Encapsulation)-2nd try
On Sunday 17 August 2008 05:05:30 Gert Doering wrote: From the comments seen on this list, I don't think that any sort of L2VPN on 7500s is a good idea. 7500 is pretty much a dead and unsupported platform these days. Good afternoon, list and Gert. I have read this list for some time now, and I am very grateful for much useful and constructive advice that I have seen that is relevant to what I am doing. However, I must rant just a bit, so please indulge me for a moment. And I fully realize many of you won't care about what I'm going to talk about below, and that's ok. Not all folk using older Cisco gear for core routing are financially able to do forklift upgrades. Some people, in this day of shrinking IT budgets and lowering bandwidth costs/margins (at least to NSP's; the enterprise user is seeing the opposite problem; for example, my OC3's base tariff went UP $1,000 per month thanks to tariff changes by the NECA), simply don't have the budget to write off their investment in older gear and drop in a newer platform. Although, PARI WILL accept your donation of older gear after you've done a forklift upgrade! There are non-profits (and for-profits that are turning into non-profits involuntarily) out there who would like to hear something a little more constructive than 'your platform is EoS; time to upgrade'. If I personally ask 'hey, anybody out there ever done L2TPv3 on a 7500/12012 pair that's serving an APS protected OC3 to a pair of 7401ASR's serving the other end of the APS protected OC3, and what have you found?' I don't want to hear 'you need to get a new whizbang 2 to do that; all four of your routers are too old'. I'd like to hear what people have experienced; and, Gert, your experiences in particular have been very enlightening to me. I (and other enterprise usera and NSP's in my boat; I use an NSP who is a non-profit, for instance) am well aware that I should have something more modern; I cannot afford it, especially now that a big hunk of my equipment budget just went away thanks to the NECA tariff increase. And while I know that there is a contingent out there with the attitude that if someone can't afford rolling forklift upgrades every few years that they shouldn't be in business, I have no need for their opinion on that matter. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 http://www.pari.edu ___ 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] Netflow TopTalkers and Modular 12.2(18)SXF4
Hi, Does anyone have experience of configuring Netflow Top Talkers on Modular 12.2SX images? We are running modular 12.2(18)SXF4 on Sup720, MSFC3, PFC3 on 6509-E, as below: sh ver Cisco Internetwork Operating System Software IOS (tm) s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN-VM), Version 12.2(18)SXF4, RELEASE SOFTWARE (fc1) ..output ommited... disk0:/sys/s72033/base/s72033-advipservicesk9_wan-vm ..output ommited... Thanks, Mark Mark Tohill UTV Internet T:+44 (0)28 90 262196 M:+44 (0)7786 278716 E:[EMAIL PROTECTED] BLOCKED::mailto:[EMAIL PROTECTED] ___ 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] Nasty PIX 6.3 bug
On Mon, Aug 18, 2008 at 4:30 AM, Robert Blayzor [EMAIL PROTECTED] wrote: We've been running 6.3 for years and only after all the recent DNS exploits did we see this one start hitting us. The only way to fix it is to upgrade to 7.x or get the maint/patch train from TAC. If you have any DNS servers behind your PIX with a lot of clients The page says it's patched in 6.3(5.105) -- is that available only from the TAC? CCO lists just 6.3(5) GD. Forgive my ignorance, but it's been a long time since I've had to get a special file from TAC -- does an end-user have to have smartnet on the device? --Adam ___ 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] Fwd: Alternantive to REB(route bridge Encapsulation)-2nd try
Lamar Owen wrote: However, I must rant just a bit, so please indulge me for a moment. And I fully realize many of you won't care about what I'm going to talk about below, and that's ok. It's not that I won't care, it's that I care about your stance here. I (and other enterprise usera and NSP's in my boat; I use an NSP who is a non-profit, for instance) am well aware that I should have something more modern; I cannot afford it, especially now that a big hunk of my equipment budget just went away thanks to the NECA tariff increase. And while I know that there is a contingent out there with the attitude that if someone can't afford rolling forklift upgrades every few years that they shouldn't be in business, I have no need for their opinion on that matter. The 7500s are roughly 13 years old. As such, they've served about four generations of IT lifecycle and then some, assuming upgrades every few years. From what little I can dig up, they were designed for core backbone routing applications. The 12000 series is perhaps 9 years old. That's three lifecycles, and these too were designed for core backbone routing applications. Remember the great time-to-market linecards? Yeah, the ones with no hope of being an edge card. With all due respect, how much enterprise feature value were you HONESTLY expecting from these core backbone routing platforms? Have any of these devices STOPPED doing what they do/did best? pt ___ 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] multicast bringing big irons to their knees?
Thanks all That's literally all the info I have just now, it's a client network I may have to go look at. Just figured I'd toss it out and see if anybody had a screamer of a disclaimer on that hardware. I'll see how much more Ivan find out before I being this world of pain down on myself :) Sent from my iPhone On Aug 18, 2008, at 9:33 AM, Paul Cosgrove [EMAIL PROTECTED] wrote: Hi Christian, You will need to explain more about the topology, your multicast setup and the traffic flows, for instance: - Are the foundary switches acting as your RPs? - Have you any other commands applied which will cause multicasts to be process switched? - Do you have high rates of multicast on the network? - Are you using any multicast groups which will appear the same as well known multicast groups at Layer 2 (e.g. x.0.0.1, x.0.0.2 etc)? If the Foundary switches are your RPs, the requirement to decapsulate register messages could explain why these are affected much more than your 6500s, 3750s and netscreens. 'ip pim register-rate-limit 5' applied to the cisco designated routers will help if that is the problem (not sure about equivalent netscreeen command). Paul. Christian MacNevin wrote: Hi I've only got the most superficial of ideas what's going on with this network, but i've been asked if there's any particular reason some Foundry switches would be being brought to their knees every time mcast is switched on in a network. 65s, 3750s and Netscreens all handle it fine. Given Foundry's marketing, they dobrag that everything's handled in port-based ASICs, but obviously it sounds like this stuff is going to the processor. Maybe it's PIM Sniffing not supported in hardware, not sure. Anyway, sorry for the amazing vagary here, but it's all I've got right now. Any thoughts? Cheers Christian___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] Nasty PIX 6.3 bug
On Aug 18, 2008, at 1:05 PM, Adam Korab wrote: The page says it's patched in 6.3(5.105) -- is that available only from the TAC? CCO lists just 6.3(5) GD. Yes, 6.3(5)GD is released. The actual patched version TAC provided to us was 6.3(5.145) Which fixed the problem. And yes, you can only obtain it via TAC. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ 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] debugging stack corruption
anyone see anything like this. i assume only a reload will fix this:
rtr1#sh proc cpu | e 0.0
CPU utilization for five seconds: 33%/8%; one minute: 37%; five minutes:
35%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
3528125122320274973 22 23.35% 20.79% 20.97% 0 Exec
70 3616544001417549298255 0.15% 0.11% 0.12% 0 IP Input
115 4851843096833738 0 0.15% 0.14% 0.15% 0 HQF Shaper Backg
rtr1#
nobody else is logged on, little to no amount of traffic is running
through the aux/cons ports, but this is interesting:
rtr1#show stacks
Minimum process stacks:
Free/Size Name
5676/6000 CDP BLOB
8640/9000 EM ED RF
11052/12000 Router Init
8676/9000 cdp init process
8348/12000 Init
5304/6000 RADIUS INITCONFIG
3616/6000 BGP Open
2264/3000 Rom Random Update Process
5616/6000 URPF stats
5316/6000 BGP Accepter
9248/12000 Exec
7176/12000 SSH Process
4264/6000 TFTP Read Process
4204/6000 MSDP Open
34540/36000 TCP Command
5236/7200 TTY Daemon
8496/9000 IP-EIGRP Router
3360/6000
d^\ytd^[^P^Ld^\zTd^[`Dd^[I$d^\^[Td^[T^Dd^\y^Dd^\^P[EMAIL
PROTECTED]d^\^B,[EMAIL PROTECTED])$d^[pLd^[|^\d^\
,d^[mdd^\^Nld^\
dd^[4d^[Qd^[^V^\d^\1dd^[1d^[O4d^[|Dd^\^Pd^[^Ydd^[e\d^[)$d^[NTd^[
4d^[1^Dd^[`Td^[{td^[^E^\d^[md^[^Z^Ld^[8d^[}^Dd^[j^\d^\^Q|d^[x^\d^[u^\d^\
,d^\^ALd^[jTd^[pLd^[|^\d^[~td^[^D,d^[RDd^ld^[x$d^[^^Dd^[ptd^[^Bld^[^QLd^[^Q\d^[
ld^[zdd^\,$d^[ttd^[^Vdd^[iLd^[^X\d^[)4d^\34d^[v$d^[^VTd^\^Ptd^^\d^[{Dd^[R|d^\^Q^\d^[`^Ld^[]^Ld^\
,d^[^R^Dd^[^Fld^[\d^[b^Td^[^LDd^\^P^Dd^[^B4d^[^NLd^[^Y,d^[^Kdd^\
^\d^\^CDd^[s^Td^[^A^\d^[U,d^[j,d^[~^Dd^\^QDd^[Jtd^[~Ld^[|^Td^[,Dd^^\d^[rld^[R|d^[{Dd^[
\d^[^Add^[^Q\d^[^QLd^[
ld^[ttd^[zdd^\,$d^[^Vdd^[)4d^\34d^[wLd^[m,d^[^Z|d^[\,d^[g|d^[y|d^[^Dd^[x$d^[^^Dd^[
ld^[^Bld^[RDd^[ptd^[^Q$d^[v4d^\^Ptd^[^VTd^[7$d^\1td^[P$d^[uTd^[^VTd^[zdd^[7$d^[z,[EMAIL
PROTECTED]^Dd^\,$d^\+Dd^\,4d^[^Dd^\`^Dd^[^VTd^[k4d^[P^Td^[a$d^[$d^[^V^\d^[^Utd^[mdd^[^Ytd^[|^Ld^[^L^Ld^\^ALd^[#^Dd^[e\d^[f^Dd^\^FTd^[^Pld^[^B|d^[n^\d^[d4d^[H|d^[^Rtd^[^N^Td^Td^[^Td^[{,d^[+dd^[`Td^[.^Dd^[s\d^[^ETd^[^Z^Ld^[
$d^[YTd^\^L^Dd^[1^Dd^[^O^\d^[^PDd^[^L^\d^\
dd^[
Ld^[)$d^[#td^[1d^[^E|d^[^_Ld^[KTd^[
4d^[^BDd^[yLd^[+,d^[^E^\d^\^S^Dd^[
4d^[y^Td^[^WDd^[l\d^[Y|d^\1^Dd^\0$d^\/Dd^\1dd^[{^Dd^[^SDd^[^LTd^[|^\d^[H4d^[pLd^[Md^[.,d^[]ld^[Qd^[U^\d^[~td^[l$d^[8d^[6^Ld^[^F4d^[^Odd^\^O$d^[^Kd^[^Nd^[^K^Dd^[^W4d^[_,d^[p^Dd^[+^\d^[N,d^[$Td^[~^\d^[eLd^[NTd^[
,d^[xTd^[r4d^[u^\d^[n^Ld^[rDd^[p^Td^[{td^[~d^\
,d^[}$d^[}^Dd^[P\d^[w|d^[mtd^[O4d^[{ld^[x\d^[?d^[md^[
d^[o4d^[wd^[yd^[*d^\^Pd^[u|d^[^Ydd^\^Pdd^[^Yd^[D|d^\^P,d^[.td^\^Nld^\^N4d^[|Dd^[$^\d^[jTd^[q,d^[j^\d^[\Td^\^Q|d^[f,d^[^D,d^[gDd^[x^\d^[]4d^\Dd^[w^Ld^[bLd^[L\d^[
Dd^[dld^[.d^[Lld^\ td^\4d^\ld^^Td^\d^\ d^\
^Dd^Ld^$d^[,d^[dd^[^\d^[Td^\
6856/9000
d^\^[Td^[T^Dd^\y^Dd^\^P[EMAIL PROTECTED]d^\^B,[EMAIL
PROTECTED])$d^[pLd^[|^\d^\
,d^[mdd^\^Nld^\
dd^[4d^[Qd^[^V^\d^\1dd^[1d^[O4d^[|Dd^\^Pd^[^Ydd^[e\d^[)$d^[NTd^[
4d^[1^Dd^[`Td^[{td^[^E^\d^[md^[^Z^Ld^[8d^[}^Dd^[j^\d^\^Q|d^[x^\d^[u^\d^\
,d^\^ALd^[jTd^[pLd^[|^\d^[~td^[^D,d^[RDd^ld^[x$d^[^^Dd^[ptd^[^Bld^[^QLd^[^Q\d^[
ld^[zdd^\,$d^[ttd^[^Vdd^[iLd^[^X\d^[)4d^\34d^[v$d^[^VTd^\^Ptd^^\d^[{Dd^[R|d^\^Q^\d^[`^Ld^[]^Ld^\
Minimum process stacks:
Free/Size Name
,d^[^R^Dd^[^Fld^[\d^[b^Td^[^LDd^\^P^Dd^[^B4d^[^NLd^[^Y,d^[^Kdd^\
^\d^\^CDd^[s^Td^[^A^\d^[U,d^[j,d^[~^Dd^\^QDd^[Jtd^[~Ld^[|^Td^[,Dd^^\d^[rld^[R|d^[{Dd^[
\d^[^Add^[^Q\d^[^QLd^[
ld^[ttd^[zdd^\,$d^[^Vdd^[)4d^\34d^[wLd^[m,d^[^Z|d^[\,d^[g|d^[y|d^[^Dd^[x$d^[^^Dd^[
ld^[^Bld^[RDd^[ptd^[^Q$d^[v4d^\^Ptd^[^VTd^[7$d^\1td^[P$d^[uTd^[^VTd^[zdd^[7$d^[z,[EMAIL
PROTECTED]^Dd^\,$d^\+Dd^\,4d^[^Dd^\`^Dd^[^VTd^[k4d^[P^Td^[a$d^[$d^[^V^\d^[^Utd^[mdd^[^Ytd^[|^Ld^[^L^Ld^\^ALd^[#^Dd^[e\d^[f^Dd^\^FTd^[^Pld^[^B|d^[n^\d^[d4d^[H|d^[^Rtd^[^N^Td^Td^[^Td^[{,d^[+dd^[`Td^[.^Dd^[s\d^[^ETd^[^Z^Ld^[
$d^[YTd^\^L^Dd^[1^Dd^[^O^\d^[^PDd^[^L^\d^\
dd^[
Ld^[)$d^[#td^[1d^[^E|d^[^_Ld^[KTd^[
4d^[^BDd^[yLd^[+,d^[^E^\d^\^S^Dd^[
4d^[y^Td^[^WDd^[l\d^[Y|d^\1^Dd^\0$d^\/Dd^\1dd^[{^Dd^[^SDd^[^LTd^[|^\d^[H4d^[pLd^[Md^[.,d^[]ld^[Qd^[U^\d^[~td^[l$d^[8d^[6^Ld^[^F4d^[^Odd^\^O$d^[^Kd^[^Nd^[^K^Dd^[^W4d^[_,d^[p^Dd^[+^\d^[N,d^[$Td^[~^\d^[eLd^[NTd^[
,d^[xTd^[r4d^[u^\d^[n^Ld^[rDd^[p^Td^[{td^[~d^\
,d^[}$d^[}^Dd^[P\d^[w|d^[mtd^[O4d^[{ld^[x\d^[?d^[md^[
d^[o4d^[wd^[yd^[*d^\^Pd^[u|d^[^Ydd^\^Pdd^[^Yd^[D|d^\^P,d^[.td^\^Nld^\^N4d^[|Dd^[$^\d^[jTd^[q,d^[j^\d^[\Td^\^Q|d^[f,d^[^D,d^[gDd^[x^\d^[]4d^\Dd^[w^Ld^[bLd^[L\d^[
Dd^[dld^[.d^[Lld^\ td^\4d^\ld^^Td^\d^\ d^\
^Dd^Ld^$d^[,d^[dd^[^\d^[Td^\
10468/12000 HSRP (Standby)
Interrupt level stacks:
LevelCalled Unused/Size Name
1 2648551315 6280/9000 Network interfaces
2 0 9000/9000 DMA/Timer Interrupt
3 185107 7472/9000 PA Management Int Handler
4 1715750501 8444/9000 Console Uart
5 0 9000/9000 OIR/Error Interrupt
7 3207930022 8532/9000 NMI Interrupt Handler
Spurious interrupts: 233
rtr1#
and on a different router:
rtr1.chi#sh stacks
Minimum process stacks:
Re: [c-nsp] Fwd: Alternantive to REB(route bridge Encapsulation)-2nd try
Hi, On Mon, Aug 18, 2008 at 12:40:23PM -0400, Lamar Owen wrote: Not all folk using older Cisco gear for core routing are financially able to do forklift upgrades. I fully understand your point. I'm not one of those that recommend to put a 7206/NPE-150 into the junk bin, just because it's old... Cisco-XXX uptime is 7 years, 15 weeks, 2 days, 49 minutes ... cisco 7206 (NPE150) processor with 57344K/8192K bytes of memory. (yes, I know, but that's not the point. It's working, and all problematic packets are ACLed away) *But* especially the 7500 is not old, it was already old when I started networking (well, the 7500 was new then, but it shares much of the architectural limits with the 7000, and that one was already old then). We have junked our single 7500 (at some time my great pride - dual RSP4+s in there!!!) some 3-4 years ago, because it was just too huge (space and power in the rack), too unreliable (OIRs usually caused a bus stall or a complete crash), and too feeble IOS support - no real 12.2S support, none of the cool features available, and a fairly clear commitment from Cisco to let the platform die. If a shop is in serious need for a L2VPN solution, and all they have is a 7500, I would seriously suggest finding two old PCs somewhere, put in a $15 intel GigE card, install Linux+OpenVPN, and enjoy the result. With Cisco, they are not going to be happy - it's expensive or more advanced/tricky things are just not going to work. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] pgp6B7qDQ0zCI.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] Fwd: Alternantive to REB(route bridge Encapsulation)-2nd try
Hi, On Mon, Aug 18, 2008 at 03:00:22PM -0400, Lamar Owen wrote: good firewall set and, like I said, NAT. Just wish a 12.0S had been released for the RSM; it is, after all, a 7500-series RSP2 on that card. And why the RSFC isn't able to run something past 12.1 is a crying shame, given the hardware heritage of the card (I know why it was crippled, I just don't agree with non-technical reasons to cripple what the device can do). I couldn't agree more wiht you on *that*. We're in the process of retiring 2 RSMs and 1 RSFC due to end of IOS - no IPv6 on them, and especially on the RSFC, purposely crippled to 12.1 (no 64bit counters and such). Since I'm the one that suggested buying them, and the hardware is still doing its job very well, I'm indeed not overly happy. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] pgp3NJY8GCgTx.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] Good 10GE Metro switch
Turns out the fiber length is about 60km, but it is testing at 13dB for 1550 nm. This winds up fitting in the 24dB optical budget for the XENPAK-10GB-ZR (80 km). I have removed dB for connectors and potential splices as well. Next challenge: On the other end of the connection is a Juniper MX. So here we go again ... You should be just fine with a 10-GBASE-Z (80 km) XFP on the Juniper MX. See for instance Table 3 on this page: http://www.juniper.net/techpubs/hardware/common/mx-series-dpc/4-port-10-gigabit-ethernet-dpc-with-xfp.html#mx-series-dpc-4xge-xfp Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ 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] CAB-HD8-ASYNC extension cables?
Does anyone know what the formal name for the 'HD' end of an CAB-HD8-ASYNC (for the HWIC-8A/16A)? Ideally I'd like to do an extended runbefore fanning out into RJ45's. Also, given the async line definition of: line 0/0/0 0/1/15 ...is it proper to infer that 0/0 has 16 ports? Namely, if 0/0 was an 8 port module, would it be broken out, separately such that IOS would present: line 0/0/0 0/0/7 line 0/1/0 0/1/15 ___ 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] Good 10GE Metro switch
Wow. Thanks Steinar, I've been looking all over their website for this! Looks like about the same power budget as the Cisco XENPAK-10GB-ZR. Joe [EMAIL PROTECTED] 08/18/2008 04:46 PM To Joe Loiacono/CIV/[EMAIL PROTECTED] cc cisco-nsp@puck.nether.net Subject Re: [c-nsp] Good 10GE Metro switch Turns out the fiber length is about 60km, but it is testing at 13dB for 1550 nm. This winds up fitting in the 24dB optical budget for the XENPAK-10GB-ZR (80 km). I have removed dB for connectors and potential splices as well. Next challenge: On the other end of the connection is a Juniper MX. So here we go again ... You should be just fine with a 10-GBASE-Z (80 km) XFP on the Juniper MX. See for instance Table 3 on this page: http://www.juniper.net/techpubs/hardware/common/mx-series-dpc/4-port-10-gigabit-ethernet-dpc-with-xfp.html#mx-series-dpc-4xge-xfp Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ 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] Netflow TopTalkers and Modular 12.2(18)SXF4
On Mon, Aug 18, 2008 at 05:12:46PM +0100, Mark Tohill wrote: Hi, Does anyone have experience of configuring Netflow Top Talkers on Modular 12.2SX images? I thought netflow top-talkers was an SXH feature? We are running modular 12.2(18)SXF4 on Sup720, MSFC3, PFC3 on 6509-E, as below: sh ver Cisco Internetwork Operating System Software IOS (tm) s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN-VM), Version 12.2(18)SXF4, RELEASE SOFTWARE (fc1) ..output ommited... disk0:/sys/s72033/base/s72033-advipservicesk9_wan-vm ..output ommited... Ok - but what are you asking? ___ 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] debugging stack corruption
anyone see anything like this. i assume only a reload will fix this: Nothing exactly like this, but I have a number of crash files from SB11/12 on a 7200 with memory corruption (Block overrun/redzone corruption). Unfortunately the 7200 (a non-VXR) cannot be on maintenance (EOS/EOL), so I cannot open a TAC case (and no existing bugid seemed relevant). That is what I would recommend to you (open a TAC case). Gary ___ 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] Need some guidance for T1 / wireless ethernet handoff load balancing/failover setup
I have a customer who went directly to cisco to ask about how to load balance two WAN connections to their Cisco PIX 515E. Cisco sold them an ASA 5510 and two 1841s and suggested VRRP or GLBP for the LAN with the ASA and 1841s. Apparantly, the customer didn't even mention that the two connections were to the same ISP, me. The customer just ordered the equipment and said Make it work. The WANs are T1 (existing) and 4Mbps ethernet delivered via a wireless network. Cisco sales tech guy said: What we discussed was the ASA having a default route to the virtual IP address of the routers and they would be running either VRRP or GLBP (whatever they decided they wanted to do) going out to the service provider. Then the routers would simply have a default route going out to the service provider to hit the 'Net. The network design is supposed to be something like : Cisco 7204VXR NPE G1 (ISP) || T1Wireless network cloud || Cisco 1841 Cisco 1841 || -+---++- | Cisco ASA 5510 (Customer) The wireless network cloud is creating logistical issues for me. The wireless ethernet makes multiple hops through StarOS based routers which do not speak OSPF, yet. I have to staticly route traffic to the wireless cloud. The wireless network is handled by a different group here and I don't have much influence over how they run it. I've been running ISP routers for 10 years, but have not had this configuration come up before. 99.% of my customers have been single homed to me. Also, ASA/PIX devices haven't been common for me until the past couple of years and I keep running into areas where they seem to try very hard to avoid having common routing features. I'm primarily a servers guy but when you work in small ISPs, you get to do everything. I could use some guidence in the best way to make these links load balance with graceful degradation if one link should fall down. I've been considering bringing up an IPSec VPN from the 7204VXR to the 1841 handling the wireless ethernet connection, just to bypass the need for dynamic routing in the wireless network. Then I could run OSPF or other magic between the 1841s and my 7204. Is OSPF going to be enough to load balance the links, or will I need something else? If not, could an MLPPP bundle be brought up which uses the T1 and an IPSec tunnel? But then, how would I use the 1841s redundantly? To keep the 1841s redundant, do I need to use their existing router to act as a T1 to ethernet bridge? Also, on the VRRP front, the customer currently has a /29 LAN subnet outside their ASA. The current T1 router has one IP and the rest of the IPs are in use on the ASA. Will we need to renumber them to a /28 subnet? Or, can the virtual router address be from their current subnet with the individual routers having their primary IPs from another, RFC 1918, subnet? The 7204VXR is running at 55% CPU load handling about 1800 PPPo(A|E) connections. If I configure the VirtualTemplates to permit CEF, which lowers CPU utilization to about 30%, the router hangs in an ininite loop at random intervals, at least with c7200-ik91s-mz.122-28.SB5.bin. Any of the 12.2 SB series images at the time I last tried CEF did the same thing and I haven't had enough nerve to try again since. Hopefully, that is not important right now. The only reason I mention it is in case an IPSec tunnel, or whatever the necessary magic ends up being, might make a significant impact on the CPU. -- Scott LambertKC5MLE Unix SysAdmin [EMAIL PROTECTED] ___ 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] ip cef load sharing
Dan, Another option is to use the PfR NAT integration. The idea is that PfR will actively monitor the traffic and move subnet reachabilty around to try to even out the traffic. For existing NATed flows, PfR will preserve the stickiness on the established path. http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/ps8787/white_paper_C11-458124.html -- Aamer Akhter / [EMAIL PROTECTED] Ent Commercial Systems, cisco Systems -Original Message- From: [EMAIL PROTECTED] [mailto:cisco-nsp- [EMAIL PROTECTED] On Behalf Of Dan Letkeman Sent: Monday, August 18, 2008 12:06 PM To: Ben Steele; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ip cef load sharing My only options for the IP CEF command are as follows: original Original algorithm tunnel Algorithm for use in tunnel only environments universal Algorithm for use in most environments I tried original, and it seems as if it load balances, but it doesn't switch from modem to modem very fast. But in any case there is a lot less problems with this on. I also found out that the content filter that is before the cisco router is also doing NAT. I'm assuming that's a problem as well because now the router doesn't know what the source IP is anymore. Any other ideas on how to make this work better? Thanks, Dan. On Sat, Aug 16, 2008 at 6:35 PM, Ben Steele [EMAIL PROTECTED] wrote: Dan the reason your having issues is not MTU related, it's NAT related, because you have 3 ADSL lines each doing NAT against a different outside IP when you turn on per-packet load sharing you end up with flows to the same destination having different source IP addresses. Your only option is per-destination load balancing (ie the default), one way you can tweak this a little without breaking to much is to change the standard algorithm to include ports. Try adding ip cef load-sharing algorithm include-ports destination into your global config once you've removed your per-packet load sharing and see how you go. You are never going to get perfect load balancing in your scenario but if you have enough hosts on your LAN it should be sufficient enough, one way you can do per-packet is if you get another IP routed down all 3 adsl lines and put it on a loopback and NAT everything against that. Ben - Original Message - From: Dan Letkeman [EMAIL PROTECTED] To: Rodney Dunn [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Saturday, August 16, 2008 3:29 AM Subject: Re: [c-nsp] ip cef load sharing Still seem to have the same problem even with this: interface FastEthernet0/0 ip address 10.1.10.1 255.255.255.0 ip tcp adjust-mss 1300 duplex auto speed auto interface FastEthernet0/1 ip address 192.168.10.1 255.255.255.0 ip load-sharing per-packet duplex auto speed auto Dan. On Fri, Aug 15, 2008 at 12:49 PM, Rodney Dunn [EMAIL PROTECTED] wrote: On Fri, Aug 15, 2008 at 12:35:01PM -0500, Dan Letkeman wrote: ip load-sharing per-packet I tried adding this to F0/1 and the trace route works now(it randomly picks either line), but there seems to be issues with maybe the MTU? If I try to browse websites i get page errors and some of the pictures and pages don't load. Yep...try configuring ip tcp adjust-mss 1300 or so on the ingress interface from the LAN. Any ideas? Thanks, Dan. On Fri, Aug 15, 2008 at 12:12 PM, Rodney Dunn [EMAIL PROTECTED] wrote: Try ip load-sharing per-packet on both egress interfaces. On Fri, Aug 15, 2008 at 12:00:46PM -0500, Dan Letkeman wrote: Hello, I have a 2621 router running 12.3(26) and I would like to setup load sharing to multiple adsl lines. When I do a traceroute on the router it randomly picks a dsl line and seems to work fine. But when I do traceroute tests from a workstation it always seems to take the same adsl line. Is there something else I need to add to the configuration to make it pick random lines, or is there a timeout of some sorts before it will select the next ip route Here is my config: ! interface FastEthernet0/0 ip address 10.1.10.1 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 ip address 192.168.10.1 255.255.255.0 duplex auto speed auto ! ip http server ip classless ip route 0.0.0.0 0.0.0.0 192.168.10.10 ip route 0.0.0.0 0.0.0.0 192.168.10.11 ! The two adsl modem/routers I have are 192.168.10.10, and 192.168.10.11 Thanks, Dan. ___ 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
Re: [c-nsp] CAB-HD8-ASYNC extension cables?
On Aug 18, 2008, at 5:01 PM, Kevin Graham wrote: Does anyone know what the formal name for the 'HD' end of an CAB-HD8- ASYNC (for the HWIC-8A/16A)? Ideally I'd like to do an extended runbefore fanning out into RJ45's. The connector on the cards are (Micro)D68F (also used by SCSI-3 devices). You would be looking for a D68M-D68F cable to extend the connection. Check with your favorite cabling vendor for pricing, but it may be cheaper to extend the RJ45's than purchase a D68 cable...though I'd admit the D68 extension is a tidier solution in the rack :). I was also able to come up with vendors that make custom length CAB-HD8-ASYNC compatible cables, that start in the neighborhood of $100USD. PGP.sig Description: This is a digitally signed message part ___ 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] Need some guidance for T1 / wireless ethernet handoff load balancing/failover setup
Hi Scott, Hopefully I am understanding your challenge correctly. It appears to me like you're having trouble chatting dynamic routing protocols directly with the wireless network, among some other various nitty-gritty that is not just as simple as the SE tries to make it sound. Looking at your diagram, it seems that the 7204 also should have a route to the 1841 via the mysterious cloud there, albeit a few more hops in between. For obvious reasons (lack of link state awareness), plain old static routing isn't a reliable option in your scenario. With that said, OSPF may not even be necessary. Have you considered the possibility of running ebgp-multihop from the Cisco 7204XVR to the 1841's interface directly connected to the wireless network? You could also establish a private BGP session with the other 1841 via the directly connected T1 link, and announce the same prefix out of both sessions. As for the VRRP question: If memory serves, I want to say yes, you can use a real IP address that does not exist in the same subnet as the floating virtual; at least, this worked the last time I tried to do it so far as I can recall. Unfortunately for the past year and change, I've been dealing with a limitation on a never-to-be-named hardware/software platform that just recently started allowing this... uhm, feature. I'm still kind of scratching my head on a good, clean way to load-balance this outbound for you, given only one of the routers is going to serve as the ASA's default route out in a VRRP/HSRP configuration. I'm sure there is an answer, it just doesn't look pretty in my head. Maybe the answer here is to do OSPF between the 1841s and the ASA, all in NBMA mode so that the 1841s aren't trying to share a default to one another. The only thing the 1841s should need to do are A) create an adjacency with the ASA, and b) advertise it a default route. In that case, it may be necessary to expand to a /28 if everything else is in use on that subnet. Maybe someone else has a better solution -- that's at least the one I'd try to lab out first, if it were me. Just something to think about, I guess... :) -Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Lambert Sent: Monday, August 18, 2008 7:36 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Need some guidance for T1 / wireless ethernet handoff load balancing/failover setup I have a customer who went directly to cisco to ask about how to load balance two WAN connections to their Cisco PIX 515E. Cisco sold them an ASA 5510 and two 1841s and suggested VRRP or GLBP for the LAN with the ASA and 1841s. Apparantly, the customer didn't even mention that the two connections were to the same ISP, me. The customer just ordered the equipment and said Make it work. The WANs are T1 (existing) and 4Mbps ethernet delivered via a wireless network. Cisco sales tech guy said: What we discussed was the ASA having a default route to the virtual IP address of the routers and they would be running either VRRP or GLBP (whatever they decided they wanted to do) going out to the service provider. Then the routers would simply have a default route going out to the service provider to hit the 'Net. The network design is supposed to be something like : Cisco 7204VXR NPE G1 (ISP) || T1Wireless network cloud || Cisco 1841 Cisco 1841 || -+---++- | Cisco ASA 5510 (Customer) The wireless network cloud is creating logistical issues for me. The wireless ethernet makes multiple hops through StarOS based routers which do not speak OSPF, yet. I have to staticly route traffic to the wireless cloud. The wireless network is handled by a different group here and I don't have much influence over how they run it. I've been running ISP routers for 10 years, but have not had this configuration come up before. 99.% of my customers have been single homed to me. Also, ASA/PIX devices haven't been common for me until the past couple of years and I keep running into areas where they seem to try very hard to avoid having common routing features. I'm primarily a servers guy but when you work in small ISPs, you get to do everything. I could use some guidence in the best way to make these links load balance with graceful degradation if one link should fall down. I've been considering bringing up an IPSec VPN from the 7204VXR to the 1841 handling the wireless ethernet connection, just to bypass the need for dynamic routing in the wireless network. Then I could run OSPF or other magic between the 1841s and my 7204. Is OSPF going to be enough to load balance the links, or will I need something else? If not, could an MLPPP bundle be brought up which uses the T1 and an IPSec tunnel? But then, how would I use the 1841s redundantly? To keep the 1841s redundant, do I
[c-nsp] Will there be a Cisco 887?
Hey all, I am trying to plan some CPE deployments for next year and wanted more information about the 880 series. I love the Wireless N and the 3G backup on the 881. But this is a ADSL2 deployment which I was going to use 877W's for, but given the move to N and the 3G option, I would prefer an 887. but I can't find out if they are going to release one or not. The 881 I understand, but the 888 (SHDSL) I have no idea why that would come BEFORE an ADSL2 model. Can someone at Cisco possibly enlighten me? .Skeeve -- Skeeve Stevens, RHCE [EMAIL PROTECTED] / www.skeeve.org Cell +61 (0)414 753 383 / skype://skeeve eintellego - [EMAIL PROTECTED] - www.eintellego.net -- I'm a groove licked love child king of the verse Si vis pacem, para bellum ___ 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] Need some guidance for T1 / wireless ethernet handoff load balancing/failover setup
BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }
Hi Scott,
Try this:
Seeing as you are working statics over your wireless cloud to
simplify things a little setup a GRE tunnel from your 7200 over the
wireless to the 1841 (don’t forget to subtract 24 bytes off the MTU,
ie if it's a 1500 path put ip mtu 1476 in the tunnel interface and
also add keepalives so it will actually go down if it is down), and I
assume your T1 is point to point from the other 1841 to the 7200.
Now assuming this is going to be a redundant configuration as well
as load-balanced you need to have a subnet that can float between the
2 links that your customer can NAT against (which by the way will
happen on the ASA they got sold), there are 2 ways you can achieve
this, 1 is by using ip sla to monitor the next hop of each of the
customer links from your 7200 with statics, the other is private BGP,
you sure as hell don't want to start running an IGP to your
customers(unless it's MPLS VPN).
Lets say you assign your customer 1.0.0.0/27 as their usable
floating subnet and the T1 is 2.0.0.1/30 at your end and your GRE
tunnel(wireless) is 2.0.0.5/30 at your end.
Setup ip sla with icmp echo to 2.0.0.2 and 2.0.0.6 (each in their
own rtr group of course, say 1 and 2 respectively).
Ip route 1.0.0.0 255.255.255.224 2.0.0.2 track 1 Ip route 1.0.0.0
255.255.255.224 2.0.0.6 track 2
Hope that makes sense, essentially traffic will only route to your
customer if your 7200 can ping their respective 1841, the other
private BGP option I am going to assume you are already familiar with
being in an ISP.
Now for the customer to you.
AFAIK the ASA cannot load balance it can only forward out 1
interface at a time.
So what you need to do is put the ASA and the 2 1841 interfaces into
a switch so they can all see each other at layer2, now setup hsrp on
your 1841 interfaces for redundant gateways lets say you use
1.0.0.1(t1),1.0.0.2(wireless),1.0.0.3(hsrp), now the next part is a
little trickier, I am going to assume your T1 is your primary link for
this example but you can switch it around if you want.
On your T1 1841 add a static route for the wireless /30 to go via
the LAN interface of the Wireless 1841(ip route 2.0.0.4
255.255.255.252 1.0.0.2, you should now be able to ping the ISP end of
the wireless link from your T1 1841, you want to setup ip sla to
monitor the ISP end of the wireless link from your T1 router(ie the T1
router is monitoring 2.0.0.5) and you also want to monitor its end of
the T1 link aswell 2.0.0.1
What this does is let your primary gateway know that it has a
complete and valid path for both gateways for redundancy.
Now you add 2 static routes with tracking on your primary 1841
Ip route 0.0.0.0 0.0.0.0 2.0.0.1 track 1 Ip route 0.0.0.0 0.0.0.0
1.0.0.2 track 2
Your wireless 1841 need only have the 1 gateway via its wireless
tunnel as it should only ever fall over to that router if there is a
serious problem on the primary side so you don't want it routing back
that way anyway, however make sure you enable pre-empt so it fails
back to the primary once it is back up.
You can optimise this a little further with the global command ip
cef load-sharing algorithm include-ports destination source or if
your game you can even do per-packet load sharing however i wouldn't
recommend it as your 2 paths are going to have different
characteristics, id probably just try the method i listed first.
As mentioned previously the ASA config will just be straightforward,
NAT/PAT against some pool in 1.0.0.0/27 with a default route to
1.0.0.3(hsrp), nothing more to it, the 1841's will do all the
redundancy and load balancing.
Hope at least some of that made sense, if you need clarification on
anything let me know.
Cheers
Ben
On Tue 19/08/08 9:06 AM , Scott Lambert [EMAIL PROTECTED] sent:
I have a customer who went directly to cisco to ask about how to
load
balance two WAN connections to their Cisco PIX 515E. Cisco sold them
an
ASA 5510 and two 1841s and suggested VRRP or GLBP for the LAN with
the
ASA and 1841s. Apparantly, the customer didn't even mention that the
two connections were to the same ISP, me. The customer just ordered
the
equipment and said Make it work.
The WANs are T1 (existing) and 4Mbps ethernet delivered via a
wireless
network.
Cisco sales tech guy said:
What we discussed was the ASA having a default route to the
virtual
IP address of the routers and they would be running either VRRP or
GLBP (whatever they decided they wanted to do) going out to the
service provider. Then the routers would simply have a default
route
going out to the service provider to hit the 'Net.
The network design is supposed to be something like :
Cisco 7204VXR NPE G1 (ISP)
| |
T1 Wireless network cloud
| |
Cisco 1841 Cisco 1841
Re: [c-nsp] Need some guidance for T1 / wireless ethernet handoff load balancing/failover setup
BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }
Hi Scott,
Try this:
Seeing as you are working statics over your wireless cloud to
simplify things a little setup a GRE tunnel from your 7200 over the
wireless to the 1841 (don’t forget to subtract 24 bytes off the MTU,
ie if it's a 1500 path put ip mtu 1476 in the tunnel interface and
also add keepalives so it will actually go down if it is down), and I
assume your T1 is point to point from the other 1841 to the 7200.
Now assuming this is going to be a redundant configuration as well
as load-balanced you need to have a subnet that can float between the
2 links that your customer can NAT against (which by the way will
happen on the ASA they got sold), there are 2 ways you can achieve
this, 1 is by using ip sla to monitor the next hop of each of the
customer links from your 7200 with statics, the other is private BGP,
you sure as hell don't want to start running an IGP to your
customers(unless it's MPLS VPN).
Lets say you assign your customer 1.0.0.0/27 as their usable
floating subnet and the T1 is 2.0.0.1/30 at your end and your GRE
tunnel(wireless) is 2.0.0.5/30 at your end.
Setup ip sla with icmp echo to 2.0.0.2 and 2.0.0.6 (each in their
own rtr group of course, say 1 and 2 respectively).
Ip route 1.0.0.0 255.255.255.224 2.0.0.2 track 1 Ip route 1.0.0.0
255.255.255.224 2.0.0.6 track 2
Hope that makes sense, essentially traffic will only route to your
customer if your 7200 can ping their respective 1841, the other
private BGP option I am going to assume you are already familiar with
being in an ISP.
Now for the customer to you.
AFAIK the ASA cannot load balance it can only forward out 1
interface at a time.
So what you need to do is put the ASA and the 2 1841 interfaces into
a switch so they can all see each other at layer2, now setup hsrp on
your 1841 interfaces for redundant gateways lets say you use
1.0.0.1(t1),1.0.0.2(wireless),1.0.0.3(hsrp), now the next part is a
little trickier, I am going to assume your T1 is your primary link for
this example but you can switch it around if you want.
On your T1 1841 add a static route for the wireless /30 to go via
the LAN interface of the Wireless 1841(ip route 2.0.0.4
255.255.255.252 1.0.0.2, you should now be able to ping the ISP end of
the wireless link from your T1 1841, you want to setup ip sla to
monitor the ISP end of the wireless link from your T1 router(ie the T1
router is monitoring 2.0.0.5) and you also want to monitor its end of
the T1 link aswell 2.0.0.1
What this does is let your primary gateway know that it has a
complete and valid path for both gateways for redundancy.
Now you add 2 static routes with tracking on your primary 1841
Ip route 0.0.0.0 0.0.0.0 2.0.0.1 track 1 Ip route 0.0.0.0 0.0.0.0
1.0.0.2 track 2
Your wireless 1841 need only have the 1 gateway via its wireless
tunnel as it should only ever fall over to that router if there is a
serious problem on the primary side so you don't want it routing back
that way anyway, however make sure you enable pre-empt so it fails
back to the primary once it is back up.
You can optimise this a little further with the global command ip
cef load-sharing algorithm include-ports destination source or if
your game you can even do per-packet load sharing however i wouldn't
recommend it as your 2 paths are going to have different
characteristics, id probably just try the method i listed first.
As mentioned previously the ASA config will just be straightforward,
NAT/PAT against some pool in 1.0.0.0/27 with a default route to
1.0.0.3(hsrp), nothing more to it, the 1841's will do all the
redundancy and load balancing.
Hope at least some of that made sense, if you need clarification on
anything let me know.
Cheers
Ben
On Tue 19/08/08 9:06 AM , Scott Lambert [EMAIL PROTECTED] sent:
I have a customer who went directly to cisco to ask about how to
load
balance two WAN connections to their Cisco PIX 515E. Cisco sold them
an
ASA 5510 and two 1841s and suggested VRRP or GLBP for the LAN with
the
ASA and 1841s. Apparantly, the customer didn't even mention that the
two connections were to the same ISP, me. The customer just ordered
the
equipment and said Make it work.
The WANs are T1 (existing) and 4Mbps ethernet delivered via a
wireless
network.
Cisco sales tech guy said:
What we discussed was the ASA having a default route to the
virtual
IP address of the routers and they would be running either VRRP or
GLBP (whatever they decided they wanted to do) going out to the
service provider. Then the routers would simply have a default
route
going out to the service provider to hit the 'Net.
The network design is supposed to be something like :
Cisco 7204VXR NPE G1 (ISP)
| |
T1 Wireless network cloud
| |
Cisco 1841 Cisco 1841
Re: [c-nsp] Need some guidance for T1 / wireless ethernet handoff load balancing/failover setup
Scott Lambert wrote: I have a customer who went directly to cisco to ask about how to load balance two WAN connections to their Cisco PIX 515E. Cisco sold them an ASA 5510 and two 1841s and suggested VRRP or GLBP for the LAN with the ASA and 1841s. Apparantly, the customer didn't even mention that the two connections were to the same ISP, me. The customer just ordered the equipment and said Make it work. Whoever sold them on that solution should be the one to make it work. ;) The WANs are T1 (existing) and 4Mbps ethernet delivered via a wireless network. Cisco sales tech guy said: What we discussed was the ASA having a default route to the virtual IP address of the routers and they would be running either VRRP or GLBP (whatever they decided they wanted to do) going out to the service provider. Then the routers would simply have a default route going out to the service provider to hit the 'Net. The network design is supposed to be something like : Cisco 7204VXR NPE G1 (ISP) || T1Wireless network cloud || Cisco 1841 Cisco 1841 || -+---++- | Cisco ASA 5510 (Customer) I dunno what Cisco would do, but I'd start with a GRE tunnel over the wireless side. I do this from home back to the office (crypto on the tunnel too, of course) so I can get all my office routes via OSPF and effectively be directly connected. Make sure to put some static routes in there so the tunnel endpoint doesn't because learned over OSPF, which would cause the tunnel to drop. I wouldn't bother with the load balance on drastically unequal links - the first time they have a huge transfer and expect to see 6.5 megs, the flow will end up over the T1 and they'll be screaming about the 1.5 meg reality. ~Seth ___ 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] CAB-HD8-ASYNC extension cables?
The connector on the cards are (Micro)D68F (also used by SCSI-3 devices). You would be looking for a D68M-D68F cable to extend the connection. [...oops. sorry Brian, you were right...] Thanks, I didn't have one on hand to check. Do you happen to know if the pinout is consistent w/ the HD68's used in the CAB-OCTAL? (Could be very useful for sparing...) ...though I'd admit the D68 extension is a tidier solution in the rack :). That's the idea. Even with clean cable management, its still better to get that fanout as far from central panels as needed. I was also able to come up with vendors that make custom length CAB-HD8-ASYNC compatible cables If going that approach, it'd be even cooler to get something in a cassette format to go right next to the MPO breakouts... ___ 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/
