RouTing

back to http://scratchpad.wikia.com/wiki/Sasecurity TableOfContents

http://localhost:8080/GaMing

Load balancing via Mikrotik
If you bring them in to one physical location and use a Dual WAN load balancing router between them and the Gateway Mesh box

But not as far as I am aware via two separate mesh boxes in the Mesh, you can specify preferred gateway on each Mesh AP

we have both scenarios working on same Mesh

So Yes and Load balancing No! unless someone knows better

> Lets say you want a mesh box to pull from more then one carrier > on the same physical network. Can the meshap pull from more > than one source at the same time and can it do load balancing?

>Lets say you want a mesh box to pull from more then one carrier >on the same physical network. Can the meshap pull from more >than one source at the same time and can it do load balancing?

Not by default - I would use a mikrotik router upstream to do the load balancing.

Adding second route ? Lets say you want a mesh box to pull from more then one carrier on the same physical network. Can the meshap pull from more than one source at the same time and can it do load balancing?

edit me
I will change my power to Auto and see if that helps. Also I noticed that when I did a reporter again, I got a tun0 instead the the tun1 shown below.. I wonder what that means, and if it is a clue as to what is going on.. Good Eyes, Ertay!

Your reporter on tha said node shows:

The only thing seems strange to me is that 1.72.16.248.1 should have the name tun0, not tun1. All my nodes except gateway shows these tunnels as tun0. I do not know if this differs anything. Also check with route commands what your tunnel IP shows and if it is default route and both having the same tunnel name.

I *might* have fixed it.. time will tell.. I really started think about routing.. and how nodes always are announcing themselves, and I someone mentioned rebooting the gateways every night.. So... Now the answer.....drum roll please I rebooted the far gateway that was not having any problems nor the nodes that it backhauls for. As soon as that was rebooted, all the problems on the other end of the network went away. So I guess the g/w node was putting out bad routes?

Event though we may have the same symptoms, I don’t think we have the same problem. My node that is having the problems only sees 1 other node. And doesn’t block any nodes, if it did, I would lose it altogether. It doesn’t do a signal re-test or anything. The tunnel just goes and then comes back. almost as if the routing table is just losing the tunnel route and then gains it again, while all the time keeping the 1.xx.x.x mesh address routing fine.

I'm getting the same thing. I have 5 nodes that dog leg around 18 apartment buildings. The reflection from these building I though we giving me some weird reading. For example: Unit "D" can mesh with unit "A" but between them is 16 floors and concrete and metal. Basically no way no how the signal is going to penetrate that building but because of the other building in the area the signal is bouncing around. Meshap reports that he can talk with the unit directly because of the signal strength but what it is getting is true noise. I change the network to "blocknode" these signal in order for them to properly " dog leg" around the build. When "blocknode" is working Reporter indicates that Unit "D" can see unit "A" via unit "C" Then what happens is Meshap does an automatic unblock node (even when Wiana setting is set to disable) I assume it is call broadunblock then all of a sudden the node start see the noisy environment and I start to loose units "A" and "C" I can ping them ok and I can ssh into them. Remotemanagement fails and people connected to these Meshap loose connectivity. I too am using dev 88 Too resolve the problem I reboot the Gateway nodes everyday. That seems to resolve the problem temporarily. Next I start getting a Broadcast Storm. I'm not sure if this related but the outer nodes i.e. "A" and "C" start reporting Broadcast Storm. I have been battling the network for weeks now. I have add some 200mW cards to increase sensitivity of Gateway but this only increased the problem. I'm not sure if the software is buggy or the operators is nuts. I wish we had a bench mark or better understand of what how blocknode actually works and if it is really working. I noticed that to use the "walled garden" you have to use dev 88. What I will try to do is first reduce power on the 200 mW cards Second if that doesn't work I will try to add blocknode in crontab every 10 minutes to stop the direct connections of the two nodes. Third If that doesn't work I will try to do the reversal and set Wiana to unblock nodes every 10 minutes again. Hopefully these combination may give me so clue to your and my problems.

