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
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
Hello,
does anyone here know how *exactly* MC-LAG split-brain detection works
in the event that one of the MC-LAG peers is down?
For example when one of the MC-LAG peers does a software upgrade and
is down the traffic is switched to the other peer. How does JunOS
distinguish this from a
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...
-
Thanks Steven and Saku, that's what I was looking for.
Dan
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
On 23 June 2015 at 17:43, Saku Ytti s...@ytti.fi wrote:
I don't have access to any JNPR box right now, so can't give exact command.
But as you're using QX for scheduling, you'll need the chipID, and
L2/L3 index, and taildrop index, then you can use 'show qx ..' to
fetch the size of the tail,
On (2015-06-24 11:40 +0100), Dan Peachey wrote:
Hey Dan,
I must be missing something, but it seems that regardless of what I set as
a temporal buffer, the byte buffer value assigned doesn't appear to change.
Can you give
CLI config (TCP, shaper and queues)
show cos halp ifl X
show qx N
We are considering upgrading to a Juniper MX104, but another vendor (not
Juniper) pointed out the following limitations about the MX104 in their
comparison. I am wondering how much of it is actually true about the MX104?
And if true, is it really that big of a deal?:
1. No fabric redundancy
Comments inline below.
On Jun 24, 2015, at 9:08 AM, Colton Conor colton.co...@gmail.com wrote:
We are considering upgrading to a Juniper MX104, but another vendor (not
Juniper) pointed out the following limitations about the MX104 in their
comparison. I am wondering how much of it is
Hey Dan,
I must be missing something, but it seems that regardless of what I set
as
a temporal buffer, the byte buffer value assigned doesn't appear to
change.
Can you give
CLI config (TCP, shaper and queues)
show cos halp ifl X
show qx N tail-rule Y 0 0
show qx N q Z queue-length
Hello,
I have no the full knowledge to disccussall of the points above, but the
real point is where you come from ? mx80 ? and why you need an upgrade
to (say) mx104 ?
And for what I know:
1. MX104 like MX80 have no SBC, true. They are integrated router.
So no redundancy on this point.
2.
On (2015-06-24 08:08 -0500), Colton Conor wrote:
Hey,
1. No fabric redundancy due to fabric-less design. There is no switch
fabric on the MX104, but there is on the rest of the MX series. Not sure if
this is a bad or good thing?
I'd say categorically good thing. Less latency, less
On (2015-06-24 16:08 +0100), Dan Peachey wrote:
Hey Dan,
class-of-service {
traffic-control-profiles {
10M {
scheduler-map 10M_COS;
shaping-rate 10m;
guaranteed-rate 10m; # add this
}
QueueStateMax Guaranteed
On 24 June 2015 at 22:29, Dan Peachey d...@illusionnetworks.com wrote:
Hey,
I thought the weights were determined by the %? The weights are then used
to schedule the queues appropriately. Even if the queues are in excess,
they should be weighted correctly?
I tested this when Trio came out,
14 matches
Mail list logo
