Device protocol not recognizing interface address change

[Israel G. Lugo]

On 13-08-2015 18:37, Ondrej Zajicek wrote:
> 
> So these interfaces are UP but not LOWER_UP in 'ip addr list' output?
> 

This is the situation when BIRD is launched, right after the network
service finishes:

eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
mode DEFAULT qlen 1000

eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
mode DEFAULT qlen 1000

eth0.165 at eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue state LOWERLAYERDOWN mode DEFAULT

eth0.141 at eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue state LOWERLAYERDOWN mode DEFAULT

eth0.1411 at eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue state LOWERLAYERDOWN mode DEFAULT

eth0.2000 at eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue state LOWERLAYERDOWN mode DEFAULT

eth1 is uplink connection to area 0. eth0 is divided into access VLANs.
At this time, all interfaces are UP but NO-CARRIER (driver prepping the
NIC, link being negotiated, etc) => state DOWN.

A few seconds later, we have the transition to normal state:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode
DEFAULT qlen 1000

eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode
DEFAULT qlen 1000

eth0.165 at eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP mode DEFAULT

eth0.141 at eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP mode DEFAULT

eth0.1411 at eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP mode DEFAULT

eth0.2000 at eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP mode DEFAULT


> I guess that you have enabled 'check link' in OSPF?
>

Yes. Stripped configuration follows:

protocol kernel {
  learn;
  persist;
  scan time 20;
  export all;
}

protocol device {
  scan time 30;
}

protocol ospf backbone {
  import filter ...
  export filter ...
  tick 1;
  ecmp yes;
  area 0.0.0.0 {
    stub no;
    interface "eth1" {
      authentication cryptographic;
      password ...
      check link yes;
    };
    interface "lo" { stub; };
  };
  area 0.0.165.0 {
    stub yes;
    summary yes;
    interface "eth0.2000" {
      type ptp;
      check link yes;
    };
    interface "eth0.141", "eth0.165", "eth0.1411" {
      stub;
      check link yes;
    };
    networks {
      ...
    };
  };
}

I just tried to reproduce the problem, by rebooting the router with the
switch ports administratively down. But now the behavior was different:
bird simply died. bird6 is there and running, but the bird process is not.

The only log messages are:

2015-08-13T20:11:09.054662+01:00 gwtsul bird: Started
2015-08-13T20:11:13.001849+01:00 gwtsul bird: backbone: Iface eth1 in
down state?

Is this behavior by design? This is a problem e.g. in case of power
failure. Sometimes the switch takes a minute longer than the PC to come
back up. I would expect OSPF to wait until then.

Regards,

--
Israel G. Lugo
Núcleo de Redes e Comunicações
Direção de Serviços de Informática
Instituto Superior Técnico

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20150813/221a40ff/attachment.asc>