We help IT Professionals succeed at work.

Netscreen-50 Asymmetric Rate Limits for FTP

Ecompro
Ecompro asked
on
According to Juniper's KB http://kb.juniper.net/KB4752  putting  FTP-GET and FTP-PUT rules together in the same group cancel each other out.

What I'm trying to do is set asymmetric rate-limits on FTP service, to parallel the asymmetry of the circuit's capacity.

Assume an asymmetrical Cable or DSL connection with capacity of 10 Mbps down, 2 Mbps up.  We'd want to limit inbound FTP activity to 5 Mbps (50% of downstream speed) and outbound to 1 Mbps (50% of the upstream speed) so that up to 50% of the circuit's capacity can be used by FTP in either direction.

Creating a general rule to permit "FTP" (not specifically Get or Put) and apply a rate-limit, it will apply that rate limit equally to transfers in either direction.   If set to 5 Mbps rate-limit, then upstream transfers can saturate the 2 Mbps upstream capacity of the circuit.  But if I set to 1 Mbps, upstream is not saturated, but it creates an unnecessary downstream bottleneck because only 1 out of 10 Mbps can be used to download.

Any ideas if asymmetrical rate-limits are possible with a Netscreen-50, and if so, how it would be accomplished?
Comment
Watch Question

Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
I would try to use separate FTP-Put and FTP-Get policies with appropriate bandwith limits. You need to use separate policies anyway, because you can only put a single bandwith limit into a policy.FTP-Put and FTP-Get should never be in the same custom service group. If you do not combine them, they do not contradict.

Author

Commented:
Yes, I always put in different groups, because that's the only way to define a rate-limit separately.  If I grouped together, I could only define a single rate-limit, which defeats the purpose of what I'm trying to do.

Problem I'm having is if I create separate FTP-PUT and FTP-GET rules (not in the same group), the FTP session works *one way*.  It depends on what rule I put first.

If I put FTP-GET rule first, I can get but when I try to put the connection is blocked.  

Conversely, when I put FTP-PUT rule first, I can put but attempts to get are blocked.

I have also tried (in separate groups) the following.......

FTP-PUT
FTP  

And I have tried.........

FTP-GET
FTP

But the results were the same.  The presence of an FTP-GET rule appears to block all PUT activity even if PUT is allowed by another rule.  And the presence of an FTP-PUT rule appears to block any GET activity even if GET is allowed by another rule.

Netscreen appears to see the FTP-GET rule (first in line) and immediately blocks PUT without looking for any other rules.  And it appears to see the FTP-PUT rule (when it is put first) and blocks GET without looking for any other rules.

Qlemo"Batchelor", Developer and EE Topic Advisor
Top Expert 2015

Commented:
I feared that this is an issue ... As a session is bound to a specific policy once created, it cannot change the policy for direction. No chance you can split the FTP commands to different sessions? Or wouldn't that help because e.g. FTP-Get is *blocking* FTP-Put, no matter if there is a policy for that positioned later?

Author

Commented:
Yes, that is correct, PUT blocks GET (if PUT is the first rule) or GET blocks PUT (if GET is the first rule).

It would be VERY helpful if:
  The PUT rule would "allow" PUT without explicitly denying GET.  
  The GET rule would "allow" GET without explicitly denying PUT.

Leave the "deny" part to the decision of the administrator.

I don't know with 100% certainty an "explicit deny" exists, but the observed behavior suggests that is the case.  
"Batchelor", Developer and EE Topic Advisor
Top Expert 2015
Commented:
The description in the KB link you provided does confirm that, but I was not 100% positive about that.
IMHO this does not make much sense. But it is as it is. And yoiu are liost. I cannot see any means to do asymmetric bandwidth limiting, if you cannot use either source or destination IP to differ between the directions. In the same FTP session there is no way.