Hello,
The FC in JUNOS is the same as "qos-group" in CSCO IOS - invisible
internal-only field which travels along with packet content across the
switch, but is never inserted in the actual packet. The FC has
significance for choosing output scheduling, RED drop, marking.
Of course there are JUNOS defaults for output scheduling, RED drop, marking.
I suggest You read this Day1 book to get the concepts
http://www.juniper.net/us/en/training/jnbooks/day-one/fundamentals-series/deploying-basic-qos/index.page
As for counters - without ingress queueing, which EX4200 does not
support, there are no classifier counters or MIB objects You can use.
But with fixed port classifier, any packet entering the given port is
statically sorted into fixed FC, so interface counters can be used in
place of classifier counters.
If You want separate counters to monitor classifier work, then use an
input filter:
set firewall family ethernet-switching filter i-want-counters
interface-specific
set firewall family ethernet-switching filter i-want-counters term 1
then forwarding-class be1
set firewall family ethernet-switching filter i-want-counters term 1
then count my-cnt1
set firewall family ethernet-switching filter i-want-counters then accept
- and assign this filter to the ingress interface.
HTH
Thanks
Alex
On 25/06/2015 07:25, Victor Sudakov wrote:
Alexander,
There is one thing (two, actually :-) I cannot understand, please bear
with me. Does your "fixed port classifier" change the way frames are
processed in the switch (queue assignment etc) or is this
classification purely a marker?
After you assign a forwarding-class with the first stanza, is there a
show command to verify that the classifier has worked, that something
in fact has happened?
Alexander Arseniev wrote:
That's what my "fixed port classifier" does - any packet entering the
given port is assigned a FC:
class-of-service {
interfaces {
ge-0/0/0 { ### ingress untagged interface for Internet traffic
unit 0 {
forwarding-class be1;
}}
Then this FC is matched on egress port and 802.1p bits are rewritten:
ge-1/0/0 { ### egress tagged interface for Internet traffic
unit 0 {
rewrite-rules {
ieee-802.1 test1; }}}}
On 24/06/2015 07:34, Victor Sudakov wrote:
Yes but there should be a way to say "any packet enering this untagged
port should be processed as if it has such and such CoS value."
Alexander Arseniev wrote:
Not on untagged ports - IEEE 802.1 PCP bits are only present in tagged
frames.
Thanks
Alex
On 23/06/2015 12:47, Victor Sudakov wrote:
Alexander Arseniev wrote:
On 17/06/2015 15:45, Victor Sudakov wrote:
Would you care to give a simple example?
Of course. Please try the below and see if it works for You:
While trying to implement your example, I have come across something
called a classifier:
admin@sw-kedr> show class-of-service classifier type ieee-802.1
Classifier: ieee8021p-default, Code point type: ieee-802.1, Index: 11
Code point Forwarding class Loss priority
000 best-effort low
001 best-effort low
010 best-effort low
admin@sw-kedr> show class-of-service interface ge-0/0/12.0
Logical interface: ge-0/0/12.0, Index: 81
Object Name Type Index
Classifier ieee8021p-untrust untrust 16
Can I possibly define my own ieee-802.1 classifier and apply it on ingress?
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
