Re: Microsoft SOHO router multicast problem? - or maybe it's just doing what it's supposed to be doing...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chance Whaley wrote: | Sorry about that. Didn't look in detail. Saw the UDP port 6257 and | stopped. | | The mcast is coming from someplace upstream from | fastethernet-0-0.genoa-gw.amplex.net (that is if I did my mcast | MAC to mcast IP conversion right). Without knowing your topology | and seeing more traffic it's kinda hard to figure out. | | | If you want to send more traffic captures I will be happy to look | at them. | | .chance | The destination mac address the routers start using is 01:00:5e:76:6c:7e. The 01:00:5e is the ethernet multicast header. The 76:6c:7e is supposed to be the lower 23 bits of the Ethernet multicast address - which translates to 118.108.126.With the 23 bits from the multicast spec for encoding the IP address 118 is the correct conversion of 246 with the high bit stripped off. The gateway on this subnet is 64.246.108.126 (netmask is 255.255.255.0 but originally was .128 - hence the odd spot for the gateway). The routers decided to convert a mangled unicast packet to a multicast packet - for them to then loop on it is even stranger. It makes for a pretty good DOS attack. 2 or more of these routers in a broadcast domain can get ugly in a hurry. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCX3F2g0PQSWMG2wsRAhYaAKCDeTpKF1QuDhX82rQIOpPTQW4xwACggXhd uHRnFxzmWbrfHSvZGS9ljrs= =IcaN -END PGP SIGNATURE-
Re: AUP for NANOG?
On Apr 14, 9:22am, Scott Grayban [EMAIL PROTECTED] wrote: The more bashing I hear here the less I want to ask a question here. I'm not stupid but I am worried that one question might spark a rash of flames back at me. This is a newbies point of view. Thanks for braving it.-) It would be interesting if we knew the newbie:bully:oldie ratio on NANOG. As an oldie, I would rather see clueless newbie questions as opposed to contentless rants and posturing, and I don't believe any kind of edge vs core split of NANOG is good. Networking is end-to-end, and what is needed is a tech vs non-tech split. In the old days we had a list called com-priv which effectively worked as the non-tech counterpart; anything to do with domain names, law suits, business practices, peering politics, legislation and regulation, etc, etc, etc would go on com-priv. Many, if not most, people subscribed to both lists, but kept things separate in their heads and in their postings. That didn't mean NANOG was a panacea for newbies, but just getting today's S/N ratio under control would be of great help. -- Per
RE: OpenTransit (france telecom) depeers cogent
If I may, you sound like someone whom FT has depeered in the past? :) Personally no. ;) simply playing devils advocate - who really knows what business model people are following? who really knows why this has happened? But in my view this type of action where it impacts customers doesn't help any of us. If you can't compete at the market price then you shouldn't be in the business, aggressive pricing in the market is just another thing you need to deal with. Regards, Neil.
Re: Anyone familiar with the SBC product lingo?
you'll never get better redundancy than having more than one carrier. On the contrary, you get better redundancy by sticking to one carrier and making sure that they really provide separacy though the entire span of the circuit. If you have two carriers running fibre to yoiur building down the same conduit, then you do NOT have separacy and as a result, the redundancy is not there. Of course, you can get separacy with two carriers but it is generally more work to verify that the two companies do not share fibre or conduit or tunnels. --Michael Dillon
RE: OpenTransit (france telecom) depeers cogent
from FT: FT terminated its direct interconnection with Cogent as they did not comply with 2 of the criterias of the FT Peering Policy. This Policy is official and published. However, route exchanges between Cogent and FT customer remained possible through IP transit provider networks such as Sprint for FT. As a matter of retaliation, Cogent blackholed all FT IP addresses, cutting the routes between their customers and FT's ones. This unitaleral measure is a breach of the rules agreed upon among the IP community. FT cannot be held responsible vis a vis its customers for the negative consequences of an action taken under the sole responsibility of Cogent. Regards, Jonas
Re: Postini Problems?
Lanny I'm seeing delays of arounf 5 hours for mail being sent through Postini at the moment. One of our suppliers complained they hadn't got our normal call-offs and then it arrived, about 5 hours after had been sent. The Postini is accepting messages, before passing on to the end recipient domain very slowly... -- Martin Hepworth Snr Systems Administrator Solid State Logic Tel: +44 (0)1865 842300 Lanny Jason Godsey wrote: I'm not able to reach Postini.com. Is anyone else having problems reaching them? Thanks! Lanny Godsey ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote confirms that this email message has been swept for the presence of computer viruses and is believed to be clean. **
Re: New Outage Hits Comcast Subscribers
Hi John, * [EMAIL PROTECTED] (John Payne) [Fri 15 Apr 2005, 00:48 CEST]: Do you? Relying 100% on anycast is MUCH worse than not deploying anycast at all. Spend some time thinking about various failure modes. (*sigh* just read NANOG archives if you want the short cut) In my opinion this statement is a bit overly broad. Yes, you can make anycast less reliable than two geographically and topologically separate nameservers, but if you place two nameservers behind the same router you end up with a less reliable system than even the simplest anycast setup. There is more than one solution to every problem. Don't fixate on anycast purely because your university hosts a couple of web pages on it. Nice - I'd have said purely because your boss read about it in some trade magazine, but the bottom line is the same: just because it's hip doesn't mean it's the best for you. -- Niels. -- The idle mind is the devil's playground
The Cidr Report
This report has been generated at Fri Apr 15 21:48:05 2005 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
08-04-05155649 106425
09-04-05155822 106490
10-04-05155876 106556
11-04-05155931 106518
12-04-05155938 106693
13-04-05156063 106855
14-04-05156161 106970
15-04-05156270 107016
AS Summary
19324 Number of ASes in routing system
7911 Number of ASes announcing only one prefix
1470 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - ATT WorldNet Services
90489600 Largest address span announced by an AS (/32s)
AS721 : DLA-ASNBLOCK-AS - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 15Apr05 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 156432 1069914944131.6% All ASes
AS4323 1090 225 86579.4% TWTC - Time Warner Telecom
AS18566 7898 78199.0% COVAD - Covad Communications
AS4134 887 216 67175.6% CHINANET-BACKBONE
No.31,Jin-rong Street
AS721 1118 563 55549.6% DLA-ASNBLOCK-AS - DoD Network
Information Center
AS7018 1470 953 51735.2% ATT-INTERNET4 - ATT WorldNet
Services
AS27364 517 22 49595.7% ACS-INTERNET - Armstrong Cable
Services
AS22773 477 23 45495.2% CCINET-2 - Cox Communications
Inc.
AS6197 887 469 41847.1% BATI-ATL - BellSouth Network
Solutions, Inc
AS3602 507 141 36672.2% SPRINT-CA-AS - Sprint Canada
Inc.
AS17676 430 77 35382.1% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS9929 347 45 30287.0% CNCNET-CN China Netcom Corp.
AS4766 572 277 29551.6% KIXS-AS-KR Korea Telecom
AS6478 383 96 28774.9% ATT-INTERNET3 - ATT WorldNet
Services
AS9583 708 448 26036.7% SIFY-AS-IN Sify Limited
AS6140 399 142 25764.4% IMPSAT-USA - ImpSat
AS14654 2636 25797.7% WAYPORT - Wayport
AS9443 373 122 25167.3% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS1239 911 663 24827.2% SPRINTLINK - Sprint
AS7545 484 250 23448.3% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS4755 451 219 23251.4% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS23126 252 21 23191.7% KMCTELCOM-DIA - KMC Telecom,
Inc.
AS15270 266 37 22986.1% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS6198 457 232 22549.2% BATI-MIA - BellSouth Network
Solutions, Inc
AS2386 842 624 21825.9% INS-AS - ATT Data
Communications Services
AS5668 489 282 20742.3% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS11456 318 111 20765.1% NUVOX - NuVox Communications,
Inc.
AS9498 270 72 19873.3% BBIL-AP BHARTI BT INTERNET
LTD.
AS22909 348 151 19756.6% DNEO-OSP1 - Comcast Cable
Communications, Inc.
AS6167 272 78 19471.3% CELLCO-PART - Cellco
Partnership
AS6147 205 20 18590.2% Telefonica del Peru S.A.A.
Total 16782 65931018960.7% Top 30
RE: Anyone familiar with the SBC product lingo?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Friday, April 15, 2005 6:34 AM To: nanog@merit.edu Subject: Re: Anyone familiar with the SBC product lingo? you'll never get better redundancy than having more than one carrier. On the contrary, you get better redundancy by sticking to one carrier and making sure that they really provide separacy though the entire span of the circuit. If you have two carriers running fibre to yoiur building down the same conduit, then you do NOT have separacy and as a result, the redundancy is not there. Which is the case in about 99% of the commercial buildings providers serve. Unless you're designed as a carrier hotel or a colo (even some colos aren't diverse entrance facility), this is the de-facto standard. The reason why is carriers et. al. must pay for conduit access to a building and it impacts pricing, especially if you're not servicing a huge load of service to the building. From the entrace facilities, carriers typically also pay riser conduit fees. Service delivery inside of the prem is insidiously complicated unless you understand a little RE and how OSP is linked to the ISP (in side plant). Of course, you can get separacy with two carriers but it is generally more work to verify that the two companies do not share fibre or conduit or tunnels. Im a metro loop, they are almost certainly going to share the same path. It is less certain that they will share a conduit. This is standard if you have the route diversity, which is why you want the provider diversity to make it all work. Hope that helps. -M
RE: Anyone familiar with the SBC product lingo?
On the contrary, you get better redundancy by sticking to one carrier and making sure that they really provide separacy though the entire span of the circuit. If you have two carriers running fibre to yoiur building down the same conduit, then you do NOT have separacy and as a result, the redundancy is not there. Which is the case in about 99% of the commercial buildings providers serve. Do you have any sources of data to back up that number? I believe that you are wrong and that it is not 99%. In Manhattan and similar city centers, I believe that your view is mostly correct but even there I don't believe that it is as high as 99%. And in places like Silicon Valley or Sacramento, the majority of commercial buildings are surrounded by parking lots, patches of grass and trees. In those areas, if your building doesn't have dual entrance, it is feasible to make it so. Maybe not easy, but definitely within the realm of feasibility. Service delivery inside of the prem is insidiously complicated unless you understand a little RE and how OSP is linked to the ISP (in side plant). No argument there. People who want to buy separacy have got to learn all of these things in order to guarantee that they are getting what they think they are getting. Once the market has matured a bit, I expect that 3rd party network suppliers will take over that duty. These 3rd party separacy providers won't have their own networks for the most part, but will do the donkey work to make sure that their carriers are supplying true separacy. In cities like New York and Philly, I would expect this type of third party to put in some of their own metro network links to work around hot-spots where it is too hard to guarantee that the carrier is really providing separacy. This is not unlike the way in which the tier 2 ISPs of the 90's were able to provide better uptime than the tier 1's because they aggregated access to several tier 1 networks. Im a metro loop, they are almost certainly going to share the same path. It is less certain that they will share a conduit. This is standard if you have the route diversity, which is why you want the provider diversity to make it all work. I'm not sure what you mean by path here, but people who want to buy separacy want those circuits to be physically separate at all points and they want the distance between circuits to be sufficiently great that they two circuits do not share fate. Two sides of the Baltimore tunnel would not qualify as truly separate paths by those standards. This is why I use the term separacy rather than diversity. Separacy seems to have originated among people planning SANs (Storage Area Networks) to interconnect mission-critical data centers in the same metropolitan area. --Michael Dillon
Re: Six PCs caused BigPond problems
...which reminds me of the Spoofer Project: The Spoofer Project: State of IP Spoofing http://momo.lcs.mit.edu/spoofer/summary.php - ferg -- Bill Stewart [EMAIL PROTECTED] wrote: That's ok. At least six more Telstra PCs will get compromised tomorrow. I don't know if they're doing uRPF etc. to stop address spoofing, or blocking RFC1918, but if not, that may help keep the load down. I'm not a fan of using anycast as opposed to building scalable distributed configurations of DNS servers and coordinating them with the DHCP settings that tell customers what server to use, (and monitoring them to make sure they keep working :-), but it can be good for isolating some problems like this. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://spaces.msn.com/members/fergdawg/
Re: Anyone familiar with the SBC product lingo?
Speaking on Deep Background, the Press Secretary whispered: (Anybody here *NOT* seen cases where the 2 fibers leave the building on opposite sides, go down different streets - and rejoin 2 miles down the way because there's only one convenient bridge/tunnel/etc over the river, or similar?) A friend works for Uncle Sam, and he is required to audit the routes used on certain high-availability systems, to insure the diversity we pay for. (It's in the contracts with the carriers..) He describes it as a long drawn-out exercise in futility. A non-trivial employee has to spend eons on the task. It's a recursive onion peeling, or a data version of Tom Lehrer's I Got It From Agnes... And once done... the errors found, the diversity restored, and the report signed off; it's soon worthless...because the carriers soon shuffle things around Yet Again. And I agree re: the building entrance issue and later choke points. Anyone recall the time several years ago that most of the Valley was isolated? One route was across the ?Bay? Bridge; it was down for planned maintenance when backhoe fade struck around San Jose. How many paths is enough? -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: New Outage Hits Comcast Subscribers
On Fri, Apr 15, 2005, Daniel Golding wrote: I also wonder how long it will be before home routers have DNS servers built-in, with a switch to let users select between iterative queries of their upstream's DNS and a normal recursive query. Has anyone seen this in the consumer market? My netcomm NB1300 ADSL modem/router already has a built-in DNS server. -- Adrian ChaddWhen you're a fantasy artist, [EMAIL PROTECTED] everything needs breasts. - Lisaera, Lusternia
RE: OpenTransit (france telecom) depeers cogent
Do you seriously view it that way? See the financial analysis available on the web about Cogent and tell me the same thing again. Same could be said for many companies in our industry at the moment, I call them the zombies. I want my packets to make it to the destination. For some Euros more I get real transit from real networks. See, all the world is fine again. He who wants to save even more money gets what he pays for. I remember people saying that about Level3 and many others. I bet your viewpoint would maybe change if you had nearly exclusively DSL traffic and hardly B2B- type traffic. I could be wrong, of course. If I was solely in that business I would not be focused on building big international networks, its pointless and unless you take significant market share from the PTTs, notably in Europe (which btw is highly unlikely given that the various legislators and regulators fail on a near constant basis to level the playing field for all operators) - the chances of making a return are incredibly slim. Better to setup smaller national networks, exchange most of the local traffic at the local peering point and pay $transit_network for the other 30 odd percent, do a decent deal with $transit_network and you'll be quids in and have a much more managable cashflow cycle without the step upgrades to some chunky network that the majority of your customers don't care about. Neil.
N+? redundancy
And I agree re: the building entrance issue and later choke points. Anyone recall the time several years ago that most of the Valley was isolated? One route was across the ?Bay? Bridge; it was down for planned maintenance when backhoe fade struck around San Jose. How many paths is enough? In my opinion, the following rule of thumb is reasonable. 1 path is enough for a site/enterprise that shuts down its services evenings and weekends. 2 paths is enough for a site/enterprise that provides a 24 hour, 7 day per week service. 3 paths is enough for a population center with under a million inhabitants. 5 paths is enough for a population center with over a million inhabitants. And a very few population centers such as New York, London, Tokyo, and Cheyenne Mountain should probably have more than 5 paths. --Michael Dillon
Re: New Outage Hits Comcast Subscribers
On Thu, 14 Apr 2005, Jeff Cole wrote: Brandon Ross wrote: On Thu, 14 Apr 2005, Sean Donelan wrote: Its called DHCP/PPP, both will auto-magically configure the correct DNS Which doesn't work very well when your provider cannot keep a DNS server up for 10 minutes at a time. See the beginning of this thread. Run bind locally on your laptop. I already do that. I wasn't referring to myself, I was referring to other users who might not have the skills or interest in running their own DNS daemons. -- Brandon Ross AIM: BrandonNRoss Director, Network Engineering ICQ: 2269442 InternapYahoo: BrandonNRoss
Re: Postini Problems?
I'm seeing delays of arounf 5 hours for mail being sent through Postini at the moment. One of our suppliers complained they hadn't got our normal call-offs and then it arrived, about 5 hours after had been sent. FYI, Postini only talks to their customers, not to senders whose mail they are delaying, losing, mangling, misfiling, etc. You might see if you can do a three-way call with your supplier if he's a customer. It is also my impression that as far as Postini is concerned, a problem is defined as something that makes customers stop paying their bills or cancel their service. Without those symptoms, it's not a problem. I'm sure I'm not the only person who's added explicit routes to his MTA to bypass Postini and mail to the customer's real MTA. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor I shook hands with Senators Dole and Inouye, said Tom, disarmingly.
Re: New Outage Hits Comcast Subscribers
On Apr 15, 2005, at 8:59 AM, Daniel Golding wrote: Too late. Every Mac ships with a working version of BIND. Its not enabled by default, but it can be turned on with a few keystrokes. Name a flavor of unix which doesn't? And even if you can, name a flavor of unix which can't get it installed with a few keystrokes [or mouse clicks]. We want people to use unix, stop complaining when they do. :-) Besides, the OSX named is well behaved in its default configuration (in my limited personal experience on my own laptops). -- TTFN, patrick
Re: OpenTransit (france telecom) depeers cogent
[EMAIL PROTECTED] (Daniel Golding) writes: This is part of the game. more like a war. Party A depeers Party B. Party B has received 30 to 60 days notification. That gives party B enough time to do one of two things. 1) They can ensure they have sufficient transit and/or peering with Party A's customers to ensure that all packets will be delivered. They can make sure that they are seeing all of A's routes through those other networks. This is what's called being good to your customers 2) They can take the time to put measures in place to punish party A. Things like route filters to make sure that the only places A gets B's routes are through the (soon to be gone) direct peering. Things like canceling or turning down enough transit so they can claim they CAN'T send the traffic anywhere else. Things like filtering out A's routes from their upstream's BGP feeds. This is called try to inflict enough pain to effect a reversal for the record, when the old AS174 (PSInet) depeered the old AS6461 (AboveNet), we (old MFN) chose #1. emotionally, i would have preferred #2 -- by a lot! but i could tell that PSInet wasn't going to be alive long enough for this to matter, so there was no long term payoff for the costs of such a war. the customers on both sides of the schism are probably happy that professionalism prevailed... but if PSInet had won and also somehow stayed in existence, then the whole industry would have suffered from the economic power thus conveyed. in other words, sometimes it's better to take pain in a lump sum than on the time payment plan. if that's what cogent's trying to do, they've got my support. if on the other hand cogent is, as accused here today, dumping transit at below cost, then may they rot in hell. (could i say that simpler?) Game theory is fun, folks! With real money on the line, its also very interesting. yes indeed. -- Paul Vixie
RE: MD5 for TCP/BGP Sessions
I would like to take this opportunity to thank everyone at Nanog that has assisted me in the completion of this paper. It's being submitted on Monday and I will be sure to let you know how it goes Once again - THANX Doug MDC Student Kingston University London /UK -Original Message- From: Doug Legge Sent: 30 March 2005 16:51 To: 'nanog@merit.edu' Subject: MD5 for TCP/BGP Sessions NANOG, I'm currently writing a paper for submission, as part of a MSc in Data Communications, and would appreciate if anyone could update me as to the implementation of MD5 for TCP authentication in BGP. Following the alerts last year: http://www.cisco.com/warp/public/707/cisco-sa-20040616-bgp.shtml http://www.us-cert.gov/cas/techalerts/TA04-111A.html http://www.cisco.com/en/US/products/products_security_advisory09186a00803be7 d9.shtml http://www.foundrynet.com/solutions/security/TCP_Vulnerability_v1_3.pdf http://www.kb.cert.org/vuls/id/415294 http://isc.sans.org/diary.php?date=2004-04-20 What has been the general effect in the ISP/Enterprise community following the warnings? - Have people applied MD5? - If not what other technologies were implemented (IPSec AH transport mode for BGP sessions/ACL/rate limiting etc)? - Has there been any performance impacts seen since implementation? - Has the support of the BGP environment been increased because of this implementation (What policies regards changing the MD5 keys were implemented)? - Was this seen as a valid fix or a knee-jerk reaction (Having re-read the exchanges on NANOG regards the actual mathematical probability of generating this attack, what did the ISP community actually do (compared to what the academic/vendor community were suggesting)? Whilst I've had some response from bgp-info and bgp-security, it's not really been sufficient to draw any real conclusions. From your knowledge and experience are you aware, either internally or with customers the take up of MD5 implementations and had anyone actually suffered an attack prior to implementation Please do not supply confidential information or anything that would be commercially sensitive, if you want to contact me off-line or from a private account please do Yours Doug Legge MDC Student Kingston University London /UK
Re: New Outage Hits Comcast Subscribers
Daniel Golding wrote: If you take a look at the dslreports.com forums, there are numerous complains about DNS performance from various DSL and cable modem users. I'm not sure how reasonable these complains are. The usual solution from other users is to install a piece of Windows software called Treewalk which will magically cure their problems. Consumer ISP's who don't proactively take care of security/abuse usually end up with harvesting-bots which consume significant amount of DNS resources, typically doing anything from a few dozen to a thousand queries _a_second_. A few hundred of these will seriously hamper an usually provisioned recursive server. Pete
Re: N+? redundancy
And a very few population centers such as New York, London, Tokyo, and Cheyenne Mountain should probably have more than 5 paths. I disagree. They may need that many spare paths beyond what is required to provide their services, but in my experience pretty much all infrastructure services are overloaded (or at least heavily loaded), and even if they have N+M redundancy, eliminating just one or two of those M links will be enough to overwhelm the others and take everything down in a complete cascade failure. Now you are talking about path capacity as well as the separacy issue. Let's consider the situation where you are designing a network to serve a city of over 1 million population. According to the rule of thumb, 5 paths are enough. What does this mean in practice? First, it probably means that you need to have 5 PoPs fully meshed within the city, or perhaps a larger number of PoPs in a partial mesh, so that you can get traffic from any point in the city to one of your 5 exits. However, the rule of thumb doesn't talk about this at all. Let's further simplify and consider the city to be a node, with 5 paths radiating out from it. One path could fail and the traffic from that path would have to be distributed to the other 4. As you have pointed out, this doesn't work unless all paths are running at four fifths of a normal load. Presumably, since IP circuits cannot run at 100% capacity, the 5 circuits are at somewhat less than 80%, but for now, let's just assume that they are running at no more than 80%. This is an N+1 scenario where one link can fail and service continues. But if two links fail, then 3 links must carry all the traffic, therefore all links must be at less than 60% of capacity. This would be an N+2 scenario. In the rule of thumb, I didn't really consider what failover scenario was right because it isn't a rule of thumb if it goes into too much detail. But the numbers, 1, 2, 3, 5, were chosen because I think that the sites which close up every evening, can live with N+0, then the others can probably live with N+1 except when you get to population centers above 1 million where connectivity to the rest of the world is important enough to have N+2 overall. In the real world, at the city level, there is more than one company providing the connectivity so it becomes tricky to analyze the true connectivity. Remember, paths are not equal to circuits. Therefore, the aggregate of all circuits from all companies which connect Chicago to St. Louis should count as one path. I'd love to see someone do a serious academic analysis along these lines to see what kind of rules of thumb have EMERGED from the past decades of network building and consolidation. It would be interesting if this type of research compared the network's topology to the topology of villages, market towns and cities which is remarkably uniform across continents and civilizations. --Michael Dillon
Best Practices Knowledge Capture (was: Re: AUP for NANOG?)
On Thu, Apr 14, 2005 at 12:20:14PM -0700, Steve Gibbard wrote: Speaking just for myself, I'd welcome discussion of operational and design issues specific to edge networks here, and newbie questions are useful as well. If those with experience don't share knowledge with those with less experience, we'll just have the same mistakes being made over and over again. And, in that vein, I'd like to repost, to the list, a query which I sent offlist to a couple dozen people last week, and only got 3 replies: == The Background == It came up on NANOG a week or so ago, not for the first time, that it might contribute to the general well being of the net if the (hopefully) not insubstantial section of the network operations audience who *want* to run their networks better, but don't know *how* yet had some place to go to gather that information. Having acquired some experience in the last 6 to 9 months about the usefulness of wiki software (and particularly MediaWiki, which is used to run the half-million article Wikipedia and is fairly well tuned for large audiences and easy administration) for facilitating distributed knowledge capture, I suggested that it might be A Good Idea to set up a wiki site for this purpose. As it happens, the Wikipedia people themselves have a facility for this sort of thing. It was named Wikicities, because when Jimmy Wales thought up the idea, Geocities was pretty popular. He has since changed his opinion, but, of course, it's hard to rename such a site. == The Pitch == Since they have a finite investment in labor to set up and in network costs to run such sites, and also an investment in the brand name, they want to have a pretty good idea that people proposing such a site have a sufficiently large crew of writers, editors, and wranglers to make a given site viable before they'll approve it. At Michael Dillon's suggestion, I've sifted through the last 5 months or so of NANOG traffic, and picked out the addresses of those of you whom I either know (mostly from the list, admittedly), or whose chops seem obvious from the traffic on the list. [ and only three replied :-} ] All I need at this point, as tacky as it sounds, is your names. :-) If you think you'd be willing to contribute in some fashion to such a site, either by way of original writing, editing or commenting on other people's work, or by contributing original writing you've already composed, please let me know. In not more than a week, I'll count up the noses, and get in touch with the Wikicities people. == The Reminder == As with all good sources of knowledge, wikis provide metadata on the provenance of the information contained on them, and visitors are expected to make use of it when deciding how -- and how much -- to make use of the information they find there. Wikipedia has developed a fairly good set of procedures for coping with the situation wherein the information on a page is disputed or controversial, and the other situations experienced on a public wiki (I propose, if they'll let me, to make the wiki registered-user write only), but those situations *will* happen -- just making sure everyone has their expectations strapped on straight. If people want to contribute finished papers, those can be protected so that their form does not change, but in general, the information on the site will be subject to continuous editing and improvement -- with all changes attributed, of course. If you'd like to help out on this, or make suggestions, or if you think I'm completely off my rocker, please drop me a note back. And note that I'm not making this a NANOG project per se; I expect that the email, anti-spam, RBL, and other crowds will have useful things to contribute as well; I merely don't follow those crowds as closely. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: AUP for NANOG?
From: Per Gregers Bilse [EMAIL PROTECTED] Date: Fri, 15 Apr 2005 09:46:14 +0100 On Apr 14, 9:22am, Scott Grayban [EMAIL PROTECTED] wrote: The more bashing I hear here the less I want to ask a question here. I'm not stupid but I am worried that one question might spark a rash of flames back at me. This is a newbies point of view. Thanks for braving it.-) It would be interesting if we knew the newbie:bully:oldie ratio on NANOG. As an oldie, I would rather see clueless newbie questions as opposed to contentless rants and posturing, and I don't believe any kind of edge vs core split of NANOG is good. Networking is end-to-end, and what is needed is a tech vs non-tech split. In the old days we had a list called com-priv which effectively worked as the non-tech counterpart; anything to do with domain names, law suits, business practices, peering politics, legislation and regulation, etc, etc, etc would go on com-priv. Many, if not most, people subscribed to both lists, but kept things separate in their heads and in their postings. That didn't mean NANOG was a panacea for newbies, but just getting today's S/N ratio under control would be of great help. We HAVE such a list: [EMAIL PROTECTED] It has been around for several years now... Unfortunately, not too much used... Regards, Gregory Hicks -- Per - 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: [EMAIL PROTECTED] 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
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] If you have any comments please contact Philip Smith [EMAIL PROTECTED]. Routing Table Report 04:00 +10GMT Sat 16 Apr, 2005 Analysis Summary BGP routing table entries examined: 159923 Prefixes after maximum aggregation: 93150 Unique aggregates announced to Internet: 76898 Total ASes present in the Internet Routing Table: 19422 Origin-only ASes present in the Internet Routing Table: 16899 Origin ASes announcing only one prefix:7905 Transit ASes present in the Internet Routing Table:2523 Transit-only ASes present in the Internet Routing Table: 68 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 23 Prefixes from unregistered ASNs in the Routing Table:13 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 14 Number of addresses announced to Internet: 1381478720 Equivalent to 82 /8s, 87 /16s and 177 /24s Percentage of available address space announced: 37.3 Percentage of allocated address space announced: 58.5 Percentage of available address space allocated: 63.7 Total number of prefixes smaller than registry allocations: 74677 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:32657 Total APNIC prefixes after maximum aggregation: 15410 Prefixes being announced from the APNIC address blocks: 30588 Unique aggregates announced from the APNIC address blocks:15419 APNIC Region origin ASes present in the Internet Routing Table:2240 APNIC Region origin ASes announcing only one prefix:652 APNIC Region transit ASes present in the Internet Routing Table:340 Average APNIC Region AS path length visible:4.4 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 181601920 Equivalent to 10 /8s, 211 /16s and 6 /24s Percentage of available APNIC address space announced: 67.4 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575 APNIC Address Blocks 58/7, 60/7, 124/7, 126/8, 202/7, 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes: 86956 Total ARIN prefixes after maximum aggregation:53107 Prefixes being announced from the ARIN address blocks:67784 Unique aggregates announced from the ARIN address blocks: 24901 ARIN Region origin ASes present in the Internet Routing Table: 9862 ARIN Region origin ASes announcing only one prefix:3573 ARIN Region transit ASes present in the Internet Routing Table: 929 Average ARIN Region AS path length visible: 4.3 Max ARIN Region AS path length visible: 21 Number of ARIN addresses announced to Internet: 244720640 Equivalent to 14 /8s, 150 /16s and 36 /24s Percentage of available ARIN address space announced: 69.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863 ARIN Address Blocks24/8, 63/8, 64/6, 68/7, 70/6, 198/7, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 30300 Total RIPE prefixes after maximum aggregation:20946 Prefixes being announced from the RIPE address blocks:27340 Unique aggregates announced from the RIPE address blocks: 18226 RIPE Region origin ASes present in the Internet Routing Table: 6543 RIPE Region origin ASes announcing only one prefix:3457 RIPE Region transit ASes present in the Internet Routing Table:1092 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 23 Number of RIPE addresses announced to Internet:
Re: OpenTransit (france telecom) depeers cogent
Paul Vixie wrote: in other words, sometimes it's better to take pain in a lump sum than on the time payment plan. if that's what cogent's trying to do, they've got my support. if on the other hand cogent is, as accused here today, dumping transit at below cost, then may they rot in hell. (could i say that simpler?) I'm not sure about the US price war, I just can say that I've seen an offer of AS174 in Switzerland which is 38% of the price of AS1239 we currently pay (same CDR). I'm not sure if ths already justifies hell, but at least purgatory ;-) Regards, Fredy
Re: AUP for NANOG?
If interested in such a list, an active one is ISP-CHAT. Details: To Join: mailto:[EMAIL PROTECTED] To Remove: mailto:[EMAIL PROTECTED] Archives: http://isp-lists.isp-planet.com/isp-chat/archives/ Be warned however that it is wildly inflammatory and rarely useful. Perhaps a in-between list that is for topics that are not immediatly operational but still on-topic for the industry? A nanog-industry list? sigh...not that I need to be on more lists... John At 12:09 PM 4/15/2005, Gregory Hicks wrote: [...] both lists, but kept things separate in their heads and in their postings. That didn't mean NANOG was a panacea for newbies, but just getting today's S/N ratio under control would be of great help. We HAVE such a list: [EMAIL PROTECTED] It has been around for several years now... Unfortunately, not too much used... Regards, Gregory Hicks
Re: OpenTransit (france telecom) depeers cogent
On Apr 15, 2005, at 2:10 PM, Fredy Kuenzler wrote: Paul Vixie wrote: in other words, sometimes it's better to take pain in a lump sum than on the time payment plan. if that's what cogent's trying to do, they've got my support. if on the other hand cogent is, as accused here today, dumping transit at below cost, then may they rot in hell. (could i say that simpler?) I'm not sure about the US price war, I just can say that I've seen an offer of AS174 in Switzerland which is 38% of the price of AS1239 we currently pay (same CDR). I'm not sure if ths already justifies hell, but at least purgatory ;-) Does that imply that 1239 has a better line on what actually costs are, or else sets those costs for other operators? Tom
Service providers that NAT their whole network?
A number of IETF documents(*) state that there are some service providers that place a NAT box in front of their entire network, so all their customers get private addresses rather than public address. It is often stated that these are primarily cable-based providers. I am trying to get a handle on how common this practice is. No one that I have asked seems to know any provider that does this, and a search of a few FAQs plus about an hour of Googling hasn't turned up anything definite (but maybe I am using the wrong keywords ...). Can anyone give me some names of providers that do this? Can anyone point me at any documents that indicate how common this practice is? - Philip (*) Some IETF documents that mention this practice: - RFC 3489 - draft-ietf-sipping-nat-scenarios-00.txt (now expired, but available at http://www.ietf.org/proceedings/02jul/I-D/draft-ietf-sipping-nat-scenarios-00.txt
Re: Service providers that NAT their whole network?
On Fri, Apr 15, 2005 at 03:39:56PM -0400, Philip Matthews wrote: A number of IETF documents(*) state that there are some service providers that place a NAT box in front of their entire network, so all their customers get private addresses rather than public address. It is often stated that these are primarily cable-based providers. I am trying to get a handle on how common this practice is. No one that I have asked seems to know any provider that does this, and a search of a few FAQs plus about an hour of Googling hasn't turned up anything definite (but maybe I am using the wrong keywords ...). Can anyone give me some names of providers that do this? Rose.net, the municipal provider in Thomasville GA. They'll assign you a fixed public address which can be gotten back through if you ask, for extra money, but your interface address will still be in 1918 space. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Service providers that NAT their whole network?
On Fri, 15 Apr 2005, Philip Matthews wrote: A number of IETF documents(*) state that there are some service providers that place a NAT box in front of their entire network, so all their customers get private addresses rather than public address. It is often stated that these are primarily cable-based providers. Didn't some of the African ISPs claim that they were forced to do this by ILEC/monopoly providers who would not give them the IP space they needed, resulting in ARIN allowing a minimum ISP allocation of /24 for the African region which is now AfriNIC? http://www.arin.net/policy/proposals/2003_15.html http://archives.afnog.org/msg02339.html goes into much more detail -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Service providers that NAT their whole network?
Philip == Philip Matthews [EMAIL PROTECTED] writes: Philip A number of IETF documents(*) state that there are some Philip service providers that place a NAT box in front of their Philip entire network, so all their customers get private addresses Philip rather than public address. It is often stated that these Philip are primarily cable-based providers. Philip I am trying to get a handle on how common this practice is. Philip No one that I have asked seems to know any provider that does Philip this, fastweb.it in Italy, and the Direcway satellite system in the US are the most obvious examples that I know of. I'm sure there are more. -- Andrew, Supernews http://www.supernews.com
Re: Service providers that NAT their whole network?
A number of IETF documents(*) state that there are some service providers that place a NAT box in front of their entire network, so all their customers get private addresses rather than public address. It is often stated that these are primarily cable-based providers. I am trying to get a handle on how common this practice is. No one that I have asked seems to know any provider that does this, and a search of a few FAQs plus about an hour of Googling hasn't turned up anything definite (but maybe I am using the wrong keywords ...). We nat a portion of our residentail users -- not all of our network. As I recall our current nat pools are comprised of a /21 --sjk
Re: Service providers that NAT their whole network?
On 4/15/05, Philip Matthews [EMAIL PROTECTED] wrote: I am trying to get a handle on how common this practice is. No one that I have asked seems to know any provider that does this, and a search of a few FAQs plus about an hour of Googling hasn't turned up anything definite (but maybe I am using the wrong keywords ...). There was a MA based provided that catered towards municipalities that did this. I was a volunteer on our local IT comittee and was shocked to see this in action :) After a few requests they eventually did assign a public address to the router, but I think it was SOP to NAT everything. -Steve
Re: Service providers that NAT their whole network?
A number of IETF documents(*) state that there are some service providers that place a NAT box in front of their entire network, so all their customers get private addresses rather than public address. It is often stated that these are primarily cable-based providers. I am trying to get a handle on how common this practice is. It's not uncommon among smaller providers in developing countries. International transit providers, particularly those that use satellite for local loop seem to be pretty miserly with IP addresses, leading their customer-ISPs to use NAT more broadly than is healthy. Obviously this makes it very difficult to multi-home, which reinforces the upstream's position. -Bill
Re: New Outage Hits Comcast Subscribers
I'm not complaining about it - heck, I use it. I just wanted to point out that desktop DNS servers are a reality. Right now, few folks use them. If ISP DNS server quality gets worse or there are a few big outages, we may see desktop DNS usage climb. This may have deleterious effects on the roots and TLD servers. It might be interesting to pull query data on a root server and correlate it with known dynamic IP address pools to spot a trend. - Dan On 4/15/05 9:54 AM, Patrick W Gilmore [EMAIL PROTECTED] wrote: On Apr 15, 2005, at 8:59 AM, Daniel Golding wrote: Too late. Every Mac ships with a working version of BIND. Its not enabled by default, but it can be turned on with a few keystrokes. Name a flavor of unix which doesn't? And even if you can, name a flavor of unix which can't get it installed with a few keystrokes [or mouse clicks]. We want people to use unix, stop complaining when they do. :-) Besides, the OSX named is well behaved in its default configuration (in my limited personal experience on my own laptops).
Re: Service providers that NAT their whole network?
On Fri, 15 Apr 2005, Philip Matthews wrote: A number of IETF documents(*) state that there are some service providers that place a NAT box in front of their entire network, so all their customers get private addresses rather than public address. It is often stated that these are primarily cable-based providers. In my experience many cellular providers (at least in the US) do this as well. A GPRS connection to Cingular, even from a laptop device, will get a 1918 address. I don't mind since my phone runs linux with no root password (thanks motorola). -Scott
RE: Service providers that NAT their whole network?
Back when I worked at RCN in 1999, they had begun putting cable modem customers behind NAT using 10/8 addresses. This occasionally drew complaints from customers who were expecting a public IP (probably wanted to host a server), but they weren't given much choice. Whether or not they're still NATing, I have no idea. I can see the benefits for residential services like cable modem or even dial-up when there will never be a need for multihoming. Practically unlimited IP pool, and I assume it's easier to control things like worm propogation (correct me if I'm wrong). However, I'm sure there's several compromises you'd have to make in order to operate this way. -Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Matthews Sent: Friday, April 15, 2005 3:40 PM To: nanog@merit.edu Subject: Service providers that NAT their whole network? A number of IETF documents(*) state that there are some service providers that place a NAT box in front of their entire network, so all their customers get private addresses rather than public address. It is often stated that these are primarily cable-based providers. I am trying to get a handle on how common this practice is. No one that I have asked seems to know any provider that does this, and a search of a few FAQs plus about an hour of Googling hasn't turned up anything definite (but maybe I am using the wrong keywords ...). Can anyone give me some names of providers that do this? Can anyone point me at any documents that indicate how common this practice is? - Philip (*) Some IETF documents that mention this practice: - RFC 3489 - draft-ietf-sipping-nat-scenarios-00.txt (now expired, but available at http://www.ietf.org/proceedings/02jul/I-D/draft-ietf-sipping-nat-scenari os-00.txt
Re: Service providers that NAT their whole network?
On Fri, Apr 15, 2005 at 01:40:12PM -0700, Scott Call wrote: On Fri, 15 Apr 2005, Philip Matthews wrote: A number of IETF documents(*) state that there are some service providers that place a NAT box in front of their entire network, so all their customers get private addresses rather than public address. It is often stated that these are primarily cable-based providers. In my experience many cellular providers (at least in the US) do this as well. A GPRS connection to Cingular, even from a laptop device, will get a 1918 address. I don't mind since my phone runs linux with no root password (thanks motorola). Must depend on the service. My CDPD and the 1X-RTT that replaced it, both from Verizontal, had public addresses, though they grew incoming filters around the Code Red days... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: OpenTransit (france telecom) depeers cogent
On Apr 15, 2005, at 2:10 PM, Fredy Kuenzler wrote: Paul Vixie wrote: in other words, sometimes it's better to take pain in a lump sum than on the time payment plan. if that's what cogent's trying to do, they've got my support. if on the other hand cogent is, as accused here today, dumping transit at below cost, then may they rot in hell. (could i say that simpler?) I'm not sure about the US price war, I just can say that I've seen an offer of AS174 in Switzerland which is 38% of the price of AS1239 we currently pay (same CDR). I'm not sure if ths already justifies hell, but at least purgatory ;-) Strange, I am REALLY HAPPY when someone offers me a comparable product for less money. If you prefer to pay more, well, I'm happy for you. (And no flames about Cogent not being comparable. I've already posted here that their network runs just fine. Of course, now that they are no longer offering full transit, we are re-considering how good their pricing is.) Back on topic, I am unclear on why you sell X for less than I do is justification for rotting in hell. Whether X is below your cost is COMPLETELY immaterial. Whether it is below their cost is irrelevant to me, but it might be important to some countries / laws / whatever. If they are breaking a law, have someone investigate charge them. If there is no law against it, deal with it. They should be going out of business RSN anyway. -- TTFN, patrick
Today's tech news highlights....
For your perusal: Encarta to Test User Edit System Vint Cerf Slams Net Phone Regulation Study Finds Pervasive Chinese Internet Controls Last-minute tax filers hit the Web Vint Cerf: Hollywood interested in BitTorrent Google's Track by Number Gizmo South Korea Cracks Down on Online Porn George Bush expresses e-mail privacy fears Virus Writers have Girlfriends, too Entertainment industry doesn't like Grouper, new privacy-friendly P2P app More Royal Brawn than Brains? Comcast customer sues over disclosure Polo Ralph Lauren confirms HSBC data security problem Bogus blogs snare fresh victims Comcast Suffers Three Outages In A Week IBM announces $125m deal with UAE Where's That Windows Media Player Update? Study: Home workers pose security risk For what it's worth, I've relocated the blog to: http://fergdawg.blogspot.com/ so the site feed should work now. Comments welcome. Cheers, - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: Service providers that NAT their whole network?
While not big by any sense of the word, we NAT [almost] all of our internal network. It wasn't initially a matter of choice, but rather of necessity. We had a sprinklings of small netblocks in the old legacy C swamp, mostly in the old SURAnet/BBN allocation, and after the Genuity takeover they yanked our routes on short notice (actually, our upstream didn't notify us until the last minute). We had to NAT into a new temporary allocation from an upstream, and later renumbered into a portable block for multihoming. There are still some old Genuity addresses in use inside (renumbering is easier said than done) but we're slowly cleaning them up. NAT seemed to be the best option at the time, especially since we had no portable allocation. We used to overload, but talk about overhead... Jeff
RFC1918 in-addr.arpa local copies
After a routing issue between us and an instance of the RFC1918 anycast servers blackhole-[12].iana.org which caused all sorts of bizzare failures within customer networks, I'm trying to figure out if there is a really good reason why I shouldn't keep a copy of the 1918 zones on my local recursive customer-facing DNS servers so breakage between us and these servers won't cause grief in the future. So my questions are: 1) Is there a good reason why I shouldn't host a local copy of the RFC1918 in-addr zones on my servers? 2) I've dug around and haven't been able to find an example of a RFC1918 zone file ala what's on the official servers. I'm assuming that these are basically just empty domain filas but I'd love to verify that this is the case. Of course, the blackhole servers I tried don't respond to AXFR. 3) Alternatively, I could host a local anycast instance of these servers, but I can think of lots of good reasons why this might be bad. Ideas? Comments? --forrest
Re: RFC1918 in-addr.arpa local copies
On Fri, 15 Apr 2005, Forrest W. Christian wrote: After a routing issue between us and an instance of the RFC1918 anycast servers blackhole-[12].iana.org which caused all sorts of bizzare failures within customer networks, I'm trying to figure out if there is a really good reason why I shouldn't keep a copy of the 1918 zones on my local recursive customer-facing DNS servers so breakage between us and these servers won't cause grief in the future. hrm, www.as112.net might have info you would like to see/read/implement. So my questions are: 1) Is there a good reason why I shouldn't host a local copy of the RFC1918 in-addr zones on my servers? nope, I suspect: www.as112.net would like you to host one. 2) I've dug around and haven't been able to find an example of a RFC1918 zone file ala what's on the official servers. I'm assuming that these are basically just empty domain filas but I'd love to verify that this is the case. Of course, the blackhole servers I tried don't respond to AXFR. probably you would get a copy of this when you turned up a set of hosts for www.as112.net :) 3) Alternatively, I could host a local anycast instance of these servers, but I can think of lots of good reasons why this might be bad. sure, the folks at www.as112.net might even have answers, and perhaps you could summarize back to the list? I am interested atleast...
Re: RFC1918 in-addr.arpa local copies
[EMAIL PROTECTED] (Forrest W. Christian) writes: 1) Is there a good reason why I shouldn't host a local copy of the RFC1918 in-addr zones on my servers? according to RFC 1918, you should do this. 2) I've dug around and haven't been able to find an example of a RFC1918 zone file ala what's on the official servers. I'm assuming that these are basically just empty domain filas but I'd love to verify that this is the case. Of course, the blackhole servers I tried don't respond to AXFR. an empty zone (except for the SOA and NS) works pretty well. 3) Alternatively, I could host a local anycast instance of these servers, but I can think of lots of good reasons why this might be bad. more is better. -- Paul Vixie
