为什么当我使用自动带宽时，我的等成本LSP的负载平衡不一样？

Question

首先，我加入了这个问题，并回答了自己，因为这种行为是绝对找不到的，希望它能帮助到某人。

问题：

我们使用自动带宽来处理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为R1 480‘S，核心-R1-R4为R1 960’S。

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

拓扑：

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

Configuration:

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;

Answer 1

问题是：

[edit protocols rsvp]
load-balance bandwidth

如果您查看不等成本负载平衡的Juniper文档，它会声明：

若要使用带宽进行不均衡的负载平衡，则必须至少有两个相同成本的LSP用于相同的出口路由器，并且至少一个LSP必须具有在编辑协议mpls标签交换路径lsp路径名称层次结构级别上配置的带宽值。如果没有LSP配置带宽，则执行等量分配负载平衡。如果只有一些LSP配置了带宽，则没有配置任何带宽的LSP不会接收任何通信量。

这意味着，无论配置了该功能，如果不静态地为单个LSP设置带宽值，则不会发生相同的成本负载平衡，如下所示：

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

然而，尽管在配置中没有自动带宽，但自动带宽实际上可以算作设置带宽值。

当启用自动带宽时，RPD将开始监视带宽消耗。它将根据利用率分配带宽值，然后RSVP中的“负载平衡带宽”语句将立即开始尝试将流量比率保持在这些订阅中(分别为35、35、26、5)。问题是，它从来没有给自动带宽调整的机会，因为“负载平衡带宽”S的目标是使流量尽可能接近这些比率。当它们被设定为，10，30，20，40时，这是有意义的。

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

移除后：

编辑协议应答负载平衡带宽

交通调整(有轻微的打嗝，见下文)：

注意:这是一个来自不同路由器的例子，它受到相同问题的影响。

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

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

Answer 2

“我们理解JUNOS使用了一种按流负载平衡算法，尽管策略中有”每个数据包“的声明，以启用负载平衡”

当使用iperf测试一些负载平衡场景时，发现该语句非常正确。对于单个iperf会话，流量根本不是负载均衡的，但是当启用paralell iperf会话时，流量会达到负载平衡。

尽管Juniper文档提出了相反的建议！http://www.juniper.net/documentation/en_US/junos13.2/topics/usage-guidelines/mpls-configuring-load-balancing-across-rsvp-lsps.html

我想知道上述规定是否适用于联合行动13.2