I use this file as an evidence map for the Packet Tracer LAN. It links the design claims in the README to configuration authority and saved simulator outputs.
This is not a production certification record. The configuration exports establish what was configured; the screenshots record selected Packet Tracer observations captured during the lab. Where a behavior was not independently re-run or does not have a dedicated saved artifact, I state that boundary explicitly.
For each control I distinguish between:
- Configuration authority — what the exported device configurations establish.
- Saved operational evidence — Packet Tracer output captured in the repository.
- Supported conclusion — the narrow claim the available evidence can support.
- Boundary — what I do not claim from that evidence.
Configuration authority
- VLANs 10, 20, 30, 40, 50, 60, 70 and 999 are defined across the switching layer.
- Trunks use VLAN 999 as the native VLAN and explicitly allow VLANs 10–70.
Saved operational evidence
Screenshots/VLAN_Trunks/asw1-show-vlan-brief.pngScreenshots/VLAN_Trunks/asw1-trunk.pngScreenshots/VLAN_Trunks/asw2-trunk.pngScreenshots/VLAN_Trunks/core1-show-vlan-brief.pngScreenshots/VLAN_Trunks/core1-trunk-active.pngScreenshots/VLAN_Trunks/core2-trunk.png
Supported conclusion: the VLAN and trunk design is present in the exported configurations and corresponding Packet Tracer state was captured.
Boundary: this does not prove every access port or trunk state was re-tested at the current repository SHA.
Configuration authority
- AS1 and AS2 each use one LACP-configured uplink toward each core.
- The corresponding physical interfaces use
channel-group ... mode active. - Each current port channel has one physical member.
Saved operational evidence
Screenshots/EtherChannel/core1-etherchannel-summary.pngScreenshots/EtherChannel/core1-etherchannel.pngScreenshots/EtherChannel/core2-etherchannel.png
Supported conclusion: LACP and port-channel configuration were exercised in Packet Tracer.
Boundary: the current topology does not provide multi-link bandwidth aggregation or intra-bundle link redundancy because each port channel has a single physical member. Access-path redundancy comes from dual-homing each access switch to both cores.
Configuration authority
- CORE1 and CORE2 carry matching HSRP groups 10–70 and matching virtual gateway addresses.
- CORE1 uses priority
110withpreempt, making it the preferred active HSRP device. - CORE2 retains the matching virtual gateway configuration as the standby path.
Saved operational evidence
Screenshots/HSRP/core1-standby-brief.pngScreenshots/HSRP/core2-standby-brief.pngScreenshots/Failover/core1-failover.png
Supported conclusion: the configuration supports a preferred CORE1 / standby CORE2 gateway design, and the repository contains saved HSRP/failover observations from the simulator.
Boundary: the saved artifacts are lab evidence, not a measured production convergence or availability guarantee.
Configuration authority
- OSPF process 1 runs on CORE1, CORE2, R1 and R2.
- CORE1 prefers R1 with cost
10and uses R2 as the higher-cost path at100. - CORE2 prefers R2 with cost
10and uses R1 as the higher-cost path at100. - R1 and R2 each originate a default route into OSPF when their upstream route is present.
Saved operational evidence
Screenshots/OSPF/core1-ip-route.pngScreenshots/OSPF/core2-ip-route.pngScreenshots/OSPF/R1-OSPF.pngScreenshots/OSPF/R2-OSPF.pngScreenshots/OSPF/isp-ip-route.png
Supported conclusion: the configurations implement deliberate core-to-edge path preference, and saved Packet Tracer routing output exists for both cores and both edge routers.
Boundary: there is no dedicated saved artifact in this repository that by itself establishes R1 failure reconvergence timing. I therefore treat R1 failover as a configured alternate-path design rather than a quantified convergence claim.
Configuration authority
- CORE1 and CORE2 both define the seven client/service scopes.
- Exclusion ranges divide the usable address space so the two cores do not allocate overlapping lease ranges.
- Both sides advertise the HSRP virtual gateway as the default router.
Saved operational evidence
Supported conclusion: the lab implements split-scope DHCP across the two cores and saved lease/binding output exists from both sides.
Boundary: this is split-scope configuration, not a state-synchronized DHCP failover protocol.
Configuration authority
- The same extended
INTER-VLAN-POLICYACL is applied inbound on VLAN SVIs 10–70 on both cores. - The ACL contains explicit departmental denies, selected service-path permits, and a final broader
permit ip any any.
Saved operational evidence
Screenshots/ACL/core1-access-list.pngScreenshots/ACL/core2-access-list.pngScreenshots/ACL/acl-permit-deny-test.png
Supported conclusion: the lab contains mirrored inter-VLAN filtering logic and saved evidence of ACL state plus permitted/denied traffic testing.
Boundary: this is a selective policy, not a default-deny segmentation model. The final permit means traffic not matched by the explicit denies remains allowed.
Configuration authority
- R1 and R2 mark their core-facing links as NAT inside and their ISP-facing link as NAT outside.
- Both routers use PAT overload for the internal
192.168.0.0/16space. - Each router has a default route toward its ISP-facing next hop.
Saved operational evidence
Supported conclusion: both edge routers are independently configured for outbound translation and Packet Tracer NAT state was captured on both.
Boundary: the two routers do not synchronize NAT session state. Alternate egress capability should not be described as stateful NAT failover.
Configuration authority
CORE2 mirrors the relevant VLAN, HSRP, DHCP, OSPF and ACL configuration required to continue the core role if CORE1 is unavailable.
Saved operational evidence
Supported conclusion: the repository contains a saved Packet Tracer observation from a CORE1-disconnection exercise alongside configuration that supports HSRP takeover.
Boundary: CORE2 is not explicitly guaranteed to become the secondary STP root by configured priority because CORE2 and both access switches use the same secondary priority. Remaining bridge IDs can therefore influence Layer 2 root selection after CORE1 loss.
Configuration authority
The exported device configurations retain SSHv2, login local and SSH-only VTY transport.
The Packet Tracer lab credentials used during construction were simulation-only. Those credential values are intentionally redacted from the public text exports, so the exported files show management-plane intent rather than a directly reusable login configuration.
The complete simulator project is available at PacketTracer/LAN_Project.pkt.
A reviewer can use it to reproduce or extend the lab, but Packet Tracer behavior should not be treated as equivalent to production Cisco IOS validation.
The repository preserves configuration exports, topology, simulator project files and selected screenshots. I use those artifacts to support narrow, inspectable claims about the design.
I do not use them to claim:
- production availability or convergence guarantees;
- synchronized NAT state between edge routers;
- synchronized DHCP failover;
- multi-link EtherChannel bandwidth aggregation in the current topology;
- a guaranteed CORE2 secondary STP-root role;
- complete re-execution of every operational test against the latest Git commit.