[j-nsp] Class of Service help on T-series w/8.2R1.7
samuel.gay at bt.com
samuel.gay at bt.com
Thu Apr 10 05:20:47 EDT 2008
Hi !
It seems that we have the same kind of problem.
We are seing this issue on M10i/M7i routers and 4 ports GE IQ2, with all JUNOS version. In fact the problem come from the CFEB. For the moment we have seen it with 3 CFEBs. The requirement for reproduction is that the input interface for the PE in output of the MPLS network needs to be an IQ2 interface. For some reason it is not correctly passing the PLP bit to the PFE.
The first time that we have seen the problem (May 2007) we have open a case and JUNIPER done a RMA on the faulty CFEB.
We have met again this issue in February 2008 with 2 CFEBs. A new case has been opened and now JUNIPER is doing researchs on this case. For the moment we have no method to know if a CFEB in production is good or not ... We are following this with JUNIPER engineers team.
Regards,
Samuel
-----Message d'origine-----
De : juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] De la part de Lucio Fraile
Envoyé : mercredi 9 avril 2008 21:44
À : David Ball
Cc : juniper-nsp at puck.nether.net
Objet : Re: [j-nsp] Class of Service help on T-series w/8.2R1.7
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
_______________________________________________
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