Red Bike Reflector

Network Functions Virtualization Enables Cost-Effective Route Reflectors

Red Bike ReflectorOne of the concerns I hear from network managers regarding all things software defined networks (SDNs) is the lack of use cases for the new technology.  It seems the technology promises to solve so many problems that it’s hard to understand where to start.  Network Functions Virtualization (NFV) is no different.  Lots of possibilities, but where should one start?

One strong use case for NFV is to use it to deploy route reflectors.  For those that aren’t familiar with route reflectors, configuring border gateway protocol (BGP) in medium- to large-scale WANs can be quite challenging, particularly in networks with a high number of peering sessions.  Typically with global WANs these peering sessions mandate the need for a fully meshed network that needs to be provisioned manually.  Configuring IBGP to handle all the various routes and paths can be quite onerous to configure and then to continually manage.

BGPs way of handling the IBGP configuration challenges is through the use of route reflectors.  Route reflectors receive routing information from a group of routers and then shares that information with each router on an individual basis.  The route reflectors act as peer distribution system for that segment of the network.

The basic premise of route reflection is that network managers can designate any number of routers to be a route reflector.  The BGP protocol allows the re-advertising restrictions to be relaxed, permitting the route reflectors to accept and then pass along IBGP routes to the down stream devices.

A network with only 16 routers would require 15 IBGP peering sessions per router or a total of 120 IBGP sessions.  However, if 4 of the routers are designated to be router reflectors, the configuration can be significantly minimized.  The WAN can be designed where each of the reflectors front-ends a cluster of routers creating natural segments.  Without going into too much technical detail, only the 4 route reflectors need to be fully meshed, reducing the number of peering sessions from 120 to a mere 18 IBGP sessions.  That’s an order of magnitude reduction in management overhead.

While the use of route reflectors can significantly reduce the management overhead on the network, some network managers may shy away from deploying them as it could require new hardware to be deployed.  Or, in a large scale network, route reflectors may also require the organization to have to re-architect the network to organize the routers in logical clusters.  However you slice it, it’s a challenge.

Now consider how NFV can be used.  Instead of having to deploy new routers, a virtual, software based router can be used.  This can be especially useful in existing, large scale networks.  Instead of having to re-architect the network to accommodate route reflection, one could leave the existing routers in place and then deploy virtual router reflectors using NFV.  In fact, it would be easy for network managers to slowly implement route reflectors on an on demand basis since the routers are virtual.

The use of a high performance, high cost hardware based router is overkill for route reflection considering the application operates only in the control plane.  One could argue for large scale networks, the performance requirements for routing packets requires hardware based routers but there’s no need to spend this kind of money on route reflectors.

Any company using BGP in the network today should consider route reflectors.  If they are already in place on dedicated hardware, then redeploy the hardware platforms as edge routers and use NFV to create scalable route reflectors.

Image credit: Richard Eriksson (flickr) / CC-BY