- Test - lists.nanog.org

Mass de-aggregation?
by Grant A. Kirkwood 09 Mar '04

09 Mar '04

Has anybody noticed a dramatic (~10k prefixes) jump in the routing table size? I'm getting about 10k more routes from all of my transits (3549, 2914, 6453) than I was yesterday. Cheers, Grant -- Grant A. Kirkwood - grant(at)tnarg.org Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED

2 1

Re: Verification required for steve@blueyonder.co.uk, protected by 0Spam.com.
by Michael.Dillon＠radianz.com 09 Mar '04

09 Mar '04

>> This is the future of e-mail, if something better at spam suppression >> doesn't come along. >Pace en requiat email Please! Spare us the fractured Latin. Requiescat in pace - May he/it rest in peace. Requiescat - 3rd person singular subjunctive of "requiescere" in - same as English preposition "in" pace - ablative singular of "pax" indicating that in refers to position rather than movement. Personally I think you should have said Requiescas in pace o email which means "Oh email, may you rest in peace"

3 2

Re: Verification required for steve@blueyonder.co.uk, protected by 0Spam.com.
by James Edwards 09 Mar '04

09 Mar '04

NO ! On Mon, 2004-03-08 at 05:52, verify(a)0spam.com wrote: > ATTENTION! > A message you recently sent to a 0Spam.com user with the subject "Re: Source address validation (was Re: UUNet Offer..." was not delivered because they are using the 0Spam.com anti-spam service. Please click the link below to confirm that this is not spam. When you confirm, this message and all future messages you send will automatically be accepted. > > http://www.0spam.com/verify.cgi?user=1079785893&verify=568107 > > > ======================================== > This is an automated message from 0Spam.com. > Please do not reply to this Email. > > Looking for a free anti-spam service? > Visit us at http://www.0spam.com to find out more.

8 8

Discussion Group: Web Based tool for tracking circuits
by Marius Strom 09 Mar '04

09 Mar '04

