July 1997 - Test - lists.nanog.org

RE: Usage Stats
by George Broadfoot 22 Jul '97

22 Jul '97

Webtrends at www.webtrends.com is what I consider to be an outstanding product (I NO NOT WORK FOR THEM). It runs on 95 or NT and can pull logs from any OS that it can get the server access logs from. The access can be via ftp, HTTPD, network login and I think some other ways. It is very inexpensive (I think around 400.00) - We have used it for about 2 months - think it is one of our best buys. -----Original Message----- From: Shaun S. Amini [SMTP:samini@diginetusa.net] Sent: Monday, July 21, 1997 10:55 PM To: nanog(a)merit.edu Subject: Usage Stats We have created our own home grown tools to provide utilization stats for clients. Is there a real product out there that can handle the task properly? Preferably one that runs on the NT platform. Shaun

3 2

Greg: get it right.
by Jay R. Ashworth 22 Jul '97

22 Jul '97

Apologies to the list; this will be the final posting you see on this topic. Greg: the system is valid, verifiable, and has an A record. If that's not good enough for you, sign off now. -----Forwarded message from Mail Delivery Subsystem <MAILER-DAEMON>----- On Mon, Jul 21, 1997 at 07:06:58PM -0400, Greg A. Woods wrote: > > get a real mailer. > Oh oh! Trouble down there in Florida making you cranky Jay? ;-) Nope. People who don't read the RFC's. :-) > Thanks for your voicemail message -- sorry I couldn't answer directly as > I've been keeping the line open to a customer who's brand new T1 is down > and out and there's lots of finger pointing going on.... I'm hip. > FYI here's the log entry may mailer records when this sort of thing > happens (this example from your most recent attempt): Yeah, this time, as noted, I got the reply myself. > 07/21/1997 17:37:16: remote MAIL FROM: '<jra(a)scfn.thpl.lib.fl.us>SIZE=3395' target 'scfn.thpl.lib.fl.us' is not a valid domain (no MX record); by jra(a)scfn.thpl.lib.fl.us [204.198.80.3]. > > The '<jra(a)scfn.thpl.lib.fl.us>SIZE=3395' is exactly what was sent by > "your" mailer as the parameter for the "MAIL FROM" SMTP command, and the > reason for the rejection is because the target 'scfn.thpl.lib.fl.us' > doesn't have an MX. ("jra(a)scfn.thpl.lib.fl.us [204.198.80.3]" is the > results of the PTR lookup and an IDENT query.) > > And nope, I'm not going to change this -- I'm doing it on purpose! ;-) > (and I know full well what I am doing in this case since I wrote the > code to do it this way and the requirements I set out to fulfill have > been met! ;-) Except that you forgot that an MX record isn't necessary. An A record works nicely... and there _IS_ one of those. > Yes this is draconian, but it helps immensely at rejecting spam and it > rarely rejects any legitimate mail (except from sticks-in-the-mud like > the folks at PSU.EDU who don't seem to have ever heard of MX records and > folks such as yourself who haven't yet run across this). I receive > hundreds of messages per day, and others using similar mail > authorisation rules receive thousands or even tens of thousands of > messages per day. This form of authorisation is spreading to more and > more mailers too -- I understand that even sendmail can do it, and from > what I've heard aol.com has enabled such rules and Brad Knowles himself > advocates enforcing such checks. To quote a tiny portion of private > e-mail that he sent to me just before he decided to cut off all > discussion with me (I'm now privileged to be in his >/dev/null list! ;-): Don't misunderstand me; I salute your intent. Just do it _correctly_. :-) And note that you shouldn't validate the sender address until you have a recipient address. Mail addressed solely to "postmaster" has to be deliverable anyway, or you violate RFC 822. > He wasn't talking explicitly about requiring a valid MX for the sender > address, but I think you'll see the direction he seemed to be going in. Certainly; he was talking about verifying the existence of the sender. MX records are optional, and therefore inspire false negatives of this sort. > > > Your DNS is rather sparse of MX records. You might want to add at least > > > the following as well: > > > > > > thpl.LIB.fl.us. MX 1 scfn.thpl.lib.fl.us. > > > scfn.thpl.LIB.fl.us. MX 1 scfn.thpl.lib.fl.us. > > > > > > Either that or use a return address of <jra(a)ns1.thpl.lib.fl.us> > > > (i.e. the "MAIL FROM:" address given in the SMTP envelope). > > > > The return address you should have had was "jra(a)baylink.com". > > baylink.com MX's to scfn.thpl.lib.fl.us, which is an A record. > > Yes, that would have worked A-OK, but perhaps you're thinking of the > RFC-822 "Reply-To" address whereas I'm talking about the SMTP envelope > sender address. If you got an envelope address of ns1, then we have a mail routing problem on outbounds of which I wasn't aware. > Hopefully we can get this sorted out amicably -- I can't bend on my rule > to require an MX for sender addresses, but I may think about adding an > exception list to allow friends to break the rules (until they see clear > to fixing their DNS! ;-). Unless you can come up with a valid explanation why simply an A record isn't enough, I think you'll have to bend your rule to avoid violating the RFCs. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592 --JAA28200.869579680/scfn.thpl.lib.fl.us-- -----End of forwarded message----- -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592

