Forum Discussion

ecce's avatar
ecce
Icon for Cirrostratus rankCirrostratus
Nov 16, 2018

Failover status error on internal interface

In my VE Lab environment I have two VE's in sync-failover configuration. I have two failover networks, the (only) inside vlan and management network. However something seems wrong:

root@(bigip2)(cfg-sync In Sync)(Standby)(/Common)(tmos) show cm failover-status

--------------------
CM::Failover Status
--------------------
Color    gray
Status   STANDBY
Summary  1/1 standby
Details

--------------------------------------------------------------------------------------------
CM::Failover Connections
Local Failover Address  Remote Device     Packets  Transitions  Received Last Packet  Status
--------------------------------------------------------------------------------------------
10.1.20.2:1026          bigip1.study.lab  0        1            -                     Error
192.168.14.112:1026     bigip1.study.lab  774520   1            2018-Nov-16 08:11:22  Ok

Warning(s):
Only receiving failover updates from bigip1.study.lab on 1 failover interfaces, out of 2.

When I tcpdump the inside vlan (that has the 10.1.20.0/24 network) I see failover packets going both ways (snipped the output):

root@(bigip2)(cfg-sync In Sync)(Standby)(/Common)(tmos) tcpdump -nni inside.vlan port 1026
 out slot1/tmm0 lis=
08:07:26.132896 IP 10.1.20.1.63468 > 10.1.20.2.1026: failover_packet {
   failover_packet_cluster_mgmt_ip ip_address 192.168.14.113
   failover_packet_slot_id uword 0
   failover_packet_state ulong 7
   failover_packet_sub_state ulong 0
   failover_packet_monitor_fault ulong 0
   failover_packet_hop_cnt uword 1
   failover_packet_peer_signal ulong 0
   failover_packet_version ulong 2
   failover_packet_msg_bits ulong 2
   failover_packet_traffic_grp_score ulong 5118
   failover_packet_device_load ulong 1
   failover_packet_device_capacity ulong 0
   failover_packet_traffic_group_load ulong 0
   failover_packet_build_num ulong 4158237899
   failover_packet_next_active ulong 0
   failover_packet_traffic_grp string `/Common/traffic-group-1`
   failover_packet_previous_active ulong 0
   failover_packet_active_reason ulong 8
   failover_packet_left_active_reason ulong 0
}
 in slot1/tmm0 lis=
08:07:26.133414 IP 10.1.20.2.8775 > 10.1.20.1.1026: failover_packet {
   failover_packet_cluster_mgmt_ip ip_address 192.168.14.112
   failover_packet_slot_id uword 0
   failover_packet_state ulong 5
   failover_packet_sub_state ulong 0
   failover_packet_monitor_fault ulong 0
   failover_packet_hop_cnt uword 2
   failover_packet_peer_signal ulong 0
   failover_packet_version ulong 2
   failover_packet_msg_bits ulong 2
   failover_packet_traffic_grp_score ulong 5102
   failover_packet_device_load ulong 1
   failover_packet_device_capacity ulong 0
   failover_packet_traffic_group_load ulong 1
   failover_packet_build_num ulong 4158237899
   failover_packet_next_active ulong 1
   failover_packet_traffic_grp string `/Common/traffic-group-1`
   failover_packet_previous_active ulong 1
   failover_packet_active_reason ulong 0
   failover_packet_left_active_reason ulong 1
}

AFM is provisioned, that's the only thing I can see that would stop the packets. Default action is set to ALLOW (for now). I've also tried settings Security Policy on the SelfIP allowing failover traffic, but that does not fix the problem.

Why does it says error on one interface?

No RepliesBe the first to reply