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

Valaskor

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

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

  • Посещение

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


  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) на клиента, маршруты дистрибьютятся по всем роутерам. Такая схема ограничивает рост, связи медленнее перестраиваются, нужно что то агрегировать и т.п., лучше сразу в дизайне это учесть.
  15. Кто разобрался, где же этот "уникальный код (идентификатор) в выгрузке"?
  16. Сделайте над собой усилие, и перестаньте думать, что /64, /48 или /32 это «слишком много». Дизайн ipv6 рассчитан не для сохранения свободных адресов для всех провайдеров на миллион лет вперед, а перспективу геометрического роста клиентских ip-адресов и уменьшение количества маршрутов путем агрегации (при этом ДОЛЖНА осуществляется ОГРОМНАЯ бесполезная трата v6-ипишников на запасы во всех местах). Немного тезисов из рекомендаций райпа (https://www.ripe.net/publications/docs/ripe-690): Рекомендуется использовать для конечных пользователей: /48 (для абсолютно всех может казаться излишне, но все равно делайте, райп даст адреса, всем хватит) /56 (рекомендуется ВСЕМ, кроме бизнес сегмента(любого), для них мало!) /60 только при аппаратных ограничениях (не рекомендуется!) /64 для конечного клиента – райп осуждает и крайне не рекомендует так делать! Т.е. предполагается, что клиентский роутер поделит /56 на кучу сетей /64, отдельно вайфай, отдельно провод, гостевая и т.д. При делении подсетей, настоятельно рекомендуется идти кратно 4 битам, чтоб не путаться с hex-нотацией адреса. Префикс клиента должен быть статическим, иначе при его смене клиенты внутри сети абонента могут об этом не узнать и ipv6 не будет работать. При переезде клиента рекомендуется менять префикс, чтоб не ломалась географическая агрегация и не нужно было строить отдельный маршрут. Между роутером абонента и провайдером рекомендуется отдельная /64 (нормально работают трассы и и.п.), но не обязательно. (например, мы сейчас вообще там юзаем автоматические link-local, пакеты нормально ходят в сетку юзера и обратно). Пока думаю делить как-то так: Префикс лировский /32 (меньше они не выделяли, при этом он еще до /29 расширяется – место автоматически зарезервировано райпом). Из него юзаем /36, остальное запас (т.е. используем 1/16). Получается до 16 (сейчас 6) узлов агрегации по /40. А на узлах агрегации до 65к клиентов по /56. (фактический онлайн сейчас в несколько раз меньше).
  17. Всё роутеры умеют. Если есть поддержка ipv6, практически всегда поддерживается и dhcp6-prefix-delegation. Роутер получает префикс, внутри раздает через чаще по slaac, инногда dhcp6. Сейчас пробуем протестить на небольшой выборке. По роутерам: ASUS - нужно включить в настройках ipv6, ничего хитрого прописывать не нужно. OpenWrt свежие - взлетает сразу OpenWrt старые - некоторые траблы, нужны доп. настройки и т.п. Zyxel - вроде тоже сразу Естественно, имеются ввиду модели, где поддержка ipv6 заявлена. В общем ситуация сейчас значительно лучше, чем года три назад. Если просто включить DHCPv6 в абонентском влане, куча клиентов просят адреса.
  18. перепробовали пробовали штуки три разных фирм, и в других местах ни с одним из них проблем не было.
  19. Итого: c Cisco 4900M - связь есть несколько десятков секунд, потом немного потерь несколько секунд после чего пропадает полностью с Dlink DGS-3420-24TS - каждые секунд тридцать пропадает на несколько секунд. Линк не гаснет. с Мыльницей Tp-Link (гигабитной) в транзит на 4900M - все стабильно. c Dlink DES-3028 - тоже все стабильно Обе циски ведут себя аналогично. На другой площадке нормально работало с Dlink DGS-3120-24SC.
  20. На соседнем здании есть вышка сотовой связи. Но техничеки это подвал/бомбоубежище старого завода. Мобилки не ловили. Правда внутри есть GSM-репитер, отключить его попробую конечно, но надежда слабая.
  21. нет конечно, при чем тут это? учитывая, в одну сторону пакеты ходят всегда
  22. В общем есть у нас такая древняя циска для телефонки - C1700. Много лет отработала на одной нашей площадке, но нам ее понадобилось перевезти на другое место. Привозим - нет связи по ethernet. Если делать clear interface fastethernet 0/0 - связь появляется на несколько десятков секунд, но потом начинает прерываться и пропадает совсем. Слушал дампом, сравнивал счетчики - пакеты от нее нормально проходят, а к ней - нет. Счетчик на другой стороне растет, а на циске в packets input - ничего не появляется. Пробуем проверить разные варианты: -Патчкорды (медь 3м) - меняли разные. -Точки включения пробовали Cisco 4900M (медная карта), Dlink-DGS медные порты - одинаковое поведение. -Пробовал опускать линк в 10мбит и/или half-duplex - нет эффекта -Проверяли помехи по питанию - запитывали от ИБП на батарее. -Разные подсети, вланы, ипишники - по нулям. Короче решили, что порт/чип как то странно там погорел. Привозим на офис - работает в идеале! Вернули на старую площадку и там все летает! Короче недоумение полное - новой площадке тоже много лет, работают наверное сотни единиц техники, никогда с таким не сталкивались. Ок, решили купить у нага такую же циску на замену и... да, она тоже там не работает =) Короче мне уже кажется, что циска не хочет работать в шумном помещении. Остался вариант только попробовать взять длиннее провода и вынести ее за дверь. У кого то есть идеи, что можно еще проверить?   Забыл уточнить, в счетчиках ошибок почти нет, немного overrun, и, почему-то, giants (mtu 1500 на обоих сторонах). CRC нет вообще.
  23. Вроде бы там тупая лайнкарта. Между портами трафик внутри гонять не умеет, все через тушку.