I've been benching a new system and I am not so happy with the speeds I am getting from the RB532s. I really need to bridge this network but with the units set in bridging I only get 13mbps TCP. I change things to be routed and now I can get 18 to 19mbps.

I had hoped to install a fast network for this school but now I'm not sure thats going to happen.

Does anyone else see the same speed drop when you use bridging vs routing.

I've run into the same problem. I'm running Nstreme2 between 2 400mhz rb532's. Worked great until I had to bridge the units. Since Nstreme2 does not support bridging I was forced to run EOIP on the rb532s and that effectively brought be back down to 20mb (could just aswell get rid of the second radio). I guess you could always setup a standard PC on either end the do the EOIP there and bridge them with some older machines laying around...

We bridge backhauls running the Nstreme2 protocol by placing one end into mode=bridge and the other end into mode=station-wds and configuring a wds interface on the mode=bridge side (you could also set up dynamic wds, but we run static).

Then place the wds interface into the bridge on the mode=bridge side and the wireless interface into the bridge on the mode=station-wds side.

We have dozens of these links and they work very well.

Dave

I'm not haveing a config or setup problem here. I am have a speed problem.
What I'm looking for is why the speed is so slow on bridging?

I was moreso replying to the other gentleman who said he couldn't get bridging to work, but instead had to use EoIP. EoIP will be slower than WDS bridging.

I haven't done enough testing to know if bridging is significantly slower than routing. But since we use bridging, I am certainly interested in getting it to run as quickly as possible.

I would suggest e-mailing support@mikrotik.com with your configurations and tests to get a response. They don't always pay attention to the forums.

Dave

Make sure that you are using a newer version -- new than .20. We optimized some bridging after that.

John

I'm running 2.9.24.

Please post your bridge configuration and test parameters...

Speeds higher than those are very easily achievable.

* Bridging will be slower the more hosts you have in your "learn" table.
* Bridging more than two interfaces will easily lead to inefficiencies. consider bridges as hubs that can sometimes optimize by forwarding the packet out only one (or more) interfaces). Packet duplication is not cheap!
* Bridging puts the interfaces in promiscous mode which will lead to more to do for the input path.
* Bridging uses 802.1d algorithm (afaik) and so it sacrifices packet processing efficiency to gain correctness (which is a very good thing!)
* Bridging has an extra firewall to traverse when it's an ip packet (which is not necessarily a large penalty but processor instruction is a processor instruction.


* route lookups require at most somewhere around 32 lookup steps, whereas bridging will have many many more lookup steps. it would have to compare source address to as many hosts learned on the incoming interface and then compare destination address to all hosts learned on all other interfaces. 48 bit compares are not very "natural" for 32 bit architectures

* routers only forwards packets destined for router mac address (no manycast or poorly bridged packets wasting forwarding capacity).

I don't know if you work for Mikrotik or not, but you seem quite knowledgeable about the subject.

I found one bridge behavior that appears to be less than optimal. I have a DST-NAT rule in my bridge that changes the destination MAC address of packets with an destination of FF:FF:FF:FF:FF:FF (broadcast) to a specific MAC address. The only broadcasts on our network are from DHCP clients needing an IP address. This rule is designed to send the DHCP request directly to the DHCP server, and keep the broadcast from reaching everyone else. But with this DST-NAT rule, the bridge still forwards the packet out all interfaces, not just the interface on which the NATted MAC destination resides:

Here is my complete bridge configuration:

