BGP Essentials

Theory and Practice Origin

Weight

Next-Hop

MED

AS-Path

Local preference
LIST OF CONTENTS

BGP Introduction _____________________________________________________________________1

 ii

BGP Introduction______________________________________________________________________1

BGP Packets__________________________________________________________________________2

BGP Establishment Process______________________________________________________________3

BGP Use Case ________________________________________________________________________5

How BGP manages update______________________________________________________________6

BGP Rule____________________________________________________________________________8

BGP Route Reflector__________________________________________________________________12

BGP Best Path Selection_______________________________________________________________15

BGP Lab____________________________________________________________________________22

This material is taken from the advanced IP routing course presented by Mr. M Aditya Hananto in the
Indonetworkers Community forum. This note contains material about the Basic Theory of Border
Gateway Protocol (BGP) along with a simple lab.

Course in bahasa :
https://www.youtube.com/watch?v=_VQQGzL8d5Y&list=PLkiWVEWnNVJ8AzGvR5dudpTjewslVpPrE&ind
ex=5
 1

BGP Introduction

BGP is an exterior gateway protocol that performs routing between autonomous systems.

Figure 1 typical BGP networks

BGP can be said to be the backbone of the internet, if BGP routing has problems then the internet can be
chaotic, config errors in BGP can cause important prefixes on the internet to be unreachable, this shows
how important the role of BGP is on the internet. The internet consists of many autonomous systems, for
simplicity, for example in the following example there are AS 1, AS 56, AS 7, AS 91 on the internet, in one
AS there are many routers, there are many networks in one autonomous system. The routing protocol
used by routers in the internal AS uses IGP, while between ASes uses the exterior gateway protocol,
namely BGP. We will see how the characteristics of BGP compare to IGP.
 2

BGP Packets

BGP Packet types Description

Keep alive Keep alive aims to keep neighbors connected. This packet is exist in every
routing protocol, in OSPF and EIGRP this packet is called hello. hello is used for
acquaintances as well as keep alive. In eigrp hello timer is once every 5
seconds, in OSPF the default is once every 10 seconds while in BGP it is once
every 60 seconds or one minute. so every minute BGP sends a hello or keep
alive message.

Open This packet contains BGP attribute information on the router. For example,
what number does the router belong to, according to the name ”open”, which
is for opening when you first want to become a neighbor. After establishing a
connection, this open message is used for negotiation, if the BGP parameters
of a router are different from the router next to it, then it cannot be a
neighbor.

Refresh This refresh is used when a router requests an update from another router. By
default, BGP will not send updates if there is nothing. For example, if there is a
router that needs an update for some purpose, if you wait, it is not clear when
there will be a change in topology. Instead of waiting, it is better to send a
refresh message, so the router asks its neighbors to send an update.

Update Updates contain prefixes known by a router that are forwarded to its neighbors
along with BGP attributes such as AS-Path, metrics, origin and so on.

Notification Notification is a BGP packet that is sent if an error occurs, for example there is
a parameter mismatch, there is something that doesn't match between
neighbors, then the neighbor will send a notification that might says “we don't
match, so we can't continue the BGP neighbor adjacency process”.
Table 1 BGP packet types
 3

BGP Establishment Process

BGP States Description

Idle Idle is a condition when there is no BGP connection at all.

Connect Connect is a condition when a router tries to initiate a TCP three way
handshake to another router. In contrast to the interior gateway protocol
which does not use TCP, IGP only sends hello which is connectionless. In IGP
there is no dedicated connection like TCP. Because BGP uses TCP to establish
neighbors with other routers, this allows 2 routers that are not directly
connected still be able to form BGP session because the connection is based on
Layer 4 TCP, its not like IGP which the connection is based on Layer 3. BGP uses
port 179.

Active active, this is the condition when the three way handshake is established or
connected, the next step is to send an open message to another router, then
the parameters of the two routers will be compared for suitability, if the
parameters match, then proceed to the next state, namely open confirm

OpenConfirm open confirmation is a condition when both routers have received the open
message and both the open message parameters are in accordance with each
other.

Established When established, keep alive exchanges between neighbors are smooth and
both routers also send and receive update messages.
Table 2 BGP neighbor establishment processes

The TCP connection in BGP is established continuously, not after the BGP session is established, the TCP
connection is torn down. so the TCP connection remains connected. If TCP breaks, the BGP neighbor
relationship also breaks. The second difference in BGP compared to IGP is, in BGP neighbors must be
defined manually, similar to if we want to make a TCP connection to a web server, for example the web
server uses http or https, then we have to define whether we want to connect to the IP http server. the
port is 80 or 443. So in BGP, the neighbors have to be defined manually, whereas in IGP we don't
configure IP neighbors, IGP uses multi cast addresses, eigrp multi cast address is 224.0.0.10 then in OSPF
There are 2 multicast addresses 224.0.0.5 for OSPF routers then there is also 224.0.0.6 for Designated
Routers (DR). So in BGP the neighbor must be defined manually, if it is defined manually it means
unicast, so in BGP it is unicast, not multicast.

