http://www.dslreports.com/forum/ool OptimumOnline forum current topics en Copyright 2007, dslreports.com Mon, 20 May 2013 10:46:35 EDT Mon, 20 May 2013 10:46:35 EDT http://i.dslr.net/bbrdisc1.gif http://www.dslreports.com 19 18 bbr disc http://www.dslreports.com/forum/remark,28304304 http://www.dslreports.com/forum/remark,28304304 2013-05-19 12:08:26 http://www.dslreports.com/forum/remark,28296977 http://www.dslreports.com/forum/remark,28296977 2013-05-16 15:46:37 http://www.dslreports.com/forum/remark,28284496 http://www.dslreports.com/forum/remark,28284496 2013-05-12 18:49:33 http://www.dslreports.com/forum/remark,28299533 http://www.dslreports.com/forum/remark,28299533 2013-05-17 12:15:24 http://www.dslreports.com/forum/remark,28248897 http://www.dslreports.com/forum/remark,28248897 2013-04-30 09:15:29 http://www.dslreports.com/forum/remark,28297339 http://www.dslreports.com/forum/remark,28297339 2013-05-16 17:36:40 http://www.dslreports.com/forum/remark,28287838 http://www.dslreports.com/forum/remark,28287838 2013-05-13 20:54:48 http://www.dslreports.com/forum/remark,28295995 http://www.dslreports.com/forum/remark,28295995 2013-05-16 10:40:33 http://www.dslreports.com/forum/remark,28293261 http://www.dslreports.com/forum/remark,28293261 2013-05-15 13:58:59 http://www.dslreports.com/forum/remark,28229049 Fortigate 100D WAN2 port OOL Boost port 1--> Fortigate 100D WAN1 port OOL Boost port 2---> Netgear residential router (WiFi antenna off) Feeds the Guest LAN which feed the Guest WiFi open-mesh access points In normal operation, these ethernet connections are always physically connected and the devices are powered up The only difference between conditions where the DPQ3925 reboots or stays stable are the route policies in the Fortigate to direct general traffic through WAN1 or WAN2. We found no ground potential differences between gear, no POE on the WAN ports feeding the DPQ3925, no RF interference from wifi access points (there are none in the room, and we tested with them powered off as well as disconnected) On the same coax splitter that feeds the DPQ3925 is a Optimum Voice only modem with 4 lines. it never reboots spontaneously. Behavior: ====== representative basic test cases: WAN1 ALL Company Internet traffic WAN2 Only Email Server traffic --------------------------------- During business hours: If we policy route the company LAN - Internet traffic out WAN1, within a short amount of time the DPQ3925 will begin rebooting spontaneously throughout the day, anywhere from 10 minute to 40 minute intervals between. WAN1 Admin PC internet access for load testing WAN2 All other company internet, Email Server ----------------------------------------------- Also done During business hours: From an Administrative PC (exclusively policy routed through WAN1) we initiated 6 bittorrent downloads of large Linux distribution iso files Slammed the link at 64Mbs consistently for over an hour NO DROPOUTS For each of the two representative cases we retested with the following changes: -------------------------------------------------------------------- - We changed power source (used the modem direct to mains since it has a battery, removed the battery, used the modem plugged into the same UPS as the Fortigate) - We disconnected the netgear router serving the guest LAN from port 2 on the DPQ3925 and powered off the wifi units (which were not near the server room) - We put a small gigabit switch in line between the Fortigate WAN1 and the DPQ3925 ethernet port 1 to help isolate the two In all retests, the two main test cases above produced the same results Wireshark Capture ============ The Gigabit switch we put inline between the DPQ and the Fortinet is a 5 port switch with a permanent port mirror from port 1 to port 5 DPQ3925 ethernet 1 ----> Gigabit Switch port 1 (mirror source) Fortigate WAN1 ----> Gigabit Switch port 2 Wireshark Laptop ----> Gigabit Switch port 5 (mirror target) Preliminary Results: --------------------- We ran the test case that generates dropouts / reboots again and captured three of them this past friday. Filtered within wireshark by time windows surrounding the dropouts and noted that there were no malformed packets leading up to the reboot, just lots of streaming media traffic streams. Just before the modem reboots, the streams seem to dominate the connection to the exclusion of other traffic. This capture is the data at the DPQ's LAN port, not the Fortinet's WAN1, so this is what was hitting the modem at that point. The guest LAN was disconnected during that test, so nothing else was affecting the DPQ Other Research ========== I found the following thread where similar rebooting behavior is described. http://forums.whirlpool.net.au/forum-replies.cfm?t=1509330 ----------------------- [snip] Extreame In the penalty box http://whrl.pl/RcobID herring | anchor Reply to this post | posted 2010-Aug-12, 4:49 am internaut writes... Is anyone else with the DPQ3925 experiencing drop outs where their modem will reset/reboot and lose internet access? The issue here is the router component of the Cisco is of poor quality, and has a tiny NAT table size, when the NAT table gets full (usually because of many connections, such as torrents etc) the unit will reboot to clear the table. If you have a few wireless clients, this can also cause the unit to reboot. Unfortunately, BP Cisco EPC3925 modems have the same issue, very similar to the Netgear CG814WG (HNG) modem rebooting issue's. Unless Optus can update the firmware to reduce these issue's, not much can be done about the reboots, if you use torrents, then reduce the amount of connections that the application is using. Hope this helps. Extreame [snip] ------------------ Disclaimer: I realize that the above quoted post is from over 2 years ago, and from australia, and the DPQ's router subsystem is set up in extream's case as a NAT/PAT firewall gateway, not just a router as is the case with OOL Business Boost Plus Static IP To that end, I know that a NAT table is not the issue, but it seems to me that if there is some other table the DPQ's router uses to reassemble elements of the traffic, perhaps this is getting overloaded when it passes multiple media streams from/to multiple hosts behind the Fortigate? FRUSTRATION ========= I understand completely the perspective the Field Service department is coming from regarding this issue, as far as their purview is concerned they have verified the DOCSIS and cable plant stuff is within spec, and the signal levels are good at the modem. But it is REALLY frustrating to hear that the problem is in the "customer's premise equipment" when there is absolutely nothing unusual about the premise equipment or environment, and it may be an unusual set of conditions and or traffic that is causing the modem reboots, presumably in the gateway subsystem within the DPQ3925 What it seems at this stage is that LEGITIMATE protocols and traffic going from/to LEGITIMATE equipment is causing the DPQ 3925 to exhibit some kind of bug that might be missed at a smaller OOL Boost Business customer or one who does not have multimedia as much part of their business as this one does. That said, I don't know that, it is more of a hunch, but here is NO way to tell what is happening in the DPQ3925 logs at the point of failure, so we don't have anything to go on that is concrete. It may be an incompatibility between the DPQ and the fortinet, but how would we be able to escalate that possibility? We need something concrete to go on as to the point of actual failure. We are capable of setting up a syslog server target if we could for the modem boot / error logs, if possible. I am REALLY hoping there is someone at Cablevision who can work with us to troubleshoot the problem with the gateway in the DPQ. Someone with a name, an invested interest in solving the problem, and an email address. Even if it comes to submitting a ticket to the vendors (cisco and fortinet) to address a possible incompatibility between their equipment and ask for a firmware fix for it. As it stands, all that seems to happen is we are escalated around to other technicians who are reading from the overall notes taken in our account in their system, written from their perspective. I understand that this is not their fault. And we keep hearing the only conclusion that the field techs can actually make given their purview, that it is a problem at the customer end now. They are gracious about it, but they can't take the troubleshooting any further. An email address of someone who can work with us, so we can build up a thread that both of us can reference would be huge. Anyway, we are going to do more testing today and more wireshark captures to see if there is any really solid pattern of traffic just before the DPQ resets that could shed light on things. Also, I hope I posted in the right subsection (OOL as opposed to help?) Thanks, Chris. -- Time is an illusion..... Lunchtime, DOUBLY so..... Ford Prefect]]> http://www.dslreports.com/forum/remark,28229049 2013-04-23 15:43:48 http://www.dslreports.com/forum/remark,28107336 http://www.dslreports.com/forum/remark,28107336 2013-03-15 21:59:48 http://www.dslreports.com/forum/remark,28287707 http://www.dslreports.com/forum/remark,28287707 2013-05-13 20:08:24 http://www.dslreports.com/forum/remark,28288485 http://www.dslreports.com/forum/remark,28288485 2013-05-14 01:35:32 http://www.dslreports.com/forum/remark,28179794 http://www.dslreports.com/forum/remark,28179794 2013-04-08 15:55:57 http://www.dslreports.com/forum/remark,28284157 http://www.dslreports.com/forum/remark,28284157 2013-05-12 15:23:57 http://www.dslreports.com/forum/remark,27571883 http://www.dslreports.com/forum/remark,27571883 2012-09-28 19:26:31 http://www.dslreports.com/forum/remark,28242563 http://www.dslreports.com/forum/remark,28242563 2013-04-27 19:59:02 http://www.dslreports.com/forum/remark,28265827 http://www.dslreports.com/forum/remark,28265827 2013-05-06 10:59:03 http://www.dslreports.com/forum/remark,28283005 http://www.dslreports.com/forum/remark,28283005 2013-05-11 23:46:25