|
At 10:41 24/08/2001 +0200, Roberto Nibali wrote:
Hello,
> Hm, we better first to put the goals and the possible setups
> on the table. Tonight I'll try to read again the RFC and will reply
> again but for now, IMO, we should consider many things:
I think this is also what I would consider Alexandre. Could you write
down the exact specifications and wishes? Or is it the paper you once
sent, or can I find it on the project's homepage?
Ok will do it tonight ! The first shot is the simple PDF I have sent. I
will write detailed specs tonight.
> - different topologies
Here IMO we need a vrrpd per netentity (physical segment, customer)
> - many cards connected to same shared/switched hub
I think bonding might help here.
Will investigate on it.
> - what fails, all cases for all different scenarios
It's a n*2 matrix, with n being the interfaces and 2 states for
failed/working. With this you can design your desired state
transition table and derive a logical function for failover.
Yes I am currently working on a FSM like this to sync instances.
> - one IP reachable through many devices
It's a routing problem and can be solved as such.
> - is to possible the routing to change short time after the failure
This is not very nice, Julian :)
- think about a maintainance mode, were we temporarly shut down a
service or even a whole netentity.
> When we analyze all setups we can tell whether some tricks will work
> and where. You talk about 2 NICs but I don't know how exactly they are
> connected.
The same over here :)
ETH0 WAN interface connected to a SWITCH or HUB. Same for ETH1. ETH0 accept
Internet traffic.
Will document it.
> > => The VRRP VIP is a simple ip alias on the eth interface.
>
> In Linux you can put local IP on any device. There are small
> number of considerations to put them on specific device.
Well and you can mark it to play a certain role, such as being secondary
(which is will always be, if there is already an IP) or dynamic or
tentative or deprecated.
> Hm, can you append a simple picture for such setup? There are
> many floating setups in my head for similar setups.
I second that.
> > My point of vue is runing one VRRP instance per physical instance.
>
> OK, some rules:
>
> - if you send ARP reply for one IP with specific MAC through one NIC,
> then you have to be able to receive traffic for this MAC through the same
> NIC
:) ooups, didn't think about that one. Good point. Tell me Julian, because
I forgot: Can the proxy_arp come in handy?
> - if you send ARP reply with same MAC through different devices (if you
> receive probes from many devices for this IP) then the result will be
> that you report same VMAC through different devices. Then these NICs
> can be on same hub, the hub will notice two NICs to report same MAC:
> the standards require the replies to be to the link layer source address.
On a Cisco, if you might have VLAN's you instantly freeze the ports. It's
in the CISCO IOS 12.1. No way around this. It's MAC address spoofing and
you will never get away with this.
Ratz : good climbing and solar cream.
Regards,
Alexandre
| 