Комментарии 12
Мало того, что пост специфичный сугубо для провайдеров и прочих, подключённых к инету напрямую, так вы хоть объясните почему так случилось. Краткий пересказ: у нас все сломалось. Виноваты вот эти. Сломалось у всех, мы тут не причём. Они чёт пофиксили. Мы тоже чёт пофиксили. Всем бобра.
+2
Так автор объяснил почему. Вот поэтому — «Quagga создавала анонс сразу с несколькими аномалиями: в маршруте оказывалась как неправильная длина атрибута AS_PATH, равно как и само значение атрибута AS_PATH оказывалось некорректным.» Суховато, конечно. Без экспрессии и буйства эмоций. Это ж не роман, а техническая статья.
+10
А нам вешали лапшу про ураган в Костарике и по этой причине датацентр плохо доступен. :)
+1
Примерно две недели назад команда Qrator Radar столкнулась с интересным сетевым инцидентом
В действительности, с инцидентом столкнулось большинство инженеров, использующих Quagga на бордерах. Какая заслуга именно Qrator в обнаружении и устранении проблемы — не понятно. «Наша команда...», «мы обнаружили...», «мы задали...», «мы убедились..», «мы рекомендуем...».
0
> Какая заслуга именно Qrator в обнаружении и устранении проблемы
> Команда Qrator Radar предоставила дополнительный патч для Quagga, исправляющий формирование некорректного значения атрибута AS_PATH, и вчера он был принят, но пока еще не относится к текущему релизу.
> Команда Qrator Radar предоставила дополнительный патч для Quagga, исправляющий формирование некорректного значения атрибута AS_PATH, и вчера он был принят, но пока еще не относится к текущему релизу.
+3
Наверное, предложенный патч более правильный, чем тот, что спас нас (и не только) — lists.quagga.net/pipermail/quagga-dev/2017-September/033284.html
Спасибо!
Спасибо!
+2
Судя по git-у quagga, патч таки прислал таки Eugene Bogomazov из qrator.
+3
И всё же. Каков механизм распространения? От Коста-Рики достаточно далеко, если я правильно понимаю то в AS_PATH для AS_SEQ не может быть больше 255 ASn. Даже если Quagga и сформировала неверный UPDDATE, то первый же сосед должен был положить сессию в направлении источника, то что это долетело до России как-то странно. Тоже пострадали, но на Ericsson. Или на всём пути у всех Quagga и её клоны?
P.S. Проблеме сверх длинных AS_PATH ой как много лет уже. Вот навскидку ссылка.
0
Проблема сверх длинных AS_PATH — ей и вправду много лет, и это именно проблема реализаций, а него самого протокола. Да, в одном сегменте не может быть больше 255 номеров, однако никто не запрещает иметь несколько сегментов (тоже обычное появление {}, т.е. одновременно AS_SEQ и AS_SET приводит к разбиению пути на два сегмента).
Проблема в Quagga была в том, что при наличие несклольких сегментов AS_SEQ, неправильно считалась сумма длины всего атрибута — результат NOTIFICATION, а по факту постоянные флапы. Так же Quagga дописывала номера АС не в последний сегмент, а во все сегменты сразу, в итоге получался веселый путь: AS3 AS2 AS3 AS2 253xAS1 AS3 AS2 253xAS1.
Проблема в Quagga была в том, что при наличие несклольких сегментов AS_SEQ, неправильно считалась сумма длины всего атрибута — результат NOTIFICATION, а по факту постоянные флапы. Так же Quagga дописывала номера АС не в последний сегмент, а во все сегменты сразу, в итоге получался веселый путь: AS3 AS2 AS3 AS2 253xAS1 AS3 AS2 253xAS1.
+2
Я может чего-то не понимаю, но разве 256 AS не сделают как минимум столько же узлов в tcp/ip трассировке, на которую всё не хватит никакого TTL?
0
Нет, длина AS_PATH не имеет привязки к числу хопов. Более того, стандартный способ деприоритизации направления между операторами связи — это как раз добавление несколько раз номера своей АС в AS_PATH (prepend policy), кол-во хопов внутри сети, очевидно, при этом не меняется.
Как написано в статье, обычно делать препенд больше 5 не имеет смысла, но при этом делать его больше никто не запрещает.
Как написано в статье, обычно делать препенд больше 5 не имеет смысла, но при этом делать его больше никто не запрещает.
+2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Глобальные последствия одной ошибки в Quagga