[YuryD]

5 минут назад, zhenya` сказал:

Шта? У вас в аплинках одни колхоз-телекомы?

 Монстры онли, но пробиться до спецов - очень непросто. А уж как я фуллвью выпрашивал, пока резолюцию "да и х.  с ними дайте." не поймал. Суть глупостей в переписке по ТТ у монстров - они всё цитируют в переписке, и внутренние сообщения тоже. За фуллвью кстати требовали приложение к договору и бабки согласно, но это другой монстр. Не говоря уж о блокировке, когда мы под ддосом стояли, и никакого комюнити...

[zhenya`]

эм. никогда дополнительно ничего не просил по управляющим коммунити. в райпе глядите и выставляете. потом на лг обязательно проверьте. AS20485 / AS8359 / AS31133 всегда все работало из коробки (кроме блэкхол коммунити).

[Черномазов]

С AS3216 тоже проблем не было.

[Черномазов]

Задам и свой глупый вопрос в тему: Есть ли смысл во 2й АС для обеспечения отказоустойчивости?

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

[alibek]

AS это не средство для отказоустойчивости.

AS это сеть с единой политикой маршрутизации.

Как она может помочь в отказоустойчивости — даже не представляю.

[Черномазов]

17 минут назад, alibek сказал:

AS это не средство для отказоустойчивости.

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

 

22 минуты назад, alibek сказал:

AS это сеть с единой политикой маршрутизации.

Сетевому узлу же никто не мешает входить в несколько сетей с разными политиками маршрутизации. Это к примеру.

[straus]

7 часов назад, Черномазов сказал:

Задам и свой глупый вопрос в тему: Есть ли смысл во 2й АС для обеспечения отказоустойчивости?

AS- это не физическое устройство, а просто номер, плюс протоколы взаимодействия. Наличие второй AS никак не влияет на отказоустойчивость.
 

[Черномазов]

@straus 

Некорректная конфигурация тоже приводит к отказу. Хотя связи с физическим устройством может не иметь.

Приведённый выше пример отказа не связан с аппаратной проблемой. Отказ был решён только костылём со стороны аплинка. Через месяц после обнаружения.

[straus]

Поясняю. Для тех, кто в пределах первой AS, при её отказе - наличие второй AS никак не поможет. И наоборот.
 

[Черномазов]

@straus 

Спасибо за пояснение. В общем случае, согласен.

Но есть, на мой взгляд, интересные частные контрпримеры:

1. Если есть возможность, на время сбоя, перевести часть из АС1 во АС2, то это позволит восстановить доступность для этой части до восстановления АС1. Затраты, необходимые для этого перевода, выведем за скобки.

2. Если ресурс имеет адреса как из АС1, так и из АС2, то при проблемах с АС1 он сохранит доступность по адресам из АС2, что снизит влияние сбоя АС1 на этот ресурс. А при соответствующем мониторинге можно относительно оперативно вносить изменения в записи DNS, что в среднесрочной перспективе снизит влияние сбоя ещё больше.

Может быть, в этих примерах есть ошибки? Имеют ли они вообще смысл? Известны ли случаи таких сбоев? Возможно, использование 2х АС в каких-то ситуациях просто вредно?

[dignity]

34 минуты назад, Черномазов сказал:

@straus 

Спасибо за пояснение. В общем случае, согласен.

Но есть, на мой взгляд, интересные частные контрпримеры:

1. Если есть возможность, на время сбоя, перевести часть из АС1 во АС2, то это позволит восстановить доступность для этой части до восстановления АС1. Затраты, необходимые для этого перевода, выведем за скобки.

2. Если ресурс имеет адреса как из АС1, так и из АС2, то при проблемах с АС1 он сохранит доступность по адресам из АС2, что снизит влияние сбоя АС1 на этот ресурс. А при соответствующем мониторинге можно относительно оперативно вносить изменения в записи DNS, что в среднесрочной перспективе снизит влияние сбоя ещё больше.

Может быть, в этих примерах есть ошибки? Имеют ли они вообще смысл? Известны ли случаи таких сбоев? Возможно, использование 2х АС в каких-то ситуациях просто вредно?

Лютая наркомания

[rm_]

21 hours ago, Черномазов said:

Есть ли смысл во 2й АС для обеспечения отказоустойчивости?

Это как иметь вторую квартиру на случай если в первой туалет засорится.

[Черномазов]

@rm_ 

Всякая аналогия относительна.

Но если туалет не будет работать месяц... А с учётом разницы в скоростях обычной жизни и электронной можно говорить и о годе... И идея о 2й квартире становится не такой сомнительной. ;) Особенно, в случае проблем с кишечником. У всей семьи.

[alibek]

2 часа назад, Черномазов сказал:

1. Если есть возможность, на время сбоя, перевести часть из АС1 во АС2, то это позволит восстановить доступность для этой части до восстановления АС1. Затраты, необходимые для этого перевода, выведем за скобки.

2. Если ресурс имеет адреса как из АС1, так и из АС2, то при проблемах с АС1 он сохранит доступность по адресам из АС2, что снизит влияние сбоя АС1 на этот ресурс. А при соответствующем мониторинге можно относительно оперативно вносить изменения в записи DNS, что в среднесрочной перспективе снизит влияние сбоя ещё больше.

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

 

1. Какой сбой? AS это виртуальная сущность, аварии по физике влияют не на саму AS, а на оборудование, вне зависимости от того, к какой AS это оборудование приписано. Если же говорить о каких-то надуманных примерах, когда аплинк фильтрует AS1, но не фильтрует AS2, то прежде всего нужно понимать, что любые изменения могут занять более суток.

 

2. Какие проблемы с AS? Если это проблемы с доступностью, то изменение номера AS эту проблему не решит. Если это кривой экспорт, то исправить его будет гораздо быстрее (и правильнее), чем переносить часть сети в другую AS, в которой экспорт настроен правильно. А причем тут DNS — я не уловил.

[Черномазов]

@alibek 

Спасибо за ответ.

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

2. Исправлять неверно настроенное всегда нужно, абсолютно согласен. Но не всегда удаётся сделать это быстро (особенно, если проблема не у тебя), а время идёт, претензии накапливаются, деньги уходят. Попробую точнее описать про DNS. Есть АС1 с адресами 1.1.1.0/24 и АС2 с адресами 2.2.2.0/24. Даём ресурсу адреса 1.1.1.100 и 2.2.2.200. Вносим в DNS 2 записи A с именем resource.domain.tld и этими адресами. Ресурс доступен по 2м адресам, через 2 АС. Когда возникает проблема с АС1, ресурс становится недоступен по адресу 1.1.1.100, но остаётся доступен по адресу 2.2.2.200. Т.к. DNS выдает по запросу к имени то один адрес, то другой, часть клиентов получает работающий адрес 2.2.2.200 и успешно пользуется ресурсом, а другая часть - неработающий 1.1.1.100 и не может им пользоваться. Т.о. ресурс недоступен только частично, а не полностью, как если бы адрес был только один. Потом мы удаляем запись из DNS, указывающую на адрес 1.1.1.100, и ресурс становится доступен всем. А мы в это время решаем проблему, и месяц не становится совсем ужасным сроком.

[dignity]

20 минут назад, Черномазов сказал:

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

2. Исправлять неверно настроенное всегда нужно, абсолютно согласен. Но не всегда удаётся сделать это быстро (особенно, если проблема не у тебя), а время идёт, претензии накапливаются, деньги уходят. Попробую точнее описать про DNS. Есть АС1 с адресами 1.1.1.0/24 и АС2 с адресами 2.2.2.0/24. Даём ресурсу адреса 1.1.1.100 и 2.2.2.200. Вносим в DNS 2 записи A с именем resource.domain.tld и этими адресами. Ресурс доступен по 2м адресам, через 2 АС. Когда возникает проблема с АС1, ресурс становится недоступен по адресу 1.1.1.100, но остаётся доступен по адресу 2.2.2.200. Т.к. DNS выдает по запросу к имени то один адрес, то другой, часть клиентов получает работающий адрес 2.2.2.200 и успешно пользуется ресурсом, а другая часть - неработающий 1.1.1.100 и не может им пользоваться. Т.о. ресурс недоступен только частично, а не полностью, как если бы адрес был только один. Потом мы удаляем запись из DNS, указывающую на адрес 1.1.1.100, и ресурс становится доступен всем. А мы в это время решаем проблему, и месяц не становится совсем ужасным сроком.

При чем здесь AS? Пожалуйста вещайте от одной AS хоть сто сетей.

[Черномазов]

8 минут назад, dignity сказал:

При чем здесь AS? Пожалуйста вещайте от одной AS хоть сто сетей.

Это ограниченный пример, который только показывает, причём тут DNS. То, что на каждой АС может висеть много сетей разного размера, к сути примера отношения не имеет.

[dignity]

4 минуты назад, Черномазов сказал:

Это ограниченный пример, который только показывает, причём тут DNS. То, что на каждой АС может висеть много сетей разного размера, к сути примера отношения не имеет.

В общем, если бы использование нескольких AS для повышения надежности было необходимо, это бы входило в перечень и рекомендации от вендоров и интеграторов. Если найдете такой документ, пожалуйста, будет здорово всем узнать о такой практике, иначе существующий набор динамических протоколов, протоколов резервирования L3 и L2 отлично решает все проблемы... Что же касается DNS - не надо путать теплое и мягкое, DNS это высокоуровневый прикладной протокол.

[gruber]

В 29 января 2018 г. в 11:22, Черномазов сказал:

Есть ли смысл во 2й АС для обеспечения отказоустойчивости?

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

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

 

