March 2004 - Test - lists.nanog.org

TCP headre compression and CPU usage on Cisco AS5800
by Paul Khavkine 17 Mar '04

17 Mar '04

Hi folks. On a cisco AS5800, what are the parameters that could be tweaked to reduce CPU utilization ? With 360 active calls here's what i have: NAS01-MTNDODS#sh proc cpu | exclude 0.00 CPU utilization for five seconds: 79%/17%; one minute: 81%; five minutes: 80% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 3 80428996 4609093 17450 2.19% 1.08% 0.78% 0 Check heaps 7 147676920 1554810 94984 2.43% 4.42% 3.93% 0 Serial Backgroun 29 8102432 16740884 483 0.08% 0.18% 0.18% 0 Net Background 61 11903404 9770801 1218 0.24% 0.22% 0.23% 0 ISDN 74 8349756642098634624 397 7.72% 6.99% 6.93% 0 IP Input 76 3189204 1447125 2203 0.08% 0.04% 0.04% 0 CDP Protocol 79 665792 8520105 78 0.16% 0.13% 0.10% 0 IP Background 91 795916 2427196 327 0.08% 0.19% 0.23% 0 PPP IP Route 92 31107300 5726565 5432 38.09% 45.42% 45.05% 0 PPP IPCP 120 80886604 2196656 36822 0.73% 0.74% 0.74% 0 Compute load avg 148 32705256 345451242 94 4.30% 2.52% 2.07% 0 PPP Events 156 3841144 63989161 60 0.08% 0.06% 0.03% 0 IP SNMP 158 8978492 27800036 322 0.16% 0.26% 0.16% 0 SNMP ENGINE 210 222569208 2670597 83340 5.60% 5.39% 4.83% 0 AAA Per-User As you see that IPCP process takes ~ 45% of the CPU. Is there a way to disable TCP header compression completely ? Or any other CPU intensive things ? It's an AS5800 with NPE-300 Thanx Paul ************************************************ Paul Khavkine Network Administrator DISTRIBUTEL Communications. 740 Notre Dame West, Suite 1135 Montreal, Quebec, Canada, H3C 3X6 1-514-877-5505 x 263 http://www.distributel.net ************************************************

1 0

Strange message possibly through nanog mail server
by william(at)elan.net 17 Mar '04

17 Mar '04

