Need help to understand this point in BGP

[turbo_engine26]

Dears,

As per the topology, Vail and Telluride are iBGP peers using loopback interfaces. In order for them to establish a TCP connection, these loopback addresses should be enabled under an IGP routing process (in this case, OSPF). Alternatively, static routes pointing to loopback addresses works as well. I wonder, why the link connecting both routers are included under the IGP process too? The link is highlighted in red in the attached config. file. ... When i tested it, i noticed it is not necessary to include this link under OSPF.

Please let me know if it is a printing or author's mistake.

Thanks

AM

[cadet alain]

Hi,

I think the answer is in the sentence right above the picture: resiliency

Regards.

Alain

Don't forget to rate helpful posts.

[turbo_engine26]

Please clarify with details. I am not a big fan of short answers.

Thank You.

[turbo_engine26]

Anybody?

[Giuseppe Larosa]

Hello turbo_engine26,

as noted by Alain running OSPF on all the links provides network redundancy, that is if one link fails the iBGP session can still be up, because the OSPF domain is not divided in two parts by the fault as it would be if one link would not be in the OSPF domain.

This is the main reason to use loopback addresses as iBGP endpoints redundancy and fault tolerance.

Hope to help

Giuseppe

[turbo_engine26]

Hi Giuseppe,

Thank you for your reply.

This is actually what confuses me. This topic is talking about "BGP over IGP", which means to run an internal IGP instead of the fully meshed iBGP. Because of this, the link between the ASBRs should run iBGP only and not included in the IGP process. If it is to be included in the IGP process, this means that paths to routes in AS 200, for example, would be preferred over iBGP since the OSPF's AD is lower than iBGP. Is this what we want to achieve at the end?  ... We can still achieve redundancy by creating static routes to each loopback address and turn off sync. if the link between Vail and Aspen failed, for example. At the end,  i don't want to end up configuring IGP while the whole topic is talking about BGP

What do you think?

AM

[turbo_engine26]

Ok, let's go through it step-by-step.

1) Loopback addresses are configured in each ASBR for the intention to form iBGP session indirectly.

2) For iBGP session to establish indirectly, each ASBR must reach their Lo addresses using IGP or static routes.

3) iBGP is now established between ASBRs through IGP. (But the link between ASBRs still not yet included under the IGP process)

4) From Telluride, AS 200 destinations (E2 routes) are now reachable through Aspen because OSPF 110 is lower than iBGP 200.

5) Let's try now to include the link between ASBRs under OSPF. From Telluride, AS 200 destinations (E2 routes) are now reachable via two OSPF paths, through Aspen and Vail but OSPF has selected Vail path as the best one because i think Vail's router ID is higher than Aspen, i don't remember OSPF topic now. (This step is the start point of my confusion. If i reach destinations through OSPF paths, why did we create an iBGP session in the first place? I can just run OSPF in all three routers in AS 100 and redistribute BGP to them. Of course, ASBRs still need to run BGP since they are connected to other ASs.)

6) Let's disable the link between Vail and Aspen to see what happens. From Telluride, AS 200 destinations are now reachable via one OSPFpath, which is through Vail.

7) Now, let's remove the link between ASBRs from the IGP process, create static routes instead and turn off sync.

8) AS 200 destinations (B routes) are now reachable via the native iBGP peer.

Hope you understand my confusion.

AM

[Giuseppe Larosa · Accepted solution]

Hello AM,

the book example has some limitations I agree on this.

In real world we need to be able to accomodate both signalling plane ( routing protocols level, IGP and iBGP sessions) and to be able to move traffic within the anatomy of the autonomous system AS 100 (the forwarding plane or data plane).

The IGP can be used to provide infrastructure connectivity ( loopback addresses of all routers published over the IGP), but an IGP is not so scalable as BGP can be.

So all the services related IP networks can be advertised using BGP.

In short, for a good working example you need:

a) IGP running on all links between routers in AS 100 including the link betweeen Vail and Telluride.

b) a full mesh of iBGP sessions on loopback addresses on Vail, Telluride AND Aspen

Aspen needs to be part of the iBGP mesh or it may become a black hole for traffic with destinations that are learned on Vail or Telluride via eBGP sessions.

In real world redistribution of BGP into IGP is not performed for scalability reasons. BGP can support hundreds of thousands of routes, instead OSPF only supports a few thousands of routes.

Answering to your questions:

1) OK

2) OK

3) KO if Aspen is not in the iBGP mesh and BGP routes are not redistributed into OSPF (this is almost NEVER done in real world as explained above). The problem is that the iBGP session can come up but Aspen may be unable to route traffic between destinations in other ASes like AS 200 or AS 400.

4) Requires redistribution of BGP into OSPF that is not good practice. If this redistribution is performed on BGP border routers Vail and Telluride then Aspen can route traffic as you note.

5) If we include the link between Vail and Telluride in OSPF, transit traffic will go over that link following external OSPF routes as you noted.

>> why did we create an iBGP session in the first place?

This is the key point: AS 100 is providing transit services to other ASes like AS 200, AS 400, AS 300.

Without the iBGP session between Vail and Telluride AS 400 will not learn about routes of AS 200 and AS 300 or would not see the correct AS path if OSPF external routes would be redistributed into BGP.

The iBGP session between Vail and Telluride is needed for correct propagation of eBGP routes.

6) - 8) running OSPF on all links inside AS 100 is the best choice instead of dealing with static routes

The book example protects the iBGP session between Vail and Telluride running OSPF in all links internal to AS 100.

In real world OSPF and BGP run separately with no redistribution of BGP into OSPF so other two iBGP sessions Aspen -Vail and Aspen - Telluride is needed and again the good move is to make this iBGP sessions on loopback addresses.

Hope to help

Giuseppe

[turbo_engine26]

Hi Giuseppe,

That was a one fine great explanation. Thank you for your efforts really.

I totally agree, common real world sense is to use a native internal BGP using either full mesh, RRs or confederations and just avoid the headache of redistribution. However, because i am studying for the lab exam, i must perform every single scenario even if it is not required in the real world. And this BGP over IGP topic really gives me pain in the ***.

I just want to let you know that you are correct. i tested it again and noticed that the iBGP session between Vail and Telluride is of a huge important. Simply, if this session was not there, AngelFire would not be able to reach AS 400. In addition, the AS will lose insight for the AS path. In fact, you will laugh when you know that i tried to natively run OSPF in AS100 and used redistribution from BGP to OSPF in Telluride, then used redistribution from OSPF to BGP in Vail, in order for AngelFire to reach AS 400 but it didn't work.  

If you allow me to ask one more question regarding my last sarcastic attempt, and maybe it will sound naive but just curious to ask it:

Why redistibution of routes from AS to another AS and when that other AS redistribute those routes to another AS doesn't work?

Just for discussion.

I would like to thank you for your help.

AM

[Giuseppe Larosa · Accepted solution]

Hello AM,

>> Why redistibution of routes from AS to another AS and when that other AS redistribute those routes to another AS doesn't work?

my guess is that you did only half of the job according to your attempt description:

>> that i tried to natively run OSPF in AS100 and used redistribution from BGP to OSPF in Telluride, then used redistribution from OSPF to BGP in Vail, in order for AngelFire to reach AS 400 but it didn't work

The above is able to take eBGP routes learned from AS 400 in OSPF domain as O E2 routes and then on Vail to pick the corresponding O E2 routes and to inject them  towards AS 300 and AS 200 but a similar job should be done on Vail to inject in OSPF the eBGP routes learned from AS 200 and AS 300 and then on Telluride to redistribute from OSPF to BGP. A lot of work that can be saved by an iBGP session!

This is why I have written you had made half of the job.

You need to provide a return path for traffic.

Clearly all this is unmanageable and does not scale in real world.

Let me suggest you that you need to study more the theory, as a CCIE lab candidate should not use the sentence running "OSPF in AS 100" as OSPF has no AS concept but uses local process-id.

This is needed to be able to understand the lab requirements.

Hope to help

Giuseppe

[turbo_engine26]

Dear Giuseppe, thank you so much for your great help that you provided in this thread.

Clearly all this is unmanageable and does not scale in real world.
Let me suggest you that you need to study more the theory, as a CCIE lab candidate should not use the sentence running "OSPF in AS 100" as OSPF has no AS concept but uses local process-id.
This is needed to be able to understand the lab requirements.

Yes, all this is unmanageable indeed. Actually, this is a part of my learning process is to do unmanageable things first. This for sure may sound odd to you but when i learn the theory of specific technology, i try to implement every worse scenario you that can imagine in order to know what are the consequences and how this technology actually thinks. For example, i learned that RIP's split horizon states that routes learned from a neighbor are not allowed to go back to that neighbor again. However, in order to see this fact, i advertised those routes back to that neighbor again. Same with BGP here, instead of running iBGP session, i said let's try to do something strange and just run IGP in all internal routers and play with some unmanageable work.

In other words, i don't like to just follow the right configurations of something but to do the opposite configurations to make sure that the right configurations was right.

Once again, thank you so much for your time.

Regards,

AM

[turbo_engine26]

Almost forgot, thanks for the suggestion, it certainly was valuable.

[turbo_engine26]

Dear Guiseppe,

Sorry i forgot to tell you something about this strange redistribution attempt. After reading your reply carefully, i figured out that i didn't clarify more.

Giuseppe Larosa wrote:
>> that i tried to natively run OSPF in AS100 and used redistribution from BGP to OSPF in Telluride, then used redistribution from OSPF to BGP in Vail, in order for AngelFire to reach AS 400 but it didn't work
The above is able to take eBGP routes learned from AS 400 in OSPF domain as O E2 routes and then on Vail to pick the corresponding O E2 routes and to inject them  towards AS 300 and AS 200 but a similar job should be done on Vail to inject in OSPF the eBGP routes learned from AS 200 and AS 300 and then on Telluride to redistribute from OSPF to BGP. A lot of work that can be saved by an iBGP session!

When i redistributed BGP to OSPF in Telluride and redistributed OSPF to BGP in Vail, the routes of AS 400 are not injected in AngelFire's IGP table. Only the routes of the in AS 100 is injected, which are the three links in AS 100. I mean, It is not a pinging issue as you may think, it is a non-existent routes issue.  When you said "half job" i thought that you might think it was a ping issue. Also, as you noted, when i redistribute BGP to OSPF in Vail and redistribute OSPF to BGP in Telluride, the routes of AS 200 are not injected in Alta's IGP table.

Just want to clarify.

Appreciate your help.

AM

[turbo_engine26]

Hello Alain,

I would like to thank you for at least responding to my thread and please forgive my harsh words.

Regards,

AM

[cadet alain]

Hi,

I'm happy you got the detailed explanation you wanted and this is not a problem, I didn't take them as harsh.

Regards

Alain

Don't forget to rate helpful posts.