CCR2216 Mikrotik Router Animation & Simulation in Proteus

Explore step-by-step how to model the CCR2216 router in Proteus, visualize its packet flow, and simulate network configurations for practical learning.

Watch the following video demonstration:

The video "ISP CCR2216 Mikrotik Router Animation & Simulation in Proteus" demonstrates a virtual networking and routing simulation environment built inside Proteus Design Suite.

Here is an explanation of what is happening in the simulation:

1. Network Topology & Devices

• CCR2216 (Cloud Core Router): Represents a high-performance Mikrotik CCR2216 core router acting downstream.

• ISP A: Represents an upstream gateway / simulated ISP router providing internet connectivity.

• Interconnection: The routers are linked together in the schematic via serial/network lines, and each device has a dedicated Virtual Terminal attached to monitor console outputs and command-line interactions in real time.

2. Initialization & IP Lease (DHCP / Routing)

• When the simulation boots up, the virtual terminals initialize both devices (ISP-A and CCR2216).

• The CCR2216 detects the upstream neighbor (ISP A), requests an IP address lease (Leased 203.0.113.2 to CCR2216), learns default routes, and establishes gateway communication (Default route installed via 203.0.113.1).

3. Live Ping & Connectivity Testing

The simulation demonstrates interactive testing via the virtual terminal command line:

• Gateway & Public IP Pings: The CCR2216 terminal executes ping commands to verify packet transmission across interfaces (e.g., pinging external addresses like Cloudflare 1.1.1.1, Google 8.8.8.8, or domain names like ee-diary.net and example.com).

• Packet Statistics: The virtual terminals output live round-trip times (RTT), packet loss metrics (0% loss), and successful reply echoes, proving that the simulated routing table and gateway handshakes are fully operational within the Proteus VSM framework.

Features

ISP A (203.0.113.1)

• Offers the CCR2216 a lease of 203.0.113.2/30, like DHCP, and learns its customer network, like BGP.
• Announces a default route, and sends keepalives every 5 s (session resets after 15 s of silence).
• Acts as a pretend internet:
  • DNS server at 1.1.1.1.
  • example.com (93.184.216.34) and ee-diary.net (104.21.10.5), which return simple HTTP pages.
  • Answers pings to any outside address.

CCR2216 (WAN 203.0.113.2, LAN 198.51.100.1)

• DHCP server for the home router, pool 198.51.100.2–.20, 120 s lease.
• Relays the home router’s ping, DNS and HTTP requests to the ISP and returns the replies.
• Own console tools: nslookup, get.

Home router, TL-WR841N (LAN 192.168.0.1)

• WAN side: DHCP client that renews at half the lease.
• LAN side: DHCP server for the PC, pool .100–.199.
• NAT and DNS proxy: the PC’s traffic leaves with the router’s WAN address.
• tplinkwifi.net returns the router’s admin page.

PC

• DHCP client with Windows-style ipconfig, ping (by IP or name), nslookup and curl.

All four consoles share debug on|off (shows the raw link messages) and Ctrl-C to stop a ping.

How to test

Power everything on, then wait about 15–20 s. DHCP retries every 4 s, so the boot order doesn’t matter. Click a Virtual Terminal before typing in it.

1. Startup (just watch)

• ISP-A: “Neighbor CCR2216 detected”, “Leased 203.0.113.2”, “Learned route 198.51.100.0/24”.
• CCR2216: “Link up. WAN IP 203.0.113.2” and “Default route installed”.
• TL-WR841N: “WAN connected: IP 198.51.100.2”.
• PC: “DHCP: got address 192.168.0.100”.

2. Each link, one hop at a time

3. End to end from the PC

4. NAT. After the PC tests, run show nat on the home router. It lists the last ping, DNS and HTTP translations, each showing the PC address mapped to the WAN address.

5. From outside back in

• ISP-A: ping 198.51.100.2 (the router’s WAN address) should reply.
• ISP-A: ping 198.51.100.50 should time out, since nothing has that address.
• The PC’s 192.168.0.x address can’t be reached from outside, which is what NAT does.

