On Thursday, July 22, 2010 07:00:45 pm Pavel Lunin wrote:
> The problem with EX in ISP applications is very limited
> MPLS capabilities. So if you want VPLS or L3VPN in some
> remote location, EX will not save you although it has
> way higher forwarding performance.
Yes, this, indeed, was a probl
On Thursday, July 22, 2010 06:50:00 pm Heath Jones wrote:
> Out of curiosity, how many people here are thinking of
> (or have changed to) another vendor??
Because of this, we exclusively use Cisco's 7201 as a route
reflector. It's cheap, has a much smaller OS footprint in
RAM after boot, and ru
On Thursday, July 22, 2010 05:12:08 pm Pavel Lunin wrote:
> But imho running things like full BGP,
Yes.
> tons of IFLs with
> queues,
Skip that.
> thousands of IGP routes,
Yes.
> label forwarding
> states,
Skip that.
> etc
Maybe
> on J series is a little bit strange sort of
> network des
On Thursday, July 22, 2010 04:44:39 pm sth...@nethelp.no
wrote:
> This and many other reasons means that we're not even
> considering Juniper for the CPE role. We have some J
> series routers in the lab, and they are staying at the
> last non flow based version of JunOS.
>
> IMO Juniper has roya
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 t
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 Wh
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
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 mo
> 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-mod
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
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 ca
I understand. I was specifically addressing the high-level comment/concern
that Juniper might do the same (ie implement flow mode) on M/MX/T series.
SRX serves this purpose. That's all.
My concern is that not everyone seems to understand the high-level decisions
behind architecture, product and fe
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
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" wrote:
> Chris,
>
> Thanks for your feedback.
> However I think it does not address the following
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 w
> 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 u
> > 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 migh
On Thu, Jul 22, 2010 at 11:49:46AM -0700, Chris Whyte wrote:
> > 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
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
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
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?
> y
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 st
you can't do the mpls ping to validate? (ping mpls l2vpn ...)
you could also hook two ports on the same J box together and put the IP on one
and EoMPLS on the other...
(Cisco:
Router#ping mpls pseudowire 10.0.0.1 115
Sending 5, 100-byte MPLS Echos to 10.0.0.1,
timeout is 2 seconds, send
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 from
> 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
und
> * 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
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 phy
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.
__
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 t
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 cust
On Thu, Jul 22, 2010 at 03:00:45PM +0400, Pavel Lunin wrote:
>
> 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 ev
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 the
Once upon a time, Pavel Lunin 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 version (or when ther
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 w
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
challe
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 can
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 destin
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 is
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] M
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 de
> > 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 s
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
* 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
43 matches
Mail list logo