/ interface bridge
add name="ap" mtu=1500 arp=reply-only protocol-mode=rstp priority=0x8000 \
auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s \
forward-delay=15s transmit-hold-count=6 ageing-time=5m comment="bridge to \
ap-# sectors" disabled=no
/ interface bridge port
add interface=ap-1 bridge=ap priority=0x80 path-cost=10 edge=auto \
point-to-point=auto external-fdb=auto comment="" disabled=no
add interface=ap-2 bridge=ap priority=0x80 path-cost=10 edge=auto \
point-to-point=auto external-fdb=auto comment="" disabled=no
add interface=ap-3 bridge=ap priority=0x80 path-cost=10 edge=auto \
point-to-point=auto external-fdb=auto comment="" disabled=no
add interface=ether1 bridge=ap priority=0x80 path-cost=10 edge=auto \
point-to-point=auto external-fdb=auto comment="" disabled=no
/ interface bridge filter
add chain=forward mac-protocol=arp action=accept comment="" disabled=no
add chain=forward mac-protocol=ip action=accept comment="" disabled=no
add chain=forward mac-protocol=0x8863 action=accept comment="" disabled=no
add chain=forward mac-protocol=0x8864 action=accept comment="" disabled=no
add chain=forward action=drop comment="" disabled=no
/ interface bridge nat
add chain=dstnat src-mac-address=!00:30:48:27:65:D8/FF:FF:FF:FF:FF:FF \
dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF action=dst-nat \
to-dst-mac-address=00:30:48:27:65:D8 comment="" disabled=no

To help, I added an IP rule that allows IP broadcasts (destination IP 255.255.255.255) to only go out the interface where the DHCP server resides. This does keep the packet from going out the other interfaces of the router. But it seems that the bridge DST-NAT rule should do the same.

If you have any advice for me on making my bridge configuration more efficient, I'm all for it.

Thanks,

Dave

I don't know if you work for Mikrotik or not, but you seem quite knowledgeable about the subject.

I do not work for mikrotik.

/ interface bridge
add name="ap" mtu=1500 arp=reply-only protocol-mode=rstp priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s transmit-hold-count=6
ageing-time=5m comment="bridge to ap-# sectors" disabled=no

rstp bridge module is experimental. it's probably not quite optimized for speed yet.

/ interface bridge port
add interface=ap-1 bridge=ap priority=0x80 path-cost=10 edge=auto \
point-to-point=auto external-fdb=auto comment="" disabled=no
add interface=ap-2 bridge=ap priority=0x80 path-cost=10 edge=auto \
point-to-point=auto external-fdb=auto comment="" disabled=no
add interface=ap-3 bridge=ap priority=0x80 path-cost=10 edge=auto \
point-to-point=auto external-fdb=auto comment="" disabled=no
add interface=ether1 bridge=ap priority=0x80 path-cost=10 edge=auto \
point-to-point=auto external-fdb=auto comment="" disabled=no

Here is one of the design problems i mentioned. You bridge more than 2 ports. More than 2 ports mean packet duplication.

/ interface bridge filter
add chain=forward mac-protocol=arp action=accept comment=""
add chain=forward mac-protocol=ip action=accept comment=""
add chain=forward mac-protocol=0x8863 action=accept comment=""
add chain=forward mac-protocol=0x8864 action=accept comment=""
add chain=forward action=drop comment="" disabled=no

You have defined what might pass but you never define where.
Rules are evaluated from top to bottom. Is arp the protocol that generates the most packets?

/ interface bridge nat
add chain=dstnat src-mac-address=!00:30:48:27:65:D8/FF:FF:FF:FF:FF:FF dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF action=dst-nat to-dst-mac-address=00:30:48:27:65:D8 comment="" disabled=no

This one will most likely be a -real- performance killer. If it's dhcp you run then perhaps dhcp relaying might be better. You don't specifying inbound interface.

I'm reachable via; lists@arcticwireless.no

TO: sten

I changed my test setup to OSPF for testing the speed of routing so I can't post the config just yet. I am going to need to set it back up in bridge mode again because the network will have to be bridged for this whole campus system. I will post the configs after I get it back in bridge mode.

I there a better way to do the bridging then AP-Bridge/WDS to Station-wds?

We need this system to look as if it's connected to the main switch like the rest of the work stations and servers.

I will be running a PC with 4 radios in the main building and the smaller 4 buildings will have rb532s for the small networks in them. The links will be ptp links so we don't over load any one radio like in a ptmp setup.
The wireless network and their current wired network will be one big /24 network.

All in all we will be ok if we can get 25mbps thru each ptp.

Connection tracking is off.

RB532 #1

