Мы постепенно начинаем внедрять dhcp-snooping на наших коммутаторах серии HP ProCurve 2610, все с прошивкой R.11.72. Я наблюдаю странное поведение, когда пакеты dhcp-request или dhcp-renew отбрасываются при отправке от «нисходящих» коммутаторов из-за «ненадежной информации ретранслятора от клиента».
Полная ошибка:
Received untrusted relay information from client <mac-address> on port <port-number>
Более подробно мы имеем 48-портовый HP2610 (коммутатор A) и 24-портовый HP2610 (коммутатор B). Коммутатор B является «нисходящим» от Коммутатора A благодаря DSL-соединению с одним из портов Коммутатора A. Сервер DHCP подключен к коммутатору А. Соответствующие биты следующие:
Переключатель А
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 не настроено ни на одном коммутаторе, 2) сеть уровня 3 здесь плоская, та же подсеть. Пакеты DHCP не должны иметь модифицированный атрибут option 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 позволяет коммутатору A утверждать трафик dhcp от коммутатора B, просто отключив эту функцию. Каковы последствия не проверки опции 82 модифицированного трафика DHCP? Если я отключу опцию 82 на всех моих «восходящих» коммутаторах - будут ли они передавать трафик dhcp от любого нисходящего коммутатора независимо от легитимности этого трафика?
Такое поведение не зависит от операционной системы клиента. Я вижу это как с Windows, так и с Linux клиентами. Нашими DHCP-серверами являются машины под управлением Windows Server 2003 или Windows Server 2008 R2. Я вижу это поведение независимо от операционной системы серверов DHCP.
Может кто-нибудь пролить свет на то, что здесь происходит, и дать мне несколько советов о том, как мне следует приступить к настройке параметра 82? Я чувствую, что у меня просто нет полностью утешенных атрибутов dhcp-relay и option 82.
Ответы:
Вы сказали, что «реле dhcp не включено» ... но ясно, что это так, на основании вашего вывода show dhcp-relay.
Попробуйте отключить его явно; основываясь на комментариях выше, я подозреваю, что ваша проблема исчезнет :)
источник
На самом деле, пакет на коммутаторе A уменьшается, потому что вы получили пакет DHCP-клиента с параметром 82 на ненадежном порту. Эта опция-82 вставляется переключателем B.
Я думаю, что ниже должно работать -
On, SwitchB - отключить опцию 82, чтобы она не вставляла эти опции. пометьте interface-25 как доверие, чтобы позволить пакету сервера DHCP течь вниз к.
Вкл, SwitchA - Вы можете оставить опцию 82 включенной / отключенной здесь. это не должно иметь значения. пометьте порт, который подключен к switchB, как ненадежный. пометьте порт, который подключен к dhcp-серверу, как доверенный.
источник
Я думаю, что вы можете неправильно истолковывать идею доверенного порта. Я согласен, что доверять только портам, из которых поступают предложения, интуитивно понятно, но я понимаю, что вам также необходимо доверять транковому порту на коммутаторе А. Вы помечаете доверенные порты, которые подключены к оборудованию, которое вы знаете и которому доверяете. Тот факт, что вы помечаете магистраль на коммутаторе A как доверенную, не означает, что вы разрешите несанкционированному DHCP-серверу существовать на коммутаторе B. При правильной настройке коммутатор B не будет доверять никаким другим портам, кроме его магистрали, поэтому до сих пор не позволяли неконтролируемому DHCP-серверу сидеть на коммутаторе B и отправлять предложения клиентам на коммутаторе A.
Короче говоря, вы должны доверять портам, подключенным к вашим собственным DHCP-серверам, и портам, подключенным к другим управляемым вами коммутаторам (так что вы можете быть уверены, что других доверенных портов нет).
источник