[Gunner]

Есть портченел между DGS3627 и MES3124 из 2х гигабитных каналов. Задача отследить почему разваливается LACP, возможно ли простым зеркалированием отследить только LACР пакеты(на DGS3627 есть только 1 свободный порт). Какой порт зеркалировать ? DGS3627 не может зеркалировать LACP.

[orlik]

может не надо мониторить , достаточно дебаг включить ?

[pfexec]

Есть портченел между DGS3627 и MES3124 из 2х гигабитных каналов. Задача отследить почему разваливается LACP, возможно ли простым зеркалированием отследить только LACР пакеты(на DGS3627 есть только 1 свободный порт). Какой порт зеркалировать ? DGS3627 не может зеркалировать LACP.

посмотрите на загрузку процессора обоих. может быть пики загрузки совпадают с разносом лацпа. попробуйте выключить лацп, если проблема исчезнет значит дело в lacp, если нет, то надо понаблюдать за уровнем сигнала (без ddm'а на сфпшках не выйдет, да).

если в разрыве нет никаких богопротивных медиаконвертеров, то фейловер должен успешно работать и на присутствии/отсутствии линка.

[Gunner]

Коммутаторы объединены по меди, друг от друга в 10м. Дебаг со стороны MES3124 включен те грешат на длинк - на предыдущей версии софта все работало до перезагрузки меса. Портченел подымался но не работал. Пересоздаем все пашет. Сейчас он самостоятельно собирается и разбирается сам. Чтоб убедить Элтекс мне нужен дамп. Связка боевая там сейчас 1.5гбита. Проц на DGS3627 -20% на MES3124 -5%

[s.lobanov]

Ну так возьмите ещё один dgs3627g, подключите его к mes3124 и снимайте дампы

[Gunner]

Нету еще 1го да и на MES3124 портов свободных тоже нет, остался лишь 1 тенгиг. Элтекс требует дамп с DGS

[pfexec]

Коммутаторы объединены по меди, друг от друга в 10м.

хоспаде! уберите вы этот лацп, зачем он вам ? неготиейшона на прямых медных линках мало ?

 

Дебаг со стороны MES3124 включен те грешат на длинк - на предыдущей версии софта все работало до перезагрузки меса

если у вас всё сломалось после обновления софта, то может стоит подчинить откатом софта ?

[kayot]

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

[s.lobanov]

ага. давайте ещё предложим заменить Po на десятку, ведь на обоих свитчах оно есть(правда для блинка нужно модуль докупать)

[DVM-Avgoor]

Ну так-то человеку надо что-бы работало.

А дебажить две китайские железки разных поколений (одна уже сильно старая другая еще сильно новая) затея, надо сказать, тоже весьма увлекательная.

[kayot]

Потому и предлагаю, включить статикой и забыть навсегда.

[rdc]

+1 к статике

вообще ситуаций, когда действительно нужен LACP, очень мало

в большинстве случаев статика проще и всяко надёжнее

[pfexec]

ага. давайте ещё предложим заменить Po на десятку, ведь на обоих свитчах оно есть(правда для блинка нужно модуль докупать)

ну вы то вроде серъезный человек, а не школоодмин локалхоста с убунту или центосью, а туда же.

какой прок от дополнительной сигнализации на 10 метровом линке из одной среды ? с вопросом определения разрыва линка справится и обычный negotiation. гонять рядом еще один l2 протокол смысла нет. вот если бы на линке были еще медиаконвертеры, которые не могут negotiation pass through, то тогда да. без lacp'а или oam'а не обойтись.

заменить 2х1Gbps на 1х10Gbps - всегда добрая идея. да и по баблу это уже не космические деньги.

но в данном случае всё решит либо откат софта, либо отказ то lacp в пользу статики на неготиейшоне. имхо, последнее в любом случае надо делать.

[terrible]

Если совсем всё тупо - убейте вообще Po и разрулите нагрузку вланами между 2-мя портами - абсолютно идиотская, но железобетонная схема

[Gunner]

Если совсем всё тупо - убейте вообще Po и разрулите нагрузку вланами между 2-мя портами - абсолютно идиотская, но железобетонная схема

Тоже склоняюсь к этому. Будем думать в принципе жаль что такая дубовая технология как LACP не работает как надо.

[DVM-Avgoor]

Тоже склоняюсь к этому. Будем думать в принципе жаль что такая дубовая технология как LACP не работает как надо.

 

 

Нет в ней ничего дубового. Контрольные сообщения LACP обрабатываются на большинстве железок в CPU. Если CPU чем-то невероятно занят - лацп может рваться.

Надо смотреть загрузку цпу, или от лацп отказаться.

[s.lobanov]

ага. давайте ещё предложим заменить Po на десятку, ведь на обоих свитчах оно есть(правда для блинка нужно модуль докупать)

ну вы то вроде серъезный человек, а не школоодмин локалхоста с убунту или центосью, а туда же.

какой прок от дополнительной сигнализации на 10 метровом линке из одной среды ? с вопросом определения разрыва линка справится и обычный negotiation. гонять рядом еще один l2 протокол смысла нет. вот если бы на линке были еще медиаконвертеры, которые не могут negotiation pass through, то тогда да. без lacp'а или oam'а не обойтись.

заменить 2х1Gbps на 1х10Gbps - всегда добрая идея. да и по баблу это уже не космические деньги.

но в данном случае всё решит либо откат софта, либо отказ то lacp в пользу статики на неготиейшоне. имхо, последнее в любом случае надо делать.

 

Не знаю в каких масштабах вы работаете, но лично я могу даже не иметь представления как далеко друг от друга находятся две железки с которыми нужно сделать какие-то манипуляции, поэтому всегда предпочитаю делать LACP вместо static lag. Кроме того я видел и полусгоревшие порты и sfp (на которых горят линки и даже может ходить трафик в одну сторону), что может запросто случится даже в пределах одной серверной. А уж если выбраться за пределы серверной и иметь дело с активным транспортом(конвертеры, релейки, dwdm-ы и т.п.), то там вообще веселуха.

 

Относительно данной проблемы(нормалного дебага нет на обеих железках) я бы предпочёл 10ку вместо 2x1G static(если выбирать из этих двух варианто), но ведь автор наверное знает про этот вариант, просто денег жалко.

 

Ну вообще не иметь оборудования в ЗИП это отдельная история(из серии "бэкапы для трусов". Был бы ЗИП, можно было бы отдебажить

 

Кстати, мнение Juniper относительно LACP:

" An easy way to acheive a UDLD-like check between switches of any vendors is to use LACP protocol in a single member LAG. The LACP protocol assures that device-id and port-id are exchanged between the switches whose links are inter-connected. This assures that the link stays up and functioning only if the other end is transmitting LACP packets at layer 2, else the local side takes down the LAG link." (http://kb.juniper.net/InfoCenter/index?page=content&id=KB13314 )

 

Они вообще предлагают использовать его для избавление от односторонней слышимости в inter-vendor конфигурациях

[pfexec]

Они вообще предлагают использовать его для избавление от односторонней слышимости в inter-vendor конфигурациях

мало ли что они там предлагают, как насчет немножко PR почитать, например PR898097: "commit operations might cause a spike in CPU utilization, resulting in a timeout of the time sensitive applications/protocols like Link Aggregation Control Protocol (LACP), Bidirectional Forwarding Detection (BFD), and etc."

и что характерно, если слепить на oam'е, то похоже, его не разносит как хомячка. беда в том что oam != udld из циски, например. хотя с икстримом вяжется. я думаю просто циска как обычно выпендрилась ок :)

но я вобщем то не про циску или чтото еще, я не спорю что лацп весь такой хороший и нужный, но пихать его в каждый линк вовсе не нужно. и проблема топикстартера одно из множества свидетельств, а PR у J другое подобное свидетельство.

Не знаю в каких масштабах вы работаете, но лично я могу даже не иметь представления как далеко друг от друга находятся две железки с которыми нужно сделать какие-то манипуляции, поэтому всегда предпочитаю делать LACP вместо static lag.

ну автор сказал что там медный линк на 10 метров. мониторить ошибки и дропы всё равно надо, а от них лацп не спасет. определить двухстороннюю согласованость линка тоже можно. вобщем тут оно излишне кмк. да и в прямом оптическом линке на 25км лацп тоже не нужен: если будут потери, то кто сказал что лацп обязательно перестанет работать ? у вас так же будет деградация, так же надо траблшутить. вобщем ничего не меняется. просто лацп - это еще один протокол, который дает какие-то +, можно забить на negotiation pass through, но и несет свои "риски", - процессору в определенный момент может оказаться не до lacp'а и что-нибудь еще.

 

а так да, изи-вей, потому что как не крути, а лацп поддерживают все.

[s.lobanov]

Ну с коммитом на J отдельная история. На Cisco IOS-like (т.е. почти всё) коммита нет. И кстати про BFD и некоторые другие простые протоколы, они же в нормальном оборудовании с line-card делается, даже хуавей такое умеет

 

Насколько мне известно, есть специальные техники, предотвращающие проблемы с lacp, bfd и прочим по причине HCU, а именно QoS в сторону CPE/RE и приоритезации задач/процесс "внутри" управляющего ПО