I don't know much about Juniper but I'm about to learn with a new job. If I'm going to take full routes from a couple of upstreams and have a couple of peers will the M10i (768M max) be enough or is the M20 (2048M max) a better choice. Layout here is such that I'd expect to use a single quad gigabit port ethernet blade in each of a pair of M10i/M20 to achieve redundancy.
Is there a pricing resource for this stuff online some where? I do *not* want to hear from any sales people over this comment ...
I don't know much about Juniper but I'm about to learn with a new job. If I'm going to take full routes from a couple of upstreams and have a couple of peers will the M10i (768M max) be enough or is the M20 (2048M max) a better choice.
I think the quick answer based on just that requirement is "an M10i will do fine". I am not aware that Juniper sell a router which will struggle with a default configuration to handle a few views of the full table, but perhaps my rhetorical spectacles are unreasonably rosy right now.
Layout here is such that I'd expect to use a single quad gigabit port ethernet blade in each of a pair of M10i/M20 to achieve redundancy.
Is there a pricing resource for this stuff online some where? I do *not* want to hear from any sales people over this comment ...
I don't know much about Juniper but I'm about to learn with a new job. If I'm going to take full routes from a couple of upstreams and have a couple of peers will the M10i (768M max) be enough or is the M20 (2048M max) a better choice. Layout here is such that I'd expect to use a single quad gigabit port ethernet blade in each of a pair of M10i/M20 to achieve redundancy.
The M10i is perfectly capable of handling the full table and then some. The only question is whether you want to buy more just in case your needs grow.
That said- Last time I spoke to a Juniper rep I was told that their 4 port GigE card for the M7/M10 is oversubscribed 4:1- ie the backplane connection is only gigabit. Check into that if it is important to you. I may have been misled or things may have changed- frankly I didn't look into it much as an equivalent Cisco solution with additional ports came in at 1/4 of the price
Is there a pricing resource for this stuff online some where? I do *not* want to hear from any sales people over this comment ...
The pricing for all of this stuff is so ludicrously flexible it isn't funny. If the company wants you as a client (for marketing reasons or whatever) then suddenly a $50k router becomes a $25k (or less) router. If you point out a competitors router is xyz dollars less you may suddenly find yourself with yet another discount. Get quotes from everyone, compare features, and don't hesitate to push for better pricing from everyone.
choice. Layout here is such that I'd expect to use a single quad gigabit port
ethernet blade in each of a pair of M10i/M20 to achieve redundancy.
he said 'blade' to which I read '4 pics in a FPC'... maybe it's a
terminology thing? Neal?
The M10i doesn't have an FPC blade per se (it's built into the chassis) so in the context of the M10i I assumed "single quad gigabit port ethernet blade" meant a single card- though I could definitely be wrong. My knowledge of the Juniper line is sadly pretty limited.
M7i is a very, very attractive lab/spare box, but this company wants
carrier class - dual engine M10i are the minimum.
An M10i will handle a full routing table just fine. Note that as with
other hardware based forwarding boxes memory on the RE is just one of
several resources you need to verify.
These days I would probably recommend the RE-850, which runs just fine
in both M7i and M10i, and comes standard with 1.5 GByte memory.
I don't know much about Juniper but I'm about to learn with a new job.
If I'm going to take full routes from a couple of upstreams and have a
couple of peers will the M10i (768M max) be enough or is the M20 (2048M
max) a better choice. Layout here is such that I'd expect to use a
single quad gigabit port ethernet blade in each of a pair of M10i/M20 to
achieve redundancy.
As mentioned in another email, the M10i can use the RE-850 which has
1.5 GByte on the RE.
As for the GigE cards: Note that the 4 port GigE PIC for M10i/M7i
(PE-4GE-TYPE1-SFP-IQ2) has 1 GigE (full duplex) backplane capacity,
thus you will *not* be able to run all 4 ports line rate at the same
time. I haven't checked whether the same restriction also applies to
the corresponding M20 card.
Strange. My rep always took pride in the fact that M- and T- series
devices have no overcommit at all.. Maybe things changed, we use no
quad-gig.
Many of Junipers cards for the M7/M10 are oversubscribed- just look at their pdf's on the subject:
I'm very happy about the Juniper devices I manage. They're expensive but
very reliable, and their config interface has lots of unique features.
Juniper's greatest asset over Cisco is the single software image for all their systems. In my latest purchase that didn't justify paying 4 times as much no matter how much I love the software.
If I remember correctly from M5/M10, they uses FEB (built-into-Chassis FPC version), and each FEB (row) has restriction up to 3.6Gbps rate.
So total aggregated bandwidth can not go over this limit.
If you install 4GE (4 of 1-port GigE PIC) in same FEB row, you can use 0.9Gbps in average per PIC with max 1Gbps.
Also, 4GE PIC (single PIC with 4-port GigE) has limitation for up to 1Gbps aggregated bandwidth, too.
M7i/M10i has redundant RE options from M5/M10.
So no differencce except M7i with built-in GigE into chassis.
If you really wants to use GigE per trunk, you may have to use PE-1GE-SFP instead of single quad-port GigE PIC.
For memory, it may be sufficient with 768MB memory for now,
But if I were you, I would go with 1.5GB with new RE.
It's pain in the XXX to add more memory later from production system.
If you are concerned about the budget, you can use after-market memory.
If you read up on juniper.net you'll see that in addition to the one gigabit port PIC there is now a card with four SFP ports but only a gigabit available via the backplane slot. This oversubscription of the slot is good when you have several little switches you wish to drive and don't need the full line rate.
Sorry for the PDF but it seems to be the only way to see the information:
Warren: For me the greatest asset is the stability... the stability and performance... The two greatest assets are stability and performance... and the fact that the commands that you can type actually do something[0]. The *three* greatest assets are stability and performance and the fact that the commands that you can type actually do something... and the ease of the CLI. The *four" greatest ... no ... Amongst their greatest assets are the stability, performance, commands that actually DO something, the CLI...... I'll come in again.
[Warren exits]
Donald: Juniper's greatest asset over Cisco is the single software image for all their systems
[JARRING CHORD]
[Warren bursts in]
Amongst their greatest assets are the stability, performance, commands that actually DO something, the ability to actually count the bits that you send[1]... and pretty colors - Oh damn!
Warren
[0] -- You haven't lived until you have spent 4 hours in the middle of the night trying to figure out why the command that you typed (and that shows up in the config) doesn't work -- only to be told "Oh, that doesn't exist in this train, you need to upgrade to <inset some new version that doesn't include the ability to actually forward packets or something else equally critical>, we just reused the same parser..."
[1] -- If you haven't run into the "oh, we can either forward packets *really* fast, or count them, but not both" answer then you haven't been doing this long enough.
P.S: I neither work for, nor hold any stock of either of the above companies.
[0] -- You haven't lived until you have spent 4 hours in the middle
of the night trying to figure out why the command that you typed (and
that shows up in the config) doesn't work -- only to be told "Oh,
that doesn't exist in this train, you need to upgrade to <inset some
new version that doesn't include the ability to actually forward
packets or something else equally critical>, we just reused the same
parser..."
Oh, only 4 hours? We went thru this for two weeks with TAC for the
exact same reason. In our case: QoS on MLPPP on ATM PVCs. You can
configure that fine on 12.2S, but it's only supported in 12.2SB.
After the recommended upgrade ("this version should be fine with your
hardware/software/features combination"), MLPPP on ChSTM1 stopped
working, yay! Not that they had "sh tech" outputs to double-check
for such known bugs before recommending an upgrade, no... of course
they did. First and foremost TAC job always seems to be "collect
intellig^Wconfigs of our customers" as we all know. :-Z
Now we're another step into upgrade-to-latest-greatest lala-land
(31SB5). No obvious problems yet (except that we can't standardise
on that version as PA-MC-8E1 stopped working [EOL, yay!], and we have
those deployed in other boxes). Let's see wether we will encounter
the mem leak problems other folks in the industry observed with 31SB*.
[hardware is NPE-G1 btw]
Shared Cisco trouble halves the pain.
</rant mode=SCNR>
[1] -- If you haven't run into the "oh, we can either forward packets
*really* fast, or count them, but not both" answer then you haven't
been doing this long enough.
To be fair, JNPR had bugs regarding that too. But they fixed them
quickly.
I'm not sure wether one can nowadays believe the counters on the
dsc discard interface btw...
P.S: I neither work for, nor hold any stock of either of the above
companies.
