Create a service account for a Kubernetes app.
If an RR sees an update with it’s own RID the route is ignored. The ORIGINATOR_ID is created by the route reflector and is the router-id (RID) of the originator of a route. In order to do that RR’s make use of two BGP path attributes: ORIGINATOR_ID & CLUSTER_LIST. If the route was learned from an eBGP - it is reflected to all clients and non-clientsĭue to the iBGP rule where internal neighbors cannot advertise routes learned from on internal router to another, route reflectors need a method in order to prevent.If the route was learned from a client, it is reflected to all non-clients and clients (except for the originating client).If the route is learned from a non-client iBGP it is reflected to clients only.Route Reflectors follow three rules to determine who the route is advertised to:
An AS can have multiple clusters and there also can be multiple RR for redundancy in the setup.
The RR can peer with both internal and external neighbors outside of the cluster. The clients can peer with other external neighbors or clients in the cluster. The RR can learn routes from its clients and advertise them to clients and non-clients.
Imagine an iBGP setup where you have 50+ routers in a full mesh - it would be a very tough situation to manage! With route reflectors you can have one router configured as a route reflector (RR) and other iBGP peers called clients.Ī router reflector and it’s clients are known as a cluster. In iBGP peers must exist in a fully meshed topology to insure no routing loops. To understand Route Reflectors you must understand the problem they attempt to alleviate.
They can make your large BGP setups become stress free (assuming you use them right :P). While these two names do sound like something out of Star Trek, please do not be afraid of them. One is called Route Reflectors and the other is called Confederations. Today we will be discussing two different set of BGP related tools you can use to help scale and maintain a large BGP implementation.