Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
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 --]

      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