Windows Server 2008 R2 नेटवर्क एडॉप्टर काम करना बंद कर देता है, इसके लिए हार्ड रिबूट की आवश्यकता होती है

Question

TL; DR संस्करण: यह विंडोज सर्वर 2008 R2 में एक गहरी ब्रॉडकॉम नेटवर्किंग बग था। इंटेल हार्डवेयर की जगह इसे तय किया। हम ब्रॉडकॉम हार्डवेयर का उपयोग नहीं करते हैं। कभी।

हम लिनक्स-हा परियोजना से दिल की धड़कन के साथ-साथ HAProxy का उपयोग कर रहे हैं । हम एक विफलता प्रदान करने के लिए दो लिनक्स उदाहरणों का उपयोग कर रहे हैं। प्रत्येक सर्वर का अपना सार्वजनिक IP और एक एकल IP होता है, जो दोनों के बीच एक वर्चुअल इंटरफ़ेस (eth1: 1) का उपयोग करके IP: 69.59.196.211 पर साझा किया जाता है

वर्चुअल इंटरफ़ेस (eth1: 1) IP 69.59.196.211 उनके पीछे विंडो सर्वर के गेटवे के रूप में कॉन्फ़िगर किया गया है और हम मार्ग यातायात के लिए ip_forwarding का उपयोग करते हैं।

हम अपने लिनक्स गेटवे के पीछे हमारे एक विंडोज सर्वर पर एक सामयिक नेटवर्क आउटेज का सामना कर रहे हैं। HAProxy सर्वर का पता लगाएगा जो ऑफ़लाइन है जिसे हम विफल सर्वर को हटाकर गेटवे को पिंग करने का प्रयास कर सकते हैं:

32 बाइट डेटा के साथ 69.59.196.211 पिंग करना:
69.59.196.220 से उत्तर: गंतव्य मेजबान पहुंच से बाहर है।

arp -aइस विफल सर्वर पर चलने से पता चलता है कि प्रवेश द्वार के पते (69.59.196.211) के लिए कोई प्रविष्टि नहीं है :

इंटरफ़ेस: 69.59.196.220 --- 0xa
इंटरनेट पता भौतिक पता प्रकार
69.59.196.161 00-26-88-63-c7-80 गतिशील
69.59.196.210 00-15-5d-0a-3e-0e गतिशील
69.59.196.212 00-21-5e-4d-45-c9 गतिशील
69.59.196.213 00-15-5d-00-b2-0d गतिशील
69.59.196.215 00-21-5e-4d-61-1a गतिशील
69.59.196.217 00-21-5e-4d-2c-e8 गतिशील
69.59.196.219 00-21-5e-4d-38-e5 गतिशील
69.59.196.221 00-15-5d-00-b2-0d गतिशील
69.59.196.222 00-15-5d-0a-3e-09 गतिशील
69.59.196.223 ff-ff-ff-ff-ff-ff-static
224.0.0.22 01-00-5e-00-00-16 स्थिर
224.0.0.252 01-00-5e-00-00-fc स्थिर
225.0.0.1 01-00-5e-00-00-01 स्थिर

हमारे लिनक्स गेटवे उदाहरणों पर arp -aपता चलता है:

eth1 पर <अपूर्ण> <शिखर> colo-196-220.peak.org (69.59.196.220)
stackoverflow.com (69.59.196.212) पर 00: 21: 5e: 4d: 45: c9 [ईथर] eth1 पर
पीक-colo-196-215.peak.org (69.59.196.215) 00: 21: 5e: 4d: 61: 1a [ईथर] eth1 पर
चोटी-colo-196-219.peak.org (69.59.196.219) 00: 21: 5e: 4d: 38: e5 [ईथर] eth1 पर
चोटी- colo-196-222.peak.org (69.59.196.222) 00: 15: 5d: 0a: 3e: 09 [ईथर] eth1 पर
चोटी- colo-196-209.peak.org (69.59.196.209) 00: 26: 88: 63: c7: 80 [ईथर] eth1 पर
चोटी- colo-196-217.peak.org (69.59.196.217) 00: 21: 5e: 4d: 2c: e8 [ईथर] eth1 पर

