Pull to refresh

Comments 160

Ну встала у СММ-щиков работа ненадолго, ну какие-то бизнес-механизмы легли. А вот что будет если лягут подключенные облачно jQuery или bootstrap например. Кажется мне, больше половины сайтов перестанут работать корректно.

Уверен, сервисы FB посещают гораздо больше людей, чем все сайты, которые получают ключевые библиотеки с одного какого-то публичного CDN. Будет повод перенести библиотеки к себе, ведь межсайтовое кэширование уже сломано и толку от единых CDN стало гораздо меньше.

"межсайтовое кэширование уже сломано" поясните пожалуйста

Если сайты abc.com и cba.com запрашивают одинаковые файлы cdn.com/script.js и cdn.com/style.css. То браузер будет качать эти файлы лишь однажды.

подозреваю, что теперь эта фича кеширования изменена.

Да, теперь браузер скачает файл дважды и будет хранить две копии. Именно так работает Network Partitioning. С ростом пропускной способности каналов связи польза от общего кэша уменьшилась настолько, что лучше отказаться от него в пользу большей приватности.
В современных браузерах кеш разделяется по доменам для того, чтобы нельзя было отследить, посещали ли вы другой сайт. Например, я могу разместить скрипт с уникальным названием на сайте А, и посмотреть, загружали ли вы этот ресурс при открытии сайта Б.

Сайт Б может своими скриптами подключить тот самый уникальный скрипт с сайта А и замерить время, сколько он будет грузиться. Если этот скрипт загрузится практически мгновенно — значит он уже был в кэше.

Так и думал, спасибо.

Плюс к этому еще навскидку performance.now и :visited.

А почему нельзя сохранить время загрузки этого скрипта с сайта А и отдавать сайту Б с такой же задержкой?

Сайт Б может попробовать сначала много раз реально запросить скрипт с сайта А (добавляя незначащие GET-параметры), построить текущее распределение времени загрузки данного скрипта, а потом запросить тот же скрипт ровно таким образом, как это делает сайт А, и проверить статистическую вероятность того, что время загрузки этого скрипта подходит под построенное распределение. Учитывая, что интернет сущность весьма динамичная, вполне может оказаться, что записанная заранее задержка не сойдётся с текущей реальностью, и опять же вскроется, что пользователь уже был на сайте А.

Толк от хранения библиотек в CDN пропал с массовым переходом на http/2.

Но ведь CDN снижает нагрузку на собственный сайт и уменьшает время, за которое грузится ресурс, из-за того, что этот самый ресурс грузится с более близкого к конечному пользователю узла CDN. Разве нет?

Разве нет?

Так утверждают. Но мой опыт ясно говорит – все сайты, которые используют CDN, медленные. И наоборот, все быстрые сайты, CDN не используют.


Да, может причина и следствие перепутаны, но я бы сказал – делайте сайты, которые в CDN не нуждаются.

Да-да. Если у них нет хлеба, пусть едят пирожные.

В целом утверждение не совсем корректное. Взрослые быстрые сайты конечно же используют CDN, только они используют CDN как часть своей "собственной" облачной инфраструктуры, со своими собственными доменами, а не как какую-то левую публичную зависимость.
Cloudflare там, Google Cloud CDN, Cloudfront и иже с ними.

Я думаю, тут разные сущности CDN.
Например, я писал сервис на Angular. В нем есть возможность деплоя на другой УРЛ. Был выбрал AWS.
Никто другой не будет использовать эти скрипты на своих сайтах. А вот для пользователей скорость загрузки сайта уменьшается, так как запрос идет к ближайшему для них серверу.

Знали бы вы, как спасает CDN, когда твои сервера раздают hls-видео на тысячи людей

Это тоже влияет, но основной эффект снижения нагрузки предполагался за счет уменьшения количества запросов в веб-серверу, которые не могли выполнятся параллельно в рамках одного TCP соединения, что стало не актуальным с появлением http/2, который поддерживает мультиплексирование.

Повод перенести библиотеки к себе был всегда. Именно из за ненулевой вероятности такого случая.
И даже частичная потеря связности для клиента (например РКН) запросто обрушит сайт при недоступности того же jquery.
Никогда не понимал почему оставляют внешнюю ссылку. И никогда не принимал работу с внешними ссылками на ресурсы.

