एक डीएचसीपी-क्लाइंट क्या "सर्वश्रेष्ठ" उत्तर मानता है?


13

हमारे पास प्रशिक्षण कक्ष हैं जहां सामान्य रूप से विंडोज एक्सपी स्थापित किया जाता है (पीएक्सई के माध्यम से)। "सामान्य" डीएनएस / डीएचसीपी बुनियादी ढांचा विंडोज-सर्वर हैं। प्रशिक्षण कक्ष का अपना वीएलएएन (विंडोज सर्वर से अलग) होता है, इसलिए सिस्को राउटर पर सक्रिय डीएचसीपी अनुरोधों के लिए सबसे अधिक आईपी सहायक है जहां उस कमरे से सभी पीसी जुड़े हुए हैं।

अब हम इसके बजाय कुछ पीसी को लिनक्स में बदलना चाहते थे। यह विचार था: हमारे अपने लैपटॉप को डीएचसीपी सर्वर के साथ कमरे के वीएलएएन में डालें और "सामान्य" डीएचसीपी प्रतिक्रिया को ओवरराइड करें। विचार यह था कि यह काम करना चाहिए, क्योंकि वीएलएएन में सीधे संलग्न डीएचसीपी सर्वर के पास उस वीएलएएन से कुछ हॉप्स स्थित "सामान्य" डीएचसीपी सर्वर की तुलना में तेजी से प्रतिक्रिया-समय होना चाहिए।

यह पता चला कि यह काम नहीं किया। हमें मूल डीएचसीपी सर्वर पर पट्टे को मैन्युअल रूप से जारी करना था ताकि इसे काम किया जा सके।

लैपटॉप पर हमने क्लाइंट को आईपी के लिए अनुरोध करते हुए देखा और "हमारा" dhcp विंडोज आईपी अनुरोध के लिए NACKs भेज रहा था, इससे पहले कि हम अपनी प्रतिक्रिया दें।

पुराना सवाल: यह उम्मीद के मुताबिक काम क्यों नहीं हुआ? क्या पीसी अपने पुराने पट्टे हासिल कर रहा है?

अद्यतन 2012-08-08:

डीएचसीपी-आरएफसी में रीजेन-इश्यू को समझाया गया है। अब यह बताता है कि पीसी अपने पुराने पट्टे को वापस क्यों लेता है।

अब हम एक और कोशिश देने से पहले विंडोज-डीएचसीपी-सर्वर से आईपी जारी करते हैं।

फिर से - विंडोज-डीएचसीपी-सर्वर जीतता है।

मुझे संदेह है कि dhcp- क्लाइंट के लिए कुछ एल्गोरिदम है जो क्लाइंट के लिए "सर्वश्रेष्ठ" dhcp-answer निर्धारित करता है। नया सवाल यह है:

क्लाइंट "सर्वश्रेष्ठ" उत्तर का चयन कैसे करता है?


आप आईपी पता कहाँ जारी कर रहे हैं? विंडोज़ क्लाइंट में, या पीएक्सई बूट एजेंट में?
लॉन्गनेक

@ लॉन्गनेक हमें इसे काम करने के लिए विंडोज-डीएचसीपी सर्वर पर पता जारी करना था।
निल्स

एक नए प्रश्न का उदाहरण देने के लिए अजीब तरीका, आशा है कि आप इसे हल करेंगे
डैनियल ली

जवाबों:


4

यह विक्रेता, यहां तक ​​कि फर्मवेयर विशिष्ट है कि कैसे एक ग्राहक कई डीएचसीपी उत्तरों पर प्रतिक्रिया करता है।

पिछले वर्षों में मैंने जो वेरिएंट देखे हैं:

1) चाहे वह ACK हो या NACK, पहले स्वीकार करें।

2) पहला ACK लें, NACK की पूरी तरह अनदेखी करें।

3) एक निर्धारित समय-अंतराल (आमतौर पर 5-10 सेकंड) के भीतर प्राप्त अंतिम एसीके को लें।

उदाहरण: कुछ साल पहले हमारे पास रिको एमएफपी के मुद्दे थे।
हमारे पास 2 डीएचसीपी सर्वर थे। एक ने पते की आपूर्ति की, दूसरे ने केवल अतिरिक्त डीएचसीपी विकल्प। दूसरा सर्वर हमेशा पहले उत्तर देता है।
रिको के इस्तेमाल किए गए संस्करण 1) भले ही 1 प्रस्ताव में केवल डीएचसीपी विकल्प हों। रिकोह ने इसे वेरिएंट 2 में बदल दिया) एक फर्मवेयर अपडेट के बाद हमने उन्हें समस्या बताई।


OFFERपैकेट क्या क्लाइंट सिस्टम के बीच तय करने की आवश्यकता होगी, है कर रहे हैं। ACKऔर NACKपैकेट केवल एक के जवाब में भेजे जाते हैं REQUEST, जो केवल क्लाइंट द्वारा "तय" किए जाने के बाद होता है, जो बाद में जाने की पेशकश करता है। यह प्रिंटर के साथ एक बहुत अच्छा बग है, हालांकि!
शेन झुंझलाना

