Hello,

from my cable provider i could get 5 fixed ip addresses via DHCP - but i have to gave them the interface mac address upfront. The cisco cable modem is connected to ethernet port 1.
有办法吗create additonal Interfaces including DHCP clients with independent mac addresses but linked to the same physical Interface?

If there is a trick - please advidse

thank you,

frank

No good way to do this that I know.

There is a virtual-ethernet interface (vif), but its purpose is to allow communication between host router and virtualized router (either KVM on x86, or MetaROUTER on MIPSBE and single-core Freescale PowerPC), so not all boxes that run RouterOS will show you the option.

理论上,RouterOS设备上,l雷竞技有一口port for '/interface virtual-ethernet', you could create a bunch, just not use them with a virtual router, and bridge all of them together, or for router models that don't support this interface type, you could create a bunch of some other ethernet-like interface that is essentially virtual (e.g., EoIP) and bridge THOSE together. But all direct member interfaces of a bridge will assume the bridge's MAC address and not their own when transmitting frames, so you would still be stuck with a single MAC address. To transmit individual, unique MAC addresses, the bridge has to be forwarding frames, not originating/outputting frames, which still means multiple devices.

If you *are* using a router that has support for virtualization (KVM or MetaROUTER), the easiest way is to fire up one virtual router per IP address and dump them all in a bridge with your WAN port on the host. But that does seem a bit excessive to be running 4 or 5 virtual routers just to do this.

One final possibility that you might investigate is to do as suggested earlier and create a bunch of virtual ethernet-like interfaces and bridge them with the WAN port, and then use '/interface bridge nat' to construct L2 NAT rules to change the MAC address used on frame transmission. This might get complex rather quickly, though, and may even be impossible, since bridge NAT is basically stateless (no tracking of any kind) and the specific matchers that you might need to translate the MAC address on egress and ingress may not even exist.

-- Nathan

It seems that it's possible to misuse VRRP for that:

ros code

/interface vrrp add interface=ether1 name=vrrp1 vrid=1 add interface=ether1 name=vrrp2 vrid=2 add interface=ether1 name=vrrp3 vrid=3 # VRRP interface needs some static address to come up: /ip address add address=127.0.0.2/32 interface=vrrp1 network=127.0.0.2 add address=127.0.0.3/32 interface=vrrp2 network=127.0.0.3 add address=127.0.0.4/32 interface=vrrp3 network=127.0.0.4 /ip dhcp-client add default-route-distance=0 dhcp-options=hostname,clientid disabled=no \ interface=ether1 add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=\ vrrp1 use-peer-dns=no use-peer-ntp=no add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=\ vrrp2 use-peer-dns=no use-peer-ntp=no add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=\ vrrp3 use-peer-dns=no use-peer-ntp=no

It's definitely not a proper solution and I'm not sure about all possible side effects. But at the first sight, it works:

ros code

Flags: X - disabled, I - invalid, D - dynamic # ADDRESS NETWORK INTERFACE 0 127.0.0.2/32 127.0.0.2 vrrp1 1 127.0.0.3/32 127.0.0.3 vrrp2 2 127.0.0.4/32 127.0.0.4 vrrp3 3 D 192.168.80.50/24 192.168.80.0 ether1 4 D 192.168.80.48/24 192.168.80.0 vrrp2 5 D 192.168.80.47/24 192.168.80.0 vrrp3 6 D 192.168.80.49/24 192.168.80.0 vrrp1

It seems that it's possible to misuse VRRP for that: [snip]

Clever!!!

-- Nathan

For all whom want to create a similar infrastructure. I have done this succesfully with VRRP, but this is kind of an abuse and has some flaws. You can do it with MetaRouter (if available), but that is a bit heavy for the system and the IP's will virtually be on different routers.
The easiest (and best) way to do this is to put a switch in front (between modem and router) and offer a physical interface to every IP...

是的。的路由器,将开关在前面bingo! At least meanwhile until mikrotik come with some real and usable solution. Maybe abusing eoip tunnels to some other device and back could do the job also.

I did try vrrp config on an hAP lite.
Vrrp interface are all red (all config added)
Did try the same on hEX 750Gr3 interface did came up.
But all did get the same IP from my ISP.

It depends on what ISP does. The idea here was that ISP is willing to provide multiple addresses to devices directly connected to WAN. Is it your case? Multiple devices = multiple MAC addresses, VRRP can provide those. But it won't just work everywhere, when you're not supposed to get more than one address.

I did just try to connect ether1 to an Router with DHCP. So this router should give away IP to any who ask.
Stil red DHCP interfaces.
Tested on rb951g-2hnd and CRS-125-24G

It seems that it's possible to misuse VRRP for that:

ros code

/interface vrrp add interface=ether1 name=vrrp1 vrid=1 add interface=ether1 name=vrrp2 vrid=2 add interface=ether1 name=vrrp3 vrid=3 # VRRP interface needs some static address to come up: /ip address add address=127.0.0.2/32 interface=vrrp1 network=127.0.0.2 add address=127.0.0.3/32 interface=vrrp2 network=127.0.0.3 add address=127.0.0.4/32 interface=vrrp3 network=127.0.0.4 /ip dhcp-client add default-route-distance=0 dhcp-options=hostname,clientid disabled=no \ interface=ether1 add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=\ vrrp1 use-peer-dns=no use-peer-ntp=no add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=\ vrrp2 use-peer-dns=no use-peer-ntp=no add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=\ vrrp3 use-peer-dns=no use-peer-ntp=no

