- NANOG - lists.nanog.org

other routing anomalies
by Gordon Cook 17 Apr '96

17 Apr '96

For the last week the *ONLY* way I can hold a connection to tigger at jvnc.net has been to log into a net access machine in philly and telnet from there to tigger rather than telnet directly from my house. Both connections go througth the CIX to get me 20 miles up the road in New jersey!! When I get packets from this connection it is like a 1200 baud connect. The infuriating thing is that after giving me 1200 baud service for a minute or two, it will stop for any where from up to 45 seconds to 3 minutes before moving a single character!!!!! I have complained to jvnc. They say they are laboring mightily to solve the problem and that a LOT of their users are affected. Not much luck so far ...still 300 baud service. BUT a traceroute from tigger to a commercial web site in wash DC run by PSI goes through MCI's MAE EAST ++ router which is where *MY* packets oughtta go rather than to California and back. Anyone have any idea why? The person I asked at JVNC today didn't. Here are the two traces done within the last 30 minutes. JVNC To my router via cix traceroute to 205.164.155.1 (205.164.155.3), 30 hops max, 40 byte packets 1 nomad-eth0 (128.121.50.50) 2 ms 2 ms 2 ms 2 liberty-hssi1/0-1 (130.94.40.250) 11 ms 10 ms 10 ms 3 waters-ser1/6 (130.94.45.249) 77 ms * 61 ms 4 ness-ser4 (130.94.17.250) 89 ms 126 ms 116 ms 5 goldengate-ser8 (130.94.15.65) 204 ms 186 ms 163 ms 6 cix-jvnc.west.cix.net (149.20.6.1) 194 ms 152 ms 149 ms 7 * hlc.west.cix.net (149.20.64.32) 109 ms 139 ms 8 hlc-east.gw.hlc.net (205.214.32.1) 128 ms * 159 ms 9 * mae-east.netaxs.com (192.41.177.87) 176 ms 172 ms 10 wynd-mae-east-gw.netaxs.com (207.8.160.5) 374 ms 198 ms 194 ms 11 wynd-mfs/k2ne/goldner-we0.netaxs.com (207.8.186.88) 226 ms 127 ms 160 ms 12 k2ne-wynd-t1.tty0.netaxs.com (206.161.91.14) 133 ms 184 ms 158 ms 13 router-ewing.netaxs.com (205.164.155.1) 167 ms 221 ms 199 ms Traceroute JVNC to comcast web site via mae east: tigger-gcook> traceroute www.comcast.com traceroute to www.comcast.inter.net (38.15.13.172), 30 hops max, 40 byte packets 1 nomad-eth0 (128.121.50.50) 2 ms 4 ms 3 ms 2 liberty-hssi1/0-1 (130.94.40.250) 37 ms 15 ms 13 ms 3 border2-hssi2-0.NewYork.mci.net (204.70.45.9) 23 ms 14 ms 24 ms 4 core1-fddi-1.NewYork.mci.net (204.70.3.17) 13 ms 12 ms 16 ms 5 core1-hssi-2.Washington.mci.net (204.70.1.5) 20 ms 19 ms 19 ms 6 borderx1-fddi0-0.Washington.mci.net (204.70.2.4) 18 ms 22 ms 18 ms 7 mae-east-plusplus.Washington.mci.net (204.70.74.102) 26 ms 19 ms 21 ms 8 * mae-east.psi.net (192.41.177.245) 35 ms 32 ms 9 38.1.2.14 (38.1.2.14) 21 ms 37 ms 28 ms 10 www5a-gw.inter.net (38.15.1.40) 36 ms 25 ms 52 ms 11 www5a.inter.net (38.15.13.2) 31 ms * 28 ms ********************************************************************* Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 USA Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook(a)cookreport.com Corporate Site Lic. $650 http://pobox.com/cook/ for new COOK Report Glossary of Internet terms *********************************************************************

5 6

Route aggregation tool runs for MAE-East routes
by Avi Freedman 17 Apr '96

17 Apr '96

I re-ran on today's data the route aggregation suggestion tool on routes from MAE-East. The results are at http://routes.netaxs.com. These are based *not* on AS-PATHs to determine "ownership of routes". They're based on next hop IPs from a MAE-East router. The goal is primarily to suggest possible border aggregations that could be made, for anyone who's interested in looking. We developed the tool for internal use, but I thought it'd be interesting to give it some Real Data... Please direct any followup flames or comments to cidrd; nanog probably isn't the place to *discuss* such things, but I figured it'd be helpful to announce it there as well. Avi

1 0

Re: The Attitude (was: the Internet Backbone)
by Paul Ferguson 17 Apr '96

17 Apr '96

At 10:32 PM 4/16/96 EDT, EDS(a)RHQVM21.VNET.IBM.COM wrote: > >Flap dampening works on most routers- just have to be aware of what >the effects are, particularly with multiple BGP Peers. >You have to decide whether to dampen outbound and/ >or inbound, and if short duration events like temporary >recalculations of the IGP are considered a "flap". > Excuse me? Care to qualify this comment? - paul >Ed Segal EDS(a)RHQVM21.VNET.IBM.COM 914 684-3976 > > >

1 0

Re: The Attitude (was: the Internet Backbone)
by Paul Ferguson 17 Apr '96

17 Apr '96

At 04:39 PM 4/16/96 -0400, Avi Freedman wrote: >> Exponential backoff works well, too bad the code base that does >> route flap damping isn't really stable enough for production >> use in large parts of the Internet. > >I think the code base that does route flap damp(en)ing is in use in >large parts of the Internet... > I would have a tendency to agree with you on this datapoint. :-) - paul >> Jeremy Porter, Freeside Communications, Inc. jerry(a)fc.net > >Avi > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso(a)cisco.com c i s c o S y s t e m s

1 0

Re: Some corrections
by Scott Huddle 16 Apr '96

16 Apr '96

> But then, this is all beside the point! The point was that another more > direct path exists, via Chicago, that would stop swamping your DC > routers, and reduce my recorded congestion. If only these regional > providers would cooperate. Mea culpa, the connection to Chicago is a backup T1, Oarnets other T3 connection to us is in Atlanta. > And I see that you are working on the links, even changing the inverse > names for the same address: [collection of traceroutes deleted] These are the new OC3 trunks... -scott

1 0

Re: Some corrections
by William Allen Simpson 16 Apr '96

16 Apr '96

> From: Scott Huddle <huddle(a)mci.net> > Oarnet is an MCI customer as well. they have a T3 connection to our > network at Washington and another to the Chicago area. I think you might > be confusing traffic to them over their dedicated line at Washington > as going over MAE-East. > Thanks, I checked again, and you are correct, it no longer seems to go via the same paths in the DC area that it did in February or March.... Every month, a different path! But then, this is all beside the point! The point was that another more direct path exists, via Chicago, that would stop swamping your DC routers, and reduce my recorded congestion. If only these regional providers would cooperate. However, this little public exchange has stimulated some local comment, and there may be some cooperation at hand. I am deeply gratified! ---- And I see that you are working on the links, even changing the inverse names for the same address: Recording Wed Feb 28 17:42:29 1996 10: 204.70.1.102 core1-hssi-3.WestOrange.mci.net. (226 ms) (273 ms) (214 ms) 11: 204.70.1.106 core2-hssi-2.Washington.mci.net. (229 ms) (238 ms) (231 ms) 12: 204.70.1.73 core1-aip-4.Washington.mci.net. (240 ms) *** (248 ms) 13: 204.70.2.3 border3-fddi-0.Washington.mci.net. (231 ms) (235 ms) (240 ms) 14: *** 204.70.58.10 ohio-state-u--oarnet.Washington.mci.net. (267 ms) (235 ms) 15: *** 206.21.252.2 oeb-fddi-gwoeb2.columbus.oar.net. (1298 ms) (376 ms) 16: 199.18.105.250 (266 ms) (254 ms) *** 17: *** *** 192.20.239.132 ds2.internic.net. (277 ms) Recording Mon Mar 18 22:25:27 1996 10: 204.70.1.102 core1-hssi-3.WestOrange.mci.net. (226 ms) (273 ms) (214 ms) 11: 204.70.1.106 core2-hssi-2.Washington.mci.net. (243 ms) (379 ms) (240 ms) 12: 204.70.74.52 borderx1-fddi-1.Washington.mci.net. (325 ms) (281 ms) (250 ms) 13: 204.70.74.102 mae-east-plusplus.Washington.mci.net. (251 ms) *** (284 ms) 14: *** *** *** 15: *** *** *** 16: *** *** *** Recording Tue Apr 16 20:29:01 1996 9: 204.70.1.102 core1-hssi-3.WestOrange.mci.net. (214 ms) (201 ms) (201 ms) 10: 204.70.4.129 core1.Washington.mci.net. (307 ms) (367 ms) (214 ms) 11: 204.70.2.3 border3-fddi-0.Washington.mci.net. (206 ms) (205 ms) (208 ms) 12: 204.70.58.10 ohio-state-university.Washington.mci.net. (223 ms) (218 ms) (217 ms) 13: 206.21.252.2 oeb-fddi-gwoeb2.columbus.oar.net. (227 ms) (219 ms) (218 ms) 14: 199.18.105.250 (442 ms) (245 ms) (226 ms) 15: *** *** *** 16: *** *** *** 17: *** *** *** Note that the last 2 times, I still couldn't reach my final destination, ds2.internic.net. Of course, I usually only record the trace when there is an ongoing problem.... WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: The Attitude (was: the Internet Backbone)
by William Allen Simpson 16 Apr '96

