jeudi 19 février 2015

Remote Access VPN + Radius


Un petit exemple de remote VPN avec authentification/Authorization via Radius.
Configuration des IP et du nom d’hôte

Router(config)#hostname VPNGATE
VPNGATE(config)#int f0/1
VPNGATE(config-if)#ip address 192.168.254.1 255.255.255.0
VPNGATE(config-if)#no shut
VPNGATE(config-if)#int f0/0
VPNGATE(config-if)#ip add 80.80.80.80 255.255.255.0
VPNGATE(config-if)#no shut
VPNGATE(config-if)#int loop1
VPNGATE(config-if)#ip address 192.168.1.1 255.255.255.0
Ping vers le serveur radius:
VPNGATE#ping 192.168.254.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.254.10, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/6/16 ms
Configuration du remote VPN:
Voici les différentes étapes à suivre:
  • Configuration des politiques de groupes utilisée par le VPN (aaa)
  • Configuration ISAKMP et IPSEC
  • Configuration du client VPN Cisco
  • Optionnel: Ajout de l’authentification XAuth

Configuration des politiques de groupes utilisée par le VPN (aaa)

Dans cette première partie, nous allons indiquer comment la configuration des utilisateurs va être appliquée par le VPN. Je vais créer un groupe local, et un groupe sur mon serveur radius.

Configuration AAA

VPNGATE(config)#aaa new-model
VPNGATE(config)#aaa authorization network Remote_VPN_Author group radius local
VPNGATE(config)#aaa authentication login Remote_VPN_Authen group radius local

Configuration du group local

Je vais créer un groupe d’administrateur de secour de manière à ce que si le serveur radius tombe en panne, le VPN soit encore accessible.
Il faut définir un pool d’adresse qui sera utilisé, puis configurer le groupe avec une clé pré partagée ainsi que les diverses options du groupe (serveur wins, DNS…).
On vas aussi créer un utilisateur LocalAdmin
VPNGATE(config)#ip local pool Remote_VPN_Pool 192.168.100.1 192.168.100.254
VPNGATE(config)#crypto isakmp client configuration group VPN_Admins
VPNGATE(config-isakmp-group)#key 4dm!nVPNP4$$
VPNGATE(config-isakmp-group)#pool Remote_VPN_Pool
VPNGATE(config-isakmp-group)#domain mynetwork.lan
VPNGATE(config-isakmp-group)#exit

Configuration du serveur radius

Sur le routeur:
VPNGATE(config)#radius-server host 192.168.254.10 key R4d!usK3y
Sur le serveur ACS:
Note: Ne pas oublier de changer l’adresse IP dans Network Configurations / AAA Servers et redémarrez le serveur radius (CSRadius)
NOTE: Pour les groupes ISAKMP Avec radius, il faut créer un utilisateur portant le nom du groupe, et l’associer à son groupe, avec le mot de pase cisco qui est un mot de passe spécial !
Je penses qu’il faut faire cela car le protocol radius n’accepte pas que l’on lui passe un groupe en paramètre, on utilisera donc un utilisateur pour authentifier le groupe. A vérifier
Source: http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftunity.html#wp1191206 ethttp://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftunity.html#wp1045273
Dans le menu Network configuration, dans AAA Clients, cliquez sur add entry et mettez ces paramètres:
Hostname: VPNGATE
AAA Client IP: 192.168.254.1
Shared Secret: R4d!usK3y
Authenticate using: RADIUS (CISCO IOS/PIX)
Puis cliquez sur submit+apply





Allez ensuite dans Interface configuration, puis RADIUS (Cisco IOS/PIX 6.0), et vérifiez que « 026/009/001] cisco-av-pair » est coché (première ligne), puis submit.


Dans group Setup, choisissez le groupe 1, renommez le en VPN_USERS (optionnel), puis cliquez sur edit settings.
Dans la partie « Cisco IOS/PIX 6.x RADIUS Attributes » cochez « [009\001] cisco-av-pair » et mettez ceci:
ipsec:key-exchange=ike
ipsec:key-exchange=preshared-key 
addr-pool=VPN_Users_Pool
ipsec:default-domain=myNetwork.lan
Note: le pool VPN_Users_Pool Doit exister sur le router:
VPNGATE(config)#ip local pool VPN_Users_Pool 192.168.101.1 192.168.101.254
Cocher aussi ces attributs dans Radius IETF (s’ils n’apparaissent pas, aller dans Interface configuration, RADIUS IETF, puis cochez les)
  • Attribute 6: Service-Type=Outbound
  • Attribute 64: Tunnel-Type=IP ESP
  • Attribute 69: Tunnel-Password=U$3rVPNP4$$




Cliquez sur Submit+Restart
Je n’ai pas trouvé la liste exhaustive des attributs supportés, je me suis inspiré de ceux ci:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftunity.html#wp1058287
AJOUT DE L’UTILISATEUR DU GROUPE !!
ajouter un utilsateur VPN_USERS avec le mot de passe cisco (cisco et pas un autre mot de passe, voir note au début de ce point). Dans la partie Client IP Address Assignment, mettez « No IP address assignment »

Ajoutez un utilisateur dans le serveur radius (cliquez sur User setup, entrez un nom d’utilisateur puis cliquez sur add/edit et mettez les paramètres sur screenshot).




j’ai créé l’utilisateur vpnuser avec le mot de passe cisco (ici le mot de passe cisco n’est pas obligatoire, vous pouvez mettre ce que vous voulez). Testons les paramètres sur le routeur:
VPNGATE#test aaa group radius vpnuser cisco legacy
Attempting authentication test to server-group radius using radius
User was successfully authenticated.

Configuration ISAKMP et IPSEC

Configuration ISAKMP: Hash md5, Authentification PSK, Diffie-Hellman Group 2, et encryption DES
VPNGATE(config)#crypto isakmp policy 1
VPNGATE(config-isakmp)#hash md5
VPNGATE(config-isakmp)#authentication pre-share
VPNGATE(config-isakmp)#group 2
VPNGATE(config-isakmp)#encryption des
VPNGATE(config-isakmp)#exit
Note: La clé pré partagée IKE sera celle du groupe.
Il faut maintenant créer un transform set, et une crypto map dynamic. Les crypto map dynamiques sont des crypto map dont l’ensemble des paramètres n’est pas connu, par exemple en l’occurence le peer distant n’est pas static, on ne connait pas les adresses IP qui vont se connecter en remote VPN.
Creation d’un transform set et d’une crypto map dynamiques. La fonction reverse-route permet d’intégrer une route /32 avec l’adresse du client dans la table de routage et donc de la propager aux autres routeurs via des mises à jour (RIP, EIGRP, OSPF…) afin qu’il soit connu des autres routeur du réseau.
Note: Les numéros 1 et 10 des crypto map correspondent au numéros de séquence, ce qui permet d’avoir plusieurs profiles. Le numero le plus petit est prioritaire, car il sera traité en premier.
VPNGATE(config)#crypto ipsec transform-set Remote_VPN_TSet esp-3des esp-Md5-hmac
VPNGATE(cfg-crypto-trans)#exit
VPNGATE(config)#crypto dynamic-map Remote_VPN_Dynmap 1
VPNGATE(config-crypto-map)#set transform-set Remote_VPN_TSet
VPNGATE(config-crypto-map)#reverse-route
Nous allons maintenant creer la crypto map qui indiquera comment est déclenchée la connexion client, ainsi que les paramètres d’authorization
VPNGATE(config)#crypto map Remote_VPN_Map isakmp authorization list Remote_VPN_Author
!connexion déclenchée par le client
VPNGATE(config)#crypto map Remote_VPN_Map client configuration address respond
VPNGATE(config)#crypto map Remote_VPN_Map 10 ipsec-isakmp dynamic Remote_VPN_Dynmap  
Note: Les numéros 1 et 10 des crypto map correspondent au numéros de séquence, ce qui permet d’avoir plusieurs profiles. Le numero le plus petit est prioritaire, car il sera traité en premier.
Il ne reste plus qu’a appliquer notre crypto map au l’interface par laquelle vont se connecter les clients et ça doit marcher (suspens)
VPNGATE(config)#interface FastEthernet 0/0
VPNGATE(config-if)#crypto map Remote_VPN_Map

