BGP: Difference between revisions
→Confederation
Line 244:
= Confederation =
*RR does not require major changes to existing configuration
*It implies choosing routers that will act as a focal point for iBGP sessions within a single AS, running a single IGP.
*Confederations needs quite a config change and architecture.
*Confederations may contain different IGPs, adding more flexibility to scaling your network.
*In case your IGP is exceeding its scalability limit and becomes unmanageable, use Confederation.
*A method to subdivide a single AS into multiple internal sub-AS's, yet still advertise as a single AS to external peers.
*The intent is to reduce iBGP mesh size, scalable approach for a large autonomous system.
*Each of Sub-AS has its own AS number.
*Reduces the total number of iBGP peering sessions per router within AS.
*Large no of iBGP sessions can consume bandwidth and cause high CPU utilization, so negatively affect the performance.
*Each sub-AS has different AS number.
*All peers in sub-AS are fully meshed in order to learn external routes from external sources.
*Every sub-AS is identified by its unique AS number(private: 64512 – 65535), the connection between them is always eBGP peering called Intra-Confederation eBGP.
*eBGP routes between sub-ASs called Confederation External Routes, are preferred over iBGP routes.
*If BGP has to choose between two paths, one leading inside sub-AS and other outside sub-AS, within confederation, it will choose the external path – to neighboring sub-AS.
*To choose between Confederation eBGP route and eBGP route leading outside of confederation, BGP will choose the second one.
*AS_PATH attribute contains AS_CONFED_SET parameter which is modified inside the confederation only
*In case the confederation runs one IGP, NEXT_HOP, MED, LOCAL_PREF do not change when routing update traverses Intra-Confederation eBGP
= Route Aggregation =
| |||