IP Packing seems not possible on GRE Tunnels. Seems strange as GRE is a level 2 tunnel and IP Packing should works with level 2 interfaces. It works on EoIP tunnels.
GRE is not proprietary and should be the prefered tunnel interface because it is statefull and Generic. (Seems that EoIP is statefull as well now in version 5.0).
Without IP packing, it is not possible to use GRE to tunnel packets over xDSL links because of MTU problems.
Why keeping two different level 2 tunnels ?
Would be simpler to drop EoIP support and correct IP packing for GRE.
At the same time, it would be nice if we could put a routing mark on GRE tunnels, so that we can easily route them through different gateways to a single destination.
Ok i thought that GRE was encapsulating Ethernet inside Router OS. (this is possible as well, changing the protocol field to 0x6558). Perhaps adding Ethernet GRE over IP mode inside router OS would be possible ?
To allow for GRE packet routing to different gateways, when more than one tunnel originate from the router to the same destination, it would be possible to define the routing field inside the GRE header (if adding a routing mark is not possible).
So that the router know wich gateway to use for it.
This routing field has been deprecated inside RFC 2784, but is still used by some RFC 1701 implementations.
Interoperation with RFC 1701 Compliant Implementations is defined inside RFC 2784. RFC 2890 talk about the key and sequence number optionnal fields.
Sample from RFC 1701 (completed by RFC 1702) :
Routing Information (variable)
The Routing Information field contains data which may be used in
routing this packet. The exact semantics of this field is defined in
other documents.
Forwarding of GRE packets
Normally, a system which is forwarding delivery layer packets will
not differentiate GRE packets from other packets in any way.
However, a GRE packet may be received by a system. In this case, the
system should use some delivery-specific means to determine that this
is a GRE packet. Once this is determined, the Key, Sequence Number
and Checksum fields if they contain valid information as indicated by
the corresponding flags may be checked. If the Routing Present bit
is set to 1, then the Address Family field should be checked to
determine the semantics and use of the SRE Length, SRE Offset and
Routing Information fields. The exact semantics for processing a SRE
for each Address Family is defined in other documents.
Once all SREs have been processed, then the source route is complete,
the GRE header should be removed, the payload’s TTL MUST be
decremented (if one exists) and the payload packet should be
forwarded as a normal packet. The exact forwarding method depends on
the Protocol Type field.
Unfortunately, it was awhile ago when I tried it. I believe it was later v3.x or early v4.x. Basically, when I enabled IP->Packer on an EoIP interface, the router would lock up, and I lost internet until a reboot. Also, I played with various options, but none seemed to work.
Is IP Packer supported on EoIP interfaces, or, what are all the interface types IP Packer is supported on?
FIPTech,
Thanks for the info. I figured it was supported, but may have been buggy. Also, by crashing I mean this EoIP tunnel was not my main internet, it was a tunnel across the internet, and I was connected through the LAN port to the router. The router locked up to where I couldn’t connect anymore from the LAN port when enabling Packing on the EoIP interface. Just wanted to clarify that a bit, after re-reading my post I thought it needed more clarity.
I ended up not using it, though, I was trying to enable it to test it out, and see the performance status, latency, etc.
Generally speaking it’s best to avoid using proprietary, undertested and young code.
IP packing is the perfect sample of undertested code. 95% of Mikrotik users even don’t know what is it.
This is one of the advantages of opensource : experts can watch inside and make the code stronger. It does avoid poor quality hided code.
If Linux was not opensource, Mikrotik would not be here. I think they should open a bit more their code to allow faster developpement and code sanity verifications.
Same kind of problems with IPsec inside Router OS: should be fully reliable, but can crash. I prefer to use a fully reliable PPTP or L2TP, even if MPPE128 is less stronger, than using an IPsec that nobody know why it is crashing. We don’t know what it is doing at crash time, can you imagine the consequances if it was forgetting to crypt an outgoing packet with bank account informations during crash ?
ip packing had some problems but they where solved for 4.x and 5.x later versions. It is rarely used, but test case with packing configured on ethernet interfaces passes.
I plan to use it in a test lab with IPsec and dynamic routing, for clients management VPNs. Without it, i can’t find a way to allow 1500 bytes tunneled packets on xDSL links. (except using PPP with MRRU).
Would be interesting to have IP packing on IP in IP and GRE tunnels.