We have some small and medium networks.
There are Radius and Dhcp servers and wired and wireless (Wi-fi) supplicants (clients) .
Some of them are set up to static IP, some of them to dynamic IP (Dhcp).
Also Radius authentication port-mac is set up.

We need an authenticator, that is a Mikrotic switch would send IP(s) and net mask(s) of wired/wireless supplicant plugged to the switch ethernet ports directly or via Mikrotik Wi-Fi access point.
For example:
1. supplicant PC with DHCP address:
1.1. if the supplicant does not yet have IP, the authenticator send to the Radius server 0.0.0.0/0 incorporated to the Radius packet;
1.2. if the supplicant is already assgined IP, the authenticator send to the Radius server assigned IP/mask, for example 192.168.12.50/24 at one attribute or 192.168.12.50 and 255.255.255.0 at two attributes;
2. supplicant PC with statically set address(es) :
2.1. if the supplicant is already set up single IP, the authenticator send to the Radius server this IP/mask, for example 192.168.0.10/24 at one attribute or 192.168.0.10 and 255.255.255.0 at two attributes;
2.2. if the supplicant is already set up multiple IPs, the authenticator send to the Radius server all these IPs/masks, for example 192.168.2.20/24,10.20.0.30/20 and so on (if there are any) at one attribute or 192.168.2.20,10.20.0.30 and 255.255.255.0,255.255.240.0 at two attributes;

At the time managed switches even of L2 are mostly is able to see incoming client (upplicant) IPs which uses at IP-Port-Mac binding feature.

And there are Framed-IP-Address, Freamed-IP-Mask, but as we understand it don' t work for common ethernet clients.

We looked at CRS326-24G-2S.
There is no and necessary info.

I it possible to set up with CRS and/or may ROS developers add it to the OS ?

It doesn't work like that. Unlike PPP, which RADIUS was originally designed to support, IPoE requires two separate processes - one to gain access to the network and another to acquire an IP address. The data for these may be related, for example a MAC address may be used for both authorisation to gain access and to assign a static IP address, or not, for example using EAP-PEAP-MSCHAPv2 for authentication and authorisation then the MAC address to assign a static address.

Have I understood you correctly, additionally that:
1. powered on client sends frame/packet to a switch, but at the stage the switch sees only MAC and doesn' t see IP; then, for example the client authenticaion is passed;
2. client sends frame/packet, and at the stage, the switch sees as MAC as IP and IP-Mac-Port binding is engaded ?
Otherwise, if authentication at stage 1 fails, is the IP-Mac-Port not reached ANYWAY ?

Not quite.

For wired clients without their own supplicant the switch uses the source MAC address of the first packet received after the port state changes down->up to initiate MAC authorisation, if that method is enabled, against a RADIUS server. If successful the authorisation from the RADIUS server indicates to the dot1x server in the switch that the wired client may be connected, and optionally to which VLAN.

For wired clients with their own supplicant, e.g. dot3svc on Windows, the EAPOL protocol is used to exchange messages between the wired client and the dot1x server in the switch. The authentication typically uses certificates or username/password with the dot1x server relaying information from the wired client to the RADIUS server. Again, if successful the authorisation from the RADIUS server indicates to the dot1x server in the switch that the wired client may be connected.

Wireless clients using WPA-Enterprise/WPA2-Enterprise operate similarly to the 'wired clients with their own supplicant' scenario.

At this stage the client is connected to an ethernet network, and the dot1x server in the switch now does nothing until the port state changes up->down. The switch, or similarly AP, may or may not restrict which source MAC addresses are permitted to ingress depending on what functionality the vendor has provided, and how it is configured.

If the client now uses DHCP to obtain an IP address the DHCP server may also be configured to use RADIUS to allocate specific IP address based on MAC address (or DUID).

But when the switch begins to see IP of wired client without its own supplicant and with it ?
And when IP-Mac-Port binding begis to act, before authentication at all or after unsuccessful or successfull authentication or after only successfull authentication ?
And is it two parralel procedure - authentication and IP-Port-Mac binding, acting independently of each other or IPM starts to work aftter authentication or authentication can not work with IPM set up to exact IP-Mac-Port because IPM blocks authentication on the port ?

