On Mon, Oct 29, 2018 at 9:36 AM Sam Hague <[email protected]> wrote: > Anil, > > what does that setting do? And is this a long-term change that is > suggested? > This setting will put all the controller to the equal role for the switch (but internally plugin will assume the master/slave role and only one controller instance will be managing the device). We added this feature, because during the cluster partitioning and ownership switchover, setting the role on the device adds some delay before controller can configure the device and sometime pushing role to device fails and it end up in bad situation. Once you enable the equal role, the only thing that changes is that, packet_ins will be sent to all controller connected to the switch, apart from that everything works as default mode.
So it's not really a long term or short term deployment, user should enable it based on their usecase. If their solution require huge number of packet_in to be processed by controller, it's not recommended to enable this feature because it will put stress on switch to replicate the packet to three controllers ( although at the controller side non-owner controler will drop the packet at the openflowjava level). But if solution doesn't rely on the packet_in or lower rate of packet_ins, we recommend to user to enable this setting. This will significantly help user to stabilize their solution, specially when they deployed openflowplugin in clustered setup. > > I believe we hit this issue in both 1node and 3node, but the 3node are the > worst so I guess that workaround won't help much right? > It can help in both the scenario, in single node scenario, it definitely can help, because it does not make sense to send master/slave role to switch if you are using single controller. For cluster setup also it helps significantly to stablize the switch ownership, but it has a side effect that i mentioned above. If netvirt is not heavily relying on packet_in i would suggest to enable it. This is also recommended for the solution where more than one non-clustered ODL instance are managing the device. Overall this setting is recommended in general except the solution that rely on high packet_ins. > > Thanks, Sam > > On Mon, Oct 29, 2018 at 12:22 PM Jaime Caamaño Ruiz <[email protected]> > wrote: > >> Thanks for the tip Anil. >> >> -----Original Message----- >> From: Anil Vishnoi <[email protected]> >> To: [email protected] >> Cc: Jamo Luhrsen <[email protected]>, openflowplugin-dev <openflowplug >> [email protected]> >> Subject: Re: [openflowplugin-dev] openflow connections problems >> Date: Mon, 29 Oct 2018 08:56:06 -0700 >> >> Pushing master or slave role to device is failing . If you are using >> single node controller, as a workaround you can enable the "equal- >> role=enabled" config knob in openflowplugin.cfg file. >> >> On Mon, Oct 29, 2018 at 4:16 AM Jaime Caamaño Ruiz <[email protected]> >> wrote: >> > Ok, a third restart did eventually help ;) >> > >> > -----Original Message----- >> > From: Jaime Caamaño Ruiz <[email protected]> >> > Reply-to: [email protected] >> > To: Jamo Luhrsen <[email protected]>, [email protected] >> > ay >> > light.org >> > Subject: Re: [openflowplugin-dev] openflow connections problems >> > Date: Mon, 29 Oct 2018 11:08:59 +0100 >> > >> > Hey Jamo >> > >> > The error is the same but it does not tell much in itself and I am >> > not >> > operating a cluster. Restarting the single ODL does not help in my >> > case. >> > >> > BR >> > Jaime. >> > >> > -----Original Message----- >> > From: Jamo Luhrsen <[email protected]> >> > To: [email protected], [email protected] >> > Subject: Re: [openflowplugin-dev] openflow connections problems >> > Date: Thu, 25 Oct 2018 09:07:21 -0700 >> > >> > Jaime, >> > >> > any chance you are hitting this? >> > >> > https://jira.opendaylight.org/browse/OPNFLWPLUG-1035 >> > >> > JamO >> > >> > On 10/25/18 5:18 AM, Jaime Caamaño Ruiz wrote: >> > > Hello >> > > >> > > Randomly I sometimes get an OVS (2.9.2) switch to which ODL cannot >> > > connect because MASTER role cannot be set. At the end, the only >> > > traces >> > > indicative of the problem. No other ERROR/WARNS are printed. >> > Attached >> > > a >> > > capture. It looks like the multipart reply OFPMP_DESC is never >> > > processed properly, but nowhere shows why. >> > > >> > > Any hints? >> > > >> > > Thanks >> > > Jaime >> > > >> > > 2018-10-25T05:14:33,047 | WARN | epollEventLoopGroup-9-2 | >> > > ContextChainImpl | 379 - >> > > org.opendaylight.openflowplugin.impl - 0.8.0.SNAPSHOT | Not able to >> > > start clustering services for node openflow:185574002334271 >> > > 2018-10-25T05:14:33,047 | WARN | ofppool-11 | >> > > ContextChainHolderImpl | 379 - >> > > org.opendaylight.openflowplugin.impl - 0.8.0.SNAPSHOT | Not able to >> > > set >> > > MASTER role on device openflow:185574002334271, reason: >> > > java.lang.RuntimeException: Failed to initialize device >> > > openflow:185574002334271 in 9s: >> > > java.util.concurrent.TimeoutException: >> > > Waited 9000 milliseconds for >> > > com.google.common.util.concurrent.Abstract >> > > TransformFuture$AsyncTransformFuture@52c8e28d[status=PENDING, >> > > >> > info=[inputFuture=[com.google.common.util.concurrent.AbstractTransfor >> > > mF >> > > uture$TransformFuture@30c900ec[status=PENDING, >> > > info=[inputFuture=[com.g >> > > oogle.common.util.concurrent.SettableFuture@7015a912[status=PENDING >> > ]] >> > > , >> > > >> > function=[org.opendaylight.openflowplugin.impl.device.initialization. >> > > OF >> > > 13DeviceInitializer$$Lambda$1305/1764863356@2d21d4bc]]]], >> > > function=[org >> > > >> > .opendaylight.openflowplugin.impl.device.initialization.OF13DeviceIni >> > > ti >> > > alizer$$Lambda$1306/930757835@5d94c1b6]]] >> > > 2018-10-25T05:14:33,047 | WARN | ofppool-11 | >> > > ContextChainHolderImpl | 379 - >> > > org.opendaylight.openflowplugin.impl - 0.8.0.SNAPSHOT | This >> > > mastering >> > > is mandatory, destroying context chain and closing connection for >> > > device openflow:185574002334271. >> > > >> > > >> > > _______________________________________________ >> > > openflowplugin-dev mailing list >> > > [email protected] >> > > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >> > > >> > >> > >> > _______________________________________________ >> > openflowplugin-dev mailing list >> > [email protected] >> > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >> >> >> _______________________________________________ >> openflowplugin-dev mailing list >> [email protected] >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >> > -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
