Re: OSPF HELLO wrong mask
On Wed, May 15, 2013 at 07:29:04PM +0200, Ondrej Zajicek wrote:
On Wed, May 15, 2013 at 08:33:08PM +0400, Slawa Olhovchenkov wrote:
Interesting What 'show interfaces' and 'show ospf interface' return? And also 'show status' for router id.
ifconfig em0 (full) em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO> ether 68:05:ca:0e:d3:e1 inet 10.254.0.2 netmask 0xffff0000 broadcast 10.254.255.255 inet6 fe80::6a05:caff:fe0e:d3e1%em0 prefixlen 64 scopeid 0x1 inet 185.17.0.1 netmask 0xffffff00 broadcast 185.17.0.255 inet 185.17.1.1 netmask 0xffffff00 broadcast 185.17.1.255 inet6 2a03:e2c0:0:1::1 prefixlen 64 inet 185.17.2.1 netmask 0xffffff00 broadcast 185.17.2.255 inet 185.17.3.1 netmask 0xffffff00 broadcast 185.17.3.255 inet 10.90.90.1 netmask 0xfffffff0 broadcast 10.90.90.15 inet 193.93.192.1 netmask 0xfffffc00 broadcast 193.93.195.255 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active
So this is a problem with multiple IPs on an iface. On BSD, we support just one primary address in OSPF (others are just handled as stubs). Lexicographically smallest address was chosen. Unfortunately the kernel chose a different one as a source address.
Why lexicographically smallest? Why not first from getifaddrs() list?
If you use multiple IPs on an iface in BSD with BIRD, you have to use option 'primary' of device protocol to specify the proper one: http://bird.network.cz/?get_doc&f=bird-6.html#ss6.2
10x, working.
On 15.05.2013 21:18, Slawa Olhovchenkov wrote:
On Wed, May 15, 2013 at 07:29:04PM +0200, Ondrej Zajicek wrote:
On Wed, May 15, 2013 at 08:33:08PM +0400, Slawa Olhovchenkov wrote:
Interesting What 'show interfaces' and 'show ospf interface' return? And also 'show status' for router id. ifconfig em0 (full) em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO> ether 68:05:ca:0e:d3:e1 inet 10.254.0.2 netmask 0xffff0000 broadcast 10.254.255.255 inet6 fe80::6a05:caff:fe0e:d3e1%em0 prefixlen 64 scopeid 0x1 inet 185.17.0.1 netmask 0xffffff00 broadcast 185.17.0.255 inet 185.17.1.1 netmask 0xffffff00 broadcast 185.17.1.255 inet6 2a03:e2c0:0:1::1 prefixlen 64 inet 185.17.2.1 netmask 0xffffff00 broadcast 185.17.2.255 inet 185.17.3.1 netmask 0xffffff00 broadcast 185.17.3.255 inet 10.90.90.1 netmask 0xfffffff0 broadcast 10.90.90.15 inet 193.93.192.1 netmask 0xfffffc00 broadcast 193.93.195.255 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active So this is a problem with multiple IPs on an iface. On BSD, we support just one primary address in OSPF (others are just handled as stubs). Lexicographically smallest address was chosen. Unfortunately the kernel chose a different one as a source address. Why lexicographically smallest? Why not first from getifaddrs() list? I've got the following patch, which works for CARP instances, and should work in your case.
If you use multiple IPs on an iface in BSD with BIRD, you have to use option 'primary' of device protocol to specify the proper one: http://bird.network.cz/?get_doc&f=bird-6.html#ss6.2 10x, working.
On Wed, May 15, 2013 at 09:18:10PM +0400, Slawa Olhovchenkov wrote:
So this is a problem with multiple IPs on an iface. On BSD, we support just one primary address in OSPF (others are just handled as stubs). Lexicographically smallest address was chosen. Unfortunately the kernel chose a different one as a source address.
Why lexicographically smallest? Why not first from getifaddrs() list?
Well, this is mainly a consequence of the facts that primary address selection is currently in platform independent code and on Linux the order of addressess has no real meaning. Therefore it seemed to be a good idea to make it more deterministic, i.e. independent on the order in which the addresses appeared. Perhaps the best idea would be to remove the whole primary address selection (as it does more harm than good) and replace it by platform dependent flag that this address is preferred for the interface (and don't even use this flag on Linux). We enumerate addresses on BSD using CTL_NET / NET_RT_IFLIST sysctl scan. Does anyone know whether is a reliable way to determine which one of returned addresses is the primary one or whether we should just add an another call of SIOCGIFADDR (as suggested by Alexander V. Chernikov)? I would guess it is the first one, but i am not sure if that is specified or just a coincidence. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On 18.05.2013 16:43, Ondrej Zajicek wrote:
On Wed, May 15, 2013 at 09:18:10PM +0400, Slawa Olhovchenkov wrote:
So this is a problem with multiple IPs on an iface. On BSD, we support just one primary address in OSPF (others are just handled as stubs). Lexicographically smallest address was chosen. Unfortunately the kernel chose a different one as a source address. Why lexicographically smallest? Why not first from getifaddrs() list? Well, this is mainly a consequence of the facts that primary address selection is currently in platform independent code and on Linux the order of addressess has no real meaning. Therefore it seemed to be a good idea to make it more deterministic, i.e. independent on the order in which the addresses appeared.
Perhaps the best idea would be to remove the whole primary address selection (as it does more harm than good) and replace it by platform dependent flag that this address is preferred for the interface (and don't even use this flag on Linux).
We enumerate addresses on BSD using CTL_NET / NET_RT_IFLIST sysctl scan. Does anyone know whether is a reliable way to determine which one of returned addresses is the primary one or whether we should just add an It should be the first one, yes. The problem starts when the primary address gets removed. I'm thinking of adding special flag to ifa_flags indicating that address is primary, and either use RTM_NEWADDR to announce new primary address (sent before RTM_DELADDR) or completely new message like RTM_PRIMADDR with the same data.
However, I probably can do this for FreeBSD only, and something has to be implemented for other *BSD flavors..
another call of SIOCGIFADDR (as suggested by Alexander V. Chernikov)? It seems that platform-dependent code with addional constantly open socket calling SIOCGIFADDR on address change is the easiest hack^Wthing to do.. I would guess it is the first one, but i am not sure if that is specified or just a coincidence.
On 18.05.2013 16:43, Ondrej Zajicek wrote:
On Wed, May 15, 2013 at 09:18:10PM +0400, Slawa Olhovchenkov wrote:
So this is a problem with multiple IPs on an iface. On BSD, we support just one primary address in OSPF (others are just handled as stubs). Lexicographically smallest address was chosen. Unfortunately the kernel chose a different one as a source address. Why lexicographically smallest? Why not first from getifaddrs() list? Well, this is mainly a consequence of the facts that primary address selection is currently in platform independent code and on Linux the order of addressess has no real meaning. Therefore it seemed to be a good idea to make it more deterministic, i.e. independent on the order in which the addresses appeared. There seems to be another "driver" for changing this behavior: currently ifa_recalc_all_primary_addresses() simply shuts interface down if primary address disappears. After that, it stays down until the next "device" protocol pass.
This is quite annoying in our scenario: we are using bird to announce load balancers /32 VIPs, and _sometimes_ when one (so-called primary) address is being removed, all other services are disrupted for 10-15 seconds. It seems that the only protocols which are interested in such changes are OSPF (and possibly RIP/IS-IS). Maybe we should consider moving "primary-is-changed" case to protocol-dependent hook without doing nest interface manipulations?
Perhaps the best idea would be to remove the whole primary address selection (as it does more harm than good) and replace it by platform dependent flag that this address is preferred for the interface (and don't even use this flag on Linux).
We enumerate addresses on BSD using CTL_NET / NET_RT_IFLIST sysctl scan. Does anyone know whether is a reliable way to determine which one of returned addresses is the primary one or whether we should just add an another call of SIOCGIFADDR (as suggested by Alexander V. Chernikov)? I would guess it is the first one, but i am not sure if that is specified or just a coincidence.
participants (5)
-
Alexander V. Chernikov -
Alexander V. Chernikov -
Alexander V. Chernikov -
Ondrej Zajicek -
Slawa Olhovchenkov