Arp कभी-कभी इस असफल सर्वर के लिए प्रविष्टि को <अपूर्ण> के रूप में क्यों सेट करेगा? क्या हमें अपनी arp प्रविष्टियों को सांख्यिकीय रूप से परिभाषित करना चाहिए? मैंने हमेशा 99% काम करने के बाद अकेले arp छोड़ दिया है, लेकिन इस एक उदाहरण में यह विफल हो रहा है। क्या कोई अतिरिक्त समस्या निवारण चरण हैं जो हम इस समस्या को हल करने में मदद कर सकते हैं?

हमें पता चला है

मैंने लिनक्स गेटवे में से एक पर परीक्षण के लिए एक स्थिर arp प्रविष्टि जोड़ी जो अभी भी मदद नहीं की।

root@haproxy2:~# arp -a
peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a [ether] on eth1
peak-colo-196-221.peak.org (69.59.196.221) at 00:15:5d:00:b2:0d [ether] on eth1
stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 [ether] on eth1
peak-colo-196-219.peak.org (69.59.196.219) at 00:21:5e:4d:38:e5 [ether] on eth1
peak-colo-196-209.peak.org (69.59.196.209) at 00:26:88:63:c7:80 [ether] on eth1
peak-colo-196-217.peak.org (69.59.196.217) at 00:21:5e:4d:2c:e8 [ether] on eth1
peak-colo-196-220.peak.org (69.59.196.220) at 00:21:5e:4d:30:8d [ether] PERM on eth1

root@haproxy2:~# arp -i eth1 -s 69.59.196.220 00:21:5e:4d:30:8d
root@haproxy2:~# ping 69.59.196.220
PING 69.59.196.220 (69.59.196.220) 56(84) bytes of data.
--- 69.59.196.220 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6006ms

विंडोज़ वेब सर्वर को रिबूट करना इस मुद्दे को अस्थायी रूप से नेटवर्क में कोई अन्य परिवर्तन के साथ हल करता है लेकिन हमारा अनुभव दिखाता है कि यह मुद्दा वापस आ जाएगा।

स्वैपिंग नेटवर्क कार्ड और स्विच

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

(हमने एक और स्विच की कोशिश की जो हमारे हाथ में है, कोई बदलाव नहीं)

नेटवर्क हार्डवेयर ड्राइवर संस्करण बदलना

हमें लेटेस्ट ब्रॉडकॉम ड्राइवर के साथ-साथ बिल्ट-इन ड्राइवर के साथ भी यही समस्या है जो विंडोज सर्वर 2008 आर 2 में जहाज करते हैं।

नेटवर्क केबल की जगह

एक आखिरी खाई के प्रयास के रूप में हमने एक और बदलाव को याद किया, जो हमारे सर्वर / स्विच के बीच पैच पैच के सभी का प्रतिस्थापन था। हमने निजी इंटरफेस के लिए दो सेट, लंबाई 1 फीट का एक हरा - 3 फीट और सार्वजनिक इंटरफेस के लिए लाल केबलों का एक और सेट खरीदा था। हमने एक अलग ब्रांड के साथ सभी सार्वजनिक इंटरफ़ेस पैच केबलों की अदला-बदली की और एक पूरे सप्ताह के लिए हमारे सर्वर को बिना किसी समस्या के चलाया।

चेकसम ऑफ़लोड को अक्षम करें, TProxy को हटा दें

हमने ड्राइवर में टीसीपी / आईपी चेकसम ऑफलोड को अक्षम करने का भी प्रयास किया, कोई परिवर्तन नहीं। अब हम TProxy को बाहर निकाल रहे हैं और x-forwarded-forबिना किसी फैंसी आईपी एड्रेस पुनर्लेखन के एक अधिक पारंपरिक नेटवर्क व्यवस्था की ओर बढ़ रहे हैं । हम देखेंगे कि क्या मदद करता है।

वर्चुअलाइजेशन प्रदाताओं को स्विच करें

बंद मौके पर यह हाइपर-वी से संबंधित था (हम इस पर लिनक्स लिनक्स वीएम होस्ट करते हैं), हमने वीएमडब्लू सर्वर पर स्विच किया। कोई परिवर्तन नहीं होता है।

होस्ट मॉडल स्विच करें

हम अपनी समस्या निवारण रस्सी के अंत तक पहुँच चुके हैं और अब औपचारिक रूप से Microsoft समर्थन में शामिल हैं। उन्होंने मेजबान मॉडल को बदलने की सिफारिश की:

• http://en.wikipedia.org/wiki/Host_model
• http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx

हमने ऐसा किया, और हमें कुछ अप्रकाशित कर्नेल हॉटफ़िक्स भी मिले, जो संभवतः 2008 R2 SP1 में रोल किए गए थे। कुछ तय।

नेटवर्क कार्ड हार्डवेयर की जगह

अंततः, इंटेल नेटवर्क हार्डवेयर के साथ ब्रॉडकॉम नेटवर्क हार्डवेयर की जगह ने हमारे लिए इस मुद्दे को ठीक कर दिया। इसलिए मुझे लगता है कि ब्रॉडकॉम विंडोज सर्वर 2008 आर 2 ड्राइवर गलती पर हैं!

http://blog.serverfault.com/post/broadcom-die-mutha/

Comments

ध्यान दें - हम भी HAProxy के माध्यम से आने वाले यातायात के वास्तविक आईपी को वापस भेजने के लिए TProxy (पारदर्शी प्रॉक्सी) का उपयोग करते हैं। blog.loadbalancer.org/…

— जेफ एटवुड

LUnix ... हेह हे ... hld.c64.org/poldi/lunix/lunix.html

— इवान एंडरसन

उत्पादन परिवेश पर कभी भी ऑटो सेटिंग पर भरोसा न करें। जो होना चाहिए उसकी गति निर्धारित करें, और सुनिश्चित करने के लिए उस पर एक मॉनिटर लगाएं।

— डैनियल सी। सोबरल

@ डैनियल सोबरल: मुझे आपसे असहमत होना है। 2003 में मुझे लगता है कि मैं देख सकता था। आधुनिक हार्डवेयर के साथ, हार्ड-सेटिंग पोर्ट स्पीड और डुप्लेक्स गति / डुप्लेक्स बेमेल प्राप्त करने के लिए एक नुस्खा है। आधुनिक ईथरनेट गियर पर ऑटोनॉग्रेशन ठीक काम करता है।

— इवान एंडरसन

मैं @ डैनियल सोबरल के साथ खड़ा हूं, कई बार मेरे पास सबसे खराब समय में खराब गति वार्ता के कारण नेटवर्क विफलताएं हैं, इसलिए उत्पादन प्रणालियों पर मैं स्थिर सेटिंग्स के साथ जाता हूं। जब ऐसा होता है, तो स्विच पर लिंक स्थिति क्या कहती है? यह प्रबंधित है, है ना? विंडोज सिस्टम क्या कहता है? मैं लिंक स्तर पर नेटवर्क विफल होने पर शर्त लगाऊंगा, और यही वह कारण है जो एआरपी अपूर्णताएं उत्पन्न कर रहा है (एआरपी जो प्राप्त करने में विफल या प्रतीक्षा कर रहा है)। खराब हार्डवेयर / ड्राइवर एक कारण हो सकता है। आइए देखें कि स्वैप करने के बाद यह कैसे जाता है।

— पाब्लो अलसीना

Answer 1

से http://linux-ip.net/html/ether-arp.html :

यदि कोई अनुरोधित गंतव्य IP के लिए कोई ARP कैश प्रविष्टि मौजूद नहीं है, तो कर्नेल उत्तर प्राप्त करने तक mcast_solicit ARP अनुरोध उत्पन्न करेगा। इस खोज अवधि के दौरान, ARP कैश प्रविष्टि को अपूर्ण स्थिति में सूचीबद्ध किया जाएगा। यदि ARP अनुरोधों की निर्दिष्ट संख्या के बाद लुकअप सफल नहीं होता है, तो ARP कैश प्रविष्टि को विफल स्थिति में सूचीबद्ध किया जाएगा। यदि लुकअप सफल होता है, तो कर्नेल ARP कैश में प्रतिक्रिया में प्रवेश करता है और पुष्टिकरण और अद्यतन टाइमर को रीसेट करता है।

ऐसा लगता है कि आपका गेटवे बॉक्स आपके गेटवे बॉक्स से एआरपी अनुरोधों का जवाब नहीं दे रहा है (या बहुत धीरे से जवाब दे रहा है)। क्या <incomplete>आखिरकार यह करने के लिए स्विच करता है <failed>? सर्वर और गेटवे के बीच आपके पास कौन सा नेटवर्क हार्डवेयर है? क्या यह संभव है कि ARP अनुरोधों को दो मेजबानों के बीच कहीं फिल्टर या ब्लॉक किया जाए?

