Kompatibilitas klien SRX DHCP dengan HP Procurve DHCP Relay

Saya mencoba untuk bootstrap konfigurasi pada beberapa Juniper SRX100s dan saya mengalami beberapa masalah DHCP.

Secara khusus, saya menghubungkan port 0/0 (fe-0/0/0 dalam perangkat lunak) ke jaringan saya yang ada, di mana DHCP telah bekerja dengan cukup andal untuk hampir semua perangkat lain yang saya gunakan. SRX100s tidak mendapatkan alamat DHCP. SRX100 adalah konfigurasi default out-of-the-box ketika saya mencoba ini.

Saya membawa salah satu perangkat ke rumah saya dan menyambungkannya ke jaringan rumah saya dan mendapat alamat IP di jaringan rumah saya melalui DHCP tanpa masalah.

Jaringan kantor saya memiliki switch Procurve 1400 (layer 2 saja) di desktop saya, di-uplink ke telepon IP Polycom IP670 (bertindak sebagai switch layer 2 sederhana), di-link ke switch Procurve 3500yl yang bertindak sebagai router untuk jaringan dengan "ip helper-address 1.1.1.1 "pada antarmuka vlan yang menunjuk ke server DHCP untuk relay DHCP.

Adakah yang punya pengalaman dengan mendapatkan klien DHCP SRX mendapatkan alamat IP melalui Procurve (menjalankan perangkat lunak K.15.09.0012 ... meskipun masalahnya ada di beberapa versi firmware pada Procurve). SRX100 tampaknya memiliki 11.2 pada mereka ketika mereka keluar kotak, meskipun saya pikir masalahnya terus ada ketika ditingkatkan ke 12.1X44-D10.4.

Adakah yang punya saran untuk mengatasi masalah ini? Procurve 3500yl tampaknya tidak mengakui telah melihat permintaan klien DHCP yang datang dari SRX100, tetapi info pemecahan masalah pada Procurves di area ini tampaknya terbatas. Server DHCP pasti tidak melihat paket DHCPDISCOVER tiba yang berkaitan dengan SRX100.

Solusi saya adalah mengonfigurasi alamat IP pada SRX100 secara statis untuk membuatnya di jaringan dan melakukan sisa konfigurasi saya, tetapi proyek yang saya kerjakan melibatkan pengiriman SRX100 ke lokasi terpencil yang tidak di bawah kendali saya dan, jadi, tergantung pada mereka yang andal mendapatkan alamat DHCP untuk konektivitas jadi saya benar-benar ingin memecahkan masalah ini dan menjalankan penyebab tertentu sehingga saya tahu apa yang harus dicari jika ini terjadi di situs jarak jauh.

Pembaruan: Saya telah (memeriksa ulang) SRX100 default pabrik, dan menancapkannya langsung ke port pada Procurve 3500yl dan saya masih melihat masalah, sehingga menghapus telepon 1400 dan IP670 dari diskusi. Saya telah memasukkan output tcpdump dari SRX100 di bawah ini ... seperti yang Anda lihat, pengirimannya tentang paket DHCP semudah mungkin, ketika cenderung menyarankan bahwa masalahnya adalah fungsi dhcp-relay pada 3500yl. Saya tidak dapat menemukan cara untuk mendapatkan hasil debug dari paket 3500yl yang menunjukkan fungsi dhcp-relay (berhasil atau tidak). Saran tentang cara men-debug fungsi ini pada 3500yl akan sangat dihargai.

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

Saya membuka kasus dengan HP tentang masalah ini. Setelah meningkat melewati teknologi Level 1 yang tidak berguna, teknologi Level 2 dengan sangat waspada melihat sesuatu yang tidak saya miliki.

SRX mengirimkan paket DHCPDISCOVER-nya dengan TTL dari 1. Procurve tampaknya akan mengurangi TTL dan menggunakan TTL yang dihasilkan dalam paket relay ke server DHCP. Dalam hal ini, penurunan tersebut meninggalkan TTL pada 0 yang berarti paket akan jatuh ke lantai.

Ini sebenarnya dalam spesifikasi untuk relay DHCP / BOOTP, meskipun jelas itu menyebabkan interoperabilitas berkurang. Saya telah meminta HPNetworking untuk memperlakukan ini sebagai bug / RFE dan mengubah perilaku. Tidak ada tanggapan langsung terhadap permintaan itu dalam kasus ini.

