[j-nsp] DFW_PFE out of memory errors

[Josef Buchsteiner]

the root of the problem is not the firewall filter but the shortage of
sram memory on the IPII. You have a board which is using 8M of SRAM
and this space is used for all routes, firewall filter, policers,
next-hops and so on... It happen that you are so close to the limit
that changing a fw filter you hit the boundary already. Enhanced SSB
have 256 on CPU Memory ( 4 times higher ) and 16MB of IPII SRAM. (
double)

Josef

Thursday, July 6, 2006, 8:09:33 AM, you wrote:

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