- Test - lists.nanog.org

Re: multi-homing
by Paul Vixie 29 Aug '01

29 Aug '01

uurtamo(a)arttoday.com (steve uurtamo) writes: > is _your_ router going to explode if my /24 gets added to your table? of > course not. your main concern is that your router explodes if _too_ many > people's prefixes, of whatever size, get added to your table. this is, i > think, a good thing to worry about, but it's a little early to be worrying. i think that absent the worrying that's already gone on, from way back before CIDR when BGPv3 was classful, is the only reason you can still say it's "early." alas, doomsayers who are taken seriously in their own time, that is, early enough for their prophesies to be treated as foresight and acted upon preventatively, are often called unstable sky-is-falling cranks in the history books. (witness the Y2K debacle if CIDR doesn't excite you.)

1 0

RE: What is the limit? (was RE: multi-homing fixes)
by Roeland Meyer 29 Aug '01

29 Aug '01

|> From: Martin, Christian [mailto:cmartin@gnilink.net] |> Sent: Tuesday, August 28, 2001 3:22 PM |> |> This is the umpteenth time that this type of thread and its |> spawn have been religiously fought out on NANOG. I didn't notice any wildly religious views, this time around. Maybe, with practice, we are getting better at it? |> What we don't see is any real data that indicates who |> is right and who is wrong. The only empirical data |> shows a comparison between routing table growth and Moore's |> law, which doesn't amount to a whole hill of beans |> if there isn't a reasonable frame of reference to which |> we can make comparisons. This is a serious problem. Can we not issue a writ of habeus corpus? Where is the body of evidence for the claims? Yes, I see a theoretical problem and, yes, there is sufficient argument that someone should start work on it (IETF?). However, is anyone working on it? In the meanwhile, I see no reason to bring the Internet to a screeching halt, based on the evidence thus far presented. |> To offer an analogy, what we are doing is standing in front |> of a bridge that says "Maximum Weight - Not Too Much Or It |> Might Collapse". This reminds me much of the arguments presented by D'Crock wrt the imminent collapse if only a few more TLDs were introduced. Which, in light of the volume in COM alone, was absurd. We, involved in the ICANN, are adding a bunch more than a few, with no software changes. Collapse is not expected anytime soon. Those of us running the independent root-zones have done the tests (which D'Crock was trying to forestall with such argument) and found the claims baseless and not amounting to anything more than FUD. The proof is in the new ICANN TLD roll-outs. The instance-proof was actually there all along, since NSI was running both root servers and gTLD servers on the same boxen. I am now seeing the same sort of argumentation. Only this time, the objective is to try and keep folks from being able to multi-home or otherwise achieve independence. Jeez, in both cases, the upper-level goal seemed to be the same. Why is that? BTW, I have direct evidence to the above, all the way back to the newdom list. Also, the FUD did delay things a *bunch* of years. Does this sound familiar? |> I think that what we need to do is have a fourth group, call |> them Internet Engineers for lack of a better word, |> come in and determine what the sign should read. Now *that* would indeed be novel. However, I suspect that the answer would be as elusive as the same answer was for the DNS. The bottom-line is that it appears to be bandwidth and hardware limited. Just like the DNS. The architecture appears to be open-ended. I must confess that I know the DNS much better than I know BGP. The projected worst-case scenario *appears* to be artificial, given the evidence at hand. It doesn't follow that what *can* happen, *will* happen. The Sun could go nova tomorrow, but I'm betting that it wont. |> So I plead with you all, lets end this war of baseless |> claims and move toward a solution, by first determining |> at what point we need one, and then determining what it is. Realistic projected usage scenarios might be a good place to start. It's amazing how real requirements have a way of actualizing the problem. Let's get the proper horse/cart relationship, first. |> TTFN, |> -chris (who happens to be a pragmatist) -roeland (who realizes that business needs drive IT, not the other way around)

2 1

Performance monitoring package utilizing Cisco SAA
by Yu Ning 29 Aug '01

29 Aug '01

Hi nanog, I wonder if there is any third part IP network performance monitoring software utilizing Cisco SAA (Service Assure Agent) feature ? The package should be able to generate and publish performance & SLA report in web style (better with historical graph, like MRTG). BTW, if not utilize Cisco SAA what do you use for your backbone performance monitoring ? Thanks for any input. Yu Ning ____________________________________________ (Mr.) Yu Ning, Chief Engineer ChinaNET(AS4134) Sr. Sup.& New Sev. R&D Internet Product Dep. DCB, China Telecom Beijing, P.R.China +86-10-62072357/62072354 ____________________________________________

1 0

What is the limit? (was RE: multi-homing fixes)
by Martin, Christian 28 Aug '01

28 Aug '01

This is the umpteenth time that this type of thread and its spawn have been religiously fought out on NANOG. The camps are split between the doomsayers (Internet armageddonists), the pragmatists, and the laisez-faire who are continually walking on sunshine. Assertions are made, flames are thrown, people dodge and parry, and the war goes on. In the end, the armageddonists fortell the end of the Internet, the pragmatists portend that a solutin must be found, and the grazers simply don't get it or don't care because there is revenue on the line in a shrinking market. What we don't see is any real data that indicates who is right and who is wrong. The only empirical data shows a comparison between routing table growth and Moore's law, which doesn't amount to a whole hill of beans if there isn't a reasonable frame of reference to which we can make comparisons. For example, what is the state of the Internet routing system today, in terms of memory utilization and processing load? Most of my routers spend a majority of their processing cycles doing a whole lot of nothing (besides crash every so often because of cosmic radiation and other stellar phenomena), have copious amounts of memory, and process a couple of thousand updates a day under steady state (no link flaps internally). Under extreme circumstances (protocol implementation bugs, filtering leaks, etc), the routers enter into a state of hary-cary, but this is rare, and independent (in most cases) of the size of the table. So they are not by any means part of the current Moore cycle, but perhaps a few generations behind. So, I sit back and evaluate the data available to me and wonder, "Where does this all break? At what point does the routing system overheat, and what steps can be taken to prevent it?" I see a lot of answers to the latter, many which I agree with, but some of which I can't make an accurate judgement until the former is answered. To offer an analogy, what we are doing is standing in front of a bridge that says "Maximum Weight - Not Too Much Or It Might Collapse". The Armageddonists have formed a picket line in front of it, the pragmatists are inspecting the beams and footings, and the grazers are driving their 18-wheelers across, honking their horns, and swigging their favorite hop-juice. I think that what we need to do is have a fourth group, call them Internet Engineers for lack of a better word, come in and determine what the sign should read. At the same time, we have a fifth group, call them vendors, begin design on a new bridge that has known scaling limitations that we can all agree on. Finally, we have a sixth group, call them the IETF, come in and invent a flying car that doesn't need the bridge at all. So I plead with you all, lets end this war of baseless claims and move toward a solution, by first determining at what point we need one, and then determining what it is. TTFN, -chris (who happens to be a pragmatist) > -----Original Message----- > From: hardie(a)equinix.com [mailto:hardie@equinix.com] > Sent: Tuesday, August 28, 2001 4:39 PM > To: david.conrad(a)nominum.com > Cc: davids(a)webmaster.com; nanog(a)merit.edu > Subject: Re: multi-homing fixes > > > > drc writes: > > Micro-allocations and filtering are treating symptoms. The > underlying > > disease (rational route announcement policy) > > > I agree with David's analysis of the problem right up to this point; > from my pespective the underlying disease is the route > convergence/routing table growth issue. The route announcement > policy's rationality has to be judged in the light of this greater > pathology. It *is* the real problem, though, and we have to keep it > in mind to understand that any invocation of market forces, draconian > filters, or community-mindedness only delays the progress of the > underlying pathology. In a sense, they too are symptoms, however > rational they may appear in today's lights. > > Or as Randy puts, we're playing whack-a-mole here, and we're doing it > knowing it only buys us time. > > The underlying problem is real, and it will take time to develop a > real solution. Encourage your vendors to participate in the > appropriate working groups, tell them you'll spend money on products > that fix it, and be ready as an operator to help debug potential > solutions. It's important. > > End of pleading.... > regards, > Ted > > (Not speaking for Equinix; speaking for David. No wait, I > meant *to* David.) > > > >

1 0

RE: multi-homing fixes
by Roeland Meyer 28 Aug '01

28 Aug '01

|> From: John Fraizer [mailto:nanog@Overkill.EnterZone.Net] |> Sent: Tuesday, August 28, 2001 11:56 AM |> |> > Multihomed customers generate LESS technical support rather than |> > more? Maybe we should urge more people to multihome... |> |> "Multihomed customers generate LESS technical support rather than |> more?" Perhaps in an outage instance they do. When they |> have a routing |> issue, it can become a finger-pointing match between their |> upstreams and |> thus, it generates 100% more technical support for the upstream who |> doesn't have the problem. only until the mal-functioning provider is replaced.

1 0

Re: DNS Parser
by Paul Vixie 28 Aug '01

28 Aug '01

> Does anyone know of a simple script that will go through a list of BIND > primary files, or more and output a list of output like this: > > secondlevel.domain --> address > thirdlevel.secondlevel.domain --> address > > and so on for several thousand domain files. I agree with the comment that you ought to use AXFR rather than parsing zone files, since the zone files can have all kinds of irregularities that make it a complex job to parse them, whereas an AXFR client will have predictable output. Much as it pains me to recommend the use of "nslookup" by anybody for anything, it has a reasonable way of doing this: nslookup <<EOF | awk yada yada server $MASTER ls -t A $ZONE EOF If you prefer "dig" then you'll shortly be cursing me for its non-optional shorthand pretty-printing, but once in 1995 when I got done cursing myself for this misfeature, I wrote $BIND8/contrib/misc/normalize_zone.pl, as in dig @$SERVER $ZONE axfr | bind8/contrib/misc/normalize_zone.pl | grep ' IN A ' Hope this helps.

2 1

RE: multi-homing fixes
by Roeland Meyer 28 Aug '01

28 Aug '01

1 0

RE: multi-homing fixes
by Roeland Meyer 28 Aug '01

28 Aug '01

|> From: Leo Bicknell [mailto:bicknell@ufp.org] |> Sent: Tuesday, August 28, 2001 8:12 AM |> |> On Tue, Aug 28, 2001 at 08:00:40AM -0700, Sean M. Doran wrote: |> > I urge the rest of you to invoice him for your |> 50-cents-times-n, today. |> |> In the spirt of the market as of late.... |> |> Roland, you don't want Sean to route your prefixes, you want me to |> route them. As such I'm going to give you a deal, just 25 cents |> per prefix! |> |> (I'm sure no one else will want to price it lower. :-) Considering our current upstream arrangements, please respond to RFP posted at http://www.rotflmao.bid. At the moment, we are practicing safe exchange using NAT, with multiple providers, but we are not getting full satisfaction from the relationships. Not all of our services are being utilized to the full enjoyment of our customers. Some hardcore services, like SSL, are not even possible with these relationships. We are looking for two, potentially long-term, relationships that will culminate in mutual satisfaction, where we will be safely protected from any mis-judgements of either of the parties involved. We are looking for a bundled price that includes all connectivity, interchangably with either of the parties, or both. We are looking for two lowest bidders. We don't tolerate incest so those IP-addrs have to be as widely separated as possible, for at least two generations. Two ISPs with the same upstream wont cut it. Even if those upstreams share a common upstream, it is grounds for disqualification. We are looking for good lineage, there is just too much risk of inheriting downstream business problems and we have to protect the well-being of our current customers and future customers that we may both generate. Please direct bids to mailto:harry@palmpilot.rotflmao.bid.

1 0

Re: multi-homing fixed
by smd＠clock.org 28 Aug '01

28 Aug '01

| I've asked this of a number of people now, but how many providers | have multiple POP's in a city that are _completely redundant_? | That is, they can operate _fully_ with one POP out of service? The suitcase nuclear bomb that takes out my facility in one location is very likely to take out my other facility in the same metro area. And probably all the customers who would remotely care. | Even if they have two pops, many of those cities won't have redundant | long haul capacity. The bigger problem is actually that many of those cities will have zero customers who are willing to pay extra to be connected to a router in POP-A and a router in POP-B, and I know of no way to make such a connection cost the same or less than a single connection to only one of those routers. So, while it's _possible_ to make the Big Red Switches' states very nearly totally invisible to any customer, it's not often done. But, hey, deep-pockets people have found out that several suppliers are eminently capable of engineering (nearly) all the resilience and redundundancy that the deep-pockets can manage to pay for... Sean.

6 6

Re: multi-homing fixed
by Rachel Warren 28 Aug '01

28 Aug '01

> > A bomb threat is definately something to worry about, though. > > Once upon a time, while talking with a customer about a particular LA > datacenter's fault tolerant features (you know, generators, UPS, HVAC, > diverse fiber entrances, etc...), they very calmly asked me what > procedures we had in place in the event that a major earthquake struck > the southland and dropped LA into the ocean or otherwise put the city > underwater. I told them very bluntly that if an earthquake of that > magnitude were to hit LA, I would *not* be overly concerned with their > servers/circuit/etc., assuming I was still breathing. They were quite > taken aback. ;) I guess I should have been more clear. I'm not talking about nuclear bombs. I was talking about regular explosives (for lack of better wording) - pipe bombs and the latter. The type of quake you are talking about is up in the nuclear-bomb stratosphere, and that's not something that would keep me up at night worrying. Plus, I live on the east coast. We don't have to worry about these things called earthquakes for the most part. ;-) Rachel -- Women and elephants never forget. - Dorothy Parker

3 2