We Keep Coding

Calculate which subnets an IP address belongs to

I'm kind of stuck on a particular issue. I need to calculate the subnets an IP address belongs to. It could be done in SQL or Python or similar.
So if I have e.g. 100.100.100.105 I need to get all the subnets:
100.100.100.105/32
100.100.100.104/31
100.100.100.104/30
100.100.100.104/29
100.100.100.96/28
100.100.100.96/27
100.100.100.64/26
...
100.64.0.0/10
100.0.0.0/9
...
64.0.0.0/2
0.0.0.0/1
But really don't know how to approach the issue.

you can achieve this with the python3 built in ipaddress module
import ipaddress
addresses = []
# get the int representation of your ip
ip = int(ipaddress.IPv4Address('100.100.100.105'))
for mask in range(32):
addresses.append(f'{ipaddress.IPv4Address(ip & ((2**32-1)-(2**mask -1)))}/{32-mask }')
At each iteration, we apply the mask to our IP by doing a logic AND operation between the integer representations of the IP and the mask. We then convert the result to ip octets and append the '/24' subnet notation. You can replace 2**32-1 with 4294967295, I left it there so its clearer what is happening.

How to know which IP is after a certain number of IPs

Im working on RIPE Delegation Stats
and each line in the file is in the following format:
registry|cc|type|start|value|date|status[|extensions...]
where start and value means the following:
start: This is the IPv4 'first address' of the range.
value: In the case of IPv4 address the count of hosts for this range. This count does not have to represent a CIDR range.
examples for start and value:
196.4.163.0|768
41.74.0.0|4096
195.35.104.64|192
198.54.38.0|1536
216.252.155.0|256
141.226.144.0|10240
93.242.1.0|20224
193.53.200.0|11520
How can I know which IP to end up with?
Thank you so much!
--- Update ----
I figured out how to solve this problem.
convert the first IP to a decimal number then add the value to it then convert back to ip < like that I will get both start and end IP for the range

ipcalc, sipcalc, or just pure Bash will do the trick.
For more answers, including with examples, see: https://serverfault.com/q/54981
As for Python, you can just use the builtin https://docs.python.org/3/library/ipaddress.html or just struct and socket builtins https://stackoverflow.com/a/44043448

how do you convert to cidr in python3?

I have an ip address 1.2.3.4 with a subnet mask 255.255.255.0
I want to convert this to cidr notation
1.2.3.4/24
How do I do this in Python3?

Use the ipaddress module in the standard library.
An address plus a netmask is either a network or an interface, not an address. Given that you've got some of the host bits set (it's 1.2.3.4, not 1.2.3.0), either you've got an interface, or you've got a non-canonical name for a network; I'll assume it's an interface, so use ip_interface:
>>> i = ipaddress.ip_interface('1.2.3.4/255.255.255.0')
Or, if you want to make sure it's explicitly IPv4 not IPv6:
>>> i = ipaddress.IPv4Interface('1.2.3.4/255.255.255.0')
Or you can compose it out of an address and a network, instead of out of a combined string. It depends on what format you have this information in and what makes sense to you.
To get the CIDR format, use the with_prefixlen accessor:
>>> i.with_prefixlen
'1.2.3.4/24'
You can also do all kinds of other nifty things—extract the address (1.2.3.4) as i.address, or the network (1.2.3.0/24) as i.network, or enumerate all the addresses on the network by treating i.network as a sequence, etc.

You can use the IPy library to do this. If you scroll down to the documentation you can see the string conversions it can do. The one we're after is strNormal(1)
IP("1.2.3.4/255.255.255.0").strNormal(1)

CIDR subnet calculation and python ipcalc

I am questioning the results of the ipcalc module (ipcalc) for Python (it seems that netaddr may be a better choice).
Let's take 192.168.1.25/30 as an example. In binary, the last octet is 00011001 AND 11111100 = 00011000, so I get 192.168.1.24 as the Network ID and the range 192.168.1.24 - 192.168.1.27.
Using ipcalc, when I specify
subnet = ipcalc.Network('192.168.1.25/30')
for x in subnet: print x
The output is
192.168.1.25
192.168.1.26
192.168.1.27
192.168.1.28
I am not understanding the inconsistency. When using CIDR notation, it seems that specifying both 192.168.1.24/30 and 192.168.1.25/30 (or .26/30 or .27/30) refer to the same subnet.
Is that correct? Is this just a bug in the ipcalc module?

