Конфликт mac адресов роутер

Уважаемая тех. поддержка. Помогите решить проблему

Установили в качестве WireLess клиента DWL-2100. По какой-то непонятной причине он работает «как роутер» т.е. при обмене пакетами с AccessPointом подменяет МАС адреса, подключенных к нему по Ethernet пользователей на свой МАС адресс. По этой причине все компьютеры находящиеся за WireLess клиентом DWL-2100 подключаются к серверам сети с разными IP, но с одним и тем-же МАС адресом (адресом самого DWL-2100).
Пробовали сбрасывать все настройки на заводские, залили самую последнюю прошивку v210eu-r0338. Ничего не помогает. WireLess клиент все равно упорно заменяет МАС адреса на свой.

Не смотря на то, что устроство как-бы работоспособно (в режиме «Точки доступа» работает нормально), фактичеки мы не можем пользоваться приобретенным оборудованием по назначению.

режим варелесс клиента служит для подноключения ОДНОГО компа к беспроводной сети. при этом 2100 выдают своё мак точки доступа(ибо она и производит подключение а не то что за ней)
для соединения проводных сетей служит режим WDS. если при этом к точке доступа нужно подключить ещё и беспроводных клиентов то WDS with AP.
переводится в веб интерфейсе путём выбора режима и прописования маков друг друга.

Спасибо за совет, но к сожалению такой вариант не подойдет, нужен именно режим клиента.
А вообще странно.
Почти за четыре года опыта работы с WireLess оборудованием стандарта 802.11b/g это первый такой случай непредсказуемого поведения Точки доступа работающей в режиме «Client».
Если не считать единственного случая, когда DWL-2000AP+ rev.B2 с прошивкой 2.11 включенный в режиме «Repiter» через 10-20 минут работы начинал подменять все проходящие через него МАСи на свой.

Тоже сталкивались с такой проблемой. Решается она просто — ставьте 2100 не в режим клиента (AP Client), а в режим моста (AP Repeater). В таком режиме она не подменяет клиентские маки на свой.

Небольшая поправка — AP Repeater это не мост, а повторитель. Мост — WDS. И еще одна поправка — и мост и повторитель работают только между одинаковыми точками доступа.

У нас такая же проблема — подменяет MAC-и

Но вот один интересный нюанс, о котором почти никто не написал:

когда ставишь режим WDS, или WDS+AP, или вклоючаешь режим репитера, проблема с MAC-адресами исчезает, НО. про шифрование WPA можно позабыть насовсем — нет его при вышеупомянутых режимах ! А шифрование WEP c длиной 128 b — слишком простенькое и ключик подобрать, учитывая современный уровень развития начинающих хацкеров является делом совсем простым.

Ладно бы сетка домашняя была, а то ведь госучреждение.

Версия прошивки — 2.10 EU (DWL2100AP-firmware-v210eu-r0338.tfp), WDL 2100AP

Специалисты D-link утверждают, что в последней _Beta_ — версии прошивки (вероятно, подразумевается DWL2100AP-firmware-v220eu-r486-master-IC.tfp) WDS+wpa реализовано, да вся штука в том, что сама по себе эта прошивка глючная до невозможности и это не только мое мнение.

Вот и возникает вопрос — когда же, наконец, будет нормальная рабочая прошивка ?

Последний раз редактировалось Ray_Y Пт июл 14, 2006 11:21, всего редактировалось 1 раз.

мост работает с броадкомовским чипсетом.

Давно юзаем 220 скачанную с немецкого фтп. Нравится

Вообщем аналогична проблема, 2 девайса 2100 АР.. в режиме моста работает все нормально. Расточние между точками 300 метров, в прямой видимости. Но есть одно но . Скорость не прыгает более 3 метров в секунду. Дочитался на форуме, что скорость всем нам обещаня 108 мегабит, работает только в связке клиент-точка, гарантий, что точка будет работать на такой скорости в режиме моста нет.. точнее насколько я понял из ответа, работать не будет. Вообщем перевожу точки в режим клиент — точка. Ура открылся второй канал как описано в характеристике технологии 108 мегабит, скорость в реале около 4.5 метров, с прыжками от 4 до 5.. Скажем так, если ятнуть фильм, то около 4 .. если мп3 перепысывать то да 5.4 метров в сек прыгало, т.е. песня — 1 секунда. Но начался сдешний глюк описаный више, и глюк идет от точки которая стоит в режиме клиента. Как я решил эту проблему . Я поменял на точках IP адреса . в сети у меня стоит везде 10,2,ххх.ххх , а АП точек я сменил на 192,168,30.ххх В итоге получилось, что точки работают нормально, т.к. они по сути дела выступают в роли моста, с точки зрения сети, и скорость осталась прежней на уровне 4-5 метров в сек.. Пропали конфликты Ап адресов. Но осталась проблема, когда пользователь который сидит за точкой доступа (которая стоит в режиме клиент) сканит сеть на предмет ресурсов тем же Ланскопом, то фаервол реагирует, и расценивает это как атаку, закрываю фаервол, конфликта Ап нет. вот седня это все сделел, думаю за пару дней виден будет результат..

