NAT64 et DNS64

La normalisation par l'IETF du mécanisme de translation d'adresse IPv6 vers IPv4 est effective (RFC6144). Elle repose sur le NAT64 (RFC6146 ) et le DN64 (RFC6147). Je pense que cette dernière sera une composante importante dans les mécanismes de coexistence entre IPv4 et IPv6.

Le but de ce mécanisme est de préciser le fonctionnement général d'une communication entre une machine en IPv6 et une machine en IPv4. Il est à noter que ce type de protocole (NAT64) repose sur une communication client/serveur.

L'intérêt de cette RFC est de permettre à une entreprise ou un ISP dont seule une plage d'adresse IPv6 leur sera affectée de continuer à communiquer avec le reste du monde (en IPv4).

Le déploiement de ce mécanisme nécessite 2 équipements:

• Le routeur qui réalisera le NAT64
• Le DNS64 qui permet de traduire un enregistrement A en un enregistrement AAAA

Le schéma ci-dessous détail la mise en œuvre:

1. Le client réalise une requête DNS vers le DNS64
2. Si le domaine ne possède pas d'enregistrement AAAA (retour message erreur) le serveur DNS64 effectue une requête A
3. Le serveur IPv6 génère une adresse IPv6 avec le préfixe 64:FF9B::/64 et renvoie cette dernière au client
4. Le client reçoit une adresse AAAA
5. Le client initie une communication avec le serveur au travers du routeur NAT64
6. Le routeur NAT64 créé une session via l'association adresse IP + port

Les implémentations existantes de NAT64:

- Ecdysis, opensource

- Cisco dans une version IOS XE

Les implémentations existantes de DNS64:

- Bind 9.8.0

Communication entre VRF (Astuce)

Le but des VRFs est de cloisonner plusieurs instances de routage sur les mêmes équipements.
Cependant, à des fins de tests ou pour une config un peu particulière il peut être souhaité de faire communiquer 2 VRFs entre elles. Pour se faire, il existe une petite astuce qui consiste à tirer un câble entre 2 ports du switch et de les configurer en tant qu'interface de niveau 3. Le schéma ci-dessous est un exemple de cette configuration:


La configuration à appliquer:

ip vrf VRF_A
rd 2:2
!
ip vrf VRF_B
rd 3:3
!
ip vrf VRF_B
rd 4:4
!
vlan 200
name in_VRF_A
!
vlan 100
name in_VRF_B
!
vlan 150
name in_VRF_C
!
interface GigabitEthernet10
no switchport
ip vrf forwarding VRF_A
ip address 10.10.10.10 255.255.255.0
!
interface GigabitEthernet11
no switchport
ip vrf forwarding VRF_B
ip address 10.10.10.20 255.255.255.0
!
interface GigabitEthernet12
no switchport
ip vrf forwarding VRF_A
ip address 10.10.11.10 255.255.255.0
!
interface GigabitEthernet11
no switchport
ip vrf forwarding VRF_C
ip address 10.10.11.20 255.255.255.0
!
interface Vlan100
ip vrf forwarding in_VRF_A
ip address 100.100.100.100 255.255.255.0
!
interface Vlan150
ip vrf forwarding in_VRF_C
ip address 150.150.150.150 255.255.255.0
!
interface Vlan200
ip vrf forwarding VRF_B
ip address 200.200.200.200 255.255.255.0

!

ip route vrf VRF_A 100.100.100.0 255.255.255.0 10.10.10.20
ip route vrf VRF_A 150.150.150.0 255.255.255.0 10.10.11.20
!
ip route vrf VRF_C 100.100.100.0 255.255.255.0 10.10.11.10
ip route vrf VRF_C 200.200.200.0 255.255.255.0 10.10.11.10
!
ip route vrf VRF_B 150.150.150.0 255.255.255.0 10.10.10.10
ip route vrf VRF_B 200.200.200.0 255.255.255.0 10.10.10.10

IPv6: un point sur les Opérateurs français et les accès aux particuliers

Ce post a pour vocation de lister l'avancement du déploiement d'IPv6 chez les principaux opérateurs français. Je n'ai étudié que les offres réservées aux particuliers.

SFR:
Ils annoncent la possibilité de passer en IPv6 sur les neufBox d'ici cet été:
http://www.sfr.com/les-mondes-numeriques/les-nouvelles-technologies/ipv6-un-nouveau-protocole

Orange:
La livebox n'est pas aujourd'hui compatible avec IPv6. L'opérateur a annoncé sur twitter que cette dernière serait compatible dans ça nouvelle génération disponible à l'horizon de l'été 2012.
Si cela est confirmé, l'impact sera important puisque seules les nouvelles livebox n'auront cette fonctionnalité. Le changement de parc est donc considérable.
https://twitter.com/#!/presseorange/status/25907079453614080


Free:
Ils ont déployé la technologie 6rd qui permet d'offrir un accès IPv6 aux clients dégroupés et ceux depuis 2007.
http://www.iliad.fr/presse/2007/CP_IPv6_121207.pdf
Aujourd'hui aucune information circule sur les accès non dégroupés.