6. Dynamic IP

• On the home router, run show wan and note the IP and lease time left.
• Run wan release, then ping 1.1.1.1 on the PC. It should time out.
• Run wan renew and then show wan. The WAN IP should change to 198.51.100.3, because the CCR hands out the next pool address.
• Check show dhcp on the CCR for the new lease.

7. Lease renewal. Watch show wan on the home router. At about 60 s the lease counter jumps back to 120 s. Renewal is silent, so there’s no message. On the CCR, show dhcp shows “expires in” resetting too.

8. PC DHCP. Run ipconfig /release, then ping 192.168.0.1, which should fail. Then run ipconfig /renew, and the PC gets an address again (192.168.0.101 this time).

9. Failure recovery. Pause or unplug the ISP–CCR link in Proteus.

• After 15 s, ISP-A prints “Peer timed out” and the CCR prints “Upstream lost”.
• Reconnect, and the whole HELLO → lease → default route sequence repeats.

10. Debugging. Type debug on on any device to see the raw [… TX] and [… RX] messages. If a ping times out, check whether the message leaves one chip and arrives at the next.

Known limits

• The CCR serves one DHCP client (the home router).
• The router’s DHCP server serves one client (the PC).
• The NAT table holds one pending translation per protocol.
• Pinging another LAN address, such as 192.168.0.50, gets no reply.

Results

CCR2216 Border Router Terminal

WR481N Home Router Terminal

PC Terminal

Most of the tests pass, but DNS and HTTP from the PC fail, and the ISP answered a private address that it shouldn’t.

What passed

• Startup: every device came up (leases, default route, DHCP: got address 192.168.0.100).
• Per-link pings: all four worked.
• PC to the internet: ping 198.51.100.1 and ping 1.1.1.1 work, as do ping 8.8.8.8 (replies) and ipconfig.
• NAT: show nat shows the PC address 192.168.0.100 mapped to the WAN address 198.51.100.2.
• Dynamic IP: wan release then wan renew moved the WAN IP from 198.51.100.2 to .3, and the CCR’s show dhcp shows the new lease.
• PC DHCP: release and renew moved the PC from 192.168.0.100 to .101.
• ISP pings: replies from 198.51.100.2 and a timeout for 198.51.100.50, as expected.

The two timeouts in your second ping 1.1.1.1 most likely came from the moment you released the router’s WAN address. Both timeouts happened before the replies resumed, and the order of your tests matches.

What failed

1. DNS and curl from the PC always time out. This covers nslookup, ping example.com and curl. Your show nat output shows the DNS query for nowhere.invalid reached the home router and was forwarded. So the request dies at the CCR or the ISP, or the reply never makes it back. From the code alone I can’t tell which. These steps will find it:

1. On the CCR2216, run nslookup ee-diary.net. If this works, the ISP is fine and the fault is in the relay. If it times out, the fault is in the CCR↔ISP DNS exchange.
2. Run debug on on the home router, the CCR and ISP-A. Then run nslookup ee-diary.net on the PC and read each terminal. The lines to look for are:
   • Home router: [HR WAN TX] DNS,ee-diary.net
   • CCR: [CCR DN RX] DNS,... and then [CCR UP TX] DNS,...
   • ISP: [ISP RX] DNS,... and then [ISP TX] DNSR,...
   • CCR again, then the home router, for DNSR coming back.
   The last device that shows its line is where it breaks.

If messages vanish with no pattern, the likely cause is memory. The ATmega2560 has only 8 KB of RAM and the sketches use a lot of String objects. Tell me and I’ll switch to fixed buffers.

2. The ISP replied to a private address. ping 192.168.0.100 from ISP-A got replies with time=0ms. That’s wrong, and my expected result in test 5 (“can’t be reached from outside”) was wrong too, because the ISP code treats any non-customer address as a pretend internet host. The same quirk explains why your typo ping 192.158.0.1 from the PC got a reply. The ISP answers pings to any outside address, including ones that don’t exist.