清除 IP TOS 标头中的 ECN 位是否有害?

清除 IP TOS 标头中的 ECN 位是否有害?

我正在考虑清理我们网络边界上的这些位。这是否有害或邪恶?

一些背景:

我们有从互联网到某些移动设备的入口流量,这些设备位于 IPSec 隧道后面,通向移动网络运营商 GGSN。

+----+    +--------------+       +------------+ Tunnel via +----+     +------+
|Inet|----| Border router|------>|IPSEC-Router|============|GGSN|-----|mobile|
+----+    +--------------+       +------------+ Internet   +----+     +------+

部分来自互联网的入口流量标有 TOS 0x03,值得注意的是,所有流量都来自名为 UnityMedia 的德国有线 ISP。

由于目前未知的原因,IPSec 路由器上的 IPSec 实现决定丢弃所有标有 TOS 0x01 或 0x03 的包。关于这一点,我提出一个问题这里。

作为解决方法,我会从边界路由器上的 TOS 字段中删除 ECN 相关位,但另一方面,我不确定这样做是否会产生新的问题,因此我的问题是:

这被认为是有害的还是邪恶的?

答案1

不。这通常是由工程师清除 dscp 位来完成的,但想法是一样的。作为网络工程师,您应该决定哪些流量获得优先级或特殊排队权限,而不是端点。路径中的大多数路由器很可能没有启用 ECN 排队,如果它通过互联网传输,则绝对不会启用。一些路由器和防火墙甚至不会将 TOS 位从未加密的数据包复制到加密的数据包头。

现在就您的情况而言,您是否在网络上运行任何实时应用程序,例如语音或视频?您使用哪种路由器或防火墙来传输流量?如果是企业级设备,您应该能够在 ECN 位到达路由器的未加密接口时剥离它们。这个隧道是通过互联网还是专用电路传输出去的?

编辑:

这并不算邪恶,因为负责网络的是你自己,而不是你的用户。因此,由你来决定要传递哪些流量以及为这些流量分配什么速度和队列。通常认为,最佳业务实践是在入口处清除用户的 DSCP 位,然后自行对流量进行分类以进行排队和拥塞控制。

它是否有害取决于具体情况。看来,在您的场景中,您的用户通过 VPN 隧道从互联网进入,然后又以明文方式返回互联网。由于互联网是尽力而为的网络,ECN 位对您来说基本上是无用的,因为互联网路由器不会遵守这些位。通常,传输级别的 QoS 和拥塞控制仅在您可以端到端控制设备的网络中或您与提供商有保证速率或 SLA 的网络中才有用。

答案2

抱歉,如果可以的话,请把我降级:我没有足够的管理员积分来投票或添加评论。

resmon6 给出的答案在我看来非常糟糕和无知。他谈论 TOS 和 DSCP 就好像它们与 ECN 相同。ECN 完全不同,应该保持原样并允许其发挥作用!

resmon6:

作为网络工程师,您应该决定哪些流量获得优先级或特殊排队权限”

真的吗?那这和 ECN 到底有什么关系?

resmon6:

路径中的大多数路由器很可能没有启用 ECN 排队,如果是通过互联网传输的话肯定没有启用。

据我所知,这完全不是事实。过去十年或更久以来,所有操作系统和路由器都支持 ECN,如果我没记错的话,至少 Linux 默认部分启用了 ECN,当然不是“所有互联网路由器”都禁用 ECN。虽然有一些坏苹果(黑洞),但总的来说还是有效的。

只有无知的人故意破坏 ECN,才会给其他人的使用带来如此大的问题。

resmon6:

这并不被视为邪恶,因为对你的网络负责的是你,而不是你的用户。

真是胡说八道!只要流量没有危害,你就需要让你的用户做他们想做的事:网络中立等等。ECN 对每个人都有好处:你和你的用户。你的言论毫无意义!

要想不惹恼 ECN,你需要做的就是忽略它。什么也不要做。你到底为什么要禁用它?

说真的……如果您不知道 ECN 是什么,在假装专家回答问题之前,至少先浏览一下维基百科页面!

http://en.wikipedia.org/wiki/Explicit_Congestion_Notification

DSCP 根本不存在,唯一的 TOS 就在“macintosh”这个词里!FCOL!

答案3

优先权的反面

在网络内将 ECN 字段清除为零对其他流量非常有害,并且毫无用处。

由于 ECN 会通知拥塞,因此它的效果与优先级相反。因此,如果您从某些流量中清除 ECN,则相对于其他流量,您会给予该流量极大的优势。

解释:瓶颈最常见的位置是将数据包标记为显式拥塞通知 (ECN) 的位置,即进入互联网的家庭网关路由器。如果在网络中的某个位置清除了 ECN 字段,则发送方将无法感知任何瓶颈拥塞。然后,它们将越来越快地发送,直到超出瓶颈缓冲区,在增加大量排队延迟后导致数据包丢失。

虽然这并不令人愉快,但您正在破坏的数据包的发送者可以承受失去 ECN 的好处……然而,其他所有人都会受到影响。如果通过同一瓶颈的部分流量在互联网的其他地方(而不是通过您正在破坏的点)关闭,它仍会看到极端拥塞通知,因为缓冲区溢出(因为您没有通过干预向所有人隐瞒这一点)。因此,其他流量将迅速降低其速率并陷入困境。

适当的解决方案

如果 VPN 隧道出口丢弃了 ECN 字段设置为 0x3 的数据包,这是因为内部 IP 报头上的 ECN 字段为 00。根据 ECN 规范,这就是隧道的本意[RFC3168]解决方案不是盲目清除所有数据包上的 ECN 字段(这会导致上述问题)。正确的解决方案是确保在以 ECN == 0 开头的数据包上不将 ECN 设置为 0x3。因为根据 ECN 规范,这是一种非法转换(这就是 VPN 出口丢弃它们的原因)。

20 世纪恐龙

IP 标头(v4 和 v6)中的 8 位服务类型字段于 1998 年 12 月重新定义,并分为 6 位用于差异化服务,2 位用于显式拥塞通知 (ECN)。

只有仍然生活在 20 世纪的恐龙(包括 resmon6)才会认为 ECN 领域仍然与优先级有关。

相关内容