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

neperpbl3

Пользователи
  • Posts

    13
  • Joined

  • Last visited

About neperpbl3

  • Rank
    Абитуриент
    Абитуриент

Информация

  • Пол
    Array

Город

  • Город
    Array

Контакты

  • Skype
    Array

Recent Profile Visitors

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

  1. Hardware cisco Nexus3000 C3064PQ Chassis Intel(R) Celeron(R) CPU P4505 @ 1.87GHz with 3901500 kB of memory. BIOS: version 5.0.0 NXOS: version 9.3(7)
  2. Гигабитный 24 портовый коммутатор коммутатор Элтекс MES2324 с 4 портами 10G стоит около 16 тыс. руб. Мы его используем повсеместно. Удобен и надежен.
  3. Здравствуйте! Привожу пример настройки Control Plane Policing (CoPP) для Cisco Nexus 3064 когда ключевая роль устройства - маршрутизатор, а второстепенная роль - коммутатор. CoPP- это этакий storm-control для процессора коммутатора. При бродкастовом шторме, помимо прочего, резко возрастает количество ARP-запросов. Когда это количество зашкаливает, процессор загружается на 100% – и сеть, понятно, говорит вам “до свиданья”. CoPP умеет “дозировать” количество ARP-запросов и таким образом управлять нагрузкой на процессор. Неплохо справляется и с броадкастовыми штормами со стороны точек обмена трафиком, и с различными DDoS-атаками — проверено. habr.com Очистить статистику clear copp statistics Просмотр потерь show policy-map interface control-plane | i DropPackets Просмотр блоков Cisco-Nexus# show policy-map interface control-plane | section "class-map copp-s-arp" class-map copp-s-arp (match-any) police pps 2000 OutPackets 13782509 DropPackets 16321314 sh policy-map type control-plane show running-config copp Описание ключевых блоков Пороговые значения всех функций pps являются единым целым. Просто прибавить нельзя. Чтобы добавить к одному, нужно отщепить от другого. class copp-s-glean (police pps 10000) Какие-то очень важные пакеты, если Nexus используется в роли маршрутизатора. Замечено, что ARP пакеты, предназначающиеся клиентам или самому маршрутизатору попадают в этот счетчик. Этот счетчик начинает резко расти при перестроении дерева Spanning-tree (MSTP). Если пороговое значение низкое, то в момент перестроения Spanning-tree начинают тупить пинги до клиентов, в то время как счетчик drop продолжает расти. Значения 6000 PPS при тестировании перестроении MSTP не хватает. Пока не сделаешь «clear ip arp» счетчик не перестает расти. Можно ли сделать скрипт, который при росте счетчиков делал бы «clear ip arp»? При стрессе (петля) немного появляется дропов. class copp-s-arp (police pps 20000) Это все ARP пакеты, проходящие через коммутатор L3. В этот счетчик попадают абсолютно все ARP пакеты, проходящие через коммутатор, даже не адресованные коммутатору L3 (например транзитные arp пакеты из клиентских каналов). При закольцеваниях и штормах дропы начинают резко расти. Это оказывает отрицательное влияние, если Nexus используется в качестве маршрутизатора, страдает качество предоставления услуги интернет. Пороговое значение надо выставлять максимально возможным. class copp-s-bpdu (police pps 500) Обработчик bpdu кадров. class copp-s-igmp (police pps 50) Отрицательного влияния не выявлено class copp-s-routingProto2 (police pps 100) Не понятно, что за пакеты. При стрессе (петля) дропов нет. На настроенную маршрутизацию по протоколу BGP никакого отрицательного влияние не выявлено. class copp-s-routingProto1 (police pps 500) Не понятно, что за пакеты. Наличествует много дропов. При тестировании 50 PPS возникает лавина дропов, но отрицательного влияния при стрессе (петля) не выявлено. На настроенную маршрутизацию по протоколу BGP никакого отрицательного влияние не выявлено. class copp-s-selfIp (police pps 800) Все пакеты, назначающиеся к самому устройству (ping любого IP адреса самого коммутатора, работа ssh, snmp). При малых значениях PPS пакеты начинают выстраиваться в очередь. Если интенсивно пинговать, то затрудняется доступ в SSH. Клиенты при диагностике (ping основного шлюза) могут получать большие задержки и даже потери. На коммутацию и маршрутизацию это никак не влияет. У copp-s-selfIp при превышении отсутствует drop. Вместо этого пакеты выстраиваются в очередь и доступ к устройству начинает тупить. class copp-s-l3destmiss О назначении этих пакетов не известно copp-s-l2switched О назначении этих пакетов не известно Полная конфигурация policy-map type control-plane copp-system-policy class copp-s-default police pps 100 class copp-s-l2switched police pps 500 class copp-s-ping police pps 10 class copp-s-l3destmiss police pps 100 class copp-s-glean police pps 10000 class copp-s-selfIp police pps 800 class copp-s-l3mtufail police pps 10 class copp-s-ttl1 police pps 20 class copp-s-ipmcmiss police pps 5 class copp-s-l3slowpath police pps 5 class copp-s-dhcpreq police pps 5 class copp-s-dhcpresp police pps 5 class copp-s-dai police pps 5 class copp-s-igmp police pps 50 class copp-s-eigrp police pps 5 class copp-s-pimreg police pps 5 class copp-s-pimautorp police pps 5 class copp-s-routingProto2 police pps 100 class copp-s-v6routingProto2 police pps 5 class copp-s-routingProto1 police pps 500 class copp-s-arp police pps 20000 class copp-s-ptp police pps 5 class copp-s-vxlan police pps 5 class copp-s-bfd police pps 10 class copp-s-bpdu police pps 400 class copp-s-dpss police pps 5 class copp-s-mpls police pps 5 control-plane service-policy input copp-system-policy SNMP OID OutPackets copp-s-l2switched .1.3.6.1.4.1.9.9.166.1.17.1.1.6.721420317.721420319 copp-s-glean .1.3.6.1.4.1.9.9.166.1.17.1.1.6.721420317.721420322 copp-s-selfIp .1.3.6.1.4.1.9.9.166.1.17.1.1.6.721420317.721420323 copp-s-ttl1 .1.3.6.1.4.1.9.9.166.1.17.1.1.6.721420317.721420325 copp-s-igmp .1.3.6.1.4.1.9.9.166.1.17.1.1.6.721420317.721420331 copp-s-routingProto2 .1.3.6.1.4.1.9.9.166.1.17.1.1.6.721420317.721420335 copp-s-routingProto1 .1.3.6.1.4.1.9.9.166.1.17.1.1.6.721420317.721420337 copp-s-arp .1.3.6.1.4.1.9.9.166.1.17.1.1.6.721420317.721420338 copp-s-bpdu .1.3.6.1.4.1.9.9.166.1.17.1.1.6.721420317.721420342 DropPackets copp-s-l2switched .1.3.6.1.4.1.9.9.166.1.17.1.1.20.721420317.721420319 copp-s-glean .1.3.6.1.4.1.9.9.166.1.17.1.1.20.721420317.721420322 copp-s-selfIp .1.3.6.1.4.1.9.9.166.1.17.1.1.20.721420317.721420323 copp-s-ttl1 .1.3.6.1.4.1.9.9.166.1.17.1.1.20.721420317.721420325 copp-s-igmp .1.3.6.1.4.1.9.9.166.1.17.1.1.20.721420317.721420331 copp-s-routingProto2 .1.3.6.1.4.1.9.9.166.1.17.1.1.20.721420317.721420335 copp-s-routingProto1 .1.3.6.1.4.1.9.9.166.1.17.1.1.20.721420317.721420337 copp-s-arp .1.3.6.1.4.1.9.9.166.1.17.1.1.20.721420317.721420338 copp-s-bpdu .1.3.6.1.4.1.9.9.166.1.17.1.1.20.721420317.721420342 Примеры графиков Ссылки Cisco Nexus 3000 Series NX-OS Security Configuration Guide, Release 7.x Five Things About Cisco Nexus 5K Control Plane Policing (CoPP) blog/ posts/ NX-OS Control Plane Policing Modifying Control Plane Policying to Protect Routing Neighbors Coping with CoPP – Why ICMP Drops Happen
  4. Здравствуйте. Не интересовался. В data_sheet что-нибудь сказано? Здесь спрашивали? Есть свободный тестовый коммутатор. Если нужно проверить скажите как проверить. я проверю. Здравствуйте. Файл сжимается минут 5-7 Здравствуйте. Коммутатор загружается около 5 минут. По секундомеру не замерял. Могу замерить, если для вас это важно.
  5. Здравствуйте. Хочу поделится опытом обновления устройства Cisco Nexus N3K-C3064PQ. Возможно это кому-то будет полезно. Не стал создавать новую тему, здесь вроде как разбирается тема обновлений. Согласно www.cisco.com Cisco сейчас рекомендует релиз 9 ветки 9.3(7). Подробности здесь. Отличие 7 и 9 версии: В официальном руководстве Cisco Nexus 3000 Series NX-OS Software Upgrade and Downgrade Guide, Release 7.x сказано, что обновление осуществляется через версию 6.0.2.U6(3) Согласно инструкции по обновлению Upgrade Nexus 3000 and 3100 NX-OS Software обновление с 6 до 7 версии осуществляется через промежуточную версию 6.0(2)U6(10) А обновление с 6 до 9 версии осуществляется через две промежуточные версии 6.0(2)U6(10) и 7.0(3)I7(9) Другие официальные инструкции: Инструкции Cisco Nexus 3000 Series NX-OS Software Upgrade and Downgrade Guides Cisco Nexus 3000 Series NX-OS Software Upgrade and Downgrade Guide, Release 9.3(x) Cisco Nexus 3000 Series NX-OS Software Upgrade and Downgrade Guide, Release 9.2(x) Cisco Nexus 3000 Series NX-OS Software Upgrade and Downgrade Guide, Release 6.x Практический опыт обновления Обновлять нужно строго последовательно по схеме и никаких проблем не возникнет. Основная сложность - это перейти с 6 ветки на 7. Если скокануть со старой 6 сразу на 7 или 9 без промежуточных обновлений, то может получится кирпич. Кирпичи получаются, когда люди по незнанию начинают обновляться со старых 6 сразу на последние версии, подобно как на привычных системах IOS. Промежуточные версии нужны для того, что в них последовательно обновляется BIOS и микрокод в других платах (не проверенная инфа). Устройство может стать кирпичем, если возникнет сбой при обновлении BIOS. Коммутатор просто не выполнит первичный загрузчик и не загрузится. Начиная с 7 ветки обновление практически безопасное. В процессе обновления флешка может не определяться. Это нормально. Чтобы была видна USB флешка в некоторых случаях нужно ее вынимать при перезагрузке устройства, а в других случаях надо оставлять вставленной при перезагрузке. Если не появляется, то перезагружать нужно без флешки, затем ждать минут пять, потом вставить на минуту, затем вынуть на минуту и опять вставить. Когда загрузится, то нужно вставить, потом вынуть и опять вставить. Cisco позволяет сжимать образы (команда compact). Файл заметно уменьшается, но однако устройство будет дольше грузиться, т.к. файл будет распаковывается при загрузке. Внимание!!! Файл «compact» нужно генерировать каждый раз заного. Сгенерированный под одной версией он может быть несовместимым с другой. Проверка файла на читаемость во время установки отсутствует. Во время операций копирования следите за свободным местом с помощью команды dir. Инструкция по обновлению Алгоритм обновлений 6.0(2)U3(9) 6.0(2)U5(2) 6.0(2)U6(2a) 6.0(2)U6(10) (!!!) 7.0(3)I7(1) 7.0(3)I7(9) (!!!) 9.2(1) 9.2(4) 9.3(7) Подключаемся к коммутатору с помощью стандартного консольного кабеля. По-умолчанию скорость порта 9600. Рекомендуется её повысить до 11500 Проверяем версию Проверяем активированные лицензии Вставляем флешку размером 8-16 ГБ. Если не определяется, то нужно перевключить. Свободно 1,4 ГБайт Копируем все версии 6 ветки на внутреннюю память «bootflash». Эти версии занимают немного и памяти хватит. В дальнейшем в инструкции не будет приводится вывод команды «dir». При каждой операции проверяйте наличие свободного места на внутренней памяти. На внутренней памяти bootflash должны появится все скопированные версии 6-й ветки. Устанавливаем 6.0(2)U3(9) После перезагрузки Устанавливаем 6.0(2)U5(2) После перезагрузки Устанавливаем 6.0(2)U6(2a) После перезагрузки Устанавливаем 6.0(2)U6(10) (!!!) После перезагрузки Удаляем старые образы и копируем новые образы на внутреннюю память Устанавливаем 7.0(3)I7(1) После перезагрузки Удаляем старые образы и копируем новые образы на внутреннюю память Сжимаем следующий образ, чтобы он влез на внутреннюю память. Команда «install all nxos usb1:файл compact» только сжимает файл и больше ничего не делает. Устанавливаем 7.0(3)I7(9) (!!!) После перезагрузки Удаляем старые файлы и сжимаем следующий образ, чтобы он влез на внутреннюю память. Устанавливаем 9.2(1) После перезагрузки NXOS версии 9.2.1 не умеет сжимать образы подветки 9.3.х. Они почему-то получаются меньшего размера. Если их установить такие сжатые версии, то коммутатор не загрузится и нужно будет восстанавливать старую версию. Как видно ниже глючные сжатые версии nxos.9.3.5.bin и nxos.9.3.6.bin имеют меньший размер, чем текущая nxos.9.2.1_compact.bin Для перехода на версию 9.3.х нужно обновится на версию 9.2.4. Врсия 9.2.4 правильно сжимает файлы подветки 9.3.х Удаляем старые файлы и сжимаем следующий образ, чтобы он влез на внутреннюю память. Устанавливаем 9.2(4) После перезагрузки Удаляем старые файлы и сжимаем следующий образ, чтобы он влез на внутреннюю память. Устанавливаем 9.3(7) (последняя) но сперва удостоверяемся, что файл новой версии занимает больше прежней. После перезагрузки Задача выполнена. Как загрузиться при неудачном обновлении? Удерживаем ctrl+L при появлении сообщения и входим в загрузчик
  6. Алгоритм создания сертификата PEM для подписания файла-запроса в РосКомНадзор: 1. Скачать КриптоПро CSP и установить на Windows; 2. Импортировать сертификаты в Windows при помощи КриптоПро CSP. Сертификаты могут предоставлятся в виде файла реестра или токен USB-ключа. При импорте из файла реестра нужно в предварительно файле заменить ID пользователя на актуальный. Узнать его можно с помощью команды «whoami /USER»; 3. Запустить программу P12FromGostCSP последней версии для ГОСТ 2012 и сохранить сертификаты в формате «.pfx». Версия программы для ГОСТ 2001 не работает с новыми сертификатами 2019 года сформированные по ГОСТ 2012 (программа попросту вылетает); 4. Собрать openssl с поддержкой ГОСТ 2012. Проверить поддержку ГОСТа можно командой «openssl ciphers | tr ":" "\n" | grep GOST»; 5. Ввести команду openssl pkcs12 -in file.pfx -out file.pem -nodes -clcerts.
  7. В разделе Работа с ЭЦП с командной строки (бесплатно) есть важная информация.
  8. Алгоритм создания сертификата PEM для подписания файла-запроса в РосКомНадзор: 1. Скачать КриптоПро CSP и установить на Windows; 2. Импортировать сертификаты в Windows при помощи КриптоПро CSP. Сертификаты могут предоставлятся в виде файла реестра или токен USB-ключа. При импорте из файла реестра нужно в предварительно файле заменить ID пользователя на актуальный. Узнать его можно с помощью команды «whoami /USER»; 3. Запустить программу P12FromGostCSP последней версии для ГОСТ 2012 и сохранить сертификаты в формате «.pfx». Версия программы для ГОСТ 2001 не работает с новыми сертификатами 2019 года сформированные по ГОСТ 2012 (программа попросту вылетает); 4. Собрать openssl с поддержкой ГОСТ 2012. Проверить поддержку ГОСТа можно командой «openssl ciphers | tr ":" "\n" | grep GOST»; 5. Ввести команду openssl pkcs12 -in file.pfx -out file.pem -nodes -clcerts.
  9. SergKz, эта проблема с Centos вообще не связана. Проблема с пропуском GRE пакетов в Linux возникла в определенной версии ядра linux (точной информацией не располагаю). Начиная с версии ядра 4.10.11-1 и выше проблема устранена.
  10. Диоген жил в глиняном сосуде, а мне мало 62,5 квадратных метров

  11. Здравствуйте, друзья! Я хочу попросить помощи в следующей ситуации! У меня есть сервер: CPU Intel® Xeon® E5320 @ 1.86GHz 2шт x 4 ядра Мат. плата Intel S5000PSL 2 встроенных сетевых адаптера Intel 82563EB Внешние сетевые адаптеры Intel 82541, Intel 82544, HP BCM5706 (2 порта). На маршрутизаторе используется 2 сетевые карты. Одна смотрит в сторону пограничного маршрутизатора, вторая - в сторону клиентов. В примере указано больше сетевых адаптеров, т.к. я тестировал проблему в различных комбинациях сетевых интерфейсов, но нужно два сетевых интерфейса. uname -a Linux localhost 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux __________________________________________ Intel 82563EB driver: e1000e version: 3.2.6-k firmware-version: 1.0-0 [root@localhost ~]# ethtool -c enp4s0f0 Coalesce parameters for enp4s0f0: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 3 rx-frames: 0 rx-usecs-irq: 0 rx-frames-irq: 0 tx-usecs: 0 tx-frames: 0 tx-usecs-irq: 0 tx-frames-irq: 0 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 0 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0 __________________________________________ Intel 82541, Intel 82544 driver: e1000 version: 7.3.21-k8-NAPI [root@localhost ~]# ethtool -c enp5s1 Coalesce parameters for enp5s1: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 0 rx-frames: 0 rx-usecs-irq: 0 rx-frames-irq: 0 tx-usecs: 0 tx-frames: 0 tx-usecs-irq: 0 tx-frames-irq: 0 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 0 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0 __________________________________________ HP BCM5706 driver: bnx2 version: 2.2.6 firmware-version: bc 1.9.6 [root@a-gw ndu]# ethtool -c net1 Coalesce parameters for net1: Adaptive RX: off TX: off stats-block-usecs: 999936 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 18 rx-frames: 12 rx-usecs-irq: 18 rx-frames-irq: 2 tx-usecs: 80 tx-frames: 20 tx-usecs-irq: 18 tx-frames-irq: 2 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 0 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0 Я провожу стресс тест на количество пропускаемых пакетов сетевой картой. Входящие пакеты любым сетевым адаптером равномерно распределяются между ядрами при любой нагрузке. Исходящие пакеты равномерно распределяются между ядрами только при нагрузке менее 500 тыс. пакетов/сек. Если нагрузка исходящего трафика превышает порог 500 тыс. пакетов/сек, то одно из ядер забивается на 100%. В этом случае на этой сетевой карте затормаживается обработка пакетов, пока нагрузка не упадет. Сетевые карты проверял в различных комбинациях. Кольцевые буферы выставлял на максимум - результат не меняется. Я еще раз повторю, что ядро забивается в случае отправки пакетов, а не приема. Я обнаружил, что проблема возникает во всех случаях, кроме случае прохождения пакета пакет-->внешний сетевой адаптер-->OS Linux-->внутренний сетевой адаптер. Однако практически во всех других комбинациях наблюдается эта проблема. Почему почти? Потому-что я не могу досконально утверждать, что все комбинации проверял, ведь сетевая карта HP BCM5706 используется под нагрузкой. Вот пример проблемной ситуации Every 1.0s: cat /proc/softirqs localhost: Mon Jun 19 13:05:31 2017 CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 HI: 0 1 0 4 0 0 0 0 TIMER: 18766 17311 21781 36072 18429 14728 14850 17759 NET_TX: 218 1208 250 114181 720 257 243 511 NET_RX: 3611784 3595720 3608193 3697658 3542628 3540516 3553108 3531652 BLOCK: 2318 1691 1652 1881 1995 1583 2107 2025 IRQ_POLL: 0 0 0 0 0 0 0 0 TASKLET: 2601 2669 2600 2696 2635 2656 2606 2660 SCHED: 15465 13632 14378 16157 14260 10967 11437 13048 HRTIMER: 0 0 0 0 0 0 0 0 RCU: 9876 9856 15880 17163 10356 8367 8260 12001 Every 1.0s: cat /proc/interrupts| grep enp localhost: Mon Jun 19 13:06:50 2017 25: 2126060 2090503 2151377 2113891 2125791 2150314 2128414 2140061 IO-APIC 1-fasteoi enp5s1 (Счётчики в момент ступора ядра останавливаются) 26: 6765 6982 6726 6883 6968 6856 6731 6898 PCI-MSI 2097152-edge enp4s0f0 28: 1251194 1285380 1225995 1262559 1250625 1226919 1248457 1236982 PCI-MSI 2099200-edge enp4s0f1 (Счётчики в момент ступора ядра останавливаются) ATOP PRC | sys 3.01s | user 0.02s | | | #proc 146 | #trun 2 | #tslpi 134 | | #tslpu 0 | #zombie 0 | clones 10 | | | #exit 10 | CPU | sys 1% | user 1% | | irq 100% | | idle 698% | wait 2% | | | steal 0% | guest 0% | curf 1.87GHz | | curscal ?% | cpu | sys 0% | user 0% | | irq 100% | | idle 0% | cpu003 w 0% | | | steal 0% | guest 0% | curf 1.87GHz | | curscal ?% | cpu | sys 0% | user 1% | | irq 0% | | idle 99% | cpu000 w 0% | | | steal 0% | guest 0% | curf 1.87GHz | | curscal ?% | cpu | sys 0% | user 0% | | irq 0% | | idle 100% | cpu001 w 0% | | | steal 0% | guest 0% | curf 1.87GHz | | curscal ?% | cpu | sys 0% | user 0% | | irq 0% | | idle 98% | cpu004 w 1% | | | steal 0% | guest 0% | curf 1.87GHz | | curscal ?% | cpu | sys 0% | user 0% | | irq 0% | | idle 100% | cpu006 w 0% | | | steal 0% | guest 0% | curf 1.87GHz | | curscal ?% | CPL | avg1 0.80 | | avg5 0.42 | avg15 0.33 | | | | csw 413 | | intr 1446 | | | numcpu 8 | | MEM | tot 3.9G | free 3.7G | cache 48.4M | dirty 0.1M | buff 15.4M | slab 60.0M | slrec 36.0M | shmem 0.6M | shrss 0.0M | shswp 0.0M | vmbal 0.0M | | hptot 0.0M | hpuse 0.0M | SWP | tot 16.0G | free 16.0G | | | | | | | | | | vmcom 38.4M | | vmlim 17.9G | MDD | md1 | busy 0% | | read 0 | write 3 | | KiB/r 0 | KiB/w 4 | MBr/s 0.0 | | MBw/s 0.0 | avq 0.00 | | avio 0.00 ms | DSK | sda | busy 4% | | read 0 | write 8 | | KiB/r 0 | KiB/w 2 | MBr/s 0.0 | | MBw/s 0.0 | avq 1.10 | | avio 15.9 ms | DSK | sdb | busy 4% | | read 0 | write 8 | | KiB/r 0 | KiB/w 2 | MBr/s 0.0 | | MBw/s 0.0 | avq 1.13 | | avio 15.8 ms | NET | transport | tcpi 4 | tcpo 4 | udpi 0 | | udpo 0 | tcpao 0 | tcppo 0 | tcprs 0 | tcpie 0 | tcpor 0 | | udpnp 0 | udpie 0 | NET | network | ipi 1053809 | | ipo 1053800 | ipfrw 1054e3 | | deliv 12 | | | | | icmpi 0 | | icmpo 0 | NET | enp4s0f 8% | pcki 526904 | pcko 526887 | | sp 1000 Mbps | si 89 Mbps | so 89 Mbps | | coll 0 | mlti 0 | erri 0 | erro 0 | drpi 0 | drpo 0 | NET | enp5s1 8% | pcki 526912 | pcko 526857 | | sp 1000 Mbps | si 84 Mbps | so 84 Mbps | | coll 0 | mlti 0 | erri 0 | erro 0 | drpi 0 | drpo 0 | NET | enp4s0f 0% | pcki 33 | pcko 4 | | sp 100 Mbps | si 7 Kbps | so 5 Kbps | | coll 0 | mlti 0 | erri 0 | erro 0 | drpi 0 | drpo 0 | Прикреплено вложение вывода htop Вопросы: Почему ОС Linux в случае отправки пакетов при превышении указанного порога начинает задействовать только одно ядро (есть незначительная загрузка других ядер)? Может достигнута пропускная способность какой-либо шины материнской платы? Почему в момент перегрузки останавливаются счетчики /proc/interrupts ? Если не сможем разобраться, то есть другой вариант - использовать сервер HP G5 ntel® Xeon® CPU X5260 @ 3.33GHz со встроенными адаптерами BCM5708. На нем этой проблемы нет.
  12. В этой статье написано как правильно создать VPN (в частности pptp) c использованием masquerade (NAT)
  13. Друзья, хочу поделиться опытом как подружили D-link 3526 и Cisco 2960 в одном MSTP кольце. Первый раз, когда начали стыковать два различных производителя мы столкнулись спроблемой (цитата выше). Было это около 8 месяцев назад. Проблема была выявлена. Она заключалась в том, что коммутаторы D-link пропускают пакеты "Cisco PVST" (01-00-0C-CC-CC-CD 0x0802 Cisco Shared Spanning Tree Protocol Address). Тем самм к нам в сеть вклинивались абонентское оборудование cisco и наша сеть сходила с ума. Решение достаточно простое. mac access-list extended FilterPVST deny any host 0100.0ccc.cccd permit any any Уже пол года вместе работают коммутаторы CISCO 2960 и DES-3526. Ни одной аварии не было. Проблема как подружить D-link и CISCO мы решили. Возможно комуто эта информация будет полезной
  14. Пытались объеденить кольцо MSTP DES-3526 (Firmware: Build 5.01.B43) и CISCO 3600. Настройки стандартные. 2 часа поработало. Затем один DES самопроизвольно сменил значение магистрального порта с RSTP на STP. После этого произошол сбой и кольцо не могло толком собраться. Вернуло сеть к жизни перезагрузка DES-3526. После разъеденения все работает без нареканий. Вывод: MSTP D-link и cisco совместимы в теории. На практике будут проявляться недокументированые проблемы. Комментарий от 16.11.2012 Данная проблема решена. Решение http://forum.nag.ru/forum/index.php?showtopic=66179&view=findpost&p=774838