Сумісність клієнта SRX DHCP з HP Procurve DHCP Relay

Я намагаюся завантажувати конфігурацію деяких Juniper SRX100s і у мене виникають деякі проблеми DHCP.

Зокрема, я підключаю порт 0/0 (fe-0/0/0 в програмному забезпеченні) до моєї існуючої мережі, де DHCP працює досить надійно майже для кожного іншого пристрою, який я використовував. SRX100 не отримують DHCP-адреси. SRX100 - це нестандартна конфігурація за замовчуванням, коли я намагаюся це зробити.

Я приніс один із пристроїв додому і підключив його до домашньої мережі, і він отримав IP-адресу в домашній мережі через DHCP без проблем.

Моя офісна мережа має на своєму робочому столі комутатор Procurve 1400 (лише 2 рівень), підключений до IP-телефону Polycom IP670 (діє як простий комутатор рівня 2), підключений до комутатора Procurve 3500yl, який виконує функцію маршрутизатора для мережі з "ip helper-адреса 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-адресу на SRX100, щоб отримати їх у мережі та виконати решту моєї конфігурації, але проект, над яким я працюю, передбачає надсилання SRX100s у віддалені місця, які не знаходяться під моїм контролем, і, Таким чином, від них надійно отримувати DHCP адреси для підключення, тому я дуже хотів би усунути цю проблему та зменшити конкретну причину, щоб я знав, що потенційно шукати, якщо це станеться на віддалених сайтах.

Оновлення: у мене (для подвійної перевірки) SRX100 за замовчуванням встановив дефолт і підключив його безпосередньо до порту на Procurve 3500yl, і я все ще бачу проблему, так що вилучає з обговорення 1400 та IP670 телефон. Я включив вихід tcpdump з SRX100 нижче ... як ви бачите, його надсилання про найпростіший можливий пакет DHCP, коли, як правило, припускають, що проблема полягає у функції dhcp-реле на 3500yl. Я не можу знайти жодного способу отримати вихід налагодження з 3500yl, що показує пакети, що потрапляють на функцію реле dhcp (успішно чи іншим чином). Пропозиції щодо налагодження цієї функції на 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. Насправді інтерфейс чітко виходить з боку ялівцю?
   • show interfaces fe-0/0/0 extensive твій друг
   • (Я знаю, що це не підходить для цього, але все ж ...) Для оптичних інтерфейсів також перевіряйте рівні потужності: show interfaces diagnostics optics ge-0/0/0
3. Додайте слід клієнту DHCP:

налаштувати
встановити системні служби dhcp traceoptions файл dhcp_client.log, що читається у всьому світі
встановити системний сервіс dhcp traceoptions flag flag client
встановити системні послуги dhcp traceoptions рівня всіх
вчинити і кинути

Потім слідкуйте за журналом під час налаштування інтерфейсу monitor start dhcp_client.log. (Не забудьте видалити трасеопцію після того, як ви закінчите)