I'm getting the same thing. I have 5 nodes that dog leg around 18 apartment buildings. The reflection from these building I though we giving me some weird reading. For example: Unit "D" can mesh with unit "A" but between them is 16 floors and concrete and metal. Basically no way no how the signal is going to penetrate that building but because of the other building in the area the signal is bouncing around. Meshap reports that he can talk with the unit directly because of the signal strength but what it is getting is true noise. I change the network to "blocknode" these signal in order for them to properly " dog leg" around the build. When "blocknode" is working Reporter indicates that Unit "D" can see unit "A" via unit "C" Then what happens is Meshap does an automatic unblock node (even when Wiana setting is set to disable) I assume it is call broadunblock then all of a sudden the node start see the noisy environment and I start to loose units "A" and "C" I can ping them ok and I can ssh into them. Remotemanagement fails and people connected to these Meshap loose connectivity. I too am using dev 88 Too resolve the problem I reboot the Gateway nodes everyday. That seems to resolve the problem temporarily. Next I start getting a Broadcast Storm. I'm not sure if this related but the outer nodes i.e. "A" and "C" start reporting Broadcast Storm. I have been battling the network for weeks now. I have add some 200mW cards to increase sensitivity of Gateway but this only increased the problem. I'm not sure if the software is buggy or the operators is nuts. I wish we had a bench mark or better understand of what how blocknode actually works and if it is really working. I noticed that to use the "walled garden" you have to use dev 88. What I will try to do is first reduce power on the 200 mW cards Second if that doesn't work I will try to add blocknode in crontab every 10 minutes to stop the direct connections of the two nodes. Third If that doesn't work I will try to do the reversal and set Wiana to unblock nodes every 10 minutes again. Hopefully these combination may give me so clue to your and my problems.

- Yes I can ssh into the node.. remember the node is not unreadable the 172.16 tunnel is. That is what is so strange…

Then a few minutes or seconds later it is reachable. This cause all downloads to stop and restart which kills many internet sessions. If both the mesh IP and the tunnel IP were unreachable, I would understand, but when you get great ping times to the mesh ppoint and get unreachable on the tunnel, it make me think something is happening to the tunnels.

can you ssh into the unreachable nodes? Sound like a stupid question but what dev are you using?

-       Help please.. I need to understand why or how this is happening..

I have the gateway ‘locked’ to the proper gateway and I have blocked the other routes, so there is no other way to get out. I was beginning to think this was a wifi problem unitl I noticed that a node further downstream is responding.. abit slow.. and its mesh ping time is also fine.

1.76.85.159 is alive (14.2 ms)- 172.16.137.2 is alive (698 ms)

There is no relation to the amount of traffic that is one the network. This problem happens at 6am and 1am at 12noon at 6pm.. I monitor the traffic at the gateway through a mikrotik router so I can watch all traffic.. and there is not a lot of traffic

When I look at the node they all seem fine.. they just don’t respond. And then they do.. but the mesh ip always seems to respond.

People are now calling asking why it is bouncing.

1.85.96.148 is alive (0.34 ms)

1.37.139.122 is alive (7.32 ms)---1st hop

10.203.199.39 is alive (5.38 ms)

1.76.85.159 is alive (14.2 ms)--- 3rd hop

1.252.243.83 is alive (14.9 ms)— 3rd hop

10.133.99.112 is alive (13.1 ms)

1.221.35.250 is alive (11.8 ms)2nd hop

172.16.194.2 is alive (13.5 ms)

172.16.137.2 is alive (698 ms)

172.16.244.2 is unreachable

172.16.248.2 is unreachable

=
No conflicting CellIds.. I have made sure they are all differenet, and I have all my nodes under 1 wiana account.

>At 2:20 pm -0800 11/11/04, Ken Nye wrote: >>Yes I can ssh into the node.. remember the node is not unreadable >>the 172.16 tunnel is. That is what is so strange© >> >>1.221.35.250   uses a tunnel called  172.16.244.2 >> >> >>1.221.35.250 is reachable and I can login and all is fine.. >>but >>172.16.244.2 the tunnel that everyone uses for internet access is >>not reachable >> >> >>Then a few minutes or seconds later it is reachable. This cause all >>downloads to stop and restart which kills many internet sessions. >> >>If both the mesh IP and the tunnel IP were unreachable, I would >>understand, but when you get great ping times to the mesh ppoint and >>get unreachable on the tunnel, it make me think something is >>happening to the tunnels. >> >>All nodes are running dev88 >> > >Have you got two nodes with identical CELLID1 values? If you have >meshboxes registered to different accounts with conflicting values, >Wiana won't warn you. The CELLID1 value is what is used as the 3rd >octet of the tunnel IP address. If there is a conflict, the tunnel >will be recreated pointing to a different meshbox, and so you will >see the tunnel going up and down all the time.

>Yes I can ssh into the node.. remember the node is not unreadable >the 172.16 tunnel is. That is what is so strangeŠ > >1.221.35.250   uses a tunnel called  172.16.244.2 > > >1.221.35.250 is reachable and I can login and all is fine.. >but >172.16.244.2 the tunnel that everyone uses for internet access is >not reachable > > >Then a few minutes or seconds later it is reachable. This cause all >downloads to stop and restart which kills many internet sessions. > >If both the mesh IP and the tunnel IP were unreachable, I would >understand, but when you get great ping times to the mesh ppoint and >get unreachable on the tunnel, it make me think something is >happening to the tunnels. > >All nodes are running dev88 >

