- Test - lists.nanog.org

The Cidr Report
by cidr-report＠potaroo.net 12 Mar '04

12 Mar '04

This report has been generated at Fri Mar 12 21:47:22 2004 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 05-03-04 132261 92241 06-03-04 132433 92219 07-03-04 132274 92242 08-03-04 132268 92202 09-03-04 132135 92247 10-03-04 132227 92450 11-03-04 132445 92466 12-03-04 132560 92585 AS Summary 16741 Number of ASes in routing system 6735 Number of ASes announcing only one prefix 1389 Largest number of prefixes announced by an AS AS7018 : ATTW AT&T WorldNet Services 73583360 Largest address span announced by an AS (/32s) AS568 : DISOUN DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 12Mar04 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 132868 92556 40312 30.3% All ASes AS4323 689 200 489 71.0% TWC-34 Time Warner Communications, Inc. AS7018 1389 968 421 30.3% ATTW AT&T WorldNet Services AS6197 678 300 378 55.8% BNS-14 BellSouth Network Solutions, Inc AS7843 492 120 372 75.6% ADELPH-13 Adelphia Corp. AS701 1318 947 371 28.1% UU UUNET Technologies, Inc. AS27364 388 33 355 91.5% ARMC Armstrong Cable Services AS22909 372 34 338 90.9% CMCS Comcast Cable Communications, Inc. AS6198 547 216 331 60.5% BNS-14 BellSouth Network Solutions, Inc AS4134 643 317 326 50.7% CHINANET-BACKBONE No.31,Jin-rong Street AS22773 351 39 312 88.9% CXAB Cox Communications Inc. Atlanta AS1239 968 669 299 30.9% SPRN Sprint AS4355 385 101 284 73.8% ERSD EARTHLINK, INC AS6347 370 87 283 76.5% SAVV SAVVIS Communications Corporation AS6140 375 111 264 70.4% IMPSA ImpSat AS1221 889 634 255 28.7% ASN-TELSTRA Telstra Pty Ltd AS17676 297 43 254 85.5% JPNIC-JP-ASN-BLOCK Japan Network Information Center AS9583 384 140 244 63.5% SATYAMNET-AS Satyam Infoway Ltd., AS6478 273 42 231 84.6% ATTW AT&T WorldNet Services AS25844 243 16 227 93.4% SASMFL-2 Skadden, Arps, Slate, Meagher & Flom LLP AS209 722 509 213 29.5% QWEST-4 Qwest AS14654 215 4 211 98.1% WAYPOR-3 Wayport AS20115 629 420 209 33.2% CHARTE-72 Charter Communications AS11305 243 41 202 83.1% INTERL-80 Interland Incorporated AS4766 436 244 192 44.0% KIX Korea Internet Exchange for "96 World Internet Exposition AS2386 431 240 191 44.3% ADCS-1 AT&T Data Communications Services AS4519 204 21 183 89.7% MAASCO Maas Communications AS9929 209 30 179 85.6% CNCNET-CN China Netcom Corp. AS6327 206 28 178 86.4% SHAWC-2 Shaw Communications Inc. AS5668 350 173 177 50.6% CIH-12 CenturyTel Internet Holdings, Inc. AS3356 853 683 170 19.9% LEVEL3 Level 3 Communications Total 15549 7410 8139 52.3% Top 30 total Possible Bogus Routes 24.138.80.0/20 AS11260 AHSICHCL Andara High Speed Internet c/o Halifax Cable Ltd. 64.46.0.0/18 AS7850 IHIGHW iHighway.net, Inc. 64.46.4.0/22 AS11711 TULARO TULAROSA COMMUNICATIONS 64.46.12.0/24 AS7850 IHIGHW iHighway.net, Inc. 64.46.27.0/24 AS8674 NETNOD-IX Netnod Internet Exchange Sverige AB 64.46.34.0/24 AS3408 64.46.60.0/24 AS7850 IHIGHW iHighway.net, Inc. 64.46.63.0/24 AS7850 IHIGHW iHighway.net, Inc. 64.62.126.0/23 AS25700 SWIFTD SWIFTDESK VENTURE 66.114.0.0/19 AS16526 BIRCHT Birch Telecom, Inc. 69.8.128.0/17 AS7260 NORL Norlight Telecommunications 132.0.0.0/10 AS568 DISOUN DISO-UNRRA 137.0.0.0/13 AS568 DISOUN DISO-UNRRA 138.136.0.0/13 AS568 DISOUN DISO-UNRRA 158.0.0.0/13 AS568 DISOUN DISO-UNRRA 164.234.0.0/16 AS721 DNIC DoD Network Information Center 164.234.0.0/18 AS721 DNIC DoD Network Information Center 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.30.127.0/24 AS719 LANLINK Elisa Oyj 192.43.230.0/24 AS4738 SAARDNET-AS South Australian Academic Research and Development Network 192.44.0.0/19 AS702 AS702 MCI EMEA 192.64.84.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.81.182.0/24 AS719 LANLINK Elisa Oyj 192.81.183.0/24 AS719 LANLINK Elisa Oyj 192.81.184.0/24 AS719 LANLINK Elisa Oyj 192.119.135.0/24 AS270 NASA National Aeronautics and Space Administration 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.133.6.0/24 AS4004 GLOBALONE-EQUANT-UK Equant UK Autonomous System 192.135.50.0/24 AS7018 ATTW AT&T WorldNet Services 192.136.71.0/24 AS719 LANLINK Elisa Oyj 192.136.79.0/24 AS719 LANLINK Elisa Oyj 192.153.144.0/21 AS568 DISOUN DISO-UNRRA 192.172.0.0/19 AS568 DISOUN DISO-UNRRA 192.188.208.0/20 AS568 DISOUN DISO-UNRRA 192.243.32.0/23 AS2044 PALINA Palin Aquisitions Inc. 198.23.26.0/24 AS4390 BELLAT-7 Bell Atlantic, Inc. 198.97.72.0/21 AS568 DISOUN DISO-UNRRA 198.97.80.0/20 AS568 DISOUN DISO-UNRRA 198.97.88.0/24 AS89 NUSC-1 Naval Underwater Systems Center 198.97.192.0/20 AS568 DISOUN DISO-UNRRA 198.97.240.0/20 AS568 DISOUN DISO-UNRRA 198.101.4.0/22 AS568 DISOUN DISO-UNRRA 198.136.32.0/20 AS19329 MCBCC Martin County Board of County Commissioners 198.144.32.0/19 AS3998 CITY CityNet, Inc. 198.161.87.0/24 AS6539 GTGR GT Group Telecom Services Corp. 198.161.165.0/24 AS852 AGTA Telus Advanced Communications 198.163.155.0/24 AS684 MRN Manitoba Regional Network 198.167.0.0/16 AS7456 INS-51 Interhop Network SERVICES Inc. 198.167.163.0/24 AS15290 ACCA-2 Allstream Corp. Corporation Allstream 198.168.0.0/16 AS701 UU UUNET Technologies, Inc. 198.169.0.0/16 AS803 SASK SaskTel 198.232.133.0/24 AS23075 SKOTOS Skotos Tech, Inc 199.10.0.0/16 AS568 DISOUN DISO-UNRRA 199.60.0.0/20 AS271 UBC-3 University of British Columbia 199.84.0.0/16 AS701 UU UUNET Technologies, Inc. 199.114.0.0/18 AS568 DISOUN DISO-UNRRA 199.114.0.0/21 AS568 DISOUN DISO-UNRRA 199.114.128.0/18 AS568 DISOUN DISO-UNRRA 199.114.130.0/24 AS721 DNIC DoD Network Information Center 199.114.132.0/24 AS721 DNIC DoD Network Information Center 199.114.136.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.138.0/24 AS721 DNIC DoD Network Information Center 199.114.140.0/24 AS3544 DISAUN DISA/UNRRA 199.114.142.0/24 AS721 DNIC DoD Network Information Center 199.114.144.0/24 AS721 DNIC DoD Network Information Center 199.114.148.0/24 AS721 DNIC DoD Network Information Center 199.114.150.0/24 AS721 DNIC DoD Network Information Center 199.114.152.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.154.0/24 AS1733 ADP-41 AF DDN PMO 199.114.156.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.160.0/24 AS1733 ADP-41 AF DDN PMO 199.120.32.0/19 AS16582 NXLI NEXTLEVEL INTERNET, INC. 199.121.0.0/16 AS568 DISOUN DISO-UNRRA 199.123.0.0/18 AS568 DISOUN DISO-UNRRA 199.123.16.0/20 AS568 DISOUN DISO-UNRRA 199.123.80.0/21 AS568 DISOUN DISO-UNRRA 199.189.32.0/19 AS7332 IQUEST IQuest Internet 199.202.0.0/16 AS701 UU UUNET Technologies, Inc. 202.2.64.0/20 AS9729 IS-AP iAdvantage Limited 202.47.1.0/24 AS7491 PI-PH-AS-AP PI-PHILIPINES 202.70.0.0/20 AS4658 NETFRONT-AS NETFRONT I.T. LIMITED (HONG KONG) 202.70.24.0/24 AS17888 SINGTEL-HK SingTel Hong Kong Limited 202.70.28.0/24 AS4515 ERX-STAR Star Internet Services Ltd. 202.70.240.0/20 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.73.128.0/22 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.86.128.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.142.0/24 AS30362 HAWAI-1 Hawaii-Pacific Teleport 202.86.171.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.172.0/23 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.86.190.0/24 AS4750 LOXLEY-TH Loxley Information Co., Ltd. 202.93.0.0/20 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 202.122.76.0/24 AS17553 TIMELESS-AP System Integration provider 202.133.3.0/24 AS9335 CIP-JAPAN-AS-AP ATT IPlus 202.143.56.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.149.240.0/20 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.149.240.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.149.248.0/21 AS4761 INDOSAT1-AP INDOSATNET-ASN 202.155.243.0/24 AS4795 INDOSAT2-ID-AP INDOSATNET-ASN 202.170.128.0/22 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.170.133.0/24 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 202.170.134.0/23 AS4755 VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 203.32.4.0/23 AS7617 203.62.0.0/17 AS7572 AARNET-ACT-RNO Australian Academic and Reasearch Network (AARNet) 203.87.224.0/19 AS4799 CHINA169-JT CNCGROUP old Jitong IP network 203.132.107.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.108.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.118.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 203.132.122.0/24 AS4802 WANTREE-AS-AP Wantree Development 203.132.123.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 203.132.124.0/24 AS18065 CENTRALDATA-WA Central Data Pty Ltd. 204.69.144.0/22 AS5668 CIH-12 CenturyTel Internet Holdings, Inc. 204.154.125.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.194.110.0/23 AS30653 EXOBI Exobit Networks Inc. 205.150.0.0/15 AS701 UU UUNET Technologies, Inc. 206.41.32.0/19 AS14824 NCC-105 NewSouth Communications Corp. 206.81.187.0/24 AS19194 SNL-8 Sentris Network LLC 206.108.34.0/24 AS852 AGTA Telus Advanced Communications 206.108.35.0/24 AS852 AGTA Telus Advanced Communications 206.167.57.0/24 AS376 RISQR-3 Reseau Interordinateurs Scientique Quebecois (RISQ) 206.191.64.0/18 AS15290 ACCA-2 Allstream Corp. Corporation Allstream 206.251.69.0/24 AS27429 TIL-33 Telesat International Ltd. 207.162.192.0/19 AS4589 EASYNET Easynet Group Plc 207.231.96.0/19 AS11194 NUNETI NuNet Inc 208.81.187.0/24 AS19194 SNL-8 Sentris Network LLC 209.169.219.0/24 AS189 GNTY Genuity 209.169.223.0/24 AS189 GNTY Genuity 209.172.0.0/18 AS7770 TRTI Triton Technologies, Inc. 209.205.69.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.70.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.81.0/24 AS15066 SkyNet de Colombia S.A. 209.205.82.0/24 AS15066 SkyNet de Colombia S.A. 209.205.84.0/24 AS15066 SkyNet de Colombia S.A. 209.205.95.0/24 AS6347 SAVV SAVVIS Communications Corporation 209.213.32.0/19 AS10629 INS-52 Inter-Pacific Network Services 209.213.50.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.51.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.55.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.56.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.222.137.0/24 AS27429 TIL-33 Telesat International Ltd. 209.240.96.0/19 AS10815 KCNETI-1 KCnet, Inc. 209.251.0.0/19 AS11036 SISCOM-1 SISCOM, Inc 209.251.64.0/19 AS10266 MDCN MDC, Inc. 210.213.0.0/19 AS6453 GIEUROPE Teleglobe America Inc. 216.18.224.0/21 AS11458 IMBRIS-1 IMBRIS, INC. 216.18.224.0/22 AS11458 IMBRIS-1 IMBRIS, INC. 216.18.228.0/22 AS11458 IMBRIS-1 IMBRIS, INC. 216.96.128.0/18 AS7018 ATTW AT&T WorldNet Services Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

