Jump to content
Калькуляторы

mutin.sa

Пользователи
  • Content Count

    11
  • Joined

  • Last visited

2 Followers

About mutin.sa

  • Rank
    Абитуриент

Информация

  • Пол
    Мужчина
  • Интересы
    R&D, MPLS, BGP, OSPF, RIP, IPv6, MSTP, FreeBSD, OpenBSD, C, D...

Город

  • Город
    Москва

Recent Profile Visitors

802 profile views
  1. Тоже сталкивался с этим. Причём на разных версиях RouterOS. Вроде как это не баг, похоже этот функционал в MikroTik пока ещё вообще не реализован. https://forum.mikrotik.com/viewtopic.php?f=14&t=113314
  2. Изначально речь шла о IN фильтрах и о ИСХОДЯЩЕМ трафике. Ссылки можно найти по запросу "bgp best path selection algorithm". Как рулить входящим трафиком - тема отдельная и непростая, зависит от многих вводных данных. Балансировать (т.е. равномерно или в определённых пропорциях распределять входящий трафик по каналам) можно как минимум: 1) анонсируя разные префиксы в разных аплинков (если у вас несколько префиксов или минимум /23) 2) препендингом - удлиняя путь при отправке маршрута аплинку 3) банально имея аплинков одного уровня (к примеру AS12389/AS20485/AS9049/AS31133/AS8359/AS3216 - это один уровень, а вот AS12389 и какой нибудь местный региональный оператор или региональная ASка магистрала - это разные уровни) уже будет балансировка
  3. Путаница возникла. Я, изначально, говорил про то, что использовать set-distance для управления ВХОДЯЩИМИ маршрутами и, соответственно, ИСХОДЯЩИМ трафиком не совсем корректно, но потом @Sergey_cha спросил как рулить ВХОДЯЩИМ трафиком и пошла путаница...   Не наблюдал такого. У меня быстро выводит, максимум секунды две на это уходит.
  4. Комьюнити, само по себе, на приоритет маршрута вообще никак не влияет. Комьюнити - это просто маркировка маршрута, своего рода тег, ярлык. У телекомщиков есть даже выражение "красить маршруты" при помощи комьюнити. Как я уже писал, для управления весом маршрутов в BGP есть LocalPref и Weight. Упрощённо - если у вас один бордер и по iBGP маршруты никуда передавать не нужно - то можно управлять весом маршрутов с помощью LocalPref или Weight. Если бордеров несколько и/или есть iBGP - то вариант один - LocalPref. PS: Тут, кстати, путаница возникла. Я, изначально, говорил про то, что использовать set-distance для управления ВХОДЯЩИМИ маршрутами и, соответственно, ИСХОДЯЩИМ трафиком не совсем корректно, но потом @Sergey_cha спросил как рулить ВХОДЯЩИМ трафиком и пошла путаница...
  5. Менять дистанс - странное и не совсем правильное решение. Для управления приоритетом маршрутов в BGP предназначен Local Pref или уж тогда Weight. А препендинг воспринимать как балансировку и того страннее.
  6. bgp-as-path=3 - некорректно, атрибут bgp-as-path в фильтре на выход вам вряд ли нужен. к тому же вы его некорректно используете, там должно быть регексп-выражение типа ^12389_20485$ или _9049_... Вообще, у вас фильтры, похоже, составлены полностью неправильно и не работают вообще.
  7. У меня сейчас в работе микротики с фуллвью от пяти IPv4 апстримов, пяти IPv6 апстримов и маршрутами с двух аиксов и двух приват пиров впридачу. Заливка фуллвью от апстрима - а это ~ 710000 маршрутов для IPv4 и ~ 54000 маршрутов для IPv6 - занимает порядка 40 секунд. Да, в реализации BGP у микротиков сейчас задействуется только одно ядро, но особых проблем от этого я не вижу. На x86 микротиках так и вообще всё отлично. Есть. Поддерживаю. Нам МегаФон фуллвью отдавал по ~ 26 минут. Пинали их долго, но допинали таки... через пол-года. У них стояло ограничение на количество TCP пакетов в секунду. Видимо какая то реализация защиты от DDoS. Когда убрали - фуллвью стал прилетать за ~ 42 секунды.
  8. Схема рабочая, но я бы предложил отказаться от OpenVPN в пользу GRE over IPSec. CARP и OSPF отлично уживаются вместе, дополняя друг друга. Особого смысла вводить дополнительные арии для филиалов в вашем случае не вижу. Если хотите балансировку нагрузки между каналами, то проще всего, наверное, заменить OSPF на BGP и реализовать схему, при которой, пока живы оба канала, трафик в офис идёт по первому, а из офиса - по второму. Это хороший вариант, при условии, что каналы везде у вас приблизительно одинаковой ширины т.к. в этом случае вы получите фактически удвоение ширины канала + резервирование (при падении одного из каналов весь трафик пойдёт по оставшемуся). Ещё могу порекомендовать отказаться от pfSense в пользу MikroTik RouterOS. Сам долго и активно пользовался pfSense, но в нашей сети его недостатки оказались существенными и пришлось искать замену, которой стала MikroTik RouterOS. Довольны полностью. У pfSense есть несколько серьёзных недостатков: - запустить на нём OSPF + BGP одновременно не получится, либо одно, либо другое; - периодически (редко) намертво подвисает OSPF; - до сих пор не устранён баг, приводящий к переполнению места на системном разделе после установки некоторых пакетов - критично, при сохранении любых изменений в Web-интерфейсе при переполненном корневом разделе слетает конфигурация начисто; - настройка IPSec-а на pfSense не самое приятное занятие; - реализация интерфейса для настройки DHCP сервера оставляет желать лучшего - конкретно добавление резервирования IP адреса... Но у pfSense есть и существенные плюсы перед MikroTik RouterOS: - замечательный файрвол, который предельно прост, логичен и настроен из коробки; - XMLRPC Sync; - бесплатность; - возможность расширения функционала сверх стандартных функций для шлюза - к примеру из него можно сделать ещё и антиспам SMTP прокси; - рабочий Proxy ARP для PPTP/L2TP (сомнительный плюс). Ещё у Вас и в офисе и в филиалах есть дополнительная точка отказа - коммутаторы. По хорошему их тоже стоит резервировать, как минимум в офисе.
  9. Слишком мало информации. Хотелось бы увидеть конфигурации обоих микротиков (интерфейсы, адресация, маршруты, файрвол, параметры BGP - инстансы/пиры/сети, фильтры), узнать версию RouterOS и то, на какой платформе она работает.
  10. Слишком мало информации. Хотелось бы увидеть конфигурации обоих микротиков (интерфейсы, адресация IPv6, маршруты IPv6, файрвол IPv6), узнать версию RouterOS и то, на какой платформе она работает.