I'd like to see ability to use it as a PPPoE client concentrator.

I'd like to be able to terminate different PPPoE sessions to different VLANs so I can use a 532 with a VLAN switch to service many customers in an MTU.

And can't you already do that?

I've asked on this forum as well as on the Part-15 Mikrotik listserv. I've even offered to pay consultants to come up with a solution for me and all contacted were unable to do so.

If someone knows how to do this, please let me know now.

Try creating a VLAN called "vlan1" then using the PPoE example here but substitute "interface=vlan1" for "interface=wlan1" when creating the IP pool and PPP server. You will need a separate IP pool and PPP profile for each VLAN

Try creating a VLAN called "vlan1" then using the PPoE example here but substitute "interface=vlan1" for "interface=wlan1" when creating the IP pool and PPP server. You will need a separate IP pool and PPP profile for each VLAN

To which example are you referring? If you're referring to Quick Setup Guide #1, that would just send the PPPoE request over the vlan instead of the wlan. I'm looking to have a wireless interface that the PPPoE tunnels are running over. Each PPPoE tunnel would terminate to a different VLAN. The different VLANs would be isolated from each other.

I understand that I will need a seperate DHCP server, IP pool, NAT rule(s), PPPoE users, etc. on the client concentrator.

perhaps i misunderstand but, routeros pppoe cannot encapsulate ethernet frames. afaik, it doesnt support anything other than good ol' IPv4. to achieve something similar you would need to have an eoip tunnel inside the pppoe tunnel.
if you just want to route the traffic onto different vlans based on static source ip then that could be configured policy routing. if however you are using dynamic ip's and want it routed based on user then that would require you to add static interfaces for those users (meaning it would make it alot more difficult to implement radius).

What I'm trying to accomplish is a multi-tenant facility with each client on their own VLAN, receiving their Internet via a wireless link to a tower. Each client is provisioned over its own PPPoE connection backed by RADIUS.

Currently you can create multiple PPPoE links, but the routing just decides a single PPPoE link to send all traffic over.

What is needed (unless it already exists in some form) is for ROS to be able to pool a VLAN and a PPPoE-client interface and isolate routing commands to specific pools... creating a bunch of mini-routers inside the one physical router. Perhaps a field when creating a route where you can specify an interface pool to be assigned to (with a global pool being an option). Any routing command created elsewhere (other th an global) would have no effect on that particular pool.

Please tell me if this makes sense and if there is already a method of doing this. If there is no current method and what I'm saying makes sense, I'll request that feature.

it's called policy-routing. that tag you talk about is called a routing-mark
however, it wont necessarily be so clean as you want (policy routing requires isolating the packets necessary and that can be done pr interface or pr ip field) but yes, "multiple mini routers".

Okay, because of the various different responses you keep getting, I'm not really sure how to interpret your request. Perhaps a diagram would help?

Some clarifying questions...

Are you saying that each tenant in the MTU will be associating to your network wirelessly, or merely that the MTU building will be connecting to the internet with a single wireless connection and then you are breaking out ports on a VLAN'd switch to each unit in the place?

If the former, I don't think there's any way to do what you want, nor do I really understand why it would be desireable. If you have an AP, and you want each client's traffic to be separated into its own VLAN, well, in 802.11, each SSID only works as if it is a "single" switchport. You can't "untag" multiple VLANs on a single switchport and expect things to work. So you would need to deliver traffic to every associated client with the 802.1q tags intact, their wireless client would need to be able to decipher 802.1q-tagged wireless frames, and each tenant would need to manually program their wireless client so that it knows what VLAN-ID their traffic has been assigned. And this is all assuming that 802.1q and 802.11 get along...I'm not sure that 802.1q works reliably (if at all) over 802.11 frames. It would be WAAAAY easier to just set up a PPPoE client on every tenant's computer and turn "default-forwarding" off on your AP interface to get the kind of traffic separation/security that it sounds like you desire.

The other (equally convoluted but technically possible) way that you could achieve VLAN-to-WLAN-association mapping would be to use an Atheros card as an AP so that you could take advantage of the Virtual-AP interfaces. Create a separate Virtual-AP per VLAN/customer, give each VAP a distinct SSID, and then bridge the VAP with the VLAN interface you wish to assign to it. Presumably, in order to make sure that there was only one customer per VLAN and that the customers were on the VLAN you intend for them to be on, you'd have to use some kind of security/enforcement, such as turning off "default-authentication" and adding their wireless MAC statically to the wireless access-list for their VAP interface, or perhaps giving every VAP a separate WEP/WPA key that only the customer who is supposed to associate to it is privy to.

This sounds like a whole lot of trouble for little questionable benefit. If everyone had their own PPPoE tunnel on a single AP interface, even without default-forwarding turned off, I can't imagine that customers would (typically) be able to peer into the other PPPoE tunnels that their neighbors are using. PPPoE tunnels in this case effectively == VLANs.

Now, if what you mean is that you have a wireless connection to the building and a switch + MikroTik in the building that you are using to separate each tenant's traffic (presumably connected via good-ol' hard-wired ethernet) into different VLANs, and rather than routing all of those different networks to a single outbound you wish to map each VLAN to a specific pppoe-client interface, then it should be possible to do what you want, I would think. There will be some tricks to doing so, though, and I don't think you will be able to automate most of this through RADIUS...most of the configuration will have to be done statically on the PPPoE-client "concentrator" MikroTik, as you have been referring to it.

