Forum Discussion

Vladimir_Akhmarov's avatar
Jan 10, 2024

What is the proper way to define GTM regions

Hello!

According to Bug ID https://cdn.f5.com/product/bugtracker/ID1040153.html we should "not put mixed subnets in one region"

Who knows what is the correct way to define region records with mixed subnets?

Option 1

gtm region Option1_region {
    region-members {
        subnet 10.0.0.0/8 { }
        subnet 172.16.0.0/12 { }
        subnet 192.168.0.0/16 { }
    }
}

Option 2

gtm region RFC1918_10_region {
    region-members {
        subnet 10.0.0.0/8 { }
    }
}
gtm region RFC1918_172_region {
    region-members {
        subnet 172.16.0.0/12 { }
    }
}
gtm region RFC1918_192_region {
    region-members {
        subnet 192.168.0.0/16 { }
    }
}
gtm region Option2_region {
    region-members {
        region /Common/RFC1918_10_region { }
        region /Common/RFC1918_172_region { }
        region /Common/RFC1918_192_region { }
    }
}

 

2 Replies

  • There is no right or wrong answer, as this can be mostly an architecture decision. For example, different private class subnets can be used for internal networks, management networks, and even the DMZ. In such a case, you want to use blocks for each datacenter so that you can summarize on the network size. In terms of the F5 DNS module, I would still group them as one datacenter region... so I can easily check if the LDNS is part of ANY local datacenter subnet. Now, there may also be a use case for determining if the LDNS source IP is coming from the datacenter internal network (normal user) or perhaps the DMZ (some proxy server, VPN user, etc) and provide a different DNS response / resource accordingly.

    So you have the right idea, but there is no best practice really. Architecture decision 😉

    • Thanks for the answer but as I understand you are talking about more common scenario for DNS region usage.

      And I would like to know more about masks and regions from the mentioned Bug ID perspective. They say "BIG-IP returns malformed packets or the narrowest scope not matching the request" if mixed sub networks with different mask length in one region.

      Option 1 uses different sub networks with different mask length in the same region

      Option 2 uses different regions with different sub networks with different mask length

      Both options may be used. But what is the correct way of usage?

      Or maybe both options lead to "BIG-IP returns malformed packets or the narrowest scope not matching the request" and we should use three different regions (each contain it's own sub network from RFC1918) and create more topology records?