I Just received this. I would like to check if others have received it and did it indeed come through nanog mailist: > Date: Wed, 17 Mar 2004 21:10:38 +0000 > From: Deep Throat <deepthroat20004(a)hotmail.com> > To: schroebel6(a)aol.com > Subject: Spamhaus Exposed > > Disturbing information on one of the founders of Spamhaus.org > > http://www.geocities.com/jackjack9872004/ _______________________________________________________________________ And while the website was unavailable and the sender is being anonymous (whichis against nanog list policies if this was sent through it), what I do find worse is that they managed to do it so that nanog(a)merit.edu is not added to "CC" (which if I understood is always supposed to happen when something through this mail list, which makes me think it might have come through merit mail machine but not actually though mail list). What I find even more disturbing is that ip address listed as origin (which may well have been forged if they managed to gain some highier level access to merit servers) is that of US Military. Below is the header for your review. I do however find it slightly more likely that its some kind of sophisticated joe-job on spamhaus and that info is forged but they may have used some bug on merit mail software. Return-Path: <owner-nanog(a)merit.edu> Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by sokol.elan.net (8.12.5/8.12.5) with ESMTP id i2HMKZdw015368 for <william(a)elan.net>; Wed, 17 Mar 2004 14:20:35 -0800 Received: by trapdoor.merit.edu (Postfix) id CF8FA91307; Wed, 17 Mar 2004 16:11:00 -0500 (EST) Delivered-To: nanog-outgoing(a)trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92B3591328; Wed, 17 Mar 2004 16:11:00 -0500 (EST) Delivered-To: nanog(a)trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BCC5691307 for <nanog(a)trapdoor.merit.edu>; Wed, 17 Mar 2004 16:10:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id A27775DE7B; Wed, 17 Mar 2004 16:10:39 -0500 (EST) Delivered-To: nanog(a)merit.edu Received: from hotmail.com (bay13-f78.bay13.hotmail.com [64.4.31.78]) by segue.merit.edu (Postfix) with ESMTP id 5C2B05DE72 for <nanog(a)merit.edu>; Wed, 17 Mar 2004 16:10:39 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Mar 2004 13:10:38 -0800 Received: from 198.26.130.36 by by13fd.bay13.hotmail.msn.com with HTTP; Wed, 17 Mar 2004 21:10:38 GMT X-Originating-IP: [198.26.130.36] <---- Note this, see below X-Originating-Email: [deepthroat20004(a)hotmail.com] X-Sender: deepthroat20004(a)hotmail.com From: "Deep Throat" <deepthroat20004(a)hotmail.com> To: schroebel6(a)aol.com Subject: Spamhaus Exposed Date: Wed, 17 Mar 2004 21:10:38 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: <BAY13-F78KxAh5hMpAn0002ba61(a)hotmail.com> X-OriginalArrivalTime: 17 Mar 2004 21:10:38.0810 (UTC) FILETIME=[4C3633A0:01C40C64] Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing(a)merit.edu X-Loop: nanog Disturbing information on one of the founders of Spamhaus.org http://www.geocities.com/jackjack9872004/ ---------------------------------------------------------------------- $ host 198.26.130.36 36.130.26.[98.in-addr.arpa domain name pointer BU-WCS1-SAND.NIPR.MIL. [whois.completewhois.com] Elan Completewhois.Com Whois Server, Version 0.91a6, compiled on Jan 02, 2004 Please see http://www.completewhois.com/help.htm for command-line options Use of this server and any information obtained here is allowed only if you follow our policies at http://www.completewhois.com/policies.htm [IPv4 whois information on 198.26.130.36 ] [Query Origin: Main Whois Query ] [whois.arin.net] OrgName: The Defense Information Systems Agency OrgID: DISA Address: DISA/DSSO/JCLCC Address: Room BF655A, The Pentagon City: Washington StateProv: DC PostalCode: 20301 Country: US NetRange: 198.25.0.0 - 198.26.255.255 CIDR: 198.25.0.0/16, 198.26.0.0/16 NetName: NETBLK-DISA-C NetHandle: NET-198-25-0-0-1 Parent: NET-198-0-0-0-0 NetType: Direct Allocation NameServer: AAA-KELLY.NIPR.MIL NameServer: AAA-VAIHINGEN.NIPR.MIL NameServer: AAA-WHEELER.NIPR.MIL NameServer: AAA-VIENNA.NIPR.MIL Comment: RegDate: 1992-12-05 Updated: 2004-01-13

3 2

RE: Strange message possibly through nanog mail server
by Mike Tancsa 17 Mar '04

17 Mar '04

At 04:58 PM 17/03/2004, Alon Tirosh wrote: >I *think* I loaded the page in lynx before it got rate-limited, and lynx >flashed through a whole mess of fast redirects before faulting out. No >logs, unfortunately. A safe way I find to examine potentially trojaned pages is via fetch (or wget) fetch -o questionable.html <url> Then you can examine the page with appropriate tools. ---Mike

1 0

RE: Strange message possibly through nanog mail server
by Thor Larholm 17 Mar '04

17 Mar '04

> From: william(at)elan.net [mailto:william@elan.net] > I Just received this. I would like to check if others > have received it and did it indeed come through nanog mailist It came through NANOG, delivered from a Hotmail account that accepted it from 198.26.130.36. Yes, that is a military IP, and most definitely not the first time that spammers have relayed emails through compromised military machines. Spammers broke federal law long before the YOU-CAN-SPAM act. For some reason, Peter Schroebel was CC'ed. You can read more about him at http://www.spamhaus.org/rokso/listing.lasso?-op=cn&spammer=Peter%20Schro ebel%20-%20SMS/Fullport Character attacks such as this one are pretty common against anti-spammers, we also had one attempted at Brian Bruns just days ago here on NANOG. Regards Thor Larholm Senior Security Researcher PivX Solutions 24 Corporate Plaza #180 Newport Beach, CA 92660 http://www.pivx.com thor(a)pivx.com Phone: +1 (949) 231-8496 PGP: 0x5A276569 6BB1 B77F CB62 0D3D 5A82 C65D E1A4 157C 5A27 6569 PivX defines "Proactive Threat Mitigation". Get a FREE Beta Version of Qwik-Fix <http://www.qwik-fix.net>

