dadv: (chuck)

Сегодня в пол-второго ночи одновременно испортились оба блока питания PWR-2700-AC в шасси Cisco 7606.
чудеса )

dadv: (chuck)

Поднял новый канал, передал отделу мониторинга техданные для включения канала в схему. А они потом переспрашивают: "какая-какая максимальная скорость? а почему железка по SNMP другое говорит"?

Полез в конфиг, и правда, bandwidth другой указал. Пытаюсь исправиться:

(config)#interface Port-channel1
(config-if)#bandwidth 20000000
                             ^
% Invalid input detected at '^' marker.

(config-if)#bandwidth ?
  <1-10000000>  Bandwidth in kilobits
  inherit       Specify how bandwidth is inherited

Вот так. Нельзя на Cisco 7606 IOS 12.2(33)SRD4 на канале из двух 10-гигабитных линков прописать bandwidth 20000000.

dadv: (Default)

Перенос ip tcp adjust-mss с border-роутера Cisco 7604 на BRAS-ы мгновенно уменьшил загрузку CPU у 7604 в четыре раза, с 60% до 15% (fabric utilization не поменялась).

BRAS-ы 72xx и 7301 - софтовые роутеры, всё равно разбирают PPPoE-фреймы и перепаковывают данные, им дополнительная корректировка MSS нагрузку если и увеличила, то в пределах погрешности измерений. А на mpd5 корректировка MSS уже была включена.

А вот разница между аппаратным роутингом через ASIC в 7604 и process switching хотя бы только для пакетов TCP SYN на нескольких гигабитах трафика оказалась драматической.

dadv: (stopstupid)

#show spanning-tree interface Gi4/13

Mst Instance        Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
MST0                Desg BLK 200000    128.781  Dispute P2p

На сайте cisco.com описан Dispute Mechanism, но причин блокирования порта этим механизмом приведено только две: однонаправленный канал или некорректно настроенный EtherChannel.

В моём случае временное включение spanning-tree bpdufilter на этом транке приводило к разблокировнию порта и трафик начинал ходить нормально, да и портканалом тут не пахло. Причина оказалась банальна - на свиче с другой стороны линка был включен RSTP. Переключение в MSTP на той стороне проблему убрало полностью, spanning-tree на этой стороне перестал блокировать порт.

NSF

2011-04-26 22:12
dadv: (Default)

Ночью с коллегами заставили работать WS-SUP720-3BXL в режиме Hot Standby cо старым WS-SUP720-3B (проапгрейженным до 3BXL путем установки WS-F6K-PFC3BXL и дополнительной памяти) в шасси 7604:

#show module 
Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
  1    2  Supervisor Engine 720 (Active)         WS-SUP720-3B       SADXXXXXXXX
  2    2  Supervisor Engine 720 (Hot)            WS-SUP720-3BXL     SADYYYYYYYY
<skip>

Заодно включили Cisco nonstop forwarding (NSF) для протоколов маршрутизации, включая BGP. На eBGP-линке с Евротелом NSF включился автоматически, на линке с местным ТТК нет и обращение по e-mail в поддержку ничего не дало: "нет технической возможности".

Днём отсыпался.

dadv: (Default)

Первый стресс-тест mpd-5.5/PPPoE под FreeBSD 8.2-STABLE/amd64 на реальной нагрузке.

Система настроена решать одну задачу - терминировать пользовательские сессии PPPoE с AAA через RADIUS, с шейпингом трафика и анонсированием абонентских IP-адресов в ядро сети через OSPF. На машине нет NAT (адреса реальные), нет netflow (собирается на другом роутере), нет BGP.

В час наибольшей нагрузки отмечено:

  • 1812 сессий PPPoE;
  • средняя нагрузка по ядрам процессора 2% user time / 88% (system time + interrupts) (CPU0: 2+90, CPU1: 2+89, CPU2: 2+90, CPU3: 3+86);
  • 1184.9Mbit/s трафика в сторону клиентов и 830.9Mbit/s от них (итого 2015.8Mbit/s);
  • 549.8Kpps: на интерфейсе lagg0 136.2Kpps in, 120.3Kpps out и на lagg1 139.0Kpps in, 154.3Kpps out;
  • до 102K прерываний в секунду (device polling не использовался);
  • использовано памяти:

    Mem: 101M Active, 41M Inact, 486M Wired, 1644K Cache, 138M Buf, 3314M Free

  • в среднем на одну PPPoE-сессию приходилось 654.1Kbit/s трафика на вход и 434.2Kbit/s на выход.

