You say: * Direct L2 communication between the AC and the client needed to work. * Since the tunnel is PtP each client can (should) be its own L2 segment. So I understand that the VPLS tunnel is needed in order to establish a L2 connection between customer and PPPOE AC, for PPOE to work. So how does this apply in the case of a WISP? Does every CPE device need to be MANUALLY configured with a VPLS tunnel back to the TT? Isn't this a maintenance nightmare or am I missing something?
OK so after reading through the slides a bit more carefully I realised that the vpls tunnel extends between the tunnel concentrator and the Tower Router. The vpls tunnel on the router is bridged with the interfaces connecting to the CAPs. On the other side on the AC, the interface running the PPPOE server is bridged to the interface going to the TT. So in practice anyone connecting to the wlan/ether1 BRIDGE on a CAP (i.e the CPE devices) should have access to my PPPOE server for authentication. Is this correct?
Kyriacos Hajisavva In the example of a WISP, your AP would build the VPLS tunnel to the TTs. The VPLS tunnel is bridged with the wireless interface where the CPEs are connected. This means that the CPEs are on the same L2 segment with the PPPoE ACs, but the CPEs of course do not build VPLS tunnels. More generally, usually the last L2 device that connects the CPEs will bridge those CPEs into the AC L2 segment using VPLS.
Kyriacos Hajisavva Exactly. The point is simply to build an L2 tunnel (VPLS) over routed (and then MPLS switched) topology. What you do after that (like putting a PPPoE server on one side of the bridge and a CPE on the other) is purely a matter of extending that L2 segment. As mentioned tho, for public access with PPPoE, each client should be its own L2 domain. Either using port isolation on the switches, or no-default-forwarding on the APs.
Tomas Kirnak I got this working fine in my lab setup, pppoe session is up and pushing traffic through it fine. I'd like to be able to deliver full 1500 byte frame through PPPOE session and I can ping the PPPOE-AC from customer CPE with size=1500 do-not-fragment, although the max-mtu and max-mru values are set to 1480 on ppoe server and client. I don't understand how this works!
Kyriacos Hajisavva You probably have mrru set. Make sure mrru is not set on both server and client. /interface pppoe-server server set x mrru=disabled /interface pppoe-client set x mrru=disabled
Hello Thomas! Nice presentation! Good work! Could you tell me if bonding is still a issue? I looked on change log but did not find anything about it. Thank you
+Andre Henrique de Almeida Hi. I have actually not tested since the presentation. Since bonding had issues, we completely stopped using it in our networks. Since we dont use it, I dont know if it has been fixed yet. I will put together a lab, test it, and let you know the results.
Great presentation Tomas!
Great content Tomas, thanks. 👍
a question please,
How to assign /32 public ip ?
one of the goals, you haven't discussed
You say:
* Direct L2 communication between the AC and the client needed to work.
* Since the tunnel is PtP each client can (should) be its own L2 segment.
So I understand that the VPLS tunnel is needed in order to establish a L2 connection between customer and PPPOE AC, for PPOE to work.
So how does this apply in the case of a WISP? Does every CPE device need to be MANUALLY configured with a VPLS tunnel back to the TT?
Isn't this a maintenance nightmare or am I missing something?
OK so after reading through the slides a bit more carefully I realised that the vpls tunnel extends between the tunnel concentrator and the Tower Router.
The vpls tunnel on the router is bridged with the interfaces connecting to the CAPs. On the other side on the AC, the interface running the PPPOE server is bridged to the interface going to the TT.
So in practice anyone connecting to the wlan/ether1 BRIDGE on a CAP (i.e the CPE devices) should have access to my PPPOE server for authentication. Is this correct?
Kyriacos Hajisavva In the example of a WISP, your AP would build the VPLS tunnel to the TTs. The VPLS tunnel is bridged with the wireless interface where the CPEs are connected.
This means that the CPEs are on the same L2 segment with the PPPoE ACs, but the CPEs of course do not build VPLS tunnels.
More generally, usually the last L2 device that connects the CPEs will bridge those CPEs into the AC L2 segment using VPLS.
Kyriacos Hajisavva Exactly. The point is simply to build an L2 tunnel (VPLS) over routed (and then MPLS switched) topology.
What you do after that (like putting a PPPoE server on one side of the bridge and a CPE on the other) is purely a matter of extending that L2 segment.
As mentioned tho, for public access with PPPoE, each client should be its own L2 domain. Either using port isolation on the switches, or no-default-forwarding on the APs.
Tomas Kirnak I got this working fine in my lab setup, pppoe session is up and pushing traffic through it fine. I'd like to be able to deliver full 1500 byte frame through PPPOE session and I can ping the PPPOE-AC from customer CPE with size=1500 do-not-fragment, although the max-mtu and max-mru values are set to 1480 on ppoe server and client.
I don't understand how this works!
Kyriacos Hajisavva You probably have mrru set. Make sure mrru is not set on both server and client.
/interface pppoe-server server set x mrru=disabled
/interface pppoe-client set x mrru=disabled
Hello Thomas! Nice presentation! Good work!
Could you tell me if bonding is still a issue? I looked on change log but did not find anything about it. Thank you
+Andre Henrique de Almeida
Hi. I have actually not tested since the presentation. Since bonding had issues, we completely stopped using it in our networks. Since we dont use it, I dont know if it has been fixed yet.
I will put together a lab, test it, and let you know the results.
HI thomas,
is bug on bounding still exist on 6.37.x ?
i have problem with it though, vpls cannot pass normally on bonding interface
It should work, for a few versions now, bonding interfaces have L2MTU.
Thank very much for share.
Microphones are designed to be placed 1 foot away from your mouth, not 1 inch.