On Friday, October 21, 2011 12:00:47 AM Alexandre Snarskii
wrote:
> Well, there are scenarios when load-balancing will not
> happen (for example, if LAG carries point-to-point link
> between routers, and traffic is MPLS-encapsulated), but
> this is expected behaviour (S/D mac's are always the
> s
On Thursday, October 20, 2011 11:16:11 PM Chuck Anderson
wrote:
> It appears to work here on 10.4R6.
10.4R4.5, for us, doing only bridging, no IP.
Maybe it was a bug (a bad one at that). We only had 3hrs in
which to resolve the issue back then, and R4.5 was the only
code available.
JTAC insi
On Thursday, October 20, 2011 11:13:56 PM Pavel Lunin wrote:
> I saw plenty of EXes doing more or less smooth LB both on
> LAGs and ECMP.
On ingress, traffic is equally shared across all member
links, but that's because the remote device (a router) was
doing the actual load sharing, and all the
On Thursday, October 20, 2011 10:13:33 PM Paul Stewart
wrote:
> We have LAG running on EX4200's today ... traffic is
> pretty much perfectly load balanced.
On egress?
Mark.
signature.asc
Description: This is a digitally signed message part.
___
juni
On 20 October 2011 16:02, Phil Mayers wrote:
> On 10/20/2011 08:28 PM, Sebastian Wiesinger wrote:
>>
>> One problem with active/standby is mac aging on the CE switch(es).
>> When the primary PE goes down, the backup PE takes over and the
>> CE-switches learn mac addresses on the link towards the b
A spanning tree TCN would do it as well. It would be nice if configuring
STP at the edge caused the box to TCN when it gives up mastership. I
haven't tried it but I'm pretty sure it doesn't.
2011/10/20 David Ball
> On 20 October 2011 14:00, William Cooper wrote:
> > I might be confused... but
On 10/20/2011 08:28 PM, Sebastian Wiesinger wrote:
One problem with active/standby is mac aging on the CE switch(es).
When the primary PE goes down, the backup PE takes over and the
CE-switches learn mac addresses on the link towards the backup PE.
Now when the primary link comes online again, t
On 20 October 2011 14:00, William Cooper wrote:
> I might be confused... but wouldn't the switches learn the MAC to port
> association dynamically based
> on traffic flows?
In the absence of gratuitous ARP (used, for example, by VRRP), no.
The switch will learn it once, cache it, and that MAC-to
On Thu, Oct 20, 2011 at 3:43 PM, Humair Ali wrote:
> If you need a shorter mac timeout,
>
> you can set the mac aging timer to a lower value than the default 300ms
> timeout
>
> On 20 October 2011 20:28, Sebastian Wiesinger
> wrote:
>
>> * Phil Bedard [2011-10-13 02:01]:
>> > Coming soon to at l
If you need a shorter mac timeout,
you can set the mac aging timer to a lower value than the default 300ms
timeout
On 20 October 2011 20:28, Sebastian Wiesinger wrote:
> * Phil Bedard [2011-10-13 02:01]:
> > Coming soon to at least one platform, but haven't heard anything about
> > Juniper. Th
* Phil Bedard [2011-10-13 02:01]:
> Coming soon to at least one platform, but haven't heard anything about
> Juniper. The active/standby mechanisms work pretty well but active/active
> using something like SPBM or TRILL would be nicer.
One problem with active/standby is mac aging on the CE switc
Thanks Gabe - really appreciate the feedback. I have been trying to avoid the
service management license :) It definitely has a number of cool features
though...
I have to question the cost of the service manager license into a platform that
has 5 years or less left in it although it's really
I would use the service manager. I've run into the same issue and i've
never managed to make it work using the ingress/egress filters.
You can do some really cool things with it, such as adjusting a single
pppoe session on the fly (without having the user disconnect) using
radius initiated cha
Thanks for that... this is quite lengthy below, apologies for it being so long.
When I say "doesn’t work" this is what I have to share below. Juniper is
telling me that I should see the policy attached to the interface itself (which
seems strange to me given that it's on a per subscriber basis
"Paul Stewart" writes:
> We are trying to get a "lite profile" working on ERX platform for PPPOE
> clients. This would restrict their download/upload speeds on a per user
> basis via Radius attributes.
>
>
>
> I have a ticket running at JTAC now for a long time on this - they have now
> come b
On Thu, Oct 20, 2011 at 10:05:58PM +0800, Mark Tinka wrote:
> On Thursday, October 20, 2011 09:18:06 PM Chuck Anderson
> wrote:
>
> > Not true according to these:
>
> Not according to what we actually saw in the field.
>
> We configured LAG's with LACP and our EX4200 couldn't load
> balance an
Hi Guys
Anyone is aware when the LNS feature will be supported on the MX-series ?
--
Humair
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Hey folks.
We are trying to get a "lite profile" working on ERX platform for PPPOE
clients. This would restrict their download/upload speeds on a per user
basis via Radius attributes.
I have a ticket running at JTAC now for a long time on this - they have now
come back and told me I must r
hey,
> I meant that in order to do LB on labels alone (to have enough of
> hash-keys for micro-flows), you need a large enough set of labels in the
> core and more or less uniformly distributed traffic over these labels.
Or you could use additional hash-labels. Let the ingress LER do all the l
On Thu, Oct 20, 2011 at 10:05:58PM +0800, Mark Tinka wrote:
> We configured LAG's with LACP and our EX4200 couldn't load
> balance any of the traffic.
>
> While those links discuss how the box performs load sharing,
> it isn't actually configurable at all, nor does it work. The
> issue also aff
While those links discuss how the box performs load sharing,
it isn't actually configurable at all,
This is exactly what I tried to point out when Richard proposed to use
Broadcom Trident+ as an LSR PFE. EX3200 uses, AFAIR, Marvell something,
but I don't believe Trident+ much differs in this.
This is where the number of labels comes into play. If we
talk about LSR for not that huge IPS (having not that
much of core LSPs), I'm afraid, this can require to get
back to the old good conception of FEC per prefix :)
When we were small and using Cisco 7200's as BGP-free core
routers, we wer
We have LAG running on EX4200's today ... traffic is pretty much perfectly
load balanced. Did I perhaps miss part of this conversation? ;)
Paul
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mark Tinka
Sent: Thursda
On Thursday, October 20, 2011 09:18:06 PM Chuck Anderson
wrote:
> Not true according to these:
Not according to what we actually saw in the field.
We configured LAG's with LACP and our EX4200 couldn't load
balance any of the traffic.
While those links discuss how the box performs load sharing
On Thu, Oct 20, 2011 at 02:57:04PM +0800, Mark Tinka wrote:
> On Thursday, October 20, 2011 11:52:32 AM Chuck Anderson
> wrote:
>
> > This is why when given a choice I always like to design
> > L2 networks to not require dynamic protocols where
> > possible. E.g. rely on autonegotiation's Remote
On Thursday, October 20, 2011 04:25:02 PM Pavel Lunin wrote:
> This is where the number of labels comes into play. If we
> talk about LSR for not that huge IPS (having not that
> much of core LSPs), I'm afraid, this can require to get
> back to the old good conception of FEC per prefix :)
When we
On Thu, Oct 20, 2011 at 08:59:32AM +0200, Felix Schueren wrote:
> The biggest problem is with "router alert" style traffic (i.e., most
> broadcasts or all-nodes multicast etc), if that gets looped the EX will
> soon start dropping control protocol traffic, losing BFD/LACP/IS-IS
> adjacencies etc.
> I think decent core routers do this today. We've had good
> luck load sharing MPLS traffic on LDP labels alone on
> various Cisco and Juniper kit, provided the IGP cost is the
> same.
>
This is where the number of labels comes into play. If we talk about LSR for
not that huge IPS (having not tha
Currently I'm running 11.1R1.14 . I will update You as soon as
possible with the results.
Best
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of ext Danny
Vernals
Sent: Wednesday, October 19, 2011 11:42 AM
Cc: jun
Tim,
>
> Anyone encountered anything like this before? Any ways to mitigate?
>
I feel your pain. The EXes have a very, very, very weak link between
routing & forwarding engine (hardcoded to a limit of 1,000 pps). I don't
know if they've finally gotten around to it, but as of a year or so ago
t
On Thursday, October 20, 2011 11:52:32 AM Chuck Anderson
wrote:
> This is why when given a choice I always like to design
> L2 networks to not require dynamic protocols where
> possible. E.g. rely on autonegotiation's Remote Fault
> Indication (RFI) or Far End Fault Indication (FEFI)
> rather th
31 matches
Mail list logo
