Несколько раз замечал: тумблер начинает странно себя вести. Обычно, если коммутатор не выходит из строя сразу, обычно обращают внимание на то, что DHCP не работает.
У нас сегодня был сбой Linksys SRW-224P. Системы, которые все еще были подключены, работали нормально, пока не пришло время продлевать аренду DHCP. По истечении срока аренды они перестали работать, но до тех пор мы не могли обнаружить сбой. Это включает в себя телефоны PoE VoIP - они работают нормально, пока срок их аренды не истечет, после чего они готовы.
Я заметил это на вышеупомянутых Linksys, трех разновидностях 3Com и, возможно, полдюжине тупых переключателей.
Что в DHCP делает его чувствительным к сбоям коммутаторов?
Возможно, вы смотрите на это не с той стороны, вместо того чтобы спрашивать, почему не работает DHCP, возможно, вам следует спросить, почему связь на основе TCP работает в ненадежной сети, где происходит потеря или повреждение пакетов.
Связь на основе TCP должна быть надежной, и протокол предназначен для повторной попытки связи, другие протоколы, такие как UDP, ненадежны. DHCP просто использует UDP. В типичной сети большая часть того, что вы видите в наши дни, основано на TCP. Его свойства устойчивости могут быть тем, что позволяет вам поддерживать связь при отказе оборудования.
Возможность перенаправить запрос помощника bootp / dhcp?
РЕДАКТИРОВАТЬ: Хорошо, поскольку они не являются коммутаторами уровня 3 (вероятно, следует прочитать это немного внимательнее), они, вероятно, не участвуют в пересылке dhcp.
Я бы сказал, что DHCP немного сложнее, чем говорят HTTP-запросы, но я бы поспорил с собой, пытаясь утверждать, что способ узнать, не работает ли ваш коммутатор, - это проверить, успешно ли выполняются запросы DHCP через него. Я почти уверен, что если вы посмотрите на свой реальный трафик VOIP, вы заметите потерю пакетов. Потеря пакетов VOIP (UDP) может быть заметна во время разговора в зависимости от% отброшенного. Если несколько из них будут отброшены, это не имеет большого значения, но с запросами DHCP эти пакеты действительно важны, и, поскольку они не передаются повторно, это нарушит запрос.
Может пригодиться, чтобы понять все, что DHCP делает для вас (через Cisco).
Я видел такое поведение на двух коммутаторах Netgear Smart. В обоих случаях коммутаторы игнорировали весь широковещательный трафик. Таким образом, запросы и ответы DHCP не передавались.
DHCP основан не только на широковещании. Это его «Запрос». Происходит соединение с сетью, затем запрос адреса в этой сети, затем ответ, отправленный от DHCP-сервера, который либо удерживает аренду адреса, либо сообщает о сбое. Запрос повторяется внутри клиента, отправляя его каждые несколько секунд и ожидая ответа.
Однако, если этот ответ не получен, если он отброшен или просто не передан через коммутационные устройства должным образом, вы не сможете получить адрес. Убедитесь, что ваши подсети правильно настроены. Я заметил, что многие любят использовать биты x.0.x для хранения только статических управляемых устройств (коммутаторов и принтеров), сохраняя компьютеры и серверы на x.1.x или в другом месте (это всего лишь пример). Если вы не включите x.0.x в маскировку вашей подсети должным образом, вы можете получить битовые маски, которые отбрасывают ваши запросы dhcp или неправильно их направляют.
Не забудьте включить этот x.0.x в качестве основного начального адреса, а затем перейдите к настройке подсети настолько широкой, насколько вам нужно, с маской, которая полностью соответствует вашему DHCP; обратите внимание, что sume устанавливает подсети относительно фактического DHCP-сервера, это бесполезно, это создает утечки пакетов. Если вы настроили DHCP, чтобы не передавать статическую часть, вам все равно нужно установить его внутри своей подсети.
Если вы подсети свой DHCP-сервер, вам следует перенастроить маски, добавив 1 к изменению битовой маски. Если вы подсети 255.255.252.0 для своей маски на вашем DHCP, вам необходимо подсеть 255.255.251.0 на ваших коммутаторах, чтобы разрешить запросы масок адресов x.0.x (статические маршруты, введенные на клиенте) для передачи dhcp-сигнала так же, как и остальная часть сети. Убедитесь, что маскировка вашей подсети позволяет подсетям, которым необходимо взаимодействовать, видеть друг друга, даже если только через них проходят запросы DHCP.
Вы можете разделить сетевые службы на компьютерах с Windows (а теперь и на Mac), установив ограничения для рабочей группы или домена. Доступ к сервисам должен осуществляться через логин, а не через vlan. Логин может управлять полученным адресом, если вы знаете, как записать сценарий на свои серверы, но это следует делать только в случае крайней необходимости. VLAN должна функционировать только для того, чтобы помогать сетевым специалистам отслеживать, отслеживать и устранять проблему, следуя схеме маскирования адреса до физического местоположения.
Помните, что вы можете соединить vlan совершенно разных масок, но это позволяет им видеть друг друга только с точки зрения сети, а не уровня доступа. Если им нужен доступ к службам, все vlan должны быть связаны с основным интерфейсом, и этот интерфейс должен нести полную маску, содержащую все vlan, в то время как интерфейсы vlan несут только основную маску 255.255.255.0 (или любую другую подсеть vlan, которую вы помещаете через него) .
Единственное, о чем я могу думать, - это то, что коммутатор не сможет правильно обновить свой кеш ARP, чтобы отразить недавно назначенный IP.