- Test - lists.nanog.org

RE: LoadBalancing products: Foundry ServerIron
by Karyn Ulriksen 08 Jul '00

08 Jul '00

A friend of mine was using LD's on his service. They do about 180mbps over 3 locations and were running performance problems. (They ended up moving to F5's). One of Exodus's Senior Network Engineers has seen that consistenly become problematic at about the magic 80mbps you mentioned. I spoke with a few different neteng buddies when we started looking at LB's over a year ago and they all told me to stay away from the LD's. But like all of us, they get better as they stay around longer... Probably, it's the same with all LB products ... you have to match the right products with your needs. Me, I have to go for the big scale. So I'll sacrifice features for ability to consistently handle the traffic and scalability. I eliminated quite a few simply because they couldn't handle the volume, but that doesn't mean that they would work well for a site located in one of the big data centers. -Karyn -----Original Message----- From: Bennett Todd [mailto:bet@rahul.net] Sent: Thursday, July 06, 2000 9:25 AM To: Karyn Ulriksen Cc: 'nanog(a)merit.edu' Subject: Re: LoadBalancing products: Foundry ServerIron 2000-07-06-11:56:34 Karyn Ulriksen: > > How about Local Director? > > Everyone I've spoke to about LD is very unhappy with it's > performance. That can only be because you didn't speak to me:-). Seriously, I've used them a fair bit, and like 'em a lot. Their H-A failover is superb, they load balance really gracefully, their hold-time feature (making assignments sticky) works well with simple website designs for session tracking; and I really love the way they passively monitor the performance of all servers in the farm and consistently route traffic to the currently fastest server. I've heard that they max out around 80Mbps. That was a year or so ago, I've no idea if that's still the case. I've never hit their limits. But I can believe that a faster-but-dumber load balancer would have a higher ceiling. -Bennett

5 4

FW: LoadBalancing products: Cisco LocalDirector
by Roeland M.J. Meyer 08 Jul '00

08 Jul '00

> -----Original Message----- > From: ejm(a)onmedia.com [mailto:ejm@onmedia.com] > Sent: Saturday, July 08, 2000 10:19 AM > To: Roeland M.J. Meyer; 'Stephen Sprunk'; 'Karyn Ulriksen' > Cc: 'North American Noise and Off-topic Gripes' > Subject: RE: LoadBalancing products: Cisco LocalDirector > > > Actually, the MSM module has been phased-out in favor of what Cisco > calls the "MSFC/PFC" modules for the supervisor engine. It performs > silicon based L3/L4 services, rather than MSM CPU/CEF based > forwarding. > > It is true that there is IOS based LB, which can be enabled on the > MSFC. However, the functionality is a subset of the LD. > You'll have to > visit Cisco to get the full scoop on the 6xxx futures for LB. > > You might forward this to the NANOG list, since I'm a "listen only" > member. > > As a disclaimer, I work for Cisco. > > Thanks! > > ... Erik > --- > Erik Murrey > > > "Roeland M.J. Meyer" <rmeyer(a)mhsc.com> wrote on Saturday July 8, 2000 > at 7:35am: > > > >I heard rumor that Cisco was considering including LD capability > >in the 6509 MSN router module? > > > >> Stephen Sprunk: Friday, July 07, 2000 5:46 PM > >> > >> If you are using a LocalDirector with a Cat6k switch, you can > >> enable the > >> Accelerated Server Load Balancing feature. This allows the > >Cat6k to > >> forward the bulk of the flow (at wire speed), and lets the LD > >focus > >> exclusively on the connection setup/teardown functions. > >> > >> For more information: > >> http://www.cisco.com/univercd/cc/td/doc/product/iaabu/localdir > >> /ld33rns/l > >> dicgd/ld3_ch04.htm#xtocid1675521 > >> > >> S > >> > >> | | Stephen Sprunk, K5SSS, CCIE #3723 > >> :|: :|: Network Design Consultant, HCOE > >> :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX > >> .:|||||||:..:|||||||:. Email: ssprunk(a)cisco.com > >> > >> > >> ----- Original Message ----- > >> From: "Karyn Ulriksen" <kulriksen(a)publichost.com> > >> To: "'Bennett Todd'" <bet(a)rahul.net>; "Karyn Ulriksen" > >> <kulriksen(a)publichost.com> > >> Cc: <nanog(a)merit.edu> > >> Sent: Thursday, July 06, 2000 11:40 > >> Subject: RE: LoadBalancing products: Foundry ServerIron > >> > >> > >> > > >> > A friend of mine was using LD's on his service. They do > >> about 180mbps > >> over > >> > 3 locations and were running performance problems. (They > >ended up > >> moving to > >> > F5's). One of Exodus's Senior Network Engineers has seen > >that > >> consistenly > >> > become problematic at about the magic 80mbps you mentioned. > >I spoke > >> with a > >> > few different neteng buddies when we started looking at LB's > >over a > >> year ago > >> > and they all told me to stay away from the LD's. But like > >> all of us, > >> they > >> > get better as they stay around longer... > >> > > >> > Probably, it's the same with all LB products ... you have > >> to match the > >> right > >> > products with your needs. Me, I have to go for the big > >> scale. So I'll > >> > sacrifice features for ability to consistently handle the > >> traffic and > >> > scalability. I eliminated quite a few simply because they > >couldn't > >> handle > >> > the volume, but that doesn't mean that they would work well > >> for a site > >> > located in one of the big data centers. > >> > > >> > -Karyn > >> > >> > >> > > > ....

