On Mon, 2015-11-02 at 16:29 +0100, Lukas Tribus wrote: > > , so you would have to mark on the physical interface, > > not the subinterface. > > Not so true. Just because you are on a subinterface, doesn't mean > you can't set cos values.
Interesting. I was genuinely unaware of that, since I have never had the need and never tried. I would probably advise against actually doing that since I think some people would find it unintuitive at 3 in the morning. > Yes, the COS field isn't theoretically "visible" if you strip the > dot1q header from the packet on the wire, however that > doesn't mean the information can't propagate through the > stack anyway. > > "qos-groups" are available on a lot of platforms, which is > an internal/local QoS parameter that you can't see on the wire, > yet you still can set it on ingress and match on egress. > Because it propagates through the stack/fabric, just as COS > does. I'm not intimately familiar with QoS groups, but I'm unsure how they would help. Or how it is related. Yes, the QoS group tag is internal and not present on the wire, like "pak_priority". But CoS is not, it actually exists on the wire, though it might also have an internal representation. Being able to set CoS bits anywhere in the processing path (and not via setting something else and using a map, as I suggested) means the platform has to actually preserve the p-bits even if it otherwise discards the Q-tag. It's not a lot of bits of course, so maybe most platforms do so. But for many switch-based platforms, which I must admit is what I primarily work with, CoS only exists on the wire. The Cat3k switches for example (unless I am mistaken and probably not that platform OP uses of course) have no internal representation of CoS and can only set it via maps. That's why I tried to have OP actually reveal the platform. :-) > Of course, certain platforms may be unable to set COS in > this situation, but thats a specific limitation then. It might very well be a ubiquitous feature that only a few platforms happen to not implement. If that is the case then I have misrepresented the problem and apologise for that. I'm not sure how any of this actually helps OP though... -- Peter _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
