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

Valaskor

Активный участник
  • Публикации

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

  • Посещение

О Valaskor

  • Звание
    Студент
    Студент

Контакты

  • ICQ
    Array

Информация

  • Пол
    Array

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

2762 просмотра профиля
  1. sess_tcp=2000

    Коллеги, мне это кажется, или в версии 12.4 опять как то стали подзалипать сессии? Никто не обращал внимания?
  2. Не понятно, можно ли верить этой таблице, данные по capacity в ней не совсем соответсвуют даташиту. А вот тут https://isp-tech.ru/switch-asic/huawei-s6730-h-s6330-h/ вообще пишут, что это практически один и тот же коммутатор, все ограничения софтовые.
  3. sess_tcp=2000

    Похоже в 11 версии с натом стало получше.
  4. sess_tcp=2000

    Ух ты, неужели кроме нас еще кто-то жалуется, багу уже много лет, часть тсп-сессий не таймаутится. Моя чистилка: cat /etc/cron.d/nat_clean PATH=/sbin:/bin:/usr/sbin:/usr/bin 1-59/5 * * * * root fdpi_ctrl list all status --service 11 --outformat json | jq -r '.lstatuses[] | select(.status_11.sess_tcp>1990) | .ipv4'| head -n50 | xargs -L1 fdpi_ctrl del --bind_multi --ip Если не используется авторизация, можно просто 11 услугу выключать-включать по идее.
  5. Решил пока оставить minimal-responses yes, жалоб вроде не было.
  6. не понял вашего вопроса, все происходит мгновенно   еще должна помочь биндовая опция minimal-responses yes; размер ответа значительно уменьшается, нет секции authoritative чем грозит ее включение?
  7. У нас часто прилетает такой резолв: www.youtube.com -CNAME> youtube-ui.l.google.com -A> список из 16шт A-записей, разные ипишники. Клиентское устройство (обычно смарт-телек или андроид) в этом случае считает, что ответ великоват и пытается перезапросить у днс-сервера то же самое по TCP-53. Но, если клиентское CPE не умеет TCP-DNS, на этом все и заканчивается, ютуб не работает! Большая часть soho-роутеров как раз не умеет. Кто сталкивался? Как побороть? Фейковые A-записи прокатывают, но это так себе способ, не хочется следить за их актуальностью.
  8. так он включается на L3-интерфейсе, а маршруты удваивает все что есть.
  9. Приоритезация и игры

    А от чего лагают танки то у вас? Мы тестили так - если загнать торренты в пониженный класс, это катит прям вообще заметно - юзер качает на своих 30 мегабитах торрент на полную, при этом пинги и игрушки работают идеально ровно. Если класс не выделять - пинги скачут на сотни мс сразу при загрузке. Но это работает только на таких тарифах, если тариф прямо 100, то оно упрется в сетевой линк клиента 100мбит раньше, и в любом случае будет лагать.
  10. Если будет uRPF (кстати, можно как-то выключить?), 100к префиксов не влезет (при переполнении ведет себя крайне не приятно). Утилизация есть в sh platform hardware ip route summary
  11. по даташиту 4900M - 200к маршрутов но вот влилось в нее около 100к и все навернулось по c4k_l3hwforwarding-4-tcamfull Покопавшись в счетчиках с удивлением обнаружил: entity total used free util% Entries 258048 190825 67223 73 uRPF Ipv4 98304 95196 3108 96 uRPF Ipv6 0 0 0 0 UC Ipv4 98304 95193 3111 96 MC Ipv4 2048 429 1619 20 UC Ipv6 2048 7 2041 0 MC Ipv6 0 0 0 0 SpecDst 0 0 0 0 SpecSrc 0 0 0 0 unused 57344 57344 0 100 Т.е. на каждый маршрут есть так же uRPF-запись. ip verify unicast source reachable-via rx используется на локальных тупиковых интерфейсах, но там нет и десятой доли маршрутов, основная масса прилетает по ospf и на тех интерфейсах никакого RPF нет. Можно как-то перераспределить ресурсы, чтоб можно было хоть чуть больше маршрутов влить?
  12. А... вот как... К слову, использую OSPF, в нем десяток узлов и более 70000 префиксов(ipv4). При подключении клиента с новым префиксом никогда проблем не было(всегда мгновенно отдается по всей сети), а вот перестроение занимает несколько секунд. IBGP тоже есть, но у него перестроение еще медленнее, у него скорее преимущество в гибкости (можно в любом месте роутмапов навешать). Под агрегированием я понимаю выделение отдельных больших префиксов на каждый агрегирующий L3. Соответственно, только эти префиксы отдаем в IGP, клиентские префиксы выделяем внутри, но не анонсим.
  13. ни один протокол не сможет потягаться с агрегированными префиксами по скорости перестроения
  14. Может быть на подъезд и перебор, но ospf тоже не резиновый. Сейчас юзаем роут /32 (ipv4) на клиента, маршруты дистрибьютятся по всем роутерам. Такая схема ограничивает рост, связи медленнее перестраиваются, нужно что то агрегировать и т.п., лучше сразу в дизайне это учесть.