Community discussions

MikroTik App
 
rajo
newbie
Topic Author
Posts: 45
Joined: Tue Aug 16, 2011 11:12 pm

Please support terminating EoIP and IPIP tunnels on VRRP Int

Wed Nov 28, 2012 5:44 pm

Please add support for terminating EoIP and IPIP tunnels on a VRRP Interface. Currently, if I terminate a mix of EoIP and IPIP tunnels on a VRRP interface, only one of the EoIP tunnels will come up (after a long wait). The other tunnels will never come up. Only when I terminate the tunnels on the physical interface does everything work. Tested with 5.22 on RB400 series

I need to be able to make such termination for failover purposes

Thanks
 
robertpenz
Member Candidate
Member Candidate
Posts: 104
Joined: Mon Oct 10, 2011 8:41 am

Re: Please support terminating EoIP and IPIP tunnels on VRRP

Fri Nov 30, 2012 5:34 pm

Why not make 2 ipip tunnels and run ospf over it? I'm running ipsec encrypted ipip tunnels with ospf for a long time without problems .
 
rajo
newbie
Topic Author
Posts: 45
Joined: Tue Aug 16, 2011 11:12 pm

Re: Please support terminating EoIP and IPIP tunnels on VRRP

Fri Nov 30, 2012 5:58 pm

Why not make 2 ipip tunnels and run ospf over it? I'm running ipsec encrypted ipip tunnels with ospf for a long time without problems .
I'm referring to terminating the tunnels on a VRRP interface as opposed to only the physical interface, irrespective of tunneling method used.

I need this because a /29 subnet terminates on the Internet-connected interface and only one of the IP addresses is used for tunnel termination while the others are used for various services. Not splitting up IP addresses between routers simplifies DNS and client-related configurations so that only a single IP address needs to be specified for services.

I cannot mix VRRP and non-VRRP terminations, because RouterOS provides no ability to specify the interface a route must take -- only the gateway can be specified. This limitation results in the VRRP interface being used as the default outbound interface when instead I need it to use the physical interface. If it were possible to specify both interface and gateway, I could work around this. If RouterOS is simply designating the lowest MAC address and IP address as default, I suppose I could try to force this by assigning the physical interface a bogus MAC address than is lower in number than anything VRRP would assign, but this makes things needlessly messy and difficult track -- increasing the possibility for future mistakes and network breakages.

Ultimately RouterOS being able to properly handle input chain traffic to a VRRP interface is the simpler and more foolproof solution.

Who is online

Users browsing this forum: jaclaz, jcjc81, NetworqAndy, pmcsill and 120 guests