RE: Counter DoS
by Drew Weaver 12 Mar '04

12 Mar '04

-----Original Message----- From: Gregory Taylor [mailto:greg@xwb.com] Sent: Thursday, March 11, 2004 3:55 PM To: Rachael Treu Cc: nanog(a)merit.edu Subject: Re: Counter DoS Yes, lets allow the kiddies who already get away with as little work as they can in order to produce the most destruction they can, the ability to use these 'Security Systems' as a new tool for DoS attacks against their enemies. Scenerio: Lets say my name is: l33th4x0r I want to attack joeblow.cable.com because joeblow666 was upset that I called his mother various inappropriate names. I find IP for joeblow.cable.com to be 192.168.69.69 I find one of these 'security' systems, or multiple security systems, and i decide to forge a TCP attack from 192.168.69.69 to these 'security systems'. These 'security systems' then, thinking joeblow is attacking their network, will launch a retaliatory attack against the offender, 192.168.69.69 thus destroying his connectivity. Kiddie 1 Joeblow 0 The Internet as a whole 0 Greg --- Rant/ Their solution isn't the best idea out there, but something definitely needs to be done, and quickly. Network providers shouldn't have to purchase 4x the amount of bandwidth that they need just in case someone hijacks a bunch of cable modems and wants to party. Perhaps their bad idea will lead to a better idea, its happened before with how many countless practices on the internet? You start with a blurry idea, then someone else takes it and makes it work. Im not saying ddosing people back is the best idea, but something needs to happen, we waste way too much time and money mitigating these attacks, when in reality they cant be mitigated unless you continue to throw cash into the bandwidth bucket. These DSL and cable modem companies need to tighten things up so that if their users are abusive (and I don't claim to know how exactly the parameters of abuse should be measured) that their systems automatically choke them. For example, I have a Cable modem /w rr at my home, they have my upstream limited to next to nothing, how much damage could I possibly do? On the other hand I've seen attacks from some residential DSL providers that have hit with over 500KB(bytes)ps from a single machine, if you have maybe 20 of these hitting one of your interfaces, its going to cause latency, unless your upstream, or their downstream is doing something to protect you, which they wont. /Rant -Drew

5 4

Automate router configs
by Jason Graun 12 Mar '04

12 Mar '04

Is anybody automating router/switch configs in any manner other then telnet scripts or Ciscoworks? I am just trying to get some ideas. Thanks Jason

4 3

Re: Enterprise Multihoming
by John Neiberger 12 Mar '04

12 Mar '04

>Whilst the topic's under discussion may I present myself as a lightning >rod :) by asking: > >(a) Has anyone here used any of the 'basement multi-homing in a box' >products such as Checkpoint's ISP Redundancy feature? > >http://www.checkpoint.com/products/connect/vpn-1_isp_redundancy.html >(The 'VPN-1' brand is slightly misleading - it's a generic firewall.) > >This allows edge networks to multihome between separate ISPs. When it was >first mentioned around the office I explained that it couldn't possibly >work, and my colleagues explained to me that I was full of it and that the >product is on the market and in use. (It has subsequently been lab'd here >and seemed to work between our main link (UUnet) and a humble BT DSL line.) >As far as I understand it, it's a form of NAT - the device keeps track of >which session's packets are going where and spreads traffic around. If one >ISP goes down it'll fail over to the other link. There are similar boxes from FatPipe and Radware (and others) that promise the same thing. I've done some light research on them and while I can see some positives, I don't prefer them to our current solution. My boss asked me to take a look at them, again, because he's concerned that there's little BGP experience in our department apart from me and he thought that might be one possible solution. It still may be but I don't like the hoops you have to jump through to make these devices work. Then again, I don't have any practical experience with them and I hope someone who has will chime in. John --

3 2

RE: Counter DoS
by Priscilla Oppenheimer 12 Mar '04

12 Mar '04

One aspect of the problem with DoS attacks and warlike responses to these attacks is that the younger generation is getting their computer science training via gaming and hacking. Many high schools in the U.S. are so financially strapped that they can't afford to teach programming, networking, etc., and if they can, the teachers are often also the shop teacher or the journalism teacher who happened to "be good with computers" but is actually rather clueless about real computer science issues and the computer industry. Tekkie high school students aren't being challenged. They are learning their computing skills without mentors. We can help with that aspect of the problem. Get involved with your local high schools. Sponsor user groups at the high school. Offer to teach some mini courses. The teenage crowd needs our help learning best practices and ethics. The hacking problem is multi-faceted, of course, and this is just one facet of a partial solution, but still, do consider it. Thanks for listening. :-) Priscilla Oppenheimer At 04:48 PM 3/11/04, Pendergrass, Greg wrote: >By "The Art of War on the Internet" I didn't mean information warfare, >that's been with us as long as there's been information and the internet is >certainly going to be a major part of that. What I am against is anyone >trying to popularize the idea of the internet as a battleground where one >uses force and deception to "gain ground". It's just another case of people >wrongly attempting to fit somthing that they don't understand into a >framework that they do understand, thereby creating a fallacy. Trying to >base a product off of a flawed idea is bound to fail but also likely be a >major irritation before it does. > >GP > > >-----Original Message----- >From: Etaoin Shrdlu [mailto:shrdlu@deaddrop.org] >Sent: 11 March 2004 14:58 >To: Nanog >Subject: Re: Counter DoS > > > >"Pendergrass, Greg" wrote: > > > > I can see now that it's only a matter of time before some nut writes "The > > Art of War in the Internet". I read the whitepaper, it goes on a lot about > > how defensive policies are ineffective but doesn't really say why active > > response has never been tried: > >Ask, and ye shall receive. > >http://btobsearch.barnesandnoble.com/textbooks/booksearch/isbnInquiry.asp?us >erid=2XH986JPUE&btob=Y&isbn=1581128576&TXT=Y&itm=1 > >I thought that someone mentioned that Mr. Forno was reputed to be on staff >with these folk. > > > Their proposition is a terrible idea and their "rules of engagement" would > > be funny instead of frightening if it wasn't serious > >I note that he also has a title from last year, which seems applicable >here: > >Weapons of Mass Delusion (ISBN 158961111X) > >I will point out that I cannot take seriously a company (Symbiot) that >depends on a shockwave plugin to put up a web page. > >Pity that they came out so aggressively; it might have been an interesting >product. Hype can kill as well as sell. > >-- >It is by caffeine alone I set my mind in motion. >It is by the beans of Java that thoughts acquire speed, >the hands acquire shaking, the shaking becomes a warning. >It is by caffeine only I set my mind in motion. > > >Vodafone Global Content Services Limited >Registered Office: Vodafone House, The Connection, Newbury, >Berkshire RG14 2FN > >Registered in England No. 4064873 > >This e-mail is for the addressee(s) only. If you are not an addressee, you >must not distribute, disclose, copy, use or rely on this e-mail or its >contents, and you must immediately notify the sender and delete this e-mail >and all copies from your system. Any unauthorised use may be unlawful. The >information contained in this e-mail is confidential and may also be legally >privileged. _______________________________ Priscilla Oppenheimer www.priscilla.com When your Daemon is in charge, do not try to think consciously. Drift, wait, and obey. -- Kipling.

