[193373] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: BGP Route Reflector - Route Server, Router, etc

daemon@ATHENA.MIT.EDU (Phil Bedard)
Fri Jan 13 08:02:58 2017

X-Original-To: nanog@nanog.org
Date: Fri, 13 Jan 2017 08:02:49 -0500
From: Phil Bedard <bedard.phil@gmail.com>
To: James Bensley <jwbensley@gmail.com>,
 "NANOG =?UTF-8?B?4oCO?=[nanog@nanog.org]=?UTF-8?B?4oCO?=" <nanog@nanog.org>
In-Reply-To: <CAAWx_pV-7ikSECry2UwbDc4eptzVb==PV4q2p4whrxPrNF9RPw@mail.gmail.com>
Errors-To: nanog-bounces@nanog.org

The vRR image and the vMX have always been separate.  The vRR image is what=
 Juniper sells as a solution for control-plane only applications like vRR.  =
It=E2=80=99s also the image they run as part of their Northstar controller to spea=
k BGP-LS to the network.   It=E2=80=99s very lightweight, you can run a bunch of t=
hem in very little memory space, for instance if you want to do a vRR per AF=
I/SAFI, or service.  I=E2=80=99ve tested it against the vMX in applications like v=
RR and the performance is pretty much identical with much less memory/cpu us=
e. =20

Cisco makes a distinction between IOS-XRv which is their simulation/test ve=
rsion of XR like you would find in VIRL/CML and the XRv-9000 which is optimi=
zed for higher throughput.  They sell a vRR-specific version of the XRv-9000=
 that is very reasonably priced.   XRv-9000 is a bit more cpu/memory intensi=
ve in my experience. =20

Nokia also has a vRR version of their SR-OS virtual router.  It has a light=
weight cpu/memory footprint and is very fast.  But really all of the virtual=
 vRR solutions are fast and scale very high, little performance difference b=
etween them.  I would recommend one based on the vendors you are most comfor=
table with and support for the AFI/SAFIs you are interested in.     =20

Phil=20

-----Original Message-----
From: NANOG <nanog-bounces@nanog.org> on behalf of James Bensley <jwbensley=
@gmail.com>
Date: Friday, January 13, 2017 at 06:04
To: "NANOG =E2=80=8E[nanog@nanog.org]=E2=80=8E" <nanog@nanog.org>
Subject: Re: BGP Route Reflector - Route Server, Router, etc

    On 13 January 2017 at 04:02, Hugo Slabbert <hugo@slabnet.com> wrote:
    >
    > On Thu 2017-Jan-12 22:59:21 +0000, James Bensley <jwbensley@gmail.com=
>
    > wrote:
    >
    >> On 12 January 2017 at 20:32, Justin Krejci <JKrejci@usinternet.com> =
wrote:
    >>>
    >>> . I have not found many resources discussing using a non-router box=
 as a
    >>> route reflector (ie a device not necessarily in the forwarding path=
 of the
    >>> through traffic). I am thinking things like OpenBGPd and BIRD could=
 make a
    >>> good route reflector though they are most often discussed in the co=
ntext of
    >>> IXPs (ie eBGP sessions).
    >>
    >>
    >> The CSR1000v (IOS-XE),IOS-XRv and vMX are production ready. People a=
re
    >> deploying these in production and its increasing in popularity.
    >
    >
    > Any thoughts on vRR vs. vMX for this use case?  I see Mark called out=
 vRR as
    > having morphed into vMX, but AFAIK vRR is just vMX minus the forwardi=
ng
    > plane, is targeted as an out-of-path reflector, and coexists with vMX=
 as a
    > different deployment option rather than having been replaced by it.  =
I would
    > assume that vRR should come in a few bucks lower than the vMX as a re=
sult,
    > but I've only previously gotten quotes on vRR not vMX.
    >
    >
    >> Mark Tinka gave a good preso at a recent Nanog:
    >>
    >> https://www.nanog.org/sites/default/files/2_Tinka_21st_Century_iBGP_=
Route_Reflection.pdf
    >>
    >> https://www.youtube.com/watch?v=3DwLEjOj2fyp8&list=3DPLO8DR5ZGla8hcpeEDS=
BNPE5OrZf70iXZg&index=3D21
    >>
    >> Cheers,
    >> James.
    >
    >
    > --
    > Hugo Slabbert       | email, xmpp/jabber: hugo@slabnet.com
    > pgp key: B178313E   | also on Signal
   =20
   =20
    Sorry I don't know about the pricing, but the newer vMX product is now
    split into two VMs, the virtual control plane and virtual forwarding
    plane. I think the vRR product is still like the "older" style vMX
    which was one combined control and forwarding plane image. At a guess,
    perhaps its heavy throughput limited?
   =20
    We have used the "older" style vMX images in the lab (14.something)
    which is the combined all in one VM, it works fine for us for actual
    network traffic testing as well as various BGP tests like router
    reflectors so I see know reason why it wouldn't work as a vRR. I think
    the actual "vRR" product from Juniper is just a more light weight VM,
    perhaps someone can clarify the tech behind it?
   =20
    We don't have any virtual RRs in production yet but we are running
    CSR1000v in lab tests right now which is working fine for us so we'll
    probably push that out to prod at some point in both scenarios (as an
    in path virtual router and out of path virtual route-reflector) but
    that is 12+ months away as we still have lots more testing to do.
   =20
    Cheers,
    James.
   =20



home help back first fref pref prev next nref lref last post