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