Redundant Core Routing

[jmon420007]

hello,

I have attached a net. diagram for a new core routing setup. I am trying to get full redundancy for all attached distribution routers to our primary core bgp routers. I am thinking iBGP might be a solid option and I am looking for some advice or possible configuration options to get me started.

Our setup is as follows:

2 core bgp-routers connecting to multiple carriers. Our core routers are directly attached to two different distribution routers. The distribution routers connect to multiple remote site Edge routers,, that are all connected in an ospf topology with full redundant paths back to our network core.

Any info or comments would be greatly appriciated.

Thanks,

Thomas

[Reza Sharifi]

Hello Thomas,

I see some inconsistency in you design.  For example, I see you are connecting edge-2 to dist-1 only (single point of failure), yet you have  edge-1 connecting to dist-1 and also edge-3 and 4 and not dist-2. I am assuning the edge switches are where the users are connected.  So, I would connect edge-1 to dist-1 and dist-2 and the same for edge-2, 3 and 4.  This way you have redundency for all your devices.  Are the edge devices layer-2 only or is there another layer behinde them?

HTH

Reza

[jmon420007]

Hello,

All the edge devices are layer3 devices. I am not concerned with the Dist to Edge routers. We have multiple paths between each Edge remote site back to the core. My main concerns are with the direct connections between the Edge routers and the BGP-Core routers. I need to be able to have a fully redundant/auto fail over setup.

[Ganesh Hariharan]

hello,
I
have attached a net. diagram for a new core routing setup. I am trying
to get full redundancy for all attached distribution routers to our
primary core bgp routers. I am thinking iBGP might be a solid option
and I am looking for some advice or possible configuration options to
get me started.
Our setup is as follows:

2
core bgp-routers connecting to multiple carriers. Our core routers are
directly attached to two different distribution routers. The
distribution routers connect to multiple remote site Edge routers,,
that are all connected in an ospf topology with full redundant paths
back to our network core.
Any info or comments would be greatly appriciated.
Thanks,
Thomas

Hi Thomas,

As your core routers are already running BGP with external peers and you have full meshed connectivty between core and distribution routers.so ibgp will be one of the good option running between core and distribution routers.

If you have decided to go with BGP in core network then just check the router capabilties to handle the bgp process because a High CPU due to the BGP scanner process can be expected for short durations on a router carrying a large Internet routing table. Once a minute, BGP scanner walks the BGP RIB table and performs important maintenance tasks.

and The BGP router process runs about once per second to check for work. BGP convergence defines the duration between the time when the first BGP peer is established and the point at which BGP is converged.

and check out the below linkfor ibgp and ebgp configuration link

http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080093f25.shtml#ibgpconfig

Another option is there if you have all devices are cisco then also check for option for running EIGRP between all core and distribution routers as it is one of the fastest routing protcol with high level of convergence.

Hope to help

If helpful do rate the post

Ganesh.H

[jmon420007]

Is there any need for route reflection between the routers in the iBgp mesh? I guess I am just lost on the config for this with iBgp and multiple routers.

[loworderbit1]

Route reflectors allow IBGP to scale better.  IBGP requires a full mesh between peers.  IBGP routers peer with the route reflectors in order to receive route updates--instead of peering with every other IBGP router within the AS.

[jmon420007]

If I only have 4 routers that will be a part of the ibgp mesh, and they are all directly connected, and I have them all peered together, can I assume that the use a designated router reflector is not neccessaery or needed? I have attached an updated diagram to show exactly what setup I have. Also, within the Ibgp mesh, can I use a "private" AS or should I configure the ibgp mesh using our assigned ARIN AS?

[Reza Sharifi]

jmon420007 wrote:
If I only have 4 routers that will be a part of the ibgp mesh, and they are all directly connected, and I have them all peered together, can I assume that the use a designated router reflector is not neccessaery or needed? I have attached an updated diagram to show exactly what setup I have. Also, within the Ibgp mesh, can I use a "private" AS or should I configure the ibgp mesh using our assigned ARIN AS?

That is correct.  In your scenario with 4 routers all connected together fully meshed you do not need a route reflector.  Even if they ware not physically  fully meshed and as long as you have IGP readability between all your 4 routers, you still can get by without using a route reflector. The use of route reflector becomes more important as you start adding more routers.  Also, if you already have an assigned AS number why not just use it.

HTH

Reza

[jmon420007]

I was just not sure if I need to designate a seperate AS for the iBGP mesh as apposed to our AS were using for our eBGP connections. So does it matter, draw backs/benefits, etc?

Thanks for all the info...

[Reza Sharifi]

For 4 routers, I think one AS is good enough.  The thing to remember is if you deploy a private AS, once it hits the first service provider router, they all do remove-private, so your AS will not go any further. The config is a little more complicated if you have 2 AS numbers, but it also gives more control over the boundaries of your network and your policies.

HTH

Reza

[jmon420007]

Can you provide a sample config or direct me in the right locations. I would really like to only use our assigned AS on the eBGP sessions to our carriers and keep the iBGP seperate and private AS.

[bdmckamey]

Heres my recommendation. Cores, distribution, and edge routers will all be in one autonomous system (i.e. it looks like you already have AS 200 for the cores, just extend to the other routers). Make the Distro's be the route reflectors for your edge routers. The distro's and the core routers will be fine to do regular iBGP do to the fully meshed interconnects. Make sure when you make the Distro's route reflectors of the edge routers, you run 'next-hop-self' so that the core routers don't get the Edge router routes and see the next hop as the edge routers. They will see the distro's as the next hop for the packets. Look up route reflector configurations on the cisco site. When you configure your eBGP sessions on your core routers, be sure to check your metrics and ensure you are returning in through the internet path you are routing out of.

Just my two cents. It seems I might be replying waaaaaaaay too late on this post, but this is in case someone stumbles upon this post and wondered what would be a good way to remedy this solution.

On a side note, I would try to run redundant connections from my edge routers to the distribution routers in the WAN and make both the distro's router reflectors of each of the edge routers. Also, I see that you are referencing the routers in what appears to be your WAN (that is, the transport network portion of your network basically everything above the firewalls and before the ISP provider connection). The router directly connected to your internet uplink or ISP is typically the Edge router and the rest of your routers are outer routers. Core switch/router is typically what is directly connected to the inside of your firewall and the distribution portion is below that. Though I get what you were conveying with the diagram. In the WAN those are basically the functionality of the routers, just was confused when I first looked at your diagram and then it hit me this was the WAN and not the LAN portion. I kept wondering where you had the firewalls to seperate the outer from the inner portion of the network until I realized it was the WAN. LOL!!!