Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate fastd instance for inter-gateway traffic #112

Open
ohrensessel opened this issue Apr 27, 2015 · 8 comments
Open

Separate fastd instance for inter-gateway traffic #112

ohrensessel opened this issue Apr 27, 2015 · 8 comments

Comments

@ohrensessel
Copy link
Contributor

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
Copy link
Contributor

sargon commented Apr 28, 2015

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
Copy link
Contributor

do9xe commented Apr 28, 2015

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
Copy link
Contributor Author

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
Copy link
Contributor

sargon commented May 1, 2015

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
Copy link
Contributor

rubo77 commented Aug 6, 2015

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
Copy link
Contributor Author

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

@rubo77
Copy link
Contributor

rubo77 commented May 2, 2017

#200 is another attempt

@rubo77
Copy link
Contributor

rubo77 commented May 3, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants