Internal BGP (Border Gateway Protocol) explained

Hello Card

It depends on how you have configured the loopback in R1. If it was configured with an IP address of 1.1.1.1 and a subnet mask of 255.255.255.0 then the network 1.1.1.0 mask 255.255.255.0 command should work. But if the loopback was configured as 1.1.1.1 with a subnet mask of 255.255.255.255 then only the network 1.1.1.1 mask 255.255.255.255 command will successfully advertise it.

This is because, as you very correctly stated, that you have to advertise the prefix as it shows up in the routing table. And it will show up in the routing table according to how you have configured it on the loopback itself.

BGP is used to route traffic from AS to AS. So traffic will be routed between AS1, AS2, and AS3 using BGP. Any traffic routed WITHIN an AS is done so using IGPs such as OSPF and EIGRP. Even though iBGP is configured on all three routers in AS2, the networks being advertised and shared between them are external to the AS. If you see the output of the show ip bgp command on internal AS2 routers, you will see that there are no internal routes included in the BGP table. So iBGP is used to share routing information about Autonomous Systems between routers in the same AS. However, the protocols that do the routing between routers in the same AS are IGPs.

Now it is possible to enable the advertising of internal networks within an AS so that iBGP will be used to route internally as well, but this is not best practice, because BGP converges too slowly for the needs of such networks.

I hope this has been helpful!

Laz

1 Like

I love this explanation…

“Now it is possible to enable the advertising of internal networks within an AS so that iBGP will be used to route internally as well, but this is not best practice, because BGP converges too slowly for the needs of such networks”

Thanks!

1 Like

Your explanation throughout was amazingly involving. But I had one concern.
While we were not able to ping from R3, we left that in mid and we directly jumped on to the main requirement of R5 pinging to R1.
Now my question is, “Isn’t there any scenario/real time requirement where R3 would be required to ping R1? , a router in the transit path?” Was it not important to solve the issue that R3 should also ping R1?"

Hello Praveen

In the troubleshooting procedure, Rene is trying to find out why R5 cannot ping R1. So he starts by looking at R2, checks to see if the ping works and it does. He goes one step further, and checks R3, and that’s where the ping no longer works. Then in the process of troubleshooting, he sees that the problem is in R1. He fixes it, and then tests the whole ping from R5 to R1, and the ping works. From the moment the ping works from R5, it means the problem is solved. This also means that the ping will work from R3 as well.

Remember that the purpose of the troubleshooting procedure was to verify the ping from R5 to R1. Since this was achieved, there was no need to check R3 again. However, if R3 was checked again, you would see that it would work, since R5 to R1 worked as well.

I hope this has been helpful!

Laz

1 Like

sir
i have 2 question in my mind which is confusing me
Q.1> it is possible that i can run ospf in AS 2 routers and in end point where i will do redistribution with both endpoint routers which is the member of different AS
Q.2> why firstly you have used OSPF and then You used IBGP ? why we can’t directly use IBGP instead of OSPF

Hello Harshit

Yes it is possible to do this. However, it is not a good idea. This is why we have Autonomous Systems, so that all the routing information concerning internal routing can be dealt with using an IGP like OSPF. You don’t want to share the information in one AS with another AS using an IGP. The routing tables just get too large! That’s why BGP is there, to take care of inter AS routing. So to answer your question, yes you can do it, but it’s not a good idea to do so.

This is a question that is often asked. Why not use iBGP to route internally and forget about IGPs? Take a look at this post, I hope you find your answer there.

I hope this has been helpful!

Laz

2 Likes

Hi Ankit,
Let me try to answer your question. IBGP neighbors needing to be full mesh, does not mean they need to be physically connected - but rather they should have an IBGP neighbor session configured between them. If the 2 routers are reachable over an IGP you can configure IBGP between them. With this, it does not restrict you with the default rule of TTL being 1 as neighborship as intermediate router/s will drop the packet.

For the second question, IBGP does not use the AS path check for loop prevention so it will allow the prefixes to be learned. For the loop prevention, IBGP uses the split horizon(that is it will not forward a route received from an IBGP neighbor to another IBGP neightbor). Hope this helps.

Thanks,
Madhu

2 Likes

