On Mon, Mar 7, 2011 at 11:15 AM, Claudio Jeker <[email protected]>wrote:
> On Mon, Mar 07, 2011 at 10:38:45AM -0500, Steve Johnson wrote: > > Hi, > > > > I'm having some issues with network connectivity on a system. When doing > > netstat -ns, I get a lot of errors with missed PCB cache, drops due to no > > socket. I have already increased the TCP and UDP send and receive space > up > > to 262144, but the error counters are still increasing. One of the > highest > > impacts is a lot of false positive alerts in our monitoring system since > > this generates a lot of errors with the SNMP monitoring, which has a lot > of > > high rate UDP bursts. > > > > What makes you believe that the PCB cache and send and receive space have > anything in common? > I didn't know if they did, but these were the 2 counters that seemed problematic. > TCP and UDP send and receive space have absolutly no influence on the > number of missed PCB. > The missed PCB cache is not an error. It just a counter telling when no > PCB has been found for the incomming packet based on the src/dst IP and > port. In other words new connections will always increase this counter (as > will port scans). > For UDP it is probably even more common since in most cases recvfrom() and > sendto() is used and so the first lookup will always fail and a lookup in > the list of listening PCB needs to be done. > The "dropped due to no socket" counter will tell you how many packets are > dropped because nothing was listening on that port. Ok, thanks. Good to know all that information. > The 1-mio pesos > question is why there is no socket listening on that port. > > > The systems are a pair of Dell 1950s with dual Xeon 5130 2GHz CPUs and > the > > network cards are Intel PRO/1000 PT (82571EB). The running version is 4.8 > > GENERIC.MP#335 amd64. All they are doing is routing and filtering with > PF > > and PFSync. > > I don't get it. Are you running the SNMP server on the firewall or are you > just forwarding traffic on the firewall and some of it gets dropped? > PCB lookups do not matter when doing just routing and filtering with PF. > PCB lookups are only used for local connections. > No, the SNMP traffic is just going through the system and some of it seems to get dropped. We've only started to have this issue in the monitoring system after replacing the old IPTables back-end systems with the new PF ones. > > > Any idea what else I could tweak or modify to rectify these errors? Let > me > > know if there is anything else that I should include to provide > additional > > information. > > I guess your problem is somewhere else. Is it possible that pf runs out of > states? > The stats from pfctl seem to be fine, which is what led me to believe that it would be more of a tuning parameter somewhere. State limit is at 300K and we just had another important issue and I had only about 20K entries in the stats. There are no errors on the interfaces either, nor on the switch ports. PFSync stats do show a lot of failed lookup/inserts though. Here are the counters for PF: Counters match 639843438 729.1/s bad-offset 0 0.0/s fragment 14 0.0/s short 77 0.0/s normalize 688 0.0/s memory 1480933 1.7/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 612 0.0/s proto-cksum 0 0.0/s state-mismatch 164303 0.2/s state-insert 288 0.0/s state-limit 16 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s Limit Counters max states per rule 16 0.0/s max-src-states 0 0.0/s max-src-nodes 0 0.0/s max-src-conn 0 0.0/s max-src-conn-rate 0 0.0/s overload table insertion 0 0.0/s overload flush states 0 0.0/s > -- > :wq Claudio > Thanks
