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:
Operation:
Please refer to the next page lab diagram to perform this exercise:
Lab Diagram
lo0: 192.168.20.1
DCE
AS 77
Sao Paulo
lo0: 192.168.12.1
ge-0
/0/1
21.1
/1
1/0
se - 1
16.
Tokyo
ge-0
/0/1
lo0: 192.168.18.1
21.2
lo0: 192.168.16.1
AS 702
Denver
lo0: 192.168.5.1
/0
1/0
se- 16.2
.2
2 2 /3
Vlan 674
0/0
eg
3
0/
-0/
g e .1
22
ge-0/0/1
0.2
ge-0/0/2
0.1
San Jose
15.2
ge-0/0/2
15.1
Sydney
AS 666
E-BGP
I-BGP
Key Commands
Key operational mode commands used in this lab include the following:
show
show
show
show
show
show
show
show
interfaces
route
ospf interfaces
ospf neighbors
bgp neighbor
bgp summary
route
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.
__________________________________________________________________
[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.
__________________________________________________________________
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
Address
10.0.22.1
10.0.16.1
Interface
ge-0/0/3.0
se-1/0/0.0
State
Full
Full
ID
192.168.18.1
192.168.16.1
Pri
128
128
Dead
37
37
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
192.168.18.1/32
224.0.0.5/32
____________________________ 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-TokyoHongKong which cost is 1 for each interface
__________________________________________________________________
Step 3.3
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.
__________________________________________________________________
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
[edit protocols bgp group ibgp]
lab@SanJose# set type internal
[edit protocols bgp group ibgp]
lab@SanJose# set local-address 192.168.20.1
[edit protocols bgp group ibgp]
lab@SanJose# set neighbor 192.168.18.1
[edit protocols bgp group ibgp]
lab@SanJose# set neighbor 192.168.16.1
Step 4.3
When complete, your ibgp peer group definition should be similar to this example taken from the
SanJose station in AS 702:
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:
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:
lab@SanJose> show bgp summary
Groups: 2 Peers: 3 Down peers: 0
Table
Tot Paths Act Paths Suppressed
inet.0
611
307
0
Pending
0
Peer
AS
InPkt
State|#Active/Received/Accepted/Damped...
10.0.0.2
300/300/300/0
192.168.16.1
0/300/300/0
192.168.18.1
0/0/0/0
44
0/0/0/0
702
0/0/0/0
702
0/0/0/0
OutPkt
OutQ
473
428
3:02:02
553
555
3:29:51
478
546
3:29:47
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
lab@SanJose> show route protocol bgp
inet.0: 315 destinations, 616 routes (315 active, 0 holddown, 300 hidden)+ =
Active Route, - = Last Active, * = Both
44.44.1.0/24
44.44.2.0/24
44.44.3.0/24
...
10
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.
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
lab@SanJose> configure
Entering configuration mode
[edit]
lab@SanJose# edit protocols bgp
[edit protocols bgp]
lab@SanJose# set traceoptions file bgp
[edit protocols bgp]
lab@SanJose# set traceoptions flag update detail
12
Step 7.2
Commit your changes, return to operational mode, and monitor the bgp trace file to answer the
following question:
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
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:
lab@SanJose> clear bgp neighbor 192.168.18.1 soft
lab@SanJose>
Jan 15 18:29:41.439687 bgp_send: sending 413 bytes to 192.168.18.1 (Internal AS
702)
Jan 15 18:29:41.439772
Jan 15 18:29:41.439772 BGP SEND 192.168.20.1+59509 -> 192.168.18.1+179
Jan 15 18:29:41.439805 BGP SEND message type 2 (Update) length 413
Jan 15 18:29:41.439898 BGP SEND Update PDU length 413
Jan 15 18:29:41.439931 BGP SEND flags 0x40 code Origin(1): IGP
Jan 15 18:29:41.439955 BGP SEND flags 0x40 code ASPath(2) length 6: 44
Jan 15 18:29:41.439977 BGP SEND flags 0x40 code NextHop(3): 10.0.0.2
Jan 15 18:29:41.439996 BGP SEND flags 0x40 code LocalPref(5): 100
Jan 15 18:29:41.440014 BGP SEND flags 0xc0 code Communities(8): 44:44
Jan 15 18:29:41.440048 BGP SEND
44.44.89.0/24 , 44.44.88.0/24 ,
44.44.87.0/24 , 44.44.86.0/24
Jan 15 18:29:41.440153 BGP SEND
44.44.85.0/24 , 44.44.84.0/24 ,
44.44.83.0/24 , 44.44.82.0/24
Jan 15 18:29:41.440226 BGP SEND
44.44.81.0/24 , 44.44.80.0/24 ,
44.44.79.0/24 , 44.44.78.0/24
Jan 15 18:29:41.440262 BGP SEND
44.44.77.0/24 , 44.44.76.0/24 ,
44.44.75.0/24 , 44.44.74.0/24
Jan 15 18:29:41.440289 BGP SEND
44.44.73.0/24 , 44.44.72.0/24 ,
44.44.71.0/24 , 44.44.70.0/24
Jan 15 18:29:41.440315 BGP SEND
44.44.69.0/24 , 44.44.68.0/24 ,
44.44.67.0/24 , 44.44.66.0/24
Jan 15 18:29:41.440421 BGP SEND
44.44.65.0/24 , 44.44.64.0/24 ,
44.44.63.0/24 , 44.44.62.0/24
Jan 15 18:29:41.440461 BGP SEND
44.44.61.0/24 , 44.44.60.0/24 ,
44.44.59.0/24 , 44.44.58.0/24
Jan 15 18:29:41.440489 BGP SEND
44.44.57.0/24 , 44.44.56.0/24 ,
44.44.55.0/24 , 44.44.54.0/24
Jan 15 18:29:41.440516 BGP SEND
44.44.53.0/24 , 44.44.52.0/24 ,
44.44.51.0/24 , 44.44.50.0/24
Jan 15 18:29:41.440542 BGP SEND
44.44.49.0/24 , 44.44.48.0/24 ,
44.44.47.0/24 , 44.44.46.0/24
Jan 15 18:29:41.440566 BGP SEND
44.44.45.0/24 , 44.44.44.0/24 ,
44.44.43.0/24 , 44.44.42.0/24
Jan 15 18:29:41.440590 BGP SEND
44.44.41.0/24 , 44.44.40.0/24 ,
44.44.39.0/24 , 44.44.38.0/24
Jan 15 18:29:41.440708 BGP SEND
44.44.37.0/24 , 44.44.36.0/24 ,
44.44.35.0/24 , 44.44.34.0/24
Jan 15 18:29:41.440742 BGP SEND
44.44.33.0/24 , 44.44.32.0/24 ,
44.44.31.0/24 , 44.44.30.0/24
Jan 15 18:29:41.440770 BGP SEND
44.44.29.0/24 , 44.44.28.0/24 ,
14
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.
Yes, in this example, the trace output shows IBGP session teardown and
reestablishment:
lab@SanJose> clear bgp neighbor 192.168.18.1
Cleared 1 connections
lab@SanJose>
Jan 15 18:32:19.778275 bgp_peer_mgmt_clear:6270: NOTIFICATION sent to 192.168.18.1
(Internal AS 702): code 6 (Cease) subcode 4 (Administratively Reset), Reason:
Management session cleared BGP neighbor
Jan 15 18:32:19.778355 bgp_send: sending 21 bytes to 192.168.18.1 (Internal AS
702)
Jan 15 18:32:19.778383
Jan 15 18:32:19.778383 BGP SEND 192.168.20.1+59509 -> 192.168.18.1+179
Jan 15 18:32:19.778411 BGP SEND message type 3 (Notification) length 21
Jan 15 18:32:19.778540 BGP SEND Notification code 6 (Cease) subcode 4
(Administratively Reset)
Jan 15 18:32:25.372979 bgp_send: sending 19 bytes to 192.168.16.1 (Internal AS
702)
Jan 15 18:32:25.373065
Jan 15 18:32:25.373065 BGP SEND 192.168.20.1+63243 -> 192.168.16.1+179
15
Step 7.5
Stop monitoring the bgp log file.
STOP
16