2 1

Re: Counter DoS
by Rachael Treu 11 Mar '04

11 Mar '04

On Thu, Mar 11, 2004 at 03:21:29AM -0500, Brian Bruns said something to the effect of: > > On Thursday, March 11, 2004 3:05 AM [EST], Brian Bruns <bruns(a)2mbit.com> > wrote: ..snip snip.. > > How the hell could a company put something like this out, and expect not to > > get themselves sued to the moon and back when it fires a shot at an innocent > > party? Caution: 'innocent' is not the buzzword here. Subscribers: check your respective AUPs. You will likely find explicit prohibition of any malicious and generally unsolicited traffic generated by a node in your control, and I don't think that self-defense has an extenuation clause or special case appendix therein. You attack an attacker, he, too, can pursue you legally. There are not provisions made for DoS-ing a DoS-er. Vigilante nonsense is discouraged. > ..snip snip..> > Whats going to happen when they find a nice little exploit in these buggers > (even if they have anti-spoof stuff in them) that allows the kids to take > control of them or trick them into attacking innocents? Instead of thousands > of DDoS drones on DSL and cable modems, you'll see kids with hundreds of these > 'nuclear stike firewalls' on T1s, T3s, and higher, using them like they use > the current trojans? This won't even require a exploit to effect. These boxes can likely be used to do the bidding of miscreants with some simply-crafted packets and source spoofing. This thing could become something akin to a smurf amp with a big-time attitude problem. Anti-spoof rules will afford a modicum of reverse-path protection, but not enough to swat away the majority of inbound crafted traffic. This stupid PoS appliance would have to be installed and widely-deployed provider-side to discern on such a level. This would become the stuff of yet-another-botnet. > > No product is 100% secure (especially not something that runs under Windows, > but thats another issue), so how are they going to deliver updates? This is the least of their concerns; update management is already done effectively and easily by most IDS, anti-virii, and other signature-based appliance manufacturers. Snakeoil salesmen offer at the most basic a valid means of distributing updates, even. > Or make sure that the thing is configured right? Now _that_ is a real problem. Given that no one has beaten the creators with the illustrious clue stick and anyone who'd truly subscribe to this thing is likely mis-wired him/herself, I would guess that poor configuration is an engineering cornerstone on which this entire debacle desperately depends. Flog the scoundrels. ymmv, --ra -- k. rachael treu, CISSP rara(a)navigo.com ..quis costodiet ipsos custodes?.. > I could see blacklists (BGP based) > cropping up of these systems, so that you can filter these networks from ever > being able to come near your network. > > This is starting to sound more and more like a nuclear arms race - on one side > we have company a, on the other company b. Company A fears that B will attack > it, so they get this super dooper nuclear strike system. Company B follows > suit and sets one up as well. Both then increase their bandwidth, outdoing > the other until finally, script kiddie comes along, and spoofs a packet from A > to B, and B attacks A, and A responds with its own attack. ISPs hosting the > companies fall flat on their face from the attack, the backbone between the > two ISPs gets lagged to death, and stuff starts griding to a halt for others > caught in the crossfire. > > So, and who thinks that this is a good idea? :) > -- > Brian Bruns > The Summit Open Source Development Group > Open Solutions For A Closed World / Anti-Spam Resources > http://www.sosdg.org > > The Abusive Hosts Blocking List > http://www.ahbl.org

