[AusNOG] AS703/Verizon routing contact

[Matthew Moyle-Croft]

On 15/02/2012, at 12:11 PM, Mark L. Tees wrote:

> What's got me stunned is that it appears other people with the same transit advertisements to Vocus are not being effected by the same issue.

Have you got another example?

> 
> I am going to triple check all the communities and paths just in case I have missed something. 
> 
> Does anyone know if Verizon use any of the route object databases for filtering?

Haven't been VzB transit customer for a long time, but I don't think so - usually large peers don't filter between themselves- just trust that they filter customers on the way in.  

MMC

> 
> On 15/02/2012, at 10:23 AM, Matthew Moyle-Croft wrote:
> 
>> VzB has a concept of different scale peers -  global or regional ones are preferred over single countries.  Optus are single country.   So, when you build out into APAC you need to be careful who your peering and transit is with and what communities you tag where.
>> 
>> MMC
>> 
>> On 14/02/2012, at 1:50 PM, Mark Tees wrote:
>> 
>>> Good afternoon listers,
>>> 
>>> Does anybody out there have any contacts for getting a routing issue
>>> within the Verizon network in Melbourne looked at?
>>> 
>>> Or, possibly a networking contact for Mvoice I can send a ticket number to?
>>> 
>>> Or, Vocus transit in Melbourne that we can get further
>>> traceroutes/evidence from?
>>> 
>>> We are getting high latency from our Sydney Vocus transit back to a
>>> voip service in Melbourne (Mvoice) that appears to be run on IP's
>>> originated in the Verizon network in Melbourne.
>>> 
>>> Our side: 101.0.127.3, Mvoice side: 203.166.10.151
>>> 
>>> I managed to get one of the admins from the other side to send us a
>>> trace route which reveals the route back is going a rather long way:
>>> 
>>> traceroute to 101.0.127.3 (101.0.127.3), 30 hops max, 52 byte packets
>>> 
>>> 1 system-203-166-10-129.mvoice.com.au (203.166.10.129) 0.511 ms 0.502 ms
>>> 0.406 ms
>>> 2 0.so-3-1-2.XL4.MEL1.ALTER.NET (210.80.34.229) 0.403 ms 0.445 ms 0.391 ms
>>> 3 0.so-0-2-1.XT4.SYD4.ALTER.NET (210.80.33.9) 12.840 ms 13.451 ms 12.771
>>> ms
>>> 4 0.so-0-1-0.XT4.SIN2.ALTER.NET (210.80.50.78) 113.888 ms 113.873 ms
>>> 119.663 ms
>>> 5 203.103.244.150 (203.103.244.150) 114.166 ms 114.209 ms 120.063 ms
>>> 6 63-218-214-22.static.pccwglobal.net (63.218.213.22) 115.455 ms 115.449 ms
>>> 115.383 ms
>>> 7 pos-0-1-0.bdr02.per02.wa.VOCUS.net.au (114.31.206.46) 115.898 ms 116.243
>>> ms 116.570 ms
>>> 8 ge-0-0-3.bdr01.per02.wa.VOCUS.net.au (114.31.206.32) 116.304 ms 116.196
>>> ms 116.379 ms
>>> 9 ip-108.206.31.114.VOCUS.net.au (114.31.206.108) 116.363 ms 116.454 ms
>>> 116.145 ms
>>> 10 ge-0-0-3-500.bdr01.syd04.nsw.VOCUS.net.au (114.31.192.219) 116.362 ms
>>> 115.920 ms 115.713 ms
>>> 11 ip-53.73.45.175.VOCUS.net.au (175.45.73.53) 116.240 ms 116.249 ms
>>> 116.087 ms
>>> 12 core-sw-a.c1.voc.digitalpacific.com.au (101.0.127.3) 117.665 ms 118.985
>>> ms 120.132 ms
>>> 
>>> As far as I am aware Verizon should be local pref'ing the routes from
>>> their Optus peering and getting back to us via Optus->Vocus.
>>> 
>>> Vocus is definitely sending our routes to Optus (checked via the Optus
>>> route server) and Optus appears to be directly connected to AS703 in
>>> some paths.
>>> 
>>> From what I can tell the AS path is even but Verizon should be doing
>>> something internally to prefer the local route to go via Optus or
>>> another local peering right?
>>> 
>>> I have asked the other side to lodge a ticket with Verizon but they
>>> didn't seem to believe routing was destination based and told me to
>>> lodge a ticket with Vocus. I have also asked our friendly Vocus NOC if
>>> they have anybody that might be able to get this looked at.
>>> 
>>> Anyway, if anybody out there has someone they can point me to I would
>>> be very thankful.
>>> 
>>> Regards,
>>> 
>>> Mark L. Tees
>>> _______________________________________________
>>> AusNOG mailing list
>>> AusNOG at lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>> 
>