Сеть состоит из нескольких подсетей, в центре стоит маршрутизатор от Цыски, в каждой подсети в узловых точках стоят DES-3010G на которых через телнет прошивается таблица соответствий ip - mac. Один из клиентов имеет роутер DIR-320 mac wan порта которого прописан в таблице ip-mac binding свича DES-3010G. Если у роутера на wan порте не подымать vpn соединение на NAS сервер (L2TP или PPTP), то все работает идеально. Как только подымается впн, то через несколько секунд работы в инете (аська успевает подконнектится на компе) мак роутера попадает в таблицу ip-mac binding blocked. На роутерах прописана еще таблица маршрутизации.
Где искать грабли?

Посмотрели на NAS-сервере - протокол ВПН подымается нешифрованный, получается что коммутатор каким-то образом в пакете с mac адресом роутера видит айпи который выдал ему впн сервер, а так как он не соответсвует прибитому, то блокирует его...

Нет, такого быть не может.

Запустите на клиентском порту зеркалирование и похватайте клиентский трафик с момента включения роутера до момента его блокировки. Пришлите сниф в формате pcap мне на почту, попробуем разобраться.

есть аналогичная проблема с DES-3026 (разные свичи разные прошивки) и четырмя dir-300 (тоже стоят на разных свичах) когда 2+ клиента и один обязательно win7
тоже pptp не шифрованное

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

пришлось этим людям отключить IPMAC


небыло не времени не желания разбираться.. и эти 4 человека только те кто позвонил. наверняка есть еще абоненты у кого сработала блокировка и они грешат на dir-300... а не звонят провайдеру в тех поддержку

_________________
Умная книжка по теории сетей и настройкам свичей:
ftp://ftp.dlink.ru/pub/Trainings/Switch_D-Link_newest_Basic.pdf

отправил мылом. попытлся сам почитать лог...

сразу роут подключается в сеть с айпи 192.168.5.222:
Sender MAC address: Tp-LinkT_ca:6b:e5 (00:1d:0f:ca:6b:e5)
Sender IP address: 192.168.5.222 (192.168.5.222)

затем идет подключение к впн серверу и роутер для впн получает айпи 91.210.10.242
Sender MAC address: Tp-LinkT_ca:6b:e5 (00:1d:0f:ca:6b:e5)
Sender IP address: 91.210.10.242 (91.210.10.242)

после этого этот мак попадает в таблицу блокировок...

на серии DIR это лечится сменой режима с Russian PPTP Dual Access на простой PPTP

так в том то и дело, что при поднятом впн нужна и локалка. при работе роутера в простом PPTP вроде таблица маршрутизации не работает...

подведем итог:

1)ответ техподдержки:
Пакет № 518. Роутер зачем-то шлёт ARP запрос от адреса 91.210.9.236. Этого запроса не
должно быть вообще, фактически это ошибка в прошивке роутера. Коммутатор правильно делает,
что блокирует его, он не соответствует валидной связке IP-MAC

2)идем на тп-линк и пишем там http://forum.tp-link.su/viewtopic.php?f=5&t=3&start=40 Получаем ответ:
да - действительно, такая проблема сущестовала с серией tp-link, начиная с 340G модели, и заканчивая 642. Вы всё верно расписали. Мы эту проблему обнаружили, когда пустили icmp пакеты на внутренний айпи роутера, и когда роутер поднят туннель - он стал отвечать на эти запросы с внешнего айпи, как и в вашем случае. Эта проблема решена в 542G v7 в прошивке TL-WR54xG_V7_091015 со слов разработчиков, но я ещё постараюсь это уточнить.Вы указали что у вас хардварная версия 4, но прошивка 4.3.3 Build 091015 Rel.73367n. Прошивка от 7 версии на 4 не встанет, вы имеете ввиду, что у вас тестовая прошивка, или как?...
на тестовой прошивке не добавлен фикс данной проблемы, этот фикс был добавлен в конечную версию прошивки для хардварной версии 7.
Я думаю, что для 4 версии больше не будет прошивок, т.к. производитель TP-LINK изменил политику компании, скорее всего более 542 не будут выпускаться...

ЗЫ. Девайс, который отработал 1 год уже можно выкидывать на свалку...

Так покупайте наши роутеры!:)