Memory Myths, Subnet Mask Mistakes, and Telnet Tricks: Ops Lessons

Memory Battle

Do we really need more memory?

A development team under a tight six‑month deadline blamed system slowness on high memory usage, while operations monitored and found the root cause in code inefficiencies.

Development needed to launch a new system quickly, working weekends and accumulating bugs. Performance degraded in the final month, prompting a search for reasons.

Operations analyzed logs for several days and identified code‑related issues.

A developer reported "high memory usage" and provided a screenshot as evidence.

Memory usage was 14873/16062 = 92.6%, which slowed the system.

Development requested purchase of 50 × 16 GB memory modules.

Because the purchase required additional budget and a lengthy approval process, the technical director asked operations for an opinion.

Operations presented analysis showing the problem stemmed from code, not memory shortage.

How does Linux calculate usable memory?

Linux tries to use all available RAM; the kernel places free memory into cache, which is not counted as "free".

When a system runs for a long time, cached memory can become large, especially on workloads with frequent file I/O.

Although free memory appears small, the kernel can reclaim cache when an application requests more RAM, making that memory effectively available.

Thus, usable memory = free memory + buffers + cached (and also includes buffers).

From the OS perspective, buffers and cached are considered used; available memory was 1188 MB.

From an application perspective, buffers and cached are available for allocation.

Therefore the actual Linux memory usage is:

1 - (11289 / 16062) = 30%

This analysis shows that adding memory was unnecessary; improving code quality and application performance was the proper solution.

Subnet Mask Confusion

Network operators often overlook subnet masks, leading to connectivity problems.

A client complained that a submitted policy used a mask that was "too large" and needed refinement.

A subnet mask indicates which bits of an IP address identify the network and which identify the host.

Misunderstanding the mask caused the policy to be rejected, even though the intended rule was very specific.

Examples:

10.192.0.1 with mask 255.255.255.0 belongs to network 10.192.0.0.

10.192.1.1 with mask 255.255.255.0 belongs to network 10.192.1.0 – different subnets, cannot communicate directly.

10.192.0.1 with mask 255.255.0.0 and 10.192.1.1 with the same mask belong to the same network 10.192.0.0 – communication is possible.

Firewalls also use positive and negative masks:

Positive mask example: 10.4.21.0/255.255.255.128 covers 10.4.21.1‑127.

Negative mask example: 10.4.21.33 0.0.0.127 (router ACLs often use this form).

Neglecting subnet‑mask configuration is a frequent source of network outages.

Telnet Trouble

Telnet is a TCP‑based tool; it cannot test UDP ports.

A project required testing UDP port 177 for XMANAGER. The remote admin used Telnet and reported the port was closed.

Correct tools for UDP testing include

nc

(netcat) or

nmap

.

<code>nc -vuz 10.4.29.35 177</code>

Result: "Connection to 10.4.29.35 177 port succeeded!" – the UDP port is open (note that nc may sometimes be inaccurate).

Alternative:

nmap -sU -p 177 10.4.29.35

for a more reliable check.

Lesson: small details matter; using the right tool prevents misdiagnosis.

Conclusion

Technical growth requires both theory and hands‑on analysis. Each incident—whether memory‑related, mask‑related, or tool‑related—deepens understanding and helps avoid future "gotchas" in operations.