Configuration du client VPN Cisco

Dans le client VPN Cisco, cliquez sur new:

Dans la fenêtre utilisez ces paramètres (ou ceux que vous avez spécifier pour votre groupe local à l’étape 1).:
Group : VPN_Admins
Password: 4dm!nVPNP4$$
Refaire la même étape avec les paramètres du serveur Radius
Group: VPN_USERS
Password:U$3rVPNP4$$
ester la connexion VPN_USERS:
Sélectionnez la connexion dans le Client VPN, puis cliquez sur connect. Cela doit marcher.
Vérification de la reverse-route (80.80.80.1 est mon l’adresse publique du client).
VPNGATE#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     80.0.0.0/24 is subnetted, 1 subnets
C       80.80.80.0 is directly connected, FastEthernet0/0
C    192.168.254.0/24 is directly connected, FastEthernet0/1
C    192.168.1.0/24 is directly connected, Loopback1
     192.168.101.0/32 is subnetted, 1 subnets
S       192.168.101.1 [1/0] via 80.80.80.1
Affichage des clients:
VPNGATE#sh crypto isakmp peers
Peer: 80.80.80.1 Port: 3800 Local: 80.80.80.80
 Phase1 id: VPN_USERS

VPNGATE#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
80.80.80.80     80.80.80.1      QM_IDLE           1001    0 ACTIVE

IPv6 Crypto ISAKMP SA

VPNGATE#sh crypto session
Crypto session current status

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 80.80.80.1 port 3800
  IKE SA: local 80.80.80.80/500 remote 80.80.80.1/3800 Active
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.101.1
        Active SAs: 2, origin: dynamic crypto map
Et sur mon pc:
Carte Ethernet Connexion au réseau local 8:

        Suffixe DNS propre à la connexion : myNetwork.lan
        Adresse IP. . . . . . . . . . . . : 192.168.101.2
        Masque de sous-réseau . . . . . . : 255.255.255.0
        Passerelle par défaut . . . . . . : 192.168.101.1
Maintenant, désactivons le serveur radius (déconnecter, shutdown,…) pour tester le groupe admins. Si on ne faisait pas ça, le serveur radius répondrait par invalid user et on ne pourrais s’authentifier avec le groupeVPN_Admins.Si l’on voulais que ce groupe soit quand même accessible, il aurait fallu le créer ET sur le routeur ET sur le serveur radius. Pour ma part je vais shutdown l’interface du radius.
Note: Cela ne marche pas car le temps qu’il y ait un timeout pour contacter le serveur radius, le client VPN annule la connexion. Par contre si je modifie la ligne
VPNGATE(config)#aaa authorization network Remote_VPN_Author group radius local
par
VPNGATE(config)#aaa authorization network Remote_VPN_Author local
Le groupe VPN_Admins fonctionne. On remarque bien un pool d’adresse différent:
Carte Ethernet Connexion au réseau local 8:

        Suffixe DNS propre à la connexion : mynetwork.lan
        Adresse IP. . . . . . . . . . . . : 192.168.100.1
        Masque de sous-réseau . . . . . . : 255.255.255.0
        Passerelle par défaut . . . . . . : 192.168.100.2
Il faudrait trouver un moyen d’augmenter le timeout pour le client VPN, ou de baisser celui du serveur radius sur le routeur. Bref on va plutot s’attaquer à l’XAUTH.

Ajout de l’authentification XAuth

XAuth c’est quoi? XAuth = eXtended Authentication. Oui mais encore ? Xauth est un processus entre les phase 1 et 2 IKE (parfois appelé phase IKE 1.5), permettant d’authentifier un utilisateur lorsqu’il se connecte en VPN. Les plus doué d’entre vous auront peut être remarqué que j’ai créé un utilisateur vpnuser avec le mot de passe cisco, et que j’ai ajouter une ligne dans la configuration du routeur qui ne nous a pas encore servie:
VPNGATE(config)#aaa authentication login Remote_VPN_Authen group radius local
Bref, pour activer XAuth, ajouter une authentication list à la crypto map précédemment créée:
VPNGATE(config)#crypto map Remote_VPN_Map client authentication list Remote_VPN_Authen
Maintenant, il suffit de couper la connexion, et de la relance (VPN_USERS), et l’on va être amenés à se logguer. Nous utiliseront vpnuser/cisco (ou tout autre utilisateur que vous aurez créé). Libre à vous d’ajouter d’autres utilisateurs dans ACS. Pour les groupes locaux, il suffit d’utiliser les utilisateurs créé avec la commande username. (Ne pas oublier de remettre aaa authorization network Remote_VPN_Author group radius local si vous aviez enlevé radius pour testé le group local)


Configuration finale:

VPNGATE#sh run
Building configuration...

Current configuration : 1785 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname VPNGATE
!
boot-start-marker
boot-end-marker
!
!
aaa new-model
!
!
aaa authentication login Remote_VPN_Authen group radius local
aaa authorization network Remote_VPN_Author group radius local 
!
aaa session-id common
!
resource policy
!
memory-size iomem 15
no network-clock-participate slot 1
no network-clock-participate wic 0
ip cef
!
!
!
!
!
!
!
!
username LocalAdmin privilege 15 secret 5 $1$tDWV$6NngMkxdNRufvvGGmZ68h1
!
!
!
crypto isakmp policy 1
 hash md5
 authentication pre-share
 group 2
!
crypto isakmp client configuration group VPN_Admins
 key 4dm!nVPNP4$$
 domain mynetwork.lan
 pool Remote_VPN_Pool
!
!
crypto ipsec transform-set Remote_VPN_TSet esp-3des esp-md5-hmac
!
crypto dynamic-map Remote_VPN_Dynmap 1
 set transform-set Remote_VPN_TSet
 reverse-route
!
!
crypto map Remote_VPN_Map client authentication list Remote_VPN_Authen
crypto map Remote_VPN_Map isakmp authorization list Remote_VPN_Author
crypto map Remote_VPN_Map client configuration address respond
crypto map Remote_VPN_Map 10 ipsec-isakmp dynamic Remote_VPN_Dynmap 
!
!
!
!
interface Loopback1
 ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 80.80.80.80 255.255.255.0
 duplex auto
 speed auto
 crypto map Remote_VPN_Map
!
interface FastEthernet0/1
 ip address 192.168.254.1 255.255.255.0
 duplex auto
 speed auto
