鉴于您的客户是具有 /24 前缀的单个 ASN，您最好只应用前缀列表（最好在路由映射中分配前缀列表以允许设置更多属性在入口（本地偏好、社区等））到您的客户会话。这是一个示例路由映射，您可以将其应用于您的客户会话，它只允许他们的前缀并拒绝其他任何内容：

ip prefix-list ASXXX-PREFIXES permit x.x.x.x/24

route-map ASXXX-IN permit 10
 description Allow Customer Prefixes from ASXXX
 match ip address prefix-list ASXXX-PREFIXES

route-map ASXXX-IN deny 20
 description Block Everything Else

上面的路由映射将确保在会话中允许客户前缀，同时确保其他所有内容都被阻止。在路由映射/前缀列表上尽可能具体是最佳实践。

关于您对上游前缀重新分配的查询，只有在下游会话中收到客户端前缀时，您才应该这样做。这样做的一个好方法是通过 BGP 社区。在上面列出的入口路由映射上，您可以将 BGP 社区应用于允许的前缀（例如 111:444）。现在，在您的上游路由图上，您可以有一个声明，它将发送带有 111:444 标记的前缀，因为您知道带有该社区标记的唯一前缀将是您的客户端。这个面向上游的路由图也应该总是包含一个前缀列表。

小规模BGP客户前缀过滤

在这个小规模上，为您的 BGP 客户手动配置一个prefix-list是合适的。

更大的交通网络做什么

较大的传输网络使用IRR 数据库（ RADB FAQ 链接）来自动生成这样的前缀列表。然而，对于一个只有一个前缀列表条目的 BGP 客户来说，这种自动化投资是不明智的。

您的上游运输提供商做什么，以及现在如何影响您

请注意，您可能还需要从运输提供商的角度考虑这一点——他们如何在他们的设备上管理您的前缀列表；您的新 BGP 客户是如何进入该列表的？

您是否手动要求他们更新列表；或者您是否发布了适当的 IRR 条目，并且它们会消耗它们？

如果您的运输提供商要求您维护 IRR 条目

如果是后者，您需要将新的 BGP 客户添加到as-set: 包含您的 ASN 和他们的 ASN 的 IRR 对象；并确保route: 存在与每个原始 ASN 匹配的适当对象。

如果他们需要并代表您进行

如果您的交通服务提供商只是代表您执行此操作，那么将来会为您带来 IRR 数据库维护难题。最好控制自己的 IRR 对象；不必向以前的 ISP 发送电子邮件以在以后更新/删除它们。