我试图找出如何在JUNOS中使用ECMP负载平衡。 我知道这不是负载平衡的最佳方式，但它的快速和肮脏，并完成我所需要的。 在ScreenOS中，这非常简单。
设备：SRX220 JunOS：10.3R2.11
这是迄今为止我所得到的：
routing-options { static { route 0.0.0.0/0 { next-hop [ 1.1.1.1 1.1.1.2 ]; metric 10; } } maximum-paths 2; 这样做吗？
汤姆
你绝对不想要maximum-paths 。 这将限制你的路由表大小，并与ECMP无关。
所以只是：
routing-options { static { route 0.0.0.0/0 { next-hop [ 1.1.1.1 1.1.1.2 ]; metric 10; } } }
你会看到的：
lab@router> show route 0.0.0.0/0 ... 0.0.0.0/0 *[Static/5] 00:01:28, metric 10 > to 1.1.1.1 via ge-0/0/0.0 to 1.1.1.2 via ge-0/0/0.0
下一跳都出现在路由表中，但是看看转发表中究竟发生了什么，你必须深入研究：
lab@router> show route forwarding-table destination 0.0.0.0/0 ... Destination Type RtRef Next hop Type Index NhRef Netif 0.0.0.0/0 user 0 1.1.1.1 ucst 558 3 ge-0/0/0.0
默认情况下，当路由器将路由表下推到转发表时，它随机select一个下一跳。 要改变这种行为，你可以定义一个“转发表导出”策略来控制转发表从路由表中生成时发生的情况：
routing-options { static { route 0.0.0.0/0 { next-hop [ 1.1.1.1 1.1.1.2 ]; metric 10; } } forwarding-table { export LOAD-BALANCE; } } policy-options { policy-statement LOAD-BALANCE { then { load-balance per-packet; } } }
现在，路由表仍然看起来一样：
lab@router> show route 0.0.0.0/0 ... 0.0.0.0/0 *[Static/5] 00:07:28, metric 10 > to 1.1.1.1 via ge-0/0/0.0 to 1.1.1.2 via ge-0/0/0.0
但是转发表（它在哪里）有两个路由：
lab@router> show route forwarding-table destination 0.0.0.0/0 ... Destination Type RtRef Next hop Type Index NhRef Netif 0.0.0.0/0 user 0 ulst 262142 2 1.1.1.1 ucst 558 3 ge-0/0/0.0 1.1.1.2 ucst 540 3 ge-0/0/0.0
现在你是负载平衡！
但有一点需要记住的是，尽pipeload-balance per-packet声明的load-balance per-packet 令人难以置信 ，但所有采用此configuration的瞻博networking路由器实际上都是按照stream量进行负载均衡。 每个数据包基于（src-ip，dst-ip和协议号）进行散列。 所以如果你只有几个stream量的话，他们可能都会使用相同的下一跳。 一旦你增加了stream量的数量，你应该会看到更多的负载。
（实际上，第一个硬件确实做了每个数据包的负载平衡，但是你可能永远不会碰到一个）