- Test - lists.nanog.org

Re: Has PSI been assigned network 1?
by Vadim Antonov 30 Apr '95

30 Apr '95

FYI -- Sprint never submitted NACRs on behalf of customers, for purely legal reasons. As common carrier Sprint is legally prohibited from enforcing anything related to contents of communications, hence it couldn't enter legal agreements on AUP-compliance in regard to customer traffic. So, we HAVE to pass thru all NACRs (and don't forget that 1800 has most of Europe to care about). --vadim >From sjr(a)merit.edu Thu Apr 20 02:14:32 1995 Received: from tiny.sprintlink.net (tiny.sprintlink.net [199.0.55.90]) by titan.sprintlink.net (8.6.9/8.6.9) with ESMTP id CAA22156 for <avg(a)titan.sprintlink.net>; Thu, 20 Apr 1995 02:14:31 -0400 Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by tiny.sprintlink.net (8.6.9/8.6.9) with ESMTP id CAA22402 for <avg(a)sprint.net>; Thu, 20 Apr 1995 02:14:29 -0400 Received: from localhost (sjr@localhost) by home.merit.edu (8.6.12/merit-2.0) with SMTP id CAA21817; Thu, 20 Apr 1995 02:14:26 -0400 Message-Id: <199504200614.CAA21817(a)home.merit.edu> To: Vadim Antonov <avg(a)sprint.net> cc: HANK(a)taunivm.tau.ac.il, curtis(a)ans.net, guy(a)ghost.uunet.ca, jerry(a)fc.net, nanog(a)merit.edu, prs(a)isi.edu Subject: Re: Has PSI been assigned network 1? In-reply-to: Your message of Wed, 19 Apr 1995 18:49:39 EDT. <199504192249.SAA20468(a)titan.sprintlink.net> Date: Thu, 20 Apr 1995 02:14:25 -0400 From: "Steven J. Richardson" <sjr(a)merit.edu> Status: R Vadim: > Date: Wed, 19 Apr 1995 18:49:39 -0400 > From: Vadim Antonov <avg(a)sprint.net> > To: HANK(a)taunivm.tau.ac.il, avg(a)sprint.net, curtis(a)ans.net, guy(a)ghost.uu net.ca, jerry(a)fc.net > CC: nanog(a)merit.edu, prs(a)isi.edu > Hank Nussbacher <HANK(a)taunivm.tau.ac.il> wrote: > > >The e-mail interface > >of NACRs is close to uselessness, and too big headache to deal with. > >Waiting time on processing is simply ridiculous. > > >I've been sending updates to auto-dbm(a)ripe.net for the past 2 years > >with no problem. > > You don't have to keep a full-time engineer just to handle > NACRs, do you? Please be fair; most of this is a problem which Sprint brought on itself through poor follow-through with an allocation policy which you and I discussed on the phone a quite a while ago. To be clear about what is going on, let's review the history. I called you a long time ago (about a 1.5 years ago) and mentioned that it would be a lot easier on your NACR person (the pre-Lisa-Carlson person, as I remember) if you would: - decide on a consistent (net announcement ["aslist"] + AUP) for some large aggregates of IP address space, - register (NACR) those aggregates, - sit back and assign customers of like policy out of these pre-existing aggregates. Note that these customers would NOT require a NACR. You agreed and set up three /16 aggregates of what had been Class-C IP address space. From that time on, there has been a "drift" in policy away from the aggregate policy, which shows that the procedure for assigning nets from Sprint-controlled IP address aggregates was somehow ignoring what you set up. If your lead had been following by whatever internal procedures Sprint uses, then there would have been no need to NACR any customers who had policy which matched one of those aggregates. When new interconnection points were added, the aggregate's policies could have been updated, automagically updating the policy of all of the members of the aggregates. Currently, the state of Sprint policy is shown by the fact that, out of 118 "/16" aggregates, for instance, there are 2580 included prefixes which have policy which does NOT match that of the aggregates. Here's the profile: 188 "/16" Sprint aggregates have 26 different policies among themselves. These 188 aggregates include 2580 more-specific prefixes which have their own policies which differ from the /16 prefix of which they are a part. Of these 2580 prefixes, 2255 (87.4%) are completely due to Sprint (i.e., they are not caused by prefixes which have moved to have a primary AS which is not 1239, 1240, or 1800). These 2255 prefixes are contained within 65 of the "/16" aggregates (34.6% of the 188 total "/16" aggregates). Of these 65 large aggregates: 21 have 1 different policy 15 have 2 different policies 8 have 3 different policies 8 have 4 different policies 6 have 5 different policies 4 have 6 different policies 1 has 7 different policies 1 has 8 different policies 1 has 9 different policies If you sort all of these policies, you find that they can be summarized as follows: Number of: ----------------------------- more-specific "/16" aggs prefixes with in which they policy diffs are found Net announcement policy ----------------------------------------------------------------------------- 24 4 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 253 20 1:1239(144) 2:1800 185 19 1:1239(144) 2:1800 3:1239(218) 2 1 1:1239(144) 2:1800 3:1239(218) 4:210 5:209 2 2 1:1239(144) 2:1800 3:1239(218) 4:3561(11) 5:3561(218) 6:685 7:73 8:101 1 1 1:1239(144) 2:1800 3:1239(218) 4:3561(218) 5:93 22 4 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 3 1 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 5:701 10 4 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5 4 1:1239(218) 2:1239(144) 3:1800 35 6 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 149 18 1:1239(218) 2:1800 3:1239(144) 2 1 1:1239(218) 2:1800 3:1239(144) 4:3561(218) 4 2 1:1239(218) 2:1800 3:1239(144) 4:3830 3 1 1:1240 2:1800 3:1239 12 1 1:1800 130 6 1:1800 2:1133 3:1239(144) 1 1 1:1800 2:1133 3:1239(144) 4:1674 942 32 1:1800 2:1239(144) 20 1 1:1800 2:1239(144) 3:1133 16 4 1:1800 2:1239(144) 3:1133 4:1674 189 20 1:1800 2:1239(144) 3:1239(218) 1 1 1:1800 2:1239(144) 3:1239(218) 4:701(147) 5:701(134) 5 1 1:1800 2:1239(144) 3:1740(135) 1 1 1:1800 2:1239(144) 3:2149 4:174 122 15 1:1800 2:1239(218) 3:1239(144) 1 1 1:1800 2:1239(218) 3:1239(144) 4:1321 1 1 1:1800 2:1240 28 4 1:1800 2:1240 3:1133 4:1674 70 4 1:1800 2:1879 3:1133 4:1239(144) 3 1 1:1800 2:297(145) 3:297(144) 4:372 5:1133 6:1239(144) 6 1 1:1800 2:701(147) 3:701(134) 6 1 1:1800 2:701(147) 3:701(134) 4:1239(144) 5:1133 6:1674 1 1 2:1800 3:1239(218) ============================================================================= 2255 -- 34 different policies SO--by using 34 different policies, you could cover all of the more-specific; in fact, there are only 46 different Sprint-primary policies altogether (i.e., including the policies of the "/16" aggregates): 24 1:1239(144) 2:1239(147) 3:1239(218) 4:1800 253 1:1239(144) 2:1800 196 1:1239(144) 2:1800 3:1239(218) 4 1:1239(144) 2:1800 3:1239(218) 4:209 5:210 3 1:1239(144) 2:1800 3:1239(218) 4:210 5:209 1 1:1239(144) 2:1800 3:1239(218) 4:297(144) 2 1:1239(144) 2:1800 3:1239(218) 4:3561(11) 5:3561(218) 6:685 7:73 8:101 1 1:1239(144) 2:1800 3:1239(218) 4:3561(218) 5:93 23 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 3 1:1239(147) 2:1239(144) 3:1239(218) 4:1800 5:701 11 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 3 1:1239(147) 2:1239(218) 3:1239(144) 4:1800 5:1321 5 1:1239(218) 2:1239(144) 3:1800 35 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 5 1:1239(218) 2:1239(147) 3:1239(144) 4:1800 5:3561(27) 6:3561(218) 7:93 170 1:1239(218) 2:1800 3:1239(144) 2 1:1239(218) 2:1800 3:1239(144) 4:3561(218) 4 1:1239(218) 2:1800 3:1239(144) 4:3830 3 1:1240 2:1800 3:1239 12 1:1800 138 1:1800 2:1133 3:1239(144) 1 1:1800 2:1133 3:1239(144) 4:1674 1 1:1800 2:1133 3:1239(144) 4:1849 5:3561(218) 6:3561(11) 1 1:1800 2:1133 3:1239(144) 4:3561(218) 5:3561(11) 1 1:1800 2:1133 3:1674 944 1:1800 2:1239(144) 23 1:1800 2:1239(144) 3:1133 25 1:1800 2:1239(144) 3:1133 4:1674 205 1:1800 2:1239(144) 3:1239(218) 1 1:1800 2:1239(144) 3:1239(218) 4:1325 11 1:1800 2:1239(144) 3:1239(218) 4:209 5:210 2 1:1800 2:1239(144) 3:1239(218) 4:210 5:209 2 1:1800 2:1239(144) 3:1239(218) 4:3354 1 1:1800 2:1239(144) 3:1239(218) 4:701(147) 5:701(134) 5 1:1800 2:1239(144) 3:1740(135) 1 1:1800 2:1239(144) 3:2149 4:174 1 1:1800 2:1239(144) 3:3354 124 1:1800 2:1239(218) 3:1239(144) 2 1:1800 2:1239(218) 3:1239(144) 4:1321 1 1:1800 2:1240 28 1:1800 2:1240 3:1133 4:1674 76 1:1800 2:1879 3:1133 4:1239(144) 3 1:1800 2:297(145) 3:297(144) 4:372 5:1133 6:1239(144) 6 1:1800 2:701(147) 3:701(134) 6 1:1800 2:701(147) 3:701(134) 4:1239(144) 5:1133 6:1674 1 2:1800 3:1239(218) Without analyzing the size of the IP address space consumed--which is important, to be sure--I will assume that the 118 /16s could easily hold all of the customers of each of the 46 policies. That means that Sprint has actually submitted *at least* 2255 *extra* NACRs (not including changes and deletes) which certainly is a bit of work if you do it by hand. Of course, there are some NSPs (such as BARRNet) which seem to have laid down such policies and kept to them; in fact, it seems to me that we seldom had NACR activity from BARRNet for the past year or so. > --vadim Steve Richardson/Merit

