SRX DHCP istemci HP Procurve DHCP Rölesi ile uyumluluk

Bazı Juniper SRX100'lerde yapılandırmayı önyüklemeye çalışıyorum ve bazı DHCP sorunları yaşıyorum.

Özellikle, 0/0 bağlantı noktasını (yazılımda fe-0/0/0), DHCP'nin kullandığım hemen hemen her cihaz için oldukça güvenilir bir şekilde çalıştığı mevcut ağıma bağlıyorum. SRX100'ler DHCP adreslerini almıyor. Bunu denediğimde SRX100 kullanıma hazır varsayılan yapılandırmadır.

Cihazlardan birini evime getirdim ve ev ağıma bağladım ve ev ağımda DHCP aracılığıyla sorunsuz bir IP adresi aldım.

Ofis ağımın masaüstümde bir Polycom IP670 IP telefonuna (basit bir katman 2 anahtarı görevi görür) bağlı, "ip ile ağ için yönlendirici görevi gören bir Procurve 3500yl anahtarına bağlı Procurve 1400 (yalnızca katman 2) anahtarı var vlan arabiriminde DHCP geçişi için DHCP sunucusunu gösteren yardımcı adres 1.1.1.1 ".

Herkes bir Procurve üzerinden bir IP adresi almak bir SRX DHCP istemcisi alma konusunda herhangi bir tecrübesi var mı (K.15.09.0012 yazılımı çalışıyor ... sorun Procurve üzerinde birden fazla ürün yazılımı sürümünde mevcut olsa da). SRX100s, kutudan çıktıklarında 11.2'ye sahip gibi görünüyor, ancak 12.1X44-D10.4'e yükseltildiğinde sorun devam ediyor.

Herkes bu sorunu gidermek için herhangi bir öneriniz var mı? Procurve 3500yl, SRX100'den gelen DHCP istemci isteğini gördüğünü itiraf etmiyor gibi görünüyor, ancak bu alandaki Procurves ile ilgili sorun giderme bilgileri sınırlı görünüyor. DHCP sunucusu, SRX100 ile ilgili herhangi bir DHCPDISCOVER paketi gelmediğini kesinlikle görmez.

Geçici çözümüm, SRX100'lerde bir IP adresini ağda almak ve yapılandırmamın geri kalanını yapmak için statik olarak yapılandırmaktı, ancak üzerinde çalıştığım proje, SRX100'leri kontrolüm altında olmayan uzak konumlara göndermeyi ve böylece, güvenilir bir şekilde bağlantı için DHCP adresleri alma onlara bağlıdır, bu yüzden gerçekten bu sorunu gidermek ve belirli bir nedeni çalıştırmak istiyorum, bu yüzden uzak sitelerde bu olup olmadığını potansiyel olarak aramak için biliyorum.

Güncelleme: SRX100'ü fabrikada varsayılan olarak (çift kontrol etmek) ve Procurve 3500yl üzerindeki bir bağlantı noktasına doğrudan taktım ve hala sorunu görüyorum, böylece 1400 ve IP670 telefonu tartışmadan kaldırılıyor. Aşağıdaki SRX100'den tcpdump çıktısını ekledim ... Gördüğünüz gibi, sorunun 3500yl'deki dhcp rölesi işleviyle ilgili olduğunu öne sürdüğünde, mümkün olan en basit DHCP paketi hakkında gönderilmesi. Dhcp-relay fonksiyonuna (başarılı veya başka şekilde) isabet eden 3500yl gösteren paketlerden herhangi bir hata ayıklama çıkışı almanın bir yolunu bulamıyorum. Bu işlevi 3500yl'de nasıl ayıklayacağınıza dair öneriler çok takdir edilecektir.

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 ile bu konuyla ilgili bir dava açtım. Seviye 1 teknolojisini geçtikten sonra Seviye 2 teknolojisi, sahip olmadığım bir şeyi çok dikkatli bir şekilde fark etti.

SRX, DHCPDISCOVER paketini 1 TTL ile gönderiyor. Procurve's görünüşte TTL'yi azaltacak ve röleli pakette elde edilen TTL'yi DHCP sunucusuna kullanacaktır. Bu durumda, azalma TTL'yi 0'da bırakır, yani paket yere düşürülür.

