- NANOG - lists.nanog.org

Re: ATM (was Re: too many routes)
by Carmen Hillenburg 12 Sep '97

12 Sep '97

Sean M. Doran wrote: > BTW, your formatting sucks to the point that your note is > unreadable and unquotable without fmt(1) or fill-paragraph. Sorry, bad program to send from ;{ >So anyway, as I was saying, I'm ignorant about such matters. Cute. ;) Its nice to know you have a sense of humor ! >Oh now THERE's a reliable source. "Hi my name is Frank > and ATM will Just Work. Hi my name is Warren and ATM is > fantastic.". Ugh. (kent bait kent bait kent bait) Not my point, I was just quoting my "source" of timings, nothing more. >At higher bandwidths bits are shorter not faster. Yes, but at lower bandwidth they are spaced further apart. >Repeat that several times. Yes, do. >Whether you are signalling at 300bps or at >293875983758917538924372589bps, the start of the first bit >arrives at the same time. I was talking about a total performance increased experienced by more bandwidth, not *just* latency. BTW the total transmission time is still reduced, my original point. I was careful to note the resultant transmission time, not latency. Also, if the cell entered the net to carry the "first bit" before it's natural TAT...... >Um, no it doesn't. As with all demand-cached forwarding >schemes you have to process a packet heavily when you have >a cache miss. You are right. I was not accurate on full implementation detail, but the concept was there. I *really* must remember *not* to use simplifications for brevity in the nanog list. But, the description was not intended as an RFC. I was only noting the advantage to not needing to look up where to send a packet , * every time *. > MPLS is conceptually related, btw. Interesting. PS. I am a supporter. >P.S.: You have some very entertaining and unique expansion > of a number of acronyms in general and relating to > ATM in particular. I'm curious how you expand "PDH". > Personally I favour "Pretty Damn Historical", > although other epithets come to mind. I repeat, I will NEVER, NEVER, NEVER, over simplify for brevity to the nanog again. Bad Richard, Bad! (But each one gave you the general idea, didn't it.) I rather liked your response(s), it was informative. I still hold to my point, though. Now rather than fire a response to all those flames, one at a time.... To One individual: Yes, I used some terms from Frame Relay, instead of ATM. (OOPs! I work with all the above, and it was the end of a 10 hour day) And yes, the acronyms are in error in literal expansion, however, not in concept. They perform the same BASIC function. ---------------------------- Never, never, never again.... ---------------------------- And to another, I did not claim that the speed of light is NOT a factor, just not the only one. And since I cannot change the speed of light ..... ---------------------------- Bad! Never, Never.. ---------------------------- (One guy hated a 12ms difference between my "on the cuff estimate", and his calculation of the RTT.) Boy, THAT invalidates ATM. ---------------------------- Never, Never, Never... ---------------------------- > I wasn't around for the invention of statistical muxing, >but I'm sure there are some people here who could clarify >with first-hand knowledge (and I'll take email from you, >thanks :) ). Neither was I. However, I wasn't being quite that literal. I will accept that I presented an inaccuracy. SDM just allowed more diverse use of a given voice circuit. A lot of this chain-flame is my fault, a little too tired.., and not exacting detail. However, Sorry, I still hold to ATM being superior for WAN, and possibly exchange delivery. This does not mean ATM will hold as well as other technologies when seriously OVERSUBSCRIBED. (Now, what fool would do that .) But, I should note that during the recent "brown outs" it was not the ATM NAP's that were collapsing. (Not that some peoples ports weren't lossy) Many of you picked at details you could find wrong, from spelling to 12ms differences in earth round trip time. etc. I hope some of you noted what was right. Those points never seem to get "cut and pasted." Some times you just can't see the forest for the all tree's in the way.. And boy there were a LOT of tree's. A) ATM is better. B) No its not! A) Yes it is! B) No its not! A) Yes it is ! B) Your hair is died !! A) Uhhh...Its only grecian formula... B) Is that your natural color ? A) Well, no, I told you I use greci... B) uh-huh, SEE! ATM isn't better! A) sigh....... Wasn't this on Monty Python ?

