The command show route displays the contents the routing table

CET327 Tutorial 2

• Explain how eBGP operates.

Why are you studying this?

•

that R1 in part of AS1, R2 is part of AS2, R3 is						192.168.1.1/30	Internet
							Internet
				10.2.0.1/24 lo1			10.3.0.1/24 lo1
						lo2


						Gi0/1
lo0	Gi0/2	Gi0/2	R2		lo0	R3
	Gi0/2	Gi0/2	R2			Gi0/2
		10.0.0.6/30	Gi0/4			Gi0/2
		10.0.0.6/30	Gi0/4				3.3.3.3/32
1.1.1.1/32		10.0.0.13/30					3.3.3.3/32

10.0.0.14/30

Gi0/1

lo0	R4
4.4.4.4/32	R4

P a g e 1 | 22

The following screenshots contain the commands required to name a router, configure loopbacks and setup your Gigabit Ethernet interfaces.

Initial configuration of R3

•	After you have verified that all your directly connected links are working correctly, you may proceed to R1 and issue the BGP commands shown below. These commands will enable R1 to establish a neighbour relationship with R2 and will inform R1 that it must advertise its 10.1.0.0/24 subnet to R2

This number is called the Autonomous System Number (ASN) Each company must have its own number. The ASN in this tutorial is the router number (e.g. R1 is in AS1, R2 is in AS2, Rx is in AS x)

Notice that R2 is in ASN 2 and that it will
use its lo0 address 2.2.2.2 as its router ID

This command tells R2 that it has an eBGP
neighbour in AS 1 with IP address 10.0.0.5.
This is R1. A neighbour relationship will form
between the two routers once each device
has a matching neighbour statement.

•

P a g e 3 | 22


		Notice that the command displays
	the Router ID and ASN of R1

This indicates that R1 has learned one prefix
(route) from its neighbour R2(10.0.0.6)

We are using BGP
		Idle or Active rather than a number then the neighbour
	route changes and that route is
of BGP)

•	•

		your R1 configuration. R1 has also received one prefix(a route from R2 which is 10.2.0.0/24). The table
		version is incremented whenever a neighbour supplies us with a new prefix or an updated prefix. You
		may see a different table version to the one shown in the screenshot above. It will depend upon whether
		you had to make any topology or configuration corrections.

•	Notice that R2 has the router ID 2.2.2.2 and that it has the same table version as R1. R2 also has one neighbour at present which is identified by the IP address 10.0.0.5. This is the IP address of R1.

P a g e 4 | 22

The neighbour’s router ID is 2.2.2.2 (R2)

The neighbour relationship will be maintained by the
exchange of short BGP messages called Keepalives every
60 seconds. A neighbour will be declared dead if no
Keepalives have been received for 180 seconds.(After
three consecutive keepalives have failed to arrive).

Notice that the neighbour’s router ID is displayed (2.2.2.2) and that the relationship state is
Established. This indicates that the neighbour relationship is working and that routes may be exchanged. The show command also identifies how frequently BGP keepalives are exchanged (every 60 seconds) and how long the router will wait without hearing from its neighbour before declaring it down (hold time180 seconds). These timers are configurable.

The show command also identifies how many BGP packets of each type have been exchanged. Issue the command again. You should see that the number of keepalives has incremented.

•

The local router is the TCP client and is using TCP port 12652. You will probably have a different outcome as this number is randomly chosen

•

This means that each BGP router must listen for messages sent to port 179. It doesn’t matter to BGP which router becomes client and which becomes server, so if a router receives a request on port 179 before it has sent a TCP client packet it will accept the server role. If two routers send and receive TCP messages at the same time then the router with the largest router ID is chosen as the client. It is therefore imperative that firewalls don’t block traffic on port 179 in either direction as it is virtually impossible to determine which BGP neighbour will act as the server. It is also noteworthy that the use of TCP means that BGP peers don’t have to be directly connected to each other.

You will now view the TCP three way handshake on both R1 and R2. Enter the command debug ip packet detail on both R1 and R2. This command will display the contents of all IP packets sent and received by both routers. Don’t forget that debug commands must be entered from Privileged mode.

R1 (10.0.0.5) sent this packet to R2 (10.0.0.6)

Each message with a SYN code is part of the TCP
three way handshake

•

•

•

P a g e 7 | 22

• •	The routes that BGP neighbours exchange are stored in the BGP table. The best route to each destination is then offered to the routing table. You can view the BGP routes using the command show ip bgp

Enter the command show ip bgp on each router. You should see the following output.

A next hop of 0.0.0.0 indicates that this route was advertised by the local router (R1 in this case) via a network statement

P a g e 8 | 22

A next hop of 0.0.0.0 indicates that this route was advertised by the local router (R2 in this case) via a network statement

The Pathcolumn identifies which autonomous systems must be traversed to reach the destination subnet.

•

P a g e 9 | 22

Show ip route on R1

An eBGP route is labelled with the letter B. It also has an
Admin distance of 20 which means it will be preferred over
IGPs but not static routes or directly connected routes

Show ip route on R3

•

•	I have chosen lo1 because it has the address 10.1.0.1. R3 will be able to reply to ping packets sent from this address as it has a route to the 10.1.0.0/24 subnet (see routing table of R3). You can verify this by pinging 10.3.0.1 from R1 using the commands displayed in the output below.

This failed because the ping packets used 10.0.0.5 as the
source address. They were routed to R3 but R3 doesn’t know
where 10.0.0.5 is located and therefore couldn’t respond

	P a g e 11 \| 22

•

This ping succeeded because R3 sent its pings with the source
address of lo1 (10.3.0.1). R1 received the pings and was able to
reply because it has a route to 10.3.0.0/24

•	You should find that R2 can ping 10.1.0.1 and 10.3.0.1 without modifying the default source address. Why is this the case?

Clear the BGP configuration on R1

Clear the BGP configuration on R2

Clear the BGP configuration on R3

Required Static Route for R3

•

•	Use the following extended ping command to verify that lo0 of R2 (2.2.2.2) can reach lo0 of R3 (3.3.3.3)


New BGP configuration for R1	Notice that R2 will be referenced using its lo0	This command tells R1 that is must use its lo0
New BGP configuration for R1		This command tells R1 that is must use its lo0

•	New BGP configuration for R2	Notice that R1 will be referenced using its lo0

P a g e 14 | 22

•

R3 is now represented by its lo0 address

(3.3.3.3) rather than 10.0.0.10 which was its

•

address of lo0 of R2 (2.2.2.2)

P a g e 15 | 22

• Configuration for R3

•

BGP description text appears here if
configured. You can enter up to 80 characters

Basic Security

Password configuration for R1

•

•	Now complete the BGP authentication between R2 and R3 by entering the following commands on R3. You will need to reset the BGP neighbour relationship between R2 and R3 before these commands will be activated.

•

Configuration on R1

Please note that the commands above must be assigned to each side of a BGP neighbour relationship or the relationship will fail.

P a g e 18 | 22

•

BGP Default Routes

• Most companies that use BGP will still have to deploy a default route as they won’t have, or more


	Go to R3 then enter the following commands.	This command instructs R3 to advertise a default route to its neighbour R2 (2.2.2.2).

P a g e 19 | 22

This is the BGP default route. Notice that
the letter B is superseded by a * which
indicates that this route is a candidate
default route

• If you check the BGP table on R1 you will find that R2 (2.2.2.2) has passed this default route on to R1.