On Wed, Aug 23, 2017 at 12:22:03AM +0200, Florian Riehm wrote: > 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).
I see. I also tested with vlan on top of trunk on top of ix. Looking forward to your test results with em. > > My problem is not the multicast error message. I just can't 'see' your > fix, since my interfaces stay down after netstart. You are talking about the interface state in ospfd (ospfctl show int) and not the state displayed by ifconfig, right? > Does your interface come up again, if the multicast error message occurs? No. When this multicast error occurs ospfd can't join the multicast groups anymore. But the interface as displayed with ifconfig is up and has link. I noticed that the vio0 interface has the flag "ALLMULTI" set in addition to "MULTICASST". The interfaces I tested with do not have "ALLMULTI" set. Remi