16 Apr '96

> From: "Erik E. Fair" (Internet Architect) <fair(a)apple.com> > Perhaps the easy way out is to suggest that educating the ISPs as to > what constitutes good behavior at an exchange (routing system stability > and reliable packet delivery) is the responsibility of the exchange > operators, This is not just the easy way out, I believe that it is the only way out. Then, we don't have the problem of all those multiple peering agreements. Instead, just one with the exchange. Also, this eliminates the problem of each ISP trying to "filter" bogus routes. Instead, the exchange operators will handle that problem. Indeed, I think that this is/was a major impetus for "policy-based" routing in the first place (reading the old RFCs), and a clear reason we need the Routing Arbiter! > and it might even be possible to enforce some interesting > policies in that regard in the route servers (e.g. if you have more > than N routing or BGP peer transitions per time period, the route > server will refuse to peer with you for 48 hours - think of it as the > hold-down or damper from Hell). > Interesting concept! > I certainly think that to the extent that the exchange operators can > measure such things as routing and peer stability, it is in everyone's > interest to see the numbers (except those ISPs who are unstable). Who > knows? A series good reports from exchange operators about an ISP might > lead to offers of private peering arrangements outside of the exchange, > to the benefit of the ISP. Similar to the way that having a good credit > record seems to lead to endless offers of more credit. > I understood that the RA contract provided for these measurements, and agree that they would be a good thing! WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

3 2

Re: Some corrections
by Scott Huddle 16 Apr '96

16 Apr '96

At 9:59 AM 4/16/96, William Allen Simpson wrote: >Both Merit and CICnet are connected to MCI. Correct? My new >understanding is that the problem seems to be that MCI is stuck in the >middle there, and for some reason shunts some (but not all) OSU and >OARnet traffic off through MAE-East, rather than passing it more >directly to OARnet (through CICnet or otherwise). And this is because >of some _source_ based algorithm, since this only happens to Merit >sourced traffic, but not other CICnet traffic, as you are using MCI to >hold together pieces of CICnet? Sounds bizarre to me.... Bill, Oarnet is an MCI customer as well. they have a T3 connection to our network at Washington and another to the Chicago area. I think you might be confusing traffic to them over their dedicated line at Washington as going over MAE-East. Hope this clears things up, -scott (huddle(a)mci.net) MCI Internet Engineering

1 0

Re: Some corrections
by rrv＠uiuc.edu 16 Apr '96

16 Apr '96

