Совместимость DHCP-клиента SRX с ретранслятором HP Procurve DHCP

Я пытаюсь загрузить конфигурацию на некоторых устройствах 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.

root@% sysctl -w net.inet.ip.mcast_ttl=64

Я открыл RFE вместе с HP, чтобы сделать их функцию ретрансляции более устойчивой, но пока не получил от них ответа, если / когда это будет работать.

Устранение неполадок может быть затруднено, если вы не знаете, в чем заключается проблема, и у вас есть три устройства от трех поставщиков, прежде чем у вас появится какая-либо видимость (SRX100, 1400 и IP670). Я не могу говорить с определенными устройствами, но вы никогда не ошибетесь, отслеживая пакеты. Поскольку ProCurve 1400 является неуправляемым устройством, вам необходимо использовать сетевой отвод.

Вы хотели бы захватить трафик в следующих местах (на основании вашего заявления о том, что 3500yl не получает пакет обнаружения):

• Между SRX100 и 1400.
• Между 1400 и IP670
• Между IP670 и 3500yl

Вы можете делать все это со своего рабочего стола, и, хотя нажатие вызывает помехи, когда вы подключаете / отключаете его, оно должно влиять только на вас и ваши устройства.

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

Возможно, вы также захотите захватить DHCP-пакеты обнаружения с устройств, которые также работают, чтобы увидеть, есть ли какие-либо отличия от пакета обнаружения, который отправляет SRX100.

Как только вы узнаете, где происходит сбой в работе пакета, вы можете детально разобраться, почему он не работает в этот момент.

Хотя вы тестировали SRX в другом месте:

1. Получает ли SRX адрес с точно такой же конфигурацией дома?
   • Это должно означать, что следующее не является проблемой:
   • set security zones security-zone host-inbound-traffic system-services dhcp было сделано
   • Конфигурация базового интерфейса выполнена (необработанный интерфейс, теги vlan, интерфейс в правильном vlan, этот vlan в
2. Интерфейс действительно подходит на стороне Juniper?
   • show interfaces fe-0/0/0 extensive твой друг
   • (Я знаю, что это не подходит для этого, но все же ...) Для оптических интерфейсов также проверьте уровни мощности: show interfaces diagnostics optics ge-0/0/0
3. Добавьте трассировку к клиенту DHCP:

настроить
установить файл трассировки dhcp системных служб dhcp_client.log для чтения во всем мире
установить системный сервис dhcp traceoptions flag client
установить системные службы dhcp traceoptions level all
совершить и выйти

Затем следите за журналом, когда вы открываете интерфейс monitor start dhcp_client.log. (Не забудьте удалить traceoption, как только вы закончите)