You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

(1) First, go and set up an LIR for TDS Telecom (or whatever branch of TDS is doing this):

/admin/admin-lir.php

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.

An example of how this should look from my own organization:


We can verify this information by querying the ARIN database, like so:

https://whois.arin.net/rest/org/CONNE-81/pft?s=conne-81 https://whois.arin.net/rest/poc/6CONN-ARIN?s=6conn-arin
So when something goes wrong with a 6connect IP block, people know who to yell at.

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.

(3) 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. If ARIN doesn't think that the IP block you are using is administered by the LIR you have set up, you will get nowhere with them.

(4) Danger #2: Make sure the IP space is actually assignable with ARIN. This is where a whole lot of problems happen.

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. ARIN's database is absolutely *filthy* in this regard.

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. As far as I can tell the only way to debug

SWIP the /28 -- it will just tell you its invalid. As far as I can tell the only way to debug this situation is manually probe the ARIN database until you find the already-SWIP'd block, construct tihs 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.

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 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:


From here we can see that the /27 is currently undivided as far as ARIN is concerned. ARIN's database is arranged in a hierarchy, so it first looks to see if that /27 exists in its

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:

https://whois.arin.net/rest/net/NET-67-221-240-0-1

And ARIN's own base allocation as the next-highest owner:

https://whois.arin.net/rest/net/NET-67-0-0-0-0

The story of this block is thefore: "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 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 is currently not possible to have a single Contact with both roles, so you'll need two.

Here is the last piece, our IP block:


So I open up the wrench menu for the IP block right here on the 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:

https://whois.arin.net/rest/net/NET-67-221-244-160-1

A new ARIN entry for the fake company has been automatically made:

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:

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 that /27, they'll know to call up Test Jonny at MedaTeckle to yell at them, and not me.











  • No labels