Community discussions

MikroTik App
 
PhoenixAura
just joined
Topic Author
Posts: 2
Joined: Fri Nov 11, 2022 5:26 am

Cisco-equivalent of "Interface range"

Fri Nov 11, 2022 6:12 am

Good day everyone,

Just signed up, and this is my first post.

We have been a Cisco and Cisco-equivalent shop for years (Cisco SG/CBS lines, Nexus, Dell PowerConnect and N-Series, etc).

Given global supply chain issues, we have had to pivot a bit in order to ensure we can complete projects in a timely fashion with gear that is equally stable and reliable.

I have been a Mikrotik fan for years, especially as it applies to the niche-space/ special-use; however, I have yet to fully engage and go full tilt with in in production environments. With the current situation, and the fact that Mikrotik has made significant in-roads over past several years (48-port PoE edge switching, hardware offload at both L2 and now L3, cost-effective 10 GB network at the core layer, including VRRP), we are finally considering it as a viable alternative.

Of course, given the completely different CLI (we have no intention of relying upon the Web or GUI options), it's going to take a few weeks for us to become completely acclimated. Already, we have made significant headway, practicing building out Mikrotik-equivalent builds to our standard Cisco builds and standards that we commonly roll out in production.

The networking knowledge is there, so the challenge, thankfully, it limited mostly to conquering the command-side of things.

Anyway, with that said, we have hit a couple of really inconvenient snags that perhaps some of you gurus can help us address. They are as follows:

1. Is there a means of efficiently deploying complex VLAN configuring to multiple port ranges? I am sure most of you are familiar with the "Interface range" command syntax in the Cisco world, so we are looking for something that can be comparable. Before answering, please consider that we have already embarked on using the "[find where ...]" statements and ":for i from=0 to=10 do" one-liners where it makes sense. For instance, using the ":for i" method works well when applying a new PVID to multiple ports in the interface/bridge/ports context. However, when it comes to assigning multiple untagged and tagged VLANs to various port ranges,, we have not yet been able to figure out a Cisco-equivalent. This is partly because with VLANs in the interface/bridge/vlans context, the interfaces need to be specified in comma-delimited fashion after the "tagged=" and "untagged=" options. My hope is that we are simply missing something, and that one of you has already figured out a quick and easy way to accomplish this.

2. In most cases, our deployments are customer-specific, and we do not require segmenting or routing multiple customer environments over the same hardware. However, I do like the idea of using vrf to create a sudo "out-of-band" dedicated management interface that is completely separate from the main bridge and only accessible via a special management network separate from the production customer environment(s). I have been able to create a vrf called "Mgmt", and a separate bridge called "Mgmt". I then add the appropriate port (i.e. ether49 on their 48-port model) to the Mgmt bridge. I realized this second bridge is CPU bound, not hardware offloaded, but it is dedicated only for management via a separate secure network. I then move all IP services off the 'Main' vrf over to the "Mgmt" vrf, create a separate "Mgmt" routing table, and bind it to the Mgmt vrf interface. Lastly, I create a separate default 0.0.0.0/0 route specifically for this vrf. Anyway, until now, I have NOT been able to get it to route properly --- I can access the Ip services when bound to the same broadcast domain, but the vrf is inaccessible across subnets. Furthermore, when configured in this fashion, I can no longer ping or run other IP tools from within RouterOS successfully (i.e. no route to host). I assume I am just missing something or incorrectly configuring a portion of it, but I have not been able to figure it out. I just want to confirm that what I am looking to do here is actually possible, which it seems to be, but I don't want to be kicking a dead horse so-to-speak. Of course, if I remove the Mgmt vrf, and move everything back to 'Main' including the IP services, management works across subnets and the Mikrotik appliance is able to access external resources (i.e. auto update, etc).

