The Assimilation Project based on Assimilation version 184.108.40.2063634880
Nanoprobes are mostly policy-free. They do what the central monitoring agency tells them to do. The only things they do on their own are:
The process that the nanoprobes go through when booting/rejoining/starting up looks like this:
Step 1 above will be configured to default to a multicast operation - to our reserved multicast address. This address is
220.127.116.11 - and officially belongs to the Assimilation project.
If a client discovers that one of its peers is dead, and it has not received an ACK from the CMA for this, then there will be a notification outstanding in a queue which will keep getting retransmitted until it gets an ack. If this happens, and the client hears from its peer before getting an ACK from the CMA, then the client will remove this notification request from the queue - treating it as though an ACK had been received.
One of the ways this can happen is if a switch dies - leaving clients unable to communicate with the CMA about dead machines. This might slow down a cascade of errors... It would be nice if the client could tell that the link status had gone away on its own NIC (see below) - so that it could also cancel the event and keep letting timers pop until the NIC comes back - or it starts hearing heartbeats. In fact, it should probably cancel it until the NIC comes back.
$ for j in address addr_len duplex mtu speed carrier; do printf '%s: ' $j; cat /sys/class/net/eth0/$j; done
Produces this output:
address: 00:1b:fc:1b:a8:73 addr_len: 6 duplex: full mtu: 1500 speed: 100 carrier: 1
There are LLDP functions for the MTU, and duplex. Watching for carrier changes on links should eventually be a special case, since it would tell us that we have the problem, not the other guy...