[CrazyApelsin]

Все привет.

 

Появилась проблема флуда на коммутаторах Juniper EX-3200-24T

Версия JunOS 12.3R3.4

 

Проблема заключается в следующем: мак не сохраняется в

таблице мак-адресов и трафик предназначенный данному абонента

летит на все порты, где присутствует влан, в котором находится абонент.

 

Вот что удалось обнаружить:

run show ethernet-switching mac-learning-log | match f5:72

 

Fri Sep 20 13:54:06 2013 vlan_name v4000 mac 10:bf:48:e6:f5:72 was learned on ge-0/0/11.0

Fri Sep 20 13:54:06 2013 vlan_name v4000 mac 10:bf:48:e6:f5:72 was deleted on ge-0/0/11.0

Fri Sep 20 13:54:08 2013 vlan_name v4000 mac 10:bf:48:e6:f5:72 was learned on ge-0/0/11.0

Fri Sep 20 13:54:08 2013 vlan_name v4000 mac 10:bf:48:e6:f5:72 was deleted on ge-0/0/11.0

Fri Sep 20 13:54:10 2013 vlan_name v4000 mac 10:bf:48:e6:f5:72 was learned on ge-0/0/11.0

Fri Sep 20 13:54:10 2013 vlan_name v4000 mac 10:bf:48:e6:f5:72 was deleted on ge-0/0/11.0

 

Это абонентский мак (10:bf:48:e6:f5:72), которого нет в таблице.

> show ethernet-switching table vlan v4000 | match f5:72

 

>

 

Так же известно о проблеме с хэш коллизиями (PR842439),но проблема была на ex-4500 и по утверждению джунипера она исправлена.

 

Куда копать, что можно посмотреть?

[Night_Snake]

Выкинуть нахрен EX3200

Проблема на всех EX3200/EX4200/EX4500. На EX4500 они ее исправили (кажется), на остальных - не уверен...

[CrazyApelsin]

Выкинуть нахрен EX3200

Проблема на всех EX3200/EX4200/EX4500. На EX4500 они ее исправили (кажется), на остальных - не уверен...

 

 

Отлично))

 

P.S. на EX3300 вроде тоже самое

Изменено 24 сентября, 2013 пользователем CrazyApelsin

[stranger2904]

Именно из-за этого от джуниперов и отказываемся, есть у них проблемы с хеш-коллизиями, причем насколько я знаю аппаратная(прошивкой не исправишь).

[ash]

Именно из-за этого от джуниперов и отказываемся, есть у них проблемы с хеш-коллизиями, причем насколько я знаю аппаратная(прошивкой не исправишь).

 

откуда известия о аппаратной проблеме?

[stranger2904]

ash

От коллеги из достаточно крупного оператора, у которого был сервис контракт на железо.

Они массово столкнулись с данной проблемой и не "слезали" с вендора пока он(вендор) не развел руками...

З.Ы. Причем это все уже достаточно давно было...

Изменено 24 сентября, 2013 пользователем stranger2904

[ash]

ash

От коллеги из достаточно крупного оператора, у которого был сервис контракт на железо.

Они массово столкнулись с данной проблемой и не "слезали" с вендора пока он(вендор) не развел руками...

З.Ы. Причем это все уже достаточно давно было...

вопрос интересен

если не секрет скиньте что за оператор в личку

аппаратная часть это серьезная претензия к джуну

[CrazyApelsin]

ash

От коллеги из достаточно крупного оператора, у которого был сервис контракт на железо.

Они массово столкнулись с данной проблемой и не "слезали" с вендора пока он(вендор) не развел руками...

З.Ы. Причем это все уже достаточно давно было...

вопрос интересен

если не секрет скиньте что за оператор в личку

аппаратная часть это серьезная претензия к джуну

 

Дак процентов на 99 это аппаратная проблема, так как функции эти выполняет ASIC (должен, поправьте если не прав))).

Вот сижу и думаю что делать

Изменено 24 сентября, 2013 пользователем CrazyApelsin

[stranger2904]

ash

афишировать не могу, ничего личного.

CrazyApelsin

вижу два варианта:

1)менять вендора

2)дробить на более мелкие l2 сегменты,