1 0

RE: Strange message possibly through nanog mail server
by Alon Tirosh 17 Mar '04

17 Mar '04

Got it, came from nanog, originated from DISA (purportedly, anyways): Received: from 198.26.130.36 by by13fd.bay13.hotmail.msn.com with HTTP; Wed, 17 Mar 2004 21:10:38 GMT #whois 198.26.130.36 OrgName: The Defense Information Systems Agency OrgID: DISA Address: DISA/DSSO/JCLCC Address: Room BF655A, The Pentagon City: Washington StateProv: DC PostalCode: 20301 Country: US NetRange: 198.25.0.0 - 198.26.255.255 CIDR: 198.25.0.0/16, 198.26.0.0/16 NetName: NETBLK-DISA-C NetHandle: NET-198-25-0-0-1 Parent: NET-198-0-0-0-0 NetType: Direct Allocation NameServer: AAA-KELLY.NIPR.MIL NameServer: AAA-VAIHINGEN.NIPR.MIL NameServer: AAA-WHEELER.NIPR.MIL NameServer: AAA-VIENNA.NIPR.MIL I *think* I loaded the page in lynx before it got rate-limited, and lynx flashed through a whole mess of fast redirects before faulting out. No logs, unfortunately. Just a question: is this the chinese year of the immature script kiddie or something? -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of william(at)elan.net Sent: Wednesday, March 17, 2004 5:58 PM To: nanog(a)merit.edu Subject: Strange message possibly through nanog mail server I Just received this. I would like to check if others have received it and did it indeed come through nanog mailist: > Date: Wed, 17 Mar 2004 21:10:38 +0000 > From: Deep Throat <deepthroat20004(a)hotmail.com> > To: schroebel6(a)aol.com > Subject: Spamhaus Exposed > > Disturbing information on one of the founders of Spamhaus.org > > http://www.geocities.com/jackjack9872004/ _______________________________________________________________________ And while the website was unavailable and the sender is being anonymous (whichis against nanog list policies if this was sent through it), what I do find worse is that they managed to do it so that nanog(a)merit.edu is not added to "CC" (which if I understood is always supposed to happen when something through this mail list, which makes me think it might have come through merit mail machine but not actually though mail list). What I find even more disturbing is that ip address listed as origin (which may well have been forged if they managed to gain some highier level access to merit servers) is that of US Military. Below is the header for your review. I do however find it slightly more likely that its some kind of sophisticated joe-job on spamhaus and that info is forged but they may have used some bug on merit mail software. Return-Path: <owner-nanog(a)merit.edu> Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by sokol.elan.net (8.12.5/8.12.5) with ESMTP id i2HMKZdw015368 for <william(a)elan.net>; Wed, 17 Mar 2004 14:20:35 -0800 Received: by trapdoor.merit.edu (Postfix) id CF8FA91307; Wed, 17 Mar 2004 16:11:00 -0500 (EST) Delivered-To: nanog-outgoing(a)trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92B3591328; Wed, 17 Mar 2004 16:11:00 -0500 (EST) Delivered-To: nanog(a)trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BCC5691307 for <nanog(a)trapdoor.merit.edu>; Wed, 17 Mar 2004 16:10:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id A27775DE7B; Wed, 17 Mar 2004 16:10:39 -0500 (EST) Delivered-To: nanog(a)merit.edu Received: from hotmail.com (bay13-f78.bay13.hotmail.com [64.4.31.78]) by segue.merit.edu (Postfix) with ESMTP id 5C2B05DE72 for <nanog(a)merit.edu>; Wed, 17 Mar 2004 16:10:39 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Mar 2004 13:10:38 -0800 Received: from 198.26.130.36 by by13fd.bay13.hotmail.msn.com with HTTP; Wed, 17 Mar 2004 21:10:38 GMT X-Originating-IP: [198.26.130.36] <---- Note this, see below X-Originating-Email: [deepthroat20004(a)hotmail.com] X-Sender: deepthroat20004(a)hotmail.com From: "Deep Throat" <deepthroat20004(a)hotmail.com> To: schroebel6(a)aol.com Subject: Spamhaus Exposed Date: Wed, 17 Mar 2004 21:10:38 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: <BAY13-F78KxAh5hMpAn0002ba61(a)hotmail.com> X-OriginalArrivalTime: 17 Mar 2004 21:10:38.0810 (UTC) FILETIME=[4C3633A0:01C40C64] Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing(a)merit.edu X-Loop: nanog Disturbing information on one of the founders of Spamhaus.org http://www.geocities.com/jackjack9872004/ ---------------------------------------------------------------------- $ host 198.26.130.36 36.130.26.[98.in-addr.arpa domain name pointer BU-WCS1-SAND.NIPR.MIL. [whois.completewhois.com] Elan Completewhois.Com Whois Server, Version 0.91a6, compiled on Jan 02, 2004 Please see http://www.completewhois.com/help.htm for command-line options Use of this server and any information obtained here is allowed only if you follow our policies at http://www.completewhois.com/policies.htm [IPv4 whois information on 198.26.130.36 ] [Query Origin: Main Whois Query ] [whois.arin.net] OrgName: The Defense Information Systems Agency OrgID: DISA Address: DISA/DSSO/JCLCC Address: Room BF655A, The Pentagon City: Washington StateProv: DC PostalCode: 20301 Country: US NetRange: 198.25.0.0 - 198.26.255.255 CIDR: 198.25.0.0/16, 198.26.0.0/16 NetName: NETBLK-DISA-C NetHandle: NET-198-25-0-0-1 Parent: NET-198-0-0-0-0 NetType: Direct Allocation NameServer: AAA-KELLY.NIPR.MIL NameServer: AAA-VAIHINGEN.NIPR.MIL NameServer: AAA-WHEELER.NIPR.MIL NameServer: AAA-VIENNA.NIPR.MIL Comment: RegDate: 1992-12-05 Updated: 2004-01-13