Have you got two nodes with identical CELLID1 values? If you have meshboxes registered to different accounts with conflicting values, Wiana won't warn you. The CELLID1 value is what is used as the 3rd octet of the tunnel IP address. If there is a conflict, the tunnel will be recreated pointing to a different meshbox, and so you will see the tunnel going up and down all the time.

The node in question only sees one other node.. it is kinda out on a ledge and separate from the rest of the mesh. More info for the mind This node I am in is having the problem.. I am logged into and it is responding fine., 1.85.96.148 is alive (31.8 ms) is the gateway I have the tunnel to. Here again it lost the tunnel 172.16.248.1 is unreachable

1.252.243.83@meshbox:~# pingtest

10.69.142.61 is alive (0.53 ms)

1.252.243.83 is alive (0.35 ms)

10.207.227.152 is alive (3.96 ms)

1.221.35.250 is alive (2.86 ms)

1.254.54.186 is alive (78.2 ms)

1.85.96.148 is alive (31.8 ms)

172.16.248.1 is unreachable

http://h1.f518.mail.yahoo.com/ym/Compose?To=1.252.243.83@meshbox:~

If I do a reporter, it show no problems..

1.252.243.83@meshbox:~# reporter

br0      Link encap:Ethernet  HWaddr 00:02:6F:09:A1:E4

inet addr:1.252.243.83 Bcast:1.255.255.255  Mask:255.0.0.0

wlan0    IEEE 802.11b  ESSID:"SurfnetAP1"  Nickname:"1.252.243.83"

Mode:Master Frequency:2.412GHz  Access Point: 00:02:6F:09:A1:E4

Bit Rate:11Mb/s  Tx-Power=24 dBm   Sensitivity=2/3

Retry min limit:8  RTS thr=250 B   Fragment thr=500 B

Encryption key:off

Power Management:off

Link Quality:0 Signal level:0  Noise level:0

Rx invalid nwid:0 Rx invalid crypt:0  Rx invalid frag:0

Tx excessive retries:661736 Invalid misc:1442599   Missed beacon:0

Connected to the network

inet addr:172.16.248.2 P-t-P:172.16.248.1  Mask:255.255.255.255

0.0.0.0        172.16.248.1    0.0.0.0         UG    0      0        0 tun1

==>     21  DHCP clients

Mesh nodes detected

10.207.227.152 10.207.227.152 1 95 (100% @ 0)

1.221.35.250 10.207.227.152 1 95 (100% @ 0)

1.85.96.148 10.207.227.152 3 255

1.252.243.83@meshbox:~#

so why did it lose tunnel and nothing else? Dmesg window show no problems

NET: 40 messages suppressed.

192.168.213.193 sent an invalid ICMP error to a broadcast.

NET: 44 messages suppressed.

192.168.213.202 sent an invalid ICMP error to a broadcast.

NET: 39 messages suppressed.

192.168.213.193 sent an invalid ICMP error to a broadcast.

wlan0: Could not find STA 00:02:6f:33:ad:66 for this TX error (@27410416)

HJAODV: Gateway calling:1.85.96.148:

NET: 40 messages suppressed.

192.168.213.203 sent an invalid ICMP error to a broadcast.

wlan0: Could not find STA 00:02:6f:33:ad:66 for this TX error (@27410909)

HJAODV: Gateway calling:1.137.214.14:

NET: 39 messages suppressed.

192.168.213.203 sent an invalid ICMP error to a broadcast.

NET: 40 messages suppressed.

192.168.213.193 sent an invalid ICMP error to a broadcast.

NET: 39 messages suppressed.

192.168.213.193 sent an invalid ICMP error to a broadcast.

AODV: RREP from: 10.207.227.152 src: 1.252.243.83 dst: 1.37.139.122 - hop: 2 seq: 1099115662 lifetime 5000 Im going bald pulling my hair out.. help before it’s all gone J

This is an issue that I've seen in both OSS and Pro. What I suspect is going on is that the node momentarily hears a neighbor node closer to the gateway than it's current pathway, or even hears the gateway - and connects to it. Then, for some reason, noise comes into the channel and that connection drops out and it takes a moment to reestablish it's connection pathway to the gateway.

To solve this - consider setting MINSIG. You can check whether this is the issue by manually blocking all of the neighbors except the strongest and seeing if this clears up.

Let us know if this fits your mesh layout and if this solves your issue.

