Hi @udo.konstantin,
MTU mismatch in EIGRP is indeed a problem. In this specific scenario, the ACI Border Leaf could send EIGRP UPDATE packets with an MTU size of 9000 and these packets would not be properly received on the ASR1K Router due to its interface allowing only an MTU size of 1500. If the ASR1K does not receive the EIGRP UPDATE packet, it will never reply with any EIGRP ACK causing that eventually, the EIGRP process on the ACI Border Leaf to give up and terminate the EIGRP adjacency by sending an EIGRP packet to indicate to the ASR1K the session is being terminated (and therefore that "is down: Peer Termination received" message on the ASR1K). This process will repeat indefinitely.
This scenario may not be evident in case the EIGRP UPDATE packet is smaller than 1500 bytes which may be the case if there is a small number of routes to advertise. Adding new routes to be advertised by EIGRP will generate small size EIGRP UPDATE packets containing only these new routes. However, if the EIGRP session needs to be initiated from scratch (for instance, after the Router was reloaded) this mis-configuration can cause the EIGRP session to start flapping since the number of routes to be advertised has grown and the EIGRP UPDATE packet to be sent will contain a large number of routes and therefore its size can be larger than 1500 bytes.
The note included in the documented shared by @balaji.bandi applies regardless of SVI, routed sub-interface or routed interface in ACI ... actually it applies for any EIGRP neighborship between any kind of network devices.
From the document:
Note – Ensure your MTU matches! Failure to match your MTU will result in EIGRP neighbor sessions that do not fully form.
Good luck!
