[j-nsp] Setting CoS bits on ingress frames
Chuck Anderson
cra at WPI.EDU
Thu Jul 30 10:27:59 EDT 2015
On Thu, Jul 30, 2015 at 03:08:05PM +0100, Dave Bell wrote:
> 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.
You can check this with "show class-of-service interface" to find what
classifier is being used for dot1p by default. Here is a switch
without any class-of-service configuration:
EX> show configuration class-of-service
An access port uses "ieee8021p-untrust" by default:
EX> show class-of-service interface ge-0/0/0
Physical interface: ge-0/0/0, Index: 133
Queues supported: 8, Queues in use: 4
Scheduler map: <default>, Index: 2
Congestion-notification: Disabled
Logical interface: ge-0/0/0.0, Index: 71
Object Name Type Index
Classifier ieee8021p-untrust untrust 16
Now look at the classifer named "ieee8021p-untrust"
EX> show class-of-service classifier name ieee8021p-untrust
Classifier: ieee8021p-untrust, Code point type: ieee-802.1, Index: 16
Code point Forwarding class Loss priority
000 best-effort low
001 best-effort low
010 best-effort low
011 best-effort low
100 best-effort low
101 best-effort low
110 best-effort low
111 best-effort low
A trunk port uses "ieee8021p-default" by default:
> show class-of-service interface ae0
Physical interface: ae0, Index: 128
Queues supported: 8, Queues in use: 4
Scheduler map: <default>, Index: 2
Congestion-notification: Disabled
Logical interface: ae0.0, Index: 66
Object Name Type Index
Classifier ieee8021p-default ieee8021p 11
Now look at the classifer named "ieee8021p-default"
EX> show class-of-service classifier name ieee8021p-default
> show class-of-service classifier name ieee8021p-default
Classifier: ieee8021p-default, Code point type: ieee-802.1, Index: 11
Code point Forwarding class Loss priority
000 best-effort low
001 best-effort low
010 best-effort low
011 best-effort low
100 best-effort low
101 best-effort low
110 network-control low
111 network-control low
Now look at forwarding-class "best-effort":
EX> show class-of-service forwarding-class
Forwarding class ID Queue Policing priority SPU priority
best-effort 0 0 normal low
expedited-forwarding 1 5 normal low
assured-forwarding 2 1 normal low
network-control 3 7 normal low
Now look at rewrite-rules for that forwarding class:
EX> show class-of-service rewrite-rule
Rewrite rule: ieee8021p-default, Code point type: ieee-802.1, Index: 34
Forwarding class Loss priority Code point
best-effort low 000
best-effort high 001
expedited-forwarding low 010
expedited-forwarding high 011
assured-forwarding low 100
assured-forwarding high 101
network-control low 110
network-control high 111
> >> 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
More information about the juniper-nsp
mailing list