- Test - lists.nanog.org

Qwest fiber cut in dallas?
by Daniel F. Chief Security Engineer - 08 Apr '02

08 Apr '02

Qwest fiber cut in dallas? Has anyone head any thing. I heard this from an unconfirmed source. thanks -- Chief Security Engineer | Daniel Fairchild danielf(a)supportteam.net GCS d- s++:++ a- C++ UL++++ P+++ L+++ E--- W++ N++ o+ K- w+ O M- V PS+ PE Y+ PGP+ t 5+ X-- R+ tv b++ DI++ D

1 0

Best provider to use ?
by internetguy205＠hotmail.com 08 Apr '02

08 Apr '02

Out of the Tier 1s who is the best to use ? Thanks.

9 8

RE: Checkpoint is down...
by Steve Smith 08 Apr '02

08 Apr '02

Me too. -----Original Message----- From: Ian A. Finlay [mailto:iaf@cert.org] Sent: Monday, April 08, 2002 9:35 AM To: Pascal Gloor; nanog(a)nanog.org Subject: Re: Checkpoint is down... They are up from my perspective. -Ian --On Monday, April 08, 2002 3:03 PM +0200 Pascal Gloor <pascal.gloor(a)spale.com> wrote: > > Anyone knows what's going on with www.checkpoint.com ? I urgently need > 'SecuRemote', could anyone send me sr-w2k-4185-strong.exe ? > > Thanks, > Pascal >

1 0

ANN: 0.1-final release of Panoptis DoS/DDoS detection software
by Constantinos A. Kotsokalis 08 Apr '02

08 Apr '02

Hello all, first of all I would like to thank everyone who downloaded and tested the beta-5 version of Panoptis. After killing that last bug (which was still in beta-5, contrary to my belief) the first stable release (0.1) is out. I have it running for 5 days, it works like a charm. You can download it from: http://prdownloads.sourceforge.net/panoptis/panoptis-0.1.tar.gz Please keep in mind that: 1. The peer module (thread) is not activated yet, it needs testing. However, that does not affect a node's ability to detect attacks. 2. The NetFlow V8 code has not been tested *at all*. It probably isn't working correctly. V1 and V5 should be ok. 3. Unfortunately it is still working only on Linux (tested on kernel 2.4.x, glibc 2.2.x). The ports to Solaris and FreeBSD are still worked on. 4. I can make no promises as far as its effectiveness is concerned. It is working fine for me at the moment though. If you try it and find any problems, please let me know (ckotso(a)grnet.gr) I would also like to listen to ideas anyone may have, regarding future directions and implementation of new functionality. Thanks, Costas -- Constantinos A. Kotsokalis || ckotso(a)grnet.gr Greek Research and Technology Network Tel: +30 10 7474243 && Fax: +30 10 7474490

4 3

None
by David Barak 08 Apr '02

08 Apr '02

__________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

1 0

verio.net
by Ariel Biener 08 Apr '02

08 Apr '02

Hi, I need someone in a senior position at verio.net (if on the list) to contact me offlist, on something of a personal nature (no I am not looking for a job). --Ariel -- Ariel Biener e-mail: ariel(a)post.tau.ac.il PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html

1 0

Re: Perspective on ARIN allocations to non-American entities
by Brian Wallingford 08 Apr '02

08 Apr '02

:>I've searched the IANA and ICANN sites, and have found no justification :>for what appear to be ARIN allocations to foreign entities within :>66.231. :> :>Two serious UCE/hacking attempt offenders are as follows: :>66.231.64.0/20 GIGA-BLK-1 : : Last I checked, Columbia was part of South America. The 'A' in Arin means :America, the two continents. Granted, that was a poor example. :>66.231.128.0/20 ECON-BLK-1 Last I checked, France wasn't in either of the Americas. :> :>Both of which appear to be completely unapologetic for their users' :>activities and refuse to take any action against repeat offenders :>(10's of thousands of attempts per week here). Why have these blocks :>apparently been allocated via ARIN? :> :>Am I missing something? : : I'm not sure what you think ARIN has to do with UCE/hacking. ARIN allocates :IP addresses. The regional splitting of the registries is more for reasons of :convenience than anything else and I don't believe there's any special reason :ARIN should deny a request just because the addressees will be using the :block out-of-the region. (Though it is recommended that you use the registry :for your region.) Understood, and I certainly wouldn't expect that any given registry would presume to play policeman for the networks they've allocated. My only point was that one should be able to assume, based on network number, that a given prefix can be looked up via a given registry's database, and that the result should reflect an organization (or a branch of an organization) within that registry's region. : It is common for companies with a presence in multiple regions to deal with :a single regional registry and then use the blocks where they actually need :them. This is much better than them using two for a variety of reasons :including that it makes the registry better able to assess the justification. :So a multinational company might request all the blocks it needs through ARIN :and it's U.S. office. Again, understood. NTT/Verio, among others, is a good example of such. In such a case, the ARIN record should reflect the physical address, and other contact info for the given U.S. office, IMHO, not the foreign address, for what I would think are obvious reasons. Cheers, Brian