1 0

RE: Firewall opinions wanted please
by Matt Ryan 17 Mar '04

17 Mar '04

Depending on your chosen vendor the ACL cost is unlikely to be $0 - if you steal CPU cycles from packet forwarding then you incur earlier router upgrade costs and that has a NPV cost increase associated with it. It's just not as obvious as a invoice for a firewall. Matt. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Eric Gauthier Sent: 17 March 2004 17:20 To: nanog(a)merit.edu Subject: Re: Firewall opinions wanted please > > _Everyone_ (network connected) should have a firewall. My grandma should > > have a firewall. Nicole, holding dominion over this business network and > > its critical infrastructure, should _definitely_ have a firewall. ;) By "firewall", do you mean "dedicated unit that does statefull filtering" or just "something that will block packets"? We've successfully argued to just about every group here at our University who came to us asking for a "firewall" that, given what they wanted to achieve, they could accomplish the same thing with simple ACLs... I'm sure that the cost of the ACL's (i.e. $0.00) versus the cost of a firewall also helped them in their decision... Eric :) ------------------------------------------------------------------------------ Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==============================================================================

2 1

Update on Querying IADB
by Anne P. Mitchell, Esq. 17 Mar '04

17 Mar '04

For those interested in seeing how this has evolved, and what exactly this particular accreditation database provides, our query pages have been expanded, and include a link to the full suggested DNSL data response codes. The codes we use at present include: 127.0.0.1 Listed in IADB 127.0.1.255 Vouched listing 127.2.255.1 Publishes SPF record 127.2.255.2 Publishes Microsoft "Caller I.D. for Email" record 127.2.255.101 Participates in Habeas program 127.2.255.102 Participates in Ironport's Bonded Sender program 127.3.100.0 Has absolutely no mailing controls in place 127.3.100.1 Scrapes addresses, pure opt-out only 127.3.100.2 Accepts unverified sign-ups such as through web page 127.3.100.3 Accepts unverified sign-ups, gives chance to opt out 127.3.100.4 Reserved 127.3.100.5 Has opt-in confirmation mechanism 127.3.100.6 Has and uses opt-in confirmation mechanism 127.3.100.7 Reserved 127.3.100.8 Reserved 127.3.100.9 Reserved 127.3.100.10 All mailing list mail is confirmed opt-in The general information is at http://www.isipp.com/iadb.php Query information specifically is at http://www.isipp.com/iadbquery.php It is, of course, free to query IADB, as well as to be listed as an individual. Anne

