Alternatives to GRE for multicast over MPLS

Since you are using all ASA-X firewalls, I suggest you go with EIGRP and drop the GRE part - configure IPSEC VPN on ASA.

I had about 80+ branch offices connecting to main site with IPSEC VPN (Although tunnels were on routers not on firewalls) EIGRP played really well. EIGRP is much lighter with computations and has better performance than OSPF. Plus EIGRP is lot easier to troubleshoot and configure.

As for GRE you don't have that option (because you have ASA firewalls not routers) and if you ask me GRE is not the way to go with IPSEC VPN anyway.

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.