Перейти к содержимому
Калькуляторы

tec1

Пользователи
  • Публикации

    13
  • Зарегистрирован

  • Посещение

О tec1

  • Звание
    Абитуриент
    Абитуриент

Посетители профиля

Блок посетителей профиля отключен и не будет отображаться другим пользователям

  1. Никто не говорит, что дропать трафик - хорошее решение. Но бороться с нежелательным трафиком - необходимость. То, что more specific отправляются через IX неосознанно, не соглашусь в корне. Каков мотив? Могут отдаваться и less, и more specifics одновременно и аплинкам и в обменники. Но и здесь можно наступить на грабли. А чем не нравится решение, подсказанное здесь @evd , не дропать клиентский транзитный трафик, а отправлять его по less specific, более гибко используя классы в отличие от vrf? Механизм отправки во всех случаях один и тот же - PBR/FBF (здесь @evd прав, альтернативы нет, в статье 2009 года, где автор трактовал решение Гинсбурга для Cisco, использовался тоже PBR). Различие только в разделении трафика. И здесь явно выигрывают классы.
  2. Евгений, в очередной раз спасибо за подсказку!
  3. Года два назад еще было актуально). Спасибо за подсказку, Евгений. Попытаемся внедрить у себя ваш передовой опыт)   Мне кажется, механизмы те же, DCU/SCU, FBF. Без последнего явно никак...
  4. Почему жлобство ISP? Не клиента? Ведь ничего же не мешает отдавать свои анонсы ровно, и в IX-ы, и своим аплинкам, и не тянуть трафик тирванов через своих аплинков и обменник. Писалось же выше об этом.
  5. Попробуйте, особенно для клиента, у которого распарсенный as-set включает несколько тысяч route-objects, большая часть из которых еще и агрегированна. И если таких клиентов далеко не один. Устанут ручки, и не только... Другой, не менее значимой, проблемой статиков является возможный blackhole трафика при падении канала без падения линка.
  6. Попытаюсь дополнить здесь содержимое статьи, заодно прокомментировать обсуждение. Скрытой нитью в статье отражается преднамеренность подобных действий со стороны клиента, что подвтерждается и на практике. Наверное, только одна десятая из всех случаев - ошибка администрирования. Какой смысл отдавать более специфичный маршрут на обменник, при этом анонсировать менее специфичный своему аплинку? Почему нельзя аносировать во все линки одинаково? Все же знают, что у всех, кто пристутствует на обменнике, Local Preference для анонсов с IX всегда выше, чем для аплинков, и поэтому трафик от участников обменника клиент будет всегда получать через обменник. Специфики здесь абсолютно не нужны. "Обьяснения о нехорошости " все клиенты безоговорочно принимают и немедленно исправляют ситуацию, что подтверждает осознанность их действий. Фильтровать все клиенсткие анонсы с IX? Конечно нет же. Правильно выразил причину, почему этого не стоит делать, vurd. Во-первых, на каком основании? Только из-за отдельных "мудрых" клиентов? Во-вторых, да, действительно, что произойдет, если клиент снимет анонс с вас (своего аплинка), оставит его только через IX, и вы его отфильтруете? В лучшем случае вы его увидите в FV от своих апстримов и весь ваш трафик на такие префиксы пойдет через линки с апстримами вместо обменника (экономически теряете вы же). В худшем, вы его совсем потеряете в своих таблицах, чем нарушите связность. В целом, подобная практика далеко не нова. Ей, как минимум, лет десять и применяется во многих крупных ISP. Из известных мне, Ростелеком, РЕТН...   Все верно. Self Driving Network & Artificial Intelligence )))
  7. Несколько аспектов не отраженных в статье из-за дефицита времени при ее написании. 1. Нежелательно агрегировать инфраструктурно-значимые префиксы, тем самым создавая предпосылки для BGP hijack с помощью more specific. 2. У многих существует строгое убеждение, что корневая причина зла - отсутствие какой-либо фильтрации клиентских анонсов на аплинках. Истины в подобных утверждениях немного. В основном проблема с корректной фильтрацией составная, и носит системный характер. Как уже отмечалось в статье, прежде всего, это программно-аппаратные вендорские ограничения, не позволяющие реализовать на оборудовании полноценные фильтры для довольно больших клиентских as-sets. Второй, не менее значимой составляющей проблемы, является отсутствие в правовом поле единой базы, консолидирующей все записи региональных IRR, что важно для Операторов присутствующих на рынках разных регионов. Последнему, в качестве возражения, может быть сопоставлен http://radb.net/. Но здесь, как показывает практика, есть тоже довольно серьезные проблемы с безопасностью. Еще в прошлом году обратил внимание, что кто угодно, за небольшие деньги может создать аккаунт мантейнера с дальнейшими правами создания objects. На практике это подтвердилось пару месяцев назад, когда один из наших клиентов, пользующейся сервисом Colocation, именно таким способом смог успешно проанонсировать от себя специфики префиксов China Telecom, которые успешно "ушли в мир", в т.ч. и через наших аплинков.
  8. Есть ли альтернатива BGP Flowspec?

    В примере конфигурации упущен один момент. Созданная policy должна быть применена на export к routing-options forwarding-table, например: set routing-options forwarding-table export dcu-psa
  9. Дополнение к тому, откуда брать информацию о ТОП ASNs для того, чтоб держать перманетно в as-path: https://www.spamhaus.org/statistics/botnet-asn/ Могу уверенно подтвердить достоверность информации, основываясь на опыте последних недель. С AS4134 и AS4837 регулярно прилетает свыше 100 Гбит/с разного рода флуда. Шестое место в ТОПе уверенно занимает: AS12389 ROSTELECOM-AS, RU Number of Bots: 198957 Что неудивительно из-за огромного сегмента ШПД.
  10. Дополнение к тому, откуда брать информацию о ТОП ASNs для того, чтоб держать ASNs перманетно в as-path: https://www.spamhaus.org/statistics/botnet-asn/ Могу уверенно подтвердить достоверность информации, основываясь на опыте последних недель. С AS4134 и AS4837 регулярно прилетает свыше 100 Гбит/с разного рода флуда.
  11. Защита от DDoS - геофильтрация трафика на маршрутизаторах Juniper с применением Source Class Usage (SCU) http://nag.ru/articles/article/32177/zaschita-ot-ddos-geofiltratsiya-trafika-na-marshrutizatorah-juniper-s-primeneniem-source-class-usage-scu-.html
  12. Имхо технически правильно такое реализовывать на региональных узлах. Вот стоит в регионе узел связи - на нем и СОРМ и фильтрация. И всю область или район обрабатывает. Естественно, можно все обрабатывать на региональных узлах, зеркалировать через сплиттеры, или на коммутаторах, ну еще и несколько стоек серверов с портами 10GE, чтоб обработать весь трафик. :)
  13. "extFilter - Программа для блокирования сайтов из списка РКН с использованием DPDK. Программа осуществляет блокировку сайтов путем анализа зеркалированного трафика от пользователей." Как Вы себе представляете "зеркалированного трафика от пользователей" и его доставку в больших операторских сетях? MPLS в сочетании с MP-BGP и BGP Flow-Spec в данной статье рассмотрен исключительно как транспорт для доставки перенаправленного трафика.