我正在尝试找到一种最优雅的方法来为从客户收到的路由实施RTBH过滤器。

过滤器应：


仅接受客户前缀列表中自己的前缀
仅接受/ 32前缀
仅黑洞社区的前缀
将下一跳设置为RTBH下一跳（192.0.2.1）

首先，我查看了Juniper的“在路由策略条款中配置匹配条件”文档。

首先，我考虑将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的前缀转移到下一个策略。之后，如果/ 32在客户范围内，则匹配prefixes术语，匹配其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;
    }
}


这是处理这个问题的最优雅的方式吗？还有其他解决方案吗？

#1 楼

没有理由将客户限制为仅黑洞/ 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”，以便可以将下一跳更改为链接地址以外的其他地址。

我也强烈支持提供商开始支持不同的黑洞社区，而不仅仅是“完全黑洞”。尤其是如果您在一个以上的国家/地区开展业务，攻击通常是来自中转站，而客户通常实际上大多是想访问国内同行，因此实施多个级别的黑洞攻击很有用：


完整
在外部国家/地区（本地IXP，看到了自己的AS +客户）
在外部国家/地区（如果适用，对我来说可能是'Nordics'）
在黑洞中包含/排除特定的对等路由器

如果您的对等路由器是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;
        }
..
}


这种方式应该是逻辑与。但是我真的看不到创建复杂性以降低配置的表现力的价值。

评论

谢谢您的回答。我不希望客户在他们的大部分空间上留下黑洞，因为大多数情况下，他们是用脚在自己的脚上开枪。关于“ accept-remote-nexthop”，我在策略过滤器中更改了下一跳，因此不需要在会话中启用它。

–塞巴斯蒂安·维辛格
13年6月12日上午9:50
我们不是在“惩罚”任何人。如果他们想将较大的前缀列入黑名单，他们当然可以提出要求。在过去的几年中，没有人要求它。

–塞巴斯蒂安·维辛格
2013年6月12日上午10:57
您会看到更多麻烦，增加了复杂性，从而降低了表达能力。如果您从未提供过此服务，您怎么知道您的客户会不小心将黑洞社区添加到比/ 32大的网络中？碰巧的是，每当我们向供应商索要功能时，他们都会回答“从未有人要求过”，而当您与社区交流时，您会发现很多人都想要这种功能。无论如何，我添加了有关如何实现此限制的建议。

–ytti
2013年6月12日11:00


我意识到在您的示例中，没有黑洞就根本不接受前缀。因此，您可能有两个对等点，一个对等流量，一个对黑洞，在您的情况下，黑洞可能是多跳的，在多跳中，下一跳检查已关闭，因此您不需要“接受远程” -nexthop'。我的示例涵盖了同一配置中的两个BGP对等点，并且由于它是无多跳的直接PE <-> CE，因此需要“ accept-remote-nexthop”。

–ytti
13年6月12日在11:13
是的，是的，您需要在直接会话中使用它。过滤器在两种情况下均应工作，在PE <-> CE方案中，您可以将其与后面的其他过滤策略链接起来。

–塞巴斯蒂安·维辛格
13年6月12日在11:57

#2 楼

已经有一段时间了，但是这里需要考虑与accept-remote-nexthop相关的问题。
假定客户对端有更改下一跳的导入策略，accept-remote-nexthop将允许带有任何下一跳的前缀，使它对于某些类型的攻击是“开放的”。
不确定解决方法。也许在策略下添加了一条仅接受实际客户下一跳的声明，这才是可行的方法。
另一件事是，eBGP多跳似乎无法接受accept-remote-nexthop。