EBGP Multihop


(Brian C) #51

I am just reading through first time so all of this is new to me and I am doing good to just get the high level parts. However, saying all that I have started to read all of these pages of post even those I don’t understand, and I have to say Andrew and Rene you guys are intimidating on your knowledge. I figured even if I don’t understand all the posts later some of the things here may ring a bell or be in the back of my mind. Hopefully one day this stuff will start to register like the CCNA stuff did!


(Networklessons Admin) split this topic #52

19 posts were merged into an existing topic: EBGP Multihop


(Brian C) #53

The conversation with Hussein is very good conversation but its a bit muddled.

I think basically an example was used that was kind of special case to demonstrate perhaps some commands and partial thought process.

I also wondered about the disabled connected and the reason I wondered about the disabled connected check was that I did not think the loop back was seen as directly connected because I didn’t think the loopback was seen.

The reason I didn’t think the loopback was seen was because it counted the loopback as a hop (is that wrong word?) meaning it incremented the TTL by 1 which added up to a total of 2. so I thought once you fixed that then it could show up if you had the following commands required by BGP which I thought was the following:

R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 remote-as 2
R1(config-router)#neighbor 2.2.2.2 update-source loopback 0
R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 2

So to me using the disabled connected command was meaningless in regards to that. I think you was trying to point out something by using it but I don’t know what it was you was trying to get at. You finally said it was not needed and that makes sense to me in how I understand how things work. In addition, it was just where you was going with it in the first place that was not clear to me.

hope that’s clear but its hard to communicate some of these advanced granular thing as you know because even harder to try and write the lessons to convey these things I am sure.

======================================================================

Next question:

Right now I am thinking BGP unlike IGP routing protocols and also unlike static routes does not supply connectivity. Let me give some examples hopefully they help communicate my thought process.

the reason BGP works on directly connected routers is only because directly connected routes show up in the routing table minus loop back which as mentioned above has a TTL issue that has to be modified and then you can add as neighbor.

So in some ways using directly connected routers does not pound in the issue of the truth as I believe it. you have to have routes in place to run BGP over or it has to be directly connected otherwise they don’t know where to send crap because they don’t know the road to where they need to go.

This is confusing because every other thing you setup when you set it up that is the road but not with BGP as I understand it. So if not directly connected you need either a routing protocol or static routes to provide a road for BGP to run over.

Is that connect thinking? Its not really stated explicitly anywhere in the reading and perhaps because its not easy to state that in a few words as I just drummed on for half a page trying to ask the question.

If I had to sum up everything I just said in a few words it would be the following and I will quote myself(can people quote themselves?? lol)

BGP will only run over directly connected links or run over additional routing protocol or static route. In a very broad and loose sense it works a bit like a VPN running over something else, or as OSPF running over frame replay. It has to has to know where its going! BGP by itself does not provide itself a road map over Ethernet as do other IGP and static routes.

even that is not great wording because BGP runs but does not provide end to end connectivity for things to get from point A to point B.

If I used an analogy I would say:

BGP is like driving your car on a highway without any road signs or directions you simply don’t know how to get where you need to. You must use GPS(a routing protocol ) or they have to put in road signs (static routes). Once that’s done you can get to where you need to go and also know how to get back home where you started.

could add the reason you don’t need routing protocols or static routes for directly connected is basically same principle:

if you can see the store from your house you don’t need maps because you can see all the information right there both to reach it and to return from it.

I didn’t mention it my main assertions as I figured most at this level probably understood that.

Is my thinking correct on this?


(Lazaros Agapides) #54

Hello Brian

I’m not sure if I am answering your question, but I’m going to attempt to answer the summary question you quoted in your message. For reference, here is the quote I will be commenting on:

The interesting thing about BGP, and this is one of the major areas in which it is different from IGPs, is that in order for two BGP routers to communicate, they must have connectivity. (duh! :stuck_out_tongue: ), What I mean is, neighbour relationships are configured manually, and neighbours don’t have to be physically adjacent. This means that routing must be established in some form or another (static route, IGP) between the BGP neighbouring routers in order for them to exchange BGP routing information. One might say “well if we have to run an IGP to get BGP to function, what’s the point?” I stress that routing between the two routers must be established for the exchange of BGP routing information, and NOT for the transfer of user data. Once BGP neighbourhoodship has been established, BGP routes can be exchanged and the network can converge for the purpose of transferring user data.

I hope this has been helpful!

Laz


(Chris N) #55

I’m still not clear on why the second scenario requires multihop when the neighbours are directly connected.

Are you saying that when traffic is sourced from and to a loopback, it is effectively taking 3 hops? (2 of which are virtual within the routers).


(Lazaros Agapides) #56