Answer 2

इसका मतलब है कि आपने पते को पिंग किया है, आईपी में एक पीटीआर रिकॉर्ड है (इसलिए नाम) लेकिन मशीन से सवाल का जवाब नहीं दिया। जब हम देखते हैं कि यह आमतौर पर सबनेट मास्क के गलत तरीके से सेट होने के कारण होता है - या आईपी के मामले में एक लूपबैक इंटरफ़ेस से जुड़ा होता है जो गलती से एथ इंटरफेस के लिए बाध्य थे।

196.220 क्या है? यह 196.211 के साथ क्या संबंध है? मैं मान रहा हूँ कि .220 HA प्रॉक्सी मेजबान में से एक है। जब आप इस पर ifconfig -a & arp -a चलाते हैं तो यह क्या दिखाता है?

Comments

यदि यह रुक-रुक कर हो रहा है, हालांकि, मुझे लगता है कि यह गलत तरीके से सेट सबनेट मास्क नहीं है (जो, माना जाता है, अक्सर एआरपी अनुरोधों का जवाब देने में विफल मशीनों का कारण होता है)।

— इवान एंडरसन

पोस्ट मुझे काफी स्पष्ट लगती है। .211 IP पता HAProxy इंस्टेंस द्वारा साझा किया गया एक वर्चुअल IP है। .220 आईपी पते को एक विंडोज मशीन को सौंपा जाता है, जो समय-समय पर .211 आईपी पते के साथ संचार करने की क्षमता खो देता है (जैसा कि पोस्ट में एआरपी आउटपुट के "इंटरफ़ेस:" पंक्ति में देखा जा सकता है)।

— इवान एंडरसन

196.220 विफल विंडोज़ सर्वर का आईपी है - 196.211 हाइपर प्रॉक्सी इंटरफेस के लिए वर्चुअल आईपी है।

— ज्योफ Dalgas

Answer 3

जैसा कि मैक्स क्लार्क कहते हैं, <अधूरा> का अर्थ है कि 69.59.196.211 ने 69.59.196.220 के लिए ARP अनुरोध किया है और अभी तक कोई प्रतिक्रिया नहीं मिली है। (Windows- भूमि में आप इसे ARP मैपिंग के रूप में "00-00-00-00-00-00-00" पर देखेंगे ... यह मुझे अजीब लगता है, BTW, कि आप ऐसे ARP मैपिंग को नहीं देख रहे हैं 69.59.196.211 के लिए 69.59.196.220।)

मुझे स्थिर ARP प्रविष्टियों का उपयोग करना पसंद नहीं है क्योंकि, मेरे अनुभव में, ARP ने आम तौर पर हर समय अपना काम किया है।

अगर यह मेरे थे, तो मैं इसे "असफल" विंडोज मशीन (69.59.196.220) पर उपयुक्त ईथरनेट इंटरफेस सूँघता हूँ, इसे 69.59.196.211 के लिए ARP'ing करने के लिए, और यह देखने के लिए कि 69.59 के ARP अनुरोधों का जवाब कैसे / यदि दिया गया है। 196.211। मैं केवल ARP के लिए गेटवे मशीन पर सूँघने पर भी विचार करूँगा ( tcpdump -i interface-name arpयह देखने के लिए कि ARP ट्रैफ़िक लिनक्स मशीन की तरफ से कैसा दिखता है।

मुझे पता है, ब्लॉग से , कि आपको बैक-एंड नेटवर्क और फ्रंट-एंड नेटवर्क मिला है। इन आउटेज के दौरान, "असफल" विंडोज सर्वर (69.59.196.220) को फ्रंट-एंड नेटवर्क में अन्य मशीनों से संवाद करने में कोई समस्या है, या यह सिर्फ इसके गेटवे पर बात करने में समस्या है? अगर आप एक्ट में इसे पकड़ रहे हैं तो आप सामने वाले या बैक-एंड नेटवर्क के माध्यम से असफल मशीन पर आ रहे हैं, तो मैं उत्सुक हूं।

जब आप समस्या को हल करने के लिए क्या कर रहे हैं?

संपादित करें:

