[j-nsp] Class of Service help on T-series w/8.2R1.7
David Ball
davidtball at gmail.com
Wed Sep 5 16:10:39 EDT 2007
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