मैक-पतों को फिर से लिखना क्यों स्विच नहीं करता है?

Question

क्या कोई विशेष कारण है कि ईथरनेट स्विच पैकेट के मैक पते को नहीं बदलते हैं?

क्या यह मैक पते, या कुछ और का उपयोग करके अंतिम मेजबान पहचान के लिए है?

Comments

मान लीजिए आपका नाम कुमार था। क्या आप इसे पसंद करेंगे अगर लोग आपको "जेसिका" कहने लगे?

— माइक पेनिंगटन

स्विच पैकेट (फ्रेम) को फिर से लिखना नहीं है; वे बस उन्हें इंटरफ़ेस से इंटरफ़ेस तक ले जाते हैं। (प्रसारण / मल्टिकास्ट के मामले में, इसमें कई पोर्ट्स की नकल शामिल है।)

— रिकी बीम

क्या आप एक मान्य कारण के बारे में सोच सकते हैं कि क्यों स्विच को मैक पते को बदलना चाहिए ?

— टुन विंक

क्या किसी उत्तर ने आपकी मदद की? यदि हां, तो आपको उत्तर को स्वीकार करना चाहिए ताकि प्रश्न हमेशा के लिए पॉपअप न हो जाए, उत्तर की तलाश में है। वैकल्पिक रूप से, आप अपना स्वयं का उत्तर प्रदान कर सकते हैं और स्वीकार कर सकते हैं।

— रॉन Maupin

Answer 1

यदि एक स्विच मैक पते को बदलने के लिए था, तो यह पूरी तरह से नेटवर्किंग को तोड़ देगा।

मैक एड्रेस एक विशिष्ट पहचानकर्ता है जो स्थानीय नेटवर्क पर होस्ट द्वारा उपयोग किया जाता है।

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

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

यह आगे 802.1X और अन्य तंत्र जैसी चीजों के साथ समस्या पैदा कर सकता है जो डिवाइस को पहचानने / वर्गीकृत करने के लिए मैक पते का उपयोग करते हैं।

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

Answer 2

डेटाग्राम के पतों की पुनरावृत्ति परत 3 पर होती है, उदाहरण के लिए जब गेटवे (राउटर या फ़ायरवॉल) NAT नेटवर्क पर होस्ट के IP पतों को फिर से लिखते हैं, तो वे सभी गेटवे पर ही एक (या कुछ) बाहरी आईपी एड्रेस से दिखाई देते हैं।

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

NAT के साथ परत तीन मामले में, NAT कई समस्याओं का हल करता है:

• IP पतों का उपयोग वैश्विक संचार के लिए किया जाता है, और उपलब्ध IP पतों का एक सीमित पूल होता है जिसे साझा करना होता है। NAT का उपयोग करके, कोई यह सुनिश्चित करता है कि बड़ी संख्या में आंतरिक होस्ट सार्वजनिक इंटरनेट पर कम (आमतौर पर सिर्फ एक) आईपी पता साझा कर सकते हैं।
• आईपी ​​पतों की पुनर्लेखन को कुछ लोगों द्वारा माना जाता है, लेकिन आंतरिक मशीनों के आईपी पतों को मर्ज करके सुरक्षा की एक परत को जोड़ने के लिए सभी को नहीं।

इसलिए, यदि हम NAT उदाहरण के साथ चिपके रहते हैं, तो NAT की परत के दो समकक्षों की वास्तव में कोई आवश्यकता नहीं है।

• इंटरनेट पर डेटाग्राम को संबोधित करने के लिए मैक पते विश्व स्तर पर उपयोग नहीं किए जाते हैं, उनका उपयोग स्थानीय सबनेट पर सही मेजबानों को फ्रेम भेजने के लिए किया जाता है। चूंकि स्थानीय सबनेट अपेक्षाकृत छोटे होते हैं, और संभावित मैक पतों की संख्या बहुत बड़ी होती है, कोई लेयर 2 स्तर पर "उपलब्ध मैक पतों" से बाहर नहीं निकलता है। (एनआईसी के मैक पते को मैन्युअल रूप से पुन: कॉन्फ़िगर करने का विकल्प एक मनमाना मूल्य में परिवर्तित नहीं होता है)
• और फॉरवर्ड करते समय डेटाग्राम पतों के पुनर्लेखन योग्य लाभकारी सुरक्षा लाभ के लिए: जैसा कि मैक पतों का उपयोग केवल एक स्थानीय सबनेट के भीतर किया जाता है, आमतौर पर किसी व्यक्ति के संबंध में, उस सबनेट पर सुरक्षा दृष्टिकोण से बहुत बेहतर नियंत्रण (शारीरिक रूप से और साथ ही अधिकांश) परत 3 मामले में समकक्ष की तुलना में शामिल डिवाइस), जो कि संपूर्ण इंटरनेट है (जो कि हम जुड़े हुए उपयोगकर्ताओं और नेटवर्क इंजीनियरों के रूप में व्यवहार में कोई सुरक्षा नियंत्रण नहीं है)।

