Solve the problem of oracle11gr2rac node downtime caused by enabling iptables

Generally, when installing a database, the vast majority of users require selinux and iptables to be disabled before installation. However, in the carrier's system, many security factors need to enable iptables on the database host on the current network. When enabling iptables, pay attention to it. for example, the hosts configuration in RAC is as follows: 192.168.142.115subsd. when installing the database, the vast majority of requests require selinux and IptablesDisable and then install. However, in the carrier's system, many security factors need IptablesEnabled.
When enabling iptables, you must note that, for example, the hosts configuration in RAC is as follows:
192.168.142.115 subsdb1 192.168.142.117 subsdb1-vip
10.0.0.115 subsdb1-priv
192.168.142.116 subsdb2 192.168.142.118 subsdb2-vip
10.0.0.116 subsdb2-priv
192.168.142.32 db-scan should allow all the above IP addresses. However, in actual operation, the above IP address has been released, and a database-1 instance is down.
Look at the database's alert log:
Tue Aug 20 00:29:40 2013
IPC Send timeout detected. Sender: ospid 8284 [oracle @ subsdb2 (LMD0)]
Explorer: inst 1 binc 1740332689 ospid 15851
IPC Send timeout to 1.0 inc 10 for msg type 65521 from opid 12
Tue Aug 20 00:29:48 2013
IPC Send timeout detected. Sender: ospid 8276 [oracle @ subsdb2 (PING)]
Explorer: inst 2 binc 1801834534 ospid 8276
Tue Aug 20 00:29:52 2013
Detected an inconsistent instance membership by instance 2
Errors in file/oracle/app/oracle/diag/rdbms/gdordb/GDORDB2/trace/GDORDB2_lmon_8282.trc (incident = 784092 ):
ORA-29740: evicted by instance number 2, group incarnation 12
Incident details in:/oracle/app/oracle/diag/rdbms/gdordb/GDORDB2/incident/incdir_784092/GDORDB2_lmon_8282_i784092.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packagingdetails.
Errors in file/oracle/app/oracle/diag/rdbms/gdordb/GDORDB2/trace/GDORDB2_lmon_8282.trc:
ORA-29740: evicted by instance number 2, group incarnation 12
LMON (ospid: 8282): terminating the instance due to error 29740
Tue Aug 20 00:29:54 2013
ORA-1092: opitsk aborting process
Tue Aug 20 00:29:54 2013
License high water mark = 29
Tue Aug 20 00:29:57 2013
System state dump requested by (instance = 2, osid = 8282 (LMON), summary = [abnormal instance termination].
System State dumped to trace file/oracle/app/oracle/diag/rdbms/gdordb/GDORDB2/trace/GDORDB2_diag_8272.trc
Instance terminated by LMON, pid = 8282
USER (ospid: 31106): terminating the instance
Instance terminated by USER, pid = 31106

From the above point of view, we can initially conclude that there is a problem with internal communication, but how can we solve it?
However, the following information is found in the alert logs of the database and the alert logs of the ASM instance:
Private Interface 'bond2: 1' configured from GPnP for use as your vate interconnect.
[Name = 'bond2: 1', type = 1, ip = 169.254.148.209, mac = 00-25-b5-00-00-67, net = 169.254.0.0/16, mask = 255.255.0.0, use = haip: cluster_interconnect/62]
Public Interface 'bond0' configured from GPnP for use as a publicinterface.
[Name = 'bond0', type = 1, ip = 192.168.142.116, mac = 00-25-b5-00-01-cb, net = 192.168.142.0/24, mask = 255.255.255.0, use = public/1]
Picked latch-free SCN scheme 3
From this information, the RAC internal communication also needs to use the net = 169.254.0.0/16 IP address, and the MOS Doc ID1383737.1 also has this description, finally, I used ifconfig to find that the IP address of the 169 network segment used in the two nodes of RAC is:
169.254.122.59
169.254.148.209
After the two IP addresses are enabled in iptables, the cluster is normal.