Yes; the feature went into 1.5.x.
--
Thanks,
Jeff
On Thu, Jan 19, 2017 at 10:37 AM, Steve Malenfant <smalenf...@gmail.com> wrote:
> I didn't know about this which is good information. Does that work on
> Traffic Router 1.6?
>
> On Mon, Jan 9, 2017 at 12:44 PM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
>
>> Jeff and I had a quick Slack convo, so I’ll add a followup summary here in
>> case anyone else is interested.
>>
>> Cache Group location (lat/long) is configured in Traffic Ops today (and is
>> used for computing distance from Maxmind Geolocation).
>>
>> You can also configure the location (lat/long) for a Cache Group in the
>> CoverageZone file (example below).
>>
>> When this location is configured (and Jeff’s suggested logic fix from
>> below is applied) and all caches in the mapped cache group are unavailable,
>> TR will send a client request to the cache group that is closest to the
>> original mapped group.
>>
>> Example CZF w/ cache location
>> -----
>> "coverageZones": {
>> “edge-cg-1": {
>> "network6": [
>> ...
>> ],
>> "network": [
>> ...
>> ],
>> "coordinates": {
>> "longitude": “-75.3342",
>> "latitude": “42.555"
>> }
>> },
>>
>>
>> —Eric
>>
>>
>> > On Jan 5, 2017, at 12:06 PM, Jeff Elsloo <jeff.els...@gmail.com> wrote:
>> >
>> > If we applied the proposed change, given your scenario we should fall
>> > through to the return statement that calls getClosestCacheLocation().
>> > That method will order all cache groups based on their lat/long and
>> > the lat/long of the cache group we hit on in the CZF. Once the list is
>> > ordered, we iterate through the list until we find a cache group that
>> > has available caches for that DS.
>> >
>> > BTW, the stuff on line 536 is likely to produce the exact same result
>> > as the check that precedes it. networkNode.getLoc() will return the
>> > string name of the cache group, so when we find the CacheLocation, it
>> > will be the same as what we had just checked. We could probably get
>> > away with removing that part of the method as it's redundant.
>> > --
>> > Thanks,
>> > Jeff
>> >
>> >
>> > On Wed, Jan 4, 2017 at 11:54 AM, Eric Friedrich (efriedri)
>> > <efrie...@cisco.com> wrote:
>> >> Where would TR look outside the assigned cache group to find the next
>> closest cache group?
>> >>
>> >>> On Jan 4, 2017, at 11:25 AM, Eric Friedrich (efriedri) <
>> efrie...@cisco.com> wrote:
>> >>>
>> >>>
>> >>> On Jan 3, 2017, at 5:20 PM, Jeff Elsloo <jeff.els...@gmail.com<mailto:
>> jeff.els...@gmail.com>> wrote:
>> >>>
>> >>> Hey Eric,
>> >>>
>> >>> It sounds like the use case you're after is an RFC 1918 client
>> >>> associated with a cache group whose caches are all unavailable for one
>> >>> reason or another. Is that correct?
>> >>> Yes, exactly.
>> >>>
>> >>>
>> >>> I looked at the code a bit, and I think that we can make a minor
>> >>> change to achieve the behavior you're looking for as long as you're
>> >>> able to put your RFC 1918 ranges in the CZF.
>> >>> Yes, we would want those ranges in the CZF. I can’t think of any other
>> place they would go.
>> >>>
>> >>>
>> >>> There's a small logic gap in the existing algorithm around cache
>> >>> location selection and I think if we fix that (two line change), we
>> >>> should be better off all around. I think the only time we'd ever want
>> >>> to go to the geolocation provider is in the event of a miss on the
>> >>> CZF, so as long as we have a hit there, we should find the cache group
>> >>> closest to that hit location that has available caches. This would
>> >>> automatically provide the "backup" cache group concept, and has the
>> >>> added benefit of doing this selection dynamically based on the state
>> >>> of the CDN.
>> >>> Wow, thanks for picking up on this solution. Sounds like a strong
>> possibility. I like that it can extend dynamically.
>> >>>
>> >>>
>> >>>
>> >>> See this to get an idea of what I mean: http://apaste.info/u3PQo
>> >>> https://github.com/apache/incubator-trafficcontrol/blob/
>> 249bd7504eeb7cc43402126f3719017e2475ad33/traffic_router/
>> core/src/main/java/com/comcast/cdn/traffic_control/
>> traffic_router/core/router/TrafficRouter.java#L536
>> >>> Does this line set cacheLocation to the closest cache group with
>> active caches on that DS?
>> >>>
>> >>> What does networkNode.getLoc() actually return?
>> >>>
>> >>> —Eric
>> >>>
>> >>>
>> >>>
>> >>> Obviously we'd need to test this to ensure we don't break other
>> functionality.
>> >>> --
>> >>> Thanks,
>> >>> Jeff
>> >>>
>> >>>
>> >>> On Tue, Jan 3, 2017 at 10:07 AM, Eric Friedrich (efriedri)
>> >>> <efrie...@cisco.com<mailto:efrie...@cisco.com>> wrote:
>> >>> 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 <j...@knutsel.com<mailto:
>> j...@knutsel.com>> 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) <
>> efrie...@cisco.com<mailto:efrie...@cisco.com>> 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
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>>
>>
