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

Lucio Fraile lucio.fraile at ericsson.com
Wed Apr 9 15:43:54 EDT 2008


Hi David, 

I have read your email in the list regarding the Qos with the Iq2 interface.

I have saw the same problem here, with a M10i, Junos 8,2R1.7, in a 4 port Ge IQ2. Basically the problem is that, regardeless the input classifier (EXP, DSCP, 8021.1P) all the traffic goes to the Best Effort ingress Queue but get out correctly in the apropiate egress queue. 

We would like to know how you solve your problem?, have you done the Junos Upgrade? Do you think this is related with the oversuscription in this Pic?

Many Thanks


Lucio Fraile Galilea
Customer Network Support Engineer
_____________________________________________________
Ericsson Chile S.A.  Phone : 562-3725976  Fax : 562-3725421
Mobile : 5698-2391043   ECN: 818-25976  E-mail : lucio.fraile at ericsson.com
Av. Vitacura 2939 Piso 17- Las Condes


-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of David Ball
Sent: Jueves, 06 de Septiembre de 2007 12:44
To: Sean Clarke
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Class of Service help on T-series w/8.2R1.7


  On a T640 running 8.2R1.7 (Type 2 FPCs with IQ2 gig PICs used in my testing).  Will try 8.3R2 in the lab to verify.  Thanks Sean.

David


On 06/09/07, Sean Clarke <sean at clarke-3.demon.nl> wrote:
> Hi David,
>
> On what box ? It was broken on certain boxes .. but it's fixed now in
> 8.3R2 ....
>
> Cheers
> Sean
> --
> not so long ago , you wrote:
>
> >   For those interested, I was able to get pbit recognition working 
> > in an L2VPN, and DSCP working in an L3VPN/VRF. It was, and still is, 
> > VPLS I'm having the problem with for p-bits. Will contact TAC.  
> > Thanks for all the suggestions.
>
> > David
>
>
> > On 05/09/07, David Ball <davidtball at gmail.com> wrote:
> >>   Moved all code-points to af-low-fc forwarding class in 
> >> classifier, and am seeing same bad behaviour.  Suspecting p-bit 
> >> recognition again...will test against another platform to see if 
> >> they're being honoured there.
> >>
> >> classifiers {
> >>     ieee-802.1 trial {
> >>         inactive: 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 be-low-bits be-high-bits ef-high-bits 
> >> nc-low-bits nc-high-bits ];
> >>         }
> >>         inactive: forwarding-class ef-low-fc {
> >>             loss-priority low code-points [ ef-high-bits 
> >> nc-low-bits nc-high-bits ];
> >>         }
> >>     }
> >> }
> >>
> >> And from a 'show interface ge-7/0/7 extensive' :
> >>
> >> Physical interface: ge-7/0/7, Enabled, Physical link is Up <snip>
> >>   Statistics last cleared: 2007-09-05 14:06:29 MDT (00:00:11 ago)
> >>   Traffic statistics:
> >>    Input  bytes  :           1214414460            971483232 bps
> >>    Output bytes  :           1214388754            971538896 bps
> >>    Input  packets:              1776169               177916 pps
> >>    Output packets:              1777420               177565 pps
> >>   Ingress traffic statistics at Packet Forwarding Engine:
> >>    Input  bytes  :           1214414642            971505456 bps
> >>    Input  packets:              1776140               177813 pps
> >>    Drop   bytes  :                    0                    0 bps
> >>    Drop   packets:                    0                    0 pps
> >>   Label-switched interface (LSI) traffic statistics:
> >>    Input  bytes  :                    0                    0 bps
> >>    Input  packets:                    0                    0 pps
> >> <snip>
> >>   Ingress queues: 8 supported, 8 in use
> >>   Queue counters:       Queued packets  Transmitted packets      Dropped packets
> >>     0 be-low-fc                      0              1776140                    0
> >>     1 be-high-fc                     0                    0                    0
> >>     2 af-low-fc                      0                    0                    0
> >>     3 af-high-fc                     0                    0                    0
> >>     4 ef-low-fc                      0                    0                    0
> >>     5 ef-high-fc                     0                    0                    0
> >>     6 nc-low-fc                      0                    0                    0
> >>     7 nc-high-fc                     0                    0                    0
> >>   Egress queues: 8 supported, 8 in use
> >>   Queue counters:       Queued packets  Transmitted packets      Dropped packets
> >>     0 be-low-fc                      0              1777335                    0
> >>     1 be-high-fc                     0                    0                    0
> >>     2 af-low-fc                      0                    0                    0
> >>     3 af-high-fc                     0                    0                    0
> >>     4 ef-low-fc                      0                    0                    0
> >>     5 ef-high-fc                     0                    0                    0
> >>     6 nc-low-fc                      0                    0                    0
> >>     7 nc-high-fc                     0                    0                    0
> >>
> >> David
> >>
> >>
> >>
> >> On 05/09/07, Rafał Szarecki <rszarecki at gmail.com> wrote:
> >> > 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
> >>
> > _______________________________________________
> > 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


More information about the juniper-nsp mailing list