Помнится когда под горячую руку РКН при попытках блокировки телеграмма попали гугловские айпишники, огромное количество сайтов встало колом от того, что использовало блокирующую загрузку шрифтов с гуглового fonts.google.com. (браузер ждал таймаута и только после него загружал сайт).

Не оправдывая завязку на внешние ресурсы, замечу, что по стандарту browser не должен создавать много одновременных соединений с одним доменом. А с разными — может. Поэтому, положив библиотеки на другие домены, можно добиться их параллельной загрузки. Если бы ещё и про fallback кто-нибудь думал при этом, то это было бы не худшим решением.

Во многих случаях, как уже заметили выше, HTTP/2 нивелирует выигрыш, при условии нормальной ширины канала между сервером и пользователем.

Даже если и так, никто не мешает использовать, например, домен static.yourdomain.com, который вы контролируете, для хранения зависимостей.

Не оправдывая завязку на внешние ресурсы, замечу, что по стандарту browser не должен создавать много одновременных соединений с одним доменом.


Можно чуть подробнее об этом?
Ссылку на стандарт? И «много» — это сколько?
RFC2616 §8.1.4
A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.

На практике в последние годы без прокси-сервера лимит у некоторых browser-ов можно было повысить или даже был повышен по умолчанию, с прокси-серверами было максимум 2, когда я проверял в последний раз.

RFC-2119:


SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.

Если очень хочется, то можно.

Уже ложилось, помню. Про быстренько перенесли к себе те, кто умел, остальные дождались поднятия, ничего особенного.

Заскриню этот коммент чтобы запостить этот скрин когда уже совсем скоро эта страна будет отрезана от интернета в рамках т. н. "суверенного интернета". Ничего ведь особенного не произошло.

В описываемом вами сценарии все сайты, размещённые на зарубежных хостингах, будут недоступны

Плохо что до сих пор остались люди, не понимающие сарказм, живя в этой стране, у них же все нормально и "ничего особенного" не произошло.

Ага, плюс встала работа везде, где есть "Login with Facebook"

а эти ресурсы должны же кэшироваться браузером?

Должны, только вначале же для этого их нужно откуда-то получить чтобы закэшировать уже в браузере юзера

У меня в последние несколько месяцев bootstrap отрыгивается на некоторых сайтах

Принцип Парето в отношении сайтов еще более перекошенный. Как правило это легаси недобложики в своей массе с околонулевым траффиком, сейчас любой уважающий себя июнь даже калькулятор запихивает в вебпак, а веб проекты, в которые не стыдно кидать свое резюме, используют route 53.

А из-за чего двери у сотрудников заблокировались и они не могли попасть в свои офисы?

Как вариант, система пропусков тоже использовала инфраструктуру мордокниги и не могла достучаться для проверки допуска.

Грубо говоря, чтобы поднять упавшую систему надо чтобы упавшая система была не упавшей.

Интересно, а как разблокируется в случае стихийного бедствия? Должна же быть у охраны "тревожная" кнопка.

Возле дверей, изнутри комнат есть что то вроде пожарной кнопки, которая разблокирует дверь. Но и охрана получает сигнал, что дверь разблокирована аварийно.

По правилам пожарной безопасности изнутри двери должны открываться безо всяких кнопок. Сигнализацию, конечно, это не отменяет.

Там два блока на стене, первый "красный пожарный" - про спуск лифтов на первый этаж, разблокировку всей дверей в здании и сирену. Второй - зеленый, который аварийно разблокирует конкретную дверь.

UPD. "Там" это не FB, это в нашем кампусе другой конторы

UFO landed and left these words here

Это касается пожарных выходов, а не входов и это российские правила. В других странах все по своему

В штатах ещё строже — там выходы вообще датчиком движения оснащаются, который открывает двери при любом движении внутри.


И иногда 'движение' может быть из очень неожиданных источников:

В порядке стёба - получает через лежащую систему?

Сломай систему - войди через выход! )))

Скорее наоборот — почини систему :D

Хотел бы я на это посмотреть, в случае с ростовым турникетом:)