1 0

RE: RBL-type BGP service for known rogue networks?
by rdobbins＠netmore.net 08 Jul '00

08 Jul '00

Sure; I see your point. Thing is, though you don't -have- to make the ACL thing automatic - you can have someone sitting and watching the thing, and triggering it manually after positive identification. -----Original Message----- From: John Kristoff [mailto:jtk@depaul.edu] Sent: Friday, July 07, 2000 5:01 PM To: nanog(a)merit.edu Subject: Re: RBL-type BGP service for known rogue networks? rdobbins(a)netmore.net wrote: > I certainly don't think that intrusion-detection makes sense for the > backbones and NAPs and so forth, but when you get closer to the > traffic-orginator/requestor boundaries of the network, it becomes more > feasible, does it not? Perhaps. It might be less detrimental to the entire Internet community if only a edge customer's dynamic IDS/filtering system went haywire. It then boils down to an organization's design and support philosophy. Personally, I don't like the idea of messing with packets/streams in transit unless it's route them, drop them (congestion) or mark them (IP ToS bits/DiffServ). There of course may be a few instances where you block an entire netblock (e.g. RFC 1918) or specific ports (e.g. snmp) that are widely know to be insecure or invalid. It seems easier in the long run (harder intially) to secure the end systems. Maybe I'm just getting used to vendors automatically configuring my network with the routing protocols and I'm not quite ready for automatic ACL definitions based on traffic patterns. :-) John

1 0

RE: RBL-type BGP service for known rogue networks?
by rdobbins＠netmore.net 08 Jul '00

08 Jul '00

But that's why we have human beings in the NOCs, no? As I'm mucking about with the Cisco Netranger/IDS on one of my networks, I've been able to winnow down the false-positives substantially, and am still working on improving its reliability further. I certainly don't think that intrusion-detection makes sense for the backbones and NAPs and so forth, but when you get closer to the traffic-orginator/requestor boundaries of the network, it becomes more feasible, does it not? -----Original Message----- From: John Kristoff [mailto:jtk@depaul.edu] Sent: Friday, July 07, 2000 1:59 PM To: nanog(a)merit.edu Subject: Re: RBL-type BGP service for known rogue networks? rdobbins(a)netmore.net wrote: > Isn't that why some sort of intrusion/exploit-detection system integrated > with ACLs would perhaps be a better remedy? Dealing with false positives and "intentional" black holing would be a difficult thing to get right. It sounds like the MAPS approach someone mentioned earlier would be workable. John

