| Hi Bill
This is contradictory to what is in 2085.9, which suggests that it
doesn't matter whether the responders are on the same LAN/ext LAN or
not.
I have been involved in a number of designs where the responders were
not in the same LAN, and so far, have not heard any complaints of the
redundancy not working.
Can you explain further?
Regards
Jeannie
|
| Today I did tests with the failover, as described in .0.
The failover works pretty good. The failover of the physical connection
is immediate.
But the following must be kept in mind:
As there is bridging between the 2 responders, it lasts a significant
amount of time until the network traffic fails over. In my environment
it was between 20 and 50 seconds. The bridge forwarding tables have to
learn the new configuration.
It seems to work, but: Is this an OFFICIALLY SUPPORTED and RECOMMENDED
configuration ?
Regards,
Karl
|
| re .2
Geezzzzz
We are talking about a repeater being configured with a master port
pair for the sole purpose of providing redundancy, right?
> This is contradictory to what is in 2085.9, which suggests that it
> doesn't matter whether the responders are on the same LAN/ext LAN or
> not.
>
> I have been involved in a number of designs where the responders were
> not in the same LAN, and so far, have not heard any complaints of the
> redundancy not working.
>
These are "REDUNDANT" links! If they don't go to the same LAN or
---------
ELAN what is the point? The primary is the only link that is up
whether the ports connect to two different LAN/ELANs (with no
repeater, bridge, widget connecting them) or not. If they are not
connected then the stations on the other end of the secondary better be
happy just talking among themslves because that's all they can reach.
There is no signaling that occurs between the two responder ports so
there is nothing that requires them to be locating on the same
physically net. It just doesn't make any sense, if we are talking
redundancy, for the other ends of the master port pair to be connected
to physically disjoint Ethernets.
bill
|