Bouygues Telecom:
La seule information que j'ai trouvé à leur sujet est que la nouvelle Bbox fibre supporte IPv6 en dual stack après upgrade FW .

Flash or not flash !

La carte SUP-720-10G possède 2 cartes flash interne (sur la RP et la SP). Petit problème, elle change de nom entre le passage en rommon et le fonctionnement normal !

• Une pour la SP « Switching Processor » (flash_1)
  

• Une pour la RP « Routing Processor » (flash_2)

En CatOS la SP démarrais avec la flash_1 et la RP avec la flash_2 pour l'IOS. Ces deux flash possédaient le même nom mais sur 2 OS différents.

Aujourd'hui le CatOS et l'IOS sont mutualisés dans l'IOS. La SP et la RP démarrent donc avec le même binaire situé sur une seule flash (flash_1). La flash_2 n'est pas utilisée mais reste visible après le boot.

Il est bon de savoir que les flashs changent de nomination entre le boot (rommon) et une fois la phase de boot terminée. Cette remarque est importante pour identifier les variabales de boot, le stockage des différentes sauvegardes...

En résumé en phase de boot (rommon):

• SP => Bootflash:

• RP => Non Accessible

Après la phase de boot:

• SP => Sup-bootflash:

• RP => Bootflash:

Rmq: je n'ai pas abordé le cas des disques ATA qui modifient aussi leur identification!

Sauvegarde équipements réseaux via pexpect

Ci-dessous un petit script qui permet de lancer les commandes de sauvegarde TFTP via pexpect sur un composant Cisco:

import pexpect
IPa = raw_input('Entrer l adresse IP du composant:')
IP = 'ssh admin@'+IPa
child = pexpect.spawn (IP)
child.expect ('Password: ')
pwd = raw_input('Entrer le password du composant:')
print pwd
child.sendline (pwd)
child.expect ('#')
child.sendline ('copy running-config tftp:')
child.expect ('\? ')
child.sendline ('10.10.10.20')
child.expect ('\? ')
host = IPa+'.cfg'
child.sendline (host)
child.expect ('#')
child.sendline ('exit')
print child.before

Idem pour un Altéon:

import pexpect
child = pexpect.spawn ('ssh admin@10.10.10.10')
child.expect ('password: ')
child.sendline ('admin')
child.expect (['Main#','[y]'])
i = child.expect (['Main#','[y]'])
if i == 0:
print 'Connexion Ok'
elif i == 1:
child.sendline ('y')
else:
p.expect(pexpect.EOF)
print 'Timeout connexion'
child.expect ('Main#')
child.sendline ('/cfg/ptcfg')
child.expect ('server: ')
child.sendline ('10.10.10.20')
child.expect ('server: ')
child.sendline ('hostname.cfg')
child.expect ('server: ')
child.sendline ('')
print child.before

Idem pour un ISG1000:

import pexpect
child = pexpect.spawn ('ssh admin@10.10.10.10')
child.expect ('password: ')
child.sendline ('admin')
child.expect ('>')
child.sendline ('exec save config to tftp 10.10.10.20 hostname.cfg')
child.expect ('>')
print child.before

N'étant pas familié du scripting, je suis preneur de toute amélioration à apporter.

NAT sur Catalyst 6500

Le NAT sur les catalyst n'étant réalisable que sur les châssis 6500 (même les 3750 ne supporte pas le NAT), cette configuration est peut documentée. Dans certains cas, il est cependant nécessaire de réaliser une config de NAT autre part que sur un pare-feu.

Exemple de configuration:



Voici la configuration à appliquer pour reproduire le schéma ci-dessus:

ip nat pool testNAT 201.200.200.200 201.200.200.200 netmask 255.255.255.0
ip nat inside source list 150 pool testNAT overload
access-list 150 permit ip 192.168.20.0 0.0.0.255 200.200.200.0 0.0.0.255
!
interface Vlan100
ip address 192.168.20.1 255.255.255.0
ip nat inside
!
interface Vlan200
ip address 201.200.200.1 255.255.255.0
ip nat outside

La commande suivante permet de valider l'état du NAT:

show ip nat translations

Afin de pousser un peu plus le diagnostique, il est nécessaire
d'activer le mode debug avec la commande:
 debug ip nat

Sécurisation SNMP sur Catalyst Cisco

SNMP est une source importante d'information sur les composants réseaux. La communauté public est trop souvent laissée par défaut sur les composants. Si vous êtes appelé à utiliser SNMP, je conseil d'utiliser SNMPv3 et de filtrer les adresses IP qui ont l'accès en lecture ou lecture/écriture.

Ci-dessous la configuration à appliquer pour du SNMPv3 sur un catalyst Cisco (configuration en lecture avec du filtrage sur l'IP source):
access-list <Numero_ACL> permit
access-list <Numero_ACL> deny any

snmp-server group <Nom_groupe> v3 priv snmp-server user <Nom_user> <Nom_groupe> v3 auth md5 <password> priv des <password> access <Numero_ACL>
Exemple de configuration:
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 deny any

snmp-server group ReadOnly v3 priv snmp-server user admin ReadOnly v3 auth md5 password priv des password access 1