- NANOG - lists.nanog.org

Re: Reducing Usenet Bandwidth
by Stephen Stuart 17 Feb '02

17 Feb '02

> Like many Internet settlement schemes, this seems to not make much sense. If > a person reads USENET for many years enjoying all of its wisdom, why should > he get a free ride? And why should the people who supply that wisdom have to > pay to do so? A USENET transaction is presumed to benefit both parties, or > else they wouldn't have configured their computers to make that transaction. Well, the idea wasn't exactly fully formed, and you've taken it in a direction that doesn't match what I was thinking. I am definitely *not* thinking at the granularity of "users." I've heard of users, and their hunger for pornography, MP3s, and pirated copies of Word, but this isn't about them. It's about sites that want to offer USENET to these "users," and the ever-increasing cost to play in the global USENET pool. The topic being discussed is to try to reduce USENET bandwidth. One way to do that is to pass pointers around instead of complete articles. If the USENET distribution system passed pointers to articles around instead of the actual articles themselves, sites could then "self-tune" their spools to the content that their readers (the "users") found interesting (fetch articles from a source that offered to actually spool them), either by pre-fetching or fetching on-demand, but still have access to the "total accumulated wisdom" of USENET - and maybe it wouldn't need to be reposted every week, because sites could also offer value to their "users" on the publishing side by offering to publish their content longer. It would be helpful if that last decision - how much to publish - didn't have global impact the way it does now. When someone injects a copy of Word into the USENET distribution system now, everyone's disk and bandwidth cost is incurred immediately. If a pointer was flooded instead, the upfront cost is less, and article transfer cost is (arguably) able to more closely match a site's level of demand, rather than other sites' willingness to supply. This would have the effect of letting sites with different levels of willingness to expend resources still play in the global USENET game with, in theory, greater access to information. It would, again in theory, allow sites that don't necessarily have the benefit of a lot of resources to spool articles to leverage access to sites that do (thus the comment about the cost being incurred by the publisher, or, more appropriately, those willing to publish). The primary benefit, I think, is that sites that publish poorly - allow a lot of trash to be posted - could do so without poisoning the village green for others. A downstream spool might be able to implement the policy option of choosing not to pre-fetch on a site-by-site basis, rather than having to tune their spool on a group-by-group basis, and the information is all still there. The incentive to publish quality information is that downstream sites are more willing to pre-fetch from you, lowering your bandwidth costs. There are, of course, a thousand devils in the details, like how to chase down an article when you didn't necessarily have it and you didn't necessarily know who might still be offering a copy. Some of those problems in that vein that appeared insurmountable ten years ago might have solutions in current "peer-to-peer" networking technologies (thus the off-hand comment about Napster). Users, in theory, would not really see anything different than they see today. Underneath the covers, though, (a) some articles might take longer to fetch than others, and (b) there'd be less trash distributed globally. I don't envision reducing the hunger of "users" for pornography, MP3s, or pirated copies of Word. Maybe we don't need to incur so much cost transmitting them to and storing them in thousands of sites around the net each week, though. Stephen

5 6

Call for papers - First ever NordNOG event
by Kurt Erik Lindqvist 17 Feb '02

17 Feb '02

(Apologies for the slightly off-topic posting) The organizers of the very first Nordic Network Operator Group meeting are hereby inviting interested speakers to send in suggestions for their topics. The meeting is planned to be held in Stockholm 13-14th of March. Speakers interested in presenting at the NordNOG-1 conference should send a summary of their topics and a presentation of themselves to meeting(a)nordnog.org. As this is the first ever event, we would also appreciate if people interested in attending would let us know. You can do this via email to kurtis(a)kurtis.pp.se. For more information on the event, see http://www.nordnog.org. Best regards, - kurtis -

1 1

Re: Call for papers - First ever NordNOG event
by smd＠clock.org 17 Feb '02

17 Feb '02

Kurtis skrivit: | (Apologies for the slightly off-topic posting) ... | For more information on the event, see http://www.nordnog.org. F|rl}t? L{nken virker icke. 8-bit DNS-problem? No such domain: nørdnog.org No such domain: nördnog.org Tjaaaaa... Sean. (som har kommit vilse) PS: nerdnog.org doesn't work either, dammit.

1 0

zebra/ospf issue
by Josh Gentry 17 Feb '02

17 Feb '02

