HP Procurve DHCP रिले के साथ SRX DHCP क्लाइंट संगतता

Question

मैं कुछ जुनिपर SRX100s पर कॉन्फ़िगर को बूटस्ट्रैप करने की कोशिश कर रहा हूं और कुछ डीएचसीपी मुद्दों पर चल रहा हूं।

विशेष रूप से, मैं अपने मौजूदा नेटवर्क में 0/0 पोर्ट (सॉफ्टवेयर में fe-0/0/0) को कनेक्ट कर रहा हूं, जहां डीएचसीपी ने मेरे द्वारा उपयोग किए जाने वाले प्रत्येक अन्य डिवाइस के बारे में काफी भरोसेमंद रूप से काम किया है। SRX100s को DHCP पते नहीं मिल रहे हैं। SRX100 जब मैं यह प्रयास कर रहा हूँ तो यह एक आउट-ऑफ-द-बॉक्स डिफ़ॉल्ट कॉन्फिग है।

मैं अपने घर में उपकरणों में से एक लाया और इसे अपने घर नेटवर्क में प्लग किया और इसे बिना किसी समस्या के डीएचसीपी के माध्यम से अपने घर नेटवर्क पर एक आईपी पता मिला।

मेरे कार्यालय नेटवर्क में मेरे डेस्कटॉप पर एक Procurve 1400 (लेयर 2 केवल) स्विच है, जो एक Polycom IP670 IP फोन (एक साधारण लेयर 2 स्विच के रूप में कार्य करता है) के लिए अपलिंक है, एक Procurve 3500yl स्विच के साथ नेटवर्क के लिए एक राउटर के रूप में "ip" है। डीएचसीपी सर्वर के लिए डीएचसीपी सर्वर की ओर इशारा करते वलान इंटरफेस पर हेल्पर-एड्रेस 1.1.1.1 "।

क्या किसी को SRX DHCP क्लाइंट को Procurve (K.15.09.0012 सॉफ़्टवेयर चलाकर) IP पता प्राप्त करने का कोई अनुभव है ... हालाँकि समस्या Procurve पर कई फर्मवेयर संस्करणों में मौजूद है)। SRX100s बॉक्स से बाहर आने पर उन पर 11.2 लगते हैं, हालांकि मुझे लगता है कि 12.1X44-D10.4 में अपग्रेड होने पर समस्या बनी रहती है।

किसी को भी इस समस्या निवारण के लिए कोई सुझाव है? Procurve 3500yl SRX100 से DHCP क्लाइंट अनुरोध को देखने के लिए स्वीकार करने के लिए नहीं लगता है, लेकिन इस क्षेत्र में Procurves पर समस्या निवारण जानकारी सीमित लगती है। DHCP सर्वर निश्चित रूप से SRX100 से संबंधित किसी भी DHCPDISCOVER पैकेट को नहीं देखता है।

मेरा वर्कअराउंड SRX100s पर एक IP एड्रेस को स्टेटिक रूप से कॉन्फ़िगर करने के लिए किया गया है, उन्हें नेटवर्क पर लाने के लिए और मेरे बाकी के कॉन्फिगर करने के लिए, लेकिन जिस प्रोजेक्ट पर मैं काम कर रहा हूं उसमें SRX100s को रिमोट लोकेशन पर भेजना शामिल है जो मेरे नियंत्रण में नहीं हैं और इस प्रकार, कनेक्टिविटी के लिए उन पर निर्भरतापूर्वक डीएचसीपी पते प्राप्त करना निर्भर करता है, इसलिए मैं वास्तव में इसका निवारण करना चाहता हूं और एक विशिष्ट कारण को नीचे चलाना चाहता हूं, इसलिए मुझे पता है कि दूरस्थ साइटों पर ऐसा होने पर संभावित रूप से क्या देखना है।