Hello Rene,
the command update-source is responsible for choosing the loopback interface as a router id?
Or what do you mean by the bgp session?
Thank you.

Eda

Hello Eduard

The update-source command indicates to the router which interface will be the source of the BGP messages that will be exchanged between the BGP neighbors. By default, the BGP update packet’s source IP address is that of the outgoing interface. By using “update-source”, you are indicating that you want the loopback to be the source of these packets rather than the exit interface.

I hope this has been helpful!

Laz

2 Likes

topology_BGp

Hi Rene,

I had configured in Lab iBGP as you had explained but I have confusion in two commands why we actually use these:

update-source Loopback0
 next-hop-self

In the loopback 0, this loopback will be the neighbor lo interface (can be 0, 1 or which it has) or will be the loopback interface of the device on which we are doing configuration?

I had attached the config file for all the devices in the topology and I am not able to form iBGP between the Transit Area due to which there is no communication, error that I am getting is below:

Jun 18 13:01:16.975: %BGP-5-ADJCHANGE: neighbor 4.4.4.4 passive Down AFI/SAFI not supported

Kindly advice what is the issue due to which I am getting this error on R5.

R1

interface Loopback1
 ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 duplex full
!
interface FastEthernet1/0
 no ip address
 shutdown
 speed auto
 duplex auto
!
interface FastEthernet1/1
 no ip address
 shutdown
 speed auto
 duplex auto
!
router bgp 1
 bgp log-neighbor-changes
 network 1.1.1.0 mask 255.255.255.0
 neighbor 192.168.1.2 remote-as 2
!

R2

interface Loopback0
 ip address 2.2.2.2 255.255.255.0
!
interface FastEthernet0/0
 ip address 192.168.1.2 255.255.255.0
 duplex full
!
interface FastEthernet1/0
 ip address 10.1.1.1 255.255.255.0
 speed auto
 duplex auto
!
interface FastEthernet1/1
 no ip address
 shutdown
 speed auto
 duplex auto
!
router ospf 1
 network 2.2.2.0 0.0.0.255 area 0
 network 10.1.1.0 0.0.0.255 area 0
 network 192.168.1.0 0.0.0.255 area 0
!
router bgp 2
 bgp log-neighbor-changes
 neighbor 3.3.3.3 remote-as 2
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 3.3.3.3 next-hop-self
 neighbor 4.4.4.4 remote-as 2
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 4.4.4.4 next-hop-self
 neighbor 5.5.5.5 remote-as 2
 neighbor 5.5.5.5 update-source Loopback0
 neighbor 5.5.5.5 next-hop-self
 neighbor 192.168.1.1 remote-as 1
!

R3

interface Loopback0
 ip address 3.3.3.3 255.255.255.0
!
interface FastEthernet0/0
 no ip address
 shutdown
 duplex full
!
interface FastEthernet1/0
 ip address 10.1.1.2 255.255.255.0
 speed auto
 duplex auto
!
interface FastEthernet1/1
 ip address 10.4.4.1 255.255.255.0
 speed auto
 duplex auto
!
router ospf 1
 network 3.3.3.0 0.0.0.255 area 0
 network 10.1.1.0 0.0.0.255 area 0
 network 10.4.4.0 0.0.0.255 area 0
!
router bgp 2
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 2
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 next-hop-self
 neighbor 4.4.4.4 remote-as 2
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 4.4.4.4 next-hop-self
 neighbor 5.5.5.5 remote-as 2
 neighbor 5.5.5.5 update-source Loopback0
 neighbor 5.5.5.5 next-hop-self
!

R4

interface Loopback0
 ip address 4.4.4.4 255.255.255.0
!
interface FastEthernet0/0
 no ip address
 shutdown
 duplex full
!
interface FastEthernet1/0
 ip address 10.3.3.2 255.255.255.0
 speed auto
 duplex auto
!
interface FastEthernet1/1
 ip address 10.4.4.2 255.255.255.0
 speed auto
 duplex auto
!
router ospf 1
 network 4.4.4.0 0.0.0.255 area 0
 network 10.3.3.0 0.0.0.255 area 0
 network 10.4.4.0 0.0.0.255 area 0
