I have a RB150 (ROS 3.0) and an x86 (ROS 3.0), with an L2TP tunnel between them. I have the MRRU setting on both ends set to 1614, and I’m bridging across the tunnel. All traffic passes fine for a certain period of time, after which the tunnel stops passing all traffic, although it remains up at both ends.
If I do not use MRRU, I am able to pass traffic (less than a certain packet size, of course) through the bridge indefinitely, however this is not suitable for bridging the traffic I had hoped (ethernet for concentrated Hotspot gateway).
This bug has existing since at least RC5 (submitted to Mikrotik support with suppouts at the time).
this is happening to me too. the bridge that the hotspot is sitting on seems to stop responding. I get the initial http redirect to the login page, but since the response packet is bigger than 1460 MTU it never makes it back thru the l2tp bridged tunnel. It works for a few hours and then quits. Reboot and it works fine for a few more hours.
okay - it’s time to move forward with this and I need to get a solution. It may be that I have to go back to using EoIP tunnels until MT can figure out whats broken (or a workaround).
Basically 1500 byte packets are NOT traversing the tunnel, even though MRRU is 1500. A client connects, hits the hotspot authentication, the client performs the redirect to the login page, but since the login page is > 1500 bytes it never loads. I packet sniff and can see everything else working perfectly. Please help : ) It seems that it starts working if I perform a reboot on both routers but it only lasts a few minutes.
-
The client is assigned an IP from DHCP on the distant router, so the bridge is working.
-
The client can perform a HTTP GET on port 80 and get the redirect to the hotspot login, so the hotspot is working. I can see this with the packet sniffer.
-
The client hangs while loading the login page because its payload > 1500 bytes. I can see this with a packet sniffer. 1500 byte packet is sent but the remote router never receives it.
-
A reboot of both routers, without any changes, fixes it for up to about 10 - 20 minutes.
-
If I redo this configuration and simply insert an EoIP tunnel in between then things work perfectly. I am trying to avoid doing this by using the new feature of 3.x and PPP bridges.
Thx,
Sam
Sam
okay - I think MT support helped me figure this one out. MRRU needs to be 1518 because the bridge is transporting ethernet frames and not just IP… so 1500 + 18 byte header. It was suggested to make it 1600 MRRU just for safety down the road.
How very interesting! I discovered this same problem with MRRU combined with PPPoE this week, and submitted a request to support concerning this problem myself. I have not yet heard back from them.
What I discovered was that, with MRRU enabled on a PPP interface, the more data you end up moving, the higher the likelihood that the tunnel will stop working. If I enable MRRU on a PPPoE server and client (say, two RouterBoards directly connected together with ethernet), and then conduct a bandwidth-test over that tunnel from the client to the server, with it running full-bore, the tunnel will cease to move traffic within about 30-45 seconds. I don’t have to reboot to get the tunnel working again; all I have to do is disable and re-enable the PPPoE client interface to force it to reconnect, and I’m able to move traffic across the tunnel again. This problem only occurs when I have MRRU enabled.
changeip, that is an interesting suggestion that you received from support, and I will give it a try…however, it seems somewhat strange to me that you would be required to use a value of 1518 or above. I found that the MTU of the PPPoE client interface matched whatever value I specified for MRRU, which means that if I were to set MRRU to 1518, I should expect the MTU of the client interface to also show me 1518. However, the maximum transmission unit size for ethernet frames doesn’t generally include the ethernet header overhead. Having to set MRRU to 1518 (and thus the client interfaces’ MTUs to 1518) seems confusing, and inconsistent with the way that MTU values are used everywhere else.
– Nathan
Support has confirmed with me that this is a bug and that they will be working on a fix.
I’m guessing the MRRU code is shared between all PPP tunnel types (PPPoE/PPTP/L2TP) and so the fix will apply to all of them.
– Nathan