dslreports logo
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
5028
share rss forum feed

ayryq

join:2013-09-01
Buchanan, MI

Help understanding Zywall USG bandwidth management

Hi,
I'm an amateur trying to figure out the BWM on my ZyXEL ZyWall USG 50. There's some things that confuse me, and some things I'm not quite sure how to do. Sorry this is long. I posted at smallnetbuilder about a week ago and had no replies; maybe I'll have more luck here.

My first question is regarding the difference between "inbound" and "outbound" as regards to BWM. I've read the help document a dozen times and I'm still not sure I have it straight in my head. Here's an example of something I want to do:

I have an IP cam that will totally saturate my DSL upload bandwidth if someone off-network views it. I want to limit that bandwidth so browsing doesn't suddenly become impossible. It's got a port open in the firewall, which is forwarded via NAT to a different port on the camera.
When someone (say, my brother) opens the rstp stream from the camera, who is "incoming"? My brother initiated the whole shebang by requesting the rstp stream. He is the "connection initiator," meaning the stream from my camera on LAN1 to my brother out on WAN1 is actually "inbound traffic" right? Seems backwards but that's how it reads in the manual, I think. So I need to limit a stream with SOURCE: WAN1 and DESTINATION: CAMERA on either the "outside" port or the "inside" port since they're different.

Can anyone make sense of the scenario above, in small words for a noob?

So the other problem I want to solve with BWM is really the same one. Any large upload (Pictures to a hosting site, video to youtube) kills my internet connection, breaks netflix, etc. presumably because there isn't enough upstream bandwidth to even get simple http and dns requests out. Can I fix this with BWM? How? Do I need to figure out a list of high-priority things (what else would be on this list?) or figure out a list of low-priority things? How can I limit youTube upload (which probably uses http) while allowing other http packets to sneak through?

If it sounds like I'm confused... I am. Sorry. Please help?

Thanks,
Eric

P.S. I know I need to set my outgoing bandwidth properly on WAN but I'm not sure what to set it too. What my ISP says I should get? What speedtest.net says I actually get? The minimum bandwidth I get when my neighborhood all gets online?

FirebirdTN

join:2012-12-13
Brighton, TN
kudos:1
Reviews:
·Comcast

4 edits
I know what you mean, it is a little confusing. However, i successfully set up my BWM and it works exactly the way I wanted it to, so I *think* I got it down.

I had to redo my post, as you definitely pointed out something I had not thought of.

Unless you are running a server of some sort (such as your IP cam), then connection initiation will ALWAYS be on a local interface (LAN1, LAN2, DMZ, etc), and NEVER be on the WAN.

So ordinarily you might have rules such as "incoming interface LAN1 ; outgoing interface WAN". That one rule will catch traffic going from the LAN1 interface (that would be OUTBOUND), and will also control traffic coming from the WAN back to LAN1 (that would be INBOUND).

You would not *normally* have BWM rules with the incoming interface being set to WAN and the outgoing interface set to a local interface [such as LAN1].

Since you are running a server, in order to properly apply BWM, you might actually have a rule that the incoming interface is "WAN" and the outgoing is "LAN1", and apply your desired bandwidth accordingly. (for this rule, OUTBOUND would actually be from the internet to your LAN, and INBOUND would actually be from your LAN to the internet; inbound/outbound are in reference to the incoming interface).

NOW, I hope this helps. 8)

-Alan

PS Opps...forgot. To best set your global egress bandwidth, download a tool called "shaperprobe" and run it a couple times during your networks busiest time. You definitely want to get that set to keep bufferbloat from killing your connection during upload saturation-something I had to learn about the hard way.

ayryq

join:2013-09-01
Buchanan, MI
So if I have the egress bandwidth set correctly, should I not have to worry about my second question? I.e. will the Zywall correctly share bandwidth between my big video upload and any other incindental requests?

ayryq

join:2013-09-01
Buchanan, MI
I did some testing with my brother, connecting from a remote location to my IP camera.

I only successfully applied BWM to the RTSP stream if I did source:CAM destination:WAN1 service:ANY.

In my log, I see the connection forwarded through the firewall, from his IP.
Then I see several attempts, rejected by the Zywall firewall, from his ports 56xxx, 57xxx, to my ports 20008-20015. He's using VLC to view the stream.

If I get a BWM log, it's from my-ip:20008 or 20009 to his-ip:57998 or 57999

So applying BWM to the service I thought I was using (port 554) has no effect.

Not sure what's going on here.

Eric

FirebirdTN

join:2012-12-13
Brighton, TN
kudos:1
Reviews:
·Comcast
reply to ayryq
said by ayryq:

So if I have the egress bandwidth set correctly, should I not have to worry about my second question? I.e. will the Zywall correctly share bandwidth between my big video upload and any other incindental requests?

In theory, yes. Although BWM may still be a good thing to implement, but typically BWM is done only to ensure "real time" traffic has the highest priority [ip phone, video chat, gaming, etc.] Please read this:

»www.bufferbloat.net/projects/blo ··· calIntro

I have a rather lengthy thread buried several pages down in the Comcast section here where due to bufferbloat my network was "cutting out" exactly as you describe during (unbeknownst to me at the time due to a stuck email with large attachement in my wife's ipad) upload saturation. Bufferbloat itself describes the "lag" or latency induced by large buffers during saturation. What I had discovered [quite by accident] was with my new DOCSIS 3 cable connection, not only did I suffer extreme lag and packet loss, but actual TOTAL NETWORK FAILURE; something I had not previously seen mentioned when discussing bufferbloat.

-Alan

FirebirdTN

join:2012-12-13
Brighton, TN
kudos:1
Reviews:
·Comcast

4 edits
reply to ayryq
As to what is going on with your ip camera and not using the service you thought it was, I will try and explain. This is going to be quite a lengthy post, so grab some popcorn. Disclaimer: I am a novice as well, so hopefully if I post inacurrate info someone will straighten me out. Having said that, i have a USG50 here at the house with only two very simple BWM rules, but I also have a USG200 at work where I have about a dozen BWM rules. Some of which I had to change around because they "didn't make sense" in exactly the same way that yours doesn't:

That is one thing about these ZyXels....they are very feature rich. BUT...in order to properly implement the desired rules, it kind of forces you to really learn a little bit about what happens during packet exchanges during traffic sessions.

Let's take your rtsp stream on port 554 as an example. With just that info we can make *assumptions* about how we *think* it works, but really we won't know for sure.

Example:

NORMALLY you would assume the traffic initiator would be on the internet (WAN), say by your bother. Your bother has an IP address of 1.2.3.4. When he first establishes a session with your camera, his computer will select a port to use for the outgoing connection; say port 5678. So his request, initiated on his IP of 1.2.3.4 on his outgoing port 5678 is delivered to your router, port 554. Your router forwards the incoming packets on port 554 to your camera. So far so good. Now, here is where the assumption comes in: You would expect Your cam to send the video stream back to your brother using that very same port 554. But as you can see from your log, there is actually at least one other port that has nothing to do with your camera service in use. Now this is where I get foggy, and do not know exactly what is happening: Is it your camera that is sending the stream on a different port, OR is it the ZyXel that is doing some PORT translation-that I do NOT know. BUT.....since the actual video stream is going OUT on a different port OTHER than the one that was initially contacted, BWM rules on that one service [port 554] will have NO effect! I can only take a very wild guess as to what is actually going on here: I suspect your bothers computer and your IP cam basically establish a communication on port 554, but basically agree that the actual video stream itself is going to be sent to your brothers IP, but using another separate port (source port of 20008 or 9, destination port of 57998 or 9). His side of the connection probably sends an outbound request to your router (to open HIS router for the return reply which is the actual video stream itself), and is why your ZyXel drops the packets [and why you see it in your log]. Again, this is just a VERY wild guess on my part. If this is indeed what is happening, it would explain why the only BWM rule that worked would be source: CAM (I am assuming IP address of CAM here), destination WAN, service ANY. This rule would match all the criteria of my wild ass guess above.

I guess in short the easiest way to explain it would be like this: Normally you would *assume* there would only be a single session in which the request, and the resulting video stream itself would travel. If that were the case, your BWM rule using port 554 above should actually work. What looks like is happening here is there are actually TWO sessions. The incoming session initiated by your bother essentially requesting the video stream itself, AND the separate outgoing session of your camera headed back to your bother's computer.

I ran into an extremely similar scenario at work on a real time device that I *HAD* to apply the highest BWM priority on. What made it worse, was the port used was NOT consistent. What I ended up doing was since the device had a static IP, I used its static IP as one of the rule criteria. Whether that is the "proper" way to do it or not I don't know; all I know is the end result was that it WORKS.

The best way I have found to really get a grasp on what is going on, the next time you and your bother experiment, bring up your session log, and find the IP address of the camera. You should get a real good feel for what session(s) it uses, source ports, destination ports, and protocols. That session log is really great, as it should arm you with enough info to successfully write BWM rules that will work. Also, as you noticed, using the BWM logging feature will also tell you whether your rules are working or not.

I hope this helps a little bit, but I am sorry I don't have ALL the detail on exactly what is going on here.

-Alan

PS Hope this doesn't confuse you too much. Normally BWM is easy peasy. Its only when you have active servers (where connection initiation is usually from the internet vs locally) that it can get tricky.


Brano
I hate Vogons
Premium,MVM
join:2002-06-25
Burlington, ON
kudos:14
reply to ayryq
Some pointers here
- »Re: SIP BWM for Zywall USG 20W V3.00
and here
- »Re: SIP BWM for Zywall USG 20W V3.00

ayryq

join:2013-09-01
Buchanan, MI
reply to FirebirdTN
I installed shaperprobe and ran it (with cron) every half an hour over a day and a half. Can you help me interpret the results?

Each run gave me something like this:
---------------------------------------------
Connected to server 203.5.76.164.

Estimating capacity:
Upload packet train 1: 1026 Kbps
Upload packet train 2: 1029 Kbps
Upload packet train 3: 1018 Kbps
Upload packet train 4: 1027 Kbps
Upload packet train 5: 1028 Kbps
Upload packet train 6: 1017 Kbps
Upload packet train 7: 1035 Kbps
Upload packet train 8: 1032 Kbps
Upload packet train 9: 1027 Kbps
Upload packet train 10: 1027 Kbps

Download packet train 1: 5052 Kbps
Download packet train 2: 7582 Kbps
Download packet train 3: 16396 Kbps
Download packet train 4: 16103 Kbps
Download packet train 5: 16374 Kbps
Download packet train 6: 13512 Kbps
Download packet train 7: 16381 Kbps
Download packet train 8: 14613 Kbps
Download packet train 9: 16266 Kbps
Download packet train 10: 16240 Kbps
Upstream: 947 Kbps.
Downstream: 12385 Kbps.

Upstream: No shaper detected.
Median received rate: 933 Kbps.

Downstream: No shaper detected.
Median received rate: 11050 Kbps.
---------------------------------------------
So I have a series of upload speeds, all above 1000Kbps, then "upstream" which is less, then "median received rate" which is less still.

I ran it 66 times; my average "upstream" was 953 Kbps. The minimum was 550 (at 4:40 PM on the first day of school). Most were in the 900s. My "median received rate" was usually either 933 or 970Kbps.

I had 17 runs where my "downstream" was "Measurement aborted due to high packet loss rate."

FirebirdTN, I found your other thread and you didn't say, that I could find, how you fixed your bufferbloat problem. Also, it seemed like it was on your modem, not your router?

ayryq

join:2013-09-01
Buchanan, MI
reply to ayryq
With regards to the camera:

I set up a BWM rule using just the address of the camera and it works. So I'm good there. As far as understanding what's going on, I think I understand your post, FirebirdTN (thank you!). The fact that the ports are somewhat random, or at least change each time, means I'm not going to do anything to accommodate them. It works even though they get blocked. Also, I have in mind to add a second IP camera of the same make and model, so I wouldn't know (at the router) which camera to forward these ports to.

Another weird thing: If I use an app on my phone to see the ip cam stream, I don't see these references to blocked ports etc., just the forwarded connection. So it may be peculiar to VLC or ffmpeg on Windows.

FirebirdTN

join:2012-12-13
Brighton, TN
kudos:1
Reviews:
·Comcast

3 edits
reply to ayryq
You want to set your ingress/egress just slightly less than your lowest "median receive rate".

The bufferbloat problem was indeed the modem, not the router (I tried several router's, and it made no difference). Actually though, I almost never generate enough upload traffic to saturate my connection. I would have never known there was a problem or even heard of bufferbloat if it wasn't for my wife's stuck large email attachment. I didn't know much about the ipad at the time, and didn't make the connection. As it turns out though, when I rented a DOCSIS 2 modem, although I got lag, I never got internet disruption. I found that DOCSIS 3 modems (when ran at relatively lower speed than their max throughput) not only causes lag during saturation, but kills the connectivity for anyone else on the network! You probably didn't find the right thread...the one I was talking about it 3 pages, and I believe its titled "momentary internet issues", but the fix was applying proper egress settings on the router to keep from utilizing the modems abnormally large buffer. Ironically, about a week after applying the "fix", THEN I found the stuck email in her outbox.

I am not endorsing this person's product, but a really good example of why you get bufferbloat is here: Watch the video "what causes lag:

»sejent.com/

As to adding a second camera-that is no problem, BUT....you cannot use the same port with only a single public IP. Hopefully your second camera allows you to set the port used for accessing the cam.

-Alan

-EDIT- As far as what is going on with VLC or FFMPEG...I am not positive, but what I said above does seem likely. Its almost like the ftp protocol if you are familiar with it-it actually uses TWO (or more) ports....one in essence for the command channel, and another for the actual data transfer. FTP used to be extremely difficult getting working behind NAT routers until more recent "smart" routers hit the streets. As far as why your cam doesn't do it with your phone, I'm at a loss, unless it is actually using your port 554 to reply the actual video stream itself back to your phone (instead of some other random port).

FirebirdTN

join:2012-12-13
Brighton, TN
kudos:1
Reviews:
·Comcast
reply to ayryq
RTSP Interleaved:

Just because I like to learn myself, I did some googling on the behavior of your cam.

There isn't much info out there, but what I found pretty much matches what I suspected above:

The RTSP protocol typically uses TCP port 554 for access and control data, but will negotiate with the viewer a separate UDP port to transfer the actual video.

However, due to firewalls and such, RTSP can negotiate an "Interleaved" streaming method in which the actual video data uses the same port 554 itself for transmitting back the video.

Just search for "RTSP Interleaved". Bottom line, when your brother accesses your stream, its normal RTSP behavior; when your phone accesses it, it is being sent interleaved video.

-Alan