или как вариант (сам не пробовал), если есть влан точка-точка со значительным количеством маков, отключить на нем лернинг...

[CrazyApelsin]

ash

афишировать не могу, ничего личного.

CrazyApelsin

вижу два варианта:

1)менять вендора

2)дробить на более мелкие l2 сегменты,

или как вариант (сам не пробовал), если есть влан точка-точка со значительным количеством маков, отключить на нем лернинг...

 

 

Да, пришли к такому же выводу.

[msdt]

При каком количестве маков проблема становится заметна на EX4200? Есть ли какие-то средства диагностики, аналогчные длинковскому sh flood_fdb?

[srg555]

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

 

По большому счёту, мак-таблица на агрегации нужна лишь для кольцевой схемы доступа, чтоб не дублировать трафик в оба плеча кольца, а так в принципе mac-learning на агрегации не нужен

 

Если схема звезда и используется vlan-per-switch или vlan-per-user, то пофиг на mac-learning вообще

 

По поводу софта - на многих asic-ах ресурсы аппаратный ресурс можно перераспределять(между fdb, fib, mfib и т.п.) и это единственное что может сделать вендор софтово, в принципе на пограничных случаях в говносетях типа "вся сеть в одном влане" это поможет

[CrazyApelsin]

При каком количестве маков проблема становится заметна на EX4200? Есть ли какие-то средства диагностики, аналогчные длинковскому sh flood_fdb?

Не знаю как насчет 4200, но у нас на появилась проблема при 7к маков, на данный момент около 11к маков (выученных и показанных в ethernet-switching table на джунипере, а так как он запоминает не все, то видимо маков больше)

[srg555]

CrazyApelsin

Чем вам это мешает? У вас вся сеть в одном влане или у вас один Q-in-Q S-Vlan влан для интернет-сервиса?(т.е. изучение происходит в одном и том же влане)

[CrazyApelsin]

CrazyApelsin

Чем вам это мешает? У вас вся сеть в одном влане или у вас один Q-in-Q S-Vlan влан для интернет-сервиса?(т.е. изучение происходит в одном и том же влане)

 

 

Скажем так, есть район города куда смотрят несколько qinq вланов, в них уже сидят абоненты, каждый в своем влане. Да, изучение получается во влане с outer tag'ом.

 

К примеру возьмем один q-in-q влан с outer tag 4000 (см. первый пост), смотрю снифером в этот влан и там летает куча дермища, т.е. дст мак известен, но ех3200 к которому подключен маршрутизатор ничего об этом маке не знает. Получается что в этом влане у меня летает около 10 мегабит трафика ненужного, точнее нужного, но только одному абоненту, а не всем в этом влане. Ситуация получается следующая абонент начинает качать (тариф у него 10 мегабит) и джунипер шлет эти 10 мегабит на все порты с 4000ым вланом. как то так

[srg555]

CrazyApelsin

Один outer tag это почти тоже самое, что и "вся сеть в одном влане". Делайте разные outer-теги на разные физические порты и настанет вам счастье. Если у вас кольца, то делайте outer tag на кольцо, тогда флуд у вас будет только в соседнее плечо этого кольца. И то не факт что флуд будет, больше вланов - меньше вероятность коллизии внутри влана, а интер-влан коллизии не приводят к флуду

[CrazyApelsin]

CrazyApelsin

Один outer tag это почти тоже самое, что и "вся сеть в одном влане". Делайте разные outer-теги на разные физические порты и настанет вам счастье. Если у вас кольца, то делайте outer tag на кольцо, тогда флуд у вас будет только в соседнее плечо этого кольца. И то не факт что флуд будет, больше вланов - меньше вероятность коллизии внутри влана, а интер-влан коллизии не приводят к флуду

 

У нас впринципе так и сделано, получается в одном SP-Vlan порядка 300-400 CE-Vlan, каждый на своего абонента. Т.е. в сети используется порядка 25-30 SP-Vlan. 300-400 маков в одном SP-Vlan'e это много?

[srg555]

CrazyApelsin

У вас есть SP-vlan, который на несколько интерфейсов? (т.е. больше, чем на аплинк и даунлик интерфейсы)

 

