The command seems loosely of the kind:
set <attribute1=value1> <attribute2=value2>
Once you are in:
/interface/ethernet/switch
the command:
set switch1 mirror-source=ether2 mirror-target=ether7
is different from the one you posted:
set mirror-source=ether2 mirror-target=ether7
my bad. The command above as per documentation from Mikrotik fails the same; i already tried to fiddle around with the command to make it work.
[admin@crs312] /interface/ethernet/switch> set switch1 mirror-source=ether2 mirror-target=ether7
expected end of command (line 1 column 13)
If i enter “set switch1 mirror” the auto-completed line reads “set switch1 mirror-target=”. That’s why i deduced it does not know the command “mirror-source”.
I asked for the output of
/interface/ethernet/switch
because yours could be called “switch2” or “mickey mouse”, and in some cases it may be easier to refer to the number (that you should get from the output of print).
Or try command line autocompletion from the beginning, , i.e.
set [TAB]
and see what options you have
Starting from RouterOS version 7.15, it is possible to configure multiple source ports and selectively choose whether to mirror incoming traffic, outgoing traffic, or both. In this example, both incoming and outgoing traffic from the ether2 interface will be copied and sent to the ether3 interface for monitoring or analysis.
Since RouterOS v7.15
/interface ethernet switch port
set ether2 mirror-egress=yes mirror-ingress=yes
/interface ethernet switch
set switch1 mirror-target=ether3
Older RouterOS:
/interface ethernet switch
set switch1 mirror-source=ether2 mirror-target=ether3
many thanks, this was the information that i failed to find!
I have yet to verify it but the commands worked and i see traffic flowing in Wireshark so i am optimistic!
[admin@crs312] /interface/ethernet/switch/port> set ether2 mirror-egress=yes mirror-ingress=yes
[admin@crs312] /interface/ethernet/switch> set switch1 mirror-target=ether7
It is one of those (actually trifling) things that make you believe that sometimes the good Mikrotik guys do not think too much before changing a syntax.
I mean, I do understand how the new syntax allows to select whether the miroring is ingress or egress traffic (or both) but it could have been implemented differently, the “old” syntax was “easy” :
Older RouterOS:
/interface ethernet switch
set switch1 mirror-source=ether2 mirror-target=ether3
the new one is (IMHO without reason) stupidly complex, as the settings are divided into two different submenus:
Since RouterOS v7.15
/interface ethernet switch port
set ether2 mirror-egress=yes mirror-ingress=yes
/interface ethernet switch
set switch1 mirror-target=ether3
They could have done (still IMHO) :
#Hypothetical syntax
/interface ethernet switch
set switch1 mirror-source=ether2 mirror-target=ether3 mirroring=ingress|egress|both
With the default being “both”, this way all settings would have remained on one line.
The new one is (potentially) flexible, it may allow this scenario:
/interface ethernet switch port
set ether2 mirror-egress=yes mirror-ingress=no
set ether4 mirror-egress=no mirror-ingress=yes
set ether5 mirror-egress=yes mirror-ingress=yes
/interface ethernet switch
set switch1 mirror-target=ether3
I don’t see how this can be achieved using old syntax … multiple mirror sorces yes, but not selection of direction to be mirrored per mirrored source port.
Well, if I have ether1, ether2, etc., I surely can have mirror-source1, mirror-source2 and mirroring1, mirroring2, etc.
BTW, I don’t oppose to changing names of properties/obiects/whatever I am opposing to the idea that something to work needs settings in two different places.
Another, still IMHO valid approach could have been putting it (still all together) in a dedicated level, like:
I agree that it’s only too confusing to have to configure one functionality in multiple places (VLANs is a good example of this lunacy).
Instead here’s my proposal:
/interface ethernet switch port
set ether2 mirroring=egress mirror-targets=ether3
set ether4 mirroring=ingress mirror-targets=ether3
set ether5 mirroring=both mirror-targets=ether3,ether6
Even more scalable as it easily allows to set-up several mirroring targets and even miroring to multiple target ports. Surely this is not supported by many switch chips, but in case some future switch chips will support multiple mirror targets/pairs/whatever, this would then allow to utilize feature to its fullest without another syntax change.
ROS would have to carefully check the validity of settings (and observe the switch chip limitations). E.g. it should not allow setting mirror pair (source, destination) where all involved ports are not controlled by same switch chip (on devices with multiple switch chips installed) … ditto for ports connected directly to CPU. But those rules could be simply baked into ROS and then it would be only up to proper error reporting in case that user entered invalid parameter combination.
And yes, I like your concept of mirroring=none|both|ingress|egress instead of directly setting bits for the table (yuck!) … where none would disable the mirroring altogether for that particular port.
Yep, your proposal is just fine, everything is in one place, and it would be even better if the settings would be moved from “main”
/interface ethernet switch port
to its own level:
/interface ethernet switch port mirroring
or
/interface ethernet switch port mirrors
apart from the discussion how the syntax could have been adopted less impacting, less changed, yet more flexible, i basically just did not find the 7.15-7.16rc4 info on the page i received as google result when searching for the obvious search terms.
Yep, rest assured it is not you fault, usually when searching on Google the first results are on the (old) wiki that often gives obsolete info, then, when you get to the right “help” site finding the relevant information you are looking for is often challenging.
The way the topics are organized in Mikrotik documentation ranges from extremely simple, logical and straightforward to completely senseless, but on average they seem to me more like if a smart, good willing, alien from Alpha Centauri was trying to explain the way the engine of his flying saucer works, the overall principles can often be understood but most of the details are either missing (or omitted/given as implied/obvious) and the whole stuff is somehow permeated by a logic that while similar to ours remains slightly alien.
It seems like a relatively large group of non-native English speaking programmers were co-authoring the documentation without an editor and/or sufficient coordination …