2 1

Re: LSR and packet filters
by rja＠corp.home.net 12 Sep '97

12 Sep '97

On Sep 11 21:06, Sean M. Doran wrote: % 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. Hmm. I wouldn't go that far :-). % 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. A reasonable security policy is focused on maintaining network availability and uptime. If one focuses exclusively on diagnostic tools, one's network will be down much more often than if one strikes a reasonably balanced overall perspective on things. All IMHO. % 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). You haven't defined terms (e.g. "backbone router"), so your meaning is not clear. Assuming that "backbone router" is only those within 2 hops of an external connection and that one has a network with nice deep heirarchy (much more than 2 levels), I could agree with you. :-) I will note that its none of someone else's business what one's internal topology looks like. The only _legitimate_ need of a peer is to be able to isolate the problem to one's network (or someone else's network) so that the peer can then come after one (or one's NOC) to fix the problem(s). So I'm not trying to kill off LSR as a diagnostic tool, merely limit the downside operational risks of LSR to a reasonable level. The ultimate goal of my proposal is to _enhance_ network availability. Ran rja(a)home.net Disclaimers from yesterday's note all apply; especially the one about not enough coffee. :-) PS: I've revised the subject line to be more clear.

1 0

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

12 Sep '97

Nathan Stratton <nathan(a)netrail.net> writes: > This is what I beleave sprint is doing. They are using the new Cisco 12000 > GSR with external router servers. It is a smart way of patching the > problem. If you need more CPU or memory you can just add a bigger box and > more RAM. The GSRs are to move bits fast. They are not to act as route servers. Sprint recently announced that they are deploying 622Mbps POS cross-country links, and the GSRs are the only things you can put on the ends of such beasts that are available today. (Someone may point out that it may not be the only choice for very long, however, it's the only one whose design I know and have had any influence upon, and is therefore frankly the only one I trust, although I don't expect the people building the competing box will ship anything but a good product even if they are now rather deeply in bed with the cell-heads and about as transparent to most observers as the Kremlin during the cold war... The box being built by someone who actually worked very close to the Kremlin during the cold war is also something I don't know enough about, however that is much more due to my neglect than due to organizational attitude.) Remember that a current snapshot is not a good indicator of future health. Sure the processing demands of routing are such that the GSR's main CPU is largely idle after converging with its neighbours, however there is still a CPU spike during convergence and the processing load is non-zero. If you increase the growth curve of the number of prefixes, you increase the CPU demands during large-scale convergence. You also statistically increase the CPU demand after convergence unless you reduce the probability of any given prefix transitioning from up to down or vice versa over time. If you have a growth curve where the processing load during large-scale convergence and the processing load to handle background noise increases beyond processing capacity faster than processing capacity can be increased, you lose, no matter how crunchy your box is today relative to today's processing demands. In other words, removing the feedback mechanisms on the growth of the number of globally-visible prefixes and on prefix instability is probably a really bad idea. Sean.

5 5

frac DS3 from PAIX
by andrew khoo 12 Sep '97

12 Sep '97

any contacts for getting a frac DS3 from PAIX to the PanAmSat teleport facility at Napa? ============================================================== andrew khoo - rebel leader gsm: +61-500-555-466 Ourworld Global Network work: +61-2-9223-2777 sushi-eating good guy - wild wookie pager: +61-2-9962-4414 speaks in home-grown tongue - ren usa: +1-415-531-2754 ============================================================== -- We Bite (tm) --

1 0

Re: not rewriting next-hop, pointing default, ...s
by Vincent J. Bono 12 Sep '97

12 Sep '97

Although it is not likely that Avi is wrong, I'm sorry that this whole mess has degenerated to "did-to did-not" loops. Sigh. Avi Freedman wrote: > > You may have been peering with them but you were ALSO default-routing > to them. > > >From 4/96: > > -------------------------------------------------------------- > > NOW TRYING: [e0-10m.mae-east.netrail.net (192.41.177.228)] > > -------------------------------------------------------------- > > -------------------- to mci through [e0-10m.mae-east.netrail.net] > > trace 204.70.57.10 > > Type escape sequence to abort. > Tracing the route to internetmci-ipdev.Washington.mci.net (204.70.57.10) > > 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 376 msec 120 msec 120 > msec > 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 128 msec 136 ms > ec 148 msec > 3 E0-10M.nr-1-Arlington-VA.netrail.net (205.215.4.1) [AS 4006] 148 msec 8 msec > 8 msec > 4 204.70.56.29 [AS 3561] 8 msec 12 msec 8 msec > 5 core1-fddi-0.Washington.mci.net (204.70.2.1) [AS 3561] 20 msec 12 msec 12 ms > ec > 6 border2-fddi-0.Washington.mci.net (204.70.3.2) [AS 3561] 12 msec 12 msec 12 > msec > 7 internetmci-ipdev.Washington.mci.net (204.70.57.10) [AS 3561] 12 msec * 8 m > sec > mae-netaxs# > > -------------------- to sprint through [e0-10m.mae-east.netrail.net] > > trace 204.117.214.13 > > Type escape sequence to abort. > Tracing the route to ftp.sprintlink.net (204.117.214.13) > > 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 4 msec 8 msec 4 msec > 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 8 msec 12 msec > 8 msec > 3 E0-10M.nr-1-Arlington-VA.netrail.net (205.215.4.1) [AS 4006] 8 msec 8 msec 8 > msec > 4 204.70.56.29 [AS 3561] 8 msec 12 msec 12 msec > 5 core1-fddi-0.Washington.mci.net (204.70.2.1) [AS 3561] 12 msec 8 msec 12 mse > c > 6 204.70.3.4 [AS 3561] 104 msec 12 msec 8 msec > 7 204.70.74.118 [AS 3561] 8 msec 8 msec 12 msec > 8 sl-mae-e-f0/0.sprintlink.net (192.41.177.241) [AS 3491] 8 msec 24 msec 12 ms > ec > 9 sl-dc-8-H1/0-T3.sprintlink.net (144.228.10.41) [AS 1239] 32 msec 12 msec 12 > msec > 10 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) [AS 1239] 12 msec 8 msec 8 msec > 11 ftp.sprintlink.net (204.117.214.13) [AS 1239] 8 msec 8 msec 12 msec > mae-netaxs# > > -------------------- to agis through [e0-10m.mae-east.netrail.net] > > trace 205.137.48.30 > > Type escape sequence to abort. > Tracing the route to agisgate.agis.net (205.137.48.30) > > 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 4 msec 4 msec 4 msec > 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 8 msec 8 msec 1 > 2 msec > 3 E0-10M.nr-1-Arlington-VA.netrail.net (205.215.4.1) [AS 4006] 8 msec 8 msec 8 > msec > 4 border1-serial2-5.Washington.mci.net (204.70.56.29) [AS 3561] 4 msec 8 msec > 8 msec > 5 core1-fddi-0.Washington.mci.net (204.70.2.1) [AS 3561] 16 msec 8 msec 8 msec > 6 204.70.1.6 [AS 3561] 80 msec 208 msec 208 msec > 7 204.70.3.18 [AS 3561] 204 msec 16 msec 12 msec > 8 sprint-nap.NewYork.mci.net (204.70.45.6) [AS 3561] 16 msec 16 msec 20 msec > 9 agis.sprint.ep.net (192.157.69.19) [AS 1239] 28 msec 16 msec 20 msec > 10 pennsauken.agis.net (205.137.61.2) [AS 4200] 52 msec 208 msec 212 msec > 11 detroit-trenton.detroit.agis.net (205.137.60.233) [AS 4200] 40 msec 48 msec > 52 msec > 12 agis.detroit.agis.net (205.137.60.66) [AS 4200] 44 msec 64 msec 52 msec > 13 agisgate.agis.net (205.137.48.30) [AS 4200] 60 msec 56 msec 52 msec > mae-netaxs# > > -------------------- to ans through [e0-10m.mae-east.netrail.net] > > trace 192.77.167.33 > > Type escape sequence to abort. > Tracing the route to www.ans.net (192.77.167.33) > > 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 4 msec 4 msec 4 msec > 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 8 msec 12 msec > 4 msec > 3 E0-10M.nr-1-Arlington-VA.netrail.net (205.215.4.1) [AS 4006] 8 msec 8 msec 8 > msec > 4 border1-serial2-5.Washington.mci.net (204.70.56.29) [AS 3561] 8 msec 8 msec > 8 msec > 5 borderx1-fddi0-0.Washington.mci.net (204.70.2.4) [AS 3561] 36 msec 80 msec 8 > msec > 6 mae-east-plusplus.washington.mci.net (204.70.74.102) [AS 3561] 8 msec 8 msec > 12 msec > 7 mae-east.ans.net (192.41.177.140) [AS 3491] 8 msec 8 msec 8 msec > 8 ft3.cnss56.Washington-DC.t3.ans.net (140.222.56.4) [AS 690] 12 msec 12 msec > 8 msec > 9 f0.cnss61.Washington-DC.t3.ans.net (140.222.56.197) [AS 690] 12 msec 8 msec > 12 msec > 10 enss186.t3.ans.net (199.221.107.86) [AS 1327] 192 msec 136 msec 140 msec > 11 www.ans.net (192.77.167.33) [AS 1327] 80 msec * 136 msec > mae-netaxs# > > -------------------- to psi through [e0-10m.mae-east.netrail.net] > > trace 38.8.8.2 > > Type escape sequence to abort. > Tracing the route to www.psi.net (38.8.8.2) > > 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 8 msec 116 msec 4 mse > c > 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 8 msec 8 msec 4 > msec > 3 E0-10M.nr-1-Arlington-VA.netrail.net (205.215.4.1) [AS 4006] 12 msec 8 msec > 8 msec > 4 border1-serial2-5.Washington.mci.net (204.70.56.29) [AS 3561] 8 msec 8 msec > 8 msec > 5 borderx1-fddi0-0.Washington.mci.net (204.70.2.4) [AS 3561] 12 msec 8 msec 12 > msec > 6 mae-east-plusplus.washington.mci.net (204.70.74.102) [AS 3561] 72 msec 8 mse > c 200 msec > 7 mae-east.psi.net (192.41.177.245) [AS 3491] 8 msec 20 msec 12 msec > 8 38.1.2.14 [AS 174] 8 msec 12 msec 12 msec > 9 www.psi.net (38.8.8.2) [AS 174] 12 msec 12 msec 12 msec > mae-netaxs# > > -------------------- to uunet through [e0-10m.mae-east.netrail.net] > > trace 199.170.0.30 > > Type escape sequence to abort. > Tracing the route to charlotte01.va.pubnix.com (199.170.0.30) > > 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 0 msec 4 msec 8 msec > 2 Vienna1.VA.ALTER.NET (192.41.177.249) [AS 3491] 8 msec 12 msec 8 msec > 3 Hssi1/0.GW2.FFX1.Alter.Net (137.39.100.70) [AS 701] 108 msec 40 msec 8 msec > 4 UUNET3-GW.UU.NET (137.39.12.35) [AS 701] 4 msec 4 msec 8 msec > 5 charlotte01.va.pubnix.com (199.170.0.30) [AS 701] 8 msec 8 msec 8 msec > mae-netaxs# > > -------------------- to nowhere through [e0-10m.mae-east.netrail.net] > > trace 3.4.5.6 > > Type escape sequence to abort. > Tracing the route to 3.4.5.6 > > 1 e0-10m.mae-east.netrail.net (192.41.177.228) [AS 3491] 8 msec 4 msec 8 msec > 2 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] 12 msec 12 msec > 8 msec > 3 S2-T1.nr-2-Arlington-VA.netrail.net (205.215.63.5) [AS 4006] !H !H !H > mae-netaxs# > > conf term > Enter configuration commands, one per line. End with CNTL/Z. > mae-netaxs(config)#no ip route 3.4.5.6 > mae-netaxs(config)#ip route 3.4.5.6 192.41.177.112 > mae-netaxs(config)#no ip route 199.170.0.30 > mae-netaxs(config)#ip route 199.170.0.30 192.41.177.112 > mae-netaxs(config)#no ip route 38.8.8.2 > mae-netaxs(config)#ip route 38.8.8.2 192.41.177.112 > mae-netaxs(config)#no ip route 192.77.167.33 > mae-netaxs(config)#ip route 192.77.167.33 192.41.177.112 > mae-netaxs(config)#no ip route 205.137.48.30 > mae-netaxs(config)#ip route 205.137.48.30 192.41.177.112 > mae-netaxs(config)#no ip route 204.117.214.13 > mae-netaxs(config)#ip route 204.117.214.13 192.41.177.112 > mae-netaxs(config)#no ip route 204.70.57.10 > mae-netaxs(config)#ip route 204.70.57.10 192.41.177.112 > mae-netaxs(config)#end > mae-netaxs# > > Avi > > > > > NO I DID NOT, Just talk to UUNet, I was peering with that at that time. > > > > > > Nathan Stratton President, CTO, NetRail,Inc. > > ------------------------------------------------------------------------ > > Phone (888)NetRail NetRail, Inc. > > Fax (404)522-1939 230 Peachtree Suite 500 > > WWW http://www.netrail.net/ Atlanta, GA 30303 > > ------------------------------------------------------------------------ > > "No king is saved by the size of his army; no warrior escapes by his > > great strength. - Psalm 33:16 > > > > On Fri, 12 Sep 1997, Avi Freedman wrote: > > > > > You did. > > > I saw it. > > > Others saw it. > > > > > > Avi > > > > > > > > > > > I was not, I have never pointed a default route at anyone. I was peering > > > > with UUNet at the time, I did not and never have pointed a default route > > > > at them. > > > > > > > > > > > > Nathan Stratton President, CTO, NetRail,Inc. > > > > ------------------------------------------------------------------------ > > > > Phone (888)NetRail NetRail, Inc. > > > > Fax (404)522-1939 230 Peachtree Suite 500 > > > > WWW http://www.netrail.net/ Atlanta, GA 30303 > > > > ------------------------------------------------------------------------ > > > > "No king is saved by the size of his army; no warrior escapes by his > > > > great strength. - Psalm 33:16 > > > > > > > > On Fri, 12 Sep 1997, Avi Freedman wrote: > > > > > > > > > You were defaulting into UUNET at the time... > > > > > > > > > > Avi > > > > > > > > > > > What was netrail a default violation? > > > > > > > > > > > > Nathan Stratton President, CTO, NetRail,Inc. > > > > > > ------------------------------------------------------------------------ > > > > > > Phone (888)NetRail NetRail, Inc. > > > > > > Fax (404)522-1939 230 Peachtree Suite 500 > > > > > > WWW http://www.netrail.net/ Atlanta, GA 30303 > > > > > > ------------------------------------------------------------------------ > > > > > > "No king is saved by the size of his army; no warrior escapes by his > > > > > > great strength. - Psalm 33:16 > > > > > > > > > > > > > >

1 0

SpamShield
by Deepak Jain 12 Sep '97

12 Sep '97

I didn't see anything about this in the archives, but as far as implementing a reasonably friendly anti-spam policy (http://www.abest.com/~kai/spamshield.html) without forbidding relaying entirely, is there a consensus opinion? Thanks, Deepak

2 1

Re: not rewriting next-hop, pointing default, ...
by dlr＠bungi.com 12 Sep '97

12 Sep '97

[In the message entitled "Re: not rewriting next-hop, pointing default, ..." on Sep 11, 15:23, Randy Bush writes:] > >> no neighbor 192.41.177.73 > > they should not care if you peer with them or not, they can have > > the upstream provider to give them your routes, then: > > ! > > set nexthop 192.41.177.121 > > Yes, folk seem to be doing this kind of thing, as shocking and disgusting as > it seems. Hey, at least they know how to configure routers, now. Give them points for that, at least :-) above.net$ traceroute -g 192.41.177.98 www.mci.net traceroute to www.mci.net (204.70.133.140): 1-30 hops, 78 byte packets 1 gate-96.sjc.above.net (207.126.96.161) 2.16 ms 3.92 ms 2.53 ms 2 mae-west-T3-2.above.net (207.126.96.238) 4.85 ms mae-west-T3-1.above.net ( 207.126.96.245) 4.77 ms mae-west-T3-2.above.net (207.126.96.238) 3.32 ms 3 mae-east-oc3.above.net (207.126.96.66) 74.0 ms 78.1 ms 122 ms 4 mae-east-01.ix.ai.net (192.41.177.98) 81.0 ms !S * 87.9 ms !S -- Dave Rand dlr(a)bungi.com http://www.bungi.com