An example of determining the best path in BGP using one of the BGP attributes, namely AS-Path.
 4

Figure 2 Best Path Selection using shortest AS-Path

Next, lets take a look at the topology above. For example, we are currently in AS 100, we want to go to
network 10.11.12.0/24 which is behind AS 400, all edge router on each AS’s are sending and receiving
BGP update from its eBGP neighbor. Including AS 400. in BGP update, one of the attributes that is sent is
AS-Path, which is the enumeration of AS that is traversed to the destination. The router on the AS 400
will send a BGP update to another AS regarding the 10.11.12.0 prefix on the AS 400. If the update is sent
to an AS, the AS Path will be prepended (added at the front). When AS 100 wants to go to prefix
10.11.12.0 there are 2 paths, namely via AS 200, with AS Path 200 300 400, and the second path is via AS
500 with AS Path 500 400. When the default condition, means we don't manipulate the BGP routing
configuration, then BGP will choose the shortest AS-path via the bottom route. If you look closely, this
shortest AS Path selection scenario is similar to the RIP routing information protocol. In RIP, when you
want to determine the best path, what you look at is the number of routers traversed to the destination
(hop count), whereas in BGP it is not the number of routers but the number of AS traversed to the
destination. So in one AS there could be hundreds of routers or there could be another AS that only
contains 5 routers and both conditions are considered the same, because one AS is still one AS no matter
how many routers are there. In BGP it doesn't look at each router or per hop, but what it looks at is per
AS, so one AS with many routers and one AS with few routers is the same as one AS. This is an example
of determining the simplest best path in BGP.
 5

BGP Use Case

In what condition BGP is used?

Figure 3 Typical BGP Implementation on Service Provider

One of the conditions that makes us use BGP is when we become the transit AS. Let's say AS 200 is a
transit AS that connects AS 100 with AS 300 and 400 on the right. an example of AS transit is an ISP
service provider. When a customer wants to go to the AS on the internet, they need to go through AS
200.

Figure 4 Typical BGP Implementation on Multihomed Customer

 6

Apart from transit AS, a scenario that requires BGP is when there is a customer connecting to two ISPs.
For example, AS 200 as the first ISP and AS 500 as the second ISP. When a customer wants to go to the
internet, he can go via the top route or he can go via the bottom route. So mostly BGP is used by transit
AS and multihome customers.

How BGP Manages Update?

Let's see for example, if we have a simple topology like this, A is AS 1500, B is AS 2610. A and B are not in
the same AS, if the AS is different then this is called external BGP, so external BGP is a BGP session that is
formed between two different autonomous system. C is in the same AS as B, which is in AS 2610, so B
and C are internal BGP. Then D is also still in AS 2610 so C and D are internal BGP. E is already in a
different AS from D, that is AS 4530, between D and E this is external BGP.

Figure 5 BGP Router send an update to its eBGP neighbor

Okay, now when A sends an update to B, B enters it into the BGP routing table. 10.1.1.0/24 the nexthop
is A, the administrative distance if it comes from external BGP (from outside the US) then the AD is 20
(beating many IGP ADs, OSPF AD 110, eigrp AD 90).

Figure 6 BGP router forward update from external to its iBGP neighbor

After B receives the update from A, B sends the update to C, in C it is also noted the BGP 10.1.1.0/24
who the nexthop is and what the administrative distance is. Router C receives 10.1.1.0 BGP Update from
B. The question is who is the nexthop listed on C and then what is the administrative distance. OK, the
answer is A become the next hop and the administrative distance is 200 (administrative distance is 20
from external BGP but from internal BGP AD is 200). We see that by default BGP consider the nexthop is
an external neighbor, BGP doesn’t consider its internal (iBGP) as the nexthop, so here the nexthop is still
 7

A, still external BGP. when a router sends an update from eBGP to an internal neighbor (iBGP), the
nexthop does not change, the nexthop remains external.

Figure 7 How IGP manages update

This is what differentiates BGP from IGP. When we study IGP, whether it is eigrp or OSPF when A sends a
Routing Update (RU) to B, then the next hop recorded at B is A (which gave it to A), and then when B
gives it to C, the nexthop is B because the routing update comes from B, if C sends the routing update,
then the nexthop is C and so on. Basically, on the IGP, the next hop is who sends the routing update.

.
Figure 8 How BGP manages update

But in BGP, this rule does not apply. If A sends an update to its eBGP neighbor which is B, then B will
record its nexthop as A. However, when B forwards the update received from A to its iBGP neighbor, that
is C, then the nexthop recorded on C remains A, because A is its external nexthop, but this BGP behavior
can be changed when we configure something called next-hop-self. This is optional, yes, if we configure
nexthop self on router B, then here the nexthop is b, but if we talk about default, the next hop is an
external neighbor, aka external BGP. Next, now we look at D. Previously, router C had received updates
from B. The question is, did router D receive BGP updates from C?
 8

BGP Rule

Figure 9 BGP rule

