From: Ben Greear <greearb@candelatech.com>
To: Mark Zipp <mark.r.zipp@gmail.com>
Cc: bridge@osdl.org
Subject: Re: [Bridge] Multiple "br" interfaces for a single bridge ?
Date: Thu, 01 Dec 2005 09:11:19 -0800 [thread overview]
Message-ID: <438F2EB7.40502@candelatech.com> (raw)
In-Reply-To: <a9a0929d0511301826j4be826fao@mail.gmail.com>
Mark Zipp wrote:
> Hi,
>
> We've been recently trying to use VRRP
> (https://sourceforge.net/projects/vrrpd/) to provide redundancy for a
> couple of servers. What we wanted to do was to have both servers be
> VRRP backups for the other. For example :
>
> Server A - eth0
> VRRP Master IP - 10.0.0.1
> VRRP Backup IP - 10.0.0.2
>
> Server B - eth0
> VRRP Master IP - 10.0.0.2
> VRRP Bcakup IP - 10.0.0.1
>
> We'd then put two A records in DNS for the single hostname, and then
> rely DNS round robin to perform basic load balancing between the
> servers. If one of the servers fails, then the other would then take
> over both of the VRRP Master IP addresses. This wouldn't be a perfect
> fail over as any existing TCP sessions would die, however it is enough
> availability for our requirements.
>
> One problem we have is that, due to the way VRRP has to interact with
> kernel ARP, the vrrpd software changes the assigned MAC addresses on
> the interfaces it has been configured to use. Since the above scenario
> would have two VRRP groups, resulting in two different MAC addresses,
> we can't run two instances of VRRP as above using the same ethernet
> interface.
>
> One idea we had was to create a bridge on each server, add eth0 and
> then a couple of dummy interfaces into the bridge, and then have each
> VRRP instance use the a separate dummy interfaces. This would then
> allow the dummy interfaces to have their MAC address changed, and
> would then allow us to run multiple instances of VRRP on the hosts.
>
> Unfortunately when we tried this, we found that because the dummy
> interfaces become "pure" layer 2 interfaces when they are added to a
> bridge, we can't refer to them with VRRP, as they won't talk IP - only
> the bridge "brX" interface for a bridge will. Of course, there is only
> one of them for a bridge, so again we're limited to one VRRP instance
> on the server. Although we didn't expect it to work, we did try
> creating two bridges and assigning the single eth0 interface to both
> them. That didn't work.
>
> Is there a way to somehow create multiple, separate IP interfaces for
> a single bridge ?
>
> The alternative way we were able to get something to work was to use
> VLAN trunk interfaces, as they're IP capable, and are considered
> separate interfaces by VRRP. The drawback was that we'd then have to
> run VLAN trunks into the servers, and also have to have the VRRP
> instances running on different IP subnets. That's certainly an option,
> it was just a bit too complex for what we want to achieve.
>
> If anybody has any suggestions as to how else we might achieve this,
> I'm all ears.
You could try the MAC-VLAN feature in my consolidated patch. MAC-VLANs
give you a virtual interface that has a particular MAC, and packets with
that MAC (or broadcast) are received by it. It's a real network device,
like 802.1Q VLANs, so it will probably work with your VRRP.
My patch is here..there is more than just MAC-VLANs in there, by the way:
http://www.candelatech.com/oss/candela_2.6.13.patch
You'll also need the macvlan_config tool from the VLAN page:
http://www.candelatech.com/~greear/vlan.html
>
> Thanks,
> Mark.
>
> P.S., please CC me as I'm not subscribed to the list.
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/bridge
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
prev parent reply other threads:[~2005-12-01 17:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-01 2:26 [Bridge] Multiple "br" interfaces for a single bridge ? Mark Zipp
2005-12-01 17:11 ` Ben Greear [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=438F2EB7.40502@candelatech.com \
--to=greearb@candelatech.com \
--cc=bridge@osdl.org \
--cc=mark.r.zipp@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.