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?
Not sure I understand the working of all of these, please help me out here?
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