Categorization Failed

I just checked four different client sites and I don't see this problem anywhere.

Cheers - Bob

It's not constant..it's intermittent.  I have two installations on that don't fail at the same time..they both use opendns and they both are linked into AD.  If it were a dns problem internally simply removing the machines from AD and clearing the dns links would do it..it never does.  If it was internal dns i would not be able to resolve internal FQDN's when this occurs..i can.  I can also resolve external FQDN's when this issue occurs.  The only thing that fails in the http transaction itself.  That's not DNS that's not IPS.  I have also disabled ALL ips features when this occurs..that does not solve the issue...not an IPS problem.  The only thing that fixes it is either turning off content filtering(CFF) or disabling the http proxy altogether(that's a big hammer).  I've seen it when using the isp dns servers AND when using opendns..so it's not those dns servers either.  The only thing i have not done is try to ping and trace the cff servers when this occurs...i will next time.

Good for you.  I don' doubt that this is a glitch somewhere, I just don't think anyone has asked the right question yet...

Cheers - Bob

i have same problem 3com 905b card seems to be have problem ?

thx


2010:02:15-19:32:25 acenn kernel: eth1: transmit timed out, tx_status 00 status 8000.
2010:02:15-19:32:25 acenn kernel: diagnostics: net 0cc0 media 8802 dma 005000a1 fifo 8800
2010:02:15-19:32:25 acenn kernel: Flags; bus-master 1, dirty 22237(13) current 22253(13)
2010:02:15-19:32:25 acenn kernel: Transmit list 37ca3a20 vs. f7ca3a20.
2010:02:15-19:32:25 acenn kernel: 0: @f7ca3200  length 80000051 status 00000051
2010:02:15-19:32:25 acenn kernel: 1: @f7ca32a0  length 80000051 status 00000051
2010:02:15-19:32:25 acenn kernel: 2: @f7ca3340  length 80000051 status 00000051
2010:02:15-19:32:25 acenn kernel: 3: @f7ca33e0  length 80000046 status 00000046
2010:02:15-19:32:25 acenn kernel: 4: @f7ca3480  length 80000046 status 00000046
2010:02:15-19:32:25 acenn kernel: 5: @f7ca3520  length 80000046 status 00000046
2010:02:15-19:32:25 acenn kernel: 6: @f7ca35c0  length 80000046 status 00000046
2010:02:15-19:32:25 acenn kernel: 7: @f7ca3660  length 8000004a status 0000004a
2010:02:15-19:32:25 acenn kernel: 8: @f7ca3700  length 80000046 status 00000046
2010:02:15-19:32:25 acenn kernel: 9: @f7ca37a0  length 8000005a status 0000005a
2010:02:15-19:32:25 acenn kernel: 10: @f7ca3840  length 80000046 status 00000046
2010:02:15-19:32:25 acenn kernel: 11: @f7ca38e0  length 80000046 status 80000046
2010:02:15-19:32:25 acenn kernel: 12: @f7ca3980  length 80000051 status 80000051
2010:02:15-19:32:25 acenn kernel: 13: @f7ca3a20  length 80000051 status 00000051
2010:02:15-19:32:25 acenn kernel: 14: @f7ca3ac0  length 80000051 status 00000051
2010:02:15-19:32:25 acenn kernel: 15: @f7ca3b60  length 80000051 status 00000051
2010:02:15-19:32:35 acenn kernel: NETDEV WATCHDOG: eth1: transmit timed out
2010:02:15-19:32:35 acenn kernel: eth1: transmit timed out, tx_status 00 status 8000.
2010:02:15-19:32:35 acenn kernel: diagnostics: net 0cc0 media 8802 dma 00240021 fifo 8800
2010:02:15-19:32:35 acenn kernel: Flags; bus-master 1, dirty 22237(13) current 22253(13)
2010:02:15-19:32:35 acenn kernel: Transmit list 37ca3480 vs. f7ca3a20.
2010:02:15-19:32:35 acenn kernel: 0: @f7ca3200  length 80000051 status 00000051
2010:02:15-19:32:35 acenn kernel: 1: @f7ca32a0  length 80000051 status 00000051
2010:02:15-19:32:35 acenn kernel: 2: @f7ca3340  length 80000051 status 00000051
2010:02:15-19:32:35 acenn kernel: 3: @f7ca33e0  length 80000046 status 00000046
2010:02:15-19:32:35 acenn kernel: 4: @f7ca3480  length 80000046 status 00000046
2010:02:15-19:32:35 acenn kernel: 5: @f7ca3520  length 80000046 status 00000046
2010:02:15-19:32:35 acenn kernel: 6: @f7ca35c0  length 80000046 status 00000046
2010:02:15-19:32:35 acenn kernel: 7: @f7ca3660  length 8000004a status 0000004a
2010:02:15-19:32:35 acenn kernel: 8: @f7ca3700  length 80000046 status 00000046
2010:02:15-19:32:35 acenn kernel: 9: @f7ca37a0  length 8000005a status 0000005a
2010:02:15-19:32:35 acenn kernel: 10: @f7ca3840  length 80000046 status 00000046
2010:02:15-19:32:35 acenn kernel: 11: @f7ca38e0  length 80000046 status 80000046
2010:02:15-19:32:35 acenn kernel: 12: @f7ca3980  length 80000051 status 80000051
2010:02:15-19:32:35 acenn kernel: 13: @f7ca3a20  length 80000051 status 00000051
2010:02:15-19:32:35 acenn kernel: 14: @f7ca3ac0  length 80000051 status 00000051
2010:02:15-19:32:35 acenn kernel: 15: @f7ca3b60  length 80000051 status 00000051
2010:02:15-19:39:33 acenn kernel: IPSEC EVENT: KLIPS device ipsec0 shut down.
2010:02:15-19:40:26 (none) kernel: ACPI: Power Button (FF) [PWRF]
2010:02:15-19:40:26 (none) kernel: ACPI: Sleep Button (CM) [SLPB]
2010:02:15-19:40:26 (none) kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
2010:02:15-19:40:27 (none) kernel: Netfilter messages via NETLINK v0.30.
2010:02:15-19:40:27 (none) kernel: ip_conntrack version 2.4 (191739 buckets, 1533912 max) - 252 bytes per conntrack
2010:02:15-19:40:27 (none) kernel: ctnetlink v0.90: registering with nfnetlink.
2010:02:15-19:40:29 (none) kernel: r8169: eth0: link up
2010:02:15-19:40:29 (none) kernel: r8169: eth0: link up
2010:02:15-19:40:29 (none) kernel: ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 21 (level, low) -> IRQ 58

do u see this kind of messages in u r kernel log when i face problem i get this kind of error

i'm running 905b's..turning off the proxy9ir disabling hte content filter) fixes it.  At least in my case it's not a nic issue.

The only thing i have not done is try to ping and trace the cff servers when this occurs...i will next time.

That is EXACTLY where the problem is.  Support says the box is supposed to check ping times every 10 minutes. We have found that is NOT the case.  Plus, some of these ping times are absolutely horrible and would definitely lend credence to the fact that their categorization lookup systems are NOT reliable at all.

We DID some ping and traceroute tests and only have a FEW of their cffs servers that respond in a timely fashion.  Over half respond in times greater than 100ms.  Once you get over and above those types of ping times, it is BOUND to fail.

The reason some of those content filter category servers have such high ping times is that some of them are located on an entirely different continent than you are on... hence the Astaro's constant (mine, and our customers, units do it many, many times a day) check on the ping times to the various servers.  It uses that data to determine in which order to access content filter category servers; so, just becuase some of the servers show high ping times in the log doesn't mean they are "not reliable."

I can say I have not seen an issue as you describe yet (and we have more than 30 customers running this solution)... maybe there is a hardware issue of sorts going on.

All this said, I am a proponent of hosting the category database locally on the Astaro Appliance itself, with updates retrieved from up2date servers to keep the category database updated...  It would increase performance, and reduce issues due to intermittent internet connectivity on the Internet that could result in the category servers being temporarily unavailable.  I believe you can vote for that feature request at Astaro Gateway Feature Requests.

Any updates from anyone? Looking at some of the recent threads, this problem appears to be getting worse...

if you checkout my time to solve the http proxy mystery thread i've been able to pretty much rule out DNS..also ips is not eating dns.  Their CFF categorization servers have been intermittent for a while and 7.5xx seems to be more prone to it.  Time to move that database locally.