> Yes I can ssh into the node.. remember the node is not unreadable the > 172.16 tunnel is. That is what is so strange… > > > > 1.221.35.250    uses a tunnel called  172.16.244.2 > >  > >  > > 1.221.35.250 is reachable and I can login and all is fine.. > > but > > 172.16.244.2 the tunnel that everyone uses for internet access is not > reachable > >  > >  > > Then a few minutes or seconds later it is reachable. This cause all > downloads to stop and restart which kills many internet sessions. > > > > If both the mesh IP and the tunnel IP were unreachable, I would > understand, but when you get great ping times to the mesh ppoint and > get unreachable on the tunnel, it make me think something is happening > to the tunnels. > > > > All nodes are running dev88

> can you ssh into the unreachable nodes? Sound like a stupid > question but what dev are you using? > > These 2 tunnels report unreachable > > 172.16.244.2 is unreachable > > 172.16.248.2 is unreachable > >  but the mesh point itself responds fine. > > 1.221.35.250 is alive (11.8 ms)--- 172.16.244.2 is unreachable > > 1.252.243.83 is alive (14.9 ms)--- 172.16.248.2 is unreachable > I have the gateway ‘locked’ to the proper gateway and I have blocked > the other routes, so there is no other way to get out. > > I was beginning to think this was a wifi problem unitl I noticed that > a node further downstream is responding.. abit slow.. and its mesh > ping time is also fine. > > 1.76.85.159 is alive (14.2 ms)- 172.16.137.2 is alive (698 ms) > > > > There is no relation to the amount of traffic that is one the network. > This problem happens at 6am and 1am at 12noon at 6pm.. I monitor the > traffic at the gateway through a mikrotik router so I can watch all > traffic.. and there is not a lot of traffic > > > > When I look at the node they all seem fine.. they just don’t respond. > And then they do.. but the mesh ip always seems to respond. > > People are now calling asking why it is bouncing. > > > > 1.85.96.148 is alive (0.34 ms) > > 1.37.139.122 is alive (7.32 ms)---1st hop > > 10.203.199.39 is alive (5.38 ms) > > 1.76.85.159 is alive (14.2 ms)--- 3rd hop > > 1.252.243.83 is alive (14.9 ms)— 3rd hop > > 10.133.99.112 is alive (13.1 ms) > > 1.221.35.250 is alive (11.8 ms)2nd hop > > 172.16.194.2 is alive (13.5 ms) > > 172.16.137.2 is alive (698 ms) > > 172.16.244.2 is unreachable > > 172.16.248.2 is unreachable >

=
Yes I can ssh into the node.. remember the node is not unreadable the 172.16 tunnel is. That is what is so strange… 1.221.35.250   uses a tunnel called  172.16.244.2 1.221.35.250 is reachable and I can login and all is fine.. but 172.16.244.2 the tunnel that everyone uses for internet access is not reachable Then a few minutes or seconds later it is reachable. This cause all downloads to stop and restart which kills many internet sessions. If both the mesh IP and the tunnel IP were unreachable, I would understand, but when you get great ping times to the mesh ppoint and get unreachable on the tunnel, it make me think something is happening to the tunnels. All nodes are running dev88

Ken can you ssh into the unreachable nodes? Sound like a stupid question but what dev are you using?

These 2 tunnels report unreachable

172.16.244.2 is unreachable

172.16.248.2 is unreachable

but the mesh point itself responds fine.

1.221.35.250 is alive (11.8 ms)--- 172.16.244.2 is unreachable

1.252.243.83 is alive (14.9 ms)--- 172.16.248.2 is unreachable

I have the gateway ‘locked’ to the proper gateway and I have blocked the other routes, so there is no other way to get out.

I was beginning to think this was a wifi problem unitl I noticed that a node further downstream is responding.. abit slow.. and its mesh ping time is also fine.

1.76.85.159 is alive (14.2 ms)- 172.16.137.2 is alive (698 ms)

There is no relation to the amount of traffic that is one the network. This problem happens at 6am and 1am at 12noon at 6pm.. I monitor the traffic at the gateway through a mikrotik router so I can watch all traffic.. and there is not a lot of traffic

When I look at the node they all seem fine.. they just don’t respond. And then they do.. but the mesh ip always seems to respond.

People are now calling asking why it is bouncing.

1.85.96.148 is alive (0.34 ms)

1.37.139.122 is alive (7.32 ms)---1st hop

10.203.199.39 is alive (5.38 ms)

1.76.85.159 is alive (14.2 ms)--- 3rd hop

1.252.243.83 is alive (14.9 ms)— 3rd hop

10.133.99.112 is alive (13.1 ms)

1.221.35.250 is alive (11.8 ms)2nd hop

172.16.194.2 is alive (13.5 ms)

172.16.137.2 is alive (698 ms)

172.16.244.2 is unreachable

172.16.248.2 is unreachable

=
===================================================================