QOS / multiple IKEv2 Tunneling / behaviour at physical interface?

[_|brt.drml|_]

Hi there.

In my setup I have a central infrastructure (HUB) and multiple spokes that are connected to it. That infrastructure offers multiple services to my clients (MPLS).

All are working with VLANs and Tunnel.

It all works great, but I want to better understand the behavior of my QoS settings and the tunnels.

Therefore, during Corona crisis, I had the time to create at home a LAB. This Lab is made of two physical 2911 routers that have the same basic configuration. The only difference: I nested a tunnel in a tunnel.

The latter has let me observe if IpSec packets are 'tagged' with the correct ToS. And they weren't. ... That thought me that one of my clients who is using the underlayer did not apply QoS.

I created the 'basic' QoS configuration for Audio, Video and Routing. In the tunnel I observed that the tagging works.

My Question (:-))

My underlayer already has a QoS policy that performs what it should do. We even calculated minimum voice and video requirements for the customers on that network. The tunnels from above run through it. Will that QoS policy also recognize and handle the 'ipsec-QoS' traffic. e.g.: if cs0/IpsecToS is recognized it will get almost no bandwidth.

If so: then this means that all packets coming from those customers that where not tagged correctly at ingress... they where actually experiencing bad voice quality...

I understand so far that the hierarchy of the QoS has impact on all 'tunnels'.

I hope you understood this.

Thank you in advance.

Sincerely

Bart

[Georg Pauwen]

Hello,

--> I nested a tunnel in a tunnel

Do you mean QinQ ? Can you post the configurations of your routers ?

[Cristian Matei]

Hi,

     Everything goes down to the initial original packet being marked properly, somewhere down the line, before the re-encapsulation takes s place. In the end, when a Cisco router takes an IP packet and puts it inside an IPsec tunnel, in case of tunnel mode where a new IP header is added, it copies the ToS value from the inner/protected/original IP header to the new IPsec IP header; the same goes with MPLS, where when the PE takes an IP packet and puts it inside the MPLS/LSP tunnel, it copies to ToS value from the IP header down to the MPLS label Exp bits. So, as we speak about Diff Services, everything is a matter of packets being marked properly at some point (the sooner, the better, closer to the originator) and QoS policies being synchronised and persistent where implemented.

Regards,

Cristian Matei.

[_|brt.drml|_]

Glad to read this, that proves what I already noticed and had tested so far.

So this means that, in the end when everything is properly marked, that the whole bunch is taken together and shaped to the policy applied according to the physical interface.

Meaning that, my original voice and video calculations for bandwidth reservations are compromised.

The latter will only happen when a 'tunnel' packet carries a EF packet ...



Correct?