IVB Опубликовано 23 ноября, 2012 · Жалоба День добрый. Есть проблема. На OS6850 при определенном стечении обстоятельств по одному из vlan'ов заходит трафик (по L2), предназначенный для неизвестного MAC-адреса (т.е. раньше этот MAC был, теперь пропал). И OS6850 весь этот трафик начинает пихать во все порты этого vlan'а, в надежде, что где-то все-таки нужный MAC "найдется". Что, в свою очередь, создает проблемы для тех устройств, которые тоже находятся в этом vlan'е и не в состоянии нормально дропнуть этот паразитный трафик (грубо говоря - захлебываются). Вопрос: можно ли "отучить" OS6850 от такого поведения, и сделать так, чтобы весь L2 трафик для неизвестных MAC-адресов молча дропался. > show system System: Description: Alcatel-Lucent OS6850-P48X 6.4.4.551.R01 Service Release, August 28, 2012., Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 23 ноября, 2012 · Жалоба День добрый. Есть проблема. На OS6850 при определенном стечении обстоятельств по одному из vlan'ов заходит трафик (по L2), предназначенный для неизвестного MAC-адреса (т.е. раньше этот MAC был, теперь пропал). И OS6850 весь этот трафик начинает пихать во все порты этого vlan'а, в надежде, что где-то все-таки нужный MAC "найдется". Что, в свою очередь, создает проблемы для тех устройств, которые тоже находятся в этом vlan'е и не в состоянии нормально дропнуть этот паразитный трафик (грубо говоря - захлебываются). Вопрос: можно ли "отучить" OS6850 от такого поведения, и сделать так, чтобы весь L2 трафик для неизвестных MAC-адресов молча дропался. DST MAC у этого трафика какой - unicast или broadcast? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IVB Опубликовано 23 ноября, 2012 · Жалоба День добрый. Есть проблема. На OS6850 при определенном стечении обстоятельств по одному из vlan'ов заходит трафик (по L2), предназначенный для неизвестного MAC-адреса (т.е. раньше этот MAC был, теперь пропал). И OS6850 весь этот трафик начинает пихать во все порты этого vlan'а, в надежде, что где-то все-таки нужный MAC "найдется". Что, в свою очередь, создает проблемы для тех устройств, которые тоже находятся в этом vlan'е и не в состоянии нормально дропнуть этот паразитный трафик (грубо говоря - захлебываются). Вопрос: можно ли "отучить" OS6850 от такого поведения, и сделать так, чтобы весь L2 трафик для неизвестных MAC-адресов молча дропался. DST MAC у этого трафика какой - unicast или broadcast? Unicast. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BiWiS Опубликовано 23 ноября, 2012 · Жалоба увеличить время жизни МАС? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
JoeDoe Опубликовано 23 ноября, 2012 · Жалоба Можно ограничить flood rate на интерфейсе. Если вы используете port mapping, тогда все еще проще: port mapping 5 unknown-unicast-flooding disable Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IVB Опубликовано 23 ноября, 2012 · Жалоба увеличить время жизни МАС? Можно увеличить время жизни MAC. Можно попытаться "разобраться" с аплинком - почему у него не экспайрится МАС (тогда он перестанет "пихать" мне трафик). Можно найти и устранить причину пропадания МАСа у даунлинка. Но все это - за пределами зоны моей ответственности. Поэтому я хочу решить проблему кардинально - дропать L2 трафик, у которого нет адресата. Чтобы проблемы моих линков не мешали жить мне. Как говорится, проблемы индейцев шерифа не волнуют. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IVB Опубликовано 23 ноября, 2012 · Жалоба Можно ограничить flood rate на интерфейсе. Прочитал доку - так и не понял, что произойдет, когда flood превысит заданный порог. Не получится ли так, что флудящий порт просто будет отрублен? Попытался выставить значение 0 - не поддерживается. Пришлось ставить значение 1 mbps. Если вы используете port mapping, тогда все еще проще: port mapping 5 unknown-unicast-flooding disable Нет, порт-маппинг не используется. Речь идет о транзитном L2 трафике. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
svenk Опубликовано 23 ноября, 2012 · Жалоба День добрый. Есть проблема. На OS6850 при определенном стечении обстоятельств по одному из vlan'ов заходит трафик (по L2), предназначенный для неизвестного MAC-адреса (т.е. раньше этот MAC был, теперь пропал). И OS6850 весь этот трафик начинает пихать во все порты этого vlan'а, в надежде, что где-то все-таки нужный MAC "найдется". Что, в свою очередь, создает проблемы для тех устройств, которые тоже находятся в этом vlan'е и не в состоянии нормально дропнуть этот паразитный трафик (грубо говоря - захлебываются). Вопрос: можно ли "отучить" OS6850 от такого поведения, и сделать так, чтобы весь L2 трафик для неизвестных MAC-адресов молча дропался. DST MAC у этого трафика какой - unicast или broadcast? Unicast. А в arp кэше его нет, может он там статиком прописан. show arp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IVB Опубликовано 26 ноября, 2012 · Жалоба День добрый. Есть проблема. На OS6850 при определенном стечении обстоятельств по одному из vlan'ов заходит трафик (по L2), предназначенный для неизвестного MAC-адреса (т.е. раньше этот MAC был, теперь пропал). И OS6850 весь этот трафик начинает пихать во все порты этого vlan'а, в надежде, что где-то все-таки нужный MAC "найдется". Что, в свою очередь, создает проблемы для тех устройств, которые тоже находятся в этом vlan'е и не в состоянии нормально дропнуть этот паразитный трафик (грубо говоря - захлебываются). Вопрос: можно ли "отучить" OS6850 от такого поведения, и сделать так, чтобы весь L2 трафик для неизвестных MAC-адресов молча дропался. DST MAC у этого трафика какой - unicast или broadcast? Unicast. А в arp кэше его нет, может он там статиком прописан. show arp Как раз из кеша он и пропадает. У аплинка в кеше он еще есть (или он там вообще статиком прописан), поэтому аплинк гонит этот трафик на меня. А у меня этого MACа уже нет - поэтому моя железка не знает, куда его девать. Заниматься настройкой аплинка и даунлинка (для которых я являюсь транзитером) нет ни малейшего желания. Вопрос остался без ответа, поэтому повторю: Что происходит, если ingress flood трафик превышает заданный rate? Этот трафик дропается, или порт переводится в error-disabled? (в доке это очень невнятно описано) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 26 ноября, 2012 · Жалоба ни разу с таким не сталкивался, т.к. либо все VLAN прописаны p2p+STP, либо это L3 стыки, где алкатель - шлюз. попробуйте увеличить aging-time -> show mac-address-table aging-time Mac Address Aging Time (seconds) = 300 -> mac-address-table aging-time 600 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IVB Опубликовано 26 ноября, 2012 · Жалоба попробуйте увеличить aging-time Я ведь писал, что не хочу разбираться с линками. Если у меня пропадает MAC даунлинка, а у аплинка он не пропадает - где-то что-то криво настроено. И за поиски этих кривых настроек мне денег не платят. Поэтому меня вполне устроит, если flood трафик (т.е. трафик с неизвестным МАС-адресом получаетеля) будет просто дропаться. Т.е. предложенный вариант с ограничением flood rate - это именно то, что мне нужно. interfaces 1/49 flood unknown-unicast rate mbps 1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 26 ноября, 2012 · Жалоба Описанная в первом посте ситуация совершенно нормальна и в общем случае препятствовать ей нельзя. В частном же случае можно использовать дроп, но эта фича, емнип, реализуется программно и, теоретически, способна нагрузить процессор коммутатора. Правильнее будет разобраться с причиной. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...