Vous êtes sur la page 1sur 20

Configuration du NAT sur un routeur Cisco

De Steve De Jongh | 6 avril 2013 | Cisco, La pratique

Quand il s’agit d’interconnecter un réseau privé (que ce soit d’entreprise ou particulier), en IPv4, il est
pratiquement impossible de se passer du NAT. Voici donc une configuration qui reprend l’essentiel des trois
principaux types de NAT que l’on peut configurer, à savoir:

 Le NAT statique
 Le NAT dynamique avec pool d’adresses
 Le NAT dynamique avec surcharge (NAT overload, aussi connu sous le nom de PAT)

Topologie du labo

Le labo est divisé en deux parties, le côté privé (réseau de l’entreprise) et le côté publique (le FAI et
Internet). Le routeur ISP (qui représente le FAI), n’a aucune connaissance des réseaux privés de l’entreprise
et ne peut donc rien router à destination des réseaux 192.168.x.x. (comme défini dans la RFC1918). Ces
adresses sont réservées pour l’utilisation dans les réseaux privés. Il en va de même pour toutes les adresses
faisant parties des plages suivantes:

 10.0.0.0/8 (de 10.0.0.0 à 10.255.255.255)


 172.16.0.0/12 (de 172.16.0.0 à 172.31.255.255)
 192.168.0.0/16 (de 192.168.0.0 à 192.168.255.255)

Dès lors, nous allons configurer le NAT afin de permettre un accès à Internet (simulé par l’adresse
8.8.8.8/32 configurée sur une interface loopback d’ISP):

 Le réseau 192.168.0.0/24 utilisera du NAT dynamique avec surcharge.


 Le réseau 192.168.1.0/24 utilisera du NAT avec pool d’adresse.
 La machine 192.168.1.100 sera accessible depuis le réseau publique grâce à une configuration de
NAT statique.

1
Configuration de la topologie de base
Sur ISP:

Configuration de l’interface loopback

ISP#conf t
ISP(config)#int l0
ISP(config-if)#ip address 8.8.8.8 255.255.255.255
ISP(config-if)#exit

Configuration de la liaison sérielle vers R1

ISP(config)#int s0/0
ISP(config-if)#no shut
ISP(config-if)#ip address 80.79.100.1 255.255.255.252
ISP(config-if)#exit

Configuration de la route vers le pool d’adresses publique

ISP(config)#ip route 201.49.10.16 255.255.255.240 serial 0/0

Sur R1 :

Configuration de l’interface sérielle vers ISP

R1#conf t
R1(config)#int s0/0
R1(config-if)#ip address 80.79.100.2 255.255.255.252
R1(config-if)#no shut
R1(config-if)#exit

Configuration de l’interface du LAN1

R1(config)#int fa0/0
R1(config-if)#ip address 192.168.0.1 255.255.255.0
R1(config-if)#no shut
R1(config-if)#exit

Configuration de l’interface du LAN2

R1(config)#int fa0/1
R1(config-if)#ip address 192.168.1.1 255.255.255.0
R1(config-if)#no shut
R1(config-if)#exit

Configuration de la route par défaut

R1(config)#ip route 0.0.0.0 0.0.0.0 serial 0/0

Pour le moment il est possible d’effectuer les tests suivants:

 Effectuer un ping depuis chaque PC vers R1


 Effectuer un ping entre les PCs de LAN différent
 Effectuer un ping depuis R1 vers 8.8.8.8

2
Test de C1 à R1
VPCS[1]> ping 192.168.0.1
192.168.0.1 icmp_seq=1 ttl=255 time=70.000 ms
192.168.0.1 icmp_seq=2 ttl=255 time=54.000 ms
192.168.0.1 icmp_seq=3 ttl=255 time=67.000 ms
192.168.0.1 icmp_seq=4 ttl=255 time=65.000 ms
192.168.0.1 icmp_seq=5 ttl=255 time=63.000 ms

Test de C1 à C2
VPCS[1]> ping 192.168.1.10
192.168.1.10 icmp_seq=1 ttl=63 time=31.000 ms
192.168.1.10 icmp_seq=2 ttl=63 time=16.000 ms
192.168.1.10 icmp_seq=3 ttl=63 time=32.000 ms
192.168.1.10 icmp_seq=4 ttl=63 time=32.000 ms
192.168.1.10 icmp_seq=5 ttl=63 time=32.000 ms

Test de R1 à 8.8.8.8
R1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/29/112 ms

Par contre impossible par exemple pour C1 de communiquer avec 8.8.8.8

VPCS [1]> ping 8.8.8.8


8.8.8.8 icmp_seq=1 timeout
8.8.8.8 icmp_seq=2 timeout
8.8.8.8 icmp_seq=3 timeout
8.8.8.8 icmp_seq=4 timeout
8.8.8.8 icmp_seq=5 timeout

Configuration commune à tout type de NAT


La première chose à faire lorsque l’on configure du NAT, quel qu’en soit le type, c’est d’indiquer au routeur
où se situe le réseau privé et où se situe le réseau publique.

Le NAT ne prend effet que lorsque qu’un paquet est routé d’une interface « inside » (côté privé) vers une
interface « outside » (côté publique) et vice-versa.

Dans notre cas, les interfaces Fa0/0 et Fa0/1 sont du côté privé et seront déclarées comme « inside »,
l’interface S0/0 par contre, étant du côté publique, sera configurée comme « outside ».

