Hi,
On Montag 10 Dezember 2007, Predrag Balorda wrote:
Before I go round upgrading my routers, are these two incompatible because it seems so?
Yes, everyting < 863 is incompatible with revisions >= 863
If so then I'll need to figure out the exact order of upgrading (i.e furthest first - I don't want to have to climb roofs or walk too long)
The following should be possible even without any upgrading order - allowing a completely seamless, in-the-field protocol migration. May sound a bit oversized but is probably the only way for large-chaotic mesh networks.
In short this approach involves three steps:
1) Install the new batman version in parallel to the existing one (ensure independent operation of the two protocols, more details below...)
2) Test the new batman version
3) Disable the old batman version
Now the long and detailed howto. Don't be afraid it turns out to be much easier than it first sounds.
0) You keep your current revision running as it is.
1) Install the new version in parallel to the existing one. Do NOT enable GW-client mode (-r of -p) before step 2. Configure the new version with independent: a) alias interfaces and IP ranges ( e.g. use eth0:bmx 103.x.y.z/8 in addition to eth0:bat 105.x.y.z/8 )
Ensure that the old batmand gets (re-)started after the new alias interfaces and ip ranges have been configured. Thus, either - you only restart the old batmand after the new interface configuration or - you put the bat and bmx alias-interface configuration in your startup scripts and reboot your device. The reason for this is that batman learns about the networks of a node during its startup process and takes care that packets towards these networks are not routed into the batman tunnel. Because we don't want the 103.0.0.0/8 traffic (related to the new batmand) to be routed via the bat0 tunnel of the old batmand, we have to make sure that the old batmand knows about it.
b) binary name (e.g. rename the binary to /usr/sbin/bmxd) c) protocol port numbers ( e.g. use 14305 instead of 4305 ) d) ip preference rules (e.g. use 14xxx instead of 6xxx) e) ip routing tables (e.g. use table 144-148 instead of 64-68 ) f) gateway tunnel ip ranges (e.g. use bat1 169.254.128.0/22 instead of bat0 169.254.0.0/22 ) g) unix-socket identifier to access debug messages
The good thing is, the --neta option cares for task c,d,e,f,g automatically, so the only tasks left are the binary names and the interface configuration (and of course the annoying firewall configuration)
2) Now - when the new version is installed everywhere - it can be tested. So fare GW-Client mode should not have been activated with the new version. Therefore, the first testing can only involve the routing inside the mesh, the cpu load of the new version,... One note, to access the debug output of the new batman version use --neta -cd1 , the verbose output has moved to debug-level 8 (--neta -cd8)
To test internet connectivity I assume that the nodes which were operating in GW-mode with the old batmand are also operating in GW-mode with the new batman version. But so fare GW-Client mode has not been activated with the new version. The GW-Client mode (e.g. -r 3) configures your default route and there can be only ONE default route per node. So here each node/user has to make a choice. The good thing is, this choice can now be done independently at each node. Since revision 811 (this is before the compatibility change) you can use -c -r 0 to dynamically deactivate GW-client mode with the old batman and --neta -c -r 3 to dynamically activate GW-client mode with the new version.
3) Once every node and user is convinced that using the new batman version for routing and surfing the internet pays out (thus uses -r 0 with the old batman and -r 3 with the new version) the old version can be gradually deactivated.
happy routing, axel
Best regards,
Pele
P.S. also has anyone compared network throughput between beta and exp and are there any benefits to beta over exp?
P.P.S I'm experimenting with PoE and guess which process is the first that gets killed because of undervoltage?! :-)
B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n