@ShaneMadden यह सही है, लेकिन मैंने ग्राहकों के कई मामलों को BOTH ऑफ़र के जवाब में अनुरोध भेजने और फिर मेरे द्वारा बताए गए उत्तरों पर कार्रवाई करने के रूप में देखा है। जब से मैंने इस पर गहराई से देखा, तब तक कुछ समय हो चुका है। मुझे स्पष्ट रूप से याद है कि NT4, W2K और XP इसके लिए दोषी हैं। रिको ने भी किया। उन्होंने लिनक्स 2.2 कर्नेल और नेटवर्क स्टैक चलाया।
टॉन्की

9

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

पीसी: ओह हाय वर्ल्ड, क्या मैं 192.168.1.123 का उपयोग कर सकता हूं?

न्यू-डीएचसीपी: मैं कहता हूं कि नहीं।

ओल्ड-डीएचसीपी: मैं कहता हूं हां।

पीसी: किसी ने कहा हाँ! मीठा, मैं इसका इस्तेमाल करूँगा!


पीसी के कोल्ड-बूट के बाद बातचीत "मेरा मैक एक्सवायजेड है - कृपया मुझे एक आईपी दें"। फिर दोनों डीएचसीपी-सर्वर आईपी की पेशकश करते हैं ... केवल अंतर यह है कि इसमें एक सर्वर पर एक सक्रिय पट्टा है - लेकिन यह सिर्फ सर्वर का परिप्रेक्ष्य है।
निल

1
नहीं अगर पीसी पहले से ही एक आईपी पता था। यदि यह पहले एक डीएचसीपी सर्वर द्वारा सौंपा गया आईपी पता था, तो वह दूसरे पते के लिए पूछने से पहले उस एक का उपयोग करने के लिए कहेगा।
लॉन्गनेक

@ लॉन्गनेक वह आईपी पीसी पर कहाँ संग्रहीत किया जाएगा?
Nils

मेरे सिर के ऊपर से, मुझे नहीं पता। लेकिन इसे साफ़ करने का उचित तरीका है कि आप ipconfig / release
longneck

3
@longneck - सेशन एक PXE पर्यावरण, जहां हम यह सोचते हैं कर रहे हैं कि बूट BIOS पिछले जूते या IP पते के बारे में कोई अनुस्मरण है में के बारे में पूछ रहा है
मार्क हेंडरसन

3

यदि और कुछ नहीं मदद करता है - आरटीएफएम (ठीक मैनुअल पढ़ें)। इस मामले में पहला हिट था।

RFC 2131 डीएचसीपी-ऑपरेशंस की रूपरेखा तैयार करता है।

अनुभाग 1.6 कहा गया है कि डीएचसीपी चाहिए :

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

अब दिलचस्प सवाल यह है कि कैसे डिज़ाइन लक्ष्य को एक ऐसे ग्राहक को प्राप्त किया जा रहा है जिसे इसके अतीत का कोई ज्ञान नहीं है। धारा 3.2 की रूपरेखा:

3.2 क्लाइंट-सर्वर इंटरैक्शन - पहले से आवंटित नेटवर्क पते का पुन: उपयोग करना

यदि कोई ग्राहक पहले से आवंटित
नेटवर्क पते का पुन: उपयोग करना याद रखता है और चाहता है , तो ग्राहक
पिछले अनुभाग में वर्णित कुछ चरणों को छोड़ना चुन सकता है । चित्र 4 में समय रेखा चित्र
पहले से आवंटित नेटवर्क पते का पुन: उपयोग करने वाले क्लाइंट के लिए एक विशिष्ट क्लाइंट-सर्वर इंटरैक्शन में समय संबंधों को दर्शाता है।

  1. क्लाइंट अपने स्थानीय सबनेट पर एक DHCPREQUEST संदेश प्रसारित करता है। संदेश में 'अनुरोधित आईपी पते' विकल्प में ग्राहक का नेटवर्क पता शामिल है। चूंकि क्लाइंट को अपना नेटवर्क पता नहीं मिला है, इसलिए उसे 'ciaddr' फ़ील्ड में नहीं भरना चाहिए। BOOTP रिले एजेंट DHCP सर्वर पर संदेश को एक ही सबनेट पर नहीं पास करते हैं। यदि क्लाइंट ने अपना पता प्राप्त करने के लिए 'क्लाइंट पहचानकर्ता' का उपयोग किया है, तो क्लाइंट को DHCPREQUEST संदेश में समान 'क्लाइंट पहचानकर्ता' का उपयोग करना होगा।

  2. क्लाइंट के कॉन्फ़िगरेशन पैरामीटर के ज्ञान वाले सर्वर क्लाइंट को एक DHCPACK संदेश के साथ प्रतिक्रिया करते हैं। सर्वर यह जाँच नहीं करते कि ग्राहक का नेटवर्क पता पहले से उपयोग में है; क्लाइंट इस बिंदु पर ICMP इको अनुरोध संदेशों का जवाब दे सकता है।