Hello Chris

Essentially, if you use the FastEthernet interfaces to interconnect BGP, then the routers are considered directly connected and you wouldn’t need to use multihop. However, because we are using two redundant links to connect the two routers, if we use the fastEtherent interfaces, and one link goes down, then the BGP connection between them will also go down, thus rendering the redundant link unusable. This is why it is preferable to use the loopback interfaces. However, If you use the loopback interfaces, you can see that these loopbacks are not directly connected to each other and thus require an additional hop between them. This is why multihop is necessary. This is reinforced by the fact that a value of 2 is used for the TTL which would be the number of hops, counting each router as one hop.

I hope this has been helpful!

Laz


(Chris N) #57

Hi Laz

So you are saying a TTL of 2 is required for 2 directly connected routers to reach each other, if both are using loopbacks as their update source.

In this case then, is “disable-connected-check” effectively useless in most scenarios as it’s best practise to use a loopback as an update source? As it doesn’t modify the TTL value. “disable-connected-check” will only work between 2 directly connected routers who are using PHYSICAL (not loopback) IP values as their update-source?


(Lazaros Agapides) #58

Hello Chris

Default eBGP operation checks the eBGP neighbour statement against its list of directly connected neighbours. Since the loopback does not fall into the common subnet, the eBGP neighbour relationship doesn’t attempt to form by default.

For this reason, you must configure eBGP multihop whenever the eBGP connections are not on the same network subnet, such as the above scenario.

Alternatively, the disable-connected-check overrides this behaviour and allows the attempt to occur, even if TTL=1 by default. Note: This does not override the TTL behaviour of 1 hop for eBGP but just allows an exception for the loopbacks of directly connected eBGP routers.

The disable-connected-check is not necessary if the neighbor X.X.X.X ebgp-multihop Y command is used. In other words, the disable-connected-check is used for peering between eBGP loopbacks on directly connected neighbours where the TTL value = 1.

So essentially you are correct.

I hope this has been helpful!

Laz


(Deepika A) #59

why are we using “neighbor 1.1.1.1 ebgp-multihop 2” when neighbors are directly connected ?
I am talking about the scennario

R2(config)#router bgp 2
R2(config-router)#neighbor 1.1.1.1 remote-as 1
R2(config-router)#neighbor 1.1.1.1 update-source loopback 0
R2(config-router)#neighbor 1.1.1.1 ebgp-multihop 2

(Lazaros Agapides) #60

Hello Deepika

This question has been addressed in a couple of posts above. Take a look at this post and the subsequent answers. If you still have questions, please feel free to ask them!

I hope this has been helpful!

Laz


(sims) #61

Hi,
What prefix you are talking here , can you give an example
“Even though R1 and R3 are now neighbors, having a non-BGP in router in between R1 and R3 is a bad idea. R1 and R3 might exchange prefixes through BGP but once packets reach R2, it will have no clue where to forward these packets to…”
Thanks


(Rene Molenaar) #62

Hi Sims,

It could be any prefix that is advertised on R1 or R3. For example, let’s say you add a loopback interface on R1 with IP address 1.1.1.1/24 that you advertise in BGP.

R3 will be able to learn this prefix from R1, but think of what happens when R3 tries to send a packet to 1.1.1.1.

The destination is 1.1.1.1, the packet ends up at R2 which has no idea where 1.1.1.1 is and so the packet will be dropped.

Rene


(Walid A) #63

Hi Rene,

thanks for your wonderful explanation, I have a question regarding the use of “update-source loopback0” command.

when I configured the neighbors without the “update-source loopback0” command then added this command on one router only, I found that the neighbor-ship came up although I didn’t configured the other router with the “update-source loopback0” command. why this happen?

thanks
Walid


(Lazaros Agapides) #64

Hello Walid.

In order for a BGP neighbourship to be established, the only prerequisite is to have IP connectivity between the source IP addresses of the two routers in question. Whether that source is the looback address or the IP address of a physical interface makes no difference.

Refer to the diagram from the lesson:


Let’s say you configured the update-source loopback and the ebgp-multihop 2 on R1. The source for BGP communication on R1 is the L0 interface. The source for BGP communication on R2 is still on one of the physical interfaces, say, Fa0/0.

BGP neighourship has been established between the L0 interface on R1 and the Fa0/0 interface on R2, which is completely valid. Once you apply the same command on the other side, the neighbourship will occur between the loobacks.

I hope this has been helpful!

Laz


(Walid A) #65

Hello Laz,