Folks, I'm experimenting with using Zebra running on a Debian box to do OSPF with the Ciscos on our network. The zebra box has 2 interfaces, each in a different area. This is the first time we have tried to impliment multiple areas on our network. Right now, area 51 consists only of the zebra box and a Cisco 2500, and is just for testing. The zebra box is forming a full adjacency with the Cisco in area 51 with no problems. It will not, however, become fully adjacent with the DR and BDR in area 0. This seems to be preventing the distrobution of routes to the zebra box. Distrobution of routes in area 51 works fine. Here is my config, minus auth info. ! Zebra configuration saved from vty ! 2002/02/02 16:35:11 ! hostname ospfd log file /var/log/zebra/ospfd.log service password-encryption ! ! interface lo ! interface eth1 ip ospf authentication-key <password> ! interface eth0 ip ospf message-digest-key <keyid> md5 <password> ip ospf priority 5 ip ospf hello-interval 10 ip ospf dead-interval 40 ! router ospf ospf router-id 216.184.8.55 ospf abr-type cisco ospf rfc1583compatibility network 198.59.115.0/24 area 0 network 216.184.8.0/24 area 51 area 0 authentication message-digest area 51 authentication redistribute static Any insight would be appreciated. Thanks. Josh jgentry(a)systemstability.org

3 5

AT&T 24.126.0.0
by Simon Higgs 17 Feb '02

17 Feb '02

Hi, Can someone confirm that there's some kind of DOS happening on the 24.126.0.0 network? I'm receiving an http request every three minutes (24/7) and it's been going on for about a week now. What is puzzling me is that each request is coming from what appears to be a random address within this same net block. If anyone from AT&T is out there that knows what this is please contact me. Best Regards, Simon -- ###

1 0

Re: zebra/ospf issue
by Josh Gentry 17 Feb '02

17 Feb '02

> Folks, > > I'm experimenting with using Zebra running on a Debian box to do OSPF with > the Ciscos on our network. The zebra box has 2 interfaces, each in a > different area. This is the first time we have tried to impliment > multiple areas on our network. Right now, area 51 consists only of the > zebra box and a Cisco 2500, and is just for testing. > > The zebra box is forming a full adjacency with the Cisco in area 51 with > no problems. It will not, however, become fully adjacent with the DR and > BDR in area 0. This seems to be preventing the distrobution of routes to > the zebra box. The adjacency issue is solved. We were hoping to use the Debian Zebra package because we like their package management so much, but they do tend to be behind the development curve. When we built Zebra from the current source the adjacency issue just went away. Next question. Now that the adjacency issue is solved, the router that is in both area 51 and area 0 is learning routes from area 0, and the other router in area 51 is then learning those routes in turn. If I add a route on the area 51 only router, however, that route shows up on the router in both area 51 and area 0, but does not show up on the other routers in area 0. I am using all the redistrute commands I can find. I'm baffled at this point. Any insight would be appreciated. > > Distrobution of routes in area 51 works fine. > > Here is my config, minus auth info. > > ! Zebra configuration saved from vty > ! 2002/02/02 16:35:11 > ! > hostname ospfd > log file /var/log/zebra/ospfd.log > service password-encryption > ! > ! > interface lo > ! > interface eth1 > ip ospf authentication-key <password> > ! > interface eth0 > ip ospf message-digest-key <keyid> md5 <password> > ip ospf priority 5 > ip ospf hello-interval 10 > ip ospf dead-interval 40 > > ! > router ospf > ospf router-id 216.184.8.55 > ospf abr-type cisco > ospf rfc1583compatibility > network 198.59.115.0/24 area 0 > network 216.184.8.0/24 area 51 > area 0 authentication message-digest > area 51 authentication > redistribute static > Josh jgentry(a)swcp.com

1 1

NSI/VeriSign propogating incorrect DNS glue records
by David Luyer 16 Feb '02

16 Feb '02

Does anyone know any way to contact NSI and get them to remove or correct bogus glue records (host entries)? Not the phone number on their website for international callers - they're completely _not_ helpful. Very polite, just no help. Their automated systems send confirmation requests to the wrong addresses (the legacy contact address on the *-HST record rather than the new contact address on the domain, despite the claims on their help pages). As NSI are poisoning the DNS with incorrect and extraneous glue records, all domains with the DNS servers in question are broken, despite the domain which contains the DNS servers being already redelegated and having correct updated entries for those hostnames in it. I've called NSI twice but they just seem to make up random stories and tell me things I've done before aren't possible (pointing two registered nameserver names at one IP for example... we have a number pointing at one IP already, which they eventually verified). And sitting on hold to the USA is frustrating, too. Emailing them resulted in an automated response promising an answer within 24 hours. 36 hours ago. Can another registrar even do anything? Since NSI have the domain and host record, it doesn't seem likely. And this is really urgent for me since the bogus/old IPs being propogated by NSI are to be derouted in less than 48 hours, so even if they do fix it there's still outage time for the domains due to the 48 hour TTL. It's just completely screwed up that they can't even verify and expedite the request in any way and just make up excuses like "our mail server is playing up" and "email tends to take 24-48 hours to get through". I don't have a problem getting email from/to anyone else on the internet in less than a minute... David.

