- NANOG - lists.nanog.org

RE: Randy Bush et al
by Vincent J. Bono 12 Sep '97

12 Sep '97

Well. After getting back from a trip I find, what? That Mr. Bush has a bug up his ass. Bottom line: - We do default route. Into a Sprint T3 that we pay for. :-) - We do not pass no-next-hop-self routes - Check around, if someone was as bright as they think they are it would be obvious. - We only peered with Verio in the first place becuase someone other than Randy contacted us - We formerly sent a lot of traffic to Verio because it's customers love porn, and we have several rather large web farms downstream. The number listed in whois is bad, sorry, it happens. But the number on our web site is not. When there is a problem and we are involved, I say so. There was no problem here and we won't miss Verio peering one bit. Vinny vbono(a)comstor.com 888-624-8700 NOC 702-802-0222 ext 3148 voice BTW: Below is the "snotty" message that was sent to our NOC and it's reply. Who was snottier than who? ------- Forwarded Message Follows ------- Date: Thu, 11 Sep 1997 02:34:58 -0400 From: Matt Luebke <mluebke(a)mclean.mai.net> To: Randy Bush <randy(a)verio.net> Cc: noc(a)verio.net, noc(a)mai.net Subject: Re: you have been depeered Randy Bush wrote: > your peering at mae-east is very unacceptable. the phone number in whois is > answered by a modem. so you have been de-peered with 2914. > > randy Our peering at mae-east is very acceptable to us. However we find that Verio brings nothing to our table. Thank you and Goodbye. Matt

2 1

Re: too many routes
by Sean M. Doran 12 Sep '97

12 Sep '97