!
ip local pool Remote_VPN_Pool 192.168.100.1 192.168.100.254
ip local pool VPN_Users_Pool 192.168.101.1 192.168.101.254
!
!
ip http server
no ip http secure-server
!
!
!
!
radius-server host 192.168.254.10 auth-port 1645 acct-port 1646 key R4d!usK3y
!
control-plane
!
!
!
!
line con 0
line aux 0
line vty 0 4
!
!
end

mardi 10 février 2015

Clientless SSL VPN (WebVPN) avec ASA 5505

TOPOLOGIE

Lab instructions

SSL VPN technology can be configured in three ways :
  • Thin Client VPN
  • SSL VPN Client
  • Clientless SSL VPN (WebVPN)
Clientless SSL VPN is a technology allowing limited but secure access to internal network ressources from any location using a web browser. No specific VPN client is needed, a remote user only needs an SSL-enabled web browser to access http- or https-enabled web servers on the internal network. This technology is available on ASA 5505 firewall and has been implemented in Packet Tracer 6.1 network simulator.

Firewall configuration to apply in this lab:
  • Outside IP : 192.168.1.1/24
  • Inside IP : 192.168.2.1/24
  • User login : test
  • User password : test.test
  • Website IP : site 1

 

Solution

1. Create the bookmark site1 to the URL http://192.168.2.3 on the ASA 5505 firewall
2. Apply the following configuration to the firewall :
interface Vlan1
 nameif inside
 security-level 100
 ip address 192.168.2.1 255.255.255.0
!
interface Vlan2
 nameif outside
 security-level 0
 ip address 192.168.1.1 255.255.255.0
!
webvpn
 enable outside
object network LAN
 subnet 192.168.2.0 255.255.255.0
!
object network LAN
 nat (inside,outside) dynamic interface
!
group-policy group1 internal
group-policy group1 attributes
 vpn-tunnel-protocol ssl-clientless
 webvpn
  url-list value site1
username test password D35rLrqYJOMRHDCX encrypted
username test attributes
 vpn-group-policy group1
!
!

Site à site IPSEC VPN avec ASA 5505

Network diagram

Campus addressing schema :
  • Campus IP addresses : 172.16.0.0/17
  • DC : 172.16.0.0/18
  • Users : 172.16.64.0/20
  • DMZ : 172.16.96.0/21
  • Network devices : 172.16.252.0/23
  • L3 P2p links : 172.16.254.0/24

Branch office 1 IP subnet : 172.16.129.0/24
Enterprise internet IP addresses : 134.95.56.16/28

IPSEC VPN configuration to apply :
  • ESP Encryption : AES-256
  • AH hash algorithm : SHA
  • Pre shared key : SHAREDSECRET

Solution

Campus network - ASA 5505 IPSEC VPN headend device configuration .
interface Vlan1
 nameif inside
 security-level 100
 ip address 172.16.254.254 255.255.255.252
!
interface Vlan2
 nameif outside
 security-level 0
 ip address 134.95.56.17 255.255.255.240
!
object network BRANCH01_NETWORK
 subnet 172.16.129.0 255.255.255.0
object network BRANCH_NETWORK
 subnet 172.16.128.0 255.255.128.0
object network CAMPUS_NETWORK
 subnet 172.16.0.0 255.255.128.0
object network PRIVATE_NETWORK
 subnet 176.16.0.0 255.255.0.0
!
route outside 172.16.129.0 255.255.255.0 134.95.56.18 1
route inside 172.16.0.0 255.255.128.0 172.16.254.253 1
!
access-list BRANCH01_TRAFFIC extended permit tcp object CAMPUS_NETWORK object BRANCH01_NETWORK
access-list BRANCH01_TRAFFIC extended permit icmp object CAMPUS_NETWORK object BRANCH01_NETWORK
access-list ENTERPRISE_PRIVATE-TRAFFIC extended permit tcp object PRIVATE_NETWORK object PRIVATE_NETWORK
access-list ENTERPRISE_PRIVATE-TRAFFIC extended permit icmp object BRANCH_NETWORK object CAMPUS_NETWORK
!
!
access-group ENTERPRISE_PRIVATE-TRAFFIC out interface inside
!
crypto ipsec ikev1 transform-set L2L esp-aes 256 esp-sha-hmac
!
crypto map BRANCH1 1 match address BRANCH01_TRAFFIC
crypto map BRANCH1 1 set peer 134.95.56.18
crypto map BRANCH1 1 set security-association lifetime seconds 86400
crypto map BRANCH1 1 set ikev1 transform-set L2L
crypto map BRANCH1 interface outside
crypto ikev1 enable outside
crypto ikev1 policy 1
 encr aes
 authentication pre-share
 group 2
!
tunnel-group 134.95.56.18 type ipsec-l2l
tunnel-group 134.95.56.18 ipsec-attributes
 ikev1 pre-shared-key SHAREDSECRET
!

The ENTERPRISE_PRIVATE-TRAFFIC access-group is important to allow the IP traffic through the firewall from remote subnets to the inside subnets. The traffic wiill be blocked by the ASA if this access-list is not configured and applied to the inside vlan interface.

Branch office n°1 - ASA 5505 remote device configuration
interface Vlan1
 nameif inside
 security-level 100
 ip address 172.16.129.1 255.255.255.0
!
interface Vlan2
 nameif outside
 security-level 0
 ip address 134.95.56.18 255.255.255.240
!
object network BRANCH01_NETWORK
 subnet 172.16.129.0 255.255.255.0
object network BRANCH_NETWORK
 subnet 172.16.128.0 255.255.128.0
object network CAMPUS_NETWORK
 subnet 172.16.0.0 255.255.128.0
object network PRIVATE_NETWORK
 subnet 176.16.0.0 255.255.0.0
!
route outside 172.16.0.0 255.255.128.0 134.95.56.17 1
!
access-list PRIVATE_TRAFFIC extended permit tcp object BRANCH01_NETWORK object CAMPUS_NETWORK
access-list PRIVATE_TRAFFIC extended permit icmp object BRANCH01_NETWORK object CAMPUS_NETWORK
access-list ENTERPRISE_PRIVATE-TRAFFIC extended permit tcp object PRIVATE_NETWORK object PRIVATE_NETWORK
access-list ENTERPRISE_PRIVATE-TRAFFIC extended permit icmp object CAMPUS_NETWORK object BRANCH_NETWORK
!
!
access-group ENTERPRISE_PRIVATE-TRAFFIC out interface inside
!
!
crypto ipsec ikev1 transform-set L2L esp-aes 256 esp-sha-hmac
!
crypto map BRANCH1 1 match address PRIVATE_TRAFFIC
crypto map BRANCH1 1 set peer 134.95.56.17
crypto map BRANCH1 1 set security-association lifetime seconds 86400
crypto map BRANCH1 1 set ikev1 transform-set L2L
crypto map BRANCH1 interface outside
crypto ikev1 enable outside
crypto ikev1 policy 1
 encr aes
 authentication pre-share
 group 2
!
tunnel-group 134.95.56.17 type ipsec-l2l
tunnel-group 134.95.56.17 ipsec-attributes
 ikev1 pre-shared-key SHAREDSECRET
!

lundi 7 juillet 2014

Lab OSPF/OSPFv3