If we receive an update from an external neighbor, we can give the update to internal or external
neighbors, aka whoever we can give it to. If we receive an update from internal BGP from a neighbor in
the same AS, then we can forward it to the external neighbor (eBGP) but it cannot be given to another
internal neighbor, this is not allowed, so in BGP there is one rule, there is only one prohibition that is not
allowed. that is, “if we receive update from internal BGP and then give it again to another internal BGP”.
This is the only thing that is not permissible, apart from that, it's okay, external to internal, internal to
external, external to external is okay.

10.1.1.0/24

Figure 10 How does BGP Rule works

So if we look at C, router C receives updates from B which is internal BGP, so can it give it to D? it's not
allowed because C and D are internal BGP again, so D doesn't receive BGP Updates from C. If D doesn’t
receive BGP Updates from C then D doesn't know the contents of the updates sent by B to C, so that D
also knows, then between B and D need to form an iBGP neighbor too. You know, B and D are not
connected, can B and D be iBGP neighbors to each other? The answer is yes, iBGP allows two neighbors
not to be directly connected as long as they are reachable. How is it reachable? Yes, of course you can,
because in one AS there is an IGP. For example, if we use OSPF, if in AS2610 we already have OSPF then
B-C-D is reachable. So later B sends an update to D via C but C only forwards it, only forwards the BGP
update from B to D (not read by C) if B and C have their own update so B gives the update to C then B
 9

sends the update to D, So B sends two updates and forms two iBGP sessions, one for C and the other for
D. So later on, router D will record 10.1.1.0/24, the nexthop is A and then has AD value of 200.

10.1.1.0/24

Figure 11 How does BGP Rule works (2)

After D receives the update, then D forward its update to E, because D and E are using eBGP, E can
receive updates from D, E will record the BGP update for the prefix 10.1.1.0/24, the next hop is D, then
AD=20 (update from eBGP). Now the question is, because the BGP table in C and D recorded the next
hop to go to 10.1.1.0 is A, how do C and D know about A, while C and D are not directly connected to A,
B is directly connected to A, If B goes to A, there's no problem. What about C and D? How does C or D
know how to get to A?

Figure 12 Solution to overcome BGP rule limitations

This can be achieved by A being advertised by B, so B tells C about A using IGP, for example OSPF, so later
on C it will list the OSPF destination to A. The next hop is B if the OSPF administrative distance is 110.
Then by C this information is passed on. continue to D using OSPF again, OSPF to A, the next hop is C. So
so that C and D know how to get to A, C and D are told to use IGP by B in a chain, so that's it. This is just
an example, the IGP doesn't have to be OSPF, other IGPs are also allowed, but if we talk about service
providers in Indonesia, most of them use OSPF. Now the condition has converged, from router E you can
go to 10.1.1.0/24. So we can say that AS 2610 is a transit AS because it connects AS 1500 with AS 4530.
From here we see that there is another difference with IGP, in BGP the name nexthop is not necessarily
 10

the provider of updates, because for BGP, the default nexthop is its external BGP, unless we use nexthop
self. After that, in BGP there is a rule that we have mentioned earlier, that “if you receive an update from
internal BGP then you cannot give it to internal BGP again”.

Figure 13 Typical issue happen when edge router need to form iBGP session to whole router within the same AS

What if, for example, we are a provider with a lot of routers, the routers can be tens or hundreds of
routers in one AS. When a router receives an external BGP update from outside as in the picture above,
this router forms an internal BGP session to all other routers. Imagine, for example, we have 100 routers
in the AS, then the router that receives this external BGP update, must forward it to other 99 iBGP
routers. He sent the routers for one AS one by one, because we can't give them internally and then send
them internally again, that's not allowed. If we talk about default, the rule must be like that, a router
receives it from externally, then it must give it to all internal BGP but this is not scalable, if there are
more neighbors it will burden this router. Moreover, if we are talking about a provider that is full route,
so if he has to send full route updates to tens or even hundreds of iBGPs it will be difficult. The solution
to dealing with the problem above is the material that will be discussed next, which we called with route
reflectors.
 11

BGP Route Reflector (RR)

Figure 14 BGP RR comes as the best solution to overcome BGP Rule limitations

When a router receives update from external BGP, it needs to send the update to a router which
functions as an RR. Routers that receive eBGP and RR updates form iBGP session. This RR will forward
the update to another iBGP neighbor. How come it's permissible? to say that from internal you can't go
internal again? Yes, if it's not RR, if it's a route reflector, that's an exception. This RR must be configured
manually, who is the RR? So our internal BGP neighbors, even though in AS we have 100 internal BGP
neighbor routers, we don't need to go to 99 other routers, just go to at least one RR. We give it to one RR
and then that RR will pass it on to the others. This RR has many neighbors, but the other routers
neighbors are just RR route reflectors.
 12

Figure 15 Typical BGP RR Redundancy

What if this RR goes down? Is the BGP update broken? Yes, the BGP update is broken, so don't have one
RR, at least there is a backup RR. Our router that receives eBGP updates on the left, sends updates to
both RRs or more. If there is only one RR, there is a danger that if that RR dies, then the AS will collapse,
because it will no longer have internal neighbors if there is only one RR.