3 4

Re: Firewall opinions wanted please
by Rachael Treu 17 Mar '04

17 Mar '04

On Wed, Mar 17, 2004 at 02:01:59PM -0500, Matthew Silvey said something to the effect of: > On Wed, Mar 17, 2004 at 11:57:33AM -0600, Rachael Treu wrote: > > > > As for your assertion that firewalls "reduce the overall security of the > > 'net."...can you please elaborate on that, as well? Other factions might/do > > argue that it's the other team refusing to lock their doors at night that > > are perpetuating the flux of bad behavior as a close second to the ignorant > > and infected. > > > > > to extend an abstraction: > > these factions are arguing about the lock on the door, but it is the door > that is important. it is a feature of the house, a means of entering and > exiting. if you argue that all doors must have a lock then you can no longer > have the freedom of design and creation to decide whether your house will > have a door for pigeons, hamster, cats, or humans without deciding how each > specific door can be accessed by each specific creature. By that rationale, why must any houses have doors at all? Further, your analogy doesn't, I feel, hold water in this case. Let's reverse that portion of said abstraction. I said all doors must have locks and all edges filters. I did not expound upon to what extent those edges are filtered. Saying that the doors must be locked does not have anything to do with whether the doors are for pigeons, hamster, cats, or humans... Access control balances this equation. You can lock a pigeon door with a key that the pigeon can bear and the hamster... Okay...this is getting absurd. Let's revert to netspeak. :) Access control. "if you argue that all doors must have a lock then you can no longer have the freedom of design and creation to decide whether your house will have a door for pigeons, hamster, cats, or humans without deciding how each specific door can be accessed by each specific creature." Exactly. Absolutely! What is wrong with that? That is my point. This is not an "information wants to be free" argument, guys. You have a network connection, you have a responsibility to ensure that you manage your risks and also that you do not enable it to be used to harm others. You build a corporate intranet server and I want to get into it. Are you going to let me? Or are you going to design it with the intent that only corporate hamsters...er...employees can access that specific door. How about your home network? Mind if I do a little recon and raid your personal systems for password and personal info harvesting? Do you _use_ passwords, for that matter? If the argument is really about a means of entering and exiting and not locking or restricting access, then why bother? Do you lock the front door to your house? These wide-swinging doors of which you speak are not practical in terms of government intelligence. Or physical border control. If your doors-- which given what you are describing are actually doorless doorways and more closely resemble gaping maws--were appropriate edge deployments, then guards should drop from perimeter and border walls, passwords should come off machines, encryption should die, ATM PINs should be decommissioned, and so on and so forth. Inarguably people complain that passwords are annoying to maintain and enter and that firewalls are in the way a lot of the time. Thankfully, many of those complaining are outsiders and intruders that shouldn't be getting in, too. I imagine that vehicle thieves find door locks to be a bit of an impairment to their livelihood, too. This is about access control. Not everything out there is meant to be collected and used by everyone else. Why do you have doors? So that people can get in. Why do you lock them? So that only the appropriate people can. The tenet of effective network security is to make the holes punched into a network small enough to prevent unauthorized access, but not so small that functionality is impaired. It is the goal of security engineers (the decent ones at least) to determine how things like access controls can best serve and protect, interoperate with, and withstand the rigors of the network, not the other way around. Now...how is it that a firewall deployed to protect the deployer's network is crushing the fundamental network purism or kills our inner rogue or pens in our data (free range packets, anyone?) These methodologies are not conjured up in order to irritate those managing the movement of traffic (legitimately). This is about flow control of payload, as are stoplights and turnstyles and credit card companies asking for your mother's maiden name and photo IDs and taking a number at the butcher or DMV... > if you're selling services that consist of pushing http/dns/smtp/pop3 traffic > then you have a much easier time inserting and using any kind of filtering > system. but if your preventative system stifles the development of new > applications then you have a losing situation. any kind of filtering > automatically creates a roadblock for network application development. If there is no network, there is no netapp development. Denial of Service then presents something other than a roadblock? Or the hijacking or prevention of development details and trade secrets? The owning of a device or deletion of throngs of data to make room for warez...? Bandwidth consumption due to other security violations...? Develop in-house, behind edge filters. The only development that edge filtering gets in the way of is rootkits that the nefarious are testing. Make use of a competent security professional who knows how to tweak filters properly for the task at hand and you won't have any "roadblocks" except for those trying to roadblock the criminal element... > all > in all the cost of the IT staff is probably less than the cost of lost > development time. it sucks, but any delays on a development schedule can > translate to potential revenue lost. And what kind of cost do you think is realized by your providers who are required by contract and law to maintain security teams and respond to security incidents? You are merely passing the buck here and shifting collateral damage. I'm going to try to climb down from this soapbox now. Remember...we're all friends here. Neither side wants to halt innovation or network utilization. --ra -- k. rachael treu, CISSP rara(a)navigo.com ..quis costodiet ipsos custodes?..

