Few BGP questions

[mandeep62]

Hi Everyone,

I have a few questions regarding BGP below:

Q1) Why do we have IBGP?

From what I understand is that inside a big ISP cloud, there could be many routers that will be under one AS and learning information from IGP protocols and hence, connecting to other AS through EBGP to share all those routes to another ISP.

I'm not sure if my understanding is correct.

Q2) Why IBGP requires a full mesh between all the routers in an AS?

Q3) What's the advantage of using router reflector and BGP conferderation?

I understand to create a partial mesh. Is it to save CPU resources? Any other reason

Q4) What mechanism IBGP uses to prevent routing loops? Is it possible to observe the behavior of routing loop in IBGP through a topology or so?

Thanks all.

[Francesco Molino]

Hi

Here are answers to your questions:

Q1. We use ibgp for more scalability, flexibility and enforcement. You can be more specific when you need to filter prefixes than IGP.

Q2. You need full mesh to get a proper routing information propagation. Ibgp loop prevention is based on split-horizon which means a route learned from a ibgp session isn't advertised towards other ibgp neighbors.

Q3. Confederation and route reflector have the same minding.

Q4. Already answered.

[Joseph W. Doherty]

In addition to what Francesco already posted for Q1, yes iBGP is used to pass BGP information between routers internally, but there can be internal routers that only run an IGP. I.e. not all the internal routers need to run BGP, as iBGP routers don't need to be directly connected.

The forgoing often allows the usage of "less powerful" routers, for internal routing (and not running BGP) , assuming we're using BGP to pass around copies of the Internet route tables.

Q3 also cuts down on BGP configuration size and the number of peering relationships. A BGP route reflector is somewhat similar in concept to an OSPF DR and non-DR/BDR on a multi-access network.

[Richard Burts]

There is another aspect of BGP that may help explain the requirement about full mesh between IBGP peers. If a router is running BGP and has some external peers (EBGP) and some internal peers (IBGP) there is a difference about how it forwards prefixes leaned from its peers. Any prefix leaned from an EBGP peer will be advertised to all of its peers (both EBGP and IBGP) subject to any filtering that has been configured. But prefixes learned from an IBGP peer are advertised only to EBGP peers and not to other IBGP peers. Perhaps a simple example might help. Think of a situation where an AS has 3 routers running BGP, R1, R2, and R3. Assume that each router has at least one external peer, and assume that R1 peers with R2 (but does not peer with R3), R3 peers with R2 (but does not peer with R1). Now assume that the external peer with R1 advertises network 200.100.50.0 to R1. R1 advertises the network to R2. The important question is whether R3 will learn about that network? As described here R3 does not learn the network. To solve this issue R1 must peer with both R2 and R3, and R3 must peer with both R2 and R1 (which creates the full mesh that solves the problem).

HTH

Rick

[Joseph W. Doherty]

"There is another aspect of BGP that may help explain the requirement about full mesh between IBGP peers."

Hopefully it's already understood, but what Rick is explaining about the iBGP full mesh requirement is only true when you're not using a confederation or route reflector.

[Richard Burts]

The original post asked 4 questions. My response focused on answering #2 which asked about full mesh. I contemplated discussing Route Reflector and Confederation and decided to simplify and focus on one aspect. Joseph has responded about #3 which was about Route Reflector and Confederation and the fact that they provide an alternative which does not require full mesh.

These are enhancements added to BGP to relax the requirement for full mesh. So why might we want an alternative to full mesh? If we have full mesh then every router must be neighbor with every other router. If there are N number of routers and each router is neighbor with every other router in the AS then in mathematical terms this is N * (N - 1) and from this we can see that the number of neighbor relationships depends on N square. Any relationship that involves N square does not scale well. For example with 2 neighbors there are only 2 * 1 = 2 neighbor relationships. But with 4 neighbors there are 4 * 3 = 12 neighbor relationships, and with 10 neighbors there are 10 * 9 = 90 neighbor relationships. What if an ISP has 20 routers that need full mesh? This helps explain why we want to find alternatives to requirements for N square. For example OSPF  forming neighbor relationships on a broadcast network would involve N square. And so OSPF implements DR and BDR to get around the requirements for full mesh. In similar approach BGP has implemented Route Reflector and Confederation to get around the requirement for full mesh in IBGP neighbors.

HTH

Rick

[mandeep62]

Thank you, Richard. To sum it up, Any router running IBGP which learns any route from external peer will not advertise the routes to other IBGP speakers unless we have full mesh. Why do we have this behavior?

Between, Do you mind If I post more questions about BGP here? I'm just new to learning BGP.

Thanks again.

[Francesco Molino]

This is called split horizon.
I've found this post that explains it:
http://www.itcertnotes.com/2012/01/bgp-split-horizon-and-full-mesh-ibgp.html?m=1

[mandeep62]

I have created a small topology which is attached below. I'm running R1,R2 & R3 in AS 1 and created full mesh. R3 is also connected to an external peer R4 which is in AS2. From AS2, I advertised a loopback address 4.4.4.4.

Now, R3 is learning 4.4.4.4 from an external peer and hence, advertising that route to it's internal peers without changing the next-hop to the internal peers R1 and R2. That was possible because of full mesh, otherwise R3 wouldn't have advertised that route to other peers.