Un lab OSPF  ou l’on va explorer tout ce que sont que ces notions importantes de types de LSA, la problématique des réseaux NBMA, le routage OSPF multi aires, les routeurs type ABR, ASBR…
Ici, je vais tout faire en dual-stack ipv4/ipv6


Pour l’IPv6 sur frame relay, l’inverse-arp n’est pas encore implémenté sur IOS, en tous cas sur les 12.2, j’ai pas testé sur le 12.4, j’ai donc fait des mapping manuels via la commande frame-relay map ipv6 ip dlci BROADCAST.
Pour la connexion internet, je ne mettrais pas d’IPv6 car j’ai envie de tester le NAT-PT et les tunnels

Area 0 : Réseaux NBMA

dans un réseaux non broadcast, un routeur n’aura pas forcément un accès direct aux autres routeurs, même si ceux-ci sont dans le même réseau, l’exemple le plus flagrant est celui du frame-relay partia-mesh ou hub and spoke comme dans notre exemple. Cela pose donc des problème, puisque admettons qu’ABR1 avertisse une route vers ASBR1, et que celui-ci la transmette a ABR2, ABR2 aura ABR1 en nexthop, mais ne saura pas y accéder (sauf si on rajoute un mappage ou une route manuellement).
On va donc voir plus en détail ces problèmes. Dans les configurations OSPF, je vais coder le router-id à la main, car en effet, par défaut il est calculé automatiquement en prenant en compte la plus grande interface, mais il suffit que l’on change ou rajoute une adresse IP, lorsque le process OSPF sera redémarré, cela peut changer la topologie et créer des erreurs.
Pour la configuration OSPF/OSPFv3, voici les commandes (remplacer les routers ID, et ajoutez les réseaux 10.X.0.0 sur ABR[1|2|3] dans les bonnes aires)
ASBR1(config)#router ospf 1
ASBR1(config-router)#network 10.0.0.0 0.0.0.255 area 0
ASBR1(config-router)#router-id 10.0.0.1
ASBR1(config-router)#ipv6 router ospf 1
ASBR1(config-rtr)#router-id 10.0.0.1
ASBR1(config-rtr)#interface serial 0/0
ASBR1(config-if)#ipv6 ospf 1 area 0
ASBR1(config-if)#exit

Et la on s’aperçois qu’aucun voisins ne passe en FULL, ils ne sont d’ailleurs pas reconnu. Pour la suite des choses je vais faire les différentes config uniquement pour IPv4 car cela fonctionne à l’identique pour IPv6, puis pour la configuration finale je reviendrai sur l’IPv6.

Par défaut, le réseau est non broadcast, donc pas d’envoi de messages multicast pour la découverte des voisins. Si on veut activer les voisins, sur ce type de réseau, il faut les déclarer statiquement via la commande neighbor. Il n’est pas nécéssaire de le faire sur tous les routeurs puisqu’un routeur répondras aux hellos même s’ils viennent d’un voisin non déclarés statiquement, mais n’en enverra pas.
Sur ASBR1 donc:
ASBR1(config)#router ospf 1
ASBR1(config-router)#neighbor 10.0.0.2
ASBR1(config-router)#neighbor 10.0.0.3
ASBR1(config-router)#neighbor 10.0.0.4
ASBR1(config-router)#exit
*Mar  1 00:38:06.531: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.2 on Serial0/0 from LOADING to FULL, Loading Done
*Mar  1 00:38:13.570: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.3 on Serial0/0 from LOADING to FULL, Loading Done
*Mar  1 00:38:25.710: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.4 on Serial0/0 from LOADING to FULL, Loading Done
Donc mes voisins sont montés (cela peut prendre du temps, jusqu’a 1 minute…), mais est-ce que cela marche pour autant ?
Oui et non. Regardons ces commandes:
ABR3#sh ip route
Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 3 subnets
C       10.2.0.0 is directly connected, FastEthernet0/1
C       10.0.0.0 is directly connected, Serial0/0
O IA    10.1.0.0 [110/192] via 10.0.0.1, 00:14:19, Serial0/0
ABR3#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.1          1   FULL/BDR        00:01:33    10.0.0.1        Serial0/0
On voit que mon routeur ASBR1 n’est pas le DR, seulement, les routes sont donc apprise par ASBR1, mais vue comme un saut supplémentaire, pas comme si c’était le DR qui les avait averties. On va donc passer ASBR1 en DR avec la commande ip[v6] ospf priority 10, et on va mettre les autres routeurs à 0 pour qu’il n’y ai pas de BDR (il faudrait un deuxième routeur avec 3 PVCs), puis pour que les changements soient reflettés, on va faire un clear ip[v6] ospf process (et attendre que les voisins montent, longtemps,…)
ABR3#sh ip route
Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 3 subnets
C       10.2.0.0 is directly connected, FastEthernet0/1
C       10.0.0.0 is directly connected, Serial0/0
O IA    10.1.0.0 [110/128] via 10.0.0.2, 00:00:17, Serial0/0
Voyez que le cout à baissé, et que le next-hop n’est plus ASBR1, mais bien le bon routeur dans le réseau (ABR1). Ceci est le comportement normal, lorsqu’on est dans un réseau multi accès, un routeur avertissant une route devient le nexthop pour cette route pour les autres routeurs du réseau.
Ici avant la configuration du DR, vu que ce dernier n’était pas le bon routeur et que ASBR1 et ABR3 avaient formé une relation de voisinage, ASBR1 avertissait des routes, mais pas en tant que DR, bref, un gros bazard…Qui est loin d’être fini d’ailleurs: On remarque que le nexthop est bien ABR1, seulement, notre routeur ne sait pas joindre cette IP car il existe un VC frame relay uniquement entre ABR1 et ASBR1.
Ici plusieurs options s’offrent à nous (sans configurer de circuits virtuels supplémentaires):
  • Faire un mappage frame-relay manuel sur les ABR 1, 2 et 3 en mappant les next-hops vers leur DLCI de sortie
  • Faire un mappage des IPs des voisins avec des routes statiques et ASBR1 en nexthop
  • Activer l’option ip ospf network point-to-multipoint (sur tous les routeurs, si network type différent, pas d’adjacence), ce qu’on va faire.
  • On pourrait aussi utiliser des sous interfaces sur ASBR1 et faire des réseau point-to-point, mais cela necessiterai des sous réseaux séparés sur ASBR1.
On commence par enlever les neighbor, car toute la beauté de cette solution c’est qu’ils seront découverts dynamiquement (pour peu que votre réseau NBMA supporte le multicast, sans quoi il faut utiliser point-to-multipoint non-broadcast et laisser les neighbor)
ASBR1(config)#router ospf 1
ASBR1(config-router)#no neighbor 10.0.0.2
ASBR1(config-router)#no neighbor 10.0.0.3
ASBR1(config-router)#no neighbor 10.0.0.4
ASBR1(config-router)#exit
ASBR1(config)#int s0/0
ASBR1(config-if)#ipv ospf network point-to-multipoint
ASBR1(config-if)#ipv6 ospf network point-to-multipoint
N’oubliez pas les autres routeurs ABR 1/2/3
Et maintenant regardez ça :
ABR3#sh ip route
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C       10.2.0.0/24 is directly connected, FastEthernet0/1
O       10.0.0.2/32 [110/128] via 10.0.0.1, 00:01:25, Serial0/0
C       10.0.0.0/24 is directly connected, Serial0/0
O IA    10.1.0.0/24 [110/192] via 10.0.0.1, 00:01:25, Serial0/0
O       10.0.0.1/32 [110/64] via 10.0.0.1, 00:01:25, Serial0/0
ABR3#ping 10.1.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/73/121 ms
ABR3#traceroute 10.1.0.1

