dmitry_

как с одним, так и с 2-мя картина одинаковая, блоки питания тоже одинаковые, отличаются только серийным номером

Есть аналогичный свич 4500х, и спустя всего процесса загрузки пишет Если сидеть в rommon железка не выключается, получается проблема в IOS? Железка: Rom Monitor (P) Version 15.0(1r)SG11 CPU Rev: 2.2, Board Rev: 9, Board Type: 108 CPLD Mobat Rev: 2.0x549a.0x59a4 Chassis: WS-C4500X-16 загружаю IOS: cat4500e-universal.SPA.03.04.02.SG.151-2.SG2.bin Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSAL-M), Version 03.04.02.SG RELEASE SOFTWARE (fc1) Блоки питания: C4KX-PWR-750AC-R-V01 EMERSON 7001591-J500 REV.AB По цвету блоки питания с вентиляторами совпадают (все красные) Подскажите, в чем может быть проблема?

Это ограничение данной модели свича, мы пару лет тоже думали использовать 3326GSR как L3 свич, но после экспериментов и переписки на форуме Dlink-a, поняли, что это плохая мысль. Используем его только как L2 свич, и то если держать несколько VLAN-ов с включенным igmp_snooping - то TV будет работать только в одном, тот из которого первыми канал запросили смотреть.

никак, DLink это называет не багом, а ограничением в данной серии :) трафика будет больше, соответственно при популярном сервисе IPTV ваша сеть загнется (это же и минус решения vlan на абонента) ps. железка которая будет отдавать каналы по http, должна быть очень серьезной. к примеру один HD канал ~ 10Мбит/с, 100 смотрящих абонентов сделают вам уже 1Гбит/с

У данной железки есть такой артефакт, который проявляется при просмотре IPTV в нескольких виланах (при схеме IPTV без ISM вилана) с включенным igmp_snooping на виланах, проявляется он тем, что каждый канал будет показывать только в одном вилане (который первый на канал подписался). Плюс непонятное увеличение CPU utilisation в таких схемах. Используем на железке только 1 вилан с включенным igmp снупингом. В остальном претензий нет.

кол-во прерываний от сетевой карты, настройки передаются драйверу, на худой момент всегда можно применить RPS

асики форвардят трафик друг другу через fabric Продолжу тему про WS-X6708-10GE + DFC3CXL. Это что получается если порты 1,4,5,7 - 0-я шина (20G), 2,3,6,8 - 1-я шина (20G), пусть пакет идет с 1-го порта на 2-й, то он будет утилизировать Fabric channel 20G как 0-й шины так и 1-й шины? Зачем тогда канал между Fabric ASIC-ами (с DFC между ними)? Кто-нибудь опровергните это или действительно так работает? ps. мысль покупки платы WS-X6716-10G и проливание трафика внутри платы тогда отпадает

мы пошли по 2-му пути

А по объему хранилища где лежик кэш видео, как оно растет и примерные его объемы? если трафику в сумме к примеру пару гигабит, то зарулить весь ютубовский трафик (по их AS -> ipset dst) на какую-нибудь кэширующую тачку, то какое предположительно по объему нужно хранилище и по производительности сама машина?

судя по всему каждый следующий destination добавляется к следующему ядру, у нас 4-ядра и 2 destination в ipt_netflow, видно что работает на 2-х ядрах cpu# stat: <search found new, trunc frag alloc maxflows>, sock: <ok fail cberr, bytes>, traffic: <pkt, bytes>, drop: <pkt, bytes> Total stat: 375512613636 2276478461299 95344396434, 0 0 0 0, sock: 2059235300 86 1357198, 9084524023 K, traffic: 2371822857733, 1719003881 MB, drop: 0, 0 K cpu0 stat: 93834663813 568756742860 23896162193, 0 0 0 0, sock: 1483755120 0 1351878, 2121306148 K, traffic: 592652905053, 429723699 MB, drop: 0, 0 K cpu1 stat: 94050266069 569999918215 23796398364, 0 0 0 0, sock: 575480180 86 5320, 6963217875 K, traffic: 593796316579, 429915273 MB, drop: 0, 0 K cpu2 stat: 93824651652 569013481714 23885601122, 0 0 0 0, sock: 0 0 0, 0 K, traffic: 592899082836, 429910613 MB, drop: 0, 0 K cpu3 stat: 93803032102 568708318510 23766234755, 0 0 0 0, sock: 0 0 0, 0 K, traffic: 592474553265, 429454295 MB, drop: 0, 0 K

NAT? Shaping? или простой роутинг?

Несколько постов выше писали(в том числе и я): Двухпроцессорные платформы не дают выигрыша(даже хуже). Некоторые пишут HT вредит системе. Мои результаты не подтверждают это(хотя я в соседней теме написал, что тоже столкнулся с проблемами). Но даже если HT дает 1,5 раза прирост, то вторая платформа не очень выглядит привлекательной. Возможно вам надо оптимизировать софт - на i7-3770 можно вытянуть более 1Мpps и 5Гбит\с(в сумме всех if). Серверные платформы не очень удобны для разгона, а необходимую надежность, при разгоне, только вы сможете оценить. софт крутится на всех шейперах одинаковый, и оптимизировать его не вижу смысла, что скорее всего придется делать то это разгонять проц E5620 или покупать еще одну жельзяку, уже думаю на i7

выложу свои наблюдения по этому поводу имеем 2 разновидности серверов, все на платформах супермикро. на первой платформе стоит проц Intel® Xeon® CPU E31220 @ 3.10GHz - 4 ядра, сетевухи: 2 встроенные e1000e и Intel 82576 2х портовая, из них делаются 2 bond, один на вход, другой на выход. Трафик на каждом bond: ~ 150kpps in/out, 1.33Gb/s in и 600Mb/s out в это время видим загрузку CPUs следующую на второй платформе стоит проц Intel® Xeon® CPU E5620 @ 2.40GHz - 8 ядер, с сетевухами картина идентичная первой Трафик на каждом bond: ~ 145kpps in, 111kpps out, 1.25Gb/s in и 480Mb/s out в это время видим загрузку CPUs следующую На обоих машинах крутятся, nat, htb shaping на in/policing на out, и самописный демон для снятия conntrack - видно что 1 камень загружен чуть больше. Можно сделать вывод что 4-х ядерный проц с большей тактовой частотой справляется лучше с задачами, чем более ядерный, но меньшей тактовой частотой. У меня были мысли разогнать Xeon® CPU E5620 @ 2.40GHz, кто-нибудь таким занимался и стоит ли вообще гнать CPU в таких решениях, не выйдет ли это боком? 2-я платформа покупалась с надеждой, что вытянет честные 2Gb/s, но не тут то было, теперь думаю или разогнать CPU или купить 2-проц, платформа позволяет устанавливать 2

rate и ceil случаем не 2000mbit у корневого класса?

используя 3-ю машину, которая весь трафик (внутренний) разбалансирует на НАТ машины (к примеру через iproute2)