Tuesday, June 2, 2015

PART1: VRR Junos for BGP route reflectors

In very big networks, we need a means for sharing the routers iBGP information. This is a challenge when you have  dozens or more of devices in the network .The  BGP confederations concepts helps, but the iBGP router_reflector with iBGP clients is even better in some case and does not require major changes to an existing network like in a case of redesigning & deploying for a bgp confederations.

Juniper has made it simple with a prepackaged VRR ( virtual router reflector machine )


It's probably one of the best ideal yet by Juniper imho

I've used  OpenBGPd on virtual machines to accomplished the same task,  but a  pre-made  image that ready for install is just as great.


Cisco also have  XRv  & CS1000v but these are are actually data forwarding devices.

I'm not going to argue one  over the other, but will suggest that the commercial offerings are great if you have a Network Deptmartment  or CTO that hates or won't accept a  open source solution. The OpenBGD solution is very flexible, advance and best of all... FREE! YMMV

1st let's look at a typical BGP_RR designs. Take this network with  10x BGP device.

All BGP routers would need to be fully mesh for internal bgp connectivity. This would require more than  80+ peers defined for the above topology. iBGP requires all BGP peers within the same AS to be fully meshed for various reasons.

So how can we reduce the configuration efforts? & maintain this full-meshed requirements ?

Easy we can deploy a BGP-Route/Reflector. We could take any one of the routers here and make a router-reflector or installed 2 dedicate routers for just route-reflectors  operations within the iBGP peers.


NOTE:  A dual BGP_RRs with top-level fully meshed and bottom-level RR  connected.

note: It's ideal to deploy 2x for redundant operations in case one BGP_RR is lost, powered down. With a redundant virtual-hosting architect, you can continue to keep  your bgp mesh contact with all peers.

Now let's look at the Juniper VRR. It's a low impact image that ready to go.  I will install this on a  linux-KVM Host.

The image is prepackage as a qcow2 image format. You can set the unit and start the boot process and login in  as the user  "root".

The very 1st thing you should do is to set the root password & then we can look over the interface lists.

Enable ssh services just in case you want to login via ssh & then build a loopback address and test the ssh access and the login for the user "root".

Now we can start the basic cfg setups which we will cover in my PART2 but the steps in general;

   1: we 1st will build the local vNIC that will sit in our DC-design. This interface will be ether-encapsulation and assigned to our local subnet

  2: we will define the BGP configuration

  3: and set the bgp policy 

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
       /  \


  1. Wow.. great post!
    I will wait the second part.. Thanks for share this..

  2. I'm working on that ( part#2) , so stand by for part#2. I will also have a OpenBGPd episode coming up soon. It's free and simple if you don't mind UNIX. You could even get away with using pfSense and the OpenBGPd pkg if you wanted a "can'd image for installation"

    BTW: The Juniper implementation requires JUNOS knowledge which might be limiting or intimidating to some.

  3. Great..I think the second part will be very usefull.. See you

  4. Hi Ken

    great post! just one question: what about the IGP? Does it is not needed anymore? How the VRR learns about the backbone loopbacks devices?


    1. VRR also support ISIS and OSPF so it can participate in the IGP to learn loopbacks of other devices.

    2. VRR also support ISIS and OSPF so it can participate in the IGP to learn loopbacks of other devices.

  5. Hello,

    Good job! But unfortunately Part 2 was never here;)