Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Таблица MAC-адресов в коммутаторе
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Fast Ethernet/Gigabit Ethernet/FibreChannel
troiden
Сначала вводная часть:
В простейшем случае есть схема, представленная в прикрепленном файле. 1 и 2 - устройства на базе FPGA с гигабитным портом, 3 - обычный компьютер, всё это связано через обычный неуправляемый коммутатор. Устройство 1 шлет UDP-поток данных на устройство 2, в котором происходит обработка, и результирующие данные отсылаются опять-таки через UDP с 2 на компьютер 3. По логике работы, в коммутаторе есть таблица соответствия MAC-адресов портам и в нормальном режиме работы коммутатор должен слать поток от устройства 1 только на четвертый порт, а на восьмом пакетов этого потока быть не должно, и соответственно данные с устройства 2 должны приходить только на восьмой порт. Именно такое поведение наблюдается, если слать данные с 2 на 3 или напрямую с 1 на 3 - пакеты приходят только на восьмой порт, остальные остаются неактивными.
Однако если слать данные с 1 на 2, то коммутатор начинает спамить пакетами на все порты. Насколько я понимаю, это связано с отсуствием записи в MAC-таблице коммутатора о соответствии устройства 2 определенному порту.
Ну а теперь сам вопрос: как добавить эту запись?

Что было испробовано:
1. Устройство 2 шлет UDP-поток на 3.
2. Устройство 2 шлет широковещательные ARP-сообщения со своими MAC и IP адресами.
3. Устройство 2 шлет ICMP echo запрос (Ping) на 3.
4. Устройство 2 принимает ARP-запрос со своим IP-адресом и отвечает отправителю верным ARP-ответом.

Однако же, ни один из приведенных методов ассоциации устройства определенному порту не вызвал.

Совместное использование двух последних решений привело к тому, что устройство 2 может беспрепятственно пинговать компьютер 3, т.е. через коммутатор проходит цепочка сообщений Ping request от 2 к 3 -> ARP request от 3 к 2 -> ARP reply от 2 к 3 -> Ping reply от 3 к 2. Следовательно, сами сообщения составлены правильно, через коммутатор проходят, но желаемого результата не дают.

Куда следует копать дальше? Может, для заполнения MAC-таблицы нужны TCP-пакеты?
halfdoom
Цитата(troiden @ Apr 5 2012, 22:02) *
Куда следует копать дальше? Может, для заполнения MAC-таблицы нужны TCP-пакеты?

Скорее всего, где-то есть отклонения от стандарта, т.е. пакет нормальный и правильно пропускается, но что-то мешает попаданию МАК-адреса в таблицу. У меня была похожая проблема (правда, с управляемым коммутатором) - устройство отвечало на ARP пакеты одним адресом, а исходящий UDP поток шел от другого. Вроде ничего особенного, но UDP поток появлялся на всех подключенных портах.
kolobok0
Цитата(troiden @ Apr 5 2012, 23:02) *
...Куда следует копать дальше? Может, для заполнения MAC-таблицы нужны TCP-пакеты?


1) надо для начала убедиться, что "неуправляемый коммутатор" имеет диспетчирезацию на MAC уровне. И что это не простой хабик.
2) убрать все не известные и протестировать коммутатор отдельно в сети. понять что он работает корректно.
3) UDP поток адресуется как? конкретно адресу или широковещательно?
4) Что происходит если через коммутотор послать UDP пакет конкретному адресу с персоналки например? Он так же виден другими адресами?


маки уникальны я надеюсь...
удачи вам
(круглый)
tolik1
Цитата(troiden @ Apr 5 2012, 22:02) *
Куда следует копать дальше? Может, для заполнения MAC-таблицы нужны TCP-пакеты?

Начните с того, что замените устройства с FPGA на персональные компы и симитируйте на них обмен данными. Если эффект повторится, то меняйте коммутатор, если нет - смотрите реализацию UDP на FPGA.
PS 1)по личному опыту знаю, что таблица ARP может периодически обновляться(получается примерно что и у Вас)
2)А на сколько Вас вообще это напрягает?
troiden
В результате экспериментов проблема обнаружилась там куда даже не думалось - как оказалось, при всех тестах случайно задавался групповой MAC-адрес. При смене первого байта адреса всё стабилизировалось, для обновления таблицы в коммутаторе хватает периодического посыла широковещательного ARP-сообщения.

Цитата
2)А на сколько Вас вообще это напрягает?

Напрягало сильно. Мало того что поток не доходил до целевого устройства целиком, так еще и вся сеть сильно проседала.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.