From: sabat <sabat@eloan.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] VRRPD (rfc2338)
Date: Fri, 13 Dec 2002 19:17:54 +0000 [thread overview]
Message-ID: <marc-lartc-103980713230331@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103950635007394@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 4430 bytes --]
Dmitry Golubev wrote:
>Hello,
>
>And then bridge these interfaces together? I do not want to use any king of
>switch simply to make the card respond for multiple MAC addrs. Moreover
>I have seen VLAN probems with some eth cards that cannot work with
>1504 byte packets
>
Well, any good switch (at least Cisco) has spanning tree on so that such
a bridge loop would not actually happen. But no, I mean that only the
'live' router would have this MAC address. Maybe I don't understand what
you're saying, exactly, but multiple MACs are how things are done in
VRRP anyway. It's just a matter of whether you want multicast MACs or not.
>
>Anyway, Alexandre claims VLAN solution hacky. Do You use it in production?
>
I don't use it in production yet -- I'm about to start testing -- but I
got the idea from someone who does use it in production, and seems quite
satisfied that it works well, hacky or not. :) Check out the Linux
Virtual Router Project: http://www.cs.fiu.edu/~flynnj/work/virtrouter.html
>
>BR, Dmitry
>
>======= At 2002-12-12, 15:05:00 you wrote: =======
>
>
>
>>Dmitry Golubev wrote:
>>
>>
>>
>>>But as far as I know, there is no VRRP implementations that fully comply
>>>with rfc2338 as it requires multiple MAC addresses for the one poor linux
>>>box's interface. Maybe, someone can suggest a working solution of this
>>>problem?
>>>
>>>
>>>
>>Yes, there is a way -- the VLAN code in the linux kernel supports
>>setting the MAC address of virtual interfaces (eth0.5, for instance).
>>AFAIC, this is much superior (in concept) to multicast MACs, given the
>>Cisco problem.
>>
>>
>>
>>>I have seen one idea, but haven't tested it yet (hope someone can try it out):
>>>
>>>To bridge the physical iface with TAP on which the vrrpd (or keepalived) is
>>>running. In that case we could make the VRRP-router that fully comply with RFC.
>>>
>>>For more info see: http://www.math.leidenuniv.nl/pipermail/bridge/2002-June/002021.html
>>>
>>>BR, Dmitry
>>>
>>>======= At 2002-12-11, 03:56:00 you wrote: =======
>>>
>>>
>>>
>>>
>>>
>>>>The daemon at http://www.keepalived.org/ is the VRRPd implementation
>>>>that's supposed to be the best. It's actually part of the Linux Virtual
>>>>Server project (layer 4 load balancer), but the author claims you should
>>>>be able to use it as a pure VRRP daemon -- although when I've read the
>>>>doc, I couldn't figure out how. (But don't be discouraged by my
>>>>impatience. :) It's supposed to be the most mature and ready-for-production.
>>>>
>>>>There's also Jerome Etienne's reference implementation (don't have a
>>>>URL, but it's easy to Google). However, I've heard from more than place
>>>>that this is too proof-of-concept and perhaps not production-worthy.
>>>>Here's a link to a paper about running VRRPd as the hotspare protocol
>>>>for linux firewalls (uses Jerome Etienne's implementation):
>>>>http://www.gnusec.com/resource/security/docs/HAFirewallLinux-VRRP.pdf.
>>>>
>>>>BTW, keep in mind that if you intend to use VRRP in an environment with
>>>>Cisco routers, you'll need to do some work on them too. Cisco routers do
>>>>not accept multicast MAC addresses as legit ARP replies by default.
>>>>Unfortunately, the VRRP RFC and all implementations use multicast MACs.
>>>>What that means is that you'll need to either 1) turn the switch on the
>>>>Cisco routers that makes them accept multicast MAC ARP replies (good),
>>>>or 2) put a static ARP entry in the Cisco routers for the VRRP multicast
>>>>MACs (better).
>>>>
>>>>Hope that helps.
>>>>
>>>>-S
>>>>
>>>>
>>>>Anton Tinchev wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Can someone point me for good VRRPD (rfc2338) implementation on linux.
>>>>>Some stable and live project
>>>>>Thanks
>>>>>
>>>>>_______________________________________________
>>>>>LARTC mailing list / LARTC@mailman.ds9a.nl
>>>>>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>_______________________________________________
>>>>LARTC mailing list / LARTC@mailman.ds9a.nl
>>>>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>LARTC mailing list / LARTC@mailman.ds9a.nl
>>>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>>>
>>>
>>>
>>>
>
>
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 6127 bytes --]
prev parent reply other threads:[~2002-12-13 19:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-10 7:45 [LARTC] VRRPD (rfc2338) Anton Tinchev
2002-12-11 11:56 ` sabat
2002-12-12 23:05 ` sabat
2002-12-13 19:17 ` sabat [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-103980713230331@msgid-missing \
--to=sabat@eloan.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox