I have a client looking to implement x86 based route reflectors, and was looking at the ax1000. I'm wondering if anyone has implemented it yet, and what your experience has been?
Any other alternatives would also be appreciated. This customer does standard L3 VPNs, and VPLS services so the software has to support that.
Thanks!
I have spoken about our success in using Cisco's CSR1000v on ESXi on
x86_64 hardware previously on this list.
Yes, the licenses will cost you (both VMware and CSR1000v). KVM is
supported, but I haven't tried it. Suffice it to say, Cisco seem to be
putting most of their energy into ESXi.
Mark.
We have the CSR1000v on KVM with the premium 10mbps license as a RR it is
works perfectly. We did have to play about with the nic drivers and found
that the e1000 seems to be the most stable.
N
Nick Ryce
Network Architect, Fluency Communications Ltd
T: +44 (0)845 874 7000
www.fluency.net.uk <http://www.fluency.net.uk/>
nick@fluency.net.uk
That's great to hear.
We deployed on VMware ESXi with a Premium license for 8GB RAM (which
gives you 500Mbps, not that you need it).
The installation wasn't problematic, just don't live by Cisco's
instructions re: the VM - not very useful :-).
Mark.
I've been testing various vRR solutions recently but haven't taken a long
look at Metaswitch, but I may contact them. On paper, their RR doesn't
support all the AFI/SAFI combinations I require.
There are a few commercial options which have come to market very recently
namely:
ALU VSR
Juniper vMX (vRR version)
Cisco XRv (IOS-XR)
Cisco CSR1000v (IOS-XE)
I can't give exact numbers, but all of them are much faster on pretty
basic newish Xeon hardware than a Cisco ASR9K/Juniper MX with the latest
and greatest RP, while using almost no CPU really. They don't need much
RAM either, 8-16GB is more than enough. XRv and the CSR1000v will run
under ESX fine, and are packaged/documented to deploy that way. vMX/VSR
will but it's not really a supported/documented thing yet, they are
currently supported running under Qemu/KVM.
One issue with VSR/xRV under ESX right now is they have no "display"
drivers/output, so you have to use a virtual serial port which is only
supported with the Enterprise+ version of ESX for some inane reason.
XRv is 32-bit for now, the others are all 64-bit.
CSR1000v has definitey been around the longest. XRv, vMX, and VSR all get
built the same time as the router software now so they get features when
the router software does. You will find more features in them than the
CSR1000v and new service provider features will be in XR before XE. For
instance Cisco has something called Optimized Route Reflection where a vRR
will simulate the IGP network rooted at each client and send the best BGP
paths specific to each client. It means you can have a centralized RR
without running into the issue of it selecting paths based on its position
in the network vs. the client. That's a beta XRv thing but I don't know
if you'll ever see it in XE.
All of them support pretty much every major AFI/SAFI.
Pricing wise the CSR1000v is going to easily be the cheapest option.
Phil
CSR1000v has definitey been around the longest. XRv, vMX, and VSR all get
built the same time as the router software now so they get features when
the router software does.
Junos 14.2R2 just released a few days ago, which officially brings vMX
to the market. That said, pricing is not yet (officially) available, but
one can get code to test from your SE in the interim.
You will find more features in them than the
CSR1000v and new service provider features will be in XR before XE. For
instance Cisco has something called Optimized Route Reflection where a vRR
will simulate the IGP network rooted at each client and send the best BGP
paths specific to each client. It means you can have a centralized RR
without running into the issue of it selecting paths based on its position
in the network vs. the client. That's a beta XRv thing but I don't know
if you'll ever see it in XE.
This was one of the reasons shifting the RR functionality to a VM on x86
hardware compelled us to go this route. Much cheaper and more
sustainable to deploy a box at site to avoid this issue until the tech.
(BGP-ORR) becomes more widely available from the community/vendors. I
believe it's being worked on under:
Cheers,
Mark.
I can¹t speak for this product specifically as we do not use it, but on
metaswitch voice platforms there support is impecable.
Carlos Alcantar
Race Communications / Race Team Member
1325 Howard Ave. #604, Burlingame, CA. 94010
Phone: +1 415 376 3314 / carlos@race.com / http://www.race.com
<http://www.race.com/>