अद्यतन: मेरे पास (एसएक्सएक्स -100 को फ़ैक्टरी-डिफॉल्ट करने के लिए) है, और इसे सीधे प्रोकुरवे 3500yl पर एक पोर्ट में प्लग किया गया है और अभी भी समस्या को देख रहा हूं, ताकि चर्चा से 1400 और आईपी 670 फोन को हटा दिया जाए। मैंने नीचे SRX100 से tcpdump आउटपुट को शामिल किया है ... जैसा कि आप देख सकते हैं, इसका सबसे सरल संभव डीएचसीपी पैकेट के बारे में पता लगाना, जब यह सुझाव देता है कि समस्या 3500yl पर dhcp-relay फ़ंक्शन के साथ है। मैं किसी भी डिबग आउटपुट को पाने के लिए किसी भी तरह से डिबक-रिले फ़ंक्शन (सफलतापूर्वक या अन्यथा) को मारते हुए पैकेट दिखाते हुए 3500yl से नहीं पा सकता। 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

Comments

क्या आपने यह सुनिश्चित करने के लिए SRX को सीधे 3500yl से जोड़ने की कोशिश की है कि न तो 1400 से अधिक है या पॉलीकॉम DHCPDISCOVER प्रसारण को फ़िल्टर कर रहा है?

— डेविड रोथरा

मैंने नहीं किया है, और यह एक बुरा विचार नहीं है। मैं, हालांकि, इस अवसर पर, अन्य प्रणालियों को समान तरीके से जोड़ता हूं और अन्य डेस्कटॉप पर डीएचसीपी पते प्राप्त करता हूं, जिसमें मेरी डेस्कटॉप मशीनें भी शामिल हैं जो लगातार इस तरीके से नेटवर्क पर हैं, जिससे कि समस्या होने की संभावना नहीं है। मैं देखूंगा कि क्या मैं उसका परीक्षण कर सकता हूं, हालांकि।

— जेफ मैक एडम्स

मेरी प्रतिक्रिया में कुछ जानकारी के साथ अपडेट किया ... विशेष रूप से SRX में डीएचसीपी अनुरोधों के टीटीएल मान को बदलने के साथ-साथ यह भी ध्यान दिया कि मैंने एचपी के साथ एक आरएफई खोला है।

— जेफ मैकएडम्स

Answer 1

मैंने इस मुद्दे से संबंधित एचपी के साथ एक मामला खोला। बेकार स्तर 1 तकनीक से आगे बढ़ने के बाद, स्तर 2 तकनीक ने बहुत सतर्कता से कुछ देखा जो मैंने नहीं किया था।

SRX अपने DHCPDISCOVER पैकेट को 1. TTL के साथ भेज रहा है। Procurve के जाहिरा तौर पर TTL को घटा देगा और परिणामी TTL को डीएचसीपी सर्वर में रिले पैकेट में उपयोग करेगा। इस मामले में, गिरावट टीटीएल को 0 पर छोड़ देती है जिसका अर्थ है कि फर्श पर पैकेट गिरा हुआ है।

यह वास्तव में डीएचसीपी / बीओओटीपी रिले के संबंध में है, हालांकि स्पष्ट रूप से यह कम अंतर का कारण बनता है। मैंने HPNetworking को इसे बग / RFE के रूप में मानने और व्यवहार को बदलने के लिए कहा है। मामले में उस अनुरोध पर कोई तत्काल प्रतिक्रिया नहीं।

1 के TTL के साथ DHCPDISCOVER भेजने वाला SRX भी शायद कल्पना के भीतर है, लेकिन, फिर से, कम अंतर की पसंद, इसलिए मैं उसी आधार पर JTAC के साथ एक मामला खोलने की योजना बना रहा हूं।

मैं जुनिपर और एचपी की प्रतिक्रिया पर अधिक जानकारी जोड़ूंगा क्योंकि यह उपलब्ध है।

