On 08/21/17 18:57, Remi Locherer wrote:
On Mon, Jul 24, 2017 at 04:59:46PM +0200, Remi Locherer wrote:
On Fri, Jul 21, 2017 at 06:24:06PM +0200, Remi Locherer wrote:
On Fri, Jul 21, 2017 at 02:45:03PM +0200, Florian Riehm wrote:
On 06/25/17 23:47, Remi Locherer wrote:
Hi,
ospfd does not react nicely when running "sh /etc/netstart if".
This is because adding the same address again do an interface results
in RTM_DELADDR and RTM_NEWADDR. ospfd handles the former but the later.
If this happens ospfd says "interface vether0:192.168.250.1 gone".
Adjacencies on that interface are down and ospfd can not recover.
The below patch adds IMSG_IFADDRADD to deal with that. With it ospfd
logs the following after "ifconfig vether0 192.168.250.1/24" (same address
as active before):
Hi Remi,
thanks for your report and your patch.
I think it is the right approach, but unfortunately it doesn't work in my setup.
If I run 'sh /etc/netstart vio1' vio1 goes down and stays down.
Please have a look to my config / logs. What is the differece between your and
my test?
I tested with an interface connected to stub network. Your output shows an
interface connected to a transit network. In my test setup I did not get the
error message: "if_join_group: error IP_ADD_MEMBERSHIP"
I'll look into it and try to fix this.
I could reproduce the behaviour you see with my patch when testing with
vmm and vio interfaces. It looks like in the IFADDRDEL case the interface
can not leave the multicast group.
I do not see this when testing with vether, pair or vlan (over ix)
interfaces. Could this be a bug with multicast handling in vio?
Today I did a test with an unpatched ospfd and a vio interface in vmm.
I started ospfd and waited till adjacency was up. Then I did
"ifconfig vio0 192.168.250.101/24" (same ip as set before).
The debug output from ospfd:
[...]
if_leave_group: error IP_DROP_MEMBERSHIP, interface vio0 address 224.0.0.5:
Can't assign requested address
if_leave_group: error IP_DROP_MEMBERSHIP, interface vio0 address 224.0.0.6:
Can't assign requested address
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface vio0
orig_rtr_lsa: stub net, interface vether0
if_act_elect: interface vio0 old dr 192.168.250.1 new dr 192.168.250.101, old
bdr 192.168.250.101 new bdr none
orig_rtr_lsa: area 0.0.0.0
[...]
Doing the same with a pair or vether interface does not produce the message
"if_leave_group: error IP_DROP_MEMBERSHIP ....".
My conclusion of this is that the error is problem with the vio driver and
not with my patch for ospfd.
Could we proceed with the proposed ospfd patch and attack the vio problem
separately?
Actually I would be fine with that approach after I am sure it is a vio(4)
problem.
I think vether(4) and pair(4) are a bit too exotic to prove your patch works ;)
Tomorrow I will test your change with em(4).
My problem is not the multicast error message. I just can't 'see' your
fix, since my interfaces stay down after netstart.
Does your interface come up again, if the multicast error message occurs?
friehm