3 3

The Cidr Report
by CIDR Report 16 Feb '02

16 Feb '02

This is an auto-generated mail on Fri Feb 15 23:00:00 PST 2002 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 15Feb02 0) General Status Table History ------------- Date Prefixes 080202 105598 090202 105704 100202 105732 110202 105576 120202 105729 130202 105810 140202 105555 150202 105693 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 96.0.0.0/20 from AS3549 AS Summary ---------- Number of ASes in routing system: 12420 Number of ASes announcing only one prefix: 7568 (4308 cidr, 3260 classful) Largest number of cidr routes: 722 announced by AS701 Largest number of classful routes: 1371 announced by AS701 1) Gains by aggregating at the origin AS level --- 15Feb02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1152 889 263 22.8% Telstra Pty Ltd AS701 1371 1126 245 17.9% UUNET Technologies, Inc. AS577 324 198 126 38.9% Bell Advanced Communications Inc. AS16473 198 77 121 61.1% Bell South AS7018 821 703 118 14.4% AT&T AS6595 172 60 112 65.1% DoD Education Activity Network As AS4151 253 148 105 41.5% USDA AS705 307 203 104 33.9% UUNET Technologies, Inc. AS852 427 326 101 23.7% Telus Advanced Communications AS7046 318 232 86 27.0% UUNET Technologies, Inc. AS19632 94 9 85 90.4% Metropolis Intercom S.A. AS2048 186 105 81 43.5% State of Louisiana AS12302 111 32 79 71.2% MobiFon S.A. AS1239 479 403 76 15.9% Sprint AS4323 416 344 72 17.3% Time Warner Communications, Inc. AS3908 337 270 67 19.9% Supernet, Inc. AS4755 192 129 63 32.8% Videsh Sanchar Nigam Ltd. Autonom AS3464 157 97 60 38.2% Alabama SuperComputer Network AS703 275 216 59 21.5% UUNET Technologies, Inc. AS7303 107 49 58 54.2% Telecom Argentina Stet-France Tel AS724 212 154 58 27.4% DLA Systems Automation Center AS16758 63 6 57 90.5% IKON Office Solutions AS226 145 89 56 38.6% Los Nettos AS19834 63 8 55 87.3% NetForce, Inc. AS10620 77 22 55 71.4% TVCABLE BOGOTA AS702 624 570 54 8.7% UUNET Technologies, Inc. AS209 302 250 52 17.2% Qwest AS1 478 426 52 10.9% BBN Planet AS9051 74 23 51 68.9% INCONET Autonomous System AS2149 304 253 51 16.8% Performance Systems, Inc. Total 53554 41894 11660 21.8% For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Transit Analysis
by Guy.Ram＠usa.telekom.de 15 Feb '02

15 Feb '02

> I'm trying to understand what techniques/solutions are available to > determine which AS's would make good peering partners. If we look at our > Transit stream to our upstream provider, I had heard the following from > someone and would like to get some other opinions: > > When trying to identify good AS candidates for peering from your transit > traffic stream. It would seem that distinguishing the ingress traffic by > not only the next-hop AS but also by the next-next-hop AS (or by the > complete AS path) so that you can identify which customer or peer of your > transit provider might be a likely interesting new peer for you. However, > due to the concept of BGP traffic in the internet being asymmetrically > distributed. It is not possible to exactly determine the real AS path of > incoming traffic. The only reliable information is about the next-hop and > the origin AS. Assuming that traffic is mostly symmetrical it is possible > to "estimate" the distribution of ingress traffic on AS paths. While this > assumption is questionable it at least allows to find out one (or some) of > the several "potential" intermediate" ASNs for a given origin ASNs. > > Is the above statement OK, and what about egress analysis, would that not > also provide useful as that information is more reliable? > > -guy > >

3 2

via the IP list...
by bmanning＠karoshi.com 15 Feb '02

15 Feb '02

http://www.newsbytes.com/news/02/174510.html The Federal Communications Commission (FCC) today said it has tentatively concluded that broadband Internet access provided over phone lines constitutes an "information service," and as such may not be subject to the open-access rules that govern the nation's phone networks. While the text of today's "notice of proposed rulemaking" probably won't be made publicly available for a couple days, the FCC signaled that it intends to remove some of the regulatory fetters that dictate how the nation's four Bell phone giants offer broadband services. <snip>

5 4