"Kent W. England" <kwe(a)geo.net> writes: > But you didn't actually do it then. Ok, true. > And the reason they started noticing it later was because > only then did you actually implement the filters, without > further notice, instead of much earlier. The surprise was > due to the fact that you did it without further notice > and not the fact that you did it. Hey, people should take notes when I rant. However you're right and as I said a long time ago it probably would have been helpful to try to coordinate things a little better. On the other hand, the unilateral action completely eliminated any argument that there was collusion between Sprint, MCI and the rest, which maybe was a good thing at the time. That people still yell about this is sort-of funny. Do you think people would be screaming less about allocation policies if I had been doing a count-down between the final warning and the actual implementation? (That's an actual question with obvious future operational impact rather than a rhetorical point. Really.) Sean.

1 0

spam and CIDR blocks
by Jeremiah Kristal 12 Sep '97

12 Sep '97

I know everyone is tired of IP address issues, and even more tired of spam, but I think this has some operational content. I'm sure that a good number of network operators have set up null0 routes for some of the more annoying spam sites, and I'm pretty sure that many people are sending whole /24s and maybe even larger blocks to null0 because of lack of response by the spam sites. What is going to happen when the spammers find that they are unable to reach 30% of their mailing list because of null0 routes? The spam sites just renumber into another network. Eventually the spam sites, or their upstream provider, will have to request more addresses from Arin, and this is where we might be able to gain another tool to fight spam. All address allocation requests have to be justified, I think that we can use this to prevent additional allocations to spam sites. The reasoning is that spam sites are not using their previously allocated space efficiently, and have poisoned their existing blocks enough so that even if they were to give them back to Arin, Arin would be in a very perilous legal position if they were to re-allocate these block. Basically, once an address is associated with spam, it is not going to be globally reachable until all null0 routes for it are removed. I'm open to any and all comments, suggestions, corrections, or flames on this. Jeremiah

3 3

Re: too many routes
by Sean M. Doran 12 Sep '97

12 Sep '97

Sanjay Dani <sanjay(a)professionals.com> writes: > There are backbone providers and there are providers of specialized > ISP or hosting or security etc. services that need independent* IP > address space and do not have to waste resources on building a private > "backbone". NAT. Sean. (read an old message by Paul Vixie prior to some NANOG that wasn't worth going to really where I think he might have said pretty much the same things he wrote) P.S.: > I had thought predicting consolidation in the Internet services > market was an exclusive realm of only the clueless "market research" > firms. Even they seem to be wisening up. "Internet services" is a rather broad term. I think the "consolidation is coming" crowd is looking more at transport. People watching UUWHO recently might see some justification for the "consolidation is coming" predictions. On the other hand there are models which are attractive beyond the "we run a backbone and dialup and web hosting and this and that and this and that and what else is on your checklist, oh yah, we do that too or are buying up a company that does it already" as such a model tends to scale poorly vs. the number of working brain cells in any given organization needed to offer reliable and coherent service over time.

4 4

NAT (was Re: too many routes)
by Sanjay Dani 12 Sep '97

12 Sep '97

>From smd(a)clock.org Thu Sep 11 13:13 PDT 1997 >"Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> writes: >> Perhaps I misunderstood Sanjay, Sean, but I believe his concern was >> that the addresses _not be the property of an upstream (ie: backbone) >> provider_ to provide flexibility of connection choice. > >Welcome to the new Internet, which is being built. > >Two of the fundamental concepts that are important: > > -- IP addresses are not forever > -- IP addresses are not end-to-end Jay paraphrased my concerns correctly. NAT does not give any incentives to an independently addressed provider (that does not own global physical infrastructure) to switch to using "multiple outward-facing addresses [from upstream providers' address space]". Hey, if I were a dreamer, I wouldn't count on those clueless, bandwidth stealing, soon-to-be squashed or consolidated, small providers, to help me bring through my vision ;-) No disrespect meant. I do enjoy reading and learning from the long, well written articles of the experienced folks out there. However, a small provider (one that believes they engineer better Internet throughput for clients' web servers than some of the big boys), would rather watch the bottomline. Sanjay.

1 0

Re: too many routes
by Peter Lothberg 12 Sep '97

12 Sep '97

Alan writes; > There is another router vendor who has OC-12 router interfaces ... > There is a choice in the market today for OC12 router interfaces. > -alan Let's try to define the terminolog; oc3 3*sts-1 (=3*ds3) oc3c 3*sts-1 concatenated (vc4, or one container 1920 bytes) oc12 12*sts-1 (=12*ds3) oc12c 12*sts-1 concatenated (can carry a STM-4, 7680 bytes) Most (all?) data equipment uses ocXXc chanels, so I asume that is what we are talking about. ATM OC12c-celltax = 'oc9' worth of IP traffic (467M) POS OC12c-frametax = 'oc11' worth of IP traffic ((580M) This is before we look at system performance, routers understand IP, Switches does not. -Peter

1 0

Re: not rewriting next-hop, pointing default, ...
by Sean M. Doran 12 Sep '97

12 Sep '97

rja(a)corp.home.net (Ran Atkinson) writes: > Letting LSR in two hops lets outsiders trying to debug (e.g. some > routing problem) at least perform first-level fault-isolation > so they know whose NOC to call for further debugging assistance. > So I view the 2-hop notion as an attempt at "reasonable > compromise". Cool, and I now view the 2-hop notion as the first reasonable argument for encouraging people to totally flatten their network into a full mesh. Security policy should not under any circumstances prevent the Internet as a whole from functioning reasonably well, scaling decently, or make discovering and diagnosing problems any harder than it already is. Your opinion may vary with mine, but I am solidly in line with Randy's suggestion that enabling LSRR on backbone routers should be a requirement for peering. (This is not surprising as I used to require it of a couple of peers in a previous life, because in practice it is unfortunately an irreplaceable diagnostic tool). Sean.

1 0

Re: too many routes
by Sean M. Doran 12 Sep '97

12 Sep '97

"Joseph T. Klein" <jtk(a)titania.net> writes: > Having hopelessly screwed up my facts ... I was trying to make a point here. > So the router was worse than I thought. Retaing policies that exclude > new players because of AGS+'s inability to handle large routing flaps > just does not cut it. > > Sprint imposed this at a time when 7000s with 64M of memory where available. > Will /19 remain policy when the majors are running with Cisco 12000 and GRFs? I am not sure what point you are trying to make here. If you feel like grinding this axe again, I am more than willing to play in my fleeting spare moments. An AGS+ with a CSC/4 has exactly the same CPU as a 7000 with an RP. In fact, AGS+ performance is slightly higher in some cases because of some interesting design features of the 7000 and the other AGS+ downgrade path routers (notably the 7500 series). I did not put in a filter on /18s (yes it was /18s initially, and got changed to /19s after much discussion with the registries, especially Daniel Karrenberg at RIPE, in an attempt to harmonize Sprint's filters with slow-start allocation policies) because of the AGS+ difficulties; all the routers that were carrying full routing at the time had 64Mbytes of RAM, and the two remaining AGS+es were there to implement historical things done principally for ICM (like a STUN connection and the PANAMSAT router). What triggered the filter was the observation that in the blocks freshly allocated by all three registries were very poorly aggregated. More annoyingly, those allocated to Sprint's principal peers (most notably Internet MCI) demonstrated the worst aggregation; in one case a /14 was announced almost exclusively as prefixes no shorter than 19 bits. After spending some time trying to chase this down -- with some success, as in the case of PSI's then newest blocks, but not in the case of Internet MCI, who did nothing -- I decided to issue a warning that once the /8 that the InterNIC was using had filled up (and after some discussion, once RIPE and APNIC proceeded to allocate from new /8s), I would begin filtering all new unicast addresses to ignore Sprintward announcements of any prefix longer than 18 bits. Moreover, I also announced that I would filter out any subnets of historically classful As and Bs. The warning was several months old when people started noticing that they couldn't reach things behind Sprintlink, and alot of time was spent explaining to people that this shouldn't have surprised them at all. Some changes happened, notably I dropped down to 19 bits, the registries began to explain to people that anything longer than that almost certainly would not be routable, and that allocation != routing. This measurably flattened the growth curve of the number of prefixes seen by default-free routers, changing it from a nearly exponential function to a linear one, with the slope below that of Moore's law. In other words, it probably as much as the initial introduction of supernetting as a concept acted to keep the Internet scalable while it continued to use the current set of routing protocols. > If aggregation is the goal then mechanisms should be developed > for exchanging CIDR blocks so the address space can be > re-packed. It is time for everyone to learn a term that unfortunately I did not invent: IPv4ever. NAT and other clever gatewaying effectively provides a mechanism to extend the address lifetime expectancy not only of the IPv4 unicast address space in general, but of any given host in particular. That is, there are now mechanisms which can hide address changes from hosts that deal with address changes badly, while at the same time there is increasingly good software to assist with renumbering hosts. There are mechanisms evolving which ultimately should lead to nearly any given unicast subnet of 0/0 to be perceived by everything else as having a different number than things within that subnet believe. Moreover, there are also mechanisms evolving which will cause nearly any given unicast subnet of 0/0 to renumber itself so that all the numbered entities under that subnet renumber into a different unicast subnet of 0/0. This alone should give rise to maximal aggregation, and if combined with schemes which overload some addresses or which simply compress sparsely populated large subnets into densely populated smaller ones, should eliminate a large percentage of address waste. In other words, the mechanism(s) you allude to are being worked on. I would like to see them applied to the swamp within the next year or two. The "IP addresses never change within the lifetime of a session" and "IP addresses are end-to-end" crowds who have misthought a number of protocols will probably fight tooth and nail to see this never happen. Mind you, they are mostly the same people who fought tooth and nail against the idea of renumbering in the first place, so one can expect roughly the same type of "discussions". > The /19 policy is archaic. It creates an obstacles and > only partly resolves the problem. Fixing holes in CIDR > blocks, exchanging fragmented blocks for contiguous > blocks, and cleaning up "The Swamp" can do more for the > stability and size of the routing table. If you have an implementation of something Sprint and its competitors who now do precisely the same filtering can buy that can cause the swamp to be aggregated into a small handful of prefixes from their point of view, then I can point you at people who would be happy to sign a cheque. The only real problem I saw in the implementation of the /19 filter was the bad press generated by people who refused to listen to registries' warnings that long prefixes probably would not be globally routable, and possibly the lack of a tariff which would have allowed people with money to purchase exceptions in the Sprint filters. > BTW - If you use a route server to do the dampening and calculation of peer > routes you can even make a wimpy CPUed 7000 handle backbone traffic. The wimpy 7000 still has to receive at least one copy of the NLRI, and process changes into the forwarding table(s). As the number of prefixes increase, even if the level of "background" noise (the rate at which a large set of prefixes demonstrate instability that is considerably less than that which would be prevented even by very aggressive route dampening) were to remain constant, you require more CPU even in the simple case of receiving and installing modified forwarding tables. In the absence of any feedback mechanism that holds down the total number of globally visible prefixes, the increase in CPU requirements could easily outstrip Moore's law and overwhelm even state-of-the-art processors in a matter of time. Note that the liklihood of keeping up with the economics of dealing with things which are CPU bound and ill suited to parallel processing and which grow along the same slope or on a slightly greater slope than Moore's law is small. This describes the amount of BGP processing required prior to the installation of the first prefix-length filters at Sprint's border routers. I was always open to suggestions that would accomplish the same result, and helped push Cisco to develop two of them (a large cleanup of some of their BGP implementation's processing and an implementation of something very close to Curtis Villamizar's route flap dampening algorithm), however I have yet to see suggested something that eliminates the need for such filters that is readily deployable and which will keep the slope of processing requirements below that of processing capability. I still am, I belive my successors at Sprint and like-minded people at other ISPs who implement prefix-length filtering are too. Until such a thing emerges, however, I continue to believe that inbound prefix-length filtering is a good policy that should be implemented universally. Sean.

2 1

new CAIDA tool: Mapnet (warning: of possible operational utility)
by k claffy 12 Sep '97

12 Sep '97

what: new tool from CAIDA group why: (original motviation) visualization of Internet traffic and topologies is an important next step in the global evolution of the net. as a result, the cooperative association of internet data analysis (caida) is working on a new tool -- mapnet where: www.caida.org/Tools/Mapnet/Backbones how: mapnet will permit visualization of the infrastructure of multiple backbone providers simultaneously. it also allows individual isps to update and correct information about their infrastructure, either via a GUI or ascii mail in template form. (see mapnet update at www.caida.org/Tools/Mapnet/Update) the current prototype version relies on third party data (boardwatch, with some updates and clarifications) each of the commercial backbones and government provided data about federally funded r&e and mission-oriented backbones. caida staff have translated topology information provided in the last boardwatch release into lat/long specific nodes on a global map. the data are useful in a general sense, any data from a 3rd party obviously requires authentication. we recognize that much backbone-specific info is outdated or wrong and invite each provider to designate an authorized individual to periodically update their topology data. note that we include link, ISP, bandwidth, lat/long of cities, and peering information if available, as well as contact folk for the network in question. the availability of a tool like mapnet will assist with macro-level understanding of the internet, with standardizing public depiction of isps' infrastructure, and with communicating complicated peering information. (for those isp's willing to share in such an endeavor) we would appreciate any feedback: comments, constructive criticism, suggestions. please contact me or send email to brad huffaker (lead developer, mapnet) at mapnet(a)nlanr.net. tnx k caida kc(a)caida.org nlanr kc(a)nlanr.net

1 0

Re: too many routes
by Sean M. Doran 11 Sep '97

11 Sep '97

Vadim Antonov <avg(a)pluris.com> writes: > Sprint never used cisco 4000s in the backbone. Just FYI. True. The only one I ever remember was the DANTE access router which was dropped in place before AS-path prepending in software came about, and that wasn't a backbone router by any stretch of the imagination. There may have been one deployed to handle NACSIS or some other odd case at some point, however I don't remember it concretely. > Historically, memory limitation was because CSC/4 board in AGS/+ > routers had memory soldered in. The box was absolute top of the line > when it started to fall over. Sprint, in fact, was in an OK position since it was possible to eliminate full routing on most of the AGS+es in relatively short order once the memory problem became more apparent. I believe you and I got to the point where none of our AGS+es had full routing before people like JANET started having regular problems and had to start dropping routes from places like PSI entirely in order to have any connectivity at all. The AGS+ -> 7000 migration was a conceptual disaster, since the RP+SP combination simply didn't perform well under load. The SSP made things happier, particularly when things like selective packet drop were implemented, and this in essence led to Peter's frequent (and pretty accurate) complaint that the initial introduction of the 7500 compared to a 7000 + RP + SSP was a step backwards. (Several people who used to be at cisco, and some who still are, also have been heard making that complaint from time to time...) > Can you spell "economies of scale"? Or "using fiber at cost means > owning the fiber"? If you want to play the backbone game you've > got to own long-haul transmission facilities. And if you own such transmission facilities you have to hope that your competitiveness police don't force you to separate your transmissions facilities from your value-added services, and require the transmissions people to offer consistent pricing to all parties including the value-added services people. Of course, if bandwidth becomes much cheaper than you had bargained for initially, it could be a disadvantage to be trapped into using your own company's transmissions facilities with a requirement of a decent ROI, so it kinda cuts both ways. Sean.

2 1