I looked at this a little last night, but didn't have time to write an
email about it. Verizon has a lookingglass:
https://www.verizon.com/business/why-verizon/looking-glass/
which you can use to see that Verizon has no route covering 182.61.200.0.
Looking at routeviews, I see routes for 182.61.200.0/22,
and 182.61.200.0/21, but no path via Verizon.
Also looking at routeviews, there's ample evidence that Verizon and China
Telecom peer, so the question is, does China Telecom not advertise these
routes to Verizon, or is Verizon rejecting them for some reason? I
suspect only engineers at CT and VZ can answer that.
On Wed, 20 Jul 2022, holow29 wrote:
To follow up on this:I've engaged Verizon's executive office to finally try to
get to a network engineer (because I don't have a contact myself). The
(proxied) response
from the engineer was that they aren't receiving any announcements for these
routes to AS701, and I would need to take it up with Baidu. I guess I would
like to understand
if that seems reasonable to people since it is my presumption that Baidu would
return and say something similar (that they advertise their routes to their
peers correctly
and to take it up with Verizon). To me, it seems like there is clearly a
failing in one of Verizon's peers where they are not advertising or accepting
this route
correctly, but that it would be incumbent on Verizon to do the legwork to fix
it since they are the ones who know their peering agreements and have these
contacts.
Unfortunately it seems like policy that Verizon pushes any issues that aren't
internal routing issues to an external party, but surely they have a
responsibility to
maintain their peering and routes to external services as well. In other words,
this type of buckpassing does not seem right to me (and I've heard it from them
on other
routing issues before), especially given that they are the ones empowered to
fix it. Any thoughts?
(As it happens, pan.baidu.com now resolves to an IP range that is routable by
Verizon, but it could always revert, and it seems like Verizon should have
these routes
regardless.)
Thanks.
On Fri, Jun 24, 2022 at 7:41 AM Matthew Huff <[email protected]> wrote:
From my limited vantage point it appears that there is some issue between
Verizon & Baidu. Baidu has 182.61.0.0/16 registered, but is only advertising
pieces
of it globally (or at least from what I can see). In our tables,we are
receiving none from Verizon of the subnets that are advertised directly from
Baidu
(origin AS of 38365). The few within that registered range that have a
different origin AS are coming to us from Verizon. For example:
*> 182.61.0.0/19 144.121.203.141 0 46887 3356
4134 58466 38365 i
*> 182.61.0.0/18 144.121.203.141 0 46887 6461
4134 58466 38365 38365 i
*> 182.61.32.0/19 144.121.203.141 0 46887 3356
4134 58466 38365 i
*> 182.61.64.0/18 204.148.121.221 0 701 6453
55967 i
* 182.61.128.0/23 204.148.121.221 0 701 4134
4134 4134 4134 4134 58540 ?
*> 182.61.130.0/24 144.121.203.141 0 46887 6461
4134 23724 38365 38365 38365 i
*> 182.61.130.0/23 144.121.203.141 0 46887 6461
4134 58466 38365 38365 i
*> 182.61.131.0/24 144.121.203.141 0 46887 6461
4134 23724 38365 38365 38365 i
*> 182.61.132.0/23 144.121.203.141 0 46887 3356
4134 58466 38365 i
*> 182.61.132.0/22 144.121.203.141 0 46887 6461
4134 58466 38365 38365 i
*> 182.61.134.0/23 144.121.203.141 0 46887 3356
4134 58466 38365 i
*> 182.61.136.0/22 144.121.203.141 0 46887 3356
4134 58466 38365 i
*> 182.61.136.0/21 144.121.203.141 0 46887 6461
4134 58466 38365 38365 i
*> 182.61.140.0/22 144.121.203.141 0 46887 3356
4134 58466 38365 i
*> 182.61.144.0/21 144.121.203.141 0 46887 3356
4134 58466 38365 i
*> 182.61.144.0/20 144.121.203.141 0 46887 6461
4134 58466 38365 38365 i
*> 182.61.160.0/19 204.148.121.221 0 701 6453
55967 i
*> 182.61.192.0/23 144.121.203.141 0 46887 3356
4134 58540 i
*> 182.61.194.0/23 144.121.203.141 0 46887 3356
4134 58540 i
*> 182.61.200.0/22 144.121.203.141 0 46887 6461
4134 23724 38365 i
*> 182.61.200.0/21 144.121.203.141 0 46887 6461
4134 58466 38365 38365 i
*> 182.61.216.0/21 144.121.203.141 0 46887 6461
4134 58466 38365 38365 i
*> 182.61.223.0/24 144.121.203.141 0 46887 6461
4134 58466 38365 38365 i
*> 182.61.224.0/19 144.121.203.141 0 46887 6461
4134 58466 38365 38365 i
We are getting the 182.61.200.0/21 and 182.61.200.0/22 from all of our
other peers:
asr-inet2#sh ip bgp 182.61.200.0/21
BGP routing table entry for 182.61.200.0/21, version 15779018
Paths: (2 available, best #2, table default)
Advertised to update-groups:
3
Refresh Epoch 1
54004 6128 1299 4134 58466 38365 38365, (aggregated by 38365
119.75.208.225)
148.77.99.201 from 148.77.99.201 (24.157.4.25)
Origin IGP, localpref 100, valid, external, atomic-aggregate
rx pathid: 0, tx pathid: 0
Updated on Apr 29 2022 21:02:05 EDT
Refresh Epoch 1
46887 6461 4134 58466 38365 38365, (aggregated by 38365 119.75.208.225)
129.77.17.254 from 129.77.17.254 (129.77.40.7)
Origin IGP, metric 0, localpref 100, valid, internal,
atomic-aggregate, best
rx pathid: 0, tx pathid: 0x0
Updated on May 3 2022 04:02:50 EDT
From: NANOG <[email protected]> On Behalf Of holow29
Sent: Thursday, June 23, 2022 5:49 PM
To: [email protected]
Subject: Verizon no BGP route to some of AS38365 (182.61.200.0/24)
I've been trying (to no avail) for over a month now to get Verizon to
investigate their lack of BGP routing to 182.61.200.0/24, which hosts Baidu
Wangpan at
pan.baidu.com (Baidu's cloud services/equivalent of Google Drive).
Easily verified through Verizon's Looking Glass.
We all know Verizon's BGP routing is a disaster, but does anyone have any ideas?
----------------------------------------------------------------------
Jon Lewis, MCP :) | I route
StackPath, Sr. Neteng | therefore you are
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