संयोग से, मैंने एक सिस्को 4506 (फ़र्मवेयर संस्करण तुरंत उपलब्ध नहीं) के रिले व्यवहार का परीक्षण किया है, और एक ब्रोकेड / फाउंड्री फास्टरोन एज एक्स (7.2 या 7.3 फ़र्मवेयर, मेरा मानना ​​है कि पुष्टि करने के लिए तत्काल पहुंच नहीं है) और वे दोनों को संभालते हैं समस्या के बिना TTL 1 के साथ अनुरोध को रिले करना।

अद्यतन टीटीएल मान को बदलने का एक तरीका है जो एसआरएक्स अपने डीएचसीपी अनुरोधों पर उपयोग करता है, लेकिन इसके पास नहीं है जो जुनोस क्ली के भीतर से है ... इसका अंतर्निहित यूनिक्स ओएस से किया गया है।

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

मैंने उनके रिले फंक्शन को अधिक लचीला बनाने के लिए HP के साथ एक RFE खोला है, लेकिन उन पर अभी तक प्रतिक्रिया नहीं हुई है कि क्या / जब उस पर काम किया जाएगा।

Answer 2

जब आपको पता नहीं है कि समस्या कहाँ है, तो उसका निवारण करना कठिन हो सकता है और आपके पास तीन विक्रेताओं के तीन उपकरण हैं, इससे पहले कि आपको कोई दृश्यता हो (SRX100, 1400 और IP670)। मैं विशिष्ट उपकरणों से बात नहीं कर सकता, लेकिन पैकेट ट्रेस करके आप कभी गलत नहीं हो सकते। चूंकि ProCurve 1400 एक अप्रबंधित उपकरण है, इसलिए आपको नेटवर्क टैप का उपयोग करने की आवश्यकता होगी।

आप निम्नलिखित स्थानों में ट्रैफ़िक कैप्चर करना चाहते हैं (आपके कथन के आधार पर कि 3500yl खोज पैकेट प्राप्त नहीं कर रहा है):

• SRX100 और 1400 के बीच।
• 1400 और IP670 के बीच
• IP670 और 3500yl के बीच

आप इन सभी को अपने डेस्क से कर सकते हैं, और जब आप इसे कनेक्ट / डिस्कनेक्ट कर रहे हैं, तो एक नल विघटनकारी है, यह केवल आपको और आपके उपकरणों को प्रभावित करना चाहिए।

मैं इस सूची के शीर्ष पर शुरू करूंगा, क्योंकि यह आपको कम से कम एक बार डीएचसीपी खोज पैकेट पर कब्जा करने की अनुमति देनी चाहिए और फिर डीएचसीपी खोज पैकेट के बाद के किसी भी कैप्चर की तुलना इस से की जा सकती है कि क्या कोई संशोधन है या नहीं।

आप उन उपकरणों से DHCP खोज पैकेट कैप्चर करना चाहते हैं जो यह देखने के लिए काम कर रहे हैं कि क्या SRX100 द्वारा भेजे गए पैकेट से कोई अंतर है या नहीं।

एक बार जब आप जान जाते हैं कि पैकेट कहाँ गलत है, तो आप विशेष रूप से समस्या निवारण में देख सकते हैं कि यह उस बिंदु पर गलत क्यों है।

Comments

हाँ, मैं अभी तक उन विशिष्ट चरणों में नहीं गया हूँ क्योंकि मुझे बहुत अच्छा विश्वास है कि 1400 और ip670 मज़बूती से केवल परत 2 हैं और इस प्रकार डीएचसीपी ट्रैफ़िक के बारे में नहीं सोचा जा सकता है। मुझे लगता है कि समस्या SRX और 3500yl के बीच किसी प्रकार की असंगति है। मुझे संदेह है कि पैकेट 3500yl को मिल रहा है, लेकिन इसे सही तरीके से नहीं संभाल रहा है। यह इंगित करने के लिए मुझे 3500yl नहीं मिल सकता है कि यह पैकेट मुझे लगता है कि 35,000yl पर सीमित डिबगिंग क्षमताओं के कारण अधिक है।

