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

Azamat

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

    279
  • Joined

  • Last visited

Everything posted by Azamat


  1. Коллеги, доброго дня. Просьба, у кого есть возможность, глянуть - нет ли в списке на блокировку адресов : Address: 104.24.124.213 Address: 104.24.125.213 Это адреса CloudFlare, за ними оказался сайтец, весьма популярный в нашем конце географии - СНГ, но не РФ. Наши арбайтеры в РФ с него, в том числе, черпали инфу о том, все ли у нас сдохло, или что то еще есть живое. Может он прицепом оказался в выгрузке ? Причем резолв и пинги на эти адреса ходят, а браузер дает ошибку соединения. Заранее спасибо и все такое .
  2. не, на не маленькой сети в мст переходить - лучше в 512 вланах жить (имхо).
  3. Проверили по ссылке выше - к домену претензий нет: По Вашему запросу ничего не найдено Значит, одними и теми же IP адресами у CloudFlare прикрыты множество сайтов. Вряд ли РКН что-то изменит, если их вежливо попросить убрать данные адреса из списка ?
  4. Всем доброго дня. Плз подскажите, если кому не лень будет, есть что-то радикально другое в прошивках 9.Х в отличии от 6.Х ? Я бы обновился, если бы кол-во активных вланов выросло бы выше 512, но это же аппаратное ограничение.
  5. Всем доброго дня. Если кто-то сталкивался, может подскажет с проблемой ? Сегодня вдруг на 2 nexus 3064 часа за 3 утекла память до перезагрузки. Сначала подрос процессор с 20% до 40 % (что ниже порога извещения), потом коммутаторы ребутнулись. Что бы могло вызвать такие глюки ? Nex3064-mem leak
  6. нет, это коммутаторы с простой задачей без шансов на получение full. из того, что успели зафиксировать - вырос параметр FWM_MEM_fwm_temp_t Но, есть ли корреляция или нет - не понятно.
  7. Доброго дня, коллеги. Наткнулся на какой-то лютый косяк у nexus N3K-C3064PQ-10GE (на 4 шт точно), может кто-то сталкивался - побеждал/как именно ? При втыкании/извлечении (бывает сразу, бывает с 2-3 цикла) модуля QSFP гнездо на шасси "засыпает", далее при втыкании модуля перестает работать (что опт. трансивер, что медный кабель). Когда гнездо "заснуло" светодиод занятости горит или в оранжевом (мол гнездо пустое) или не горит вообще - мол модуль есть, но линк не поднимается. Лечится только перезагрузкой. Никакие shut/no shut не помогают. После перезагрузки гнезда работают нормально до след. цикла извлечения по какой-либо надобности. Хорошо их там 4, уже пара штук в работе, у которых по 2-3 гнезда "уснули", но линк на 40 работает в последнем гнезде. При этом 10Гб гнезда работают без нареканий.
  8. Вот такие модули не капризничают Ethernet1/15 transceiver is present type is QSFP-40G-LR4 name is OEM part number is QSFP-40G-LR4 revision is 1B serial number is CSQLRI30006 nominal bitrate is 10300 MBit/sec Link length supported for SMF fiber is 10 km cisco id is -- cisco extended id number is 192 Кто производитель - хз. Но порты выдерживают по 6-8 перетыкиваний без зависания. Нам этого хватает. Зато есть один зависший порт, воткнули/вынули модуль от FS, ждем нового года для плановой перезагрузки Eth1/13 eth 40G BAD PORT Reboot at NewYer На медных кабелях ни разу не замечали подвисаний, как то раз 10-15 втыкали/вынимали.
  9. С медными проблем совсем не замечали. Проблема именно с оптическими QSFP+ и если оптический модуль завесил порт, то выкл/вкл порта уже не поможет, только ждать ребута.
  10. Всем доброго дня. Столкнулся с проблемой, плз подскажите, кто знает возможное решение. Есть мост на FreeBSD версии 8.4 - с ним никаких проблем, кроме того, что для замены диска в зеркале надо выключать машину. Решили проверить новые версии 11.2/12.0 в режиме фильтрующего моста. Вроде сдеали по инструкциям из интернет, но видим что пакет попадает в pipe и там уже дропается :( правило в такой форме: создание интерфейса моста: ifconfig_ix0="up -tso4 -tso6 -lro -vlanhwtso" ifconfig_ix1="up -tso4 -tso6 -lro -vlanhwtso" cloned_interfaces="bridge0" ifconfig_bridge0="addm ix0 addm ix1 up" создание трубы: ipfw pipe 100 config bw 15Mbit/s queue 465 заворот в pipe: ipfw add 100 pipe 100 ip from any to 10.10.10.0/24 out via ix0 В таком виде имеем статистику: (net.inet.ip.fw.one_pass: 0) 00100 4946 378727 pipe 100 ip from any to 10.10.10.0/24 out via ix0 00110 0 0 allow ip from any to 10.10.10.0/24 out via ix0 На мосту FB 8.4 оба правила растут синхронно, сначала пакеты попадают в pipe, потом возвращаются в след. правила и выпадают из файра по allow. В 11.2/12.0 никак не могу добиться, чтобы пакет возвращался из pipe к след. правилу. Если правило 100 с pipe убрать совсем - тогда все работает, пакеты ходят нормально. Т.е. что то с dummynet настройками ? Если какая-то инфа нужна для дальнейшей диагностики - плз скажите что именно - сразу опубликую. Заранее спасибо и все такое.
  11. там может быть debounce timer понастраивать надо ? вроде как он отвечает за реакцию на упавшее. По qsfp падений не было больше чем полугодия, а те что были - исключительно ночью. Поэтому реально ни на что не сказывалось. Видимо, если от них не требовать невозможного - то вполне себе зверушка.
  12. Доброго всем дня. Есть nexus 3064, на нем помимо всего прочего 4 svi интерфейса. Вчера в одно и тоже время на всех svi возник из ничего нереально большой исходящий трафик - например, обычный трафик на 2 svi - порядка 1,2 гиг на каждом. Сейчас исходящий судя по графику - 560Гиг на каждом. На 3-м svi обычный трафик 100Кбит/с - влан управления - сейчас на нем исходящий 300Гиг. Доступ только через mgmt порт, через IP адрес на svi управления - скидывается. Реально, нет событий, к которым можно было бы привязать взрыв трафика. Пытались зеркалировать - ничего не видать, вроде т.к. в зеркало на source vlan идет только rx, а взрывной трафик по tx. А сделать source int vlanXXX не дает. Версия 6.ХХХ Из странного еще хороший прирост процесса bcm_usd. На физических интерфейсах - ничего примечательного, все как до взрыва трафика. Пытались делать shutdown на int влана управления - мин 10 держали, потом подняли - ничего не изменилось. В общем может кто подскажет, как можно хоть что-то отдебажить до перезагрузки, которую запланировали на 6 утра ? Может есть возможность убить процесс с HUP ? Сам не нашел, как именно - ибо ремесленники мы. Добавил график.
  13. да, у нас в основном 2-4 х 10гиг в портченнел. Нужно не для расширения полосы, а для надежности стыка.
  14. Не соглашусь. В сети 66 штук 3064, с pim все в порядке, qsfp на Х версии работают как часы. Портченнелы примерно на 30 шт. есть Все на одной и той же версии 6.ххх Заболел первый коммутатор, примерно за 3 года. Стало жалко зверушку, но до причин не докопались. 7 бед - один ресет.
  15. нет, все внутри, ничего наружу не выходило ни через один физ. интерфейс. На всех svi только исходящий (у нас синий по графику), зеленого в плюсе не было нигде. Как будто под себя ср..ть начал, заболел чем то зараза. Вот и хотели понять, как диагноз поставить.
  16. После ребута полет нормальный. Продолжаем наблюдение.
  17. тв "сыплет" :( это из заметного. Через стандартный IP во влане управления недоступен. Медленно работает консоль, т.к. проц загружен вместо обычных 30-40 проц на 85
  18. У меня есть один аплинк, с которым 2 геогр. разных стыка. С одного из них приходит full, весь виден в netstat -rn | wc -l (за 700К записей), но при попытке его отдать дальше клиенту - уходит где то 2К маршрутов. Причем с другого стыка этого же аплинка и full принимается и анонсируется нормально. Если в квагге включить побольше логирования - у меня было видно, что от "корявого" стыка приходила какая-то ошибка в опциях при обмене capabilities - на конкретные вхождения в full и после этого re-anounce маршрутов останавливался. Т.к. победить ту сторону не получилось, то основной full принимается с нормального стыка с аплинком, на второй просто забито, на него default прописан статиком на всякий случай. Суть - включить побольше дебагов квагги и смотреть, на чем идет затык при обмене данными с аплинком, который тормозит отдачу маршрутов дальше. Это если предположить, что сами по себе настройки пиров без ошибок.
  19. в самом первом посте было в общем контексте: net.inet.ip.fw.one_pass: 0 То ли в 12.0 увели в штатном режиме обработку прерываний в system, то ли х.з. что еще. Вот роутер на 12.0-stab: netstat -bdh -w1 -I ix0 416k 0 0 515M 222k 0 46M 0 0 544k 0 0 673M 289k 0 61M 0 0 netstat -bdh -w1 -I ix1 input ix1 output packets errs idrops bytes packets errs bytes colls drops 229k 0 0 64M 408k 0 492M 0 0 234k 0 0 65M 426k 0 517M 0 0 255k 0 0 68M 447k 0 546M 0 0 257k 0 0 71M 461k 0 562M 0 0 top -PHS last pid: 63873; load averages: 2.04, 2.20, 2.16 up 30+04:29:51 22:20:40 191 threads: 8 running, 166 sleeping, 17 waiting CPU 0: 0.4% user, 0.0% nice, 52.3% system, 0.4% interrupt, 46.9% idle CPU 1: 0.0% user, 0.0% nice, 52.7% system, 0.0% interrupt, 47.3% idle CPU 2: 0.0% user, 0.0% nice, 54.0% system, 0.0% interrupt, 46.0% idle CPU 3: 0.0% user, 0.0% nice, 61.5% system, 0.0% interrupt, 38.5% idle Mem: 26M Active, 1348M Inact, 1050M Wired, 493M Buf, 5596M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 0 root -76 - 0 384K CPU1 1 206.2H 53.17% kernel{if_io_tqg_1} 0 root -76 - 0 384K - 2 207.1H 49.33% kernel{if_io_tqg_2} 0 root -76 - 0 384K - 3 206.5H 48.67% kernel{if_io_tqg_3} 0 root -76 - 0 384K - 0 202.7H 48.41% kernel{if_io_tqg_0} здесь тоже вся прерывания в system, хотя: net.isr.numthreads: 4 net.isr.maxprot: 16 net.isr.defaultqlimit: 20480 net.isr.maxqlimit: 20480 net.isr.bindthreads: 1 net.isr.maxthreads: 4 net.isr.dispatch: direct + выпилен Fastforwarding (во всех предыдущих версиях облегчал жизнь),сейчас вместо сделали какой-то tryforward, как зафиксировать его влияние - хз. до кучи: interrupt total rate irq1: atkbd0 2 0 cpu0:timer 2934125667 1125 cpu1:timer 2935059792 1125 cpu2:timer 2933854332 1125 cpu3:timer 2934959046 1125 irq264: ix0:rxq0 61858968128 23714 irq265: ix0:rxq1 75590459238 28978 irq266: ix0:rxq2 75312963992 28871 irq267: ix0:rxq3 75505104647 28945 irq268: ix0:aq 7 0 irq269: ix1:rxq0 90200128638 34578 irq270: ix1:rxq1 97008771872 37188 irq271: ix1:rxq2 96822862993 37117 irq272: ix1:rxq3 96773135031 37098 irq273: ix1:aq 18 0 irq275: ahci0 36970587 14 irq278: em0:irq0 410569352 157 Total 681257933342 261161 Работает как роутер не хуже, но и не лучше других версий, у меня на них базовая 10.3
  20. Кажется повсюду рекомендации отключать HT. Что-то изменилось ?
  21. Может потому что число ядер в процессоре 6 ? Вот по кол-ву ядер и распределилось по например по net.isr.bindthreads="1" Performance # of Cores6
  22. Итого: под нагрузкой мост на FB 12.0 оказался полной лажей : на трафике меньше 1 Гбит/с (который мост на FB 8.4 даже не замечает): CPU 0: 0.0% user, 0.0% nice, 77.6% system, 0.0% interrupt, 22.4% idle CPU 1: 0.0% user, 0.0% nice, 77.6% system, 0.0% interrupt, 22.4% idle CPU 2: 0.0% user, 0.0% nice, 74.8% system, 0.0% interrupt, 25.2% idle CPU 3: 0.0% user, 0.0% nice, 83.7% system, 0.0% interrupt, 16.3% idle Mem: 18M Active, 8680K Inact, 276M Wired, 90M Buf, 7479M Free Swap: 8192M Total, 8192M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 0 root -76 - 0 400K CPU1 1 55:25 81.45% kernel{if_io_tqg_1} 0 root -76 - 0 400K - 3 57:22 80.68% kernel{if_io_tqg_3} 0 root -76 - 0 400K - 2 55:35 74.87% kernel{if_io_tqg_2} 0 root -76 - 0 400K CPU0 0 56:27 69.53% kernel{if_io_tqg_0} 11 root 155 ki31 0 64K RUN 0 21:21 29.24% idle{idle: cpu0} 11 root 155 ki31 0 64K CPU2 2 22:51 24.90% idle{idle: cpu2} 11 root 155 ki31 0 64K RUN 3 21:06 19.16% idle{idle: cpu3} 11 root 155 ki31 0 64K RUN 1 23:01 18.71% idle{idle: cpu1} 0 root -92 - 0 400K - 0 0:57 1.57% kernel{dummynet} Почему то вся нагрузка на system, хотя net.isr в direct net.inet.ip.dummynet.io_fast: 1 волшебной крутилки чтобы снизить нагрузку не нашел, возвращаемся на 8.4
  23. Вам отдельное спасибо, реплики "Не мешайте ему жить в древнем мире." - очень мотивируют на самостоятельный поиск решений.