1 0

Re: Enterprise Multihoming
by John Dupuy 11 Mar '04

11 Mar '04

John As already stated by lots of folks on the list, this is largely a business decision rather than a technical one. However, there are some more useful thoughts: 1. Is the decision to multi-home consistent with your other redundancy plans? For example, why go through all the trouble of multi-homing and setting up BGP, only for both circuits to be plugged into the same router? ..or, two routers but neither of them on UPS. This is akin to insisting on a Class A bank-grade firewall but not bothering to put a lock on the server room door... 2. Multi-homing is usually considered critical when one is discussing hosting of some kind. Could you be served with multiple servers in geographically separate collocation centers inside one ASN? While many MIS departments like to have direct access to their own servers, this can often be an emotional preference rather than a technical one. Often only the "public facing" servers need BGP redundancy. The back-ends can be set up to fail-over to separate VPN/IPs in separate ASNs. Having said all that, I prefer physical access to my machines too. So I'm a hypocrite. 3. If you are not doing hosting, a two-ISP NAT solution may make more sense than BGP. In addition to burdening the global routing tables; good BGP management is expensive. It involves either hiring someone with the proper expertise/experience or purchasing that expertise. Relatively speaking, there are not a lot good experienced BGP admins out there. 4. What is the price of downtime, in real dollars? For many business, this really can be estimated. Consider lost time (wages, utilities, etc.) and lost sales. Then compare it to the various options. Just my two cents, John At 10:04 AM 3/11/2004, you wrote: >On another list we've been having multihoming discussions again and I >wanted to get some fresh opinions from you. > >For the past few years it has been fairly common for non-ISPs to >multihome to different providers for additional redundancy in case a >single provider has problems. I know this is frowned upon now, >especially since it helped increase the number of autonomous systems and >routing table prefixes beyond what was really necessary. It seems to me >that a large number of companies that did this could just have well >ordered multiple, geographically separate links to the same provider. > >What is the prevailing wisdom now? At what point do you feel that it is >justified for a non-ISP to multihome to multiple providers? I ask >because we have three links: two from Sprint and one from Global >Crossing. I'm considering dropping the GC circuit and adding another >geographically-diverse connection to Sprint, and then removing BGP from >our routers. > >I see a few upsides to this, but are there any real downsides? > >Flame on. :-) > >Thanks, >John >--

