zNetLaB › Guided labs › Enterprise
eBGP through a transit AS 54 — 64565 to 65347 via 65013
Enterprise Advanced 3 devices 4 checked tasks 100 points Plan lab
Scenario — customer Ludhiana (AS 64565) reaches customer Lucknow (AS 65347) only through transit provider AS 65013, already configured. Peer both customers with the provider (203.0.73.0/30 and 203.1.73.0/30), originate 198.19.53.0/24 at Ludhiana and 198.18.53.0/24 at Lucknow, and show each customer learns the other's prefix through the transit. 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
customer Ludhiana (AS 64565) reaches customer Lucknow (AS 65347) only through transit provider AS 65013, already configured. Peer both customers with the provider (203.0.73.0/30 and 203.1.73.0/30), originate 198.19.53.0/24 at Ludhiana and 198.18.53.0/24 at Lucknow, and show each customer learns the other's prefix through the transit.
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. Cust-Ludhiana starts with addresses (G0/1 203.0.73.1/30, L0 198.19.53.1/24). Transit-65013 starts with addresses (G0/1 203.0.73.2/30, G0/2 203.1.73.1/30) and BGP 65013 already configured. Cust-Lucknow starts with addresses (G0/1 203.1.73.2/30, L0 198.18.53.1/24).
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
Both sessions to the transit are Established (30 pts) Each customer originates its own prefix (20 pts) Ludhiana learns 198.18.53.0/24 through the transit (25 pts) Lucknow learns 198.19.53.0/24 through the transit (25 pts)
The activity, in order
Both sessions to the transit are Established On Cust-Ludhiana, make the BGP session to 203.0.73.2 reach Established: neighbor <ip> remote-as <AS>, and a route to the peer’s address. On Cust-Lucknow, make the BGP session to 203.1.73.1 reach Established: neighbor <ip> remote-as <AS>, and a route to the peer’s address.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 Each customer originates its own prefix The configuration of Cust-Ludhiana must contain the line: network 198.19.53.0 mask 255.255.255.0. Type it in the right mode (global, interface or line) and check it appears. The configuration of Cust-Lucknow must contain the line: network 198.18.53.0 mask 255.255.255.0. Type it in the right mode (global, interface or line) and check it appears.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 Ludhiana learns 198.18.53.0/24 through the transit Advertise 198.18.53.0/24 from Cust-Ludhiana with the network command. The exact prefix and mask must already exist in the routing table.Why: BGP only advertises what you tell it to AND what is in the routing table. Verify with: show ip bgp Lucknow learns 198.19.53.0/24 through the transit Advertise 198.19.53.0/24 from Cust-Lucknow with the network command. The exact prefix and mask must already exist in the routing table.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: Neighbour address on the wrong side of the link Common mistake: A network statement with no matching route in the table Common mistake: Expecting customers to see each other without the transit
Why this matters
A transit AS carries customer routes for money: each customer peers with it, announces its own prefix, and learns every other customer's prefix back. The customers never peer with each other.
What you will be able to do
Peer two autonomous systems with a transit
Originate a prefix
Follow an AS path in show ip bgp
The network
ISR 2911 — 3 devices in all, already cabled.
Gi0/1 203.0.73.1/30 Gi0/1 203.0.73.2/30 Gi0/2 203.1.73.1/30 Gi0/1 203.1.73.2/30 Cust-Ludhiana Transit-65013 Cust-Lucknow Drawn from this lab: devices, cables, ports and the addresses already set.
Device Model Address already set
Cust-Ludhiana ISR 2911 configure it
Transit-65013 ISR 2911 configure it
Cust-Lucknow ISR 2911 configure it
Cabling
Cust-Ludhiana Gi0/1 ↔ Transit-65013 Gi0/1
Transit-65013 Gi0/2 ↔ Cust-Lucknow Gi0/1
What is configured at the start
These are already configured when the lab opens — including, where this is a troubleshooting lab, the fault itself:
Cust-Ludhiana interface g0/1
ip address 203.0.73.1 255.255.255.252
no shutdown
exit
interface lo0
ip address 198.19.53.1 255.255.255.0
no shutdown
exit
Cust-Lucknow interface g0/1
ip address 203.1.73.2 255.255.255.252
no shutdown
exit
interface lo0
ip address 198.18.53.1 255.255.255.0
no shutdown
exit
Transit-65013 interface g0/1
ip address 203.0.73.2 255.255.255.252
no shutdown
exit
interface g0/2
ip address 203.1.73.1 255.255.255.252
no shutdown
exit
router bgp 65013
bgp router-id 2.2.2.2
neighbor 203.0.73.1 remote-as 64565
neighbor 203.1.73.2 remote-as 65347
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 Both sessions to the transit are Established 30 On Cust-Ludhiana: show ip bgp summary — neighbour 203.0.73.2 is Established. and On Cust-Lucknow: show ip bgp summary — neighbour 203.1.73.1 is Established.
2 Each customer originates its own prefix 20 On Cust-Ludhiana: show running-config contains the line(s) matching network 198\.19\.53\.0 mask 255\.255\.255\.0. and On Cust-Lucknow: show running-config contains the line(s) matching network 198\.18\.53\.0 mask 255\.255\.255\.0.
3 Ludhiana learns 198.18.53.0/24 through the transit 25 On Cust-Ludhiana: show ip bgp lists 198.18.53.0/24.
4 Lucknow learns 198.19.53.0/24 through the transit 25 On Cust-Lucknow: show ip bgp lists 198.19.53.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
Neighbour address on the wrong side of the link
A network statement with no matching route in the table
Expecting customers to see each other without the transit
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:
Cust-Ludhiana router bgp 64565
bgp router-id 1.1.1.1
neighbor 203.0.73.2 remote-as 65013
network 198.19.53.0 mask 255.255.255.0
exit
Cust-Lucknow router bgp 65347
bgp router-id 3.3.3.3
neighbor 203.1.73.1 remote-as 65013
network 198.18.53.0 mask 255.255.255.0
exit
Where this is examined
CCNP ENARSI BGP; CCIE EI BGP.
This lab practises these topics in the zNetLaB certification courses:
Related labs
Where to start
The lessons are open to everyone, all guided labs are listed by track, and
plans explains what is free and what is not.
CCNA®, CCNP® and Cisco® are trademarks of Cisco Systems, Inc. zNetLaB is not affiliated with or endorsed by Cisco.