Изначальные условия: IP DSLAM D-link в режиме бриджа.
Клиентский порт настроен следующим образом:

modify bridge port intf portid 7 status disable
modify bridge port intf portid 7 maxucast 1
modify bridge port intf portid 7 status enable
modify bridge port intf portid 7 StickyStatus enable

Подключаем клиента, запускаем на него пинг. В таблице коммутации появляется следующее:
$ get bridge forwarding vlanid 13

MAC Addr PortId VlanId Status
-----------------------------------------------
00:04:61:4F:98:66 385 13 Learned
00:13:46:64:40:23 7 13 Sticky

Для пущей важности выполняем следующее
modify bridge port intf portid 7 fdbmodify disable
create acl port macentry portid 7 macaddr 00:13:46:64:40:23

Т.е. по идее привязка мака на порту должна состояться

Ладно, создаем на роутере статическую связку "ip клиента-мак" с другим маком, которого в данный момент в сети нет. Запускаем пинги и смотрим сниффером на клиентском порту.
А там свободно идут входящие Unicast пакеты с левым маком.
Потому что DAS форвардит все Unicast пакеты с маками которых у него нет в таблице коммутации на все клиентские порты, даже на те, обучение маков на которых выключено и есть статическая FDB запись(!).

В итоге это приводит к чему:

Клиент берет любой 500Т, настраивает его роутером и назначает IP клиента с соседнего DAS, которого счас в сетке нет и спокойно работает.
Потому как D-linkу 500Т в режиме роутера все равно с каким DST MAC ответ пришел -его только Destination IP интересует.
А исходящие пакеты он отправляет со своим маком, и марштуризатор такие пакеты форвардит.

На тех же свитчах 3526 после привязки маков на порту почему-то нет лишнего Unicast трафика с destination mac отличающимся от привязанного к порту!

Как подобного поведения добиться от DASов? Не уж то только создавать дополнительный ACL filter rule и прописывать туда маки и IP как тут некоторые делают? ИМХО это криво!

1. После создания правила ACL DSLAM "смотрит" на source MAC адреса в кадрах, поступающих на абонентский порт от CPE (модема). Если в кадре source MAC отличается от того, который был указан при создании ACL правила - такой кадр будет отброшен.

2. Вы писали:
"Потому что DAS форвардит все Unicast пакеты с маками которых у него нет в таблице коммутации на все клиентские порты, даже на те, обучение маков на которых выключено и есть статическая FDB запись(!)."

Ответ: это нормально. Если от CPE пришел запрос, DSLAM проверяет соответствие source MAC адреса в поступившем кадре и если этот MAC адрес соответствует тому, что прописано при создании ACL правила - этот запрос форвардится во вне.

3. Опишите в подробностях, чего Вы хотите реализовать. Жестко привязать абонентские устройства к портам?

_________________
С уважением, Давыдов Денис.

Не вижу ничего нормального. На порт Uplink DSLAM пришел пакет с определенным destination MAC адресом. Если данного пакета нет в текущей таблице коммутации на каком основании данный пакет DSLAM форвардит на все клиентские порты на которых
1) Обучение макам отключено
2) Максимальное допустимое кол-во маков 1 и этот 1 мак УЖЕ присутствует в таблице коммутации cо статусом Sticky.

В той же самой ситуации со свитчами 3526 если на порту есть статическая FDB запись (или мак привязан DeleteOnReset или Permanent) то на этот порт никогда не попадут пакеты с destination mac отличным от статически привязанного к порту. Почему DAS себе такое позволяет?

Опишите в точности, что Вы хотите реализовать и как это должно выглядеть. Я опишу Вам пример настройки DSLAM.

_________________
С уважением, Давыдов Денис.

Я хочу создать статическую MAC запись в таблице коммутации (fdb) на клиентском порту. И чтобы DSLAM не форвардил _извне_ (с Uplink) на клиентские ADSL порты пакеты с destination mac, отличающихся от прописанных и привязанных на ADSL портах.
И желательно чтобы это происходило без костылей в виде дополнительных ACL.

Мне кажется ненормальным текущее поведение железки, и я склонен данное поведение DSLAMA считать ошибкой.

Выдержка из описания ACL:

Per Port ACL
Создается для конкретного bridge порта
Все входящие пакеты, у которых source MAC адрес совпадает с одним из адресов, перечисленных в списке, имеют доступ к данному bridge порту. Все остальные входящие пакеты доступа к данному bridge порту не имеют, т.е. отбрасываются.
Если список MAC адресов пуст, любые адреса имеют доступ на данный Bridge порт.
Только unicast MAC адреса могут быть добавлены в список.

Global ACL
Создается на глобальном уровне (целиком на DAS-3248)
Всем пакетам, имеющим source MAC адрес, совпадающий с одним из адресов, перечисленных в списке, может быть запрещен доступ путем выбора опции Deny.
Данный список может быть использован для отслеживания содержащихся в нем MAC адресов. В этом случае при перемещении MAC адреса на другой порт будет сгенерирован SNMP Trap.
Только unicast MAC адреса могут быть добавлены в список.

Если вы хотите производить фильтрацию, основываясь на Destination MAC в заголовке пакета, нужно использовать пакетные фильтры с соответствующими действиями.

_________________
С уважением, Давыдов Денис.

Мы с вами как-то про разные вещи говорим.

Ответьте пожалуйста на конкретный вопрос - на каком основании DAS форвардит чужие Ucast пакеты на клиентский порт, если максимальное кол-во маков которое может быть на порту - 1 и этот мак уже присутствует на порту и имеет статус Sticky.

