You are on page 1of 16

Juniper BGP lab exercise: BGP Peering

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:

Juniper BGP lab exercise: BGP Peering

Lab Diagram

Lab 1: BGP Peering POD A


AS 44

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

Hong Kong ge-0/0/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

10.0.x/24 = Physical Interfaces


192.168.x.y/32 = Loopback Interfaces
192.168.x/24 and 200.0.x/24 = Static (Customer) Routes

Juniper BGP lab exercise: BGP Peering

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

Part 1: Load reset configuration on your routers


Step 1.1
Familiarize yourself with the BGP Peering setup in the lab 1 diagram handout taking note of your
routers AS number and IBGP/EBGP peering relationships. You will configure 3x J-series routers.
Note that the topology includes some other ASs that contain other routers. You do NOT need to
configure those; they are already pre-configured to do their role. Feel free however to login into them
and look at your convenience.
Log into your assigned routers and go ahead and load the file lab1-bgp-start that is located in
the bgp/ directory of your device. This will give us a working baseline configuration on the devices.

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.
__________________________________________________________________

Juniper BGP lab exercise: BGP Peering

Part 2: Configure Your IGP (OSPF)


Step 2.1
You will begin configuring an IGP for your ASs as described in the lab topology diagram. OSPF will
be your choice.. Remember that OSPF should be configured only within each AS. To do so, make
sure that you only run the protocol on the core facing interfaces.
Be sure that you prevent IGP adjacency formation between AS boundaries by disabling your IGP on
the links that interconnect your router to EBGP peers (just do not run ospf on them).
Configure OSPF protocol on your device and include all participating interfaces on area 0. As a
reference, here you have a capture from the SanJose router. Once you are satisfied, go ahead and
commit your changes.

