One-Way Ping After a Server Migration
Two Linux servers were migrated onto the same flat VLAN behind a Junos router. Server A is configured as 172.16.4.10/22 and Server B as 172.16.5.20/24. Both use 172.16.5.1 as their default gateway, which is the router's irb.5 interface (172.16.5.1/24). No other Layer 3 device is involved on that VLAN.
After the migration, Server A can ping Server B successfully, but Server B gets 100% loss pinging Server A. The router's irb.5 input counters climb while B's ICMP attempts fail. There are no interface errors, no STP events, and Server A's ARP table shows a correct entry for Server B. The application owner insists both servers are "on the same subnet" and wants the router fixed.
1. Explain why the ping succeeds in one direction only, and identify which device is actually misconfigured.
Read the worked answer
The two masks disagree, and Server A is the device that is wrong.
- A is 172.16.4.10/22, so its on-link range is 172.16.4.0 - 172.16.7.255. 172.16.5.20 falls inside that range, so A treats B as directly connected and ARPs for it. Because the VLAN is flat, that ARP is answered and the echo request is delivered at Layer 2. No router is involved in that direction.
- B is 172.16.5.20/24, so its on-link range is 172.16.5.0 - 172.16.5.255. 172.16.4.10 is outside it, so B sends the echo request to its default gateway, 172.16.5.1.
- The router receives the packet on irb.5, looks up 172.16.4.10, and finds only the connected route 172.16.5.0/24. Nothing matches, so the packet is dropped - which is exactly the input-side counter increase observed.
The asymmetry is not a routing bug: one direction never leaves Layer 2. The defect is that A's address/mask pair describes a subnet that does not exist anywhere else in the network, so anything the rest of the network sends to A must be routed and cannot be.
2. List the commands you would run on the router and on the hosts to prove this, and state what each one establishes.
Read the worked answer
On the router (Junos)
show route 172.16.4.10- shows no matching route (or only a default), confirming the drop is a lookup miss, not a filter.show route 172.16.5.0/24- confirms the only connected subnet the router knows for this VLAN is the /24.show arp interface irb.5- shows B's MAC/address; A's 172.16.4.10 will not appear, because A's traffic to the router never arrives (A talks to B directly).monitor traffic interface irb.5 matching "icmp" no-resolve- shows echo requests arriving from 172.16.5.20 to 172.16.4.10 with no replies leaving, isolating the failure to the router's lookup.
On Server A
ip addr show- reveals the /22.ip route get 172.16.5.20- returnsdev eth0 ... src 172.16.4.10, i.e. on-link, no via.
On Server B
ip route get 172.16.4.10- returnsvia 172.16.5.1 dev eth0, proving B is routing the packet to the gateway.
Together these show the request path is on-link in one direction and gateway-routed in the other.
3. What are the possible fixes, and what are the side effects of each?
Read the worked answer
Option 1 (correct one): re-address A to 172.16.5.10/24. Puts A in the subnet the rest of the network actually uses. Side effects: A needs a new address (DNS, firewall rules, hard-coded peers, licence bindings), and you must confirm no other host in 172.16.4.0/22 depends on A's old address. Low risk if A is new.
Option 2: keep A's address and add a route on the router, e.g. set routing-options static route 172.16.4.0/22 next-hop 172.16.5.10. This works only because A considers 172.16.5.1 on-link and will ARP for the router.
Side effects: it plants a /22 pointing into a VLAN that is really a /24, so any other host later placed in 172.16.4.0/22 will silently be routed to A and fail, and the route is local to this router - any other router needing to reach A still breaks.
Option 3: widen B's mask to /22. Makes B consider A on-link again. Side effects: it changes the broadcast domain definition for B relative to every other host on the VLAN, creates the same asymmetry with the next host that is added, and hides rather than fixes the inventory error.
Recommendation: Option 1, with Option 2 only as a temporary, documented stop-gap with a removal ticket.