I’d like to thank you for your explanation, but I need to understand the difference between two situations:
1- I didn’t apply the update-source lo0 command on both routers but they are reachable via IGP, why the BGP session didn’t formed if the case is to find a route to the loopback IP?
2- I applied the update-source lo0 command on one router only and the session came up although in the first and this situation the Loopback IPs were reachable for both routers, so what makes the BGP neighborship come up with the physical interface although I configured the neighbors to form neighborships with the loopbacks only?

Thanks
Walid


(Lazaros Agapides) #66

Hello Walid.

Thanks for the clarification, I will attempt to answer below.

In the previous post I mentioned that the only prerequisite for two BGP neighbours to form a neighbourship was that the IP addresses used as the BGP sources should be reachable via an IGP (or static routing). However, this is one more requirement and that is that they be only one hop away from each other. If they are more than one hop away from each other as is the case if you use the L0 addresses, then you must have the ebgp-multihop X command where X is the number of hops between the BGP source IP addresses. Now because the two loopback addresses are not directly connected but are two hops away from each other, X must be 2, and only then will a neighbour relationship form.

Unlike IGPs, when BGP forms a neighbour relationship, it only forms in one direction. In order to understand what I mean, take a very simple topology such as the following:

Imagine you enable BGP on both routers and you put in the following command on the R1 router:

neighbor 192.168.12.2 remote-as 2

This will create a one way BGP neighbour relationship between R1 and R2. This means that if you enter the show ip bgp neighbors command on R1 you will see the neighbour relationship. If you go to R2 and enter the same command you will see no neighbours. Neighbours on the R2 router will appear once the following command has been entered on R2:

neighbor 192.168.12.1 remote-as 1

Once this is complete, then there is a mutual neighbour relationship.

The same thing occurs when you implement the topology in the lesson. When you put in the update-source lo0 command on one router, the neighbour relationship comes up in only one direction. If you go to the other router, you won’t see any neighbours until you put in the corresponding command in that router as well.

I hope this has been helpful!

Laz


(Walid A) #67

Hello Laz,

thanks for your detailed explanation, but my question is related to the last point you mentioned

The same thing occurs when you implement the topology in the lesson. When you put in the update-source lo0 command on one router, the neighbour relationship comes up in only one direction. If you go to the other router, you won’t see any neighbours until you put in the corresponding command in that router as well.

I have tried this again in a lab and the BGP neighborship formed successfully on both sides, although the update-source lo0 is configured from one side as shown below:

Router 1 side

R1#sh run | sec bgp
router bgp 1
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 neighbor 2.2.2.2 remote-as 1
 neighbor 2.2.2.2 update-source Loopback0
R1#sh ip bgp summary | b Nei
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4            1      10      12        2    0    0 00:05:54        0

Router 2 side

R2#sh run | sec bgp
router bgp 1
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1

R2#sh ip bgp summary | b Nei
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4            1       5       6        5    0    0 00:01:55        1

and my question is why the bgp neighborship forms before adding the update-source lo0 on the second router although the neighbor statement is configured with the loopback ip address of the peer router?

Thanks
Walid


(Rene Molenaar) #68

Hi Walid,

This will work as long as R1 is the router that initiates the TCP connection for BGP. It uses the IP address from the update-source command as the source (1.1.1.1) to initiate the connection and 2.2.2.2 as the destination. R2 responds with its 2.2.2.2 address.

When R2 initiates the connection, it uses the IP address on the interface that faces R1 (192.168.12.2) which doesn’t match the neighbor command on R1.

A quick way to verify that R1 is the TCP client is to look at the port numbers:

R1#show ip bgp neighbors | include port:  
Local host: 1.1.1.1, Local port: 28823
Foreign host: 2.2.2.2, Foreign port: 179
R2#show ip bgp neighbors | include port:
Local host: 2.2.2.2, Local port: 179
Foreign host: 1.1.1.1, Foreign port: 28823

You can see this in action in wireshark. Take a look at this capture:

https://www.cloudshark.org/captures/96e0d64cc32a

I did a clear ip bgp * on R2. In packet 6, you can see that R2 did an attempt from 192.168.12.2 that R1 refuses in packet 7. When R1 initiates it from R1, it works.

Hope this helps!

Rene


(Durga M) #69

Rene,
Is it work if you use network command to advertise Loopback address at both pee routers under BGP instead of using static routes. Please explain in brief.
Thank you in Advance.


(Lazaros Agapides) #70

Hello Durga

The static routes to the loopback addresses are used in order to be able to establish BGP neighbor adjacency. If you don’t have neighbor adjacency, then even if you add the network command with the loopback addresses, the router will not share this information because there is no BGP neighbor.

The static routes in this scenario are necessary in order to establish BGP neighbourhoodship. These routes could be learned via an IGP as well, but for the sake of simplicity, it was done with static routes here.

I hope this has been helpful!

Laz