Hello,
On Tue, 27 Oct 2015, Andy Gospodarek wrote:
> > Of course, we have a semantic problem when setting
> > RTNH_F_LINKDOWN on last address removal, i.e. this event
> > has nothing to do with the link state. But it works because
> > RTNH_F_LINKDOWN is valid for lookups only when DE
On Tue, Oct 27, 2015 at 09:42:25AM +0200, Julian Anastasov wrote:
>
> Hello,
>
> On Tue, 27 Oct 2015, Andy Gospodarek wrote:
>
> > I tested this patch and I now see that your reported problem is a result
> > of dummy never taking carrier down. There was a presumption that
> > carrier noti
Hello,
On Tue, 27 Oct 2015, Andy Gospodarek wrote:
> I tested this patch and I now see that your reported problem is a result
> of dummy never taking carrier down. There was a presumption that
> carrier notification would go down when hardware went down (or when the
> logical device bac
On Mon, Oct 26, 2015 at 11:59:13PM +0200, Julian Anastasov wrote:
> When nexthop is part of multipath route we should clear the
> LINKDOWN flag when link goes UP or when first address is added.
> This is needed because we always set LINKDOWN flag when DEAD flag
> was set but now on UP the nexthop i
When nexthop is part of multipath route we should clear the
LINKDOWN flag when link goes UP or when first address is added.
This is needed because we always set LINKDOWN flag when DEAD flag
was set but now on UP the nexthop is not dead anymore. Examples when
LINKDOWN bit can be forgotten when no NE
