At 07:28 PM 6/18/2002 +0100, Stephen J. Wilcox wrote:
Path is one of the last things to be checked
BGP first checks all kinds of network admin defined things such as local prefs etc which ought to be properly set by the admins to ensure traffic is going the best way (which should include local interconnects rather than last resort transits). Then all things being well BGP can make choices on path!
So, you're advocating that the admin do all of the optimization manually for all destinations by setting preferences? Mathew
On Tue, 18 Jun 2002, Mathew Lodge wrote:
At 01:33 PM 6/18/2002 -0400, Pawlukiewicz Jane wrote:
Are you asking _why_ there are so many hops between yourself and the guy across town?
He's not, but answer is that BGP's key metric is AS path length. This can have very little to do with the optimality (expressed as efficient use of resources) of the actual packet path.
Cheers,
Mathew
Jane
brett watson wrote:
i sit behind cox-cable service at home, and in troubleshooting why my connectivity is *so* horrible, i find the following traceroute. does anyone do any sane routing anymore? does diameter matter (we used
about it a long, long while ago). i guess i'm just old and crusty but this seems to violate so many natural laws.
i find in more random testing that i seem to be a minimum of 15 hops from anything, and it's not just the # of hops, it's the *paths* i travel. bouncing between two cities several times, on several different
to talk provider
networks, from one border to the other.
wow.
-b
traceroute www.caida.org
1 10.113.128.1 30 unavailable 2 68.2.6.25 10 ip68-2-6-25.ph.ph.cox.net 3 68.2.0.26 40 ip68-2-0-26.ph.ph.cox.net 4 68.2.0.18 50 ip68-2-0-18.ph.ph.cox.net 5 68.2.0.10 20 ip68-2-0-10.ph.ph.cox.net 6 68.2.0.70 10 ip68-2-0-70.ph.ph.cox.net 7 68.2.14.13 10 chnddsrc02-gew0303.rd.ph.cox.net 8 68.1.0.168 20 chndbbrc02-pos0101.rd.ph.cox.net 9 68.1.0.146 30 dllsbbrc01-pos0102.rd.dl.cox.net 10 12.119.145.125 40 unavailable 11 12.123.17.54 30 gbr6-p30.dlstx.ip.att.net 12 12.122.5.86 51 gbr4-p90.dlstx.ip.att.net 13 12.122.2.114 80 gbr2-p30.kszmo.ip.att.net 14 12.122.1.93 50 gbr1-p60.kszmo.ip.att.net 15 12.122.2.42 70 gbr4-p40.sl9mo.ip.att.net 16 12.122.2.205 60 gbr3-p40.cgcil.ip.att.net 17 12.123.5.145 60 ggr1-p360.cgcil.ip.att.net 18 207.88.50.253 90 unavailable 19 64.220.0.189 80 ge5-3-1.RAR1.Chicago-IL.us.xo.net 20 65.106.1.86 70 p0-0-0-0.RAR2.Chicago-IL.us.xo.net 21 65.106.0.34 60 p1-0-0.RAR1.Dallas-TX.us.xo.net 22 65.106.0.14 120 p6-0-0.RAR2.LA-CA.us.xo.net 23 64.220.0.99 80 ge1-0.dist1.lax-ca.us.xo.net 24 206.111.14.238 211 a2-0d2.dist1.sdg-ca.us.xo.net 25 209.31.222.150 80 unavailable 26 198.17.46.56 140 pinot.sdsc.edu 27 192.172.226.123 91 cider.caida.org
| Mathew Lodge | mathew@cplane.com | | Director, Product Management | Ph: +1 408 789 4068 | | CPLANE, Inc. | http://www.cplane.com |
No, I'm suggesting that key interconnections should be preferenced where they provide better throughput/latency/whatever .. in the below example its unclear what causes the path to be the way it is but it doesnt look optimum in terms of ip hops altho it presumably is only 2 or 3 AS hops i'm saying that AS hops give no indication of the network size and there is some manual intervention to improve BGPs short sight Steve On Tue, 18 Jun 2002, Mathew Lodge wrote:
At 07:28 PM 6/18/2002 +0100, Stephen J. Wilcox wrote:
Path is one of the last things to be checked
BGP first checks all kinds of network admin defined things such as local prefs etc which ought to be properly set by the admins to ensure traffic is going the best way (which should include local interconnects rather than last resort transits). Then all things being well BGP can make choices on path!
So, you're advocating that the admin do all of the optimization manually for all destinations by setting preferences?
Mathew
On Tue, 18 Jun 2002, Mathew Lodge wrote:
At 01:33 PM 6/18/2002 -0400, Pawlukiewicz Jane wrote:
Are you asking _why_ there are so many hops between yourself and the guy across town?
He's not, but answer is that BGP's key metric is AS path length. This can have very little to do with the optimality (expressed as efficient use of resources) of the actual packet path.
Cheers,
Mathew
Jane
brett watson wrote:
i sit behind cox-cable service at home, and in troubleshooting why my connectivity is *so* horrible, i find the following traceroute. does anyone do any sane routing anymore? does diameter matter (we used
about it a long, long while ago). i guess i'm just old and crusty but this seems to violate so many natural laws.
i find in more random testing that i seem to be a minimum of 15 hops from anything, and it's not just the # of hops, it's the *paths* i travel. bouncing between two cities several times, on several different
to talk provider
networks, from one border to the other.
wow.
-b
traceroute www.caida.org
1 10.113.128.1 30 unavailable 2 68.2.6.25 10 ip68-2-6-25.ph.ph.cox.net 3 68.2.0.26 40 ip68-2-0-26.ph.ph.cox.net 4 68.2.0.18 50 ip68-2-0-18.ph.ph.cox.net 5 68.2.0.10 20 ip68-2-0-10.ph.ph.cox.net 6 68.2.0.70 10 ip68-2-0-70.ph.ph.cox.net 7 68.2.14.13 10 chnddsrc02-gew0303.rd.ph.cox.net 8 68.1.0.168 20 chndbbrc02-pos0101.rd.ph.cox.net 9 68.1.0.146 30 dllsbbrc01-pos0102.rd.dl.cox.net 10 12.119.145.125 40 unavailable 11 12.123.17.54 30 gbr6-p30.dlstx.ip.att.net 12 12.122.5.86 51 gbr4-p90.dlstx.ip.att.net 13 12.122.2.114 80 gbr2-p30.kszmo.ip.att.net 14 12.122.1.93 50 gbr1-p60.kszmo.ip.att.net 15 12.122.2.42 70 gbr4-p40.sl9mo.ip.att.net 16 12.122.2.205 60 gbr3-p40.cgcil.ip.att.net 17 12.123.5.145 60 ggr1-p360.cgcil.ip.att.net 18 207.88.50.253 90 unavailable 19 64.220.0.189 80 ge5-3-1.RAR1.Chicago-IL.us.xo.net 20 65.106.1.86 70 p0-0-0-0.RAR2.Chicago-IL.us.xo.net 21 65.106.0.34 60 p1-0-0.RAR1.Dallas-TX.us.xo.net 22 65.106.0.14 120 p6-0-0.RAR2.LA-CA.us.xo.net 23 64.220.0.99 80 ge1-0.dist1.lax-ca.us.xo.net 24 206.111.14.238 211 a2-0d2.dist1.sdg-ca.us.xo.net 25 209.31.222.150 80 unavailable 26 198.17.46.56 140 pinot.sdsc.edu 27 192.172.226.123 91 cider.caida.org
| Mathew Lodge | mathew@cplane.com | | Director, Product Management | Ph: +1 408 789 4068 | | CPLANE, Inc. | http://www.cplane.com |
SJW> Date: Tue, 18 Jun 2002 19:38:40 +0100 (BST) SJW> From: Stephen J. Wilcox SJW> in the below example its unclear what causes the path to be SJW> the way it is but it doesnt look optimum in terms of ip hops SJW> altho it presumably is only 2 or 3 AS hops I dub it... eOLPF. SJW> i'm saying that AS hops give no indication of the network SJW> size and there is some manual intervention to improve BGPs SJW> short sight BGP might be "good enough" if there were enough peering points. But peering is a business decision, and perhaps vulnerable to an "inverse tragedy of the commons" approach. How little can you get away with before customers leave? Why peer when you hopefully can force a sale here or there? Wars of attrition can be interesting. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
ML> Date: Tue, 18 Jun 2002 11:34:34 -0700 ML> From: Mathew Lodge ML> So, you're advocating that the admin do all of the ML> optimization manually for all destinations by setting ML> preferences? If I find "6347 3561 1" works better than "3549 1", I'll tune local-pref accordingly. The OP had a much more clear-cut case where "Cox AT&T XO" left much to be desired. Of course, note that we discuss outbound traffic. The OP might wish for a good return path, too, being a traffic sink. Without selective prepends, it's time for some coarse tuning. Won't start that thread again due to underwhelming interest (at least when I tried to put together a resource on providers who offer that). Looks like the simple answer is: few do. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
participants (3)
-
E.B. Dreger -
Mathew Lodge -
Stephen J. Wilcox