Propagation of BGP Routing Information among Routers belonging to the Same Company, Part 1

Hukou Old Street after sunset.
Hukou Township, Hsinchu County, Taiwan.

This post is continuing the previous BGP post.



Internal BGP, IBGP

When routers belonging to the same company are configured to exchange BGP routes, the neighbor sessions are called Internal BGP sessions, or IBGP.

The purpose of IBGP sessions are more to share and to synchronize all BGP routes learned at any owned BGP routers from any other companies.

No auto neighbor discovery, just like EBGP

The same as external BGP, all IBGP neighbor sessions must be defined manually.

Rule of re-sharing of IBGP learned routes

The magic of AS-PATH to prevent routing loops is not working well in internal BGP sessions, because now all internal BGP routers have exactly the same AS number. Can routers also sign-in using this same AS number, just like external BGP sessions?

Just imagine now that if I were the designer of BGP protocol, I had the following feasible different approaches.

Option 1: Re-define the interpretation of AS-Path, so internal BGP routers can sign in using the same AS number and maybe again and again, just to let other BGP routers know that these BGP routes are learned from internal BGP routers so be careful about the possibility of routing loops …

Quite complex, isn’t it! And at the same time, all internal BGP routers in production networks should be stopped and upgraded to enable this protection.

Option 2: Add more BGP attributes to mark some BGP routes are learned from internal BGP sessions. I think this is also a good way to add loop protection. The only drawback is all internal BGP routers in production networks should also be stopped and upgraded to enable this protection.

Option 3: “Avoid” this problem totally. No, I do NOT allow internal BGP sessions to re-share BGP routes AT ALL. Because routing loops always start from some router re-shares routing information from other routers, if I forbid re-sharing from happening at the beginning, no routing loops would would ever take place.

Somehow the designers took Option 3, so today the BGP protocol works like this:

By default, BGP routers would ONLY share learned external BGP routes to all internal BGP peer routers on DIRECT neighbor sessions. In other words, BGP routers would never re-share any BGP routes learned from other internal BGP routers.

I am calling this rule as “Direct Sync”.

Implication of “Direct Sync.” rule: full mesh of internal BGP sessions

That is, if any pair of two internal BGP routers are not configured with direct neighbor session, according to the rule no other routers would help to re-share BGP routes for them, then it is possible some learned BGP routes will never be synchronized between them.

After some math calculation, we all know a full mesh connecting N routers requires N*(N-1)/2 sessions.

This is a sample full mesh of 6 routers. Picture source: Wikimedia

When N is 10, we need 10*(10-1)/2 = 45 BGP sessions to configure. Maybe 45 BGP sessions to configure is not that difficult for some people, what about imagine we are asked to add one more router? We will have to check configurations of existing 10 BGP routers and add 10 more sessions. What a boring and repeating task! In addition, human beings make mistakes all the time. If something is configured wrong, how much additional time do we have to spend just to troubleshoot?

(When N is 100, we need 100*(100-1)/2 = 4,950 BGP sessions to configure! It is almost impossible to configure and deploy BGP sessions this way.)


So, this is really a problem. We need remediations for this design. I am going to discuss two working remediations in other posts.


Conclusion so far

Taking Direct Sync and full mesh aside, behaviors are almost the same in both IBGP end EBGP. So discussions in previous post, such as routing information propagation, BGP neighbor sessions, BGP routes, installation of IP routing table, best route selection, and show commands are all identical. When we get familiar with one, we also get familiar with the other. So BGP is not that difficult, isn't it!

To make you feel more comfortable about BGP, I share one more observation about BGP here.

When we make some mistakes such as we do not configure full mesh correctly, will there be any nasty warning messages telling us we have configured something wrong?

The answer is NO!

That is, no warnings, no error prompts, no bad news, and no frustrations at all! Nobody will notice our errors until comparing all BGP routes and all configurations. We always have plenty of time to fix the problems.

I personally like this "feature" very much!

(To be continued.)