zNetLaB › Guided labs › Enterprise
iBGP route reflector — full mesh without the full mesh
Enterprise Advanced 3 devices 4 checked tasks 100 points Plan lab
iBGP will not re-advertise a route learned from one iBGP peer to another, so three routers in one AS need a full mesh — or a route reflector. Make the hub the reflector for two clients and check that a prefix one client originates arrives at the other, though they never peer. You build it in a browser, type real commands at each device, and every task below is
checked against the running configuration — so you find out it is wrong before anybody else does.
Open this lab in the simulator
The simulator runs in your browser with nothing to install. This lab is part of the full simulator: open it free for 7 days with a new account, then with a plan. It needs an account, which keeps your progress.
The scenario
iBGP will not re-advertise a route learned from one iBGP peer to another, so three routers in one AS need a full mesh — or a route reflector. Make the hub the reflector for two clients and check that a prefix one client originates arrives at the other, though they never peer.
Your role: a network engineer on the enterprise team. Level: Advanced Done when: all 4 goals show as passed (100 points).
Network status
Devices: 3 routers, cabled as drawn. No Layer 1 or Layer 2 faults: every link is connected and up. RR-Hub starts with addresses (G0/0 10.0.1.1/30, G0/1 10.0.2.1/30, L0 1.1.1.1/32) and OSPF 1 already configured. Client1 starts with addresses (G0/0 10.0.1.2/30, L0 2.2.2.2/32, L10 172.16.10.1/24) and OSPF 1 already configured. Client2 starts with addresses (G0/0 10.0.2.2/30, L0 3.3.3.3/32, L20 172.16.20.1/24) and OSPF 1 already configured. Known problems
The network worked and now does not: the scenario above says what users report. The cause is a configuration fault, not a cable. Find it with show commands (interfaces, routes, neighbours, running-config) before you change anything; fix only what is wrong. Goals
The hub peers with both clients (iBGP, AS 65000) (25 pts) Both clients are marked as route-reflector clients on the hub (25 pts) Client1 learns Client2’s prefix 172.16.20.0/24 (25 pts) Client2 learns Client1’s prefix 172.16.10.0/24 (25 pts) The activity, in order
The hub peers with both clients (iBGP, AS 65000) Why: BGP does nothing until the TCP session is Established. Active or Idle means a wrong AS number, no route to the peer, or a block. Verify with: show ip bgp summary Both clients are marked as route-reflector clients on the hub Why: This is the task that checks your configuration directly: the line must really be there, not just look right. Verify with: show running-config Client1 learns Client2’s prefix 172.16.20.0/24 Why: BGP only advertises what you tell it to AND what is in the routing table. Verify with: show ip bgp Client2 learns Client1’s prefix 172.16.10.0/24 Why: BGP only advertises what you tell it to AND what is in the routing table. Verify with: show ip bgp Tips
Work in the order given: later goals depend on the earlier ones. After every change, run the verify command before moving on; do not guess. Stuck? Read the verify output first. It names the interface, neighbour or route that is wrong. Common mistake: No IGP route to the loopbacks, so the session never forms Common mistake: Forgetting update-source Common mistake: Making a non-client a client and creating loops Why this matters
iBGP does not advertise a route learned from one iBGP peer to another, which forces a full mesh. A route reflector breaks that rule for its clients so n routers need n sessions, not n(n-1)/2.
What you will be able to do
Peer clients to a reflector using loopbacks with an IGP underneath
Mark neighbours as route-reflector clients
Verify a client learns the other client’s prefix without peering with it
The network
ISR 2911 — 3 devices in all, already cabled.
Gi0/0 10.0.1.1/30 Gi0/0 10.0.1.2/30 Gi0/1 10.0.2.1/30 Gi0/0 10.0.2.2/30 RR-Hub Client1 Client2 Drawn from this lab: devices, cables, ports and the addresses already set. Device Model Address already set
RR-Hub ISR 2911 configure it Client1 ISR 2911 configure it Client2 ISR 2911 configure it
Cabling
RR-Hub Gi0/0 ↔ Client1 Gi0/0 RR-Hub Gi0/1 ↔ Client2 Gi0/0
What is configured at the start
These are already configured when the lab opens — including, where this is a troubleshooting lab, the fault itself:
RR-Hub interface g0/0
ip address 10.0.1.1 255.255.255.252
no shutdown
exit
interface g0/1
ip address 10.0.2.1 255.255.255.252
no shutdown
exit
interface lo0
ip address 1.1.1.1 255.255.255.255
no shutdown
exit
router ospf 1
router-id 1.1.1.1
network 10.0.1.0 0.0.0.3 area 0
network 10.0.2.0 0.0.0.3 area 0
network 1.1.1.1 0.0.0.0 area 0 Client1 interface g0/0
ip address 10.0.1.2 255.255.255.252
no shutdown
exit
interface lo0
ip address 2.2.2.2 255.255.255.255
no shutdown
exit
interface lo10
ip address 172.16.10.1 255.255.255.0
no shutdown
exit
router ospf 1
router-id 2.2.2.2
network 10.0.1.0 0.0.0.3 area 0
network 2.2.2.2 0.0.0.0 area 0 Client2 interface g0/0
ip address 10.0.2.2 255.255.255.252
no shutdown
exit
interface lo0
ip address 3.3.3.3 255.255.255.255
no shutdown
exit
interface lo20
ip address 172.16.20.1 255.255.255.0
no shutdown
exit
router ospf 1
router-id 3.3.3.3
network 10.0.2.0 0.0.0.3 area 0
network 3.3.3.3 0.0.0.0 area 0 Tasks, and how each one is checked
Every task is decided by reading the live network — a neighbour in FULL, a ping that succeeds, a line in the running configuration — not by looking for a keyword you typed. The same command shows you what the lab sees.
# Task Pts How to verify it yourself
1 The hub peers with both clients (iBGP, AS 65000) 25 On RR-Hub: show ip bgp summary — neighbour 2.2.2.2 is Established. and On RR-Hub: show ip bgp summary — neighbour 3.3.3.3 is Established. 2 Both clients are marked as route-reflector clients on the hub 25 On RR-Hub: show running-config contains the line(s) matching neighbor 2\.2\.2\.2 route-reflector-client[\s\S]*neighbor 3\.3\.3\.3 route-reflector-client|neighbor 3\.3\.3\.3 route-reflector-client[\s\S]*neighbor 2\.2\.2\.2 route-reflector-client. 3 Client1 learns Client2’s prefix 172.16.20.0/24 25 On Client1: show ip bgp lists 172.16.20.0/24. 4 Client2 learns Client1’s prefix 172.16.10.0/24 25 On Client2: show ip bgp lists 172.16.10.0/24.
Stuck? Ask the coach
Tell the coach what you see or what you tried. It gives you a hint, not the answer, the way a senior engineer would. Included with a free trial or any plan.
Ask the coach
Common mistakes
No IGP route to the loopbacks, so the session never forms
Forgetting update-source
Making a non-client a client and creating loops
Reference solution
Try it yourself first — the lab checks your work either way. This is one configuration that makes every task pass, device by device:
RR-Hub router bgp 65000
bgp router-id 1.1.1.1
neighbor 2.2.2.2 remote-as 65000
neighbor 2.2.2.2 update-source lo0
neighbor 2.2.2.2 route-reflector-client
neighbor 3.3.3.3 remote-as 65000
neighbor 3.3.3.3 update-source lo0
neighbor 3.3.3.3 route-reflector-client
exit Client1 router bgp 65000
bgp router-id 2.2.2.2
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source lo0
network 172.16.10.0 mask 255.255.255.0
exit Client2 router bgp 65000
bgp router-id 3.3.3.3
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source lo0
network 172.16.20.0 mask 255.255.255.0
exit Where this is examined
CCNP ENARSI (iBGP), CCIE EI (BGP at scale), CCNP SP.
This lab practises these topics in the zNetLaB certification courses:
Related labs
Where to start
The lessons all guided labs plans
CCNA®, CCNP® and Cisco® are trademarks of Cisco Systems, Inc. zNetLaB is not affiliated with or endorsed by Cisco.