[UglyAdmin]

Добрый день, коллеги.

 

Кто в курсе внутреннего устройства 6500/7600 платформы?

 

Проблема в следующем: на анализатор никак не выдаётся больше примерно 13,5 гигабит трафика, хоть входящий+исходящий превышают эту цифру.

Пробовал по-всякому: и в пределах одной 6708; и источники на 6704, приёмники на 6708; и источники на 6708, приёмники на 6704; и по разным каналам разносил и в пределах одного - всё равно одинаково, примерно 13,5 гиг выдаётся, остальное дропается.

Причём трафик во всех случаях идёт через RSP720 (где и дропается судя по "sh platform hardware central-rewrite drop"), хотя я надеялся что при размещении источников и приёмников на 6708 всё замкнётся на ней.

 

Конфигурация такова: 2 порта 10G - источники трафика, Port-channel из двух портов 10G - получатеть трафика, сессия локальная.

[UglyAdmin]

Кстати, дополнительная непонятка: в канале занимается ДВОЙНАЯ полоса ingress на каждый порт-источник трафика и ДВОЙНАЯ полоса egress на каждый порт - получатель трафика. Примерно вот так:

#sh plat hard cap fab
Switch Fabric Resources
  Bus utilization: current: 31%, peak was 36% at 17:57:15 MSK Sun Mar 13 2011
  Fabric utilization:     Ingress                    Egress
    Module  Chanl  Speed  rate  peak                 rate  peak
    4       0        20G    0%    0%                  65%   78% @17:57 19Mar11
    4       1        20G    0%    0%                  65%   76% @17:35 19Mar11

65% на 4 модуле по каждому каналу - это 2 порта по 6,5Гбит. =)

[Magnum72]

Кстати, дополнительная непонятка: в канале занимается ДВОЙНАЯ полоса ingress на каждый порт-источник трафика и ДВОЙНАЯ полоса egress на каждый порт - получатель трафика. Примерно вот так:

#sh plat hard cap fab
Switch Fabric Resources
  Bus utilization: current: 31%, peak was 36% at 17:57:15 MSK Sun Mar 13 2011
  Fabric utilization:     Ingress                    Egress
    Module  Chanl  Speed  rate  peak                 rate  peak
    4       0        20G    0%    0%                  65%   78% @17:57 19Mar11
    4       1        20G    0%    0%                  65%   76% @17:35 19Mar11

65% на 4 модуле по каждому каналу - это 2 порта по 6,5Гбит. =)

Мы тоже с этим маялись, В понедельник напомни точно скажу как выкрутились.

[Butch3r]

Всем напомните только :)

[rps]

Что в ingress двойная полоса - не удивительно. Если оба получателя (и нормальный получатель, и span) находятся на одном канале - то и по двойной egress не удивителен. Что за трафик вообще, unicast или mcast? В какой моде репликации работает шасси - egress или ingress? Удивляет 30% загрузки bus, если у вас там в шасси старые карты типа 6148 есть - то точно будет ingress replication. В каком режиме работают карты по "sh platform hardware capacity system"?

Если есть возможность - то, кмк, правильно вешать источники и получателей на одну 6708, причём в виде канал1(источник(асик1)-получатель(асик2))-канал2(источник(асик1)-получатель(асик2)).

 

[UglyAdmin]

Что за трафик вообще, unicast или mcast?

Трафик unicast.

В какой моде репликации работает шасси - egress или ingress?

Понятия не имею. :)

если у вас там в шасси старые карты типа 6148

Старых плат нет, все 67хх, но с CFC, кроме 6708:

#sh platform hardware capacity system
System Resources
  PFC operating mode: PFC3CXL
  Supervisor redundancy mode: administratively sso, operationally sso
  Switching resources: Module   Part number               Series      CEF mode
                       1        WS-X6748-GE-TX            CEF720           CEF
                       2        WS-X6708-10GE             CEF720          dCEF
                       3        WS-X6724-SFP              CEF720           CEF
                       4        WS-X6704-10GE             CEF720           CEF
                       5        RSP720-3CXL-GE        supervisor           CEF
                       6        RSP720-3CXL-GE        supervisor           CEF

