Baldur Norddahl wrote:
Around here there are certain expectations if you sell a product called IP
Transit and other expectations if you call the product paid peering.
That some word is used for marketing hype with an intentional
self-contradicting definition is not my problem, at all.
The
On Mon, Oct 18, 2021 at 1:47 PM Matthew Petach wrote:
> On Mon, Oct 18, 2021 at 1:17 PM William Herrin wrote:
>> Since peering customers can only reach transit customers, it follows
>> that one of the customers in the equation is a fully-paid transit
>> customer. That fully paid customer's
On 10/18/21 1:51 PM, Sabri Berisha wrote:
I know that there are a lot of risks with hamfisted gubbermint
regulations. But even when StarLink turns the sky into perpetual
daylight and we get another provider, there are going to still be
painfully few choices, and too often the response to
- On Oct 18, 2021, at 12:40 PM, Michael Thomas m...@mtcc.com wrote:
> On 10/18/21 12:22 PM, Sabri Berisha wrote:
>> I totally agree. 100%. Now we just have to agree on the regulation that
>> we're talking about.
>>
>> My idea of regulation in this context is to get rid of the
On Mon, Oct 18, 2021 at 1:17 PM William Herrin wrote:
> On Mon, Oct 18, 2021 at 11:47 AM Matthew Petach
> wrote:
> > On Mon, Oct 18, 2021 at 11:16 AM William Herrin wrote:
> >> On Mon, Oct 18, 2021 at 10:30 AM Baldur Norddahl
> >> wrote:
> >> > Around here there are certain expectations if
On Mon, Oct 18, 2021 at 11:47 AM Matthew Petach wrote:
> On Mon, Oct 18, 2021 at 11:16 AM William Herrin wrote:
>> On Mon, Oct 18, 2021 at 10:30 AM Baldur Norddahl
>> wrote:
>> > Around here there are certain expectations if you sell a product called IP
>> > Transit and other expectations if
On 10/18/21 12:22 PM, Sabri Berisha wrote:
- On Oct 18, 2021, at 11:51 AM, Michael Thomas m...@mtcc.com wrote:
Hi,
On 10/18/21 11:09 AM, Sabri Berisha wrote:
The term "network neutrality" was invented by people who want to control
a network owned and paid for by someone else.
Your
- On Oct 18, 2021, at 11:51 AM, Michael Thomas m...@mtcc.com wrote:
Hi,
> On 10/18/21 11:09 AM, Sabri Berisha wrote:
>>
>> The term "network neutrality" was invented by people who want to control
>> a network owned and paid for by someone else.
>>
>> Your version of "unreasonable" and my
est-ix.com
- Original Message -
From: "Michael Thomas"
To: nanog@nanog.org
Sent: Monday, October 18, 2021 1:51:50 PM
Subject: Re: DNS pulling BGP routes?
On 10/18/21 11:09 AM, Sabri Berisha wrote:
>
> The term "network neutrality" was invented by people wh
On 10/18/21 11:09 AM, Sabri Berisha wrote:
The term "network neutrality" was invented by people who want to control
a network owned and paid for by someone else.
Your version of "unreasonable" and my version of "unreasonable" are on the
opposite end of the spectrum. I think it is
On Mon, Oct 18, 2021 at 11:16 AM William Herrin wrote:
> On Mon, Oct 18, 2021 at 10:30 AM Baldur Norddahl
> wrote:
> > Around here there are certain expectations if you sell a product called
> IP Transit and other expectations if you call the product paid peering. The
> latter is not providing
On Sun, Oct 17, 2021 at 4:54 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> Matthew Petach wrote:
>
> > I'd like to take a moment to point out the other problem with this
> > sentence, which is "antitrust agencies".
> >
> > One of the key aspects to both CDN providers and transit
>
On Mon, Oct 18, 2021 at 10:30 AM Baldur Norddahl
wrote:
> Around here there are certain expectations if you sell a product called IP
> Transit and other expectations if you call the product paid peering. The
> latter is not providing the whole internet and is cheaper.
The problem with paid
- On Oct 18, 2021, at 1:40 AM, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp wrote:
> Sabri Berisha wrote:
>
>> Therefore, anti-trust intervention is only considered in markets
>> where there are a relatively small amount of competitors and this
>> lack of competition harms the consumer,
On Mon, 18 Oct 2021 at 09:51, Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> But, with settlement free peering between tier 1 ISPs, tier 2
> ISPs having transit/paid peering with a tier 1 ISP will receive
> routes from peers of the tier 1 ISP. There is transit traffic
> exchanged
Mark Tinka wrote:
Yes, but nobody cares about Layer 1 or Layer 2.
As you wrote:
You can't tell me that US$700 million being spent to build a > submarine cable
around a continent is something to scoff at.
you do care.
Look, I'm not saying the ITU are bad
FYI, I'm not arguing
>
> Otherwise, CDN providers with their own backbone are free riders
> ignoring access costs.
>
I think the Pointy Hairs and Bean Counters would love it if they could
ignore all the monthly bills for the access costs that we generate.
On Sat, Oct 16, 2021 at 9:46 AM Masataka Ohta <
On 10/18/21 14:16, Masataka Ohta wrote:
As copper and optical fiber for access politically belongs to ITU,
DSL and optical fiber standards of ITU are followed by the IETF
world.
Yes, but nobody cares about Layer 1 or Layer 2.
Once the road is built, all anyone remembers is the car I drove
Mark Tinka wrote:
As you are seemingly requesting international legal formality,
let me point out there are "International Telecommunication
Regulations", based on which network neutrality is discussed
by ITU.
And since when does the IETF world follow the ITU standards?
As copper and
On 10/18/21 10:11, Masataka Ohta wrote:
As you are seemingly requesting international legal formality,
let me point out there are "International Telecommunication
Regulations", based on which network neutrality is discussed
by ITU.
And since when does the IETF world follow the ITU
Sabri Berisha wrote:
Therefore, anti-trust intervention is only considered in markets
where there are a relatively small amount of competitors and this
lack of competition harms the consumer, or when one or more dominant
parties use their position to force smaller companies into
unreasonable
Mark Tinka wrote:
What?
I will use my network for what I want my network to do for me. There
are no international rules about why a network must be built.
As you are seemingly requesting international legal formality,
let me point out there are "International Telecommunication
Regulations",
Baldur Norddahl wrote:
Neutral backbone providers don't peer with access/retail ISPs.
They sell transit to them.
FYI, that is called paid peering.
> Paid peering is not the same product as IP Transit. In general a
> packet never traverse two peering links because that would mean the
>
On 10/16/21 15:44, Masataka Ohta wrote:
What?
I will use my network for what I want my network to do for me. There are
no international rules about why a network must be built. Provided that
I am clear to those whom I want to connect to my network, I can do what
I want with it and not
søn. 17. okt. 2021 11.16 skrev Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp>:
> Jay Hennigan wrote:
>
> >> Access/retail ISPs have no problem by peering with neutral
> >> backbone providers.
> >
> > Neutral backbone providers don't peer with access/retail ISPs. They
> > sell transit to them.
- On Oct 17, 2021, at 4:50 AM, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp wrote:
Hi,
> Matthew Petach wrote:
>> One of the key aspects to both CDN providers and transit
>> providers is they tend to be multi-national organizations with
>> infrastructure in multiple countries on multiple
* mo...@necom830.hpcl.titech.ac.jp (Masataka Ohta) [Sun 17 Oct 2021, 11:17
CEST]:
Jay Hennigan wrote:
Neutral backbone providers don't peer with access/retail ISPs.
They sell transit to them.
FYI, that is called paid peering.
Can you please please please stop posting nonsense?
--
Matthew Petach wrote:
I'd like to take a moment to point out the other problem with this
sentence, which is "antitrust agencies".
One of the key aspects to both CDN providers and transit
providers is they tend to be multi-national organizations with
infrastructure in multiple countries on
Jay Hennigan wrote:
Access/retail ISPs have no problem by peering with neutral
backbone providers.
Neutral backbone providers don't peer with access/retail ISPs. They
sell transit to them.
FYI, that is called paid peering.
CDN provided backbone only reduces costs of other backbone
On Wed, Oct 13, 2021 at 6:26 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> Matthew Petach wrote:
>
> >>> With an anycast setup using the same IP addresses in every
> >>> location, returning SERVFAIL doesn't have the same effect,
> >>> however, because failing over from anycast
On 10/16/21 06:48, Masataka Ohta wrote:
Jay Hennigan wrote:
Access/retail ISPs should want to peer with CDNs as it greatly
reduces their transport costs.
Not at all.
Access/retail ISPs have no problem by peering with neutral backbone
providers.
Neutral backbone providers don't peer with
* mo...@necom830.hpcl.titech.ac.jp (Masataka Ohta) [Sat 16 Oct 2021, 15:50
CEST]:
Access/retail ISPs have no problem by peering with neutral backbone
providers.
Getting strong Marie-Antoinette vibes here.
-- Niels.
Jay Hennigan wrote:
Access/retail ISPs should want to peer with CDNs as it greatly reduces
their transport costs.
Not at all.
Access/retail ISPs have no problem by peering with neutral backbone
providers.
CDN provided backbone only reduces costs of other backbone providers
without reducing
Mark Tinka wrote:
Remember that CDN providers are not neutral at all.
Well, the purpose of a network is whatever its proprietor deems it to
be, and makes no false advertising about it.
What?
A private enterprise network that carries a company's internal traffic -
which may or may not
On 10/13/21 07:34, Masataka Ohta wrote:
But, I certainly mean that CDN operators should not request
peering directly to access/retail ISPs merely because they have
their own transit, because the transit is not at all neutral.
I'm not sure that I understand this. Peering is rarely if ever
On 10/13/21 17:24, Masataka Ohta wrote:
The problem is that, unlike neutral transit providers, "the bits"
is biased by the CDN provider.
Then, access/retail ISPs who also want to supply their own contents,
even though they must be neutral to contents provided by neutral
transit providers,
Tom Beecher wrote:
But, I certainly mean that CDN operators should not request
peering directly to access/retail ISPs merely because they have
their own transit, because the transit is not at all neutral.
I'm still confused.
Let's say I have a CDN network, with a datacenter somewhere, an
On Wed, Oct 13, 2021 at 10:56 AM Tom Beecher wrote:
> But, I certainly mean that CDN operators should not request
>> peering directly to access/retail ISPs merely because they have
>> their own transit, because the transit is not at all neutral.
>>
>
> I'm still confused.
>
> Let's say I have a
>
> But, I certainly mean that CDN operators should not request
> peering directly to access/retail ISPs merely because they have
> their own transit, because the transit is not at all neutral.
>
I'm still confused.
Let's say I have a CDN network, with a datacenter somewhere, an edge site
Tom Beecher wrote:
For network neutrality, backbone providers *MUST* be neutral
for contents they carry.
However, CDN providers having their own backbone are using
their backbone for contents they prefer, which is *NOT*
neutral at all.
As such, access/retail providers may pay for peering with
>
> For network neutrality, backbone providers *MUST* be neutral
> for contents they carry.
>
> However, CDN providers having their own backbone are using
> their backbone for contents they prefer, which is *NOT*
> neutral at all.
>
> As such, access/retail providers may pay for peering with
>
Matthew Petach wrote:
With an anycast setup using the same IP addresses in every
location, returning SERVFAIL doesn't have the same effect,
however, because failing over from anycast address 1 to
anycast address 2 is likely to be routed to the same pop
location, where the same result will
On Tue, Oct 12, 2021 at 8:41 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> Matthew Petach wrote:
>
> > With an anycast setup using the same IP addresses in every
> > location, returning SERVFAIL doesn't have the same effect,
> > however, because failing over from anycast address 1
Matthew Petach wrote:
With an anycast setup using the same IP addresses in every
location, returning SERVFAIL doesn't have the same effect,
however, because failing over from anycast address 1 to
anycast address 2 is likely to be routed to the same pop
location, where the same result will
Christopher Morrow wrote:
To be fair, it looks like FB has 4 /32's (and 4 /128's) for their
DNS authoritatives. All from different /24's or /48's, so they should
have decent routing diversity. They could choose to announce
half/half from alternate pops, or other games such as this.
Yup.
I
On Mon, Oct 11, 2021 at 8:07 AM Christopher Morrow
wrote:
> On Sat, Oct 9, 2021 at 11:16 AM Masataka Ohta <
> mo...@necom830.hpcl.titech.ac.jp> wrote:
>
>> Bill Woodcock wrote:
>>
>
[...]
>
> it seems that the problem FB ran into was really that there wasn't either:
>"secondary path to
On Sat, Oct 9, 2021 at 1:40 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> Christopher Morrow wrote:
> >> means their DNS servers were serving the zone, even after they
> >> recognize their zone data were too old, that is, expired.
>
> > that's not what this means. I think Mr.
On Sat, Oct 9, 2021 at 11:16 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> Bill Woodcock wrote:
>
> >> It may be that facebook uses all the four name server IP addresses
> >> in each edge node. But, it effectively kills essential redundancy
> >> of DNS to have two or more name
Owen DeLong wrote:
But, it has nothing specifically to do with anycast. As there
are other name servers with different IP addresses, there is
no reason to withdraw routes. So?
WRONG.
First, assuming that there are non-anycast name servers assumes
facts not in evidence.
There is no such
> On Oct 7, 2021, at 06:49 , Masataka Ohta
> wrote:
>
> William Herrin wrote:
>
This is quite common to tie an underlying service announcement to BGP
announcements in an Anycast or similar environment.
>>>
>>> Yes, that is a commonly seen mistake with anycast.
>> You don't know
Bill Woodcock wrote:
It may be that facebook uses all the four name server IP addresses
in each edge node. But, it effectively kills essential redundancy
of DNS to have two or more name servers (at separate locations)
and the natural consequence is, as you can see, mass disaster.
Yep. I
> On Oct 9, 2021, at 10:37 AM, Masataka Ohta
> wrote:
> It may be that facebook uses all the four name server IP addresses
> in each edge node. But, it effectively kills essential redundancy
> of DNS to have two or more name servers (at separate locations)
> and the natural consequence is, as
On Fri, Oct 8, 2021 at 10:04 AM Christopher Morrow
wrote:
> On Fri, Oct 8, 2021 at 10:22 AM Masataka Ohta
> wrote:
>> The end result was that our DNS servers became unreachable
>> even though they were still operational.
>>
>> means their DNS servers were serving the zone, even after
>>
Christopher Morrow wrote:
means their DNS servers were serving the zone, even after they
recognize their zone data were too old, that is, expired.
that's not what this means. I think Mr. Petach previously described
this,
He wrote:
So, the idea is that if the edge CDN node loses
(I'm going to hate myself in the morning, but)
On Fri, Oct 8, 2021 at 10:22 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> William Herrin wrote:
>
>
> https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/
>
> our DNS servers disable those BGP advertisements
William Herrin wrote:
If they are not using standard expire mechanism expecting
internal data still accessible even after external data
has expired, there is difference.
I give up.
To accept the reality of disastrous facebook failure? I know.
Although you have no knowledge whatsoever
>
> In facebook case, it was combined with poor understanding
> on short/long expiration period to cause the disaster.
>
Still, no.
The CAUSE of the outage was all of the FB datacenters being completely
disconnected from their backbone, and thus the internet. DNS breaking was a
direct RESULT of
On Thu, Oct 7, 2021 at 9:04 PM Masataka Ohta
wrote:
> William Herrin wrote:
> > Facebook withdrawing the BGP
> > routes to its anycasted public DNS servers as they expired made no
> > difference.
>
> If they are not using standard expire mechanism expecting
> internal data still accessible even
On 2021-10-08, at 07:25, Sabri Berisha wrote:
>
> Whenever there is an aviation incident, the keyboard warriors at pprune.org
> are always the first to start speculating about root causes
So we need an NTSB, BFU, ... for the Internet and widely used Internet
applications.
(And the other
Sabri Berisha wrote:
Let's for a moment contemplate about the sheer magnitude of
their operation. With almost 3 billion users worldwide, can you imagine the
amount of DNS queries they have to process? Their scale is unprecedented.
That's what I predicted about 20 years ago, which is why
I
On 10/8/21 07:25, Sabri Berisha wrote:
Whenever there is an aviation incident, the keyboard warriors at pprune.org
are always the first to start speculating about root causes, and complain how
the air crew made mistakes. They, the keyboard warriors, of course know how
best to fly an aircraft
- On Oct 7, 2021, at 9:03 PM, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp wrote:
Hi,
> It means DNS management of facebook is poor.
Whenever there is an aviation incident, the keyboard warriors at pprune.org
are always the first to start speculating about root causes, and complain how
William Herrin wrote:
Facebook's _internal_ DNS, while not anycasted, followed a similar
logic: if the data center is isolated and their data goes stale, they
stop serving potentially wrong answers.
As I already wrote, that is a standard mechanism of DNS with SOA
expiration period as is
On Thu, Oct 7, 2021 at 10:23 AM Masataka Ohta
wrote:
> William Herrin wrote:
> > Facebook's _internal_ DNS, while not anycasted, followed a similar
> > logic: if the data center is isolated and their data goes stale, they
> > stop serving potentially wrong answers.
>
> As I already wrote, that is
William Herrin wrote:
Facebook's _internal_ DNS, while not anycasted, followed a similar
logic: if the data center is isolated and their data goes stale, they
stop serving potentially wrong answers.
As I already wrote, that is a standard mechanism of DNS with SOA
expiration period as is
that they
also lost physical access to the building.
We all learned a lot and we're still learning.
Jean
-Original Message-
From: Bill Woodcock
Sent: October 7, 2021 12:45 PM
To: Jean St-Laurent
Cc: Masataka Ohta ; Bjørn Mork
; nanog@nanog.org
Subject: Re: DNS pulling BGP routes
On Thu, Oct 7, 2021 at 9:52 AM Masataka Ohta
wrote:
> But, this time, the reality strikes back.
Not really. Or at all. Facebook the external service was down hard as
soon as the cross-datacenter connections all failed. Whether or not
the BGP routes for the external DNS were withdrawn had no
William Herrin wrote:
It wasn't forgotten. Folks gained a lot of experience with anycast DNS
between 2002 and 2006. Not withdrawing the routes when the servers are
deemed malfunctioning turned out not to be an operationally sound
practice. The theory offered in 3258 was wrong.
So, from
> On Oct 7, 2021, at 6:25 PM, Jean St-Laurent via NANOG wrote:
>
> Nice document.
>
> In section 2.5 Routing, this is written:
>
> Distributing Authoritative Name Servers via Shared Unicast Addresses...
>
> organizations implementing these practices should
> always provide at least one
On 10/7/21 18:21, William Herrin wrote:
It wasn't forgotten. Folks gained a lot of experience with anycast DNS
between 2002 and 2006. Not withdrawing the routes when the servers are
deemed malfunctioning turned out not to be an operationally sound
practice. The theory offered in 3258 was
it be that by having the NS a,b in one mesh and c,d in another was a
mistake?
-Original Message-
From: NANOG On Behalf Of Masataka
Ohta
Sent: October 7, 2021 11:27 AM
To: Bjørn Mork
Cc: nanog@nanog.org
Subject: Re: DNS pulling BGP routes?
Bjørn Mork wrote:
>>>>> This
On Thu, Oct 7, 2021 at 8:28 AM Masataka Ohta
wrote:
> My comment on the rfc is that it is simply wrong.
>
> See also:
>
> https://datatracker.ietf.org/doc/html/rfc3258
> While it would be
> possible to have some process withdraw the route for a specific
> server instance when it
Bjørn Mork wrote:
This is quite common to tie an underlying service announcement to BGP
announcements in an Anycast or similar environment.
Yes, that is a commonly seen mistake with anycast.
You don't know what you're talking about.
I do but you don't.
Masataka Ohta writes:
> William Herrin wrote:
>
This is quite common to tie an underlying service announcement to BGP
announcements in an Anycast or similar environment.
>>>
>>> Yes, that is a commonly seen mistake with anycast.
>> You don't know what you're talking about.
>
> I do but
>
> But, the reality is that it is impossible to correctly
> recognize server is unavailable or to correctly withdraw
> routes only when server is unavailable.
>
Not true at all.
On Thu, Oct 7, 2021 at 9:50 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> William Herrin wrote:
>
>
On 10/7/21 13:18, Jean St-Laurent wrote:
Something public that we know now, is that it's possible to totally shut down
facebook and restart it.
Can we shutdown the full internet one day and see if it will restart properly
without too much hack here and there?
I think one thing that I
William Herrin wrote:
This is quite common to tie an underlying service announcement to BGP
announcements in an Anycast or similar environment.
Yes, that is a commonly seen mistake with anycast.
You don't know what you're talking about.
I do but you don't.
If your anycast node stops
On Wed, Oct 6, 2021 at 10:44 PM Masataka Ohta
wrote:
> Jared Mauch wrote:
> > This is quite common to tie an underlying service announcement to BGP
> > announcements in an Anycast or similar environment.
>
> Yes, that is a commonly seen mistake with anycast.
You don't know what you're talking
: October 7, 2021 2:31 AM
To: nanog@nanog.org
Subject: Re: DNS pulling BGP routes?
On 10/7/21 08:26, Hank Nussbacher wrote:
>
> Better question is why do we not see any FB netadmins on NANOG? I'm
> not talking about October 2021 but rather over the past 3-5 years how
> many FB
On 10/7/21 08:26, Hank Nussbacher wrote:
Better question is why do we not see any FB netadmins on NANOG? I'm
not talking about October 2021 but rather over the past 3-5 years how
many FB techies have posted here like we see people from Google,
Cloudflare, Akamai, etc.?
They are likely
On 06/10/2021 22:38, Jon Lewis wrote:
But I just don't understand why this is a good idea at all. Network
topology is not DNS's bailiwick so using it as a trigger to withdraw
routes seems
Everything I've seen posted about this (whether from Facebook directly,
or others) is so vague as to
Jared Mauch wrote:
This is quite common to tie an underlying service announcement to BGP
announcements in an Anycast or similar environment.
Yes, that is a commonly seen mistake with anycast.
I would say more like Application availability caused the BGP routes
to be withdrawn.
Considering
On 10/7/21 00:22, Michael Thomas wrote:
But it wasn't just their DNS subnets that were pulled, I thought. I'm
obviously really confused. Anycast to a DNS server makes sense that
they'd pull out if they couldn't contact the backend. But I thought
that almost all of their routes to the
On 10/7/21 00:37, Michael Thomas wrote:
Maybe the problem here is that two things happened and the article
conflated the two: the DNS infrastructure pulled its routes from the
anycast address and something else pulled all of the other routes but
wasn't mentioned in the article.
The
On Wed, 6 Oct 2021, Michael Thomas wrote:
On 10/6/21 3:33 PM, Jon Lewis wrote:
On Wed, 6 Oct 2021, Michael Thomas wrote:
People have been anycasting DNS server IPs for years (decades?). So,
no.
But it wasn't just their DNS subnets that were pulled, I thought. I'm
obviously really
On 10/6/21 3:33 PM, Jon Lewis wrote:
On Wed, 6 Oct 2021, Michael Thomas wrote:
People have been anycasting DNS server IPs for years (decades?).
So, no.
But it wasn't just their DNS subnets that were pulled, I thought. I'm
obviously really confused. Anycast to a DNS server makes sense
On Wed, 6 Oct 2021, Michael Thomas wrote:
People have been anycasting DNS server IPs for years (decades?). So, no.
But it wasn't just their DNS subnets that were pulled, I thought. I'm
obviously really confused. Anycast to a DNS server makes sense that they'd
pull out if they couldn't
On 10/6/21 2:58 PM, Jon Lewis wrote:
On Wed, 6 Oct 2021, Michael Thomas wrote:
On 10/6/21 2:33 PM, William Herrin wrote:
On Wed, Oct 6, 2021 at 10:43 AM Michael Thomas wrote:
So if I understand their post correctly, their DNS servers have the
ability to withdraw routes if they
On Wed, 6 Oct 2021, Michael Thomas wrote:
On 10/6/21 2:33 PM, William Herrin wrote:
On Wed, Oct 6, 2021 at 10:43 AM Michael Thomas wrote:
So if I understand their post correctly, their DNS servers have the
ability to withdraw routes if they determine are sub-optimal (fsvo).
The
On 10/6/21 2:33 PM, William Herrin wrote:
On Wed, Oct 6, 2021 at 10:43 AM Michael Thomas wrote:
So if I understand their post correctly, their DNS servers have the
ability to withdraw routes if they determine are sub-optimal (fsvo).
The servers' IP addresses are anycasted. When one data
On Wed, Oct 6, 2021 at 10:43 AM Michael Thomas wrote:
>
> So if I understand their post correctly, their DNS servers have the
> ability to withdraw routes if they determine are sub-optimal (fsvo).
The servers' IP addresses are anycasted. When one data center
determines itself to be
On Wed, 6 Oct 2021, Michael Thomas wrote:
So if I understand their post correctly, their DNS servers have the ability
to withdraw routes if they determine are sub-optimal (fsvo). I can certainly
understand for the DNS servers to not give answers they think are unreachable
but there is always
- On Oct 6, 2021, at 10:42 AM, Michael Thomas m...@mtcc.com wrote:
Hi,
> My guess is that their post while more clear that most doesn't go into
> enough detail, but is it me or does it seem like this is a really weird
> thing to do?
In large environments, it's not uncommon to have DNS
On Wed, Oct 6, 2021 at 10:45 AM Michael Thomas wrote:
> So if I understand their post correctly, their DNS servers have the
> ability to withdraw routes if they determine are sub-optimal (fsvo). I
> can certainly understand for the DNS servers to not give answers they
> think are unreachable but
Yes, it really is common to announce sink routes via bgp from destination
services / proxies and to have those announcements be dynamically based on
service viability.
On Wed, Oct 6, 2021, 12:56 Jared Mauch wrote:
> This is quite common to tie an underlying service announcement to BGP
>
This is quite common to tie an underlying service announcement to BGP
announcements in an Anycast or similar environment. It doesn’t have to be
externally visible like this event for that to be the case.
I would say more like Application availability caused the BGP routes to be
withdrawn.
They most likely sent an update to the DNS servers for TLV DNSSEC and in
oversight forgot they needed to null something's out of the workbook to not
touch the BGP instances.
I'd hardly believe that would be triggered by the dns server itself.
--
J. Hellenthal
The fact that there's a highway
97 matches
Mail list logo
