Jump to content

nixx

Активный участник
  • Posts

    404
  • Joined

  • Last visited

1 Follower

About nixx

  • Rank
    Студент
    Студент

Информация

  • Пол
    Array

Город

  • Город
    Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. с обоими новыми прошивками при этих командах получаю ответ от OLT: DHCPR:Failed,the maximum number(100) of VLANs allowed has been exceeded. как теперь это ограничение убрать? или всё, никак?
  2. не пробовал. но именно локально оно и уходило в себя. top на экране зависал, на клавиатуру никакой реакции, все ядра в полке, пока не снимал трафик с сетевухи. ну и гугл говорит, что при превышении этого значения должны быть сообщения типа "interrupt storm detected on..." - ничего подобного не было. сетевухи были 82599 и connectx-4, сама фря - 10я, как чистая, так и с патчами от разработчика упомянутого здесь "BSD Router Project". я тогда дошел до 7,5 Mpps без дропов, дальше дропы, дальше ну где-то на 10 Mpps - висяк. линукс же, даже при вливании в него по максимуму 14 Mpps, оставался вполне пинабельным с консоли, хоть и хреново роутящим )
  3. я не понимаю, чему там падать, если оно вообще проц не кушает ) ну в смысле - неужели другой софт написан более жруче? вот стоит бордер с тремя фулл-вью (честными, по 900к маршрутов), скушанное бёрдом процессорное время - 1 час 40 минут за 80 суток аптайма. процесс snmpd и то больше отъел. ушел с фри на линукс, убедившись в непереносимости фрёй ддосов с высоким pps. там, где фря становится колом и вообще не реагирует на внешние раздражители, линукс, дропая 80% пакетов, вполне жив и отзывчив.
  4. я тоже удивлялся, чего у меня часы не синхронизируются. но подсказка командной строки рулит. ntp client enable
  5. спасибо ) и скажите сразу, чтобы лишних тем не заводить - у вас в хранилище появился такой каталог: https://data.nag.ru/BDCOM/Firmware/P3600-XXE/ - это ведь для этой модели прошивки? P3600-08E.
  6. BDCOM(tm) P3600-08E Software, Version 10.1.0G Build 92596 есть BDCom, есть два микротика, воткнутых в него downlink-портами (к абонентам) абоненты подключены по схеме vlan на пользователя планируется перенос части абонентов с одного микротика на другой (ну то есть перекидывание части вланов с одного порта BDCom'а на другой) работающий интерфейс: interface GigaEthernet0/1 description --Mtik-to-clients-- switchport trunk vlan-allowed 1001-1512,3000 switchport trunk vlan-untagged 3000 switchport mode trunk switchport pvid 3000 dhcp snooping trust no storm-control broadcast threshold no storm-control multicast threshold no storm-control unicast threshold второй интерфейс: interface GigaEthernet0/4 description --TEST-to-clients-- switchport trunk vlan-allowed 3000 switchport trunk vlan-untagged 3000 switchport mode trunk switchport pvid 3000 dhcp snooping trust no storm-control broadcast threshold no storm-control multicast threshold no storm-control unicast threshold помимо этого, в конфиге такое: ip dhcp-relay snooping ip dhcp-relay snooping vlan 1001-1512 планировал убрать с первого интерфейса вланы 1300-1400 и перекинуть их на Gi0/4 но помешало забавное лезу на второй микротик (подключенный к Gi0/4) и вижу, что у него висят в dhcp десяток лиз, выданных в абонентские вланы, в абсолютно разные - и в 1119, и в 1430 причем на порту BDCom'а-то вланов этих нет как показали эксперименты, засада в строчке "dhcp snooping trust" когда ее прописываю на порт, через него начинают форвардиться dhcp-запросы в абонентских вланах убираю - запросы пропадают вот такой прикол. или так задумано? )
  7. да, была очередь по умолчанию, потом по совету какого-то спеца по микротикам поставили как раз 1000. вообще ничего не изменилось, те же тормоза. при нормальной работе трафик в очереди попадает, счетчики увеличиваются. но вот за счетчики именно в момент тормозов не ручаюсь, спецом не смотрел. спрошу у коллег, может кто вспомнит... ну или посоздаем негатив, включим шейпер минут на 10.
  8. прочитать одну страницу документации https://github.com/aabc/ipt-netflow, ищите по строке "bind socket to"
  9. ну то есть вы хотите сказать, что если забить мегабитное (мелкое по скорости) правило, то весь шейпер встанет раком? ...или нет, наверное не хотите. наверное, недопоняли. тормозит весь шейпер (все абоненты) до мегабита и ниже, а не какие-то одиночные подключения.
  10. у вас IPFIX льется? в 1.6.11 еще вообще не заявлены nat-event из IPFIX.
  11. господа, а кто-нибудь льет nat-events с ipt_NETFLOW 2.3 (да, старый) в IPFIX-формате в nfcapd? получается нормально принять? если да, то сразу завелось, или были нюансы? у меня распоследний nfcapd (и 1.6.25 и 1.7.0.1) отказывается читать время в NAT-events, пишет 1970-й год. обычные flow пишет нормально. сдампил летящие flow - вроде как время передается нормально, wireshark видит корректную дату. или я что-то недоконфигурил в ipt_NETFLOW (а что там можно конфигурить? protocol=10 natevents=1, всё) или nfdump немного не очень в IPFIX?
  12. да нет никакого мониторинга от слова "совсем"... я только сделал на скорую руку, чтобы интерфейсы рисовались. насчет перегрева - идея в голову залетала, но была отметена по причине того, что вместо 1009 туда уже ставился 1072, и он так же тормозил. ну, в целом-то, отрисовать температуры/обороты - дело нескольких щелчков, сделаю сегодня.
  13. есть узлы сети на микротиках, много ccr1009 (в основном) работают в качестве шейперов/маршрутизаторов для клиентов, подключенных по схеме vlan-per-user, в каждом влане также поднят dhcp сервер с маской /29, плюс в целом на микротике для абонентов работает днс с форвардингом запросов во внешний мир (ну типа на 8.8.8.8, 1.1.1.1). еще там есть файерволл из ~4-6 правил с редиректом на сайт провайдера для отключенных абонентов, но он, сцуко, везде разный, и я пока не добился, как же он должен выглядеть в оригинале. походу, буду сам сочинять. и вот пришел сентябрь, абоненты вернулись в родные края кто работать, кто учиться, трафик приподнялся, и все это начало в отдельно взятых местах (т.е. в 2-3 местах из десятка, где такое железо стоит) нещадно тормозить - у абонентов in/out скорость снижается до 1 мбита вместо тарифных 50. при этом загрузка всех ядер - в пределах 40 процентов, т.е. в проц не упирается ну вообще никак. отключаем шейпинг - тормоза проходят. шейпинг сделан на simple queues, одна общая очередь в гигабит размером, в которую (как в Parent'а) напиханы персональные абонентские по ~50мбит. queue type - default-small. вопрос к знатокам (я, увы, вот так плотно в абонентов микротики не впихивал - у меня они сугубо для каналообразующих целей всю жисть были) - как/где дебажить, из-за чего именно скукоживается шейпинг? абонтрафик ниже микротика дампил, в целом ничего в глаза бросающегося не поймал (ну типа там высоких pps, левых пакетов и прочего). но дампил "по случаю", объем был маленький, по-хорошему надо ехать (увы, далеко и лениво) и снова дампить. нетбиос позаблочил везде, ipv6 тоже до кучи (до меня вообще никаких acl'ек нигде не было). пока из идей - еще раз половить вредителей сниффером (если они вообще есть), попробовать убрать все редиректы из файерволла, оставив только drop/reject отключенным абонентам. upd: все это происходило на 6.48.6, и также пробовали накатывать 7.5 - без изменений.
  14. такие вопросы позволяют почувствовать себя гуглом. https://h10145.www1.hpe.com/downloads/SoftwareReleases.aspx?ProductNumber=JG912A&lang=en&cc=us&prodSeriesId=
  15. стоит во всеуслышанье пожаловаться, как всё лечится ) даунгрейд до ядра 4.19.37 помог (поставил чистый дебиан 10.0 и "зафиксировал" apt-mark'ом пакеты ядра от обновлений). нагрузка снизилась до приемлемых процентов/переключений и ошибок на интерфейсах пока ноль. подожду чнн. драйвер сетевухи 4.9 из отсюда.