На АСР уже приходит трафик без внешней метки. Т.к. это на экстриме cep(client edge port) аналог вашего UNI.
Хочу еще раз отметить, что при использовании 3120 такого не повторялось. Если нужно, могу повторить эксперимент с 3120. Не исключаю и своей ошибки. Но согласитесь, что смешать два влана в один(замылить одну из меток), но в то же время отдать влан на АСР с внутренней меткой 206 - какая то мистика.
Еще у меня вопрос, QinQ аппаратная фишка данного свича?
И насколько мне известно вайршарк не показывает тегов.
По кр мере у меня не получалось этого добиться, буду рад совету.

По вайресшарку - это зависит от драйверов на сетевую карту.

Все верно, wireshark 802.1q метки показывает. Вам лучше на транзитном DGS-3120 поймать проходящие через него пакетики и посмотреть, какие в них метки.

Драйвер на сетевуху интелловый стоит. Сам теги может генерировать, но теги вайршарк не показывает(ос вин7).

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

Разобрался с сетевой картой.
Теперь отображает теги. Сделал захват на 1ом 3120.
Вот что обнаружилось.
3200 честно упаковывает все пинги в два тега.
А вот ответ от интерфейса 192.168.0.1 приходит только со внешним тегом, что по сути и должно происходить(внутренний тег никак ему не мог назначиться). Стало быть проблема где то выше, но все бы ничего, но зачем его тогда 3200 передает на клиентский порт? Или он не может не передавать?
Т.е. получается, что в каком бы влане не пришел пакет, при такой схеме 3200 его освобождает от тегов и высылает на UNI порт?


Капча во вложении, проще будет наверное фильтрануть по icmp

К сожалению не могу отмониторить порт на экстриме, через rspan, т.к. этот порт одновременно и даунлинк ко мне и даунлинк к нашей схеме.
А экстрим ненавидит такие команды в сочетании:
* KZN-Lavr-x670.13 # enable mirroring to port 9 remote-tag 73
* KZN-Lavr-x670.14 # conf mirroring add port 9 vlan "Test-QinQ"
Error: Monitor port cannot be mirrored

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

Согласитесь, это не очень хорошо, когда пользователь может видеть ingress трафик с другого влана? Как то можно запретить это делать? Фильтровать там как то, разрешать только кадры с внутренним тегом?

Он ничего и не будет видеть, если с другой стороны все верно настроено. Когда Вы настраиваете Q-in-Q Port-Based, то коммутатор на весь клиентский трафик навешивает второй тег и также потом в обратном направлении внешний тег снимает. Если там только одна метка, то на выходе будет просто untag трафик, который и поступает клиенту. То есть, нужно так настроить оборудование с другой стороны, чтобы и обратном направлении трафик был с двумя тегами, что вполне логично.

По сути нужно, чтобы во "внешнем" влане не ходило никакого трафика. Если трафик все же ходит, то абонент может его видеть. Я Вас правильно понял?

Трафик должен быть в таком формате, в каком его ждет клиент. Если Вы навешиваете два тега, а в обратку у Вас только один приходит, то схема конечно не будет полноценно работать.

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

У Вас клиент посылает трафик и он же его обратно получает. MAC-адрес не меняется, причем здесь злоумышленник?

Давайте рассмотрим случай, когда на UNI порту сидит "умный" пользователь и кроме того, что он принимает и отправляет свой траф, он еще и мониторит, что к нему приходит на порт.
В случае если во внешнем влане что-то ходит, например броадкаст какой то, то он его получит.