At 9:59 AM 4/16/96, William Allen Simpson wrote: >Both Merit and CICnet are connected to MCI. Correct? My new >understanding is that the problem seems to be that MCI is stuck in the >middle there, and for some reason shunts some (but not all) OSU and >OARnet traffic off through MAE-East, rather than passing it more >directly to OARnet (through CICnet or otherwise). And this is because >of some _source_ based algorithm, since this only happens to Merit >sourced traffic, but not other CICnet traffic, as you are using MCI to >hold together pieces of CICnet? Sounds bizarre to me.... > >In any case, it still proves my point -- Merit and CICnet (and MCI) >somehow view each other as competitors and don't cooperate to carry >traffic by the "best" route, thereby clogging other areas of the >Internet (MAE-East) at others' unknowing expense. Bill, you are way off base.

1 0

Re: The Attitude (was: the Internet Backbone)
by William Allen Simpson 16 Apr '96

16 Apr '96

> From: Jeremy Porter <jerry(a)fc.net> > Bill, here is why you will never be taken seriously be > any ISP/NSP. If networks can't find ways to cooperaate without > prodecting there own interests, we all might as well give up > now. > I'll try to remember not to take myself seriously.... This is a most unusual argument: that we should cooperate without protecting our own interests; and if we cannot, we should give up. Are you sure that you know what you are writing? > THE ONLY WAY TO BUILD A SCALABLE INTERNET IS FOR PROVIDERS > TO BE MOTIVATED BY SELF INTEREST AND ECONOMIC FACTORS. > This is contrary to your above assertion. However, this does not match the historic record. A scalable Internet doesn't even require the concept of "providers". Nor does it require self interest. There are certainly other models that could be (and have been) followed. > This is exaclty an issue of customer education, If customers > wanted good connectity they CAN find it. > Really? Where? And who does the education? Using what data (as the providers themselves have refused to release it)? May I suggest that this form of argument was advanced for rather a lot of other fields, such as food, drugs, comparing doctors and lawyers and their fees, and purchasing of automobiles and refrigerators. As I remember, Consumers Union (I'm a lifetime member) was investigated at one time as a "communist conspiracy". This does not follow the subject of this thread, which was in regard to (lack of) cooperation with competitors. I don't see how customer education will affect the physical interconnections of carriers, except as perhaps encouraging consumers to sue their providers for fraud.... > Hm.. maybe Apple should have thought a little more > about their little T-1 link to a single provider when they > had about 3 T-1s worth of data to send. I offer to sell > more connectivity to Apple, but they WEREN'T interested. I question your objectivity. Sounds like you have a personal self-interest issue here. By my measurements, there was no problem with the Apple T1(s). The problem I documented was that Sprint didn't have enough bandwidth out of Texas (specifically to Chicago in my tests, but reportedly to other places as well) to ensure full T1 delivery for Apple while also supplying service to others in Texas. That is, Sprint was underprovisioned. Also, their links flapped a lot. > They didn't care that there application/distribution model was > broken, and breaking the net, they didn't want to fork > out the extra bucks, or deal with the internal politics > to put the release out on the West coast where they > had a much higher bandwidth connection. > I disagree, as Apple DID care very much! In fact, they eventually did put it out on other sites, including their west coast connection. How would it have helped if they had a T3 in Texas, when Sprint couldn't even handled another T1's worth of traffic to the same site? How would it have helped the net if they had been multihomed? You provide a separate link to Chicago, and load balancing between you and other providers? > I haven't seen many reports of Sprint problems since > Sprint put its policies in places and they had time work. Only recently has Sprint been cooperating with the RA enough to actually get some Sprint flapping statistics. I cannot help that you personally have not seen them.... Why not look at them yourself? > MCI on the other hand has been bleeding about 30% packets out of > San Francisco, on its OWN INTERAL network for several MONTHS. Too true. I did not mean to pick on Sprint exclusively, except where Sean seemed to make a claim that somehow the Sprint network was somehow operating better then others, and that it was due to his wonderful sagacity in refusing to carry others traffic. I have not (yet) heard the same non-cooperative attitude from MCI. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1