ACE FT Vlan Down

[thomascollins]

I'm trying to configure Fault Tolerance on a pair of 4710s.  I followed the doc, and configured int gi1/4 as the fault tolerance interface, using vlan 12.  However the GUI is saying FT Vlan Down

The troubleshooting wiki said check the physical connectivity, but everything there looks good.  Each ACE can ping it's own IP, but not the router on that VLAN, or the peer.   They're connected to a dedicated VLAN in a switch, and I even tried a crossover cable to directly connect the two.

Here's our config:

ace1/Admin# show running-config ft

Generating configuration....

ft interface vlan 12

  ip address 192.168.12.1 255.255.255.0

  peer ip address 192.168.12.2 255.255.255.0

  no shutdown

ft peer 1

  heartbeat interval 300

  heartbeat count 20

  ft-interface vlan 12

  query-interface vlan 1000

ft group 1

  peer 1

  peer priority 200

  associate-context Admin

  inservice

interface gigabitEthernet 1/4

  description FT

  ft-port vlan 12

  no shutdown

Everything looks good, the interface is up/up, but I can't ping the peer.  Gui shows FT Vlan Down. Here's a show ft peer...

ace1/Admin# show ft peer 1 detail

Peer Id                      : 1

State                        : FSM_PEER_STATE_DOWN

Maintenance mode             : MAINT_MODE_OFF

FT Vlan                      : 12

FT Vlan IF State             : UP

My IP Addr                   : 192.168.12.1

Peer IP Addr                 : 192.168.12.2

Query Vlan                   : 1000

Query Vlan IF State          : UP, Manual validation - please ping peer

Peer Query IP Addr           : 0.0.0.0

Heartbeat Interval           : 300

Heartbeat Count              : 20

Tx Packets                   : 0

Tx Bytes                     : 0

Rx Packets                   : 0

Rx Bytes                     : 0

Rx Error Bytes               : 0

Tx Keepalive Packets         : 0

Rx Keepalive Packets         : 0

TL_CLOSE count               : 0

FT_VLAN_DOWN count           : 0

PEER_DOWN count              : 2

SRG Compatibility            : INIT

License Compatibility        : INIT

FT Groups                    : 1

Any other ideas on what to check?

Thanks

Tom

[ohynderi]

Hi Tom,

It looks the vlan and the physical interface are up. You can anyway check the following to confirm:

sh interface gi 1/4

sh interface vlan 12

In "sh interface gi 1/4 counters", do you see the "RX packets" counter increasing?

You should be able to ping 192.168.12.2 from 192.168.12.1 and vice versa. Which ip did you assign to the other peer. Should be:

ft interface vlan 12

  peer ip address 192.168.12.2 255.255.255.0

  ip address 192.168.12.1 255.255.255.0

  no shutdown

You can check as well "sh ft stats" and see if the heartbeats counter are increasing.

Regarding to other interfaces, you mention that you can't ping devices on the ACE adjacent vlans. Are you allowing icmp traffic? For instance:

policy-map type management first-match management

  class management

    permit

class-map type management match-any management

  match protocol icmp any

  …

service-policy input management

Finally, did you check whether you are able to resolve mac addresses?

I hope it helps,

Olivier

[thomascollins]

Olivier,

Thanks for the reply.

Yes, both interface and VLAN are up..
Yes, RX packets on gi1/4 are increasing.
The interface from ace2 is just as you suggested.
Heartbeats are being sent, but not received...
I can ping things on the main admin interface (gi1/1), just nothing over gi1/4. ICMP is allowed.
Regarding ARP, what's interesting is the switch has the ARP entries for both ace1 and ace2.  (our switch is .12)

show ip arp vlan 12
Protocol  Address          Age (min)  Hardware Addr  Type  Interface
Internet  192.168.12.1          29  7081.0501.1443  ARPA  Vlan12
Internet  192.168.12.2          98  7081.0501.1447  ARPA  Vlan12
Internet  192.168.12.12          -  000e.83a0.463f  ARPA  Vlan12

So it looks like layer2 connectivity is okay, since the switch sees the MACs.  But something is not allowing the pings over gi1/4?

Full config from the primary unit attached.

THANKS!

Tom

[ohynderi]

Thanks Tom,

Would be better if you could send me a show tech from both ACEs.

Thanks,

Olivier

[thomascollins]

Here are the two show techs.  Thanks!

[ohynderi]

Tom,

Ft group 1 on ace2 should be configured with the Admin context and put inservice. What if you apply the remote_mgmt_allow_policy globally? Can you then ping the ft vlan ip address?

Olivier

[thomascollins]

Thanks.  I configured ft group 1 on ace2 (and put it in service).  I wasn't sure how to apply the policy globally, but I did:

int vlan 1000

    no  service-policy input remote_mgmt_allow_policy

exit

service-policy input remote_mgmt_allow_policy

But I still couldn't ping the FT interfaces.  New show tech's included. I also did some pings at the end, to show they can ping each other on gi1/1, but not gi1/4. 

FYI, just to be sure my cables and switch ports are correct, I connected two laptops to the same cables, assigned them 192.168.12.1/2, and they could ping each other.

Tom

[ohynderi · Accepted solution]

Hi again!

Ok, i believe i have found where the issue is…

"sh gi 1/4" shows that the port got indeed some packets.

GigabitEthernet Port 1/4 is UP, line protocol is UP

Hardware is ACE Appliance 1000Mb 802.3, address is 70:81:05:01:14:43

Description: FT

MTU 9216 bytes

Full-duplex, 100Mb/s

COS bits based QoS is disabled

input flow-control is off, output flow-control is off

    279772 packets input, 18576890 bytes, 0 dropped <<<<<<

    Received 271891 broadcasts (7808 multicasts) <<<<<<

Although we don't see them on vlan12  interface :-)

vlan12 is up, VLAN up on the physical port

     0 unicast packets input, 0 bytes <<<<<<

     0 multicast, 0 broadcast <<<<<<

     0 input errors, 0 unknown, 0 ignored, 0 unicast RPF drops

With the ft-port-vlan command, the ACE modifies the associated Ethernet port to a trunk… So the ports on your switch should be configured as well as a trunk otherwise the 802.3q tag will be removed. Can you check that?

Thanks,

Olivier

[thomascollins]

That was the problem.  Changing the switch ports to a trunk fixed the problem.  Thank you very much!