Juniper远程触发黑洞(RTBH)滤波器

Question

我正试图找到一种最优雅的方法来为从客户那里接收到的路由实现特波黑过滤器。

过滤器应：

1. 只接受来自前缀列表的客户自己的前缀。
2. 只接受/32前缀
3. 只有黑洞社区的前缀
4. 将下一跳设置为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;
}

但后来我在文档中无意中发现了这样的信息：

如果配置包括路由筛选器、前缀列表和源地址筛选器组合的策略，则根据逻辑OR操作或最长路由匹配查找对它们进行评估。

正如我所理解的(我发现它有点不清楚)，如果我在同一术语中使用prefix-list-filter、route-filter和/或source-address-filter，那么它们之间将使用最长的匹配或匹配，这使得这种方法不可用。

我想出的是下面的过滤器。hostroutes-only术语将所有短于/32的前缀转移到下一个策略。在此之后，prefixes术语匹配如果/32在客户的范围内，匹配他的路径并设置黑洞社区：

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

那么，这是处理这件事最优雅的方法吗？还有其他解决办法吗？

Answer 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设置下设置“”，以便下一跳可以更改为链接地址以外的其他内容。

我也强烈支持供应商开始支持不同的黑洞社区，而不仅仅是“完全黑洞”。特别是如果你在一个以上的国家经营，通常攻击是来自过境，而且客户实际上主要是想进入国内的痛苦，所以实现几个层次的黑洞是有用的：

1. 完整
2. 在当地以外的国家(当地的IXP，全部自己的客户见过)
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;
        }
..
}

这样应该是合乎逻辑的。但我真的不认为创造复杂性来降低配置的表现力有什么价值。

Answer 2

已经有一段时间了，但这里有一点需要考虑与接受-远程-下一项相关。

假设在客户端上有一个改变下一跳的导入策略，将允许任何下一跳前缀，使其对于某些类型的攻击是“开放的”。

不确定能不能找到解决办法。也许，在策略下添加另一条语句，只接受实际的客户下一跳，这是可行的方法。另一件事是，使用eBGP多跳似乎不可能实现接受远程下一步操作。