Например, в конфигурации устройств СКУД управляющий сервер или сервер БД был прописан не по IP, а по доменному имени... А DNS-а то нету из-за испорченного BGP, и все.

Ну или просто сам сервер был внутри сети, к которой пропал доступ из-за косяка в том же BGP. Вариантов довольно много, на самом деле.

Больше интересно, почему анонсы по BGP пропали.

Согласен, что интересно… Для этого нужно ждать информацию от самой Facebook. Им явно придётся выдать на публику какой-то отчёт. Пока есть только такое.

Информация от ФБ исходит из пиар-департамента, так что это или лукавство для отвода глаз, или просто прямая ложь, чаще последнее. Уверен, в этот раз будет точно так же, признаки уже есть типа заявлений ФБ в Тви, что падение затронуло «некоторых» пользователей.

Так что как раз не от ФБ.

Вероятно, подпись под постом -- "Santosh Janardhan, VP Infrastructure" -- объясняет больше, чем сам пост.

Да, по три that в одном предложении – это, конечно, не пиар-департамент готовил текст. Тем не менее, любой сотрудник ФБ обязан согласовывать такие штуки, это прямо сказано вот тут https://developers.facebook.com/devpolicy/, ищите «PR Guidelines» на странице.

Я скорее о том, что там никаких подробностей. Пост построен по такому принципу:

  1. Извините, что у нас получилась ошибочка, ведь нашими сервисами пользуются сотни миллионов.

  2. Мы всё поняли, научились, такого больше не будет.

  3. Нашими сервисами пользуются сотни миллионов (опять), и вам лучше не думать о плохом, ведь сотни миллионов мух не могут ошибаться.

или лукавство для отвода глаз, или просто прямая ложь

Тошно от лжи уже. Особенно когда она такая прямая и очевидная. Они просто всех дураками выставляют

У нас много ребят в FB работают. На перерыве коллега встречался с одним и вот что написал:
So a friend told me that someone did a change on TF or other automation system that changed some config on all of the routers and withdraw the routes, also like everyone knows its the same infra as all of their internal tools bu they have an emergency infra just for these cases that they can fail over all of their internal system to this infra.. apperantly 90% of the company was not familliar with this infra :sweat_smile:

So no one knew how to fail over to it and most of them did not even know it exists.

UFO landed and left these words here

Второй закон Вейнберга: если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию.

в последнее время похожее все чаще можно сказать и про администраторов, которые настраивают роутеры.

Как человек, первую половину нулевых проработавший в Тир-1 провайдере, могу сказать, что так было всегда.

Этот второй закон очень слабая аналогия. Здания не обладают такой внутренней сложностью, как программы.

Так может это не причина, а следствие. Чем проще структура, тем сложнее её поломать.


Ну и на любой замок поглядите — средневековый или наших дней. Там такие кубернетесы внутри порой бывают. А обычные человейники — это как сайты на CMS, их делают для массового потребления.

Не понял вашу мысль. Вы полагаете, что программы надо писать гораздо проще, чем пишутся сейчас? Вряд ли их можно писать существенно проще, кроме того, это серьёзно замедлит время разработки, что никого не устроит.

В целом, программы едва ли не всегда должны быть написаны проще, но есть нюанс... как говорится.

здания не перепроектируют заново по мере возведения каждого этажа. Или сроки горят: сдаём MVP без водопровода.

Вспомнились фотографии со строительства под олимпиаду в Сочи)

Agile архитектура желаете?

Программы тоже не перепроектируют. Вокруг готовые библиотеки и фреймворки.

полностью не перепроектируют конечно, но например добавить пару этажей в проект к уже строящемуся дому — это вполне распространенная вещь на самом деле
добавить пару этажей в проект к уже строящемуся дому
А как насчёт несущие конструкции подвинуть, чтобы планировку изменить? ;)

Уважаемый строитель, перенесите-ка здание на 5 метров влево. А можно ещё такое же здание, только на 50 метров дальше? Как нужны ещё ресурсы?

В 16:58 UTC мы заметили, что Facebook перестал анонсировать маршруты для своих DNS-префиксов.

Это происходит по той причине, что в DNS, как и во многих других системах в интернете, используется свой механизм маршрутизации.