Now, to change the next-hop, I used next-hop-self command on R3 which is the transit AS router. I was able to change the next hop address for network 4.4.4.4 on internal AS routers R1 and R2.

If I try to reach 4.4.4.4 from internal routers R1 and R2, I cannot reach it. The loopbacks are created on every router.

Below is the output of few commands:

R3#show ip bgp sum

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4            1      38      39        2    0    0 00:32:22        0
2.2.2.2         4            1      81      85        2    0    0 01:09:43        0
192.168.4.2     4            2     102     100        2    0    0 01:28:01        1

R2# show ip bgp

     Network          Next Hop            Metric LocPrf Weight Path
 *>i 4.4.4.4/32       3.3.3.3                  0    100      0 2 i

R1#     Network          Next Hop            Metric LocPrf Weight Path
 *>i 4.4.4.4/32       3.3.3.3                  0    100      0 2 i

R2#     Network          Next Hop            Metric LocPrf Weight Path
 *>i 4.4.4.4/32       3.3.3.3                  0    100      0 2 i

R2#ping 4.4.4.4

Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
.....

R1 configuration

router bgp 1
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 1
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 3.3.3.3 remote-as 1
 neighbor 3.3.3.3 update-source Loopback0

R2 Config

router bgp 1
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 3.3.3.3 remote-as 1
 neighbor 3.3.3.3 update-source Loopback0

R3 Config

router bgp 1
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.1 next-hop-self
 neighbor 2.2.2.2 remote-as 1
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 next-hop-self
 neighbor 192.168.4.2 remote-as 2
 neighbor 192.168.4.2 next-hop-self

The OSPF is configured in AS1 correctly.

Am I doing something wrong?

Thanks again.

[Richard Burts]

Thank you for posting the diagram which is quite helpful. Your BGP configuration is simple and should be adequate for what you are trying to test. And the output of show ip bgp on both R1 and R2 does show that the route is being advertised by BGP. So that part is working. You mention that OSPF is configured but do not tell us any detail about it. And you do not show the output of shop ip route from R1 or R2. 

So what might be the problem here? Looking at the output of show ip bgp we can see that the next hop is 3.3.3.3. So perhaps one question might be whether 3.3.3.3 is reachable from R1 and R2. Since the neighbor relationship is successful I believe that we can assume that 3.3.3.3 is reachable. So what else might be the problem? 

If we think about how ping works there might be a hint about the problem. Ping works by sending an ICMP packet to the destination and the destination sends an ICMP response. It looks like you probably do have a route to the 4.4.4.4 destination in both R1 and R2 so probably the ping request does get to 4.4.4.4. But does R4 have a route to get back to R1 or R2? Check the routing table on R4 and see if it has a route to get back to R1 or R2? 

HTH

Rick

[Richard Burts · Accepted solution]

The way that you phrase this is not quite right "Any router running IBGP which learns any route from external peer will not advertise the routes to other IBGP speakers unless we have full mesh". In the original design of the BGP routing protocol the assumption was that there would be full mesh and another assumption was that when an IBGP router had learned a route from an IBGP peer that it would not advertise that route to another IBGP peer. Route Reflectors and Confederations were added to BGP later as a way to relax the requirement for full mesh. 

The example that I suggested was an illustration of the normal BGP behavior. R1 has 1 EBGP peer and 1 IBGP peer, R3 also has 1 EBGP peer and 1 IBGP peer, while R2 has 1 EBGP peer and 2 IBGP peers. R1 learns a route from its EBGP peer an advertises it to R2. R2 has learned the route from an IBGP peer and does not advertise that route to R3. The only way for R3 to learn that route is for R3 to be a neighbor of R1. When every router running IBGP is a neighbor with every other router running IBGP in that AS then this is full mesh.

When an IBGP router is neighbor to only some (but not all) IBGP routers then this is partial mesh and for this to work you need something like Route Reflector or Confederation. 

You are certainly welcome to ask additional questions about BGP. It is a complex protocol and it certainly takes a while to become familiar with it.

HTH

Rick

[mandeep62]

Thank you so much for the explanation. If you could look at the topology I posted above, and clear my doubt, it would be great. I don't understand why I'm not able to reach the destination in it. Thanks again.

[paul driver]

Hello

---

@mandeep62 wrote:

Hi Everyone,

I have a few questions regarding BGP below:

Q1) Why do we have IBGP?

From what I understand is that inside a big ISP cloud, there could be many routers that will be under one AS and learning information from IGP protocols and hence, connecting to other AS through EBGP to share all those routes to another ISP.

---

If you have a BGP AS with multiple rtrs within it, And some of those rtrs are connecting towards external AS's and the rest just connecting internally between each other, Then to provide a updated view of all egress/external routes from the ibgp/ebgp rtrs to all the internal rtrs within this single AS,  The best way to accomplish this advertisement is to use the same inter AS routing protocol (BGP) but have those internal routers to be IBGP peers with each other and with ibgp/ebgp rtrs 

As for originated interior routes within the AS,  The running of an Igp process internal to the AS will provide an updated view of all these routes