I'm currently overhauling a large network, attempting to eliminate any single points of failure, and building up a core network to replace the adhoc mess in existance now. Currently we have a single border router all our our uplinks come into, with it handling BGP. It then uses OSPF to redistribute info to the rest of the network.
The redesign calls for a OSPF based 'core' network, with three pops. I'd like to split the uplinks across those pops. Doing so means at the very least getting iBGP meshing going amongst all three border routers.
My thought is now would be the time to deploy either a route reflector setup, or a route server, to take the majority of the bgp load off the border routers and place it on equipment that isn't actually shuffling packets. What would you recomend in this situation? The end goals, in order of priority are reliabilty, scalability, and ease of maint.
Are your internal routers, gonna be running BGP or just the 3 POP routers ? IF your internal routers are not gonna be using BGP, then with your 3 router network, you ll need only 3 IBGP connections between the routers, which shouldnt be an overhead for the routers to handle. You can definitely offload the uplinks and distribute them among all 3 border routers. A route reflector is really not needed in this case, unless all routers in your network are gonna run BGP.
Imagine a network where there are N routers. FOr IBGP, routes are exchanged only if you have a BGP session between 2 routers. If routers A, B and C are 3 routers running BGP, and there is a IBGP session between A and B and another IBGP session between B and C, routes wont be exchanged between A and C, unless there is an IBGP session between A and C. This requirement makes IBGP full meshing not to scale well enough in large networks. The formula for the number of IBGP sessions is
X = N (N-1)/2. Where N is the number of routers in your network. In your case, N = 3, so X = 3.2/2 = 3. Imagine a large network with 100 routers ( a big ISP).
X = 100.99/2 = 4950. Can you imagine the amount of configuration required, as well as how much memory and CPU will be utilised per Router, if that many IBGP connections have to maintained. In such cases you should really consider about going for a Route reflector design or a Confederation type design.
Imagine when N shoots up to 6, you can see that you ll need 15 IBGP connections.
Another thing to notice is that, when you plan to incorporate a router reflector into your topology, you should consider using a high end router as the RR, because the RR has to maintain full mesh IBGP connection with all its clients and other RRs. RR redudancy is also a good design, where all clients will have redudant physical/logical connections to the RRs, so that incase of a RR failure, a backup RR is available.
Use of RR has one advantage that, configuration wise, a lot of overhead is taken off the hands of the administrator. The route reflector configuration is done using a single command, and that too is given only on the route reflector. Clients are transparent to the RR design.
Ok, if I'm reading this correctly, if I'm not exepecting to expand beyond 3 border routers to mesh with IBGP, than staying with the simple IBGP mesh is a clean/viable solution. If I'm likely to expand the number of IBGP peers, using RRs becomes advantageous in cutting connections and configuration down.
Is there a good doc on using a Cisco IOS based device as a RR?
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...