Multicast SSM bug?
Stef Walter
stef-list at memberwebs.com
Thu Sep 10 03:09:32 UTC 2009
Stef Walter wrote:
> The packets from 172.27.2.2 are not being delivered to the ospfd process
> socket (verified via userland debugging and logging). Even though, as
> you can see above the em0 interface is part of the group.
I've done more research on this.
Each time a packet is not delivered, I can see this counter being
incremented:
> # netstat -s -p ip | grep multicast
> 885 packets received for unknown multicast group
That counter originates from this block of code in raw_ip.c:
> 354 blocked = imo_multi_filter(inp->inp_moptions, ifp,
> 355 (struct sockaddr *)&group,
> 356 (struct sockaddr *)&ripsrc);
> 357 if (blocked != MCAST_PASS) {
> 358 IPSTAT_INC(ips_notmember);
> 359 continue;
> 360 }
After instrumenting it with this printf:
> printf("not member: group = %s, ", inet_ntoa (group.sin_addr));
> printf("src = %s, why = %d\n", inet_ntoa (ripsrc.sin_addr), (int)blocked);
Then wait, then up down some interfaces, etc.... quagga adds/drops
memberships, eventually I see the following output:
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
The why = 2 is MCAST_NOTSMEMBER. 172.28.1.66 is the tunnel peer sending
OSPF multicast packets. Somehow imo_multi_filter is limiting via packet
source for this membership. However, this is what the interface looks
like via ifmcstat (ie: no SSM memberships):
> portillo1:
> inet 172.28.1.65
> igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> group 224.0.0.5 mode exclude
> group 224.0.0.1 mode exclude
Any of the above ring a bell? If not, I'll keep poking around and see
what I find.
Cheers,
Stef
More information about the freebsd-net
mailing list