I just stumbled across this old one showing up as related, and wanted to answer, for having been in that situation more than once.
No need for trust configuration on cisco routers like ISR G1 (18xx/28xx/38xx), G2 (19xx/29xx/39xx) or ISR 4000 series - and probably older ones, too.
As long as there is no inbound QoS policies that would classifiy and (re)mark the packets, they will leave the ToS byte alone.
Usually, the to-be-encapsulated packet's ToS Byte (including DSCP) is copied out to the encapsulating headers.
Also see https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book/IPSecQoS.pdf
Chapter "ToS Byte preservation" (Page 6-12):
To overcome this predicament, the IPSec protocol standards inherently have provisioned the capability
to preserve the ToS byte information of the original IP header by copying it to the IP headers added by
the tunneling and encryption process.
QoS Preclassification is also explained right there. In a nutshell: with QoS preclassify, every to-be-encrypted data packet gets a companion data structure in router memory that holds information from the original packet. Egress QoS policies then queue/schedule the encrypted packet properly, based on the data from the companion data instead of the encapsulated/encrypted (and therefore inaccessible) original packet.
If I understand your case correctly, default-active ToS byte preservation and an egress policy on the tunnel interface should work pretty nicely, making sure that the packets leave the router in the order you intend them to.
However, it may be that the metro ethernet or the WAN service provider might not trust the dscp markings in the outermost IP headers and might nullify them. That may be of minor concern for two reasons:
- the packets left the router after queuing/scheduling, in the order you
wanted them to. If your egress policy includes proper shaping to just-under-the-SP's thresholds, the SP's devices won't need to queue/reschedule.
- the remote tunnel endpoint will start do decapsulate the incoming packet. First step will be to discard the outermost IP header with the possibly nullified ToS byte. No harm done, the next IP Header will still have the original ToS byte with the DSCP field.