2 1

RE: RBL-type BGP service for known rogue networks?
by Karyn Ulriksen 07 Jul '00

07 Jul '00

Rodney Joffe wrote: >If you are talking about any of the MAPS black holes (RBL RSS etc.) the >process of getting in there is not arbitrary. It actually takes work. So >the likelihood of an innocent bystander ending up there is close to >zero. Rodney would know! I remember having to figure out how to email him back in the early spam days when I was at AnaServe. He'd blackholed one of my subnets due to a dedicated client I had back then who was spamming profusely. The only downsides I saw in it is that our network was not notified prior to the blackholing (although many avenues where publicly available) and I think that subnet is STILL (despite many, many requests and 4 years later) listed on black lists even though its neither being black holed or utilized by spammers. However, I wouldn't be surprised if some overzealous netadmin came across one of those lists and threw it in for good measure. Not my problem anymore, but UUNet's next customer who gets that block may be in for a surprise... Karyn -----Original Message----- From: Rodney Joffe [mailto:rjoffe@centergate.com] Sent: Friday, July 07, 2000 1:53 PM To: nanog(a)merit.edu Subject: Re: RBL-type BGP service for known rogue networks? John Kristoff wrote: > > Perhaps I wasn't clear... > > The organization in question does nothing wrong... but somehow gets in > the blackhole list either by someone spoofing their netblocks, from > faked complaints or other means. Thus, causing the said organization to > be denied connectivity by some malicious person(s). If you are talking about any of the MAPS black holes (RBL RSS etc.) the process of getting in there is not arbitrary. It actually takes work. So the likelihood of an innocent bystander ending up there is close to zero. /rlj

2 1

RE: RBL-type BGP service for known rogue networks?
by Kai Schlichting 07 Jul '00

07 Jul '00

At Friday 04:28 AM 7/7/00, Joe Shaw wrote: >UUNet's abuse department used to be the same way, especially during the >weekend. If you wanted to annoy the piss out of a UUNet dedicated line >customer, the weekend was the time to do it. I don't know if that's >changed now. Winds are shifting. One of the original spam floods that trigggered the creation of SpamShield, was from an Alternet dialup, and it took them a mere 10 minutes to shut that account off. That must have been a different department at the time: Try being on the receiving end of a spoofed/randomized SYN/anything flood that doesn't exceed, say: 1Mbps and doesn't load UUnet's network so much. They won't even lift a damn finger and TRY to trace this back, supposedly because they can't trace it back through their ATM PVCs (an argument that has been backed up by other people I spoke to). They will happily charge you for the traffic though. A network design that doesn't allow tracing back spoofed traffic? Way to go, UUnet. And yes, I remember CenterTrack: http://www.nanog.org/mtg-9910/robert.html , it just wasn't in production at the time - and I have no idea if it was ever deployed successfully. Now, lets watch Vijay rush to the defense of his, uhm, stock options.

5 4

scripts kiddie sites
by Karyn Ulriksen 07 Jul '00

07 Jul '00

For my edjumacation, could someone clarify what a scripts kiddie source network as it's being bandied about here is? I can only *assume*, and I try to avoid doing that (not always successfully). Thanx, Karyn. --------------------------------------------------------------------- Best regards, Karyn Ulriksen Director of Network Operations PublicHost, A SiteStream Company 22 Mauchly, Suite 200 Irvine, California 92618 USA Phone: (949) 743-2000 email: kulriksen(a)publichost.com URL: http://www.publichost.com

9 9

RE: RBL-type BGP service for known rogue networks?
by rdobbins＠netmore.net 07 Jul '00

07 Jul '00