Type escape sequence to abort.
Tracing the route to 10.1.0.1

  1 10.0.0.1 44 msec 32 msec 44 msec
  2 10.0.0.2 72 msec 100 msec *
On voit que ASBR1 averti des routes /32 vers les nexthop qui passent par lui !
Note: le mode Point-To-Multipoint n’utilise pas les mécanismes DR/BDR et multiplie donc les adjacences
Pour IPv6, cela ne marche pas, car j’avais oublié de rajouter l’option broadcast dans la commande frame-relay map dans la config initiale, donc modifiez les map (sh run | i map) en rajoutant broadcast pour que ça fonctionne, et la ça ne fonctionne pas, et voici l’explication (bon j’avoue que j’ai fait un petit coup de google :p).
On obtient ça :
*Mar  1 01:56:43.307: %OSPFv3-5-ADJCHG: Process 1, Nbr 10.0.0.4 on Serial0/0 from EXSTART to DOWN, Neighbor Down: Too many retransmits
Un petit coup de debug:
ASBR1#deb ipv osp ev
OSPFv3 events debugging is on
ASBR1#deb ipv6 packet
IPv6 unicast packet debugging is on
*Mar  1 02:00:56.133: OSPFv3: Send DBD to 10.0.0.4 on Serial0/0 seq 0x149B opt 0x0013 flag 0x7 len 28
*Mar  1 02:00:56.133: IPV6: source FE80::CA00:CFF:FE4F:0 (local)
*Mar  1 02:00:56.137:       dest FE80::CA01:CFF:FE4F:0 (Serial0/0)
*Mar  1 02:00:56.137:       traffic class 224, flow 0x0, len 68+0, prot 89, hops 1, originating
*Mar  1 02:00:56.137: IPv6: Encapsulation failed

ABR1#sh ipv6 int br s0/0
Serial0/0                  [up/up]
    FE80::CA01:CFF:FE4F:0
    FC00::A:0:0:2
Vous voyez où je veux en venir ? Dans OSPFv3 les hellos sont envoyés en multicast, les voisins de détectent, mais les mises à jours sont envoyées via les adresses Link-local, or, on a vu, il n’y a pas d’I-ARP pour IPv6 sur frame relay, votre routeur ne sait donc pas ou les router, il faut donc rajouter des frame-relay map broadcast vers les adresses des link local des voisins…
Note: les addresses mac sous dynamips pouvant changer, les adresses link-local vont aussi changer…
On peut modifier ça via la commande ipv6 address FE80::XXX:0 link-local (sans masque)
voici donc le résultat après le mapping:
ASBR1#sh ipv ospf nei

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
10.0.0.3          0   FULL/  -        00:01:59    5               Serial0/0
10.0.0.2          0   FULL/  -        00:01:40    5               Serial0/0
10.0.0.4          0   FULL/  -        00:01:40    5               Serial0/0
Notez qu’il n’y a pas de DR/BDR ce qui est normal. Et la table de routage:
ABR1#sh ipv route ospf
IPv6 Routing Table - 10 entries
O   FC00::A:0:0:1/128 [110/64]
     via FE80::CA00:AFF:FE87:0, Serial0/0
O   FC00::A:0:0:3/128 [110/128]
     via FE80::CA00:AFF:FE87:0, Serial0/0
O   FC00::A:0:0:4/128 [110/128]
     via FE80::CA00:AFF:FE87:0, Serial0/0
OI  FC00::A:2:0:0/120 [110/129]
     via FE80::CA00:AFF:FE87:0, Serial0/0
ABR1#ping FC00::A:2:0:1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FC00::A:2:0:1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/69/100 ms
Voilà, notre aire 0 backbone est fonctionelle en IPv4 et IPv6.
Je voudrais attirer votre attention sur le fait qu’on n’est pas obligé d’avoir le même type de réseau OSPF en IPv4 et en IPv6… L’option point-to-multipoint est la plus intéressante si l’on a pas une topologie full mesh, du fait qu’elle palie aux problèmes de communication entre les voisins, cependant, le nombre d’adjacences et donc les ressources peuvent être impactée selon la topologie car vous n’avez pas de DR/BDR. Dans la réalité, il faut prendre en compte que les PVC frame relay ont un cout, mais qu’une topologie comme celle-ci ne fournie pas de redondance… L’utilisation de deux routeurs DR/BDR avec des VC sur chaques routeurs distants et un réseau type NBMA classique avec des map frame-relay manuelles peut être une bonne solution pour de la redondance sans utiliser de réseau full mesh qui nécessite plus de pvc frame-releay (dans ce cas utiliser le type de réseaux broadcast).

Area 1 : 

avant d’attaquer le principe des areas stub, et totally stub que l’on va découvrir, voici la configuration de STUB1:
STUB1(config)#ipv6 unicast-routing
STUB1(config)#router ospf 1
STUB1(config-router)#router-id 10.1.0.1
STUB1(config-router)#network 10.1.0.0 0.0.0.255 area 1
STUB1(config-router)#network 10.1.0.0 0.0.0.255 area 1
STUB1(config)#ipv6 router ospf 1
STUB1(config-rtr)#router-id 10.1.0.1
STUB1(config-rtr)#exit
STUB1(config)#int s0/0
STUB1(config-if)#ipv6 ospf 1 area 1
STUB1(config-if)#int loop0
STUB1(config-if)#ipv6 ospf 1 area 1
STUB1(config-if)#exit
Ici, l’interface n’utilise pas frame relay, et le réseau OSPF est de type point-to-point (par défaut), pas besoin donc de configuration particulière.
Jetons maintenant un coup d’oeil sur la table de routage de STUB1:
STUB1#sh ip route
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O IA    10.2.0.0/24 [110/193] via 10.1.0.1, 00:11:30, Serial0/0
O IA    10.0.0.2/32 [110/64] via 10.1.0.1, 00:11:30, Serial0/0
C       10.1.1.0/24 is directly connected, Loopback0
C       10.1.0.0/24 is directly connected, Serial0/0
O IA    10.0.0.1/32 [110/128] via 10.1.0.1, 00:11:30, Serial0/0
O IA    10.0.0.4/32 [110/192] via 10.1.0.1, 00:11:30, Serial0/0
On a donc plein de routes, alors que cette aire est isolée (stubbed), et n’a qu’un chemin pour contacter les autres aires. On va donc alléger cette table de routage en « stubbant » l’area.
Pour ce faire, il suffit d’aller sur STUB1 et ABR1, et de taper area 1 stub dans la configuration OSPF (IPv4/6)
Voyons ce qu’on obtiens:
STUB1#sh ip route
Gateway of last resort is 10.1.0.1 to network 0.0.0.0

     10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O IA    10.2.0.0/24 [110/193] via 10.1.0.1, 00:07:03, Serial0/0
