<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <br>
    <br>
    <br>
    On 7/20/2011 1:15 AM, AMANI M. BIN SUWAIF wrote:
    <blockquote cite="mid:4E266459.7070001@ies.etisalat.ae" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      Hi,<br>
      <br>
      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. <br>
      <br>
      <br>
      <div class="moz-signature"> <font color="black" face="Georgia"
          size="2">Thanks & Regards, </font><br>
        <br>
        <font color="darkgreen" face="Georgia" size="2"> <b>Amani</b></font><br>
        <br>
        <br>
        <br>
      </div>
      On 7/20/2011 2:50 AM, Kevin Darcy wrote:
      <blockquote cite="mid:4E260A45.7030107@chrysler.com" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        <title></title>
        On 7/18/2011 11:42 PM, AMANI MOHAMED BIN SUWAIF wrote:
        <blockquote cite="mid:4E24FD36.6020702@ies.etisalat.ae"
          type="cite">
          <meta http-equiv="content-type" content="text/html;
            charset=ISO-8859-1">
          Hi,<br>
          <br>
          I have the below scenario <br>
          <br>
          _TCP.EXAMPLE.COM    IN SRV    10    0    5060   
          primary-sbg.example.com <br>
          _TCP.EXAMPLE.COM    IN SRV    20    0    5060   
          secondary-sbg.example.com <br>
          <br>
          I have 2 IP ranges and 2 SBGs host, my intention is <br>
          <br>
          for client in IP range1 <br>
          primary-sbg      IN    A    1.1.1.1 <br>
          secondary-sbg    IN    A    2.2.2.2 <br>
          <br>
          for client in IP range2 <br>
          primary-sbg      IN    A    2.2.2.2 <br>
          secondary-sbg    IN    A    1.1.1.1 <br>
          <br>
          can this be achieved without using a views? <br>
          <br>
          I thought this can be solved just by a sortlist, where <br>
          primary-sbg    IN    A    1.1.1.1 <br>
          primary-sbg    IN    A    2.2.2.2 <br>
          secondary-sbg    IN    A    2.2.2.2 <br>
          secondary-sbg    IN    A    1.1.1.1 <br>
          <br>
          and then introduce the sortlist, which sorts the position of
          IP addresses based on the IP range client comes from? <br>
          something like, <br>
          <br>
          sortlist { <br>
              { <br>
               IPRANGE1;  // 1st client IP selection matches any of
          these <br>
               {1.1.1.1;   // return any of these response IPs as 1st
          preference <br>
               }; <br>
              { <br>
               IPRANGE2;  // 1st client IP selection matches any of
          these <br>
               {2.2.2.2;   // return any of these response IPs as 1st
          preference <br>
               }; <br>
          }; <br>
          <br>
          but in this case, <br>
          client from IPRANGE1 receive 1.1.1.1 as a first choice for
          both primary-sbg and secondary-sbg <br>
          and <br>
          client from IPRANGE2 receive 2.2.2.2 as a first choice for
          both primary-sbg and secondary-sbg <br>
          which is not the intention. sortlist doesn't not  consider
          domain name. <br>
          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... <br>
          <br>
          (LOC)RANGE    PRIMARY(LOC)   SECONDARY(LOC) <br>
          (L1)IPRANGE1  SBG1(L1)       SBG6(L2) <br>
          (L1)IPRANGE2  SBG2(L1)       SBG7(L2) <br>
          (L1)IPRANGE3  SBG3(L1)       SBG8(L2) <br>
          (L1)IPRANGE4  SBG4(L1)       SBG9(L2) <br>
          (L1)IPRANGE5  SBG5(L1)       SBG10(L2) <br>
          <br>
          (L2)IPRANGE6  SBG6(L2)       SBG1(L1) <br>
          (L2)IPRANGE7  SBG7(L2)       SBG2(L1) <br>
          (L2)IPRANGE8  SBG8(L2)       SBG3(L1) <br>
          (L2)IPRANGE9  SBG9(L2)       SBG4(L1) <br>
          (L2)IPRANGE10 SBG10(L2)      SBG5(L1) <br>
          <br>
          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. <br>
        </blockquote>
        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).<br>
        <br>
        <br>
                                                                       
                                                                    -
        Kevin<br>
      </blockquote>
    </blockquote>
    Well, you could always stand up some virtual IPs on the same servers
    (or possibly NAT it upstream) and then perform some *fancy*
    sortlisting, e.g.<br>
    <br>
    for clients in IP range1<br>
    primary-sbg 1.1.1.1, 2.2.2.3<br>
    secondary-sbg 2.2.2.2, 1.1.1.2<br>
    <br>
    for clients in IP range2<br>
    primary-sbg 2.2.2.3, 1.1.1.1<br>
    secondary-sbg 1.1.1.2, 2.2.2.2<br>
    <br>
    That way range1 clients would always fail over -- via SRV failover
    or A-record failover -- from the 1.1.1.x server to the 2.2.2.x
    server and range2 clients would always fail over from the 2.2.2.x
    server to the 1.1.1.x server.<br>
    <br>
    Bear in mind that "view"s, i.e. giving different answers to the same
    DNS query, depending on the client, is not something which is (as
    far as I'm aware) sanctioned by the Internet Standards, but A-record
    failover was specified as far back as RFC 1123 (1989):<br>
    <br>
    "2.3 Applications on Multihomed hosts<br>
    <br>
    When the remote host is multihomed, the name-to-address translation
    will return a list of alternative IP addresses. As specified in
    Section 6.1.3.4, this list should be in order of decreasing
    preference. Application protocol implementations SHOULD be prepared
    to try multiple addresses from the list until success is obtained.
    More specific requirements for SMTP are given in Section 5.3.4.
    "<br>
    <br>
    2.3  Applications on Multihomed hosts<br>
    <br>
          When the remote host is multihomed, the name-to-address<br>
          translation will return a list of alternative IP addresses. 
    As<br>
          specified in Section 6.1.3.4, this list should be in order of<br>
          decreasing preference.  Application protocol implementations<br>
          SHOULD be prepared to try multiple addresses from the list
    until<br>
          success is obtained.  More specific requirements for SMTP are<br>
          given in Section 5.3.4.<br>
    <br>
    So if you're worried about what is "standard" and what isn't, you
    should cast your lot with A-record failover and *not* any "view"
    trickery.<br>
    <br>
                                                                     
                                                        - Kevin<br>
    <br>
      <br>
  </body>
</html>