— जेफ मैकएडम्स

@JeffMcAdams, मैं उस मूल्यांकन से सहमत होना चाहूंगा, लेकिन पहले अजीब मुद्दों से आश्चर्यचकित हो गया था। चूँकि आप अपने डेस्क से उन सभी जगहों पर नल को स्थानांतरित कर सकते हैं, मैं पैकेट का पालन करने की गारंटी देता हूं कि चीजें अपेक्षित रूप से काम कर रही हैं। यदि आपको नेटवर्क कोठरी, फर्श, इमारतों या साइटों के बीच स्थानांतरित करना था, तो मैं कहूंगा कि जहां समस्या है और वहां शुरू करें। इसके अलावा, एक अच्छा ज्ञात खोज पैकेट प्राप्त करने से आपको पता चल जाएगा कि क्या इसमें कुछ "अतिरिक्त" हो सकता है, आपका डीएचसीपी सर्वर पसंद नहीं करता है (विकल्प 82 या शायद कुछ और)।

— YLearn

Answer 3

यद्यपि आपने SRX का अन्यत्र परीक्षण किया है:

1. क्या SRX को घर पर सटीक समान कॉन्फ़िगरेशन के साथ एक पता मिलता है ?
   • इसका मतलब यह होना चाहिए कि निम्नलिखित मुद्दे नहीं हैं:
   • set security zones security-zone host-inbound-traffic system-services dhcp हो गया है
   • बेसिक इंटरफ़ेस कॉन्फिगर किया गया (या तो कच्चा इंटरफ़ेस, वलान टैग, सही व्लान में इंटरफ़ेस, वह वलान
2. क्या इंटरफ़ेस वास्तव में जुनिपर की तरफ साफ-साफ आता है?
   • show interfaces fe-0/0/0 extensive आपका दोस्त है
   • (मुझे पता है कि यह इसके लिए उपयुक्त नहीं है, लेकिन फिर भी ...) ऑप्टिकल इंटरफेस के लिए भी बिजली के स्तर की जांच करें: show interfaces diagnostics optics ge-0/0/0
3. DHCP क्लाइंट में एक ट्रेस जोड़ें:

कॉन्फ़िगर
सेट सिस्टम सेवाएँ dhcp ट्रेसॉप्शन फ़ाइल dhcp_client.log विश्व-पठनीय
सिस्टम सेवाओं को सेट करें dhcp ट्रेसॉप्शन ध्वज ग्राहक
सिस्टम सेवाएं सेट करें dhcp ट्रैसटॉप्शन स्तर सभी
प्रतिबद्ध और छोड़ दिया

तब लॉग की निगरानी करें क्योंकि आप इंटरफ़ेस को ऊपर ला रहे हैं monitor start dhcp_client.log। (याद रखें कि आपके द्वारा एक बार ट्रेसओप्शन हटाने के बाद)

Comments

1. हाँ, मैं ब्रेक-ऑफ-द-आउट-ऑफ-द-बॉक्स-फ़ैक्टरी-डिफ़ॉल्ट कॉन्फिग्स, दोनों घर पर और कार्यालय में कर रहा हूं। फ़ैक्टरी डिफ़ॉल्ट कॉन्फ़िगरेशन में होस्ट-इनबाउंड-ट्रैफ़िक सिस्टम-सेवाएँ dhcp शामिल हैं, जो कि fe-0/0 / 0.0 इंटरफ़ेस पर उपयोग किया जा रहा है। 2. हां, इंटरफ़ेस साफ-सुथरा है, और अगर मैं उस पर IP जानकारी को स्थिर करता हूं, तो यह ठीक काम करता है। 3. मैंने मूल प्रश्न को पैकेट के एक tcpdump के साथ संपादित किया है ... मैं कभी भी एक पैकेट वापस नहीं देखता, और कभी पैकेट को DHCP सर्वर को हिट नहीं देखता।

— जेफ मैकएडम्स