3. We normally deploy a combination of edge port, bpdu-protection, unknown unicast protection, broadcast protection, and loopback protection on all edge/workstation ports. Mikrotik seems to be able to accomplish most of what I am able to do on the Cisco-end... with the exception of a few items:
- On Cisco devices, I am able to setup an auto-recovery time-frame, where if a port is placed into an err-disable state due to say a loopback condition, the Cisco switch can be configured to auto-re-enable the port after say 25 mins, without requiring user intervention. This is not a deal breaker, but does Mikrotik have this capability (i.e. equivalent of err-disable recovery for bpdu protection, loopback protection, etc)?
- With respect to storm-control (unicast, broadcast, and multicast), am I able to setup the control on a percentage basis? For instance, on the Cisco appliances, I can set unicast storm control to 30% of the interface's capacity. Is there something similar on the Mikrotik side in terms of customizing when storm control will kick-in?

4. Seems like a stupid question, but I have not figured out yet how to easily check "active" ports from the cli? Someone on another forum provided a one-liner script that returns a value for checking individual interfaces, but this seems a bit ridiculous to me. If I want to get a complete view quickly in terms of what ports are currently active and in-use, I have had to thus far open the Web GUI to gain a clear picture. Please tell me I am missing something, and it's just a simple command to list all ports currently active from cli?


That's it for now.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cisco-equivalent of "Interface range"

Sun Nov 13, 2022 5:31 pm

1. ... when it comes to assigning multiple untagged and tagged VLANs to various port ranges ...
The result of [find] is a list, and so are the tagged and untagged items on /interface bridge vlan rows.

So something like /interface bridge vlan set [find where bridge=bridgeX vlan-ids=Y] tagged=[/interface find where name~"ether(10|12|15)"] untagged=[/interface find where name~"ether[23]"] should do the trick.

2. I do like the idea of using vrf to create a sudo "out-of-band" dedicated management interface that is completely separate from the main bridge and only accessible via a special management network separate from the production customer environment(s).
In RouterOS 6, VRF actually works only for transit traffic - the router itself listens in all VRFs. So to implement your idea, the management has to be in the "default VRF", and the customer transit traffic in other VRFs. But if the router provides services like DNS cache (proxy) for the customers, the results may not be satisfactory.

When pinging or tracerouting from RouterOS itself into a customer VRF, you have to specify the routing table to use.

In RouterOS 7, VRF is work in progress (some interface types do not support VRF, firewall rule matching on routing-mark was not working a few versions ago) so maybe the final result will be better but so far it is a bit worse than in RouterOS 6.

3. ... the Cisco switch can be configured to auto-re-enable the port after say 25 mins, without requiring user intervention. This is not a deal breaker, but does Mikrotik have this capability ... ?
Not directly, but many things can be accomplished using scheduled scripts.

3. With respect to storm-control (unicast, broadcast, and multicast), am I able to setup the control on a percentage basis?
To my knowledge, this is individual per device model - only some switch chips can limit ingress traffic.

4. Seems like a stupid question, but I have not figured out yet how to easily check "active" ports from the cli?
e.g. /interface print where !disabled and !running will give you a list of all ports that are administratively enabled (!disabled) but inactive (!running).
 
PhoenixAura
just joined
Topic Author
Posts: 2
Joined: Fri Nov 11, 2022 5:26 am

Re: Cisco-equivalent of "Interface range"

Tue Nov 15, 2022 10:11 am

So something like /interface bridge vlan set [find where bridge=bridgeX vlan-ids=Y] tagged=[/interface find where name~"ether(10|12|15)"] untagged=[/interface find where name~"ether[23]"] should do the trick.
Thank you for the response and your detailed answers. Some questions though:
So something like /interface bridge vlan set [find where bridge=bridgeX vlan-ids=Y] tagged=[/interface find where name~"ether(10|12|15)"] untagged=[/interface find where name~"ether[23]"] should do the trick.
This helps a bit, and much better than how I was originally doing it, but it is still cumbersome. For instance, if I want to add VLANs to interfaces 1 through 42, my search line for the interfaces is going to be: "[/interface find where name~"ether(1|2|3|...all the way to...|42)"]". Perhaps I am still missing something and you wouldn't mind providing a concrete example for the following: Add tagged VLANs 5, 10, 15, 20, and 25 and untagged vlan 1000 to interfaces 1 through 42. Show me the most efficient one-liner command capable of accomplishing this.