Route Reflector Behavior

Traffic usually does not traversed on the router that is chosen as the RR. Here is the Example

Figure 16 Route Reflector Behaviour

 13

There are router B-C-D, and then there is RR. Router B receives external BGP updates and then sends
internal BGP updates to RR. then RR will forward it to another router called the RR client.

Figure 17 RR only focused on sending update, not forwarding traffic.

When traffic from D wants to go to the eBGP network behind B. The traffic flow is D -> C -> B, the traffic
flow does not go through RR. RR is just a router whose job is only to forward BGP Updates, so it doesn't
need a router with high specs, it doesn't need a Terra router which can handle terabit or gigabit traffic,
because the traffic doesn't go through RR. Even today, RR can be implemented in the form of virtual
machines, not router physically, but the form is a VM. The RR task is crucial for BGP Update, but not for
traffic.

Figure 18 Typical physical link for RR redundancy

Then for redundant RR it is better to use a different route. If you use the same link, when the link goes
down, both RR will be down. So it's best if the physical connection between one RR and another RR has a
different path.
 14

Okay, can iBGP running without IGP?

Figure 19 iBGP Session scenario

For example, B and D want to form an iBGP neighbor relationship. B and D want to be iBGP without IGP (
it doesn’t use OSPFor EIGRP), can B and D be reachable? No, because B and D are not reachable, iBGP
will not be formed. So the order remains, we have to run IGP first, for example OSPF between B-C-D so
that end to end, B and D are reachable. If B and D are reachable then iBGP can work.

BGP Best Path Selection

OK, now lets take a look at BGP path selection, how to choose the best path in BGP.

1. Highest weight

Figure 20 BGP Weight attribute

This weight attribute has local and proprietary character. Local means that this attribute is never given to
other routers or neighbors, only within itself. then the second proprietary weight is only known at Cisco.
 15

For example, if there are two paths to a destination, one with a weight above 100 and one below a
weight of 200, then the path chosen is the one with the greatest weight, which is via the bottom. So the
first thing attribute to look at for choosing the best path is the highest weight.

2. Highest local preference

Figure 21 BGP local preference attribute

What if the weight is the same? The second BGP attribute seen is highest local preference. This local
preference is sent to internal neighbors, only exchanged between internal BGP, not with external BGP. so
for example we have two gateways to the destination. Gateway 1 sends a local preference update of 150,
while gateway 2's local preference is 100, assuming the weight is the same (default), then the path taken
is via gateway 1, which has a greater local preference.

3. Shortest AS Path

Figure 22 BGP AS-Path attribute

 16

OK, now what if the local preferences are the same. Suppose the destination is at AS 50. We assume the
local preferences have the same value, and the weight is the same. So the one chosen is the one with
the shortest AS path. choose the shortest, if you go from the top the AS path is 30 40 50. If you go from
the bottom, the AS path is 60 50. So the bottom path is chosen.

4. Origin

Figure 23 BGP Origin attribute

So, for example, if the destination has the same number of AS paths, then the next attribute to be
compared is the origin. Origin has 3 values “I”, “e” “?”. The following are the origin types and their
explanations

Origin types Description

i This code i indicates the prefix that was registered using the network command.
So a network in BGP can be advertised with the network command such as in
OSPF or EIGRP, we can enter it using the network command.

e code e means using legacy protocol. If we don't manipulate, we won't find e

automatically.

? The question mark is the result of redistribution. So let's say we redistribute OSPF
in BGP. So the origin of the redistribution result is "?"

So if you go through the top, the origin is i, if you go through the bottom, the origin is "?" then the one
selected is the origin i . the order of preference is “I”, then “e”, then “?”.

5. Multi Exit Discriminator (MED)

 17

Figure 24 BGP MED attribute

OK, what if the origin values are both i or both "?". The next order of attributes to look at is the BGP
metric or what is called the multi exit discriminator. This MED is given to external neighbors, this is
different from local preference, if local preference is given to internal neighbors, with MED we can give
preference to external neighbors when external neighbors want to enter our AS so that they choose the
path that we want. For example, if we tell external neighbors, for the top route we send MED value of
100, and for the bottom route, we send the MED value of 50. Because a lower Metric is preferred, the
neighbor will choose to go via the bottom route.

6. eBGP is more prefered than iBGP.

Figure 25 update from eBGP is preferred than iBGP

what if the metrics or MED are also the same? For example, when this router wants to go to its
destination, there are two options, the first is the router goes via an external neighbor, the second is the
router goes via an internal neighbor. For the weight value, the local preference, AS-path and the origin of
 18

the two paths are the same, so external BGP is chosen rather than internal BGP. We can even know
which path to choose by looking at the AD value, the administrative distance for external BGP AD is 20,
and internal BGP is 200. So external BGP is preferred over internal BGP.

7. Lowest IGP metric to IBGP neighbor

Figure 26 lowest IGP metric is preferred during best-path selection