Почему для DAS для этого нужно писать еще какие-то фильтры, а на тех же свитчах 3526 все работает без дополнительных ACL.

Потому что на DES-3526 ACL работают несколько иначе. Если ACL в DES-3526 можно сконфигурировать на проверку как Source, так и Destination MAC, то на DSLAM правила ACL "смотрят" только на Source MAC в заголовке пакетов, приходящих от абонентских устройств (CPE). Такова реализация ACL в DSLAM.

_________________
С уважением, Давыдов Денис.

Денис, да не используется для этого никаких ACL на DES-3526

Просто, так же как и на DAS, ограничивается кол-во обучаемых маков на порту 1 шт. и, так же как и на DAS, выставляется что данный порт этому 1 маку обучается и выставляется ему свойство "Delete On Reset" или "Stickly" по аналогии с DAS. И все - пакеты с чужим destination mac на клиентский порт не уйдут.

Хотелось бы от DAS аналогичного поведения.
Мое мнение, что это ошибка в firmware - форвардить весь юникастовый (не широковещательный, а именно unicast) флуд который неизбежно гуляет по сети на _каждый_ клиентский порт, хотя заранее известно какой на порту MAC и известно что больше MACов там никогда не будет. Может стоит запросить разработчиков, пусть подправят в след. прошивке.

Потому как слишком уж однобоко срабатывает имеющаяся функция create acl port macentry . При том как она сейчас реализованна что она есть - что ее нет, ничего не мешает пользователю подделать IP неработающего в данный момент клиента и воровать интернет.

ACL в данном устройстве (DSLAM) предназначены для привязки абонентских MAC адресов к DSL портам. Это применимо либо к конкретному порту, либо глобально для всего устройства.
Правила ACL в DAS-3224 и 3248 смотрят только на Source MAC пакетов, приходящих только от абонентских устройств. Если Вам нужно ограничивать поступающий к абоненту трафик по какому либо критерию (MAC, IP, порт, EtherType и др.) - используйте пакетные фильтры. Другими способами этого не достичь.

Если Вам нужно сделать жесткую привязку MAC и IP адреса абонента к DSL порту (чтобы предотвратить подмену IP и MAC адресов) - я напишу Вам пример.

_________________
С уважением, Давыдов Денис.

Не будем касаться слова ACL. Вообще.

Давайте рассмотрим действие команды

modify bridge port intf portid portid ifname (ifname)

Читаем документацию

7.2.Настройка функций, связанных с Unicast передачей данных.

7.2.1.Таблица коммутации. Port Security.
Для устройств 2 уровня (коммутаторов, в том числе и коммутаторов ADSL - DSLAМ)) характерно наличие в устройствах таблицы коммутации (Forwarding Table), в которой содержатся МАС адреса сетевых устройств, находящихся за соответствующими физическими портами устройства. Поскольку количество и состав МAC адресов изменяться со временем могут на каждом порту, то ручное ведение таблицы было бы не рациональным. Поэтомубыло введено понятие обучения (Learning) портов. В режиме обучения порт автоматически наполняет таблицу коммутации MAC адресами содержащимися в поле Source MAC address приходящих Ethernet пакетов. Чтобы предотвратить перегрузку DSLAM MAC адресами, а также улучшить безопасность сети, применяется функция Port Security, позволяющая порту обучится только заданному количеству MAC адресов и отвергающая все пакеты со всеми иными MAC.

maxucast (maxucast addresses)
Определяет максимальное количество MAC адресов, которому может быть обучен данный Bridge порт. Опциональный параметр. Значение
по умолчанию 256.
Насчет 256 в документации ошибка, значение данного параметра по умолчанию 16. Допустим выставляем значение 1.

stickystatus (enable | disable)
Включает режим постоянной привязки MAC адресов к bridge порту.
В состояние enable запись о MAC адресе не устаревает, поэтому однажды обученный определенному MAC адресу, порт сохраняет запись и не дает <обучится> данному MAC другой порт.
Опциональный параметр. Значение по умолчанию enable.

Снова ошибка в документации, значение по умолчанию - disable.

Итак, постоянная привязка MAC адреса включена, порт обучился одному маку. Вполне логично предположить, что других маков на порту не будет. Но как уже писал выше DAS по прежнему форвардит на этот порт ВСЕ пакеты с чужими НЕшироковещательными, НЕ мультикастовыми destination мак адресами.
Это ошибка, которую править нужно!
Почему Вы упорно данное поведение устройства считаете нормальным ?!?

Было бы неплохо рассмотреть Ваш пример настройки DAS при котором на каждый клиентский порт будут попадать исходящие к абоненту пакеты только с клиентским destination mac адресом.

Вариант создавать 48 filter rule entry (ruledir out),
В каждом из них прописывать 48 SubRule c клиентскими маками да еще потом привязывать это все к интерфейсам изначально сомнителен. Даже не из-за кривости и сложности,а хотя бы потому, что максимум создаваемых egress filter rule - 25 (!), а в исходных данных DAS-3248 и на некоторых портах нужно привязать 2 мака.

p/s: И пожалуйста не предлагайте фильтровать по src IP на абонентском порту! Это _не_ решит проблему поскольку абонент по прежнему будет получать _чужие_ пакеты которые для него не предназначены!

up

В FDB устройства записываются только Source MAC адреса.
Все операции с Destination MAC адресами производятся только посредством пакетных фильтров.

_________________
С уважением, Давыдов Денис.

Т.е. отфильтровать исходящий к абоненту трафик по хотя-бы 1 DST MAC адресу на кажом порту DAS-3248 не представляется возможным?

Это можно сделать только посредством пакетных фильтров.

_________________
С уважением, Давыдов Денис.