Hi,

On Sun, Jul 10, 2022 at 02:23:41PM +0000, Henning Svane wrote:
> About IPv4 and IPv6 I was of that impression that when you declared the
> stick-table you also declared it with a type for either ipv4 or ipv6, and it
> was not possible to save both of them in the same table. I have no problem to
> use the extra space if that will work.

If you set "type ipv6" it will indeed store IPv6 addresses, and IPv4
ones will be automatically converted to IPv6 before being looked up,
so an ipv6 table can store both, though if you enumerate it you'll
see IPv6 representation for all addresses.

> But still I can see the need to select between IPv4 and IPv6 when your are
> running dual stack. 

The above will work for this. Since you mentioned the usefulness of options
in your earlier message, let me also point the ".if" preprocessor directives.
These allow to ignore some configuration blocks based on conditions. Thus
you could have something like this in your config to adapt to different
environments:

  global
      presetenv ADDRTYPE "v4"  # or "v6" or "dual"

Then later you can rely on this variable, e.g.

  backend table
  .if streq("${ADDRTYPE}",v6) || streq("${ADDRTYPE}",dual)
        stick-table type ipv6 ...
  .else
        stick-table type ip ...
  .endif

Similarly you can imagine that some frontends have an IPv4 address and
an optional IPv6 one, and only bind those that are defined:

  global
      presetenv BIND_FOO_IPV4 192.168.10.10
      presetenv BIND_FOO_IPV6 2001:bd8::1010

  frontend foo
  .if defined(BIND_FOO_IPV4)
      bind "${BIND_FOO_IPV4}":1234 name ipv4
  .endif
  .if defined(BIND_FOO_IPV6)
      bind "${BIND_FOO_IPV6}":1234 name ipv6
  .endif

Or even:
  frontend foo
  .if defined(BIND_FOO_IPV4) && defined(BIND_FOO_IPV6)
      bind "${BIND_FOO_IPV4}":1234,"${BIND_FOO_IPV6}":1234 name dual
  .elif defined(BIND_FOO_IPV4)
      bind "${BIND_FOO_IPV4}":1234 name ipv4
  .elif defined(BIND_FOO_IPV6)
      bind "${BIND_FOO_IPV6}":1234 name ipv6
  .endif

To be honest, it makes the confs completely unreadable, but it can ease
config versioning and deployment. I know that some users are placing
all their variables in a separate file, so that they can share a common
core config between multiple machines/clusters and only have a few
variables in system-local config file.

Regards,
Willy

Reply via email to