ZyXEL → USG Firmware 3.30 is out!

Its funny you say that...a slight exaggeration on my part I'm sure, but I recall having a conversation with a coworker and basically said I'm old enough to remember before PCs hit mainstream, no one would tolerate an "incomplete product". But now-a-days, we seem to accept it as the norm. Something doesn't work quite the way its supposed to (whether its a car, blu ray player, or any other technical gizmo), then we usually just shrug it off as a bug and say "oh, i'm sure it will be fixed in a software update."

Ironically, I wonder how many "bugs" never get addressed even after a product is "end of lifed". Zyxel seems to be an exception here as Im sure there are others, but for alot of products review sites are almost worthless. By the time a product has enough reviews to determine whether its a decent buy or not, its usually been "refreshed" and is out of production, only to be replaced by the next version for the cycle to begin all over again.

-Alan

Kruser you slay me. How can I keep ignoring router features when you bring them up like this!
Tres kewl. Imagine I have used my routers and never emailed a single graph. I mean how did I survive.

Has anyone else seen this latest issue (does anybody else email graphs?) I am curious if it is also a multi-router isssue.

I have to admit that I didn't know one could mail graphs.

kirby

Configuration > Log & Report > Email daily report

I've been using this from day one.

If anybody is going to report anything with e-email reports please make sure you re-iterate the need to add SMTPS (SSL/TLS) for the outgoing server.

You mean a feature on the USG to add SMTPS??

USG needs to send email using SMTPS (user/pass auth sent over ssl/tls). I'm sending daily logs to internal mail server. Sucks not having secure smtp.

Same problem here but not limited to USG. 3 other devices only talk port 25 w/to TLS no SSL no nothing. Brano suggested setting up a Raspberry Pi device as an SMTP Relay. Took his advice and haven't looked back. More recently it's also become my Syslog server.
J

Good for you. Just advising based on the issues I've seen with a very large number customers using ZyXEL devices and Safari or IE. Maybe they've fixed their issues, I just generally don't trust anything put out by Apple or Microsoft out of the box, or even updated for that matter.

This apparently needs to be brought up by as many people as possible to ZyXEL. Was pretty sure this would be part of the 3.30 update or AT LEAST something the new ZyWALL 110/310/1100 would have. But apparently not...

Email reports are working fine on a USG200 I upgraded to 3.30 AQU1, including graphs of the cpu usage.

For awhile ZyXEL stuff only worked well with IE. Go figure.

I know. IE 8 worked perfectly. Then it seems like after that ZyXEL could never keep up and it's been nothing but problems since.
I always use Chrome since I've almost never had an issue with it. Firefox is good too, but overall I prefer Chrome anyway.

E-mail reports are working as expected on USG200 3.30.1

I'm not a fan of Google's privacy practices, and that I'm "the product," but yeah, Chrome seems to get more testing love from UI developers these days.

At my provider

secureimap.t-online.de using -> Port: 993 security: SSL/TLS works
securesmtp.t-online.de using -> Port: 587 security: STARTTLS does not works.

Shucks, now I must try again and rebuild config from scratch being as you and at least one other reported working email graphs.

Instead of rebuilding from scratch, I tried something else.
I upgraded the firmware to AQU1 from AQU0 but this time I unticked the check box for sending the daily report before I upgraded the FW.
Once the new FW was running, I then went back in and checked the box to send the daily email report again. It is now working just fine once again and the graphs are displaying as they did before AQU0 and earlier.
I did log the FW update messages via the console port as I always do but there were no errors while converting my config file when I went from 3.00 to 3.30 and then again from AQU0 to AQU1 so go figure!

10/02/2013 updated to v.3.30
I also have the numerous log entries pointing to Roku - how did you turn off logging for those events?

I took Brano 's advice and turned off logging.

For all you guru tech guys (real IT unlike me) what is an expected throughput loss by invoking BWM. I had never thought there should be but I do not exactly know what it does and thus have no insight. What do other routers experience??

There is going to be some CPU consumption by BWM, no doubt. However with properly sized HW where in engineering stages you (shoudl) account for all your overhead CPU (and MEM) needed this is not an issue and the real throughput should be un-impacted.

When however you size your HW to one feature only i.e. Firewall throughput and then add additional features you're in trouble.

I'm no network guru, but I pretend pretty good

In all seriousness, there should not be any *throughput* loss at all.

BWM is mostly used to prioritize "real-time" traffic. As long as there is sufficient BW for all your traffic, then really BWM shouldn't be needed. Its only on congested links (where buffering to prevent loss induces packet delay) that when all the traffic is fighting to get through that BWM is used to give priority to time sensitive traffic, while less important traffic gets put "to the back of the line".

I work for a group of radio stations, three of which use the internet to deliver the audio to the transmitter sites. I use BWM to ensure those UDP streams have priority over all other traffic.

However, I also use it to limit throughput for various devices and applications. For example, at home I have a 50/10 connection. Although its rare I have anyone on the guest wireless, I want to make sure they don't suck all my BW up, so I limit my guest wireless to 10/2, thereby guaranteeing I get at least 40/8 for my regular network.

I also use it to properly size my network "exit" pipe to my ISPs "entrance" pipe. Shortly after getting my USG (back in December) I started having disconnect issues. My internet would randomly cut off for 30 seconds at a time. After three long months, I finally found out it was bufferbloat. Using BWM can prevent that from ever happening again (although the ROOT cause was a stuck outgoing email with large attachment in my wife's iPad, I wanted to make SURE when I saturated my uplink that I never had that issue again, and BWM works great for this too).

-Alan

-EDIT for clarification- Above when I said there shouldn't be any throughput loss, what I meant to say was there shouldn't be any loss except any that you induce on your connection on purpose. Example, if I have a 100Mbps connection, but I globally limit my throughput to 50mbps, then the router should limit the speed to exactly that. Just enabling BWM itself with no limits in theory shouldn't impact throughput at all. In practice it might slightly (just like enabling other features impacts throughput...some very slightly, some greatly, like UTM)

Just curious: How are you keeping "Fred down the hall's" iTunes movie download (or the like) from saturating your downstream connection, causing delays in things like DNS lookups, etc? I spent about six months trying to get first a Z5 and then a USG100 to effectively prioritize SIP traffic on a heavily used connection and was never able to get acceptable QoS. We gave up on SIP and switch to a PRI.

I'm no expert, thats for sure, so maybe I'm not doing it quite right but...based on my home experience with bufferbloat:

According to my daily reports, we rarely saturate our links...but just in case what I did was measure our sustained throughput in both directions on each WAN. I then set up the global egress to limit our speed to *just under* our sustained speed on each WAN. Then I created our rules to give top priority to those UDP streams, and set aside the needed bandwidth no matter what outgoing interface is used [outgoing TRUNK]. I also created rules to globally limit all remaining traffic to specific speeds [both ingress and egress] on specific links (there are rules for the ext-wlan interface, my bridged public interface, and my protected lan interfaces when using the WAN1 interface, and rules when on WAN2). When all the speeds of all the rules are added up, they exactly match the ingress/egress limits I imposed on the connections.

In theory anyway, those high priority UDP streams will always get their traffic in/out. If everyone else saturates the link, once they hit my limits, thats when packet drops should start to occur, and hopefully the TCP algorithm will take over and adjust send speeds accordingly.

I guess the short answer, is I make sure that *MY* network is the bottleneck, so I can control the priority. If the ISP is the bottleneck, and we saturate the link, then their equipment buffers add latency, and prioritizing traffic is no longer under my control.

Thats my theory anyway. I have no complaints thus far.

We don't use VoiP though. All our equipment needs real POTS phone lines.

-Alan

-EDIT- One thing that seems to be quite controversial when talking about BWM, and I have an opinion, but no factual info.....is that in order to successfully have flawless BWM/traffic prioritization, you need to implement BWM on BOTH ends of the link. You may have done everything you could and had everything set up just right, but if the persons network on the other end is a mess, its out of your control. Again, that is just an opinion. In my application, I manage the networks on both ends for all our stations.

Thanks for pointing me in the right direction - many hidden features in the USG 50.
What I don't understand is: why the Roku was O.K. in v.3.0 (BDS.4.) C0 and not so good in v.3.30 (BDS.1) C0 ? In twenty minutes, 9 pages of logs?
My memory consumption also went from 48% to 69% with (I think) a slight increase in CPU usage.
Last night I reinstalled v.3.0 (BDS.4.) to get a better baseline and will reinstall the 3.30 later.
Again, thanks.

I have a new USG 100, so I don't have any experience with the firmware other than 3.30 AQ0 and AQ1. However, under both of those firmware versions I'm seeing a maddening problem with the VPN log. It looks like when you have multiple VPNs and are having problems with the configuration of one of them, the tunnel names and IP addresses in the log show the tunnel name and IP address of some other VPN link (sometimes a link that was actually up and working).

I replaced a Z35 with a USG 100 and ran into problems because apparently the USG 100 does something different with the DNS names of the IPSEC VPN endpoints. Although the IP address is static where the USG 100 (and the Z35 before it) is located, I was using the DNS name in some of the gateway policies. However, I have a split brained DNS setup so that IP address of the Exchange server can be reached via a local IP address from within the LAN using the same SSL certificate. This somehow messed up the VPN connections that used that same DNS name in the gateway policy, I think because the USG 100 was using the internal IP address instead of the external one in the phase 1 negotiation. Anyway, I was trying to figure out what was wrong and the messages in the VPN log kept saying that it was a different tunnel and IP address that had mismatched phase 1 encryption keys. It was only after I noticed that I was only having problems with VPN connections where I used the DNS name instead of the static IP address that I figured it out. The bad log messages had me thinking that maybe the config file got hosed somehow and that the relationships between the gateway policies and the tunnels themselves had gotten scrambled.

I'm curious if anyone else is able to reproduce this behavior. It occurs on both versions of the 3.3 firmware.

USG needs to use the FQDN that points to the external IP of the tunnel end point. Make sure the USG is querying the right DNS server. Alternatively punch in the IP if need be.

Yea, I eventually figured that out after I chased my tail around for a couple of hours because of the bad log messages. That's really irritating.

And sometimes a punch to the hardware relieves a little tension as well...

(figured I'd beat Anav to the punch)