DHCPDISCOVER / DHCPOFFER, लेकिन कोई DHCPACK नहीं


17

मेरे पास एक दूरस्थ क्लाइंट मशीन है जो डीएचसीपीआईएससीओओआरवी के बाहर भेज रही है। सर्वर DHCPOFFER के साथ प्रतिक्रिया दे रहा है, लेकिन कोई DHCPACK नहीं है।

यह एक ही मेजबान से लगभग 30 सेकंड दोहराता है। क्या ऐसा कुछ है जिसे मैं दूरस्थ रूप से कर सकता हूं या क्या मुझे इसे रिबूट करने के लिए किसी की आवश्यकता है? यह एक डेटा सेंटर में है इसलिए मुझे इसे करने के लिए यात्रा करनी पड़ सकती है!


सुझाव के लिए धन्यवाद। मैंने सभी मशीनों को रिबूट किया है, लेकिन मेरे पास अभी भी मुद्दे हैं। मुझे लगता है कि मेरे कॉन्फ़िगरेशन के साथ एक समस्या है। क्या यह सही लगता है?

#
# /etc/dhcpd.conf for primary DHCP server
#

authoritative;
ddns-update-style none;
deny duplicates;
default-lease-time 600;
max-lease-time 3600;

# Our fixed hosts
host host2  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.202; }
host host3  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.203; }
host host4  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.204; }
host host5  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.205; }

subnet x.x.x.128 netmask 255.255.255.128 {
  option subnet-mask 255.255.255.128;
  option broadcast-address x.x.x.255;
  option routers x.x.x.129;
  option domain-name-servers 8.8.8.8, 8.8.4.4;

  # Testing pool.
  pool {
    max-lease-time 300; # 5 minutes
    range x.x.x.250 x.x.x.254;
    deny known-clients;
  }

  # Our hosts - I didn't have this pool declaration before, do I need it if I want
  # the hosts to be running dhcp but always get the same address?
  pool {
    max-lease-time 1800;
    range x.x.x.200 x.x.x.220;
    deny unknown-clients;
  }
}

DHCPRequest को DHCPAck से पहले आना चाहिए। क्या आप उसे देख रहे हैं? सर्वर पर एक पैकेट कैप्चर चलाने की कोशिश करें और सर्वर से DHCPDiscover, DHCPOffer, DHCPRequest और DHCPAck देखें। क्या क्लाइंट सर्वर के समान LAN खंड पर है? यदि नहीं, तो क्या दो डीएचसीपी रिले के रूप में कॉन्फ़िगर किए गए राउटर को अलग किया जा रहा है?
जोकेवेटी

यह पता चला कि समस्या एक गलत धारणा के कारण थी। मेरे पास एक डायनामिक रेंज ओवरलैप करने वाली स्टैटिक रेंज थी।
मैट

जवाबों:


14

यह जाता है:

CLIENT -> DHCPDISCOVER
SERVER -> DHCPOFFER
CLIENT -> DHCPREQUEST
SERVER -> DHCPACK

आप अपने विवरण में DHCPACK से पहले DHCPREQUEST को याद कर रहे हैं।

यदि क्लाइंट DHCP सर्वर से अलग सबनेट पर है, तो DHCPOFFER को 67 UDP पोर्ट पर DHCP- रिले के साथ यूनिकस्ट भेजा जाता है। DHCP-relay एजेंट DHCPOFFER को UDP पोर्ट 68 पर सबनेट में प्रसारित करता है।

मैं DHCPOFFER से जुड़े कनेक्टिविटी मुद्दों की जाँच करूँगा। इसे ट्रैक करें और देखें कि क्या यह क्लाइंट के पास वापस जाता है और यदि ऐसा होता है, तो क्लाइंट DHCPREQUEST क्यों नहीं है: पते का उपयोग करें।

एक सामान्य dhcp रिले एजेंट एक विशिष्ट इंटरफ़ेस के तहत सिस्को स्विचेस में "आईपी हेल्पर-एड्रेस" विकल्प है।


10

अपने डीएचसीपी-सर्वर और डीएचसीपी-क्लाइंट का समर्थन करना दोनों एक ही ईथरनेट सेगमेंट से जुड़े हैं, और इस तरह के ईथरनेट सेगमेंट को विभिन्न "ट्रंक" ( 802.1q) के साथ जुड़े कई L2- स्विचेस फैलाते हैं ) लिंक के , मैं ऐसे ही मुद्दों पर चला गया था जब वहाँ था कम से कम एक ट्रंक लिंक के कॉन्फ़िगरेशन के बीच एक बेमेल।

विस्तार से, DHCP-DISCOVER / DHCP-OFFER (जैसा कि डीएचसीपी-सर्वर साइड से देखा गया है) का कभी खत्म न होने वाला चक्र, मुझे लगता है कि DHCP- क्लाइंट नहीं है DHCP-OFFER प्राप्त रहा है और इसलिए, DHCP को फिर से जोड़ना -DISCOVER संदेश। इस तरह के डीएचसीपी-डिस्कोवर (जैसा कि डीएचसीपी-क्लाइंट पक्ष से देखा जाता है) डीएचसीपी-सर्वर्स से सही ढंग से प्राप्त होता है।

