Lab1 BGP Exercise BGP Peering

8/15/2019 Lab1 BGP Exercise BGP Peering

1/16

Juniper BGP lab exercise: BGP Peering

1

LLaabb 11 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 takesas a configuration example POD A but this just a reference. If you have been assigned a differentPOD 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:


2/16


2

Lab Diagram

Lab 1: BGP Peering POD A

AS 77

AS 666

E-BGP

I-BGP

AS 702

AS 44

Denver

Sydney

Hong Konglo0: 192.168.16.1

San Joselo0: 192.168.20.1

lo0: 192.168.5.1

ge-0/0/10.2

ge-0/0/2

0.1

ge-0 / 0 / 215.2

g e - 0 / 0 / 1 2 1 .1

s e - 1 / 0 / 1

1 6 . 1

ge-0 / 0 / 2 15.1

s e - 1 / 0 / 0

1 6 . 2

g e - 0 / 0 / 1 2 1 .2

Tokyolo0: 192.168.18.1

Sao Paulo

DCE

g e - 0 /

0 / 3

2 2. 1

Vlan 674 2 2

. 2

g e - 0 / 0 / 3

lo0: 192.168.12.1

10.0.x /24 = Physical Interfaces

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


3/16


3

Key Commands

Key operational mode commands used in this lab include the following:

show interfacesshow route

show ospf interfaces

show ospf neighborsshow bgp neighbor

show bgp summaryshow routeshow route protocol ospf

Part 1: Load reset configuration on your routers

Step 1.1Familiarize yourself with the BGP Peering setup in the lab 1 diagram handout taking note of your

router’s 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 configuredon 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 thetopology.

__________________________________________________________________


4/16


4

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 willbe 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 yourconfiguration 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 OSPFdomains on each respective AS.

__________________________________________________________________


5/16


5

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 Interface State ID Pri Dead

10.0.22.1 ge-0/0/3.0 Full 192.168.18.1 128 37

10.0.16.1 se-1/0/0.0 Full 192.168.16.1 128 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 *[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 ofinterface) 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

__________________________________________________________________


6/16


6

Step 3.3 Fix the metric issue of serial interfaces

Enter the following command on all routers with serial interfaces participating in OSPF. Please notethis 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


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;

}

}


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


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, youshould not proceed until you have confirmed that your AS’s IGP is operational. __________________________________________________________________


7/16


7

Part 4: Configure Loopback-Based IBGP Peerings

Step 4.1

Configure your router’s 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..


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 yourautonomous 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 station’s

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


lab@SanJose# set local-address 192.168.20.1


lab@SanJose# set neighbor 192.168.18.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:


lab@SanJose# show

type internal;

local-address 192.168.20.1;


8/16


8

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


lab@SanJose# up

[edit protocols bgp]

lab@SanJose# edit group AS44

[edit protocols bgp group AS44]

lab@SanJose# set type external




lab@SanJose# set peer-as 44

Step 5.2

When complete, your EBGP peer definition should be similar to this example taken from theSanJose station. Note how this configuration places the EBGP neighbors into separate EBGP peer

groups:

[edit protocols bgp group AS44]lab@SanJose# up


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;


9/16


9

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.



commit complete

Exiting configuration mode

____________________________ Note__________________________

Repeat similar steps and bring up the relevant eBGP sessions on your otherassigned 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 History Damp State Pending

inet.0

611 307 0 0 0 0


10/16


10

Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn

State|#Active/Received/Accepted/Damped...

10.0.0.2 44 473 428 0 0 3:02:02

300/300/300/0 0/0/0/0

192.168.16.1 702 553 555 0 0 3:29:51

0/300/300/0 0/0/0/0

192.168.18.1 702 478 546 0 0 3:29:47

0/0/0/0 0/0/0/0

♦ 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 0routes 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 *[BGP/170] 02:54:09, localpref 100

AS path: 44 I> to 10.0.0.2 via ge-0/0/2.0

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

AS path: 44 I

> to 10.0.0.2 via ge-0/0/2.0

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

AS path: 44 I

> to 10.0.0.2 via ge-0/0/2.0

...


11/16


11

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:

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.4Display 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 thatof the session’s hold time.

♦ What NLRI has been negotiated for this session? Does the peer support BGPrefresh?

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 179and 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.


12/16


12

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: Last State: OpenConfirm Last Event: RecvKeepAlive

Last Error: None

Options:

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: 300Peer 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: 0Advertised 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


lab@SanJose# set traceoptions file bgp


lab@SanJose# set traceoptions flag update detail


13/16


13


lab@SanJose# set traceoptions flag open detail


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:



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.085993Jan 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: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.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 router’s iBGP sessions while monitoring the bgp log file.

♦ According to the tracing output, did the soft clear tear down the BGP session?


14/16


14

No, a soft clear uses the BGP refresh capability to request that a peer readvertise all ofits 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>


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 413Jan 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 ,


15/16


15

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


702)

Jan 15 18:29:41.445457Jan 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


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)


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


16/16


16


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 19Jan 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: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.268214 bgp_read_v4_message: done with 192.168.16.1 (Internal AS

702) received 19 octets 0 updates 0 routes


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:51.788254 advertising graceful restart receiving-speaker-only

capability to neighbor 192.168.18.1 (Internal AS 702)


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 You have completed Lab 1 !

Documents

Lab1 BGP Exercise BGP Peering