Reply
Highlighted
Emerging Member
Posts: 58
Registered: ‎04-02-2014
Kudos: 8
Solutions: 1

Dual Wan with sticky routing?

As noted before, I have a dual-wan setup. One issue I've run into is that IP based validation for service logins (for example secure.nccsoft.com) doesn't work since my IP address randomly changes. I fixed it for now by adding an override for HTTPS that uses one primary WAN and one fallback WAN.


This works but isn't optimal. What I'd prefer to do would be to have connection stickyness so subsequent requests to the same host, within a reasonable timeframe, uses the same external interface.

 

Is this a possible configuration option using the current LBS system?

Previous Employee
Posts: 13,551
Registered: ‎06-10-2011
Kudos: 5429
Solutions: 1656
Contributions: 2

Re: Dual Wan with sticky routing?

That is not supported in the current implementation, but perhaps it may be possible to add using the "recent" match module. For now the static override may still be needed.

Veteran Member
Posts: 5,050
Registered: ‎03-12-2011
Kudos: 2495
Solutions: 120

Re: Dual Wan with sticky routing?

[ Edited ]

Another issue I've found is with peer to peer gaming services (think xboxes) breaaking hard if a connection to one host has a different source ip than a connection to another - which recent match module wouldn't help.

If your load is sufficiently distributed across a number of hosts it may prove beneficial to route half your hosts down one and the other half down the other. I do this with aid of a patch (that I believe is going to be included in the next beta?) to match the least significant bit of the ip address (ie if the last octet is odd take one route, if its even take another) with some fancy nat rules and routing.

Previous Employee
Posts: 13,551
Registered: ‎06-10-2011
Kudos: 5429
Solutions: 1656
Contributions: 2

Re: Dual Wan with sticky routing?

Yeah that would be a slightly different issue. Maybe a "hashing"-based approach could work for both? I.e., making the load balancing decision based on a hash of the 5-tupple or something like that.

Veteran Member
Posts: 5,050
Registered: ‎03-12-2011
Kudos: 2495
Solutions: 120

Re: Dual Wan with sticky routing?

Its really needs to be a hash of just the source (ie lan/internal ip) and nothing else to determine which route to use if you want complete assurance that its not going to break protocols that rely on 1 host == 1 public ip.
Previous Employee
Posts: 13,551
Registered: ‎06-10-2011
Kudos: 5429
Solutions: 1656
Contributions: 2

Re: Dual Wan with sticky routing?

Yeah I mean allowing the user to specify which combination of the 5-tupple should be used for the hashing. For example in the OP's case he could use destination IP (or maybe combined with destination port too). In the xbox example it could be source IP as you said. Etc. etc.

Established Member
Posts: 1,175
Registered: ‎06-18-2010
Kudos: 196
Solutions: 10

Re: Dual Wan with sticky routing?

you guys are describing this

 

http://wiki.mikrotik.com/wiki/ManualMan TongueCC

Emerging Member
Posts: 58
Registered: ‎04-02-2014
Kudos: 8
Solutions: 1

Re: Dual Wan with sticky routing?

It would be great to be able to add rules like that, i.e:

 

Given destination group (say a network), pick a connection based on the hash of the source ip address. I think that's pretty much what's been said in the previous posts though.


Of course, this is something I'd like to do on a selective basis - I want to use both connections when I download from steam for example, and that's possibly (although not necessarily) going to the same server. I also have a download plugin for firefox that opens multiple connections, allowing use of both outgoing wans at the same time.

 

As noted in earlier posts, I do use a separate LBS configuration specifically for ESO due to it breaking horribly if the external source address changes randomly.

Previous Employee
Posts: 13,551
Registered: ‎06-10-2011
Kudos: 5429
Solutions: 1656
Contributions: 2

Re: Dual Wan with sticky routing?

Yeah using some combination of the 5-tuple to differentiate flows is pretty standard, so we'll need to look into how to add that to the load balancing/failover feature (i.e., what the config structure should look like etc.).

Reply