Не подскажет ли кто, как осуществить такое вот вроде бы вполне естественное желание? (И осуществимо ли такое вообще?)

Имеется свич указанной системы (точнее DGS-3627G с прошивкой 2.50.B35). Есть на нем клиентские порты (точнее порты, ведущие к клиентским свичам) и два аплинковых порта. Хочется пропустить от клиентов в аплинки след.трафик:
1) PPPoE
2) IP-трафик, подлежащий маршрутизации через свич

Все остальное желательно запретить. Для этого пишу примерно такие слова:
create access_profile profile_id 1 ethernet ethernet_type
config access_profile profile_id 1 add access_id 1 ethernet ethernet_type 0x8863 port 1-22 permit rx_rate no_limit
config access_profile profile_id 1 add access_id 2 ethernet ethernet_type 0x8864 port 1-22 permit rx_rate no_limit
create access_profile profile_id 3 ethernet destination_mac FF-FF-FF-FF-FF-FF
config access_profile profile_id 3 add access_id 3 ethernet destination_mac 00-1C-F0-25-B4-80 port 1-22 permit rx_rate no_limit
create access_profile profile_id 12 ethernet vlan
config access_profile profile_id 12 add access_id 128 ethernet vlan Cust-300 port 1-22 deny

В профиле 3 указан MAC-адрес самого свича - подразумевается, что трафик, подлежащий маршрутизации свичом, на L2 будем адресован лично свичу.

После этого наблюдаю следующую картину: PPPoE ходит, а больше ничего не ходит, в том числе и L3-трафик. То есть правило 3 отнюдь не помогает.

При удалении правила 128 L3-трафик начинает идти, а вместе с ним, естественно и весь прочий L2-трафик прямиком по VLAN-у, чего, конечно не хотелось бы.

Кто-нибудь знает, как это победить?

А про ARP Вы не забыли?

Да не забыл (вроде бы).

Сначала я думал, что в данном списке уместен будет и ARP. А потом обратил внимание, что сам свич со стороны клиента и так прекрасно виден (пингуется) без всяких дополнительных телодвижений. Почему он пингуется, я не знаю, но догадываюсь - видимо потому, что доступ к самому свичу контролируется отдельным ACL-ом вида "CPU protection...".

Как бы то ни было, клиент и свич прекрасно знают MAC-адреса друг друга, и потому я счел отдельные правила про ARP излишними. Однако если вы думаете, что явное упоминание об ARP может помочь, я, конечно, попробую. Будет странно, если поможет, но все и без того уже странно

Странно, не странно, а помогло (я имею в виду разрешение для ARP).

После его добавления (а также добавления разрешающего правила для IP) все заработало. А правило разрешающее доступ к MAC-адресу свича оказалось вообще лишним; все работает и без него. Тем более, что и MAC-адрес свича оказался неправильным (я взял его из Web-интерфейса свича). Наблюдения за ARP-таблицей на клиенте показали, что для маршрутизации свич пользуется MAC-адресом, на единицу большим.

Спасибо.

Рад слышать! Не странно а правильно. В исходном ARP пакете не все адреса определены. А по поводу MAC-адреса отличающегося на единицу, свитч L3 на каждый интерфейс назначает свой MAC-адрес из диапазона.