瞻博网络的BGP远程触发黑洞（RTBH）过滤器

我正在尝试找到最优雅的方法来为从客户收到的路由实施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在客户范围内，则该术语匹配，匹配其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. 局域外（如果适用，对我来说可能是“北欧”）
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;
        }
..
}

这样，它应该是逻辑与。但是我真的看不到创建复杂度以降低配置的表现力的价值。