Before we get to the radius part, a comment about this:
And since the these links going to both switches are having the same MAC
Be sure to understand how your host handles MAC addresses when failing over from one NIC & Switchport to the other, to avoid MAC-Flapping between the switches. The various host side NIC redundancy features may have different strategies for that (but host side questions are off-topic for this board).
Switch aspect:
The issue might be less with the RADIUS server as such, but more with the switches and their concept of "MAC based authentication session" and what comes with it. For example: once a MAC is learned on a port and authenticated (for example with 802.1X with MACAuthenticationBypass, "MAB" for short), some switches generate a static entry in their CAM table, and they will refuse to dynamically learn that MAC address on any other port, as long as the given authentication session is valid and active.
If you like, please let us know vendor, model and software version of your switches, and some configuration extracts you've been working on for MAC based authentication. We might be able to explore the switch aspect a bit deeper.
RADIUS aspect:
Usually, a 802.1X/MAB enabled switch will just ask (overly simplified) "Hey RADIUS, I have this MAC address here as a username on switchport x/xx. What do you want me to do with it?", upon which the RADIUS server's response might be be some "access-accept", possibly with a few attributes such as a VLAN ID, or it might be a negative answer. This is as far as the RADIUS protocol goes.
However, the RADIUS server's backend (database, application logic, etc.) might also have the notion of a "session" and a policy that might allow or forbid to authenticate the same user or MAC address from a different switch&port while there already is an existing session... and now we're again leaving the scope of this board.