Wed, Aug 23, 2017 at 02:06:28PM CEST, libteam(a)ephemeric.online wrote:
Hi Jiri,
Thank you, I have reread the man pages in order to try and understand.
Am I misunderstanding the expected behaviour here?
I'm thinking that tap0 has prio: 100 and tap1 has prio: -10, so if tap0 goes down then
tap1 takes over and upon tap0 coming back up it should take over?
Yes.
Not sure I understand the working of all of these, please help me out here?
It is as you wrote.
>
>On Wed 23 Aug, 10:40, Jiri Pirko wrote:
>> Tue, Aug 22, 2017 at 06:45:19PM CEST, libteam(a)ephemeric.online wrote:
>>
>> [...]
>>
>>
>> >
>> >Running tcpdump, ARP requests start by coming through to tap0 on server,
change to tap1 on server upon link going down but never return to tap0 when link is
restored.
>> >In /var/log/messages client side I see the active port is changed but it
never gets changed back to sticky.
>>
>> I think that you misunderstand what "sticky" means. Quote from
teamd.conf(5):
>>
>> ports.PORTIFNAME.sticky (bool)
>> Flag which indicates if the port is sticky. If set, it means the
port does not get unse‐
>> lected if another port with higher priority or better parameters
becomes available.
>>
>> So the stickyness is on "unselect". If you want to have one iface with
>> higher priority, that always gets selected when it has link, you should
>> setup "prio". Quote from teamd.conf(5):
>>
>> ports.PORTIFNAME.prio (int)
>> Port priority. The higher number means higher priority.
>> _______________________________________________
>> libteam mailing list -- libteam(a)lists.fedorahosted.org
>> To unsubscribe send an email to libteam-leave(a)lists.fedorahosted.org