sort list and view

[AMANI M. BIN SUWAIF]

Hi,

The problem is that fail-over between A records is not standard and 
might/might not work with various SIP clients. On the other hand SRV in 
my opinion has been designed with that in mind, that's why the 
additional complexity with 2 SRV records.


Thanks & Regards,

*Amani*



On 7/20/2011 2:50 AM, Kevin Darcy wrote:
> 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
>
>
> _______________________________________________
> Please visithttps://lists.isc.org/mailman/listinfo/bind-users  to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110720/10d01463/attachment.html>