within CAPs provisioning I can select “create enabled” or “create dynamic enabled” for interfaces. What practical influence do those parameters have? Is there any benefit using “static” instead of “dynamic” intefaces?
Regards
(According to Wiki:
create-disabled - create disabled static interfaces for radio. I.e., the interfaces will be bound to the radio, but the radio will not be operational until the interface is manually enabled;
create-enabled - create enabled static interfaces. I.e., the interfaces will be bound to the radio and the radio will be operational;
create-dynamic-enabled - create enabled dynamic interfaces. I.e., the interfaces will be bound to the radio, and the radio will be operational;
none - do nothing, leaves radio in non-provisioned state;)
We use dynamic interfaces. Static interfaces allow you to manually set configuration in the interface itself, whereas you can’t modify a dynamic interface. However, since you can configure all of these settings in the other tabs with dynamic interfaces, I personally do not see the point in making the interface static in most situations.
i am using static because i can set parameters to each cap. rename interface name, set configuration (channel, datapath) etc. even after caps reboots their names and configuration stays the same.
i dont know how you can do this with dynamic interfaces like “mducharme” above suggested. (with copy command?)
Very easy with dynamic interfaces - you use provisioning rules to match and apply the proper configuration to the device, and the configuration includes the channel / datapath settings. You still have control over everything without needing static interfaces. The only thing you don’t have control over is the exact interface name, since it is auto generated. However you do have control over the name format (i.e. how it generates the name) in the provisioning rule.
The advantage with dynamic interfaces is your provisioning rules can match something like the identity of the CAP in regexp, and then use that to control which configuration gets applied. for example, you could have something in the identity itself AP1-conf1, AP2-conf3, AP3-conf2, AP4-conf1 and then use the regexp to match the -conf1 -conf2 and -conf3, then you do not need to duplicate settings in cases where multiple APs will share a duplicate configuration.
I had the following issue with create dynamic enabled:
On a Capsman managed AP with multiple SSID’s (3) I had duplicate mac addresses with dynamic enabled. The MAC address of the 3rd (2nd virtual) SSID Radio was the same as the actual interface.
I found no way to influence that with create dynamic enabled.
Switched to create enabled and was able to manually edit the MAC address in Capsman.
i still prefer static interfaces than making dozens provisioning rules. sorry “mducharme”.
also i want to specify “exact interface name” by myself and no with provisioning rules.
One other thing to note, when dynamic interfaces are created, they disappear and reappear, thus causing anything referencing them in the config to turn into numeric values.
If created in static mode… when (re)provisionning OR reboot the caps, do they will be removed/flushed and replaced by new like expected by provisionning rules ?
The idea os to avoid having lot of unused interfaces…
Those are two different things, you can’t compare reboot with provisioning. All settings you manually apply persist after reboot, interfaces remain same.
Provisioning is as registration and acording to Mikrotik, it should be done just once. So the work flow should be provision, unprovision, provision again. And not provision, provision, provision…