LIR Walkthrough
| Info | ||
|---|---|---|
| ||
Before you begin, determine who in your organization has access to the RIR API Keys related to the ASNs used by your organization and gather the following data: For ARIN, you will need to gather data for the ASN, Org ID, Admin/Tech/Abuse POCs, Name Prefix, and API Keys for each ASN. For all other RIRs, you will need information for the Maintainer, Password, and Admin/Tech Contacts per ASN. |
Table of Contents
Create LIRs
(1) First, go and set up an LIR for TDS Telecom (or whatever branch of TDS is doing this):
/admin/admin-lir.php
from Admin → IPAM Admin.
Click "Add / Edit / Update LIRs"
Complicated or large organizations will likely need many.
Start by adding a new LIR by clicking the "Add LIR" button at the top of the page:
At this point, you should have data collected for each RIR/ASN combination used in your organization.
Select the RIR, enter the Name and ASN, and then enter the relevant Org ID / POC / API Key (or Password) for the LIR. Entering the ARIN API Keys for ARIN LIRs An organization of TDS's complexity will likely need many. Someone in your organization knows the ARIN API keys relevant to the different AS-numbers TDS Telecom will be using. This step is critical for every SWIP action. The API Key contained within an LIR object will be used to authenticate against ARIN's systems when you want to update them. I do not know how you can hunt this individual down. If you can give the IP block you want to work with I can query the ARIN database perhaps we can find out some clues
When you are done, click "Save" and continue to add other LIRs as needed.
An example of how this should look from my own organization:
We can verify this information by querying the ARIN database, like so:
| No Format |
|---|
https://whois.arin.net/rest/org/CONNE-81/pft?s=conne-81 https://whois.arin.net/rest/poc/6CONN-ARIN?s=6conn-arin |
...
When you are doing a *Simple* re-assign, you posting a notice that when something goes wrong with a particular block of IP space, people should yell at the contact listed in the LIR. Which is to say: you. When you are doing a *Detailed* re-assign you are supplying a different set of contacts, and posting them to receive the aformentioned yelling.
Once you have an LIR in ProVision, it is trivial to query the API of its resource from the ProVision database . The above is resource id# 451 in our local database, but it will undoubtably be something different in yours.
(2) Setup. I'm going to assume you have entered IP space, and have entered some sample Contacts, and have built an example Resource. Further, I'm going to assume you have associated those Contacts with the Resource, and have Assigned some IP space to that Resource. So we need to have a Resource with an IP Block and some Contacts.
There are many dangers here.
...
using the resource Id number.
Set up IP Associations
From here, ensure that IP space has been entered into ProVision, along with necessary Contacts and Resources.
Associate Contacts with the Resources, and assign IP space to the necessary Resources. See: Working with Resources, Working with Entries, Contact Manager, and Working with IP Blocks.
Make sure that you have followed the following guidelines:
- Danger #1: Make sure you own the IP space in question. ARIN knows who is supposed to be administering every bit of IP space under its domain
...
- , and you will run into issues if you do not actually own the IP space according to the RIR.
- Danger #2: Make sure the IP space is actually assignable with ARIN.
...
| Info | ||
|---|---|---|
| ||
Lets imagine that 10 years ago some network administrator did a simple assignment with ARIN which noted that a certain /26 was under management by Company A. Since then, that administrator has been fired, the company he worked for has been acquired, that company was then itself acquired, and Company A has gone bankrupt and dissolved. Today, nobody knows about all this. But ARIN remembers that a certain /26 has been delegated to Company A, and nobody has informed them otherwise. |
...
This is a not-uncommon issue. So today, you come along and you are doing your tests with a /28 which happens to be a sub-block of the /26. You can configure everything correctly and despite that, ARIN will completely refuse to SWIP the /28, because ARIN thinks that the /28 is part of a /26 which is already SWIP'd. To make matters worse, ARIN won't tell you why it is refusing to |
...
SWIP the /28 -- it will just tell you its invalid. |
...
The only way to debug |
...
this situation is manually probe the ARIN database until you find the already-SWIP'd block, construct |
...
this block in ProVision, try to SWIP it (and fail, because it is already SWIP'd), then de-SWIP it, clearing the erroneous state both from ProVision and from ARIN. |
...
Due to a lack of access to the ARIN database, ProVision is limited in its methods of handling situations such as these. |
SWIP
We
This situation is something we've given a lot of thought to and the primary reason why we can't do this better is that ARIN does *not* enjoy people casually probing their database.
If we had access to that data we could do some wonderful things, but we don't. Its a mess.
(5) Ok. We've got everything together so lets let's do some SWIP'ing. Our happy candidate is 67.221.244.160/27, which is a slice of 6connect's very own domain. Screenshot from ARIN:
...
database (nope), then it looks for blocks it *does* know about it which contains it. Here we see 6connect's /20 as its immediate owner:
| No Format |
|---|
https://whois.arin.net/rest/net/NET-67-221-240-0-1 |
And ARIN's own base allocation as the next-highest owner:
| No Format |
|---|
https://whois.arin.net/rest/net/NET-67-0-0-0-0 |
The story of this block is theforetherefore: "ARIN was given this IP Block by ICANN, then ARIN did a Direct Allocation of a /20 to 6connect." And in a bit here, 6connect will do a detailed re-assign to MedaTeckle, a made-up company whose headquarters is the birthplace of Genghis Khan.
Here is my the resource:
And here are the contacts:
Having someone in the 'ARIN-NET' and the 'ARIN-ADMIN' roles is required for a Detailed Reassign. As I mentioned with Joe earlier, it It is currently not possible to have a single Contact with both roles, so you'll need two contacts listed.
Here is the last piece, our IP block:
So I open up the wrench gear menu for the IP block right here on the Resource resource page and I get this screen:
I select the LIR in the upper-left (currently selected: 6connect), the Net Name is automatically generated from the LIR + netblock, and we are using the "CONNE-81" organization within the 6connect LIR. This will supply the ARIN API Key to make this all happen. I hit Detailed Reassign and after a few minutes of waiting for ARIN to catch up, here are the results:
...
Our /27 has been delegated to our new fake company, here:
| No Format |
|---|
https://whois.arin.net/rest/net/NET-67-221-244-160-1 |
A new ARIN entry for the fake company has been automatically made:
| No Format |
|---|
https://whois.arin.net/rest/org/MEDAT-1.html |
...
https://whois.arin.net/rest/org/MEDAT-1.html |
And the relevant Points of Contact have been generated:
| No Format |
|---|
https://whois.arin.net/rest/org/MEDAT-1/pocs |
I will go clean this up later, but most people don't so the ARIN database is highly polluted.
This is how SWIP'ing works. Now if anyone has a problem with the behavior of This lets everyone know that if issues arise with that / 27, they 'll know to call up Test Jonny at MedaTeckle to yell at them, and not mewho to contact to resolve the issue.