errors in every interface

one candidate: problem with switch where have you connected port1 and port2 Try changing that switch and retest One useful CLI command to test status: diagnose hardware deviceinfo nic portX

hi Abel I have a different switch for every interface, i think to have a firewall problem, because the error are in every interface of the firewall, also the " ha" which is directly connectet with the firewall/cluster. fnsysctl ifconfig port1 port1 Link encap:Ethernet HWaddr 00:09:0F:xx:xx:xx inet addr:xxx.xxx.xxx.xxx Bcast:xxx.xxx.xxx.xxx Mask:xxx.xxx.xxx.xxx UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:53644162 errors:646716 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:20 Base address:0xe000 Memory:efe60000-efe60038 thanks for the command. thi is the output diagnose hardware deviceinfo nic port1 Description Intel(R) 8255x-based Ethernet Adapter Driver_Name e100 Driver_Version 2.1.29 PCI_Vendor 0x8086 PCI_Device_ID 0x1209 PCI_Subsystem_Vendor 0x8086 PCI_Subsystem_ID 0x0070 PCI_Revision_ID 0x0010 PCI_Bus 10 PCI_Slot 4 IRQ 20 System_Device_Name port1 Current_HWaddr 00:09:0F:xx:xx:xx Permanent_HWaddr 00:09:0F:xx:xx:xx Part_Number ffffff-0ff Link up Speed 100 Duplex full FlowControl receive State up Rx_Packets 647234 Tx_Packets 1189437 Rx_Bytes 53673775 Tx_Bytes 1398250773 Rx_Errors 0 Tx_Errors 0 Rx_Dropped 0 Tx_Dropped 0 Multicast N/A Collisions 0 Rx_Length_Errors 0 Rx_Over_Errors 0 Rx_CRC_Errors 0 Rx_Frame_Errors 0 Rx_FIFO_Errors 0 Rx_Missed_Errors 0 Tx_Aborted_Errors 0 Tx_Carrier_Errors 0 Tx_FIFO_Errors 0 Tx_Heartbeat_Errors 0 Tx_Window_Errors 0 Rx_TCP_Checksum_Good 0 Rx_TCP_Checksum_Bad 0 Tx_TCP_Checksum_Good 0 Tx_TCP_Checksum_Bad 0 Tx_Single_Collision_Frames 0 Tx_Multi_Collision_Frames 0 Tx_Deferred 0 Rx_Symbol_Errors 0 Tx_Pause_Frames 0 Rx_Pause_Frames 0 Rx_Control_Unknown_Opcodes 0 Tx_TCO_Packets 0 Rx_TCO_Packets 0 Rx_Interrupt_Packets 0 Rx_Polling_Packets 647881 Polling_Interrupt_Switch 0 RX Polling Packets what does it mean ? is equal to the number of errors ....

Hi! seems to get pretty deep here.... Actually this one looks pretty much like the linux (Kernel 2.2 and 2.4) e100 Driver from Intel. Intel offers this as a feature of the Driver: " Support for polling on RX" [...] What i assume on this (Intel) document: Usually when a packet arrives at the interface, the Packet is stored at some RAM (at the NIC or system memory, depending on implementationand hardware) and an Interrupt is fired. Just to notify the cpu that a packet has arived and the CPU should do *something*. (In Program language: to make a task switch and jump to the pointer linked with this interrupt and execute the code at this memory adress - usually something to grab the packet and forwrd it ;-) This switching normally works perfectly, BUT what happens in case this procedure is right in the ' task switch' anc concurrently the next packet arrives? Yes, they put it in the queue and fire no additional interrupt for the second packet, since the CPU is still occupied with the interrupt of the first packet. BTW: there is just a SINGLE interrupt line from the NIC to the InterruptController/CPU. So there is simpe ON/OFF (The NIC switches it on if needed, the CPU off if done) For this reason (qeueing featureof NIC/DRIVER) one interrupt can handle more than one Packet. In normal live this can happen if the cpu is occupied by some task A with high priority. In meanwhile a packet T arrives at some interface and an interrupt is fired when the data is fully in RAM. But the CPU is still working on task A . now Packet S arrives at the same interface and is stored in RAM too. Now you can' t fire an interrupt because your interrupt line for the interface is still up for packet T. So you simply make a note, that a second packet is there and wait for the CPU to grab both packets and reset the interrupt line to " off" . This can happen at a PC if your CPU is occupied heavyly or you get lots of interrupts from some other Hardware ( other interfaces etc.) AND you get TONS of (small) packets on one Interface. --> So this seems nothing to worry about IF you know what occupied the CPU / InterruptController that much. By now, no packets ware actually lost or late... EDIT: minor changes, typo' s.

hi woswasi this is the output of my firewall' s cpu Even though the cpu level is very low, we still have RX errors on all interfaces. This causes an increase in the memory usage, up to 80-90%. As a consequence, we experience sessions loss, and a severe decrease in performances. Please notice that, on average, the number of active sessions is in the order of 300-400 (which should be a pretty low level for this firewall' s throughput). get system performance status CPU states: 0% user 0% system 0% nice 99% idle Memory states: 93% used Average network usage: 209 kbps in 1 minute, 2064 kbps in 10 minutes, 1305 kbps in 30 minutes Average sessions: 258 sessions in 1 minute, 249 sessions in 10 minutes, 315 sessions in 30 minutes Virus caught: 0 total in 1 minute IPS attacks blocked: 0 total in 1 minute Uptime: 0 days, 2 hours, 55 minutes Thank you. Best regards, Nyno

Well THIS seems to be something for the second level support at Fortinet... If I may guess, this seems to be some low-level network controller or (PCI-)Bus problem. (e.g. DHCP Client, PPPoE Client, DisplayInterface, Timer, ...). Maybe you should have a look at the memory-Table which tasks need this extra ram. Maybe at the driver or Hardware. - Take another firmware, reset configuration (test with very basic configuration where no migration between versions was done) or take a different box... Hope someone else can help you. *sorry*

abelio, the firewall is a cluster with 3 active interface 1 inside 2 outside 3 dmz every interface is connected with a different cisco switch. woswasi i' ve tried to disconnect the cluster, i' ve booted the alternative firmvare build 319 --- build 408 but without good result thank everybody for the support.