BFD COS Marking on ASR 9000

gogie · ‎03-16-2015

I'm trying to set COS 6 on BFD packets originated by ASR 9000. Below is my config. Although BFD packets have IP PREC of 6, COS is set to 0, as seen on Wireshark capture.

Do I need to do something special to set COS for locally originated packets? Specifically BFD?

Also I came across one Cisco presentation mentioning:

LOP (local originated packets) on 12k/CRS

...

"All LOPs marked with ‘qos-group 0’ – important for uniform/pipe model "

May be my config of qos-group 0 setting COS to 0 is messing it up?

class-map match-any GRP_6
match qos-group 6
match precedence 6
match mpls experimental topmost 6
end-class-map
!

class-map match-any GRP_7
match qos-group 7
match precedence 7
match mpls experimental topmost 7
end-class-map
!

class-map match-any GRP_0
match qos-group 0
end-class-map

policy-map MARK_OUT
class GRP_0
set cos 0
!
class GRP_6
set cos 6
!
class GRP_7
set cos 7
!
class class-default
!
end-policy-map

xthuijs · ‎03-17-2015

That is an inject bug if that is the case.

When the prec is set to a specific value, then the COS should follow that on the inject path.

Injected packets by the control plane are not subject to features (aka INJECT TO WIRE), so a pmap you have there doesn't do anything.

Would recommend to check with latest code if that issue still exists there and if so, I would recommend filing a TAC case for a DDTS so we can fix that up in code.

We recitified this very early on in XR3.9: CSCsr32152

so I am bit surprised that you see this still...

cheers

xander

Florian Frotzler · ‎03-18-2015

Hi,

Do you see any matches for class "GRP_0"? Also I wonder where you set those qos groups that you like to match now on the egress side. If you want to catch locally originated packets, this makes obviously no sense, and also as Xander already mentioned, on ASR9K this is generally not possible as locally originated packets skip the QOS path and are handle automatically by the priority 1 queue (this might be different on 12K/CRS, hence the slide you have found is misleading).

Florian

gogie · ‎03-18-2015

I'm running 5.1.3, and do not really want to upgrade just because of this issue.

I definitely see BFD, BGP and LDP packets locally originated on 9k marked with PREC 6, MPLS EXP 6 but COS 0.

If I match qos-group 0 in outbound policy-map and set COS 6, then I start seeing this BFD, LDP and BGP packets with COS 6 in Wireshark

class-map match-any GRP_6
match qos-group 6 0
match precedence 6
match mpls experimental topmost 6
end-class-map

policy-map MARK_OUT
...
class GRP_6
set cos 6

...

So I assume internally 9k is marking self-originated traffic with qos-group 0. This is not solution for my problem, because any traffic coming in to 9k and not explicitly marked to some qos-group is assumed to be qos-group 0. This way I may end up having excessive unnecessary traffic in COS 6 queue.

The bug mentioned, CSCsr32152, is not public, and I can not view any additional info on it.

So should I assume that

1. Correct behavior for 9k is to set same COS as IPPREC or MPLS EXP for locally originated traffic, if egress interface has dot1q header.

2. This behavior can not be affected by egress policy-map, except matching qos-group 0 (which is mentioned should not be possible, but my Wireshark sees it) (which will catch way too much unwanted traffic)

3. The fact that COS is not the same as IPPREC is abnormal and might be reincarnation of CSCsr32152 already fixed in 3.9.

Florian Frotzler · ‎03-18-2015

OK, now the scenario is more clear to me. I agree with Xander, the COS part need to be looked at with TAC, this might be a software defect. Regarding the QoS matching part, I can only repeat what the TAC told me when I was asking about BGP (but this should also apply to BFD and LDP):

Here is how QoS classification works:
1. Locally punted/Injected BGP packets should skip QoS.
2. Transit BGP packets can be matched by QoS, since they are no different than other TCP data packets

QoS implicitly put all punt/injected BGP (and many other protocols) control packets in port priority 1 queue, so these packets are never dropped even when the port is congested with 100% line-rate data traffic.

So, according to TAC, there is no way on A9K to match locally originated control packets by a QoS policy.

Maan Al Bachari · ‎10-23-2015

But this says otherwise

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/routing/configuration/guide/b_routing_cg53xasr9k/b_routing_cg53xasr9k_chapter_0100.html#ID567

"As configured CoS values in ethernet headers may not be retained in Echo messages, CoS values must be explicitly configured in the appropriate egress QoS service policy. CoS values for BFD packets attached to a traffic class can be set using the set cos command"