[j-nsp] Class of Service help on T-series w/8.2R1.7

[David Ball]

   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

>