RN3DCX Posted March 10 Есть ли какая-то best-практика противодействия пролива трафика вышестоящим оператором через нижестоящего? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sol Posted March 10 1 час назад, RN3DCX сказал: Есть ли какая-то best-практика противодействия пролива трафика вышестоящим оператором через нижестоящего? Есть конечно. Все так делают. Все строят фильтры по ripe. Есть даже ряд замечательных xNIX утилит для этого, bgpq3 и bgpq4 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
[anp/hsw] Posted March 11 Best - взымать плату за трафик. А good - просто не анонсировать то, что генерирует много трафика. Или речь идет о том, что анонсов нет, а трафик к вам все равно льется? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vurd Posted March 11 Шатдаун на интерфейсе решает проблему максимально эффективно. Поясните суть вопроса, что за пролив, откуда куда. Вышестоящий всегда заливает в нижестоящего, закон телеком-джунглей. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
TheUser Posted March 11 12 часов назад, RN3DCX сказал: Есть ли какая-то best-практика противодействия пролива трафика вышестоящим оператором через нижестоящего? Правильно настроенные анонсы на стороне "нижестоящего". Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
RN3DCX Posted March 11 6 часов назад, vurd сказал: Поясните суть вопроса, что за пролив, откуда куда. Речь о том, когда вышестоящий направляет свой трафик через апстримы нижестоящего. Что бы такого не было localpref 200 решает данную ситуацию со стороны вышестоящего, но как оказалось или по невнимательности, либо намеренно - не все вышестоящие применяют localpref 200. Отсюда и возник вопрос в первом посте. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
TheUser Posted March 11 3 минуты назад, RN3DCX сказал: Речь о том, когда вышестоящий направляет свой трафик через апстримы нижестоящего. Что бы такого не было localpref 200 решает данную ситуацию со стороны вышестоящего, но как оказалось или по невнимательности, либо намеренно - не все вышестоящие применяют localpref 200. Отсюда и возник вопрос в первом посте. Ну как бы local preference - метрика относительная, у кого-то максимальное значение 100 (на клиентов), у кого-то 850. Давайте уже конкретику, чего ныкаться, все свои же) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
RN3DCX Posted March 11 14 минут назад, TheUser сказал: Ну как бы local preference - метрика относительная, у кого-то максимальное значение 100 (на клиентов), у кого-то 850 Самое главное цифры больше 20, что является приоритетом для выбора куда пульнуть трафик. 14 минут назад, TheUser сказал: Давайте уже конкретику Вы меня спрашиваете?)) Я вот как бы сам хотел узнать подробности по первому посту. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Умник Posted March 11 1 час назад, RN3DCX сказал: Речь о том, когда вышестоящий направляет свой трафик через апстримы нижестоящего. Если я правильно вас понял, вопрос не технический. Если это недосмотр, то решать проблему нужно административными способами, через NOC. Если же у вашего аплинка просто такая политика назначения localprefs, что ваш localpref у него оказывается ниже, чем localpref ваших апстримов (ваш аплинк подключен к тем же апстримам, что и вы сами, так ведь?), то даже не знаю, что можно сделать. Вы можете порезать свои анонсы на more-specifics и анонсировать их таким операторам, но это не очень хорошее решение, ИМХО. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
UglyAdmin Posted March 11 как вариант - ACL на вход решает проблему, если он не слишком большой (вы не транзитный оператор). Трафик не должен ходить с одного аплинка на другой... Анонсируйте своим аплинкам только свои сети и те, что получаете от клиентов... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
RN3DCX Posted March 11 1 час назад, UglyAdmin сказал: как вариант - ACL на вход решает проблему при получении Fullview? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sirmax Posted March 11 3 часа назад, RN3DCX сказал: при получении Fullview? Ээээ может я не знаю bgp но фильтры на анонсы же работают и на передачу тоже? никто вас не может заставить рассказать аплинку что у вас есть еще второй аплинк если я уловил суть проблемы, конечно Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nixx Posted March 11 тут, по-моему (ну если из ТСа таки корректно вытянули ситуацию), сразу обе стороны лажают - и аплинк нифига не фильтрует принимаемые от даунлинка роуты, и даунлинк экспортит спасибо, что не фулл-вью ) (а вдруг?) а локалпреф вообще где-то сбоку, я могу и 3 поставить, и 300, как моей пятке захочется, на то он и Local. к слову, мне тут внутренние сети IX'ов анонсирует один аплинк, хотя у них в правилах явно сказано "низзя"... уже несколько раз пинал - а пофигу. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
UglyAdmin Posted March 12 On 3/11/2025 at 6:15 PM, RN3DCX said: при получении Fullview? А в чём проблема? Вы же от аплинка ФВ принимаете, а не от клиента. Указываете в ACL свои сети и сети клиентов как разрешенные, остальной трафик дропаете. Но да, убедитесь что аплинку вы анонсируете только свои сети и сети клиентов... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Умник Posted March 12 @RN3DCX , вы все-таки опишите подробней ваш сценарий. Какие AS в схеме, как они соединены друг с другом, какие префиксы анонсируют, как трафик должен ходить в этой схеме и как не должен. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Gray swordsman Posted March 12 Поддерживаю UglyAdmin, вопрос решается установкой ACL по входу. Был приблизительно такой же случай. При потере свзянности с одним из клиентов трафик с его оборудования продолжал форвардиться в наш ip адрес, но уже через внешние каналы. Соответственно прилетал трафик с сорсе-префиксами которые мы не аноннсировали. Могу ошибасть в деталях , дело было давно, но точно лечилось установкой ACL. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Умник Posted March 12 28 минут назад, Gray swordsman сказал: При потере свзянности с одним из клиентов трафик с его оборудования продолжал форвардиться в наш ip адрес, но уже через внешние каналы. Интересно, как это могло получится? Клиент был подключен еще к кому-то BGP и при потери прямого линка вы начали анонсировать в мир своим аплинкам его префиксы, которые сами получили в full view и выбрали как best? Тогда зачем ломать людям связанность при помощи ACL? Здесь нужны BGP-фильтры на out-анонсы, которые явно или неявно учитывают AS_PATH, чтобы не становится транзитным оператором. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Gray swordsman Posted March 12 нее...от нас аннонсов не было "левых" . у него в таблице маршрутов в качестве шлюз оставался наш ip-шник. Его железка резолвила где он находится и форвардила на него пакеты. как-то так было. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