2 1

gtld-servers returning multiple A records for a NS?
by Matt Levine 08 Apr '02

08 Apr '02

When did this start? > dig uunet.com @a.gtld-servers.net ; <<>> DiG 8.3 <<>> uunet.com @a.gtld-servers.net ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4 ;; QUERY SECTION: ;; uunet.com, type = A, class = IN ;; AUTHORITY SECTION: uunet.com. 2D IN NS NS.UU.NET. uunet.com. 2D IN NS UUCP-GW-1.PA.DEC.com. uunet.com. 2D IN NS UUCP-GW-2.PA.DEC.com. ;; ADDITIONAL SECTION: NS.UU.NET. 2D IN A 137.39.1.3 UUCP-GW-1.PA.DEC.com. 2D IN A 16.1.0.18 UUCP-GW-1.PA.DEC.com. 2D IN A 204.123.2.18 UUCP-GW-2.PA.DEC.com. 2D IN A 16.1.0.19 Regards, Matt -- Matt Levine @Home: matt(a)deliver3.com @Work: matt(a)eldosales.com ICQ : 17080004 AIM : exile PGP : http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0D04CF "The Trouble with doing anything right the first time is that nobody appreciates how difficult it was." -BIX

10 14

RE: Load balancing in routers
by Gironda, Andre 08 Apr '02

08 Apr '02

> Does anybody know what are load balancing algorithms > by most routers ? Where can I more information about > this ? > > thanks > Abhi oh hey, does anyone on this list know how to make cars go faster for most makes/models? heh, j/k ;> you might want to check out rfc2991 and rfc2992. "most" routers are cisco routers, and they use cisco express forwarding for next-hop forwarding decisions along with ospf/isis/eigrp/bgp4/etc. this is commonly known as load balancing or load sharing or equal cost multipath (sometimes abbreviated as ECMP). cisco and other vendors have more information about how they do ECMP on their websites. I believe you can search their websites for even load balacing and come up with the information that you are looking for. if you are looking for source code that you can compile and play with, try zebra.org. -dre

1 0

RE: Qwest Support
by internetguy205＠hotmail.com 08 Apr '02

08 Apr '02

WOW. After going through the string of emails on this subject, it really amazes me that someone would bash someone else in regards to getting correct support. This appeared to be a legitimate need for support, & Regardless of the nature of the problem, as Mr. Urban suggests, quite correctly, this gentleman Mr. Dills could not get support when he required it, & was shuffled around. In fact, someone suggested that he would have had" greater sympathy " for this gentleman if he was really down. & if it had of been a legitimate routing problem, it would have been " more interesting ". Now, we all can understand with the state of the industry, that support response times & support in general might just be a bit stretched these days. But no sympathy, or would have had greater sympathy, come on. Infact, reading further emails, it appears that this gentleman, Mr. Dills DID have a routing issue. & once he lit into his provider, via NANOG, they did not like the exposure & quickly gave him some assistance. Now, NANOG is really not the place to b****, but if it works... Greater sympathy.... ?? More interesting if it was a routing problem... When it appears it was... Wonder if they treat their customers like that at Sockeye Networks. A customer is a customer, plain & simple. Dont tell him you will call him back in 30 minutes then shuffle him off. For a day. Regards. > -----Original Message----- > From: Gregory Urban [mailto:urban@cs.umbc.edu] > Sent: Friday, April 05, 2002 11:14 AM > To: Daniel Golding; nanog(a)merit.edu > Subject: RE: Qwest Support > > > > You totally missed the point. Had this been a real emergency, he > would be > unable to get resolution since Qwest was unable to dredge up a > clue within > their customer support machine. > > Greg U

2 1