I’ve had some basic experience with using the dhcp-client as well as getting a static IP from my ISP, but I’m looking to combine the two and I’ve reached the limit of my knowledge:
My ISP gives me a static IP and several additional dynamic IPs, it can’t be as simple as enabling /ip/dhcp-client on ether1-gateway as well as setting the static IP, and then manually setting up the routes so that one internal subnet goes out the static IP and another goes out the dynamic IP, can it?
I’m anticipating that the the problem here is that the static route and the dhcp client would both be on ether1-gateway, or am I overthinking that?
The problem with dynamic IP addresses, when handed out using DHCP protocol, is that these are most often linked to client’s identity (which is almost always reflecting MAC address). So you can’t simply run multiple DHCP clients off same ethernet interface as they will all use same MAC address and DHCP server will hand out the very same IP address eachtime. There are some tricks to allow ROS device to use multiple MAC addresses when sending traffic out of same ethernet interface. Personally I never had a need for such setup, so somebody else will have to describe how to achieve this.
It is possible to use one dynamic IP address and a static one on the same interface. Routing doesn’t really depend on IP address on interface, so you might be fine if you only use the routing set up for static IP address (if dynamic IP address is in the same WAN subnet as static one) … so you’d have to confiugre DHCP client not to add default route (add-default-route=no). If static IP address and dynamic IP address are not in the same subnet (and thus imly use of different upstream gateway), then you’ll probably have to play with different routing tables and route marking.
I guess that more normal way of using those extra IP addresses would be if multiple devices connected to ISP’s CPE (eitehr directly or via a WAN switch). Those devices would clearly use different MAC addresses and they’d get different WAN IP addresses. You can use your router instead of the mentioned switch and configure it so that it would still use firewall rules to control the traffic … transparrently, other WAN facing devices would not be aware.
There are some tricks to allow ROS device to use multiple MAC addresses when sending traffic out of same ethernet interface.
There is no need for the VRRP trick anymore in the latest ROS versions. Now that we have the new MacVlan : https://help.mikrotik.com/docs/display/ROS/MACVLAN
The intention of MacVlan is to have multiple MAC adresses on the same ethernet interface. (The idea comes from connecting to Docker containers, but MT has it set for multiple MAC addresses on one ethernet interface as such.)
Otherwise having one DHCP client IP, and multiple local IP addresses in the same subnet , all on the same ethernet interface, does not require any special setting.
Only the IP addresses must be different. (avoid using the “static” IP address set in the DHCP server, as local IP address, or the lease will fail (address already in use))
I use the “distance” in the manual routes and (“Advanced → default route distance”) in the DHCP client , to set which one is preferred, whenever a lease is active.
Thank you both, very helpful!
It seems like the macvlan is basically the same thing as linux virtual interfaces (e.g. eth0:0), is that accurate?
OK thx for the answer.
No experience with Linux virtual interfaces. (They do not need a physical master ??)
VRRP, MACVlan, Virtual (WLAN interface), wifi (slave) are all virtual interfaces that use the master interface connection in RouterOS, but have their own MAC address.
I would not have called it MACVlan, but something else. However VETH name is already taken by Docker.
And “MACVlan” name seems to come from Docker, but with a different purpose.
MACvlan has no specific relation to tagged VLAN.
Introduction to MacVLAN
In the IT industry, we define MacVLAN as a specific kind of driver with built-in network driver edition and offers several unique specifications. At first glance, MacVLAN is a very lightweight driver because rather than using any kind of Linux bridging or port mapping technology, it is mainly used to connect container interfaces directly with host interfaces. In general, containers are inscribed with routable IP addresses that exist on the subnet of the external network architecture.
The result of using routable IP addresses is that containers start to communicate directly with network resources that usually exist outside a Swarm cluster without any need to use NAT or port mapping techniques.