Вот и получается что или выбирай скорость или безглючность.

Источник

D-Link Switches: Tips & Tricks

Продолжаем тему прошлой заметки. Здесь пойдет речь об очевидных и не очень последствиях появления «конфликтующих» MAC-адресов.

Самой очевидной проблемой, конечно же, будет отсутствие всех «пересекающихся» MAC-адресов в таблице коммутации. При получении кадра, адресованного такому MAC’у, коммутатор не сможет определить порт назначения (Destination Lookup Failure, DLF) и кадр будет отправлен во все порты, являющиеся участниками данного VLAN, кроме того, откуда данный кадр был получен. Тем самым коммутатор (свитч) превращается в концентратор (хаб), т.е. не справляется со своей основной задачей — коммутацией трафика. Чем больше пересекающихся MAC-адресов в сети, тем больше лишнего трафика по ней перемещается. Часть кадров при этом может теряться и конечный потребитель не получает небходимой «скорости».

Как решение здесь напрашивается сегментация сети на VLAN’ы меньшего размера, вплоть до vlan-per-user. Широковещательный домен при этом уменьшится, количество передаваемого по сети мусора тоже. В случае vlan-per-user проблема, казалось бы, устраняется полностью. Но не все так просто.

Есть еще два VLAN, которые не могут быть уменьшены слишком уж сильно. Это управляющий (management) и мультикаст (mvr) вланы. Поскольку конфликты запросто происходят между разными влан, то пересечение с абонентским MAC может вызвать «замусоривание» управляющего влана либо ухудшение работы IPTV*.

Следующая проблема — сам механизм обнаружения таких конфликтов (enable flood_fdb), где производятся вычисления, аналогичные тем, что выполняются в ASIC. То есть это не извлечение проблемного адреса из недр памяти, а вычисление, проводящееся параллельно работе чипа. Только в этом случае расходуются уже ресурсы CPU. Отсюда следует, что большой поток трафика может привести к ненужной нагрузке на CPU. На практике, к сожалению, так и получается. В модели DES-3028 CPU уходит в 100% загрузку и устройство становится недоступным. При том, если коммутатор выступает в роли релей-агента, то абоненты перестают получать адреса от DHCP. На DES-3200-28/A1/B1 ситуация несколько отличается — коммутатор с некоторой вероятностью не может ответить на ARP-запрос. Когда время жизни arp на маршрутизаторе истекает, коммутатор на некоторое время становится недоступен. Результатом будет «моргающая» карта сети.

Комментарий D-Link:
Ситуация вызвана тем, что flood_fdb (как и обсуждалось ранее) — софтовый функционал. Исправить это нет никакой возможности, рекомендация — использовать flood_fdb только для анализа проблемных ситуаций и не держать его включенным повсеместно на сети.
Загрузка cpu будет напрямую зависеть от количества, типа трафика и пр, но каких-то конкретных значений pps сказать не представляется возможным.

Таким образом, использовать flood_fdb можно только в не нагруженных сетях без мультикаста.

Еще одна проблема, предположительно связанная с «конфликтом hash» — глюки дополнительного функционала коммутаторов. Например, IP-MAC-Port Binding в режиме DHCP Snooping блокирует кадры от абонента несмотря на наличие валидной связки в своей таблице.

Ну и последнее — затруднительная диагностика проблем абонентов из-за отсутствующих на порту MAC’а адресов. То есть сразу не понятно, имеем ли мы конфликт hash или же просто что-то не так включено у самого абонента. При этом, как мы помним, flood_fdb выключен, т.к. его включение чревато потерей доступа.

Вывод: Конфликтующие MAC-адреса, помимо явной проблемы с коммутацией трафика рано или поздно приведут к труднодиагностируемым побочным проблемам. Единственный правильный выход из ситуации — физически сегментировать сеть, тем самым уменьшая общее количество MAC-адресов на проблемных устройствах**.

Меры, помогающие снизить ущерб:
1. Уменьшение размеров абонентских VLAN.
2. Уменьшение размера управляющего VLAN.
3. Отказ от использования MVR (мультикаст вещается в абонентском VLAN или не вещается вовсе).
4. Отключение изучения MAC-адресов на коммутаторах, включение сегментации трафика, когда абонент может передать кадр только в аплинк, использование auto_fdb (если позволяют свободные ресурсы коммутатора).
5. Установка проблемных коммутаторов** в конец цепочки.
6. Отказ от использования функционала IMP

Эти меры помогут выиграть время для грамотного перепланирования сети.

* Мультикаст вещается на специальные адреса для групповой рассылки, которые обрабатываются коммутатором несколько иначе, чем обычные адреса, но пересечения MAC все равно могут приводить к описанной проблеме.
** Все вышенаписанное применимо, прежде всего, к DES-3028 и DES-1228/ME/A1. На DES-3200 проблема практически никогда не достигает серьезных масштабов

Источник