2 1

Re: not rewriting next-hop, pointing default, ...
by rja＠corp.home.net 12 Sep '97

12 Sep '97

On Sep 11 15:54, Randy Bush wrote: } Subject: Re: not rewriting next-hop, pointing default, ... > LSR is actually a significant security issue. So, while I do > understand and am sympathetic to the operational debugging > issues that LSR addresses, I think that requiring a peer to > enable LSR more than 2 hops inside their network from the > outside world is unreasonable. % So, you're comfortable with asking for LSR at the IX and a hop behind? "Comfortable" isn't the word I'd choose. Ideally, I'd filter out LSR entirely [1], but there are real operational issues. 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". > In a world where SSH were available in cisco routers and/or > IPsec were more widely deployed, I might have different views. % K5 does not give you sufficient warm fuzzies? No, I'm afraid that Kerberos 5 doesn't give me sufficient warm fuzzies. I don't care to be very detailed on a public list such as NANOG. I will note that aside from my non-public concerns, Kerberos-5 is expensive to deploy and maintain. Kerberos can also adversely impact network availability if it isn't installed in exactly the right way (surprisingly few folks seem to do it right). Ran rja(a)home.net [1] DISCLAIMERS: - I'm not a security expert, so my opinion probably doesn't mean very much in the grand scheme of things. - I am NOT with @Home's Security Group, which is ably managed by Mike StJohns, who is a Security Expert. So don't blame them for my comments. - I don't make policy for @Home, so my opinions are just mine not my employer's. - I haven't had enough coffee yet today. :-)

