We recently completed an upgrade of code on our SMA from 7.2.2 to 7.9.0-107 and now we keep receiving the following message:
The Warning message is:
The updater has been unable to communicate with the update server for at least 1h.
Last message occurred 6 times between Sat Sep 21 02:40:09 2013 and Sat Sep 21 03:30:10 2013.
Anyone have any idea what this is referring to and how I can fix it. Everything else is working fine, this is the only open issue from our upgrade. This is part of an overall upgrade for our WSA environment to a 7.5.x code train. Any information/help would be greatly appreciated.
This message is usually referring to the appliance trying to reach the Update Manifest server.
I'd try this in the SSH/CLI:
-(select the interface configured to fetch updates)
If this fails, then it sounds like a connectivity issue.
Anyways, the SMA doesn't really have any updates (such as scanning engines/reputation scores) to fetch so at this point, it is probably just cosmetic. But access to that site from the SMA is needed for an upgrade.
You can also view the current Updater Logs on the SMA to see if the problem is still occuring.
Thanks for the information. The SMA uses a proxy to get out to the internet, it does not have direct access so the telnet will fail and this is expected. This issue occurred in the past but really sporadically, I guess if there was an issue on the web but since the upgrade I recieve a failure message every hour and this only started to happen after our upgrade. If there is nothing to update I am fine with shutting this feature off, but I do not see a way to do this either.
You may go to Management Appliance > System Administration > Update Settings.
If your SMA needs a proxy to get out to the internet, you would configure it there. If it is already configured and you are still receiving that message, it'd be best to take a look at the proxy server and see if the traffic was being denied.
During the troubleshooting at the proxy, you can force the SMA to generate some update traffic by going to System Administration > Feature Keys, and check for new keys.
I have dug a little more into this issue and I found a solutoin I am just not sure I understnad why it is occuring. I have my SMA pointing at the same WSA it did before the upgrade for internet access. This has caused the updater error message every hour. I looked at the logs for that WSA and see successful traffic going to the update server for that WSA itself which means te traffic is getting out. This WSA is running the older 7.1.3 code. When I pointed the SMA at a recently upgraded WSA (7.5.1-201) it is successful at getting to the internet and the update servers. Now the question is why does it only seem to work on the newer code?
Good question. But really, if you see the transactions as successful, it should work.
The only thing I can think of is in that the newer versions, they added (I think, not sure if it was already there), the option to tunnel non HTTP traffic via port 80 (to an extent), and non HTTPS traffic via port 443.
If you want to dig deeper into this, I'd recommend you open a TAC case.
Thanks for your assistance, I did open up a TAC case and we found the issue. It is actually a bug related to the SMA code, you cannot use an ip address for the proxy setting in the SMA you must use a DNS call to resolve the proxy for communication to the internet to work. Once I change the proxy ip to a DNS entry it worked and the alerts stopped.
BenefitsDocumentationPrerequisiteImage Download LinksLimitationsSupported PlatformsLicense RequirementsTopologyStep-By-Step ConfigurationConfigure Virtual ServiceActivate the virtual service and configure guest IPsConfiguring UTD (Service Plane)Configurin...
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...