Bug 426842

Created attachment 290444 [details]
The following text file contains Ethernet Channel Bonding Configuration Details and Other Details

Balaji,

There could be a couple of causes - right now we think this might be a
documentation issue; i.e. the instructions are wrong or unclear.  

We're reviewing the documentation to see if there are any errors, and will let
you know if we find any.

(In reply to comment #4)
> Balaji,
> 
> There could be a couple of causes - right now we think this might be a
> documentation issue; i.e. the instructions are wrong or unclear.  
> 
> We're reviewing the documentation to see if there are any errors, and will let
> you know if we find any.

Sir,

 Can you help me to solve the above problem and it is very urgent or send me any
other Alternate Configuration details for Ethernet Channel Bonding

Regards
-S.Balaji
   

The documentation looks correct, and your configuration looks correct.

I'm not sure what would cause it to fail in your tests - as I understand it,
without channel bonding, everything works, but with channel bonding, we end up
with two sub-clusters (for some reason, both become quorate).

Note -- more configuration information here:

https://www.redhat.com/archives/linux-cluster/2008-February/msg00349.html

Dear All,
 I have refered
(https://www.redhat.com/archives/linux-cluster/2008-February/msg00349.html) this
Configuration Details as you send and that configuration details and query is
send by myself and but the solution is not given.
 
 I need clarification about Ethernet Channel Bonding will work with Fence Device
or without fence device.
 
Regards
-S.Balaji
  
 
(In reply to comment #5)
> (In reply to comment #4)
> > Balaji,
> > 
> > There could be a couple of causes - right now we think this might be a
> > documentation issue; i.e. the instructions are wrong or unclear.  
> > 
> > We're reviewing the documentation to see if there are any errors, and will let
> > you know if we find any.
> 
> Sir,
> 
>  Can you help me to solve the above problem and it is very urgent or send me any
> other Alternate Configuration details for Ethernet Channel Bonding
> 
> Regards
> -S.Balaji
>    

Ethernet bonding is supposed to be transparent to applications (this includes
cman and fencing), so your configuration *should* work with fencing.  It looks
like your bonded interface is correctly configured, which is why we're having
trouble identifying the problem.

Attaching your cluster.conf to the bugzilla would be helpful.  

Created attachment 301748 [details]
My Cluster Configuration File

The configuration file looks OK, but it's hard to be sure without knowing what
IP addresses the names resolve to. I do recommend that you use fully-qualified
host names in cluster.conf as this can avoid some ambiguities.

Can you please attach the output of the commands

 cman_tool status
 cman_tool nodes

to the bugzilla please ?
It's also worth you checking that the IP addresses shown in "cman_tool status"
match those that you are expecting.

It might also be worthwhile doing a tcpump of the communications between the two
nodes (please do this on both nodes so we can see if/where the communications is
missing). The command is

  tcpdump -xs0 -w cman-tcpdump.dmp port 6809

You might also like to read this document which discusses how cman uses the
network, and how to do some diagnostics for yourself:

http://people.redhat.com/ccaulfie/docs/CSNetworking.pdf

What's odd is the node(s) became quorate and reportedly started services in a
two_node="1" cluster w/o any fencing.  (Looked @ cluster.conf)

(see comment #1)

Dear All,
  For your Verification 
  cman_tool status and  cman_tool nodes outputs after Ethernet Channel Bonding in RHEL Cluster Suite details are added below

Before Bonding:
corviewprimary: cman_tool status
Protocol version: 5.0.1
Config version: 106
Cluster name: EMSCluster
Cluster ID: 11444
Cluster Member: Yes
Membership state: Cluster-Member
Nodes: 2
Expected_votes: 1
Total_votes: 2
Quorum: 1
Active subsystems: 4
Node name: corviewprimary
Node ID: 1
Node addresses: 192.168.13.110

corviewsecondary: cman_tool status
Protocol version: 5.0.1
Config version: 106
Cluster name: EMSCluster
Cluster ID: 11444
Cluster Member: Yes
Membership state: Cluster-Member
Nodes: 2
Expected_votes: 1
Total_votes: 2
Quorum: 1
Active subsystems: 4
Node name: corviewsecondary
Node ID: 2
Node addresses: 192.168.13.179


After Bonding:
corviewprimary: cman_tool status
Protocol version: 5.0.1
Config version: 106
Cluster name: EMSCluster
Cluster ID: 11444
Cluster Member: Yes
Membership state: Cluster-Member
Nodes: 1
Expected_votes: 1
Total_votes: 1
Quorum: 1
Active subsystems: 4
Node name: corviewprimary
Node ID: 1
Node addresses: 192.168.13.110


corviewsecondary: cman_tool status
Protocol version: 5.0.1
Config version: 106
Cluster name: EMSCluster
Cluster ID: 11444
Cluster Member: Yes
Membership state: Cluster-Member
Nodes: 1
Expected_votes: 1
Total_votes: 1
Quorum: 1
Active subsystems: 4
Node name: corviewsecondary
Node ID: 1
Node addresses: 192.168.13.179

cman_tools nodes at primary after bonding
Node  Votes Exp Sts  Name
   1    1    1   M   corviewprimary

cman_tools nodes at secondary after bonding
Node  Votes Exp Sts  Name
   1    1    1   M   corviewsecondary

Regards
-S.Balaji

Thank you.

So that proves that cman is using the correct IP addresses for bonding, and it's now very clear that traffic is not flowing between the two systems - at least not cman traffic. Have you checked that you can ping and (if appropriate) ssh between the two system with bonding enabled?

If you have iptables set up then it is worth reviewing those rules so that they are applicable to the bonded interfaces.

If all this looks OK, then I'm a little stumped. It could be that, for some reason, only multicast traffic is not being passed correctly over the bonded interfaces. 'ip maddr list' might be able to shed some light on this.

Nothing has happened on this bug for 10 months now so I'm going to close it. If there is any more information or a reproducible recurrence then feel free to re-open it.