D-Link Forums
The Graveyard - Products No Longer Supported => D-Link NetDefend Firewalls => Topic started by: frankijskes on June 18, 2010, 04:24:57 AM
-
Hello,
we have numerous questions regarding the use of pipe and pipe-rules.
Some general information about our setup:
We have 3 dfl-210's.
One is setup to have customers connect to our reverse proxy and other services we provide to our customers.
It also allows some connections to the internet.
A incoming vpn-tunnel is setup for teleworkers.
A vpn-tunnel is setup to our 2nd dlink to have a vpn-network where we store our backup data.
One (the 2nd) is setup as a vpn-network so our backups
One is a spare, in cae of an emergency and for testing purposes.
We decided to also implement traffic shaping, using pipe ans pipe rules.
PIPE and PIPE rules setup
We have 4 pipes:
PIPE NAMED Total_in:
Precedences: Kilobits per second Packets per second.
7: 1000
6:
5: 4000
4: 900
3: 5000
2:
1:
0:
Total: 9900
PIPE NAMED Total_out:
Precedences: Kilobits per second Packets per second.
7: 1000
6:
5: 4000
4: 900
3: 5000
2:
1:
0:
Total: 9900
PIPE NAMED TSM_in:
Precedences: Kilobits per second Packets per second.
7:
6:
5:
4:
3:
2:
1:
0:
Total: 8350
PIPE NAMED TSM_out:
Precedences: Kilobits per second Packets per second.
7:
6:
5:
4:
3:
2:
1:
0:
Total: 8350
We created 6 pipe-rules
# Name Source interface Source network Destination interface Destination-network Service
1 TSM_in vpn-tunnel VLAN_colo lan LOCAL-NET all_tcpudpicmp -> fixed precedence 3
2 TSM_out lan LOCAL-NET vpn-tunnel VLAN_colo all_tcpudpicmp -> fixed precedence 3
3 reverse_proxy any all-nets wan wan_ip1 http-all -> fixed precedence 5
4 SLA_customers any all-nets wan wan_ip1 SLA_Services_SHAPED -> fixed precedence 5
5 catch_all_out lan all-nets wan all-nets all_tcpudpicmp -> fixed precedence 4
6 catch_all_in wan all-nets lan all-nets all_tcpudpicmp -> fixed precedence 4
All pipe have the forward and return chain correctly configured. TSM has an ip-chain to limit the TSM bandwidth (to 8350, with vpn overhead this is slightly less than our 10Mbit line can handle).
We tested it, and it works. When our backups are running, we can still do other things without noticing any slowdowns.
But some questions remain:
PIPE and PIPE rules questions
What is the order that a packet follows when you use pipe/pipe rules?
Is it first going through the pipe, and then going to the ip-rules?
Or the other way around? Or something else?
Why do i see data on precendence 0, when the pipes are not full?
Below is a momentary capture of our pipes.
fw01:/> pipes -show total_in
fw01:/>
Details of pipe "Total_in"
--------------------------
Grouping : None
Shaping : Static
Pipe Users: 0
Min Prec : 0
Def Prec : 0
Max Prec : 7
Current Vals Dynamic Lims User Lims
Measurement Bits/s Pkts/s Bits/s Pkts/s Bits/s Pkts/s Q Bits Drops
--------------- ------ ------ ------ ------ ------ ------ ------ ------
Total 574 K 136 9.90 M
Prec 0 394 K 86.0 9.90 M 9.90 M
Prec 1 9.90 M 9.90 M
Prec 2 9.90 M 9.90 M
Prec 3 456 1.00 5.00 M 5.00 M
Prec 4 163 K 41.0 900 K 900 K
Prec 5 16.3 K 8.00 4.00 M 4.00 M
Prec 6 9.90 M 9.90 M
Prec 7 1.00 M 1.00 M
This behavior does not makes sense. All data should be precedence 4 if it is not 3 or 5. Because 4 is the catch_all filter. And none of the channels are fully utilized.
-
I believe pipes should be implemented last (or near last), but I am not certain. It shouldn't be a huge game changer here anyhow.
Precedences flow through, so my guess (given the portions of the data in front of me) is that you are exhausting your higher precedences (which are 0s) in your TSM pipes and are passing that traffic to the total pipes at precedence 0.
-
The data i gathered shows that none of the precedences are full.
So there should be no overflow from a higher precedence to a lower.
If there should be no overflow, then why is there data going through with precedence 0?
-
You have no allowance at any precedence levels on the TSM pipes, so any traffic on them will fall through to 0.
-
I do not understand what you mean.
Did we configure something incompletely?