zNetLaB › Guided labs › Enterprise
eBGP through a transit AS 16 — 64527 to 65385 via 65015
Enterprise Advanced 3 devices 4 checked tasks 100 points Plan lab
Scenario — customer Nashik (AS 64527) reaches customer Jodhpur (AS 65385) only through transit provider AS 65015, already configured. Peer both customers with the provider (203.0.35.0/30 and 203.1.35.0/30), originate 198.19.15.0/24 at Nashik and 198.18.15.0/24 at Jodhpur, 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 Nashik (AS 64527) reaches customer Jodhpur (AS 65385) only through transit provider AS 65015, already configured. Peer both customers with the provider (203.0.35.0/30 and 203.1.35.0/30), originate 198.19.15.0/24 at Nashik and 198.18.15.0/24 at Jodhpur, 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-Nashik starts with addresses (G0/1 203.0.35.1/30, L0 198.19.15.1/24). Transit-65015 starts with addresses (G0/1 203.0.35.2/30, G0/2 203.1.35.1/30) and BGP 65015 already configured. Cust-Jodhpur starts with addresses (G0/1 203.1.35.2/30, L0 198.18.15.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) Nashik learns 198.18.15.0/24 through the transit (25 pts) Jodhpur learns 198.19.15.0/24 through the transit (25 pts)
The activity, in order
Both sessions to the transit are Established On Cust-Nashik, make the BGP session to 203.0.35.2 reach Established: neighbor <ip> remote-as <AS>, and a route to the peer’s address. On Cust-Jodhpur, make the BGP session to 203.1.35.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-Nashik must contain the line: network 198.19.15.0 mask 255.255.255.0. Type it in the right mode (global, interface or line) and check it appears. The configuration of Cust-Jodhpur must contain the line: network 198.18.15.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 Nashik learns 198.18.15.0/24 through the transit Advertise 198.18.15.0/24 from Cust-Nashik 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 Jodhpur learns 198.19.15.0/24 through the transit Advertise 198.19.15.0/24 from Cust-Jodhpur 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.35.1/30 Gi0/1 203.0.35.2/30 Gi0/2 203.1.35.1/30 Gi0/1 203.1.35.2/30 Cust-Nashik Transit-65015 Cust-Jodhpur Drawn from this lab: devices, cables, ports and the addresses already set.
Device Model Address already set
Cust-Nashik ISR 2911 configure it
Transit-65015 ISR 2911 configure it
Cust-Jodhpur ISR 2911 configure it
Cabling
Cust-Nashik Gi0/1 ↔ Transit-65015 Gi0/1
Transit-65015 Gi0/2 ↔ Cust-Jodhpur 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-Nashik interface g0/1
ip address 203.0.35.1 255.255.255.252
no shutdown
exit
interface lo0
ip address 198.19.15.1 255.255.255.0
no shutdown
exit
Cust-Jodhpur interface g0/1
ip address 203.1.35.2 255.255.255.252
no shutdown
exit
interface lo0
ip address 198.18.15.1 255.255.255.0
no shutdown
exit
Transit-65015 interface g0/1
ip address 203.0.35.2 255.255.255.252
no shutdown
exit
interface g0/2
ip address 203.1.35.1 255.255.255.252
no shutdown
exit
router bgp 65015
bgp router-id 2.2.2.2
neighbor 203.0.35.1 remote-as 64527
neighbor 203.1.35.2 remote-as 65385
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-Nashik: show ip bgp summary — neighbour 203.0.35.2 is Established. and On Cust-Jodhpur: show ip bgp summary — neighbour 203.1.35.1 is Established.
2 Each customer originates its own prefix 20 On Cust-Nashik: show running-config contains the line(s) matching network 198\.19\.15\.0 mask 255\.255\.255\.0. and On Cust-Jodhpur: show running-config contains the line(s) matching network 198\.18\.15\.0 mask 255\.255\.255\.0.
3 Nashik learns 198.18.15.0/24 through the transit 25 On Cust-Nashik: show ip bgp lists 198.18.15.0/24.
4 Jodhpur learns 198.19.15.0/24 through the transit 25 On Cust-Jodhpur: show ip bgp lists 198.19.15.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-Nashik router bgp 64527
bgp router-id 1.1.1.1
neighbor 203.0.35.2 remote-as 65015
network 198.19.15.0 mask 255.255.255.0
exit
Cust-Jodhpur router bgp 65385
bgp router-id 3.3.3.3
neighbor 203.1.35.1 remote-as 65015
network 198.18.15.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.