Malwarebytes - Cybersecurity for Everyone

Linux ip Command Cheat Sheet: Spot Rogue Routes & ARP Spoofing

byShubham Chaudhary •November 02, 2026

0

Linux terminal showing ip command output for interfaces, routing table and ARP neighbor entries used in SOC investigations

Linux ip Command Cheat Sheet: Networking, Routing and SOC Investigation Guide (2026)

Last verified: November 2, 2026 (syntax checked against current iproute2 behavior).

Picture a Linux application server that "feels slow" at 2 a.m. CPU is fine, disk is fine, and the endpoint detection and response (EDR) console shows nothing alarming. The on-call analyst runs one command, ip route show table all, and spots a route nobody on the team created, sending a chunk of traffic through an unfamiliar next hop. This is an illustrative scenario, but a very realistic one. Misrouted traffic, extra IP addresses and stale neighbor entries are often the first visible symptoms of misconfiguration or tampering, and the ip command is the fastest way to see them.

Why ip Replaced ifconfig, route and arp

The ip command belongs to the iproute2 package and has replaced the older net-tools utilities (ifconfig, route, arp) on most modern distributions. It talks to the kernel through netlink, handles IPv4 and IPv6 in one tool, and exposes features the legacy tools never covered, such as policy routing, namespaces and VLAN interfaces.

Legacy command	Modern equivalent
ifconfig	ip addr / ip link
route -n	ip route
arp -a	ip neigh
netstat -i	ip -s link
iptunnel	ip tunnel

Basic ip Commands and Brief Output

These are the commands you will type most often. The -br flag prints compact, one-line-per-interface output, which is ideal for screenshots and incident notes.

ip -V
ip -br addr
ip -br link
ip route
ip neigh

ip a shows IP addresses, ip link shows interfaces, ip r shows the routing table, and ip neigh shows the ARP/NDP table.
-V prints the iproute2 version, useful when a flag behaves differently across distributions.

Expected output: ip -br addr lists each interface, its state (UP, DOWN, UNKNOWN) and its addresses. Replace eth0 in all examples with your actual interface name, since many systems use names like ens160 or enp3s0.

Interface Information and Control

ip link show eth0
ip -s link show eth0
ip -d link show eth0

ip link show reveals state and MAC address.
-s adds RX/TX packet, error and drop counters. Rising errors or drops often point to a bad cable, duplex mismatch or saturated link.
-d adds driver-level detail such as VLAN IDs, bridge membership and tunnel parameters.

To change interface state or properties:

sudo ip link set eth0 up
sudo ip link set eth0 down
sudo ip link set eth0 mtu 9000
sudo ip link set dev eth0 address 02:11:22:33:44:55

Warning: bringing an interface down on a remote server can cut off your own SSH session. MAC address and interface name changes are temporary and can be overwritten by NetworkManager or systemd-networkd. Change MTU to 9000 (jumbo frames) only if every device on the path supports it.

Viewing, Adding and Removing IP Addresses

ip -4 addr show
ip -6 addr show
ip addr show dev eth0
ip addr show scope global

Adding and removing addresses (all changes are non-persistent and vanish at reboot):

sudo ip addr add 192.168.1.100/24 dev eth0
sudo ip -6 addr add 2001:db8::100/64 dev eth0
sudo ip addr del 192.168.1.100/24 dev eth0

You can assign several addresses to one interface, which is normal for web hosting or failover setups but is also something an investigator should question when it is unexpected.

Caution: ip addr flush removes every address on an interface (or only global-scope ones with scope global). Never run it on a remote server without console access.

sudo ip -4 addr flush dev eth0

Routing Tables and Route Lookups

ip route
ip -6 route
ip route show table all
ip route get 8.8.8.8

ip route get is the most underrated command in the toolbox. Instead of making you read the table and guess, it asks the kernel which route, interface and source address it would actually use for a destination. During an investigation, running it against a suspicious external address answers "would this host even route there, and through which path?"

Typical route management:

sudo ip route add default via 192.168.1.1
sudo ip route replace default via 192.168.1.1 dev eth0
sudo ip route add 10.10.10.0/24 via 192.168.1.1
sudo ip route del 10.10.10.0/24

Prefer replace over add when a route may already exist; it succeeds either way. The kernel also supports special route types that intentionally block traffic:

