Hi Saku,
> Any syslog messages when you attach it? Nope, though I'm quite ignorant as to whether I have the appropriate logging options turned on. > I don't think the device supports 'priority level 3', there is only > default, 2 and 1 . Default being the worst and 1 the best (well in > CLI, in NPU they are reversed to make debugging less boring). > Practically all the utility of priority level has already been used, > by the time egress policy is considered, so they don't much here, you > should set them on ingress. I read that this is very much true for ingress queuing as it applies a priority across the fabric (apparently there's a separate mcast priority too). I believe this card supports four egress queues, which seems to be supported by my earlier failed commit checks! Regardless I would expect *something* to hit the counters, even if half of them are broken, no? > Not related, but I can't help myself, you shouldn't classify and > schedule on egress, you classify on ingress, and schedule/rewrite on > egress. That is 'your match dscp/cos' should be on ingress, with 'set > qos-group N', and on 'egress' you do 'match qos-group N'. Not only > will this separation of concerns make things a lot easier to rationale > and manage, but it's the only way you can do QoS on many other > platforms, so you don't have re-invent policies for different > platforms. Thanks for the tips, I'll have to investigate the use of "qos-group". Thanks Ross _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