R1(config)#int fa0/0
R1(config-if)#ip nat inside
R1(config-if)#exit
R1(config)#int fa0/1
R1(config-if)#ip nat inside
R1(config-if)#exit
R1(config)#int s0/0
R1(config-if)#ip nat outside
R1(config-if)#exit

3
Configuration du NAT statique pour C3
Ce que nous allons configurer ici c’est une translation statique dans la table de translation NAT, ce qu’on
appelle vulgairement sur du matériel domestique « ouvrir un port ». Nous allons explicitement indiquer au
routeur que ce qui arrive sur son interface publique (S0/0) et dont l’adresse destination est 201.49.10.30 (une
des adresse du pool publique) doit être redirigé vers 192.168.1.100.

Du point de vue du routeur cela revient à modifier l’adresse IP destionation dans l’en-tête IPv4 avant de
router le paquet. Cela signifie aussi que si C3 envoi un paquet vers internet, à la sortie de S0/0 de R1
l’adresse source (192.168.1.100) sera remplacée par l’adresse indiquée dans la translation, soit 201.49.10.30.

R1(config)#ip nat inside source static 192.168.1.100 201.49.10.30

La table de translations NAT doit mainentant ressembler à ceci:

R1#show ip nat translations


Pro Inside global Inside local Outside local Outside global
--- 201.49.10.30 192.168.1.100 --- ---
R1#

A présent C3 doit pouvoir communiquer avec le réseau publique

VPCS[3]> ping 8.8.8.8


8.8.8.8 icmp_seq=1 ttl=254 time=119.000 ms
8.8.8.8 icmp_seq=2 ttl=254 time=102.000 ms
8.8.8.8 icmp_seq=3 ttl=254 time=75.000 ms
8.8.8.8 icmp_seq=4 ttl=254 time=117.000 ms
8.8.8.8 icmp_seq=5 ttl=254 time=116.000 ms

Chaque paquet a donc été translaté, preuve en est la table de translations juste après l’émission de ces pings:

R1#show ip nat translations


Pro Inside global Inside local Outside local Outside global
icmp 201.49.10.30:33598 192.168.1.100:33598 8.8.8.8:33598 8.8.8.8:33598
icmp 201.49.10.30:33854 192.168.1.100:33854 8.8.8.8:33854 8.8.8.8:33854
icmp 201.49.10.30:34366 192.168.1.100:34366 8.8.8.8:34366 8.8.8.8:34366
icmp 201.49.10.30:34622 192.168.1.100:34622 8.8.8.8:34622 8.8.8.8:34622
icmp 201.49.10.30:34878 192.168.1.100:34878 8.8.8.8:34878 8.8.8.8:34878
--- 201.49.10.30 192.168.1.100 --- ---
R1#

On peut observer le résultat de la translation du côté de ISP aussi à l’aide de la commande « debug ip
packet » qui va afficher le détail de chaque paquet IP traité par le routeur (Attention, dans un environnement
réel cette commande peut gravement saturer le routeur).

ISP#debug ip packet

*Mar 1 02:22:49.491: IP: tableid=0, s=201.49.10.30 (Serial0/0), d=8.8.8.8 (Loopback0),


routed via RIB

*Mar 1 02:22:49.491: IP: s=201.49.10.30 (Serial0/0), d=8.8.8.8, len 92, rcvd 4

*Mar 1 02:22:49.495: IP: tableid=0, s=8.8.8.8 (local), d=201.49.10.30 (Serial0/0),


routed via FIB

*Mar 1 02:22:49.495: IP: s=8.8.8.8 (local), d=201.49.10.30 (Serial0/0), len 92, sending

4
Configuration du NAT avec pool d’adresses
Pour l’instant seul C3 a accès au réseau publique, nous allons maintenant configurer un autre type de NAT
pour le réseau 192.168.1.0/24 (à l’exception de C3).

Ici, au lieu de configurer une translation statique, nous allons donner au routeur une plage d’adresses
publiques (un pool d’adresse) dans laquelle il peut piocher pour créer dynamiquement les translations.

Tout d’abord créons le pool d’adresses

R1(config)#ip nat pool POOL-NAT-LAN2 201.49.10.17 201.49.10.30 netmask 255.255.255.240

Ici on crée donc une plage d’adresse nommée POOL-NAT-LAN2 allant de 201.49.10.17 à 201.49.10.30.Il
nous faut ensuite définir quelles adresses IP sources seront susceptibles d’êtres translatées … pour cela il
faut créer une ACL.

R1(config)#access-list 1 deny 192.168.1.100


R1(config)#access-list 1 permit 192.168.1.0 0.0.0.255

On autorise donc à être translatées les adresses ip du réseau 192.168.1.0/24 sauf 192.168.1.100 (pour
laquelle on a déjà une translation statique).

Il ne reste plus qu’à configurer le NAT en lui même

R1(config)#ip nat inside source list 1 pool POOL-NAT-LAN2

On instruit donc ici le routeur de créer dynamiquement une translation pour les paquets arrivant sur une
interface « inside » routés par une interface « outside » dont l’adresse IP source correspond à l’ACL 1 et de
remplacer l’IP source par une de celles comprises dans le pool POOL-NAT-LAN2.

Attention, si il y a plus de machine dans le réseau privé que d’adresses publiques disponibles, il faut alors
rajouter le mot clé « overload » à la commande:

R1(config)#ip nat inside source list 1 pool POOL-NAT-LAN2 overload

Ceci permet de « partager » les adresses publiques en translatant également les numéros de ports dans
l’entête de la couche transport (méthode communément appelée PAT).

A présent C2 (et les autres machines qui seraient dans le réseau 192.168.1.0/24) peuvent communiquer avec
l’extérieur.

VPCS[2]> ping 8.8.8.8


8.8.8.8 icmp_seq=1 ttl=254 time=111.000 ms
8.8.8.8 icmp_seq=2 ttl=254 time=97.000 ms
8.8.8.8 icmp_seq=3 ttl=254 time=143.000 ms
8.8.8.8 icmp_seq=4 ttl=254 time=131.000 ms
8.8.8.8 icmp_seq=5 ttl=254 time=99.000 ms

La table de translation de R1 a maintenant une nouvelle entrée crée dynamiquement, mais qui réserve
l’adresse publique pour C2 (tant que l’on ne purge pas la table NAT).

R1#sh ip nat trans


Pro Inside global Inside local Outside local Outside global
--- 201.49.10.17 192.168.1.10 --- ---
--- 201.49.10.30 192.168.1.100 --- ---
R1#
5
Configuration du NAT dynamique avec surcharge (sans pool)
Il reste encore à configurer R2 pour que le réseau 192.168.0.0/24 puisse accéder à l’extérieur. Pour cela nous
allons configurer le troisième type de NAT, à savoir du NAT dynamique avec surcharge (overload) en
utilisant l’adresse publique configurée sur l’interface S0/0 de R1.

Notez que c’est la configuration la plus courante dans un réseau modeste (par exemple dans un réseau
domestique). Cette méthode ne requiert pas d’obtenir de nouvelles adresses publiques auprès du provider.

Nous devons cette fois aussi identifier les adresses sources à faire passer par le NAT, donc nous créons une
nouvelle ACL.

R1(config)#access-list 2 permit 192.168.0.0 0.0.0.255

Il ne reste plus qu’à configurer le NAT.

R1(config)#ip nat inside source list 2 interface serial 0/0 overload

Nous disons ici au routeur de translater les paquets provenant des adresses décrites dans l’ACL 2
(192.168.0.0/24) et de remplacer l’adresse IP source par celle configurée sur l’interface Serial 0/0 en la
surchargeant pour permettre à plus d’une machine de communiquer avec l’extérieur (PAT).

C1 (ainsi que toute machine de ce réseau) peut communiquer avec l’extérieur désormais

VPCS[1]> ping 8.8.8.8


8.8.8.8 icmp_seq=1 ttl=254 time=132.000 ms
8.8.8.8 icmp_seq=2 ttl=254 time=130.000 ms
8.8.8.8 icmp_seq=3 ttl=254 time=127.000 ms
8.8.8.8 icmp_seq=4 ttl=254 time=112.000 ms
8.8.8.8 icmp_seq=5 ttl=254 time=125.000 ms

Le « debug ip packets » sur ISP donne le résultat suivant

ISP#
*Mar 1 03:11:46.195: IP: tableid=0, s=80.79.100.2 (Serial0/0), d=8.8.8.8 (Loopback0),
routed via RIB
*Mar 1 03:11:46.195: IP: s=80.79.100.2 (Serial0/0), d=8.8.8.8, len 92, rcvd 4
*Mar 1 03:11:46.199: IP: tableid=0, s=8.8.8.8 (local), d=80.79.100.2 (Serial0/0),
routed via FIB
*Mar 1 03:11:46.199: IP: s=8.8.8.8 (local), d=80.79.100.2 (Serial0/0), len 92, sending

On voit là que c’est bien l’adresse de S0/0 qui est utilise pour remplacer l’IP source du paquet.

6
Configure NAT – GNS3 Lab
To configure static NAT we need to complete these tasks:
* Define the router’s interfaces as inside or outside:
R0uter(config-if)#ip nat inside (or ip nat outside)

* Define static mapping between the inside address and the outside address:
R0uter(config)#ip nat inside source static

+ Static NAT:

To make everything clear, we will configure static NAT in GNS3. Open your GNS3 and build a topology
like this:

(IOS used: c2600-bin-mz.123-6f.bin but you can use other versions)

We should use 3 routers in this topology but I want to save some RAM and demonstrate how to ping from
the loopback interface so I only use two :) Therefore we should configure the loopback interface of R0 as
the source IP address and the fa0/0 interface of R0 as the “outgoing static NAT” address.

R0#configure terminal
R0(config)#int loopback0
R0(config-if)#ip address 10.0.0.1 255.0.0.0
R0(config-if)#ip nat inside

R0(config-if)#int f0/0
R0(config-if)#ip address 200.0.0.1 255.255.255.0
R0(config-if)#no shutdown
R0(config-if)#ip nat outside
R0(config-if)#exit

Finally, we have to tell the router to translate my private IP 10.0.0.1 to public IP 200.0.0.2 so that I can go to
the Internet!

R0(config)#ip nat inside source static 10.0.0.1 200.0.0.2

In R1 we just assign the IP address and no shut its interface.

R1#config terminal
R1(config)#int f0/0
R1(config-if)#ip address 200.0.0.10 255.255.255.0
R1(config-if)#no shutdown

Check if all things are right or not:

