Mesh in V3

[wolfcreek]

Did I read the specs for V3 properly. You will be providing Mesh using OLSR? This is what we have been waiting for. We have been planning a mesh system for a county wide redundant backbone system. We were even thinking of writing our own due to the overpricing of some solutions and the lacking features of others.

Will this mesh be able to use multiple radios and self heal? If it is something like what mesh dynamics or similar companies have and you are offering it for the Star OS pricing we will be buying a lot of Star OS boards. Will this feature be working in the initial release? We would like to start testing ASAP.

[tony]

It is currently available in the latest WAR release. It supports multiple radios, and ethernet devices. It also has a web front-end to see the network topology. (port 8001 once enabled in the olsr configuration).

[lonnie]

We are ready and pleased to accept your orders.

OLSR has been in play/testing since Fall 2005 and we felt it was indeed ready for use. This is not the MESH that people think about, with its ADHOC mode and using a single radio. It uses all available devices (radio and Ethernet) and performs auto routing between connected systems. I call it OSPF on steroids.

Next week we will convert our whole system to use mesh. We feel strongly that it will work so we are going to give it a try. On smaller networks closer to our POP we have been pleased, so we'll see how it joins 4 communities and a number of repeaters and AP units.

Did I read the specs for V3 properly. You will be providing Mesh using OLSR? This is what we have been waiting for. We have been planning a mesh system for a county wide redundant backbone system. We were even thinking of writing our own due to the overpricing of some solutions and the lacking features of others.

Will this mesh be able to use multiple radios and self heal? If it is something like what mesh dynamics or similar companies have and you are offering it for the Star OS pricing we will be buying a lot of Star OS boards. Will this feature be working in the initial release? We would like to start testing ASAP.

[tkerns]

I was reading the info at the OLSRP site and they claim low CPU and memory usage, I'm wondering with the limited amount of memory on WAR's and WRAPS (if you plan to release it for WRAPS) what will the limits on network size will be. etc. number of routers, gateways.

[wolfcreek]

Will Star OS be able to determine nodes that are gateways automatically and will any of the OLSR plugins be usable? I guess what I am wondering is if this will work like other mesh solutions and I can set up for example several nodes and have a couple of gateways to the net and it be able to identify the gateways and create routes based on cost and availability of a gateway

[tony]

We do not impose any restrictions on how you setup your network. If you have multiple gateways, olsrd should take care of your routes for you.

The system comes with the httpinfo, dyn_gw and dot_draw plugins.

[kbldawg]

I've been doing some research on MESH networks, trying to decide if your MESH offering will be something I want to look at implementing on our Network. I am getting to a point to where I have need for multiple gateways to provide redundant backhauls for our WPOPs. So I'm wondering if this new MESH ("OSPF on steroids") will be the ticket or if OSPF is they way to go.

I can also see how a MESH network could grow (geographically) really fast, to extend to the "last mile" customers, hmmmmm!!! [grin]

Not having study the subject much, until just recently hearing about your offering, I don't have any real world experiences with MESH so, all I have to go on is what I've read.

I assume some of the bigger flaws with the conventional MESH network, was the dregradation in throughput at each hop (1/2 at each hop), not only that but, it's contention based characteristics, and high latency as well.

I assume that your system is not like that, based on your statement?


This is not the MESH that people think about, with its ADHOC mode and using a single radio. It uses all available devices (radio and Ethernet) and performs auto routing between connected systems.

Care to elaborate more on how MESH V3 differentiates itself from your A-typcial MESH? Or is the secret simply the olsr routing protocol? I read the olsr links your posted, but to be honest, I didn't get a whole lot out of it.

MESH V3 sounds exciting and I'm definitely interested in learning as much about it as I can.


Chad

[lonnie]

Adhoc is hop to hop to hop through users and gets real slow, real quick. All systems use then same ESSID and channel. I consider it to be a mess ans is one reason why we have not implemented Adhoc, which was really a substitute for an AP when nobody had AP code. When we did the first AP for the TT 2 mbps cards that all changed back in 1998.

With OLSR, it uses a familiar backbone and microcell approach to provide multiple connections for the backbone. In this way the microcells will always get a connection that takes them to the rest of the network.

OLSR will route around a down link and restore connectivity to the parts of the network it can see with the new set of connections.