O IA    10.0.0.2/32 [110/64] via 10.1.0.1, 00:07:03, Serial0/0
C       10.1.1.0/24 is directly connected, Loopback0
C       10.1.0.0/24 is directly connected, Serial0/0
O IA    10.0.0.1/32 [110/128] via 10.1.0.1, 00:07:03, Serial0/0
O IA    10.0.0.4/32 [110/192] via 10.1.0.1, 00:07:03, Serial0/0
O*IA 0.0.0.0/0 [110/65] via 10.1.0.1, 00:07:03, Serial0/0
Vous ne vous attendiez pas à ça hein ? On voit bien qu’on a une route par défaut qui a été ajoutée, mais on a encore les routes IA. Cela vient du fait que par défaut une area stub filtre les LSA type 5 (externes), mais pas les types 3 (inter Area). Pour tout filtrer, il faut rajouter l’option no-summary après area 1 stub, cela crée une aire dite « Totally stubbed »
STUB1(config)#router osp 1
STUB1(config-router)#area 1 stub no-summary
STUB1(config-router)#ipv6 router ospf 1
STUB1(config-rtr)#area 1 stub no-summary
STUB1(config-rtr)#exit
STUB1(config)#^Z
STUB1#sh ip
*Mar  1 00:15:35.228: %SYS-5-CONFIG_I: Configured from console by console
STUB1#sh ip route
Gateway of last resort is 10.1.0.1 to network 0.0.0.0

     10.0.0.0/24 is subnetted, 2 subnets
C       10.1.1.0 is directly connected, Loopback0
C       10.1.0.0 is directly connected, Serial0/0
O*IA 0.0.0.0/0 [110/65] via 10.1.0.1, 00:00:13, Serial0/0
STUB1#sh ipv6 route ospf
OI  ::/0 [110/65]
     via FE80::CA01:AFF:FEC1:0, Serial0/0
STUB1#
C’est mieux non ? Mais on va pouvoir faire quelque chose d’encore mieux! Regardez ça:
ASBR1#sh ip route | i 10.1
O IA    10.1.1.1/32 [110/129] via 10.0.0.2, 00:13:45, Serial0/0
O IA    10.1.0.0/24 [110/128] via 10.0.0.2, 00:14:57, Serial0/0
On voit que toutes les routes de l’aire 1 sont averties séparément, alors que l’on pourrait les regrouper. Ici, on en a que deux, mais il faut imaginer qu’on puisse en avoir des centaine. Pour agréger des routes avec OSPF, il y a deux commandes:
  • area X range pour les routes OSPF
  • summary-address pour les routes externes
Cela donne donc ceci (configurer sur l’ABR):
ABR1(config-router)#area 1 range 10.1.0.0 ?
  A.B.C.D  IP mask for address

ABR1(config-router)#area 1 range 10.1.0.0 255.255.0.0
ABR1(config-router)#exit
ABR1(config)#ipv6 router ospf 1
ABR1(config-rtr)#area 1 range FC00::A:1:0:0/96
Vérification:
ASBR1#sh ip route | i 10.1
O IA    10.1.0.0/16 [110/128] via 10.0.0.2, 00:01:13, Serial0/0
ASBR1#sh ipv6 route | i A:1
OI  FC00::A:1:0:0/96 [110/128]
On a donc une belle aire OSPF Totally stubbed !

Areas 3 & 4: Virtual link OSPF

Ceux qui connaissent un petit peu OSPF savent que son design impose que toutes les aires soient reliées à l’aire 0 (d’ailleurs un des avantages de ISIS c’est de ne pas avoir cette contrainte). Cependant, dans la pratique, cela n’est pas toujours possible. Il faut donc créer un lien virtuel qui traverse une aire afin de simuler que notre aire (ici la 4) soit directement connectée. OSPF dispose d’une fonction dédiée à cela, cependant, il est tout à fait possible d’utiliser un tunnel GRE ou IPSEC (avec une VTI pour ne pas bloquer le multicast).
La configuration d’ABR4 de base n’étant pas plus compliquée que ce qu’il y a au dessus, je vais passer les détails:
ABR2(config)#router ospf 1
ABR2(config-router)#netw 10.3.0.0  0.0.0.255 area 3
ABR2(config-router)#int F0/1
ABR2(config-if)#ipv6 ospf 1 area 3
!!!!!!!!!!!
ABR4(config)#router ospf 1
ABR4(config-router)#net 10.3.0.0 0.0.0.255 area 3
ABR4(config-router)#net 10.4.0.0 0.0.0.255 area 4
ABR4(config-router)#router-id 10.3.0.2
ABR4(config-router)#exit
ABR4(config-if)#ipv6 ospf 1 area 3
ABR4(config-if)#int F0/1
ABR4(config-if)#ipv6 ospf 1 area 4
ABR4(config)#ipv6 router ospf 1
ABR4(config-rtr)#router-id 10.3.0.2
Note, si vous avez des messages %OSPF-4-BADLSATYPE un write mem à suffit à les faire disparaitre… allez savoir !
Donc ici, on va faire une config toute simple sur RTR1 pour le moment:
RTR1(config)#router ospf 1
RTR1(config-router)#router-id 10.4.0.2
RTR1(config-router)#net 10.4.0.0 0.0.0.255 area 4
RTR1(config-router)#net 10.4.1.0 0.0.0.255 area 4
RTR1(config-router)#ipv6 router ospf 1
RTR1(config-rtr)#router-id 10.4.0.2
RTR1(config-rtr)#int loop0
RTR1(config-if)#int F0/0
RTR1(config-if)#ipv6 ospf 1 area 4
OSPFv3: No IPV6 enabled on this interface
RTR1(config-if)#ipv6 enable
RTR1(config-if)#ipv6 address FC00::A:4:0:2/120
RTR1(config-if)#ip add 10.4.0.2 255.255.255.0
RTR1(config-if)#ipv6 ospf 1 area 4
RTR1(config-if)#no sh
Ici, on aura pas de messages d’erreur, mais ABR4 ne transmettras aucune route depuis/vers RTR1.
Pour palier à cela, il y a une commande qui permets de créer un lien virtuel très simplement, dans la configuration d’ospf, sur les 2 ABR de l’aire qui est traversée par le virtual-link (ici l’aire 3), taper area X virtual-link router_id_distant.
Il s’agit ici du router-ID OSPF, et non pas de l’IP de l’interface du routeur. Les routeurs ne sont pas obligé d’être directement reliés entre eux.
ABR2(config)#router ospf 1
ABR2(config-router)#area 3 virtual-link 10.3.0.2
ABR2(config-router)#ipv router ospf 1
ABR2(config-rtr)#area 3 virtual-link 10.3.0.2
!!!!!!!!!
ABR4(config)#router ospf 1
ABR4(config-router)#area 3 virtual-link 10.0.0.3
ABR4(config-router)#ipv6 router ospf 1
ABR4(config-rtr)#area 3 virtual-link 10.0.0.3
ABR4(config-rtr)#exit
ABR4(config)#
*Mar  1 00:11:10.390: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.3 on OSPF_VL0 from LOADING to FULL, Loading Done
Vérifications:
ABR4#sh ip ospf virtual-links
Virtual Link OSPF_VL0 to router 10.0.0.3 is up
!...
RTR1#sh ip route
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
O IA    10.2.0.0/24 [110/131] via 10.4.0.1, 00:00:17, FastEthernet0/0
O IA    10.0.0.2/32 [110/130] via 10.4.0.1, 00:00:17, FastEthernet0/0
O IA    10.3.0.0/24 [110/2] via 10.4.0.1, 00:00:27, FastEthernet0/0
O IA    10.0.0.3/32 [110/2] via 10.4.0.1, 00:00:17, FastEthernet0/0
O IA    10.1.0.0/16 [110/194] via 10.4.0.1, 00:00:17, FastEthernet0/0
O IA    10.0.0.1/32 [110/66] via 10.4.0.1, 00:00:17, FastEthernet0/0
C       10.4.0.0/24 is directly connected, FastEthernet0/0
O IA    10.0.0.4/32 [110/130] via 10.4.0.1, 00:00:18, FastEthernet0/0
C       10.4.1.0/24 is directly connected, Loopback0

