Date: Wed, 24 Dec 2008 14:03:29 +0000 From: Bruce Simpson <bms@incunabulum.net> To: Ian FREISLICH <ianf@clue.co.za> Cc: Gerald Pfeifer <gerald@pfeifer.com>, Vladimir Grebenschikov <vova@fbsd.ru>, Kip Macy <kip.macy@gmail.com>, Qing Li <qingli@freebsd.org>, freebsd-net@freebsd.org, freebsd-current@freebsd.org, Sergey Matveychuk <sem@FreeBSD.org> Subject: Re: HEADSUP: arp-v2 has been committed Message-ID: <49524131.7010700@incunabulum.net> In-Reply-To: <E1LF09h-0004XQ-O2@clue.co.za> References: <494FAFAC.90802@FreeBSD.org> <E1LEfm2-000BPk-Rs@clue.co.za> <E1LF09h-0004XQ-O2@clue.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian FREISLICH wrote: > ... > I can't quite remember exactly why imr_ifindex doesn't work, but > on my hosts which have several hundred interfaces and my OSPF > sessions are never on the interface that has the default route, > until I explicitly set the imr_address, the kernel always chooses > the interface which has the default route. > Do you have applications which do not explicitly specify the interface address to use for multicast group joins? If they do not, that's a bug in the application -- IPv4 and IPv6 multicast *requires* that a link be specified somehow, either using the new APIs which take an ifindex, or an IPv4 "primary address". Unfortunately there has been historical breakage in the multicast APIs. There are some apps which run before all interfaces have been ifconfig'd up in the system, and they need to create multicast sockets. The kernel behaviour you describe is historical and I had to reintroduce it to avoid breaking such applications. It is a kludge which we probably can't retire until their developers fix their multicast apps to be aware of multiple interfaces on the system. This ground is well covered in the literature and the RFCs. thanks, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49524131.7010700>