Если есть возможность - то, кмк, правильно вешать источники и получателей на одну 6708, причём в виде канал1(источник(асик1)-получатель(асик2))-канал2(источник(асик1)-получатель(асик2)).

Пробовал, вешал источники на 4 и 6 порт, получатели на 2 и 3, всё равно отражение трафика происходит на RSP720.

[rps]

sh platform hardware capacity multicast

Судя по модулям, mode должен быть egress, но лучше бы проверить.

Пробовал, вешал источники на 4 и 6 порт, получатели на 2 и 3, всё равно отражение трафика происходит на RSP720.

Ну так получатели получились на одном асике, да ещё и с одним истошником на одном канале.

Попробуйте истошники в 1,2 и получатели на 5,6. Или просто одного из получателей перенести на 5 или 7.

 

[UglyAdmin]

sh platform hardware capacity multicast

Судя по модулям, mode должен быть egress, но лучше бы проверить.

Да, egress.

Попробуйте истошники в 1,2 и получатели на 5,6. Или просто одного из получателей перенести на 5 или 7.

Ок, попробую.

[YaroslavR]

На 6708 архитектура достаточно нетривиальная... Порты объединены в пары каналами 16G следующим образом - 1,4; 2,3; 5,7; 6,8.

 

На плате 2 асика - первая и третья пара (1, 4, 5 и 7 порты) приходят на один асик, вторая и четвертая (2, 3, 6, 8) - на другой. Между асиками трафик ходит через фабрику.

 

Соответственно попробуйте источники и получатели держать в рамках одного асика.

[Telesis]

Поставьте "Делитель оптический" и не насилуйте фабрику.

[UglyAdmin]

Поставьте "Делитель оптический" и не насилуйте фабрику.

Как Вы себе это представляете?

Трафик юникаст (интернет), отражать надо как входящий, так и исходящий, с двух портов тоже в два порта...

[alks]

кстати насчет делителя - интересная мысль!

 

берем порт 10Г - это два волокна

вешаем на каждое волокно по делителю и получаем два волокна с входящим трафиком - один на длине волны 1310 второй на 1550

вот только что дальше с ним делать?

[rus-p]

На 6708 архитектура достаточно нетривиальная... Порты объединены в пары каналами 16G следующим образом - 1,4; 2,3; 5,7; 6,8.

 

На плате 2 асика - первая и третья пара (1, 4, 5 и 7 порты) приходят на один асик, вторая и четвертая (2, 3, 6, 8) - на другой. Между асиками трафик ходит через фабрику.

 

Соответственно попробуйте источники и получатели держать в рамках одного асика.

И тоды уперетесь в эти самые каналы 16Г на егресе, да за вычетом оверхедов хрен редьки не слаще )

rps уже предложил вариант, если и он не поможет, то ой

 

Почитайте циску - http://www.cisco.com/en/US/docs/routers/76...guide/span.html

Там и про двойной лоад и прочее.

Есть некоторые ограничения и на egress-mcast.

Если я правильно понял, span заработает, только mсast трафик отливать не будет.

 

[Telesis]

кстати насчет делителя - интересная мысль!

 

берем порт 10Г - это два волокна

вешаем на каждое волокно по делителю и получаем два волокна с входящим трафиком - один на длине волны 1310 второй на 1550

вот только что дальше с ним делать?

Далее в коммутатор L2. Статик мак... и т.д.....

[rps]

Далее наверное будет оборудование органов ;)

[secandr]

нам как решение предлагали DPI - и трафик пожать красиво можно и Nx10G отмирорить на скорости потока... только стоит такая железка неприлично :)

[UglyAdmin]

А вот так http://boombax.blogspot.com/2011/03/cisco.html кто-нибудь пробовал?

