A point-to-point (P2P) link only needs two usable IP addresses — one on each end. The traditional way to allocate this is a /30 subnet (4 total addresses, 2 usable, 2 wasted on network and broadcast). Since 2000, RFC 3021 has provided an alternative: use a /31 instead, which has 2 total addresses and 2 usable, with zero waste.

This article walks through when to use /30 vs /31, the platforms that support each, the address savings at scale, and the operational gotchas.

The math: /30 vs /31

PrefixTotal addressesUsableWasteSpec
/30422 (50%)RFC 1812
/31220RFC 3021

A /30 at 10.0.0.0/30 has:

  • 10.0.0.0 — network address (not usable)
  • 10.0.0.1 — usable (one end of the link)
  • 10.0.0.2 — usable (other end)
  • 10.0.0.3 — broadcast (not usable)

A /31 at 10.0.0.0/31 has:

  • 10.0.0.0 — usable (one end)
  • 10.0.0.1 — usable (other end)

RFC 3021 explicitly states that point-to-point links do not need a network address (there's only one network) or a broadcast address (broadcast on a P2P link is the same as unicast to the other end). So both addresses become assignable.

Why this matters at scale

For a single P2P link, the difference is 2 addresses — trivial. For service provider networks with hundreds or thousands of P2P links, the difference is real money:

  • 500 P2P links with /30: 2,000 addresses consumed, 1,000 wasted.
  • 500 P2P links with /31: 1,000 addresses consumed, 0 wasted.

For IPv4-constrained operators (small ISPs, MPLS backbones with /22 of public space), saving 1,000+ addresses by switching to /31 is meaningful. It also makes documentation neater — every link is exactly 2 addresses, no exceptions.

Platform support

Platform/31 supportNotes
Cisco IOS / IOS XE / IOS XRYesSince IOS 12.2(2)T
Juniper JunosYesNative
Arista EOSYesNative
LinuxYesNative
OPNsense / pfSense / FreeBSDYesNative
Windows ServerYes (recent versions)Some edge cases historically
Embedded / IoTMixedAlways verify before deploying
Some older equipmentNoLimited to /30 minimum

If you are on a modern network, /31 is universally supported. Vendor docs explicitly recommend /31 for P2P links in IOS XE and Junos configs.

When to use /30 instead

  • Mixed-equipment environments where any device on the link might not support /31. The cost of having one mystery outage is much higher than wasting 2 addresses per link.
  • Legacy network designs being modified incrementally. Consistency with existing /30 allocations may be more important than reclaiming addresses.
  • BGP peering with vendors who specifically request a /30 in their setup docs. Some ISPs and exchanges still standardize on /30.

When to use /31

  • Greenfield service provider or DC fabric designs. The address savings compound.
  • OSPF / IS-IS / BGP between known-good routers (Cisco, Juniper, Arista, modern Linux).
  • SDN and cloud-router architectures where everything is software-defined and /31 is just a config choice.
  • Any new MPLS or BGP backbone where the team controls both ends of every link.

How to configure /31

Cisco IOS XE

interface GigabitEthernet0/0/0
 description Link to PE2
 ip address 10.255.1.0 255.255.255.254

Juniper Junos

set interfaces ge-0/0/0 unit 0 family inet address 10.255.1.0/31

Arista EOS

interface Ethernet1
   description Link to spine-1
   no switchport
   ip address 10.255.1.0/31

Linux iproute2

ip addr add 10.255.1.0/31 dev eth1

Allocating /31s from a parent

If you have 10.255.0.0/22 for P2P link addressing, you can carve it into 512 /31 links. Each link uses 2 consecutive addresses, with the lower address typically going to the "lower-numbered" side of the link (e.g., the spine).

10.255.0.0/31    Spine 1 <-> Leaf 1 (spine .0, leaf .1)
10.255.0.2/31    Spine 1 <-> Leaf 2 (spine .2, leaf .3)
10.255.0.4/31    Spine 1 <-> Leaf 3
...
10.255.0.62/31   Spine 1 <-> Leaf 32
10.255.1.0/31    Spine 2 <-> Leaf 1
...

This convention makes it easy to identify which spine/leaf a given address belongs to.

IPv6 P2P: /127, not /126

The IPv6 equivalent of /31 for P2P is /127, per RFC 6164. Same idea: 2 addresses on the link, both usable, no network or broadcast. This is the recommended IPv6 P2P size — even though IPv6 has so much address space that wasting addresses on /126s would not matter for capacity, /127 prevents NDP exhaustion attacks where attackers flood the link with neighbor discovery for random addresses.

Common /31 mistakes

  • Using /31 on a multi-access link. /31 is ONLY for true point-to-point. Two-host Ethernet between a switch and a router is fine. A switch with three hosts attached is not P2P; use /29 or larger.
  • Mixing /30 and /31 in the same OSPF area. Works but creates inconsistent documentation. Pick one convention per network.
  • Routing the /31's "network" or "broadcast" address. They do not exist in /31. Some legacy tools and scripts assume they do.

Key takeaways

  • /31 on P2P links is universally supported on modern equipment and saves 2 addresses per link.
  • /30 still works and may be needed for legacy equipment or some vendor BGP peering requirements.
  • For IPv6 P2P, use /127 per RFC 6164.
  • Use /31 by default for greenfield service-provider and DC fabric designs; use /30 only when you have a specific compatibility reason.