eoip tunnel transmit loop error

RouterOS General
1

Hi all
I have a strange issue which I’d like to resolve. Our setup as follows:

  1. LTAP with Dual LTE (R11e-LTE) (ROS v6.45.1)
  2. PPTP tunnel towards a RouterBOARD 962UiGS-5HacT2HnT (ROS v6.44.3)
  3. EOIP tunnel built between CPE and CORE

Scenario:
When the primary LTE link fails, both the PPTP tunnel and the EOIP tunnel fails over as expected and rebuilds across the secondary link. A new PPTP tunnel is built and the ‘old’ tunnel is torn down almost immediately.

The issue:
Once the Primary link restores. A new PPTP tunnel is ‘rightfully’ built, while the ‘secondary’ PPTP tunnel remains connected on the core side and service works for a little while. Once the ‘secondary tunnel’ times out and the 'new tunnel built, a loop error is detected and the interface ‘downed’. Understandably this loop prevention is valid, however, using a single PPTP tunnel across different providers to the same CPE, we will never run into a situation with loops and must disable this.

Case:
We’ve tried disabling the EOIP Loop prevention altogether with no effect. Playing with the timers (Send interval and Disable time), however, the issue remains; interface down for 60 seconds). This has an impact on our client service as restoration can take up to 2 minutes to restore, which is not ideal for our client experience.

Question;

  • I’ve seen another topic where this could be a bug. Can this be the cause?
  • Are there other ways of disabling the loop prevention we might be missing, if so, where and how(I am thinking the parent interface)?
  • Is there another workaround perhaps?
  • Any other suggestions?

Thank you very much for the assistance
eopi2.png
eoip1.png

2

You haven’t posted your configuration so it is not clear whether you use BCP along with PPTP and, therefore, whether an L2 loop can occur in the PPTP case. If you use only L3 over PPTP, there is no loop guard because L3 loops are not that deadly as L2 ones thanks to the TTL field in IP header which the Fathers of Ethernet deemed useless in the L2 header.

It is also not fully clear to me whether there is a single EoIP tunnel or one through each WAN. In case of two EoIP tunnels, one still active and the other one already active, both bridged together at both ends, I can easily imagine a frame getting to the remote through one tunnel and back to local through the other one, and thus causing the loop guard to trigger. For a single EoIP tunnel whose transport packets may take one of two different L3 paths I cannot imagine anything else than a bug that should cause the loop guard to fire.

So provide the configuration exports of both ends and we may move further.

3

Thank you @sindy.

To confirm, a single PPTP tunnel acting as the L3 transport for a single EOIP tunnel in this case. No BCP in use.

your assumption I believe is correct regarding the “frame getting to the remote through one tunnel and back to local through the other one, and thus causing the loop guard to trigger”.

I’ll post configuration a little later when able to.