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

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 > wrote: > >  > > >> On Thu, Jul 21, 2022 at 11:44 AM holow29 wrote: >> I would expect Verizon to be able to contact CT

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

On Thu, Jul 21, 2022 at 11:44 AM holow29 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...

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

On Thu, 21 Jul 2022, Paul Rolland wrote: Hello, On Thu, 21 Jul 2022 12:20:37 -0400 (EDT) Jon Lewis 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

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

Hello, On Thu, 21 Jul 2022 12:39:55 -0400 Tom Beecher wrote: > Well that shows my assertion was probably wrong. > > Given the geopolitical situation between the US and China, along with > certain government orders, could likely infer this is intentional. Well, I remember VZN when it was

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

Oddly enough I *do* see this via Verizon-but-XO: 182.61.200.0/22*[BGP/170] 3d 09:25:39, MED 100, localpref 100 AS path: 2828 4134 23724 38365 I, validation-state: unverified On Wed, Jul 20, 2022, at 3:18 PM, holow29 wrote: > > To follow up on this: > I've engaged

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

Well that shows my assertion was probably wrong. Given the geopolitical situation between the US and China, along with certain government orders, could likely infer this is intentional. On Thu, Jul 21, 2022 at 12:33 PM Paul Rolland wrote: > Hello, > > On Thu, 21 Jul 2022 12:20:37 -0400 (EDT) >

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

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

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

Hello, On Thu, 21 Jul 2022 12:20:37 -0400 (EDT) Jon Lewis 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

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

holow29, Usually decisions made about limiting route propagation outbound for certain prefixes tend to happen along financial and operational constraints. Remember, outbound route announcements control inbound traffic volumes. So, if you've got some full pipes across the ocean, for example, one

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

> > In this instance, I would define "correct" behavior as VZ having any route > to this subnet; after all, customers don't pay VZ to access just their > network or a subset of the internet. > https://en.wikipedia.org/wiki/Default-free_zone 701 is still (AFAIK) in the DFZ , meaning if they don't

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

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

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

In this instance, I would define "correct" behavior as VZ having any route to this subnet; after all, customers don't pay VZ to access just their network or a subset of the internet. You make a good point, though I would expect that if it isn't VZ's business decision to not have this route, they

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

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, whose responsibility is it other than CT? That is my question. Maybe in this instance, it is common in the industry

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

> > 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. > What defines 'correct'? ASN's routinely make traffic engineering or business decisions not to announce certain

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

>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

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

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

Re: Request for help: academic study (questionnaire)

Dear NANOGers, Payback time (unprocessed, interim aggregate analytics, more to come later): Next-generation metro area networks (google.com) , available until tomorrow Friday 22nd 8pm CET. I need more