survivor Опубликовано 22 января, 2010 · Жалоба Доброго времени суток! Хочу посоветоваться :-) Что конкретно может сделать плохого (преднамеренно или нет) ADSL клиент и как с эти бороться. Мои размышления на эту тему таковы: 1) два клиента могут соединить свои модемы езернетом, перевести модемы в бридж и сделать петлю на Л2. Когда это плохо? Учитывая что на дсламах есть изоляция портов, самому дсламу от этого плохо не будет. плохо будет свичу, если абоненты сидят на разных дсламах, а они одним вланом идут в этот свич. Если даже на свиче будет stp это не сильно поможет так как он заблокирует целый порт, то есть дслам. Значит - нужно обязательно дсламы держать в разных вланах или использовать switchport protected (поможет ли он в этом случае?) или один влан-один пользователь или... 2) абонент может уделать дслам или следующий за ним свич невообразимым количеством мак адресов и повесить их, забив соответствующие таблицы в их памяти. На дсламах в принципе есть ограничение на количество маков с каждого порта, так что это не проблема. 3) могут появиться абоненты с одинаковыми маками на разных портах, разных дсламах (левые модемы, игры с сетевыми картами, опять же петли между абонентами и т.д. вообщем бывает), тут вроде как дсламу ничего не повредит, учитывая изоляцию портов, однако на некоторых есть функция антиспуфинга, когда дслам сам шатдаугит порты с одинаковыми маками... зачем тогда эта фича? Вот свичу который идет за дсламом могут одинаковые маки не понравится - даже если они в разных вланах, ведь мак подразумевает уникальность и может он свою таблицу (мак/порт) строит не per-vlan и тогда могут быть проблемы, что скажете? 4) клиент может поставить себе мак pppoe сервера, тогда это не понравится свичу в котором сидит bras и дсламы. Единственное что приходит в голову ставить Л2 acl на порт свича в сторону дслама и фильтовать мак bras'а. Или? 5) еще может быть флуд от клиента на Л2 - просто очень много пакетов до браса со скоростью adsl соединения. Это актуально если подключать абонентов с максимально возможной скоростью по adsl а затем ограничивать скорость на брасе. Это бывает нужно если хочется предоставлять iptv в отдельном pvc в multicast влане. Тогда можно просто зафлудить брас. Шторм контроль на свиче не поможет, так как заблокирует целый порт, то есть брас. На дсламах я такой фишки не видел. Ну вот пока все... Что скажете? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bambuk Опубликовано 22 января, 2010 · Жалоба 1) самому дсламу от этого тоже станет плохо, точнее абонентам в том влане где петля, т.к. через петлю может прийти в том числе и мак адрес шлюза или pppoe сервера. в результате съедет таблица форвардинга и все перестанут работать. 4) как показала практика acl у многих вендоров работают странно. трафик дальше не пускают, но локальную таблицу мак адресов портят. лучше решать проблему радикально. каждый порт в отдельный влан + ограничение на разумное количество маков с порта. только надо обеспечить чтоб до браса был свитчинг по mac+c-vlan, при упаковке в QinQ получится mac+s-vlan, что может доставить неприятности с одинаковыми маками из разных сторон в разных c-vlan. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Картуччо Опубликовано 22 января, 2010 · Жалоба АДСЛ провайдер, которым я пользуюсь, пускает только оговоренные мак адреса. Любое изменение, добавление - по бумажному заявлению в офисе от владельца телефонной линии с документом. Как фильтруют не знаю, дисламы вроде хуавей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 22 января, 2010 · Жалоба АДСЛ провайдер, которым я пользуюсь, пускает только оговоренные мак адреса.Любое изменение, добавление - по бумажному заявлению в офисе от владельца телефонной линии с документом. Как фильтруют не знаю, дисламы вроде хуавей. в моем регионе это невозможно :-) к сожалению Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 22 января, 2010 · Жалоба 1) самому дсламу от этого тоже станет плохо, точнее абонентам в том влане где петля, т.к. через петлю может прийти в том числе и мак адрес шлюза или pppoe сервера. в результате съедет таблица форвардинга и все перестанут работать.4) как показала практика acl у многих вендоров работают странно. трафик дальше не пускают, но локальную таблицу мак адресов портят. лучше решать проблему радикально. каждый порт в отдельный влан + ограничение на разумное количество маков с порта. только надо обеспечить чтоб до браса был свитчинг по mac+c-vlan, при упаковке в QinQ получится mac+s-vlan, что может доставить неприятности с одинаковыми маками из разных сторон в разных c-vlan. один порт - один влан конечно многое решает, но я себе не смогу такого позволить... да и опять же получу одинаковые маки в ядре под разными вланами... Вообщем, проблема безопасности по всем пунктам не надумана, давайте вместе обмозгуем :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
p10neer Опубликовано 22 января, 2010 (изменено) · Жалоба 1) два клиента могут соединить свои модемы езернетом, перевести модемы в бридж и сделать петлю на Л2. Когда это плохо? Учитывая что на дсламах есть изоляция портов, самому дсламу от этого плохо не будет. плохо будет свичу, если абоненты сидят на разных дсламах, а они одним вланом идут в этот свич. Если даже на свиче будет stp это не сильно поможет так как он заблокирует целый порт, то есть дслам.Значит - нужно обязательно дсламы держать в разных вланах или использовать switchport protected (поможет ли он в этом случае?) или один влан-один пользователь или... 2) абонент может уделать дслам или следующий за ним свич невообразимым количеством мак адресов и повесить их, забив соответствующие таблицы в их памяти. На дсламах в принципе есть ограничение на количество маков с каждого порта, так что это не проблема. 3) могут появиться абоненты с одинаковыми маками на разных портах, разных дсламах (левые модемы, игры с сетевыми картами, опять же петли между абонентами и т.д. вообщем бывает), тут вроде как дсламу ничего не повредит, учитывая изоляцию портов, однако на некоторых есть функция антиспуфинга, когда дслам сам шатдаугит порты с одинаковыми маками... зачем тогда эта фича? Вот свичу который идет за дсламом могут одинаковые маки не понравится - даже если они в разных вланах, ведь мак подразумевает уникальность и может он свою таблицу (мак/порт) строит не per-vlan и тогда могут быть проблемы, что скажете? 4) клиент может поставить себе мак pppoe сервера, тогда это не понравится свичу в котором сидит bras и дсламы. Единственное что приходит в голову ставить Л2 acl на порт свича в сторону дслама и фильтовать мак bras'а. Или? 5) еще может быть флуд от клиента на Л2 - просто очень много пакетов до браса со скоростью adsl соединения. Это актуально если подключать абонентов с максимально возможной скоростью по adsl а затем ограничивать скорость на брасе. Это бывает нужно если хочется предоставлять iptv в отдельном pvc в multicast влане. Тогда можно просто зафлудить брас. Шторм контроль на свиче не поможет, так как заблокирует целый порт, то есть брас. На дсламах я такой фишки не видел. 1. На портах дслама фильтры по ethertype (pppoe), на портах коммутаторов, в которые включены дсламы, mac access-group in с запретом маков bras'ов, глючных сетевых и нулевых. QinQ тоже используется если железо позволяет.2. Ограничение на количество мак-адресов с порта. Плюс у некоторых дсламов есть защита от DoS атаки с помощью PADI и DHCP запросов, слишком активный порт просто кладется минут на 20. 3. Если одинаковые маки на одном дсламе, то есть защита от spoofing'а. Порт с которого мак пришел первый продолжает работать, второй порт кладется. Если маки с разных дсламов, то уже не тривиально :( жалобы от техподдержки, просмотр syslog'ов с коммутаторов на предмет %SW_MATM-4-MACFLAP_NOTIF. Причем помниться вирус у одного клиента попортил нам нервы, он сниферил маки в том же влане и подставлял их себе, причем catalyst 3550 молчал, как рыба об лед :( catalyst 3750 сыпал же сообщения о мак флаппинге. Один из выходов - QinQ, хотя еще есть вариант - VMAC, дслам меняет клиентский мак на заранее прописанный, в зависимости от номера порта и ip дслама. 4. Опять mac access-group in с запретом маков всех брасов. 5. Просто много бродкаста? Что-то типа storm-control, но на уровне порта дслама? Надо доку посмотреть. Хотя ограничения обратного канала в adsl является естественным сдерживающим фактором. Вот когда будет VDSL2+, тогда да :( Использовалась информация о дсламах: D-Link DAS-3248 rev.A, ECI HiFocus4, Teledata BroadAccess1000, Ericsson EDN312xp. Есть еще немного Huawei MA5600 и Zyxel IES-2000/3000, но я с ними плотно не работал, надо доку смотреть на предмет секурных фич. один порт - один влан конечно многое решает, но я себе не смогу такого позволить... да и опять же получу одинаковые маки в ядре под разными вланами...Одинаковые маки до ближайшего браса, причем каждый мак в своем личном влане, так что QinQ - один из лучших вариантов. В одном операторском влане - 4к пользовательских. Изменено 22 января, 2010 пользователем p10neer Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 25 января, 2010 · Жалоба кстати, начиная с какой серии в роутерах есть поддержка qinq pppoe? чтобы qinq не на свиче разворачивать, а прямо на bras'е терминировать и там - pppoe? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
JoeDoe Опубликовано 25 января, 2010 · Жалоба qinq не обеспечивает изоляцию пользовательских MAC-ов. В таких случаях предпочтительней MAC-in-MAC. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vIv Опубликовано 25 января, 2010 · Жалоба Что он не обеспечивает? Даже одиночный Q прекрасно делит пространство адресов. Один VLAN - одно пространство адресов, с соседними VLAN не пересекающееся. Можете при VLAN-per-customer вообще всем абонентам один МАС ставить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bambuk Опубликовано 25 января, 2010 · Жалоба Свичи форвардят по MAC+vlan. В случае qinq, MAC'и остаются прежними, а вместо пользовательских vlan появляется общий outer и на inner транзитные свичи не смотрят. Поэтому если в разных inner один и тот же MAC придет из разных мест, то будет плохо, т.к. транзитные свичи ничего про inner не знают, для них есть только outer. В качестве транзита в таких случаях можно еще использовать MPLS PW без MAC learning. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
JoeDoe Опубликовано 26 января, 2010 · Жалоба Свичи форвардят по MAC+vlan. В случае qinq, MAC'и остаются прежними, а вместо пользовательских vlan появляется общий outer и на inner транзитные свичи не смотрят. Поэтому если в разных inner один и тот же MAC придет из разных мест, то будет плохо, т.к. транзитные свичи ничего про inner не знают, для них есть только outer. В качестве транзита в таких случаях можно еще использовать MPLS PW без MAC learning. Спасибо, за раскрытие темы - это я и имел в виду.Не так много в мире коммутаторов, которые могут learning по mac+inner+outer. Точно это делает ALU 7710/7450/7750, но за счёт полного пересмотра концепции vlan в vpls с локальными на порт тагами (как dot1q, так и qinq). Они еще могут mac-in-mac через PBB–vpls связку - но это уже другая история. К сожалению, PW без MAC learning-a (epipe) тоже немногие умеют - часто PW binding идет в стандартный vlan. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 26 января, 2010 · Жалоба попробую немного обобщить.... привязка mac-порт помогает решить проблему с пересекающимися mac'ами, подстановка mac'а браса клиентом тоже становится невозможна, флуд огромным количеством маков со стороны клиента тоже невозможен, с петлями у клиентов должен по идее справится port-isolation на дсламе и switchport protected на каталисте (если петля между абонентами на разных дсламах в пределах одного влана). Это вариант A. Вариант A хорош тем что решает все проблемы, но крайне неудобен и для клиента и для провайдера, которому надо еще следить за актуальностью маков, все это прописывать, сверять, менять и т.д. Вариант B - порт-влан в qinq до браса, хорош тем что позволяет полностью справиться с петлями, прост и удобен, но во первых не решает проблему подстановки мака браса клиентом, хотя с этим легко справиться фильтрами на дсламах. Про пересечения маков внутри одного outer-vlan'а (в котором идет dot1q туннель) насколько я понял проблему не решает? Допустим у меня на АТС-1 есть дслам с 48 портами, соответственно вланы 1-48 и есть два клиента с одинаковыми масами MAC-A, самому дсламу должно быть все равно так как порты в разных вланах, так? Свичу на атс, к которому подключен дслам тоже все равно, так как вланы у пакетов разные, далее свич упаковывает все вланы в один влан 1001 и отправляет в центр, там пакеты, вернее кадры езернет попадают на центральный каталист и он видит что приходят под одним outer вланом 1001 два кадра с одним и тем же MAC-A, он думает что это два разных кадра от одной и той же машины и не паникует, затем отправляет этот outer влан на брас, который распаковывает qinq и получает два кадра в разных сабинтерфейсах с одним маком, как он к этому отнесется? Если нормально то получается, что вариант B тоже решает проблему пересекающихся маков. Проблема может быть только если сделать одинаковые outer вланы в разные направления и принимать их в разных портах на центральном каталисте. Тогда при одинаковых маках на разных атс, центральный свич будет видеть одинаковые маки в одном outer влане на разных портах и это ему уже не понравится :-) Поправьте где ошибся, плз... Минус варианта B - необходимы свичи и брасы с поддержкой qinq, что не дешево. Но плюсы - решение всех (?) проблем без особых трудностей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
p2d Опубликовано 26 января, 2010 · Жалоба попробую немного обобщить....привязка mac-порт помогает решить проблему с пересекающимися mac'ами, подстановка mac'а браса клиентом тоже становится невозможна, флуд огромным количеством маков со стороны клиента тоже невозможен, с петлями у клиентов должен по идее справится port-isolation на дсламе и switchport protected на каталисте (если петля между абонентами на разных дсламах в пределах одного влана). Это вариант A. Вариант A хорош тем что решает все проблемы, но крайне неудобен и для клиента и для провайдера, которому надо еще следить за актуальностью маков, все это прописывать, сверять, менять и т.д. Вариант B - порт-влан в qinq до браса, хорош тем что позволяет полностью справиться с петлями, прост и удобен, но во первых не решает проблему подстановки мака браса клиентом, хотя с этим легко справиться фильтрами на дсламах. Про пересечения маков внутри одного outer-vlan'а (в котором идет dot1q туннель) насколько я понял проблему не решает? Допустим у меня на АТС-1 есть дслам с 48 портами, соответственно вланы 1-48 и есть два клиента с одинаковыми масами MAC-A, самому дсламу должно быть все равно так как порты в разных вланах, так? Свичу на атс, к которому подключен дслам тоже все равно, так как вланы у пакетов разные, далее свич упаковывает все вланы в один влан 1001 и отправляет в центр, там пакеты, вернее кадры езернет попадают на центральный каталист и он видит что приходят под одним outer вланом 1001 два кадра с одним и тем же MAC-A, он думает что это два разных кадра от одной и той же машины и не паникует, затем отправляет этот outer влан на брас, который распаковывает qinq и получает два кадра в разных сабинтерфейсах с одним маком, как он к этому отнесется? Если нормально то получается, что вариант B тоже решает проблему пересекающихся маков. Проблема может быть только если сделать одинаковые outer вланы в разные направления и принимать их в разных портах на центральном каталисте. Тогда при одинаковых маках на разных атс, центральный свич будет видеть одинаковые маки в одном outer влане на разных портах и это ему уже не понравится :-) Поправьте где ошибся, плз... Минус варианта B - необходимы свичи и брасы с поддержкой qinq, что не дешево. Но плюсы - решение всех (?) проблем без особых трудностей. В варианте В именно так и происходит. Ну и на каждое устройство доступа выделяется свой outer vlan, куда без этого, сразу решается вопрос унификации настройки устройств доступа. Но в qinq есть другие недостатки - весь широковещательный трафик в этом vlan тянется транзитом до ядра в случае централизованной модели, и на все транковые порты, где требуется затерминировать inner vlan с этим outer (или где он просто не исключен из транка). Также нельзя затерминировать на близлежащей машинке без поддержки qinq - и тогда все в центр. Всякие выверты вроде qinq mapping для выдергивания inner vlan существенно повышают стоимость решения. А если возникает мультикаст в metro/sp/outer vlan - мама не горюй. Тут же забываем про igmp и qos, если вопрос цены имеет значение.Итого - QinQ плохо масштабируется, но хорош при децентрализованной модели, или в случае централизованной, но с простой топологией уровня агрегации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 30 июня, 2010 · Жалоба Итак - снова здравствуйте! :) за прошедшее время внедрил у себя qinq, сейчас каждый дслам в отдельном влане, все сводится в центр, а там пачка брасов... схема себя во многом оправдала, но не решает всех проблем, о чем собственно говоря и речь. Как оказалось среди клиентов много с одинаковыми маками. Благодаря куинку и разным вланам на дслам, свичи ведут себя спокойно, если такие абоны попадают на разные дсламы и разные брасы. Но если они случайно попадают на один брас или дслам, то начинаются дисконнекты. Ума не приложу, что делать то? Если на некоторых дсламах есть защита от одинаковых маков, которая к тому же не работает (см. http://forum.nag.ru/forum/index.php?showto...p;#entry478893), то что делать с брасами? Единственная мысль, которая приходит в голову - влан на порт, но может есть какие-то другие более экономичные варианты? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 30 июня, 2010 · Жалоба 5. Ну будет пусть даже 25 мегабит от абонента к брасу - ну и что? Вон например ЭР-Телеком дают 100мбит эзернетчикам внутри своей сети через BRAS. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дятел Опубликовано 30 июня, 2010 · Жалоба Единственная мысль, которая приходит в голову - влан на порт, но может есть какие-то другие более экономичные варианты? а чем она неэкономичная? какое число абонентов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 30 июня, 2010 · Жалоба а чем она неэкономичная? какое число абонентов? Тем, что либо нужно разворачивать все вланы в центре перед заводом на пачку брасов, а тогда количество клиентов ограничивается 4096, либо терминировать QinQPPPoE прям на брас, а мое железо такого не умеет... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yakuzzza Опубликовано 30 июня, 2010 · Жалоба Изолировать порты + фильтровать по макам на дсламе. Влан на абонента не надо. Что-то вы тут такое сложное напридумывали. Проще надо быть. А если абонент завалит брас или дслам - поднять логи и оторвать голову абоненту. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 30 июня, 2010 · Жалоба Если используется vlan на dslam и на каждый порт прописывается мак и выключается learning, то qinq не нужен. А вот если фильтра по макам нет, id порта в pppoe не вставляется/не обрабатывается, то о qinq есть смысл задуматься, чтобы точно знать с какого порта пришёл тот или иной запрос(чтобы не воровали mac-адреса и логины/пароли) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 30 июня, 2010 · Жалоба А если абонент завалит брас или дслам - поднять логи и оторвать голову абонентувашими устами, как говориться, да - меду... фильтровать по макам на дсламеу меня клиенты по портам "гуляют" (монтеры развлекаются), так что привязать клиента к порту нет возможности... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yakuzzza Опубликовано 30 июня, 2010 (изменено) · Жалоба А если абонент завалит брас или дслам - поднять логи и оторвать голову абонентувашими устами, как говориться, да - меду... фильтровать по макам на дсламеу меня клиенты по портам "гуляют" (монтеры развлекаются), так что привязать клиента к порту нет возможности... У вас провайдинг или завод? Даже если у вас 2 дслама то все документировать, иначе будет бардак. Монтерам тоже клизмы. В конце концов у нас не развлекалово, а работа. Изменено 30 июня, 2010 пользователем yakuzzza Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 1 июля, 2010 · Жалоба Даже если у вас 2 дслама то все документироватьпричем тут это? у меня все документировано... Монтерам тоже клизмыМонтеры работают в телефонной компании - за их адекватность ручаться не могу, да и ссорится с ними не желательно :) Давайте решать ТЕХНИЧЕСКИЙ вопрос, а не АДМИНИСТРАТИВНО-ОРГАНИЗАЦИОННЫЙ :) пожалуйста Вопрос же в том, как бороться (технически) с дублированием маков в сети адсл провайдера... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yakuzzza Опубликовано 1 июля, 2010 · Жалоба Очень часто вместо технически долгого решения легче организационно быстро решить. Это как запретить порносайты ;) А не надо ни с кем ссориться. Пусть просто каждый выполняет свою работу. А теперь как технически бороться с одинаковыми мак-адресами: биллинг с мак-адресами. Добавляете клиента - автоматически проверяется мак, есть такой - пусть меняет или несет оборудование к вам. Вот вам опять же пример того, как легче решить технический вопрос организационным методом. Метод менее гибкий и больше ручной работы, но при фильтрации по макам и со статической арп-таблицей на адсл-вланах вопросов практически не будет. Как-то так. Как бороться технически - разве что привязывать маки к портам. Не поймите за наезд, но у вас то нельзя ссориться, то абоненты плавают, то организационно не надо, а надо технически. Вырабатывайте политику и правила работы в сети и не будет проблем. А кто не согласен - вам уже здесь много чего рассказали почему так или так надо делать. Не от большого желания привязывают маки, фильтруют на портах итд итп. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 1 июля, 2010 · Жалоба yakuzzza УФФ... технические способы - зависят от возможностей оборудования, которое в большей степени соответствует интернациональным стандартам, и поэтому их можно легко обсуждать на форумах с людьми из других государств работающих на других рынками с другими законами и менталитетом. Поэтому я и обсуждаю ЭТОТ способ решения проблемы. Организационные способы (подходящие для моих условий) известны мне лучше чем кому-либо, поэтому их хотелось бы не касаться, а учитывать как вводные для технической задачи. А то вы прям как янки приходите на другой конец мира и говорите как тут надо жить... привязать маки, сделать отдельные вланы - ежу понятно что можно, я и сам сказал, что знаю эти решения. Я жду от дорогого и уважаемого комьюнити какой-то идеи, которую может быть упустил из виду. ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yakuzzza Опубликовано 1 июля, 2010 · Жалоба Да ради Бога. Я 130 лет собираюсь прожить и поэтому спорить не буду (старый анекдот). Привязывайте ИП к макам, ставьте arpwatch, пхайте все вланы в этот таз и трекайте логи арпвотча и коммутаторов доступа. Идеи все уже высказали. А, еще я не янки, я просто люблю спокойно спать ;) Все что я сказал - не более личного опыта. --- Удачи. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...