Malissa

Добрый день. Стоит задача дублировать трафик с 1 порта в который направляется трафик до NAT в разных вланах и возвращается в него же но уже после NAT и в отдельном влане. Дублированный трафик нужно раскидать по двум разным RSPAN Трафик до NAT входящий и исходящий 0.0.0.0/0 за минусом одной подсети /24 должен попадать в первый RSPAN Трафик после NAT входящий и исходящий только для подсети /24 должен попадать во второй RSPAN Обычно мы это решали при помощи двух портов. В один направлялся трафик до NAT, а в другой после NAT и спокойно без всяких фильтров дублировался в разные RSPAN с этих портов. Реально ли такое провернуть через ACESS-LIST и может ли кто поделиться примером настройки если такое вообще возможно?

Добрый день. Пользуемся коммутаторами D-Link. Взяли на тест коммутатор SNR модели SNR-S4550-48XQ. Обратили внимание что с него рисуются кривые графики сетевой загрузки в отличае от D-Link. График рисуется при помощи zabbix. Информация собирается раз в 30 секунд. При помощи snmpwalk опредилили что D-Link меняет значение сетевой загрузки по адресу .1.3.6.1.2.1.31.1.1.1.6.порт каждую секунду а в SNR время смены около пяти секунд. Можно как-то привести график на SNR в нормальный вид?

Разобрались. MTU надо было повыше поставить. 1504 не хватало, поставили еще выше. Тему можно закрывать.

Добрый день. Пытаюсь настроить скидывание зеркалирование трафика в несколько агрегированных портов на SNR-S4550-48XQ +RSPAN но трафика уходит в половину меньше чем приходит 46 порт 10Гб приходящий пробовали без влана или в vlan2 в любых режимах access/trunk 47 порт 10Гб уходящий и агрегирован с 48 и находиться в vlan1000 48 порт 10Гб уходящий и агрегирован с 47 и находиться в vlan1000 49 порт 40Гб reflector-port и в него ничего не включено и находиться в vlan1000 config monitor session 1 source interface ethernet 1/0/46 both vlan 1000 remote-span exit interface ethernet 1/0/47 switchport mode trunk switchport trunk allowed vlan 1000 exit interface ethernet 1/0/48 switchport mode trunk switchport trunk allowed vlan 1000 exit interface ethernet 1/1/1 switchport mode trunk switchport trunk allowed vlan 1000 exit monitor session 1 remote vlan 1000 monitor session 1 reflector-port ethernet 1/1/1 если отдавать не в агрегированные порты а в один порт через monitor session 1 destination interface ethernet 1/0/47 без использования monitor session 1 reflector-port ethernet 1/1/1 то наблюдается такая же ситуация с половинным трафиком если не внести входящий 46 порт в vlan1000 (в этом случае все нормально) но если в конфигурации отдачи трафика в агрегированные порты внести входящий 46 порт в vlan1000 то трафик возвращается обратно в 46 порт и в итоге безконечно кольцуется по сети пока не достигнет потолка 10Гбит. Кто то может подсказать что я делаю не так?

Писали в HP, там нам ответили что это баг прошивки биоса и надо прошивать биос, купите у нас продление лицензии а потом мы вам дадим прошивки.

debian 9.5 сетевуха используется другая: Intel Corporation 82599ES 10-Gigabit SFI/SFP+

При отключении гипертрейдинга из 10 ядер загружены только 8 или 16 если включен. Раньше в железке был один камень, второй взяли под увеличение нагрузки, надеялись что будет работать а не надо будет покупать другой сервер.

