Re: net neutrality and peering wars continue
On 20 June 2013 13:07, Bill Woodcock wo...@pch.net wrote: On Jun 19, 2013, at 7:21 PM, Benson Schliesser bens...@queuefull.net wrote: The sending peer (or their customer) has more control over cost. I'll assume that, by sending peer, you mean the content network. If so, I disagree. The content network has no control whatsoever over the location of the eyeball customer. The eyeball customer has sole control over his or her own location, while the content network has sole control over the location from which they reply to requests. Therefore, control is shared between the two sides. And both are incentivized to minimize costs. If both minimize their costs, overall costs are minimized. That's why this system works. I think his point was that the receiving side can massage their BGP announcements all they like but the sending network has more instantaneous control over how the traffic will flow. This is before analysis, communication, application of policies / contractual arrangements, de-peering etc.etc. kick in. cheers Marty
Re: SingTel (AS7473) is only announcing ConnectPlus (AS9911) routes to Level3 (AS3356) in SJC?
$quoted_author = Adam LaFountain ; At first I wanted to say this looks like a policy move on 7473's part but on further investigation I'm not sure if they're punishing themselves or doing some very specific traffic routing possible for balancing purposes. I was inclined to believe it was related to cost, especially seeing the prepend for AOL (1668), but began to dimiss that as I saw two known _peers_ haul the traffic to the west coast as well: Hence our confusion, too. The only thing we could come up with was some reason (capacity, cost, etc.etc.) to prefer the Singapore to SJC path. But then why peer at LINX with other large ASes? In terms of figuring it out for sure I dont think L3 will tell you anything as they probably don't know. SingTel's your best bet but good luck with that unless you become a customer. I'm going to vote backbone traffic balancing by SingTel. We have a customer who is a customer. Ticket lodged. SingTel NOC are aware of it but no feedback or changes, yet. cheers Marty
SingTel (AS7473) is only announcing ConnectPlus (AS9911) routes to Level3 (AS3356) in SJC?
Anyone on the list who can offer an explanation about the following
scenario? We have taken this up with providers at either end but it
will take awhile to filter up to the ASes in question.
We were seeing a London to Singapore connection go via San Jose
causing a 50%+ increase in latency.
It appears that SingTel (AS7473) is only announcing ConnectPlus
(AS9911) routes to Level3 (AS3356) in SJC.
However they have many adjacencies in many countries and other routes
of both AS7473 and it's other downstreams don't appear to be affected
(although I haven't tested them all).
Traceroutes are appended at the end but to see for yourself use
202.176.222.0 as a BGP or traceroute query in the Level3 looking glass
for both London and any other location, then compare with 167.172.93.0
Checking another large AS at random, they see AS7473 announcing AS9911
routes in London.
thanks
Marty
Show Level 3 (London, England) Traceroute to 202.176.222.212
1 ae-34-52.ebr2.London1.Level3.net (4.69.139.97) 0 msec 0 msec 0 msec
2 ae-42-42.ebr1.NewYork1.Level3.net (4.69.137.70) 68 msec 68 msec
ae-41-41.ebr1.NewYork1.Level3.net (4.69.137.66) 72 msec
3 ae-71-71.csw2.NewYork1.Level3.net (4.69.134.70) 68 msec
ae-81-81.csw3.NewYork1.Level3.net (4.69.134.74) 72 msec
ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) 76 msec
4 ae-82-82.ebr2.NewYork1.Level3.net (4.69.148.41) 80 msec
ae-92-92.ebr2.NewYork1.Level3.net (4.69.148.45) 84 msec
ae-72-72.ebr2.NewYork1.Level3.net (4.69.148.37) 80 msec
5 ae-2-2.ebr4.SanJose1.Level3.net (4.69.135.185) 144 msec 144 msec 144 msec
6 ae-74-74.csw2.SanJose1.Level3.net (4.69.134.246) 140 msec
ae-94-94.csw4.SanJose1.Level3.net (4.69.134.254) 148 msec
ae-64-64.csw1.SanJose1.Level3.net (4.69.134.242) 144 msec
7 ae-12-69.car2.SanJose1.Level3.net (4.68.18.4) 140 msec
ae-32-89.car2.SanJose1.Level3.net (4.68.18.132) 140 msec
ae-22-79.car2.SanJose1.Level3.net (4.68.18.68) 140 msec
8 SINGAPORE-T.car2.SanJose1.Level3.net (4.79.42.230) 140 msec 140
msec 136 msec
9 POS3-2.sngtp-ar2.ix.singtel.com (203.208.182.205) [AS7473
{APNIC-AS-2-BLOCK}] 148 msec 152 msec
203.208.182.105 [AS7473 {APNIC-AS-2-BLOCK}] 136 msec
10 ge-4-0-0-0.plapx-cr2.ix.singtel.com (203.208.183.173) [AS7473
{APNIC-AS-2-BLOCK}] 148 msec
xe-1-0-0-0.plapx-cr3.ix.singtel.com (203.208.183.170) [AS7473
{APNIC-AS-2-BLOCK}] 140 msec 140 msec
11 ge-2-1-0-0.sngtp-dr1.ix.singtel.com (203.208.183.62) [AS7473
{APNIC-AS-2-BLOCK}] 348 msec
so-2-0-0-0.sngtp-cr1.ix.singtel.com (203.208.149.181) [AS7473
{APNIC-AS-2-BLOCK}] 336 msec
ge-3-0-0-0.sngtp-dr1.ix.singtel.com (203.208.183.66) [AS7473
{APNIC-AS-2-BLOCK}] 360 msec
12 ae0-0.sngtp-cr1.ix.singtel.com (203.208.183.57) [AS7473
{APNIC-AS-2-BLOCK}] 328 msec
ge-4-0-0-0.sngtp-cr2.ix.singtel.com (203.208.182.102) [AS7473
{APNIC-AS-2-BLOCK}] 336 msec
202.160.250.226 [AS7473 {APNIC-AS-2-BLOCK}] 336 msec
13 ge-3-0-0-0.sngtp-dr1.ix.singtel.com (203.208.183.66) [AS7473
{APNIC-AS-2-BLOCK}] 348 msec 524 msec 416 msec
14 202.160.250.226 [AS7473 {APNIC-AS-2-BLOCK}] 328 msec 344 msec
203.208.232.234 [AS9911 {APNIC-AS-3-BLOCK}] 336 msec
15 203.208.129.29 [AS9911 {APNIC-AS-3-BLOCK}] 308 msec * 412 msec
16 203.208.232.234 [AS9911 {APNIC-AS-3-BLOCK}] 376 msec * *
17 * * *
Show Level 3 (London, England) Traceroute to 167.172.93.1
1 SINGAPORE-T.car1.London1.Level3.net (212.187.160.190) 0 msec 4 msec 0 msec
2 so-0-2-0-0.sngtp-ar6.ix.singtel.com (203.208.151.133) [AS7473
{APNIC-AS-2-BLOCK}] 284 msec 276 msec 276 msec
3 203.208.152.134 [AS7473 {APNIC-AS-2-BLOCK}] 288 msec 284 msec 288 msec
4 ge-5-0-8-0.hkgcw-cr3.ix.singtel.com (203.208.152.37) [AS7473
{APNIC-AS-2-BLOCK}] 276 msec 276 msec
ge-5-0-2-0.hkgcw-cr3.ix.singtel.com (203.208.152.117) [AS7473
{APNIC-AS-2-BLOCK}] 284 msec
5 * * *
Router: mpr1.lhr1.uk.above.net
Command: traceroute 202.176.222.212
traceroute to 202.176.222.212 (202.176.222.212), 30 hops max, 40 byte packets
1 195.66.225.10 (195.66.225.10) 0.991 ms 2.433 ms 0.927 ms
2 so-0-2-0-0.sngtp-ar6.ix.singtel.com (203.208.151.133) 455.799 ms
271.095 ms 254.167 ms
3 203.208.149.210 (203.208.149.210) 255.751 ms 254.794 ms 254.838 ms
4 202.160.250.226 (202.160.250.226) 263.850 ms 263.912 ms 292.504 ms
5 203.208.129.29 (203.208.129.29) 275.109 ms 282.247 ms 313.901 ms
6 203.208.232.234 (203.208.232.234) 265.677 ms 265.604 ms 266.072 ms
7 * * *
Re: ARIN IP6 policy for those with legacy IP4 Space
$quoted_author = Joe Greco ; Using the organization to justify the need for the organization is circular reasoning. I would have thought the role ARIN (and the other RIRs) has to play is clear from it's charter (registration of number resources to ensure uniqueness and fair allocation of a finite resource). And the need for someone or something to serve that role is best highlighted when it fails (e.g. duplicate ASes in RIPE and ARIN last year). Anyways, the non-answers to these questions are very illuminating. Feel free to not deploy IPv6. Or get a /48 from a tunnel broker or your ISP. You have plenty of options, just one of which is provider independent space from ARIN. cheers Marty
Re: ARIN IP6 policy for those with legacy IP4 Space
$quoted_author = Joe Greco ; Perhaps the true issue is that what you see as broken is perceived as working as intended by much of the community and membership? That's a great point. Would you agree, then, that much of the community and membership implicitly sees little value in IPv6? Is that orthogonal to Owen's statement? You can claim that's a bit of a stretch, but quite frankly, the RIR policies, the sketchy support by providers, the lack of v6 support in much common gear, and so many other things seem to be all conspiring against v6 adoption. I need only point to v6 adoption rates to support that statement. Which rates would those be? http://www.ipv6actnow.org/info/statistics/ IPv6 has had a slow start but it's certainly picking up. cheers Marty
Re: REVERSE DNS Practices.
$quoted_author = Steven Champeon ; adsl.internode.on.net gaw.internode.on.net padsl.internode.on.net adsl.adelaide.on.net link.internode.on.net as0.adl2.internode.on.net lns1.adl2.internode.on.net ...and so on and so on. You do realise that they were all infrastructure devices which would never send email? LNS isn't a big enough giveaway? Oh, there's also 'static.internode.on.net', so the safe bet is to assume that ALL of the rest are dynamic. Correct bet? Who knows. That's a safe assumption. So ignore static.internode.on.net, their MXes and block everything else *.on.net cheers marty -- xterm The problem with America is stupidity. I'm not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? http://www.bash.org/?4753
Re: Peer Filtering
$quoted_author = Paul Stewart ; I would like to know whether folks are limiting their peering sessions (BGP peering at public exchanges) only by max-prefix typically? Are we the only folks trying to filter all peers using IRR information? No, you're not the only ones. We've run across several peers now with 10,000+ prefixes who do not register barely half their prefixes in an IRR ... meaning that we deny the rest by default. Most peering agreements I have read require either registration of routes in an appropriate place or notification to the other party of an appropriate filter for their routes and/or AS path. In Au we have multi-lateral peering exchanges and at least the one $work is on requires registration of routes with the exchange provider who generates the appropriate filters. cheers marty -- supine: From the Latin for lying on one's back, to be supine has come to mean inactive. But as Damien Hirst suggests with his maxim Minimum effort for maximum effect, there's nothing wrong with being inactive. An Idler's Glossary - http://www.hermenaut.com/a158.shtml
Re: Peer Filtering
$quoted_author = John van Oppen ; Here in the US we don't bother, max-prefix covers it... It seems that US originated prefixes are rather sporadically entered into the routing DBs. ...and you are not worried about someone leaking a subset of routes? I understand that most failure cases would trigger a max-prefix but a typo could allow just enough leakage to not hit max-prefix and yet still make something important unreachable. cheers marty -- with usenet gone, we just don't teach our kids entertainment-level hyperbole any more. --Paul Vixie http://www.merit.edu/mail.archives/nanog/2006-01/msg00593.html
Re: Australian Co-Lo
$quoted_author = Bernard Becker ; Looking for recommendations for carrier neutral co-lo facility for Melbourne Australia. Our searches so far seem to turn up sites either on Telstra or Optus affiliated co-lo facilities. We need to be in a carrier neutral space with access to any of the major providers. This was created by a SAGE-AU member in response to a similar request. http://maps.google.com/maps/ms?msa=0msid=117984623075363696099.000439d39e1c7bd8d46c2ie=UTF8z=12 cheers Marty
