The other day I had a question…”How can I bridge two networks using full duplex wireless links?” Another stipulation was to also use OSPF. Here’s our diagram:

What we want to accomplish is this:

Step one is to just put the IP addresses on:
MTK1

1
2
3
4
5

/ip address
add address=192.168.1.1/30 broadcast=192.168.1.3 comment="" disabled=no \
    interface=wlan1 network=192.168.1.0
add address=192.168.1.5/30 broadcast=192.168.1.7 comment="" disabled=no \
    interface=wlan1 network=192.168.1.4

MTK2

1
2
3
4
5

/ip address
add address=192.168.1.2/30 broadcast=192.168.1.3 comment="" disabled=no \
    interface=wlan1 network=192.168.1.0
add address=192.168.1.6/30 broadcast=192.168.1.7 comment="" disabled=no \
    interface=wlan1 network=192.168.1.4

Now that we have IP addresses on the interface, make sure you can ping your neighbor 🙂

Now, lets go ahead and crank on OSPF(Turn on OSPF and set interface costs):
MTK1

1
2
3
4
5

/routing ospf network
add area=backbone comment="" disabled=no network=0.0.0.0/0
 
/routing ospf interface
add cost=20 instance-id=0 interface=wlan1 network-type=broadcast passive=no

MTK2

1
2
3
4
5

/routing ospf network
add area=backbone comment="" disabled=no network=0.0.0.0/0
 
/routing ospf interface
add cost=20 instance-id=0 interface=wlan2 network-type=broadcast passive=no

Now we will create our loopback interface (a bridge interface with no ports added):
MTK1-2

1
2
3
4
5

/interface bridge
add admin-mac=00:00:00:00:00:00 ageing-time=5m arp=enabled auto-mac=yes \
    comment="" disabled=no forward-delay=15s l2mtu=65535 max-message-age=20s \
    mtu=1500 name=bridge10 priority=0x8000 protocol-mode=none \
    transmit-hold-count=6

Now, throw an IP address on our loopback interface:
MTK1

1
2
3

/ip address
add address=1.1.1.1/32 broadcast=1.1.1.1 comment="" disabled=no interface=\
    bridge10 network=1.1.1.1

MTK2

1
2
3

/ip address
add address=1.1.1.2/32 broadcast=1.1.1.1 comment="" disabled=no interface=\
    bridge10 network=1.1.1.1

We are now going to add an EOIP tunnel interface. This tunnel interface will allow us to bridge traffic. The remote address will be set to that of the loopback interface. This way no matter which wireless interface the traffic enters it will always be able to reach the loopback interface!
MTK1

1
2
3
4

/interface eoip
add arp=enabled comment="" disabled=no l2mtu=65535 mac-address=\
    02:68:73:AC:10:E1 mtu=1500 name=eoip-tunnel1 remote-address=1.1.1.2 \
    tunnel-id=0

MTK2

1
2
3
4

/interface eoip
add arp=enabled comment="" disabled=no l2mtu=65535 mac-address=\
    02:68:73:AC:10:E1 mtu=1500 name=eoip-tunnel1 remote-address=1.1.1.1 \
    tunnel-id=0

Create a bridge interface to bridge the EOIP tunnel interface over to the ethernet interface and then add the ports to the bridge:
MTK1-2

1
2
3
4
5
6
7
8
9
10
11
12

/interface bridge
add admin-mac=00:00:00:00:00:00 ageing-time=5m arp=enabled auto-mac=yes \
    comment="" disabled=no forward-delay=15s l2mtu=1526 max-message-age=20s \
    mtu=1500 name=bridge1 priority=0x8000 protocol-mode=none \
    transmit-hold-count=6
/interface bridge port
add bridge=bridge1 comment="" disabled=no edge=auto external-fdb=auto \
    horizon=none interface=ether1 path-cost=10 point-to-point=auto priority=\
    0x80
add bridge=bridge10 comment="" disabled=no edge=auto external-fdb=auto \
    horizon=none interface=eoip-tunnel1 path-cost=10 point-to-point=auto \
    priority=0x80

So with this configuration we have a full duplex wireless link due to our OSPF cost manipulation. Since the cost is higher on certain interfaces, traffic will choose to flow in a circular pattern through the interfaces that don’t have a cost associated with them. If one of the interfaces fails, OSPF will fail the routing over to the remaining interface.

Both ether1 interfaces are on the same L2 subnet and have the advantage of higher throughput with link failover.

Alternatives

Bonding
You could bond the wireless interfaces and do L2 round robin to balance the traffic. One concern I have is that you might get some wacky jitter over the wireless links. In theory they should suffer the amount of wireless delay, though 🙂

It looks like 4.14 introduced a nice little RB1000 bug and has subsequently been replaced by 4.15. If you have 4.14, I would go ahead and delete it just for safety’s sake.

*) upgraded broken RB1000 bootloader which was included with v4.14;

Torrent can be found here.

Looks like they dropped a quick release to fix a couple of Nv2 issues.

*) radius – fixed Disconnect and CoA response signature generation;
*) radius – do not include NAS-Identifier & NAS-IP-Address in
Disconnect and CoA responses;
*) added hotspot html variable “host-ip”; => I can’t find anything on this. I’m thinking this will allow you to integrate the IP address the hotspot web page.
*) wireless nv2 – fixed station-wds mode multicast problem;
*) wireless nv2 – fixed occasional encrypted link stalls;