मैं आपके अपडेट से देखता हूं कि आप समस्या को हल करने के लिए "असफल" विंडोज मशीन को रिबूट कर रहे हैं। इससे पहले कि आप अगली बार, क्या आप यह सत्यापित कर सकते हैं कि विंडोज मशीन अपने फ्रंट-एंड इंटरफेस पर "बात" करने में सक्षम है? इसके अलावा, route printविफलता के दौरान विंडोज मशीन ( ) से रूटिंग टेबल की एक प्रति भी पकड़ो । (मैं यह पता लगाने की कोशिश कर रहा हूं कि मूल रूप से विंडोज मशीन पर एनआईसी / ड्राइवर बोनर्स जा रहा है या नहीं।)

Comments

जब यह समस्या होती है तो हम विफल वेब सर्वर (196.220) को रिबूट कर सकते हैं और यह काम करेगा - हमारे अनुभव ने दिखाया है कि 24 घंटों के भीतर यह फिर से विफल हो जाएगा।

— ज्योफ Dalgas

यह जानना दिलचस्प होगा कि सर्वर से बात करने में सक्षम था, आखिर में .211 मशीन के साथ खंड पर संलग्न एनआईसी पर (जो, मैं आपके अपडेट से समझता हूं, अब बैक-एंड सेगमेंट के साथ स्वैप किया गया है)। मेरे पेट का कहना है "बोनर्स एनआईसी" इस पर मूल कारण होने जा रहा है, लेकिन हम देखेंगे ...

— इवान एंडरसन

जब ऐसा होता है, तो मशीन निश्चित रूप से फ्रंट एंड (सार्वजनिक) एनआईसी पर बिल्कुल भी बात नहीं कर सकती है । बैक एंड (निजी) एनआईसी अप्रभावित है। मैंने हमेशा महसूस किया है कि यह एनआईसी ड्राइवर था जो बोनट जा रहा था, लेकिन सवाल "क्यों" है? (यह भी: यह नवीनतम ब्रॉडकॉम चालक के साथ-साथ डिफ़ॉल्ट विंक 28 आर 2 चालक के साथ होता है) मैं रिबूट के बाद इवेंट लॉग की जांच करने जा रहा हूं, जिसमें 10+ मिनट लगते हैं क्योंकि इसे अंततः शटडाउन के भाग के रूप में पहले बंद करना है। मैंने उन्हें पहले ही साफ कर दिया।

— जेफ एटवुड

हम अब Microsoft समर्थन को शामिल कर रहे हैं क्योंकि हम ईमानदारी से मानते हैं कि यह OS स्तर का मुद्दा है। हमने हर संभव समस्या निवारण किया है जो हम संभवतः कर सकते हैं और खारिज कर सकते हैं .. ठीक है, सब कुछ।

— जेफ एटवुड

Zow। मुझे यह सुनकर बहुत अच्छा लगा कि यह कैसे होता है।

— इवान एंडरसन

Answer 4

यह दस्तावेज़ विभिन्न राज्यों (तालिका 2.1) को दर्शाता है। अपूर्ण का मतलब यह होगा कि उसने पहला ARP अनुरोध भेजा है (संभवतः एक बासी, देरी, जांच के बाद) लेकिन अभी तक कोई प्रतिक्रिया नहीं मिली है।

Answer 5

हैप्रोक्सी नोड पर स्थैतिक एआरपी का कारण यह नहीं है कि आपका वेब सर्वर अभी भी यह पता नहीं लगा सकता है कि गेटवे पर वापस कैसे आना है।

वेब सर्वर पर स्टेटिक ARP आपके वेब सर्वर के लिए गेटवे स्विच करने की क्षमता को तोड़ता है जब एक हैप्रॉक्सी नोड्स विफल हो गया - मैं अनुमान लगा रहा हूं कि वर्चुअल इंटरफ़ेस उसी मैक पते को हैप्रोक्सी नोड के eth1 के रूप में साझा करता है, इसलिए आपको कठिन होना पड़ेगा प्रत्येक वेब सर्वर में दो गेटवे में से एक में कोड।

क्या आपके पास किसी भी तरह का सुरक्षा सॉफ्टवेयर विफल वेब सर्वर पर स्थापित है? मैंने एक लंबी रात विंडोज 2008 सर्वर के साथ बिताई, जिसमें उस पर सिमेंटेक एंडपॉइंट सुरक्षा थी - यह नेटवर्किंग स्टैक में कुछ फ़िल्टरिंग कोड स्थापित करता है जो इसे गेटवे के एआरपी पैकेट को देखने से रोकता है। उसके लिए फिक्स (Microsoft द्वारा प्रदान की गई) DLL को लोड करने वाली रजिस्ट्री प्रविष्टि को निकालना था।

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

