Zgodność klienta SRX DHCP z przekaźnikiem HP Procurve DHCP

Próbuję uruchomić konfigurację na niektórych urządzeniach Juniper SRX100 i mam problemy z DHCP.

W szczególności podłączam port 0/0 (fe-0/0/0 w oprogramowaniu) do mojej istniejącej sieci, w której DHCP działa dość niezawodnie dla niemal każdego innego urządzenia, z którego korzystałem. SRX100 nie otrzymują adresów DHCP. SRX100 jest domyślną domyślną konfiguracją, gdy próbuję tego.

Przyniosłem jedno z urządzeń do mojego domu i podłączyłem je do mojej sieci domowej, a ono bez problemu uzyskało adres IP w mojej sieci domowej przez DHCP.

Moja sieć biurowa ma przełącznik Procurve 1400 (tylko warstwa 2) na moim pulpicie, wysyłany do telefonu IP Polycom IP670 (działa jak zwykły przełącznik warstwy 2), wysyłany do przełącznika Procurve 3500yl działającego jako router dla sieci z „ip” helper-address 1.1.1.1 ”na interfejsie vlan wskazującym na serwer DHCP dla przekaźnika DHCP.

Czy ktoś ma jakiekolwiek doświadczenie z uzyskaniem klienta DHCP SRX otrzymującego adres IP za pośrednictwem Procurve (z oprogramowaniem K.15.09.0012 ... chociaż problem występuje w wielu wersjach oprogramowania na Procurve). Wydaje się, że SRX100 mają na sobie 11,2, gdy wyjdą z pudełka, ale myślę, że problem nadal występuje po aktualizacji do 12.1X44-D10.4.

Czy ktoś ma jakieś sugestie dotyczące rozwiązania tego problemu? Procurve 3500yl nie wydaje się przyznawać, że widział żądanie klienta DHCP przychodzące z SRX100, ale informacje na temat rozwiązywania problemów w Procurves w tym obszarze wydają się ograniczone. Serwer DHCP zdecydowanie nie widzi żadnych pakietów DHCPDISCOVER związanych z SRX100.

Moim obejściem było statyczne skonfigurowanie adresu IP na SRX100, aby uzyskać je w sieci i wykonać resztę konfiguracji, ale projekt, nad którym pracuję, polega na wysyłaniu SRX100 do zdalnych lokalizacji, które nie są pod moją kontrolą, i, dlatego zależy od tego, czy niezawodnie uzyskają adresy DHCP do łączności, więc naprawdę chciałbym rozwiązać ten problem i sprecyzować konkretną przyczynę, więc wiem, czego potencjalnie szukać, jeśli zdarzy się to na zdalnych stronach.

Aktualizacja: Mam (do podwójnego sprawdzenia) fabrycznie domyślną wersję SRX100 i podłączyłem ją bezpośrednio do portu w Procurve 3500yl i nadal widzę problem, więc usuwa telefon 1400 i IP670 z dyskusji. Poniżej umieściłem wyjście tcpdump z SRX100 ... jak widać, wysyła ono informacje o najprostszym możliwym pakiecie DHCP, gdy sugeruje, że problem dotyczy funkcji przekaźnika dhcp w 3500yl. Nie mogę znaleźć żadnego sposobu, aby uzyskać jakiekolwiek wyjście debugowania z 3500yl pokazujące pakiety uderzające w funkcję przekaźnika dhcp (z powodzeniem lub inaczej). Bardzo mile widziane byłyby sugestie dotyczące debugowania tej funkcji w 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

Otworzyłem sprawę w HP dotyczącą tego problemu. Po eskalacji poza bezużyteczną technologię na poziomie 1, technologia na poziomie 2 bardzo czujnie zauważyła coś, czego nie miałem.

SRX wysyła swój pakiet DHCPDISCOVER z TTL równym 1. Najwyraźniej Procurve obniży TTL i użyje wynikowego TTL z pakietu przekazanego do serwera DHCP. W takim przypadku spadek pozostawia TTL na poziomie 0, co oznacza, że ​​pakiet zostaje upuszczony na podłogę.

Jest to faktycznie określone dla przekaźnika DHCP / BOOTP, choć wyraźnie powoduje to zmniejszoną interoperacyjność. Poprosiłem HPNetworking o potraktowanie tego jako błędu / RFE i zmianę zachowania. Brak natychmiastowej odpowiedzi na to żądanie w sprawie.