In RouterOS 6, VRF actually works only for transit traffic - the router itself listens in all VRFs. So to implement your idea, the management has to be in the "default VRF", and the customer transit traffic in other VRFs. But if the router provides services like DNS cache (proxy) for the customers, the results may not be satisfactory.

When pinging or tracerouting from RouterOS itself into a customer VRF, you have to specify the routing table to use.
Funny you mention this. I was on the verge of attempting exactly that --- I noticed that, since I am able to get the management to respond and operate correctly on the "main" or default vrf, I was thinking of creating a secondary one for all customer interfaces, instead of the way I was originally doing it... creating a custom secondary one for management. And, yes, appreciate the information with regard to ping and trace route --- I will verify syntax and ensure that I am using it under the correct route cable and/or vrf context. I assume that, when I was originally doing it, it was defaulting to the main vrf and default route table.

Not directly, but many things can be accomplished using scheduled scripts.
Fair enough. I definitely won't criticize RouterOS' flexibility, or capability, espeically if one is willing to put in the time. Definitely impressive. Still, it would be nice if some of the more "common" features, commands, and functionality that are pretty much standard across most of the mainstream enterprise-class switching gear was also "easily" accessible on the Mikrotik CRS line. When I say "easily", I mean without having to write complex customized find commands and/or custom scripts to accomplish relatively simple tasks. Again, with regard to the above interface range exmaple, I appreciate the fact that I will probably be able to accomplish the equivalent of "interface range" with a complex multi-find command, but it is shocking that Mikrotik wouldn't just build in the equivalent command-function in their OS given the commonality of it across all major competitors. Like, I am actually shocked that people weren't asking for this since the very first version of the OS.

To my knowledge, this is individual per device model - only some switch chips can limit ingress traffic.
No worries. I will need to read up to see if the CRS354 supports this.

/interface print where !disabled and !running will give you a list of all ports that are administratively enabled (!disabled) but inactive (!running).
Thanks. This is actually what I was using, but figured there was a built-in command and/or function that I was missing. This is good for quickly listing active interfaces, including their current connection characteristics (i.e. full-duplex, 1000 Mbps, active), similar to what is visible in the GUI. I prefer to avoid the GUI where possible, but this may be a specific case where using the Web GUI makes the most sense.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Cisco-equivalent of "Interface range"

Tue Nov 15, 2022 11:27 am

Perhaps I am still missing something and you wouldn't mind providing a concrete example for the following: Add tagged VLANs 5, 10, 15, 20, and 25 and untagged vlan 1000 to interfaces 1 through 42. Show me the most efficient one-liner command capable of accomplishing this.
Well, that largely depends on the pre-existing state. If you have a bunch of VLANs that are handled exactly the same (as in tagged/untagged/unused) on all ports of a given bridge, you can use a single configuration line for all of them, providing a list of those VLANs in the vlan-ids column/field. For the same bridge, each VLAN may be listed on at most one row of /interface bridge vlan.

As for specification of the interface range - regular expressions work with strings, not numbers, so the regexp in the find would have to say "^ether(1-9|[123][0-9]|4[012])\$". So for ranges, like 1-42, the Cisco approach is clearly easier; for sparse lists, the regexp one requires less typing (but unless you are fluent in regexp, it is not necessarily easier).

So the whole example, assuming that nothing has been configured yet, would be (not tested, errors possible):
/interface bridge vlan add bridge=bridge vlan-ids=5,10,15,20,25 tagged=[/interface find where name~"^ether(1-9|[123][0-9]|4[012])\$"]
:foreach iface in=[/interface find where name~"^ether(1-9|[123][0-9]|4[012])\$"] do={/interface bridge port add bridge=bridge interface=$iface pvid=1000}


If you want to modify the default configuration where all interfaces are member ports of the bridge with PVID 1 by moving ether1 to ether42 to VLAN 1000, you do not need the foreach:
/interface bridge port set [find where interface~"^ether(1-9|[123][0-9]|4[012])\$"] pvid=1000

