Open AlexHighTower opened 1 year ago
forward yes
can only be used in tree topologies - as soon as you build a loop of forwarding instances, packets will loop endlessly. Generally, the "forward" feature is mostly meant for star topologies as a simple replacement for OpenVPNs client-server configuration.
For anything more complex, disable forwarding in fastd, and instead put a bridge interface with STP on top the TAP interfaces of fastd running in multitap mode. Another option is to run a routing protocol like batman-adv on top of fastd (which may result in more efficient forwarding paths in meshed topologies).
I wonder if I should simply disallow connecting two fastd instances with forwarding enabled (which will prevent such misconfigurations, but also remove the possibility to use fastd in non-star tree configurations without additional setup...)
Looks like I completely misunderstood idea of "mesh" in this case ))) I have setup where each node has connection to each other And I expected that each node will be able to access any other node via internal address. But my tests showed me that it is not so if there is no direct connection between nodes by external ip and "forward no" "start" topology has disadvantage - central server, if it is not available, nodes looses connections... At the moment I have big amount of WG links between nodes, separate subnets for this connections and bgp over, it works quite well but complex in configuration and each node has its own subnet and internal ip from it, and I wanted to make it simple and ip from one subnet...
Right, fastd does not have any builtin mesh capabilities - instead, it is often used as a transport layer under a mesh routing protocol. If your network is based on Linux, batman-adv is usually a good choice, as it doesn't require any configuration except for unique MAC addresses, and it can provide a redundant L2 overlay network over a bunch of non-forwarding fastd instances in TAP mode (no need for multitap in this case).
I've tested batman-adv on my setup It looks like work, but now I see big amount of traffic between fastd nodes Even tcpdump shows no traffic on bat0 interface at the same time it shows a lot "ethertype Unknown (0x4305)" on fastd tap interface
Hello,
I'm using fastd v18 on ubuntu 20 and debian 10 have 5 nodes tap interfaces switch mode two on nodes has "forward yes" setting, other - no this setup works stable as soon as I change at any of other three nodes forward from "no" to "yes" I get arp flood like this
is it bug or feature?