Автор оригинальной статьи зачем то(может для упрощения) смешал в одну кучу 7 и 4 урони модели OSI. Маршрутизация это 4, DNS 7. И связаны они в этой истории тем, что DNS сервер, как и любой другой сервер тоже находится в сети и взаимодействует в тч на 4 уронве. И в DNS нет ни маршуртизации(в строгом смысле этого слова) ни анонсирования маршрутов.

Все таки маршрутизация это 3 уровень модели osi

Но остальная мысль правильная нет смысла говорить о доступности dns если нет маршрутизации.

А как микросервисы должны спасти от поломки маршрутизации? Монолит бы не сломался?

А причем здесь микросервимы-то? Они так-то немного для другого нужны.

Ну да, было бы большим чудом, если бы микросервисы спасали ещё от сбоев сетевого оборудования! :)

Конечно это была шутка с моей стороны, но если серьезно, то микросервисы понижают устойчивость к сетевым ошибкам.

Рад видеть, что нашлись люди, понявшие мою шутку)

В статье нет ответа что именно сломалось у Facebook, то что DNS серверы Facebook не отвечали, разве что.

так вроде официального отчета от самой фб и не было, вот, вся инфа, что есть представлена

Так все подсети (ASN) Фейсбука просто пропали из Интернета. А для юзеров это было заметно по неработающему DNS, так как первое, что мы делаем при открытии ссылок это резолвим домен.

Там похоже не только DNS для внешних клиентов отваливался, т.к. если прописать в hosts ip facebook.com он все равно не открывался.

Отвалились не все подсети, как минимум анонсы ipv6 были доступны (судя по ripestat). Но при этом эти сервера не отвечали на пинги и на днс запросы.

Ну так автономная система отвалилась, а IP у них в собственности. Вот и привет

Что вы подразумеваете под "автономная система отвалилась"? Изначально подразумевалось что связанность роутеров с миром осталась, просто пропала часть анонсов.

В подтверждение: их static.xx.fbcdn.net (сервера, обслуживающие этот ип) оставался доступен и вполне отдавал статику для клиентов у кого не протух кеш днс (или есть запись в hosts).

AS у серверов статики (31.13.84.0/24 is announced by AS32934) и у ДНС (129.134.30.0/24 is announced by AS32934) одинаковые, т.е. получается что роутеры связанность имели. Как минимум в части ДЦ. И соответственно возник вопрос - почему анонс по ipv6 для серверов обслуживающих ДНС был, но при этом сами сервера не отвечали.

Кто-то хорошо заработал на этом;)

Даже если не было атаки, а всего лишь рученки влезли куда не надо...

Акции скинул В 16:49 UTC, например :)

"В 16:58 UTC мы заметили, что Facebook перестал анонсировать маршруты для своих DNS-префиксов" -- вот тут мой мозг сломался. =)) DNS и BGP в одну кучу.
Для тех кто не в курсе, в протоколе BGP есть только апдейты маршрутов соседней автономной зоны. DNS это этажом выше, и никак не пересекаются.

Это такой перевод, или там действительно такие чапаевские птицы?

Перевод в порядке. Вероятно, это место следует читать как "В 16:58 UTC мы заметили, что Facebook перестал анонсировать маршруты для префиксов серверов своих DNS-зон."

Ну автономная система анонсирует айпишники в глобальную сеть. Днс сервера у них свои и на своих айпишниках (странно что нет резерва в другой AS). Ну а дальше просто каскад. Нет ИП, нет ДНС, нет КЭША, нет данных

Похоже, Цукерберг предал идеалы демократии и завязал все сервисы на себя лично, без резервирования...

Сегодняшние события служат мягким напоминанием о том, что интернет — это очень сложная и взаимозависимая система из миллионов систем и протоколов, взаимодействующих друг с другом. Доверие, стандартизация и кооперация между задействованными в нём организациями — ключ к его работоспособности для почти пяти миллиардов активных пользователей со всего мира.

...


В 1968 году Министерство обороны США посчитало, что на случай войны Америке нужна надёжная система передачи информации, и предложило разработать для этого компьютерную сеть.

А потом, что-то пошло не так.

