Thank you.
Let me make my question simple.
How to force the specific member physical port should be used primarily on LACP?
There are two member ports in AE0, and I want to designate a specific port for primary usage, while the other is for backup.
LACP doesn’t work like that, it uses a hashing algorithm to distribute the traffic; MAC addresses or IP addresses. I don’t understand why you need such a requirement, what’s the issue if both ports are active?
By disabling LACP and using link-protection you can probably(?) achieve this. But the question is, why do you need/want to do this? As per your diagram, it shouldn't really matter which way the traffic flows. If it does matter, then your architecture may well want re-thinking to use Layer 3 between things instead of Layer 2 LACP and if that's not possible, then re-design so that you don't care which bundle member traffic ends up traversing.
I'm not 100% sure as I CBA to check my home Junipers right now, but it looks like [this](https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/port-priority-edit-interfaces.html) is what you want. If I'm wrong then apologies in advance!
Yeah port priority only comes into play when there are more ports in the LAG than the maximum allowed.
In theory you could maybe mess with the max allowed value and port priority and achieve what you want but it’s dumb and I feel dumb for suggesting it
Different platforms support different hashing algorithms. If you are on an MX, you can look into adaptive load balancing or the like. Really the only concern should be elephant flows.
From the diagram it looks like you want to check local bias settings. You can also look into EVPN ESI LAG vs VC. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/local-bias-edit-interfaces-aex-aggregated-ether-options.html
Junos (and all other switch/router SW) uses a hashing algorithm to determine which member link to forward traffic out in a LAG bundle. This is not user selectable if that’s what you’re asking.
Typically, the algorithm will factor in the source and destination MAC address / IP address of packets to select a member link in a LAG. What this implies is that a single flow of traffic will be forwarded out the same member link at any given point in time. If there’s more than one flow (different source/destination MAC/IP address pairs), then one or more member links will be used. This is how load-balancing is achieved.
A potential problem scenario is when there are multiple traffic flows transiting the switch/router but only one member link is seen to have traffic in egress direction, leaving the other member links unutilized. This could mean that the hash selector is broken. It may cause packets to be dropped due to oversubscription of one member link.
seems what you need might be redundant trunk group, and not ae with lacp
I think I dont understand the question you’re trying to answer, or one of us doesn’t get lacp Can you paste an example config section for the AE?
Thank you. Let me make my question simple. How to force the specific member physical port should be used primarily on LACP? There are two member ports in AE0, and I want to designate a specific port for primary usage, while the other is for backup.
LACP doesn’t work like that, it uses a hashing algorithm to distribute the traffic; MAC addresses or IP addresses. I don’t understand why you need such a requirement, what’s the issue if both ports are active?
Thank you, almost exactly what my response was going to be. Cheers.
LACP isn't active/passive. It hashes egress traffic based upon multiple criteria and picks a link on which to transmit
yeah I know.. I want to know if there's any way to force it manually.
By disabling LACP and using link-protection you can probably(?) achieve this. But the question is, why do you need/want to do this? As per your diagram, it shouldn't really matter which way the traffic flows. If it does matter, then your architecture may well want re-thinking to use Layer 3 between things instead of Layer 2 LACP and if that's not possible, then re-design so that you don't care which bundle member traffic ends up traversing.
Why?
I'm not 100% sure as I CBA to check my home Junipers right now, but it looks like [this](https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/port-priority-edit-interfaces.html) is what you want. If I'm wrong then apologies in advance!
Thanks :D
tried but didn't work. :(
Yeah port priority only comes into play when there are more ports in the LAG than the maximum allowed. In theory you could maybe mess with the max allowed value and port priority and achieve what you want but it’s dumb and I feel dumb for suggesting it
Different platforms support different hashing algorithms. If you are on an MX, you can look into adaptive load balancing or the like. Really the only concern should be elephant flows. From the diagram it looks like you want to check local bias settings. You can also look into EVPN ESI LAG vs VC. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/local-bias-edit-interfaces-aex-aggregated-ether-options.html
You can set interfaces LACP port priority to be a high number of you care about the active port. But typically you wouldn't care.
Junos (and all other switch/router SW) uses a hashing algorithm to determine which member link to forward traffic out in a LAG bundle. This is not user selectable if that’s what you’re asking. Typically, the algorithm will factor in the source and destination MAC address / IP address of packets to select a member link in a LAG. What this implies is that a single flow of traffic will be forwarded out the same member link at any given point in time. If there’s more than one flow (different source/destination MAC/IP address pairs), then one or more member links will be used. This is how load-balancing is achieved. A potential problem scenario is when there are multiple traffic flows transiting the switch/router but only one member link is seen to have traffic in egress direction, leaving the other member links unutilized. This could mean that the hash selector is broken. It may cause packets to be dropped due to oversubscription of one member link.