Evidemment ça marche aussi avec IPv6, mais je vais pas vous montrer la table de routage à tout bout de champ…
Bon, jvais totally stubb ça ça va être mieux

RTR1(config)#router ospf 1
RTR1(config-router)#area 4 stub no-summary
RTR1(config-router)#ipv router osp 1
RTR1(config-rtr)#area 4 stub no-summary
RTR1(config-rtr)#^Z
RTR1#
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ABR4(config)#router ospf 1
ABR4(config-router)#area 4 stub no-sum
ABR4(config-router)#ipv router ospf 1
ABR4(config-rtr)#area 4 stub no-sum
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
RTR1#sh ip route
Gateway of last resort is 10.4.0.1 to network 0.0.0.0

     10.0.0.0/24 is subnetted, 2 subnets
C       10.4.0.0 is directly connected, FastEthernet0/0
C       10.4.1.0 is directly connected, Loopback0
O*IA 0.0.0.0/0 [110/2] via 10.4.0.1, 00:00:35, FastEthernet0/0
Et la on sens la puissance du stub no-summary !!

Area 2: Une aire pas si stub que ça!

Bon drole de titre, mais l’appellation « not so stubby area » m’a toujours amusé, et je suis rassuré, je ne suis pas le seul, le trainer du CBT nugget BSCI parlait, à ce que j’ai compris, d’australiens adepte de marijuana qui auraient trouvé ce titre. Je ne sais pas si une vérité historique se cache derrière cela, cela mériterai de creuser, mais on s’écarte un peu de notre objectif ;).
Bon, tout d’abord, qu’est-ce qu’une aire NSSA ? Et bien en fait c’est simplement une aire STUB au niveau OSPF, mais qui contient un ASBR, autrement dit, un routeur qui apprend des routes autrement que par OSPF, et surtout ,qui est connecté à un réseau externe qui n’est pas pris en compte dans la topologie OSPF. Ces routes, lorsque redistribuées dans OSPF, ont un type LSA 7, qui est traduit en type 5 par l’ABR.
Je voudrait attirer votre attention sur le fait qu’il y a 2 types de metriques pour les routes externes (types 5 et 7): 1 = cout incrémenté, 2 = cout non incrémenté, par défaut.
Pourquoi donc cette différence, hé bien prenons mon exemple:
  • Ici, nous avons 2 connexions internet, il est donc logique que OSPF utilise celle qui est la plus proche, on va donc redistribuer les routes externes avec une metrique de type 1
  • Il est fréquent de n’avoir qu’une seule connexion internet, et donc, dans ce cas, il n’est pas utile que les routeurs fassent des calculs supplémentaires sur ces routes puisque cela ne changera en rien le résultat, étant donné qu’il n’y a qu’un seul chemin possible.
Pour configurer une NSSA, il suffit de mettre area X nssa dans la configuration d’OSPF, et c’est tout !

ABR3(config)#router ospf 1
ABR3(config-router)#net 10.2.0.0 0.0.0.255 area 2
ABR3(config-router)#area 2 nssa
ABR3(config-router)#ipv6 router ospf 1
ABR3(config-rtr)#area 2 nssa
ABR3(config-rtr)#int F0/1
ABR3(config-if)#ipv6 ospf 1 area 2
NSSA1(config)#router ospf 1
NSSA1(config-router)#net 10.2.0.0 0.0.0.255 area 2
NSSA1(config-router)#area 2 nssa
NSSA1(config)#ipv6 router ospf 1
NSSA1(config-rtr)#area 2 nssa
NSSA1(config-rtr)#int F0/0
ASBR2(config)#router ospf 1
ASBR2(config-router)#area 2 nssa
ASBR2(config-router)#netw 10.2.0.0 0.0.0.255 area 2
ASBR2(config-router)#ipv6 router ospf 1
ASBR2(config-rtr)#area 2 nssa
ASBR2(config-rtr)#int f0/0
ASBR2(config-if)#ipv6 ospf 1 area 2
ASBR2(config-if)#exit
nos routeurs sont donc bien configurés, on aurait pu rajouter l’option no-summary derrière nssa pour alléger la table de routage, mais vu qu’ici on est censé redistribuer une route pour internet, on aurait 2 routes par défaut, et donc des problèmes…

Redistribution internet IPv4


On arrive bientôt à la fin de cet article, ici, je vais inclure les routes vers internet dans OSPF. On verra la subtilité IPv6 plus tard, car j’ai envie de tester le NAT-PT et les tunnels 6to4 (on y reviendra)
Pour inclure une route par défaut, on va utiliser la commande default-information originate que l’on a vu en CCNA, cependant, cette commande ne marche que dans les aire classique OSPF. Pour une aire NSSA il faut procéder comme ce qui suit (la commande ne change pas vraiment).
Note: le redistribute static subnets ne redistribue pas la route statique sous OSPF, alors que cela fonctionne avec EIGRP.
Ici, on va définir le type de metrique à 1 comme vu au dessus, et la metrique pour la route redistribuée à 100.

ASBR2(config)#ip route 0.0.0.0 0.0.0.0 100.0.1.1
ASBR2(config)#router ospf 1
ASBR2(config-router)#area 2 nssa default-information-originate metric 100 metric-type 1
ASBR2(config-router)#exit

On noteras que l’option pour définir le type de métrique existe aussi avec la commande default-information originate (sans tiret s’il vous plaît) pour les aires classiques.
Petites vérif:

ASBR2#sh ip osp database | b Type-7
		Type-7 AS External Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         100.0.1.2       298         0x80000001 0x00199B 0
sur l’ABR:
ABR3#sh ip route | i 0.0.0.0/0
O*N1 0.0.0.0/0 [110/101] via 10.2.0.2, 00:06:07, FastEthernet0/1
noter le type N1 (NSSA External 1), et le coût, puis regardez sur ABR2 (ou n’importe quel autre routeur à l’exterieur de l’airez):
ASBR1#sh ip route | i 0.0.0.0/0
O*E1 0.0.0.0/0 [110/165] via 10.0.0.4, 00:07:51, Serial0/0
On voit que le type passe en E1 lorsque la route quitte l’aire, et que le cout est incrémenté.
On va maintenant redistribuer une route par défaut sur ASBR1, en utilisant une route-map. Cela n’est pas forcément utile ici, vu que l’on a qu’une route, mais l’on aurait pu, dans le cas ou on redistribuerai plusieures routes, leur définir des paramètres différents.
ASBR1(config)#ip route 0.0.0.0 0.0.0.0 100.0.0.1
ASBR1(config)#route-map NETMAP permit 10
ASBR1(config-route-map)#set metric 100
ASBR1(config-route-map)#set metric-type type-1
ASBR1(config-route-map)#exit
ASBR1(config-std-nacl)#exit
ASBR1(config)#router ospf 1
ASBR1(config-router)#default-information originate route-map NETMAP
ASBR1(config-router)#exit
Je peux voir que la le cout à changé sur ABR2 lorsque j’ai redistribué depuis ASBR1:
ABR2#sh ip route
!...
O*E1 0.0.0.0/0 [110/229] via 10.0.0.1, 00:00:42, Serial0/0
ABR2#sh ip route
!...
O*E1 0.0.0.0/0 [110/164] via 10.0.0.1, 00:03:08, Serial0/0
ABR2#

