Page 1 of 1
Bandwidth control and wireless bridge
Posted: Wed Jul 14, 2004 3:17 am
I have RouterOS V2.8.11 running on Routerboard 230 set up like this:
Internet---MT---AP===WB---SW---PC, PC, PC
AP: Wireless access point
WB: Wireless bridge
PC: 3 PCs connected to switch
I would like to limit up and down bandwidth to all the PCs behind the wireless bridge, not each PC individually. The wireless bridge perfoms MAC translation so all traffic has the MAC of the bridge, not each PC. I have set up masquerading so the PCs get a private IP from a DHCP server on the private side and there is a single, public IP addreess on the public side going to the Internet. Routing is set up so each PC can get to the Internet.
I cannot limit the bandwidth to all the PCs using the DHCP server as the server sees the MAC of each PC (MAC of each PC is embedded in DHCP request packet), so I need to limit according to the MAC of the wireless bridge.
So far I have set up a mangle rule to mark each packet coming from the MAC of the wireless bridge, then set up a queue tree to limit bandwidth according to the mark.
My question is, is this the best way to limit bandwidth to everything behind the bridge? Or is there a different approach?
Thanks in advance for any advice.
Posted: Wed Jul 14, 2004 10:36 am
Trying to mark traffic based on a MAC address seems like a difficult way to limit bandwidth. Just use a Simple Queue and limit it by IP address. You can limit by individual IP's, or by groups of IP's.
I would just put an inexpensive router on the other side of the bridge and use a simple queue to limit by the IP address assigned to the router. The router would hand out IP's and DNS info to all the PC's plugged into it.
limiting by MAC address
Posted: Wed Jul 14, 2004 11:35 am
To do this:
1. connection-mark all packets from the MAC of each client with different marks for each client using action=passthrough:
/ip firewall mangle add src-mac-address=01:23:45:67:89:AB mark-connection=AB \
2. Remark these packets with flow-mark (again different flow-marks for each connection-marks):
/ip firewall mangle add connection=AB mark-flow=AB
3. Now we can use these flow-marks in queue trees
While this solution should function, it is fundamentally flawed as the first packet of each connection destined to these clients will not be taken into account.
Posted: Wed Jul 14, 2004 2:12 pm
Thanks for your replies gentlemen.
I know that deploying a router behind the bridge would solve the problem but I want to avoid this because of cost (there are multiple wireless bridges in the network). Also, although I can assign a specific IP address to each client behind the bridge, how do I stop a client from setting a static address and bypassing the bandwidth controls?
Using the mangle scheme, what is the effect of the first packet not being taken into account?
Posted: Wed Jul 14, 2004 7:11 pm
You avoid the problem by assigning everyone static IP's. You use a simple queue to control bandwidth by IP, or group of IP's, and put the unassigned IP's in a queue with a very low speed setting. The advantage here is you always know who has which IP address, and you know who to turn off when they pick up a virus and bring your network to a crawl.
Posted: Wed Jul 14, 2004 8:55 pm
This scheme would only limit bandwidth to each PC behind the bridge, not the total bandwidth to all PCs behind the bridge.
An alternative would be to supply only one IP address per bridge, then requiring a router to use more then one PC.
The marking and queue tree scheme seems to be working, but I'd like to understand the "fundamental flaw" in this.
Posted: Wed Jul 14, 2004 10:18 pm
You should not worry about that one as in case of TCP, it's just connection establishment packet, and all further communucation is marked flawlessly.
Why does this happen? See, when that mentioned first packet of a new connection destined to your client arrives, it does not have source MAC address of your client (in fact, it should have a destination address of the client, but you know you cannot match the destination MAC addresses in firewall), so it is not matched by the connection-marking rule neither does it match the second rule that checks the connection mark. Those rules are only activated when the client replies. Please note that this flaw applies only on incomming connections, and that mean that if you are using masquerading for that client, this flaw does not apply to you as masquerading prevents incomming connections by definition.
Posted: Wed Jul 14, 2004 11:41 pm
Thanks, this is good news.
One more question, how do I limit bandwidth (to a low or zero speed) for traffic that does not match marked MAC addresses?
Posted: Thu Jul 15, 2004 3:54 am
You can use simple queues to control by individual IP's, or by groups of IP's. If you put in 192.168.2.176/32, it assigns a bandwidth queue for that IP address. If you put in 192.168.2.176/28, it assigns a bandwidth queue that is shared by that group of IP's (176 to 191).
Queues are processed like firewall rules. It starts at the top and goes down until it matches that IP or runs out of rules. You can start at the top with individual IP's (/32) that get special treatment, add queues for specific groups (/29,/28,etc), and then add a catch-all (/24) to limit any unassigned addresses.
Experiment a little. Once you get the hang of it, I think you will find it much easier than trying to limit by MAC address.
My customers all get static IP addresses. They either have a $35 Trendnet router behind the bridged radios (Alvarion), or are using CPE with the router functions built-in (Proxim MP.11). I have one simple queue for each client to control bandwidth.
Posted: Thu Jul 22, 2004 11:36 am
For blocking all 'unwanted' other IP's, I would use firewal/rule/forward to deny lets say 10.0.0.0/24 (I think you have to also drop webcache the same way - alow who you need, deny the rest) and than in front of it put one by one ip which you want to (example) accept 10.0.0.100/32, or even better put mac's in ip/arp so noone can get anything from your router if he doesnt have that mac with that ip.
Posted: Thu Jul 22, 2004 5:15 pm
Thanks, netcomp, I will try this out. Since I last posted in this thread I am using the universal client to translate a random IP (which I DHCP out to the clients) to a specific IP defined by the wireless bridge MAC address in the universal client access list. I am then bandwidth shaping on that IP. Any comments on this configuration?
Posted: Thu Jul 22, 2004 6:01 pm
Who gives IP's throught DHCP, mikrotik or bridge ? Why random IP's? If you have small number of clients, I dont recommend DHCP.
Did you know that some bridges make all the pc's 'behind' bridge to look like they have one MAC, but some dont, like d-link's bridge for example, so from ap you will see all pcs (macs) behind bridge.
Posted: Thu Jul 22, 2004 6:29 pm
The Mikrotik serves the DHCP addresses. The DHCP'd IPs are random or "dummy" (i.e. unrouted) because they are immediately translated to a "real" (routed) network by the universal client interface. In reality I DHCP a 10.0.0.0/24 address and then translated it to a 184.108.40.206/24 address which is masquraded to a public address.
I want to use DHCP as DHCP client is the default set-up on just about any windows machine. Also, if DHCP fails, some windows clients will set an automatic IP address which will still work fine through the universal client.
Yes, the bridge I am using translates the MAC address of the host to it's own MAC for all clients behind the bridge. Unfortunately, the DHCP protocol embeds the MAC address of the requesting client into the DHCP request packet, while the packet header gets the bridge's MAC. Therefore, the DHCP server allocates IP address by the client's MAC, not the bridges MAC. therefore, I cannot control bandwidth per customer, only per host using this method.
With my current set-up, the DHCP server is just to give any address to a client if it requests one. Static and automatic addressing will also work. As the universal client interface sees the MAC of the bridge, I assign an IP to that specific MAC using the universal client acccess list. I then control bandwidth to and from that IP using simple queues.
This seems to work so far though the manual does say that universal client interface breaks some protocols.
I have a lot more experimenting to do.