Если у вас SP-vlan не используется более, чем на одном даунлинке, то флуда не будет. Откуда у вас флуд-то берётся?

[CrazyApelsin]

CrazyApelsin

У вас есть SP-vlan, который на несколько интерфейсов? (т.е. больше, чем на аплинк и даунлик интерфейсы)

 

Если у вас SP-vlan не используется более, чем на одном даунлинке, то флуда не будет. Откуда у вас флуд-то берётся?

А, понял... Да SP-Vlan идет на несколько маршрутизаторов, аплинк, даун-линк и дальше по кольцу. Флуд понятно откуда берется. Мне не понятно почему с джуниперами такая проблема)))

 

И еще, вот что нашлось в описании джуноса 11.4

 

Increasing the maximum number of searchable hash indexes—For all EX Series

switches except the EX8200 switch, you can now mitigate situations in which hash

index collisions are causing problems with the learning of MAC addresses in the

forwarding database (FDB). The FDB on those switches is a hash table with 8192 hash

indexes (rows) of MAC addresses and four entries per hash index.

 

Я правильно понимаю что максимальное кол-во хэш-записей всего 8к и на каждую хэш запись может приходиться по 4 мак-адеса, это как?

[srg555]

CrazyApelsin

Хеш-таблица это массив, где каждый элемент массива это связанный список. Размер это связанного списка в описанном вами случае равен 4, что означает, что существует 5 мак-адресов(влан-макадресов), которые не могут быть одновременно инсталлированы в таблицу коммутации.

 

В железе "список" может быть список или же быть просто 4 "массива", просматриваемые "одновременно", но для вас это не имеет никакого значения.

 

Делайте нормальный дизайн сети(SP-vlan на порт или на кольцо). Или покупайте с очень большими мак-таблицами, где вероятность коллизии будет мала.

 

Вообще, в ISP мак-таблицы условно нужны только в случае L2-резервирования, всё остальное(не vlan-per-user) это не ISP-доступ, а локалка.

Изменено 24 сентября, 2013 пользователем srg555

[srg555]

Методика поиска коллизионных мак-адресов:

- пишите скрипт, который отсылает мак-адреса(подряд) и проверяет их наличие в таблице коммутации

- после того, как первый факт коллизии будет найден, запускаете второй проход, где неизученный мак отсылаете первым

- запускаете второй(отправляя те же маки в порт), находите мак, который не изучится, в следующий проход ставите его первым

- и т.д., пока не найдёте 5 мак-адресов, которые не могут быть изучены одновременно.

 

Поиски таких пятёрок мак-адресов особо не имеет практического смысла, разве что ради интереса, чтобы находить коммутаторы разных производителей с одинаковыми(похожими) asic, сконфигурированных в одном и том же режиме

[CrazyApelsin]

Методика поиска коллизионных мак-адресов:

- пишите скрипт, который отсылает мак-адреса(подряд) и проверяет их наличие в таблице коммутации

- после того, как первый факт коллизии будет найден, запускаете второй проход, где неизученный мак отсылаете первым

- запускаете второй(отправляя те же маки в порт), находите мак, который не изучится, в следующий проход ставите его первым

- и т.д., пока не найдёте 5 мак-адресов, которые не могут быть изучены одновременно.

 

Поиски таких пятёрок мак-адресов особо не имеет практического смысла, разве что ради интереса, чтобы находить коммутаторы разных производителей с одинаковыми(похожими) asic, сконфигурированных в одном и том же режиме

 

 

Спасибо! Будем думать что делать

[Night_Snake]

Именно из-за этого от джуниперов и отказываемся, есть у них проблемы с хеш-коллизиями, причем насколько я знаю аппаратная(прошивкой не исправишь).

Подтверждаю. Нам джунипер очень долго компостировал мозги "исправим в следующей прошивке, зуб даю, да?", но в итоге сознался, что проблема аппаратная.

[CrazyApelsin]

Будем переделывать сеть и щас возьмем на тест Extreme X460

[Agent2006]

Методика поиска коллизионных мак-адресов:

- пишите скрипт, который отсылает мак-адреса(подряд) и проверяет их наличие в таблице коммутации

Скрипт уже написан. Если есть желание, то можно потестировать.