UDLD is used to detect if a link is only available in one direction,
for example half the fibre is disconnected. UDLD performs this check
faster than STP will bring the port in to a fowarding state. That
means if you have UDLD and STP enabled then UDLD will prevent STP from
bringing a port in to a state where it will forward traffic to
nowhere.
A unidirectional link occurs when traffic is transmitted between
neighbors in one direction only. Unidirectional Link Detection is a
Layer 2 protocol. UDLD performs tasks that Layer 1 mechanisms, such
as auto negotiation, cannot perform. When UDLD and auto-negotiation
are enabled, both Layer 1 and Layer 2 detections work together to
prevent physical and logical unidirectional connections and the
malfunctioning of other protocols. Unidirectional links can cause
spanning-tree topology loops. UDLD enables devices to detect when a
unidirectional link exists and also to shut down the affected
interface. UDLD is useful on a fiber ports to prevent network issues
resulting in miswiring at the patch panel causing the link to be in
up/up status but the BPDUs are lost.
With UDLD enabled, the switch periodically sends UDLD protocol packets
to its neighbor and expects the packets to be echoed back before a
predetermined timer expires. If the timer expires, the switch
determines the link to be unidirectional and shuts down the port. If
messages are not received within the timeout interval (45 seconds),
the port is disabled. The messages are sent out every default
interval, which is 15 seconds.
The 45 seconds it takes to detect a unidirectional link and errdisable
the port is less than the 50 seconds it would take for STP to
transition the port to a Forwarding state, which is based on 20
seconds for Max Age + 30 seconds for Listening and Learning. This
prevents a loop that would otherwise be caused if STP transitioned the
port into the Forwarding state because of a lack of received BPDUs.
So in summary, yes they can be run together and on fibre links they should be run together.
This post is older in age so I'm not sure if you are still experiencing this problem. I would like to see the documentation you are referring too regarding the portfast trunk command. The portfast trunk configuration should be applied to hosts that you are trunking with, for example an ESX host or a Load Balancer. For switch to switch, this configuration should not be there.
There is a lot of information I would need to see to better understand the topology and what spanning-tree mode you are running in (PVST+, RPVST+ or MST). I suspect from what I've read you are running PVST+. I would like to first start with the output of show spanning-tree vlan x detail and a snippet of this TCN you are seeing. I would also like to see show run | i spanning.
I suspect you may have a port(s) that is flapping and the TCN message should lead us directly to the culprit.
So you have a VoIP phone plugged into a switchport that is configured switchport access vlan and computers/hosts plugged into other switchports with switchport access vlan ? Yeah you know you can set it up for switchport voice vlan. However being setup without the switchport voice vlan, I do not see this being an issue with TCN's.
TCN's are generated when a port transitions from one state to another assuming you are not changing the priority values.
The short answer is that MSTP actually uses a special instance in addition to the user defined ones to handle all MSTP control traffic, called the Internal Spanning Tree instance (IST0).
The IEEE 802.1s implementation does not send BDPUs for every active STP instance separately, nor does it encapsulate VLAN numbers list configuration messages. Instead, a special STP instance number 0 called Internal Spanning Tree (IST aka MSTI0, Multiple Spanning Tree Instance 0) is designated to carry all STP-related information. The BPDUs for IST contain all standard RSTP-style information for the IST itself, as well as carry additional informational fields. Among those fields are configuration name, revision number and a hash value calculated over VLANs to MSTI mapping table contents. Using just this condensed information switches may detect mis-configuration in VLAN mappings by comparing the hash value received from the peer with the local value.
You should definitely check out the rest of that white paper, it's a great resource.
Best Answer
UDLD is generally run on fibre media, it is not required on UTP due to the use of Fast Link Pulse which is already monitoring link status.
This page has a very good explanation of the various L2 protections available. Here is an excerpt specifically regarding UDLD:
So in summary, yes they can be run together and on fibre links they should be run together.