Going back through my posts, I realized I had not responded to your latest one here. I apologize for the delay.
If your objective is to avoid STP, which is Layer 2 redundancy, you can implement HSRP for Layer 3 IP redundancy with your two 3550s.
>>"How shall the ports be configured for non-Cisco switches?"
You must make sure that you do not create an Ethernet loop on any VLAN by first making sure that the link between the two 3550s is its own unique VLAN and subnet. That VLAN must be pruned off any VLAN trunks that leave either 3550.
If you have an access switch (Cisco or non-Cisco), and all ports on that switch are going to be in one VLAN, you don't need to configure VLANs on the access switch. Just plug the access switch into a port on one of the 3550s, and assign the port on the 3550 as an access port for a VLAN. Make sure that the VLAN is not assigned to any other access ports on the switch (to facilitate HSRP cutover when VLAN interface goes down), and make sure it is pruned from any VLAN trunk ports on the switch. Create an interface VLAN, assign a unique IP address and subnet to it; also, set up a shared IP address for HSRP on that same subnet. When you're done on the first switch, connect your access switch to the second 3550, following the same guidelines.
Uniqueness of the VLAN existing on one and only one port of the 3550 is crucial. If you have a second access switch configured to use the same VLAN as the first one, you will have redundant Layer 2 paths between your 3550s. You will need to enable STP for that VLAN to avoid the resulting loop. But STP is what we're trying to avoid here! Also, you need to be unique about the VLAN assignment because you are using the 3550's as multiport IP routers here; if you use them as Layer 2 switches, then you run the risk of having HSRP not cutover properly.
If you want to have multiple VLANs on an access switch, you can do so provided all those VLANs are unique to the VLAN trunk port they connect to on each 3550. (These would be the VLAN trunk ports that are having other VLANs pruned off in the preceding paragraphs.) On the non-Cisco switch, create the VLANs, match their 802.1Q tagging numbers with the ones you use on the 3550s, and make sure all VLANs on the access switch are present on the port which connects to each 3550's corresponding VLAN trunk port. On the 3550s, you will configure multiple VLAN interfaces, following the guidelines above.
>>"What does happen if a port of the vlan fails?"
If one physical port of the 3550 fails, it must take down any and all VLANs associated with that port on that switch, so that the interface VLAN(s) will also fail and HSRP can cutover properly. In earlier postings we talked about how multiple ports in the same VLAN on a 3550 would keep a VLAN interface up if one port failed, as long as there was another port on the switch belonging to the same VLAN.
>>"Does the first switch send some information at the second, over the trunk?"
>>"I think so, but how does non-Cisco switch react?"
With regard to HSRP, there are hello packets sent back and forth between the 3550s on each VLAN where HSRP is enabled. Each of the two switches figures out that the other one is there, and they work out who will be active and who will be standby IP address for Layer 3 redundancy. When the one running as standby doesn't hear three hello packets in a row, it assumes the active one has failed and takes over the active role. The HSRP hello packets cross both Cisco and non-Cisco switches transparently.
>>"The Catalyst does know, that the port on the other Catalyst is now active, but how should the non-Cisco switch know?"
The HSRP hello packets cross both Cisco and non-Cisco switches transparently. These access switches need to know nothing about the shared IP address, because they are not operating at Layer 3. The magic of HSRP is that in addition to sharing an IP address, the 3550s also share a MAC address. Both the shared IP address and shared MAC address show up only on the active HSRP switch. So when there is a failure of the active HSRP switch, the standby switch goes active. By going active, the shared MAC address now shows up on another, different, switch port of the access switch, which updates its MAC address tables accordingly. (Just like what happens if you unplug a computer from one switch port, and then plug it into a different switch port on the same switch. The switch adjusts which port it should send the traffic to when it receives frames destined for that MAC address.)
Because the computers have ARP cache entries for the default gateway as the shared IP address, and that IP address is mapped to the shared MAC address, the HSRP cutover requires no changes at the computer. The Layer 2 switches simply update where the MAC address is now showing up; and traffic flows again after cutover is complete. (Elapsed time from when the hello packets stopped being received until the standby goes active: about 10 seconds.)
>>"Know you whether there is an example on the Cisco sites?"
There are numerous references on Cisco's website for HSRP. I believe the key to taking advantage of HSRP while avoiding STP, in your situation, is to think of the Layer 3 switches as multiport IP routers. A Cisco router normally won't let you configure two LAN interfaces to be on the same IP subnet (exception is EtherChannel). When using the Layer 3 switches as IP routers, you have to manually configure things so that this is also the case. It can be a tedious and exacting process; often, the problems that crop up usually are the result of forgetting to prune certain VLANs from the Cisco VLAN trunk ports. But it can be done.
P.S. That all being said, I have had three customers who started down this road; then decided it was too much work to integrate multiple vendors' products. They are all in various stages of phasing out the non-Cisco switches, replacing them with Cisco and/or concentrating the non-Ciscos in one location. I'm not sure what your situation is, but you also may want to move toward a single-vendor (Cisco) solution.