R0#show ip nat translations

7
In this article we don’t use a host attached to R0 so if we want to test our NAT configuration we have to
ping from R0′s loopback interface by using the ping extended command:

We can use the extended ping command by typing only “ping” at the privileged mode, specify the “target IP
address” and type “y” at the “Extended commands” and specify the “source address or interface” at shown
below:

To approve NAT works well we can disable static NAT with the following command

R0(config)#no ip nat inside source static 10.0.0.1 200.0.0.2

Now if we use the extended ping command (without NAT configured):

-> We can’t ping from the loopback interface.

Download static NAT configuration: http://www.9tut.com/download/NAT_static_CCNA_self_study.zip

+ Dynamic NAT:

To configure dynamic NAT we need to complete these tasks:

8
* Define a pool of addresses (public IP) to be used for dynamic NAT allocation

Router(config)#ip nat pool pool_name start_ip end_ip { netmask netmask | prefix-length prefix-length }

* Configure a standard access control list to define what internal traffic will be translated

Router(config)#access-list access-list-number permit source [source-wildcard]

Link the access list to the NAT pool

Router(config)#ip nat inside source list access-list-number pool pool_name

Define interfaces as either inside and outside

Router(config-if)# ip nat inside (on fa0/0, for example)


Router(config-if)#ip nat outside (on fa0/1, for example)

* Dynamic NAT configuration example:

RouterA(config)# access-list 1 permit 192.168.0.0 0.0.0.255


RouterA(config)# ip nat pool PoolforNAT 200.23.123.6 200.23.123.10 netmask 255.255.255.0
RouterA(config)# ip nat inside source list 1 pool PoolforNAT

Note: In the above command, the word “inside” means “I want to NAT from inside to outside”; “list 1″
means “the source IP addresses to NAT are included in Access-list 1″; “pool PoolforNAT” means “NAT to
the IP addresses specified in PoolforNAT”.

RouterA(config)# int loopback0


RouterA(config-if)# ip nat inside

RouterA(config-if)# int fa0/0


RouterA(config-if)# ip nat outside

Configure PAT (NAT Overload)

* Configure a standard access list to define what internal traffic will be translated
* Link the access list to the interface to be used for PAT
* Define interfaces as either inside or outside

PAT router commands


RouterA(config)# access-list 1 permit 192.168.0.0 0.0.0.255
RouterA(config)# ip nat inside source list 1 interface fa0/0 overload

(Notice the “interface fa0/0″ means “NAT out of this interface” and the keyword overload for PAT in the
above command)

RouterA(config)# interface fa0/0


RouterA(config-if)# ip nat outside

RouterA(config-if)# interface loopback0


RouterA(config-if)# ip nat inside

9
Configuration DHCP sur un routeur Cisco
Le protocole DHCP (Dynamic Host Configuration Protocol) a pour fonctionnalité de fournir aux machines
qui le demandent une configuration IP complète, adresse IPv4, masque de sous-réseau, passerelle par défaut,
serveur dns… Cet article a pour sujet la configuration d’un routeur Cisco en serveur DHCP.

Topologie de la configuration

Nous allons ici réaliser la configuration de R1, routeur d’accès à internet du réseau et DHCP, routeur faisant
office de serveur DHCP. Bien entendu les services DHCP auraient pu être configurés sur R1, mais pour des
raisons didactiques j’ai choisi de séparer cette fonctionnalité. vous comprendre pourquoi plus tard dans
l’article.

La configuration ne reprendra que ce qui est relatif au DHCP, R1 est donc censé être configuré selon les
besoins standards (adresses IPv4 sur les interfaces, route par défaut pointant vers ISP, et bien sûr un peu de
NAT pour permettre l’accès au réseau publique).

Configuration initiale
Afin d’éviter de finir avec un article de plusieurs pages de long, je ne mettrai ici que la configuration
nécessaire. Les paramètres par défaut ne sont pas inclus.

Sur ISP

hostname ISP
!
interface Loopback0
ip address 8.8.8.8 255.255.255.255
!
interface Serial0/0
ip address 80.100.200.1 255.255.255.252
clock rate 2000000

Sur R1

interface FastEthernet0/0
10
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
interface Serial0/0
ip address 80.100.200.2 255.255.255.252
ip nat outside
ip virtual-reassembly
clock rate 2000000
!
interface FastEthernet0/1
ip address 192.168.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
ip route 0.0.0.0 0.0.0.0 Serial0/0
!
ip nat inside source list 1 interface Serial0/0 overload
!
access-list 1 permit any

Sur DHCP

hostname DHCP
!
interface FastEthernet0/0
ip address 192.168.1.5 255.255.255.0
duplex auto
speed auto
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1

Attention, la route par défaut sur DHCP est nécessaire pour la suite de la configuration, j’en toucherai un
mot plus loin.

Piqûre de rappel
Le protocol DHCP est véhiculé directement dans une trame. De plus la machine qui émet une requête
DHCP, n’ayant encore aucune identité (adresse IPv4 etc) n’a d’autre possibilité que de communiquer par
broadcast. Cela signifie donc que la requête DHCP émise par cette machine est une trame broadcast.

Cela peut paraître sans importance, mais il ne faut pas oublier qu’un broadcast est confiné dans son domaine
de diffusion, autrement dit, il ne dépasse pas un routeur. Hors, ici, entre le serveur DHCP et le LAN1 il y a
R1… un routeur!

