Verizon no BGP route to some of AS38365 (182.61.200.0/24)

Tom Beecher beecher at beecher.cc
Thu Jul 21 16:34:36 UTC 2022


>
> 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.
>

I took a quick look this morning from our view at all prefixes we see with
an origin of AS38365.

- Some prefixes I see via multiple upstreams, and for those, CT (AS4134)
adds a +4 prepend via 701, but does not prepend anything else.
- Other prefixes I see via multiple upstreams , with no 701 path at all.

This would appear, at least externally, to be an intentional CT or Baidu
decision.

On Thu, Jul 21, 2022 at 12:21 PM Jon Lewis <jlewis at lewis.org> wrote:

> 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 <mhuff at 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.com at nanog.org> On Behalf Of
> holow29
> >       Sent: Thursday, June 23, 2022 5:49 PM
> >       To: nanog at 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?
> >
> >
> >
>
> ----------------------------------------------------------------------
>   Jon Lewis, MCP :)           |  I route
>   StackPath, Sr. Neteng       |  therefore you are
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220721/b5bb6d5a/attachment.html>


More information about the NANOG mailing list