Да в общем-то всё так: несмотря на отключение куска сети, через который ходила существенная часть мирового трафика — весь остальной интернет продолжал работать.

Сравните это, например, с историей Evergreen весной, когда затор в одной точке поставил раком мировую логистику на пару недель.

Тем не менее что-то в архитектуре явно сделано нехорошо.

Это же огромная контора с серверами по всему миру. Так почему он упал весь, а не для какой-то части пользователей?

Построили недостаточно отказоустойчивым.

Есть одна древняя рекомендация - не держать все авторитативные NS в одной IP-сети класса C.

По хорошему, со времён внедрения CIDR она должна звучать как "не держать все авторитативные NS в одной AS".

Для отказоустойчивости надо иметь DNS в разных ASN, которые должны управляться отдельно, т.е. так, чтобы такие проблемы с BGP анонсами не становились глобальными.

Я так неверной строчкой в Ansible продовые сервера положил разом. Кластер, вся фигня, но не спасло от обычной ошибки в конфиге.

>А потом, что-то пошло не так.

А потом все стали переходить от децентрализованной модели изначальной сети к централизованной, где есть выделенные точки управления всей сетью. Руками ходить на каждое отдельное устройство всем надоело, решили разливать изменения всякими модными зумерскими ansible'ами, использовать REST API, NET CONF и прочие централизованные вещи. И вот одно неосторожное движение и вместо единичного отказа лежит уже вся инфраструктура.

netconf и rest api не имеют никакой связи с централизацией. rest api может вызываться/выставляться наружу микросервисами, конфиги по netconf тоже заливаются/принимаются микросервисами.

Руками никто никуда не ходит, потому что рук не хватит в энтерпрайзе и хайлоаде. Для этого используется ETSI NFV MANO. Другое дело, что внешний/внутренний периметр доступа есть в любой системе, хоть централизованной, хоть нет и если положить его весь, то может оказаться сложным удаленно его поднять обратно. Это я вам как ответственный бумер сообщаю.

Другое дело, что "положить его весь" не должно быть доступно одной группе людей, это факт. Проблема, похоже, действительно в централизации, но не архитектуры инфраструктуры, а ролей доступа к настройкам BGP. Возможно также частично проблема, а точнее задержки в её решении, заключаются и в децентрализованности BGP.

Можно было просто разные подсети анонсить из разных ASN, да ещё и с разных точек и ДЦ. Плюс, иметь DNS-серверы в разных ДЦ, в разных подсетях.

У них все так и было. Но судя по последнему отчету, они потеряли всю backbone network между дата центрами из за ошибки внесения изменений в конфигурацию роутеров (то самое централизованное управление скорее всего, про которое я писал выше). А их днс настроены так, что если теряют связь с основными сервисами, то убирают анонсы по BGP для своих адресов (считается, что данный ДЦ сломался и не надо роутить на него пользователей). И вот так получилось, что все их ДНСы во всех ДЦ потеряли связь по внутренней Backbone сети с каким то центральными сервисами и отозвали BGP анонсы.

В целом моя мысль подтверждается - виной всему излишняя централизация, которая смывает границы "домена проблемы". Сетевые протоколы всегда строились так, чтобы "домен проблемы" (объем затрагиваемых сервисов и устройств в случае точечного сбоя) был как можно меньше. Но централизованное управление ломает этот принцип и раздувает "домен проблемы" до максимальных значений, вопреки изначальному принципу.

Интересно, как скоро государства захотят себе право авторизации запросов на инфраструктурные работы для критически важных сервисов? Сейчас почти в любой крупной конторе есть какой-либо комитет с большими шишками, которые пускают или не пускают крупные работы и тормозят тем самым процесс. Представил себе в этой роли условный Роскомнадзор - и стало страшно.

UFO landed and left these words here

админы, похоже, настолько не верили в столь масштабное падение

Чуваки из Cloudflare тоже первым делом полезли проверять со своей стороны. Правда их сервисы не так просто ребутнуть "на всякий случай".

Кстати, вспомнил, у меня тоже кабельный исчез на пару минут примерно в тоже время, что и лёг фейсбук

Тоже самое было, отправил в ребут домашний роутер=)

UFO landed and left these words here