For us, it needs to restrict IP set up manually by users to avoid IPs conflicts.
Some of our office users time to time is able to carry out their laptops from office and back it again, some of then set up IP manually depending of hotel, their home IP pools.
When they go back to the officw and plug the laptops they forget to set up DHCP assigning address or set up correct IP manually.
Because of it IP conflicting may appear and apears.
To avoid it and there is necessary the request feature.
It' s necessary to reject clients which are plugged to a specified switch/router to the right (accepted) port, with right (accepted) MAC but with wrong IP.
That is client plugged to switch # 5 (for example located in accounting service room) to 8 port with MAC aa:bb:cc:dd:ee:ff will be proved to access the netork ONLY with IP 192.168.0.30 and if person who use it set up manually IP even to 192.168.0.29, the cleint will be rejected and will be accepted if user changes it manually to 192.168.0.30 or set ot up to get from DHCP.

And it is very desirable to handle trinity port-mac-IP centrally on the server, to make a decision on the server and with minimal switch set up
If is to consider ACL, after switch changing because of breaking one, ACL will be need to load again to new switch.
May be you will recommend some other wayto reach it.

802.1X was never designed to achieve that, once the ethernet connection is authorised by MAC or EAP it does not inspect packets looking for IP addresses. You might be able to use ACLs created by RADIUS attributes, however only allowing one IP, such as 192.168.0.30, will prevent anything which uses multicast IP from working correctly.

I suspect the simplest solution is to change the entire office network to use a subnet which is not commonly used elsewhere (e.g. avoid 192.168.0.x, 192.168.1.x, 10.0.0.x). Then if anyone connects a device using one of these it just doesn't work, but does not affect the office network.

> ACLs created by RADIUS attributes
May you provide more details ?
Will attributes

NAS-Filter-Rule = "permit in ip from 192.168.0.30 to any"
NAS-Filter-Rule += "permit out ip from 192.168.0.30 to any"

at Radius packet be understood by Mikrotik CRS326 ?

Or which attributes shold be used ?

Those look like Cisco-style attributes which Mikrotik would not understand.

There is some information in the help pages https://help.mikrotik.com/docs/display/ ... figuration I've not used this myself but it does appear there are limitations - it is only supported on CRS3xx series switches and devices with QCA8337, Atheros8327 or Atheros8316 switch chips, CRS1xx/2xx series switches do not support this functionality.

Also, only the mac-protocol, dst-address, dst-port and protocol conditional parameters are supported, so restricting by src-address does not appear to be possible.

Thanks.
I have огык CRS326, but it is based on Marvell 98DX3236.
So, I will try to write a ticket to Mikrotik support.
As I understand dynamic ACL works also and with static IP also, am I right ?
And as I saw dynamic ACLs are applied per MAC, not per ethernet port, are it ?

If dynamic ACLs were enhanced to support the IP source address they would only work with static IPs as they are created when the ethernet connection is authorised. They cannot change automatically as the result of a device acquiring an address by DHCP.

Both the src-mac-address and ports are automatically set by the dot1x server as they are added to the switch chip.

Today I was able to set up succesfully my Radius server for some looks like dynamic ACL with a switch, but of other brand (not Mikrotik) for testing.
Necessary rules are created after successful authentication aftre Raidus server sent its VSA attributes to the switch.

I created the following rules:
source IP = 192.168.0.30/32 port 8 permit
source IP = 192.168.0.0/24 port 8 deny
source IP = 0.0.0.0/0 port 8 deny

Positive sides:
1. I tested it with multi IPs, for example 192.168.0.30 and 10.0.20.30, access is on, for 192.168.0.40 and 10.0.20.30 access is off.
2. And IP by DHCP is assigned successfully.

Questions:
3. ll these created rules are shown on Web UI and by CLI. It seems like a static rules but created automatically
4. But there still acces to the switch itself. Why ?
5. And I can not understand how is to delete all created rules after for example disconnecting of the client.

And will try to test with CRS326.