Bu aslında DHCP / BOOTP rölesi için spesifiktir, ancak açıkça birlikte çalışabilirliğin azalmasına neden olur. HPNetworking'den bunu bir hata / RFE olarak ele almasını ve davranışı değiştirmesini istedim. Davada bu talebe anında yanıt verilmez.

DHCPDISCOVER'ı 1 TTL ile gönderen SRX de muhtemelen spesifikasyon dahilindedir, ancak yine de, birlikte çalışabilirliğin azaltılması seçeneği, bu yüzden aynı temelde JTAC ile bir dava açmayı planlıyorum.

Juniper ve HP'nin kullanıma hazır hale gelmesiyle ilgili daha fazla bilgi ekleyeceğim.

Bu arada, bir Cisco 4506'nın (ürün yazılımı sürümü hemen kullanılamıyor) ve bir Brocade / Dökümhane FastIron Edge X'in (7.2 veya 7.3 ürün yazılımı, inanıyorum, onaylamak için hemen erişim yok) röle davranışını test ettim ve her ikisi de talebin sorunsuz bir şekilde TTL 1 ile iletilmesi.

GÜNCELLEME SRX'in DHCP isteklerinde kullandığı TTL değerini değiştirmenin bir yolu vardır, ancak JunOS cli içinden değil ... temel Unix OS'den yapılır.

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

Geçiş işlevlerini daha esnek hale getirmek için HP ile bir RFE açtım, ancak onlardan ne zaman çalışılacağı / ne zaman çalışılacağı konusunda henüz yanıt vermiyorum.

Sorunun nerede olduğunu bilmediğinizde sorun gidermek zor olabilir ve herhangi bir görünürlüğe sahip olmadan önce üç satıcıdan üç cihazınız varsa (SRX100, 1400 ve IP670). Belirli cihazlarla konuşamıyorum, ancak paketleri izleyerek asla yanlış gidemezsiniz. ProCurve 1400 yönetilmeyen bir cihaz olduğundan, bir ağ musluğu kullanmanız gerekir.

Aşağıdaki konumlardaki trafiği yakalamak istersiniz (3500yl'in keşif paketini almadığını belirten ifadenize dayanarak):

• SRX100 ile 1400 arasında.
• 1400 ve IP670 arasında
• IP670 ve 3500yl arasında

Tüm bunları masanızdan yapabilirsiniz ve bir musluk bağlanırken / çıkarılırken bir musluk rahatsız edici olsa da, sadece sizi ve cihazlarınızı etkilemelidir.

Bu listenin en üstünde başlayacağım, çünkü DHCP keşif paketini en az bir kez yakalamanıza izin vermeli ve daha sonra DHCP keşif paketinin sonraki yakalamaları, herhangi bir değişiklik olup olmadığını görmek için bu listeyle karşılaştırılabilir.

SRX100'ün gönderdiği keşif paketinden herhangi bir fark olup olmadığını görmek için de çalışan aygıtlardan DHCP keşif paketlerini yakalamak isteyebilirsiniz.

Paketin nerede yanlış gittiğini öğrendikten sonra, o noktada neden yanlış gittiğini sorun gidermeye bakabilirsiniz.

SRX'i başka bir yerde test etmenize rağmen:

1. SRX evde tam olarak aynı yapılandırmaya sahip bir adres alıyor mu?
   • Bu, aşağıdakilerin sorun olmadığı anlamına gelmelidir:
   • set security zones security-zone host-inbound-traffic system-services dhcp yapıldı
   • Temel arayüz yapılandırması yapıldı (ham arayüz, vlan etiketleri, doğru vlan'da arayüz, o vlan
2. Arayüz aslında Ardıç tarafında temiz mi geliyor?
   • show interfaces fe-0/0/0 extensive senin arkadaşın
   • (Bunun uygun olmadığını biliyorum, ama yine de ...) Optik arayüzler için güç seviyelerini de kontrol edin: show interfaces diagnostics optics ge-0/0/0
3. DHCP istemcisine bir izleme ekleyin:

yapılandır
sistem hizmetlerini ayarla dhcp traceoptions dosya dhcp_client.log dünya tarafından okunabilir
sistem hizmetlerini ayarla dhcp traceoptions bayrak istemcisi
sistem hizmetlerini ayarla dhcp traceoptions level all
taahhüt et ve çık

Daha sonra arayüzü açarken günlüğü izleyin monitor start dhcp_client.log. (İşlemi tamamladıktan sonra trakeopasyonu silmeyi unutmayın)