Как оно по сравнению со SPAN'ом?

[Stak]

А вот так http://boombax.blogs...1/03/cisco.html кто-нибудь пробовал?

Как оно по сравнению со SPAN'ом?

 

Работает. Безопасники в экстазе. Но есть ряд моментов по совместимости с другими фичами , включенными на интерфейсе.

Например, PBR. Насколько я помню, при определённом размере АЦЛ для захвата, железка свалилась на софтверный форвардинг.

 

Мы такую штуку для выборочного СОРМ сделали, но из-за п.1 на отдельной 76 коробке.

Щас обдумываем вариант замены этой отдельной коробки на специализированный дивайс типа такого : http://www.vssmonitoring.com/products/product_finder.asp?product_category=DTCS&family_name=v24 , с захватом на него трафика через сплиттеры с 10Г интерфейсов. существенно дешевле получается. И даже потенциально не влияет на трафик.

[Stak]

Для истории (ответ от ТАСа):

"при использовании трех фич в одном направлении (RACL, PBR, VACL) система вынуждена выполнить merge ACL-ей и это приводит к взрывообразному потреблению TCAM.

При 2-х фичах merge не нужен, т.к. на 720-м два банка TCAM и соотв.ACL'и кладутся системой в разные банки. (При merge, кстати, используется только один банк TCAM).

 

Т.о. на текущий момент видятся следующие решения:

 

 

1) не использовать VACL capture или по кр. мере не использовать в ACL vlan access-map номера портов TCP/UDP

 

2) изменить дизайн так, чтобы на одном L3-интерфейсе было максимум 2 фичи в одном направлении

 

3) попробовать соптимизировать используемые в RACL и PBR ACL'и

 

"

[alks]

Щас обдумываем вариант замены этой отдельной коробки на специализированный дивайс типа такого : http://www.vssmonitoring.com/products/product_finder.asp?product_category=DTCS&family_name=v24 , с захватом на него трафика через сплиттеры с 10Г интерфейсов. существенно дешевле получается. И даже потенциально не влияет на трафик.

 

цена вопроса?

[Stak]

порядка 30 килобаксов за коробку с 4мя интерфейсами, +по 3 за каждый доп.интерфейс (активируется лицензиями), не считая трансиверов.

Но это если тесты подтвердят заявленный в даташите функционал.

[UglyAdmin]

На 6708 архитектура достаточно нетривиальная... Порты объединены в пары каналами 16G следующим образом - 1,4; 2,3; 5,7; 6,8.

 

На плате 2 асика - первая и третья пара (1, 4, 5 и 7 порты) приходят на один асик, вторая и четвертая (2, 3, 6, 8) - на другой. Между асиками трафик ходит через фабрику.

 

Соответственно попробуйте источники и получатели держать в рамках одного асика.

Включил источники в 6 и 8 порты, получатели во 2 и 3.

Трафик всё равно идёт через RSP720, где и дропается.

Я не понял, PFC3C-XL, который на 6708 установлен по-умолчанию, не умеет SPAN?

 

VACL - это хорошо, но в данном случае не подходит, потому что трафик в один 10G порт не помещается, а в etherchannel его направить нельзя. Зато освободил один local SPAN и направляю трафик не в Etherchannel, а весь RX в один порт, весь TX - в другой.

Удвоение egress сразу прекратилось, но всё равно больше ~13,5 гигабит не пролазит. :(

[UglyAdmin]

Раскурил устройство 6708, буду завтра переконфигурировать опять.

Не такое это простое дело - 20G трафика отразить. :(

[Telesis]

Раскурил устройство 6708, буду завтра переконфигурировать опять.

Не такое это простое дело - 20G трафика отразить. :(

это только начало, дальше будет 30 и т.д.

[UglyAdmin]

Не такое это простое дело - 20G трафика отразить. :(

это только начало, дальше будет 30 и т.д.

Добрый ты, дедушка, хороший! Приходи к нам на ёлку...