DT peer-keepalive Statistics

[Ruff1984]

Hello everybody,

is this normal that the counter of  DT peer-keepalive Statistics always stay on : 0

For example:

Tx Count: 0

Rx Count: 1

For the keepalive VLAN i have a seperate physical link and untag that port from the link to this vlan in both switches

vlan 10
   name "LACP-Keepalive"
   untagged A1
   ip address 10.0.0.2 255.255.255.0
   exit

my Config ist:

ProCurve Switch 1(config)#

distributed-trunking peer-keepalive destination 10.0.0.2 

vlan 10

ProCurve Switch 2(config)# distributed-trunking peer-keepalive destination 10.0.0.1 

vlan 10

[Chrisd131313]

Hi Ruff1984,

My settings look to be the same as yours...

Switch#1:

distributed-trunking peer-keepalive vlan 99
distributed-trunking peer-keepalive destination 192.168.254.1

Switch#2:

distributed-trunking peer-keepalive vlan 99
distributed-trunking peer-keepalive destination 192.168.254.2

And I see packets on mine...

DT peer-keepalive Statistics

---------------------------------

Tx Count : 156
Rx Count : 24

What is your uptime on that switch? Mine is 329 days and I only see that many keepalive packets.

HTH

[Ruff1984]

Hello ChrisD,

thx for you answer...

i setup the distributed Trunking 1 Day ago.

Maybe i get some counts a few days later. The Switchuptime is: 234 Days.

I thought the statistics are counting the hole time because the switch sends keepalive packets to see if the other switch is alive.

[Chrisd131313]

the keepalive is onyl used when one of the DT members is not reachable, here is an extract from a DT doc...

ISC link or device failure
In the event of ISC link failure or if the DTIP messaging infrastructure fails to communicate across the ISC link, then the
Distributed Trunking system will look to the peer-keepalive interface to determine whether the failure is a link level
failure or if the remote peer has failed entirely.

In case the remote peer is still alive (keepalive messages are received), the DT secondary switch will disable its DT
trunk member ports. The role is decided based on the switch’s system MAC address. The bridge with the lowest
system MAC address will act as a DT primary, while the other is a DT secondary.

If the “hello” messages are not being received, then the peer continues to forward the traffic, because it assumes it is
the last device available in the network. In case the ISC link gets recovered, the DT switches will resynchronize all
MAC addresses and the system will continue to forward traffic normally. The figure 6 illustrates the link states when
ISC link is down.

Based on this I would say that the keepalive link is only utilised when either of the switches are not available or the ISC is down and DT needs to establish what it is that has actually failed.

HTH