Feature request: Virtual Interface

virtual interface on ether interface (like vlan, but without tag)

Wouldn’t that be the interface itself?
Or do you really need an interface that drops any other vlan for use in bridges? Here a bridge filter can compensate for this.
Otherwise it is only cosmetic.

Currently, Mikrotik can not elementary thing - connect the two bridges. (http://forum.mikrotik.com/t/how-to-connect-two-bridges/97236/1)
I could not believe it, but Mikrotik really can not do it!

With Virtual interface without tagging it can be done.

Also, it can be done with vlan interfaces and vlan tag management, but Mikrotik do not have any manual vlan tag management! (http://forum.mikrotik.com/t/bridge-and-vlan-tag-management/97076/1)
I have already create post with feature request (http://forum.mikrotik.com/t/feature-request-switch-like-vlan-functionality-for-rb-w-o-switch-chip/97142/1)

Making a bridge between other two bridges is the same like moving all the ports from those two bridges to the third one and removing the other two. There is no need to have a hyperbridge.

No, you do not understand.
Each bridge has a unique MAC-address! And we can assign an IP address to the bridge!
Now do you understand?

You can assign as many IP addresses to any single interface as you wish.

I’m not sure how it would help with building a superbridge, so I won’t comment on that. :wink:

But on original topic, virtual interface with own MAC address could be useful, e.g. when you want to get more than one address from DHCP server (without ugly hacks), perhaps even for something else.

omg. you really do not see the difference between the two interfaces with the unique ip addresses, and one interface with two ip addresses?

As long as these two interfaces are in the same broadcast domain (i.e. bridged together)- no, I don’t see much difference.
Are you willing to explain what you think the difference is?

Well. I would surely appreciate the possibility to have multiple mac addresses on whatever interface and the ability to run multiple dhcp clients on the interface with mac address as distinguisher. And the same everywhere where applicable.

Can you provide any real-life example where this is necessary, please? Highly curious.

Some isps are providing multiple ip addresses but only via dhcp. You cannot easily get them.

If you “hyper”-bridge the bridges you have only one admin mac.

Is like you put one dhcp-client for each ether1~5 port and bridge it all together…

Just chiming in with support for this feature. My ISP assigns IPs via DHCP and requires a different MAC address for each reservation.
I’ve jimmied something up with a virtual router Bridge NATing to rewrite MAC addresses, etc. but it’s horrible.
The ability to add virtual interfaces with a unique MAC addresses, which could I could then attach a DHCP clients to would allow me to do this cleanly.

I have the same issue with UnityMedia, providing me with internet via cable (5 fixed IP addresses). They do not give you a /28, but rather assign the IPs via DHCP to specified MAC Addresses.

Solved it by plugging a dumb L2 Switch between the cable modem and my RB1100AHx2, using ETH1-5 on the RB side.

Now, I don’t mind the “lost” ports much, as I just use another 4 ports (secondary ISP, DMZ, Prod.LAN, Guest.LAN). Still… being able to assign virtual interfaces to a single ETH would save - in my case - 4 more ETH Ports.

Yeah, I considered using 5 ports for my 5 “static” IP addresses as well… I picked the virtual router method because avoiding an extra L2 switch, cable mess, port usage etc. was worth it for me.
Either option sucks though, vifs would solve it elegantly. Here’s to hoping we get this feature some day!

Why not just request multiple mac addresses per interface as general feature and then enable to have multiple dhcp clients per each mac of such interfaces?

That might also be a possibility, but virtual interfaces is how I’ve seen it done elsewhere.

As a naive user, I think having multiple MACs per interface would introduce many technical problems as it seems to me to be a non-standard way of doing it. I assume this would be an engineering decision by someone much more qualified than me.

True. This would be a good feature anyway.

This is a brilliant feature request.

Make sure to email it through to support.