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

naguser714

Пользователи
 Просмотреть профиль  Активность

  • Публикации

    21

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

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем naguser714

  5. Опубликовано · Жалоба на ответ

    On 11/24/2018 at 7:26 AM, Ivan_83 said:

    Потому что:

    - у тебя параметр 10к пакетов отрабатывается в юзерспейсной проге, а ей ядро нахерачело 1м пакетов куда то и их надо разобрать а потом додуматся что ядру надо указать отключить этот поток

    - откуда ты взял что там реально 10мс - хз

    - в влане у тебя видимо трафика меньше, а когда ты с основного забираешь то там трафик всех вланов разгребается на самом деле

    Проблема проявляется не постоянно, 1 раз из 5-10. Обычно, сбор 10к пакетов у меня занимает 10мс из расчёта 1Mpps (вход + выход).

     

     

    On 11/24/2018 at 7:26 AM, Ivan_83 said:

    Если тебе это надо то у тебя два пути:

    1. ты сам разбираешься и патчишь себе ядро и софт

    2. ты обновляешься хотя бы до 12.0 и пишешь в рассылку и багтрекер

    Так и понял. :)

     

    Всем спасибо за участие!

  6. Опубликовано · Жалоба на ответ

    5 hours ago, Ivan_83 said:

    Это не шторм прерываний, это вы в обработчике прерываний дохера делаете.

    Запуск tcpdump на 10мс для сбора всего 10000 пакетов может привести к локу на 1-2 минуты. И это происходит не всегда, и как заметили только при дампе пакетов с основного интерфейса. При сборе с vlan интерфейсов, проблема не воспроизводится.

     

     

    6 hours ago, Ivan_83 said:

    1. двухпроцовая машина для роутинга/ната зло.

    По нату не скажу, но второй процессор не снижает производительность маршрутизации. Имею в виду, что если отключить второй процессор, то производительность не поднимется, но произойдёт обратное. Это подтверждается в свежем отчёте (пункт I) по маршрутизации FreeBSD [1]

     

     

    6 hours ago, Ivan_83 said:

    PS: пора обновляться до 11.2, 12 уже скоро зарелизится.

    Да, понимаю. Есть пара сдерживающих факторов.

     

     

    [1] https://people.freebsd.org/~olivier/talks/2018_AsiaBSDCon_Tuning_FreeBSD_for_routing_and_firewalling-Paper.pdf

  7. Опубликовано · Жалоба на ответ

    Здравствуйте, уважаемые эксперты!


    Не сталкивался кто-нибудь со следующей проблемой. После оптимизации ipfw правил, переодически начали получать блокировку сервера (FreeBSD 10.3) на 1-2 минуты при попытке запуска диагностических утилит iftop/tcpdump. Запуск top в фоне показал, что сервер захлёбывается сетевыми прерываниями в это время:


    ---------------

    last pid:  2317;  load averages: 50.31, 25.49, 12.85  up 9+10:50:12    16:35:25
    261 processes: 31 running, 139 sleeping, 91 waiting
    CPU:  0.0% user,  0.0% nice,  0.0% system, 99.8% interrupt,  0.1% idle
    Mem: 13M Active, 7367M Inact, 1453M Wired, 1949M Buf, 7023M Free
    Swap: 32G Total, 32G Free

      PID USERNAME      PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
       12 root          -92    -     0K  1552K WAIT    6  37.8H 100.00% intr{irq309: ix0:q6}
       12 root          -92    -     0K  1552K CPU5    5  37.4H 100.00% intr{irq308: ix0:q5}
       12 root          -92    -     0K  1552K WAIT    4  36.9H 100.00% intr{irq307: ix0:q4}
       12 root          -92    -     0K  1552K WAIT    3  36.8H 100.00% intr{irq306: ix0:q3}
       12 root          -92    -     0K  1552K WAIT    1  36.5H 100.00% intr{irq304: ix0:q1}
       12 root          -92    -     0K  1552K WAIT    7  36.2H 100.00% intr{irq310: ix0:q7}
       12 root          -92    -     0K  1552K CPU8    8  36.0H 100.00% intr{irq311: ix0:q8}
       12 root          -92    -     0K  1552K WAIT    2  35.9H 100.00% intr{irq305: ix0:q2}
       12 root          -92    -     0K  1552K CPU9    9  35.8H 100.00% intr{irq312: ix0:q9}
       12 root          -92    -     0K  1552K WAIT   10  35.7H 100.00% intr{irq313: ix0:q10}
       12 root          -92    -     0K  1552K CPU13  13  35.7H 100.00% intr{irq316: ix0:q13}
       12 root          -92    -     0K  1552K WAIT   15  35.5H 100.00% intr{irq318: ix0:q15}
       12 root          -92    -     0K  1552K CPU12  12  35.5H 100.00% intr{irq315: ix0:q12}
       12 root          -92    -     0K  1552K WAIT   11  35.4H 100.00% intr{irq314: ix0:q11}
       12 root          -92    -     0K  1552K WAIT   14  35.3H 100.00% intr{irq317: ix0:q14}
       12 root          -92    -     0K  1552K WAIT    0  36.5H  99.27% intr{irq303: ix0:q0}
        0 root          -92    -     0K  1232K -       3 570:16   2.59% kernel{dummynet}
    5034 root           21    0 36092K  6088K CPU6    6   1:08   0.78% zebra
    -------------------

     

    Сервер используется для маршрутизации ~3Гбит трафика (вход + выход), скорость пересылки достигает ~1Mpps (вход + выход). До оптимизации ipfw, нагрузка на процессор в ЧНН достигала 70-80%, после упала на 20%, но начались вышеописанные проблемы. К примеру, следующие команды могут залочить сервер:


    iftop -n -i ix0 -f 'host 8.8.8.8'

    tcpdump -n -i ix0 -c 10000 -w /tmp/test.pcap

     

    По железу, стоит двухпроцессорная система по 8 реальных ядер на каждом (HT отключен) и сетевая 10Г карта Intel 82599ES.


    Как я понимаю, проводя меньше времени в ipfw коде, пакеты больше подвержены каким-то локам. Либо, после оптимизации поднялся PPS и проблема начала проявляться. В ЧНН нагрузка на процессор следующая:


    --------------
    last pid: 96942;  load averages:  2.54,  2.78,  2.86                                                                          up 1+08:41:17  13:37:09
    247 processes: 19 running, 133 sleeping, 95 waiting
    CPU:  0.0% user,  0.0% nice,  0.5% system, 18.4% interrupt, 81.1% idle
    Mem: 8244K Active, 67M Inact, 1079M Wired, 5344K Cache, 1722M Buf, 14G Free
    Swap: 32G Total, 32G Free

      PID USERNAME      PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
       12 root          -92    -     0K  1552K WAIT    1 319:33  18.90% intr{irq304: ix0:q1}
       12 root          -92    -     0K  1552K WAIT    2 321:07  18.80% intr{irq305: ix0:q2}
       12 root          -92    -     0K  1552K WAIT   10 307:41  18.80% intr{irq313: ix0:q10}
       12 root          -92    -     0K  1552K WAIT   13 317:14  18.65% intr{irq316: ix0:q13}
       12 root          -92    -     0K  1552K WAIT    8 306:12  18.16% intr{irq311: ix0:q8}
       12 root          -92    -     0K  1552K CPU14  14 308:14  17.29% intr{irq317: ix0:q14}
       12 root          -92    -     0K  1552K WAIT    0 320:28  17.09% intr{irq303: ix0:q0}
       12 root          -92    -     0K  1552K WAIT    3 307:38  17.09% intr{irq306: ix0:q3}
       12 root          -92    -     0K  1552K WAIT    7 301:48  17.09% intr{irq310: ix0:q7}
       12 root          -92    -     0K  1552K WAIT    5 318:14  16.99% intr{irq308: ix0:q5}
       12 root          -92    -     0K  1552K WAIT    6 314:38  16.99% intr{irq309: ix0:q6}
       12 root          -92    -     0K  1552K WAIT   12 299:17  16.99% intr{irq315: ix0:q12}
       12 root          -92    -     0K  1552K WAIT   11 300:40  16.80% intr{irq314: ix0:q11}
       12 root          -92    -     0K  1552K WAIT    9 296:23  16.80% intr{irq312: ix0:q9}
       12 root          -92    -     0K  1552K WAIT   15 307:43  16.46% intr{irq318: ix0:q15}
       12 root          -92    -     0K  1552K CPU4    4 316:50  15.19% intr{irq307: ix0:q4}
    ----------------------

     

     

    Заранее спасибо!

  8. Опубликовано · Жалоба на ответ

    On 11/9/2018 at 10:08 PM, xcme said:

    При потреблении в ЧНН около 1 мбита на пользователя больше она просто не прожует по пропускной способности в 10Г линках. Да, можно еще и 1Г порты использовать, но это неудобно.

    По сути, в том месте это все, что есть. Специально не ограничивается ничего. Сервисов по минимуму - редирект и полисинг.

    Каких либо проблем нет, поставил и забыл. Да, конечно пора уже о расширении думать, но сейчас все думают о "Яровой" :)

     

    Спасибо за информацию! Теперь имею представление о данном железе.

  9. Опубликовано · Жалоба на ответ

    11 hours ago, xcme said:

    У меня число PPPoE сессий на ASR-1001x достигает 9,5k.

    Вы не могли бы уточнить, в вашей конфигурации начинаются проблемы при значении выше 9.5к или просто не было необходимости терминировать больше?

     

    И не могли бы немного рассказать о самих сессиях, как плотно они нагружены сервисами? Спасибо.

  11. Опубликовано · Жалоба на ответ

    Здравствуйте, друзья!

     

    Подскажите пожалуйста, из чего формируется ограничение количества абонентов (8000 сессий) для ASR1001-X, указанное в документации?

     

    Это ограничение:
    (а) искусственное, оборудование начинает игнорировать запросы от 8001-го абонента;
    (б) связанное с выделением ресурсов (RAM) на каждую сессию;
    (в) рассчитанное, учитывая среднюю полосу пропускания абонента при общей полосе 20Гб/с?

     

    Используем PPPoE (ISG) на нескольких 7301, хотим мигрировать на ASR.

     

    Заранее спасибо!

  12. Опубликовано · Жалоба на ответ

    Добрый день,

     

    Подскажите пожалуйста, доступен ли данный функционал на коммутаторах SNR-S2990G-24FX (HW: 1.0.2-UPS)? Установлено ПО 7.0.3.5(R0102.0257), но вышеуказанный OID недоступен, как и команда "rps-power monitor on ".

     

    Спасибо!

  13. Опубликовано · Жалоба на ответ

    naguser714, такой команды нет.

     

    Спасибо. Можно ли будет добавить данный функционал в TODO лист? Без этой функции у пользователя с ограниченными правами отсутствует возможность проверки установленной скорости.

    Нужно ли оформить данную заявку через support?

  14. Опубликовано · Жалоба на ответ

    Подскажите пожалуйста, какой командой можно просмотреть (show ...) текущее установленное ограничение скорости на порту (bandwidth control) без вывода текущей конфигурации (show running-config). Заранее спасибо!

  16. Опубликовано · Жалоба на ответ

    authentication line console login local

    Возможно, Вам нужно это.

     

    Это установлено по-умолчанию на коммутаторе. К тому же, если новый созданный пользователь имеет полные привилегии (privelege 15), то проблем нет.

  17. Опубликовано · Жалоба на ответ

    Здравствуйте,

     

    Подскажите пожалуйста, как лечится следующая проблема. После удаления локального привилегированного (privilege 15) пользователя admin, при подключении с консольного порта не инициируется проверка подлинности, не смотря на то, что заведён другой непривилегированный пользователь.

     

    К примеру, используя следующие настройки:

     

    --

    no username admin

    enable password level 15 0 enablepass

    username user password 0 userpass

    --

     

    получаю пользовательскую строку без ввода учётных данных, используя консольный порт:

     

    SNR-S2965-24T>

     

     

    Детали по оборудованию:

    SNR-S2965-24T Device, Compiled on Dec 30 10:28:50 2016

    SoftWare Version 7.0.3.5(R0241.0133)

    HardWare Version 1.0.2

     

     

    Заранее спасибо!

  18. Опубликовано · Жалоба на ответ

    Здравствуйте!

     

    Есть ли у кого-нибудь возможность поделиться прошивкой на DSLAM ZTE 9806H версии V2.1.1P3 или выше. О существовании данной версии узнал здесь.

     

    Заранее спасибо!