[j-nsp] COS on J4350 broken?

Mark Radabaugh mark at amplex.net
Mon Dec 27 14:11:43 EST 2010


I am having considerable trouble getting a J4350 running 10.1R3 to set 
layer 2 COS bits in VLAN tagged packets.

This code used to work fine in 8.x code.   It no longer appears to 
work.   We do run this unit in 'packet' rather than flow mode as this 
router also runs BGP (and why oh why did Juniper decide to turn the 
router I purchased into a poor firewall?).

}
class-of-service {
     classifiers {
         dscp SIP-in {
             forwarding-class assured-forwarding {
                 loss-priority low code-points 101110;
             }
         }


     }
     interfaces {
         ge-0/0/2 {
             unit 0 {
                 classifiers {
                     dscp SIP-in;
                 }
             }
         }
         ge-6/0/0 {
             unit 100 {
                 rewrite-rules {
                     ieee-802.1 SIP-out vlan-tag outer;
                 }
             }

         }
     }
     rewrite-rules {
         ieee-802.1 SIP-out {
             forwarding-class assured-forwarding {
                 loss-priority low code-point 100;
             }
         }
     }
}



Untagged traffic coming in ge-0/0/2 with DSCP bits set to 101110 would 
match the classifier SIP-in, goes into the internal assured-forwarding 
queue, and exits the router on Ge0/0/0 unit 100 with COS code point 100 
set.   This tells Motorola Canopy AP's and CPE to put the traffic in the 
high priority queue.

I can tell packets make it into the assured-forwarding queue but when 
they come back out they do not have the COS bits set.  I have tried all 
kinds of variations and the only conclusion I can come to is that there 
is a bug.  No matter what I try I have never captured an output packet 
with the COS value set to anything other than 0.

TAC has been no help to date.   They keep sending me code snippets that 
don't apply and it's been utterly impossible to get them to say "yes - 
we can/can't duplicate this problem in our lab".    Latest is they want 
me to upgrade to 10.4 but they can't give me any assurance that the 
problem will be fixed in that code - or that it's broken in 10.1.

So... anyone:

  a) see any reason why this code won't work?
  b) have a way to test this on a bench?
  c) know if it's fixed in 10.4?
  d) have a way to get TAC to actually test something and create a PR 
when it doesn't work?

21 days later and I'm really unimpressed with Juniper's TAC.

Thanks,


-- 
Mark Radabaugh
Amplex

mark at amplex.net  419.837.5015



More information about the juniper-nsp mailing list