- Test - lists.nanog.org

360networks withdraws plans to acquire NetRail
by Josh Richards 19 Jun '01

19 Jun '01

"360networks today announced it no longer intends to acquire NetRail, a wholesale Internet service provider, in an all-stock transaction. The company announced plans to acquire NetRail earlier this year." Per the announcement they just sent via e-mail. Looks to be posted on <URL:http://www.360.net/> as well. -jr ---- Josh Richards <jrichard@{ geekresearch.com, cubicle.net }> [JTR38/JR539-ARIN] Geek Research, LLC - San Luis Obispo, CA - <URL:http://www.geekresearch.com/> KG6CYK - IP/Unix/telecom/knowledge/coffee/security/crypto/business/geek

4 3

Re: Routing Table inconsistencies
by rs＠seastrom.com 19 Jun '01

19 Jun '01

Tim Winders <twinders(a)SPC.cc.tx.us> writes: > This is probably a bone-head question, but what are the implications of > inconsistent-as's? it means that two different ASes are originating the same prefix/mask. > I know that I have _tons_ of bgp inconsitent-as paths, but no mbgp > inconsistent-as paths. > > I also have 2 bgp peers, but only 1 mbgp peer. I would think if you only > have 1 mbgp peer you could _not_ have any inconsistent-as paths as there > is only one source for the mbgp information, so only 1 path. Right? They could still be out there, just you would never hear them. :) ---Rob

1 0

Re: Routing Table inconsistencies
by Tim Winders 19 Jun '01

19 Jun '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is probably a bone-head question, but what are the implications of inconsistent-as's? I know that I have _tons_ of bgp inconsitent-as paths, but no mbgp inconsistent-as paths. I also have 2 bgp peers, but only 1 mbgp peer. I would think if you only have 1 mbgp peer you could _not_ have any inconsistent-as paths as there is only one source for the mbgp information, so only 1 path. Right? ********************************************** Tim Winders, MCSE, CNE, CCNA Associate Dean of Information Technology South Plains College Levelland, TX 79336 Phone: 806-894-9611 x 2369 FAX: 806-894-1549 Email: TWinders(a)SPC.cc.tx.us ********************************************** On Mon, 18 Jun 2001, David Meyer wrote: > Well, this is likely going to follow the same pattern that you've > demonstrated, that is, NASA prefixes that are advertised directly > to AS10888 and to their providers. Situation is somewhat of an > special case (that is not to say that inconsistent AS isn't a > problem in general). Interestingly, I'm not seeing either of > these at the moment, e.g. > > orix.maoz.com#sh ip mbgp inconsistent-as > > orix.maoz.com# > > (doesn't seem to be a bug, as the 2 you mention aren't > inconsistent at the moment) > > Maybe we need to get rid of 10888. > > Dave > > > Reply-To: > In-Reply-To: <3B2E8E9E.F64048DF(a)21rst-century.com>; from tme(a)21rst-century.com on Mon, Jun 18, 2001 at 07:28:31PM -0400 > > On Mon, Jun 18, 2001 at 07:28:31PM -0400, Marshall Eubanks wrote: > >> > >> Hello All; > >> > >> We had a problem with a domain with two different AS paths in the BGP table, so I wrote a script to > >> look for such problems. > >> > >> There are two prefixes in the current MBGP tables here with such problems : > >> > >> Date of BGP Dump Mon Jun 18 15:39:46 EDT 2001 > >> > >> ROUTING INCONSISTENCY Detected for Prefix = 198.9.201.0 : > >> > >> *> 198.9.201.0 160.81.38.225 75 0 1239 10888 i > >> * 204.147.129.89 0 145 24 i > >> > >> ROUTING INCONSISTENCY Detected for Prefix = 198.9.202.0 : > >> > >> * 198.9.202.0 204.147.129.89 0 145 24 i > >> *> 160.81.38.225 75 0 1239 10888 i > >> > >> And a total of 488 prefixes in the BGP tables with such problems !!!!! > >> > >> The complete lists are contained in > >> > >> http://www.multicasttech.com/status/mbgp.inconsistency and > >> http://www.multicasttech.com/status/bgp.inconsistency > >> > >> I could update these regularly if there was any demand. > >> > >> I may be obtuse, but I cannot see how this could be a good thing. > >> > >> Regards > >> Marshall Eubanks > >> > >> > >> > >> T.M. Eubanks > >> Multicast Technologies, Inc > >> 10301 Democracy Lane, Suite 410 > >> Fairfax, Virginia 22030 > >> Phone : 703-293-9624 Fax : 703-293-9609 > >> e-mail : tme(a)multicasttech.com > >> http://www.on-the-i.com > >> > >> Test your network for multicast : http://www.multicasttech.com/mt/ > >> Check the status of multicast in real time : > >> http://www.multicasttech.com/status/index.html > >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (OSF1) Comment: Made with pgp4pine 1.76 iEYEARECAAYFAjsumTQACgkQTPuHnIooYby9sQCfZmnpRildo8Irzqrx8ZvEvMBR YVIAoJsoufICV+YMv+hbEwYaNxK/u234 =3anB -----END PGP SIGNATURE-----

