Internal BGP (Border Gateway Protocol) explained


(Rene Molenaar) #61

Hi Palani,

Since R1 and R5 only have one exit path, they don’t really require eBGP in this topology. We could have used a static default route here and be done with it. If you still want to use BGP, it would also be possible to advertise a default route through BGP from R2/R4.

The main idea behind this lesson is to explain why we require iBGP, it’s because R3 will drop traffic…that’s something we can’t solve with a default route :slight_smile:

Rene


(PALANIAPPAN M) #62

Awesome, Thanks for your response. Yeah here we are talking about achieving this with BGP


(Ahmad D) #63

Great Posting !

Ahmad


(Sravanthi N) #64

Hi Rene,

I appreciate your good work! Can you direct me to lab for this lesson? Thanks!


(Rene Molenaar) #65

Hi Sravanthi,

You can take a look at my GNS3Vault labs:

Internal BGP

Rene


(Georgi T) #66

Hey Rene

thanks for the tutorial but I do have a question for you .I do understand the IBGP concepts but can you give me real time enterprise network or WAN network scenerio where we need to use IBGP .I work work telecom company but I have nevern ran into IBGP config on our network .

thanks


(Lazaros Agapides) #67

Hello Georgi.

There are alternatives to using iBGP (such as an IGRP or even eBGP), so for the same topology, you may see alternatives to iBGP being implemented. However, iBGP does have some advantages over these other solutions. The choice of which to use in a production network has to do with the network policies that govern each company (either service provider or customer).

Some of the most convincing reasons to use iBGP in a production network can be found in the following Cisco support forum post that I believe you will find informative.

I hope this has been helpful!

Laz


(rayniero p) #68

Hello

I just want to confirm I got the info.

We have a IBGP , so to make this happen the following is needed.

  1. we must configure one IGP to make known both the WAN prefix also the loopback , so we configured OSPF , so establish the BGP sessions using the loopbacks.

2-Into BGP WE MUST advertise the prefix between our routers to avoid communication issues. Right.?

3.full mesh is required.

4-Use next-hop self in the routers that connect to the prefix , due to by default next-hop is not altered.

Thanks , please let me know if this is correct.


(Andrew P) #69

Rayniero,
It is a little difficult to answer your questions without having a diagram of the network in question, but here’s my best attempt:

  1. If you are using “next-hop-self” in step #4, it would not be necessary to advertise your WAN prefix into OSPF. If you choose not to use next-hop-self, then yes, OSPF will need to advertise your WAN prefix, otherwise your iBGP routers will have an inaccessible next hop and will not install or advertise external routes

  2. I am not fully understanding what you are asking here. Are you talking about internal or external prefixes? Presumably, internal prefixes will be handled by OSPF in your case, so it would not be necessary to advertise those within BGP. In fact, you probably don’t want to do that anyway, unless either filter those internal prefixes before they leave your Autonomous System, or you know that you want the Internet to know about your prefixes.

  3. A full mesh is the best solution if you have a small number of iBGP routers. The reason is that each iBGP router has full visibility of your internal network paths, so each can decide the best exit point. If you have a large number of iBGP routers, the most common solution is to use a route-reflector or BGP confederations (much less common).

  4. This is really a design decision, as mentioned in answer #1. If you don’t do next-hop-self, then advertise your WAN prefix into your OSPF. If you have multiple exit points to the same WAN prefix, it might be best not to use next-hop-self, and let your OSPF make the decision on which exit point is the best.


(Neeraj K) #70

Hi Rene,

Based on the explanation on this chapter, ping from R3 to R1 loopback address 1.1.1.1/24 will still fail because R1 does not know how to reach 192.168.28.3. We only solved the reachability between R5 and R1?

What needs to be done such that R3 can ping R1? Advertise 192.168.23.X thru ebgp?

Neeraj


(Hoan N) #71

Hi Rene

on R2, can we only export 1.1.1.0/24 to OSPF, and on R4 , we export only 192.168.45.0/24 to OSPF,
that way, we don’t need IBGP?

Thank you


(Manami B) #72

Hi,

I have an doubt. Why we need IGP within the AS to work iBGP perfectly. Can you please explain me.

Thanks


(Manami B) #73

Hi Rene,

I must say your contents are mind blowing. Can you please write another awesome content to understand in detail why we need IGP inside AS?

Manami


(Andrew P) #74

Manami,
I can give you a couple of reasons why you should run an IGP inside an AS:

  1. Speed of convergence for the AS core
  2. Reduced hardware requirements of core routers within the AS

An important point to consider about BGP is that it is truly different from other routing protocols in that it doesn’t actually route packets. Instead, think of BGP as an application that tells you where packets need to go, but not HOW to get there. The “how” is up to a true IGP. Let’s consider this from the perspective of a very simple ISP. Let’s say this ISP has three peering points with other ISPs - A, B, and C. The routers for A, B, and C would sit on the edge of the ISP’s network at the actual connection points with other ISPs, and only these routers must run BGP. What BGP will do in this case is say, “if you want to get to network X, go to A. If you want to get to network Y, go to B. If you want to get to network Z, go to C.” Again, the key point here is that BGP tells you WHERE to go, not HOW to get there.

The job of HOW to get to A, B, or C, is up to the ISPs core routers, which are often separate from the routers for A, B, and C. These core routers don’t need to know, nor do they care, about the full Internet BGP topology. All the core cares about is routing between A, B, and C, and doing that as fast as possible. The core also needs to adapt to changes of connectivity between A, B, and C as fast as possible. Because of this, there is no reason to run BGP on them. BGP is resource intensive and very slow to converge as compared with typical ISP favorites like OSPF or IS-IS.

So the key answer to your question is understanding the separation of WHERE to go (BGP) vs HOW to get there (IGP).


(Thierry D) #75

Hi there,

If As2 runs an IGP (Say OSPF in our case), should’nt we have to make the R2 and R4 edge interfaces passives? If not, we would have the risk of sending OSPF packets outside AS2.

Correct me if I’am wrong.


(Andrew P) #76

Thierry,
In a production environment where the devices outside of AS2 are not under your control (or you don’t trust them), you are absolutely correct.


(Networklessons Admin) split this topic #77

19 posts were merged into an existing topic: Internal BGP (Border Gateway Protocol) explained


(Thierry D) #78

Thanks Andrew for you reply.

One thing I’m wondering about IP addresses used in almost any course (including this one).

In production environments, what kind of addresses are used between providers to interconnect their respective ASes. Is it generally public or private addresses ?


(Andrew P) #79

Between providers would almost always be public.


(Edi W) #80

Hi Rene,

When we have routers R1 - R2 - R3 - R4 - R5, I can understand that we need to peer between border router R1 and R3; and to peer between R3 and border router R5. That’s because border routers R1 and R5 need to advertise out prefixes to R3.

Why do we need to peer R2 and R3; R2 and R4 in full mesh? R2 will never advertise out any prefixes received from border router R1 anyway because of IBGP split horizon rule.

Thanks,
Edi