Bruce M. Simpson wrote:
Max Laier wrote:
Alternatively you could change IPPROTO_CARP in netinet/in.h to another
unused protocol number. This is really the preferred way of dealing
with mixed CARP and VRRP environments as the CARP packets might in
turn irritate the VRRP routers, too.
This seems to make the most sense to me. At this time it seems (in
RELENG_6_2 at least) that because the protocol number is shared with
VRRP that tcpdump tries to decode the CARP frames as VRRP frames and
although the header/frame is very simple this does not provide a useful
decoding of the CARP frame.
After the protocol number is changed it would be possible to write a
proper carp decoder for tcpdump or at least make any existing decoder be
able to tell the difference between VRRP and CARP frames.
This sounds like a common use case. Perhaps there is motivation for
making the protocol number used by CARP a loader tunable?
[I'd really like it if we had a kernel API for adding the virtual MAC
addresses to ifnet too, then again I'd like the cheat for infinite
chocolate fudge sundaes in life, bed and breakfast at The Savoy with my
choice of actress, etc]
/* no comment */
No disrespect to anyone intended, just that CARP does duplicate the
functionality of VRRP.
Please correct me if I am wrong, from the limited research I have done,
carp was born because Cisco made a patent claim (based on its patents
for HSRP) against a VRRP implementation.
It's worth reiterating that this is what happens when software patents
are allowed to creep in to the nuts and bolts of the operational
Internet -- and thus, CARP was born, and thus Tom runs into the issue he
has seen.
later
BMS
Thoughts?
Tom
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
