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
| Prefix | Total addresses | Usable | Waste | Spec |
|---|---|---|---|---|
| /30 | 4 | 2 | 2 (50%) | RFC 1812 |
| /31 | 2 | 2 | 0 | RFC 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 support | Notes |
|---|---|---|
| Cisco IOS / IOS XE / IOS XR | Yes | Since IOS 12.2(2)T |
| Juniper Junos | Yes | Native |
| Arista EOS | Yes | Native |
| Linux | Yes | Native |
| OPNsense / pfSense / FreeBSD | Yes | Native |
| Windows Server | Yes (recent versions) | Some edge cases historically |
| Embedded / IoT | Mixed | Always verify before deploying |
| Some older equipment | No | Limited 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.