It's definitely not a proper solution and I'm not sure about all possible side effects. But at the first sight, it works:

ros code

Flags: X - disabled, I - invalid, D - dynamic # ADDRESS NETWORK INTERFACE 0 127.0.0.2/32 127.0.0.2 vrrp1 1 127.0.0.3/32 127.0.0.3 vrrp2 2 127.0.0.4/32 127.0.0.4 vrrp3 3 D 192.168.80.50/24 192.168.80.0 ether1 4 D 192.168.80.48/24 192.168.80.0 vrrp2 5 D 192.168.80.47/24 192.168.80.0 vrrp3 6 D 192.168.80.49/24 192.168.80.0 vrrp1

Hi SOB, i tried this configuration, but the traffic not passing from LANs . I tried mark the connections and used VRF too, but without succes!
Is there any other way similar to pseudo ethernet to use in this case? Do you know if Mikrotik staff plan to support it in ROS v7?

I think it still works, at least my very quick test suggests so. But it's just the basic part, to get more MAC addresses and then more IP adddresses from them. The rest depends on what else you do with it, and there are many way in RouterOS how to create configs that don't work.

And since you brought it up, one small update for the original idea. I'd rather use IPv6 mode for VRRP interface. One advantage is that it doesn't need any extra addresses, because there are always link-local ones. And VRRP doesn't mix IPv4 and IPv6 on protocol level, so if you add the other protocol address on VRRP interface, it's strictly local-to-router thing and can't mess something up.

About proper way, I'm just regular user with no special relation with MikroTik, so I don't know any more than you do. I know I was looking it up and Linux definitely has some kind of virtual ethernet interfaces. I think even the kernel used in RouterOS v6 has some basic support. But I guess that demand for this feature is probably not very high, so who knows when or if we'll see it in RouterOS.

Thank you SOB for your comprehensive answer!

Hi,

Great hint. I could also go as far as to obtain a secondary IP address. However I am getting timeouts if I try to ping for instance:
I don't want to add a default route, but I would like to route certain IPs over this secondary xx.xx.xx.xx IP. However as of now it seemingly times out in all cases. What else is needed to bring this up properly?

It seems that it's possible to misuse VRRP for that:

ros code

/interface vrrp add interface=ether1 name=vrrp1 vrid=1 add interface=ether1 name=vrrp2 vrid=2 add interface=ether1 name=vrrp3 vrid=3 # VRRP interface needs some static address to come up: /ip address add address=127.0.0.2/32 interface=vrrp1 network=127.0.0.2 add address=127.0.0.3/32 interface=vrrp2 network=127.0.0.3 add address=127.0.0.4/32 interface=vrrp3 network=127.0.0.4 /ip dhcp-client add default-route-distance=0 dhcp-options=hostname,clientid disabled=no \ interface=ether1 add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=\ vrrp1 use-peer-dns=no use-peer-ntp=no add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=\ vrrp2 use-peer-dns=no use-peer-ntp=no add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=\ vrrp3 use-peer-dns=no use-peer-ntp=no

It's definitely not a proper solution and I'm not sure about all possible side effects. But at the first sight, it works:

ros code

Flags: X - disabled, I - invalid, D - dynamic # ADDRESS NETWORK INTERFACE 0 127.0.0.2/32 127.0.0.2 vrrp1 1 127.0.0.3/32 127.0.0.3 vrrp2 2 127.0.0.4/32 127.0.0.4 vrrp3 3 D 192.168.80.50/24 192.168.80.0 ether1 4 D 192.168.80.48/24 192.168.80.0 vrrp2 5 D 192.168.80.47/24 192.168.80.0 vrrp3 6 D 192.168.80.49/24 192.168.80.0 vrrp1

This worked flawlessly.

Had to restart my ISP gateway in order to get it to give out IPv4, but on ROS 7 this is working perfectly. Also had to add the VRRP to the WAN interface list so my firewall didn't block.

For IPv6 I added them into ND and like magic they got IPv6.

Only question I have is do I need to add default routes for the VRRP DHCPv6 clients? It seems to be working without, I assume using the default route from my Ether1's DHCPv6 client?

No, you don't need default routes for other DHCPv6 clients. In fact, no DHCPv6 client should add route, it should come from RA, but if it works, you can keep it as you have it now (plus getting gateway from RA is currently broken in v7 anyway).

No, you don't need default routes for other DHCPv6 clients. In fact, no DHCPv6 client should add route, it should come from RA, but if it works, you can keep it as you have it now (plus getting gateway from RA is currently broken in v7 anyway).

Awesome, thank you again. Seriously you were the only person that had a solution on MikroTik.

Really appreciate your time, if you have a crypto wallet I'd happily donate to you a cup of coffee.

It's fine, just enjoy. And hope for some future proper support.