Hi,

I have a setup where a client board has a "failover" where a l2tp tunnel is 
established in order to route the clients public IPs.

The client has two possible connections that this l2tp tunnel is built through.

The client is a Mikrotik Board.
Lets call the primary connection A, with an IP of 1.1.1.1
The failover internet connection is B, with an IP of 2.2.2.2

Lets call the "other end" S, with an IP of 3.3.3.3

In a normal state, a tunnel is built between IP 1.1.1.1 and IP 3.3.3.3

Failure of connection A is detected using ping and if there is no traffic 
for about 60 seconds routing is modified so the default is connection B.

L2TP then establishes a tunnel between 2.2.2.2 and 3.3.3.3

When connection A comes up, routing is changed back to connection A and the 
tunnel then works between 1.1.1.1 and 3.3.3.3 again.

When the connection fails over from A to B, the connection takes 60 seconds 
to failover, as A must be detected as "dead" first.

When the connection fails back from B to A, the failback is immediate as A 
is already back up.

The problem comes in with the failback.

Openl2tp is happily taking to the client between IPs 2.2.2.2 and 3.3.3.3
Suddenly the traffic now comes from 1.1.1.1 arriving at openl2tp (3.3.3.3)
Because the tunnel never got torn down, openlt2p answers to 2.2.2.2 (instead 
of 1.1.1.1 where the traffic comes from).

Hope this makes sense.

Openl2tp should somehow "forget" about the tunnel, as the PPP never comes up 
inside the tunnel.  The fact that there is traffic with the correct tunnel 
ID, but wrong IP is probably keeping the tunnel up.


Any idea how openl2tp can "forget" this tunnel so it can be recreated by the 
Mikrotik client after timing out.

Interestingly enough xl2tp has exactly the same behaviour, talks back to the 
wrong IP, but the ppp session actually gets established with the 
"assymetric" routing.

Cheers,


-- 


Johan Meiring
Cape PC Services CC
Tel: (021) 883-8271
Fax: (021) 886-7782

--------------------
Before acting on this email or opening any attachments
you should read Cape PC Service's email disclaimer at:

http://www.pcservices.co.za/disclaimer.html


------------------------------------------------------------------------------
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
_______________________________________________
Openl2tp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openl2tp-users

Reply via email to