1 0

who offers cheap (personal) 1U colo?
by Janet Sullivan 17 Mar '04

17 Mar '04

> I have been aching for this now for about six years. In every > professional setting I've ever been in, a need for this kind of thing > arises and my advice to my employer/client is always the same: pay the > $x per month for a colo server for your network/system engineers to use > as an outpost for emergencies, external analysis, and monitoring. Exactly! While route servers are great, sometimes I need the flexablity of an outside shell account to do troubleshooting. I know a few other people at work who also keep outside shell accounts somewhere for this very purpose. > It seems like approaching one of the larger colo providers and > coordinating some sort of "NANOG Discount" might be one quick route. I'm of two minds on this. Obviously, if a group of us go to provider X and say we want Z amount of rack space, we can probably get a good deal. On the other hand, I'm also interested in a community of like minded folks with servers located in diverse environments who would trade access with one another. If we're all in one rack in one datacenter, there is more of a chance we'll all go down together. If we have a diverse footprint, that is much less likely to happen. > The discount could be restricted to those who are appropriately vetted. > This program would be of value to the colo provider because of the > potential for discount recipients to direct business their way. How would this vetting process work? I'm willing to give other nanog folks shell accounts on my machine in return for same, but I really don't want to hand out accounts to packet kiddies. > Suffice it to say, I'm interested, both to address current work-day > issues and for personal use. I'm also interested. I do currently have a dedicated FreeBSD server in Australia for personal use. Those of us who are running our own personal mail & DNS servers could get together to back each other up.

5 4

Cisco switch CPU overload
by Priyantha 17 Mar '04

17 Mar '04

I've a core switch (cisco 5505) with 10+ VLANs configured on that and a cisco 7204 directly connected to it. 7204 then connects to my upstream and we run BGP. we announce two different /21 blocks and was fine until last week. We got new /20 IP block and we advertised it (added to 7204 config). Everything is working fine but since than we see CPU overload from time to time on 5505. The following further explains the physical connection. |-----------| |-----------| Internal | |-----------| |-------->Upstream <-----|5505 | |7204 | |-----------| |-----------| We have Rip (ver 2) running on 5505 but not on 7204. (Those two are not talking any routing protocols each other.) I can't figure out the reason but want urgently get this resolved. You may contact me off list too for further info necessary. Thanks in advance, Priyantha Pushpa Kumara Wightman Internet Ltd.

1 0