1 0

opinions on routers/switches for parallel clusters
by keichii＠freebsd.org 18 Jun '01

18 Jun '01

Hi Everyone, We are an educational institution looking into building a scientific computing cluster that has 128-256 nodes interconnected by gigE. The outward connection would be the site FDDI ring. The problem is that we want to experiment with the topology as well as the computing part. :) And I am at a loss as to what gigE switch and router we should use. The requirements are: 1. ability to morph the topology at will 2. fast (doh!) 3. Layer 1-4 is required (up to layer 7 would be nice) 4. load balancing Which companies' products do you like? (*Barring* Cisco) [If you cannot state your opinion publicly, please send me a private reply. I appreciate it and will keep it confidential.) I am looking at these companies: Lucent Foundey Networks River Stone Alteon Extreme Networks Ericcson Would the people who have had experience with these products tell me what they feel? Thank you very much. Michael -- +-----------------------------------------------------------+ | keichii(a)iteration.net | keichii(a)freebsd.org | | http://iteration.net/~keichii | Yes, BSD is a conspiracy. | +-----------------------------------------------------------+

4 3

RE: opinions on routers/switches for parallel clusters
by Dee McKinney 18 Jun '01

18 Jun '01

fairly sheltered life i'd say :) -----Original Message----- From: Albert Meyer [mailto:albert@waller.net] Sent: Monday, June 18, 2001 8:54 AM To: Michael C . Wu; nanog(a)nanog.org Subject: Re: opinions on routers/switches for parallel clusters Having dealt with Lucent I can warn you away from them (as if I need to nowadays). Having dealt with Cabletron I can warn you away from Riverstone. The only company you mention which has consistently provided excellent products and support (and never screwed me around or lied to me) is Cisco. Their stuff is a bit overpriced, but <cliche> you get what you pay for. </cliche> At 11:15 AM 6/18/01 -0500, keichii(a)freebsd.org wrote:

1 0

Re: standards for giving out blocks of IP addresses
by Charles Scott 18 Jun '01

18 Jun '01

On Sat, 16 Jun 2001, David R Huberman wrote: > Either you're saying it wrong (writing it wrong, as it were) or you are > misunderstanding RFC2050. > > ISPs *should* request 80% utilization of a block assigned to an end-user > prior to assigning additional address space. > > You understand that, right? On Sat, 16 Jun 2001 up(a)3.am wrote: > It's not really a question of what makes sense, it's what you need to do > to keep ARIN happy. As an ISP, if you only apply the 25% / 50% rule to > your customers, how are you supposed to demonstrate 80% utilization to > ARIN when requesting any kind of allocation? > > If you've handed out a whole bunch of /24 - /29 subnets to your > customers and they are compliant with RFC2050, this could well result > in a situation where you've depleted nearly all of your address space, > yet are nowhere near 80% utilization or your, say, /21 from your > upstream. Is ARIN going to allocate you a /20? David: Sorry, but nope, I don't understand it that way. Perhaps we need to properly define utilization. To an ISP, this means assignment of address space via SWIP to customers. ARIN wants you to have "assigned" 80% of your address space before asking for another allocation. To an end user, it means active hosts. ARIN suggests following RFC2050 and the 25%/50% standard prior to receiving an additional address assignment from their ISP. You, the ISP, are obligated to have justification using RFC2050 as the standard for assignements to your customers. ARIN requires you to have assigned 80% of your allocation to those customers prior to receiving additional allocations and may want to review the justification you've received from your customers. So, yes, it's very likely that when you have assigned 80% of your allocation, the sum of all your customer's utilization may be something like 50%. Judging from the confusion on this issue, I'm not surprised that some customers have a hard time getting assignments from their ISP's. This is even more confusing when the customer is both an end user and a downstream ISP themselves. In that case, it may make sence to consider the address space they use themselves as a separate assignment from them to themselves. That way you can properly determine when they have reached 80% assgnment of their space. If they aren't in turn assigning address space, then they are simply an end user and should be following RFC2050. Does this all make sence? Chuck

3 11

Re: standards for giving out blocks of IP addresses
by Charles Scott 17 Jun '01

17 Jun '01

Joshua: So what you're saying is that if I want to find out what the policy is, that I shouldn't bother going to the RIR's web site for any guidance. And, should I do that and actually bother to read the information they supply, I should ignore it because it doesn't mean anything since all that counts is what the "insider" of the day says it should be. And, if they refer to an RFC (yes I know what that stands for) then I shouldn't bother to look it up and read it, because it's only a suggestion and, "we don't really do things that way anyway". With all due respect, it's exactly that kind of situation that causes problems. Now I think I understand...somehow it's all starting to make sence. Chuck On Sun, 17 Jun 2001, Joshua Goodall wrote: > > On Sat, 16 Jun 2001, Charles Scott wrote: > > > On Sat, 16 Jun 2001, David R Huberman wrote: > > > > > - Both are judged to have used their existing assignment 'efficiently' if > > > they have used 80% of it. > > > > Nope. But I give up. > > As a multiple LIR operator and one-time RIR insider, I can say that david > is correct with regard to policy in practise, and *that* is what matters. > > 2050 does not address issues relevant to a hierarchy of IRs and for this > (and other, more human) is only useful as a historical base for > understanding RIR policy. > > Beware the RFC lawyers who've forgotten what the letters "RFC" stand for. > > J

2 2

RE: standards for giving out blocks of IP addresses
by Martin, Christian 16 Jun '01

16 Jun '01

> Of course bandwidth != subnet mask. He should give them > whatever IP's > they demonstrate a need for in the next three months. Determining and > justifying that > need has nothing to do with how over (or under) subscribed their > bandwidth is. Let us not forget what some salespersons will promise to potential large bandwidth customers. An OC-3 POS customer, for example, can expect many many /24s. One may say "They should go to ARIN", but alas, they would have to pay another $2500 on top of the $1 million+ they are paying for transit. <8{} It is surprising how much a salesperson will "sell" to get the commission on a 5 year OC-3 contract, forget about OC-12/48... So, in some cases, like it or not, bandwidth sold is proportional to IP addresses. chris > > If they are in fact only selling dialup (not leased lines, not web > hosting), > you might ask how many pops(locations) they plan to have right away, > modems/pop, space > reserved for internal devices (email/corporate lan) and links. You > could > easially justify a couple of /24's with a couple locations > and IP's for > all the new PC's in the marketing dept. > > KL >

5 6

The Cidr Report
by Tony Bates 16 Jun '01

16 Jun '01

This is an auto-generated mail on Fri Jun 15 23:00:00 PDT 2001 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 GX Networks 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 15Jun01 0) General Status Table History ------------- Date Prefixes 080601 102522 090601 102942 100601 102382 110601 102484 120601 102300 130601 102055 140601 101900 150601 101429 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 6880 Number of ASes announcing only one prefix: 2796 (0 cidr, 2796 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1403 announced by AS701 1) Gains by aggregating at the origin AS level --- 15Jun01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1392 1032 360 25.9% UNKNOWN AS701 1403 1217 186 13.3% UNKNOWN AS4293 396 281 115 29.0% UNKNOWN AS4151 252 137 115 45.6% UNKNOWN AS4755 256 142 114 44.5% UNKNOWN AS6429 207 102 105 50.7% UNKNOWN AS6595 159 59 100 62.9% UNKNOWN AS705 251 155 96 38.2% UNKNOWN AS13999 103 11 92 89.3% UNKNOWN AS8013 300 222 78 26.0% UNKNOWN AS577 254 179 75 29.5% UNKNOWN AS7018 700 628 72 10.3% UNKNOWN AS724 223 159 64 28.7% UNKNOWN AS6471 114 50 64 56.1% UNKNOWN AS3464 152 90 62 40.8% UNKNOWN AS1 597 538 59 9.9% UNKNOWN AS16758 63 6 57 90.5% UNKNOWN AS2149 333 277 56 16.8% UNKNOWN AS1239 439 384 55 12.5% UNKNOWN AS3908 207 154 53 25.6% UNKNOWN AS226 143 90 53 37.1% UNKNOWN AS6413 66 14 52 78.8% UNKNOWN AS5106 95 43 52 54.7% UNKNOWN AS17561 112 61 51 45.5% UNKNOWN AS3602 229 179 50 21.8% UNKNOWN AS13544 69 19 50 72.5% UNKNOWN AS9842 54 5 49 90.7% UNKNOWN AS852 209 160 49 23.4% UNKNOWN AS855 144 98 46 31.9% UNKNOWN AS3749 94 48 46 48.9% 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

Multicast Traffic on Backbones
by Deepak Jain 16 Jun '01

16 Jun '01

Don't know why I came across this, but I found a document on Sprintlink's site that says their entire backbone is multicast enabled, and they also peer with the MBONE for multicast traffic. They charge no fee for dedicated customers to be multicast-enabled. Are any other major networks doing this? Or have I been living under a rock and _everyone_ is doing this now? Thanks, Deepak Jain AiNET

20 37