1 0

Re: DC fiber cut: field report
by Sean M. Doran 22 Jul '97

22 Jul '97

| The impression I get is that the protection circuit is intended to | cover failures that take out a single circuit. When talking about "protection circuits", bear in mind that this is all legacy PDH stuff which hopefully soon will be dead. An STM-1, for example, can be made fault-resistant by virtue of SDH's ring architechture. Any PDH payload encapsulated in the STM-1 consequently will be immunized against backhoe fade, failed optics and the like. Obviously a failure that SDH's mechanisms can't prevent will require any encapsulated traffic to be rerouted through non-SDH means. With IP, this is simple: you see a circuit failure, and change your routing tables in the normal way. With many VC-based networks you tear down all sorts of VCs and try to build them over other paths, updating your switching tables in the normal way. Finally, with things that are reliant on PDH protection, you wait for them to fall over onto protection circuits, which are laid out in different STM-1s, ideally along completely different physical paths. In other words, in the event of a failure that SDH cannot cope with, you either overscribe other in-use capacity or you make use of stand-by capacity that is otherwise completely unused. Completely unused capacity is expensive, and you already have quite a bit of it if you build SDH rings (half, in fact). Adding more unused capacity to support unlikely failures is unattractive. However, most failures that SDH cannot cope with tend to be very rare. I would be surprised, for example, if the fibre cuts in the U.S. affected SONET-ring-carried traffic, and I would be surprised if a PDH protection circuit scheme would provide much faster recovery in the cases where SDH/SONET failed. Of course, if the lines that failed were, in fact, not PDH, I'd appreciate a private word about this. :) | For example, if you | had 10 fibers in a system and a repeater or laser died, then only | one of your fibers stops working. Fixing that with a protection | circuit adds 1/10 to the system cost. Um, huh? If you have a fibre stop working then all the data traversing that fibre stops. If you have an SDH ring, you don't really care, because along the segment between the two MUXes at either eind, you have a second fibre that likely remains working. If you have protection circuits you have to deal with DAXCs and the like and you have to have the protection circuits provisioned along another fibre and standing idle. PDH protection switching is slow and ugly, but it allows fall-back connectivity to be oversold or not provisioned in the first place. That is, you can sell people "cheapo" circuits which have no backup, and even more, circuits which will fail when an unrelated circuit used by a customer buying an expensive circuit fails. | (Maybe less if you have spare | fibers in the ground.) Fixing it with SONET ring technology roughly | doubles the system cost. If you have spare fibres in the ground, light them up to protect your primary SDH paths. Even if you use another pair of fibres runnning through the same conduit, you do protect against failed optical and electrical equipment (repeaters, lasers, fibre tips, people unplugging the wrong thing, and so on). You don't need an additional MUX, you don't need extra DAXCs, and you don't need to scurry around reprogramming lots of equipment when someone wrecks your fibre. Sean.

