Re: Slowness forming TIPC cluster with explicit node addresses
Hi Jon, On Wed, 2019-08-07 at 02:55 +, Jon Maloy wrote: > > > > > -Original Message- > > From: Chris Packham > > Sent: 4-Aug-19 19:05 > > To: Jon Maloy ; tipc- > > discuss...@lists.sourceforge.net > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > > Subject: Re: Slowness forming TIPC cluster with explicit node > > addresses > > > > On Sun, 2019-08-04 at 21:53 +, Jon Maloy wrote: > > > > > > > > > > > > > > > > > > -Original Message- > > > > From: netdev-ow...@vger.kernel.org > > > g> > > On > > > > > > > > > > > Behalf Of Chris Packham > > > > Sent: 2-Aug-19 01:11 > > > > To: Jon Maloy ; tipc- > > > > discuss...@lists.sourceforge.net > > > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > Subject: Re: Slowness forming TIPC cluster with explicit node > > > > addresses > > > > > > > > On Mon, 2019-07-29 at 09:04 +1200, Chris Packham wrote: > > > > > > > > > > > > > > > On Fri, 2019-07-26 at 13:31 +, Jon Maloy wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > From: netdev-ow...@vger.kernel.org > > > ow...@vger.kernel.org> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Behalf Of Chris Packham > > > > > > > Sent: 25-Jul-19 19:37 > > > > > > > To: tipc-discuss...@lists.sourceforge.net > > > > > > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > > > > Subject: Slowness forming TIPC cluster with explicit node > > > > > > > addresses > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I'm having problems forming a TIPC cluster between 2 > > > > > > > nodes. > > > > > > > > > > > > > > This is the basic steps I'm going through on each node. > > > > > > > > > > > > > > modprobe tipc > > > > > > > ip link set eth2 up > > > > > > > tipc node set addr 1.1.5 # or 1.1.6 tipc bearer enable > > > > > > > media > > > > > > > eth dev eth0 > > > > > > eth2, I assume... > > > > > > > > > > > Yes sorry I keep switching between between Ethernet ports for > > > > > testing > > > > > so I hand edited the email. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Then to confirm if the cluster is formed I use tipc link > > > > > > > list > > > > > > > > > > > > > > [root@node-5 ~]# tipc link list > > > > > > > broadcast-link: up > > > > > > > ... > > > > > > > > > > > > > > Looking at tcpdump the two nodes are sending packets > > > > > > > > > > > > > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60 > > > > > > > bytes, > > > > > > > MessageSize > > > > > > > 76 bytes, Neighbor Detection Protocol internal, > > > > > > > messageType > > > > > > > Link > > > > > > > request > > > > > > > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60 > > > > > > > bytes, > > > > > > > MessageSize > > > > > > > 76 bytes, Neighbor Detection Protocol internal, > > > > > > > messageType > > > > > > > Link > > > > > > > request > > > > > > > > > > > > > > Eventually (after a few mi
RE: Slowness forming TIPC cluster with explicit node addresses
> -Original Message- > From: Chris Packham > Sent: 4-Aug-19 19:05 > To: Jon Maloy ; tipc- > discuss...@lists.sourceforge.net > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: Slowness forming TIPC cluster with explicit node addresses > > On Sun, 2019-08-04 at 21:53 +, Jon Maloy wrote: > > > > > > > > -Original Message- > > > From: netdev-ow...@vger.kernel.org > On > > > Behalf Of Chris Packham > > > Sent: 2-Aug-19 01:11 > > > To: Jon Maloy ; tipc- > > > discuss...@lists.sourceforge.net > > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > > > Subject: Re: Slowness forming TIPC cluster with explicit node > > > addresses > > > > > > On Mon, 2019-07-29 at 09:04 +1200, Chris Packham wrote: > > > > > > > > On Fri, 2019-07-26 at 13:31 +, Jon Maloy wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: netdev-ow...@vger.kernel.org > > ow...@vger.kernel.org> > > > > > > > > > > > > > > > > > > > > > On Behalf Of Chris Packham > > > > > > Sent: 25-Jul-19 19:37 > > > > > > To: tipc-discuss...@lists.sourceforge.net > > > > > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > > > Subject: Slowness forming TIPC cluster with explicit node > > > > > > addresses > > > > > > > > > > > > Hi, > > > > > > > > > > > > I'm having problems forming a TIPC cluster between 2 nodes. > > > > > > > > > > > > This is the basic steps I'm going through on each node. > > > > > > > > > > > > modprobe tipc > > > > > > ip link set eth2 up > > > > > > tipc node set addr 1.1.5 # or 1.1.6 tipc bearer enable media > > > > > > eth dev eth0 > > > > > eth2, I assume... > > > > > > > > > Yes sorry I keep switching between between Ethernet ports for > > > > testing > > > > so I hand edited the email. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Then to confirm if the cluster is formed I use tipc link list > > > > > > > > > > > > [root@node-5 ~]# tipc link list > > > > > > broadcast-link: up > > > > > > ... > > > > > > > > > > > > Looking at tcpdump the two nodes are sending packets > > > > > > > > > > > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60 > > > > > > bytes, > > > > > > MessageSize > > > > > > 76 bytes, Neighbor Detection Protocol internal, messageType > > > > > > Link > > > > > > request > > > > > > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60 > > > > > > bytes, > > > > > > MessageSize > > > > > > 76 bytes, Neighbor Detection Protocol internal, messageType > > > > > > Link > > > > > > request > > > > > > > > > > > > Eventually (after a few minutes) the link does come up > > > > > > > > > > > > [root@node-6 ~]# tipc link list > > > > > > broadcast-link: up > > > > > > 1001006:eth2-1001005:eth2: up > > > > > > > > > > > > [root@node-5 ~]# tipc link list > > > > > > broadcast-link: up > > > > > > 1001005:eth2-1001006:eth2: up > > > > > > > > > > > > When I remove the "tipc node set addr" things seem to kick > > > > > > into > > > > > > life straight away > > > > > > > > > > > > [root@node-5 ~]# tipc link list > > > > > > broadcast-link: up > > > > > > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up > > > > > > > > > > > > So there appears to be some difference in behaviour between > > > > > > having > > > > > > an explicit node address and using
Re: Slowness forming TIPC cluster with explicit node addresses
On Sun, 2019-08-04 at 21:53 +, Jon Maloy wrote: > > > > > -Original Message- > > From: netdev-ow...@vger.kernel.org > > On > > Behalf Of Chris Packham > > Sent: 2-Aug-19 01:11 > > To: Jon Maloy ; tipc- > > discuss...@lists.sourceforge.net > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > > Subject: Re: Slowness forming TIPC cluster with explicit node > > addresses > > > > On Mon, 2019-07-29 at 09:04 +1200, Chris Packham wrote: > > > > > > On Fri, 2019-07-26 at 13:31 +, Jon Maloy wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: netdev-ow...@vger.kernel.org > ow...@vger.kernel.org> > > > > > > > > > > > > > > > > > On Behalf Of Chris Packham > > > > > Sent: 25-Jul-19 19:37 > > > > > To: tipc-discuss...@lists.sourceforge.net > > > > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > > Subject: Slowness forming TIPC cluster with explicit node > > > > > addresses > > > > > > > > > > Hi, > > > > > > > > > > I'm having problems forming a TIPC cluster between 2 nodes. > > > > > > > > > > This is the basic steps I'm going through on each node. > > > > > > > > > > modprobe tipc > > > > > ip link set eth2 up > > > > > tipc node set addr 1.1.5 # or 1.1.6 tipc bearer enable media > > > > > eth > > > > > dev eth0 > > > > eth2, I assume... > > > > > > > Yes sorry I keep switching between between Ethernet ports for > > > testing > > > so I hand edited the email. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Then to confirm if the cluster is formed I use tipc link list > > > > > > > > > > [root@node-5 ~]# tipc link list > > > > > broadcast-link: up > > > > > ... > > > > > > > > > > Looking at tcpdump the two nodes are sending packets > > > > > > > > > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60 > > > > > bytes, > > > > > MessageSize > > > > > 76 bytes, Neighbor Detection Protocol internal, messageType > > > > > Link > > > > > request > > > > > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60 > > > > > bytes, > > > > > MessageSize > > > > > 76 bytes, Neighbor Detection Protocol internal, messageType > > > > > Link > > > > > request > > > > > > > > > > Eventually (after a few minutes) the link does come up > > > > > > > > > > [root@node-6 ~]# tipc link list > > > > > broadcast-link: up > > > > > 1001006:eth2-1001005:eth2: up > > > > > > > > > > [root@node-5 ~]# tipc link list > > > > > broadcast-link: up > > > > > 1001005:eth2-1001006:eth2: up > > > > > > > > > > When I remove the "tipc node set addr" things seem to kick > > > > > into > > > > > life straight away > > > > > > > > > > [root@node-5 ~]# tipc link list > > > > > broadcast-link: up > > > > > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up > > > > > > > > > > So there appears to be some difference in behaviour between > > > > > having > > > > > an explicit node address and using the default. Unfortunately > > > > > our > > > > > application relies on setting the node addresses. > > > > I do this many times a day, without any problems. If there > > > > would be > > > > any time difference, I would expect the 'auto configurable' > > > > version > > > > to be slower, because it involves a DAD step. > > > > Are you sure you don't have any other nodes running in your > > > > system? > > > > > > > > ///jon > > > > > > > Nope the two nodes are connected back to back. Does the number of > > > Ethernet interfaces make a difference?
RE: Slowness forming TIPC cluster with explicit node addresses
> -Original Message-
> From: netdev-ow...@vger.kernel.org On
> Behalf Of Chris Packham
> Sent: 2-Aug-19 01:11
> To: Jon Maloy ; tipc-
> discuss...@lists.sourceforge.net
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: Slowness forming TIPC cluster with explicit node addresses
>
> On Mon, 2019-07-29 at 09:04 +1200, Chris Packham wrote:
> > On Fri, 2019-07-26 at 13:31 +, Jon Maloy wrote:
> > >
> > >
> > > >
> > > >
> > > > -Original Message-
> > > > From: netdev-ow...@vger.kernel.org ow...@vger.kernel.org>
> > > > On Behalf Of Chris Packham
> > > > Sent: 25-Jul-19 19:37
> > > > To: tipc-discuss...@lists.sourceforge.net
> > > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > Subject: Slowness forming TIPC cluster with explicit node
> > > > addresses
> > > >
> > > > Hi,
> > > >
> > > > I'm having problems forming a TIPC cluster between 2 nodes.
> > > >
> > > > This is the basic steps I'm going through on each node.
> > > >
> > > > modprobe tipc
> > > > ip link set eth2 up
> > > > tipc node set addr 1.1.5 # or 1.1.6 tipc bearer enable media eth
> > > > dev eth0
> > > eth2, I assume...
> > >
> > Yes sorry I keep switching between between Ethernet ports for testing
> > so I hand edited the email.
> >
> > >
> > > >
> > > >
> > > >
> > > > Then to confirm if the cluster is formed I use tipc link list
> > > >
> > > > [root@node-5 ~]# tipc link list
> > > > broadcast-link: up
> > > > ...
> > > >
> > > > Looking at tcpdump the two nodes are sending packets
> > > >
> > > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60 bytes,
> > > > MessageSize
> > > > 76 bytes, Neighbor Detection Protocol internal, messageType Link
> > > > request
> > > > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60 bytes,
> > > > MessageSize
> > > > 76 bytes, Neighbor Detection Protocol internal, messageType Link
> > > > request
> > > >
> > > > Eventually (after a few minutes) the link does come up
> > > >
> > > > [root@node-6 ~]# tipc link list
> > > > broadcast-link: up
> > > > 1001006:eth2-1001005:eth2: up
> > > >
> > > > [root@node-5 ~]# tipc link list
> > > > broadcast-link: up
> > > > 1001005:eth2-1001006:eth2: up
> > > >
> > > > When I remove the "tipc node set addr" things seem to kick into
> > > > life straight away
> > > >
> > > > [root@node-5 ~]# tipc link list
> > > > broadcast-link: up
> > > > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up
> > > >
> > > > So there appears to be some difference in behaviour between having
> > > > an explicit node address and using the default. Unfortunately our
> > > > application relies on setting the node addresses.
> > > I do this many times a day, without any problems. If there would be
> > > any time difference, I would expect the 'auto configurable' version
> > > to be slower, because it involves a DAD step.
> > > Are you sure you don't have any other nodes running in your system?
> > >
> > > ///jon
> > >
> > Nope the two nodes are connected back to back. Does the number of
> > Ethernet interfaces make a difference? As you can see I've got 3 on
> > each node. One is completely disconnected, one is for booting over
> > TFTP
> > (only used by U-boot) and the other is the USB Ethernet I'm using for
> > testing.
> >
>
> So I can still reproduce this on nodes that only have one network interface
> and
> are the only things connected.
>
> I did find one thing that helps
>
> diff --git a/net/tipc/discover.c b/net/tipc/discover.c index
> c138d68e8a69..49921dad404a 100644
> --- a/net/tipc/discover.c
> +++ b/net/tipc/discover.c
> @@ -358,10 +358,10 @@ int tipc_disc_create(struct net *net, struct
> tipc_bearer *b,
> tipc_disc_init_msg(net, d->skb, DSC_REQ_MSG, b);
>
> /* Do we need an address trial period first ? */
> - if (!tipc_own_addr(net)) {
> +// if (!tipc_own_addr(net)) {
> tn->addr_trial_end = jiffies + msecs_to_jiffies(1000);
> msg_set_type(buf_msg(d->skb), DSC_TRIAL_MSG);
> - }
> +// }
> memcpy(>dest, dest, sizeof(*dest));
> d->net = net;
> d->bearer_id = b->identity;
>
> I think because with pre-configured addresses the duplicate address detection
> is skipped the shorter init phase is skipped. Would is make sense to
> unconditionally do the trial step? Or is there some better way to get things
> to
> transition with pre-assigned addresses.
I am on vacation until the end of next-week, so I can't give you any good
analysis right now.
To do the trial step doesn’t make much sense to me, -it would only delay the
setup unnecessarily (but with only 1 second).
Can you check the initial value of addr_trial_end when there a pre-configured
address?
///jon
Re: Slowness forming TIPC cluster with explicit node addresses
On Mon, 2019-07-29 at 09:04 +1200, Chris Packham wrote:
> On Fri, 2019-07-26 at 13:31 +, Jon Maloy wrote:
> >
> >
> > >
> > >
> > > -Original Message-
> > > From: netdev-ow...@vger.kernel.org
> > > On
> > > Behalf Of Chris Packham
> > > Sent: 25-Jul-19 19:37
> > > To: tipc-discuss...@lists.sourceforge.net
> > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > Subject: Slowness forming TIPC cluster with explicit node
> > > addresses
> > >
> > > Hi,
> > >
> > > I'm having problems forming a TIPC cluster between 2 nodes.
> > >
> > > This is the basic steps I'm going through on each node.
> > >
> > > modprobe tipc
> > > ip link set eth2 up
> > > tipc node set addr 1.1.5 # or 1.1.6
> > > tipc bearer enable media eth dev eth0
> > eth2, I assume...
> >
> Yes sorry I keep switching between between Ethernet ports for testing
> so I hand edited the email.
>
> >
> > >
> > >
> > >
> > > Then to confirm if the cluster is formed I use tipc link list
> > >
> > > [root@node-5 ~]# tipc link list
> > > broadcast-link: up
> > > ...
> > >
> > > Looking at tcpdump the two nodes are sending packets
> > >
> > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60 bytes,
> > > MessageSize
> > > 76 bytes, Neighbor Detection Protocol internal, messageType Link
> > > request
> > > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60 bytes,
> > > MessageSize
> > > 76 bytes, Neighbor Detection Protocol internal, messageType Link
> > > request
> > >
> > > Eventually (after a few minutes) the link does come up
> > >
> > > [root@node-6 ~]# tipc link list
> > > broadcast-link: up
> > > 1001006:eth2-1001005:eth2: up
> > >
> > > [root@node-5 ~]# tipc link list
> > > broadcast-link: up
> > > 1001005:eth2-1001006:eth2: up
> > >
> > > When I remove the "tipc node set addr" things seem to kick into
> > > life straight
> > > away
> > >
> > > [root@node-5 ~]# tipc link list
> > > broadcast-link: up
> > > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up
> > >
> > > So there appears to be some difference in behaviour between
> > > having
> > > an
> > > explicit node address and using the default. Unfortunately our
> > > application
> > > relies on setting the node addresses.
> > I do this many times a day, without any problems. If there would be
> > any time difference, I would expect the 'auto configurable' version
> > to be slower, because it involves a DAD step.
> > Are you sure you don't have any other nodes running in your system?
> >
> > ///jon
> >
> Nope the two nodes are connected back to back. Does the number of
> Ethernet interfaces make a difference? As you can see I've got 3 on
> each node. One is completely disconnected, one is for booting over
> TFTP
> (only used by U-boot) and the other is the USB Ethernet I'm using
> for
> testing.
>
So I can still reproduce this on nodes that only have one network
interface and are the only things connected.
I did find one thing that helps
diff --git a/net/tipc/discover.c b/net/tipc/discover.c
index c138d68e8a69..49921dad404a 100644
--- a/net/tipc/discover.c
+++ b/net/tipc/discover.c
@@ -358,10 +358,10 @@ int tipc_disc_create(struct net *net, struct
tipc_bearer *b,
tipc_disc_init_msg(net, d->skb, DSC_REQ_MSG, b);
/* Do we need an address trial period first ? */
- if (!tipc_own_addr(net)) {
+// if (!tipc_own_addr(net)) {
tn->addr_trial_end = jiffies + msecs_to_jiffies(1000);
msg_set_type(buf_msg(d->skb), DSC_TRIAL_MSG);
- }
+// }
memcpy(>dest, dest, sizeof(*dest));
d->net = net;
d->bearer_id = b->identity;
I think because with pre-configured addresses the duplicate address
detection is skipped the shorter init phase is skipped. Would is make
sense to unconditionally do the trial step? Or is there some better way
to get things to transition with pre-assigned addresses.
Re: Slowness forming TIPC cluster with explicit node addresses
On Fri, 2019-07-26 at 13:31 +, Jon Maloy wrote: > > > > > -Original Message- > > From: netdev-ow...@vger.kernel.org > > On > > Behalf Of Chris Packham > > Sent: 25-Jul-19 19:37 > > To: tipc-discuss...@lists.sourceforge.net > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > > Subject: Slowness forming TIPC cluster with explicit node addresses > > > > Hi, > > > > I'm having problems forming a TIPC cluster between 2 nodes. > > > > This is the basic steps I'm going through on each node. > > > > modprobe tipc > > ip link set eth2 up > > tipc node set addr 1.1.5 # or 1.1.6 > > tipc bearer enable media eth dev eth0 > eth2, I assume... > Yes sorry I keep switching between between Ethernet ports for testing so I hand edited the email. > > > > > > Then to confirm if the cluster is formed I use tipc link list > > > > [root@node-5 ~]# tipc link list > > broadcast-link: up > > ... > > > > Looking at tcpdump the two nodes are sending packets > > > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60 bytes, > > MessageSize > > 76 bytes, Neighbor Detection Protocol internal, messageType Link > > request > > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60 bytes, > > MessageSize > > 76 bytes, Neighbor Detection Protocol internal, messageType Link > > request > > > > Eventually (after a few minutes) the link does come up > > > > [root@node-6 ~]# tipc link list > > broadcast-link: up > > 1001006:eth2-1001005:eth2: up > > > > [root@node-5 ~]# tipc link list > > broadcast-link: up > > 1001005:eth2-1001006:eth2: up > > > > When I remove the "tipc node set addr" things seem to kick into > > life straight > > away > > > > [root@node-5 ~]# tipc link list > > broadcast-link: up > > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up > > > > So there appears to be some difference in behaviour between having > > an > > explicit node address and using the default. Unfortunately our > > application > > relies on setting the node addresses. > I do this many times a day, without any problems. If there would be > any time difference, I would expect the 'auto configurable' version > to be slower, because it involves a DAD step. > Are you sure you don't have any other nodes running in your system? > > ///jon > Nope the two nodes are connected back to back. Does the number of Ethernet interfaces make a difference? As you can see I've got 3 on each node. One is completely disconnected, one is for booting over TFTP (only used by U-boot) and the other is the USB Ethernet I'm using for testing. > > > > > > > [root@node-5 ~]# uname -a > > Linux linuxbox 5.2.0-at1+ #8 SMP Thu Jul 25 23:22:41 UTC 2019 ppc > > GNU/Linux > > > > Any thoughts on the problem?
RE: Slowness forming TIPC cluster with explicit node addresses
> -Original Message- > From: netdev-ow...@vger.kernel.org On > Behalf Of Chris Packham > Sent: 25-Jul-19 19:37 > To: tipc-discuss...@lists.sourceforge.net > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Slowness forming TIPC cluster with explicit node addresses > > Hi, > > I'm having problems forming a TIPC cluster between 2 nodes. > > This is the basic steps I'm going through on each node. > > modprobe tipc > ip link set eth2 up > tipc node set addr 1.1.5 # or 1.1.6 > tipc bearer enable media eth dev eth0 eth2, I assume... > > Then to confirm if the cluster is formed I use tipc link list > > [root@node-5 ~]# tipc link list > broadcast-link: up > ... > > Looking at tcpdump the two nodes are sending packets > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60 bytes, MessageSize > 76 bytes, Neighbor Detection Protocol internal, messageType Link request > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60 bytes, MessageSize > 76 bytes, Neighbor Detection Protocol internal, messageType Link request > > Eventually (after a few minutes) the link does come up > > [root@node-6 ~]# tipc link list > broadcast-link: up > 1001006:eth2-1001005:eth2: up > > [root@node-5 ~]# tipc link list > broadcast-link: up > 1001005:eth2-1001006:eth2: up > > When I remove the "tipc node set addr" things seem to kick into life straight > away > > [root@node-5 ~]# tipc link list > broadcast-link: up > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up > > So there appears to be some difference in behaviour between having an > explicit node address and using the default. Unfortunately our application > relies on setting the node addresses. I do this many times a day, without any problems. If there would be any time difference, I would expect the 'auto configurable' version to be slower, because it involves a DAD step. Are you sure you don't have any other nodes running in your system? ///jon > > [root@node-5 ~]# uname -a > Linux linuxbox 5.2.0-at1+ #8 SMP Thu Jul 25 23:22:41 UTC 2019 ppc > GNU/Linux > > Any thoughts on the problem?
