DSCP trust over IPSec GRE

greipsecqos

I have 2 branch offices connecting together via a metro-e and I'm running an ipsec gre tunnel between the 2 sites.

routerA=branch1
routerB=branch2

WAN——-routerA———-|metroe|————routerB—-device

The device is marked as AF41 and its going out via the WAN connection. The service policy only exist on the routerA. What I want to achieve is to dscp trust the link between routerA and routerB.

I am not sure how to do this whether should I set qos-preclassify command under the tunnel interface or under the crypto map it will act as the same way as mls qos trust dscp or what would be the easiest way to do it?

Regards

Best Answer

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.
Related Topic