Professional Documents
Culture Documents
La b 1
BGP Peering
Overview
This lab covers configuration of OSPF and BGP (iBGP & eBGP) topics.
You have been assigned a POD consisting of 3 devices: The Tokyo, HongKong and SanJose
routers. Make sure you understand which devices have been assigned to you. This lab guide takes
as a configuration example POD A but this just a reference. If you have been assigned a different
POD than A, make sure you adapt your configurations to your assigned POD, following always the
lab diagram.
Note that your lab login (password lab123) grants you all permissions needed to complete this lab;
however some restrictions have been made to prevent loss of connectivity to the devices.
By completing this lab, you will perform the following tasks:
Configuration:
Configure the IGP within your AS (OSPF)
Configure IBGP peering between loopback addresses
Configure EBGP peering to physical addresses
Operation:
Use show commands to verify and troubleshoot interface operation
Use show commands to verify and troubleshoot routing table operation
Use show commands to verify and troubleshoot OSPF operation
Use show commands to verify and troubleshoot BGP operation
Please refer to the next page lab diagram to perform this exercise:
1
Juniper BGP lab exercise: BGP Peering
Lab Diagram
AS 44
ge-0/0/2 ge-0/0/1
San Jose 0.2 Denver
lo0: 192.168.20.1 0.1
lo0: 192.168.5.1
.2
se- 16.2
2 2 /3 DCE
0/0
1/0
Vlan 674
3 g e-
/0
0/ AS 77
-0/
g e .1
22
Sao Paulo
lo0: 192.168.12.1
Tokyo ge-0
/0/1
se - 1
lo0: 192.168.18.1
16.
21.2
1/0
ge-0
/0/1
/1
21.1
Hong Kong ge-0/0/2
lo0: 192.168.16.1
15.2 ge-0/0/2
15.1 Sydney
AS 702
AS 666
2
Juniper BGP lab exercise: BGP Peering
Key Commands
Key operational mode commands used in this lab include the following:
show interfaces
show route
show ospf interfaces
show ospf neighbors
show bgp neighbor
show bgp summary
show route
show route protocol ospf
lab@SanJose> configure
Entering configuration mode
[edit]
lab@SanJose# load override bgp/lab1-bgp-start
load complete
Familiarize with the configuration just loaded. You will notice that there are IPv4 address configured
on the interfaces. Interfaces have been preconfigured for you so do not have to worry about them,
they just work
Once you are satisfied commit your configuration.
[edit]
lab@SanJose# commit and-quit
commit complete
____________________________ Note__________________________
Do not forget to load this configuration file in the two remaining routers of the
topology.
__________________________________________________________________
3
Juniper BGP lab exercise: BGP Peering
[edit]
lab@SanJose# edit protocols
[edit protocols]
lab@SanJose# set ospf area 0 interface ge-0/0/3
[edit protocols]
lab@SanJose# set ospf area 0 interface se-1/0/0
[edit protocols]
lab@SanJose# set ospf area 0 interface lo0
Your configuration should look like this example taken from SanJose. When satisfied with your
configuration changes go ahead and commit them.
[edit protocols]
lab@SanJose# show
ospf {
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/3.0;
interface se-1/0/0.0;
}
}
[edit protocols]
lab@SanJose# commit
commit complete
.
____________________________ Note__________________________
Repeat this steps on every router in the topology. That will result in 4x OSPF
domains on each respective AS.
__________________________________________________________________
4
Juniper BGP lab exercise: BGP Peering
The IGP adjacencies associated with the SanJose router are confirmed in the sample
output related to the OSPF protocol:
[edit protocols]
lab@SanJose# run show ospf neighbor
Step 3.2
Confirm that you have IGP routes to all the loopback addresses for all routers within your AS.
Are the loopback addresses for all routers in your AS correctly listed?
The sample output taken from the SanJose router confirms that an IGP route exists
to the loopback address of both HongKong and Tokyo
[edit protocols]
lab@SanJose# run show route protocol ospf | match /32
192.168.16.1/32 *[OSPF/10] 02:56:13, metric 2
192.168.18.1/32 *[OSPF/10] 02:56:13, metric 1
224.0.0.5/32 *[OSPF/10] 03:07:06, metric 1
____________________________ Note__________________________
Note the metric value of 2 to reach the directly connected neighbor HongKong.
This comes from the OSPF calculation of metrics (metric=100000/Bandwidth of
interface) that assigns a cost of 12 to the SanJose-HongKong serial link,
making it less attractive than the 2 time GigaEthernet path SanJose-Tokyo-
HongKong which cost is 1 for each interface
__________________________________________________________________
5
Juniper BGP lab exercise: BGP Peering
Enter the following command on all routers with serial interfaces participating in OSPF. Please note
this is not needed on serial links which interconnect ASs since they do not participate in OSPF.
After the metric changes, does your traceroute follow an optimal path?
Yes it does. Now all links have a cost of 1 which makes the routing optimal. Please
note that we are just manipulating metrics and fooling OSPF as the previous behavior
certainly did follow the Shortest Path First based on cost of links
____________________________ Note__________________________
Because your loopback-based IBGP sessions rely on a functional IGP, you
should not proceed until you have confirmed that your ASs IGP is operational.
__________________________________________________________________
6
Juniper BGP lab exercise: BGP Peering
[edit routing-options]
lab@SanJose# set autonomous-system 702
Step 4.2
Configure IBGP peering sessions between the loopback interfaces of all routers associated with your
autonomous system. As BGP dictates, we need a full mesh of iBGP sessions within the AS. Look at
the lab diagram; every blue arrow is an iBGP session that you have to configure.
Assign the name ibgp to this grouping of IBGP peers. Make sure that you specify your stations
loopback address along with the local-address statement to ensure that you correctly initiate
IBGP sessions from your loopback address.
[edit routing-options]
lab@SanJose# top
[edit]
lab@SanJose# edit protocols bgp group ibgp
Step 4.3
When complete, your ibgp peer group definition should be similar to this example taken from the
SanJose station in AS 702:
7
Juniper BGP lab exercise: BGP Peering
neighbor 192.168.16.1;
neighbor 192.168.18.1;
____________________________ Note__________________________
Repeat similar steps on every router in your AS.
__________________________________________________________________
Step 5.2
When complete, your EBGP peer definition should be similar to this example taken from the
SanJose station. Note how this configuration places the EBGP neighbors into separate EBGP peer
groups:
8
Juniper BGP lab exercise: BGP Peering
peer-as 44;
neighbor 10.0.0.2;
}
Step 5.3
Commit the changes, and return to operational mode when you are satisfied with your IGP, IBGP,
and EBGP configuration.
____________________________ Note__________________________
Repeat similar steps and bring up the relevant eBGP sessions on your other
assigned routers in the topology.
__________________________________________________________________
____________________________ Note__________________________
You should use ping commands to verify connectivity to the BGP peering point
if any of your BGP sessions show a state of active, idle, or connect. If the
pings are successful, then double-check your BGP configuration to ensure no
mistakes were made.
__________________________________________________________________
Are all the BGP sessions associated with your station correctly established?
The sample output below shows that the SanJose station correctly established both
of its IBGP sessions to peers in AS 702, and the EBGP session to AS 44:
9
Juniper BGP lab exercise: BGP Peering
What is the significance of the 0/0/0/0 indication in the output of a show bgp
summary command?
In the case of the peering with your iBGP peers, the 0/0/0/0 entries indicate that 0
routes are active , that 0 routes have been received, that 0 routes have been accepted
and that 0 routes have been suppressed due to damping. In essence, this indicates that
you have established BGP sessions, but that you are not receiving any NLRI over these
sessions.
Step 6.2
Determine whether any BGP routes exist.
Yes, there are some BGP learned routes coming from the external peers
10
Juniper BGP lab exercise: BGP Peering
Step 6.3
Display BGP group information for your ibgp group.
Step 6.4
Display BGP neighbor-specific information for one of your EBGP peers.
What hold-time has been negotiated with your neighbors?
The keepalive interval is set to 30 seconds and is based on a value that is one third that
of the sessions hold time.
What NLRI has been negotiated for this session? Does the peer support BGP
refresh?
The sample display confirms that only the inet-unicast NLRI family has been
negotiated and that the refresh capability has been negotiated.
For a particular neighbor, can you tell which peer initiated the TCP connection?
Yes. The neighbor that initiates the TCP connection specifies a destination port of 179
and a source port that does not equal 179. In the sample output shown, the value of 179
in the Local: 10.0.0.2+179 portion of the display indicates that 10.0.0.1 initiated the
TCP session.
11
Juniper BGP lab exercise: BGP Peering
12
Juniper BGP lab exercise: BGP Peering
Step 7.2
Commit your changes, return to operational mode, and monitor the bgp trace file to answer the
following question:
[edit protocols bgp]
lab@SanJose# commit and-quit
commit complete
Exiting configuration mode
lab@SanJose> monitor start bgp
lab@SanJose>
The sample output taken from the SanJose station indicated that keepalive messages are
being sent and received to and from internal and external peers
lab@SanJose>
*** bgp ***
Jan 15 18:16:44.085903 bgp_send: sending 19 bytes to 10.0.0.2 (External AS 44)
Jan 15 18:16:44.085993
Jan 15 18:16:44.085993 BGP SEND 10.0.0.1+50180 -> 10.0.0.2+179
Jan 15 18:16:44.086103 BGP SEND message type 4 (KeepAlive) length 19
Jan 15 18:16:45.922820
Jan 15 18:16:45.922820 BGP RECV 192.168.16.1+179 -> 192.168.20.1+63243
Jan 15 18:16:45.922912 BGP RECV message type 4 (KeepAlive) length 19
Jan 15 18:16:45.923010 bgp_read_v4_message: done with 192.168.16.1 (Internal
AS702) received 19 octets 0 updates 0 routes
Jan 15 18:16:47.217213 bgp_send: sending 19 bytes to 192.168.16.1 (Internal AS
702)
Jan 15 18:16:47.217298
Jan 15 18:16:47.217298 BGP SEND 192.168.20.1+63243 -> 192.168.16.1+179
Jan 15 18:16:47.217332 BGP SEND message type 4 (KeepAlive) length 19
Jan 15 18:16:49.648255
Jan 15 18:16:49.648255 BGP RECV 192.168.18.1+179 -> 192.168.20.1+59509
Jan 15 18:16:49.648414 BGP RECV message type 4 (KeepAlive) length 19
Jan 15 18:16:49.648449 bgp_read_v4_message: done with 192.168.18.1 (Internal AS
702) received 19 octets 0 updates 0 routes
...
Step 7.3
Perform a soft clear on one of your routers iBGP sessions while monitoring the bgp log file.
According to the tracing output, did the soft clear tear down the BGP session?
13
Juniper BGP lab exercise: BGP Peering
No, a soft clear uses the BGP refresh capability to request that a peer readvertise all of
its NLRI without tearing down the BGP connection. This will cause our router
SanJose to send all its learned NLRIs from AS44 again to the iBGP peer. A lot of
activity will be on display:
14
Juniper BGP lab exercise: BGP Peering
44.44.27.0/24 , 44.44.26.0/24
Jan 15 18:29:41.440797 BGP SEND 44.44.25.0/24 , 44.44.24.0/24 ,
44.44.23.0/24 , 44.44.22.0/24
Jan 15 18:29:41.440825 BGP SEND 44.44.21.0/24 , 44.44.20.0/24 ,
44.44.19.0/24 , 44.44.18.0/24
Jan 15 18:29:41.440915 BGP SEND 44.44.17.0/24 , 44.44.16.0/24 ,
44.44.15.0/24 , 44.44.14.0/24
Jan 15 18:29:41.440961 BGP SEND 44.44.13.0/24 , 44.44.12.0/24 ,
44.44.11.0/24 , 44.44.10.0/24
Jan 15 18:29:41.440991 BGP SEND 44.44.9.0/24 , 44.44.8.0/24 , 44.44.7.0/24
, 44.44.6.0/24
Jan 15 18:29:41.441017 BGP SEND 44.44.5.0/24 , 44.44.4.0/24 , 44.44.3.0/24
, 44.44.2.0/24
Jan 15 18:29:41.441038 BGP SEND 44.44.1.0/24
Jan 15 18:29:41.445379 bgp_send: sending 97 bytes to 192.168.18.1 (Internal AS
702)
Jan 15 18:29:41.445457
Jan 15 18:29:41.445457 BGP SEND 192.168.20.1+59509 -> 192.168.18.1+179
Jan 15 18:29:41.445571 BGP SEND message type 2 (Update) length 97
Jan 15 18:29:41.445603 BGP SEND Update PDU length 97
...
Step 7.4
Clear one of your IBGP sessions while monitoring the bgp log file for at least 30 seconds. This time
do not use the soft command so that will cause a complete session reset.
Was the IBGP session successfully torn down and reestablished?
Yes, in this example, the trace output shows IBGP session teardown and
reestablishment:
15
Juniper BGP lab exercise: BGP Peering
Step 7.5
Stop monitoring the bgp log file.
lab@SanJose> monitor stop
lab@SanJose>
STOP
You have completed Lab 1 !
16