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

Negator

VIP
  • Публикации

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

  • Посещение

Все публикации пользователя Negator


  1. А что там за OSPF, которое долго просирается?
  2. *) vrrp - добавлена совместимость "sync-connection-tracking" с preemption-mode;
  3. Пинги от абонентов до сайтов большими пакетами проходят?
  4. Вот честно - у Вас в голове почему то крутится только одна схема. C L3 и OSPF. И схема то в целом неплохая и вполне может использоваться. Только жизнь она штука многогранная. У каждого оператора могут быть свои схемы, задачи, ресурсы, железки, варианты автоматизации и управления, варианты резервирования, да и много всего другого, админы наконец. Но по каким то причинам вы все остальное кроме вашей любимой схемы сходу объявляете "устаревшей технологией" и все. VRRP - протокол, предназначенный для увеличения доступности маршрутизаторов выполняющих роль шлюза по умолчанию. Он для резервирования роутеров предназначен, а не для резервирования каналов. И хоть сколько угодно используй динамическую маршрутизацию - от поломки или отключения питания роутера она не поможет. а VRRP - вполне. Он для этого и создан.
  5. Неправильно, просто вбить 2 статики не получится, как уже выше написали можно использовать check gateway ping Вообще если у вас 2 одинаковые железки то лучше использовать VRRP для этих целей.
  6. На статике все взлетит. Другое дело нужен ли вам OSPF для удобства или резервирования или еще для чего. Тут уж вам решать. Требований делать именно на OSPF нету. Проверьте MTU на канале. При необходимости попросите у провайдера что берете аренду повышенный MTU. И естественно нужно будет это учитывать при организации туннелей. Скорее всего корни проблемы со скоростью растут оттуда. Я на практике особой разницы между EOIP и VPLS не вижу. Вроде как второй чуть быстрее, но поймать это "чуть" сложно. Обычно если железка не вывозит EOIP - не вывезет и VPLS. Скорости то какие? По моему опыту -4011 - вывозит около гигабита 3011- мегабит 600-800 Всякие HEX POE - порядка 300 на свичах CSS даже пробовать не стоит.
  7. нет, можно обойтись статическим роутингом. Сам VPLS лучше вешать на лупбеки все же
  8. Во первых я не знаю где сидит автор. Во вторых вопрос цен и переплат не поднимался вообще. По сабжу - надо брать на тест, рисовать графики и смотреть что получается. И да - обычно можно и нужно в таких случая пробовать брать и default и FullView
  9. Нет. Так просто не получится. Еще раз в BGP - вы управляете исходящим трафиком. Влиять на входящий вы не можете напрямую. Можно поставить препендов, можно поковыряться, но какого то равномерного распределения вы не получите. В какой канал польется входящий заранее неизвестно. И совершенно не обязательно в тот, с которого запросили. Резервирование будет работать без проблем. На практике скорее всего из 2 каналов по 2 гига - вы получите в один из каналов полтора гига, во второй=0.5. Но точное распределение никто не скажет. И конечно оно может меняться по независящим от вас причинам. Почитайте теорию. Вообще Fullvew и 2 канала - маловато. Если взять 5-6 каналов от разных источников +IX -ы - то можно что то попробовать более менее раскидать. А если каналов всего 2 - берите просто default. Работать будет один, второй в горячем резерве.
  10. В BGP вы не можете управлять входящим трафиком. Только косвенными методами. А вообще в религию Saab-a я не полезу.
  11. Ага, в теории все красиво. А на практике появляются нюансы.
  12. А кто мешает на время профилактики выдать любой внешний DNS? Хоть 8.8.8.8?
  13. а зачем там вообще вебом пользоваться? неудобно же. Так то могу попробовать помочь по C-data
  14. Используем Eltex 3124F, 3324F в целом аналоги длинков 3420. Все работает, даже L3 ospf Раз в год некоторые улетают в CPU 100%, но продолжают при этом работать без проблем даже месяцами.
  15. С торрентами боролись по другой причине. Когда то они создавали кучу мелких соединений и активно утилизировали каналы как по PPS, так и по полосе. В те года оборудование было куда слабее и провайдерские железки могли полечь от траффика. Рассчитано было на пару мегабит средней утилизации канала - а там больше, причем мелкими пакетами. Где то в договорах до сих пор сноска есть, что если будут много качать- могут заблокировать. А что касается СОРМ -а - операторы сами себе злобные буратины. Пораздавали тарифов по 500 мбит за 500 рублей клиентам с целью демпинга, а теперь когда это дорого поддерживать стало начнут жаловаться.
  16. VRRP можно сделать если роутеры только NAT делают. Даже с синхронизацией NAT трансляций
  17. Да, может. Потому что мультикаст уже прилетел на железку и льется в проц. Мы блокируем ipv6 полностью по Ethertype 0x86dd на конечных железках. + traffic control Обычно проблем нет.
  18. Конечно. Как бы вы не блокировали или ограничивали мультикаст (там же traffic control например) - на порт свича он уже прилетел от клиента. И сделать с этим ничего нельзя. А вот на вышестоящих уже не будет его если корректно заблокировали. И да - есть вероятность что железке от такого может поплохеть.
  19. Значит ищите проблемы за портами свича.
  20. А что есть авторизация по маку? Это просто выдача адреса в DHCP? Микротиком или сторонним сервером? Или прям что то другое с RADIUS -ом и всем прочим? Ну а в целом - все правильно - проблем быть не должно.
  21. У нас Микротик обычно это L3 аггрегатор. Роутер для клиентов. Ну и всякий MPLS. Шейпим на отдельном сервере. DHCP -тоже на отдельном центральном. VLAN на клиента мы не делаем в PON обычно. Достаточно влана на PON порт. И вот уже вланов вместо 3к получается пару десятков. У нас пока нет тысяч абонентов на PON, есть только узлы с несколькими сотнями. Все работает нормально. Еще есть отдельные микротики для целей NAT и только. Вообще соглашусь, что использовать Микротик как чистый L2 BRAS с шейпингом, очередями и прочей авторизацией не есть правильно