I am afraid this is a misconception. If you use BCP in PPP connections, it doesn't switch the tunnel over from L3 mode to L2 one. It creates an L2 tunnel in addition to the basic L3 one, which is totally independent from it. So the IP address indicated in secret or profile is assigned to the L3 interface of the L3 tunnel, and the L2 interface of the L2 tunnel is just dynamically added as a port of the bridge indicated in the profile, no IP address is assigned to the L2 tunnel interface or to the bridge.
you might want to check out the entires for active BCP sessions under "/interface l2tp-server" with the monitor command, and you'll see that those remote/local address entries show up there instead of the 0.0.0.0 (unnumbered) setup. the problem with this is, that certain packets (better said: frames) are forwarded along the tunnels, but some aren't. because of this, your client on the remote endpoint, if it starts to do DHCP discovers, will not be able to actually acquire the address. i observed that broadcast communication goes fine, but some unicast (dhcp request) is not handled properly in this case. both examples below are configured for BCP, but the latter one is with an username that has local/remote address set:
corrent one with BCP
[admin@hgw] /interface l2tp-server> monitor 1
status: connected
uptime: 3d21h21m50s
user: cambridge
caller-id: 192.168.1.133
encoding:
mtu: 1500
mru: 1500
local-address: 0.0.0.0
remote-address: 0.0.0.0
the one with 'local-address' set
[admin@hgw] /interface l2tp-server> monitor 2
status: connected
uptime: 23s
user: cmb2
caller-id: 31.46.xx.xx
encoding:
mtu: 1500
mru: 1500
local-address: 1.2.3.4
remote-address: 2.3.4.5
anyway, the golden rule of bridging says that _all_ L3/packet related functions shall be configured on the bridge interface and never to the bridge member interfaces.
with regards to the BCP/L3 discussion:
in case of L3 over L2TP you essentially do L3 over PPP over L2TP, whereas in BCP you transmit ethernet frames with BCP over PPP over L2TP. if you have IP entries (/32 addressing) on the L2TP connection, routeros will parse the packets differently.
i included two screenshots showing the correct header stack
bcp.png
l3.png
and another one which happens to go over a BCP enabled tunnel that has local/remote address negotiated by LCP. as you see, the receiver side (since it has IP addresses configured on the tunnels) will try to parse the BCP header as IP header and the story is over.
l3bcp.png
You do not have the required permissions to view the files attached to this post.