राउटर पिंग बनाम VLAN होस्ट: कौन-सी PBR नीति लागू होती है?

VLAN 10 को VPN का उपयोग करना चाहिए और VLAN 20 को WAN का, इसलिए पहला परीक्षण VLAN 10 के इंटरफ़ेस पते को स्रोत बनाकर राउटर से किया गया पिंग है। वह सफल होता है, route-map काउंटर बढ़ते हैं और सभी मान लेते हैं कि डिज़ाइन काम करता है। यह काम नहीं करता। वह पिंग स्थानीय रूप से उत्पन्न हुआ था, और स्थानीय रूप से उत्पन्न ट्रैफ़िक VLAN इंटरफ़ेस पर आने वाले पैकेट की तुलना में नीति के दूसरे अटैचमेंट पॉइंट तक पहुँचता है।

तीन शर्तें तय करती हैं कि आप वास्तव में कौन-सी नीति का परीक्षण कर रहे हैं: पैकेट कहाँ बनता है, वह कहाँ प्रवेश करता है और किससे मेल खाता है।

पैकेट कहाँ प्रवेश करता है, यह तय करता है कि कौन-सी नीति चलती है

ip policy route-map के साथ जुड़ा इंटरफ़ेस route-map उस इंटरफ़ेस पर आने वाले पैकेट पर लागू होता है, जैसा कि IOS XE PBR गाइड बताती है। VLAN 10 का होस्ट अपना अनुरोध भेजता है, फ़्रेम VLAN सबइंटरफ़ेस पर आता है और राउटर वहाँ नीति का मूल्यांकन करता है। राउटर का अपना पैकेट कभी उस इंटरफ़ेस पर नहीं आता, क्योंकि वह राउटर में पैदा हुआ था।

VLAN पते को स्रोत चुनने से हेडर बदलता है। इससे मूल स्थान नहीं बदलता।

स्रोत वाला पिंग अब भी होस्ट क्यों नहीं है

स्रोत पता ACL मेल के लिए मायने रखता है, और यही परीक्षण को इतना विश्वसनीय बनाता है। पैकेट स्रोत शर्त से मेल खाता है, काउंटर बढ़ते हैं और आउटपुट सही दिखता है। परीक्षण यह नहीं दिखा सकता कि प्रवेश इंटरफ़ेस क्या है, आगमन का संदर्भ क्या है, या होस्ट का पैकेट वही शाखा लेगा या नहीं।

जो परीक्षण मेल को दोहराता है पर संदर्भ को नहीं, वह डिज़ाइन का आधा हिस्सा साबित करता है, और आधे प्रमाण के साथ ही डिज़ाइन गलत नीति के साथ बाहर जाते हैं।

स्थानीय नीति कब सही उत्तर है

Cisco ip local policy route-map का दस्तावेज़ीकरण उस ट्रैफ़िक के लिए करता है जो राउटर स्वयं उत्पन्न करता है। वह एक अलग दायरा है, और यह सही उपकरण है जब आवश्यकता वास्तव में राउटर के अपने ट्रैफ़िक से जुड़ी हो। यह कोई छूटा हुआ चरण नहीं है जिसकी हर VLAN-स्टीयरिंग डिज़ाइन को आवश्यकता हो। वहाँ व्यापक मेल प्रबंधन और सहायक कनेक्शनों को भी प्रभावित कर सकता है, जो दिखने से कहीं बड़ा बदलाव है।

स्थानीय रूप से उत्पन्न TCP की एक अतिरिक्त पूर्वशर्त है: उसे रूटिंग तालिका में लागू गंतव्य प्रविष्टि चाहिए, भले ही नीति कोई दूसरा पथ चुने। ICMP परिणाम TCP के लिए वही व्यवहार साबित नहीं करता।

इसके बजाय होस्ट पर क्या परखें

परीक्षण VLAN 10 के अधिकृत होस्ट से उसके वास्तविक स्रोत पते, गंतव्य, प्रोटोकॉल और पोर्ट के साथ चलाएँ। प्रवेश इंटरफ़ेस और route-map मेल को परिणाम के साथ दर्ज करें, ताकि साक्ष्य उस नीति का नाम ले जो चली। फिर VLAN 20 के होस्ट के लिए दोहराएँ और पुष्टि करें कि वह दूसरा पथ लेता है।

दोनों पथों को काम करने वाले next hop, वापसी पहुँच और, जहाँ लागू हो, VPN कवरेज चाहिए। PBR अग्रेषण निर्णय चुनता है; यह दूरस्थ सेवा नहीं बनाता और एप्लिकेशन को अनुमति नहीं देता।

परिणाम क्या साबित कर सकता है और क्या नहीं

सफल होस्ट प्रवाह साबित करता है कि नीति मेल खाई और चुना गया पथ उस समय काम कर रहा था। यह साबित नहीं करता कि राउटर का अपना ट्रैफ़िक निर्देशित हो रहा है, और यह भी साबित नहीं करता कि एप्लिकेशन अधिकृत था, क्योंकि ये अलग प्रश्न हैं जिनके अलग प्रमाण हैं।

पिंग को रिकॉर्ड में स्थानीय पैकेट के साक्ष्य के रूप में रखें। फिर जाकर होस्ट-प्रवाह का साक्ष्य लें, बजाय इसके कि नीति का दायरा तब तक बढ़ाएँ जब तक दोनों परीक्षण संयोग से एक जैसे दिखने लगें।