View Full Version : MEP on some of the gateways

2013-09-26, 10:11
We have a Remote Access community on R76 group of gateways geographically dispersed around the world. We are now experimenting with MEP. Not good so far. Wrong decisions with clients going for gateways that are far, far away instead of choosing locally.

Can we configure our most important gateway not to be a part of MEP and the ones, not so important, to be. So most of the users come to central gateway with no MEP. On the other hand, quite a few, that are far away from central, connect first on their local fws and if that fails go for the central one.



2013-09-27, 07:03
Sounds like you are using the Implicit MEP and is set to the Default of First to Respond. I have had that issue myself where a remote gateway responds before the local gateways .

At the risk of being accused of RTFM then the CP_E80.41_Remote_Access_Clients_Admin_Guide.pdf goes through the various methods of implicit vs manual MEP and the various methods.
It does involve editing $FWDIR/conf/trac_client_1.ttm. files on your gateway so get your vi skills brished up.

first_to_respond - probe to all gateways - connect to the first gateway to respond
primary_back - connect to primary, if no response then connect to secondary
load_sharing - connect to gateways and distribute clients over them all

dns_based is an option then then uses Geo-Cluster DNS Name Resolution and rely on DNS resolution of the Gateway Name to determine the closest gateway. Then depends upon you having regional DNS names configured for all of your gateways, ie your UK gateway is a .co.uk, your Germany located is co.de, etc whatever the countries DNS domain is. That way when in Germany will take you to the German Gateway, and when in UK will take you to the UK.

Sounds like you might want to do a manual MEP with primary_back

To be honest all of our customers now use "other" remote access solutions or just have the 1 Gateway location for Remote Access, so I don't get involved that much now with this stuff.

2013-10-02, 03:33
Thanks mcnallym!

Very good and clear explanation.