APP1000 will not take an update

[esquaredc]

One of my sites shows that the APP1000 needs an update.  I click on upgrade and the update never gets installed.  The APP1000 does shut down and restarts but the device still shows firmware 12.317.  I even uplugged the device power and rebooted, still no firmware upgrade.

Thanks,

John Endter

[Michael Holloway]

Hi John,

Which customer number is this?   Let us know and we'll take a look to see what might be happening in the logs.

Thanks,

-mike

[esquaredc]

Customer number 1073

[Michael Holloway]

Hi John,

The TBA is actually running the latest firmware, but we discovered an issue with that fact being propagated up to the portal.  In fact, discovery is not updating at all for this location currently, and during our investigation we found a few more sites that exhibited similar behavior.  We're in the process of writing a fix now and expect that it will be posted up to the trial after some internal testing.

Some additional information on this issue, it appears to happen only on busy networks (20+ devices) where ARP or other protocols are constantly chattering away and causing the discovery process to never detect a 5 second lull in network discovery traffic so that the TBA might decide if any devices or firmware versions have changed (including the TBA itself).  The fix involves also periodically looking to see if an amount of time has elapsed since TBA last considered posting new devices, and to post them even if there is no lull detected.

-mike

[esquaredc]

Mike,

Since there is a lot chatter on this network, is there something that can be corrected.  One of the advantages of a TB type device would be to identify systems on a network that are causing exessive network traffic.  Does TB have this abbility?

Thanks,

John

[Michael Holloway]

esquaredc wrote:
Mike,
Since there is a lot chatter on this network, is there something that can be corrected.  One of the advantages of a TB type device would be to identify systems on a network that are causing exessive network traffic.  Does TB have this abbility?
Thanks,
John

The traffic causing this issue isn't problem traffic, it's just that enough normal ARP activity is being generated on this network that it's keeping the TBA from phoning home because the TBA is waiting for a period of zero ARP activity for 5 seconds before if considers it's work done for that round of network discovery.  A fix for this is in testing at the moment.

TBA doesn't currently have any features to detect the amounts of bandwidth being consumed by individual network devices.  SNMP monitoring/graphing/alerting for some WAN devices interfaces might be a good first step in that direction.   Monitoring of per-device bandwidth is entirely possible with hardware such as the TBA, but would probably require either the cooperation of a WAN device (likely one with netflow capabilities), or a hardware network probe - possibly another TBA or an additional [USB?] ethernet interface for an existing TBA.  Either option would require visibility of all the packets entering and leaving the network.

You folks are driving the direction we are heading in, so please let us know what you'd like to see.

-mike

[Marcos Hernandez]

We are currently in the scoping phases of a traffic monitoring feature for Thunderbolt. The focus will be WAN traffic and VoIP, but there is no technical reason why we could not be also monitoring LAN activity. This project is in its early stages and we still have not decided if we will include it in the Trial, given the limited nature of it.

Marcos