Answer 6

आप स्थिर अपने एआरपी प्रविष्टि निर्धारित किया है के बाद से, अपने सर्वर पता जहां प्रवेश द्वार को खोजने के लिए। हालाँकि, यदि आपका स्विच नहीं जानता कि गेटवे कहाँ है, तो यह आपके पैकेट को अग्रेषित नहीं करेगा।

लगता है कि आपको अपने HAproxy और अपने वेब सर्वर के बीच एक बुरा (या भ्रमित) स्विच मिल गया है। इसे रिबूट करें।

या तो वह, या आपका HAproxy सर्वर असहमत है, जिसके बारे में कोई नियंत्रण में है, और दोनों ने .211 के लिए arp लुकअप का उत्तर दिया है।

इसी तर्ज पर, यदि आपका स्विच ओवरलोडेड है, तो आपके HAproxies एक-दूसरे के साथ पर्याप्त तेज़ी से संवाद करने में असमर्थ हो सकते हैं, और अधिक असफल हो रहे हैं।

Answer 7

अगली बार जब यह समस्या होगी, तो मैं दो मेजबानों पर कुछ पैकेट कैप्चर चलाने का सुझाव दूंगा, यह निर्धारित करने के लिए कि उनमें से प्रत्येक एआरपी ट्रैफ़िक क्या देख रहा है।

आपकी HAproxy मशीन में संभवतः tcpdump का कुछ स्वाद स्थापित होगा। विंडोज मशीन के लिए आपको या तो WinPCAP एप्लिकेशन की आवश्यकता होगी , जैसे Wireshark , या Microsoft नेटवर्क मॉनिटर ।

वास्तव में, इसके बारे में सोचकर, जैसा कि समस्या विशेष रूप से एआरपी के साथ प्रतीत होती है, आप संभावित रूप से HAproxy मशीन और विंडोज मशीन पर सभी ARP ट्रैफ़िक को संभावित रूप से रिकॉर्ड कर सकते हैं, जिसमें (तर्क के लिए) 10MB की रोलिंग कैप्चर फ़ाइल होती है। यह इतना बड़ा होना चाहिए कि जब तक आप विफलता का पता लगाते हैं, तब तक कैप्चर फ़ाइल में विफलता से पहले एआरपी ट्रैफ़िक होगा। (यह एक या एक घंटे के लिए कब्जा चलाकर प्रयोग करने लायक है, यह देखने के लिए कि यह कितना डेटा उत्पन्न करता है)।

लिनक्स tcpdump के लिए उदाहरण कैप्चर सिंटैक्स (ध्यान दें, मेरे पास इस पर परीक्षण करने के लिए लिनक्स बॉक्स नहीं है; कृपया उत्पादन में उपयोग करने से पहले -C और -W के व्यवहार का परीक्षण करें!):

tcpdump -C 10 -i eth1 -w /var/tmp/arp.cap -W 1 arp

इससे आपको उम्मीद है कि आप कुछ संकेत दे सकते हैं कि क्या असफल हो रहा है। जब ARP प्रविष्टि समाप्त हो जाती है (और इस लेख के अनुसार , विंडोज के नए संस्करण 'निष्क्रिय' प्रविष्टियों को बहुत आक्रामक रूप से प्रकट करते हैं), मैं निम्नलिखित होने की उम्मीद करूंगा:

1. स्रोत होस्ट लक्ष्य होस्ट के लिए ARP अनुरोध भेजेगा। एआरपी अनुरोध आम तौर पर प्रसारित होते हैं, लेकिन उस मामले में जहां एक मेजबान एक मौजूदा प्रविष्टि को ताज़ा कर रहा है, एआरपी को यूनिकस्ट भेजा जा सकता है।
2. लक्ष्य मेजबान ARP उत्तर के साथ जवाब देगा। 99% यह एकतरफा होगा, लेकिन RFC प्रसारण प्रतिक्रियाओं को अनुमति देता है। ( अधिक विस्तार के लिए IPv4 एड्रेस कोलिशन डिटेक्शन के बारे में RFC भी देखें )।

ऐसा लगता है कि सरल है, इस प्रक्रिया में हस्तक्षेप करने वाली अन्य चीजों का एक समूह है:

