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 <[EMAIL PROTECTED]> 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): > > [EMAIL PROTECTED]> 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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp