ForHosting KIT · Outils pour développeurs

Calculateur CIDR d’adresses IPv4 totales et utilisables

Ce calculateur d’hôtes utilisables CIDR convertit une adresse IPv4 et son préfixe en limites exactes du réseau, adresse de diffusion, nombre total d’adresses et nombre d’hôtes utilisables.

● BetaGratuit · dans votre navigateur

Lancer gratuitement Voir l’API

Utilisez-le depuis WebAPIE-mailTelegramApp bientôt

Il accepte une notation courante telle que 192.168.1.0/24 et normalise aussi une adresse située à l’intérieur du bloc. Les réseaux point à point /31 et les routes d’hôte /32 sont comptés correctement, sans retirer aveuglément deux adresses. Le calcul est déterministe, local et adapté à la planification rapide comme à la validation automatisée.

Interprétez correctement adresses totales et hôtes utilisables

Un préfixe IPv4 indique combien des 32 bits de l’adresse désignent le réseau. Les bits restants désignent les positions dans ce réseau : le total vaut donc deux élevé au nombre de bits restants. Un /24 laisse huit bits et contient 256 adresses. Dans les sous-réseaux classiques de /0 à /30, la première adresse identifie le réseau et la dernière sert à la diffusion. Elles ne sont normalement pas attribuables aux hôtes, ce qui laisse 254 hôtes utilisables dans un /24. Le calculateur affiche les deux valeurs, car le total décrit le bloc alloué tandis que le nombre utilisable mesure la capacité ordinaire. Il fournit aussi les limites normalisées du réseau et de la diffusion pour vérifier l’appartenance d’une adresse. Le nombre réservé explicite la soustraction. Les résultats sont des entiers exacts, y compris les 4,294,967,296 adresses de l’espace IPv4 /0 complet, et conviennent aux inventaires, à la documentation et aux règles de validation.

Comprenez les règles particulières de /31 et /32

La règle habituelle consistant à retirer deux adresses comporte deux exceptions importantes. Un /31 contient exactement deux adresses. Sur une liaison point à point, des destinations distinctes pour le réseau et la diffusion ne sont pas nécessaires : les deux adresses peuvent identifier les extrémités selon la convention /31 largement utilisée. Le résultat indique donc deux adresses totales, deux utilisables et aucune réservée. Un /32 contient une seule adresse et représente une route vers un hôte, non un sous-réseau classique à plusieurs machines. Cette adresse unique est utilisable : une au total, une utilisable et zéro réservée. Une soustraction mécanique donnerait zéro, voire une valeur négative, et fausserait la planification du routage. Les champs réseau et diffusion restent présents pour conserver un format stable : ils coïncident en /32 et désignent les deux extrémités en /31. Vérifiez toutefois la compatibilité des équipements et les règles locales avant de déployer des liaisons /31.

Exploitez les limites normalisées pour planifier le réseau

Vous pouvez saisir toute adresse IPv4 accompagnée d’un préfixe, pas uniquement une adresse déjà placée au début du réseau. Si vous envoyez 192.168.1.37/24, le calculateur la normalise en 192.168.1.0/24 et renvoie 192.168.1.255 comme adresse de diffusion. Cette fonction facilite l’examen des objets de pare-feu, des inventaires d’hôtes, des plans cloud et des configurations produites par un autre système : elle révèle le bloc réel au lieu de répéter une adresse d’hôte trompeuse. Validez la saisie avant le provisionnement, comparez le CIDR normalisé à l’allocation prévue et utilisez usable_hosts pour contrôler la capacité. Une adresse mathématiquement utilisable peut rester réservée par un fournisseur, un équipement ou une politique interne ; ces réservations spécifiques ne sont pas incluses. Le service n’interroge pas DNS et n’inspecte aucun réseau actif. Il analyse uniquement la notation CIDR IPv4 décimale et applique une arithmétique déterministe, stable pour les pipelines, audits d’infrastructure, imports IPAM et exercices pédagogiques.

Cas d’usage

Dimensionner un sous-réseau

Vérifiez qu’un préfixe IPv4 proposé fournit assez d’adresses d’hôtes utilisables avant de l’allouer.

Valider une configuration réseau

Normalisez une adresse d’hôte avec son préfixe, puis comparez les limites de réseau et de diffusion à la configuration.

Modéliser une liaison point à point

Comptez correctement les deux extrémités d’un /31 lors de la planification de liaisons entre routeurs.

Questions fréquentes

Quel est le tarif ?

L’API coûte $0.002 par requête et le calculateur dans le navigateur est gratuit.

Pourquoi retire-t-on généralement deux adresses ?

Pour les préfixes de /0 à /30, la première adresse identifie le réseau et la dernière la diffusion ; les adresses intermédiaires sont utilisables.

Combien d’hôtes utilisables contient un /31 ?

Un /31 offre deux adresses utilisables aux extrémités d’une liaison point à point, sans réservation distincte pour le réseau ou la diffusion.

Combien d’hôtes utilisables contient un /32 ?

Un /32 représente une adresse d’hôte unique ; son nombre total et son nombre utilisable valent donc tous deux un.

Puis-je saisir une adresse d’hôte plutôt que l’adresse réseau ?

Oui. Le calculateur la normalise vers la limite réelle du réseau correspondant au préfixe fourni.

Le résultat inclut-il les réservations du fournisseur cloud ?

Non. Il applique seulement les règles CIDR IPv4 standard ; les réservations supplémentaires doivent être retranchées séparément.

Pour les développeurs — accès API

Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.

Endpoint

POSThttps://api.kit.forhosting.com/dev/cidr-host-count

Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.

Appeler depuis votre stack

curl -X POST https://api.kit.forhosting.com/dev/cidr-host-count \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"cidr":"192.168.1.0/24"}'

const res = await fetch("https://api.kit.forhosting.com/dev/cidr-host-count", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "cidr": "192.168.1.0/24"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev/cidr-host-count",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "cidr": "192.168.1.0/24"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/cidr-host-count", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"cidr":"192.168.1.0/24"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"cidr":"192.168.1.0/24"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/cidr-host-count", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Exemple de requête

{
  "cidr": "192.168.1.0/24"
}

Exemple de réponse

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.cidr_host_count",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.

Tarifs

par requête$0.002

Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.

Erreurs

HTTP	Code	Signification
`401`	`unauthorized`	Clé API absente ou invalide : vérifiez l’en-tête Authorization.
`402`	`insufficient_balance`	Solde insuffisant : rechargez votre compte pour lancer cette tâche.
`404`	`unknown_type`	Type de tâche inconnu : vérifiez le champ type de votre requête.
`429`	`rate_limited`	Trop de requêtes : ralentissez la cadence, puis réessayez.

Consulter la documentation complète du KIT →