Мы медленно начинаем внедрять отслеживание DHCP-трафика на коммутаторах серии HP ProCurve 2610, на которых установлено микропрограммное обеспечение R.11.72. Я наблюдаю какое-то странное поведение, при котором пакеты dhcp-request или dhcp-refresh отбрасываются при исходящих от «нисходящих» коммутаторов из-за «ненадежной информации о реле от клиента».
Полная ошибка:
Received untrusted relay information from client <mac-address> on port <port-number>
Более подробно у нас есть 48 портов HP2610 (Switch A) и 24 порта HP2610 (Switch B). Коммутатор B является «нисходящим» коммутатором A благодаря DSL-соединению с одним из портов коммутатора A. Сервер DHCP подключен к коммутатору A. Соответствующие биты следующие:
Переключатель A
dhcp-snooping
dhcp-snooping authorized-server 192.168.0.254
dhcp-snooping vlan 1 168
interface 25
name "Server"
dhcp-snooping trust
exit
Переключатель B
dhcp-snooping
dhcp-snooping authorized-server 192.168.0.254
dhcp-snooping vlan 1
interface Trk1
dhcp-snooping trust
exit
Коммутаторы настроены так, чтобы доверять ОБА порту, к которому подключен авторизованный DHCP-сервер, и его IP-адресу. Все это хорошо и хорошо для клиентов, подключенных к коммутатору A, но клиенты, подключенные к коммутатору B, получают отказ из-за ошибки «ненадежная информация о реле». Это странно по нескольким причинам: 1) dhcp-relay не настроен ни на одном из коммутаторов, 2) сеть уровня 3 здесь плоская, та же подсеть. Пакеты DHCP не должны иметь измененного атрибута опции 82.
Однако dhcp-relay, похоже, включен по умолчанию:
SWITCH A# show dhcp-relay
DHCP Relay Agent : Enabled
Option 82 : Disabled
Response validation : Disabled
Option 82 handle policy : append
Remote ID : mac
Client Requests Server Responses
Valid Dropped Valid Dropped
---------- ---------- ---------- ----------
0 0 0 0
SWITCH B# show dhcp-relay
DHCP Relay Agent : Enabled
Option 82 : Disabled
Response validation : Disabled
Option 82 handle policy : append
Remote ID : mac
Client Requests Server Responses
Valid Dropped Valid Dropped
---------- ---------- ---------- ----------
40156 0 0 0
И что интересно, агент dhcp-relay кажется очень занятым на коммутаторе B, но почему? Насколько я могу судить, нет причин, по которым для DHCP-запросов нужен ретранслятор с этой топологией. И, кроме того, я не могу сказать, почему вышестоящий коммутатор отбрасывает законные запросы DHCP на ненадежную информацию о реле, когда рассматриваемый агент ретрансляции (на коммутаторе B) все равно не изменяет атрибуты опции 82.
Добавление no dhcp-snooping option 82 на коммутаторе A позволяет утверждать трафик dhcp от коммутатора B коммутатором A, просто отключив эту функцию. Каковы последствия не проверка опции 82 измененного трафика DHCP? Если я отключу опцию 82 на всех своих «восходящих» коммутаторах, будут ли они передавать трафик DHCP с любого нисходящего коммутатора независимо от легитимности этого трафика?
Такое поведение не зависит от клиентской операционной системы. Я вижу это как с клиентами Windows, так и с Linux. Наши DHCP-серверы - это машины под управлением Windows Server 2003 или Windows Server 2008 R2. Я наблюдаю такое поведение независимо от операционной системы DHCP-серверов.
Может ли кто-нибудь пролить свет на то, что здесь происходит, и дать мне несколько рекомендаций о том, как мне продолжить настройку параметра 82? Я чувствую, что просто не до конца разобрался с атрибутами dhcp-relaying и option 82.
Фактически, пакет на коммутаторе A падает, потому что вы получили пакет клиента DHCP с опцией 82 на ненадежный порт. Эта опция 82 вставляется переключателем B.
Я думаю, что ниже должно работать -
On, SwitchB - отключите параметр 82, чтобы эти параметры не вставлялись. пометьте interface-25 как доверие, чтобы разрешить пакету DHCP-сервера течь вниз к.
Вкл., SwitchA- Здесь вы можете включить / выключить опцию 82. это не имеет значения. отметьте порт, который подключен к SwitchB, как ненадежный. отметьте порт, который подключен к dhcp-серверу, как доверенный.
Вы сказали, что "реле dhcp не включено" ... но очевидно, что это так, судя по вашему показу вывода dhcp-relay.
Попробуйте отключить его явно; основываясь на комментариях выше, я подозреваю, что ваша проблема исчезнет :)
Я думаю, вы неправильно понимаете идею доверенного порта. Я согласен с тем, что доверять только портам, из которых поступают предложения, интуитивно понятно, но я понимаю, что вам также нужно доверять магистральному порту на коммутаторе A. Вы отмечаете порты как доверенные, которые подключены к оборудованию, которое вы знаете и которому доверяете. Тот факт, что вы помечаете магистраль на коммутаторе A как надежную, не означает, что вы собираетесь позволить мошенническому серверу DHCP существовать на коммутаторе B. При правильной настройке коммутатор B не доверяет никакому порту, кроме его магистрали, поэтому вы по-прежнему не позволяли мошенническому DHCP-серверу находиться на коммутаторе B и отправлять предложения клиентам на коммутаторе A.
Короче говоря, вы должны доверять портам, подключенным к вашим собственным DHCP-серверам, и портам, подключенным к другим управляемым вами коммутаторам (так что вы можете быть уверены, что других доверенных портов нет).