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