То есть, на каждый процент загрузки CPU пришлось по 20 сессий.
Система продолжала быть отзывчивой на ssh так же, как и без нагрузки.

Железо:

  • SuperMicro SuperServer 5016T-MTFB с двумя гигабитными интегрированными сетевыми Intel 82574L (драйвер em) и платой IPMI 2.0 с выделенным портом 100M;
  • дополнительная двухпортовая сетевая карта Intel 82576 (драйвер igb);
  • процессор Intel(R) Xeon(R) CPU E5507 @ 2.27GHz (четыре ядра, гипертрединг отключен в BIOS Setup, 4M Cache, 4.80 GT/s Intel® QPI);
  • 4GB памяти ECC;
  • в качестве загрузочного носителя SSD 64GB (KINGSTON SNV425S264GB), при загрузке монтируется только для чтения (система собрана в виде NanoBSD, без свопа).

Общая стоимость железа около 60 тысяч рублей (всё железо новое).

Сетевые em0 и em1 объединены в lagg0, на нём есть IP-адрес и нет vlan-ов, это аплинк. Сетевые igb0 и igb1 объединены в lagg1, на котором нет IP, зато создано 596 vlan-ов, каждый из которых несет PPPoE-трафик пользователей. Шейпинг выполнен через ipfw/dummynet - на каждого подключенного пользователя dummynet динамически (pipe ... mask) создает по две индивидуальных трубы, на вход и на выход, в соответствии с тарифом пользователя. Весь шейпинг делается двумя правилами ipfw, список правил не растет при росте количества абонентов:

pipe tablearg ip from any to table(11) in
pipe tablearg ip from table(12) to any in


Для сравнения: бывшая в употреблении Cisco 7201 на usedcisco.ru стоит $11400 $10900 (примерно в 5.5 раз дороже), срок поставки 3 недели. На этой же задаче и на этих же пользователях обрабатывает около 10 сессий на процент загрузки CPU (то есть, вдвое меньше), причем при высоких загрузках вносит большие задержки и сама с трудом управляется по telnet. Поэтому приходится ограничивать количество сессий на ней (не более 700), чтобы держать нагрузку в пределах 75%. Стоит отметить, что при маленьких нагрузках (ближе к нулю) количество сессий на процент загрузки CPU у обоих систем растет в разы.

Зато Cisco - продукт, и умеет гораздо больше, например, ISG. А FreeBSD - конструктор, и требует существенного тюнинга. Про тюнинг как-нибудь в другой раз.

Update: для проверки провёл второй тест на FreeBSD с целью удержать загрузку в пределах 75%. При прочих равных условиях для этого оказалось нужным ограничить количество сессий PPPoE в 1500. Подтверждается прямая пропорциональность: 1800/0.9=1500/0.75=2000, что даёт нам прогноз стопроцентной загрузки при 2000 сессиях.

На деле у меня пока достаточно железок, чтобы держать нагрузку в пике на уровне 35% :-)

dadv: (Default)
Всё-таки есть свои плюсы в тихих воскресных дежурствах.

Наконец нашлось время настроить схему с двумя Cisco Catalyst 3750G:
соединил их между собой ISL-транком и настроил каждый на прием
двух абонентских транков 802.1Q и передачу их через double vlan
поверх этого ISL-транка, как и рекомендовано в талмуде.
Всё заработало с первого раза - пропустил два разных vlan-а с тегом 15 через каталисты,
хосты внутри одного абонентского vlan-а друг друга видят, а хостов в другом
таком же vlan-е - нет.

Ещё эти каталисты умеют туннелировать STP/VTP/CDP через себя - приняв с абонентского
vlan-а пакет, скажем, STP, оно меняет ему MAC-адрес назначения на специальный мультикастный,
навешивает нужный тег и пересылает на удаленную сторону как обычные данные, а там снимает
внешний тег и доставляет в абонентский порт.

Скоро мне надо будет пропустить через такие железки четыре или пять наборов vlan-ов,
каждый с независимой нумерацией внутри набора, как раз пригодится.

В процессе тестирования сдох игравший роль абонентского свича
старенький D-Link DES-1008 - один из портов его стал показывать линк при отсутствии
в нём кабеля и, судя по показаниям сниффера, возвращать все принимаемые
из других портов пакеты в них же, эффективно блокируя работу сегмента.
Может быть, надо было заранее отключить PoE на каталистах.

Profile

dadv: (Default)
Choose your future

June 2017

M T W T F S S
   1234
56 7891011
12131415161718
19202122232425
2627282930  

Syndicate

RSS Atom

Tags

Style Credit

Powered by Dreamwidth Studios