ipfw fwd and multicast mac address

[Eugene Perevyazko]

On Tue, Mar 08, 2011 at 08:25:09PM +0100, Luigi Rizzo wrote:
> On Fri, Mar 04, 2011 at 05:55:38AM +0200, Eugene Perevyazko wrote:
> > Hi
> > 
> > I've stumbled on a pretty strange issue in combination of ipfw fwd rules
> > with multicast.
> >  The system is 7-Stable.
> >  It runs ospf, that uses MC groups 224.0.0.5 and 224.0.0.6. Normally those groups use dst mac addresses of 01:00:5e:00:00:05 and 01:00:5e:00:00:06 respectively
> > where last 4 bytes are taken from group's IP.
> >  Then I needed to add some fwd rules like this:
> > fwd 192.168.31.14 out xmit em0
> > (em0 is the interface on which ospf is running)
> > Somehow after that MC dst mac has got 2 bytes changed:
> > 224.0.0.5 got 01:00:5e:a8:1f:05 and 224.0.0.6 got 01:00:5e:a8:1f:06
> > "a8:1f" clearly is "168.31" from fwd destination.
> > Of course this means no ospf anymore.
> > I've fixed this by adding "pass dst-ip 224.0.0.0/8" before "fwd" but
> > it has made my evening much more lively until I figured what's happening.
> > 
> > The question is if this is intended consequence and if yes then why change
> > only two bytes instead of four (irony intended)? 
> 
> i am unclear whether the 224/8 packets are expected to match
> your "fwd" rule (fwd works by overwriting the dst-mac address,
> though you should see the one corresponding to 192.168.31.14),
> or they are not expected to match, in which case of course
> the packet should not be modified at all.
> 
> In any case it is really weird that the final byte (05, 06) is
> intact -- ipfw manages IP addresses as uint32 so i would have
> expected the final byte to be modified as well.
> 
> cheers
> luigi
> 

  I've repeated similar setup in lab environment with both 7 and 8 branches
and must admit that final byte is modified too. Also 3rd byte is masked 
with 127.
  So dst mac is formed from fwd destination's IP in accordance to standards.
(http://www.tcpipguide.com/free/t_TCPIPAddressResolutionForIPMulticastAddresses.htm being the reference)
  Although I can't imagine the need for such modification of multicast packet
it is pretty logical and easily avoided with appropriate ruleset.
May be it's just worth mentioning in man page of ipfw?

Sorry for the noise.

-- 
Eugene Perevyazko