This is really the way the Internet was designed in the first place. I remember being impressed when I was first researching Internet how no single outage could take out the net because of the "web" of routers feeding it. They would simply route around that one dead link. Well now WE have that same capability and it seems like most of the Internet has lost that ability, due to the number of main backbone providers and their turf protection.

It is still an awesome ability and we are glad to have it.

[wolfcreek]

I am not sure what monitoring is available in the WAR boards but if you can measure voltage it would be awesome in the future to add the power status plugin. That way if we are using this as a redundant network a low battery at a remote location would lower that nodes willingness to be a route and if another route existed it would use it. Be great in an instance of a wide area power outage and dependent on battery backup.

We are building our mesh network as a totally independent high reliabilty backhaul system to take over in case of a failure in our network. It will have multiple paths across the area to still provide bandwidth during emergencies, natural distasters etc. It will also form the backbone of an emergency communication system for local govt.

[dc2005]

Quick question: assuming this stuff worsk as it's supposed to, can anyone outline the pros and cons of using OLSR versus the more "traditional" dynamic routing protocols i.e. OSPF or RIP? I understand the idea of mobile ad-hoc networks and where OLSR has come from in this respect. What I'm not clear on is why you'd use OLSR instead of say OSPF as your preferred IGP or maybe I've missed the point.

[lonnie]

RIP does a good job of making the entire network accessable from any machine in the RIP covered area. RIP does not like circular routes and can be particulary troublesome if you provide any sort of duplicate connection.

OSPF also does a good job of making the entire network accessable from any machine in the OSPF covered area. OSPF does handle duplicate connections quite well and can provide for self healing nodes. It has a major weakness, though, in that it is only a 2 layer network. It is meant for a long straight backbone, such as from a fibre run, with nodes that feed off it. If you have nodes that feed from the nodes it does not work, although there is the concept of a virtual area to extend that another layer.

OLSR combines RIP and OSPF and a few other concepts and allows a multi layer network that can be self healing using redundant connections. We consider it to be the next logical step in routing.


Quick question: assuming this stuff worsk as it's supposed to, can anyone outline the pros and cons of using OLSR versus the more "traditional" dynamic routing protocols i.e. OSPF or RIP? I understand the idea of mobile ad-hoc networks and where OLSR has come from in this respect. What I'm not clear on is why you'd use OLSR instead of say OSPF as your preferred IGP or maybe I've missed the point.

[dc2005]

OSPF does handle duplicate connections quite well and can provide for self healing nodes. It has a major weakness, though, in that it is only a 2 layer network. It is meant for a long straight backbone, such as from a fibre run, with nodes that feed off it. If you have nodes that feed from the nodes it does not work, although there is the concept of a virtual area to extend that another layer.

OLSR combines RIP and OSPF and a few other concepts and allows a multi layer network that can be self healing using redundant connections. We consider it to be the next logical step in routing.

Lonnie - I agree one of the drawbacks of OSPF is that the required computing power can increase rapidly as networks scale up. However, I'm not sure what you mean by saying OSPF only works for a 2 layer network. I presume you mean that you can have a backbone (Area 0) and then other areas that feed off the backbone. If you use multiple areas, OSPF should scale reasonably well as the routers belonging to a specific area build and analyze the full network graph only for that area.

I guess the real question is which is the safer bet in terms of rolling out a scalable network that supports backup routes and multiple possible paths through the network in the event of failure. The answer may be only be clear when there have been some large scale and well tested deployments of OLSR. It will be very interesting to see how it pans out in practice.

[lonnie]

We are converting our 100 km backbone this week, but first I have to work out how to not shut it down while the changeover happens. I'll keep the Forums advised.

[lonnie]

Well it is mostly running on every machine in the system but in parallel to RIP, which was running things nicely.

I have a couple of machines at some edge points that do not have RIP or even defualt routes and they can get to the net and can ping all machines in the system. Tomorrow I will start to shut RIP down and see if things remain routed.

[dc2005]

Lonnie - is your backbone network configured as a ring i.e. do you have any backup route(s) in the case of failure? This would be the real test for OLSR, to see if the network reconverged quickly and reliably in the event of a failure somewhere in the primary route. If this works reliably and quickly in a decent sized network then you have something really useful - particularly if it's (as it appears) easy to setup and maintain. Keep us informed of your progress.

[tog]

Wow, I'll be real interested to hear about what happens when you shut RIP down and see if OLSR takes over. For the sake of not blowing things up for 15 minutes I hope that after shutting RIP down and having quagga remove its routes that OLSR is really smart. Although you could probably just reboot and avoid the possible quagga-removing-its-routes-related confusion for OLSR. I'd be scared to run both quagga and OLSR at the same time but you seem to already be doing that anyway. I'd be concerned about two completely different unrelated daemons both wanting to inject (possibly different) entries in my routing table.

[mp3turbo]

> I'd be concerned about two completely different unrelated daemons both wanting to inject (possibly different) entries in my routing table.


why? You have metric and you can have duplicate entries like

192.168.200.0/24 via 192.168.0.1 injected by RIP
192.168.200.0/24 via 192.168.0.1 injected by whatever else.

Actually, we run our network for a while like this - manual entries mixed up (should I say messed up?) with dynamic routing. No problem.

bye, mp3turbo.

[lonnie]

It was trouble and we figure that leaving quagga zebra running was still conflicting. We have a new test with quagga zebra daemon being removed entirely if neither RIP or OSPF are selected. I'll try this on the weekend and see what it does.

[jasontomlinson]

OLSR has been in play/testing since Fall 2005 and we felt it was indeed ready for use. This is not the MESH that people think about, with its ADHOC mode and using a single radio. It uses all available devices (radio and Ethernet) and performs auto routing between connected systems. I call it OSPF on steroids.

Several of the purportedly robust mesh solutions use separate, dedicated radios for send and receive functions:

http://meshdynamics.com/WhyStructuredMesh.html

http://www.strixsystems.com/products/default.asp

The 533 WAR board with 4 mini-pci slots seems like a good candidate to host one mesh ingress, one mesh egress, and one client access radio. Any thoughts on how this architecture could be accomplished in StarV3 utilizing the OLSR protocol? Would it require a driver rewrite in order to dedicate a radio to one direction of traffic?

Jason Tomlinson
Orion Technology, LLC
www.oriontechnology.com

[lonnie]

Are you asking for full duplex? We see these as several backbone radios with serveral AP for client microcells.

[jasontomlinson]

Are you asking for full duplex? We see these as several backbone radios with serveral AP for client microcells.

I'm trying to understand how several backbone radios can be configured in StarV3 to accomplish a full duplex backbone...separate from client access APs.

[lonnie]

Full duplex can be simulated with hand entered static routing. To do it properly and make it an easy click the check box we will have to do a driver mod. It is in the plans.

[jeff]

To do it properly and make it an easy click the check box we will have to do a driver mod. It is in the plans.


Sooner rather than later???????????????

Please???????????????

[ninedd]

Several of the purportedly robust mesh solutions use separate, dedicated radios for send and receive functions:Jason, I've read (quickly) these sites and are you certain they are talking about two radios for send & receive as in full duplex, or are they justtalking about two radios for send & receive futher up & down the backbone? When I read it, that's what I understand them to be talking about - having a 'backhaul' radio and a 'forehaul' radio, as well as of course an AP radio.

[jasontomlinson]

Jason, I've read (quickly) these sites and are you certain they are talking about two radios for send & receive as in full duplex, or are they justtalking about two radios for send & receive futher up & down the backbone? When I read it, that's what I understand them to be talking about - having a 'backhaul' radio and a 'forehaul' radio, as well as of course an AP radio.
That's my understanding also...a 'backhaul' and 'forehaul' radio. There seems to be a shortage of terms to accurately describe this architecture. Sorry for any confusion surrounding 'full duplex.' What I'm looking for is a way to assign assign 'backhaul' and 'forehaul' radios within the context of OLSR mesh in StarV3.

Full duplex can be simulated with hand entered static routing. To do it properly and make it an easy click the check box we will have to do a driver mod. It is in the plans.
We currently have a home grown testbed with WDS (client association disabled) and static routing that accomplishes the above mentioned goal, but deployment and route planning are cumbersome. We'd like to use OLSR with multiple radios to accomplish a robust mesh backbone architecture. Glad to hear that it is in the plans...I'll look forward to seeing it in future releases.

[ninedd]