[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.
__________________________________________________________________

Juniper BGP lab exercise: BGP Peering

Part 3: Use Operational Commands to Verify IGP Operation


Step 3.1
Verify that all IGP adjacencies are correctly established.

Are the IGP adjacencies to your internal peers correctly established?

 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

*[OSPF/10] 02:56:13, metric 2


*[OSPF/10] 02:56:13, metric 1
*[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-TokyoHongKong which cost is 1 for each interface
__________________________________________________________________

Juniper BGP lab exercise: BGP Peering

Step 3.3

Fix the metric issue of serial interfaces

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.

lab@SanJose# edit ospf


[edit protocols ospf]
lab@SanJose# set area 0 interface se-1/0/0.0 metric 1
[edit protocols ospf]
lab@SanJose# show
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/3.0;
interface se-1/0/0.0 {
metric 1;
}
}
[edit protocols ospf]
lab@SanJose# commit
commit complete

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

lab@SanJose# run traceroute 192.168.16.1


traceroute to 192.168.16.1 (192.168.16.1), 30 hops max, 40 byte packets
1 192.168.16.1 (192.168.16.1) 7.522 ms 6.886 ms 4.886 ms
[edit protocols ospf]
lab@SanJose# run show route 192.168.16.1
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.16.1/32

*[OSPF/10] 00:03:04, metric 1


> via se-1/0/0.0

____________________________ 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.
__________________________________________________________________

Juniper BGP lab exercise: BGP Peering

Part 4: Configure Loopback-Based IBGP Peerings


Step 4.1
Configure your routers AS number in accordance with the values shown in the lab diagram on every
router of the topology. Here is an example taken from the SanJose router..

[edit protocols ospf]


lab@SanJose# top edit routing-options
[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
[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:

[edit protocols bgp group ibgp]


lab@SanJose# show
type internal;
local-address 192.168.20.1;

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.
__________________________________________________________________

Part 5: Configure EBGP Peerings


Step 5.1
Configure the EBGP peering sessions shown for your station to the physical address associated with
the external neighbor. Look at the lab diagram; every red arrow is an eBGP session that you have to
configure.

[edit protocols bgp group ibgp]


lab@SanJose# up
[edit protocols bgp]
lab@SanJose# edit group AS44
[edit protocols bgp group AS44]
lab@SanJose# set type external
[edit protocols bgp group AS44]
lab@SanJose# set neighbor 10.0.0.2
[edit protocols bgp group AS44]
lab@SanJose# set peer-as 44

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:

[edit protocols bgp group AS44]


lab@SanJose# up
[edit protocols bgp]
lab@SanJose# show
group ibgp {
type internal;
local-address 192.168.20.1;
neighbor 192.168.16.1;
neighbor 192.168.18.1;
}
group AS44 {
type external;

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.

[edit protocols bgp]


lab@SanJose# commit and-quit
commit complete
Exiting configuration mode

____________________________ Note__________________________
Repeat similar steps and bring up the relevant eBGP sessions on your other
assigned routers in the topology.
__________________________________________________________________

Part 6: Use Operational Commands to Verify BGP Operation


Step 6.1
Confirm that all of your IBGP and EBGP sessions are correctly established.

____________________________ 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

History Damp State


0

Pending
0

Juniper BGP lab exercise: BGP Peering

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

Flaps Last Up/Dwn

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.

Are any BGP routes present

 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

*[BGP/170] 02:54:09, localpref 100


AS path: 44 I
> to 10.0.0.2 via ge-0/0/2.0
*[BGP/170] 02:54:09, localpref 100
AS path: 44 I
> to 10.0.0.2 via ge-0/0/2.0
*[BGP/170] 02:54:09, localpref 100
AS path: 44 I
> to 10.0.0.2 via ge-0/0/2.0

Juniper BGP lab exercise: BGP Peering

Step 6.3
Display BGP group information for your ibgp group.

lab@SanJose> show bgp group ibgp


Group Type: Internal
AS: 702
Local AS: 702
Name: ibgp
Index: 0
Flags: <Export Eval>
Holdtime: 0
Total peers: 2
Established: 2
192.168.16.1+179
192.168.18.1+179
Trace options: detail open, detail update, detail keepalive
Trace file: /var/log/bgp size 131072 files 10
inet.0: 0/300/300/0

Step 6.4
Display BGP neighbor-specific information for one of your EBGP peers.

What hold-time has been negotiated with your neighbors?

 The default hold time is 90 seconds.

What is the session keepalive value?

 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

lab@SanJose> show bgp neighbor 10.0.0.2


Peer: 10.0.0.2+179 AS 44
Local: 10.0.0.1+50180 AS 702
Type: External
State: Established
Flags: <Sync>
Last State: OpenConfirm
Last Event: RecvKeepAlive
Last Error: None
Options: <Preference PeerAS Refresh>
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.5.1
Local ID: 192.168.20.1
Active Holdtime: 90
Keepalive Interval: 30
Peer index: 0
BFD: disabled, down
Local Interface: ge-0/0/2.0
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 44)
Peer does not support Addpath
Table inet.0 Bit: 10001
RIB State: BGP restart is complete
Send state: in sync
Active prefixes:
300
Received prefixes:
300
Accepted prefixes:
300
Suppressed due to damping:
0
Advertised prefixes:
0
Last traffic (seconds): Received 19
Sent 24
Checked 33
Input messages: Total 485
Updates 69
Refreshes 0
Octets 12965
Output messages: Total 440
Updates 25
Refreshes 0
Octets 9776
Output Queue[0]: 0
Trace options: detail open, detail update, detail keepalive
Trace file: /var/log/bgp size 131072 files 10

Part 7: Trace BGP


Step 7.1
Configure BGP tracing to a file called bgp. Flag update, open, and keepalive using the detail
switch.

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

Juniper BGP lab exercise: BGP Peering

[edit protocols bgp]


lab@SanJose# set traceoptions flag open detail
[edit protocols bgp]
lab@SanJose# set traceoptions flag keepalive detail

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>

What BGP message types are occurring?

 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:
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

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:
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

Juniper BGP lab exercise: BGP Peering

Jan 15 18:32:25.373099 BGP SEND message type 4 (KeepAlive) length 19


Jan 15 18:32:28.696874
Jan 15 18:32:28.696874 BGP RECV 10.0.0.2+179 -> 10.0.0.1+59416
Jan 15 18:32:28.696963 BGP RECV message type 4 (KeepAlive) length 19
Jan 15 18:32:28.697067 bgp_read_v4_message: done with 10.0.0.2 (External AS 44)
received 19 octets 0 updates 0 routes
Jan 15 18:32:36.800270 bgp_send: sending 19 bytes to 10.0.0.2 (External AS 44)
Jan 15 18:32:36.800358
Jan 15 18:32:36.800358 BGP SEND 10.0.0.1+59416 -> 10.0.0.2+179
Jan 15 18:32:36.800392 BGP SEND message type 4 (KeepAlive) length 19
Jan 15 18:32:40.267971
Jan 15 18:32:40.267971 BGP RECV 192.168.16.1+179 -> 192.168.20.1+63243
Jan 15 18:32:40.268135 BGP RECV message type 4 (KeepAlive) length 19
Jan 15 18:32:40.268214 bgp_read_v4_message: done with 192.168.16.1 (Internal AS
702) received 19 octets 0 updates 0 routes
Jan 15 18:32:50.984118 bgp_send: sending 19 bytes to 192.168.16.1 (Internal AS
702)
Jan 15 18:32:50.984204
Jan 15 18:32:50.984204 BGP SEND 192.168.20.1+63243 -> 192.168.16.1+179
Jan 15 18:32:50.984238 BGP SEND message type 4 (KeepAlive) length 19
Jan 15 18:32:51.788254 advertising graceful restart receiving-speaker-only
capability to neighbor 192.168.18.1 (Internal AS 702)
Jan 15 18:32:51.788415 bgp_send: sending 59 bytes to 192.168.18.1 (Internal AS
702)
Jan 15 18:32:51.788448
Jan 15 18:32:51.788448 BGP SEND 192.168.20.1+59025 -> 192.168.18.1+179
Jan 15 18:32:51.788477 BGP SEND message type 1 (Open) length 59
Jan 15 18:32:51.788498 BGP SEND version 4 as 702 holdtime 90 id 192.168.20.1
parmlen 30
Jan 15 18:32:51.788516 BGP SEND MP capability AFI=1, SAFI=1
Jan 15 18:32:51.788531 BGP SEND Refresh capability, code=128
Jan 15 18:32:51.788546 BGP SEND Refresh capability, code=2
Jan 15 18:32:51.788669 BGP SEND Restart capability, code=64, time=120, flags=
Jan 15 18:32:51.788699 BGP SEND 4 Byte AS-Path capability
...

Step 7.5
Stop monitoring the bgp log file.

lab@SanJose> monitor stop


lab@SanJose>

STOP

16

You have completed Lab 1 !