[j-nsp] Class of Service help on T-series w/8.2R1.7
Sean Clarke
sean at clarke-3.demon.nl
Thu Sep 6 12:16:07 EDT 2007
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