1 0

Web Based tool for tracking circuits
by Marius Strom 11 Mar '04

11 Mar '04

I know there's always people searching out web based utils for tracking IP allocations and such, but surprisingly I don't recall there ever being discussion on tracking circuits. I'm looking for such a tool and am curious if anyone knows of one? I'm looking to track: circuit type, circuit id, trouble reporting number, serving telco. Possibly more, such as connected-router information, etc. Thanks in advance, if there's sufficient demand I'll summarize back to the list. -- /-------------------------------------------------> Marius Strom | Always carry a short length of fibre-optic cable. Professional Geek | If you get lost, then you can drop it on the System/Network Admin | ground, wait 10 minutes, and ask the backhoe http://www.marius.org/ | operator how to get back to civilization. \-------------| Mike Andrews |-------------------->

4 6

Re: Enterprise Multihoming
by John Neiberger 11 Mar '04

11 Mar '04

> >JN> My current opinion is that since we can't accept much >JN> downtime in the case of a single provider failure, it's >JN> probably not wise to put all of our eggs in Sprint's basket >JN> even if all circuits are geographically diverse. > >Use multiple border routers. Keep your IGP lean and nimble. >Think about BGP/IGP synchronization. > >WAN links can fail, but so can ethernet links and entire routers. We have multiple border routers and are fairly redundant internally. As it is now, any single piece of equipment could fail (except in one case that I intend to rectify soon) or any two of our three Internet connections could fail and no one would notice much except for perhaps slower connections. I've discovered the wonders of fault-tolerant transceivers and I'll be redesigning a portion of that part of the network around them. Once I'm done, quite literally any single device could fail and no one would notice. John --

1 0

Re: Enterprise Multihoming
by John Neiberger 11 Mar '04

11 Mar '04

Thanks to everyone who has responded so far. I'm glad that I got some opinions here before I proceeded. I also participate in another list that has some fairly experienced people on it. They prevailing opinion there was that multihoming to multiple providers was overrated and largely unnecessary, and they just about had me convinced. My current opinion is that since we can't accept much downtime in the case of a single provider failure, it's probably not wise to put all of our eggs in Sprint's basket even if all circuits are geographically diverse. Thanks again, John --

4 3