Nous devrons donc par la suite s’assurer que R1 soit configuré pour relayer la requête DHCP à destination
du serveur DHCP.

Méthode de configuration
Afin que DHCP puisse distribuer des adresses à la fois dans le LAN1 et dans le LAN2 nous allons devoir
configurer les points suivants:

11
 Exclure les adresses qu’on souhait ne pas distribuer (celle de la passerelle, ou de machines ayant des
adresses fixes)
 Pour chaque LAN configurer un pool DHCP dans lequel on spécifiera les options (passerelle, serveur
dns, adresse réseau, …)
 Configurer le relai DHCP pour le LAN1, sur R1.

La configuration
La bonne pratique veut que l’on configure le serveur DHCP dans un ordre qui peut paraître illogique au
premier abord. Ce qu’il faut savoir, c’est qu’une fois le pool DHCP configuré, le routeur va commencer à
attribuer des adresses. Il est donc conseillé de configurer en premiers les options (adresses à exclure
paramètres du pool… le tout avant de définir la plage d’adresse à prendre en charge), sans quoi il se pourrait
que les premières configurations reçues par les machines soient incomplètes.

Commençons par le routeur DHCP…

Exclusion des adresses nécessaires (adresse des passerelles, du serveur DHCP, …) ici nous allons exclure
les dix premières de chaque LAN (choix arbitraire).

DHCP(config)#ip dhcp excluded-address 192.168.0.1 192.168.0.10


DHCP(config)#ip dhcp excluded-address 192.168.1.1 192.168.1.10

Attention dans la définition des adresses à exclure, la première adresse donne le début de la plage et la
deuxième la fin de la plage à exclure. Si vous ne souhaitez qu’exclure une adresse, il suffit de ne pas donner
d’adresse de fin.

Configurons maintenant le pool DHCP pour la LAN1…

DHCP(config)#ip dhcp pool LAN1


DHCP(dhcp-config)#default-router 192.168.0.1
DHCP(dhcp-config)#dns-server 8.8.8.8
DHCP(dhcp-config)#network 192.168.0.0 255.255.255.0
DHCP(dhcp-config)#exit

On a donc créé ici un pool DHCP nommé LAN1, dans lequelles les machines recevront comme passerelle
par défaut 192.168.0.1 (l’adresse de R1 dans le LAN1), un serveur DNS 8.8.8.8 (totalement fictif ici, mais il
me semblait indispensable de montrer comment le configurer)… et cette configuration sera valable pour le
réseau 192.168.0.0/24 (plage d’adresse à distribuer de laquelle il faut soustraire les adresses précédemment
exclues).

Faison de même pour le LAN2…

DHCP(config)#ip dhcp pool LAN2


DHCP(dhcp-config)#default-router 192.168.1.1
DHCP(dhcp-config)#dns-server 8.8.8.8
DHCP(dhcp-config)#network 192.168.1.0 255.255.255.0
DHCP(dhcp-config)#exit

A présent les machnes du LAN2 doivent recevoir leur configuration correctement étant donné que le
serveur DHCP est dans le même domaine de diffusion qu’elles.

Vérifions sur C2…

VPCS[2]> ip dhcp
DDORA IP 192.168.1.11/24 GW 192.168.1.1

12
Le serveur DHCP devrait également avoir gardé ce bail DHCP en mémoire…

DHCP#show ip dhcp binding


Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
192.168.1.11 0100.5079.6668.01 Mar 02 2002 12:34 AM Automatic
DHCP#

Par contre … impossible pour C1 de recevoir sa configuration …

VPCS[1]> ip dhcp
DDD
Can't find dhcp server

En effet, lorsque R1 reçoit la tramme de broadcast contenant la requête DHCP de C1, vu qu’il ne sait rien en
faire, il la « jette » purement et simplement.

Il nous faut configurer le relai des trames DHCP vers le serveur DHCP. Pour cela nous devons dire
explicitement à R1 de relayer ces trames à 192.168.1.5 (le serveur DHCP) lorsqu’elles entrent sur son
interface Fa0/0. Voici la manipulation:

R1(config)#interface fastEthernet 0/0


R1(config-if)#ip helper-address 192.168.1.5

Notez que la commande « ip helper-address » a plus d’utilité que le simple relai des requêtes DHCP. Elle
sert à relayer les broadcasts UDP de plusieurs protocoles (DHCP, NTP, Netbios…).

A présent C1 peut aussi obtenir sa configuration par DHCP

VPCS[1]> ip dhcp
DDORA IP 192.168.0.11/24 GW 192.168.0.1

DHCP doit également avoir retenu les informations concernant ce bail DHCP…

DHCP#show ip dhcp binding


Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
192.168.0.11 0100.5079.6668.00 Mar 02 2002 01:27 AM Automatic
192.168.1.11 0100.5079.6668.01 Mar 02 2002 12:34 AM Automatic
DHCP#

Quelques explications complémentaires…


Comment fait DHCP pour savoir dans quel pool d’adresse il doit piocher en réponse à une requête venant du
LAN1 ou du LAN2 ?

Dans le cas du LAN2, la requête arrive sous forme de broadcast, sur l’interface ethernet de DHCP, il lui
suffit alors de fournir une configuration pour une machine dansle même domaine de diffusion que lui, donc
le pool LAN2.

Par contre dans le cas du LAN1, la requête arrive à DHCP sous forme d’unicast, car elle est relayée par R1.
R1 a en réalité, construit un paquet unicast, avec comme adresse source celle de son interface dans le LAN1
et comme destination celle du serveur DHCP.
13
Dés lors quand DHCP reçoit la requête unicast, il propose une adresse provenant du pool dont la plage
d’adresse correspond à celle configurée sur l’interface Fa0/0 de R1.

Quelques paramètres en plus…


Bien entendu la configuration du DHCP ne se limite pas à une adresse, un masque, une passerelle et un
serveur DNS. Voici quelques autres paramètres configurables…

Définir le nom de domaine qui sera associé à l’interface recevant la configuration…

DHCP(config)#ip dhcp pool LAN1


DHCP(dhcp-config)#domain-name test.lab

Configurer la durée du bail DHCP…

DHCP(dhcp-config)#lease 5 10 30

Le format est « lease <jours> <heures> <minutes> ». On peut également défini un bail illimité en utilisant
« lease infinite ».

Il est également possible de configurer des options « brutes ». Ce sont des paramètres n’ayant pas de nom
spécifiques. Mais la syntaxe varie en fonction des données à fournir.

Par exemple, si on doit renseigner une adresse de serveur TFTP pour qu’une machine puisse y récupérer une
image de démarrage (c’est le cas dans avec les systèmes de déploiement réseau), il faut indiquer l’option
150, avec comme paramètre l’adresse ip du serveur TFTP.

DHCP(dhcp-config)#option 150 ip 192.168.1.50

Encore une vérification…


Nous avons vu précédemment la commande « show ip dhcp binding » qui affiche la liste des baux en cours.
Il est aussi possible d’afficher les pools DHCP et leurs statistiques…

DHCP#sh ip dhcp pool LAN1


Pool LAN1 :
Utilization mark (high/low) : 100 / 0
Subnet size (first/next) : 0 / 0
Total addresses : 254
Leased addresses : 1
Pending event : none
1 subnet is currently in the pool :
Current index IP address range Leased addresses
192.168.0.12 192.168.0.1 - 192.168.0.254 1
DHCP#

Voilà de quoi configurer un serveur DHCP fonctionnel.

14
HSRP : Hot Standby Router Protocol

Sur un PC on configure généralement une seule passerelle par défaut… Mais que se passe-t-il si celle-ci est
hors service ? … La réponse est simple … plus moyen de communiquer en dehors de son domaine de
diffusion.

Pour remédier à cela, il existe plusieurs méthodes pour gérer la redondance de passerelle dont les protocoles
HSRP, VRRP et GLBP.

Voici un exemple simple de mise en place de redondance de passerelle à l’aide de HSRP. Il est toutefois
important de noter qu’il s’agit d’un protocole propriétaire Cisco.

La topologie

Afin d’aller directement à l’essentiel, la configuration de base de la topologie est considérée comme
terminée. Pour ma part j’ai simplement activé EIGRP entre R1, R2 et R3.

R3 dispose d’une interface Loopback (1.1.1.1/32) que j’utiliserai pour tester la communication depuis le PC.

Le PC (C1) est configuré avec l’adresse 192.168.0.10/24 avec une passerelle par défaut 192.168.0.254.
Notez qu’il ne s’agit pas de l’adresse configurée sur R1 ou R2 … Mais ce sera celle dont le rôle sera assumé
soit par R1 soit par R2 en fonction de l’état du réseau.

Principe général
HSRP est un protocole qui fourni une solution de continuité de service principalement pour la redondance de
passerelles par défaut.

Pour chaque réseau, on associe les interfaces des routeurs à un groupe HSRP (le même n° de groupe pour
toutes les interfaces qui doivent assurer le même rôle). A ce groupe on associe une adresse IP virtuelle (dans
le cas présent ce sera 192.168.0.254).

La redondance est mise en place par le biais du protocole ARP. Lorsque le PC doit envoyer une trame à sa
passerelle, il émet une requête ARP et celle-ci répond en fournissant son adresse MAC.

Avec HSRP, les routeurs vont associer une adresse MAC particulière à l’adresse IP virtuelle sous la
forme 00:00:0c:07:ac:XX (où XX est le n° du groupe HSRP).

15
Dés lors, pour le PC, quoi qu’il arrive, ce sera cette adresse MAC qui identifiera sa passerelle. De leur côté
les routeurs dialoguent par multicast afin de négocier et de savoir qui devra se charger de traiter la trame
destinée à l’adresse MAC HSRP.

Configuration de R1
R1(config)# interface FastEthernet0/0
R1(config-if)# standby 1 ip 192.168.0.254
R1(config-if)# standby 1 priority 200
R1(config-if)# standby 1 preempt

On a donc configuré ici l’interface Fa0/0 de R1 pour fonctionner dans le groupe HSRP n°1 auquel on a
associé l’adresse IP virtuelle 192.168.0.254. En plus on a défini une priorité de 200 (la plus grande priorité
sera la passerelle effective) et on active le droit de préemption (si R1 tombe en panne, R2 prend le relai…
mais is R1 revient, il reprendra sa place, sans préemption, R2 resterait la passerelle).

Configuration de R2
R2(config)# interface FastEthernet0/0
R2(config-if)# standby 1 ip 192.168.0.254
R2(config-if)# standby 1 priority 100

La configuration de R2 est similaire à celle de R1, étant donné que R2 est configuré avec une priorité plus
faible, il n’est pas nécessaire d’activer la préemption.

Vérification
Sur le PC, un test de communication démontre le bon fonctionnement de la configuration…

La configuration de C1:

NAME IP/MASK GATEWAY MAC


VPCS1 192.168.0.10/24 192.168.0.254 00:50:79:66:68:00

Test de communication vers 1.1.1.1

VPCS[1]> ping 1.1.1.1


1.1.1.1 icmp_seq=1 timeout
1.1.1.1 icmp_seq=2 ttl=254 time=50.000 ms
1.1.1.1 icmp_seq=3 ttl=254 time=50.000 ms
1.1.1.1 icmp_seq=4 ttl=254 time=39.000 ms
1.1.1.1 icmp_seq=5 ttl=254 time=48.000 ms

Il est intéressant d’analyser la table ARP de C1…

VPCS[1]> arp
00:00:0c:07:ac:01 192.168.0.254 expires in 114 seconds

On constate donc bien que 192.168.0.254 est la passerelle de C1 et que l’adresse MAC associée est bien
celle d’un groupe HSRP (ici le groupe 1, indiqué par le dernier octet de l’adresse MAC … 01). Un
traceroute prouvera que R1 est bien le routeur faisant office de passerelle…

VPCS[1]> trace 1.1.1.1


trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop
1 192.168.0.1 20.000 ms 10.000 ms 10.000 ms

16
2 172.30.0.1 30.000 ms 10.000 ms 10.000 ms
3 1.1.1.1 30.000 ms 10.000 ms 10.000 ms

Vérification de la configuration
Sur R1 et R2 il est possible de vérifier le fonctionnement de HSRP d’une simple commande:

R1#show standby
FastEthernet0/0 - Group 1
State is Active
2 state changes, last state change 00:14:40
Virtual IP address is 192.168.0.254
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.064 secs
Preemption enabled
Active router is local
Standby router is 192.168.0.2, priority 100 (expires in 8.320 sec)
Priority 200 (configured 200)
Group name is "hsrp-Fa0/0-1" (default)
R1#

On y voit que « State is Active » qui signifie que R1 est la passerelle active (et donc R2 est en standby). Le
reste des informations sont explicites.

Que se passe-t-il si R1 tombe en panne …


Pour simuler une panne, je mets simplement l’interface Fa0/0 de R1 en shutdown…

R1(config-if)# shutdown
*Mar 1 00:44:02.331: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Init
*Mar 1 00:44:04.343: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to
administratively down
*Mar 1 00:44:05.343: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0/0,
changed state to down

Réaction immédiate de R2 …

R2#
*Mar 1 00:44:11.071: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active

R2 est bien devenu la passerelle active, vérifions sur C1…

VPCS[1]> ping 1.1.1.1


1.1.1.1 icmp_seq=1 ttl=254 time=32.000 ms
1.1.1.1 icmp_seq=2 ttl=254 time=41.000 ms
1.1.1.1 icmp_seq=3 ttl=254 time=31.000 ms
1.1.1.1 icmp_seq=4 ttl=254 time=31.000 ms
1.1.1.1 icmp_seq=5 ttl=254 time=40.000 ms
VPCS[1]> arp
00:00:0c:07:ac:01 192.168.0.254 expires in 15 seconds

Rien n’a changé de son côté, normal … puisque R1 et R2 utilisent la même adresse IP virtuelle associée à la
même adresse MAC pour HSRP. Par contre le paquet ICMP passe bien par R2…

VPCS[1]> trace 1.1.1.1


trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop
1 192.168.0.2 21.000 ms 11.000 ms 11.000 ms
17
2 172.30.0.5 31.000 ms 12.000 ms 12.000 ms
3 1.1.1.1 32.000 ms 12.000 ms 12.000 ms

Voilà de quoi gérer très simplement la redondance de passerelle par défaut (à condition de disposer de
matériel Cisco).

VRRP : Virtual Router Redundancy Protocol


Dans l’article précédent nous avons vu une mise en oeuvre simple de HSRP qui permet de gérer la redondance de passerelle (entre
autre). Bien que simple à mettre en place, HSRP a comme principal defaut d’être propriétaire Cisco. Voici donc une mise en
place équivalente de VRRP, protocole standard défini dans la RFC 5798…

Afin de permettre une comparaison facile avec HSRP, j’ai gardé la même structure pour l’article.

La topologie

La topologie est similaire à celle utilisée dans l’article sur HSRP. R1 et R2 seront donc les deux passerelles
par défaut à faire fonctionner en redondance.

R1 et R2 communiqueront à l’aide de VRRP par leurs interfaces FastEthernet afin de négocier leur rôle.

Principe général

VRRP est donc, à l’instar de HSRP, également un protocole qui fourni une solution de continuité de service
principalement pour la redondance de passerelles par défaut.

Pour chaque réseau, on associe les interfaces des routeurs à un groupe VRRP (le même n° de groupe pour
toutes les interfaces qui doivent assurer le même rôle). A ce groupe on associe une adresse IP virtuelle (dans
le cas présent ce sera 192.168.0.254).

La redondance est mise en place par le biais du protocole ARP. Lorsque le PC doit envoyer une trame à sa
passerelle, il émet une requête ARP et celle-ci répond en fournissant son adresse MAC.

Dans le cas de VRRP, les routeurs vont associer une adresse MAC particulière à l’adresse IP virtuelle sous
la forme 00:00:5E:00:01:XX (où XX est le n° du groupe VRRP).

Dés lors, pour le PC, quoi qu’il arrive, ce sera cette adresse MAC qui identifiera sa passerelle. De leur côté
les routeurs dialoguent par multicast (224.0.0.18) afin de négocier et de savoir qui devra se charger de traiter
la trame destinée à l’adresse MAC VRRP.

Configuration de R1
R1(config)# interface FastEthernet0/0
R1(config-if)# vrrp 1 ip 192.168.0.254
R1(config-if)# vrrp 1 priority 200
R1(config-if)# vrrp 1 preempt
18
L’interface Fa0/0 de R1 fonctionnera dans le groupe VRRP n°1 auquel on a associé l’adresse IP virtuelle
192.168.0.254. En plus on a défini une priorité de 200 (la plus grande priorité sera la passerelle effective) et
on active le droit de préemption (si R1 tombe en panne, R2 prend le relai… mais is R1 revient, il reprendra
sa place, sans préemption, R2 resterait la passerelle).

Configuration de R2
R2(config)# interface FastEthernet0/0
R2(config-if)# vrrp 1 ip 192.168.0.254
R2(config-if)# vrrp 1 priority 100

La configuration de R2 est similaire à celle de R1. Notez que les deux routeurs doivent être configurés dans
le même groupe et gérer la même adresse virtuelle, sans quoi il n’y aura soit pas de dialogue VRRP soit un
conflit d’adresse.

Vérification

Configuration de C1:

NAME IP/MASK GATEWAY MAC


VPCS1 192.168.0.10/24 192.168.0.254 00:50:79:66:68:00

Test de communication vers 1.1.1.1

VPCS[1]> ping 1.1.1.1


1.1.1.1 icmp_seq=1 timeout
1.1.1.1 icmp_seq=2 ttl=254 time=25.000 ms
1.1.1.1 icmp_seq=3 ttl=254 time=25.000 ms
1.1.1.1 icmp_seq=4 ttl=254 time=32.000 ms
1.1.1.1 icmp_seq=5 ttl=254 time=31.000 ms

Il est intéressant d’analyser la table ARP de C1…

VPCS[1]> arp
00:00:5e:00:01:01 192.168.0.254 expires in 114 seconds

C1 a bien émi une requête ARP pour obtenir l’adresse MAC correspondant à 192.168.0.254, qui correspond
bien à une adresse MAC VRRP où le dernier byte est défini par le n° de groupe VRRP.

VPCS[1]> trace 1.1.1.1


trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop
1 192.168.0.1 19.000 ms 10.000 ms 9.000 ms
2 172.16.0.1 20.000 ms 10.000 ms 10.000 ms
3 1.1.1.1 20.000 ms 10.000 ms 10.000 ms

On constate ici que R1 assure bien le role de 192.168.0.254

Vérification de la configuration
Vérification du fonctionnement de VRRP sur R1 :

R1#show vrrp
FastEthernet0/0 - Group 1
State is Master

19
Virtual IP address is 192.168.0.254
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 200
Master Router is 192.168.0.1 (local), priority is 200
Master Advertisement interval is 1.000 sec
Master Down interval is 3.218 sec
R1#

Le « State » indique soit Master (actif) soit Backup (en standby). Le reste des informations est explicite.

Que se passe-t-il si R1 tombe en panne …


Test de fonctionnement en mettant Fa0/0 de R1 en shutdown…

R1(config-if)#shutdown
*Mar 1 02:21:46.399: %VRRP-6-STATECHANGE: Fa0/0 Grp 1 state Master -> Init
*Mar 1 02:21:48.403: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to
administratively down
*Mar 1 02:21:49.403: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0,
changed state to down

Réaction immédiate de R2 …

R2#
*Mar 1 02:21:41.727: %VRRP-6-STATECHANGE: Fa0/0 Grp 1 state Backup -> Master

R2 est bien devenu la passerelle active, vérifions sur C1…

VPCS[1]> ping 1.1.1.1


1.1.1.1 icmp_seq=1 ttl=254 time=26.000 ms
1.1.1.1 icmp_seq=2 ttl=254 time=19.000 ms
1.1.1.1 icmp_seq=3 ttl=254 time=19.000 ms
1.1.1.1 icmp_seq=4 ttl=254 time=19.000 ms
1.1.1.1 icmp_seq=5 ttl=254 time=19.000 ms
VPCS[1]> arp
00:00:5e:00:01:01 192.168.0.254 expires in 7 seconds

Comme pour HSRP,la table ARP de C1 reste identique.La transition entre R1 et R2 est transparente pour
C1.

VPCS[1]> trace 1.1.1.1

trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop


1 192.168.0.2 9.000 ms 9.000 ms 9.000 ms
2 172.16.0.5 10.000 ms 10.000 ms 10.000 ms
3 1.1.1.1 10.000 ms 11.000 ms 10.000 ms

Conclusion

Pour une configuration aussi simple, VRRP fonctionne quasiment comme HSRP, il n’y a donc pas grand
chose d’autre à ajouter. Les différences majeures se situent dans les rouages du protocole (adresse multicast
utilisée, adresse MAC etc.).

20

Vous aimerez peut-être aussi