[RN3DCX]

Есть ли какая-то best-практика противодействия пролива трафика вышестоящим оператором через нижестоящего?

 

[sol]

1 час назад, RN3DCX сказал:

Есть ли какая-то best-практика противодействия пролива трафика вышестоящим оператором через нижестоящего?

 

Есть конечно. Все так делают. Все строят фильтры по ripe. Есть даже ряд замечательных xNIX утилит для этого, bgpq3 и bgpq4

 

[[anp/hsw]]

Best - взымать плату за трафик.

А good - просто не анонсировать то, что генерирует много трафика.

Или речь идет о том, что анонсов нет, а трафик к вам все равно льется?

[vurd]

Шатдаун на интерфейсе решает проблему максимально эффективно.

Поясните суть вопроса, что за пролив, откуда куда. Вышестоящий всегда заливает в нижестоящего, закон телеком-джунглей.

[TheUser]

12 часов назад, RN3DCX сказал:

Есть ли какая-то best-практика противодействия пролива трафика вышестоящим оператором через нижестоящего?

Правильно настроенные анонсы на стороне "нижестоящего".

[RN3DCX]

6 часов назад, vurd сказал:

Поясните суть вопроса, что за пролив, откуда куда.

Речь о том, когда вышестоящий направляет свой трафик через апстримы нижестоящего.

Что бы такого не было localpref 200 решает данную ситуацию со стороны вышестоящего, но как оказалось или по невнимательности, либо намеренно - не все вышестоящие применяют localpref 200. Отсюда и возник вопрос в первом посте.

[TheUser]

3 минуты назад, RN3DCX сказал:

Речь о том, когда вышестоящий направляет свой трафик через апстримы нижестоящего.

Что бы такого не было localpref 200 решает данную ситуацию со стороны вышестоящего, но как оказалось или по невнимательности, либо намеренно - не все вышестоящие применяют localpref 200. Отсюда и возник вопрос в первом посте.

Ну как бы local preference - метрика относительная, у кого-то максимальное значение 100 (на клиентов), у кого-то 850.

Давайте уже конкретику, чего ныкаться, все свои же)

[RN3DCX]

14 минут назад, TheUser сказал:

Ну как бы local preference - метрика относительная, у кого-то максимальное значение 100 (на клиентов), у кого-то 850

Самое главное цифры больше 20, что является приоритетом для выбора куда пульнуть трафик.

 

14 минут назад, TheUser сказал:

Давайте уже конкретику

Вы меня спрашиваете?))

Я вот как бы сам хотел узнать подробности по первому посту.

[Умник]

1 час назад, RN3DCX сказал:

Речь о том, когда вышестоящий направляет свой трафик через апстримы нижестоящего.

 

Если я правильно вас понял, вопрос не технический. Если это недосмотр, то решать проблему нужно административными способами, через NOC. Если же у вашего аплинка просто такая политика назначения localprefs, что ваш localpref у него оказывается ниже, чем localpref ваших апстримов (ваш аплинк подключен к тем же апстримам, что и вы сами, так ведь?), то даже не знаю, что можно сделать. Вы можете порезать свои анонсы на more-specifics и анонсировать их таким операторам, но это не очень хорошее решение, ИМХО.

[UglyAdmin]

как вариант - ACL на вход решает проблему, если он не слишком большой (вы не транзитный оператор).

 

Трафик не должен ходить с одного аплинка на другой...

Анонсируйте своим аплинкам только свои сети и те, что получаете от клиентов...

 

[RN3DCX]

1 час назад, UglyAdmin сказал:

как вариант - ACL на вход решает проблему

при получении Fullview?

[sirmax]

3 часа назад, RN3DCX сказал:

при получении Fullview?

Ээээ может я не знаю bgp но фильтры на анонсы же работают и на передачу тоже?

никто вас не может заставить рассказать аплинку что у вас есть еще второй аплинк

 

если я уловил суть проблемы, конечно 

[nixx]

тут, по-моему (ну если из ТСа таки корректно вытянули ситуацию), сразу обе стороны лажают - и аплинк нифига не фильтрует принимаемые от даунлинка роуты, и даунлинк экспортит спасибо, что не фулл-вью ) (а вдруг?)

а локалпреф вообще где-то сбоку, я могу и 3 поставить, и 300, как моей пятке захочется, на то он и Local.

 

к слову, мне тут внутренние сети IX'ов анонсирует один аплинк, хотя у них в правилах явно сказано "низзя"... уже несколько раз пинал - а пофигу.

[UglyAdmin]

On 3/11/2025 at 6:15 PM, RN3DCX said:

при получении Fullview?

А в чём проблема? Вы же от аплинка ФВ принимаете, а не от клиента.

Указываете в ACL свои сети и сети клиентов как разрешенные, остальной трафик дропаете.

 

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

[Умник]

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

[Gray swordsman]

Поддерживаю UglyAdmin, вопрос решается установкой ACL по входу. Был приблизительно такой же случай. При потере свзянности с одним из клиентов трафик с его оборудования продолжал форвардиться в наш ip адрес, но уже через внешние каналы. Соответственно прилетал трафик с сорсе-префиксами которые мы не аноннсировали. Могу ошибасть в деталях , дело было давно, но точно лечилось установкой ACL.

[Умник]

28 минут назад, Gray swordsman сказал:

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

Интересно, как это могло получится? Клиент был подключен еще к кому-то BGP и при потери прямого линка вы начали анонсировать в мир своим аплинкам его префиксы, которые сами получили в full view и выбрали как best? Тогда зачем ломать людям связанность при помощи ACL? Здесь нужны BGP-фильтры на out-анонсы, которые явно или неявно учитывают AS_PATH, чтобы не становится транзитным оператором.

[Gray swordsman]

нее...от нас аннонсов не было "левых" . у него в таблице маршрутов в качестве шлюз оставался наш ip-шник. Его железка резолвила где он находится и форвардила на него пакеты. как-то так было.