If the DHCP pools for the different VLANs are handing out IPs from the non-publicly-routable space, for example, I think you could do something like...
...for every VLAN + PPPoE-client pair 'x'. In addition, you will need to set up some kind of policy for routing as sten pointed out earlier:
...where 'x' follows the same convention as before (VLAN or customer #x), and [PPPoE-remote-IP-x] is the remote-address value that the PPPoE server/concentrator assigned to itself for tunnel 'x'.

Now, here is where it gets tricky. Most people set up their PPPoE servers/concentrators (not talking about your "client concentrator" here, and the fact that I have to clarify this is why I dislike the use of the word 'concentrator' for anything other than the PPPoE server itself!) so that each tunnel that comes up has the same "local-address" (from the concentrator's perspective, or "remote-address" from the client's perspective). When the PPPoE tunnel comes up on the client-side and "add-default-route" is set to "yes" for that PPPoE-client interface, the gateway for that 0/0 route will be the IP address that the PPPoE server is reporting it has to the client. If all of your clients on the MikroTik at the MTU are concentrating on the same server (and, if they are all coming back to you on the same wireless link, they most likely are) and 'local-address' on that server's PPP Profile is the same for every tunnel, then the MikroTik PPPoE client "concentrator"/router at the MTU will not know which PPPoE client interface to send traffic out to, because every PPPoE tunnel running on it will have the same remote-address value!! This is a problem, because when you are statically adding routes, you cannot specify "interface=x"...the interface is automatically determined by the MikroTik when it looks to see which interface the gateway that you specify is connected to.

There is a way around this, however. You simply need to make sure that for every PPPoE tunnel that comes up on the server, it assigns itself discrete 'local-address' values per tunnel, and then make sure to use that value for the gateway fields on the client end when adding your routes. You can do this by setting the 'local-address' value statically for a given user under '/ppp secrets', or you can assign an entire IP Pool to the 'local-address' value for the profile you are using for the PPP Server under '/ppp profile' (but that might not work out since, when you assign the IPs dynamically from a pool, you aren't guaranteed to get the same remote-address for the server from the client's perspective, so the route on the client will break if the tunnel goes down and comes back up...it might be possible to script something up on the client that can programmatically determine what the server told the client its remote-address was for a given PPPoE-client interface). I think it might even be possible to tell the PPPoE server what to use for a local-address via RADIUS, which would probably be what you'd want to do anyway.

Also be sure to turn 'add-default-gateway' OFF for every PPPoE-client interface you create on your client "concentrator," with the exception possibly of the PPPoE-client that you will use for management of the MikroTik (if you use a PPPoE client to access the MikroTik from afar, otherwise just create a static default route yourself for the purpose).

You may need to tweak some things and play around with it a bit, but hopefully that will get you started. Mapping VLANs to distinct PPPoE client interfaces through routing is an interesting idea, but in the end it may be more practical to do something like stretch some tagged VLANs through the wireless link (if you're using something like nStreme+WDS), bridging those VLANs with the customer VLANs (one bridge per customer), and then do all your routing on the MikroTik at the other end of the wireless link. I dunno. I guess it depends on what exactly you are trying to do and what your purpose/goal in all of this is.

Good luck,

-- Nathan

rereading the original posts i would say that you (Hammy) could potentially do this with multiple pppoe servers with different service names servicing a single distribution vlan and multiple access vlans. it would be clean and simple.

other more traditional service providers either isolate end users in vlans from the start (together with ethernet mpls) or use pppoe/pppoa+l2tp.

Now, if what you mean is that you have a wireless connection to the building and a switch + MikroTik in the building that you are using to separate each tenant's traffic (presumably connected via good-ol' hard-wired ethernet) into different VLANs, and rather than routing all of those different networks to a single outbound you wish to map each VLAN to a specific pppoe-client interface, then it should be possible to do what you want, I would think. There will be some tricks to doing so, though, and I don't think you will be able to automate most of this through RADIUS...most of the configuration will have to be done statically on the PPPoE-client "concentrator" MikroTik, as you have been referring to it.

That's the trick. I have yet to try what you suggested, but that is what I am trying to do, so I will do what you suggested.

I'm not sure if I didn't explain things well, but I thought it was a rather simple extension of a basic thing people do. I use RADIUS backed PPPoE to serve my clients. I figured it only made sense to use one router in a multi-tenant facility instead of 30 or 40.

I'm not sure if I didn't explain things well, but I thought it was a rather simple extension of a basic thing people do. I use RADIUS backed PPPoE to serve my clients. I figured it only made sense to use one router in a multi-tenant facility instead of 30 or 40.

Where do you see the advantage in creating multiple (one per customer) separate PPPoE sessions and multiplex them onto your wireless uplink versus just using the wireless uplink as one single upstream connection for all the MTU customers as a group? In other words, why do you feel the need to keep the MTU clients separatable beyond the router that is placed in the MTU building and connected to the VLAN switch?

I'm not trying to argue against that idea, I'm just curious to learn more about your motivation behind it.

--Tom

If I can keep them seperate, it allows me to use RADIUS to automate provisioning. If a customer wants to signup for service, change their service, etc... that's all automated and I don't have to put in hours to make it happen. I don't have to allocate a /27 to an MTU that has a bunch of tenants, but only provides 3 accounts. It allows me to assign a /24 to that tower and then I can add mroe IPs on an as-needed basis, but has a higher liklihood of not being wasted.