June 2001 - Test - lists.nanog.org

Routing Table inconsistencies
by Marshall Eubanks 19 Jun '01

19 Jun '01

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

3 2

Re: opinions on routers/switches for parallel clusters
by Michael C . Wu 19 Jun '01

19 Jun '01

On Mon, Jun 18, 2001 at 11:15:10AM -0500, keichii(a)freebsd.org scribbled: Thank you all for your replies. Here is the result summed from the 21 emails that I received privately and publicly. It overwhelmingly leans towards one vendor. :) [Disclaimer: I am in no way associated with Extreme Networks.] BTW, just to clarify myself, we are not hostile towards Cisco. We currently use almost exclusively Cisco on our site. It's just that we did not think it to be necessary to be asking about a brand so well known to us and NANOG. Furthermore, we like to keep our minds open for other products. (There were people who suggested multiple choices.) Count Vendor ============================ 18 Extreme Networks (with load balancer being F5 Net) 4 Cisco 4 misc (Foundry, Riverstone) I also talked to the Extreme Networks sales engineer who responded to me in private. (I guess they know where to look for customers 8). ) She even offered a loaner before I asked. Extreme's pricing is at least less than half the Cisco price at retail, before mass purchase discounts. (The Cisco products also has less features at a higher price tag.) Adding in the extra load balancer and router costs, using Extreme is still extremely competitive in both price and functionality. -- +-----------------------------------------------------------+ | keichii(a)iteration.net | keichii(a)freebsd.org | | http://iteration.net/~keichii | Yes, BSD is a conspiracy. | +-----------------------------------------------------------+

1 0

Re: Opinions about InterNAP
by Avi Freedman 19 Jun '01

19 Jun '01

In article <101513.154547.12017(a)avi.netaxs.com> you wrote: : Filters depend on where you get your allocation. We got 216.249.16.0/20 : from arin. Since we're above the swamp, we have a greater chance of : having any given /24 not be filtered. Shortly after we got the : allocation, I announced a single /24, and could cleanly traceroute to : machines on that subnet from points behind sprint, verio, C&W, worldcom, : etc. Had we been given an allocation from 65/8 or another block in : former-class-A space, we probably would've had problems. You'd have to announce the /24 on a separate link and make sure traffic came back to it. Or, stop announcing the /20. Hope this isn't insulting, just make sure the test is good :) : -j Avi

1 0

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

18 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 18 Jun '01

18 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 18 Jun '01

18 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