SRX wysyłający DHCPDISCOVER z TTL równym 1 również prawdopodobnie mieści się w zakresie specyfikacji, ale znowu jest to wybór zmniejszonej interoperacyjności, więc planuję otworzyć skrzynkę z JTAC na tej samej podstawie.

Dodam więcej informacji na temat odpowiedzi Juniper i HP, gdy będzie dostępna.

Nawiasem mówiąc, przetestowałem zachowanie przekaźnika Cisco 4506 (wersja oprogramowania nie jest natychmiast dostępna) i Brocade / Foundry FastIron Edge X (oprogramowanie układowe 7.2 lub 7.3, jak sądzę, nie mają natychmiastowego dostępu do potwierdzenia) i oba obsługują przekazywanie żądania z TTL 1 bez problemu.

AKTUALIZACJA Istnieje sposób na zmianę wartości TTL, której SRX używa w swoich żądaniach DHCP, ale nie jest to w Junli cli ... jest zrobione z bazowego systemu operacyjnego Unix.

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

Otworzyłem RFE z HP, aby ich funkcja przekazywania była bardziej odporna, ale jeszcze nie odpowiedziały na to, czy i kiedy to będzie działać.

Rozwiązywanie problemów może być trudne, jeśli nie wiesz, gdzie leży problem, i masz trzy urządzenia od trzech dostawców, zanim zdajesz się mieć jakąkolwiek widoczność (SRX100, 1400 i IP670). Nie mogę rozmawiać z konkretnymi urządzeniami, ale nigdy nie możesz się pomylić, śledząc pakiety. Ponieważ ProCurve 1400 jest urządzeniem niezarządzanym, należy użyć kranu sieciowego.

Chciałbyś przechwycić ruch w następujących lokalizacjach (na podstawie twojego oświadczenia, że ​​3500yl nie otrzymuje pakietu wykrywania):

• Między SRX100 a 1400.
• Między 1400 a IP670
• Między IP670 a 3500yl

Możesz to wszystko zrobić z biurka, a podczas gdy kran jest uciążliwy podczas łączenia / rozłączania, powinien on wpływać tylko na Ciebie i Twoje urządzenia.

Chciałbym zacząć od góry tej listy, ponieważ powinna ona pozwolić ci na przechwycenie pakietu wykrywania DHCP przynajmniej raz, a następnie wszelkie kolejne przechwytywania pakietu wykrywania DHCP można porównać z tym, aby sprawdzić, czy jest jakaś modyfikacja.

Możesz także chcieć przechwycić pakiety wykrywania DHCP z urządzeń, które również działają, aby sprawdzić, czy istnieją jakieś różnice w stosunku do pakietu wykrywania, który wysyła SRX100.

Gdy dowiesz się, gdzie pakiet idzie źle, możesz przyjrzeć się konkretnemu rozwiązywaniu problemów, dlaczego w tym momencie nie działa.

Chociaż przetestowałeś SRX w innym miejscu:

1. Czy SRX otrzymuje adres z dokładnie taką samą konfiguracją w domu?
   • To powinno oznaczać, że następujące kwestie nie są problemami:
   • set security zones security-zone host-inbound-traffic system-services dhcp zostało zrobione
   • Wykonano podstawową konfigurację interfejsu (surowy interfejs, znaczniki vlan, interfejs w poprawnym vlan, ten vlan w
2. Czy interfejs rzeczywiście działa poprawnie po stronie jałowca?
   • show interfaces fe-0/0/0 extensive jest twoim przyjacielem
   • (Wiem, że to nie jest odpowiednie, ale nadal ...) W przypadku interfejsów optycznych sprawdź również poziomy mocy: show interfaces diagnostics optics ge-0/0/0
3. Dodaj ślad do klienta DHCP:

skonfigurować
ustaw plik systemowy dhcp traceoptions dhcp_client.log do odczytu dla całego świata
ustaw flagę klienta dhcp traceoptions usług systemowych
ustaw usługi systemowe dhcp na poziomie śledzenia wszystkie opcje
popełnij i wyjdź

Następnie monitoruj dziennik podczas uruchamiania interfejsu monitor start dhcp_client.log. (Pamiętaj, aby po zakończeniu usunąć opcję trace)