जुनिपर के लिए बीजीपी रिमोट-ट्रिगर ब्लैकहोल (आरटीबीएच) फ़िल्टर

Question

मैं एक ग्राहक से प्राप्त मार्गों के लिए RTBH फ़िल्टर को लागू करने का सबसे सुंदर तरीका खोजने की कोशिश कर रहा हूं ।

फ़िल्टर चाहिए:

1. केवल उपसर्ग-सूची से ही ग्राहकों को उपसर्ग स्वीकार करते हैं
2. केवल / 32 उपसर्ग स्वीकार करते हैं
3. केवल ब्लैकहोल समुदाय के साथ उपसर्ग करता है
4. RTBH के अगले-हॉप को अगले-हॉप (192.0.2.1) पर सेट करें

शुरू करने के लिए मैंने जुनिपर से " रूटिंग पॉलिसी की शर्तों में मैचिंग शर्तों को कॉन्फ़िगर करना " दस्तावेज़ देखा।

पहले मैंने prefix-list-filterग्राहकों से उपसर्ग-सूची में केवल मैच मार्गों के संयोजन के बारे में सोचा और एक route-filterस्वीकृत उपसर्गों को / 32 तक सीमित करने के लिए, जैसे:

from {
    as-path customer;
    community blackhole;
    prefix-list-filter customer-prefixes orlonger;
    route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}

लेकिन फिर मैं इस जानकारी के बारे में दस्तावेज में ठोकर खाई:

यदि आप किसी ऐसी नीति को कॉन्फ़िगर करते हैं जिसमें रूट फ़िल्टर, प्रीफ़िक्स सूची और स्रोत पते फ़िल्टर के कुछ संयोजन शामिल हैं, तो उनका मूल्यांकन तार्किक या ऑपरेशन या सबसे लंबे समय तक रूट मैच लुकअप के अनुसार किया जाता है।

जैसा कि मैं इसे समझता हूं (और मुझे यह थोड़ा अस्पष्ट लगता है), अगर मैं उपयोग करता हूं prefix-list-filter, route-filterऔर / या source-address-filterएक ही शब्द में इसका मूल्यांकन सबसे लंबे समय तक मिलान या उन सभी के बीच किया जाएगा, जो इस दृष्टिकोण को अनुपयोगी बनाता है ।

क्या मैं के साथ आया है यह निम्नलिखित फिल्टर है। यह hostroutes-onlyशब्द सभी उपसर्गों को अगली नीति से / 32 से कम बताता है। उसके बाद prefixesयदि शब्द / 32 ग्राहक की श्रेणी में है, तो उसका ऐश-पथ से मेल खाता है और ब्लैकहोल समुदाय सेट है:

term hostroutes-only {
    from {
        route-filter 0.0.0.0/0 prefix-length-range /0-/31;
    }
    then next policy;
}
term prefixes {
    from {
        as-path customer;
        community blackhole;
        prefix-list-filter customer-prefixes orlonger;
    }
    then {
        next-hop 192.0.2.1;
        accept;
    }
}

तो, क्या इसे संभालने का सबसे सुरुचिपूर्ण तरीका है? कोई और उपाय?

Answer 1

ग्राहक को केवल ब्लैकहोल / 32 तक सीमित करने का कोई कारण नहीं है, उन्हें उनसे कुछ भी ब्लैकहोल करने की अनुमति दें।

कुछ इस तरह:

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            prefix-list-filter AS42 orlonger;
        }
        then {
            community add NO-EXPORT;
            next-hop 192.0.2.1;
            accept;
        }
    }
    term advertise {
        from {
            prefix-list AS42;
        }
        then {
            community add ADVERTISE;
            next-hop peer-address;
            accept;
        }
    }
    term reject {
        then reject;
    }
}

बीजीपी सेटिंग्स के तहत 'स्वीकार-रिमोट-नेक्सथॉप' सेट करना याद रखें, ताकि अगली-लिंक को लिंक पते के लिए कुछ और में बदला जा सके।

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

1. पूर्ण
2. स्थानीय देश के बाहर (स्थानीय IXP, पूरे AS + ग्राहक देखे गए)
3. स्थानीय क्षेत्र के बाहर (यदि लागू हो, तो मेरे लिए यह 'नोर्डिक्स' हो सकता है)
4. ब्लैकहोल में विशिष्ट पीयरिंग राउटर को शामिल / छोड़ें

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

---

यदि आप अपने ग्राहक के विकल्पों को सीमित करना चाहते हैं, तो आप इसे जोड़ सकते हैं:

policy-statement /32 {
    term /32 {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /32-/32;
        }
        then accept;
    }
    term reject {
        then reject;
    }
}

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            policy /32;
            prefix-list-filter AS42 orlonger;
        }
..
}

इस तरह यह तार्किक होना चाहिए और। लेकिन मैं वास्तव में विन्यास की अभिव्यक्ति को कम करने के लिए जटिलता पैदा करने में मूल्य नहीं देखता।

Comments

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

— सेबस्टियन विसिंगर

हम किसी को "दंडित" नहीं कर रहे हैं। यदि वे बड़े उपसर्गों को ब्लैकलिस्ट करना चाहते हैं, तो वे निश्चित रूप से इसके लिए पूछ सकते हैं। पिछले कुछ वर्षों में किसी ने इसके लिए नहीं कहा।

— सेबस्टियन विसिंगर

आप जटिलता को कम करने के लिए अतिरिक्त परेशानी देख रहे हैं, अभिव्यक्ति को कम करने के लिए। यदि आपने कभी यह पेशकश नहीं की है, तो आप कैसे जानते हैं कि आपके ग्राहक गलती से ब्लैकहोल समुदाय को / 32 से अधिक नेट में जोड़ देंगे? संयोगवश जब कभी हम विक्रेताओं से सुविधा मांगते हैं, तो वे जवाब देते हैं कि 'किसी ने कभी भी इसके लिए नहीं पूछा है' और जब आप समुदाय से बात करते हैं, तो आपको ऐसे लोगों की सुविधा के लिए बहुत से लोग मिलेंगे। किसी भी तरह मैंने इस सीमा को लागू करने के बारे में सुझाव जोड़ा।

— यति

मुझे एहसास हुआ कि आपके उदाहरण में, आप ब्लैकहोलिंग के बिना उपसर्गों को स्वीकार नहीं करते हैं। तो आप शायद दो सहकर्मी हैं, एक सामान्य यातायात के लिए और एक ब्लैकहोलिंग के लिए, और ब्लैकहोलिंग संभावना आपके मामले में मल्टीहॉप है, मल्टीहॉप में अगला-हॉप जाँच पहले से ही बंद है, इसलिए आपको 'स्वीकार-रिमोट' की आवश्यकता नहीं है -अगली आशा'। मेरा उदाहरण एक ही विन्यास में दोनों बीजीपी पीयरिंग्स को शामिल करता है, और जैसा कि प्रत्यक्ष पीई <-> सीई बिना मल्टीहॉप के है, इसे 'स्वीकार-रिमोट-नेक्सथॉप' की आवश्यकता है।

— यति

हां यह सच है, आपको इसे सीधे सत्रों की आवश्यकता है। फ़िल्टर को दोनों स्थितियों में काम करना चाहिए, आप इसे पीई <-> सीई परिदृश्य में इसके पीछे अन्य फ़िल्टरिंग नीतियों के साथ जोड़ देंगे।

— सेबेस्टियन विसिंगर