Setting up 1Gbps MGMT port on CRS317 and CCR2004 for out of band management

I’m in the process of getting the configuration for my CRS317 and CCR2004 ironed out. After a LOT of Googling and reading, I’ve come up short on how to configure the 1G MGMT port on both devices for out of band management via the CLI.

The OOB MGMT configuration I need is super simple. No VLAN, just an access port with a static IP address and gateway from which I can fully manage the switch via SSH, winbox, etc.

I can’t find any wiki info or posts that have pointed me in the right direction. So I’d love some help on this topic. Thanks!

In ROS, every interface (ethernet, SFP, wireless, tunel endpoints, …) can be used either standalone or as bridge port. Management interface on CRS317 will appear as ether1 and you can set up L3 settings for management lan directly on ether1. I guess you’ll want SFP+ ports (appearing as sfp-sfpplusN) as switched ports (possibly with VLANs), so you’ll create a bridge and add all sfp-sfpplus interfaces to it. You’ll also configure VLANs on bridge ports as needed. You won’t, however, set up any L3 config neither on bridge nor on sfp-sfpplus interfaces.

Ok, that makes sense. So to setup the management interface on the CRS317 would I do something like:

/ip address
add address=10.13.2.13/24 interface=ether1 network=10.13.2.0
/ip route add distance=1 gateway=10.13.2.1
/ip dns
set servers=10.13.2.200,10.13.2.201

For the CCR2004 router:
Question: Does setting the route/dns here, set it globally for any bridges that I create? Or would I need another route statement after I setup a bridge and add ports?

If you don’t go into some advanced stuff, then ROS will route through interfaces with appropriate IP address set. E.g. if you have bridge1 with sfp-sfpplus1,sfp-sfpplus2 and sfp-sfpplus3, bridge2 with sfp-sfpplus4,sfp-sfpplus5 and sfp-sfpplus6 and ether1 (for OOB management), then you will probably have configuration something like

/interface bridge
add admin-mac=<some localy administered MAC here> auto-mac=no name=bridge1
add admin-mac=<another localy administered MAC here> auto-mac=no name=bridge2
/interface bridge port
add bridge=bridge1 interface=sfpsfpplus1
add bridge=bridge1 interface=sfpsfpplus2
add bridge=bridge1 interface=sfpsfpplus3
add bridge=bridge2 interface=sfpsfpplus4
add bridge=bridge2 interface=sfpsfpplus5
add bridge=bridge2 interface=sfpsfpplus6

/ip address
add interface=bridge1 address=10.1.2.3/24
add interface=bridge2 address=10.2.3.4/24
add interface=ether1 address=10.13.2.1/24
/ip route
add gateway=<default router IP address here>

/ip dns
set servers=10.13.2.200,10.13.2.201

This informs router that it’s got 10.1.2.0/24 subnet directly attached to brdige1 (which is composed of SFP+ ports 1-3 … so it bridges traffic between these ports without considering L3), then it’s got 10.2.3.0/24 subnet directly attached to bridge2 (composed of SFP+ ports 4-6) and it’s got 10.13.2.0/24 subnet directly attached to ether1. When it receives an IP packet with destination address in one of these subnets, it’ll use appropriate interface (bridge1, bridge2 or ether1) to transmit the packet. When the destination IP address is not in one of these subnets, it’ll use appropriate gateway. In example above it’s only a single gateway defined and without destination subnet set it’s implicitly using 0.0.0.0/0 (a.k.a. default). If there were multiple gateways defined, it would use gateway with the longest subnet mask defined that matches destination address of a packet.
And this routing table will be “global” for entire router (i.e. all L3 interfaces).

The /ip dns settings are unrelated: ROS has (a simple) relaying DNS server built in and the settings simply configure upstream DNS servers to use. The built-in DNS server is not a full-featured recursive resolver (which would be able to resolve query starting from top-level servers), it needs so called “forwarders”. Whenever router needs to resolve something (or receives request from clients when allow-remote-requests=yes), it will contact one of configured upstream DNS servers … and will use the usual routing decision logic. So in case of CRS configuration, CRS will use one of 10.13.2.200, 10.13.2.201 DNS servers and will use default gateway as immediate next hop. Router at 10.13.2.1 will route IP packets according to its own routing configuration.
These settings don’t affect packets being outed - e.g. if a LAN host tries to contact DNS server at 8.8.8.8, router will not redirect those packets just because it’s got DNS server addresses set.

If it needs a separate default route and you can’t use NAT or other rules for OOB to ‘trick’ it - then you’ll need to use VRFs

Keep in mind that management services DO NOT listen in VRF’s - so you’ll need to make the ‘main’ route table your management one, and create a separate vrf for normal/customer traffic OR;
Use complicated Mangle Rules to help manage the traffic in and out so it still works.

The ‘management’ port isn’t really a management port - it is just another router port for you to do as you please.

Thank you both for the replies. I’m brand new to Mikrotik, and still trying to process all the information and get a working CRS317 and CCR2004 config on paper. I have a network diagram here, that should help explain what I’m trying to do with the 1Gbps “management” interfaces. Basically I want an OOB method to reach the CCR2004 and CRS317 switches, so the remainder of the ports are free for production connectivity.

https://imgur.com/a/UkaUBdl

Maybe I’m making this too complicated with the “dedicated” management uplinks on the CRS317 and CCR2004? If these “MGMT” ports are just like any other port on the device, and I need to do trickery with routes, NAT, VRF, etc. then I think the juice isn’t worth the squeeze, so to speak. Would the “inline” method for management be to just set an IP on the bridge itself?

I’m trying to keep the config as simple as possible, yet be fairly robust. TIA!

What @joegoldman wrote, is advanced stuff. According to the network topology chart you don’t need any advanced stuff (you only have one upstream gateway from CCR2004 so no VRFs or other bells and whistles).