Isn't that why some sort of intrusion/exploit-detection system integrated with ACLs would perhaps be a better remedy? -----Original Message----- From: John Kristoff [mailto:jtk@depaul.edu] Sent: Friday, July 07, 2000 1:48 PM To: nanog(a)merit.edu Subject: Re: RBL-type BGP service for known rogue networks? Shawn McMahon wrote: > > I was referring to the case where an organization is blackholed without > > sufficient cause, which in effect is a denail of service on that > > organization. > Nonsense. It's a boycott, not a denial of service. > And it's just a boycott, it's not even picketting out front with signs. Perhaps I wasn't clear... The organization in question does nothing wrong... but somehow gets in the blackhole list either by someone spoofing their netblocks, from faked complaints or other means. Thus, causing the said organization to be denied connectivity by some malicious person(s). John

2 1

OT: Earthlink Contact - Important Root Hacked
by K. Graham 07 Jul '00

07 Jul '00

Sorry to bother you all but I am looking for a contact at Earthlink. The IP is under Sprint Advanced Network Services, Altamonte Springs Florida. We have called that contact and shuffled onto Earthlink. The 1-800# to their support line proofed futile. The traditional emails to webmaster@ abuse@ etc have been sent and several phone calls have been made to contact someone responsible to no avail. We would like to contact someone who can remove the exploit that is on one of their machines. It gives the user root access (no password required) and allows you to remote copy an exploit to other machines. Our efforts have lapsed over the past several days. This exploit was used on us and we would like to remove any likelihood of others being compromised. The exploit is in the hands of the people at rootshell. -- Kim Graham, CCNA System Administrator, Client Services

3 3

The Cidr Report
by Tony Bates 07 Jul '00

07 Jul '00

This is an auto-generated mail on Fri Jul 7 12:00:00 PDT 2000 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 07Jul00 0) General Status Table History ------------- Date Prefixes 300600 80928 010700 80965 020700 80894 030700 80985 040700 81051 050700 81066 060700 81438 070700 81549 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.56.64.0/21 from AS2941 AS Summary ---------- Number of ASes in routing system: 7835 Number of ASes announcing only one prefix: 4407 (2427 cidr, 1980 classful) Largest number of cidr routes: 975 announced by AS701 Largest number of classful routes: 1061 announced by AS701 1) Gains by aggregating at the origin AS level --- 07Jul00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 436 149 287 65.8% BCnet Backbone AS1221 626 446 180 28.8% TELSTRA-AS AS7046 535 365 170 31.8% COQUI-NET PRTC Internet AS9269 187 45 142 75.9% Hong Kong CTI AS9706 153 21 132 86.3% Pusan Metropolitan City Office of AS705 569 448 121 21.3% ALTERNET-AS AS7657 295 190 105 35.6% The Internet Group Limited AS2609 125 20 105 84.0% EUnet-TN AS9304 122 18 104 85.2% Hutchcity AS7545 154 56 98 63.6% TPG Internet Pty Ltd AS6429 211 116 95 45.0% RDC-INTERNET AS577 267 180 87 32.6% Bell Backbone AS174 556 469 87 15.6% Performance Systems International AS7496 128 43 85 66.4% Power Up AS4293 325 241 84 25.8% Internal ASN for C&W AS724 228 157 71 31.1% DLA-ASNBLOCK-AS AS3908 273 204 69 25.3% Supernet, Inc. AS1727 159 90 69 43.4% MRMS-WEST AS701 1061 996 65 6.1% Alternet AS6595 110 50 60 54.5% DODDSEUR AS5106 89 31 58 65.2% AADS-COLUMBUS AS3749 116 58 58 50.0% TECNET AS7568 81 24 57 70.4% C.S. Communications Co., Ltd. AS3602 301 244 57 18.9% Sprint Canada Inc. AS4740 328 273 55 16.8% Ozemail Pty Ltd (ASN-OZEMAIL) AS7018 541 488 53 9.8% AT&T WorldNet Service Backbone AS1785 360 311 49 13.6% NYSERNet Backbone AS209 259 211 48 18.5% Qwest Communications AS9557 61 16 45 73.8% Pakistan Telecommunication Compan AS14562 80 35 45 56.2% UNKNOWN For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0