One thing is for sure, posting on the forum will do zero for your request!
You can try making a ticket in the support system, that will at least make it end up on the desk of someone considering it.
Of course that does not mean it will be implemented, but at least there is a chance.
Even better is to go via a distributor with the use-case of your request. When they can sell 100000 routers after implementing this, it surely will be done.
(I know that it is not likely for this request, but looking at the recent changes lists for new releases we know that it works like this)
Read the above.
Posting here is useless, submit a support ticket or mail to sales@mikrotik.com
<< One thing is for sure, posting on the forum will do zero for your request! >>
.
the greek word forum and the related place, was intended once … AGAINST.
roman word : )
… I just admire the greeks … more : )
I never knew about GRETAP until I saw this thread
What advantages would it have? I know for instance that EoIP allows you to run any MTU you want as it will silently fragment packets (doesn’t care if you’ve set do-not-fragment in the IP layer) unlike say VXLAN or VPLS which still restricts you to the underlying transport MTU size
This in itself has been extremely useful for having a truly transparent ‘ethernet cable’ for testing as if I were onsite, where a different MTU could mess with results
Are there are drawbacks to GRETAP that might make EoIP still a more viable protocol in some instances? Can you run multiple instances with ID numbers?
The issue is that the protocol numbers are different, so when you have one MikroTik and one other brand router you cannot make a tunnel between them.
That could be solved when MikroTik add an option for the protocol number (or a selection between the two customary values).
Other than that, there is no advantage.
You sure about that? I just did a bit of reading up and unless the information 'im reading is wrong then both of the reasons I use EoIP are not supported with GRE (or GREtap) tunnels
- You can’t use the same source/destination IP address to create multiple tunnels. So yes, that in itself is a huge advantage with EoIP if you only have a single accessible IP on each end
- GREtap encapsulates but doesn’t fragment/defragment packets. So you cannot carry a full 1518 byte or larger ethernet packet over the internet, you can with EoIP as it’ll just silently split and reassemble the packet for you
The “tunnel ID” is a standard feature of GRE tunnels, of which EoIP is a special case. Unfortunately the “IP over GRE” tunnels in RouterOS are missing this setting. It could be added and you could have multiple GRE tunnels between the same routers.
Fragmentation/re-assembly is just a standard feature of IP, which is the layer below GRE. You can even specify what should be done with the “don’t fragment” flag on IP level (i.e. will a IP with DF flag that gets encapsulated in GRE send that DF flag down into the encapsulation and thus fail to be fragmented and send an ICMP back, or will it be fragmented in the GRE encapsulation anyway).
nuh-uh. The beauty of EoIP is you can truly simulate an ethernet cable being plugged in, through the internet. If there is any mechanism that can detect MTU or any part of the encapsulation process, then its not a good protocol for true layer2 transportation if you don’t also own the underlying transit network
I don’t want ANYTHING above layer1 to have any awareness of the transport mechanism whatsoever, and EoIP is the perfect protocol for that. I use it predominantly for troubleshooting but also as a failover protocol when you simply need to throw a virtual ethernet cable between 2 points because the primary transit has failed (using 4G/5G routers in between, or literally any transport mechanism whatsoever). Sometimes that even means running EoIP on top of something like PPTP/L2TP/SSTP due to firewalls or w/e. Performance obviously suffers, but if you have a need to transparently send any and all traffic from 1 point to the other as if there was nothing in the way - that means zero restrictions, you could even run 9000 byte traffic across the IPv4 internet if you wish - then EoIP is phenomenal for that. And it seems GRETap is not a replacement for that functionality
Some issues will only show up when you are either there in person (a 7000km flight can be prohibitive for that purpose) - or you use an EoIP tunnel to simulate every part of the connection process, from plugging a cable in with first wireshark captures to initial discovery and DHCP through to proprietary discover mechanisms @ layer2. Simply throwing any and all traffic through it blindly and knowing it will arrive reliability (performance secondary) and not having to manipulate and stuff about with things like restricting MTU is the point of EoIP. GRETap is not a replacement for EoIP if it cannot do that and requires you to choke down traffic to fit into the lowest path MTU
It is all the same for EoIP and GREtap. The only difference is the GRE protocol type.
Of course EoIP is not the same as GRE for IP. But the headers used internally are the same, only a type field is different.
So you keep saying, but find me where GREtap can do packet fragmentation and defragmentation automatically and do it without involving the payload at all. As I can’t
If EoIP is the same as GREtap at the L4 level but the above is done in the software stack as part of the tunnel. Then it’s still providing tangible benefits and would make it incompatible with GREtap from other vendors