तो एक डीएचसीपी-सर्वर एक सक्रिय पट्टा धारण करता है जो प्रोटोकोल में एक शॉर्टकट का उपयोग करके पूर्वता प्राप्त करता है।

  1. क्लाइंट: DHCREQUEST (MAC-Adress, प्रसारण, स्थानीय प्रसारण डोमेन में प्रसारण किया जाएगा - यहाँ स्थानीय VLAN और IP- हेल्पर के माध्यम से Windows-DHCP- सर्वर पर)
  2. लैपटॉप-डीएचसीपी-सर्वर: DHCPOFFER
  3. विंडोज-डीएचसीपी-सर्वर: अरे - मैं पहले से ही आपको जानता हूं - डीएचसीपीएसी
  4. ग्राहक: ओह - मुझे दो प्रतिक्रियाएं मिलीं। एक जो मुझे पहले से ही जानता है। कूल मैं ले जाऊंगा

तब से Laptop-DHCP-Server को क्लाइंट द्वारा नजरअंदाज किया जा रहा है।

तो हमारे मामले में समाधान शायद होगा (मैं इसे तब अपडेट करूंगा जब हम वास्तव में इसका परीक्षण करेंगे):

  1. सुनिश्चित करें कि क्लाइंट बंद है
  2. लैपटॉप पर डीएचसीपी-सर्वर, लैपटॉप पर नकली क्लाइंट-मैक, डीएचसीपी-अनुरोध बंद करें
  3. IP जारी करें
  4. मूल आईपी और मैक प्राप्त करें, डीएचसीपी-सर्वर चालू करें
  5. ग्राहक चालू करें और एक PXE- बूट करें ...

3

नया सवाल शायद एक अलग सवाल में होना चाहिए - सवाल का शीर्षक सवाल के शरीर के अधिकांश के साथ बिल्कुल फिट नहीं है।

किसी भी मामले में, कोई ग्राहक कैसे चुनता है कि वह किस पेशकश के साथ जाने की पेशकश करता है, उस स्थिति में जहां उसका कोई वर्तमान पट्टा नहीं है: यह ग्राहक के लिए है, लेकिन प्रत्येक डीएचसीपी ग्राहक कार्यान्वयन में जिसे मैं जानता हूं, यह एक सरल दौड़ है ।

RFC 2131 इसमें शामिल है:

डीएचसीपी क्लाइंट उन लोगों में से एक डीएचसीपी सर्वर का चयन करने के लिए किसी भी रणनीति का उपयोग करने के लिए स्वतंत्र हैं, जिसमें से क्लाइंट को डीएचसीओएफएफआर संदेश प्राप्त होता है।

वहाँ एक IETF ड्राफ्ट है जो ऐसा लगता है कि मृत है जो चयन प्रक्रिया में विन्यासता को जोड़ देगा, और इसमें एक ग्राहक की कमी (एक दशक से अधिक पहले, लेकिन बहुत कुछ नहीं बदला है) का भी उल्लेख किया गया है:

व्यवहार में, नीति के अधिकांश विक्रेता का यहाँ कार्यान्वयन बहुत ही बुनियादी है (जैसे, पहला प्रस्ताव प्राप्त या पहला स्वीकार्य प्रस्ताव) और यह "हार्ड-कोडेड" (यानी, गैर-विन्यास योग्य) है।

एक ही नेटवर्क के लिए अलग-अलग कॉन्फ़िगरेशन के साथ सेवा प्रदान करने वाले दो डीएचसीपी सर्वर होने से परिणाम केवल दौड़ में आते हैं, जो विश्वसनीयता या पूर्वानुमान की दृष्टिकोण से वांछनीय नहीं है। वास्तव में कोई कारण नहीं है कि आप अपना एकल डीएचसीपी सर्वर प्राप्त नहीं कर सकते जो आपको चाहिए।


आपको लगता है कि "स्वीकार्य" ऑफ़र dhcp-client पक्ष पर विक्रेता-विशिष्ट है? चूंकि हमारे मामले में यह "पहला" प्रस्ताव नहीं है, इसलिए इसे कुछ और होना चाहिए - व्यवहार हालांकि काफी निर्धारक है, इसलिए मुझे अभी भी लगता है कि इसके पीछे एक सामान्य मानक है।
निल्स

@ निल्स क्या आप पूरी तरह से निश्चित हैं कि विंडोज सर्वर क्लाइंट को उसी कमरे में लैपटॉप से ​​पहले अपनी प्रतिक्रिया नहीं दे रहा है? यह सहज रूप से ऐसा लगता है जैसे लैपटॉप को उस दौड़ को जीतना चाहिए, लेकिन ऐसा नहीं हो सकता है।
शेन झुंझलाना

मुझे लगता है कि मुझे नेटवर्क स्तर पर (वायरशर्क के साथ) यह पता लगाना होगा कि वास्तव में वहां क्या हो रहा है। संभवत: उस क्लाइंट के मिरर-पोर्ट पर ...
Nils
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.