Я пытаюсь загрузить конфигурацию на некоторых устройствах Juniper SRX100 и у меня возникают проблемы с DHCP.
В частности, я подключаю порт 0/0 (fe-0/0/0 в программном обеспечении) к моей существующей сети, где DHCP работает достаточно надежно практически для любого другого устройства, которое я использовал. SRX100 не получают адреса DHCP. SRX100 - это стандартная конфигурация по умолчанию, когда я пытаюсь это сделать.
Я принес одно из устройств в свой дом и подключил его к домашней сети, и он получил IP-адрес в моей домашней сети через DHCP без проблем.
В моей офисной сети есть коммутатор Procurve 1400 (только уровень 2) на моем рабочем столе, подключенный к IP-телефону Polycom IP670 (действует как простой коммутатор уровня 2), подключенный к коммутатору Procurve 3500yl, действующему в качестве маршрутизатора для сети с «ip helper-address 1.1.1.1 "на интерфейсе vlan, указывающем на DHCP-сервер для ретрансляции DHCP.
Кто-нибудь имеет опыт получения клиентом SRX DHCP, получающего IP-адрес через Procurve (с программным обеспечением K.15.09.0012 ... хотя проблема существовала в нескольких версиях прошивки на Procurve). SRX100, кажется, имеют 11.2 на них, когда они выходят из коробки, хотя я думаю, что проблема продолжает существовать при обновлении до 12.1X44-D10.4.
У кого-нибудь есть предложения по устранению неисправностей? Procurve 3500yl, похоже, не признается, что видел запрос DHCP-клиента, поступающий с SRX100, но информация об устранении неполадок в Procurves в этой области кажется ограниченной. Сервер DHCP определенно не видит поступающие пакеты DHCPDISCOVER, относящиеся к SRX100.
Мой обходной путь состоял в том, чтобы статически настроить IP-адрес на SRX100s, чтобы получить их в сети и выполнить остальную часть моей конфигурации, но проект, над которым я работаю, включает отправку SRX100s в удаленные местоположения, которые не находятся под моим контролем, и, таким образом, от них зависит надежное получение адресов DHCP для подключения, поэтому я действительно хотел бы устранить эту проблему и устранить конкретную причину, чтобы я знал, что потенциально нужно искать, если это произойдет на удаленных узлах.
Обновление: у меня есть (чтобы перепроверить) заводская установка по умолчанию SRX100 и я подключил его непосредственно к порту на Procurve 3500yl, и все еще вижу проблему, так что телефон 1400 и IP670 удаляются из обсуждения. Я включил вывод tcpdump из SRX100 ниже ... как вы можете видеть, он рассылает информацию о самом простом из возможных DHCP-пакетов, когда он предполагает, что проблема в функции dhcp-relay на 3500yl. Я не могу найти какой-либо способ получить какой-либо отладочный вывод от 3500yl, показывающий пакеты, попадающие в функцию dhcp-relay (успешно или нет). Будем весьма благодарны за предложения по отладке этой функции на 3500yl.
tcpdump -n -s 0 -c 1 -vvv -r juniper.dhcp.pcap
reading from file juniper.dhcp.pcap, link-type JUNIPER_ETHER (Juniper Ethernet)
17:49:11.538670
Juniper PCAP Flags [Ext], PCAP Extension(s) total length 16
Device Media Type Extension TLV #3, length 1, value Ethernet (1)
Logical Interface Encapsulation Extension TLV #6, length 1, value Ethernet (14)
Device Interface Index Extension TLV #1, length 2, value 34304
Logical Interface Index Extension TLV #4, length 4, value 70
-----original packet-----
IP (tos 0x0, ttl 1, id 13874, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from a8:d0:e5:1c:68:80, length 300, xid 0x643c9869, Flags [Broadcast] (0x8000)
Client-Ethernet-Address a8:d0:e5:1c:68:80
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
END Option 255, length 0
PAD Option 0, length 0, occurs 56
источник
Ответы:
Я открыл дело с HP по этому вопросу. После прохождения бесполезной технологии уровня 1, технология уровня 2 очень осторожно заметила то, чего у меня не было.
SRX отправляет свой пакет DHCPDISCOVER с TTL, равным 1. Очевидно, что Procurve будет уменьшать TTL и использовать полученный TTL в ретранслируемом пакете на сервер DHCP. В этом случае декремент оставляет TTL равным 0, что означает, что пакет отбрасывается на пол.
Это на самом деле спецификация для ретрансляции DHCP / BOOTP, хотя очевидно, что это приводит к снижению совместимости. Я попросил HPNetworking рассматривать это как ошибку / RFE и изменить поведение. Нет немедленного ответа на этот запрос по делу.
SRX, отправляющий DHCPDISCOVER с TTL, равным 1, также, вероятно, находится в пределах спецификации, но, опять же, это означает выбор ограниченной функциональной совместимости, поэтому я планирую открыть дело с JTAC на той же основе.
Я добавлю больше информации об ответе Juniper и HP, когда он станет доступным.
Между прочим, я проверил поведение ретранслятора Cisco 4506 (версия микропрограммы не доступна сразу) и Brocade / Foundry FastIron Edge X (прошивка 7.2 или 7.3, я полагаю, не имеет немедленного доступа для подтверждения), и они оба обрабатывают передача запроса с TTL 1 без проблем.
ОБНОВЛЕНИЕ Существует способ изменить значение TTL, которое SRX использует в своих запросах DHCP, но не из среды JunOS ... это делается из базовой ОС Unix.
Я открыл RFE вместе с HP, чтобы сделать их функцию ретрансляции более устойчивой, но пока не получил от них ответа, если / когда это будет работать.
источник
Устранение неполадок может быть затруднено, если вы не знаете, в чем заключается проблема, и у вас есть три устройства от трех поставщиков, прежде чем у вас появится какая-либо видимость (SRX100, 1400 и IP670). Я не могу говорить с определенными устройствами, но вы никогда не ошибетесь, отслеживая пакеты. Поскольку ProCurve 1400 является неуправляемым устройством, вам необходимо использовать сетевой отвод.
Вы хотели бы захватить трафик в следующих местах (на основании вашего заявления о том, что 3500yl не получает пакет обнаружения):
Вы можете делать все это со своего рабочего стола, и, хотя нажатие вызывает помехи, когда вы подключаете / отключаете его, оно должно влиять только на вас и ваши устройства.
Я бы начал с верхней части этого списка, поскольку он должен позволять вам захватывать пакет обнаружения DHCP как минимум один раз, а затем любые последующие захваты пакета обнаружения DHCP можно сравнивать с этим, чтобы увидеть, есть ли какая-либо модификация.
Возможно, вы также захотите захватить DHCP-пакеты обнаружения с устройств, которые также работают, чтобы увидеть, есть ли какие-либо отличия от пакета обнаружения, который отправляет SRX100.
Как только вы узнаете, где происходит сбой в работе пакета, вы можете детально разобраться, почему он не работает в этот момент.
источник
Хотя вы тестировали SRX в другом месте:
set security zones security-zone host-inbound-traffic system-services dhcp
было сделаноshow interfaces fe-0/0/0 extensive
твой другshow interfaces diagnostics optics ge-0/0/0
Затем следите за журналом, когда вы открываете интерфейс
monitor start dhcp_client.log
. (Не забудьте удалить traceoption, как только вы закончите)источник