Re: BitTorrent swarms have a deadly bite on broadband nets
On Mon, Oct 22, 2007 at 05:16:08PM -0700, Crist Clark wrote: It seems to me is what hurts the ISPs is the accompanying upload streams, not the download (or at least the ISP feels the same download pain no matter what technology their end user uses to get the data[0]). Throwing more bandwidth does not scale to the number of users we are talking about. Why not suck up and go with the economic solution? Seems like the easy thing is for the ISPs to come clean and admit their unlimited service is not and put in upload caps and charge for overages. [I've been trying to stay out of this thread, as I consider it unproductive, but here goes...] What hurts ISPs is not upstream traffic. Most access providers are quite happy with upstream traffic, especially if they manage their upstream caps carefully. Careful management of outbound traffic and an active peer-to-peer customer base, is good for ratios -- something that access providers without large streaming or hosting farms can benefit from. What hurt these access providers, particularly those in the cable market, was a set of failed assumptions. The Internet became a commodity, driven by this web thing. As a result, standards like DOCSIS developed, and bandwidth was allocated, frequently in an asymmetric fashion, to access customers. We have lots of asymmetric access technologies, that are not well suited to some new applications. I cannot honestly say I share Sean's sympathy for Comcast, in this case. I used to work for a fairly notorious provider of co-location services, and I don't recall any great outpouring of sympathy on this list when co-location providers ran out of power and cooling several years ago. I /do/ recall a large number of complaints and the wailing and gnashing of teeth, as well as a lot of discussions at NANOG (both the general session and the hallway track) about the power and cooling situation in general. These have continued through this last year. If the MSOs, their vendors, and our standards bodies in general, have made a failed set of assumptions about traffic ratios and volume in access networks, I don't understand why consumers should be subject to arbitrary changes in policy to cover engineering mistakes. It would be one thing if they simply reduced the upstream caps they offered, it is quite another to actively interfere with some protocols and not others -- if this is truly about upstream capacity, I would expect the former, not the latter. If you read Comcast's services agreement carefully, you'll note that the activity in question isn't mentioned. It only comes up in their Use Policy, something they can and have amended on the fly. It does not appear in the agreement itself. If one were so inclined, one might consider this at least slightly dishonest. Why make a consumer enter into an agreement, which refers to a side agreement, and then update it at will? Can you reasonably expect Joe Sixpack to read and understand what is both a technical and legal document? I would not personally feel comfortable forging RSTs, amending a policy I didn't actually bother to include in my service agreement with my customers, and doing it all to shift the burden for my, or my vendor's engineering assumptions onto my customers -- but perhaps that is why I am an engineer, and not an executive. As an aside, before all these applications become impossible to identify, perhaps it's time for cryptographically authenticated RST cookies? Solving the forging problems might head off everything becoming an encrypted pile of goo on tcp/443. Information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED] Someone toss this individual a gmail invite...please! --msa
Re: trans-Atlantic latency?
On Thu, Jun 28, 2007 at 06:20:31PM -0500, Neal R wrote: I have a customer with IP transport from Sprint and McLeod and fiber connectivity to Sprint in the Chicago area. The person making the decisions is not a routing guy but is very sharp overall. He is currently examining the latency on trans-Atlantic links and has fixed on the idea that he needs 40ms or less to London through whatever carrier he picks. He has spoken to someone at Cogent about a point to point link. Chicago to London: ~3950 mi New York to London: ~3470 mi c == 186,282 mi/sec (in a vacuum) 0.66 * c == 122,946 mi/sec CHI-LON: 32.128 ms NYC-LON: 28.224 ms That is one way, absolute best case, and the cables never run quite the way you want them to. If he's looking for 40 ms RTT, he is not going to get it. If he just needs 40 ms one way to London, it is possibly doable, even from Chicago. I couldn't readily find lengths for the individual segments of TAT-14, so as a representative example, we'll use TAT-12/13. From RI to the UK: 3,674 mi. ( 3674 / (0.66 * c) ) * 1000 == 29.883 ms, doubled for 59.766 ms RTT. Real world numbers seem to suggest many carriers run between 70 and 80 ms RTT from NYC to London, and I just measured around 100 ms RTT from Chicago to a host in the UK. --msa
NANOG39 PGP Key Signing
We will be running the keysigning sessions in Toronto during the general session breaks (the breaks start sometime between 1000 and 1030 each day) in Hall F. You may add your key to the keyring at: http://www.biglumber.com/x/web?keyring=9342 Additional details are available at: http://www.nanog.org/pgp.html If you have any questions, please contact me off-list. Thanks! --msa
Re: For anyone who hasn't yet asked Ren for an explanation...
On Fri, Jan 19, 2007 at 10:55:53AM -0800, Bill Woodcock wrote:
...of how this whole ATT rebranding thing works, Stephen Colbert summs it
up:
http://www.youtube.com/watch?v=Bj1Mtv9cD0Ieurl=
Much along the lines of seeing how fast you can name the
states, or their capitals alphabetically, how fast can *YOU* name the
22 operating companies?
No cheating!
(The converse game is principally played by Bell executives;
how fast can you {rename|acquire} the operating companies?)
--msa
NANOG38 PGP Key Signing
The key signings will be during the Monday and Tuesday morning breaks in Director's Row 46. Please try to get those keys into me by 9pm CDT on Sunday, however any late submissions will be accomodated as best I can. --msa -snip- Stickers for Your Name Badge When you stop by the registration desk at NANOG38, there will be colored stickers available for your name tag that indicate if you have an interest in signing PGP keys. If people keep trying to peer with you, you've picked up the wrong color sticker and should go back. How the Key Signing Works Those of you who plan to participate should email an ASCII extract of your public key to [EMAIL PROTECTED] by 10:00 p.m. CST on Sunday, February 12. Please include 'NANOG PGP KEY' in the subject, and if possible, don't send your key as a MIME attachment. I realize that some MUAs make this difficult, and I will attempt to fix any MIME-attached keys. Instructions for extracting your key to an ASCII file are below. After 9am CDT on the 9th, a complete key ring with all of the submitted keys will be available at puck.nether.net/~majdi/nanog38.pgp in binary form, and as an ASCII file at puck.nether.net/~majdi/nanog38.txt. These files may be updated with any late submissions for the Tuesday signings. Handouts with the details of each key submitted will be provided. All you should need to bring with you is: * Photo ID (driver's license, passport, etc.) * Your key ID, and its fingerprint * A pen Thank you, and I'm looking forward to seeing you all in St. Louis! How to Extract Your Public Key to an ASCII File PGP 2.x: pgp -kxa your_email_address mykey.asc PGP 5.x: pgpk -xa your_email_address mykey.asc GnuPG: gpg --export --armor your_email_address mykey.asc PGP on Windows: Start the PGPkeys application, select your key in the list, click on the Keys menu, select Export, name the resulting file, and make sure that Include Private Keys is NOT checked. PGP on a Mac: If you're using GnuPG, follow the instructions above. If you're using the commercial version, I assume the procedure is similar to the one for Windows, but cannot confirm this. Hopefully it's easy enough to figure out.
NANOG36 PGP Key Signing
The key signing will be on Monday at 3pm in the State room. If you can't make it, feel free to submit keys as there will be a follow-up session during the Wednesday morning break. So get those keys in and I'll see you in Dallas! --msa -snip- Stickers for Your Name Badge When you stop by the registration desk at NANOG36, there will be colored stickers available for your name tag that indicate if you have an interest in signing PGP keys. If people keep trying to peer with you, you've picked up the wrong color sticker and should go back. How the Key Signing Works Those of you who plan to participate should email an ASCII extract of your public key to [EMAIL PROTECTED] by 10:00 p.m. CST on Sunday, February 12. Please include 'NANOG PGP KEY' in the subject, and if possible, don't send your key as a MIME attachment. I realize that some MUAs make this difficult, and I will attempt to fix any MIME-attached keys. Instructions for extracting your key to an ASCII file are below. After noon on the 13th, a complete key ring with all of the submitted keys will be available at puck.nether.net/~majdi/nanog36.pgp in binary form, and as an ASCII file at puck.nether.net/~majdi/nanog36.txt. Handouts with the details of each key submitted will be provided. All you should need to bring with you is: * Photo ID (driver's license, passport, etc.) * Your key ID, and its fingerprint * A pen Thank you, and I'm looking forward to seeing you all in Dallas! How to Extract Your Public Key to an ASCII File PGP 2.x: pgp -kxa your_email_address mykey.asc PGP 5.x: pgpk -xa your_email_address mykey.asc GnuPG: gpg --export --armor your_email_address mykey.asc PGP on Windows: Start the PGPkeys application, select your key in the list, click on the Keys menu, select Export, name the resulting file, and make sure that Include Private Keys is NOT checked. PGP on a Mac: I assume the procedure is similar to the one for Windows, but cannot confirm this. Hopefully it's easy enough to figure out.
Re: Spring time fiber cuts (was Re: fiber cut 19 May/PM - 20 May /AM) (fwd)
On Sun, May 23, 2004 at 02:05:36PM -0700, Randy Bush wrote: and telcos usually do. but they almost always tell you it's protected. force them to test, or pull one side yourself. and repeat the test every quarter. Actually Randy, I would say 85% of the APS problems I've had were not due to a missing protect, but the inverse. There are a couple of carriers out there that insist on putting protects on everythingincluding circuits explicitly ordered without them. The best part is when they proceed to put hard loops on the protect you didn't order, and someone reloads a router. The circuit fails over to the looped protect, taking it down until you find someone that can locate which portion of the loop went to protect and take it out. Rinse and repeat for a different portion of the loop that wasn't supposed to have a protect every time anything at all takes the circuit down. Of course, since the circuit was ordered 'without' a protect, the telco themselves doesn't know it has a protect path. This is always fun to get them to troubleshoot. :) It's worth noting that just because you have a working protect doesn't mean it isn't wdmed or muxed onto the same fiber. If it is supposed to be a widely divergant path, latency can provide a clue, but in the majority of cases as the customer you can't really tell if they've given you the protect you asked for or not. --msa
Re: Barracuda Networks Spam Firewall
On Mon, May 17, 2004 at 02:26:37PM -0700, Jared B. Reimer wrote: This is a pretty serious flaw IMHO, if it is (in fact) true. qmail isn't the only mailer that behaves this way. It looks like they may have tried to kludge their way around this with LDAP in the case of MS Exchange, which also does asynchronous bouncing of undeliverable mail IIRC. Quite frankly, I'm at a loss as to why anyone would wish to accept and queue mail that they cannot deliver. Queuing everything just allocates disk unnecessarily and results in a lot of delayed bounce backscatter, almost always directed at a third party (in the common case of spoofed from: headers). Accepting everything simply because you don't wish to give away valid addresses doesn't work; the spam bots just jabber more loudly at you. In the past year I've had two domains joe jobbed, generating thousands of those helpful delayed bounce messages per hour for my role accounts. If, after RCPT TO, you do not have a valid destination, just refuse it. My role accounts thank you. --msa
NANOG30 PGP Key Signing
When you stop by the registration desk at NANOG30, there will be colored stickers available for your nametag that indicate if you have an interest in signing PGP keys. If people keep trying to peer with you, you've picked up the wrong color sticker and should go back. Additionally, there will be a PGP key signing party held during NANOG30 in (hopefully) sunny Miami. We are scheduled to meet on Monday night at 10:30 or so, after the Peering BOF. If the Peering BOF is running a little late, I'll delay us and ask Bill to tell jokes until everyone leaves. :-) Those of you who plan to participate should email an ASCII extract of your public key to [EMAIL PROTECTED] by noon on Monday, February 9th. Please include 'NANOG PGP KEY' in the subject, and if possible, don't send your key as a MIME attachment. I realize that some MUAs make this difficult, and I will attempt to fix any MIME attached keys. Instructions for extracting your key to an ASCII file are below. After 5pm on the 9th, a complete key ring with all of the submitted keys will be available at http://www.latt.net/nanog30.pgp in binary form, and as an ASCII file at http://www.latt.net/nanog30.txt Handouts with the details of each key submitted will be provided. All you should need to bring with you is: * Photo ID (driver's license, passport, etc.) * Your key ID, and its fingerprint * A pen Thank you, and I'm looking forward to seeing you all in Miami! How to extract your public key to an ASCII file: PGP 2.x: pgp -kxa your_email_address mykey.asc PGP 5.x: pgpk -xa your_email_address mykey.asc GnuPG: gpg --export --armor your_email_address mykey.asc PGP on Windows: Start the PGPkeys application, select your key in the list, click on the Keys menu, select Export, name the resulting file, and make sure that Include Private Keys is NOT checked. PGP on a Mac: I assume the procedure is similar to the one for Windows, but cannot confirm this. Hopefully it's easy enough to figure out.
Re: Block all servers?
On Fri, Oct 10, 2003 at 08:07:05PM -0600, Adam Selene wrote: IMHO, all consumer network access should be behind NAT. -snip- As for plug-in workgroup networking (the main reason why everything is open by default), when you create a Workgroup, it should require a key for that workgroup and enable shared-key IPSEC. These two requirements are mutually exclusive outside of a LAN environment, and if you're on a LAN, why require IPSEC? Filtering or NAT do not protect you from bad implementation or bad protocol design. Penalizing users that need (and will pay) for reasonably accessible two way communication is not the answer, and never will be. --msa
Re: .ORG problems this evening
On Thu, Sep 18, 2003 at 02:22:19PM -0400, Todd Vierling wrote: Sucks to be anyone trying to use the service whose routers pick those nodes as the only ones available. That's the fault of the implementor, not the client. I have a sneaking suspicion that if UltraDNS's tld cluster that is apparently located in Equinix-Ashburn stopped responding to queries for two hours last night, a lot more people would have noticed. A *lot* more people. I think it's out of line to speculate on how UltraDNS has configured these clusters, particularly in terms of how reachability information is verified and propagated without any knowledge of their configuration. The major issue here is that no *gTLD*, particularly one of the Big Three, should be subject to a SPOF -- even if it's only a regionally visible SPOF due to anycast selection. It should *always* be possible to attempt queries to more than one physical location's servers for a gTLD. Yet last night, I could not query .ORG from several different locations in the continental US, even though there were perfectly functional servers available (in the same country, no less). First it was two locations, one of which you can't tell us about (Deep inside OSPF Area 51?) -- now it's several? I've tried myself from many different hosts today, and they all route to different clusters. I'm having trouble finding more than one, geographically diverse host that routes to the same cluster. BGP errors happen (everyone here should be able to attest to that readily), and they did. What's to stop some other boneheaded DoS or oversight from causing this again? And again? Are you absolutely, positively sure this cluster was responding to 0 queries, but still propagating those two /24's? This particular outage was in the late evening in what appeared to be the affected area from my probing, which is why people like you don't appear to care; it didn't affect you. What about when it happens in the middle of the day in your neck of the woods? The reason for this is simple -- given the query volume a tld like .org receives, and given just how close this cluster is to so many millions of users in the eastern US, the odds of you being the *only* person, even amongst the few thousand on this list, to notice a problem... are incredibly slim. Since you won't tell us where these several hosts you tried to query from are addressed, and you won't tell us exactly which queries you tried, and how...it is incredibly hard to look into. This is the equivalent of calling every fire department in the nation and telling them that there is a fire, but refusing to tell them where you are, or what you've witnessed. Uh-huh. Quite a few people here know better; they also know I am surrounded by cloak/ on this list and others. If my public resume were up to date and filled in more detail, you'd know otherwise. Don't try to speak for my experience from your pedestal when you don't have the information to make that kind of baseless judgment. On the other hand, if you can't see the fatal flaw in a major Internet infrastructure service depending on a single point of failure, I can point you at a few books that could enlighten you. It isn't a single point of failure, but even if it were, I can assure you that the collective experience of this list would fill quite a few more volumes then you are capable of referring us to. You ask that we make no assumptions as to your experience -- grant us the same courtesy. --msa
Re: Nanog LAN - no rDNS?
On Mon, Jun 02, 2003 at 04:10:19PM +0100, Stephen J. Wilcox wrote: Hi, can we get any reverse DNS for the meeting LAN? Email to nanog-support is usually a good way to bring attention to this sort of problem during the conference, however, I note that it's working okay for me: 192.35.167.1 === dhcp3001.nanog28.merit.net 192.35.167.3 === dhcp3003.nanog28.merit.net 192.35.167.4 === dhcp3004.nanog28.merit.net -snip- 192.35.167.254 === dhcp3254.nanog28.merit.net --msa
Re: Global Crossing right now
On Tue, Apr 01, 2003 at 12:04:28PM -0800, Scott Granados wrote: There has been a lot of latency on several 7018 peers including 3561 and 3549 for the last week or so. Also wierd asimetric routing like one direction will have 7018 6461 and the other wil have 6461 3561 7018 with the 3561 7018 150 + ms. You should never be seeing 3561 transit 6461 to 7018, or vice versa. If you happen to notice this again, please send detailed prefix and path information to the providers in question, particularly CW. That said, the only flakiness I've seen from behind 7018 have been some odd occaisional UDP issues (Which I suspect are related to the 'traceroute' issue previously discussed on NANOG). I haven't noticed any unusual problems between 7018 and 6461. --msa
Re: 923 Mbps across the Ocean ...
On Fri, Mar 07, 2003 at 02:57:22PM -0500, Eric Germann wrote: http://www.cnn.com/2003/TECH/internet/03/07/speed.record/index.html Comments folks? Given enough thrust, pigs fly just fine...demonstrated by a professional driver on a closed track, please do not try this at home kids! Sure, given a link you don't have to share with production traffic and a lot of charity, it's possible to get TCP to do a lot of things. This doesn't make them a good idea (outside of those `special' environments.) On the other hand, if you have the need for this kind of single stream performance, and the pipe to yourself, why not devise your own protocol with less overhead? --msa
Re: Where is the edge of the Internet? Re: no ip forged-source-address
On Fri, Nov 08, 2002 at 01:01:33AM +0530, alok wrote: there was a comment from chris saying...never possible to knw what networks an bgp customer uplinks via you which is very true.. ..so i assume u mean non-bgp customers? loose or strict, rpf will not work for aasymterically connected bgp neighbouring AS How does loose not work in this scenario? If it's not in the global tables -at all-, it's not reachable, and might as well be discarded. --msa
Re: iBGP next hop and multi-access media
On Sun, Oct 06, 2002 at 11:40:11PM -0400, Ralph Doncaster wrote: Manually configuring a static route in router A would achieve the result: ip route 172.16.16.0 255.255.255.0 fa0/0 However, I'm surprised that there's no dynamic routing protocol that allows you to do everything you can with static routes. Ralph, how do you intend on getting traffic *OUT* of this subnet? Static arp entries on all the hosts? Proxy arp? It seems like that would be a lot more work and much more failure prone in the long run. Step up to the plate, configure a secondary address, and let normal routing protocols do their job. There is no compelling reason to implement an intentionally broken network, just to prove to us all how quirky you are. Thanks, --msa
Re: IP over in-ground cable applications.
On Thu, Sep 12, 2002 at 11:24:15AM -0700, Christopher J. Wolff wrote: The cable companies do this quite well; however, it's not immediately clear to me how I would multiplex the IP traffic and the existing video and deliver it to a home. Well, the traditional solutions involve some combination of digital TV (which you allude to in the next paragraph) and/or frequency division multiplexing, which has existed for quite some time. Note that FDM is what makes cable TV possible to begin with. As far as the cable is concerned, there isn't much of a difference between another TV channel and data. My current thoughts on this are to digitize the satellite video into mpeg2 and deliver it over TCP/IP through the in-ground cable. This way, integrating the video and data portion are easy, however the resident would need to buy a mpeg2 set-top-box to split out the video and internet. Thank you very much for your consideration. I'm not sure this is really any easier than existing analog FDM techniques. --msa
Re: How do you stop outgoing spam?
On Tue, Sep 10, 2002 at 12:45:01PM -0700, Al Rowland wrote: Steganography looked great in that hollywood movie Along Came a Spider with Morgan Freeman (or at least the 'screen friendly' version they portrayed) but a recent study of millions of graphics across USENET found zero steganographic images. Great theory, no examples found in the wild, other than in Hollywood scripts and some folk trading porn of the type not usually posted to the public Internet. I was going to stay out of this one, but then this came along. It is trivially easy to encrypt, transpose, or otherwise bury the message inside an image, or what have you. If I use a PRNG, prearrangement, or some other selection method to decide which bytes, or which files, or some combination of both will receive a chunk of the data to be hidden, and then encrypt it with a decent enough algorithm, it will not be easy to determine there is something there at all, particularly in a medium like USENET where lots and lots of large binary postings are common. Just because someone ran through a pile of images using jpegv4 with the jsteg patches, or some similar commercial application, does not mean it wasn't there -- it just means it wasn't obviously there. I myself have encrypted my PGP key's revocation certificates and buried them in some images on a website as a fallback storage method. Is it widely used? Probably not. Is it safe to say it's not being used on the basis of a quick check with an off the shelf utility or two? No. --msa
Re: Standalone Stratum 1 NTP Server
On Wed, Aug 28, 2002 at 09:55:21AM -0400, Robert E. Seastrom wrote: No. http://groups.google.com/groups?hl=enselm=3C32924F.994E1D01%40udel.edu Every critical organization should run at least four low-stratum servers configured as above, so dependant servers and clients can do the same thing. Each critical server should run NTP symmetric mode (better yet manycast mode) with each of the other servers at the same stratum, together with at least one peer at the same stratume in another trusted organization. By this criteria, a stratum 2 mesh of a bunch of top tier routers or diverse hosts, with external influence, should be okay. --msa
Re: Standalone Stratum 1 NTP Server
On Tue, Aug 27, 2002 at 11:57:39PM -0400, John Todd wrote: Hmm... $2400 is still in the pricey range to be throwing out bunches of these across a network in wide distribution. (Pardon me if some of you on the list snicker at my reluctance at the $2400 price - for some of us the new, new Econcomy is making things like NTP Stratum 1 clocks a luxury that The Budgeters doesn't see as necessary, since it's an invisible engineering issue.) Is it invisible? Proper timing is essential. It's not too hard to pick a suitable GPS and plug it into a host somewhere if cost is an issue. But, more to the point, you don't need a wide distribution of these boxes. 2 or 3 is more than enough. I tend to use my top level routers, or some distributed hosts (dns, authentication, logging, you name it) to form a stratum 2 mesh, and then have the rest of your network talk to them. A large number of stratum 2 servers talking to each other as well as a few stratum 1 clocks will result in a very stable distributed timesource that can support a whole lot of clients. You've already paid for the network, might as well use it. --msa
Re: your mail
On Tue, Aug 20, 2002 at 03:08:22PM -0400, N. Richard Solis wrote: I think that getting caught is a good indication that they take the security of the facility seriously. Which is clearly exhibited by them leaving a side door propped open, or not checking or securing this door earlier --msa
Re: Major Labels v. Backbones
On Sat, Aug 17, 2002 at 05:04:05PM -0400, Jared Mauch wrote: --The service provider must not determine the recipients of the material. One could argue (in theory) that a routing-table lookup may satisfy this. I'm not so sure. Generally speaking, a destination network is a given ISP, not a given individual. And it's highly impractical for an ISP to know the /individual/ a packet is destined for from the address. --The material must be transmitted with no modification to its content. Same theory here also, where one decrements ttl, since we are talking about ip packets here. I believe they're referring to copyrighted material which is wholly contained in the payload of the packets involved. Either way, this is an interesting test case and I do hope it receives immediate dismissal. This would be like asking the phone company to turn off phone service for people that arrange drug deals or similar. Not something that I see happening. I have to say I expect this one to be disposed of pretty quickly, but we'll see... --msa
Re: Is the PAIX Palo Alto taking a dump?
On Wed, Jul 31, 2002 at 05:24:57PM -0700, Herb Leong wrote: All my sessions at the PAIX are active--anybody else seeing this? I saw a fairly large traffic hit on the public fabric less than an hour ago. I'm currently seeing 87.5% of my sessions down. I suspect that the sessions that are up are probably on the same switch as the port I'm looking at. Hmm, I think I just saw one come back up. I'm going to fire off an email to [EMAIL PROTECTED] but they are probably already aware of this. Anyone else? --msa
Re: AS286 effectively no more..
On Thu, Jul 25, 2002 at 09:46:07AM +0300, Huopio Kauto wrote: Interesting how quietly one of the powerhouses in Europe has been shut down yesterday evening. Any notes on increased latency / routing issues wrt AS286 shutdown? On a much quieter note, how many people noticed that AS1673 and 140.223/16 disappeared a few weeks ago? It looks like Worldcom actually managed to integrate something! (Just before they finish going out of business, too...) --msa
Re: No one behind the wheel at WorldCom
On Mon, Jul 15, 2002 at 01:58:44AM -0400, Frank Scalzo wrote: See now we are back to the catch 22 that is IRR. No one will use it because the data isnt there, and no one will put the data into it because no one uses it. [CC: list trimmed] Actually, I think you'll find that bad data is only a small part of the problem; even with good data, there isn't enough support from various router vendors to make it worthwhile; it's effectively impossible to prefix filter a large peer due to router software restrictions. We need support for very large (256k+ to be safe) prefix filters, and the routing process performance to actually handle a prefix list this large, and not just one list, but many. IRR support for automagically building these prefix lists would be a real plus too. Building and then pushing out filters on another machine can be quite time consuming, especially for a large network. I think the way to get IRR into the real world production realm, is to really drive home the issue w/IPV6. This still doesn't solve the scaling issue. This is no different than running your own RR, which many ISPs already do -- and they still have to exempt many of their peers. Typically, RR derived prefix filtering is something reserved for only their transit customers. If it were that easy, everyone (well, some people) would be doing it. --msa
Re: XO
On Wed, Jul 10, 2002 at 11:00:58AM -0400, Pawlukiewicz Jane wrote: Anybody have a noc phone number for these guys? I can't seem to find anything on them publicly, except the usual hype. Jane, had you actually read many of the postings on this list before jumping right in and posting 20 times a day, you'd be aware of the NOC list: http://puck.nether.net/netops/ Additionally, googling for XO Communications NOC nets us all sorts of information: http://www.paix.net/participants/Participant_address_telcos/XO_Communications.htm The first rule of NANOG: * Use a search engine before asking NANOG. --msa
Re: Sprint peering policy
On Wed, Jun 26, 2002 at 12:39:11PM -0400, Ralph Doncaster wrote: While many other tier-1's have publicly listed their peering policies, I've never seen anything for 1239. Not that I'd stand a chance, but does anyone know what their peering requirements are? sprintlink.net# grep peering /etc/aliases peering:/dev/null sprintlink.net# --msa
Re: Sprint peering policy
On Wed, Jun 26, 2002 at 02:34:42PM -0400, Mitchell, Dan wrote: a strong management team (after all, they *did* build MFS) ^ `- I think you have mistaken this for an endorsement. And in the age of cooked books, stated revenue can be misleading, particularly when it looks too good to be true. I would be very wary of anyone in this business right now, particularly a CLEC. Regardless, I don't think shameless corporate plugs really belong on NANOG, but I'll allow that perhaps I am in the minority. --msa
Re: Adeklphia update
On Tue, Jun 18, 2002 at 05:30:50PM -0400, blitz wrote: Adelphia announced price increases today 90 cents a month for cable TV, bringing the package to about $39. a month in Buffalo, and $41. outside. Also they increased the powerlink cablemodem $2.00 a month. (this is the second increase this year) How do I configure my cablemodem for this? --msa
Re: Bogon list
On Tue, Jun 04, 2002 at 01:24:04PM -0700, Clayton Fiske wrote: How does the absence of an IXP route affect traceroutes -through- it? The IXP device has a route back to the source of the trace, so it can reply. The traceroute packets are addressed to the ultimate destination, so they don't need the IXP route. Quite a few GUI traceroute products expect to be able to ping each hop, and produce statistics based on that...definitely a bad approach, particularly utilizing ICMP, but that's the common practice. I cannot count the number of tickets I've seen opened because someone didn't know how to properly interpret traceroute data. --msa
Re: Betr.: KPNQwest
On Thu, May 30, 2002 at 11:46:16AM +0200, Erik-Jan Bos wrote: But the Internet, build on resilient technology, will survive... Is it? --msa
Re: PAIX (was Re: Interconnects)
On Sat, May 18, 2002 at 04:51:27PM -0400, Ralph Doncaster wrote: One BGP session instead of dozens is more convenient. Maybe not more useful for engineering, but certainly less work than negotiating and configuring a bunch of sessions for bilateral peering. For smaller ISPs like mine, knowing in advance that you won't get snubbed for peering after connecting to an exchange is the big attraction. Given the dozens of signatories on the AADS MLPA, it looks like they can be quite popular. Strictly speaking, I don't think a route-server is required to multilaterally peer, but they certainly help. However, there are a couple of big catches, particularly on an ATM or similar switching fabric: 1) One or two sessions, one or two VCs...if they go down, you will lose all your peering at that site. 2) The possibility of blackholing traffic to a peer who you have a downed VC to, but who is still advertising their prefixes to the route server. Additionally, quality of peering does not necessarily correlate to quantity of peering. I'm not going to claim that it's a bad thing to peer with a large number of typically smaller providers, but they don't always account for a statistically signifigant portion of your traffic. If you're going to have to negotiate bilateral agreements to cover the bulk of your peering traffic, why not consistantly negotiate bilateral agreements? --msa
Re: UUNET service
On Fri, Apr 12, 2002 at 04:04:42PM -0400, Bradley Corner wrote: I tried to notify UUNET at their 800-900-0241 number that there was a loop in their network. They told me that if I didnt have an account with them they were not interested in any information that I may have had for them. I stated that I was just calling so that they could pass the information onto an engineer. He repeated himself saying if you do not have an account with us I will not do anything with the information. I guess they think they run the internet and us small ISPs couldnt possibly know anything... I don't think this is a UUnet problem. -snip- 12 | 65.195.230.218 | core62007-gw.customer.alter.net 13 | 162.33.130.4| i97.toad.net 14 | 162.33.128.249 | tiara-2-balto.ds1.toad.net 15 | 205.197.182.201 | max2.toad.net 16 | 162.33.138.129 | mmsi-cpe.dsllan.toad.net 17 | 65.195.230.217 | 500.Serial2-11.GW4.BWI1.ALTER.NET 18 | 65.195.230.218 | core62007-gw.customer.alter.net 19 | 65.195.230.217 | 500.Serial2-11.GW4.BWI1.ALTER.NET 20 | 65.195.230.218 | core62007-gw.customer.alter.net -snip- To me, it looks like the customer has no internal route for this address and is defaulting to UUnet. The customer's default is the cause of the apparent loop, not anything UUnet is doing. Judging by the various toad.net hops before the loop becomes apparent, this may be caused by route instability inside the customer's network. Either way, this is not a UUnet issue. Their policies aside, I'm not sure what you want them to do about this. Incidentally, normal UNIX-style traceroute formats much better for email. --msa
Re: Need Verio Contact
On Wed, Mar 13, 2002 at 10:37:37AM -0600, [EMAIL PROTECTED] wrote: Does anyone have current contact info for VERIO NOC or Engineering? puck data is completely out of date, as is my internal lists. [EMAIL PROTECTED] is out of date? --msa
