Lab 04-03 · Static routing through a neighbour (optional)¶

In class you want to pass a note to Alex, who sits at the other end of the room. You could walk over. Or you could hand it to Bea, who sits in between, and ask her to pass it on. Bea must agree, and she must know where Alex sits. If she does not, the note ends up on the floor.

In Lab 04-02 your router knocked directly on the door of the neighbour's router. Now you take the long way on purpose: to reach neighbour A's laptop, you send your packets to neighbour B's router, and B passes them on to A. The point is not that it is a good path (it is not), but to see that every router on the way makes its own decision, and needs its own route.

The analogy: passing a note¶

Hop-by-hop routing¶

In IP routing, every router decides only the next hop for a packet, using its own routing table. Nobody plans the whole path in advance. This is called hop-by-hop routing.

That is why your route alone is not enough: the moment the packet reaches B, it is B's routing table that counts. If B has no route for 192.168.89.0/24, B uses its default route and the packet goes to the classroom gateway, which drops it.

flowchart LR
    PC1["<b>pc1</b>"] -->|"default route"| R1["<b>r1 (you)</b><br>192.168.89.0/24<br>→ 10.0.0.13"]
    R1 -->|"hop 2"| R3["<b>r3 (B)</b><br>192.168.89.0/24<br>→ 10.0.0.12"]
    R3 -->|"hop 3"| R2["<b>r2 (A)</b><br>connected"]
    R2 -->|"delivered"| PC2["<b>pc2</b><br>A's laptop"]

The scenario¶

flowchart LR
    INET["<b>internet</b><br>198.51.100.10"]
    CAP["<b>class-ap</b><br>10.0.0.1"]
    R1["<b>r1 · you</b><br>10.0.0.11<br>LAN 192.168.88.0/24"]
    R2["<b>r2 · neighbour A</b><br>10.0.0.12<br>LAN 192.168.89.0/24"]
    R3["<b>r3 · neighbour B</b><br>10.0.0.13<br>LAN 192.168.90.0/24"]
    PC1["<b>pc1</b><br>your laptop"]
    PC2["<b>pc2</b><br>A's laptop"]
    PC3["<b>pc3</b><br>B's laptop"]
    INET --- CAP
    CAP ---|"class network 10.0.0.0/24"| R1
    CAP ---|"class network"| R2
    CAP ---|"class network"| R3
    R1 --- PC1
    R2 --- PC2
    R3 --- PC3

All three routers start like Lab 04-02's starting point: fixed class address, default route to 10.0.0.1, masquerade on ether2, and no routes to the neighbours.

Start the lab¶

Download the lab files and unzip them: 04-03-static-routing-via-neighbour.zip. Open a terminal inside the 04-03-static-routing-via-neighbour folder.

sudo containerlab deploy -t topology.clab.yml

Four RouterOS routers have to boot: give it about three minutes. Then:

ssh admin@clab-mtcna-04-03-r1            # password: admin   (also r2, r3)
docker exec -it clab-mtcna-04-03-pc1 bash   # also pc2, pc3

You configure r1 and you play neighbour B on r3. In class, team up with two neighbours (slide p177). At any moment you can run CLAB_EXEC="docker exec" ./check.sh.

The laptops ask for their address by themselves when the lab starts; if ip -br address show eth1 shows no IPv4 address yet (the router was still booting), run dhclient -v eth1.

Step 1 · Send A's traffic to B¶

On r1. WinBox: IP → Routes → +, Dst. Address 192.168.89.0/24 (A's LAN), Gateway 10.0.0.13 (B's router).

/ip route add dst-address=192.168.89.0/24 gateway=10.0.0.13
/ip route print

Expected: a new As line 192.168.89.0/24 → 10.0.0.13.

Done when the route is active.

Step 2 · Watch the packet get lost at B¶

On pc1:

ping -c 3 192.168.89.254
traceroute -n 192.168.89.254

Expected: the ping fails, and the traceroute reads like a detective story:

 1  192.168.88.1         ← your router: OK
 2  10.0.0.13            ← B received it: your route works
 3  10.0.0.1  !N         ← B sent it to the classroom gateway, which says "network unreachable"

B has no route for 192.168.89.0/24, so B used its default route. The !N is the classroom gateway answering "I have no route to that network".

Done when you can point at the hop where the packet got lost.

Step 3 · Teach B the way to A¶

On r3 (neighbour B; in class, B does this on their hAP):

/ip route add dst-address=192.168.89.0/24 gateway=10.0.0.12

On pc1 again:

ping -c 3 192.168.89.254
traceroute -n 192.168.89.254

Expected: the ping works, and the traceroute shows the detour:

 1  192.168.88.1
 2  10.0.0.13        ← B
 3  10.0.0.12        ← A
 4  192.168.89.254   ← A's laptop

Done when pc1 pings pc2 and the traceroute goes through 10.0.0.13. Run CLAB_EXEC="docker exec" ./check.sh: every line must say PASS.

Step 4 · Look at the way back¶

The replies do not have to follow the same path. Run tcpdump -ni eth1 icmp on pc2 while pc1 pings again. pc2 sees the requests coming from 10.0.0.13: B's router also has a masquerade rule on ether2, and the packet entered and left B through ether2, so B rewrote the sender (your router had already rewritten it to 10.0.0.11 before). A replies to 10.0.0.13, B undoes its translation and sends it to 10.0.0.11, and your router undoes its own.

Done when you can explain the way back.

If something goes wrong¶

Clean up¶

sudo containerlab destroy -t topology.clab.yml --cleanup

Key takeaways¶

• IP routing is hop-by-hop: each router decides only the next hop, using its own routing table.
• A path through several routers needs a route on every router that is not directly connected to the destination.
• traceroute shows where a packet gets lost: the last hop that answers is where to look.
• The way back can be different from the way there; masquerade on each router changed it here.
• A router may send an ICMP redirect when it sees a shorter path; RouterOS sends them but ignores the ones it receives.

Quick check¶

Next: what if you used both paths at the same time, the direct one and the detour? That is ECMP.