!
router bgp 2
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 2
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 next-hop-self
 neighbor 3.3.3.3 remote-as 2
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 3.3.3.3 next-hop-self
 neighbor 5.5.5.5 remote-as 2
 neighbor 5.5.5.5 update-source Loopback0
 neighbor 5.5.5.5 next-hop-self
!

R5

interface Loopback0
 ip address 5.5.5.5 255.255.255.0
!
interface FastEthernet0/0
 ip address 192.168.2.2 255.255.255.0
 duplex full
!
interface FastEthernet1/0
 ip address 10.3.3.1 255.255.255.0
 speed auto
 duplex auto
!
interface FastEthernet1/1
 no ip address
 shutdown
 speed auto
 duplex auto
!
router ospf 1
 network 5.5.5.0 0.0.0.255 area 0
 network 10.3.3.0 0.0.0.255 area 0
 network 192.168.2.0 0.0.0.255 area 0
!
router bgp 2
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 2
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 next-hop-self
 neighbor 3.3.3.3 remote-as 2
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 3.3.3.3 next-hop-self
 neighbor 4.4.4.4 remote-as 2
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 4.4.4.4 next-hop-self
 neighbor 192.168.2.1 remote-as 3
!

R6

interface FastEthernet0/0
 ip address 192.168.2.1 255.255.255.0
 duplex full
!
interface FastEthernet1/0
 no ip address
 shutdown
 speed auto
 duplex auto
!
interface FastEthernet1/1
 no ip address
 shutdown
 speed auto
 duplex auto
!
router bgp 3
 bgp log-neighbor-changes
 neighbor 192.168.2.2 remote-as 2
!

Hello Navraj

First of all, in your topology, you have six routers rather than five as it is in the lesson. But that’s OK, you can still make it work like this. In the following explanations, I will be referring to the topology in the lesson with five routers.

The update-source loopback 0 command will tell the BGP router that for all BGP communications, such as hellos, and update exchanges, the source interface that will be used on the local router is the loopback 0 interface. In other words, if you configure this in the BGP AS 2 of R2, then BGP communications (hellos, updates etc) with be sent from and received by the loopback interface on R2. This is also why when you see the BGP table in R1, you will see that the next hop is 2.2.2.2 which is the IP address of the loopback of R2, which is indeed the next router in the route to the destination.

Secondly, when R4 advertises the destination address of 1.1.1.1 to R5 in the lab topology, it provides a next hop address of 192.168.12.1, which is that of R2. This is because within iBGP, by default, when a route is advertised from one iBGP router to another, the next hop IP address doesn’t change. It remains the first iBGP router that received the info from another AS, namely R2 in this case. So the command next-hop-self must be issued on R4 so that when it advertises the network to R5, it will use its own IP address as the next hop IP address, which is an address known to R5.

My suggestion to you is to first reproduce the topology in the lab with five routers successfully, with the configs as they are shown, and then move on to attempt it with 6 routers.

I hope this has been helpful!

Laz

1 Like

Hi Laz,

It worked thank you, the explanation is really good it is cleared now.
Can you please upload videos as well for BGP Attributes as there is a confusion when we apply route-map, it need to done inside or outside that where I am stuck, It’s bit confusing.

Regards

Hi,
you said "
Technically this is possible…we can run OSPF (or EIGRP) within AS2 and use redistribution between BGP and OSPF. In my example R1 will only have a single prefix so it’s no problem but what if R1 had a full internet routing table? (over 500.000 prefixes since 2014). IGPs like OSPF or EIGRP are not able to handle that many prefixes so you’ll need BGP for this.
"
so the route from BGP will propagte to AS2 , there we re using OSPF . So the full routing table will be added to OSPF database also ?

Thanks

Hello Sims

Best practice dictates that each AS have within it a self contained IGP that learns only of routes within the AS. Any routes from BGP that propagate to AS2 (that are not within AS2) should remain only within the BGP routing protocol and should not be redistributed into the local OSPF/EIGRP IGP running within the AS. Even though you have the IGP in AS2, it should not learn about the prefixes advertised from AS1 and AS3.