What if, for example, a router has two neighbors, both of which are internal BGP with the same weight
value, the same local preference, the same AS path, the same origin, and the same metric, then the next
thing to compare is the lowest IGP metric towards the iBGP neighbor. So how many metrics based on
OSPF go to each internal neighbor, so how many metrics to gateway 1 according to OSPF and how many
to gateway 2? For example, OSPF says that if you go to gateway 1 the metric is 10, if you go to gateway 2
the metric is 20, then the choice is via gateway 1. Like this, so if for example one neighbor is external and
one is internal, then choose the external one, but if both neighbors are internal, then look at the metric
IGP.
 19

8. Oldest eBGP routes

Figure 27 oldest eBGP route is preferred during best-path selection

OK, now what if both neighbors are external to BGP? If we look at the AS paths, the path is the same, the
top path goes through two ASes, the bottom also has two ASes, the metrics are the same, both routers
are external BGP, then the path that will be used is the oldest eBGP route. So what it means is like this,
the neighbor above told you about the destination two days ago, while the one below just told you
about the destination 12 hours ago, which one do you choose? The one selected is the older eBGP route.
Which of the two eBGP neighbors sends the update first? Why is that? because it was proven to be more
stable, it didn't have any downs for two days, he was fine, stable while the bottom just lasted 12 hours.
 20

9. Lowest neighbor RID

Figure 28 lowest neighbor RID is preferred during best-path selection

Next is the 9th sequence for determining BGP path selection, for example we have two iBGP neighbors
that function as external gateways, towards gateway 1 the OSPF metric is 10, towards gateway 2 the
OSPF metric is also 10, previously it was said that if they are the same -with BGP internals, what is seen is
the IGP metric, whichever is smaller, that is what is used. If the IGP metrics are the same, then what is
seen is the lowest neighbor router ID. The router ID is taken from the loopback interface, if for example
gateway 1 router ID is 10.1.1.1, and then gateway 2 router ID is 10.2.2.2, then the path that will be
chosen is iBGP neighbor that has smaller router ID, which is GW1.
 21

10. Lowest neighbor IP address

OK, this is the 10th sequence, the last one in determining BGP path selection, when all the parameters
from sequence 1 to 9 which have been mentioned previously have the same value, then the neighbor
with the lowest IP address is selected. How come the router ID values are the same? Here is the
example.

Figure 29 lowest neighbor ip address is preferred during best-path selection

We form two iBGP sessions using 2 paths to the same router. The neighbors are defined as IP 10.1.1.1
and 10.2.2.1. Indeed, from here we can see that 2 iBGP neighbors will be registered, but the router ID is
the same, namely 1.1.1.1. If the router ID is the same, then the step in sequence 9 cannot determine
which is the best route to use, so what is compared in step 10 is the lowest neighbor IP address. So the
best path is via 10.1.1.1.
 22

BGP Lab Using Cisco vIOS Image On Eve-ng

Figure 30 BGP lab topology

Initial configuration

Configure IGP OSPF between R1 and R2

R1

Figure 31 router R1 OSPF configuration

 23

R2

Figure 32 router R1 OSPF configuration

Use loopback IP to establish a BGP session.

Figure 33 iBGP session establishment between loopback interface

when router A wants to build iBGP session with router B, it can have 3 options

Options Result

1. Router A form iBGP session with the consequence of this configuration, when link to the ip
router B using ip interface of router interface of router B goes down the BGP session would be
B. it can be neighbor 10.1.1.1 or down either.
neighbor 10.2.2.2

2. Router A form two iBGP session Its wasteful configuration, because we form two iBGP session
with router B. router A build iBGP to to the same neighbor. Update also need to be sent to two
10.1.1.1 and iBGP to 10.2.2.2 times.

3. Router A form iBGP neighbor It is the best configuration, if one of its link goes down. The
relationship with router B using BGP session is still up because the session is built between
loopback ip address. loopback ip addresses.
 24

After both loopback ip address of R1 and R2 can ping each other, then we can configure iBGP between
those two loopback ip addresses.

Configure R1 and R2 to form iBGP neighbor relationships

Figure 34 R1 iBGP neighbor configuration

Figure 35 R2 iBGP neighbor configuration

Configure eBGP between R2 <-> R3, and R2 <-> R4

Figure 36 R2 eBGP neighbor configuration

Figure 37 R3 eBGP neighbor configuration

Figure 38 R4 eBGP neighbor configuration

 25

Configure IGP EIGRP between R5 and R6

Figure 39 router R5 eigrp configuration

Figure 40 router R6 eigrp configuration

We are not going to configure iBGP between R5 and R6 here. Lets continue to configure eBGP between
R5 <-> R4, and R5 <-> R3.

Figure 41 R3 to R5 eBGP neighbor configuration

Figure 42 R4 to R5 eBGP neighbor configuration

Figure 43 R5 eBGP neighbor configuration

 26

now lets take a look at the BGP neighbors status starting from R1, show ip bgp summary

Figure 44 BGP neighbor verification on R1

on R1 we have neighbor 172.16.2.2, BGP version 4, AS neighbor is 65012, now pay attention to the
rightmost column if it is already a number, even if it is 0, this means it is already established, if it is not
established, for example the state is idle or connected or active (never a number ), there must be a
parameter that doesn't match.

