[j-nsp] Class of Service help on T-series w/8.2R1.7

Wed Sep 5 15:28:34 EDT 2007

What you observe is absolutly correct. For incoming packtes L2 header is
strip on ingress PIC, then forwarder to RE in private encapsulation (this is
also Eth, but used internaly, so this is totaly new independent header).

I understand Angel suggestion as way to verify recived traffic - if they are
realy marked by .1p

I have other suggestion.
A) configure classifier to put packye into AF regardelss of .1p values. So:
classifiers {
   ieee-802.1 trial2 {
       forwarding-class af-low-fc {
           loss-priority low code-points [ be-low-bits be-high-bits
af-low-bits af-high-bits
ef-low-bits f-high-bits nc-low-bits nc-high-bits];
       }
   }
}

in effect, traffic should be in AF queue on egress side. This will prove
that classificator works somehow.

B) Then I will add next non BE class
       forwarding-class ef-low-fc {
           loss-priority low code-points [ ef-high-bits ];

And send packets with .1p = 101, chek wher packets are classified, then add
nech .1p alias, then next. The last moved for af-low-fc to ef-low-fc should
be 000.

If you make all this test you find some clue

2007/9/5, David Ball <davidtball at gmail.com>:
>
>    Thanks for your reply, Angel.  I'm using an Acterna 2808 test pad.
> I configured it as you suggested and I do see interesting results.
> Results I'm not sure I'm interpreting properly though.  Aren't I
> looking for the bit setting in an 'In' packet as opposed to the 'Out'
> packet?  The 'Out' packet indicates to me that the Juniper is replying
> to the ping and itself is setting the priority to '0' on the reply.  I
> don't see an indication of what it's receiving from the test set
> though.
>
> 09:52:51.813962  In PFE proto 2 (ipv4): 172.16.1.102 > 172.16.1.101:
> ICMP echo request, id 16707, seq 1516, length 1472
>
> 09:52:51.813978 Out 0:17:cb:64:8e:f9 > 0:80:16:28:32:54, ethertype
> 802.1Q (0x8100), length 1510: vlan 200, p 0, ethertype IPv4,
> 172.16.1.101 > 172.16.1.102: ICMP echo reply, id 16707, seq 1516,
> length 1472
>
> David
>
>
> On 05/09/07, Angel Bardarov <angel.bardarov at btc-net.bg> wrote:
> > What kind of tester are you using? If your tester is capable of doing
> pings
> > I can suggest following - reconfigure one of vlans to be normal
> interface
> > (not part of VPLS instance) and assing IP address to it; configure IP
> > address in your test device from same subnet; try  pinging router's IP
> > address from your testing equipment; you can monitor traffic destined
> for RE
> > (for example ICMP packets):
> >
> > lab at r3> monitor traffic interface ge-0/3/0.11 layer2-headers size 1500
> > verbose output suppressed, use <detail> or <extensive> for full protocol
> > decode
> > Listening on ge-0/3/0.11, capture size 1500 bytes
> >
> > 20:21:31.239070 Out 0:14:f6:28:d4:5d > 1:0:5e:0:0:5, ethertype 802.1Q
> > (0x8100), length 82: vlan 11, p 6, ethertype IPv4, 10.0.4.5 > 224.0.0.5:
> > OSPFv2, Hello, length: 44
> > ^C
> > 1 packets received by filter
> > 0 packets dropped by kernel
> >
> > That way you can see vlan tag, .1p bits, etc. ....
> >
> > Angel Bardarov
> >
> >
> > David Ball wrote:
> >  Still having issues with CoS, specifically my classifier. If I
> explicitly
> > force all traffic on a given logical unit to
> forwarding-class ef-high-fc (at
> > [edit class-of-service interface]
> heirarchy), it works as expected. All
> > traffic on that interface ends
> up in the right forwarding class. However,
> > when using the classifier
> below to (try to) do the same thing, no traffic is
> > reclassified. All
> of it ends up in my be-low-fc queues. Is there a glaring
> > error in the
> config below? I believe I've narrowed it down to the classifier
> > being
> the problem.
> I'm in the process of locating a sniffer to see if it
> > actually sees
> the 802.1p markings that my test sets are sending (sending 5
> > in one
> direction, 2 in the other), in case the Juniper isn't seeing what
> > it
> needs to. Any ideas are appreciated.
>
> classifiers {
> ieee-802.1 trial {
> > forwarding-class be-high-fc {
> loss-priority low code-points [ be-low-bits
> > be-high-bits ];
> }
> forwarding-class af-low-fc {
> loss-priority low
> > code-points [ af-low-bits af-high-bits
> ef-low-bits ];
> }
> forwarding-class
> > ef-low-fc {
> loss-priority low code-points [ ef-high-bits
> > nc-low-bits
> nc-high-bits ];
> }
> }
> }
> code-point-aliases {
> ieee-802.1 {
> > be-low-bits 000;
> be-high-bits 001;
> af-low-bits 010;
> af-high-bits 011;
> > ef-low-bits 100;
> ef-high-bits 101;
> nc-low-bits 110;
> nc-high-bits 111;
> > }
> }
> interfaces {
> ge-7/0/7 {
> unit 100 {
> scheduler-map
> > env-mpls-core-scheduler;
> input-scheduler-map env-mpls-core-scheduler;
> > classifiers {
> ieee-802.1 trial;
> }
> }
> }
> ge-7/2/7 {
> unit 100 {
> > scheduler-map env-mpls-core-scheduler;
> input-scheduler-map
> > env-mpls-core-scheduler;
> classifiers {
> ieee-802.1 trial;
> }
> }
> > }
> }
> _______________________________________________
> juniper-nsp
> > mailing list
> > juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

-- 
Rafał Szarecki JNCIE-M/T, JNCIP-E
+48602418971