By Steve Harrison & Mitchell Gulledge
Introduction
If you have heard of BGP, then you will likely know it as “the protocol that makes the internet work.” And if you have ever tried to configure it in a multivendor environment, as one of the most frustrating things you can configure in networking. So, the fact that Cisco Meraki, a company known for simplifying powerful technology, is releasing BGP as a feature might have some people scratching their heads.
In this blog post we will explore how even the most esoteric technologies can be “Merakified” into simple, scalable solutions.
What?
“Hold on,” I hear you saying. “Firstly, what exactly is BGP?”
Well, Border Gateway Protocol (to give BGP its full name) is an IP routing protocol, in the same vein as OSPF or EIGRP. Except that it is an exterior gateway protocol as opposed to an interior gateway protocol like OSPF or EIGRP. The exterior bit simply means that it is intended to operate outside of your network gateway, which in most cases means the internet. As opposed to OSPF and EIGRP, which are run inside your network gateway.
Thus all ISPs run BGP, so that your boss’s iPad can be connected to the latest news article/cat video. But that’s not all BGP is used for. In various guises BGP is ultimately responsible for the provision of nearly all of that bandwidth and services that corporations consume, including but not limited to IPVPN, MPLS, VPLS and EtherVPNs.
There is one commonality to all BGP use cases — scale — and that is no different for Meraki. The Meraki BGP implementation allows for stable bilateral integration of Meraki AutoVPN and SD-WAN-enabled organisations into broader MPLS and hybrid Cisco SD-WAN deployments.
How?
Anyone familiar with BGP knows that there are a plethora of ways to influence the routes it decides to use and propagate, anything from AS Path to Multi-Exit Discriminator (MED) to local preference. Some variables are global, some are locally significant, and some are vendor-specific, all of which means that the Meraki implementation has to distill all of those elements to their most fundamental.
BGP at its heart is a distance vector protocol, except that instead of tracking an IP path through many routes, it tracks a path through collections of routers under a single organization’s administrative control. Such organizations are referred to as Autonomous Systems and they all have a number, an ASN.
When a BGP router propagates a network (also known as a prefix) to a neighboring router (also known as a BGP peer), it appends its own ASN to the AS Path for the prefix. The BGP peer then decides how to route to that prefix by choosing the shortest AS Path for the prefix (if it has more than one path to the prefix) or the only path if it has only one.
The Meraki implementation does exactly that, just bilaterally. When sharing any prefixes it simply adds its own ASN to the AS Path.
Meaning that the router 1.2.3.4 in the above example will receive updates from the MX with an AS Path of 64512 and 5.6.7.8 will receive an AS Path of 64512, 64512. Whereas the MX could receive updates for the 10.0.0.0/8 network from both of its BGP peers (1.2.3.4 & 5.6.7.8), but only the prefix with the shortest AS Path will be used (in the event of a tie the first configured peer is preferred, as the second router offers a longer AS Path due to double AS Path pr).
The fundamental reason to choose BGP over the currently OSPF-based solution, though, is that BGP allows for bilateral propagation of prefixes, means that when networks are added in the Meraki domain they are instantly shared into the wider/SP domain and vice versa.
When?
Now! As you can see from the above graphic, this functionality has been available in beta for some time (over a year at time of writing) and will soon be enabled in a generally available code release. Whilst this event is the culmination of a lot of work from a lot of people, it is only the tip of the spear. Traffic engineering with AS Path prepending, route leak prevention, and route table security are currently available on the MX. However, more advanced features including segmentation are coming in future phases.
Conclusion
At Meraki, we take the most complex routing protocol in the industry, extrapolate out the vendor-specific elements and layers complexity to make it usable and configurable in three clicks (and a little typing).
Meaning that with Meraki, organizations can scale from mom & pop to megacorp without switching platforms. Click here to find out more.
References
http://www.ciscopress.com/articles/article.asp?p=2738462
http://www.ciscopress.com/store/routing-tcp-ip-volume-1-9781587052026
http://www.ciscopress.com/store/routing-tcp-ip-volume-ii-ccie-professional-development-9781587054709