<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 20, 2020 at 3:09 PM Saku Ytti <<a href="mailto:saku@ytti.fi">saku@ytti.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hey Nimrod,<br>
<br>
> I was contacted by my NOC to investigate a LAG that was not distributing traffic evenly among the members to the point where one member was congested while the utilization on the LAG was reasonably low. Looking at my netflow data, I was able to confirm that this was caused by a single large flow of ESP traffic. Fortunately, I was able to shift this flow to another path that had enough headroom available so that the flow could be accommodated on a single member link.<br>
><br>
> With the increase in remote workers and VPN traffic that won't hash across multiple paths, I thought this anecdote might help someone else track down a problem that might not be so obvious.<br>
<br>
This problem is called elephant flow. Some vendors have solution for<br>
this, by dynamically monitoring utilisation and remapping the<br>
hashResult => egressInt table to create bias to offset the elephant<br>
flow.<br>
<br>
One particular example:<br>
<a href="https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/adaptive-edit-interfaces-aex-aggregated-ether-options-load-balance.html" rel="noreferrer" target="_blank">https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/adaptive-edit-interfaces-aex-aggregated-ether-options-load-balance.html</a><br>
<br>
Ideally VPN providers would be defensive and would use SPORT for<br>
entropy, like MPLSoUDP does.<br>
<br>
-- <br>
  ++ytti<br>
<br></blockquote><div><br></div><div><br></div><div>There are *several* caveats to doing dynamic monitoring and remapping of</div><div>flows; one of the biggest challenges is that it puts extra demands on the </div><div>line cards tracking the flows, especially as the number of flows rises to</div><div>large values.  I recommend reading</div><div><a href="https://www.juniper.net/documentation/en_US/junos/topics/topic-map/load-balancing-aggregated-ethernet-interfaces.html#id-understanding-aggregated-ethernet-load-balancing">https://www.juniper.net/documentation/en_US/junos/topics/topic-map/load-balancing-aggregated-ethernet-interfaces.html#id-understanding-aggregated-ethernet-load-balancing</a><br></div><div>before configuring it.</div><div><br></div><div>"<span style="color:rgb(51,51,51);font-family:Lato,Arial,Helvetica,sans-serif;font-size:16px">Although the feature performance is high, it consumes significant amount of line card memory. Approximately, 4000 logical interfaces or 16 aggregated Ethernet logical interfaces can have this feature enabled on supported MPCs. However, when the Packet Forwarding Engine hardware memory is low, depending upon the available memory, it falls back to the default load balancing mechanism."</span></div><div><span style="color:rgb(51,51,51);font-family:Lato,Arial,Helvetica,sans-serif;font-size:16px"><br></span></div><div><span style="color:rgb(51,51,51);font-family:Lato,Arial,Helvetica,sans-serif;font-size:16px">What is that old saying?</span></div><div><span style="color:rgb(51,51,51);font-family:Lato,Arial,Helvetica,sans-serif;font-size:16px"><br></span></div><div><span style="color:rgb(51,51,51);font-family:Lato,Arial,Helvetica,sans-serif;font-size:16px">Oh, right--There Ain't No Such Thing As A Free Lunch.   ^_^;;</span></div><div><span style="color:rgb(51,51,51);font-family:Lato,Arial,Helvetica,sans-serif;font-size:16px"><br></span></div><div><span style="color:rgb(51,51,51);font-family:Lato,Arial,Helvetica,sans-serif;font-size:16px">Matt</span></div><div><span style="color:rgb(51,51,51);font-family:Lato,Arial,Helvetica,sans-serif;font-size:16px"><br></span></div><div> </div></div></div></div></div>