В биосе про NUMA ничего не нашли. Скрины прикреплены. numactl --hardware | grep cpus node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 Сервер HP ProLiant DL360 Gen9. Используется для маршрутизации сетевого трафика. # /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 CPU16 CPU17 CPU18 CPU19 CPU20 CPU21 CPU22 CPU23 CPU24 CPU25 CPU26 CPU27 CPU28 CPU29 CPU30 CPU31 CPU32 CPU33 CPU34 CPU35 CPU36 CPU37 CPU38 CPU39 9687 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-0 0 11370 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-1 0 0 10870 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-2 0 0 0 11574 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-3 0 0 0 0 11529 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-4 0 0 0 0 0 11500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-5 0 0 0 0 0 0 11718 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-6 0 0 0 0 0 0 0 11951 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-7 0 0 0 0 0 0 0 0 11087 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-8 0 0 0 0 0 0 0 0 0 11627 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-9 0 0 0 0 0 0 0 0 0 0 10400 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-10 0 0 0 0 0 0 0 0 0 0 0 11261 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-11 0 0 0 0 0 0 0 0 0 0 0 0 11283 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-12 0 0 0 0 0 0 0 0 0 0 0 0 0 11025 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-13 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10211 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-14 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10447 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0-TxRx-15 9625 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-0 0 10898 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-1 0 0 10508 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-2 0 0 0 10787 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-3 0 0 0 0 11110 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-4 0 0 0 0 0 10406 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-5 0 0 0 0 0 0 10383 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-6 0 0 0 0 0 0 0 10782 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-7 0 0 0 0 0 0 0 0 10009 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-8 0 0 0 0 0 0 0 0 0 11512 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-9 0 0 0 0 0 0 0 0 0 0 9820 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-10 0 0 0 0 0 0 0 0 0 0 0 10595 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-11 0 0 0 0 0 0 0 0 0 0 0 0 10864 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-12 0 0 0 0 0 0 0 0 0 0 0 0 0 10362 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-13 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10050 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-14 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9989 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1-TxRx-15 4684 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth2-tx-0 301 307 318 316 311 309 317 314 305 309 305 314 310 335 312 313 3 14 5 1 2 5 102 18 27 19 1 1 1 14 16 2 1 1 1 3 94 1 2 8 interrupts 96 96 94 95 94 95 96 95 93 94 95 95 95 94 95 95 17 7 3 1 2 3 48 5 11 9 1 1 1 5 6 2 1 1 1 2 36 2 2 4 interrupts # Load per cpu: CPU Interrupts NET RX NET TX total dropped time_squeeze cpu_collision received_rps CPU0 24405 20861 106 34026 0 0 0 0 CPU1 22672 21690 41 34209 0 0 0 0 CPU2 21792 20906 45 39450 0 0 0 0 CPU3 22774 21749 37 30181 0 0 0 0 CPU4 23048 22006 38 27668 0 0 0 0 CPU5 22312 21518 33 30442 0 0 0 0 CPU6 22516 21468 44 29341 0 0 0 0 CPU7 23142 22160 37 35235 0 0 0 0 CPU8 21495 20555 32 38061 0 0 0 0 CPU9 23542 22578 37 35224 0 0 0 0 CPU10 20620 19630 90 34012 0 0 0 0 CPU11 22265 21306 103 29419 0 0 0 0 CPU12 22555 21614 91 27423 0 0 0 0 CPU13 21816 20939 92 34165 0 0 0 0 CPU14 20668 19746 90 35561 0 0 0 0 CPU15 20845 19912 89 31498 0 0 0 0 CPU16 51 3 0 0 0 0 0 0 CPU17 24 3 0 0 0 0 0 0 CPU18 11 3 0 0 0 0 0 0 CPU19 5 3 0 0 0 0 0 0 CPU20 7 3 0 0 0 0 0 0 CPU21 11 3 0 0 0 0 0 0 CPU22 153 3 0 0 0 0 0 0 CPU23 26 3 0 0 0 0 0 0 CPU24 41 3 0 0 0 0 0 0 CPU25 32 3 0 0 0 0 0 0 CPU26 5 3 0 0 0 0 0 0 CPU27 5 3 0 0 0 0 0 0 CPU28 5 3 0 0 0 0 0 0 CPU29 22 3 0 0 0 0 0 0 CPU30 45 3 0 0 0 0 0 0 CPU31 7 3 0 0 0 0 0 0 CPU32 5 3 0 0 0 0 0 0 CPU33 5 3 0 0 0 0 0 0 CPU34 5 3 0 0 0 0 0 0 CPU35 8 3 0 0 0 0 0 0 CPU36 133 3 0 0 0 0 0 0 CPU37 6 3 0 0 0 0 0 0 CPU38 7 3 0 0 0 0 0 0 CPU39 15 3 0 0 0 0 0 0 # Network devices Device rx-packets rx-mbits rx-errors dropped missed fifo length overrun crc frame tx-packets tx-mbits tx-errors eno4 0 0 0 0 0 0 0 0 0 0 0 0 0 eno2 0 0 0 0 0 0 0 0 0 0 0 0 0 eth2 8 0 0 0 0 0 0 0 0 0 309497 290 0 eth0 302209 564 0 0 0 0 0 0 0 0 370792 2999 0 lo 0 0 0 0 0 0 0 0 0 0 0 0 0 eno3 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1 343908 2973 0 0 0 0 0 0 0 0 275173 527 0

Добрый день. Не распределяется нагрузка по всем ядрам процессоров. Стоит два процессора Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz Задействуются только 8 ядер первого процессора или 16 потоков в не зависимости с одним процессором запускать или с двумя. Кто то знает в чем проблема и как это исправить?

Прикрутили мониторинг состояний онушки. Опять появились похожии случаи, но затухание сигнала ниже. После отвала наблюдается частичная отдача онушкой информации. Не сталкивались с таким? Новая онушка работает нормально. Скрины выложил только с одной онушки, но на других похожая ситуация.

Понятно. Спасибо.

На онушке горит в это время LOSS. Новая онушка в том месте работает нормально. При запуске в режиме стенда с головой без клиентов на коротком расстоянии кабеля работает. Старые раньше через несколько дней при попытке запустить на них связь в тех же местах заработали. Манипуляции которые приводят к восстановлению связи пока не нашли.

Повторилась проблема. BDCOM P1501C1 LastDeregReason = wire-down. Последнее затухание сигнала было -26.5 DBm и ранее держалось таким же.

Не смотрели ранее LastDeregReason. Как будет следующий подобный случай, посмотрим. Проблема наблюдается на всех ONU что есть в сети.

BDCOM(tm) P3608-2TE Software, Version 10.1.0E Build 57360 вот например свежая ONU Vender ID : BDCM ONU MODEL ID : 151C Hardware Version : A0 Software Version : 10.0.17A 1017 метраж: 6556 затухание сигнала: -19.8 не работала около нескольки суток потом сама заработала из сети все время не выключалась в логах вот такая информация May 14 08:24:45 Switch %EPON-ONUDEREG: ONU 8479.7399.52ac is deregistered on EPON0/4:17. ... May 16 14:51:57 Switch %EPON-ONUREG: ONU 8479.7399.52ac is registered on EPON0/4:17. May 16 14:51:57 Switch %EPON-ONUAUTHEN: ONU 8479.7399.52ac is authenticated on EPON0/4:17. May 16 14:51:58 Switch %OLT: Interface EPON0/4:17's OAM Operational Status: Operational May 16 14:52:01 Switch %OLT: Interface EPON0/4:17's CTC OAM extension negotiated successfully!