September 2001 - Test - lists.nanog.org

black hat .cn networks
by Dan Hollis 08 Mar '02

08 Mar '02

http://wired.com/news/politics/0,1283,43437,00.html Time to drop AS4134. -Dan

16 17

Code Red -> Router Memory depletion?
by Mike Lewinski 22 Nov '01

22 Nov '01

We've seen two routers experiencing problems this AM that appear to be related to client swervers infected with the IIS Code Red virus. I say appear because of the timing with cpu profiles on downstream routers where infections broke out, but I don't have any direct evidence. The first one was a border router: Jul 19 08:00:47 5093: 2w5d: %SYS-2-MALLOCFAIL: Memory allocation of 65540 bytes failed from 0x603BF35C, pool Processor, alignment 0 Jul 19 08:00:47 5094: -Process= "BGP Router", ipl= 0, pid= 86 # sh ver uptime is 4 hours, 46 minutes System returned to ROM by bus error at PC 0x603BFCFC, address 0xFFFFFFF0 at 05:57:21 UTC Thu Jul 19 2001 The other one is a client aggregation router Jul 19 12:02:49 192: %SYS-2-MALLOCFAIL: Memory allocation of 1964 bytes failed from 0x314DA4A, pool Processor, alignment 0 Jul 19 12:02:49 193: -Process= "OSPF Router", ipl= 0, pid= 32 (This router is still functioning, but not allowing any incoming connections on telnet). -Mike

4 5

slightly OT : versign complaint department
by beldridg＠best.com 03 Nov '01

03 Nov '01

i've been trying to add a pgp key to the verisign/netsol database for the past two weeks. i've sent four messages, opened three web help requests, and spent three hours on the phone with their helpdesk. they know less than their customers about their own procedures and web documentation for adding keys for PGP guardian auth. i guess this is the problem with government sanctioned monopolies. i'd like to do something about it. does anybody know if there is a formal board or governing group that i can send my grievances to? - brett

10 11

OT: ARIN contact
by Grant A. Kirkwood 19 Oct '01

19 Oct '01

I'm trying to find someone who can help me with an ARIN request. If anyone here can help, please drop me a line. Thanks. Grant -- Grant A. Kirkwood - grant(a)virtical.net Chief Technology Officer - Virtical Solutions, Inc. http://www.virtical.net/

3 3

RE: The Gorgon's Knot. Was: Re: Verio Peering Question
by smd＠clock.org 08 Oct '01

08 Oct '01

| But, we all do, or we aren't talking BGP. The requirements here are not that | large. A Cisco 2651 with 128mb is a valid BGP speaker, these days. That's a | cheap router, indeed. And, router memory is dirt cheap. BGP is based on TCP and thus has the fun property that a big set of changes will pile up in front of a connection to a peer that is slow at processing inbound announcements & withdrawals. The slower you are at processing updates, the more likely you are to be out of sync with reality in such a way that you will begin to notice that you are forwarding some packets the wrong direction into loops or black holes. The slower you are, the greater the backlog you have to chug through to catch up, making you busier for longer periods, which in turn leads to greater backlogs. Slow down too much and the other side will help you out by resetting the session. We've seen this in the past - it's caused MASSIVE outages affecting nearly EVERYONE for hours at a time. Or you can say "smd is protecting his own personal interests" and carry on arguing the equivalent of "ANYBODY can build a modern router using a sufficient amount of ROM" which simply underlines the point that dynamic global routing is an expensive luxury that many people have gotten used to. | The common good is | promoted by allowing these folks to multihome, which would be effectively | prohibited if all networks implimented verio-style filter policies. Think of it as a catalyst for more experimentation with alternative ways of multihoming without the use of BGP. There are several which exist now, and several which are being discussed in multi6 which could be made to exist now without universal software changes. Some brainstorming could result in several other approaches, more or less generalized, but what's the point when the normal cheap-seeming thing to do is to announce CIDR holes to the world? | The number of folks who multihome is large and growing. We should support | this by promoting relatively open filtering policies and allowing /24s to be | truly, globally routable. I think we should encourage people to introduce individual /32s into the network and flap them around a bit, to force some issues which have been avoided becauase first Sprint and then Verio have been willing to take a bunch of negative PR in the act of self-protection (which has the side-effect of protecting alot of people who generate the negative PR, and everyone else). Sean.

8 11

Verio Peering Question
by P R 03 Oct '01

03 Oct '01