2 1

Re: too many routes
by Sean Donelan 12 Sep '97

12 Sep '97

>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. What's interesting is Sprint's filters have encouraged InternetMCI's customers to clean things up more than Sprintlink's customers. As an experiment, I removed my filters last night. In general my filters are more generous than any Mr. Doran used, mostly blocking 'mistakes' like /32 prefixes. What I found was the four top providers appearing in the previous filtered paths in order were, total of 1074 filtered routes 227 Sprint 225 UUNET 97 AARNET 92 MCI Sprint has taken over the number 1 spot, and MCI dropped to number 4, from the point of view of my BGP routers. Although MCI still seems to be well represented amoung the very, very long (>/30) prefixes. But this may simply be due to someone else filtering out extremely long prefixes before they reach my BGP routers. So you should view these as lower bounds. Things may be worse. What was even more interesting was number of routes accounted for by >/24's in 192-210 space and >/16's in 128-191 space was more than any of the CIDRizing suggestions in Tony Bates weekly CIDR report. Some people seem to view CIDR as an opportunity to subdivide their traditional 'Class B' networks. I would classify most of these announcements as 'mistakes' because they usually also announce the supernet, and have the same path. Here were some of the extreme examples. 168.248.0.0/30 3561 i 168.249.0.0/30 3561 i 198.203.196.144/32 3561 i 203.38.0.144/30 3561 1221 ? 203.38.0.148/30 3561 1221 ? 207.65.182.111/32 3561 i -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

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