How to use Splynx Service Port ID to differentiate services with same mac-address


#1

Hi All
I am currently testing IPoE to push IPconfig using DHCP to dedicated customers. I have a customer who subscribes for an active and backup service. This has been implemented over mikrotik vlans on an ethernet interface (i.e. ether1).
So basically primary or active internet on vlan-11 gets ip assigned from dhcp-server-11 over a vpls circuit and secondary or backup internet on vlan-12 also gets ip assigned from dhcp-server-12 through local routes. Both dhcp servers use the same radius (i.e. splynx)
The issue is that since both vlans are on the same physical interface (i.e. ether 1) they have the same mac address. I need a way for splynx to differentiate how to assign particular IPs for service on vlan-11 and another for service on vlan-12. Because if splynx assigns IP meant for service on vlan-11 to vlan-12 (i.e. due to same mac-address) routes will not go through.
How can I explore splynx port-id to achieve that?


#2

Maybe virtual interface could be a help?


#3

Hello.
You can create bridge, enable DHCP opt82 on it, then add your interface into bridge.
DHCP should run on bridge. IP address should be changed to bridge.
With this configuration Router will add DHCP option 82 (Relay Agent Information) into RADIUS packets. You can find here how to handle option 82 with Splynx: https://docs.splynx.com/networking/authentication_users/dhcp_option_82

PS: don’t use MAC address in internet service if you use PortID. In current Splynx version (2.2) they conflict.


#4

Thanks Peter for the heads up.

We currently have a routed core network and use mpls vpls circuits to centralize services access (Dedicated Internet, Shared broadband access, hotspot, customer l2 vpn services, voip etc)

Mikrotik has changed considerably its vlans implementation. So basically our access routers/switches have a single bridge (pvid, vlan filtering enabled and rstp etc disabled) on which vlans are added. VPLS interfaces are then also added to this bridge with pvid set same as service vlan.

In this case dhcp-relay interface will then be service vlan interface right?


#5

Ok so we managed to solve the problem.
In short in our setup we did not need dhcp relay (i.e. since there is no routed hop between dhcp clients and dhcp server) - we are using MPLS VPLS/pseudowire.
Now on a typical PE the VPLS interface carrying the dhcp service was already added to the single bridge hosting vlans (refer to mikrotik bridge vlan filtering). So we proceeded to set the bridge ports facing the path to dhcp server (i.e. vpls interface) as trusted and the access ports facing client CPEs (i.e. AP-Bridges and Station-Bridges as untrusted.
We then enabled dhcp option 82 on the bridge (dhcp-snooping=yes add-dhcp-option82=yes).
Referring to Peters reference on how Splynx handle dhcp option 82 we enabled the remote-agent-id on customer services and also turned on debug to see what remote-circuit-id and remote-agent-id was received by splynx radius. An alternative to debug is to see the lease parameter values - agent-circuit-id and agent-remote-id in the mikrotik dhcp-server (i.e. /ip dhcp-server lease print detail). In our case the values were agent-circuit-id=“pe01.someisp.net eth 0/6:187” agent-remote-id=“ether6” , where pe01.someisp.net was the system identity of the closest PE gateway to customer. eth 0/6:187 indicated vlan187 on the single bridge with all vlans with ether6 as a bridge port on which AP-Bridge serving customer is connected on that PE. We noted that with bridge vlan filtering its NOT necessary to create a bridge for every vlan. Infact ether6 had pvid different from vlan187.
Finally we use an ASCII to HEX converter and vice versa to verifiy and convert values.

Since Peter pointed out that MAC and Port ID (agent-circuit-id) parameters in splynx customer service settings are mutually exclusive, the challenge now is how to differentiate dhcp assignments to customers hooked to the same AP-bridge connected to the same PE port. Putting every customer on a different vlan is not scalable. Any ideas?


DHCP option 82 with Radius