I definitely won't criticize RouterOS' flexibility, or capability, espeically if one is willing to put in the time. Definitely impressive. Still, it would be nice if some of the more "common" features, commands, and functionality that are pretty much standard across most of the mainstream enterprise-class switching gear was also "easily" accessible on the Mikrotik CRS line.
You can criticize as much as you want, this is a forum, not an advertising site. In my personal opinion, with a limited budget, you have to prioritze, and there are loads of features that would be impossible or at least inefficient to be done using scripting. So I am glad that Mikrotik developers concentrate on those rather than on providing more convenience by adding parameters like autorecovery timeouts (and still get a fair amount of complaints for how long it takes them to get ROS7 features on par with ROS6 ones).

As for the CRS line in particular - one of the things that makes Mikrotik so great is that you don't need to spend time studying which features are available and which are not on a particular model. Except for the features that depend on switch chip type, everything else is available on all models and the only limitation are the hardware resources (CPU throughput and flash/RAM size).

It's dead simple - to be able to provide the Cisco set of features and the Cisco level of support, the vendor has to spend the Cisco expenses and therefore sell for the Cisco prices.

This is actually what I was using, but figured there was a built-in command and/or function that I was missing.
To get a continuously updating dashboard-like view on the command line, check the monitor command. Some bits of information (like negotiated link speed) are not available via print at all, so you may need monitor once to show them on CLI.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: Cisco-equivalent of "Interface range"

Tue Nov 15, 2022 11:31 am

When I say "easily", I mean without having to write complex customized find commands and/or custom scripts to accomplish relatively simple tasks. Again, with regard to the above interface range exmaple, I appreciate the fact that I will probably be able to accomplish the equivalent of "interface range" with a complex multi-find command, but it is shocking that Mikrotik wouldn't just build in the equivalent command-function in their OS given the commonality of it across all major competitors. Like, I am actually shocked that people weren't asking for this since the very first version of the OS.

I concur and suspect the reason for the MT mindset and the somewhat unconventional implementation originates from they grew up in a different era compared to other similar companies.

Anyhow, this might be accomplished by adding new command sets using RoS functions that simplify and extends the built-in functionality. We've solved this by setting up a common enterprise library for the Mikrotik line that mimics some of the ios functionality and other frequently performed tasks like the ones you mentioned.

EDIT:
Btw, there is one major drawback you should be aware of when it comes to building command line scripts and functions. In RoS there is no way to catch error messages and there is no uniq error number to check for when a command fails. Also, the log can sometimes be pretty hard to understand and analyze. Hopefully this will be fixed in v7 (someday...)

Some examples regarding conversion from ios to ros, in theses cases ospf and mpls.
https://stubarea51.net/2018/01/05/cisco-to-mikrotik-command-translation-ospf/
https://stubarea51.net/2018/05/03/cisco-to-mikrotik-mpls/
Last edited by Larsa on Tue Nov 15, 2022 8:08 pm, edited 1 time in total.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Cisco-equivalent of "Interface range"

Tue Nov 15, 2022 4:54 pm

When I first found RouterOS, I saw it (WinBox) as nice user friendly frontend for underlying Linux. A dream come true for me, because I liked what Linux can do, but even though I'm not against command line, it's too simple, lacks feedback and interactivity. It's great for some uses, but if I want to fiddle with single device, which I do most of the time, GUI is so much better. It's "WYSIWYG", self-documenting, I can see what's happening all the time. Add a firewall rule and immediatelly see how it interacts with with the rest, counters, drag it elsewhere, enable or disable it with one click, etc. Doing the same in command line would take me much longer and would be often very frustrating.

I'm not saying that everyone must see it the same way, clearly not, but I suspect that there are many users like myself and it is, or at least initially was the group that MikroTik wanted to make happy.

Edit: But I admit that some parts of GUI are not great, e.g. configuring bridge/switch on device with many ports could use some improvements.
 
User avatar
chechito
Forum Guru
Forum Guru
Posts: 2989
Joined: Sun Aug 24, 2014 3:14 am
Location: Bogota Colombia
Contact:

Re: Cisco-equivalent of "Interface range"

Tue Nov 15, 2022 6:47 pm

maybe a winbox feature to do the same modification on a group of elements like bridge ports in a single action will be nice

Who is online

Users browsing this forum: Ahrefs [Bot], dmitris, sadjoe and 103 guests