Separate fastd instance for inter-gateway traffic

[ohrensessel]

I would likle to have this as a feature to separate the user- from the gateway-connections.
advantages: monitoring of inter-gateway traffic, which is otherwise not distinguishable from gateway-node traffic. high load from user traffic does not influence the inter-gateway traffic (important e.g. for ipv6 uplink which not every gateway offers).

this would include a separate backbone key repository, so that node and gateway keys are separated. otherwise the cron script updating the keys would have to sort them in regard to node or gateways keys, which would be a little hacky from my point of view.

[sargon]

I like the idea, we should implement support for multiple fastd instances per community at first and also add an concept so that these instances share their peers directory. The later can be implemented
by checking out the peers repositories in some directory under /var.

After we have such concept, the topic of this issue is just a matter of minor changes and configuration in the gateway manifest.

[do9xe]

Couldn't we simply implement a few lines in the mesh-peerings.yaml?
as this file is used for the iBGP connections we could simply add the fastd information to it. I don't see why we would need a repository to maintain the fastd-keys of the gateways. We should simply generate the key-files within a puppet run. If you add a gateway to the list you need to run puppet again anyway ;)

[ohrensessel]

mh yes we could think about something like that. the idea is not bad.
but then we somehow force users of the puppet script to do it that way (I
have no problem with that)

2015-04-28 9:51 GMT+02:00 Hendrik Lüth [email protected]:

Couldn't we simply implement a few lines in the mesh-peerings.yaml?
as this file is used for the iBGP connections we could simply add the
fastd information to it. I don't see why we would need a repository to
maintain the fastd-keys of the gateways. We should simply generate the
key-files within a puppet run. If you add a gateway to the list you need to
run puppet again anyway ;)

—
Reply to this email directly or view it on GitHub
#112 (comment)
.

[sargon]

I like the idea of having all the gateway or backbone-fastd keys in on repo, so they are visible to the outside or much easier to maintain.

[rubo77]

And if we would have an extra fastd instance for the inter-gateway traffic, we could easily cut all clients from one gateway in maintenance mode by disabling the client fastd-instance.

Without special fastd instance I would add this to maintenance on:

• disable the peers update-cronjob
• sleep 3600
• rm all client-fastd-keys from the peers folder
• reload fastd

maintenance off would

• re-enable the cronjob

What is the drawback of this method?

Or maybe we should add a line in the fastd.config that limits the number of peers to the number of gateways instead, for example:

peer limit 4;

[ohrensessel]

#128 adds a second fastd instance for inter-gateway traffic

[rubo77]

#200 is another attempt

[rubo77]

https://forum.freifunk-muensterland.de/t/howto-multi-fastd/309