Кроме того чтобы получить вторую ASn (на ту же организацию) вам придется объяснить RIPE зачем вам это и описать ваши политики маршрутизации которые должны отличаться для разных AS.

 

 

 

[Черномазов]

5 минут назад, gruber сказал:

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

Можете подсказать, почему именно не стоит? Кроме "нет рекомендаций так делать". Что, конечно, аргумент (не дураки в интеграторах и вендорах сидят), но хотелось бы аргументации по фактам, а не авторитетам.

Как защититься от ошибок в конфигурации аплинков или других операторов?

6 минут назад, gruber сказал:

Старайтесь использовать аплинков которые нормально относятся к клиенту.

Город у нас небольшой, из операторов остались почти только федералы, усиленно сокращающие местный персонал. А мы - маленькие клиенты, про нас, в основном, начинают шевелиться только при угрозе расторжения договора. Этак можно без аплинков остаться. :)

8 минут назад, gruber сказал:

Для того чтобы аплинк или вышестоящий тирван начал фильтровать вашу AS, должны быть какие-то причины, наверное их стоит выяснить. 

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

[gruber]

9 минут назад, Черномазов сказал:

Можете подсказать, почему именно не стоит?

Потому что вторая AS не спасет вас от ошибок конфигурации у аплинков, да и вообще ни от чего. Если у вас проблема с AS-1, то почему вы думаете что ее не будет с AS-2, AS-3, итд... Заведите хоть десяток AS-ок, но это не решит проблему. Это ненужная избыточность. Если нет возможности поменять аплинков, звоните, пишите им в ТП или манагерам, пусть решают конкретную техническую проблему.

 

15 минут назад, Черномазов сказал:

Как защититься от ошибок в конфигурации аплинков или других операторов?

Защититься от ошибок человеков нельзя - в принципе, от них не надо защищаться, надо быть готовым к их решению.

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

 

Да, у крупных операторов очень часто бывает сложно пробиться на нужный уровень техподдержки и это нужно учитывать при выборе, но это не невозможно. Всегда можно найти контакты noc или инженеров через whois или у менеджера с которым вы общались. И это желательно сделать сразу, а не тогда когда припрет.

 

Удачи вам.

 

 

[dignity]

1 час назад, Черномазов сказал:

Можете подсказать, почему именно не стоит? Кроме "нет рекомендаций так делать". Что, конечно, аргумент (не дураки в интеграторах и вендорах сидят), но хотелось бы аргументации по фактам, а не авторитетам.

Как защититься от ошибок в конфигурации аплинков или других операторов?

Город у нас небольшой, из операторов остались почти только федералы, усиленно сокращающие местный персонал. А мы - маленькие клиенты, про нас, в основном, начинают шевелиться только при угрозе расторжения договора. Этак можно без аплинков остаться. :)

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

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

[Черномазов]

40 минут назад, gruber сказал:

Если у вас проблема с AS-1, то почему вы думаете что ее не будет с AS-2

Вероятность одновременных проблем ниже в 2 и т.д. раз. Конечно же, 100% гарантии никто не даст.

 

41 минуту назад, gruber сказал:

Защититься от ошибок человеков нельзя - в принципе, от них не надо защищаться

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

 

В остальном, спасибо за развёрнутый ответ.

 

5 минут назад, dignity сказал:

Возможно, где-то режутся сети по префиксам

Префикс-то не менялся. Поменялся только AS path, удлинившись на одно упоминание АС аплинка.

6 минут назад, dignity сказал:

поскольку FV не входит

FV - это кто?

[YuryD]

42 минуты назад, Черномазов сказал:

Префикс-то не менялся. Поменялся только AS path, удлинившись на одно упоминание АС аплинка.

FV - это кто?

 очевидно fullview. А почему as path удлиннилась на префикс аплинка ? prepend-ом обычно свой префикс добавляют, а не чужие. Кто-то опять балуется в бгп, неужели аплинк ?

[straus]

8 часов назад, Черномазов сказал:

1. Если есть возможность, на время сбоя, перевести часть из АС1 во АС2, то это позволит восстановить доступность для этой части до восстановления АС1. Затраты, необходимые для этого перевода, выведем за скобки.

Нельзя выносить за скобки. Устранение ошибку функционирования AS - это десятки минут. Перевод всех ресурсов на другую AS с перестройкой маршрутизации - от нескольких часов до пары месяцев.

 

8 часов назад, Черномазов сказал:

2. Если ресурс имеет адреса как из АС1, так и из АС2, то при проблемах с АС1 он сохранит доступность по адресам из АС2, что снизит влияние сбоя АС1 на этот ресурс.

 

Опять же перестройка маршрутизации. С отвалом всех установленных соединений и прерывания работы сервисов.

 

8 часов назад, Черномазов сказал:

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

Чур тебя! Изменения DNS расползаются по установленному таймауту. Сколько там обычно, сутки?