没有理由将客户限制为仅黑洞 /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 DCU/SCU 实现类似的功能，前提是您的对等路由器是 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;
        }
..
}

这样它应该是合乎逻辑的AND。但我真的没有看到创造复杂性以降低配置表现力的价值。

已经有一段时间了，但这里有一点需要考虑与 accept-remote-nexthop 相关。

假设客户对等点更改下一跳有导入策略，accept-remote-nexthop 将允许任何下一跳的前缀，使其对某些类型的攻击“开放”。

不确定解决方法。也许在策略下添加另一条语句以仅接受实际客户的下一跳是当时要走的路。另一件事是，eBGP 多跳似乎无法实现接受远程下一跳。