I am setting up QoS for the first time, to accomodate requirements from a specialized VoIP vendor, and testing on GNS3 with Viral IOSv images, and am running into two issues. A pair of routers on each end communicate over a tunnel (on a semi-private link not the internet) to another pair at the other end. I'm using multiple tunnels (for each router combination) and EIGRP to decide which tunnel to use on the WAN side, and HSRP on the LAN side for router failover. All that is working in simulation.
The second problem I'm having (just to get it out first) is that when I try to attach the service-policy to the tunnel interface I get an error I can't find in goggle anywhere, "Cannot support MATCH METADATA on virtual interface". This seems related to the access-groups which inspect the DSCP class of packets. This is just the beginning of the setup, but it is what gives the error:
class-map match-any Class_DSCP_EF
match access-group name DSCP_EF
match application rtp
class-map match-any Class_DSCP_CS2
match access-group name DSCP_CS2
match access-group name OAM
class-map match-any Class_DSCP_CS3
match access-group name DSCP_CS3
match access-group name DATA_CALL_CONTROL
!
policy-map xxxxx_QoS
class Class_DSCP_EF
set dscp ef
class Class_DSCP_CS3
set dscp cs3
class Class_DSCP_CS2
set dscp cs2
!
ip access-list extended DATA_CALL_CONTROL
permit tcp any any eq 9911 9999 7778 1234 9901 6601 9988 9960 9915
permit tcp any any eq 6665 9989 domain 20102 1723 5060 7777 8888
permit udp any any eq 5060 5063 9912 1234 domain
permit ip any host 225.1.77.78
permit ip any host 225.1.10.12
permit ip any host 239.9.1.1
permit ip any host 225.0.10.20
permit ip any host 225.1.10.11
permit ip any host 225.0.10.10
ip access-list extended DSCP_CS2
permit ip 10.40.0.0 0.0.255.255 10.50.0.0 0.0.255.255 dscp cs2
permit ip 10.50.0.0 0.0.255.255 10.40.0.0 0.0.255.255 dscp cs2
ip access-list extended DSCP_CS3
permit ip 10.40.0.0 0.0.255.255 10.50.0.0 0.0.255.255 dscp cs3
permit ip 10.50.0.0 0.0.255.255 10.40.0.0 0.0.255.255 dscp cs3
ip access-list extended DSCP_EF
permit ip 10.40.0.0 0.0.255.255 10.50.0.0 0.0.255.255 dscp ef
permit ip 10.50.0.0 0.0.255.255 10.40.0.0 0.0.255.255 dscp ef
ip access-list extended OAM
permit tcp any any eq 9912 5150 22 telnet 2000 3389 1433 www 443 1801
permit tcp any any eq 1801 135 2101 2103 2105 3527 1801 www 443
permit udp any any eq 3527 1801 1434
permit ip any host 225.1.10.13
When that is applied to the tunnel it gives the error. I can apply it to the Gig interfaces.
I think I can work around this issue by tagging in ingress and using a different service policy on egress, maybe, but... what does this mean? That tunnel interfaces cannot do matches to DSCP? This is an explicit tunnel not one from flexvpn (etc). Is this a IOSv limitation I might not get in hardware (using 1100 series routers, due in this coming week). Is it a sign that tunnel traffic cannot see DSCP? Which brings me to the real issue...
But the first problem is perhaps more important -- how does QoS on an IPsec tunnel function. Am I correct in trying to tag the unencrypted traffic and trusting that the encapsulation will respect the queuing specified? Ensuring in back pressure from the tunnel that some traffic from each queue will be taken?
Bottom line - what is the proper way to implement QoS when driving the data over a IPsec tunnel in a router (i.e. real tunnel interface; ikev2 if it matters)? The tunnel is encrypted because this is a sensitive installation; the link is actually a private link not internet. That said, I have no idea if it will honor QoS end to end; a state agency is involved and getting accurate info is not easy to come by.
But I'd like to honor the QoS as traffic is encapsulated and output onto the WAN link, and may need to restrict certain classes to certain amounts of bandwidth. Can that work in the tunnel interface? At least on real hardware?
Does encapsulation cause the tunnel packet to inherit the DSCP tag (or associated CoS or whatever is appropriate) from the encapsulated packet? Or is something separate needed to do that? Like a separate service policy (and can those class maps "see" the contained packet?
Sorry, I'm rambling now, hopefully that makes some sense. Thanks in advance, Linwood
