столкнулись с такой проблемой. в сети у нас более 200 дслам-ов ревизии А и В
до недавнего времени работало всё нормально. и вдруг посыпались жалобы от абонентов что они ничего не качают а пинги у них завышаются и канал забит как будто они чтото качают на скорости порта.
стали проверять, поставив абонов на мониторинг в заббиксе, где увидели что абоны забивали свой канал в "потолок", хотя в этот момент по айпитрафу на роутерах трафика нет по абонентам.
у пары абонентов перевели модемы в режим бриджа и послушали что творится с помощью wireshark-a, и заметили что абонент слышит всё что творится на других порта того же дслам-а.
из чего сделали вывод что трафик не проходит через маршрутизатор а бегает между абонентами в пределах одной атс и в определенных вилане, атак же на соседних точках где стоят такие дслам-ы в похожих вланах.
тоесть такое ощущение что дслам-ы работают как хаб.
что могло случится и как можно исправить?
глобально
$get nbsi
Bridging Mode : Restricted

по 1 влану
Bridging Mode : Restricted

по абонентским виланам у всех стоит
Bridging Mode : Residential

1.Сделайте Restricted по всем абоненским виланам.
Комманда :
modify vlan static (vlanname) bridgingmode Restricted

2. Проверьте забита ли полностью fdb ( таблица коммутации).
Возможно кто-то делает mac-флуд и превращает коммутатор DSL ( DSLAM) в хаб.
Просмотр таблицы коммутации устройства производится командой
$ get bridge forwarding
В этом случае измените кол-мо маков на порт ( port security).
Пример:
$ modify bridge port intf portid 1 status disable
$ modify bridge port intf portid 1 maxucast 5
$ modify bridge port intf portid 1 status enable

3. Как подключены аплинки дсламом? Сразу на гетвей ( L3 роутер) или еще через сегмент L2 свичей?
Если да (через L2), то ограничьте на свичах хождение трафика между несколькими DSLAМами ( например через ACL) .
Т.е. они (DSLAмы) должны общаться только через гетвей роутер (L3).

_________________
С уважением, Гакало Алексей

сколько всего должен быть размер таблицы мак адресов?


а есть ли глобальные команды? а то менять все 48 портов по всем >200 дсламам дело нелёгкое...
и сколько примерно можно разрешать маков на порт?
вернее сколько маков достаточно абоненту, допустим не домашнему а корпоративному абоненту, с небольшой внутренней сеткой из 5-10 девайсов?


дсламы подключены к свитчам через длинки 3426 и 3526
причем свичтей 3426 большее количество. это L2 же? и подскажите пожалуйста пример включения АЦЛ на них?

поднимаю тему. проблему решить не смогли.
перевод абонентских виланов в Restricted режим проблемы не решило, к тому же перестали маки передаваться в этом режиме.
и флуд продолжает идти. что ещё можно предпринять?

1. 4000.
( смотрится командой get nbsize через телнет)
"Max Mac Adresses : 4000"

2. Нет глобально нельзя.
Только "по-портово."
У абонента модем стоит скорее всего в режиме роутера, т.е к вам "светит" только MAC wan порта абонентского роутера (остальная сеть абонента скрыта за NATом абонентского модема-роутера).
В редких (клинических) случаях, когда модем стоит бриждом ,то да, до порядка 5 девайсов на абонента- это норма.
Т.е оставляйте 5 маков. Главное что бы не выключена фича совсем.

3.Да, DES-3526 и DGS-3426 - это L2 коммутаторы.

Причем я так и не понял какая у вас карта VLAN в сети ?

VLAN на DSLAМ, VLAN на абонента, 1 VLAN на всю сетку.

В третьем случае - это очень плохо. Получается очеееень большой широковещательный домен, в котором гуляют "тонны" броадкаста, который легко "заштормить" и т.д.
В этом случае действительно все лишнее надо вырезать ТОЛЬКО на свичах посредством ACL , включать штормконтроль на свичах и т д.
Соответствующие ACL и советы вы найдете на нашем сайте и форуме в разделе коммутаторы .

Гораздо лучше на мой взгляд:
разбить сеть по схеме- хотя бы VLAN на 1 DSLAМ
( т.е на шлюзе - на L3 "коммутаторе ядра" создать VLANов по кол-ву DSLAМов и на каждом VLAN на них поднять IP интерфейс с небольшой подсетью).
Таким образом сегментировав сеть, вы автоматически получите хождение трафика только через L3 (и никакого обмена напрямую между DSLAМами, кроме того уменьшаете широковешательный домен.)

_________________
С уважением, Гакало Алексей

у нас вся сеть сегментирована.
например есть 50 станций
у каждой станции по хх дсламов и свои вланы на каждую атс.
так же есть вланы для некоторых тарифных планов.
то есть на одном дсламе может использоваться от 3х до 5ти вланов.

но так и не удалось нам победить флуд.
что было сделано -
1. на всех коммутаторах 3526 и 3426:
а) отключили хождение дхцп в сети посредством ацл
б) активировали traffic_segmentation на портах
1 21-26
...
20 21-26
21 1-26
...
26 1-26
2. на паре рабочих экспериментальных дсламах:
а) удалили вручную с 1 влана все порты юр.лиц которые юзают статику, и оставили только порты физ.лиц(ПППоЕ) в 1 влане.
б) поставили порты юриков в 1 влане в форбидден.
в) перевели все вланы юр.лиц кроме первого в режим рестриктед
флуд как шпарил так и шпарит по сей момент.
например по айпитарфу на рутере 12кбит на абона, а по графику заббикса все 2 мегабита, при этом пинги огромные, и даже с потерями, и абонент жалуется что вообще ничего не открывается.
как то можно решить проблему, не выезжая к абоненту в другой конец города и не снимать дамп?
по началу думали что проблема изза того, что порты абонов светятся в 1 влане, но после вышеперечисленных манипуляций стало понятно что это было бесполезно и это не является причиной.

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

Честно?
У вас или что то не так с VLAN, или... может быть петли?
В любом случае так работать не должно.

_________________
С уважением, Гакало Алексей

да, это так . но что быть может в вланами не так?
я сейчас провёл эксперимент
на дсламе есть 303 влан
к нему привязано два порта: 7 и 10

VLAN Name : vlan303
VLAN Index : 303
Egress ports : 7 10 385
Untagged Ports : 7 10
Bridging Mode : Restricted

у обоих идёт флуд. выключил абона с 7 портом.
флуд на 10 не прекратился.
эксперимента ради вставил 7 и 10 порт в графу
Forbidden Egress Ports : 7 10
в 1 влане
и
Forbidden Egress Ports : все порты кроме 7 и 10
в 303 влане, картина не изменилась.
что ещё можно покрутить/поэкспериментировать????

почитал тут статьи и наткнулся на феномен "коллизии хеш функции мак адреса"
наверняка вам это известно, вот похоже сейчас это у нас и происходит.
что вы думаете про это? никаких решений не существует?
решили побить сеть на более мелкие подсетки(по 28 маске) и большее количество вланов.
надеемся, что это поможет избавится от проблемы.

Это не актуально для DSLAМов, а только для некоторых моделей свичей.
На DSLАМах никогда такого не наблюдалось.

Скорее похоже на какой-то неисправный DSLAМ, флудящий в сеть.

_________________
С уважением, Гакало Алексей