[BEHAVE] Using DNS64 to load balance to NAT64
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[BEHAVE] Using DNS64 to load balance to NAT64
Folks,
One of the major problems many operators have is scaling the CGN in a
reliable way. Scaling in the number of session per seconds as well as
raw concurrent sessions continues to be an issue, and will continue to
be an issue. Additionally, given that state and ALGs are being used,
boxes are known to reboot when protocols act in unexpected ways, so
fault isolation is another desire (array of independent boxes).
Does the scenarios where i have boxes NAT64-A, NAT64-B, and NAT64-C
(all unique state boxes or high-available pairs of active/standby
boxes, with unique prefix64 A, B, and C respectively announced from
each) and the DNS64 load balances traffic (for example, round-robin
assignments of Prefix64-A, B, and C to resolving clients) destine to
each NAT64-A, B, C systems evenly. This way, the DNS64 drives 1/3 of
the requests to each of the 3 NAT64 systems. And, it scales linearly
in terms of NAT64 boxes. This assumes the DNS64 system scales higher
than the NAT64 systems, which i think is a good assumption.
Additionally, the NAT64 and the DNS64 should be able to communicate in
such a way that the NAT64 can signal an overloading situation such
that the DNS64 drops the overloaded NAT64 out of the round-robin
prefix64 synthesis for some period of time. This could be implemented
as simple SNMP GET sampling of the sessions that NAT64 systems are
currently processing.
Does this make sense to have this level of load-balancing between an
array of independent NAT64 boxes and feedback / back-pressure
communicated to the DNS64 system that is ultimately driving the load
to the NAT64 boxes?
Does this fit within the existing drafts? Or is this implementation
minutia that does not require being covered here? At a minimum, i
think it would be nice to have the DNS64 draft examine how the DNS64
system can drive load to multiple unique NAT64 systems.
Thoughts?
Regards,
Cameron Byrne
Cameron
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.