So, we have: 1. BindCarrier="list of uplink ports"
2. Network.DownlinkCarrierGroup=1 in upstream interface Network.UplinkCarrierGroup=1 in downstream interface This would mean you have to create 2 new members for the Network structure. 3. If we are to add 2 members then we can also think of adding: Network.UFDGroup = 1; Network.UFDType = uplink/downlink; For the feature to be visible I would say 3, but I'm fine with any of them. Thanks, Alin -----Original Message----- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Thursday, January 29, 2015 3:49 PM To: Zbigniew Jędrzejewski-Szmek Cc: Rauta, Alin; Lennart Poettering; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd В Thu, 29 Jan 2015 15:10:16 +0100 Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> пишет: > On Thu, Jan 29, 2015 at 02:05:10PM +0000, Rauta, Alin wrote: > > What if we don't use the "*" for now and document "BindCarrier" accordingly > > to be a list of port names and no wildcard ? > > Then, if it's the case we can add such "*" support for "BindCarrier" and > > think about all those corner cases ? > > What about interpreting the wildcard dynimically instead? If > eth3 goes down, look at all interfaces which have BindCarrier set, and > check with glob if their BindCarrier setting matches eth3, and act > accordingly. > This means that every time any interface (dis)appears you must go through all existing BindCarrier statements and check whether they apply. This is really ugly. For this reasons I believe uplink group should be first class citizen also internally. And how do you set properties for it? Which of BindCarrierMode statements in different link (or are they network?) files apply if they differ? What if you need to add more properties? What about DownlinkCarrierGroup=1 in upstream interface UplinkCarrierGroup=1 in downstream interface This creates uplink group 1 and binds interfaces to it. Now you only need to care if there is another interface definition that has the same group number. But you still need ability to set group properties (although in practice every switch I have seen is using policy "all" - anyone can give compelling use case for using "any"?), so yes, we may need support configuration object for it. But the first step could be default to policy "all" which does not require any configuration. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