I have a quick question about Verio's public peering policy. What is the smallest size prefix that Verio will accept from public peering? The reason why I ask is because my company informed me that Verio will not accept anything from a Class A address with a prefix smaller than a /20 from pubic peering. Is that true? If so, how do small ISP's work around this? Peter Rohrman Network Engineer Un-Named ISP _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

38 69

Re: Verio Peering Question
by Paul Vixie 03 Oct '01

03 Oct '01

> > there has to be a limit. > > A limit is needed, but the filtering method in question to me essentially > says this: > > if you have 64.x.x.x/15, slice it into as many /20's as you can and bloat > as much as you want.. we feel this is an acceptable practice. i strongly doubt that the policy was formulated on that basis. it may or may not be equivilent to what you said, but you have not described anyone's (whom i'm aware of) actual motivations with the above formulation. > Yet, if you're a legitimately multihomed customer wants to push out a > single /24 (1 AS, 1 prefix) that is not considered acceptable. actually there's a loophole. nobody filters swamp /24's that i know of, since so much of the oldest salty crusty layers of the internet are built on those. > The only kind of prefix filtering I would want to implement is something > that can accomplish: > > 1. Define threshold, say /20 or /18 or hell even /8. > 3. all prefixes longer than threshold get held until entire tables are > loaded > 3. start looking at the longer prefixes across the entire ipv4 space > starting with the longest and finishing at threshold+1 > 4. if prefixes longer than threshold appear as part of a larger aggregate > block that *originate* from the same AS, drop. > 5. if prefixes longer than threshold originate from a different AS than > the aggregate, accept. i wish you luck in implementing this proposal. i think that folks with multivendor global networks will find it completely impractical, but you can probably pull it off in a regional zebra-based network with no problem. > This way I could get rid of redundant information yet at the same time not > cause any trouble to smaller multihomed customers. I'm not saying that we > should allow /32's to be pushed everywhere either. As you said there has > to be a limit, and /24 seems to be a pretty good one if something along > the lines of the above mentioned filtering algorithm could be used. let's do some math on this. swamp space is more or less 192/8 and 193/8 (though parts of other /8's were also cut up with a pretty fine bladed knife). if every 192.*.*/24 and 193.*.*/24 were advertised, that would be more prefixes than the entire current table shown in tony bates' reports (~100K vs 128K). that is of course just the existing swamp. and it would be hard to handle but even harder to prevent since there's no real way using today's routers to say "accept the current /24's in 192/8 and 193/8 but don't allow new ones". this is the bogey man that gives people like smd nightmares. then there's everything else. if 20 /8's were cut up into /24's then tony bates' report would have 1.3M more things in it than are there today. if the whole IPv4 space were cut up that way then we'd see 16M routes globally. those numbers may seem unreasonable, either because current routers can't hold them, or because current routing protocols would never be able to converge, or because you just can't imagine humanity generating even 1.3M /24's let alone 16M of them. multihoming is a necessary property of a scalable IP economy. actually, provider independence is necessary, multihoming is just a means to that end. if you don't think there are more than 1.3M entities worldwide who would pay a little extra for provider independence, then you don't understand what's happened to *.COM over the last 10 years. in that case i'll simply ask you to take my word for it -- you make 1.3M slots available, they'll fill up. i do not know the actual limit -- that is, where it ends. i know it's going to be higher than 1.3M though. i also know that the limit of humanity's desire for "provider independence without renumbering" (or "multihoming") is currently higher than what the internet's capital plant, including budgetted expansions, can support. and i strongly suspect that this will remain true for the next 5..10 years. > I'm sure in reality there's many reasons this would not be able to be > implemented (CPU load perhaps) but it would atleast do something more than > a "gross hack" that nails some offenders, not all by any means, and > impacts multihomed customers who are only a portion of the problem that > the current prefix filtering solution does not solve. people are out there building networks using available technology. forget about CPU load and look at delta volume and convergence. the "internet backbone" is not fat enough to carry the amount of BGP traffic that it would take to represent the comings and goings of 16M prefixes. 1.3M is probably achievable by the time it comes due for natural causes. do any of our local theorists have an estimate of how much BGP traffic two adjacent core nodes will be exchanging with 1.3M prefixes? is it a full DS3 worth? more? less? every time you change out the capital plant on a single global AS core in order to support some sea change like 10Gb/s sonet or 200K routes, it costs that AS's owner between US$200M and US$1B depending on the density and capacity. bean counters for old line telcos used to want a 20 year payback (depreciation schedule) on investments of that order of magnitude. today a provider is lucky to get five years between core transplants. bringing the period down to two to three years would cause "the internet" to cost more to produce than its "customers" are willing to pay. so in the meanwhile, verio (and others who aren't mentioned in this thread) are using the technology they have in order to maximize the period before their capital plant becomes obsolete. as i said in a previous note, they are certainly balancing their filters so that filtering more would result in too many customer complaints due to unreachability, but filtering less would result in too many customer complaints due to instability. anyone who wants the point of equilibrium to move in the direction of "more routes" should be attacking the economies which give rise to the problem rather than attacking the engineering solutions which are the best current known answer to the problem. in other words go tell cisco/juniper/whomever your cool idea for a new routing protocol / route processing engine / cheap OC768-capable backplane and maybe they'll hire you to build it for them.

4 3

RE: Verio Peering Question
by smd＠clock.org 02 Oct '01

02 Oct '01

| While I certainly support the idea of usable micro allocations, and have | voiced my support on various ARIN mailing lists for it, it should be | remembered that the same folks who generally espouse restrictive filtering | policies are also those who voice the greatest opposition to a realistic | micro allocation policy. Their argument normally underscores the somewhat | facetious issue of routing table size. In hopes of correcting this somewhat, let me say that not only am I a strong supporter of filtering, I have also suggested fairly seriously to some registry-types that it is fair to allocate individual /32s as necessary to contain address consumption. That is, the registries are correctly focusing on that resource-management, and should spend energies on reclaiming wasted space (hello MIT!) rather than on managing multiple scarce resources. ISPs can and will filter or otherwise penalize users of long and/or flappy prefixes as dynamicism forces them to do so. Since filtering can become REALLY aggressive if and as necessary, nobody should worry that ISPs will be so overwhelmed that the RIRs have to help out with this problem. | Ad hominem attacks against individuals [are bad] But but it's open season on "folks" who make "facetious" arguments? Sean.

5 4

Provider Bypass
by Christopher Wolff 01 Oct '01

01 Oct '01

Dear List: I have a customer that has a 3 meg link into my backbone providers network. Unfortunately they are not getting anywhere near 3 megs between their 3 meg link and my 100meg direct connect over this backbone network. (Lucky to get 1 meg) The existing provider is 'reluctant to reroute traffic over a more optimal link for 1 customer'. (I'll keep my venting to myself on this one..) Lets say I add another provider that has a peering point 12ms away from this customer. Is it possible to route this traffic through the alternative provider? I guess the easy solution would be to advertise only this customers specific network to the alternative provider. I know this is a vague question, just would appreciate some opinions and thoughts. Regards, Christopher Wolff, VP, CIO Broadband Labs http://www.bblabs.com

2 1

slightly OT : versign complaint department
by Bohdan Tashchuk 01 Oct '01

01 Oct '01

> i've been trying to add a pgp key to the verisign/netsol database for the > past two weeks. i've sent four messages, opened three web help requests, > and spent three hours on the phone with their helpdesk. they know less > than their customers about their own procedures and web documentation for > adding keys for PGP guardian auth. > i guess this is the problem with government sanctioned monopolies. Heh, heh, you can always complain to ICANN, another govt sanctioned monopoly. The REGISTRY is a monopoly. You have your choice of REGISTRARS. Melbourne IT is the registrar for my two (wow, whoopie!, two) domains. I can access inww.com site thru my browser, using a supposedly "secure" connection. The certificate presented by Melbourne IT is signed by Verisign! :-) It takes me 2 minutes to make a change, not two weeks. Let's not debate the limitations of this alternate security proceedure or this will be more than "slightly" off topic. > i'd like to do something about it. Vote with your dollars and with your feet. Change registrars. I apologize if you *ARE* are a registrar trying to deal with the registry. In that case, bend over and grab your ankles. Because you're getting screwed and there's nothing you can do about it. > does anybody know if there is a formal board or governing group that i can > send my grievances to? For $35 Melbourne IT will solve your problem. :-) Seriously, people, I can't for the life of me understand why anyone continues to do business with NetSol if there are so many better alternatives. Let NetSol execs cry over their $40 stock price, wishing it was back over $200. In the meantime let them know thru their pocketbooks that they should spend less time calculating the value of their stock options and spend more time running their business in a customer friendly manner. If everyone voted with their dollars, then NetSol would quickly improve or VRSN would soon be a $4 stock. Because that's about all it would be worth if their only revenue source was their govt mandated $6 "wholesale" registration fee. BTW I chose Melbourne IT because of their plain language domain name registration agreement. None of this crap about the registrar being able to change the terms at will. Only ICANN can do that to me.

2 1