Return-Path: X-Original-To: oracle-l@orafaq.com Delivered-To: oracle-l@orafaq.com Received: from puck1183.startdedicated.com (localhost [127.0.0.1]) by puck1183.startdedicated.com (Postfix) with ESMTP id 5709E1961201 for ; Fri, 9 Sep 2016 00:10:41 +0200 (CEST) Received: from turing.freelists.org (turing.freelists.org [206.53.239.180]) by puck1183.startdedicated.com (Postfix) with ESMTPS for ; Fri, 9 Sep 2016 00:10:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id B31DB2C5E3; Thu, 8 Sep 2016 18:10:39 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at turing.freelists.org Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzHS7rwjQkjJ; Thu, 8 Sep 2016 18:10:39 -0400 (EDT) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id B1E5E2C59E; Thu, 8 Sep 2016 18:10:26 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 08 Sep 2016 18:09:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id D81002C38A for ; Thu, 8 Sep 2016 18:09:04 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azODvC2_gxWW for ; Thu, 8 Sep 2016 18:09:04 -0400 (EDT) Received: from mail-ua0-f175.google.com (mail-ua0-f175.google.com [209.85.217.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id AAF332C380 for ; Thu, 8 Sep 2016 18:09:04 -0400 (EDT) Received: by mail-ua0-f175.google.com with SMTP id 95so28762948uaz.2 for ; Thu, 08 Sep 2016 15:09:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EZOpXUYNQ7/x7xytXE7ED9NNYtsQZD/bhNMVEKyXMEY=; b=P5yYBCAIfw4kpnmw0wetq0IQzhzHyS/0BhLJR04pmdQr8wjOF8Vus9GOUfqIVQvFOQ S7Xh1B1/heF/bR80xRN1WMgHwyBkjFQeSr5Dc2PMVxGjay382E7KUTVKGCqFjlv/naPL v5jLybKlCqgsQbuoghqqWLn7WNJuiUBJ8jiaM+ChmV1IeE/gPDnw8F4ZUl6kUl5w/JT/ PTQqJ1L7NGEi7Pu6jaxS8TqZ/ETstFITOFfNj3RCPa6p7KMr5AVmmfoMJYNInssGtGYo A6Puue1IIsSaG9oTUh6GqurjeRIdD89FHKc+zvkAgH9oYdajxtK4Ul3lfttSgX85LCRV xApg== X-Gm-Message-State: AE9vXwOAtjeyv58nrwrcprrrZ8/SdIfGJq6q/UNr+iXOgL/kRyZ/H2uP3emE+d2Y0GF5y8QAiz4a1Dbrvy2Zdw== X-Received: by 10.159.40.166 with SMTP id d35mr166299uad.93.1473372543962; Thu, 08 Sep 2016 15:09:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.64.166 with HTTP; Thu, 8 Sep 2016 15:09:03 -0700 (PDT) In-Reply-To: <57d1d508.d46f240a.19398.df46@mx.google.com> References: <57d1cfea.47866b0a.db709.0e5b@mx.google.com> <57d1d508.d46f240a.19398.df46@mx.google.com> From: Seth Miller Date: Thu, 8 Sep 2016 17:09:03 -0500 Message-ID: Subject: Re: Grid Networking Reliance on DHCP To: fmhabash@gmail.com Cc: "'oracle-l@freelists.org' (oracle-l@freelists.org)" Content-Type: multipart/alternative; boundary=94eb2c12381a1ad5e0053c0647f7 X-archive-position: 66178 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: sethmiller.sm@gmail.com Precedence: normal Reply-To: sethmiller.sm@gmail.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l --94eb2c12381a1ad5e0053c0647f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Over the last decade, I have never had or heard of a DHCP lease renewal failure causing a clusterware node failover. This seems like a pretty specific problem with your DNS. Regardless, is there a reason you are not using what I have found to be the easiest to implement and manage, least error prone, and most scalable option - GNS? Seth On Thu, Sep 8, 2016 at 4:15 PM, wrote: > True, but if they are left under the control of DHCP, I have seen issues > when dhclient attempts to renew the lease on these IPs and it fails for > some reason. As s result, the VIPs are gone and a failover is triggered. > > > > This can be resolved either by configuring these IPs to never expire or > remove DHCP altogether. In such case, I=E2=80=99m thinking the virtual in= terfaces > need to be configured with BOOTPROTO=3D"static" > > > > > > Feedback appreciated. > > > ---------------------------------------- > Thank you > > > > *From: *Seth Miller > *Sent: *Thursday, September 8, 2016 5:02 PM > *To: *fmhabash@gmail.com > *Cc: *'oracle-l@freelists.org' (oracle-l@freelists.org) > > *Subject: *Re: Grid Networking Reliance on DHCP > > > > The VIPs are created and managed by clusterware. You shouldn't need a > configuration file at all for them. > > > > > > Seth > > > > On Thu, Sep 8, 2016 at 3:54 PM, wrote: > > I know there are 3 options to configure the public network for a GI > cluster. GNS, DHCP, or static. I have, typically, did a static IP=E2=80= =99ing for > public & VIPs. > > > > However, Oracle official documentation indicated that as of 11.2, DHCP ca= n > by used for all VIPs, but not public IP. > > > > SO, the physical interface eth0 and its virtual eth0:1 all have > =E2=80=98BOOTPROTO=3D"static"=E2=80=99. > > > > If you are not using GNS, how are having your IP=E2=80=99s setup for an 1= 1.2 GI > cluster. > > > > > ---------------------------------------- > Thank you > > > > > > > --94eb2c12381a1ad5e0053c0647f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Over the last decade, I have never had or heard of a DHCP = lease renewal failure causing a clusterware node failover.=C2=A0This seems = like a pretty specific problem with your DNS.

Regardless= , is there a reason you are not using what I have found to be the easiest t= o implement and manage, least error prone, and most scalable option - GNS?<= /div>


Seth

On Thu, Sep 8, 2016 at 4:15 PM, <= fmhabash@gmail.com> wrote:
=

True, but if they are left under the control of DHCP, I have seen issu= es when dhclient attempts to renew the lease on these IPs and it fails for = some reason. As s result, the VIPs are gone and a failover is triggered.

=C2=A0

This= can be resolved either by configuring these IPs to never expire or remove = DHCP altogether. In such case, I=E2=80=99m thinking the virtual interfaces = need to be configured with BOOTPROTO=3D"static"

=

=C2=A0

=C2=A0

Feedback appreciated.


----------------------------------------
Thank = you

=C2=A0

<= p class=3D"MsoNormal" style=3D"border:none;padding:0in">From: Seth Miller
<= b>Sent: Thursday, September 8, 2016 5:02 PM
To: fmhabash@gmail.com
Cc:= 'oracl= e-l@freelists.org' (oracle-l@freelists.org)
Subject: Re: = Grid Networking Reliance on DHCP

=C2=A0

The VIPs are creat= ed and managed by clusterware. You shouldn't need a configuration file = at all for them.

=C2=A0

<= span style=3D"font-size:12.0pt;font-family:"Times New Roman",seri= f">=C2=A0

Set= h

=C2=A0

On Thu, Sep 8, 20= 16 at 3:54 PM, <= fmhabash@gmail.com> wrote:

I know = there are 3 options to configure the public network for a GI cluster. GNS, = DHCP, or static. I have, typically, did a static IP=E2=80=99ing for public = & VIPs.

=C2=A0

However, Oracle official documentation indicated that as of 11.2,= DHCP can by used for all VIPs, but not public IP.

=C2=A0

SO, =C2=A0the physical interface eth0 an= d its virtual eth0:1 all have =E2=80=98BOOTPROTO=3D"static"=E2=80= =99.

=C2=A0

If you are= not using GNS, how are having your IP=E2=80=99s setup for an 11.2 GI clust= er.

=C2=A0


--------= --------------------------------
Thank you

=C2=A0

=C2=A0

= =C2=A0


--94eb2c12381a1ad5e0053c0647f7-- -- http://www.freelists.org/webpage/oracle-l