That's my understanding also...a 'backhaul' and 'forehaul' radio. <EDITED> What I'm looking for is a way to assign assign 'backhaul' and 'forehaul' radios within the context of OLSR mesh in StarV3... <EDITED> ...We'd like to use OLSR with multiple radios to accomplish a robust mesh backbone architecture. Glad to hear that it is in the plans...I'll look forward to seeing it in future releases.Well StarOS can do that right now. That's what we do with V2 right now, not with OLSR, but certainly with the other routing protocals. Three radios, one to feed 'back' to the internet, one to feed 'forward' to the next AP, and one to serve as an AP for customers. My first WAR's should be here tomorrow (yay!) so I'm talking from documentation, not experience. However, with Star/OLSR and three radios, there's no reason that StarOS can't do this right out of the box, right now.

[lonnie]

We use 4 radios.

#1. One input with Internet connection, 2 AP on Channel 1 and 11, one output to next cell, which is identical to the one that feeds it.

OR

#2. One input with Internet connection, 3 feeds to next cells that are idential to scenario #1, above.

[jasontomlinson]

We use 4 radios.

#1. One input with Internet connection, 2 AP on Channel 1 and 11, one output to next cell, which is identical to the one that feeds it.
In the context of "mesh" networking, I'd like to have the four radio setup above, except without having to identify which "non-client access" radio goes connects to the Internet and which one hops to next cell. OLSR w/dynamic gateway plug-in provides this function, but I'm still left trying to understand how to configure the radios themselves (ie.- AP, STA, WDS, channel assignments, etc).

[lonnie]

Just set them to connect with another unit. One of them is AP and the other is Client. Position the AP so it can be seen by several clients and you have a node with multiple connections. Then use multiple radios with multiple connections and you have a MESH. Dynamic gateway has not been tested but we have used the HNA to announce Internet gateway and units with no default route get sent to it.

[ninedd]

My first WAR's should be here tomorrow (yay!) so I'm talking from documentation, not experience.OK, tomorrow is now today. Actualy, it's 2:30 AM, so tomorrow is already yesterday....

So, how do I setup this OLSR? The manual that came with my WAR boards was unfortunately written in invisible ink, and apparenly on invisible paper as well (LOL) so I'm a bit confused.

Should I be able to simply set each WAR board up with IP's and turn on OLSR and watch it go? Or do I have to manually put default routes in? What about a masq statement?

Computer = 192.168.1.2/24 wired to WAR1

WAR1 - Ether1 192.168.1.1/24
WAR1 - Ether2 192.168.2.1/30
|
| wired to...
|
WAR2 - Ether1 192.168.2.2/30
WAR2 - Ether2 192.168.3.1/30
|
| wired to..
|
WAR3 - Ether1 192.168.3.2/30
WAR3 - Ether2 192.168.4.1/30
|
| wired to..
|
WAR4 - Ether1 192.168.4.2/30
WAR4 - Ether2 192.168.5.1/30
WAR4 - Wpci1 192.168.6.0/24 in AP mode

[tbutcher]

I have the same problem. Even though I use Star-OS for everything one thing that I like about Mikrotik is that they provide examples for almost all of the router functions so it makes it easier to understand and setup. A couple of Star-OS How-to guides might help people and reduce the support burden.

Tim

[lonnie]

With any GPL or BSD licensed software it is always a good idea to visit the site and get the manual with visible ink. I even posted a link to it when I gave a heads up that we were going to include OLSR. http://www.olsr.org/docs/olsrd.8.html

The basic thing is to setup IP addresses on your devices and go into the olsr config and enable the devices near the bottom. We include them all, so it really should be running if simply enable OLSR. You would edit this list to add vds devices or to not announce certain devices.

If OLSR turns on you will soon be able to ping other OLSR machines and IP's that they see. It is pretty easy.

[ninedd]

Yes, thanx. It actually was working and I didn't know it. What wasn't working was my Ping from the computer to the first WAR for some reason, but when I logged into the WAR, I can ping from there to the other end of the OLSR network with no problems. I 'repaired' my Windows Ethernet connection and all was well. I have no idea why I could putty in, yet couldn't ping... Not reall possible I don't think? But, that's what was happening. Not a WAR issue at all - just a issue with my computer.

So, yes, I still had to create IP's on the the devices that would connect to each other properly in the same subnet, so the WAR1's, AP card would be 192.168.45.1 and WAR2's Client card needs to be something proper like 192.168.45.2 in the same subnet, and of course they need to have the same Channel / SSID so that they can talk on that level, and then with OLSR turned on, they started passing data. Cool. Easy. Cool.

FWIW, I did (and do) read the manuals from the authors, which is great and fine and very informative. However, there is no where that on the http://www.olsr.org/docs/olsrd.8.html docs that really says ''in StarOS, this is how you should do it'', so the documentation from Cisco or Squid or who ever is not quite the same as having a step by step guide to how a StarOS Wireless network should be designed, configured and optimized.

Nontheless, OLSR seems very good to me so far. Much more testing this weekend.

[lonnie]

We give you the exact standard, factory, default olsrd.conf that everybody uses and it is documented. So, you do it in StarV3 exactly as you would do it in any other Linux or BSD system.

For more info http://www.olsr.org/docs/olsrd.conf.5.html

[ninedd]

We give you the exact standard, factory, default olsrd.conf that everybody uses and it is documented. So, you do it in StarV3 exactly as you would do it in any other Linux or BSD system.

For more info http://www.olsr.org/docs/olsrd.conf.5.htmlThank you. As I mentioned, I've read their online docs from A to Z. However, the documentation from OLSR or Squid or ISC or Cisco or whoever is simply NOT the same as having a StarOS manual.

In any case, this was simple and it was actually working fine. My Windows box simply needed to be rebooted. You know, standard Computer Service response ''Yes Sir. Shut up an reboot, Sir" :^)

[tony]

I am pleased you got it going.

[ninedd]

With OLSR on, I still seem to need to have a Default Gateway manually setup to point back to the previous machine. I thought it would broadcast the topology and it would be able to figure that out, but I'm not clear on how much I need to tell it, and how much it can figure out. Should I be able to simply set each WAR board up with IP's and turn on OLSR and watch it go? Or do I have to manually put default routes in?

Computer = 192.168.1.2/24 wired to WAR1
|
WAR1 - Ether1 192.168.1.1/24
WAR1 - Ether2 192.168.2.1/24
|
| wired to...
|
WAR2 - Ether1 192.168.2.2/24
WAR2 - Ether2 192.168.3.1/24
|
| wired to..
|
WAR3 - Ether1 192.168.3.2/24
WAR3 - Ether2 192.168.4.1/24
|
| wired to..
|
WAR4 - Ether1 192.168.4.2/24
WAR4 - Ether2 192.168.5.1/24

If I don't have a default gateway on 192.168.4.2 pointing back to the previous machine (0.0.0.0/0 -> 192.168.4.1) then I can't ping it from my 192.168.2.2 laptop.

[lonnie]

You need one machine in the network to announce that it is a gateway, by declaring and HNA entry of 0.0.0.0 netmask 0.0.0.0

The other units will then announce that and units with no default route set will take on a proper gateway to be able to get to it.

I don't understand how you can have a 192.168.2.2 for the laptop since you have that for the WAR. How are you connecting these? It looks like you are using cat5 between the Ethernet ports. How are you actually connecting anything except other WAR boards?

[ninedd]

I don't understand how you can have a 192.168.2.2 for the laptop since you have that for the WAR.Hi, thanx. Sorry, that part was a typo... 4:30 AM and all. :^) The laptop was actually at 192.168.1.2, so on the same subnet as the Ethernet of the first WAR board.

And yes, I started with them all wired by Ethernet so that I could eliminate any radio strangness from the equasion. I wanted to make sure that any inability to ping was a real routing config and not a radio issue with channels or anything like that.

And yes, for this test setup, it was just the laptop and the four WAR's, so they were not connected on either end to anything else last night. That'll be tonight's project. Fire up the coffee pot and give it a go.

You need one machine in the network to announce that it is a gateway, by declaring and HNA entry of 0.0.0.0 netmask 0.0.0.0I did figure this out about an hour later. I read and re-read those OLSR documents, but my MT/V2 network is all static routes so I've never really used a routing protocal of any kind. Around 5:30 AM I finally arrived at the fact that it just couldn't possibly 'self heal' if there was a static default route that told it all unrouted data needed to go one one particular interface. I removed the default routes from each WAR board, and put the 0.0.0.0 0.0.0.0 in the OLSR config file of the first WAR (192.168.1.1) and it all propagated fine and I could ping / bandwidth test end to end. :^) By the looks of things, there is really nothing else in the OLSR config that needs to be adjusted. All the possible devices are there by default, and the defaults on etherthing else are the recommended values anyway, correct?