we can also check show ip bgp neighbors

Figure 45 BGP neighbor verification on R1 (2)

pay attention here our neighbor is 172.16.2.2, the state is established, it has been stable for 1 hour 2
minutes, then the default keepalive is 60 seconds, the hold time or time out is 180 seconds, okay so this
is an iBGP session between R1 and R2 is up.

okay now let's look at R2, show ip bgp summary

Figure 46 BGP neighbor verification on R2

 27

Pay attention, here we can see that R2 has three neighbors, and all three neighbors in the rightmost
column have code 0, 0 means 0 prefix received from the neighbor. R2 has not received a prefix, because
we have just created neighbors between routers, we have not yet configured what networks are
advertised on all routers. From R1 to R5, BGP only defines neighbors (who our neighbors are), but what
we give to neighbors, we haven't defined any prefixes or any networks, so its just ok the number of
state/Prefixrecord still 0, but this proves that the neighbors configuration are okay.

next we check at R3

Figure 47 BGP neighbor verification on R3

R3 is also the same, there are three neighbors here. The State/Prefix record value is 0, meaning it is
established, there are no problems.

Let's check R4

Figure 48 BGP neighbor verification on R4

R4 has three neighbors, there is R2 R3, and R5, all three are established.

next is R5

Figure 49 BGP neighbor verification on R5

R5 has two neighbors, there are R3 and R4. We deliberately didn't activate R6 BGP.
 28

How do we advertise our network into BGP?

The first method is to use the network command, so for example in R3, it has several networks that are
in its routing table, we advertise them using the network command, likewise in R1 and R2 you can use
the network command.

okay, let's start from R2 first, show ip route

Figure 50 R2's global routing table

Let's look at R2's routing table, R2 has several networks on AS 65012. We want to advertise the networks
on AS 65012, both those that are connected and those that can be accessed from OSPF, networks
10.1.1.0/29 and 172.16.1.1 can be obtained from OSPF. We can use command network or we can use
redistribution. The first way to advertise a network to BGP is to redistribute the network obtained from
OSPF to BGP.

Figure 51 typical IGP redistribution to BGP

 29

Figure 52 redistribute OSPF to BGP configuration

So we redistribute all prefixes or all networks obtained from OSPF to BGP.

OK, let's see the results on other routers, on R3, R4, and R5. Let's see the results, show ip bgp summary,

Figure 53 BGP neighbor verification on R3 after redistribution

 30

okay here R3 gets 4 prefixes. We can see the details with show ip bgp.

Figure 54 prefix update from BGP on R3

Note that in the network column there are 4 prefixes. For example, to go to network 10.1.1.0/29 you can
go through 3 paths, the first option is nexthop 10.3.5.5, the second is 10.3.4.4 the third is 10.2.3.2. From
the three nexthops above, we can compare the attributes contained in the update and we can see that
nexthop 10.2.3.2 has the shortest AS Path, so the best path to network 10.1.1.0/29 is via nexthop
10.2.3.2. There is a larger “>” sign here. This bigger sign means the best path, indicating that it is the best
path to the destination. The question mark (“?” ) after AS Path above is the origin. We said earlier that if
the redistribution results are from OSPF, then the origin is a question mark.
 31

Figure 55 R3 route options to R1 LAN

The picture above shows that when R3 wants to go to network 10.1.1.0/29, he only needs to go via AS
65012, while via the blue route, he will go via AS 65004 and then go to AS 65012, while via the green
route, R3 will via AS 65056, then 65004, and just got to AS 65012.

Figure 56 collecting information from BGP table

 32

Likewise, when R3 goes to 10.1.2.0/29, this network is also in the same AS as 10.1.1.0/29 so it goes
straight through R2.

Figure 57 collecting information from BGP table (2)

OK where do these metrics come from? Try looking at the routing table on R2.

Figure 58 global routing table on R2

 33

Here is the network 10.1.1.0 on R2’s routing table, the OSPF metric value for that destination is 2, so
when it given to R3 the metric remains 2. When we redistribute network OSPF to BGP, the OSPF metric
value is also redistributed to BGP, not only the network is carried but the metric is also by default. BGP
just follows what metric is written on OSPF, for directly connected networks it has a metric of 0, for
example for networks 10.1.2.0/29 and 172.16.2.2/32 on R2. The two networks are directly connected on
R2, so the BGP metric is also 0.

now we look at the 2nd method, we look at R3

