Conference smurf::ase

Hi Manu,

xid_send is simply sending pings (using a DLI socket, with the destination
address the interfaces own - i.e. for the network a no-op but is used to
see if the network interface is still able to send data) out the interface.
If you ifconfig the interface down, you will see this error message.  Also,
if the send queue for the interface backs up, or some other problem.

And, yes, the member name network is special, but you would get this error
message on any monitored interface if you ifconfig it down.

Hope this answers your question,

Rob Marshall
USEG

    Thanks for your reply, Rob.
    
    The problem I am facing is a different behaviour of the Primary network
    versus the other. My ni_ststus_ksh script is movinf the aliasnames from
    a bad interface to a good one as well as changing the "direct" route of
    the network trough the same good interface. To avoid a ping-pong effect
    if a cable connector is giving intermittently bad contacts, I place the
    bad interface "down" as you see. My system has 4 networks (tu0, tu1,
    tu2 and tu3) and when I removed the tu3 cable,  tu0 is receiving the
    aliases previously owned by tu3 and the route is changed accordingly. I
    can then removed tu2 and all is OK. In the script, we defined a minimum
    number of interfaces than should be UP (2) otherwyse I send the
    HSM_LOOK_DISCONNECTED message to HSM. So if 3 off the 4 networks are
    down, the host is disconnected and the service(s) are failed over.
    
    Now, here is the problem. If I remove the cable of tu1, tu2 and tu3
    then the disconnection is done. So far so well. If I remove tu0 first
    and then tu1 and tu2 the script reacts as it should do, i.e. it sends
    the HSM_LOOK_DISCONNECTED message to HSM, but there is no reply from
    the "snd" command and no failover !!! So it appears that tu0 (primary)
    does not behave like the other networks. Also, I discovered that asemgr
    cannot be invoked from the system where tu0 cable is removed. So, the
    question of the original note: Is the primary network needed for
    certain operations that the route change caused by the path_status_awk 
    script does not cover?
    
    Thanks again, 
    
    Manu.
    

Hi,

I guess I wasn't clear enough.  Yes, the primary, or member, network is
special.  All of the daemon-to-daemon traffic runs over that interface.

Normally the packets get to the output routine for the interface, see
that it is destined for one of it's own interfaces, and then re-routes
it via the loopback device (lo0).  But, since you have ifconfig'ed the
interface down, the packets are most likely not getting far enough to
get re-routed, and that is why all of the daemons appear to hang.

I guess I'm not clear on where the advantage is when you ifconfig the
interface down.  What does that really buy you?  And can you NOT do
that for the primary network?

Rob

    Rob,
    
    Thanks for these detailled explanations. I am going to remove the
    "ifconfig tu0 down" command from my script and I will give you the result
    back, later this week.
    
    Reagards,
    Manu.
    

    Rob,
    
    I went yesterday at the customer site, and it is OK now, the message is
    not coming anymore.
    
    I still have some "network route" problem that I have never seen
    before, but I still have to investigate them.
    
    Thanks again,
    
    Manu.