Present Location: News >> Blog >> Junos 12.1X44/45, 13.2X50

Blog

> Junos 12.1X44/45, 13.2X50
Posted by prox, from Pineville, on September 15, 2013 at 10:49 local (server) time

If any of you are thinking of running Junos 12.1X44 or 12.1X45 on the SRX branch series, think again.  My SRX100H at home running 12.1X45-D10 runs out of memory every 3-4 days and reboots:

einstein (ttyu0)

login: Sep 14 16:50:46 init: low_mem_signal_processes: send signal 16 to  routing
Sep 14 18:23:43 init: low_mem_signal_processes: send signal 16 to  routing
init died (signal 4, exit 0)
panic: Going nowhere without my init!
cpuid = 0
KDB: stack backtrace:
0x4af834+0x20 (0x6,0,0x3f7eef10,0x4bec10) ra 0x4af7fc sz 0
0x4af7c0+0x3c (0x6,0,0x3f7eef10,0x4bec10) ra 0x4ae114 sz 32
0x4ae090+0x84 (0x6,0,0x3f7eef10,0x4bec10) ra 0x445094 sz 56
0x445020+0x74 (0x6,0,0x3f7eef10,0x4bec10) ra 0x445110 sz 40
0x445020+0xf0 (0x6,0,0x3f7eef10,0x4bec10) ra 0x44625c sz 40
0x4461d4+0x88 (0x6,0,0x3f7eef10,0x4bec10) ra 0x446978 sz 64
0x446944+0x34 (0x6,0,0x3f7eef10,0x4bec10) ra 0x4b03f4 sz 32
0x4b03b4+0x40 (0x6,0,0x3f7eef10,0x4bec10) ra 0x4b06b8 sz 40
0x4b05d8+0xe0 (0x6,0,0x3f7eef10,0x4bec10) ra 0x4926b4 sz 32
0x492630+0x84 (0x6,0,0x3f7eef10,0x4bec10) ra 0x48d6b4 sz 48
0x48d588+0x12c (0x6,0,0x3f7eef10,0x4bec10) ra 0x4039a4 sz 3512
0x403968+0x3c (0x6,0x4d22b4,0x3f7f0060,0x4bec10) ra 0x403e40 sz 40
0x403d60+0xe0 (0x6,0x4d22b4,0x3f7f0060,0x4bec10) ra 0x3ffeefe0 sz 32
VA 0x3ffdefdc: not in user area or heuristics failed
_start+0xbfeeef00 (0x6,0x4d22b4,0x3f7f0060,0x4bec10) ra 0 sz 0
pid 1, process: init
Uptime: 4d1h54m46s
Cannot dump. No dump device defined.
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
cpu_reset: Stopping other CPUs

It doesn't bother me too much except I'm worried that eventually I'm going to start seeing some things in lost+found.

Also, my EX2200-C running Junos 13.2X50-D10.2 dies every week or two, too.  I don't have a persistent console on it, though, so I'm not sure what's happening.  The RE goes unreachable but the PFE still keeps on going (although possibly not learning additional MACs).

While it's neat to run the latest and greatest code, I'm glad I'm not running any of the mentioned X releases on any production gear at work.  Yes, JTAC recommends certain releases for a reason.

Comment by Michael on September 16, 2013 at 00:04 local (server) time

I'm running 12.1X44 just about everywhere and it seems to be working great. Best release for us yet in fact (D15 had some issues but 10.4 and 20.3 are good).

I've got 12.1X45 at home on my SRX210, no crashes but the new IPv6 features don't work correctly.

SRX210
JUNOS Software Release [12.1X45-D10]
Uptime                         57 days, 12 hours, 51 minutes, 25 seconds

EX2200-C
JUNOS EX  Software Suite [13.2X50-D10.2]
Uptime                         76 days, 25 minutes, 19 seconds

Comment by Mark Kamichoff [Website] on September 16, 2013 at 08:54 local (server) time

Huh, interesting.  I'm running a few VPNs and VRs with OSPFv2, OSPFv3, and BGP.  I'm also using logical tunnels to connect them.  I suppose it could contribute.

I'm not doing anything that fancy at all on the EX2200-C, though...

Comment by Mark Kamichoff [Website] on November 12, 2013 at 10:01 local (server) time

It looks like I am hitting this bug on the SRX:

https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR811951&smlogin=true

For those of you who can't view the PR... here's the relevant information:

> Title: If the system does not have RSVP configured, SNMP walking for
> jnxRsvpMIB or jnxVpnMIB causes rpd memory leak.

> Description: With RSVP disabled, when a SNMP get/get-next is received
> for RSVP MIB, a Path State Block (PSB) search request is enqueued,
> this enqueue operation returns nothing but, the memory allocated for
> the search request is not freed and this results in a memory leak of
> routing protocols daemon (rpd). The memory leak is observed by the
> following commands:
>
> show task memory detail | match "rsvp psb lookup req"
> show system processes extensive | match rpd
>
> When the memory usage of rpd process increases to around 85 percent of
> the system limit, the following logs are observed:
>
> re0: /kernel: %KER-5:Process (1859,rpd) has exceeded 85% of
> RLIMIT_DATA: used 1835088 KB Max 2097152 KB
>
> As a workaround, do one of the following:
>
> * Do not perform SNMP polling of RSVP 'jnxRsvpMIB'.
> * Filter SNMP polling for 'jnxRsvpMIB'.
>
> Resolved In: 11.4R6 12.1R3-S3 12.1R5 12.1X44-D20 12.1X44-D25
> 12.1X48-D60 12.2R2 13.1R1
>
> To avoid this issue, perform one of the following actions:
>
> * Filter SNMP polling for 'jnxRsvpMIB' and 'jnxVpnMIB'
>
> Example;
> lab@tsuchinoko-re0# show snmp
> view test {
>     oid jnxRsvpMIB exclude;
>     oid jnxVpnMIB exclude;
>     oid .1 include;
> }
> community test {
>     view test;
>     authorization read-only;
> }

I'm going to try that and see if it helps.


> Add Comment

New comments are currently disabled for this entry.