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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > > 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 > > > > > > > > > > > -- > > Rafał Szarecki JNCIE-M/T, JNCIP-E > > +48602418971 > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp