
This lab is designed to help you understand BGP implementation and configuration on Cisco IOS routers. Additionally we will configure other BGP technologies such as route reflectors, route-maps, and security.
Learning Objectives:
- Understand and configure the following BGP commands:
- no synchronization
- bgp router-id
- bgp log-neighbor-changes
- neighbor
- network
- Next-Hop
- route-reflector-client
- send-community
- route-map
- no auto-summary
- default-originate
A route reflector (RR) is a network routing component. It offers an alternative to the logical full-mesh requirement of internal border gateway protocol (IBGP). A RR acts as a focal point for IBGP sessions. The purpose of the RR is concentration. Multiple BGP routers can peer with a central point, the RR – acting as a route reflector server – rather than peer with every other router in a full mesh. All the other IBGP routers become route reflector clients.
Route Maps:
Cisco routers implement a route policy using Route Maps. A route map can utilize access-lists, prefix-lists, as-path access lists, and community lists to create an effective route policy.
A route map consists of a series of statements that check to see if a route matches the policy, to permit or deny the route, and then possibly an additional series of commands to adjust the attributes or metrics of those routes.
Topology:
The lab has been formatted for GNS3 using four Cisco 3725 routers with c3725-adventerprisek9_ivs-mz.124-15.T13 IOS, although you can replace these routers with other routers of your choice with similar interfaces, and IOS. This lab can also be completed with real hardware with similar interfaces and IOS.
Lab:
- Without using peer groups, configure internal BGP on R1, R2, R3, and R4 as follows:
- Statically configure a BGP router ID using the router number, e.g. 1.1.1.1 for R1, etc.
- All routers should peer using their physical interface addresses.
- Configure hostnames and IP addressing on all routers as shown in the network drawing.
- R1 should peer to R2 and R3.
- R2 should peer to R1.
- R3 should peer to R1 and R4.
- R4 should peer to R3.
- All routers should use the TCP MD5 authentication password ‘CCNP’.
- BGP Hellos should be sent out every 5 seconds.
- All of the BGP speakers should advertise a Hold Time of 15 seconds.
- The COMMUNITIES attribute (standard) should be supported.
- Advertise the 150.1.1.0/24, 150.2.2.0, and 150.3.3.0/24 subnets on R1, R2, and R3 via BGP. These prefixes must be advertised with the standard community values listed below.
NOTE: You are NOT allowed to redistribute these prefixes into BGP. Additionally, you are NOT allowed to use outbound or inbound route-maps when completing this task.
- Ensure that the community values are displayed in ASN:kk (RFC 1997 – BGP Communities Attribute) format.
- Verify your configuration using the appropriate commands.
- Configure your network so that all 150.x.x.x/24 subnets can reach each other. You are NOT allowed to use any static routes in your solution. Additionally, you are NOT allowed to advertise or redistribute the 150.4.4.0/24 subnet into BGP on R4. Instead, consider other BGP features to complete this task. You are NOT allowed to configure R2 or R4. Additionally, you are NOT allowed to configure a dynamic routing protocol to complete this task.
- Next, verify your configuration using the appropriate commands as well as the extended ping function. All pings should work when the task is completed correctly.
Download this lab now to see more: GNS3 BGP Lab-1 (214.5 KiB, 1,847 hits)

after completing 1st task, advertising Lan interfaces on R1 R2 and R3. R4 should be able to see all advertise routes from R1 r2 and R3 ?