See inline answers:
The questions I wasn’t able to answer are:
• Can the ACS work in a heterogeneous environment (i.e. Cisco and Alcatel Switches)?
Yes, as long as those devices support RADIUS and TACACS+ IETF standards. Some devices require the configuration of vendor-specific AV-pairs to work properly, which the ACS in general can do. You'll need to get details from the specific vendor on their requirements to insure it'll work.
• What happens if the server(s) fail?
o Can already authorized users still work?
This is driven by the AAA client, not the ACS. In general, if it isn't reauthenticating the users, then yes, they'll still work
o Can known users still be authorized?
In general, no, not by the ACS, but for some cases such as dot1x, it may be possible to configure fallback to local authentication or define a critical VLAN.
o Are unknown users still blocked?
Without contact to the server, the AAA client has no way of knowing what user is known / not known barring the above items.
• Is the ACS capable of authorizing users through routed networks or VPN tunnels?
Yes, as long as the VPN device is capable of sending Radius or TACACS+ requests to the ACS
• Does a change of the assigned VLAN work without relogin (or even reboot) of the client?
Yes, if using a supplicant that detects the EAP success message and knows to refresh the IP.
• Is there (besides of the reports) some kind of status overview with the ACS?
Yes, this is covered in the documentation for the appropriate ACS solution. Incidentally, the word ACS could mean ACS 4.x, or ACS 5.x, both of which are substantially different.
• Which kinds of Attacks can the ACS (alone) prevent?
ACS authenticates and authorizes users. It isn't in and of itself a device for prevention of the L2 attacks you list.
o Can it prevent MAC Spoofing?
o Can it prevent MAC Flooding?
o Can it prevent ARP Attacks?
o Can it prevent IP Spoofing?
o Can it eliminate rouge DHCP servers?
o Can it prevent STP Attacks
• And the last one: What happens if I plug in an unknown device into an IP-Phone? Is the switchport to which the IP-Phone is connected blocked or only the unknown device?
This depends on how you configure the dot1x parameters on the port. In general, this is often configured in single-host mode with a voice vlan for the phone. The phone passes through the EAPoL traffic the client passes, and in single host mode we rely on CDP bypass for the phone itself to bypass authentication. There are excellent documents for the various dot1x configuration options in our IBNS (identity-Based Network Solutions) section here:
http://www.cisco.com/en/US/customer/products/ps6638/products_ios_protocol_group_home.html