SRX yang mengirim DHCPDISCOVER dengan TTL 1 juga mungkin dalam spesifikasi, tetapi, sekali lagi, pilihan interoperabilitas yang berkurang, jadi saya berencana untuk membuka kasing dengan JTAC dengan dasar yang sama.

Saya akan menambahkan lebih banyak info tentang respons Juniper dan HP begitu tersedia.

Kebetulan, saya telah menguji perilaku relay dari Cisco 4506 (versi firmware tidak segera tersedia), dan Fastcron Edge X Brocade / Foundry (firmware 7.2 atau 7.3, saya percaya, tidak memiliki akses langsung untuk mengonfirmasi) dan keduanya menangani menyampaikan permintaan dengan TTL 1 tanpa masalah.

PEMBARUAN Ada cara untuk mengubah nilai TTL yang digunakan SRX pada permintaan DHCP-nya, tetapi itu bukan dari dalam JunOS cli ... dilakukan dari OS Unix yang mendasarinya.

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

Saya telah membuka RFE dengan HP untuk membuat fungsi relai mereka lebih tangguh, tetapi belum merespons dari mereka jika / ketika itu akan bekerja.

Mungkin sulit untuk memecahkan masalah ketika Anda tidak tahu di mana masalahnya terletak dan Anda memiliki tiga perangkat dari tiga vendor sebelum Anda tampaknya memiliki visibilitas (SRX100, 1400, dan IP670). Saya tidak dapat berbicara dengan perangkat tertentu, tetapi Anda tidak akan pernah salah dengan melacak paket. Karena ProCurve 1400 adalah perangkat yang tidak dikelola, Anda perlu menggunakan ketuk jaringan.

Anda ingin menangkap lalu lintas di lokasi berikut (berdasarkan pernyataan Anda bahwa 3500yl tidak menerima paket temukan):

• Antara SRX100 dan 1400.
• Antara 1400 dan IP670
• Antara IP670 dan 3500yl

Anda dapat melakukan semua ini dari meja Anda, dan ketika satu ketukan mengganggu saat Anda menghubungkan / memutusnya, itu hanya akan mempengaruhi Anda dan perangkat Anda.

Saya akan mulai di bagian atas daftar ini, karena itu akan memungkinkan Anda untuk menangkap paket DHCP setidaknya satu kali dan kemudian setiap tangkapan berikutnya dari paket DHCP menemukan dapat dibandingkan dengan yang satu ini untuk melihat apakah ada modifikasi.

Anda juga mungkin ingin menangkap paket DHCP untuk menemukan dari perangkat yang bekerja juga untuk melihat apakah ada perbedaan dari paket temukan yang dikirim SRX100.

Setelah Anda tahu di mana paket salah, Anda dapat melihat secara khusus pemecahan masalah mengapa itu salah pada saat itu.

Meskipun Anda telah menguji SRX di tempat lain:

1. Apakah SRX mendapatkan alamat dengan konfigurasi yang sama persis di rumah?
   • Ini berarti bahwa yang berikut ini bukan masalah:
   • set security zones security-zone host-inbound-traffic system-services dhcp sudah selesai
   • Konfigurasi antarmuka dasar sudah selesai (baik antarmuka baku, tag vlan, antarmuka dalam vlan yang benar, vlan in
2. Apakah antarmuka benar-benar tampil bersih di sisi Juniper?
   • show interfaces fe-0/0/0 extensive adalah temanmu
   • (Saya tahu ini tidak sesuai untuk ini, tapi tetap saja ...) Untuk antarmuka optik juga periksa level daya: show interfaces diagnostics optics ge-0/0/0
3. Tambahkan jejak ke klien DHCP:

konfigurasikan
mengatur layanan sistem file dhcp traceoptions dhcp_client.log dapat dibaca dunia
setel layanan sistem dhcp traceoptions flag client
setel layanan sistem dhcp tingkat penelusuran semua
komit dan keluar

Kemudian pantau log saat Anda membuka antarmuka monitor start dhcp_client.log. (Ingatlah untuk menghapus jejak pilihan setelah Anda selesai)