* Leigh Porter:
I thought that as soon as you turn MPLS on the flow mode was diabled
and you were back to good old packet mode?
No, packets targeted at the device itself are still processed in flow
mode. According to the documentation, there is no way around that.
It means that all existing
Oh... Would anybody mind telling me why this was a good idea?
--
Leigh
* Leigh Porter:
I thought that as soon as you turn MPLS on the flow mode was diabled
and you were back to good old packet mode?
No, packets targeted at the device itself are still processed in flow
mode. According to
I thought that as soon as you turn MPLS on the flow mode was diabled
and you were back to good old packet mode?
No, packets targeted at the device itself are still processed in flow
mode. According to the documentation, there is no way around that.
It means that all existing TCP sessions
On 20 Jul 2010, at 23:14, Christopher E. Brown wrote:
I know alot of us here have been bitten by this, and the fact that disabling
flow mode and
reverting to packet does not free up any of the ~ 460MB or so being eaten by
fwdd/flowd is
insane.
I am currently having the This is a design
Hate to reply to my own post, but the solution below worked just fine.
-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
boun...@puck.nether.net] On Behalf Of Eric Van Tol
Sent: Wednesday, July 21, 2010 11:34 AM
To: juniper-nsp
Subject: [j-nsp] MX
Hi all,
The issue is not that memory is being pre-allocated to the forwarding / flow
process.
This is expected and required to function.
The issue is that when things switched to flow support the memory usage went
*way* up, and
even when you convert to packet mode it is not reduced.
It
On 21 Jul 2010, at 23:28, Nilesh Khambal wrote:
I am not a J-Series person and don't know much about flowd operation but
does the memory utilization come down when you reboot the router after
disabling the flow mode?
You can't disable it completely, it needs to remain on for packets destined
On 21.07.2010 22:34, Christopher E. Brown wrote:
That is exactly our use, up to a couple hundred megs of IP services on
one, a couple hundred of L3 MPLS on another, and L2-circuit/vpls on a third.
Alaska has many small remote locations. For larger areas, M and MX
platforms are better, and
Cheers for the insight Pavel - sounds like you have been on this one for a
while..
I'm just curious about the cash people actually have to spend on
routers/firewalls these days. All the providers (especially small/mid sized
ones) I have dealt with are trying to remain competitive in a really
On 22.07.2010 14:33, Alexandre Snarskii wrote:
we also bump into the requirements of cheap devices running everything
including L3VPN/VPLS for a few hundred megs. I would suggest to use
SRX240H in packet mode and don't even think about full BGP (they can't)
You can try the same trick as
Once upon a time, Pavel Lunin plu...@senetsy.ru said:
It is also normal since J series became firewalls.
Yeah, but I bought J-series routers, not firewalls.
If you believe you really
need this, why not to stay at old good 9.3 packet-based JUNOS?
And when Juniper stops supporting that
Hi Heath,
I share your emotions, bloody capitalists are a burden to working-class
(joke). But the problem is that there are not so many exceptions. If you
know some, please let me know :)
Another problem is that customers are also not ideal. Many of them very
often want to run something
Example: you run routed metro (or datacenter) ethernet ring, with less
than 12k entries in FIB. One of your customers wants to turn BGP on his
link. There are lots of choices on how to do that:
[...]
But that is one of cases when having full-view in your edge switch RIB
and redistributed to
On Thursday, July 22, 2010 11:25:35 am Benny Sumitro wrote:
Are you doing it on J series or M series? J series
platform will discard any unclassified queue (at least,
that is what i experienced when i still have j series
with junos 8.x installed) while M series will still
forward those
IIRC, it's quite possible to use closest MX-series router to mix
draft-kompella pseudowire from EX-series into VPLS domain (it was
discussed in this list not so long time ago).
Not sure about L3VPN though.
BTW. Kompella? Didn't you mean CCC? EX only support single label MPLS.
I'm trying to test some C to J EoMPLS interoperability, but the only J box that
I have doesn't have any free interfaces on it, so I have nowhere to connect a
test CE and use the CE to ping the far end. Is there any way to stick a subnet
on to an l2circuit directly instead of having to use a
* Leigh Porter:
I thought that as soon as you turn MPLS on the flow mode was diabled
and you were back to good old packet mode?
No, packets targeted at the device itself are still processed in flow
mode. According to the documentation, there is no way around that.
It means that all
IMO Juniper has royally screwed up in the small router/CPE market.
One can hope that they won't perform similar stunts on the M/MX/T
series.
There's absolutely no reason why this would be considered. The fact that you
would make that statement leads me to believe that people might not
Assuming its martini l2ckt you are talking about, you could establish l2ckt
with lt- interfaces. Peer 2 units of lt- with each other. Put one unit in
inet.0 with IP address configured and use other unit with ethernet ccc or
vlan-ccc encap to establish the l2ckt. You can then ping the remote IP
On Thu, Jul 22, 2010 at 01:49:55PM -0400, Jason Lixfeld wrote:
I'm trying to test some C to J EoMPLS interoperability, but the only J
box that I have doesn't have any free interfaces on it, so I have
nowhere to connect a test CE and use the CE to ping the far end. Is
there any way to stick
On 2010-07-22, at 3:03 PM, Jared Mauch wrote:
you can't do the mpls ping to validate? (ping mpls l2vpn ...)
Wouldn't I need an attachment circuit in order for the l2vpn to come up, or are
you saying that a successful ping mpls l2vpn is independent of the state of the
attachment circuit?
On 2010-07-22, at 3:13 PM, Richard A Steenbergen wrote:
On Thu, Jul 22, 2010 at 01:49:55PM -0400, Jason Lixfeld wrote:
I'm trying to test some C to J EoMPLS interoperability, but the only J
box that I have doesn't have any free interfaces on it, so I have
nowhere to connect a test CE and
Chris,
Thanks for your feedback.
However I think it does not address the following points:
1. Memory consumption increased by flow mode even if the router
reverts to packet mode the pre allocation is not released.
2. Upgrade from packet mode version to flow mode version locks you out
of the
IMO Juniper has royally screwed up in the small router/CPE market.
One can hope that they won't perform similar stunts on the M/MX/T
series.
There's absolutely no reason why this would be considered. The fact that you
would make that statement leads me to believe that people might not
Chris,
The discussion is about J series routers, not SRXs.
The J series are marketed as routers not security devices and turning
them to security devices all of a sudden is a decision I still don't
understand.
If you want to open a discussion about SRX we can do that.
I have no experience
Fair enough.
I personally don't have answers to those questions but I'll do what I can to
make sure they get answered in the next day or two.
Thanks, Chris
On 7/22/10 12:19 PM, Amos Rosenboim a...@oasis-tech.net wrote:
Chris,
Thanks for your feedback.
However I think it does not address
Hi Jason -
On Thu, Jul 22, 2010 at 01:49:55PM -0400, Jason Lixfeld wrote:
I'm trying to test some C to J EoMPLS interoperability, but the only J
box that I have doesn't have any free interfaces on it, so I have
nowhere to connect a test CE and use the CE to ping the far end. Is
there any
In that case, as Richard mentioned, you will need a service-pic to create
lt- (logical tunnel) interface.
If you just have one Gig port on J, you could force it in local loopback
mode via CLI. That you bring up the port in up up state and should be able
to bring up the l2ckt as well. Then you can
We have several old m20's with RE2's terminating STM16 wavelengths,
all stable running JUNOS 9.3R2.8. This requires some hardware hacks -
if you want to get your hands dirty you can upgrade the 96MB CF card
on the RE2 to 1GB and the DRAM on SSB from 64MB to 128MB. I believe
the procedures are well
3. The issues raised below (I didn't realize this myself ) about sessions
destined to the router still being processed as flow mode, which can tear
down TCP sessions under certain circumstances.
Does anyone have a proof link for this? I've just checked a J series running
10.0R2 packet-mode
Hi Chris,
The entire SRX product line (branch and high-end) covers the performance
spectrum across M and MX series but were created specifically as
purpose-built security devices and therefore should be implemented as such.
Let me clarify the claim a little bit. The problem is that by the
I absolutely agree with the posts on the J-series boxes. I need lots of
small(ish) boxes that will do a reasonable throughput of MPLS (PWEs, L3VPN etc)
and I was really liking the J-series, but I need some QinQ stuff that they dont
support, so I thought about the SRX would be ideal, but these
Chris I think you've hit the nail on the head here.. In my experience
communication from Juniper is, exactly that. Simplex mode only.
Any opening up of channels and getting the message from customers
and 'partners' back into Juniper is greatly appreciated!
Cheers
On 22 July 2010 20:59, Chris
On Fri, Jul 23, 2010 at 12:27:21AM +0400, Pavel Lunin wrote:
Let me clarify the claim a little bit. The problem is that by the
moment when Juniper decieded to close old good packet branch for J and
rename JUNOS ES to just JUNOS for J series (we all know this was
actually done mainly to
34 matches
Mail list logo
