On Thu, Jul 30, 2015 at 03:08:05PM +0100, Dave Bell wrote: > On 30 July 2015 at 14:49, Victor Sudakov <v...@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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