sudo ip route add blackhole 203.0.113.0/24
sudo ip route add unreachable 198.51.100.0/24
sudo ip route add prohibit 192.0.2.0/24

Note: these use documentation-only IP ranges (RFC 5737). Blackhole, unreachable and prohibit routes silently or actively drop traffic, which makes them useful as a quick containment control but dangerous if applied to the wrong prefix.

ARP and Neighbor Table

ip neigh show
ip neigh show dev eth0
ip neigh show nud reachable
ip neigh show nud stale
ip neigh show nud failed

IPv4 uses ARP and IPv6 uses Neighbor Discovery Protocol (NDP); ip neigh shows the kernel table for both. Entry states (NUD) tell a story: reachable means recently confirmed, stale means unconfirmed but usable, and failed or incomplete means resolution did not succeed, which is a common clue when a host "cannot reach the gateway."

sudo ip neigh replace 192.168.1.50 lladdr 00:11:22:33:44:55 dev eth0
sudo ip neigh del 192.168.1.50 dev eth0
sudo ip neigh flush dev eth0

Flushing the neighbor table is a safe first step when you suspect stale entries, since the kernel re-resolves addresses on demand.

Policy Routing and Rules

Linux can pick a routing table based on source address, firewall mark and other attributes, not just destination. This is how multi-homed servers and VPN gateways steer traffic.

ip rule show
ip route show table main
ip route show table local

sudo ip rule add from 192.168.1.100/32 table 100
sudo ip route add default via 192.168.1.1 dev eth0 table 100
ip route show table 100

sudo ip rule del from 192.168.1.100/32 table 100
sudo ip route del default table 100

Why this matters for security: a basic ip route only shows the main table. Anything living in a custom table or rule is invisible until you run ip rule show and ip route show table all. Reviewing both is a good habit for any enterprise Linux server audit.

VLANs, Bridges, Tunnels and Namespaces

VLAN interfaces

sudo ip link add link eth0 name eth0.10 type vlan id 10
sudo ip addr add 192.168.10.1/24 dev eth0.10
sudo ip link set eth0.10 up
ip -d link show eth0.10
sudo ip link delete eth0.10

Bridges

sudo ip link add br0 type bridge
sudo ip link set br0 up
sudo ip link set eth0 master br0
ip -d link show br0
sudo ip link set eth0 nomaster
sudo ip link delete br0 type bridge

Adding a physical interface to a bridge can interrupt connectivity on that interface until the bridge is configured, so do it from a console when possible.

Tunnels

sudo ip tunnel add gre1 mode gre local 192.0.2.1 remote 198.51.100.1 ttl 255
sudo ip link set gre1 up
sudo ip addr add 10.0.0.1/30 dev gre1
ip tunnel show
sudo ip tunnel del gre1

GRE tunnels are legitimate in many enterprise WAN designs. An unexpected tunnel interface on a server, however, deserves a question: who created it, and why?

Network namespaces

sudo ip netns add testns
ip netns list
sudo ip netns exec testns ip addr
sudo ip netns exec testns ip route
sudo ip netns exec testns ip link set lo up
sudo ip netns delete testns

Namespaces power containers. They also mean a host can have network state you will not see from the default namespace, so check ip netns list when the host runs containers or virtualization tooling.

Connectivity Troubleshooting Workflow

When a server cannot reach something, work from the bottom of the stack upward:

