limit-learning on sharing master port
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎07-20-2018 08:29 AM
Hi there,
We've run into some problems when configuring limit-learning on load-sharing ports with lacp.
We use configure ports X vlanY limit-learning 0 action stop-learning combined with a static fdbentry as an L2 security measure. It works fine on normal ports, but something weird happens when we apply the same configuration to a sharing master port - lacp members of said sharing can start flapping sporadically. Removing limit-learning doesn't help, neither does disabling and enabling sharing on these ports. The only solution we found is that case is physically moving links do different ports and creating a new sharing there. This problem is not reproduced 100% of the time though, we have some LAGs that work fine with limit-learning. This is seen on both X460-48t with ExtremeXOS version 15.3.3.5, and X670-48x on 16.1.3.6. Is there a cure for that? Any suggestions would be most appreciated!
We've run into some problems when configuring limit-learning on load-sharing ports with lacp.
We use configure ports X vlanY limit-learning 0 action stop-learning combined with a static fdbentry as an L2 security measure. It works fine on normal ports, but something weird happens when we apply the same configuration to a sharing master port - lacp members of said sharing can start flapping sporadically. Removing limit-learning doesn't help, neither does disabling and enabling sharing on these ports. The only solution we found is that case is physically moving links do different ports and creating a new sharing there. This problem is not reproduced 100% of the time though, we have some LAGs that work fine with limit-learning. This is seen on both X460-48t with ExtremeXOS version 15.3.3.5, and X670-48x on 16.1.3.6. Is there a cure for that? Any suggestions would be most appreciated!
1 REPLY 1
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎07-30-2018 10:58 AM
Hello Phil,
In addition to what is recommended already:
1. Try to keep allowed vlans list reasonable. With "mint mlcp vlan" (default) MiNT link creation protocol (MLCP) will send discovery to all allowed vlans - i.e. to 4096 vlans. Which creates some CPU load.
2. Having same VLAN tunelled and availabe in trunk as well will potentially create loops. For instance client's dhcp request will be tunneled to controller, bridged there to target vlan than reach AP's LAN interface. So as recommended - filter all tunneled vlans in AP trunk
Misha
In addition to what is recommended already:
1. Try to keep allowed vlans list reasonable. With "mint mlcp vlan" (default) MiNT link creation protocol (MLCP) will send discovery to all allowed vlans - i.e. to 4096 vlans. Which creates some CPU load.
2. Having same VLAN tunelled and availabe in trunk as well will potentially create loops. For instance client's dhcp request will be tunneled to controller, bridged there to target vlan than reach AP's LAN interface. So as recommended - filter all tunneled vlans in AP trunk
Misha