There is an open bug for this at the moment: No way to resolve IP + Netmask to Network Object
And an earlier bug report that discuss the matter: Strange subnet calculations
But they have also added a function called network to get the network address from an IP. From the manual:
>>> localnet = Network('127.128.99.3/8')
>>> print localnet.network()
127.0.0.0
The manual specifically says that the constructor Network should take a network address as its first argument, not any IP in the network. Rather confusing if you ask me (especially since the above code block breaks that condition). I would at least read the code for the module before using it.

It's correct the subnet is 192.168.1.24/30 so the ips 192.168.1.24 to 192.168.1.27 make part of this network.

MAC address generator in python

For purpose of creating bulk virtual machines, I need to create a random MAC address generator in Python. I don't know how to generate random MAC addresses.
Is the following program correct or not?
import random
# The first line is defined for specified vendor
mac = [ 0x00, 0x24, 0x81,
random.randint(0x00, 0x7f),
random.randint(0x00, 0xff),
random.randint(0x00, 0xff) ]
print ':'.join(map(lambda x: "%02x" % x, mac))

For anyone wanting to generate their own MAC addresses (a good example is for VM NICs), you probably just want this:
"02:00:00:%02x:%02x:%02x" % (random.randint(0, 255),
random.randint(0, 255),
random.randint(0, 255))
Or, if you want to do this in a unix'y shell, this works on many:
printf '02:00:00:%02X:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256))
This gives you a unicast MAC address that is 100% safe to use in your environment, and isn't trampling on anyone's registered MAC address space.
More detail...
The bottom two bits of the top byte (0x02) give you a locally administered unicast address, which is probably what you want if you are hitting stackoverflow for how to generate this. :)
If the MAC address is not locally administered, it means it is supposed to be "globally unique". MAC addresses in this category are centrally registered with the IEEE, and you should have a unique OUI (Organizationally Unique Identifier) issued to you by the IEEE. See this link for the global registry of OUI values. This OUI value ends up in the first 3 bytes (or just the top 22 bits, really).
MAC addresses aren't that complicated, so you should probably also just have a look at the definition. Wikipedia has a good one.

Modified from mamofish's code to Python3:
mac = '00:00:00:'
for number in range(16**6):
hex_num = hex(number)[2:].zfill(6)
print("{}{}{}:{}{}:{}{}".format(mac,*hex_num))
Generates mac addresses as strings from 00:00:00:00:00:00 to 00:00:00:ff:ff:ff.

Since uniqueness is all you should care about (beyond making the address well-formed), I'd worry about the MSBs in the OUI and use a sequence in the NIC specific bytes. The distribution of the addresses is likely unimportant to your application (even though some NIC or switch implementations might use them as an input to a hash, this is likely not to be a big concern).
You may want to consider using the "locally administered" flag in the OUI to avoid a conflict with an existing device manufacturer.
Avoid pitfalls like setting the multicast bit (your example does).

To avoid duplicates:
If you're going to generate a LOT (millions) of such MAC addresses, you might want to generate an in-order list of MAC's, feed that to a linear randomization process (GNU sort -R should do fine - I don't think it does this in linear time, but it has a similar end result) once, and then pull your fresh addresses off one end of the randomized list as needed. I believe such a list should fit in about 34 megabytes.
If you merely need thousands, you're probably better off maintaining a text file with already-selected values, and checking for collisions against that, adding new values as you go. This is a slower algorithm asympotically speaking, but it has a much less overhead, so it should still be a win for lower numbers of mac addresses.
BTW, should the 4th octet (numbered from 1 starting on the left), be 0-ff instead of 0-7f? I see no occurrences of 7f or 127 in the Wikipedia page on Mac addresses:
http://en.wikipedia.org/wiki/MAC_address