鉴于通过 VPN 连接创建与远程 AS 的 BGP 会话所获得的优势(例如流量入口和出口控制),为什么没有提供此类服务的提供商?
HE.net 有一个类似于 IPv6 隧道的 IPv6 隧道服务,但为什么没有人提供基于 VPN 的 BGP 会话?
鉴于通过 VPN 连接创建与远程 AS 的 BGP 会话所获得的优势(例如流量入口和出口控制),为什么没有提供此类服务的提供商?
HE.net 有一个类似于 IPv6 隧道的 IPv6 隧道服务,但为什么没有人提供基于 VPN 的 BGP 会话?
某些 ISP 滥用对等关系使用了这种技巧 - 提供商 A 在两个点上对等(假设美国东海岸和西海岸)。提供商 A 在 B 的网络上的对等节点之间建立了一条隧道,而 B 突然不情愿地提供免费的跨国带宽。不用说,这种行为曾经(并且现在)非常不受欢迎。
现在 - 至于在 VPN 隧道上为中转/最终用户使用 BGP,有几个问题:
1.) 底层隧道的路由是完全不透明的。假设您有两个通向两个不同提供商的隧道,那么这些隧道可能(......如果在消费者级服务的情况下不太可能)可以穿过一些相同的中间点,如果 HA 是目标,那么这会违背目的心里。
2.) 供需——当然,ISP可以提供这类服务,但实际上谁在购买它们?如果您已经获得了 ASN,并且获得了 PI 空间(不太可能)或协商了适当的路线泄漏,那么您很可能在交通服务上花费了相当多的钱(至少)。相比之下,每月花费 59 美元购买互联网服务的消费者不太可能提供收入来(有利地)抵消登陆大量 BGP 会话的硬件成本,以及维护和支持所述会话的运营开销。在流量回程方面还有一个隐藏的成本,ISP 更不愿意为此付费。
即使您与位于您下游/上游的另一个 AS 对等,除非您直接连接,否则没有真正的方法来设计流量将采用的路径。
它在 HE 等示例中很方便的原因是您的上游可能还不支持 IPv6,但您想开始在您的 AS 中运行它,因此需要一条通往它们的隧道。