Routed Interfaces and Neighbor Resolution

Scenario: two directly connected subnets

This is a separate lab allocation: Ethernet8 and Ethernet12 are routed ports, not members of the previous VLAN lab or any LAG. Linux hosts already have the shown addresses and default gateways. Host A sends to B through its gateway because B is outside A’s /24 subnet.

Configuration: addresses on routed ports

Verify both ports exist, support the lab link settings, have no IP allocation conflict, and are in routed mode. The checked IP-add implementation rejects VLAN/LAG member ports and explicit access/trunk mode. Do not remove existing memberships just to force the command through.

sudo config interface ip add Ethernet8 192.0.2.1/24
sudo config interface ip add Ethernet12 198.51.100.1/24
sudo config interface startup Ethernet8
sudo config interface startup Ethernet12
show ip interfaces
show interfaces status Ethernet8
show interfaces status Ethernet12

SONiC setup for two reserved routed ports. Illustrative only; not executed on a SONiC device.

For explicitly prepared Linux endpoints, the corresponding setup is below; eth1 must be the dedicated data interface, never the management interface. Each host must have no conflicting lab address or default route.

# Host A
sudo ip address add 192.0.2.10/24 dev eth1
sudo ip link set eth1 up
sudo ip route replace default via 192.0.2.1 dev eth1
# Host B (on a different host)
sudo ip address add 198.51.100.20/24 dev eth1
sudo ip link set eth1 up
sudo ip route replace default via 198.51.100.1 dev eth1

Linux endpoint examples, not SONiC CLI commands. If already prepared as shown, inspect rather than add duplicates. Illustrative only; not executed on a SONiC device.

No static route is needed on SONiC between these directly attached subnets. Endpoint gateways supply the return path through the switch.

Read further: 202505 configuration CLI implementation · 202505 command reference (pinned).

State: connected route and neighbor are distinct

show ip route 198.51.100.20
show arp
ip neigh show 198.51.100.20 dev Ethernet12

Read-only default-namespace inspection; the last line is a Linux neighbor view. Illustrative only; not executed on a SONiC device.

C>* 198.51.100.0/24 is directly connected, Ethernet12
# Separate Linux neighbor-view example after resolution:
198.51.100.20 dev Ethernet12 lladdr 02:00:00:00:00:14 REACHABLE

Invented shortened outputs from different commands. Neighbor states can age through STALE or other states without immediate failure.

The connected prefix identifies an egress subnet. ARP resolves the local destination IP to its Ethernet MAC for that link. A present route does not prove a resolved neighbor or successful SAI programming. show arp may omit unresolved entries; the Linux view helps distinguish an incomplete attempt from no attempted lookup.

Read further: 202505 show CLI implementation · Windows cross-check revision: neighbor orchestration.

Forwarding evidence: the router changes the frame

From Host A, a bounded ping -c 3 198.51.100.20 would test the round trip. A first resolves its gateway’s MAC. SONiC looks up B’s IP, resolves B on Ethernet12, decrements IPv4 TTL, and constructs the egress Ethernet header using the egress router MAC and B’s MAC. The routed packet keeps its IP endpoints in this no-NAT example.

Inspect both endpoint neighbor tables and captures where available. A reply from a SONiC interface address tests the switch’s local IP stack; it is not the same evidence as A-to-B transit. Counters and software neighbor views narrow the problem but do not independently establish hardware forwarding.

Read further: 202505 command reference (pinned).

Fault and repair: the expected peer IP disappears

On Host B only, replace its expected address with .30 on the same subnet. The Ethernet link and SONiC connected prefix remain, but nobody now owns .20.

# Host B only — controlled address fault
sudo ip address del 198.51.100.20/24 dev eth1
sudo ip address add 198.51.100.30/24 dev eth1
sudo ip route replace default via 198.51.100.1 dev eth1
# Host A: attempt the original destination
ping -c 3 198.51.100.20
# SONiC: correlate route and attempted adjacency
show ip route 198.51.100.20
show arp
ip neigh show 198.51.100.20 dev Ethernet12

Fault steps span three named devices; do not paste the whole block into one shell. Illustrative only; not executed on a SONiC device.

Initially a cached MAC may still send frames toward B, where the old destination IP is no longer local. After the old entry expires and new resolution is attempted, the neighbor can become INCOMPLETE and then FAILED. Do not promise that transition immediately or flush shared caches to force it.

198.51.100.20 dev Ethernet12 INCOMPLETE

Invented later observation after a resolution attempt. The route can still exist while the adjacency is unusable.

# Host B only — restore the recorded lab address
sudo ip address del 198.51.100.30/24 dev eth1
sudo ip address add 198.51.100.20/24 dev eth1
sudo ip route replace default via 198.51.100.1 dev eth1

Exact repair for this prepared endpoint baseline. Illustrative only; not executed on a SONiC device.

Retry the original traffic after resolution, inspect .20’s neighbor state, and compare endpoint evidence. For full teardown, remove only the added SONiC addresses and restore the stated admin-down switch baseline. Endpoints remain at their original prepared addresses and gateways after the repair above.

sudo config interface ip remove Ethernet8 192.0.2.1/24
sudo config interface ip remove Ethernet12 198.51.100.1/24
sudo config interface shutdown Ethernet8
sudo config interface shutdown Ethernet12
show ip interfaces
show interfaces status

SONiC teardown for this isolated baseline. Illustrative only; not executed on a SONiC device.

Compare with the before record and leave startup files unchanged.

Check your understanding

Six questions, four choices each. Review the explanation after each answer, then see your score and retry.