1 0

Dren/Dod noc address?
by Naiming Shen 22 Jul '97

22 Jul '97

Any one got an email address for Dren/DoD Noc? Since the "noc-to-noc communication" does not work well here, I figured I might get some luck in this group. thanks. ------------------------------------------------------------------- - Naiming Shen MCI - MCI Internet Engineering 2100 Reston Parkway - +1 703-715-7056 fax: 703-715-7066 v272-7056 Reston, VA 20191

2 1

RE: is there a market for this?
by jan.novak＠aliatel.cz 22 Jul '97

22 Jul '97

Cisco calls their busses CxBus, CyBus which have the same clockrate (something about 22 MHz) but differs with the "largeness" of 32 and 64 bits and uses them for transport among different modules. The PCI is used only internaly on the same module. ---------- Od: Jacques Vidrine[SMTP:nectar@staff.communique.net] Odesláno: 22. července 1997 2:36 Komu: 'Jeremiah Kristal'; Chris Wilson Kopie: Perry E. Metzger; nanog(a)merit.edu Předmět: RE: is there a market for this? FWIW, I can't confirm this at this second, but I believe that at least the cisco 7200 series routers have a three PCI bus backplane. And it is claimed to support an OC-3c VIP2 port adapter, although I haven't put mine in action to try yet (and when I do I won't be running anywhere near 155 Mbps anyway). A single VIP2 port adapter can only connect to one of the three buses, so presumably cisco believes that PCI is up to the task. I don't know what the clockrate is, and I don't know if it is 32-bit or 64-bit. > -----Original Message----- > From: Jeremiah Kristal [SMTP:jeremiah@corp.idt.net] > Sent: Monday, July 21, 1997 5:40 PM > To: Chris Wilson > Cc: Perry E. Metzger; nanog(a)merit.edu > Subject: Re: is there a market for this? > > On Mon, 21 Jul 1997, Chris Wilson wrote: > > > Actually, I've seen a PCI-based box doing 15MByte/sec sustained > read/write > to disk, so it is possible to do it, but it's not likely to be > standard > for quite a while. I certainly think that an OC-12 card would be > overkill > though. I'm also wondering why someone who can afford an OC-x would > be > trying to save a couple bucks by using a PCI-based router. > Once you get into this type of bandwidth, I think a bus becomes a > serious > chokepoint. > >

1 0

RE: is there a market for this?
by jan.novak＠aliatel.cz 22 Jul '97

22 Jul '97

There are ATM cards on the level of OC3/OC12 for PCI, SBus... But they have usually their own i960 for SAR functions and originate a interupt only when have cell to transfer over internal bus, not with every byte accepted on input. ---------- Od: Raymond Wong[SMTP:negativl@netcom.com] Odesláno: 21. července 1997 18:44 Komu: nanog(a)merit.edu Předmět: Re: is there a market for this? The discrepancy is caused by the same limitation that allows the old PC-ISA bus to handle a theoretical 8(?16?)) Mbytes, but start to choke long before a rs232 serial port reaches 115kbps. It's not the processor or the bus, it's the number of interrupts the serial connection is generating. Move away from interrupts, increase the amount of data per interrupt, or whatever, and the limits increase. Doing it at the T level on PCI is just a matter of scale from the 232 level on old PCs with ISA. Discussing raw bandwidth just misses the point. That's my immediate reaction, anyway. Does anyone actually know better how this all works, or are we going to read another 3 days of hearsay?

1 0

Re: is there a market for this?
by Matthew James Gering 22 Jul '97

22 Jul '97