Hrm, sent several hours ago and still hasn't had nanog. Resending in-case it got snarfed by hungry routers on the intarweb. ----- Forwarded message from Marius Strom <marius(a)marius.org> ----- Date: Mon, 8 Mar 2004 16:36:14 -0600 From: Marius Strom <marius(a)marius.org> To: nanog(a)merit.edu Subject: Discussion Group: Web Based tool for tracking circuits Mail-Followup-To: nanog(a)merit.edu Ok, I've created a "carrier-neutral" mailing list on yahoogroups to house people who are interested in such a system. Interested developers and such should subscribe to cktid(a)yahoogroups.com. We can start discussions on what's out there, how to integrate things, possibly create a sourceforge project, etc. It seems everyone wants one, but no one's got one completed (other than Excel spreadsheets). On Mon, 08 Mar 2004, william(at)elan.net wrote: > Several commercial ip allocation systems exist (cost thousands, I came > across couple of them but did not keep list). The closest opensource on > this is freeipdb (http://www.freeipdb.org) but its not very feature-rich. > The IRM project (which I've never heard about until I just demod it right > now), comes much closer to what maybe needed and it does seem like it can > be converted to serve ISP allocation needs somewhat easily and is quite > extensible for shared enviroments, but in any case, such project needs to > be done right, i.e.: > 1. Creating mail list and first discussing and list of goals and features > we want in this system. > 2. Looking at existing project to see which can feets best or parts of which > of which projects can possible be combined together > 2. Creating sourceforge (or other) project and assiging features to be > implemented to developers. > Etc. > > If others are interested lets get together to work on it. I'm willing to > help in possible support for rwhois server or automated swips to arin and > some other back-end support where I have some experience I'm guessing > that at least half a dozen people need to get involved and be willing to > spend some of their time (perhaps 10 hours/month) for this to come through > and most need to be php web developers if IRM is to be used as origin. > > If I receive favorable response privately about it and enough people are > willing to spend their time on it, I'll let you know about what the project > development webpage would be (i.e. sourceforge most likely) ----- End forwarded message ----- -- /-------------------------------------------------> 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 |-------------------->

1 0

[Fwd: [alex@yuriev.com] Confirmation of your message requested]
by Laurence F. Sheldon, Jr. 09 Mar '04

09 Mar '04

quote Your message to <alex(a)yuriev.com> was intercepted by an automated spam reduction system based on TMDA. This happened because your address has not been previously verified as one used by a human, as opposite to a bloody idiot-spammer. In order to reduce the amount of junk mail received by <alex(a)yuriev.com>, only messages from verified addresses are released for delivery. unquote If you are not going to accept mail from me, do not send mail to me. Do no spam mw with this crap in any case.

3 4

TELUS contact?
by Adam Clark 08 Mar '04

08 Mar '04

Does anyone know of a Network admin contact at Telus? Have been trying to reach them for a week, but have had no human response. Thanks, -- Adam Clark

1 0

[ralden@ralden.com: FW: Web Based tool for tracking circuits]
by Marius Strom 08 Mar '04

08 Mar '04

----- Forwarded message from "Roland H. Alden" <ralden(a)ralden.com> ----- Date: Mon, 8 Mar 2004 10:04:13 -0800 From: "Roland H. Alden" <ralden(a)ralden.com> To: Marius Strom <marius(a)marius.org> Subject: FW: Web Based tool for tracking circuits Return-Path: ralden(a)ralden.com I guess I'm not allowed to post but here is something I sent for your info. -----Original Message----- From: Roland H. Alden Sent: Monday, March 08, 2004 8:37 AM To: nanog(a)merit.edu Subject: RE: Web Based tool for tracking circuits > If there is, let me know. I started to work on one a couple > of years ago, I could dust off the project. Same here. I haven't got time to dust off my project but I would gladly contribute what I have to someone else; basically a complex SQL schema with some queries, constraints and triggers done and/or partially baked. My model was as follows: A location hierarchy tunable to whatever resolution was of interest; i.e., City:Facility:Floor:Rack etc. A very complex model for pieces of equipment; i.e. chassis, blades within chassis, physical ports on blades. Ports themselves are modeled with data about their connectors (i.e., RJ45 male/female, DB9 male/female, etc.). A model of special "ports" which are status indicators like LEDs, what their exact equipment labeling is, and what colors and what not they might normally be. I.e., information of value when walking some remote hands through a troubleshooting procedure. A model for port-specific configuration so that the database can "know" that port x13 on such an such an ethernet switch is connected to VLAN 3, etc. A model for what ports should be physically connected to what ports. A necessary list of cables can then be generated automatically; connector specs and unique cable ID's are generated. A database of common connectors and their "opposite sex" is part of the model. The system does not take advantage of any understanding of how far apart ports are to suggest a cable length, but once a cable table is generated that can be added by hand so that the information is captured. A "fanout" cable model accomodates single cables that connect more than two ports. A power model that records how much heat is generated by each device and how much power of what flavor it consumes. A circuit model similar to the cable model (port:circuit:port) but accomodates "tunnels" such as a ds1 inside a ds3, or a VPN tunnel. A "noc contact" record can be associated with a particular circuit and the contractual details of a circuit (such as SLA) can also be recorded. A unique circuit ID is generated and a vendor's circuit ID can be recorded as well. Equipment configurations (and history of them) is stored within each item of equipment. However, there is no sophisticated linkage or syntax checking between the equipment model and the configuration and there is no way to automatically push a configuration to its equipment. Documents such as PDF files of equipment manuals or contracts can be attached to various items like equipment records, circuit records, etc. However this does require "blob" support and in my implementation is all MSFT specific code. A somewhat badly implemented fine-grained security model so that various views show only the rows a person was allowed to see and/or edit. My notion was that the system would be used across handoff boundaries but I didn't exactly get that far. FWIW. ----- End forwarded message ----- -- /-------------------------------------------------> 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 |-------------------->

1 0

Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
by Paul Vixie 08 Mar '04

08 Mar '04

> After all these years, perhaps its time to re-examine the assumptions. it's always fun and useful to re-example assumptions. for example, anyone who assumes that because the attacks they happen to see, or the attacks they hear about lately, don't use spoofed source addresses -- that spoofing is no longer a problem, needs to re-examine that assumption. for one thing, spoofed sources could be occurring outside local viewing. for another thing, spoofed sources could be "plan B" when other attacks aren't effective. the last thing is, this is war. information warfare. the enemy knows us better than we know them, and their cost of failure is drastically lower than our cost of failure. don't be lulled into some kind of false sense of security by the fact that YOU are not seeing spoofed packets TODAY. let's close the doors we CAN close, and give attackers fewer options.

12 30

FCC Internet Policy WG to hold VoIP 911/E911 summit on March 18th, 2004
by John Curran 08 Mar '04

08 Mar '04

<http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-243851A1.pdf> "On Thursday, March 18, 2004, the FCC¹s Internet Policy Working Group (IPWG) will hold the first in a series of a ³Solutions Summits² at which leaders in government and industry can discuss creative ways to address policy issues that arise as communications services move to Internet-based platforms. The initial meeting will focus on 911/E911 issues, and on the particular challenges and opportunities created for emergency services in expanding 911/E911 access to VoIP users and increasing the use of IP technologies in emergency services networks" This will be one of the first public discussions of 911/E911 issues for VoIP which includes both public safety and US telecomm regulatory officials. /John PS. My apologizes to those folks whose SMS or RJE gateways were hung up by my earlier mime-formatted version of this email... Nationalistic, 7-bit, discard-the-encoding-and-be-PINE-friendly used above instead.

1 0

Re: Source address validation (was Re: UUNet Offer New Protection
by Gregory Hicks 08 Mar '04

08 Mar '04

> From: Paul Vixie <vixie(a)vix.com> > Date: 08 Mar 2004 06:35:16 +0000 > > > ken(a)kdmd.net (Ken Diliberto) writes: > [...snip...] > > > > We're now blocking all SMTP traffic leaving the campus from non-blessed > > sources (read mail servers). The first day doing this we had comments > > about less junk mail traffic. We block traffic we consider harmful that > > shouldn't leave the campus. We're trying to do our part. > > > > Any suggestions how we can do better? > > yes. contact the nanog program committee so you can come to san francisco > and tell the rest of us how you did it -- both in the ones and zeros, and > in the dollars and cents. Paul: This is MY take and not Ken's... Firewall: block port 25 from all internal hosts except those 'recognized' as mail servers. For a user or department to get a mail server set up and 'recognized', they probably have to go through some sort of "qualification" and scanning process to ensure that the mail host is configured correctly... Going to San Francisco is still a good idea though. Regards, Gregory Hicks > -- > Paul Vixie --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3479 San Jose, CA 95134 | Internet: ghicks(a)cadence.com I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. "A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision." - Benjamin Franklin "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton

1 0