ジュニパーネットワークス向けのBGPリモートトリガーブラックホール（RTBH）フィルター

私は、顧客から受け取ったルートにRTBHフィルターを実装する最もエレガントな方法を見つけようとしています。

フィルターは：

1. 接頭辞リストから顧客自身の接頭辞のみを受け入れる
2. / 32プレフィックスのみを受け入れる
3. ブラックホールコミュニティのプレフィックスのみ
4. ネクストホップをRTBHネクストホップに設定する（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;
}

しかし、それから私はこの文書でこの情報につまずきました：

ルートフィルター、プレフィックスリスト、および送信元アドレスフィルターのいくつかの組み合わせを含むポリシーを構成する場合、それらは論理OR演算または最長ルート一致検索に従って評価されます。

私がこれを理解している（そしてそれが少し不明確であると思う）場合、を使用するとprefix-list-filter、route-filterおよび/またはsource-address-filter同じ用語で、それらすべての最長一致ORで評価されるため、このアプローチは使用できなくなります。

私が思いついたのはこれが次のフィルターです。このhostroutes-only用語は、/ 32より短いすべてのプレフィックスを次のポリシーに転送します。その後prefixes、/ 32が顧客の範囲内にある場合、用語は一致し、彼のas-pathに一致し、ブラックホールコミュニティが設定されます。

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

それで、これはこれを処理する最もエレガントな方法ですか？他の解決策はありますか？

お客様をブラックホール/ 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;
    }
}

BGP設定で 'accept-remote-nexthop'を設定して、ネクストホップをリンクアドレス以外に変更できるようにしてください。

また、プロバイダーが「完全なブラックホール」以外のさまざまなブラックホールコミュニティのサポートを開始することを強く支持します。特に、複数の国で運用している場合、通常、攻撃はトランジットによるものであり、顧客は実際にはほとんど国内のピアリングにアクセスすることを望んでいるため、いくつかのレベルのブラックホールを実装すると便利です。

1. フル
2. 現地国外（現地IXP、自社全体のAS +顧客が見られる）
3. ローカルエリア外（私の場合、「Nordics」のように該当する場合）
4. ブラックホールに特定のピアリングルーターを含める/除外する

ピアリングルーターがJNPRである場合、JNPR DCU / SCUでこのようなものを実装する方法の例を紹介できてうれしいですが、コミュニティだけでも可能で、少し厄介です。

顧客のオプションを絶対に制限したい場合は、これを追加できます。

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

このように、それは論理ANDでなければなりません。しかし、構成の表現力を減らすために複雑さを作成することの価値は、実際にはわかりません。