• मूल अनुरोध लक्ष्य पर नहीं आ रहा हो सकता है।
• अनुरोध लक्ष्य पर पहुंच सकता है, लेकिन प्रतिक्रिया स्रोत तक नहीं पहुंच सकती है।
• उच्च उपलब्धता तंत्र के कुछ प्रकार एआरपी के 'सामान्य' व्यवहार के साथ हस्तक्षेप कर सकते हैं:
  • HAProxy नोड्स के बीच विफलता कैसे काम करती है? क्या यह एक साझा मैक पते का उपयोग करता है, या नोड्स के बीच आईपी पते को विफल करने के लिए यह gratuitous ARP का उपयोग करता है?
  • ARP तालिकाओं में बहुत सारे मैक पते 00-15-5D से शुरू होते हैं, जो स्पष्ट रूप से Microsoft में पंजीकृत हैं। क्या आप विचाराधीन विंडोज मशीन पर किसी भी प्रकार के क्लस्टरिंग या अन्य हा का उपयोग कर रहे हैं? जब आप Windows सर्वर पर 'ipconfig / all' करते हैं तो क्या ये 00-15-5D मैक वही होते हैं जिन्हें आप हार्डवेयर NIC से संबद्ध देखते हैं?

यह जाँचने के लिए कि क्या चीजें कब / कब होती हैं:

• ARP ट्रैफ़िक के पैकेट कैप्चर को देखें; क्या बातचीत का कोई हिस्सा स्पष्ट रूप से नहीं हुआ है?
• स्विच की ब्रिजिंग / सीएएम टेबल की जांच करें; उन सभी पोर्टों के लिए प्रश्न-मानचित्र में मैक पते की अपेक्षा करें जिनसे आप उन्हें उम्मीद करते हैं?
• क्या सबनेट पर अन्य होस्ट्स के पास विंडोज और हैप्रॉक्सी होस्ट दोनों के आईपी पतों के लिए मान्य एआरपी प्रविष्टियाँ हैं?
• क्या कई अलग-अलग स्रोत मशीनों पर समान लक्ष्य IP के लिए ARP प्रविष्टियां एक ही मैक पते पर हल होती हैं? यानी सबनेट पर अन्य मेजबानों के एक जोड़े पर लॉग इन करें और सत्यापित करें कि 196.211 दोनों पर एक ही मैक पते का समाधान करता है।

Comments

हम निश्चित रूप से पैकेट कैप्चर को देख रहे हैं

— जेफ एटवुड

दुर्भाग्य से पैकेट कैप्चर ने हमें कुछ भी स्पष्ट नहीं दिखाया, और जिस मशीन पर हमने कब्जा किया है, वह संवेदनशील नेटवर्क ट्रैफ़िक है .. इसलिए हम इसे देखने के लिए विशेषज्ञों को नहीं दे सकते।

— जेफ एटवुड

@ जेफ़: क्या आप केवल ARP ट्रैफ़िक दिखाते हुए कैप्चर प्रदान कर सकते हैं? मुझे एआरपी के व्यवहार को देखने में दिलचस्पी होगी अगर कुछ और नहीं।

— मुरली सूरिार

हमने जो भी डेटा कैप्चर किया है, उस पर MSFT सपोर्ट के निर्देशों का पालन किया - इसमें कुछ हफ्ते लग गए, लेकिन आखिरकार उन्होंने हमारे लिए एक निजी कर्नेल नेटवर्किंग हॉटफ़िक्स पाया।

— जेफ एटवुड

Answer 8

हमारे पास हमारे 2008 R2 टर्मिनल सर्वरों में से एक के साथ एक समान मुद्दा था जहां एनआईसी पर सभी ट्रैफ़िक बंद हो जाते हैं लेकिन जुड़े रहते हैं, और एनआईसी एल ई डी कॉम्स दिखाएगा। यह एक चालू मुद्दा था जो सप्ताह में 2-3 बार क्रॉप करता था, लेकिन लगभग 12-13 घंटे के बाद ही (सर्वर रात को रिबूट हो जाता है)।

मैंने पाया कि Seriousbit Netbalancer कारण था, क्योंकि मैंने कोशिश की (जिज्ञासा से बाहर) NetbalancerService सेवा को समाप्त कर दिया। ट्रैफ़िक तब इंटरफ़ेस के पार जाने लगा। मैंने तब से Netbalancer की स्थापना रद्द कर दी है।

Answer 9

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