Then, to test the Mesh healing - I then also connected wirelessly between WAR2 and WAR3 like this... (BTW, I know these 'point to point' links could be a /30 instead of a /24 - I just wanted to make the IP's easier to find if I mixed them up again. However, masking tape is my friend now.)

Laptop = 192.168.1.1/24 wired to WAR1
|
| Hard wired to...
|
WAR1 - Ether1 192.168.1.2/24 - OLSR HNA {0.0.0.0 0.0.0.0}
WAR1 - Ether2 192.168.2.1/24
|
| Hard wired to...
|
WAR2 - Ether1 192.168.2.2/24
WAR2 - Ether2 192.168.3.1/24
WAR2 - WCPI1 192.168.4.1/24
|
| Hard wired & Radio Linked to..
|
WAR3 - Ether1 192.168.3.2/24
WAR3 - Ether2 192.168.5.1/24
WAR3 - WPCI1 192.168.4.2/24
|
| wired to..
|
WAR4 - Ether1 192.168.5.2/24
WAR4 - Ether2 192.168.6.1/24

So, from the laptop, I can ping and starutil throughput test to 192.168.6.1, which is great. While it's doing that, I unplug the ethernet linking WAR2 & WAR3 and after three or four missed pings, it reverts to the Wireless link. My throughput test drops from 7000K to 2000K (11b link) but it all 'heals' perfectly. I then plug the Ethernet back in, and after 10 or 20 seconds, my throughput test jumps back to 7000K, so evidently it learned the Wired connection was preferable and routed back over that link. Me likes.

So, now that I understand that part of it, in order to put this into a real network, I'd have to number the Ether1 of WAR1 with one of our Public IP's and do a MASQ statement in that board, correct? Currently, we do this in a MT machine for our V2 network, but we could move that inside a V3 machine as well, correct?

[lonnie]

Correct. V3 on WAR does nat quite nicely.

We now have a WAR board controlling each Commercial ADSL modem and using policy routing on the system feeding them, we can determine which unit gets the traffic based on its source address.

With self healing backbones we now have a better system than ever.

[ninedd]

So, Policy routing isn't any sort of bandwidth agregation or multiple-default gateways, but it would allow us to say that traffic from Towers A & C goes out this T1, and traffic from Towers B & D goes out a differnt T1, correct?

[tony]

You are correct. The other features you list are planned however.

[kbldawg]

I am curious to know if the MESH V3 feature could be enhanced to re-route traffic from a problematic link (high latency, poor signal quality caused by a sudden increase in noise...etc), to one that is solid. Is this something that is possible to do? If so, I think it would really be something of value.

The reason I ask...

I have one particular backhaul link that has recently started receiving enough interference to cause really high latency, so much latency that it is almost impossible to log into the box to try and switch channels to get around it. In all practicality, the link is dead. The only way I can get around it is to watch and wait for the latency to drop to around a couple hundred ms, and then hurry up and try and log in, switch channels, activate, and hope that channel is clear.

Could this be used to re-route traffic from a poor link, to one that is solid, then once the link has stabalized it could re-route traffic back to the default link? That would be pretty cool.

[lonnie]

OLSR does rate links based on packet loss and will switch. Give it a try.

[ninedd]

I am curious to know if the MESH V3 feature could be enhanced to re-route traffic from a problematic link (high latency, poor signal quality caused by a sudden increase in noise...etc), to one that is solid.V3 MESH already does this. The OLSR tracks the connections based on a number of criteria, and will use a fast, stable link in favour of a slower, less stable link. http://www.olsr.org/docs/README-Link-Quality.html explains how it ranks the links, but basically it's testing the likelyhood of having to resend a packet, and will use the link which is the most likely to get the packet through unmolested.

[ninedd]

Hmmm. Me needs more help.... Network as described before...

Laptop = 192.168.1.1/24 wired to WAR1
|
| Hard wired to...
|
WAR1 - Ether1 192.168.1.2/24 - OLSR HNA {0.0.0.0 0.0.0.0}
WAR1 - Ether2 192.168.2.1/24
|
| Hard wired to...
|
WAR2 - Ether1 192.168.2.2/24
WAR2 - Ether2 192.168.3.1/24
WAR2 - WCPI1 192.168.4.1/24
|
| Hard wired & Radio Linked to..
|
WAR3 - Ether1 192.168.3.2/24
WAR3 - Ether2 192.168.5.1/24
WAR3 - WPCI1 192.168.4.2/24
|
| wired to..
|
WAR4 - Ether1 192.168.5.2/24
WAR4 - Ether2 192.168.6.1/24

and all works well. From the laptop I can ping 192.168.1.1 (myself) to x.x.1.2 all the way to x.x.6.1 with no problem.

Then I decide that I'd set the latop to 192.168.6.2 (gateway 191.168.6.1) and I'd plug into the other end of the link - into WAR4's Ether2 port. But, I can then only ping WAR4's Nics at 6.1 and 5.2, but not outside that. If I Putty into WAR4, I can still ping all the way down the line to x.x.1.2, but not from the computer plugged into it.

==========================EDIT==================== =====
OK, I put into the Hna4{} block 192.168.6.0 255.255.255.0 and restarted Mesh, and it now works. I didn't think I'd have to explicitly announce the network, since the interface is already 192.168.6.1/24.

So, is that the total of the Mesh typical mesh configuration? 0.0.0.0 0.0.0.0 on the Internet Gateway WAR, and ap.card.ip.address 255.255.255.0 on the AP WAR?

[kbldawg]

OLSR does rate links based on packet loss and will switch. Give it a try.

You can bet I will be doing just that. That is awesome!

[lonnie]

OLSR primarily exchanges /32 or p2p links with the system, thus you either need a system running OLSR to become known or you need the HNA statement for the network route so the machine will announce for all the non OLSR machines.

All in all it is pretty cool and makes a very nice dynamic routing method. We like it a lot.

[ninedd]

OK, thanx Lonnie. So on a typical WAR533, where we have a 'backhaul' radio, a 'forehaul' radio and two AP radios, we'd need to assign all four cards IP/Subnets of course, but also manually add in subnets of the two AP cards into the Hna4 {} Block then? This is the way you are doing it on your network?

[lonnie]

Yes, the subnets on the AP radios must be in the HNA and then the whole system gets the network route and can talk to non OLSR systems on that subnet.

OK, thanx Lonnie. So on a typical WAR533, where we have a 'backhaul' radio, a 'forehaul' radio and two AP radios, we'd need to assign all four cards IP/Subnets of course, but also manually add in subnets of the two AP cards into the Hna4 {} Block then? This is the way you are doing it on your network?

[phendry]

Is redistribution possible with OLSR? I.e, if one of our boarder gateway routers was a cisco box could the last WAR before cisco redistribute it's OLSR table into it's RIP table so that Cisco could redistribute into eBGP for peering?

[cxmoore]

How do you setup redundancy on the wireless side if all links are on different subnets? If a preferred route is WAR1 to WAR2 to WAR3 but WAR2 dies since WAR3 is within range of WAR1 is it able do heal around WAR2? Do both WAR1 and WAR2 have a radio set in AP mode with same channel and SSID that the WAR3 is looking for? Also does WAR3 have both WAR1 and WAR2's seperate subnets configured on the same interface?

[rebel2234]

Ok when you make a hna {0.0.0.0 0.0.0.0} that declares an internet gateway, how would you make it so that one gateway is favorable over another. In other words we have a fiber link on one end of our network and a load balancer with 5 dsl connections on the other. Ofcourse we want our traffic to go to the fiber but if the fiber fails then it would need to failover to the other end.

Another question:
This was posted by Inet2000
"OK, thanx Lonnie. So on a typical WAR533, where we have a 'backhaul' radio, a 'forehaul' radio and two AP radios, we'd need to assign all four cards IP/Subnets of course, but also manually add in subnets of the two AP cards into the Hna4 {} Block then? This is the way you are doing it on your network?"
-I thought you wouldnt make a hna declration on any device except those that have a internet connection. What is the point of having a declration on your AP radios? Could someone clear this up for me?

[tog]

An Hna4 entry is to announce to the rest of the network that you have this network attached to you. It tells the rest of the network to figure out routes over to you if they want to get to whatever network you are announcing.

If you want to prefer one route over the other when using my example OLSR config, you use LinkQualityMult to downgrade the linkquality of the non-preferred OLSR neighbor to 0.40 on those systems which would have the two choices available. This will affect the routing of all downstream systems as well, so it only needs to be done on the particular system(s) that have the choice between one direction or the other.