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

10

Я пытаюсь загрузить конфигурацию на некоторых устройствах 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
Джефф МакАдамс
источник
Вы пытались подключить SRX напрямую к 3500yl, чтобы убедиться, что ни 1400, ни Polycom не фильтруют широковещательные сообщения DHCPDISCOVER?
Дэвид Ротера
У меня нет, и это неплохая идея. Однако иногда я подключаю другие системы таким же образом и получаю DHCP-адреса в других системах, включая мои настольные компьютеры, которые постоянно находятся в сети таким образом, так что кажется маловероятной проблема. Я посмотрю, смогу ли я проверить это, хотя.
Джефф Макадамс
Обновлено с некоторой информацией в моем ответе ... особенно о том, как изменить значение TTL запросов DHCP в SRX, а также о том, что я открыл RFE с HP.
Джефф Макадамс

Ответы:

9

Я открыл дело с 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, чтобы сделать их функцию ретрансляции более устойчивой, но пока не получил от них ответа, если / когда это будет работать.

Джефф МакАдамс
источник
2

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

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

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

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

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

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

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

YLearn
источник
Да, я еще не пошел к этим конкретным шагам, так как у меня есть достаточно уверенность в том, что 1400 и ip670 надежно работают только на уровне 2 и, таким образом, не портят трафик DHCP. Я думаю, что проблема в какой-то несовместимости между SRX и 3500yl. Я подозреваю, что пакет достигает 3500yl, но он не обрабатывает его правильно. То, что я не могу получить 3500yl, чтобы указать, что он видел пакет, я думаю, это больше из-за ограниченных возможностей отладки на 3500yl.
Джефф МакАдамс
@JeffMcAdams, я бы согласился с такой оценкой, но раньше меня удивляли странные проблемы. Поскольку вы можете перемещать кран в этих местах со своего рабочего стола, я следую за пакетом, чтобы гарантировать, что все работает как положено. Если бы вам приходилось перемещаться между сетевыми шкафами, этажами, зданиями или площадками, то я бы сказал, прыгнуть туда, где проблема, и начать там. Кроме того, получение хорошо известного пакета обнаружения позволит вам узнать, может ли быть что-то «лишнее», что не нравится вашему DHCP-серверу (опция 82 или что-то еще, возможно).
YLearn
1

Хотя вы тестировали 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, как только вы закончите)

LapTop006
источник
1. Да, я делаю это с конфигами «ломай из коробки», как дома, так и в офисе. Заводская конфигурация по умолчанию включает dhcp системных служб host-inbound-traffic на используемом мной интерфейсе fe-0/0 / 0.0. 2. Да, интерфейс работает чисто, и если я статичную информацию о конфигурации IP на нем, он работает нормально. 3. Я редактировал исходный вопрос с tcpdump пакета, выходящего ... Я никогда не вижу ответного пакета вообще, и никогда не вижу, чтобы пакет попал на DHCP-сервер.
Джефф МакАдамс