[j-nsp] DFW_PFE out of memory errors

[Nicola Foggi]

Ah yes...

That message actually was put in after I worked JTAC for awhile
troubleshooting some problems.  From my memory, I the firewall is
compiled in SRAM which the amount is dependent on which box you're
using.  It is a hard limit of available space, which if I remember, is
shared amongst a bunch of different things.

You can "tweak" the filter to make it less of a memory hog, or, if you
make the change, deactivate the filter, commit, the reactivate and
commit it should apply.

Nicola Foggi
Networks and Telecom
DePaul University

On Thu, 2006-07-06 at 01:09 -0500, Kevin Day wrote:
> Has anyone seen anything like this:
> 
> Jul  6 00:48:36  core1-chi mgd[4366]: UI_COMMIT: User 'admin'  
> performed commit: no comment
> Jul  6 00:48:50  core1-chi /kernel:
> Jul  6 00:48:50  core1-chi /kernel: DFW_PFE: add/change for filter fw- 
> to-lan failed due to lack of memory space.
> Jul  6 00:48:50  core1-chi ssb DFW: firewall addition failed (No memory)
> Jul  6 00:48:50  core1-chi ssb DFW: jtree cutover failed (memory  
> allocation failure) for filter (1) change!
> 
> 
> admin at core1-chi# show firewall |match "term" |count
> Count: 249 lines
> 
> SSB status:
> Slot 0 information:
>    State                                 Master
>    Temperature                        40 degrees C / 104 degrees F
>    CPU utilization                     7 percent
>    Interrupt utilization               0 percent
>    Heap utilization                   78 percent
>    Buffer utilization                 52 percent
>    Total CPU DRAM                     64 MB
>    Internet Processor II                 Version 1, Foundry IBM, Part  
> number 9
>    Start time:                           2006-07-05 16:40:10 CDT
>    Uptime:                              8 hours, 18 minutes, 59 seconds
> 
> 
> 
> I seem to have hit some limit in my firewall config - I have 249  
> active terms right now. If I add 1 or 2 more, I get the above  
> message. Once I pass 250, either my commit has no effect, or it  
> silently turns some of my firewall rules into "accept" which is kinda  
> scary. Is there a limit of 250 terms that I'm missing somewhere?  
> Which memory am I exceeding? Is there any way to boost this up any,  
> or is it a hard limit?
> 
> 
> Failing that, is there an accounting system that can do things more  
> efficiently than:
> 
>          term inhost160 {
>              from {
>                  destination-address {
>                      xx.xx.xx.160/32;
>                  }
>              }
>              then {
>                  count inhost160;
>                  accept;
>              }
>          }
>          term inhost161 {
>              from {
>                  destination-address {
>                      xx.xx.xx.161/32;
>                  }
>              }
>              then {
>                  count inhost161;
>                  accept;
>              }
>          }
> 
> 
> to generate counters for every IP passing through within a certain  
> range? I only need to monitor about a /27 worth, but we need to track  
> in/out on each IP. Or any way to make that more memory efficient?
> 
> We're doing too much traffic for the RE to handle any decent  
> percentage of traffic for generating netflow records, and an AS or MS  
> pic is a bit out of our budget.
> 
> 
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp