On Friday, January 27, 2012 04:17:24 PM Mark Tinka wrote:
> Which is why we've never ran of them in our network :-).
Actually, to be perfectly honest, the lack of QPPB support
on the SUP720 and RSP720 was the main reason we dropped
Cisco from our RFP that year (2008).
We could have lived with
On Friday, January 27, 2012 04:08:40 PM Saku Ytti wrote:
> GSR, CRS, ASR1k and ASR9k at least do it.
With lots of banging and bugging, yes, these do have them.
Certain sub-features aren't in there yet, or came very late
after the boxes started shipping - but at least the hardware
works.
> Uns
On Friday, January 27, 2012 04:01:49 PM Saku Ytti wrote:
> The feature is there and has been for >decade in IOS for
> good reason, there are some people who really have
> customers who are not created equal and some needs to
> have higher privilege to live during congestion than
> others.
>
> I f
On (2012-01-27 16:04 +0800), Mark Tinka wrote:
> I was talking about the hardware-based routers. You won't
> find this feature lacking on any (or most) of Cisco's
> software-based routers.
GSR, CRS, ASR1k and ASR9k at least do it. Unsure about ME3600 (maybe
something you can add to your list, a
On Friday, January 27, 2012 03:52:43 PM Saku Ytti wrote:
> Indeed. But it still does not change anything compared to
> customer being in same or different PE. If customer is
> directly attached to your PE, you must decide right
> there how to classify, if that is TOS or L3/L4 values or
> something
On (2012-01-27 15:50 +0800), Mark Tinka wrote:
> The problem with trying to provide any kind of QoS to
> Internet access customers is that if you can do it, it will
> most probably only be possible in the egress direction, as
> QoS scheduling is mostly on the egress portion of router
> interfa
On (2012-01-27 15:36 +0800), Mark Tinka wrote:
> Well, that is assuming the link toward your customer is
> Ethernet, 802.1Q, e.t.c., which may not be the case.
Indeed. But it still does not change anything compared to customer being in
same or different PE. If customer is directly attached to yo
On Friday, January 27, 2012 03:32:03 PM Saku Ytti wrote:
> 1. normal inet (low margin, high dos risk customers)
> 2. priority inet (high margin, low dos risk customers)
The problem with trying to provide any kind of QoS to
Internet access customers is that if you can do it, it will
most probabl
On Friday, January 27, 2012 03:17:03 PM Saku Ytti wrote:
> In JunOS you can classify packets based on incoming
> 802.1p without recolouring anything and then in egress
> match magically on the internally defined class.
Well, that is assuming the link toward your customer is
Ethernet, 802.1Q, e.t
On (2012-01-27 11:02 +0800), Mark Tinka wrote:
> Anything more than 4 is just a variation of the main 3 (be,
> ef, af), and only serves to create more complicated products
> that your sales folk can sell and make a little bit more
> money (sales guys don't care how complicated the network
> b
On (2012-01-27 11:17 +0800), Mark Tinka wrote:
> > Yes, but if you use MPLS, you can do QoS without mangling
> > TOS.
>
> But the problem with that, Saku, is traffic traversing from
> one customer to another on the same router will not be
> wrapped in MPLS.
In JunOS you can classify packets ba
On Friday, January 27, 2012 03:00:44 AM Saku Ytti wrote:
> Yes, but if you use MPLS, you can do QoS without mangling
> TOS.
But the problem with that, Saku, is traffic traversing from
one customer to another on the same router will not be
wrapped in MPLS.
We remark on ingress for Internet traf
On Friday, January 27, 2012 01:32:16 AM Keegan Holley wrote:
> This is good for some, but it's hard to recommend a
> queuing policy to someone without understanding what
> they do with their network. I've made due in the past
> with only 4 queues, especially when juniper pic's only
> had 4.
I've
On 01/26/2012 06:47 PM, Keegan Holley wrote:
That's not exactly accurate. Cisco's kit also has some queuing setup
by default. The details vary by platform. Every cisco router I've
worked with defaults to trusting incoming markings rather then
rewriting them to best effort. So the cisco defau
On (2012-01-26 13:47 -0500), Keegan Holley wrote:
> The 6509 and the other L3 switch platforms (not sure about the nexus)
> come to mind here. Not sure about the CRS and ASR-9k though.
If you do 'mls qos' you magically turn on classification and scheduling in
single command, but that is not def
>
>> That's not exactly accurate. Cisco's kit also has some queuing setup
>> by default. The details vary by platform. Every cisco router I've
>> worked with defaults to trusting incoming markings rather then
>> rewriting them to best effort. So the cisco default is vaguely
>> similar. Also, in
> % sudo tshark -i eth0 "ip[1]==192 and dst host 194.100.7.227" -w prec5.pcap
> Running as user "root" and group "root". This could be dangerous.
> Capturing on eth0
> 55
>
> So 55/74 vantage points passed 0b101 to my server.
(192 obviously is 0b110, not 0b101) I tested 0b101/prec5 also and
propa
On (2012-01-26 12:32 -0500), Keegan Holley wrote:
> I can't see this being a huge risk. Most of your upstreams will
> remark on ingress and not hand you traffic tagged with NC. If you are
I've not actually before tested how typically in INET would NC propagate,
but I just ran ping -Q192 from 7
On (2012-01-26 12:32 -0500), Keegan Holley wrote:
> That's not exactly accurate. Cisco's kit also has some queuing setup
> by default. The details vary by platform. Every cisco router I've
> worked with defaults to trusting incoming markings rather then
> rewriting them to best effort. So the
You said this is a ccc interface. Is the customer connecting to this
device through this interface or is this part of a L2 circuit that
traverses this interface. If it is the latter, they could be running
a protocol over the circuit that is being placed in your NC queue.
Also, how long did it tak
2012/1/26 Saku Ytti :
> On (2012-01-26 10:52 -0500), Keegan Holley wrote:
>
>> stable. I wouldn't use the NC queue for other traffic if you can
>> avoid it and I wouldn't make this traffic best effort without figuring
>
> Yet in INET facing router, jnpr default 95/5 split causes just that, any
> u
Thanks for the replies.
I do not have any CoS configuration on my router.
There is no Spanning-Tree is running between my device and customer device.
I have no idea what is causing an increment in the network-control queue.
Any ideas would be appreciated.
Thanks and regards,
Gokhan
On Thu, Jan 2
On (2012-01-26 10:52 -0500), Keegan Holley wrote:
> stable. I wouldn't use the NC queue for other traffic if you can
> avoid it and I wouldn't make this traffic best effort without figuring
Yet in INET facing router, jnpr default 95/5 split causes just that, any
user in Internet can get special
On (2012-01-26 16:15 +0100), Gökhan Gümüş wrote:
> How can i use %100 BE by changing my config in Juniper?
You need to do two things to avoid 95/5 split.
A) change classifier to make all code points BE
B) change scheduler to give all BW to BE (this is strictly not needed, as
when the 5% NC is no
Well NC (network control) is a completely different queue than EF
(expedited forwarding). This could be normal. Several things such as
routing protocol updates are set to NC by default because it is
network control traffic or part of the network control plane. Such
traffic should be prioritized
Dear Saku,
For note, i have not got any qos configuration on my router.
Kind regards,
Gokhan
On Thu, Jan 26, 2012 at 4:15 PM, Gökhan Gümüş wrote:
> Dear Saku,
>
> Thanks for the reply.
>
> I checked the queues on the interface as seen below;
>
> LON> show class-of-service interface ge-2/0/4
>
Dear Saku,
Thanks for the reply.
I checked the queues on the interface as seen below;
LON> show class-of-service interface ge-2/0/4
Physical interface: ge-2/0/4, Index: 158
Queues supported: 8, Queues in use: 4
Scheduler map: , Index: 2
Logical interface: ge-2/0/4.0, Index: 216
How can i u
On (2012-01-26 12:49 +0100), Gökhan Gümüş wrote:
> I have detected a strange behaviour on one of our ccc-configured gigabit
> ethernet interface.
'show class-of-service interface' should show you what classifier and what
scheduler you are using.
For IP interfaces, per default prec 0b110 and 0b11
Dear all,
I have detected a strange behaviour on one of our ccc-configured gigabit
ethernet interface.
I have a P2P ccc service and at one end strangely network-control queue
counter is increasing as seen below.
There is no other ccc-configured service on the router is getting increment
on the
29 matches
Mail list logo
