So I just came up with a hideous hack that gives the desired result:
firewall {
family inet {
filter DSCP-CLASSIFIER {
term MATCH-EF {
from {
dscp ef;
}
then {
forwarding-class VOICE-FC;
accept;
}
}
term MATCH-ALL {
then {
forwarding-class BE-FC;
accept;
}
}
}
}
}
interfaces {
irb {
unit 100 {
family inet {
filter {
output DSCP-CLASSIFIER;
}
address 192.168.88.3/31;
}
}
}
}
bdale@lab-mx80a> show interfaces queue ge-1/0/4.100
Logical interface ge-1/0/4.100 (Index 334) (SNMP ifIndex 850)
Forwarding classes: 16 supported, 5 in use
Egress queues: 8 supported, 5 in use
Burst size: 0
Queue: 0, Forwarding classes: BE-FC
Queued:
Packets : 176357 0 pps
Bytes : 21939946 0 bps
Transmitted:
Packets : 176357 0 pps
Bytes : 21939946 0 bps
Tail-dropped packets : 0 0 pps
...
Queue: 1, Forwarding classes: VOICE-FC
Queued:
Packets : 69 1 pps
Bytes : 8694 896 bps
Transmitted:
Packets : 69 1 pps
Bytes : 8694 896 bps
Tail-dropped packets : 0 0 pps
...
This works because the traffic that I’m sending is already pre-marked with DSCP; even though it is being classified by an EXP classifier on an ingress MPLS interface and that’s what we should really be using to determine forwarding-class on the egress interface, but obviously because it’s a non-mpls interface, we don’t see the EXP on egress.
It bugs me that the box is clearly capable of scheduling egress traffic from an irb in this manner, but doesn’t support it in the more traditional (and saner) way through the CoS stanza.
If you’ve got any better ideas, I’m all ears!