Baido is NOT a customer of Verizon. They are a customer of China Telecom who has a peering relationship with Verizon.
> On Jul 21, 2022, at 1:41 PM, Christopher Morrow <morrowc.li...@gmail.com> > wrote: > > > > >> On Thu, Jul 21, 2022 at 11:44 AM holow29 <holo...@gmail.com> wrote: >> I would expect Verizon to be able to contact CT and figure out why they >> aren't passing the correct routes just as I might expect Baidu to do the >> same thing, I suppose. Ultimately, > > You seem to be misunderstanding the relationship here... > Baidu is a CUSTOMER of VZ/701 > > VZ's only responsibility here is to provide reachabilty to the routes which > Baidu announces to VZ. > There's no reason VZ should believe anything other than the fact that Baidu > is not sending the particular prefix (or covering routes) to VZ 'today'.. for > reasons which are entirely Baidu's. > >> whose responsibility is it other than CT? That is my question. Maybe in this >> instance, it is common in the industry for this to be the responsibility of >> Baidu. That seems counterintuitive to me as it is Verizon without the proper >> route ultimately, but I am not an expert. > > The person announcing the routes (or not) is the one who makes the decision > to do so... > There's, of course, a possibility that VZ (or any isp instead of VZ in this > particular case) has decided to filter certain prefixes from Baidu's peering, > but > that's not generally the case for ISPs... > > Note: there are no ROA for the /24 in question, but Baidu does claim they may > announce: 182.61.200.0/22 > according to IRR data... > >> Certainly, I think it is incorrect to ask the customer to try to resolve >> these issues after bringing it to the attention of these services. If >> Verizon couldn't reach one of Google's edge servers, would it be Verizon or >> Google's responsibility to fix that if the issue were an intermediate peer >> failing to broadcase the correct route? I have the sneaking suspicion that >> Verizon might actually take some action in that instance... >> > > you have misunderstood the customer/provider relationship I suspect. > >> On Thu, Jul 21, 2022 at 9:31 AM Tom Beecher <beec...@beecher.cc> wrote: >>>> 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. >>> >>> Baidu is behind CT. If CT is not passing on routes to 701 , what exactly do >>> you expect Verizon to do about it? >>> >>> >>>> On Wed, Jul 20, 2022 at 6:40 PM holow29 <holo...@gmail.com> 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 <mh...@ox.com> 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 <nanog-bounces+mhuff=ox....@nanog.org> On Behalf Of holow29 >>>>> Sent: Thursday, June 23, 2022 5:49 PM >>>>> To: nanog@nanog.org >>>>> 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?
