[j-nsp] Class of Service help on T-series w/8.2R1.7
David Ball
davidtball at gmail.com
Thu Sep 6 12:43:34 EDT 2007
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
>
More information about the juniper-nsp
mailing list