Shaik Bajeed wrote:
> I am using Soalris 10, with C++ language.
Before we get too deep into this issue, you should know that this list
is for OpenSolaris, not Solaris 10. If you're using Solaris 10, you
should be working with Sun's technical support group. They offer
support plans for their commercial versions of Solaris.
> My product has 4 Gigabit ports, of which 2 ports are used for multicat data,
> these two ports are configured as primary and backup.
>
> primary is configured with actual ip address (192.168.200.148) and backup is
> configures with 0.0.0.0 and both are plumb up and running.
> agamin two of my devices will be configured in redundant mode with multicast
> heartbeat message between them. the primary
> device will send heartbeat message to backup device. the backup device will
> receive it and thinks that primary is up.
> If backup device does not receive any hearbeat in say 2 seconds, it will
> assume itself as primry and starts streaming heatbeat messages.
First off, if you've configured an IP interface with address 0.0.0.0, I
wouldn't expect that you can receive packets on it (at least not
reliably) unless you are using DLPI. I think you're wandering into
uncharted territory with that scheme.
That aside, I don't understand why you're doing this. Are you aware of
IPMP? What you're describing sounds like the primary purpose of IPMP.
Why reinvent the wheel?
> when i switch port from say primary port to backup port on primary device, I
> will unplumb the bge0, and bge1 interface and and re plumb them back with
> bge1 having actual ip address (192.168.200.148) and bge0 with 0.0.0.0. the
> problem i am seeing is that, what ever heartbeat packets that are being sent
> from bge1 are not going onto network until after 32 seconds of plumb up, and
> the new port does not receive anything from other device too for 32 seconds.
> however if snoop on bge0, i see packets from other device being received on
> that previous active port.
>
> so my question is if i reuse the ip address from bge0 to bge1, and set bge0
> to 0.0.0.0. why is that packets sent from bge1 are not sent out until 32
> seconds. at the same time the new port does not receive heartbeat packets
> from other device also for 32 seconds, the packets are still being routed to
> bge0.
>
> any help with this issue will be highly appreciated.
There are several things that could cause symptoms like that, and you
may need a network analyzer or other equipment to get to the bottom of it.
A couple of guesses are:
1. The timing seems a little long, but it's possibly caused by Spanning
Tree. If the ports on your local bridge ("switch") are not specially
configured as leaf ports, then the standards require the bridge to
disable communication each time the link status is established for a
period of up to 30 seconds in order to detect another bridge and avoid
establishing a forwarding loop.
If that's the problem, then I have a few suggestions. First of all, why
are you unplumbing? That's not necessary. Just change the address and
be done with it. There's nothing wrong with changing the IP address of
an interface without taking it down. In fact, when you unplumb the
interface, most drivers will disable the port, and many will actually
drop link status.
Second, check the bridge configuration. See if you can't configure
those ports with "STP disabled" or as "non-trunk ports" or as
"portfast." Different manufacturers have different names for this; read
the bridge documentation.
2. It's remotely possible that the bridge you're attached to has some
sort of "IP spoofing protection" mechanism. Again, you'll need to check
the documentation. It would not be completely unreasonable for a
regular wired bridge to disable a port when it sees the IP address that
belongs on another port, with a different Ethernet address, and without
seeing a TC (topology change) notification from other bridges.
If that's the problem, you'll need to read through the bridge documentation.
--
James Carlson 42.703N 71.076W <[email protected]>
_______________________________________________
networking-discuss mailing list
[email protected]
