[c-nsp] CPU anomoly on 3560G when adding a BGP peer

Thu Sep 13 03:11:11 EDT 2007

Ivan, Worked like a sharm.

I did not know the shared memory switches had these format options on
the CEF memory.
I was told it was dynamic, but I guess thats a partial truth.

Thanks alot!

Best regards

Mattias Gyllenvarg
Omnitron
Sweden

From: Ivan Gasparik <ivan at ig.sk>
To: cisco-nsp at puck.nether.net
Date: Wed, 12 Sep 2007 08:05:58 +0200
Subject: Re: [c-nsp] CPU anomoly on 3560G when adding a BGP peer
try to look at the output of 'show sdm prefer', especially at the
line 'number of indirect IPv4 routes'. it looks like your BGP
prefixes can't fit into the routing part of TCAM and some packets are
beeing software switched.

ivan

On Wednesday 12 September 2007, christian wrote:
> whats the output of sho proc cpu sorted 5min  look like?
>
>
>
> On 9/11/07, Wyatt Mattias Ishmael Jovial Gyllenvarg <
>
> wyatt.eliasson at gmail.com> wrote:
> > Hi all
> >
> > We have a strange behavior on a 3560G that is running IBGP + some
> > EBGP.
> >
> > It is a route-reflector client to our one core machine and it
> > takes in a few EBGP peers.
> > Now we want a certain set of prefixes to go another way then the
> > core node calculates as "best".
> >
> > We there for setup a peer with another core node (not RR-client)
> > and filtered out the prefixes and set them weight 1 in the
> > incoming route-map.
> >
> > This all works well except we get 85% CPU usage and we cannot see
> > what process is using it.
> > All bgp ques are stable and the total prefix count is ~2000.
> >
> > I assumed it was a routing loop but could not trace it.
> >
> > Any guesses?
> >
> > Best regards
> > Mattias Gyllenvarg
> > Omnitron
> > Sweden

2007/9/12, cisco-nsp-request at puck.nether.net
<cisco-nsp-request at puck.nether.net>:
> Send cisco-nsp mailing list submissions to
>         cisco-nsp at 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
>         cisco-nsp-request at puck.nether.net
>
> You can reach the person managing the list at
>         cisco-nsp-owner at puck.nether.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cisco-nsp digest..."
>
> Today's Topics:
>
>    1. ASA/CSC - workaround for limited filtering options (Garry)
>    2. Re: CPU anomoly on 3560G when adding a BGP peer (Ivan Gasparik)
>    3. GOLD on 6500s (Phil Mayers)
>    4. Re: Routing recommendations (Mark Tinka)
>    5. Re: Nokia Firewall Clustering on 6500 Cisco Switches (Nick Kassel)
>    6. Re: RSP720 Supported linecards (Mark Tinka)
>    7. Re: Recommendations for bridging/tunneling hardware (Yuri Lukin)
>    8. Troubling IPSec issues with a 6500 (Aaron Daubman)
>
>
> ---------- Vidarebefordrat meddelande ----------
> From: Garry <gkg at gmx.de>
> To: cisco-nsp at puck.nether.net
> Date: Wed, 12 Sep 2007 08:17:43 +0200
> Subject: [c-nsp] ASA/CSC - workaround for limited filtering options
> After doing basic configuration of a 5510 w/CSC20 for a customer
> network, our customer has come up with some wishes about specific
> filtering options that I don't see any way of implementing with the
> CSC's rather limited filtering options. Even with the most current 6.2
> (1599) version of the CSC OS, which finally allows the content filtering
> to be bypassed for certain IPs/Subnets, I do not see any way of
> implementing this without an additional box with - say - a squid proxy
> on it:
>
> - certain sites (all within a specific IP range) aren't supposed to get
> any web access, except for specific web sites required for business purposes
> - certain other sites (again, within a specific IP range) receive web
> access, though content scanning will prevent e.g. porn sites from being
> accessed
> - for all accesses, virus/malware filtering is to be performed, of course
>
> Having a decent permission system on the ASA/CSC itself to do more
> sophisticated ACLs for web access ... while I understand that it's not
> the main job of a _content_ engine to perform ACL supervision for client
> access, I do see it as an integral part of such a gateway ...
>
> Any thoughts or suggestions?
>
>
>
> ---------- Vidarebefordrat meddelande ----------
> From: Ivan Gasparik <ivan at ig.sk>
> To: cisco-nsp at puck.nether.net
> Date: Wed, 12 Sep 2007 08:05:58 +0200
> Subject: Re: [c-nsp] CPU anomoly on 3560G when adding a BGP peer
> try to look at the output of 'show sdm prefer', especially at the
> line 'number of indirect IPv4 routes'. it looks like your BGP
> prefixes can't fit into the routing part of TCAM and some packets are
> beeing software switched.
>
> ivan
>
>
> On Wednesday 12 September 2007, christian wrote:
> > whats the output of sho proc cpu sorted 5min  look like?
> >
> >
> >
> > On 9/11/07, Wyatt Mattias Ishmael Jovial Gyllenvarg <
> >
> > wyatt.eliasson at gmail.com> wrote:
> > > Hi all
> > >
> > > We have a strange behavior on a 3560G that is running IBGP + some
> > > EBGP.
> > >
> > > It is a route-reflector client to our one core machine and it
> > > takes in a few EBGP peers.
> > > Now we want a certain set of prefixes to go another way then the
> > > core node calculates as "best".
> > >
> > > We there for setup a peer with another core node (not RR-client)
> > > and filtered out the prefixes and set them weight 1 in the
> > > incoming route-map.
> > >
> > > This all works well except we get 85% CPU usage and we cannot see
> > > what process is using it.
> > > All bgp ques are stable and the total prefix count is ~2000.
> > >
> > > I assumed it was a routing loop but could not trace it.
> > >
> > > Any guesses?
> > >
> > > Best regards
> > > Mattias Gyllenvarg
> > > Omnitron
> > > Sweden
> > > _______________________________________________
> > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
> ---------- Vidarebefordrat meddelande ----------
> From: Phil Mayers <p.mayers at imperial.ac.uk>
> To: cisco-nsp at puck.nether.net
> Date: Wed, 12 Sep 2007 10:23:19 +0100
> Subject: [c-nsp] GOLD on 6500s
> All,
>
> We had an outage yesterday and initial analysis looks like a SUP going
> bad. I've currently got the card in the spare chassis running
> diagnostics and this has reminded me I've got some questions about GOLD
> that I've never had answered (Cisco: the IOS docs for GOLD in 12.2SX are
> awful)
>
>  1. I've seen modules fail individual tests, then pass them later on
> (either after a reload, or after being re-seated). It's my perception
> that a FAIL doesn't necessarily imply the card is bad, but a PASS
> definitely implies the card is good (at that time). Is this in fact the
> case?
>
>  2. The GOLD docs are a little unclear on exactly what some of the steps
> are. Does anyone have the IOS commands (including any relevant initial
> "conf t" / "wr mem", and inter-diagnostic "reload") to FULLY diagnose
> both a sup720 and 67xx series linecards?
>
>  3. Many of the tests state "do not perform packet switching during this
> time". What does this imply? Is it sufficient to merely unplug the ports
> on that individual linecard? Or shut down all the SVIs? Or do you
> basically have to completely unconfigure the linecard so no packets will
> pass from the fabric to the card?
>
>  4. Can GOLD diagnostic results be extracted over SNMP? In particular,
> if the non-destructive tests are scheduled nightly/weekly, how do people
> go about checking the results (and keeping history)?
>
>  5. Talking about the non-disruptive tests, why isn't there a:
> "diagnostic start module N test non-disruptive"; the docs say you have
> to do a "show diagnostic content", manually count off the non-disruptive
> tests (which I guess differ per-linecard/linecard model?) and build this
> list manually. Tedious.
>
> All input appreciated
>
> Cheers,
> Phil
>
>
>
>
> ---------- Vidarebefordrat meddelande ----------
> From: Mark Tinka <mtinka at globaltransit.net>
> To: cisco-nsp at puck.nether.net
> Date: Wed, 12 Sep 2007 17:33:59 +0800
> Subject: Re: [c-nsp] Routing recommendations
> On Tuesday 11 September 2007 22:04, Justin Shore wrote:
>
> > I'd recommend a 7201 or a short-stack 7600.
>
> Skipping off a bit... considering that the 7600 uses the
> same Supervisor (say, in this case, SUP720-3BXL) across all
> supported chassis', I'd be careful in making sure I get a
> chassis that will give me the mileage from such a spend
> (especially if a redundant RP/SP design is in play).
>
> But then again, perhaps chassis' are not as dramatically
> expensive to upgrade as the line cards, PSU's and
> Supervisor engines they need to house.
>
> Mark.
>
>
> ---------- Vidarebefordrat meddelande ----------
> From: "Nick Kassel" <Nick.Kassel at Charles-Stanley.co.uk>
> To: "Joel M Snyder" <Joel.Snyder at Opus1.COM>
> Date: Wed, 12 Sep 2007 10:36:27 +0100
> Subject: Re: [c-nsp] Nokia Firewall Clustering on 6500 Cisco Switches
> Many thanks for your reply Joel, we will have to see if this is
> possible.
>
> -----Original Message-----
> From: Joel M Snyder [mailto:Joel.Snyder at Opus1.COM]
> Sent: 11 September 2007 02:29
> To: Nick Kassel
> Cc: cisco-nsp at puck.nether.net; Abdus Hamid; Darren Holden
> Subject: Re: [c-nsp] Nokia Firewall Clustering on 6500 Cisco Switches
>
> Well, here's the best advice I can offer...
>
> Nokia clusters have three modes of operation: multicast, unicast, and
> forwarding.
>
> Forwarding is considered to be the most compatible mode, and no switch
> should be having trouble with that.  With forwarding mode, the cluster
> elects a master to receive the traffic using a normal unicast MAC
> address, and the master passes traffic to other cluster members using a
> private link (hopefully) to handle the load balancing.  You get a nice
> scalability there, so long as the path between the cluster nodes is not
> congested.  Given a 1Gb link up, there's only so far you can scale.
>
> The other two modes, unicast & multicast, all depend on a MAC address
> that is either on multiple ports (unicast) or is multicast (multicast)
> and those generally will require some manual locking down of the
> forwarding database.  You get better performance with unicast if you
> need it, but because of the relative speed of things, you will probably
> never need to jump from forwarding mode.
>
> However... you are running really, really old hardware (IP530) and
> really old software (R61), which leads me to wonder if you're not
> finding some old IPSO clustering bug.  I don't know if you've loaded
> IPSO 4.2 or are running something much older, but you should be up to
> rev on that.
>
> Note that the IPSO clustering is completely separate from NGX load
> balancing in terms of configuration and setup, so you should be able to
> have a stable IPSO cluster (using Voyager) before you even bring NGX
> into the picture.
>
> If the cluster is, indeed, stable (try some basic tests to see), then
> you may not have NGX properly linked in.  I just did some tests using
> NGX R65 and it was very solid (although I saw some load balancing
> problems related to NAT).
>
> I would suggest you get 4.2 IPSO and NGX R65 and this should work like a
>
> champ on any Cisco switch in forwarding mode.  Three weeks ago, I just
> tore down a Nokia Cryptocluster that has been on a 2924 for about 7
> years and it was rock solid with completely stock configuration.
>
> jms
>
>
>
> Nick Kassel wrote:
> > We have a new Cisco network in test which is using layer 3 routed
> access
> > design all switches are 6509, we are currently trying to test Nokia
> > Firewall clustering using IP forwarding. Does anyone have any
> experience
> > of this as we are currently having issues with the cluster. Our
> firewall
> > team seem to think that this may be an issue on the switches, as this
> > previously worked fine on our old Nortel environment. On each firewall
> > when running the cphaprob state command only the local firewall is
> shown
> > and not both cluster nodes however on the voyager GUI the cluster is
> > showing both nodes correctly.
> >
> > We have disabled IGMP snooping as recommended from another forum and
> > this helped to display both nodes in voyager but not on the individual
> > firewalls.
> >
> > Firewall setup consists of 2 x Nokia IP 530 running Checkpoint NGX R61
> > with 4 physical network ports with vlans.
> >
>
> --
> Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
> Senior Partner, Opus One       Phone: +1 520 324 0494
> jms at Opus1.COM                http://www.opus1.com/jms
> ********************SAVE PAPER - THINK BEFORE YOU PRINT**************************************************
>
> The information contained in this e-mail is strictly confidential, some or all of which may be legally privileged.
> Access to this e-mail by any person other than the recipient is prohibited. If you have received this message in
> error, any use, disclosure, copying, printing, distribution of, replying to or any action taken or omitted to be
> taken in reliance on this e-mail, is prohibited. Please advise the sender immediately should this e-mail have been
> incorrectly addressed or transmitted, and then delete the email and any attachment sent with it from your computer.
>
> You are advised that urgent, time sensitive and confidential communications should not be sent by e-mail. You
> accept that any instructions are deemed to have been given at the time the recipient(s) accesses them and that
> delivery receipt does not constitute acknowledgement or receipt by the intended recipient(s).
>
> You acknowledge that e-mails are not secure and you accept the risk of malfunction, viruses, unauthorised
> interference, mis-delivery or delay. Charles Stanley reserves the right to monitor and/or record emails sent and
> received via its network for any lawful business purpose in accordance with applicable law and regulations.
> *******************************************************************************************************
>
>
> Charles Stanley & Co. Ltd
> Registered Office: 25 Luke Street London EC2A 4AR
>
> Tel: 0207 739 8200 Fax: 0207 739 7798
> Registered in England No. 1903304
>
> Charles Stanley Sutherlands and Charles Stanley Securities are divisions of Charles Stanley & Co. Ltd
>
> Authorised and Regulated by the Financial Services Authority, Member of the London Stock Exchange, The
> International Capital Market Association and The London International Financial Futures & Options Exchange.
>
> This footnote also confirms that this email message has been swept by McAfee VirusScan and SurfControl Email
> Filter software.
>
>
>
>
> ---------- Vidarebefordrat meddelande ----------
> From: Mark Tinka <mtinka at globaltransit.net>
> To: cisco-nsp at puck.nether.net
> Date: Wed, 12 Sep 2007 17:54:12 +0800
> Subject: Re: [c-nsp] RSP720 Supported linecards
> On Tuesday 11 September 2007 21:28, Justin Shore wrote:
>
> > In particular I want
> > to confirm support for the...
>
> Uncertain about the rest, but...
>
> > ACE,...
>
> We looked into this a couple of weeks back. It turns out the
> ACE (well, at least the ACE20-MOD-K9) will only be
> supported on the RSP720 when IOS Cobra (SRC) is released;
> code expected out at the end of the year.
>
> If you need the ACE to deploy now, the SUP720 is your
> friend, else, you could hang in there.
>
> There is indication that all current Layer 2/3 line cards
> supported by the SUP720 are also supported by the RSP720.
> However, the Advanced Integrated Service Modules will only
> be supported on the RSP720 when SRC ships (might need to
> check this with your local SE, the information is a couple
> of weeks old and we were only really tracking the ACE
> modules).
>
> Mark.
>
>
> ---------- Vidarebefordrat meddelande ----------
> From: "Yuri Lukin" <lists at swaggi.com>
> To: "Hal Epstien" <hal.epstien at gmail.com>, cisco-nsp at puck.nether.net
> Date: Wed, 12 Sep 2007 08:20:09 -0400
> Subject: Re: [c-nsp] Recommendations for bridging/tunneling hardware
> On Tue, 11 Sep 2007 23:14:45 -0700, Hal Epstien wrote
> > Hi folks! We're trying to determine a low cost solution to bridge
> > 802.11Q vlans over the internet between two locations. We are
> > thinking of using IOS with bridge groups and a IPIP or GRE tunnel
> > between the two locations. Encryption is not required.
> >
> > Peak traffic is about 50Mbps and will be on fast ethernet. Not sure
> > how many packets per second...
> >
> > Right now we are using some HP DL145 servers running linux and vtun
> > to do this. It seems to work well, but I'd like to replace the
> > servers with more reliable devices.
> >
> > We are considering the 3600 series products to do this, but I'm not
> > sure how they will hold up under the kind of traffic levels we are
> > looking at.
> >
> > Any suggestions?
> >
>
>
> I recently went through the same scenario. Our requirements were roughly the
> same and we decided on L2TPv3 with a 3745 and a 3845 as endpoints for the
> tunnel. I don't think the 3600 series supports L2TPv3. We will be implementing
> this in about two weeks so I will let you know how well it works (worked well
> in the lab).
>
> I'm curious to see your linux/vtun solution, perhaps you can share it off-list?
>
>  Yuri
>
>
>
>
> ---------- Vidarebefordrat meddelande ----------
> From: "Aaron Daubman" <daubman at gmail.com>
> To: cisco-nsp <cisco-nsp at puck.nether.net>
> Date: Wed, 12 Sep 2007 09:10:52 -0400
> Subject: [c-nsp] Troubling IPSec issues with a 6500
> Greetings,
>
> I have a client that's run into some trouble with IPSec-over-GRE and
> I'm trying to help debug.  The problem sounds very familiar, however I
> haven't come up with a solution yet in my searches...
>
> The basic setup is:
>
> 7206(GigE)<------>(GigE)6500
>
> The IPSec (preshared) setup is pretty much straight out of a Cisco
> IPSec-over-GRE example with one (possibly key) difference:
> On the 6500, pretty much all traffic in/out is using single GigE
> interface with multiple trunked Vlans.
>
> The tunnel comes up and all show/debug output looks good.  The 7200
> works bi-directionally, however, the 6500 seems to be only encrypting
> in a single direction for external traffic.
>
> Traffic originating ON the 6500 (ping) gets encrypted and sent over
> the tunnel, and all received IPSec traffic is decrypted, however,
> traffic that comes in on one of the other vlans, is supposed to get
> Tunneled and then encrypted and then sent out a different Vlan, only
> gets GRE encapsulated and is skipping the IPSec crypto.
>
> What I REALLY can't figure out is that the crypto map match access
> list counters ARE incrementing for this traffic that is not being
> encrypted...
>
> The 6500 (Sup720-3a MSFC3) only has 64Mb flash, so it is running the
> latest possible image that it can:  12.2.18-SXD7b
> ...there is no FWSM in the picture.
>
> Any ideas?
>
> Interestingly enough, the same (exact, VLANs and all) setup is working
> between the 7200 and a 2600, with the only major difference I can see
> being the hardware platform and the IOS release.
>
> TIA,
>      ~Aaron
>
>
> _______________________________________________
> cisco-nsp mailing list
> cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
>
>