[c-nsp] how many maximum BGP routers can be to reside in one AS？

[Vitkovsky, Adam]

Nick is right

Confederations will help you to scale the IGP 
One IGP per Confederation -no redistribution of routes between confederations 
If you need to redistribute bgp next-hops between confederations (to allow proper inter-confed routing in mpls environments)
Carry those in BGP-ipv4-afi +labels rather than redistributing them between IGPs in different Confederations


And hierarchical RRs within the Confederation will help you to scale the number of iBGP sessions within the confed and eBGP sesions between the confeds

PEs would reflect to Intra-confed-RRs
And Intra-confed-RRs would reflect to Inter-confed-RRs which would than peer with Inter-confed-RRs in other Confederations

If you are using more than one RR in each level don't forget to put the RRs in each level into common cluster (if design allows you can use several clusters per level)

Let's say you configure 100 PEs to peer with two Intra-confed-RRs and these two RRs peer with two Inter-confed-RRs 
Put the two Intra-confed-RRs into common cluster-01-L1
And the two Inter-confed-RRs into common cluster-0-L2

Now you can configure another 100 PEs to peer with other two Intra-confed-RRs sharing a common cluster-02-L1
-these two RRs would also peer with the Inter-confed-RRs in cluster-0-L2

If you ran out of the peer capability on the two Inter-confed-RRs in cluster-0-L2
You can create another Inter-confed-RRs in a common in cluster-1-L2 and start connecting new Inter-confed-RRs with PEs to them

Please nothe that two RRs within the cluster/level don't need to peer with each other directly
Routing information between them will be deseminated over the above level
Same applies for propagating the routing info between clusters in the same level

And each device only needs to have 2 uplink sessions to next level of hierarchy

The above is how you can scale the number of iBGP sessions within the Confederation


Since all the RRs need to know of all routes within the AS 
With the above implemented the remaining limiting factor is the maximum numer of routes the weakest RR can store (memory limitations) and process/reflect (CPU limitations)

In case you need to process several milions of routes (in case you support plethora of mpls VPNs)
You can multiply/clone your RRs infrastructure into several routing Planes each servicing a subset of VPN routes (each Plane would be serviced by a separate set of devices/RRs and would not share routes with other Planes)
Than you can simply scale by adding another Plane to suppor new VPN customers


adam
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Nick Hilliard
Sent: Thursday, May 26, 2011 1:14 PM
To: ying-xiang
Cc: cisco-nsp
Subject: Re: [c-nsp] how many maximum BGP routers can be to reside in one AS？

On 26/05/2011 08:58, ying-xiang wrote:
> in another words,is there a limit to be the amount of one AS BGP routers?
> we have a network design will put 2500+ routers running ibgp session
> into a single AS.of course,RR or confederation is required.even so, i am
> not sure it will be done with this design.AFAIK, router’s memory is a
> import thing to consume of bgp route prefix.apart from this,what else
> should get my attention?

2500 routers is quite a large network.  For this size, you will probably 
want to break it down into a number of confederations and create a routing 
policy for each confederation.

It's not really possible to summarise how to do this in a short email, but 
things to look out for are:

- RR cpu load and the number of clients on each RR
- the size of each confederation
- whether or not all your routers need to receive a full routing table
- FIB size on your hardware routers
- your IGP management
- whether you're going to run mpls or not

BGP + RRs + confederations will scale to whatever size you need.

Nick
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/