>On Mon, 21 Jul 1997, Chris Wilson wrote: > >> handled over the PCI bus, and there's a company that makes T1/T3-level >> serial cards for PC's, and from what they were saying, there's no way to >> reach even a full T3 worth of bandwidth on a PCI bus, so I think trying to >> push an OC-# connection over it might be pushing it a bit ;) Well that gives one a lot of confidence in their product, doesn't it ;-). Tandem's SAN adapters operate at 900Mbps full duplex per node on a single standard half-size PCI card, so I expect they are sorely mistaken. Tandem ServerNet PCI Adapter (SPA) http://www.tandem.com/prod_des/sntpcipd/sntpcipd.htm Tandem ServerNet (SAN) Architecture http://www.tandem.com/prod_des/srvnetpd/srvnetpd.htm Matt

1 0

Re: DC fiber cut: field report
by Hal Murray 22 Jul '97

22 Jul '97

> The story that I have heard is that some providers have 1 (one) > protect circuit to cover many primary circuits... You loose too > many primary and limit number of protect circuits can't get them > all. > --asp(a)partan.com (Andrew Partan) I'm not a TELCO wizard. The impression I get is that the protection circuit is intended to cover failures that take out a single circuit. For example, if you had 10 fibers in a system and a repeater or laser died, then only one of your fibers stops working. Fixing that with a protection circuit adds 1/10 to the system cost. (Maybe less if you have spare fibers in the ground.) Fixing it with SONET ring technology roughly doubles the system cost. A protection circuit doesn't help if your problem is backhoes.

1 0

Re: question about per. hack
by Paul A Vixie 22 Jul '97

22 Jul '97

> Paul A Vixie wrote: > > i asked all the root name servers about PER. this is what they said: > > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 > > ok, so the same is true of nasa.com. all the roots return NXDOMAIN > (except J.ROOT-SERVERS.NET) and yet many nameservers > (presumably not running the fixed bind) return NOERROR for it. yes. > so slowly Im realizing that whoever is doing this must be > contacting each and every nameserver individually and > giving them bad data. is this true? yes, that is what alternic is doing. they are sending queries about their own names to every nameserver they can learn about, and then when the victim queries alternic's nameserver they get back bogus additional data. older name servers (older than 4.9.5-P1, really, but 4.9.6 and 8.1.1 are the current versions so those are the ones you should upgrade to) ignore the bogus additional data. > has anyone documented exactly how all this has played out in > the last week. it seems like there is a lack of public discussion > on just how bad what the alternic is doing is... i think this is the first time. i'm cc'ing NANOG since several folks there are wondering exactly why i think the FBI should get involved and why i think eugene kashpureff should be jailed. (i have the packet traces to prove all of the above, from multiple servers.) what i'm terribly confused about is why MCI won't just cut them off. what alternic is doing is a violation of MCI's AUP, as well as of law and morality.

8 10

RE: is there a market for this?
by Jacques Vidrine 22 Jul '97

22 Jul '97

FWIW, I can't confirm this at this second, but I believe that at least the cisco 7200 series routers have a three PCI bus backplane. And it is claimed to support an OC-3c VIP2 port adapter, although I haven't put mine in action to try yet (and when I do I won't be running anywhere near 155 Mbps anyway). A single VIP2 port adapter can only connect to one of the three buses, so presumably cisco believes that PCI is up to the task. I don't know what the clockrate is, and I don't know if it is 32-bit or 64-bit. > -----Original Message----- > From: Jeremiah Kristal [SMTP:jeremiah@corp.idt.net] > Sent: Monday, July 21, 1997 5:40 PM > To: Chris Wilson > Cc: Perry E. Metzger; nanog(a)merit.edu > Subject: Re: is there a market for this? > > On Mon, 21 Jul 1997, Chris Wilson wrote: > > > Actually, I've seen a PCI-based box doing 15MByte/sec sustained > read/write > to disk, so it is possible to do it, but it's not likely to be > standard > for quite a while. I certainly think that an OC-12 card would be > overkill > though. I'm also wondering why someone who can afford an OC-x would > be > trying to save a couple bucks by using a PCI-based router. > Once you get into this type of bandwidth, I think a bus becomes a > serious > chokepoint. > >

3 2