By Brad Edgeworth
Brad Edgeworth, CCIE No. 31574 (R&S & SP), has been with Cisco since 2011 as Systems Engineer and Technical Leader. Formerly a network architect and consultant for various Fortune® 500 companies, his 18 years of IT experience includes extensive architectural and operational work in enterprise and service provider environments.
IP Addressing for Documentation
The secret is: how do you pick the right IP addressing scheme? Part of the logic is straightforward, and the other part is artistic. The reader should be able to look at a diagram and understand the logic with the least amount of words (or legends) to understand the logic and what is being taught. We’ve all seen a diagram and asked ourselves “What was that person thinking?” and “This is going to be difficult to correlate to what I’ve got to learn”.
Unless you are documenting a production network (which is rarely shared externally), using real public IP addresses is a bad idea. Why? Because someone (there always is) will try to mock up your documentation using production devices. IP address conflicts are bad when using someone else’s private IP addressing scheme, but are worst when they are advertising those prefixes out on the Internet. If everyone’s Internet provider is doing their job, and verifying that you own the prefixes you advertise, the problem stops there. If not, you can hi-jack a network and cause someone an outage; which sometimes happens.
Use the Right IP Ranges
RFC 5737 provides three network ranges (192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24) available for documentation purposes. How many have documents have I seen that use those ranges? None. I’ve never used them either. It could be because they are only /24 networks, or because they are discontiguous… Who knows…
You will notice that most network vendors use Private IP address space (RFC 1918 – 10.0.0.0/8 172.16.0.0/12 & 192.168.0.0/16) for most of their documentation for the reasons I stated earlier. Using IP addresses that should never be seen on the Internet is deemed socially acceptable by most. RFC 1918 space provides 3 different ranges and allow for sub-dividing for additional logic. When I need more major subnets, the following come to mind: (100.64.0.0/10 – Carrier Grade NAT – RFC6598, 169.254.0.0/16 – Link Local – RFC 3927, and 198.18.0.0/15 – Benchmarking – RFC 2544). My personal favorite is the 100.64.0.0/10 range when I need a fourth range because it has lots of space for subnetting.
Note: The same logic should apply for IPv6 addresses too. 2001:db8::/32 is reserved for documentation and should provide enough space for almost anything.
This is where science and art become blurred. As you add logic to a numbering scheme, the quicker things will break. I use different major subnets to differentiate different concepts.
In most scenarios, I need at least two subnets, one for loopback addresses and the other for basic connectivity.
Loopbacks are typically used for router-ids, BGP peerings, multicast RPs, etc. Depending on what I’m using a loopback for, I pick a major class (I.E. 192.168.0.0/16) and use the last 2 or three octets to match the router number (I.E. R1= 192.168.1.1 and R11 = 192.168.11.11). I can make them /24 or /32 depending on my needs and will never conflict between other devices.
This logic allows for up to 254 devices. I’m not a big fan of just using the router number for all four octets because you encounter problems when you get to R10 (10.10.10.10) which could conflict in your 10.0.0.0/8 address range, and also intermixes with Public IPs.
For basic connectivity, I like to use the 10.0.0.0/8 address range, because I can generally use the second octet to list out which routers are connected to each other, sort-of like a link identifier.
- If I have a link between R1 and R2, I use 10.12.x.x/24 for the network. I use 10.34.x.x/24 when R3 connects to R4.
- If I have a LAN segment connecting multiple devices I use all three where applicable, or bleed into the 3rd octet. IE. LAN connecting R1, R2, R3 = 10.123.x.x/24 or if I have R4,R5,R6 connecting to a segment, I use 10.45.6.x/24. Now LAN segments are a perfect example of where logic can break, and the need to deviate in your logic. If your smart, move the router numbers around to keep the grouping below 255 J.
- I will use the 3rd octet to differentiate links. So let’s say I have two links connecting between R1 and R2. I use 10.12.1.x/24 for the first link, and 10.12.2.x/24 for the second link.
- For the fourth octet, I generally use the router number for it.
Generally this logic works really well for most scenarios. However, what about when you start to talk about multi-site topologies for WAN related topics…Well, then I use a site-identifier for the 2nd octet, and then move link-identifier (Routers on the link) to the 3rd octet. By doing so, I remove the ability to differentiate links; or have to sub-divide my /24 into a /25 and break the fourth octet’s logic.
So what happens when you need to talk about technologies that provide overlay routing (MPLS VPNs, GRE, 6PE, etc.) they all involve some form of an underlay network. What about scenarios that simulate the Internet and want to differentiate the Internet IP addresses from public addresses? Well then you might use a 3rd or 4th block of IP addresses to differentiate the traffic. Do you use the 172.16.0.0/12, or grab one of those other IP blocks I mentioned earlier… It all depends. Remember it’s part artistic.
The essential part is to use private-ip addressing, and a logic that is easy for others to identify quickly so that they can extract the relevant portion of the topology when looking at routing tables or configurations.
You can learn more about implementing IP addressing protocols in my book: IP Routing on Cisco IOS, IOS XE, and IOS XR: An Essential Guide to Understanding and Implementing IP Routing Protocols which is published by Cisco Press.