ffnord / ffnord-puppet-gateway

Deploy and manage your Freifunk community gateway, mostly compatible with Gluon.
15 stars 13 forks source link

radvd only on gateways with IPv6 uplink/icvpn #46

Open ohrensessel opened 9 years ago

ohrensessel commented 9 years ago

radvd should only run on gateways which have some kind of ipv6 uplink for the prefix they are announcing. let it be icvpn only or ipv6 uplink via icvpn and the förderverein. it makes no sense to have radvd on gateways that do not have such a connection, as the prefix is already distributed by the nodes itself.

sargon commented 9 years ago

Every gateway should only announce prefixes which it is part of. For every route not accessible directly from a gateway, but which it knows of via bird6, it will communicate that a more direct neighbour is down the road via icmp redirection messages. AFAIK all ipv6 enabled OSs are respecting these messages, and will redirect traffic of connection to the according gate.

ohrensessel commented 9 years ago

ok. wasn't aware of that, thanks

ohrensessel commented 9 years ago

I would like to reopen this issue, basically because Freifunk Rheinland recently came across an issue with RAs in their network and a Gluon based firmware. They have 10 Gateways in one mesh, each of them running radvd. This resulted in nodes crashing because they could not cope wiith this amount of RAs. (see for example freifunk-gluon/gluon/issues/277)

I would still like to see radvd running only on gateways which have a direct IPv6 Uplink or a direct IC-VPN connection. At least this is the setup we are using here in Hamburg right now and it works quite well. Gateways without IPv6 Uplink or IC-VPN connection aren't really IPv6 Routers if you want.

If it is not fine with you to activate radvd only if there is a IPv6 uplink or an IC-VPN connection present, I would like to implement a switch to disable radvd by using the params module. similar to what we are doing for bird4 and bird6.

do9xe commented 9 years ago

then we should install RADVD just as a dependency of tinc and bird6 or the FF Reihnland uplink package

sargon commented 9 years ago

Okay. We have discussed the profile pattern on congress. I would like to see this as an first step towards this direction. I dislike the idea of having something like radvd depending on tinc, bird or whatever, but as an dependency to some profile or functionality target. So yeah lets build a switch for that into the mesh profile for now.

To be honest, when some node is crashing because of announced routes, that is a bug and not one to be searched in the backbone.