ตัวกรอง blackhole ทริกเกอร์ BGP ระยะไกล (RTBH) สำหรับ Juniper

ฉันกำลังพยายามหาวิธีที่หรูหราที่สุดในการใช้ตัวกรองRTBHสำหรับเส้นทางที่ได้รับจากลูกค้า

ตัวกรองควร:

1. ยอมรับเฉพาะคำนำหน้าของลูกค้าจากรายการนำหน้าเท่านั้น
2. ยอมรับคำนำหน้า / 32 เท่านั้น
3. เฉพาะคำนำหน้ากับชุมชน blackhole
4. ตั้งค่า next-hop เป็น RTBH next-hop (192.0.2.1)

ในการเริ่มต้นฉันดูที่เอกสาร "การกำหนดค่าเงื่อนไขการจับคู่ในข้อกำหนดนโยบายการกำหนดเส้นทาง " จากจูนิเปอร์

ครั้งแรกที่ฉันคิดเกี่ยวกับการรวม a prefix-list-filterเพื่อจับคู่เส้นทางเท่านั้นจากรายการนำหน้าของลูกค้าและ a 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 อยู่ในช่วงของลูกค้าตรงกับ as-path ของเขาและมีชุมชน blackhole ตั้ง:

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;
    }
}

ดังนั้นนี่เป็นวิธีที่ดีที่สุดในการจัดการกับสิ่งนี้หรือไม่? ทางออกอื่น ๆ

ไม่มีเหตุผลใดที่จะ จำกัด ลูกค้าไว้ที่ Blackhole เท่านั้น / 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;
    }
}

อย่าลืมตั้งค่า 'accept-remote-nexthop' ภายใต้การตั้งค่า BGP เพื่อให้การเปลี่ยนแปลงครั้งต่อไปสามารถเปลี่ยนเป็นอย่างอื่นนอกเหนือจากที่อยู่ลิงก์

ฉันยังสนับสนุนอย่างยิ่งว่าผู้ให้บริการเริ่มให้การสนับสนุนชุมชน Blackhole ที่แตกต่างกันมากกว่า 'Full Blackhole' โดยเฉพาะอย่างยิ่งถ้าคุณทำงานในมากกว่าหนึ่งประเทศมักจะโจมตีจากการขนส่งและบ่อยครั้งที่ลูกค้าต้องการเข้าถึงเพียร์ในประเทศดังนั้นจึงมีประโยชน์ในการติดตั้ง blackhhole หลายระดับ:

1. เต็ม
2. นอกประเทศท้องถิ่น (ท้องถิ่น IXP ลูกค้าทั้ง AS + เท่าที่เห็น)
3. นอกพื้นที่ท้องถิ่น (ถ้ามีเช่นฉันอาจเป็น 'Nordics')
4. รวม / ไม่รวมเราเตอร์ peering เฉพาะใน blackhole

ฉันยินดีที่จะยกตัวอย่างวิธีการใช้งานสิ่งนี้กับ JNPR DCU / SCU เนื่องจากเราเตอร์ peering ของคุณคือ JNPR แต่เป็นไปได้ที่จะมีเพียงชุมชน

หากคุณต้องการ จำกัด ตัวเลือกของลูกค้าคุณสามารถเพิ่มสิ่งนี้:

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;
        }
..
}

วิธีนี้ควรจะเป็นตรรกะและ แต่ฉันไม่เห็นคุณค่าในการสร้างความซับซ้อนเพื่อลดการแสดงออกของการกำหนดค่า