R3 has 3 networks (we don't count external networks). We see in R3, show ip route connected

Figure 59 global routing table (connected) on R3

OK, let's advertise the connected network on R3 using the network command. Make sure that when
advertising with the network command, the subnet mask matches what is recorded in the routing table.

Figure 60 R3 advertise attached network to BGP

 34

OK, now let's see on router 4 whether it has received the prefix from R3. show ip bgp summary

Figure 61 R4 verify BGP neighbor update

okay from R3 we receive 8 prefixes, we can check in more detail show ip bgp
 35

Figure 62 R4 BGP table

R3's network has 10.2.3.0, 10.3.5.0, and 172.16.3.3, the path has the value 65003 at the end, which
means it belongs to R3. Then pay attention to the origin, the origin is "i" not "?". if "?" This is the result
of redistribution, but if we use the network command like in R3, then the origin is "i".

OK, so R4 has received the prefix update. Now R4 also advertises using the network command. First, let's
check the routing table, show IP route connected
 36

Figure 63 R4 global routing table (connected)

Figure 64 R4 advertise attached network to BGP

Remember, when we advertise a network on BGP, the important thing is that the network is in the
routing table, it doesn't have to be directly connected, whether it can be from OSPF or EIGRP. We can
advertise using the network command. OK, now let's check on R5, whether R5 receives R3 and R4. Show
ip bgp summary
 37

Figure 65 R5 verify BGP neighbor update

okay R5 accepts 11 prefixes from R3 and R4, let's see what is in it, show ip bgp

Figure 66 R5 BGP table

 38

This 65004 belongs to R4, for example 172.16.4.4 (R4 loopback IP). Now we see there is a small r code,
we can see above, this r is rib-failure, rib (routing information base) aka routing table, this "r" indicates
that this network will not be installed into the routing table using BGP. Let's see why, show ip bgp rib-
failure

Figure 67 BGP rib-failure table

the reason is higher administrative distance. OK, pay attention to 10.3.5.0 and 10.4.5.0, these are
obtained from external BGP, the external BGP administrative distance is 20, now lets see route to those
two networks,

show ip route | include 10.4.5.0

show ip route | include 10.4.5.0

Figure 68 verify route on R5

R5 has obtained information about the two networks from connected, and connected has AD 0, while
the two networks were obtained again from BGP with AD 20. Because the AD owned by connected is
smaller, the one installed is “C” connected, not “B” BGP. OK, now all that remains is R5. R5 wants to
advertise its prefix list to external networks with redistribution

Figure 69 R5 redistribute EIGRP to BGP

OK, now let's check R1. show ip bgp summary

 39

Figure 70 R1 verify BGP neighbor update

OK, R1 receives 13 prefixes from R2, we check what it contains, show ip bgp

Figure 71 R1 BGP table

Note the prefix containing AS Path 65056 at the end. Here we can see that R1 has received information
about R5's loopback, R6's loopback, and also received R6's LAN. Then lets check R5, show ip route bgp
 40

Figure 72 R5 BGP routing table

OK, R5 has received all prefixes, the administrative distance is 20 because it can be obtained from
external BGP.

Lets see bgp route on R1, show ip route bgp

Figure 73 R1 BGP routing table

Previously in Figure 71 we had confirmed that R1 had received the update from R2, but when we check
ed show ip route bgp, it turned out that all the prefixes sent by R2 were not installed in the routing table.
The BGP R1 routing table is empty. When we checked the previous show ip bgp on figure 71, it turns out
there is no network that has the codes "*" and ">" (valid and best path). Why do we receive updates
from BGP but they are not entered into the routing table? The following is the explanation
 41

Figure 74 example when BGP router forward update from external to its iBGP neighbor

As we said at the beginning, by default the nexthop for iBGP is external BGP, so if you look at this picture,
R1 will receive R3 and R4 as its nexthop, not R2. So now we look at R1's routing table, by default R1 still
considers the nexthop to be R3 and R4, is there a route on R1 to R3 and R4?

Figure 75 R1 global routing table

There is no route to R3's 10.2.3.3. Let's try show ip bgp 10.2.3.3

 42

Figure 76 R1 verify route to its external neighbor

Let's check the show ip route 10.2.3.3

Figure 77 R1 veriy route to external neighbor in its global routing table

There is no route to 10.2.3.3 or 10.2.4.4. This is the reason why the BGP information obtained cannot be
entered into the routing table, because by default the next hop information on BGP updates that is
received by R1 is its external BGP neighbor, which are R3 and R4, while R1 does not know how to get to
R3 and how to get to R4. So that R1 knows the route to the external route, there are two choices that
can be made on R2. First, R2 advertises R3 and R4 to R1. OK, let's see, we use the first option show run |
section ospf

Figure 78 verify OSPF running config on R2

 43

okay here 10.2.3.0 and 10.2.4.0 are not in OSPF so R2 does not advertise these two networks to R1. Now
we try to advertise these two networks

Figure 79 R2 reconfigure OSPF to advertise eBGP nexthop to its iBGP neighbor

Figure 80 verify ip interface on R2

Because towards R3 and R4 we don't want to run OSPF, so we set the passive interface at G0/1 and
G0/2.

Figure 81 R2 set OSPF passive-interface that is used for eBGP

we check show ip route for 10.2.3.3 and 10.2.4.4

now R1 can go to external BGP neighbors (R3 and R4) with OSPF. now we check BGP, show ip bgp
 44

Figure 82 R1 verify bgp table after R2 advertise eBGP network to its OSPF

sekarang semua prefix yang muncul sudah memiliki tanda “>” (the best path), nexthopnya sudah valid
sekarang ya, kalau sudah valid seharusnya sudah terinstal di global routing table, kita cek show ip route
bgp

Figure 83 R1 verify its global routing table

 45

OK, from R1, the BGP routing table was originally empty, and now it is filled.

The second way is to use something called next-hop-self,

Figure 84 next-hop-self scenario

This method changes the behavior of the BGP edge router when it receives updates from external
neighbors and forwards these updates to its iBGP neighbors. The way it works is that R2 will say to R1,
"R1, your next hop to go to the external is me", so the next hop is not R3 or R4, but the next hop is R2.

Figure 85 configure next-hop-self

After R2 is configured with next-hop-self, now look what is the difference, show ip bgp
 46

Figure 86 R1 verify its bgp table after R2 configured with next-hop-self

now we check on R1, all nexthops from the bgp prefix received by R1 change to R2. OK, so we can see
that there are two ways to make the nexthop valid, first on R2 we advertise it using IGP, externally R3
and R4 are advertised by R2 using IGP to R1. The second way is to add next-hop-self to R2. OK, so using
this method, we can ping 172.16.3.3, 172.16.4.4 or 172.16.5.5

Figure 87 R1 ping test to R3, R4 and R5

Let's try the last one 172.16.6.6

 47

Figure 88 R1 ping to R6's loopback ip address

why did it fail? let's look at show ip route on R6

Figure 89 R6 global routing table

Here we can see that R6's routing table is small, it only knows the network in AS 65056, R6 only uses
EIGRP to exchange prefixes with R5, R6 does not use BGP. So how do you make sure that R6 can go to all
destinations, from R1 to R2 to R3 to R4? let's look at the following explanation
 48

Figure 90 R5 redistribute its EIGRP prefixes to eBGP

Previously, R5 had redistributed the prefix obtained from EIGRP to eBGP, so that all routers that has
installed BGP received information about the networks on AS 65056, including networks connected
directly to R6. However, when we check R6, it turn out that R6 does not have a routing table to a
network outside R5, the solution is that R5 advertises eBGP to R6 using EIGRP, aka redistribution.

Figure 91 R5 redistribute prefixes from its eBGP to EIGRP

So R5 receives updates from external BGP, then R5 redistributes them to R6 with EIGRP. R6 received
prefix updates in the form of EIGRP.
 49

Figure 92 R5 configure BGP redistribution to EIGRP

OK, after we redistribute BGP to EIGRP, we see that in R6 the redistribution results doesn't appear.

Figure 93 R6 verify its global routing table after redistribution

This is the problem, any protocol that we redistribute to EIGRP, the default metric is infinite, it won’t be
installed on the routing table. This mean we have to define or change the seed or default metric EIGRP.
 50

Figure 94 how EIGRP received redistribute prefixes from any protocol

In EIGRP, the metric is based on two components, bandwidth and delay, although there are other
components such as reliability, load and MTU, but only bandwidth and delay are used. The default values
for reliability, load and MTU are not used in metric calculations. If we involve them in metric calculations
then when reliability and load go up and down, metrics calculation will change, this creates an additional
burden for the router. OK, let's say we enter the bandwidth as 10 mbps then the delay is 1000
microseconds. OK, so we have to define what the metric value will be when we redistribute it into EIGRP.

Figure 95 R5 changes EIGRP metric

okay the first metric is bandwidth in kilos, so if we want 10 mbps then we enter 10,000 kbps, then the
next is delay in units of 10 microseconds so if we 1000 then 1000:10=100, then for reliability, load and
MTU these values are whatever the same because it will not be included in the metric calculation. OK,
let's look at R6, show ip route
 51

Figure 96 R6 verify its global routing table after EIGRP default metric is changed

Now R6 has received the redistribution results sent by R5, the characteristic is code IX which means the
external EIGRP, D itself is EIGRP .then pay attention, the administrative distance is 170, if you get it from
regular EIGRP, just code "D", the administrative distance is 90. For redistribution, if we use named EIGRP,
then redistribute under the topology base command, so address family, then topology base, if using
classic EIGRP directly under the router command EIGRP [ASN]. Now we test the ping from R1 with
loopback source 172.16.11 to loopback R6

Figure 97 R1 verify connectivity to R6

okay loopback to loopback successfully connected. Finally, lets try connectivity between PC1 and PC6.
Configure ip and gateway on PC1 and PC6
 52

Figure 98 PC1 and PC6 ip configuration

Lets try the ping and traceroute tests

Figure 99 PC1 verify connectivity to PC6

when R1 traceroute to 10.6.6.5 the route goes via R1 > R2 > R3 > R5 > R6 then reaches PC6. Why does
the route goes via R3 and not via R4? Lets check BGP neighbor status at R2, show ip bgp summary
 53

Figure 100 R2 verify oldest its eBGP neighbor

R3 was up more than 6 hours ago while R4 was only up about 2 minutes ago, so the one that went up
first was R3, this proves that if we have two external neighbors (eBGP), then we choose which one is up
first, or which neighbor The one who sends the update to us first, that's the best path to use.