3 3

Re: BGP vs. static routing (Re: Why Vadim likes statics)
by Robert E. Seastrom 30 Apr '95

30 Apr '95

> So it does not make sense for IBM or Sony to run dynamic routing in > their internal networks?!? Well.... it probably doesn't make sense for IBM or Sony to assign a different AS number to each router in their network and speak BGP between them. It's a matter of degree we're talking about here; of course it doesn't make sense to run full routing everywhere, just as it doesn't make sense to manually set up static routes everywhere. The point we're debating is what point along the line it makes most sense to set the slider. Most corporate networks are dendritic; as Vix noted, you run dynamic routing protocols in the center where there are multiple paths, and on hosts on the leaf nets you point default at the first router in the direction of the core and then forget about it (simple arrangements like this tend not to break and mess up your day). Maybe if you're feeling generous you rip a default route into the leaf nets so that if someone gets a new machine that's running evil routed and doesn't know about default routes and such they won't lose. On the other hand, maybe you would consider such a move to be anti-Darwinian and encouraging sloped-forehead, knuckle-dragging behavior. > > The border router does aggregation outbound and points the aggregates > > at Null 0 with a high metric. > > True. > > > This is for cases in which there is no other router participating > > within the customer iBGP mesh, and where there are N (N>=1) > > upstream providers, and where dynamic routing must take place within > > the ISP's routing domain for various reasons (portable dialup > > links, links that are time-sensitive, etc.) > > The assumption in this case is a common egress point. What percentage of the Internet's end-user customers have a single egress point for their networks? At a guess, I'd say 95%. If taking the preemptive step of installing pull-ups for those networks could reduce route flap by 75%, I submit that doing so expeditiously would get out of the woods at least for the time being. This is one of those cases in which the 90% solution is indeed the Right Thing. No, it won't scale if every end-user decides to become multihomed, but I don't see any great rush in that direction and compared to getting custom hacks put into the router code, it is very cost- and-effort-effective. If space to hold the statics in the configuration memory of the routers is an issue, you don't even have to do that -- a PC running BSDI with a trivially- hacked gated and connected to the fddi ring or "utility ethernet" in your POP can dynamically broadcast the pull-ups into your routers via rip or ospf, and would probably be easier to maintain and blow automatically-generated configs into than loading up the statics directly on the routers (at least you'd only have to do it once per POP instead of once per router). ---Rob Robert E. Seastrom -- rs(a)digex.net Network Engineer, Digex International My posting, my opinions, not speaking for the company, etc. etc.

2 1

Re: Has PSI been assigned network 1?
by Vadim Antonov 29 Apr '95

29 Apr '95

> The equipment available today is designed foolishly -- > route update processing and actual packet processing should NEVER be done by > the same CPU -- but it is -- and as such you're dead when this happens. > > Lest anyone believe this, it's bullshit. > > Karl just buys low end gear and then complains because it's not high > end gear. > > Tony >I suppose that a 7000 with a SSP is considered "low end" gear then? >It was *Vadim* who was complaining about CPU usage on your boxes, not me. >Karl Denninger (karl(a)MCS.Net) Would you please refrain from attributing to me the things i did not say? Particularly i never said anything about "actual packet processing by the same CPU" here. I "complained" (heh i do not _complain_, i simply state the facts) about CPU usage by BGP updates. --vadim

4 3

Non-Routing BGP Speakers
by sds＠jazzie.com 29 Apr '95

29 Apr '95

RFC 1771 says in part: The hosts executing the Border Gateway Protocol need not be routers. A non-routing host could exchange routing information with routers via EGP or even an interior routing protocol. That non-routing host could then use BGP to exchange routing information with a border router in another Autonomous System. The implications and applications of this architecture are for further study. Would anyone be willing to share their experiences with (or thoughts about) this approach? Given that 64 MB of RAM for routing tables woudl cost only around $2,000, this seems like a totally sensible way to build a small, multi-homed AS. Will finding a vendor-supported system for this be ... difficult? (I'm not exactly sure whether a BSD box running Cornell GateD counts as "vendor-supported". ;-) -- Sean Shapira sds(a)jazzie.com +1 206 443 2028 <a href="http://www.jazzie.com/sds/">Sean's Home Page</a> Serving the Net since 1990.

7 8

Re: Has PSI been assigned network 1?
by Vadim Antonov 28 Apr '95

28 Apr '95

>> I agree that one cpu does all is outdated monolithic design. >> Even hub vendors have two: one for hubbing, one for snmp and rmon. >> >> Mike >The existing route servers do this now... One CPU to compute routes and >then we forward the tables to ISP peers. The existing cisco 7000 does this now. Take a look at SP board someday. --vadim

2 1

Re: Has PSI been assigned network 1?
by Vadim Antonov 28 Apr '95

28 Apr '95

Karl, you obviously do not understand what global networking and policy routing mean. Right today we nearly killed all Internet by _not_ doing paranoid filtering on ANS route announcements (well we couldn't do it because of certain contractual obligations). ANS had trouble with generating configuration for ENSS 147, so they simply dropped all routes at our MAE-East+ box without filtering they usually do, which would be fine if we didn't do some upgrades at ICM, which involved changing preferences in ICM-SL routing, to the effect that SL started preferring AS 690 as path to many European networks. It resulted in SprintLink -> Europe traffic being moved from SL->ICM FDDI connection to SL->ENSS(147)->ANS core->Dante path; which at the daytime grew and turned out be enough to overload ENSSes along the path. This resulted in ENSS 147 delaying BGP keealives for so long that MAE-E peers (including SprintLink) were dropping their BGP sessions, only to reset them later. Since that causes route caches being flushed all _other_ ciscos were falling back to switching by CPU, became overloaded and started dropping their BGP sessions. Which resulted in snowball of real massive routing flap. I imagine how Internet would work if everybody listened to the enlightened advice of our esteemed sage: >Fascistic filtering breaks connectivity. > >So you trade a *risk* of broken connectivity for KNOWN broken connectivity? > >Sounds like a poor trade to me, and one which, undertaken consciously and >with knowledge of the repercussions, leaves you with being less than a full >Internet connectivity provider. > >After all, if you're filtering perfectly valid announcements then you are, >by definition, not providing connectivity to the "whole Internet" to the >best of your ability, are you? Sorry, Karl. Internet is lucky that people who run most big networks know better than to wait for shit to happen. In the system as large as Internet shit happens permanently. Somewhere, in the most unxpected places. If you persist in your dislike of filtering i guess i'll purely accidentally misconfigure a static route, so it will be the the same as your backbone address. RS won't save you. This is a joke, of course. --vadim

9 13

Re: Non-Routing BGP Speakers
by Sean Doran 28 Apr '95

28 Apr '95

| We have upgraded our box since then; Curtis, have you had a chance | to look at this yet? It is a disaster waiting to happen again Serpil Bayraktar tells me that ANS upgraded their boxes a while ago. I believe an announcement went out about this on the gated list or somesuch, and that the ANS fix also has been put into the gated consortium's code. Sean.

3 2

Re: Has PSI been assigned network 1?
by Sean Doran 28 Apr '95

28 Apr '95

You would think the words "Silicon Switch Processor" might clue people in that the board in question has nice little chips on it doing routing/switching, leaving the 68040 free to process BGP updates etc. Unfortunately, the 68040 is unable to keep up in ugly situations... Sean.

1 0

Re: Has PSI been assigned network 1?
by Hank Nussbacher 27 Apr '95

27 Apr '95

On Wed, 19 Apr 1995 18:49:39 -0400 you said: >>telent info.ripe.net to test it out. > >RIPE database does not control the actual routing. > >I'm not sure the current RADB project has any mention >of real-time updates of gated from the database. `With dozens of updates we do every day it nearly as good >as useless. CERN (as an example) picks up my routing updates daily and builds its new access filter based on mine and others routing updates. I'm not sure you want realtime updates to the actual routing. In any event, it is an improvement over the time lag of NACR updates. >>It should be secure. > >>I use a password on all AS updates to AS378. > >You call *that* secure? We have way too many people who >need to do changes for our AS-es. Check the contact >list for AS1800. You can assign as many users as you wish to control specific ASs. Currently it checks my email address and password. No match - and the maintainer of the AS gets a warning mail about the attempt to alter the routing within my AS - and I have gotten warning e-mails already. Adding in PGP authentication should not be too hard if it is not done already. >If i can't implement my existing policy, i cannot use RADB, ok? > >(Well, we _will_ use it -- to talk to people whose announcements >are loaded with garbadge). We simply cannot use it to talk >to major service providers because policies in place cannot >be represented in RIPE-81. So speak to the authors and get it improved. >--vadim Hank

7 7

IPPM mailing list preload.
by Matt Mathis 26 Apr '95

26 Apr '95

The IPPM (IP Provider Metrics) mailing list was only partially preloaded from the NANOG list. There were a number of entries on the NANOG list which were not included. In general, individuals and downstream exploders of the form "staff@site", "site-eng@site", and "admin@site" were included. However, downstream exploders mentioning other lists WERE NOT INCLUDED. For example "nanog@site", "nanog-dist@site", "iwg@site" were not included. If you receive this message, but not the IPPM kickoff, please consider adding yourself or your organization by sending mail to ippm-request(a)psc.edu. Thanks, --MM-- ------- Forwarded message Return-Path: mathis Received: from mailer.psc.edu by zippy.psc.edu via SMTP (931110.SGI/930416.SGI.AUTO) for mathis id AA03741; Wed, 26 Apr 95 15:49:46 -0400 Received: from zippy.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA04083; Wed, 26 Apr 1995 15:39:19 -0400 Message-Id: <9504261939.AA04083(a)mailer.psc.edu> To: ippm(a)psc.edu Cc: mathis(a)psc.edu Subject: IPPM Kick off message Date: Wed, 26 Apr 1995 15:39:17 -0400 From: "Matt Mathis" <mathis> This is kickoff message for the IP Provider Metrics mailing list. If you do not want to receive any further messages, send a note to ippm-request(a)psc.edu. However, be forewarned that this list has been pre-loaded with precisely the people who are mostly likely to be effected by our actions. >From the draft charter: The IPPM WG will develop a set of standard metrics that can be applied to the the quality, performance and reliability of an IP datagram service. These metrics will be designed such that they can be performed by the providers themselves, customers, potential customers or independent testing groups. There is now a home page at http://www.psc.edu/~mathis/ippm, including pointers to the minutes, etc. I am still looking for candidates to co-chair the working group. Thanks, --MM--

1 0