Hello,
I would like to deploy my WISP network as per attached picture:

• A common backbone network
• Several access networks, each with its own broadcast domain
• A unique access concentrator that receives PPPoE requests from Customers from their access networks

The point is on how to connect Access Networks to my Access Concentrator via the backbone without sharing the same broadcast domain. I think that there are two solutions: VLAN and Tunnels. Due to the fact that the VLAN approach needs managed switch along the network, I would like to deploy the tunnel solution.
The backbone is an entirely private network(no security problems) so the best solution seems to be using one EoIP tunnel per each access network.
Is this approach the right one? Has anyone already used it?
I have a problem with EoIP: e.g. trying to create the tunnel between 172.22.1.1 and 192.168.2.1, as described in the manual, it seems that the tunnel doesn’t work because PPPoE requests don't reach my Access Concentrator. Does EoIP work on is own or does it need another tunnel (e.g. PPTP) to work on it?
Best Rgds

The scenario you describe is used in a lot of WISP networks I know.
Be sure to use MAC addresses from the range specified in the manual for the EoIP interfaces, or you will have the strangest effects... Unfortunately WinBox is suggesting "wrong" MAC addresses for EoIP interfaces

Thank you cmit,
my mistake was exactly the EoIP MAC address: i left the one assigned by WinBox...
With this architecture, there are two possible solutuions on Access concentrator:
- one PPPoE server instance for each EoIP tunnel, in order to keep separate access networks broadcast
- one PPPoE server instance on a bridge that includes all EoIP tunnel interface, sharing access networks broadcast

I think that the first solution is the best one, its advantages should be:
- more flexibility on troubleshooting at data link level (more broadcast domains)
- more flexibility on PPPoE profile management/profile definition

Do you agree?

Rgds

That depends on personal opinion I think

You could also bridge the EoIP tunnels at the AC and use bridge firewall rules to not create one big broadcast domain.

Thank you Cmit,
I've tested EoIP solution in my lab and on-site(with ROS 3.11).
Unfortunately, in my lab everything is ok but on-site I'm experiencing extensive data loss (about 40%) . Do you have similar results? In this conditions is not possible to use EoIP tunnels for me.

Rgds

Keep in mind, using VLANs or EoIP Tunnels does not "reduce" the broadcast domains. Your ARPs and Broadcasts will go accross your entire network and backhauls.

I do know lots of Wasps doing this, and a lot that have figured out that they should not send data across their backhauls if they don't need to. So they term their PPPoE connections at the tower, and route their networks.

That's basically a question which design you like more - one centralized PPPoE server, or distributed.
You can jsut as easily make sure that only PPPoE traffic is traveling through your EoIP tunnels back to the central PPPoE server.

Having 40% packet loss surely is not normal - but that would probably point to some other problem on the underlying infrastructure/wireless link?!

Thank you gmsmstr/cmit,

regarding broadcast, probably ARP will go also on backbone, but PPPoE will not. I've tested this, referring to the posted picture: if I enable 3 PPPoE servers on MT1 (on backbone, EoIP tunnel1, EoIP tunnel2 interfaces), I can authenticate on access network only to the corresponding PPPoE server. For sure placing PPPoE server at towers is a good solution, I'll investigate it deeply if EoIP tunnels one fails to reach stability. This will be a good solution as well because each PPPoE server behaves like a NAS to the centralized RADIUS that looks for uid/pwd/profile on centralized database (mySQL). The only "problem" with this approach is that PPPoE distributed addresses need to be routed accross the entire network...

Packet loss has nothing to do with wireless network because without EoIP tunnel (to the same client), connection is perfect (0% packet loss)...