[j-nsp] Setting CoS bits on ingress frames

[Dave Bell]

On 30 July 2015 at 14:49, Victor Sudakov <vas at mpeks.tomsk.su> wrote:
> Dave Bell wrote:
>> >> When frames enter the switch, the switch will need to classify them
>> >> and place them into a queue. By default everything goes into queue 0,
>> >> regardless of what other switches have done.
>> >
>> > I am afraid you are mistaken. If a frame enters a switch via a trunk
>> > port and the frame already has a non-zero COS value, this COS value is
>> > forwarded *intact* out the egress interface.
>> >
>> > I have experimental proof of this. In my lab, Sw1 (Cisco) classifies
>> > frames and their COS value set by Sw1 is visible at HostC.
>>
>> When a frame enters port it is classified and placed into a forwarding
>> class. There are defaults for some traffic types, but for .1p on the
>> EX, everything goes into the forwarding class that is associated with
>> queue 0.
>
> Are you speaking now about access or trunk ports? If tagged frames enter a
> trunk port and already have non-zero COS values, will they all go into
> queue 0 ?
>
> Personally I have no problem with them all going into one queue provided
> they leave the switch with the COS fiels unmolested.

I'm talking about all ports. The type is not relevant (from a JunOS
perspective).


>> On egress, if there is a rewrite rule on the forwarding class on the
>> egress interface, then all traffic gets set regardless if there is
>> already markings on the packet.
>
> And this is not desirable for me. I want frames entering trunk ports
> to leave unmolested while frames entering access ports to have their
> COS set.
>
>>
>> If there is no rewrite rule on the forwarding class, then the marking
>> remains unmolested.
>
> Well then, how do I handle the situation when I need to have some frames
> rewritten on egress and some not?
>
>>
>> The solution to this is to make sure that all your traffic enters the
>> correct forwarding class on ingress. This means when it egresses the
>> switch, it will have the intended markings.
>
> This sounds good. Have you looked at the chart at
> ftp://ftp.sibptus.ru/pub/vas/chart2.pdf
> This means that I need some frames to be rewritten and some not,
> right?
>
>>
>> Have you tried the configuration I have suggested?
>
> No, I have not yet tried to apply a classifier to the ingress trunk. I
> don't like the idea of reclassifying transit frames on ingress. I'd
> prefer some kind of passthru mode the way Cisco works. You just
> configure "mls qos trust cos" on trunk ports and you are done.

The problem you seem to be having is Juniper and Cisco do not work the same.

On Juniper, forwarding classes are king. They define what happens to
your traffic, including what marking it leaves the switch with.

If you want to use rewrite to mark some of the packets entering the
switch and exiting one of your ports then you need to classify
appropriately on ingress on all ports. You place each frame in the
appropriate FC, the markings then get written on egress. This may be
with the same marking that it entered with.

Example.

Frame enters a trunk port with .1P marking of 3.
Classifier examines this, and places it in a forwarding class
associated with queue 3 (in your example ca).
Frame gets switched to egress port where it runs through the rewrite
rule. The rewrite rule for ca states set .1P bit to 3.
Frame leaves egress port with a marking of 3.

Another example.

Frame enters an access port.
Classifier sends all frames on this port to a forwarding class
associated with queue 6 (in your example ic)
Frame gets switched to the egress port where it runs to the rewrite
rule. The rewrite rule states set .1P bit to 6.
Frame leaves egress port with a marking of 6.

What you currently (seem to) have happening.

Frame enters a trunk port with .1P marking of 3.
Default classifier ignores ,1P markings and places frame into a
forwarding class associated with queue 0 (in your example bk).
Frame gets switched to egress port where it runs through the rewrite
rule. The rewrite rule for bk states set .1P bit to 0.
Frame leaves egress port with a marking of 0.

>> Have you looked at
>> port counters for your interfaces to see what is happening to the
>> traffic?
>
> I am mostly looking at tcpdump and WireShark on HostC. What command do
> you suggest to look at the counters?


show interface <interface> detail will show you how many packets are
entering each queue.

Dave