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

Azamat

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

    274
  • Joined

  • Last visited

1 Follower

About Azamat

  • Rank
    Студент

Контакты

  • ICQ
    105546482

Информация

  • Интересы
    Internet

Город

  • Город
    Bishkek

Recent Profile Visitors

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

  1. нет, это коммутаторы с простой задачей без шансов на получение full. из того, что успели зафиксировать - вырос параметр FWM_MEM_fwm_temp_t Но, есть ли корреляция или нет - не понятно.
  2. Всем доброго дня. Если кто-то сталкивался, может подскажет с проблемой ? Сегодня вдруг на 2 nexus 3064 часа за 3 утекла память до перезагрузки. Сначала подрос процессор с 20% до 40 % (что ниже порога извещения), потом коммутаторы ребутнулись. Что бы могло вызвать такие глюки ? Nex3064-mem leak
  3. Вот такие модули не капризничают 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 втыкали/вынимали.
  4. С медными проблем совсем не замечали. Проблема именно с оптическими QSFP+ и если оптический модуль завесил порт, то выкл/вкл порта уже не поможет, только ждать ребута.
  5. там может быть debounce timer понастраивать надо ? вроде как он отвечает за реакцию на упавшее. По qsfp падений не было больше чем полугодия, а те что были - исключительно ночью. Поэтому реально ни на что не сказывалось. Видимо, если от них не требовать невозможного - то вполне себе зверушка.
  6. да, у нас в основном 2-4 х 10гиг в портченнел. Нужно не для расширения полосы, а для надежности стыка.
  7. Не соглашусь. В сети 66 штук 3064, с pim все в порядке, qsfp на Х версии работают как часы. Портченнелы примерно на 30 шт. есть Все на одной и той же версии 6.ххх Заболел первый коммутатор, примерно за 3 года. Стало жалко зверушку, но до причин не докопались. 7 бед - один ресет.
  8. нет, все внутри, ничего наружу не выходило ни через один физ. интерфейс. На всех svi только исходящий (у нас синий по графику), зеленого в плюсе не было нигде. Как будто под себя ср..ть начал, заболел чем то зараза. Вот и хотели понять, как диагноз поставить.
  9. После ребута полет нормальный. Продолжаем наблюдение.
  10. тв "сыплет" :( это из заметного. Через стандартный IP во влане управления недоступен. Медленно работает консоль, т.к. проц загружен вместо обычных 30-40 проц на 85
  11. Доброго всем дня. Есть 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 ? Сам не нашел, как именно - ибо ремесленники мы. Добавил график.
  12. У меня есть один аплинк, с которым 2 геогр. разных стыка. С одного из них приходит full, весь виден в netstat -rn | wc -l (за 700К записей), но при попытке его отдать дальше клиенту - уходит где то 2К маршрутов. Причем с другого стыка этого же аплинка и full принимается и анонсируется нормально. Если в квагге включить побольше логирования - у меня было видно, что от "корявого" стыка приходила какая-то ошибка в опциях при обмене capabilities - на конкретные вхождения в full и после этого re-anounce маршрутов останавливался. Т.к. победить ту сторону не получилось, то основной full принимается с нормального стыка с аплинком, на второй просто забито, на него default прописан статиком на всякий случай. Суть - включить побольше дебагов квагги и смотреть, на чем идет затык при обмене данными с аплинком, который тормозит отдачу маршрутов дальше. Это если предположить, что сами по себе настройки пиров без ошибок.
  13. в самом первом посте было в общем контексте: 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
  14. Кажется повсюду рекомендации отключать HT. Что-то изменилось ?