Dave Bell wrote:
>
> You can make your config a little more concise too if you wanted.
> Under the interfaces section under class-of-service, you can use the
> * operator to match multiple interfaces.
>
Thanks for the advice. However I would be more happy if I could define
interface ranges, like
Glad to hear you have got it working.
You can make your config a little more concise too if you wanted.
Under the interfaces section under class-of-service, you can use the *
operator to match multiple interfaces.
This will apply to all interfaces on the box, and in effect become the default.
Yo
Thank you Dave and Chuck and all who have replied.
I now have a working configuration which does what I wanted (using
default forwarding classes and default rewrite rules to make it
concise).
class-of-service {
classifiers {
ieee-802.1 pasolink {
forwarding-class best-effo
OK, there are some things I cannot grasp (below).
1. Any interface has a classifier (either a default or a user-defined
one) on ingress, which places a frame into a certain forwarding class.
2. Any interface maps a forwarding class to an egress queue:
Physical interface: ge-0/0/23, Enabled, Phy
On Thu, Jul 30, 2015 at 03:08:05PM +0100, Dave Bell wrote:
> On 30 July 2015 at 14:49, Victor Sudakov wrote:
> > Dave Bell wrote:
> >> >> When frames enter the switch, the switch will need to classify them
> >> >> and place them into a queue. By default everything goes into queue 0,
> >> >> regard
On 30 July 2015 at 14:49, Victor Sudakov wrote:
> Dave Bell wrote:
>> >> When frames enter the switch, the switch will need to classify them
>> >> and place them into a queue. By default everything goes into queue 0,
>> >> regardless of what other switches have done.
>> >
>> > I am afraid you are
Dave Bell wrote:
> >> When frames enter the switch, the switch will need to classify them
> >> and place them into a queue. By default everything goes into queue 0,
> >> regardless of what other switches have done.
> >
> > I am afraid you are mistaken. If a frame enters a switch via a trunk
> > por
On 30 July 2015 at 13:07, Victor Sudakov wrote:
> Dave Bell wrote:
>> When frames enter the switch, the switch will need to classify them
>> and place them into a queue. By default everything goes into queue 0,
>> regardless of what other switches have done.
>
> I am afraid you are mistaken. If a
Dave Bell wrote:
> When frames enter the switch, the switch will need to classify them
> and place them into a queue. By default everything goes into queue 0,
> regardless of what other switches have done.
I am afraid you are mistaken. If a frame enters a switch via a trunk
port and the frame alre
When frames enter the switch, the switch will need to classify them
and place them into a queue. By default everything goes into queue 0,
regardless of what other switches have done.
You have a rewrite rule on your port facing host C that sets the .p
bits on queue 0 to 0.
To fix this, you need to
Dave Bell wrote:
> Apply it to the port on SW3 that is facing SW2.
Why would I apply a classifier on a trunk port? I need to classify
frames entering the network via _access_ ports, and keep this
classification intact on trunk ports.
I'm afraid you are not following me.
--
Victor Sudakov, VAS
Apply it to the port on SW3 that is facing SW2.
On 30 July 2015 at 10:02, Dave Bell wrote:
> Hi Victor,
>
> I see two potential problems here.
>
> 1) SW2 is doing something weird and bleaching the frames before they
> reach SW3. You can apply a firewall filter to the ingress interface to
> match
Dave Bell wrote:
>
> I see two potential problems here.
>
> 1) SW2 is doing something weird and bleaching the frames before they
> reach SW3.
No, it is not.
Any COS value I set on Sw1 arrives intact at HostC _unless_ there is
a rewrite-rule on Sw3 on egress. I thought I made it clear enough.
Hi Victor,
I see two potential problems here.
1) SW2 is doing something weird and bleaching the frames before they
reach SW3. You can apply a firewall filter to the ingress interface to
match your .p bit value and count to check this.
2) As you don't have a classifier on your ingress interface,
Alexander Arseniev wrote:
> > 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
On 25/Jun/15 09:20, Alexander Arseniev wrote:
> 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
Alexander Arseniev wrote:
> 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 dro
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 JU
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 stan
class-of-service {
interface {
ge-0/0/0 {
unit 0 {
forwarding0class expedited-forwarding;
}
}
}
}
where ge-0/0/0 is defined as an untagged port (i.e. family inet with no
vlan-id, family ethernet-switching port mode access) etc...
-
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
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 Suda
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 wo
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 clas
On 17/Jun/15 16:10, Victor Sudakov wrote:
> All right, if I have Internet traffic in VLAN10 and video cameras in
> VLAN20, how do I mark on egress frames belonging to VLAN20 with CoS=1
> and those belonging to VLAN20 with CoS=4 ?
I stay away from such configurations. They make my head boil :-).
Hello,
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:
class-of-service {
forwarding-classes {
queue 0 be;
queue 1 ef;
queue 2 af;
queue 3 nc;
queue 4 be
Alexander Arseniev wrote:
>
>
> On 17/06/2015 15:10, Victor Sudakov wrote:
> > All right, if I have Internet traffic in VLAN10 and video cameras in
> > VLAN20, how do I mark on egress frames belonging to VLAN20 with CoS=1
> > and those belonging to VLAN20 with CoS=4 ?
> If You are doing it on
Hello,
On 17/06/2015 15:10, Victor Sudakov wrote:
All right, if I have Internet traffic in VLAN10 and video cameras in
VLAN20, how do I mark on egress frames belonging to VLAN20 with CoS=1
and those belonging to VLAN20 with CoS=4 ?
If You are doing it on EX-series, ingress interface is untagg
Mark Tinka wrote:
>
>
> > Oh, but I was talking about 802.1p CoS, not about IP and dscp. And
> > the interfaces I need to classify incoming frames on are configured as
> > "family ethernet-switching port-mode access", not as "family inet".
> >
> > The good thing is that when an EX4200 receives a
On Wed, Jun 17, 2015 at 12:41:32PM +0600, Victor Sudakov wrote:
> Oh, but I was talking about 802.1p CoS, not about IP and dscp. And
> the interfaces I need to classify incoming frames on are configured as
> "family ethernet-switching port-mode access", not as "family inet".
>
> The good thing is
On 17/Jun/15 08:41, Victor Sudakov wrote:
> Oh, but I was talking about 802.1p CoS, not about IP and dscp. And
> the interfaces I need to classify incoming frames on are configured as
> "family ethernet-switching port-mode access", not as "family inet".
>
> The good thing is that when an EX4200 r
Oh, but I was talking about 802.1p CoS, not about IP and dscp. And
the interfaces I need to classify incoming frames on are configured as
"family ethernet-switching port-mode access", not as "family inet".
The good thing is that when an EX4200 receives a frame with a
non-default CoS via a trunk po
Hello,
You can do it only on MX with JUNOS 14.2R3 and newer using new JUNOS
feature "policy-map", example config below:
chassis {
network-services enhanced-ip;
}
class-of-service {
policy-map pm1 {
dscp proto-ip code-point 110001;
}
forwarding-classes {
queue 0 be
Colleagues,
I hope I am not asking something unusual? I just want to classify
frames based solely on the ingress port and pass these frames out the
trunk ports keeping the CoS value.
I have read about rewriting rules and classifiers, but would be really
grateful for a simple example.
Victor Sud
Colleagues,
I have the following configuration on some Cisco switches, e.g.
interface GigabitEthernet0/10
switchport access vlan XXX
switchport mode access
mls qos cos 6
mls qos cos override
!
How do I do the same on a Juniper EX4200 switch, namely force a 802.1p
CoS value on all ingress fra
35 matches
Mail list logo
