A person of my readers sent me a dilemma together these lines:
Do I have to have an IBGP session involving Consumer Edge (CE) routers in a multihomed web-site if they run EBGP with the upstream company(s)?
Let us start out with a easy diagram and a refactoring of the issue:
- A multihomed web site has two WAN edge (CE) routers
- Each and every CE-router runs EBGP with the adjacent PE-router.
- Do we need to have an IBGP session between CE-A and CE-B?
Remember to be aware that it doesn’t make a difference if we’re talking about an MPLS/VPN- or a redundant Net accessibility deployment. There’s no change in between the two eventualities from the CE-router perspective.
Our multihomed internet site is little sufficient to have a solitary L2 change, and each CE-routers act as a default gateway for the connected hosts. Now imagine a situation the place:
- CE-A receives a routing update for desired destination X from its upstream PE-router, but CE-B receives no corresponding update from its EBGP peer.
- A host sends a packet for X toward CE-B.
It’s noticeable that CE-B should have the information and facts that it can achieve X through CE-A, and there are two approaches to reach that:
- Trade the data around an IBGP session in between CE-A and CE-B
- Redistribute EBGP info into an IGP (for case in point, OSPF)
As you could possibly be operating an IGP inside the web page and redistribute IGP info into EBGP anyway, you will quickly land in a two-way redistribution morass if you select solution#2. Working IBGP concerning CE-routers is a significantly far better tactic, and provides you the capability to have web site-wide dependable routing policy. For example, you could use BGP local preference to point out which paths need to be most well-liked, causing the other CE-router to like IBGP paths more than EBGP ones.
Last but not least a term of warning: creating an IBGP session among CE-routers that do not support RFC 8212 could flip your website into a transit site. Not pleasurable if you transpire to be a steel company attracting Cloudflare website traffic. Make certain you have deployed outbound AS-route filters dropping transit paths on all EBGP sessions.