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

mutin.sa

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

    11
  • Joined

  • Last visited

2 Followers

About mutin.sa

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

Контакты

  • Сайт
    https://www.linkedin.com/in/mutin-sa

Информация

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

Город

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

Recent Profile Visitors

1150 profile views
  1. Всем доброго, коллеги! Куплю два комплекта салазок для крепления в стойку коммутаторов Juniper QFX5100. Срочно!
  2. Подтверждаю. Номера карт 5599005050096648 (5599 0050 5009 6648), 4890494691255277 (4890 4946 9125 5277) и номер телефона +79006041743 (+7-900-604-17-43 / +7 900 604 17 43) принадлежат мошенникам. Сами карты выпущены Яндексом и Qiwi. Мы влетели на 5'000 рублей при "покупке" ушей к коммутаторам, а знакомый влетел на 63'000 рублей на "покупке" ушей, сетевых тестеров Fluke и чего то там ещё... Помимо форума нага промышляют ещё и в Телеграме, где выискивают жертв в профильных телеком группах. В нашем случае представлялся в Телеграме как "Славик". Номер телефона к аккаунту не привязан либо скрыт, юзернейм не задан. PS: Номера карт и номер телефона я специально написал в разных форматах т.к. перед переводом денег пробивал номер и карты, но из-за несоответствия формата не нашёл эту тему. На эту тему я наткнулся уже после оплаты, постфактум, когда возникли подозрения и я начал пробивать данные более тщательно, в разных поисковиках и разных форматах записи номеров.
  3. Тоже сталкивался с этим. Причём на разных версиях RouterOS. Вроде как это не баг, похоже этот функционал в MikroTik пока ещё вообще не реализован. https://forum.mikrotik.com/viewtopic.php?f=14&t=113314
  4. Изначально речь шла о IN фильтрах и о ИСХОДЯЩЕМ трафике. Ссылки можно найти по запросу "bgp best path selection algorithm". Как рулить входящим трафиком - тема отдельная и непростая, зависит от многих вводных данных. Балансировать (т.е. равномерно или в определённых пропорциях распределять входящий трафик по каналам) можно как минимум: 1) анонсируя разные префиксы в разных аплинков (если у вас несколько префиксов или минимум /23) 2) препендингом - удлиняя путь при отправке маршрута аплинку 3) банально имея аплинков одного уровня (к примеру AS12389/AS20485/AS9049/AS31133/AS8359/AS3216 - это один уровень, а вот AS12389 и какой нибудь местный региональный оператор или региональная ASка магистрала - это разные уровни) уже будет балансировка
  5. Путаница возникла. Я, изначально, говорил про то, что использовать set-distance для управления ВХОДЯЩИМИ маршрутами и, соответственно, ИСХОДЯЩИМ трафиком не совсем корректно, но потом @Sergey_cha спросил как рулить ВХОДЯЩИМ трафиком и пошла путаница...   Не наблюдал такого. У меня быстро выводит, максимум секунды две на это уходит.
  6. Комьюнити, само по себе, на приоритет маршрута вообще никак не влияет. Комьюнити - это просто маркировка маршрута, своего рода тег, ярлык. У телекомщиков есть даже выражение "красить маршруты" при помощи комьюнити. Как я уже писал, для управления весом маршрутов в BGP есть LocalPref и Weight. Упрощённо - если у вас один бордер и по iBGP маршруты никуда передавать не нужно - то можно управлять весом маршрутов с помощью LocalPref или Weight. Если бордеров несколько и/или есть iBGP - то вариант один - LocalPref. PS: Тут, кстати, путаница возникла. Я, изначально, говорил про то, что использовать set-distance для управления ВХОДЯЩИМИ маршрутами и, соответственно, ИСХОДЯЩИМ трафиком не совсем корректно, но потом @Sergey_cha спросил как рулить ВХОДЯЩИМ трафиком и пошла путаница...
  7. Менять дистанс - странное и не совсем правильное решение. Для управления приоритетом маршрутов в BGP предназначен Local Pref или уж тогда Weight. А препендинг воспринимать как балансировку и того страннее.
  8. bgp-as-path=3 - некорректно, атрибут bgp-as-path в фильтре на выход вам вряд ли нужен. к тому же вы его некорректно используете, там должно быть регексп-выражение типа ^12389_20485$ или _9049_... Вообще, у вас фильтры, похоже, составлены полностью неправильно и не работают вообще.
  9. У меня сейчас в работе микротики с фуллвью от пяти IPv4 апстримов, пяти IPv6 апстримов и маршрутами с двух аиксов и двух приват пиров впридачу. Заливка фуллвью от апстрима - а это ~ 710000 маршрутов для IPv4 и ~ 54000 маршрутов для IPv6 - занимает порядка 40 секунд. Да, в реализации BGP у микротиков сейчас задействуется только одно ядро, но особых проблем от этого я не вижу. На x86 микротиках так и вообще всё отлично. Есть. Поддерживаю. Нам МегаФон фуллвью отдавал по ~ 26 минут. Пинали их долго, но допинали таки... через пол-года. У них стояло ограничение на количество TCP пакетов в секунду. Видимо какая то реализация защиты от DDoS. Когда убрали - фуллвью стал прилетать за ~ 42 секунды.
  10. Схема рабочая, но я бы предложил отказаться от 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 (сомнительный плюс). Ещё у Вас и в офисе и в филиалах есть дополнительная точка отказа - коммутаторы. По хорошему их тоже стоит резервировать, как минимум в офисе.
  11. Слишком мало информации. Хотелось бы увидеть конфигурации обоих микротиков (интерфейсы, адресация, маршруты, файрвол, параметры BGP - инстансы/пиры/сети, фильтры), узнать версию RouterOS и то, на какой платформе она работает.
  12. Слишком мало информации. Хотелось бы увидеть конфигурации обоих микротиков (интерфейсы, адресация IPv6, маршруты IPv6, файрвол IPv6), узнать версию RouterOS и то, на какой платформе она работает.