sort list and view

[Kevin Darcy]

On 7/18/2011 11:42 PM, AMANI MOHAMED BIN SUWAIF wrote:
> Hi,
>
> I have the below scenario
>
> _TCP.EXAMPLE.COM    IN SRV    10    0    5060    primary-sbg.example.com
> _TCP.EXAMPLE.COM    IN SRV    20    0    5060    
> secondary-sbg.example.com
>
> I have 2 IP ranges and 2 SBGs host, my intention is
>
> for client in IP range1
> primary-sbg      IN    A    1.1.1.1
> secondary-sbg    IN    A    2.2.2.2
>
> for client in IP range2
> primary-sbg      IN    A    2.2.2.2
> secondary-sbg    IN    A    1.1.1.1
>
> can this be achieved without using a views?
>
> I thought this can be solved just by a sortlist, where
> primary-sbg    IN    A    1.1.1.1
> primary-sbg    IN    A    2.2.2.2
> secondary-sbg    IN    A    2.2.2.2
> secondary-sbg    IN    A    1.1.1.1
>
> and then introduce the sortlist, which sorts the position of IP 
> addresses based on the IP range client comes from?
> something like,
>
> sortlist {
>     {
>      IPRANGE1;  // 1st client IP selection matches any of these
>      {1.1.1.1;   // return any of these response IPs as 1st preference
>      };
>     {
>      IPRANGE2;  // 1st client IP selection matches any of these
>      {2.2.2.2;   // return any of these response IPs as 1st preference
>      };
> };
>
> but in this case,
> client from IPRANGE1 receive 1.1.1.1 as a first choice for both 
> primary-sbg and secondary-sbg
> and
> client from IPRANGE2 receive 2.2.2.2 as a first choice for both 
> primary-sbg and secondary-sbg
> which is not the intention. sortlist doesn't not  consider domain name.
> The intention is to have primary SBG for first iprange act as a 
> secondary SBG for the second ip range and vice verse and in similar 
> manner for multiple IP ranges and SBGs. Problem with views is that 
> anytime this setup gets bigger and we will have additional ip ranges 
> and additional SBGs, it will require additional views...
>
> (LOC)RANGE    PRIMARY(LOC)   SECONDARY(LOC)
> (L1)IPRANGE1  SBG1(L1)       SBG6(L2)
> (L1)IPRANGE2  SBG2(L1)       SBG7(L2)
> (L1)IPRANGE3  SBG3(L1)       SBG8(L2)
> (L1)IPRANGE4  SBG4(L1)       SBG9(L2)
> (L1)IPRANGE5  SBG5(L1)       SBG10(L2)
>
> (L2)IPRANGE6  SBG6(L2)       SBG1(L1)
> (L2)IPRANGE7  SBG7(L2)       SBG2(L1)
> (L2)IPRANGE8  SBG8(L2)       SBG3(L1)
> (L2)IPRANGE9  SBG9(L2)       SBG4(L1)
> (L2)IPRANGE10 SBG10(L2)      SBG5(L1)
>
> half of the SBGs is in one location (L1) and half in other (L2), 
> that's why it is important that for clients from ranges in one 
> location, first half of SBGs is preferred, and for other clients from 
> second location other half of SBGs is preferred. Client configuration 
> should be uniformed (same SRV) regardless the location.
Are you over-engineering this? If the A-record failover by your client 
is fast enough you might only need 1 SRV record, and then sortlisting 
will work fine (subject to the usual caveats: as long as you can control 
the sortlist config of every resolver your clients will use, and keep 
them in sync).


                                                                         
                                                     - Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110719/8e82bc3a/attachment.html>