आशा है कि यह कुछ प्रकाश डाला है क्यों स्विच मैक पते को फिर से लिखना नहीं है। एकमात्र परत 3 मामला जो मेरे सिर के ऊपर से आया था वह NAT था, अन्य निश्चित रूप से अन्य परत 3 मामलों का उदाहरण प्रदान कर सकते हैं जहां आईपी पुनर्लेखनों को वारंट किया गया है (और क्यों उन तकनीकों का परत 2 स्तर पर वास्तव में कोई मतलब नहीं है) ।

Comments

स्पॉट-ऑन, लेकिन मेरे पास आपके उत्तर के साथ एक छोटा सा वक्रोक्ति है। आपने उल्लेख किया है कि "NAT की परत के दो समकक्षों की वास्तव में कोई आवश्यकता नहीं है" ... जबकि मैंने MAC NAT को नहीं देखा है, मैंने मैक-स्तर की सुरंग देखी है। कुछ परिस्थितियों में, यह अन्य मैक-पतों के अंदर "टनेल" मैक पते पर स्विच करने के लिए समझ में आता है। स्थिति जो तुरंत ध्यान में आती है वह IEEE 802.1ah प्रदाता आधारित ब्रिजिंग (PBB) है । आमतौर पर, इसका उपयोग सेवा प्रदाता मेट्रो के छल्ले में उपलब्ध vlans को कम करने / मैक सीखने को कम करने के लिए किया जाता है

— माइक पेनिंगटन

@IllvilJa: अच्छा कहा ..! आपने एक शंका का समाधान किया जो मुझे पिछले कुछ हफ्तों से भ्रमित करती है। कुछ हफ्ते पहले, मैंने निम्नानुसार सोचा ... "एक राउटर, जब यह एक वैन के साथ व्यवहार करता है, तो एक प्रेषक के मैक पते (प्रत्येक पैकेट पर) के बजाय अपना मैक पता डालते हैं और पैकेट को रिसीवर को भेजते हैं। लेकिन मामले में। LAN, राउटर एक प्रेषक के मैक पते (प्रत्येक पैकेट पर) के बजाय अपना मैक पता नहीं डालता है, लेकिन सिर्फ प्रेषक और रिसीवर के बीच पैकेट को पास करता है "लेकिन आपकी व्याख्या के बाद मैं 'राउटर' और 'के बीच अंतर करने के लिए पर्याप्त स्पष्ट हूं एक स्विच'। एक बार फिर धन्यवाद..!

— महाराणा

Answer 3

मैक पते को फिर से लिखने से काफी जटिलता बढ़ जाएगी (स्विच को उच्च स्तर के प्रोटोकॉल के बारे में जानना होगा, जैसे कि यह आरएएस रिसॉल्यूशन को फिर से लिख सकता है), समस्या निवारण को कठिन बना देगा, एसटीपी जैसे प्रोटोकॉल को काम करने से रोकेगा और आमतौर पर एक पीटीए होगा। यह भी आम तौर पर जरूरत नहीं है।

यह कहना संभव नहीं है। ebtables (iptables के लिए परत 2 समकक्ष) में MAC एड्रेस ट्रांसलेशन के लिए कुछ विकल्प हैं। यह उपयोगी हो सकता है अगर आपके पास स्विच हैं जो प्रति-वील मैक तालिकाओं का उपयोग नहीं करते हैं और आप कुछ परत 2 फ़िल्टरिंग करना चाहते हैं।

http://ebtables.netfilter.org/examples/example1.html