It appeared this was an easy fix (I also tried 12.1R6.5 and 12.1X44-D11.5, to no avail).
First, I looked at the version of the signature DB that it's trying to download (2263):
netops> request security idp security-package download check-server
Successfully retrieved from(https://services.netscreen.com/cgi-bin/index.cgi).
Version info:2263(Detector=12.6.160130325, Templates=2263)
Then, I decided that this is possibly an actual bad md5 checksum (per what Junos expects), and I downloaded the previous version, 2262:
netops> request security idp security-package download version full-update 2262
Will be processed in async mode. Check the status using the status checking CLI
It worked! I've had to do something similar on Netscreen, but it's been a while. I turned off automated updates, and I can get back to studying.
netops> request security idp security-package download status
Done;Successfully downloaded from(https://services.netscreen.com/cgi-bin/index.cgi).
Version info:2262(Tue May 14 16:27:00 2013 UTC, Detector=12.6.160130325)
Now that the download is finished, everything is installing properly:
netops> request security idp security-package install
Will be processed in async mode. Check the status using the status checking CLI
netops> request security idp security-package install status
In progress:performing DB update...
netops> request security idp security-package install status
In progress:performing DB update for an xml (groups.xml)
netops> request security idp security-package install status
In progress:performing DB update for an xml (applications.xml)
etc.
netops> request security idp security-package install status
Done;Attack DB update : successful - [UpdateNumber=2262,ExportDate=Tue May 14 16:27:00 2013 UTC,Detector=12.6.160130325]
Updating control-plane with new detector : successful
Updating data-plane with new attack or detector : not performed
due to no active policy configured.
I'm thinking that this is either a bug in SRX110H-VA, a combination of hardware/software release, or bad signature updates on services.netscreen.com. I'm pretty sure that I could just look through the XML, and figure out where the bad md5sum is (and fix it by hand), but I'll follow up once I hear back from Juniper.
Newest edit: I also had to manually download the policy template from Juniper, extract it with gzip -d templates.xml.gz, and place it in /var/db/idpd/sec-download/sub-download/. Once that was done, I was able to install it. The issue here is that the request security idp security-package install policy-templates command does not take a 'version', like the other idp commands. This will always be an issue when the head IDP policy has md5 errors, although I would hope that this isn't a frequent occurrence at Juniper.
netops> request security idp security-package install policy-templates
Will be processed in async mode. Check the status using the status checking CLI
netops> request security idp security-package install status
Done;policy-templates has been successfully updated into internal repository
(=>/var/db/scripts/commit/templates.xsl)!
Interface jsrv.1 is always associated to IP address 128.0.0.127.
jsrv up up
jsrv.1 up up inet 128.0.0.127/2
An archive at SourceForge has the below command output snippet that shows a connection between 128.0.0.127 and port 6343 (sFlow port)1:
tcpdump -v udp port 6343 -s 1500:
11:52:07.624977 IP (tos 0x0, ttl 254, id 5728, offset 0, flags [none],
proto UDP (17), length 1484)
10.1.1.1.60578 > collector.6343: sFlowv5, IPv4 agent 128.0.0.127,
agent-id 17, seqnum 38496, uptime 1963373233, samples 8, length 1456
flow sample (1), length 196,
<...snipped...>
There is a Juniper Knowledge Center (cached google link) article that indicates there are 2 separate programs supporting the sFlow function, an agent and a collector.
The sFlow monitoring system consists of an sFlow agent embedded in the
EX Switch and has a centralized collector. The sFlow agent’s two main
activities are random sampling and statistics gathering. It combines
interface counters and flow samples and sends them across the network
to the sFlow collector. The sFlow collector uses the sFlow agent’s IP
address to determine the source of the sFlow data. This KB article
explains how the EX Switch assigns the IP address to the sFlow agent.
The jsrv interface appears to be a built-in Juniper sFlow sub-system that allows communication between the internal collector and agent.
1Note, this is the only connection to 128.0.0.127 I've been able to locate.
Best Answer
Try this one:
show | compare rollback 1Also this situation may rise in case when you change value(option), then in the same session revert this changed value to previous state. < This is my mention, not confirmed by the documentation.