My solution is some dirty, and your ISP may auto block the port since he sees multiple mac on same port.
What I have done is to use a MT with many ports, eks CRS125.
On this device I make a group of port that will be the outside port.
One port connects from this group to ISP, the other ports connects back to other bridges in your switch.
I was not able to get it to work with the new VLAN aware Bridge solution, so I do get one Bridge for each IP.
For every extra IP you like to get, you need two extra ports on the router.
You need three Ethernet cable extra.
Connect port #2 to #10
Connect port #3 to #11
Connect port #4 to #12
The inside design is not describe here, but should be easy to setup.
Here is the design:
And the resulting DHCP information:
@Jotne, couldn’t you avoid creating bridges Bridge_P10, Bridge_P11 and Bridge_P12 by binding DHCP clients directly to ether ports 10,11 and 12 respectively?
[admin@MikroTik] /interface vrrp> print
Flags: X - disabled, I - invalid, R - running, M - master, B - backup
# NAME INTERFACE MAC-ADDRESS VRI PRI INTERVAL V V3..
0 I vrrp1 ether1 00:00:5E:00:01:01 1 100 1s 3 ipv4
1 I vrrp2 ether1 00:00:5E:00:01:02 2 100 1s 3 ipv4
2 I vrrp3 ether1 00:00:5E:00:01:03 3 100 1s 3 ipv4
[admin@MikroTik] /interface vrrp> /ip dhcp-client
[admin@MikroTik] /ip dhcp-client> print
Flags: X - disabled, I - invalid, D - dynamic
# INTERFACE USE-PEER-DNS ADD-DEFAULT-ROUTE STATUS ADDRESS
0 I vrrp1 no no
1 I vrrp2 no no
2 I vrrp3
According to what you’ve posted, I am afraid you have missed an important point in @Sob’s cookbook.
It is not enough that the carrier interface of the vrrp one (in your case, the ether1) has an IP address; it is mandatory that the vrrp interface itself also has one. The point is that the master advertisement message of the vrrp protocol (sorry if it is not the correct name according to the RFC) must contain a non-empty list of IP addresses the master supports, so if the list would be empty, the protocol is unable to come up, and so is the interface.
So you get a chicken-and-egg problem - the vrrp interface won’t go up until it gets an IP address, and the dhcp client won’t request and obtain an IP address until the interface to which it is attached is up. So you have to provide the egg by assigning a static address to the vrrp interface; luckily, the protocol implementation doesn’t care too much about tiny details so it is enough to assign a /32 address from the localhost range 127.0.0.0/1. As soon as you attach this address to the vrrp interface, it switches from Inactive to Backup mode and after the “wait for other master” timer expires, it switches over to Master mode so it is seen as Running by the /ip dhcp-client.
There is a potential of a conflict if VRRP eventually runs at the ISP end of your WAN as well, so set the /interface vrrp priority to a very low value (1 should be safe) and if one of the vrrp interfaces says it runs in the Backup mode for more than a couple of seconds, change its vrid because it means that there is a master on ISP side which runs with the same vrid and higher priority.
you’ve added 127.0.0.10/32 to vrrp1, so vrrp1 came up, sending “I’m here and I support 127.0.0.10”
the dhcp client on vrrp1 has seen vrrp1 to be up so it asked for an address and got, say, 100.100.100.100 from the server
vrrp1 now sends “I’m here and I support 127.0.0.10,100.100.100.100”
you’ve disabled/removed the 127.0.0.10/32 from vrrp1, but the 100.100.100.100 is still there, so vrrp1 can stay up as it can send “I’m here and I support 100.100.100.100”.
If you now reboot the router, or just disable and re-enable vrrp1, vrrp1 will lose the 100.100.100.100 and won’t come back up again until you pushstart it by adding a static IP address to it.
But attaching one of the dhcp clients directly to ether1 is a good idea as you need one vrrp interface less.
That’s one of the reasons why I’m not completely satisfied with this solution. Other being that it’s a hack, the whole VRRP part is unwanted extra, I’d rather have some statically configured virtual interface (Linux does have such thing, but RouterOS doesn’t; if you want proper solution, request this from MikroTik). I tried to at least filter outgoing VRRP packets, to prevent them from disrupting ISP’s network (it would make a “passive mode” for your VRRP), but they don’t seem to go through firewall.
That’s one more thing I’m not sure about. With regular VRRP config, you have your normal subnet on parent interface and addresses on VRRP interfaces as /32. If you don’t and use the same subnet as parent interface has, it sometimes doesn’t do good things, because it’s screws up routing. In this case, all addresses from DHCP will have the same subnet. I think it may not be a problem with single VRRP instance(s) (without another server), but it might be safer to use some random subnet on parent interface and only have DHCP on VRRP.
