FireBrick Traffic Shaping: Difference between revisions
mNo edit summary |
|||
(5 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
[[File:2700-small.png|link=:Category:FireBrick]] |
|||
=Overview= |
=Overview= |
||
The FireBrick 2700 has been used as a 'black' box traffic shaping device in shared offices. It's quite easy to configure a FireBrick for a 'serviced office' scenario where tenants pay for a slice of a fast pipe. |
*The FireBrick 2700 has been used as a 'black' box traffic shaping device in shared offices. It's quite easy to configure a FireBrick for a 'serviced office' scenario where tenants pay for a slice of a fast pipe. -this would be great for leased lines, ethernet services, FTTC, FTTP etc. |
||
The FireBrick can shape based on parameters such as source/target IP/port/protocol, giving flexibility. |
*The FireBrick can shape based on parameters such as source/target IP/port/protocol, giving flexibility. |
||
When shaping, |
*When shaping, CQM graphs are produces for each 'shaper', giving a visual representation of the traffic. |
||
*FireBrick are being used to traffic shape tenants in a serviced office setup where the alternative products to do the job were many times the cost. |
|||
==Black-box== |
==Black-box== |
||
Line 9: | Line 12: | ||
=Config Examples= |
=Config Examples= |
||
==Proxy-arp Mode== |
==Proxy-arp Mode== |
||
If you want the Firebrick to be 'invisible' on your LAN, |
If you want the Firebrick to be 'invisible' on your LAN, i.e., you have machines on the LAN which use the gateway IP of your router, and you do not want to use the FireBrick as the router, then setting proxy-arp on the subnets is required. - this will then proxy arps between the FireBricks LAN and WAN, both ways. -Note broadcast traffic is not passed through the FireBrick - so the router won't be able to do DHCP - the FireBrick can, or another host on the LAN can instead. |
||
Here is a config snipet where physical ports are as follows: |
Here is a config snipet where physical ports are as follows: |
||
Line 43: | Line 46: | ||
</syntaxhighlight> |
</syntaxhighlight> |
||
Here we have defined 2 shapers, one with |
Here we have defined 2 shapers, one with 500kbit/s up/down, and one with 3Mbit/s up/down. |
||
These shapers can then be used in rules, |
These shapers can then be used in rules, e.g.: |
||
<syntaxhighlight> |
<syntaxhighlight> |
||
<route-override> |
<route-override> |
||
Line 53: | Line 56: | ||
</syntaxhighlight> |
</syntaxhighlight> |
||
Here we have set specific IP addresses to go through specific shapers, so 192.0.2.2 will get 500K/bs and 192.0.2.3 will get |
Here we have set specific IP addresses to go through specific shapers, so 192.0.2.2 will get 500K/bs and 192.0.2.3 will get 3Mbit/s. |
||
[[Category:FireBrick|traffic]] |
Latest revision as of 09:41, 25 March 2015
Overview
- The FireBrick 2700 has been used as a 'black' box traffic shaping device in shared offices. It's quite easy to configure a FireBrick for a 'serviced office' scenario where tenants pay for a slice of a fast pipe. -this would be great for leased lines, ethernet services, FTTC, FTTP etc.
- The FireBrick can shape based on parameters such as source/target IP/port/protocol, giving flexibility.
- When shaping, CQM graphs are produces for each 'shaper', giving a visual representation of the traffic.
- FireBrick are being used to traffic shape tenants in a serviced office setup where the alternative products to do the job were many times the cost.
Black-box
If a managed office already has network infrastructure then the FireBrick can work in a proxy-arp mode, and physically sit on your network between your router and your LAN.
Config Examples
Proxy-arp Mode
If you want the Firebrick to be 'invisible' on your LAN, i.e., you have machines on the LAN which use the gateway IP of your router, and you do not want to use the FireBrick as the router, then setting proxy-arp on the subnets is required. - this will then proxy arps between the FireBricks LAN and WAN, both ways. -Note broadcast traffic is not passed through the FireBrick - so the router won't be able to do DHCP - the FireBrick can, or another host on the LAN can instead.
Here is a config snipet where physical ports are as follows:
- 1 for the WAN, plugged in to the internet router
- 2 for the LAN, plugged in to the network
- 3 and 4 are unused.
In terms of IP addressing on the network:
- 192.0.2.1 is the Internet router
- 192.0.2.245 has been assigned to the FireBrick
- 192.0.2.2-253 is used for the various clients on the LAN
<port name="WAN" ports="1"/>
<port name="LAN" ports="2"/>
<interface name="WAN" port="WAN">
<subnet ip="192.0.2.254/24" gateway="192.0.2.1" proxy-arp="true"/>
</interface>
<interface name="LAN" port="LAN">
<subnet ip="192.0.2.254/24" proxy-arp="true"/>
</interface>
We're simply setting the same IP address on both sides on the FireBrick, and setting proxy-arp=true.
Traffic Shaping configuration
First we need some shapers - these define the speed lanes/tunnels/pipes:
<shaper name="Customer A" egress="500000" ingress="500000"/>
<shaper name="Customer B" egress="3000000" ingress="3000000"/>
Here we have defined 2 shapers, one with 500kbit/s up/down, and one with 3Mbit/s up/down.
These shapers can then be used in rules, e.g.:
<route-override>
<rule name="Customer A" source-ip="192.0.2.2" set-graph="Customer A"/>
<rule name="Customer B" source-ip="192.0.2.3" set-graph="Customer B"/>
</route-override>
Here we have set specific IP addresses to go through specific shapers, so 192.0.2.2 will get 500K/bs and 192.0.2.3 will get 3Mbit/s.