All guided builds

Guided buildadvanced23 steps~75 min10 devices

Enterprise capstone

The Module 8 capstone: build a two-site enterprise from bare devices — VLANs, an L3 switch, OSPF over the WAN, PAT to the provider, DHCP per site and SSH — verifying every layer before the next.

What you'll be able to do: A user at Site A leases an address, opens the file server in another VLAN, reaches a desk at Site B across the WAN and the internet behind one public address — and every router and switch on the way is managed over SSH. Saved as capstone.netforge.json, it is your practice benchmark for the Final Weighted Exam.

Start this build in the lab 10 devices — needs any paid plan (the free canvas fits 5).

Topics: VLANs · Trunking · Inter-VLAN routing · Layer 3 switching · OSPF · Default routes · NAT/PAT · DHCP · SSH

What you'll build

Step by step

  1. 1. Lay out Site A and cable it

    Drop Site A's six devices: a router, three switches, a PC and a server. The canvas calls them R1, SW1, PC1 and so on until you name them in step 3; the cable list already uses the names they are about to get. Edge-A is R1 in the chapter's diagram, PC-Users is PC1 and SRV-Files is SRV1. Cable the router's Gi0/1 to SW-Core's Fa0/1, SW-Core's Gi0/1 and Gi0/2 down to the two access switches, and the PC and the server into Fa0/1 on theirs. Configure nothing yet.

    • Cable Edge-A Gi0/1 ↔ SW-Core Fa0/1
    • Cable SW-Core Gi0/1 ↔ SW-A1 Gi0/1
    • Cable SW-Core Gi0/2 ↔ SW-A2 Gi0/1
    • Cable PC-Users Eth0 ↔ SW-A1 Fa0/1
    • Cable SRV-Files Eth0 ↔ SW-A2 Fa0/1

    Why: Bottom up means the physical layer first. Every fault you chase later — a VLAN that never reaches its gateway, an OSPF neighbour that never appears — is easier to find when you already know the cabling is right, because a cable in the wrong port looks exactly like a wrong config.

  2. 2. Lay out Site B, the WAN and the provider

    Drop Site B — a router (Edge-B, R2 in the diagram), a switch (SW-B) and a PC (PC-Branch, PC2) — and one more router for the provider (ISP). Join the two edge routers with a serial cable, Se0/0/0 to Se0/0/0: that is the WAN /30. Cable Edge-B's Gi0/0 to SW-B's Gi0/1 and the branch PC into Fa0/1, then run a second serial cable from Edge-A's Se0/0/1 to the provider's Se0/0/0.

    • Cable Edge-A Se0/0/0 ↔ Edge-B Se0/0/0 (serial)
    • Cable Edge-B Gi0/0 ↔ SW-B Gi0/1
    • Cable PC-Branch Eth0 ↔ SW-B Fa0/1
    • Cable Edge-A Se0/0/1 ↔ ISP Se0/0/0 (serial)

    Why: The chapter draws the provider as a cloud. Here it is a router you configure yourself, because the provider's end of the link needs an address for Edge-A's default route to point at. Everything past it stands for the internet.

  3. 3. Name Site A and lock privileged mode

    Give every Site A device its name and every router and switch an enable secret. Tell the switches apart by their cabling: SW-Core is the one cabled to the router, SW-A1 has the PC and SW-A2 the server. The PC and the server take their names in their own shells.

    On Edge-A — Name Site A's edge router and protect privileged mode

    enable
    configure terminal
    hostname Edge-A
    enable secret NetForge123!
    end

    On SW-Core — Name the distribution switch and protect privileged mode

    enable
    configure terminal
    hostname SW-Core
    enable secret NetForge123!
    end

    On SW-A1 — Name the Users access switch and protect privileged mode

    enable
    configure terminal
    hostname SW-A1
    enable secret NetForge123!
    end

    On SW-A2 — Name the Servers access switch and protect privileged mode

    enable
    configure terminal
    hostname SW-A2
    enable secret NetForge123!
    end

    On PC-Users — Name the user's desktop

    hostname PC-Users

    On SRV-Files — Name the file server

    hostname SRV-Files

    Check: run show running-config on Edge-A and look for hostname Edge-A.

    Why: Names are how you know which console you are in, and every log line and SSH key later is stamped with one. The enable secret is the first lock on a device: without it, anyone who reaches a console reaches privileged mode.

  4. 4. Name Site B

    Same again at the branch: the router cabled to SW-B becomes Edge-B, the switch becomes SW-B and the PC becomes PC-Branch. Leave the provider's router alone for now — it is not yours. You name and configure it when Site A connects to it.

    On Edge-B — Name Site B's edge router and protect privileged mode

    enable
    configure terminal
    hostname Edge-B
    enable secret NetForge123!
    end

    On SW-B — Name the branch switch and protect privileged mode

    enable
    configure terminal
    hostname SW-B
    enable secret NetForge123!
    end

    On PC-Branch — Name the branch desktop

    hostname PC-Branch

    Check: run show running-config on SW-B and look for hostname SW-B.

    Why: A consistent naming scheme — site, then role — means every show command's output tells you where you are without looking at the canvas, which is exactly what you need when reading the exam's exhibits.

  5. 5. Create Site A's VLANs on SW-Core and trunk it to the closets

    SW-Core is the hub of Site A, so it gets the VLAN database first: VLAN 10 Users and VLAN 20 Servers. Its two Gi ports go down to the access switches as 802.1Q trunks with an explicit allowed list, and Fa0/1 — the port Edge-A plugs into — is an access port in VLAN 10, because Edge-A's LAN leg lives in the Users subnet.

    On SW-Core — VLANs 10 and 20, two trunks to the access switches, and Edge-A's port in VLAN 10

    enable
    configure terminal
    vlan 10
    name Users
    exit
    vlan 20
    name Servers
    exit
    interface Gi0/1
    switchport mode trunk
    switchport trunk allowed vlan 10,20
    exit
    interface Gi0/2
    switchport mode trunk
    switchport trunk allowed vlan 10,20
    exit
    interface Fa0/1
    switchport mode access
    switchport access vlan 10
    exit
    end

    Check: run show interfaces trunk on SW-Core and look for Gi0/2 on 802.1q trunking 1.

    Why: An explicit allowed list means a VLAN you create later does not silently start crossing every trunk — you decide which closets carry it. Edge-A's port is an access port, not a trunk: a router port with an address and no subinterfaces sends untagged frames, so to the switch it is one more host in VLAN 10.

  6. 6. Configure the two access switches

    Each closet switch needs the same VLAN database, a trunk up to SW-Core on Gi0/1 allowing the same VLANs, and its host port in the right VLAN. PC-Users is a user, so SW-A1's Fa0/1 goes in VLAN 10; SRV-Files is a server, so SW-A2's Fa0/1 goes in VLAN 20.

    On SW-A1 — VLANs, the trunk up to SW-Core, and the user port in VLAN 10

    enable
    configure terminal
    vlan 10
    name Users
    exit
    vlan 20
    name Servers
    exit
    interface Gi0/1
    switchport mode trunk
    switchport trunk allowed vlan 10,20
    exit
    interface Fa0/1
    switchport mode access
    switchport access vlan 10
    exit
    end

    On SW-A2 — VLANs, the trunk up to SW-Core, and the server port in VLAN 20

    enable
    configure terminal
    vlan 10
    name Users
    exit
    vlan 20
    name Servers
    exit
    interface Gi0/1
    switchport mode trunk
    switchport trunk allowed vlan 10,20
    exit
    interface Fa0/1
    switchport mode access
    switchport access vlan 20
    exit
    end

    Check: run show vlan brief on SW-A2 and look for 20 Servers active Fa0/1.

    Why: A VLAN is a broadcast domain that spans switches only where trunks carry it. Giving every switch the same VLAN numbers is what makes VLAN 20 on SW-A2 and VLAN 20 on SW-Core one network; the names are only labels for humans.

  7. 7. Give Site B its VLAN

    The branch is one switch and one VLAN: create VLAN 30 Branch on SW-B and put both ports in it — Fa0/1 for PC-Branch and Gi0/1, the uplink to Edge-B. No trunk here: Edge-B's Gi0/0 is a plain routed port that sends untagged frames, so the switch side is an access port too.

    On SW-B — VLAN 30, with the PC port and the router uplink as access ports in it

    enable
    configure terminal
    vlan 30
    name Branch
    exit
    interface Gi0/1
    switchport mode access
    switchport access vlan 30
    exit
    interface Fa0/1
    switchport mode access
    switchport access vlan 30
    exit
    end

    Check: run show vlan brief on SW-B and look for 30 Branch active Fa0/1, Gi0/1.

    Why: A trunk is only needed where one cable carries more than one VLAN. Site B has a single VLAN and a router with a single untagged LAN port, so two access ports in VLAN 30 are the whole design.

  8. 8. Turn SW-Core into Site A's router

    Turn on `ip routing`, give SW-Core an SVI in each VLAN — 192.168.10.1 for Users, 192.168.20.1 for Servers — and a default route to Edge-A's LAN leg, 192.168.10.254, which you address in the next step. Then give the file server its fixed address, 192.168.20.10, with SW-Core as its gateway: servers do not take leases.

    On SW-Core — Route between the VLANs and send everything else to Edge-A

    enable
    configure terminal
    ip routing
    interface Vlan10
    ip address 192.168.10.1 255.255.255.0
    no shutdown
    exit
    interface Vlan20
    ip address 192.168.20.1 255.255.255.0
    no shutdown
    exit
    ip route 0.0.0.0 0.0.0.0 192.168.10.254
    end

    On SRV-Files — A fixed address in the Servers VLAN, with SW-Core as the gateway

    ipconfig Eth0 192.168.20.10 255.255.255.0 192.168.20.1

    On SRV-Files — Reach the Users-VLAN gateway across SW-Core

    ping 192.168.10.1

    Check: run show ip route on SW-Core and look for S* 0.0.0.0/0 via 192.168.10.254, Vlan10.

    Why: An SVI is a routed interface into a whole VLAN, so the gateway for every host in VLAN 20 lives inside the switch they plug into — no hairpin up a cable to a router. `ip routing` is what lets the switch forward between its SVIs; without it they are only management addresses.

  9. 9. Address Edge-A's LAN leg and tell it where VLAN 20 lives

    Edge-A's Gi0/1 joins VLAN 10 as 192.168.10.254 — the next hop SW-Core's default route already points at. Edge-A learns 192.168.10.0/24 from that port, but VLAN 20 lives behind SW-Core, so add a static route: 192.168.20.0/24 via 192.168.10.1. Then ping Edge-A from the file server.

    On Edge-A — Open the LAN leg and route the Servers VLAN via SW-Core

    enable
    configure terminal
    interface Gi0/1
    ip address 192.168.10.254 255.255.255.0
    no shutdown
    exit
    ip route 192.168.20.0 255.255.255.0 192.168.10.1
    end

    On SRV-Files — Reach Edge-A across SW-Core

    ping 192.168.10.254

    Check: run show ip route on Edge-A and look for S 192.168.20.0/24 via 192.168.10.1, Gi0/1.

    Why: A router knows only its own connected networks until something tells it more. SW-Core owns VLAN 20, so Edge-A needs a route to it — and once OSPF is running, it carries that same static route to Site B. The reply leg is what this ping proves: SW-Core routed the request out of VLAN 20, and Edge-A routed the answer back.

  10. 10. Bring up the WAN /30 between the sites

    Number the serial link 10.0.0.0/30: Edge-A is 10.0.0.1 and Edge-B 10.0.0.2 — a /30 holds exactly the two addresses a point-to-point link needs. While you are on Edge-B, give its LAN leg Gi0/0 the branch gateway address, 192.168.30.1. Then ping across the WAN from Edge-A.

    On Edge-A — Site A's end of the WAN

    enable
    configure terminal
    interface Se0/0/0
    ip address 10.0.0.1 255.255.255.252
    no shutdown
    exit
    end

    On Edge-B — Site B's end of the WAN and the branch gateway

    enable
    configure terminal
    interface Se0/0/0
    ip address 10.0.0.2 255.255.255.252
    no shutdown
    exit
    interface Gi0/0
    ip address 192.168.30.1 255.255.255.0
    no shutdown
    exit
    end

    On Edge-A — Ping across the WAN

    ping 10.0.0.2

    Check: run show ip interface brief on Edge-B and look for Se0/0/0 10.0.0.2 YES manual up up.

    Why: A /30 leaves two host addresses — one per end — so a WAN link wastes no address space. Up/up on both serial ports means the link and the addressing are right, and only then is it worth starting a routing protocol across it.

  11. 11. Run OSPF area 0 across the WAN

    Start OSPF process 1 on both edge routers and enable it on the networks each one has an interface in: the WAN /30 (wildcard 0.0.0.3) and its own LAN (0.0.0.255). Make the LAN legs passive so no hellos go towards the hosts. The two routers become neighbours over the serial link and each learns the other's LAN.

    On Edge-A — OSPF on the WAN and VLAN 10, passive towards the LAN

    enable
    configure terminal
    router ospf 1
    network 10.0.0.0 0.0.0.3 area 0
    network 192.168.10.0 0.0.0.255 area 0
    passive-interface Gi0/1
    end

    On Edge-B — OSPF on the WAN and VLAN 30, passive towards the LAN

    enable
    configure terminal
    router ospf 1
    network 10.0.0.0 0.0.0.3 area 0
    network 192.168.30.0 0.0.0.255 area 0
    passive-interface Gi0/0
    end

    Check: run show ip route on Edge-B and look for O 192.168.10.0/24 [110/65] via 10.0.0.1, Se0/0/0.

    Why: The wildcard mask is the inverse of the subnet mask: 0.0.0.3 for a /30, 0.0.0.255 for a /24. A `network` line selects the router's own interfaces, which is why Edge-A cannot `network` VLAN 20 — it has no interface in it. Passive interfaces are still advertised; they just never form a neighbour.

  12. 12. Redistribute the static route so Site B can reach VLAN 20

    Site B knows VLAN 10 now, but not VLAN 20: it lives on SW-Core, and only Edge-A's static route knows where. `redistribute static subnets` under OSPF on Edge-A injects that static route into the area, and Edge-B installs it as an external route. Ping the branch gateway from the file server to prove the round trip.

    On Edge-A — Inject the VLAN 20 static route into OSPF

    enable
    configure terminal
    router ospf 1
    redistribute static subnets
    end

    On SRV-Files — Reach Site B's gateway from the server VLAN

    ping 192.168.30.1

    Check: run show ip route on Edge-B and look for O E2 192.168.20.0/24 [110/20] via 10.0.0.1, Se0/0/0.

    Why: Redistribution is how a route OSPF did not discover becomes one it advertises. Edge-B marks it E2 — external — because it came from outside OSPF, and the server's ping proves both directions: Edge-B now has a route back to 192.168.20.10.

  13. 13. Connect the provider and point Site A at it

    Configure the provider's router: name it ISP, give its serial port 203.0.113.1/30 and put 8.8.8.8 on a loopback, standing in for a host out on the internet. Then give Edge-A the public end of the link, 203.0.113.2, and a default route to the provider. Edge-A can now reach 8.8.8.8.

    On ISP — Stand up the provider: its end of the link and an internet address

    enable
    configure terminal
    hostname ISP
    interface Se0/0/0
    ip address 203.0.113.1 255.255.255.252
    no shutdown
    exit
    interface Loopback0
    ip address 8.8.8.8 255.255.255.255
    exit
    end

    On Edge-A — Take the public /30 and send everything unknown to the provider

    enable
    configure terminal
    interface Se0/0/1
    ip address 203.0.113.2 255.255.255.252
    no shutdown
    exit
    ip route 0.0.0.0 0.0.0.0 203.0.113.1
    end

    On Edge-A — Reach the internet from the edge

    ping 8.8.8.8

    Check: run show ip route on Edge-A and look for S* 0.0.0.0/0 via 203.0.113.1, Se0/0/1.

    Why: An edge router cannot hold a route for every network on the internet, so it holds its own networks plus one route that matches everything else. The provider's router is the one device here you would never configure in real life — its side of the link is handed to you.

  14. 14. Share the default route with Site B

    Edge-B still has no way to the internet: a static default lives in one router's table. `default-information originate` under OSPF on Edge-A advertises it into area 0, and Edge-B installs an O*E2 0.0.0.0/0 pointing back across the WAN.

    On Edge-A — Advertise Edge-A's default route into OSPF

    enable
    configure terminal
    router ospf 1
    default-information originate
    end

    Check: run show ip route on Edge-B and look for O*E2 0.0.0.0/0 [110/1] via 10.0.0.1, Se0/0/0.

    Why: Typed once at the edge and learned everywhere else, the default follows the network as it grows: the next router added to area 0 gets it for free, and if Edge-A's default ever changes, nobody else needs touching.

  15. 15. Try the internet from inside — and get nowhere

    Ping 8.8.8.8 from the file server. Every router on the way has a route, and the request does reach the provider — but it carries the source 192.168.20.10, a private address, and the provider has no route back to it. Edge-A's own ping still works, because it leaves from 203.0.113.2.

    On SRV-Files — Try the internet from the server VLAN

    ping 8.8.8.8

    Check: run show ip route on ISP and look for C 203.0.113.0/30 is directly connected, Se0/0/0.

    Why: Private addresses are reused by millions of networks at once, so the internet does not route them — a reply would have no single place to go. Something has to rewrite the source to a public address on the way out, and that is NAT's job.

  16. 16. PAT both sites onto Edge-A's public address

    Mark the NAT boundary on Edge-A: Gi0/1 (Site A) and Se0/0/0 (the WAN, where Site B's traffic arrives) are inside, Se0/0/1 to the provider is outside. A standard ACL, NAT_INSIDE, lists the three LANs allowed out, and one overload rule translates them all to 203.0.113.2. Ping 8.8.8.8 from the server again.

    On Edge-A — Inside, outside, the NAT_INSIDE list and the overload rule

    enable
    configure terminal
    interface Gi0/1
    ip nat inside
    exit
    interface Se0/0/0
    ip nat inside
    exit
    interface Se0/0/1
    ip nat outside
    exit
    ip access-list standard NAT_INSIDE
    permit 192.168.10.0 0.0.0.255
    permit 192.168.20.0 0.0.0.255
    permit 192.168.30.0 0.0.0.255
    exit
    ip nat inside source list NAT_INSIDE interface Se0/0/1 overload
    end

    On SRV-Files — The internet, translated

    ping 8.8.8.8

    Check: run show ip nat translations on Edge-A and look for icmp 203.0.113.2:1024 192.168.20.10:1024 8.8.8.8.

    Why: NAT roles belong to interfaces: traffic routed from an inside interface out of an outside one is translated, if the ACL matches its source. Site B has no provider link of its own, so its traffic reaches the internet through Edge-A — which is why the WAN port is inside too, and 192.168.30.0 is on the list.

  17. 17. Serve Site A's users from a pool on Edge-A

    Edge-A's Gi0/1 sits in VLAN 10, so it can serve that VLAN directly. Exclude .1 to .10 — the gateway and the infrastructure addresses — then build pool VLAN10, handing out SW-Core's 192.168.10.1 as the default router and 8.8.8.8 as DNS. PC-Users asks for an address and tries the internet.

    On Edge-A — Reserve the low addresses, then serve the Users subnet

    enable
    configure terminal
    ip dhcp excluded-address 192.168.10.1 192.168.10.10
    ip dhcp pool VLAN10
    network 192.168.10.0 255.255.255.0
    default-router 192.168.10.1
    dns-server 8.8.8.8
    exit
    end

    On PC-Users — Lease an address, then reach the internet

    ipconfig /renew
    ping 8.8.8.8

    Check: run show ip dhcp binding on Edge-A and look for 192.168.10.11.

    Why: A DISCOVER is a broadcast, and broadcasts stay inside their VLAN. Edge-A is a member of VLAN 10, so the request reaches it directly. The gateway it hands out is SW-Core's SVI, not Edge-A itself, because SW-Core is the router for this VLAN.

  18. 18. Serve the branch from a pool on Edge-B

    Same on Edge-B for VLAN 30: exclude .1 to .50 for the branch's infrastructure, build pool VLAN30 with Edge-B's 192.168.30.1 as the default router and 8.8.8.8 as DNS, then let PC-Branch lease — and reach PC-Users at Site A and the internet beyond Edge-A.

    On Edge-B — Reserve the low addresses, then serve the branch subnet

    enable
    configure terminal
    ip dhcp excluded-address 192.168.30.1 192.168.30.50
    ip dhcp pool VLAN30
    network 192.168.30.0 255.255.255.0
    default-router 192.168.30.1
    dns-server 8.8.8.8
    exit
    end

    On PC-Branch — Lease an address, then reach Site A and the internet

    ipconfig /renew
    ping 192.168.10.11
    ping 8.8.8.8

    Check: run show ip dhcp binding on Edge-B and look for 192.168.30.51.

    Why: Each edge router serves its own LAN, so a WAN outage never stops the other site's desks from leasing. With OSPF, the redistributed static and the shared default in place, a fresh lease is all PC-Branch needs to reach both VLANs at Site A and the internet.

  19. 19. Give the access switches a management address

    SSH needs an address to connect to, and SW-A1, SW-A2 and SW-B have none — they only switch. Give each a management SVI in its own VLAN, from the addresses the DHCP pools exclude (192.168.10.2, 192.168.20.2, 192.168.30.2), and an `ip default-gateway` so its replies can leave the subnet.

    On SW-A1 — A management address in VLAN 10 and a way home

    enable
    configure terminal
    interface Vlan10
    ip address 192.168.10.2 255.255.255.0
    no shutdown
    exit
    ip default-gateway 192.168.10.1
    end

    On SW-A2 — A management address in VLAN 20 and a way home

    enable
    configure terminal
    interface Vlan20
    ip address 192.168.20.2 255.255.255.0
    no shutdown
    exit
    ip default-gateway 192.168.20.1
    end

    On SW-B — A management address in VLAN 30 and a way home

    enable
    configure terminal
    interface Vlan30
    ip address 192.168.30.2 255.255.255.0
    no shutdown
    exit
    ip default-gateway 192.168.30.1
    end

    Check: run show running-config on SW-A1 and look for ip default-gateway 192.168.10.1.

    Why: Switching needs no IP address at all; managing the switch does. The SVI is the switch's own address, and the default gateway is what lets it answer an admin on another subnet — reach without a way back is no reach at all.

  20. 20. SSH on both edge routers

    SSH needs four things on each device: a hostname (step 3 did that), a domain name, an RSA key named after the two, and VTY lines that accept SSH and nothing else. Add a local account for the lines to check, and type the same block on Edge-A and Edge-B.

    On Edge-A — Domain, RSA key, SSH version 2, a local account and SSH-only VTY lines

    enable
    configure terminal
    ip domain-name netforge.lab
    crypto key generate rsa modulus 2048
    ip ssh version 2
    username netadmin privilege 15 secret Forge-Admin-26
    line vty 0 4
    login local
    transport input ssh
    end

    On Edge-B — The same SSH baseline on the branch router

    enable
    configure terminal
    ip domain-name netforge.lab
    crypto key generate rsa modulus 2048
    ip ssh version 2
    username netadmin privilege 15 secret Forge-Admin-26
    line vty 0 4
    login local
    transport input ssh
    end

    Check: run show ip ssh on Edge-A and look for SSH Enabled - version 2.0.

    Why: Telnet sends every keystroke, passwords included, in clear text; SSH encrypts the session. `transport input ssh` is what actually closes the Telnet door, and `login local` makes each admin log in as themselves.

  21. 21. SSH on every switch, then log in across the WAN

    Type the same baseline on the four switches — a switch has sixteen VTY lines, so lock them all with `line vty 0 15`. Then prove it works: from Edge-B's console, SSH to SW-A1 at Site A as netadmin, run a show command on it, and exit.

    On SW-Core — The SSH baseline on the distribution switch

    enable
    configure terminal
    ip domain-name netforge.lab
    crypto key generate rsa modulus 2048
    ip ssh version 2
    username netadmin privilege 15 secret Forge-Admin-26
    line vty 0 15
    login local
    transport input ssh
    end

    On SW-A1 — The SSH baseline on the Users access switch

    enable
    configure terminal
    ip domain-name netforge.lab
    crypto key generate rsa modulus 2048
    ip ssh version 2
    username netadmin privilege 15 secret Forge-Admin-26
    line vty 0 15
    login local
    transport input ssh
    end

    On SW-A2 — The SSH baseline on the Servers access switch

    enable
    configure terminal
    ip domain-name netforge.lab
    crypto key generate rsa modulus 2048
    ip ssh version 2
    username netadmin privilege 15 secret Forge-Admin-26
    line vty 0 15
    login local
    transport input ssh
    end

    On SW-B — The SSH baseline on the branch switch

    enable
    configure terminal
    ip domain-name netforge.lab
    crypto key generate rsa modulus 2048
    ip ssh version 2
    username netadmin privilege 15 secret Forge-Admin-26
    line vty 0 15
    login local
    transport input ssh
    end

    On Edge-B — Log in to SW-A1 over SSH (the second line is netadmin's password), look, and leave

    ssh -l netadmin 192.168.10.2
    Forge-Admin-26
    show ip ssh
    exit

    Check: run show running-config | section line on SW-A1 and look for line vty 5 15.

    Why: Every managed device gets the same baseline, so there is no weak one to walk in through. Securing only lines 0 to 4 on a switch is a classic miss: lines 5 to 15 keep their old settings for whoever finds them. The login from Edge-B crosses the WAN, Edge-A and SW-Core — management traffic rides the network you just built.

  22. 22. Verify end to end, layer by layer

    Walk the build in the order you made it, on Edge-A: the routing table, the OSPF neighbour, the DHCP binding, and the NAT translations your earlier pings left behind. Then ping PC-Branch (192.168.30.51) from PC-Users — VLAN 10, SW-Core, Edge-A, the WAN, Edge-B, SW-B. Nothing changes here; you are reading the network you built.

    On Edge-A — Routes, the neighbour, the lease and the translations

    enable
    show ip route
    show ip ospf neighbor
    show ip dhcp binding
    show ip nat translations

    On PC-Users — Cross-site, end to end

    ping 192.168.30.51

    Check: run show ip nat translations on Edge-A and look for icmp 203.0.113.2:1026 192.168.30.51:1026 8.8.8.8.

    Why: Each command proves one layer: `show ip route` that the routes exist, `show ip ospf neighbor` that OSPF is FULL, the binding that DHCP leased, the translations that PAT rewrote both sites' traffic to one public address. A ping only says yes or no; the show commands say where.

  23. 23. Save it as capstone.netforge.json

    Click Export in the lab toolbar: it downloads the whole canvas — every device, cable and configuration — as a .netforge.json file. Rename it capstone.netforge.json and keep it; Import, in the same toolbar, loads it back. Signed in, Save also keeps a copy in your account under any name you choose.

    Why: This topology is your benchmark: rebuild it from scratch until the build order is automatic, and reload the saved copy whenever you want to rehearse troubleshooting on a network you know is right.

The theory behind it

Build it for real

The lab walks you through these steps and ticks each one off as your network starts working.

Open in the lab