If all caches in the primary cache group are unavailable, our goal is to provide a backup routing policy for RFC1918 clients.
When client IP is an public Internet IP, the current backup policy is to assign the client to the geographically closest cache (Distance = MaxMind Geo Lat/Long - configured CG lat/long). When client IP is an RFC1918 IP, the client would not have a maxmind geo-loc, so would fall back to the DS geo-miss lat long. We’d prefer some more granular control over where these clients are routed to, rather than a per-DS setting. So with an RFC1918 client, the lookup process would be (step 3 is only addition) 1) Check CZF for a subnet match (and find a match for existing cache group). Assign client to CG 2) Check CG for available (online and associated w/ DS) servers. In this particular case, assume CG has no servers available to route the client to 3) Walk the CZF's list of backup CGs and perform the check from #2 for each CG. Use first server that is found 4) Assuming no server is found in #3, perform geo-location and find closest cache group. Use a server from the closest CG if one is found 4a) If geo-location returns null, use the DS’ default geo-miss location as the client location. —Eric > On Dec 26, 2016, at 10:01 AM, Jan van Doorn <[email protected]> wrote: > > Hi Eric, > > How does the backup list relate to the RFC1918-is-not-in-geo problem? > > To get to a cachegroup you need to get a match in the coverage zone, I would > think? > > Rgds, > JvD > >> On Dec 22, 2016, at 12:28, Eric Friedrich (efriedri) <[email protected]> >> wrote: >> >> The current behavior of cache group selection works as follows >> 1) Look for a subnet match in CZF >> 2) Use MaxMind/Neustar for GeoLocation based on client IP. Choose closest >> cache group. >> 3) Use Delivery Service Geo-Miss Lat/Long. Choose closest cache group. >> >> >> For deployments where IP addressing is primarily private (say RFC-1918 >> addresses), client IP Geo Location (#2) is not useful. >> >> >> We are considering adding another field to the Coverage Zone File that >> configures an ordered list of backup cache groups to try if the primary >> cache group does not have any available caches. >> >> Example: >> >> "coverageZones": { >> "cache-group-01": { >> “backupList”: [“cache-group-02”, “cache-group-03”], >> "network6": [ >> "1234:5678::\/64”, >> "1234:5679::\/64"], >> "network": [ >> "192.168.8.0\/24", >> "192.168.9.0\/24”] >> } >> >> This configuration could also be part of the per-cache group configuration, >> but that would give less control over which clients preferred which cache >> groups. For example, you may have cache groups in LA, Chicago and NY. If the >> Chicago Cache group fails, you may want some of the Chicago clients to go to >> LA and some to go to NY. If the backup CG configuration is per-cg, we would >> not be able to control where clients are allocated. >> >> Looking for opinions and comments on the above proposal, this is still in >> idea stage. >> >> Thanks All! >> Eric >> >> >
