Hi,

I have serious problem, on our mikrotik (rb532) is memory growing and growing, at about 90% mikrotik hangs and watchdog reboots routerboard.
In week 5, as visible below, the RB hang and we must power off routerboard manually and do hard reset. Transfering config to another router do the same. Config is still the same, no changes made.
MT OS 2.9.11.
Have you some ideas, how to solve this problem ?
We are not using cache for dns or proxy...
Only IPSec, routing (static) and FW + nat..








Pavel

Hi,

do you use bridge an vlans?

Some config-hints my be helpful No info, no help

No bridges, no vlans.

One port to internet, one port to LAN, one port to DMZ.
One PPTP tunnel to another router.

About 40 simulaneous opened ipsec tunnels.

7 simple queues. Graphing ON (store to disk).

[admin@VLP InWay] system package> pr
Flags: X - disabled
# NAME VERSION SCHEDULED
0 system 2.9.11
1 routeros-rb500 2.9.11
2 ntp 2.9.11
3 routerboard 2.9.11
4 dhcp 2.9.11
5 routing 2.9.11
6 security 2.9.11
7 advanced-tools 2.9.11
8 ppp 2.9.11
[admin@VLP InWay] system package>

I am seeing somthing similar, although it hasn't triggered the watchdog or locked up yet (I think because of the amount of memory available). My graphs are similar and are worrying me now that I've looked at a 2 month slice. Not only is memory creeping up, but so is the floor of the CPU usage even though the network is used the same amount day in and day out.

This is 2.9.10 runnning on a Soekris 4801 266MHz w/ 128MB of memory:
- Hotspot enabled (no IP-pool)
- Basic firewalling
- No Proxies outside of the Hotspot stuff
- DNS caching is on
- No VLANS, routing, etc.

The usage of this network is the same almost every day...20 to 30 people during the day, hardly anything at night.

The one thing I have been noticing lately are more SNMP related timeouts. I've got a script that polls this network every 5 minutes - it's missing more and more polls by the week and returning bogus values ('2') for active hotspot users. Still stable right now though with an uptime of 62 days as of today - the day we switched from 2.8.28 to 2.9 . See below:


Anyone else seeing this? For the record, this is still more stable than what we've seen with 2.8 at this network (best uptime yet).