ce qui montre ASBR1 à bien injecté sa route, cepenant, rien n’a changé sur ABR3 puisqu’il garde la route qui passe par l’area 3 étant donné qu’elle a un cout plus faible.
Si l’on avait voulu changé cela, on aurait pu supprimer ou changer le cout de la route par défaut de l’aire 2 avec un filtre sur ABR3.
ABR3(config)#ip access-list standard INTERNET_AREA2
ABR3(config-std-nacl)#permit 0.0.0.0 0.0.0.0
ABR3(config)#route-map NO_NET_AREA2 deny 1
ABR3(config-route-map)#match ip address INTERNET_AREA2
ABR3(config-route-map)#match interface F0/1
ABR3(config-route-map)#exit
ABR3(config)#route-map NO_NET_AREA2 permit 2
ABR3(config-route-map)#exit
ABR3(config)#
ABR3(config)#router ospf 1
ABR3(config-router)#distribute-list route-map NO_NET_AREA2 in
Notez le masque generique de 0.0.0.0 = 0.0.0.0/32, soit uniquement cette route, et non toutes les routes.
Piouf, au revoir la route de area 2 SUR ABR3
ABR3(config)#do sh ip route | i 0.0.0.0/0
O*E1 0.0.0.0/0 [110/164] via 10.0.0.1, 00:01:45, Serial0/0
le next-hop n’est plus 10.2.0.2 comme avant.
Je tiens toutefois à préciser que l’utilisation de distribute-list avec OSPF n’enlève pas les routes de l’arbre SPF, mais empêche qu’elles soient installées dans la table de routage, ce qui veut dire que dans l’exemple au dessus, si la connexions internet de ASBR1 tombe, les autres routeur utiliserons la route de ASBR2, mais pas ABR3. Une solution aurait été que ASBR2 augmente la metric lorsqu’il envoi la route à ABR3. Plus d’info ici:

Internet pour IPv6

Ici, on va utiliser deux fonctions pour accéder à internet via un réseau IPv4:
La première, c’est du NAT-PT qui permets de faire du nat entre IPv6 et IPv4, mes hosts IPv6 seront donc mappés à une IPv4 en sortant.
La seconde , c’est l’utilisation d’un tunnel 6to4 qui permets à un routeur IPv6 de s’interconnecter avec un FAI en IPv6 en utilisant une connexion IPv4.
Je vais mettre le NAT-PT sur ASBR1 et le 6to4 sur ASBR2.
Commençons déjà par la config des FAI (que je vais pas détaillé, si vous arrivez ici, vous devrier savoir ce qu’est une adresse ip et une route statique  )
Router(config)#hostn ISP
ISP(config)#int F0/0
ISP(config-if)#ip add 100.0.0.1 255.255.255.0
ISP(config-if)#no sh
ISP(config-if)#int F0/1
ISP(config-if)#ip add 100.0.1.1 255.255.255.0
ISP(config-if)#no sh
ISP(config-if)#int f1/0
ISP(config-if)#ip add 100.0.2.1 255.255.255.0
ISP(config-if)#no sh
ISP(config-if)#exit
Router(config)#hostn ISPv6
ISPv6(config)#ipv6 unicast-routing
ISPv6(config)#int f0/0
ISPv6(config-if)#ip add 100.0.2.2 255.255.255.0
ISPv6(config-if)#no sh
ISPv6(config-if)#int lo0
ISPv6(config-if)#ipv6 en
ISPv6(config-if)#ipv6 add 2002::1/96
ISPv6(config-if)#exit
et ne pas oublier le routage IPv4 (avec un ptit ping pour la forme)
ISPv6(config)#ip route 100.0.0.0 255.0.0.0 100.0.2.1
ASBR2(config)#ip route 100.0.0.0 255.0.0.0 100.0.1.1
ASBR2(config)#do ping 100.0.2.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.2.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 16/92/184 ms
Maintenant attaquons la configuration du tunnel 6to4:
voici le template coté enteprise:
interface Tunnel0
 description 6to4 tunnel
 no ip address
 no ip redirects
 ipv6 address 2002:::1/64 !
 tunnel source
 tunnel mode ipv6ip 6to4
ipv6 route 2002::/16 Tunnel0 !Subnet ipv6 du FAI
ipv6 route ::/0 2002:::1 !ip 6to4 du FAI v6
coté FAI, la même chose, si ce n’est que l’on vas router uniquement la route en /64 vers le bon tunnel pour un client donné et pas de route par défaut.
Ici, pas de tunnel destination. La, vous allez me dire, comment ça marche ? tout simplement, lorsque je vais transférer un paquet dans mon tunnel 6to4, celui-ci va décoder l’IPv6 de destination en IPv4, et donc encapsuler l’IPv6 dans un paquet IPv4 avec l’IPv4 dérivée de l’IPv6 du paquet initial. Un tunnel 6to4 est donc multipoint.
voici mes IPv6 pour le 6to4:
100.0.2.2: 2002:6400:0202::1/64 (100=64 en hex)
100.0.1.2: 2002:6400:0102::1/64
et donc la ptite conf du tunnel (je vais pas faire de route par défaut IPv6, juste une globale)
ASBR2(config)#interface tunnel 0
ASBR2(config-if)#desc
*Mar  1 00:27:52.854: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
ASBR2(config-if)#desc cool 6to4 tunnel
ASBR2(config-if)#ipv6 address 2002:6400:0102::1/64
ASBR2(config-if)#tunnel source F0/1
ASBR2(config-if)#tunnel mode ipv6ip 6to4
ASBR2(config-if)#exit
ASBR2(config)#ipv6 route 2002:6400:0202::1/64 tunnel 0
ASBR2(config)#ipv6 route 2002::/16 2002:6400:0202::1
Ici, on a deux routes:
Une route vers le nexthop avec une IP 6to4 via le tunnel 0, qui vas permettre de router les paquets IPv6 qui transitent par ce tunnel vers la bonne IPv4, et le reste des routes IPv6 qui vont utiliser ce nexthop. Il ne faut pas router directement vers le tunnel les autres IPv6, sans quoi elles ne pourront pas, ou mal, être converties en IPv6
la configuration du FAI
ISPv6(config)#interface tunnel 1234
ISPv6(config-if)#desc tunnel 6to4 to my best client
ISPv6(config-if)#tunnel source F0/0
ISPv6(config-if)#ipv6 add 2002:6400:0202::1/64
ISPv6(config-if)#tunnel mode ipv6ip 6to4
ISPv6(config-if)#exit
ISPv6(config)#ipv6 route 2002:6400:0102::1/64 tunnel 1234
ISPv6(config)#exit
 ping:
SBR2#ping 2002::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 13/39/68 ms