Filter blackhole (RTBH) yang dipicu dari BGP untuk Juniper

Saya mencoba menemukan cara paling elegan untuk menerapkan filter RTBH untuk rute yang diterima dari pelanggan.

Filter harus:

1. Hanya terima awalan yang dimiliki pelanggan dari daftar awalan
2. Hanya menerima / 32 awalan
3. Hanya awalan dengan komunitas lubang hitam
4. Setel hop berikutnya ke RTBH hop berikutnya (192.0.2.1)

Untuk memulai, saya melihat dokumen " Mengkonfigurasi Kondisi Kecocokan dalam Ketentuan Kebijakan Perutean " dari Juniper.

Pertama saya berpikir tentang menggabungkan prefix-list-filterhanya untuk mencocokkan rute dari daftar awalan pelanggan dan route-filteruntuk membatasi awalan yang diterima ke / 32, seperti:

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

Tapi kemudian saya tersandung tentang informasi ini di dokumen:

Jika Anda mengonfigurasi kebijakan yang menyertakan beberapa kombinasi filter rute, daftar awalan, dan filter alamat sumber, mereka dievaluasi sesuai dengan operasi OR logis atau pencarian pertandingan rute terpanjang.

Seperti yang saya pahami ini (dan saya merasa agak tidak jelas), jika saya menggunakan prefix-list-filter, route-filterdan / atau source-address-filterdalam istilah yang sama itu akan dievaluasi dengan pertandingan terpanjang OR antara mereka semua, yang membuat pendekatan ini tidak dapat digunakan .

Yang saya temukan adalah ini filter berikut. The hostroutes-onlyjangka mengalihkan semua prefiks lebih pendek dari / 32 dengan kebijakan berikutnya. Setelah itu prefixesistilah tersebut cocok jika / 32 dalam jangkauan pelanggan, cocok dengan as-path-nya dan memiliki komunitas blackhole yang ditetapkan:

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

Jadi, apakah ini cara paling elegan untuk menangani ini? Ada solusi lain?

Tidak ada alasan untuk membatasi pelanggan hanya untuk lubang hitam / 32, memungkinkan mereka untuk lubang hitam apa pun dari mereka.

Sesuatu seperti ini:

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

Ingatlah untuk mengatur 'accept-remote-nexthop' di bawah pengaturan BGP, sehingga hop berikutnya dapat diubah menjadi sesuatu yang lain daripada alamat tautan.

Saya juga sangat mendukung bahwa penyedia mulai mendukung komunitas blackhole yang berbeda dari sekadar 'blackhole penuh'. Terutama jika Anda beroperasi di lebih dari satu negara biasanya serangan berasal dari transit dan seringkali pelanggan sebenarnya sebagian besar ingin mengakses peering domestik, sehingga berguna untuk menerapkan beberapa tingkat lubang hitam:

1. Penuh
2. Di luar negara lokal (IXP lokal, seluruh pelanggan AS + terlihat)
3. Di luar area lokal (jika berlaku, bagi saya itu bisa jadi 'Nordics')
4. Sertakan / Kecualikan router peering tertentu dalam lubang hitam

Saya senang memberi contoh bagaimana menerapkan sesuatu seperti ini dengan JNPR DCU / SCU, asalkan router peering Anda adalah JNPR, tetapi itu mungkin hanya dengan komunitas, hanya sedikit lebih canggung.

Jika Anda benar-benar ingin membatasi opsi pelanggan, Anda dapat menambahkan ini:

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

Dengan cara ini harus logis DAN. Tapi saya benar-benar tidak melihat nilai dalam menciptakan kompleksitas untuk mengurangi ekspresi konfigurasi.