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
Dear all
In the Juniper EX-4500 series switch if we are using a LAG say ae1 and
want to run dot1q peering on it with MX-240 upstreams is it necessary
to create the L2 VLAN also in the Switch e.g
set interfaces ae1 vlan-tagging
set interfaces ae1 description Interconnection-to-bbsw01-ae1
set inter
On Friday, January 27, 2012 03:48:23 AM Pavel Lunin wrote:
> What the VRF-based Internet users will definitely notice
> is (looks like RAS is tired of telling this story) is
> ICMP tunneling and consequent hard to interpret delay
> values. People are very suspicious to the numbers. This
> is almos
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 02:30:35 AM Keegan Holley wrote:
> I agree... I think. MPLS has a better forwarding paradigm
> and the IGP only core of P routers is a plus.
Well, I'm not so sure MPLS has a better forwarding paradigm
per se. If you're talking about raw forwarding performance,
hardwa
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
I think Pavel is speaking of the case where the PLR is more than one hop from
the ingress node. It is very topology dependent but you can end up with
bypasses or detours taking a different path than the IGP especially when its a
few hops from the ingress node. Also ring topologies introduce w
> > Because FRR uses a path from a different entry (PLP) to probably a
> different
>
Ups, I meant PLR, of course.
> > exit (say, next-next-hop). When normal LSP (either SPF or CSPF
> calculated)
> > is a path from head-end to tail-end. Whether this happens often or rare,
> the
> > need to care
On Jan 26, 2012, at 4:01 PM, Keegan Holley wrote:
> 2012/1/26 Pavel Lunin :
>>
>>
>>>
>>> why would FRR LSP's take a route different than what the IGP would
>>> converge to.
>>
>>
>> Because FRR uses a path from a different entry (PLP) to probably a different
>> exit (say, next-next-hop).
Dear All,
Our M10 (7.4R.1.4) restarts every 5 minutes. During the boot process the output
shows the following message:
"savecore: reboot after-panic: Loss of soft watchdog"
The only way to avoid reboots is typing the command "/ sbin / watchdog-off".
Is there someone who has
2012/1/26 Pavel Lunin :
>
>
>>
>> why would FRR LSP's take a route different than what the IGP would
>> converge to.
>
>
> Because FRR uses a path from a different entry (PLP) to probably a different
> exit (say, next-next-hop). When normal LSP (either SPF or CSPF calculated)
> is a path from head-
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
> why would FRR LSP's take a route different than what the IGP would
> converge to.
Because FRR uses a path from a different entry (PLP) to probably a
different exit (say, next-next-hop). When normal LSP (either SPF or CSPF
calculated) is a path from head-end to tail-end. Whether this happens oft
2012/1/26 Pavel Lunin :
>
>> Why not FRR everything? The control plane hit is negligable even if
>> your internet users wouldn't notice, care about, or even understand
>> the improvements.
>
>
> FRRed traffic can follow very fancy routes eating bandwidth on the way. FRR
> for high loads is like sen
> Why not FRR everything? The control plane hit is negligable even if
> your internet users wouldn't notice, care about, or even understand
> the improvements.
>
FRRed traffic can follow very fancy routes eating bandwidth on the way. FRR
for high loads is like sending trucks from a speedway to a n
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
2012/1/26 Mark Tinka :
> On Friday, January 27, 2012 12:36:50 AM Keegan Holley wrote:
>
>> What do you use for signaling? It seems like overkill to
>> keep one kind of traffic from using the MPLS operations
>> if there are already LSP's between the source and the
>> destination and L3/L2vpn traffi
On Friday, January 27, 2012 12:36:50 AM Keegan Holley wrote:
> What do you use for signaling? It seems like overkill to
> keep one kind of traffic from using the MPLS operations
> if there are already LSP's between the source and the
> destination and L3/L2vpn traffic flowing between them.
> You
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
On (2012-01-26 18:24 +0100), Gökhan Gümüş wrote:
> 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.
This is default
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
2012/1/26 Mark Tinka :
> On Sunday, January 22, 2012 08:55:07 AM Derick Winkworth
> wrote:
>
>> http://packetpushers.net/internet-as-a-service-in-an-mpls
>> -cloud/
>
> We also want to avoid putting too much reliance on MPLS for
> basic services like Internet access. We relegate MPLS-based
> servic
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 Thu, Jan 26, 2012 at 6:52 AM, Mark Tinka wrote:
> Keeping it really stupid is what we're after :-).
>
> Mark.
We run Internet in a VRF, but I have to agree with Mark's comments.
Unfortunately, there are lots of Engineers/Vendors/Security
Experts/Auditors who think that "making it really compl
On Wednesday, January 25, 2012 10:25:48 PM Paul Stewart
wrote:
> - the BRAS function seems
> quite "cutting edge" for me at this point to be
> honest.
Our feelings are similar re: BRAS even for the chassis-based
MX-series routers (MX480 in our case).
We're having to run the very latest co
On Saturday, January 21, 2012 12:48:40 AM Pavel Lunin wrote:
> For IP traffic (doesn't matter routed or bridged) bits
> from MACs are never included, for non-IP (MPLS as well)
> they play the main role (this is documented), which can
> bring some surprises if you don't care (see Mark's
> report on
On Sunday, January 22, 2012 08:55:07 AM Derick Winkworth
wrote:
> http://packetpushers.net/internet-as-a-service-in-an-mpls
> -cloud/
We keep Internet routes in the global table on all routers
we operate. Different routers have different capabilities
when it comes to how many routes they can
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
Thanks for quick response, i had a hoped that this could be done in other whey.
I think jseries need extra license for IDP.
On Jan 24, 2012, at 11:35 PM, Alex Arseniev wrote:
> My understanding is that GRE fragmentation should occur if egress interface
> MTU is < GRE pkt size.
> For GRE reasse
43 matches
Mail list logo