Now this is especially true if AS2 is simply a transient network, that is, a network that has no end users, but transmits packets from one AS to another. An ISP distribution network is one such network, where they essentially interconnect end user sites with the Internet. In such cases, there is no need for the IGP to know any routes outside of the AS.

I hope this has been helpful!

Laz

1 Like
R1#show ip bgp
BGP table version is 3, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       0.0.0.0                  0         32768 i
*> 192.168.45.0     192.168.12.2                           0 2 3 i

Hi,
here R1 still does not have route to R3 , So How the packet will routed to R5 ?
Thanks

Hello Sims

R1 does not require a route to R3 in order to reach R5. It only requires a route to 192.168.45.0/24. Once that route is in the routing table, and it knows the next hop, it sends it to the next hop and forgets about it. It is the responsibility of R2 and the IGP configured within AS2 to allow the packet to correctly traverse this AS and to exit it appropriately to reach the destination AS.

When talking about eBGP, think of each AS as one big router. As far as R1 is concerned, what goes on inside AS2 doesn’t matter. Those mechanisms are internal to AS2. Just as long as AS2 knows whats needed to get the packet to the next AS, which it does.

I hope this has been helpful!

Laz

1 Like

Hi,

Could you please also add the information about why IBGP is depends on IGP protocols (ospf & eigrp) to learn the routes.

Hello Krishna

It is often confusing to think that you need one routing protocol (IGP) to allow another routing protocol (BGP) to function. It sounds quite inefficient and redundant. However, that is how BGP works. Think about it this way. Networks are arranged in Autonomous Systems (AS) that are self contained. Within these AS, we have many routers that employ IGPs such as EIGRP or OSPF. All routing within the AS is achieved using IGPs.

eBGP functions as a mechanism for routing from AS to AS, and it is only the routers on the edges of each AS that participate in eBGP. eBGP requires a connection between two routers on the edges of two different AS so that routing can take place from AS to AS. So eBGP takes care of routing from one AS to another.

Now iBGP is the mechanism by which these edge routers learn about the routes internal to an AS so they can be advertised to remote AS via eBGP. But this info has to reach these edge routers somehow. This is done using iBGP. However, iBGP does not take care of routing within the AS, but it does take the information from the IGP and distributes it among iBGP routers so they are fully aware of all the networks within the AS.

Remember that iBGP peers need not be directly connected, and peering forms only if there is a route between the peers. These routes are provided only by the IGP (or static routing).

I hope this has been helpful!

Laz

1 Like

Hello NetworkLessons Crew and Readers,

Two things Rene:

  • First wanted to point out, as a friend, you have a grammatical error in this lesson in this sentence,

Are we done now? Almost…there’s one more thing I want to learn you about the IBGP neighbor adjacencies…

  • Second thing is, when R1 is trying to reply to the 192.168.23.0 subnet, you advertise 192.168.45.0 on R5 as the fix for the failed pings from R3. Why did you do it this way and how does it work?

Thanks,
Austin

1 Like

Hello Austin

Thanks for pointing out the typo, I’ll let Rene know and he’ll have that fixed. It’s always helpful when users point these out so we can provide the best quality material for everyone. Thanks for helping out!!

As for your second question, the original connectivity test that was made was a ping from R5 to 1.1.1.1 on R1. This is the communication that initially failed. So in order to troubleshoot this, Rene went to R3, and R2 to determine if from those routers, 1.1.1.1 is accessible. The original test is not connectivity from R1 to the 192.168.23.0 subnet.

Now 1.1.1.1 was “pingable” from R2 but not from R3. What was the reason? It was determined that R1 did not know how to reach the 192.168.23.0/24 subnet. So the ping reached R1, but R1 didn’t know how to reply to that destination of 192.168.23.3.

Now we don’t need R1 to be able to know how to get to 192.168.23.0/24, but this gives us a clue as to why the ping from R5 didn’t work. The reason the ping from R5 didn’t work was because R1 didn’t know how to reach the 192.168.45.0/24 subnet which contains the source IP address of the ping. So for pings from R5 to 1.1.1.1, they reached R1 but didn’t know how to get back to 192.168.45.5.

The solution was to have R5 advertise this network using BGP. Via BGP, R1 learns this subnet, and can now respond to the ping.

I hope this has been helpful!

Laz

1 Like