为什么在使用自动带宽时,我的等价 LSP 的负载均衡不均衡?

网络工程 瞻博网络 聚光灯 瞻博网络 电调 敬请回复
2021-07-03 00:48:26

首先,我正在添加这个问题并回答自己,因为这种行为绝对找不到,希望它会对某人有所帮助。

问题:

我们使用自动带宽来处理 LSP 的带宽订阅。LSP 的成本相等,并且作为每个目的地的可用下一跳适当地出现在我们的转发表/路由表中。

但是对于单个目的地,4 个等价 LSP 的负载均衡并不相等(甚至接近相等)。我们知道 JUNOS 使用按流负载平衡算法,尽管策略中声明了“按数据包”以启用负载平衡。但这并不能解释 LSP 的每个订阅之间的主要区别(这种订阅不平衡每天发生多次,这不是一次性的),如下所示:

jhead@R1> show route protocol rsvp 1.1.1.1 detail

1.1.1.1/32 (2 entries, 1 announced)
        State: <FlashAll>
        *RSVP   Preference: 7/1
                Next hop: 192.168.1.1 via xe-0/0/0.0 weight 0x1 balance 35%, selected
                Label-switched-path LSP1
                Next hop: 192.168.1.2 via xe-1/0/0.0 weight 0x1 balance 35%
                Label-switched-path LSP2
                Next hop: 192.168.1.3 via xe-0/0/1.0 weight 0x1 balance 26%
                Label-switched-path LSP3
                Next hop: 192.168.1.4 via xe-0/0/0.0 weight 0x1 balance 5%
                Label-switched-path LSP4

R1-R4 是 MX480,CORE-R1-R4 是 MX960。

下面是比较 RSVP 订阅和 LSP 利用率的图表。红色是订阅,绿色是使用。您可以看到利用率几乎全天都在预订。我们应该看到,同一目的地的 LSP 之间的订阅非常接近。

在此处输入图片说明 在此处输入图片说明 在此处输入图片说明 在此处输入图片说明

拓扑:

R1 - R4 是所有 LSP 的入口路由器,它们有 2 或 4 个 LSP 通往每个核心路由器。

在此处输入图片说明

配置:

LSP 配置是来自 R1 的单个目的地,仅作为示例。所有 LSP 的配置方式完全相同(同样,使用 2 或 4)。

[edit protocols mpls]
    statistics {
        file mpls-stats;
        interval 300;
        auto-bandwidth;
    }
    traffic-engineering bgp;
    label-switched-path LSP1 {
        to 1.1.1.1;
        optimize-timer 300;
        auto-bandwidth {
            adjust-interval 7200;
            adjust-threshold 10;
            minimum-bandwidth 100m;
            maximum-bandwidth 4g;
            adjust-threshold-overflow-limit 2;
            adjust-threshold-underflow-limit 4;
        }
        primary primary-loose;
    }
    label-switched-path LSP2 {
        to 1.1.1.1;
        optimize-timer 300;
        auto-bandwidth {
            adjust-interval 7200;
            adjust-threshold 10;
            minimum-bandwidth 100m;
            maximum-bandwidth 4g;
            adjust-threshold-overflow-limit 2;
            adjust-threshold-underflow-limit 4;
        }
        primary primary-loose;
    }
    label-switched-path LSP3 {
        to 1.1.1.1;
        optimize-timer 300;
        auto-bandwidth {
            adjust-interval 7200;
            adjust-threshold 10;
            minimum-bandwidth 100m;
            maximum-bandwidth 4g;
            adjust-threshold-overflow-limit 2;
            adjust-threshold-underflow-limit 4;
        }
        primary primary-loose;
    }
    label-switched-path LSP4 {
        to 1.1.1.1;
        optimize-timer 300;
        auto-bandwidth {
            adjust-interval 7200;
            adjust-threshold 10;
            minimum-bandwidth 100m;
            maximum-bandwidth 4g;
            adjust-threshold-overflow-limit 2;
            adjust-threshold-underflow-limit 4;
        }
        primary primary-loose;
    }

[edit protocols rsvp]
load-balance bandwidth
interface xe-0/0/0.0 {
    bandwidth 9g;
}
interface xe-0/0/1.0 {
    bandwidth 9g;
}
interface xe-1/0/0.0 {
    bandwidth 9g;
}

[edit routing-options forwarding-table]
export load-balance;
2个回答

问题在于:

[edit protocols rsvp]
load-balance bandwidth

如果您查看有关Unequal Cost Load Balancing RSVP LSPs的 Juniper 文档,它会指出:

为了使用带宽的不均匀负载平衡工作,您必须至少有两个等价 LSP 指向同一出口路由器,并且至少其中一个 LSP 必须在 [edit protocols mpls label-switched-path lsp-路径名] 层次结构级别。如果 LSP 没有配置带宽,则进行均布负载分担。如果只有部分 LSP 配置了带宽,则没有配置带宽的 LSP 不会收到任何流量。

这意味着无论配置了该功能,如果您不在单个 LSP 上静态设置带宽值,则不会发生等成本负载平衡,如下所示:

[edit protocols mpls label-switched-path LSP1]
bandwidth 2g

然而,自动带宽实际上算作设置带宽值,尽管它不存在于配置中。

启用自动带宽后,RPD 将开始监控带宽消耗。它将根据利用率分配带宽值,然后 RSVP 中的“负载平衡带宽”语句将立即开始尝试将流量比率保持在这些订阅内(分别为 35、35、26、5)。这样做的问题是它永远不会给自动带宽均匀调整的机会,因为“负载平衡带宽”的目标是使流量尽可能接近这些比率。当它们设置为 10、30、20、40 之类的东西时,这是有道理的。

它本质上是“负载平衡带宽”和“自动带宽”之间的竞争条件

删除后:

[编辑协议 rsvp] 负载平衡带宽

交通调整(有轻微的打嗝,见下图):

注意:这是受同一问题影响的不同路由器的示例。

jhead@R1> show log mpls-stats

LSP1 (LSP ID 3388, Tunnel ID 2646)    177150801 pkt   155450491134 Byte 178572 pps 152286259 Bps Util 228.46% Reserved Bw 66660264 Bps
LSP2 (LSP ID 3393, Tunnel ID 2647)            0 pkt              0 Byte      0 pps        0 Bps Util  0.00% Reserved Bw 116698880 Bps

由于您取消了负载平衡的能力(对于 RSVP),PFE 将重新编程为仅一条路径,直到自动带宽调整自动发生,或者您可以强制调整:

request mpls lsp adjust-autobandwidth

下面是 2 个具有相同症状的 LSP 的带宽调整,配置更改和调整发生在周五中午,您几乎可以立即看到订阅的不同。

在此处输入图片说明 在此处输入图片说明

“我们了解 JUNOS 使用按流负载平衡算法,尽管策略中声明了“按数据包”以启用负载平衡”

在使用 iperf 测试某些负载平衡方案时,发现该陈述是正确的。对于单个 iperf 会话,流量根本不会进行负载平衡,但是当启用并行 iperf 会话时,流量会得到负载平衡。

尽管瞻博网络文档另有说明! http://www.juniper.net/documentation/en_US/junos13.2/topics/usage-guidelines/mpls-configuring-load-balancing-across-rsvp-lsps.html

我想知道以上是否适用于 JUNOS13.2