[admin@MikroTik] > interface wireless print
Flags: X - disabled, R - running
0 X name="wlan1" mtu=1500 mac-address=00:15:6D:50:0A:88 arp=enabled
disable-running-check=no interface-type=Atheros AR5213
radio-name="00156D500A88" mode=station ssid="MikroTik" area=""
frequency-mode=manual-txpower country=no_country_set antenna-gain=0
frequency=2412 band=2.4ghz-b scan-list=default rate-set=default
supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps
supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,
54Mbps
basic-rates-b=1Mbps basic-rates-a/g=6Mbps max-station-count=2007
ack-timeout=dynamic tx-power-mode=default noise-floor-threshold=default
periodic-calibration=default periodic-calibration-interval=60
burst-time=disabled dfs-mode=none antenna-mode=ant-a wds-mode=disabled
wds-default-bridge=none wds-default-cost=100 wds-cost-range=50-150
wds-ignore-ssid=no update-stats-interval=disabled
default-authentication=yes default-forwarding=yes default-ap-tx-limit=0
default-client-tx-limit=0 hide-ssid=no security-profile=default
disconnect-timeout=3s on-fail-retry-time=100ms preamble-mode=both
compression=no allow-sharedkey=no

1 R name="wlan2" mtu=1500 mac-address=00:15:6D:51:09:B2 arp=enabled
disable-running-check=no interface-type=Atheros AR5213
radio-name="00156D5109B2" mode=station-wds ssid="MikroTik" area=""
frequency-mode=manual-txpower country=no_country_set antenna-gain=0
frequency=5180 band=5ghz scan-list=default rate-set=configured
supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,
54Mbps
basic-rates-a/g=6Mbps max-station-count=2007 ack-timeout=dynamic
tx-power-mode=default noise-floor-threshold=default
periodic-calibration=default periodic-calibration-interval=60
burst-time=disabled dfs-mode=none antenna-mode=ant-a wds-mode=disabled
wds-default-bridge=none wds-default-cost=100 wds-cost-range=50-150
wds-ignore-ssid=no update-stats-interval=disabled
default-authentication=yes default-forwarding=yes default-ap-tx-limit=0
default-client-tx-limit=0 hide-ssid=no security-profile=default
disconnect-timeout=3s on-fail-retry-time=100ms preamble-mode=both
compression=no allow-sharedkey=no

[admin@MikroTik] > interface bridge print
Flags: X - disabled, R - running
0 R name="bridge1" mtu=1500 arp=enabled mac-address=00:0C:42:04:EB:06 stp=no priority=32768
ageing-time=5m forward-delay=15s garbage-collection-interval=5s hello-time=2s
max-message-age=20s


RB532 #2

[admin@MikroTik] > interface wireless print
Flags: X - disabled, R - running
0 X name="wlan1" mtu=1500 mac-address=00:15:6D:50:0A:8D arp=enabled
disable-running-check=no interface-type=Atheros AR5213
radio-name="00156D500A8D" mode=station ssid="MikroTik" area=""
frequency-mode=manual-txpower country=no_country_set antenna-gain=0
frequency=2412 band=2.4ghz-b scan-list=default rate-set=default
supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps
supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,
54Mbps
basic-rates-b=1Mbps basic-rates-a/g=6Mbps max-station-count=2007
ack-timeout=dynamic tx-power-mode=default noise-floor-threshold=default
periodic-calibration=default periodic-calibration-interval=60
burst-time=disabled dfs-mode=none antenna-mode=ant-a wds-mode=disabled
wds-default-bridge=none wds-default-cost=100 wds-cost-range=50-150
wds-ignore-ssid=no update-stats-interval=disabled
default-authentication=yes default-forwarding=yes default-ap-tx-limit=0
default-client-tx-limit=0 hide-ssid=no security-profile=default
disconnect-timeout=3s on-fail-retry-time=100ms preamble-mode=both
compression=no allow-sharedkey=no