निम्नलिखित परिदृश्य को ध्यान में रखते हुए: यहाँ छवि विवरण दर्ज करें दो ट्रंक पोर्ट के गलत / बेमेल सेटअप का मतलब है कि:

  • VLAN X ट्रैफिक (या DHCP- सर्वर से DHCP- क्लाइंट तक) SW A द्वारा SW A द्वारा भेजा गया UNTAGGED है;
  • VL B ने SW B द्वारा SW A द्वारा ट्रंक (या डीएचसीपी-क्लाइंट से डीएचसीपी-सर्वर तक) के साथ भेजा गया ट्रैगेड है।
  • SW B के ट्रंक पोर्ट के देशी वीएलएएन सेटअप के कारण, डीएचसीपी-क्लाइंट को डीएचसीपी-सर्वर से पैकेट प्राप्त नहीं होंगे ।

यदि आप DHCP- क्लाइंट होस्ट को "नियंत्रित" करते हैं , तो इसका निवारण करना बहुत आसान है । ऐसे मामले में, eth0 को दबाना एक नेटवर्क इंटरफ़ेस है जिसका उपयोग डीएचसीपी-क्लाइंट होस्ट द्वारा किया जाता है, एक सरल:

tcpdump -n -i eth0 ether-host <dhcp-server-mac-address>

दिखाएगा कि क्या क्लाइंट को डीएचसीपी-सर्वर डीएचसीपी-सर्वर से प्राप्त होता है, या नहीं।

यदि आप क्लाइंट-साइड को नियंत्रित नहीं कर सकते हैं तो समस्या का निवारण करना अधिक कठिन है ।

पुनश्च: स्पष्ट रूप से उपरोक्त समस्याएं, साथ ही साथ अन्य संबंधित तर्क, आसानी से इस्तेमाल की जाने वाली उचित तकनीकों (जैसे GVRP , VTP या अन्य नहीं-कड़ाई से मैनुअल-कॉन्फ़िगर-दृष्टिकोण) से बचा जा सकता है लेकिन ... यह इस उत्तर के दायरे से बाहर है


ऐसा प्रतीत होता है कि यह डीएचसीपी सर्वर में एक सॉफ्टवेयर बग के परिणामस्वरूप भी हो सकता है, जब सर्वर-साइड इंटरफ़ेस को विभिन्न वीएलएएन के पार किया जाता है।
डस्टवॉल्फ

6

एक ही मुद्दा था। कोई भी DHCPACK नहीं देख रहा है। समस्या यहाँ थी:

भरी हुई डिस्क

dhcpd को नहीं लिख सका /var/lib/dhcp/dhcpd.leases


बहुत धन्यवाद। मैं खोज, प्रस्ताव, अनुरोध, अनुरोध, अनुरोध और कोई एके देख रहा था और यही कारण था। या तो / var / log / syslog में कुछ भी नहीं था, उसी कारण से। यह समय के बारे में है जब मैंने पहली बार यह जांचना सीखा जब मुझे अजीब व्यवहार दिखाई देता है जो अचानक शुरू होता है।
रोब फिशर

3

मैंने इसे कुछ बार देखा है और अब तक मैंने केवल दो कारण देखे हैं:

  • डीएचसीपी सर्वर द्वारा दिया गया आईपी पता किसी अन्य डिवाइस द्वारा पहले से उपयोग में है। आमतौर पर आप एक DHCPNAK देखेंगे।
  • आपका फ़ायरवॉल ट्रैफ़िक को dhcp सर्वर में स्वीकार कर रहा है, लेकिन ट्रैफ़िक वापस नहीं

सौभाग्य से दोनों का परीक्षण आसान होना चाहिए। आईपी ​​पते को पिंग करें और प्रासंगिक फायरवॉल की जांच करें।


धन्यवाद। मैंने दिए गए पते को पिंग किया लेकिन कोई प्रतिक्रिया नहीं हुई। फिर मैंने इसके लिए एक अलग प्रविष्टि देने के लिए एक मेजबान प्रविष्टि की स्थापना की, लेकिन इससे कोई मदद नहीं मिली। फ़ायरवॉल की जाँच करेगा।
मैट

0

मैं वर्चुअल बॉक्स का उपयोग करके फायरवॉल के बारे में सीख रहा हूं और मुझे सर्वर पर DHCPACK नहीं मिलने का एक समान मुद्दा था और यह पता चला कि एक ubuntu फ़ायरवॉल vm के लिए परीक्षण ग्रीन (आंतरिक) नेटवर्क के लिए गलत वर्चुअल बॉक्स नेटवर्क सेटिंग्स का उपयोग कर रहा था एक परीक्षण ubuntu ग्राहक वी.एम. यदि आप vb आंतरिक नेटवर्क के बजाय NAT नेटवर्क का उपयोग करते हैं तो क्लाइंट vm को DHCP सर्वर vm के बजाय vb से अपना ip मिलता है। लॉग क्लाइंट से अनुरोध प्राप्त करने वाले सर्वर को दिखाते हैं, लेकिन क्लाइंट को इसके बजाय vb से अपना आईपी मिलता है, इसलिए आपको कभी भी सर्वर पर वापस भेजा गया ACK नहीं मिलता है।


0

मेरे लिए यह क्लाइंट पर डीएचसीपी सर्वर (इंटरनेट शेयरिंग के माध्यम से) को बंद करने के लिए भूलने का मामला था। जैसे ही मैंने उसे बंद किया, डीएचसीपी पट्टे को स्वीकार कर लिया गया:

Apr 16 03:54:18 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:54:18 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:54:26 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:54:26 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:34 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:55:34 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:35 dnsmasq-dhcp[5952]: DHCPREQUEST(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:35 dnsmasq-dhcp[5952]: DHCPACK(eth0) 10.0.0.4 40:6c:8f:59:24:8e Heaths-MBP
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.