С 18:30 (по московскому) пропал проводной интернет с диагнозом "DNS lookup error". Перезагрузки роутера не помогали. Закончилась вся эта свистопляска где-то в 22-23 по московскому. Провайдер правда тоже так себе.

Место: ГДР, Дрезден.

Вероятно, DNS серверы провайдера просто легли от массовых запросов от всех FB приложений его клиентов, которые ожесточённо пытались найти дорогу домой.

На сотовых от хуавея новых тоже погас инет,так как телефоны проверяли его наличие пингуя что-то FB. Многие телефоны проверяют наличие инета пингуя 1.1.1.1. Вот если он погаснет...

А он погаснет, так как Роскомнадзор уже мечтает его заблокировать.

Роскомнадзору не обязательно же блокировать пинги до 1.1.1.1, достаточно закрыть доставку tcp пакетов на 443 порт, чтобы перестал работать DoH.
Аналогичная ситуация была на телефоне huawei p30. Мобильный интернет не работал. При попытке подключиться к WiFi телефон писал что сеть якобы без доступа в интернет, хотя с другого телефона от WiFi интернет был. Так что очевидно что проверка наличия интернета как то завязана на сервисах FB.

У меня провайдер локальный (довольно крупный) вообще умер на сутки! Ровненько одновременно с падением Фейсбука. По телефону - автоответчик "у нас авария, исправляем". Через час пришла смс "авария на магистральном кабеле". И только сегодня в обед кое-как заработало.

Киев.

У меня тоже лежал провайдер домашний вместе с фб

Екатеринбург

У меня MTS отрубился на несколько минут тоже.

В стародавние времена, когда миллениалы ещё не пребывали в эйфории от удалёнки, а зумеры только начали появляться на свет, у бородатых сисадминов уже в ходу была такая примета: "Удалённая настройка сети - это к дальней дороге..." :)

6 часов даунтайма как раз очень похожи на типичный экстренный перелёт :)

Отличная идея! Вполне даже похоже.

Может быть, я не понимаю, но BGP, это протокол прикладного уровня, поверх TCP. Он служит для динамического обновления маршрутов. Отсутствие BGP пакетов не должно сразу валить всю сеть.


Может быть через некоторое время, когда последние маршрутные таблицы не обновятся и перестанут соответствовать реальной конфигурации сети. Да и тогда, должны упасть только те части сети, которые поменялись.


Или я не понимаю как работает Интернет?

Нет, интернет работает не так.

Нет keepalive = сессия падает по hold time = всё принятое из нее удаляется. Hold time обычно секунд 180.

Как сессии упадут - всем с кем есть BGP разошлются апдейты, те своим пирам разошлют и тд.

Минут 10 - и префиксов фейсбука как бы и не было никогда :-)

А это всегда так работало? Потому что мне кажется, что коммуникации на нижних уровнях, как-то не должны зависеть от протокол прикладного уровня.

Я так понимаю, вы сейчай про модель OSI говорите. Она концептуально-условная, служит только для для разделения "слоёв". Никаких реальных зависимостей там нет.

В реальности оказалось удобно обмениваться маршрутами через прокотокол построенный на TCP. Перенос BGP ниже - если, например, накостылять какой-нить MAC-BGP где будут только MAC-адреса в заголовках - смысла не имеет. Что так апдейты пропадут и l3 уйдёт, что так.

Они и не зависят в том смысле, что если согласованно остановить демон, который отвечает за BGP, на всех роутерах сети — маршруты сохранятся и сеть продолжит работу.


Но пока этот самый демон активен — он управляет маршрутами, и может эти самые маршруты вовсе удалить. Что и делает при исчезновении партнёра, который эти маршруты передал.

Ну, так гораздо понятнее. Выходит, что они себе сепуку сделали. Ведь, после падения сети, TCP тоже работать не будет. И восстановить маршруты не получится, так как BGP работает поверх TCP.

BGP -- не единственный способ управлять маршрутами. Достаточно задать маршрут вручную, и TCP поднимется. (Что, по-видимому, и было сделано.)

Нет, они именно починили BGP, а не руками загружали на магистральные маршрутизаторы партнёров статические маршруты до своих IP диапазонов.
Вас не смущает, что DHCP тоже происходит до работы сети? Разумеется TCP работать будет. И они всего-то обрушили DNS. Кого-то до сих пор волнует DNS? Есть же facebookcorewwwi.onion и facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion

Все нормальные приложения тоже обязаны иметь ip fallback.

В нормальной конфигурации BGP не управляет теми маршрутами, через которые сам работает: внешние соединения BGP работают между соседними роутерами, а внутренние работают через сеть, управляемую другими протоколами или тоже статикой.


А вот что и правда у них наверняка отвалилось, это SSH и SNMP.

Вот вы пошли в IANA и купили айпишники. Вам надо сообщить миру о том, что они у вас есть. Тут включается AS + BGP. Вот кто то что то сделал и по таймауту эти связи ушли + спецы не могли достучаться до серверов (через интернет ходят?).
Тут либо надо было находиться внутри сети L2/L3 с наличием IP, либо топать в офис пешком

Падение BGP для внешних операторов - следствие какой-либо внутренней проблемы внутри ЦОД ФБ.

Такое часто бывает при редистрибьюции full view в IGP. Ложится вся сеть и определение первопричины занимает очень много времени (т.к. тасктрекеры тоже лежат).

При редистрибьюции в igp не пропадут анонсы. С чего бы….

Ну если только BGP роутер узнавал об этой сети из IGP, не имел интерфейсов в этой сети и не было прописано типа ip route x.x.x.x/x null 0. То да сеть пропадёт если роутеры igp отвалятся.

Я бы сделал ставку на «автоматизацию» как писали выше.

При случайной редистрибьюции full view в IGP (к примеру ospf) железка умирает на пересчете топологии, и все остальные - тоже. Может она, конечно, пристрелит процесс ospf - но это случается не всегда, да и маршруты из IGP перестают поступать - bingo!

Автономная сеть перестала анонсировать себя в глобальной сети, пул айпишников выпал по таймауту.

У меня подгрузка ленты на фб перестала работать ещё за день до полного падения.

У меня дежавю. Такое ощущение, что буквально недавно - не больше года-двух - была статья про сбой в интернете и тоже связанный с BGP. И что-то с настройкой и обновлением роутеров. Не помню, что это было, и найти не могу.

Да такое регулярно случается. То по глупости, то по умыслу и глупости (как кто-то там пытался через BGP у себя на территории блочить ютуб, в итоге заблочил его для половины мира). Все следствие того, что все эти протоколы разрабатывались давно, когда веб был уделом профессионалов и работал на доверии, в итоге корневые протоколы не содержат никаких адекватных защит от дураков и хакеров.

Точно, это был Cloudflare в прошлом году! Спасибо!

А ведь это же гениально простая схема воздействия на рынок акций. К примеру, кое-кто заинтересованный решил закупиться по хорошей цене и пролил цену таким способом.
UFO landed and left these words here
Схема потому и идеальна, что концов не найдешь! Ну пожурят ответственного инженера, «допустившего» ошибку «где вы были с 8 до 11?» (Райкин). А тот, кому надо — купит акции по хорошей цене через различные хедж-фонды и концов не найдешь.
«Мой план прост и потому гениален» (Большой Лебовски) ))

Ради инетерса нужно будет через несколько дней посмотреть на рынок акций и цену Facebook.

Путаете стиль(медведи) и инсайдеров

Не хочется уподобляться сторонникам теории заговора, но какое интересное совпадение с определенными событиями.

Норм, много кто заметил это совпадение, такие мысли современному человеку должны автоматом в голову приходить – как гипотеза. Не обязательно же в неё верить.

я счастливый человек. Абсл не заметил проблем с Интернетом и сервисами FB.

Машина стояла на качке торрентов. DNS в роутерах прописан Google, Яндекс, и че то еще бесплатное, провайдерское стер от греха. FB - зареган, но не пользуюсь. WA - раз в неделю. Insta ? меня там 3 раза банили. на 4-ый раз голых котиков постить, было как не с руки, на время сбоя.

А так. Когда кто-то мне начинает грить, что Интернет невозможно откл, я тихонько посмеиваюсь, и напоминаю, что погранзона 30 км, а где то и целые районы с областями.

Only those users with full accounts are able to leave comments. Log in, please.