1 R name="wlan2" mtu=1500 mac-address=00:15:6D:51:09:AA arp=enabled
disable-running-check=no interface-type=Atheros AR5213
radio-name="00156D5109AA" mode=ap-bridge ssid="MikroTik" area=""
frequency-mode=manual-txpower country=no_country_set antenna-gain=0
frequency=5180 band=5ghz scan-list=default rate-set=configured
supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,
54Mbps
basic-rates-a/g=6Mbps max-station-count=2007 ack-timeout=dynamic
tx-power-mode=default noise-floor-threshold=default
periodic-calibration=default periodic-calibration-interval=60
burst-time=disabled dfs-mode=none antenna-mode=ant-a wds-mode=dynamic
wds-default-bridge=bridge1 wds-default-cost=100 wds-cost-range=50-150
wds-ignore-ssid=no update-stats-interval=disabled
default-authentication=yes default-forwarding=yes default-ap-tx-limit=0
default-client-tx-limit=0 hide-ssid=no security-profile=default
disconnect-timeout=3s on-fail-retry-time=100ms preamble-mode=both
compression=no allow-sharedkey=no

[admin@MikroTik] > interface bridge print
Flags: X - disabled, R - running
0 R name="bridge1" mtu=1500 arp=enabled mac-address=00:0C:42:04:EA:FD stp=no
priority=32768 ageing-time=5m forward-delay=15s garbage-collection-interval=5s
hello-time=2s max-message-age=20s

Only getting 14Mbps tcp one way and 7.7Mbps both ways.

* Bridging more than two interfaces will easily lead to inefficiencies. consider bridges as hubs that can sometimes optimize by forwarding the packet out only one (or more) interfaces). Packet duplication is not cheap!

How then would you bridge multiple interfaces efficiently? Configure multiple bridge interfaces with only the two bridge ports defined per bridge interface? but then wouldn't you still get packet duplication due to the fact that one of the ports is going to be part of multiple bridge interfaces...

* Bridging more than two interfaces will easily lead to inefficiencies. consider bridges as hubs that can sometimes optimize by forwarding the packet out only one (or more) interfaces). Packet duplication is not cheap!

How then would you bridge multiple interfaces efficiently? Configure multiple bridge interfaces with only the two bridge ports defined per bridge interface? but then wouldn't you still get packet duplication due to the fact that one of the ports is going to be part of multiple bridge interfaces...

Depends on what you mean by efficiently.
You would still have the unknown destination problem which would lead to some form of inefficiency.

I would consider bridging each ap with a different vlan.
The next best thing in my opinion would be to shape/mold the flow of the data into a specific point A to point B stream.

Only getting 14Mbps tcp one way and 7.7Mbps both ways.

You can do better...

There are too many variables for me to help you very far over medium such as this. If you want me to take a look at them then e-mail me at the e-mail address above.

Good luck with the dark art of optimizing

Sten, do you think if 3 interfaces are bridged, the incoming frame (coming through interface A and destined for a host reachable via interface B) is also retranslated to interface C? Mikrotik manual says that the bridge interface is working as switch, not like a hub.

Sten, do you think if 3 interfaces are bridged, the incoming frame (coming through interface A and destined for a host reachable via interface B) is also retranslated to interface C? Mikrotik manual says that the bridge interface is working as switch, not like a hub.

If coming in via A and bridge knows the destination to be on B then it will not duplicate out to C.

Like a (802.1D compliant) switch, but any switch will revert to hub like behavior under certain normal everyday conditions. Which is a good thing.
Many network administrators are not aware how a bridge works and will thus bridge entire networks. Many network administrators think that just because it's done on DSL or cheap indoor AP's then it should be done on wireless. However that is emphasizing on another technologies strengths and this technologies weakness.

We bridge backhauls running the Nstreme2 protocol by placing one end into mode=bridge and the other end into mode=station-wds and configuring a wds interface on the mode=bridge side (you could also set up dynamic wds, but we run static).

Then place the wds interface into the bridge on the mode=bridge side and the wireless interface into the bridge on the mode=station-wds side.

We have dozens of these links and they work very well.

Dave

Hi, do you really mean nstream2 (dual). Since for nstream dual you have to change wlan1 and wlan2 into mode=nstream-dual-slave, so you can't use bridge or station-wds. Unlinke in regular nstream configuration bridge - station-wds si common. Right now I dont really see how to use transparent ptp bridge using nstream dual, maybe arp-proxy ?

That was a mistake. We run Nstreme, not Nstreme2. I gotta start paying better attention to my replies. Sorry.

Dave

how is the signal ?
Try without nstream ...
Did you enable polling?
Are there any other devices on the same freq?
Close freq?
SNR ?
Noise?

And more info will be helpfull ...