Multiple IP from same ISP

Jotne · Thu Sep 20, 2018 9:39 am

I have found a working solution (at least from ISP)

If you have an ISP that gives you more than one IP using DHCP you would like to use them all.
The VRRP solution mention here viewtopic.php?f=2&t=93517&p=687533#p466594 I was not able to get to work.

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:

Multiple outside IP.jpg

And the resulting DHCP information:

MiltipleIP_DHCP.jpg

And the configuration:

# sep/20/2018 07:51:52 by RouterOS 6.43.1
#
# model = CRS125-24G-1S-2HnD

/interface bridge
add fast-forward=no name=Bridge_Outside
add fast-forward=no name=Bridge_P10
add fast-forward=no name=Bridge_P11
add fast-forward=no name=Bridge_P12
/interface bridge port
add bridge=Bridge_Outside interface=ether1
add bridge=Bridge_Outside interface=ether2
add bridge=Bridge_Outside interface=ether3
add bridge=Bridge_Outside interface=ether4
add bridge=Bridge_P10 interface=ether10
add bridge=Bridge_P11 interface=ether11
add bridge=Bridge_P12 interface=ether12
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=Bridge_P10
add dhcp-options=hostname,clientid disabled=no interface=Bridge_P11
add dhcp-options=hostname,clientid disabled=no interface=Bridge_P12

Edit:
It seems that you can even set on DHCP client on the Bridge_Outside to get 4 IP with this solution.

sindy · Thu Sep 20, 2018 10:55 am

Can you post the VRRP configuration which was "red"? Somehow I think that spending physical ports on issues like this should be the very last resort.

mkx · Thu Sep 20, 2018 12:04 pm

@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?

Jotne · Thu Sep 20, 2018 12:23 pm

The vrrp interface is red/Invalid:

[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

Cut and past config from here:
viewtopic.php?f=2&t=93517#p466594
If ether1 is correct and UP

Jotne · Thu Sep 20, 2018 12:27 pm

@mkx

That should work, will test it out.

sindy · Thu Sep 20, 2018 1:01 pm

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.

Jotne · Thu Sep 20, 2018 1:21 pm

Then it worked

So by just adding:

/ip address
add address=127.0.0.10 interface=ether1 network=127.0.0.10

All goes up.

Thanks

Jotne · Thu Sep 20, 2018 2:42 pm

Found another way.

By setting up a DHCP Client to the ether1, it will get one IP and brings up the VRRP interface.

So just add:

/ip dhcp-client
add  dhcp-options=hostname,clientid disabled=no  interface=ether1

sindy · Thu Sep 20, 2018 3:18 pm

No, adding an IP address on ether1 is not enough.

What has happened:
1) 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"
2) 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
3) vrrp1 now sends "I'm here and I support 127.0.0.10,100.100.100.100"
4) 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.

Sob · Thu Sep 20, 2018 5:51 pm

There is a potential of a conflict if VRRP eventually runs at the ISP end of your WAN as well, ...

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.

But attaching one of the dhcp clients directly to ether1 is a good idea as you need one vrrp interface less.

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.

Multiple IP from same ISP

Multiple IP from same ISP

Re: Multiple IP form same ISP

Re: Multiple IP form same ISP

Re: Multiple IP form same ISP

Re: Multiple IP from same ISP

Re: Multiple IP from same ISP

Re: Multiple IP from same ISP

Re: Multiple IP from same ISP

Re: Multiple IP from same ISP

Re: Multiple IP from same ISP

Who is online