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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox