Назад | Перейти на главную страницу

Пересылка DHCP за списком доступа на Cisco Catalyst

У меня проблемы с пересылкой DHCP из подсети за списком доступа на коммутаторе Cisco Catalyst 4500. Я надеюсь, что кто-нибудь увидит мою ошибку.

Подсеть определяется следующим образом: (первые три октета IP-адресов и имя vrf анонимны)

interface Vlan40
  ip vrf forwarding vrf_name
  ip address 10.10.10.126 255.255.255.0 secondary
  ip address 10.10.10.254 255.255.255.0
  ip access-group 100 out
  ip helper-address 10.10.20.36
  no ip redirects

Я попытался включить машину VMWare в этой подсети, которая была настроена на использование DHCP, но я так и не получил ответа DHCP, и сервер DHCP не получил запрос. Я пробовал добавить в список доступа следующее:

access-list 100 permit udp host 10.10.10.254 host 10.10.20.36 eq bootps
access-list 100 permit udp host 10.10.10.254 host 10.10.20.36 eq bootpc
access-list 100 permit udp host 10.10.20.36 host 10.10.10.254 eq bootps
access-list 100 permit udp host 10.10.20.36 host 10.10.10.254 eq bootpc

Это не помогло. Кто-нибудь может понять, в чем проблема?

Изменить 2012-10-19: это решено! Подсеть ранее определялась как сеть / 25, но затем была расширена до сети / 24. Когда после этого изменения область действия DHCP была изменена, это было сделано неправильно; шлюз был перемещен на .254, арендованный диапазон IP-адресов находился в нижней половине подсети / 24, но мы забыли изменить префикс CIDR с / 25 на / 24. Это произошло около 2 лет назад, и нам не нужно было снова использовать DHCP в этой серверной сети до этой недели.

Спасибо, MDMarra и Jason Seemann, за то, что рассмотрели вопрос и попытались устранить неполадки.

Теперь мне интересно, следует ли мне пометить ответ Джейсона как принятый (я новичок в сети Stack Exchange, поэтому не знаю этикета, что делать, если я неправильно сформулировал вопрос, как в этом случае).

Примечание 1. Обычно исходящие ACL не должны влиять на исходящий трафик, исходящий от маршрутизатора, поэтому в вашем случае я не уверен, что ACL напрямую останавливает работу DHCP.

Примечание 2: я создал простую лабораторию, чтобы подтвердить вышеизложенное. По сути, я просто помещаю разрешающий IP для любого ACL журнала, чтобы подтвердить, что трафик маршрутизатора не попадает в ACL - в моем случае этого не произошло.

Примечание 3: Я подключил сниффер, чтобы понять формат пакета ответа DHCP на VLAN40. Ответ DHCP будет исходить от интерфейса маршрутизатора (10.10.10.254 в вашем случае) и направлен на широковещательный IP-адрес 255.255.255.255. Исходный порт BOOTPS, порт назначения BOOTPC. Если хотите, можете преобразовать ACL в этот формат пакета (разрешить udp host 10.10.10.254 eq bootps host 255.255.255.255 eq bootpc), но опять же, я не думаю, что вы увидите какие-либо совпадения из-за примечания №1.

Одно замечание: мой список контроля доступа зарегистрировал тест ping, исходящий от DHCP-сервера в подсеть, чтобы проверить, доступен ли IP-адрес, который он хотел назначить. Даже если вы отказываетесь от этого DHCP, он все равно должен работать, но в основном это просто к сведению.

Присмотритесь к своему серверу, клиенту и другим параметрам - вы говорите, что DHCP работает в этой подсети. Или просто базовое подтверждение, полностью удалите ACL и посмотрите, работает ли он.