Having slightly lost track of what everybody is using for peering routers
these days, what is the consensus about the best alternative to Juniper M
series routers?
I'm asking as the prices to upgrade to 10Gbit capable Juniper units (ie.
an M120) seem prohibitively high so I'm looking to get a feel for the
alternatives. The other obvious platform would appear to be a Cisco XR
12404 (or similar depending on line card requirements) but is anything
else in common use as a peering platform?
Having slightly lost track of what everybody is using for peering routers
these days, what is the consensus about the best alternative to Juniper M
series routers?
Having slightly lost track of what everybody is using for peering routers
these days, what is the consensus about the best alternative to Juniper M
series routers?
Juniper MX series? Works great for us. Much nicer 10G prices than M120.
I had looked briefly, does anybody here actually use them as peering
routers? I've seen a few implementations using them in the MPLS P and PE
router roles but never as border routers.
If there is some precedent for using them in this role that's good to hear
and I'll take another look, I was loath to move away from Juniper as our
current boxes are been the model of reliability.
I had looked briefly, does anybody here actually use them as peering
routers? I've seen a few implementations using them in the MPLS P and PE
router roles but never as border routers.
We use MX series as peering routers. They work very well.
I had looked briefly, does anybody here actually use them as peering
routers? I've seen a few implementations using them in the MPLS P and
PE router roles but never as border routers.
We've been using the MX-es as border routers for some time now. It's a
role that suits them very well in my opinion, no problems at all so far.
I'll be very surprised if we don't end up using MX-es in our next PoP
as well.
I had looked briefly, does anybody here actually use them as peering routers? I've seen a few implementations using them in the MPLS P and
PE router roles but never as border routers.
We've been using the MX-es as border routers for some time now. It's a
role that suits them very well in my opinion, no problems at all so far.
I'll be very surprised if we don't end up using MX-es in our next PoP
as well.
Best regards,
We're using them as border routers and love them. As long as you don't need sonet, i think it's a great choice.
Caveat: no MAC accounting on LAGs (IEEE speak) / Aggregated Ethernet (Juniper
speak) / Etherchannels (Cisco speak).
Might or might not be important when using bundled links to public
peering fabrics.
Best regards,
Daniel
PS: and of course JUNOS still undeterministically resetting unrelated BGP
sessions for no good reason when modifying BGP configuration - so one is
well-advised to do ANY configuration changes in the area of BGP within a
maint window as it might happen that you configure a peering session and
whoops there goes your IBGP mesh... or all your other peerings, or, ...
</rant>
Well to be fair, the session resetting on config change behavior is
actually quite deterministic (being EASY to determine is not part of the
requirements, technically speaking :P), and most of the resets really do
have perfectly good reasons. I'll certainly go with "really annoying and
often a giant pain in the @#$%^&*" though.
They've definitely been improving it over the years though, so much that
I almost never trigger a session reset on me unintentionally any more.
The things to watch out for are:
a) any time you change the update replication by moving a neighbor
between groups, renaming groups, or significantly changing the export
policy chain.
b) any time you change a major part of the underlying interface
configuration for an eBGP session, such as mtu or vlan tagging config.
c) any time you change something about the bgp session which really does
require a session reset to take effect, such as a new ASN, new endpoint
address, new mbgp family configuration, new md5 password, new tcp mss,
etc.
You can actually safeguard yourself from a lot of the accidental reset
behaviors while implementing other features at the same time by using
commit scripts (i.e. as a side-effect of my scripts which exist for
other reasons, I automatically protect myself against changes to the
policy chain or family configuration which might cause unintended
session flaps), though I'll certainly admit this is well into the
category of "power user" and not appropriate for most people. They are
making some progress though, you can actually turn NSR on and off now
without flapping your sessions, which is certainly an improvement over
the serious logic flaws in earlier versions (where you couldn't turn off
NSR without flapping every session, but you also couldn't commit w/NSR
enabled and the backup RE offline, effectively locking you out of config
changes without a total box flap if you didn't have both RE's running).
It would certainly be a lot more user friendly if they could tell you
what sessions would be reset as part of a "commit check" process though.
They've definitely been improving it over the years though, so much that
I almost never trigger a session reset on me unintentionally any more.
They must have. This was new to me and came as a shock. I don't think I've ever seen my m120 behave any different than my cisco when it comes to flapping BGP. Things have just worked as I expected them to. Not that I go screwing with underlying interface configs or changing a peer from one group to another or changing the asn; at least not on a live session. These things would seem to indicate that the session might be subject to reset.
Perhaps it just behaves for normal users and not power users.