Link: ip -s link (is it UP, any errors?)
Address: ip -br addr (right IP and prefix?)
Route: ip route get 8.8.8.8 (which path would be used?)
Neighbor: ip neigh (is the gateway's MAC resolved?)
Reachability: ping, tracepath or traceroute
Sockets: ss -tulnp for listeners

ping -c 4 192.168.1.1
ping -c 4 1.1.1.1
tracepath 8.8.8.8
ss -tulnp
ss -antp
ss -anup

ss complements ip: -tulnp shows listening TCP/UDP ports with owning processes, -antp shows all TCP connections, and -anup shows UDP sockets. Run with sudo to see process names.

SOC and DFIR Investigation with ip

For incident response, the goal is to capture volatile network state before anyone changes it. The command below builds a timestamped snapshot you can attach to a ticket or evidence record:

{
    date -Is
    echo "===== INTERFACES ====="
    ip -br addr
    echo "===== LINK DETAILS ====="
    ip -s link
    echo "===== ROUTES ====="
    ip route show table all
    echo "===== RULES ====="
    ip rule show
    echo "===== NEIGHBOURS ====="
    ip neigh show
} | tee "network-snapshot-$(date +%Y%m%d-%H%M%S).txt"

It is read-only and safe to run on a live system. Save the file to a trusted location, ideally off the host, and hash it if it may become evidence.

What to look for

Unexpected default route or secondary gateway: traffic may be steered through an unfamiliar next hop. Compare against your configuration management baseline.
Extra IP addresses: unexplained secondary addresses on an interface.
Custom rules and tables: entries in ip rule show or non-main tables that no change ticket explains.
Unfamiliar tunnel, bridge or VLAN interfaces: check ip -d link show and ip tunnel show.
PROMISC flag: an interface flagged PROMISC in ip link output can be legitimate (packet capture, bridging, virtualization) but should always be explained.
Neighbor table oddities: the gateway's MAC address changing, or several IPs resolving to one MAC, can indicate ARP spoofing (or simply a proxy-ARP setup). Treat it as a lead to verify, not proof.
Route to a suspicious address: ip route get 203.0.113.25 shows how the host would reach it.

JSON Output for Automation

ip -j addr show
ip -j route show
ip -j neigh show | jq .

The -j flag outputs structured JSON, and jq (if installed) pretty-prints and filters it. This lets you feed interface and route data into scripts, SIEM pipelines or configuration drift checks without brittle text parsing. Adding -p to ip -j also pretty-prints natively.

Expert Tips

Remember persistence: everything done with ip is runtime-only. Make permanent changes through NetworkManager, systemd-networkd or Netplan.
Baseline your fleet: store known-good ip -br addr and ip route show table all output per server role and diff against it regularly.
Always test with ip route get after any routing change.
Use out-of-band access (console, iDRAC, cloud serial console) before touching interfaces on remote hosts.
Check all namespaces on container hosts, not just the default one.
Document every manual change so the next analyst does not mistake your fix for an intrusion.
Pair ip data with firewall logs and EDR telemetry for a complete picture; network state alone rarely proves intent.

Linux Networking Commands Cheat Sheet: ip, ss, nmap (2026)
SBI CyRIS Cybersecurity Centre of Excellence: Full Breakdown
Linux pstree Command Cheat Sheet: Spot Suspicious Processes Fast
Linux pgrep Command Cheat Sheet: Find Suspicious Processes Fast
Linux pmap Command Cheat Sheet: 40 Examples for Memory Analysis
Capcom Data Breach: 11.77M Records Exposed – Are You Safe?
VeloCloud Orchestrator Flaw: Read-Only Login Gives Superuser

FAQ

Is the ip command better than ifconfig?

Yes for modern systems. ifconfig is part of the deprecated net-tools package and is missing on many new installs, while ip covers IPv6, policy routing, namespaces and more.

Are changes made with ip permanent?

No. They last until reboot or until network management software overwrites them. Use your distribution's network configuration system for persistence.

How do I see which route a packet will take?

Run ip route get <destination>. It reports the next hop, interface and source address the kernel would select.

How do I view the ARP table with ip?

Use ip neigh (or ip neighbour). It covers both ARP for IPv4 and NDP for IPv6.

Can ip help detect ARP spoofing?

It can provide clues, such as a changed gateway MAC or duplicate MACs across IPs, but confirmation needs additional evidence like packet captures or switch logs.

Is it safe to run ip commands on production servers?

Viewing commands (show, get, -s, -br) are read-only and safe. Commands that add, delete, flush or set values change live state and should follow your change process.

What does the -br flag do?

It prints brief, one-line-per-interface output, making it easy to scan and paste into tickets.

How do I output ip results as JSON?

Add -j, for example ip -j route show, then pipe to jq for filtering.

Conclusion

The ip command is small in name and huge in value. For admins it is the daily driver for interfaces, addressing and routing; for SOC analysts and incident responders it is a fast, built-in way to capture network state, validate traffic paths and notice what does not belong. Learn the read-only commands first, build a baseline for your servers, and treat every write command with the same caution you would give a firewall change. Bookmark this cheat sheet, and the next time a server "feels off" at 2 a.m., you will know where to look first.

Analysis based on SOC monitoring experience and review of public iproute2 documentation.