OSPF : Network Type Point-To-Multipoint sur réseau Ethernet

Voici le genre d’article qui me vient à l’esprit en répondant à une question lors d’un cours que je donnais concernant le Frame-Relay…

Alors que j’expliquais les bienfaits du Network Type OSPF « Point-To-Multipoint » dans une topologie Frame-Relay Hub&Spoke, Emil (merci pour m’avoir inspiré l’idée) me demande si cet Network type est applicable à une interface Ethernet …

Ma première réponse fut bien entendu … « Ca n’a pas vraiment de sens » … Mais … en y réfléchissant quelques secondes, il m’est apparu qu’il est possible de produire une topologie Hub&Spoke sur un réseau Ethernet … et ce grâce aux Private Vlans, puisque ceux-ci permettent d’isoler des pots de switch au sein d’un VLAN.

N’ayant pas sous la main un modèle de switch supportant cette technologie, je me suis rabattu sur mon C3550, qui supporte les ports en mode « Protected ». En gros, c’est une version ultra simplifiée des VLANs privés. Le principe est simple: les ports configurés en « protected » ne peuvent pas communiquer avec d’autres ports protected au sein du même switch.

J’ai donc tout ce qu’il me faut pour la mise en place de cette topologie assez tordue … mais qui n’est pas sans intérêt…

La topologie utilisée…

ospf-PTMoE

Rien de complexe. Trois routeurs, interconnectés par leurs interfaces Fa0/0 au moyen d’un Switch c3550. Le but étant de mettre en place OSPF, j’ai rajouté sur chaque routeur une interface loopback. Au final il faut que l’on puisse « pinguer » de loopback à loopback, et ce sans communication directe possible entre R2 et R3 … tout devra passer par R1 et le tout pris en charge par OSPF.

 

 

 

Mise en place de l’isolation des ports du switch

Avant de commencer, un petit test de communication, sans avoir encore rien configuré sur le switch…

R2#ping 10.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
R2#

Jusque là tout va bien… appliquons maintenant l’isolation des ports …

SWITCH-A(config)#interface range fastEthernet 0/11-12
SWITCH-A(config-if-range)#switchport protected

A partir de maintenant lers ports Fa0/11 et Fa0/12, bien qu’étant dans le même VLAN (1 par défaut), ne peuvent plus s’échanger de trames … par contre ils peuvent communiquer avec tout port non « protected », ce qui est le cas du Fa0/1 où est connecté R1.

Testons le résultat…

R2#ping 10.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R2#
R2#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R2#

Voilà une bonne chose de faite, R2 et R3 ne peuvent plus dialoguer en direct … mais R2 et R3 peuvent par contre communiquer avec R1.

Mise en place d’OSPF

Configuration sur R1…

R1#sh run | section router
router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 network 1.1.1.1 0.0.0.0 area 0
 network 10.0.0.0 0.0.0.255 area 0
R1#

Configuration sur R2…

R2#sh run | section router
router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
 network 2.2.2.2 0.0.0.0 area 0
 network 10.0.0.0 0.0.0.255 area 0
R2#

Configuration sur R3…

R3#sh run | section router
 router ospf 1
 router-id 3.3.3.3
 log-adjacency-changes
 network 3.3.3.3 0.0.0.0 area 0
 network 10.0.0.0 0.0.0.255 area 0
 R3#

Pour l’instant la configuration est tout ce qu’il y a de plus basique … mais … en toute logique certains disfonctionnements devraient apparaître…

Etat des lieux avant changement du Network-Type

Les adjacences sont formées, à première rien de spécial … MAIS …

R2#show 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
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 10.0.0.1, 00:01:26, FastEthernet0/0
 2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
 10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet0/0
R2#

R2 a une route OSPF vers la loopback de R1 mais pas de R3 … et la réciproque est vraie aussi … pourquoi ? ….

Nous sommes ici en face de cas classique d’un problème d’élection de DR/BDR sur une topologie Hub&Spoke … Le DR est dans le cas présent R2 … il est censé centraliser les updates et les transmettre aux autres routeurs … hors … il est dans l’impossibilité d’échanger des trames avec R3 … ce qui provoque donc des tables de routages incomplètes et entre autre un état des DR/BDR assez inconsistant.

Résolution du problème : OSPF Network-Type point-to-multipoint

Le network-type point-to-multipoint défini que les routeurs vont décourvrir dynamiquement leurs voisins (communication en multicast), qu’ils n’y aura pas d’élection de DR/BDR, les Hello/Dead Timers seront de 30/120s respectivement … et surtout … les adjacences seront vues par OSPF comme des liaisons point-à-point … ce qui aura pour effet de changer un poil le comportement des routeurs …

Sur R1, R2 et R3 …

Rx(config)#interface fa0/0
Rx(config-if)#ip ospf network point-to-multipoint

Et … magie …

R2#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
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 10.0.0.1, 00:00:15, FastEthernet0/0
 2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
 3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/3] via 10.0.0.1, 00:00:15, FastEthernet0/0
 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O 10.0.0.3/32 [110/2] via 10.0.0.1, 00:00:15, FastEthernet0/0
C 10.0.0.0/24 is directly connected, FastEthernet0/0
O 10.0.0.1/32 [110/1] via 10.0.0.1, 00:00:16, FastEthernet0/0
R2#

R2 a désormais toutes les routes … mais il y a une subtilité … notez que R1 est devenu le Next-Hop pour accéder à 3.3.3.3 et même à 10.0.0.3 (alors que cette interface est dans le même domaine de diffusion, mais inaccessible en direct à cause des deux protected ports). OSPF a également généré une route vers 10.0.0.3/32 … avec 10.0.0.1 en next-hop… le trafic vers cette interface devrait donc passer par R1 … et être routé pour aboutir dans le même réseau …

R2#traceroute 10.0.0.3 numeric
Type escape sequence to abort.
Tracing the route to 10.0.0.3
 1 10.0.0.1 0 msec 4 msec 4 msec
 2 10.0.0.3 4 msec * 0 msec
R2#

Et et donc … un ping de 2.2.2.2 vers 3.3.3.3 devrait fonctionner … (en passant par R1 bien sur)

R2#ping 3.3.3.3 source 2.2.2.2
Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
 Packet sent with a source address of 2.2.2.2
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
 R2#

Oui mais … Pourquoi ?

Là c’est une bonne question, bien que ce soit réalisable… l’utilité ne me saute pas aux yeux … si ce n’est que cela permet d’isoler des routeurs … et forcer des paquets à êtres routés pour passer entre deux machines du même domaine de diffusion … et qui dit routage … dit Access-List en In et Out … etc.

Donc peut-être dans une optique de privatisation ou de segmentation d’un réseau …

Quoi qu’il en soit … ça fonctionne! ( Merci Emil pour l’idée …)

NOTE: Bien que le schéma provienne de GNS3, il est impossible à l’heure actuelle de reproduire cette config en virtuel … les private-vlans etc sont des fonctionnalités qui ne sont disponibles pour le moment que sur du vrai matériel.

VN:F [1.9.22_1171]
Rating: 9.5/10 (2 votes cast)
OSPF : Network Type Point-To-Multipoint sur réseau Ethernet, 9.5 out of 10 based on 2 ratings
Posted in Cisco, La pratique, Routing
Tags: , , , , ,
4 commentaires sur “OSPF : Network Type Point-To-Multipoint sur réseau Ethernet
  1. dafunkychild dit :

    Je ne connaissais pas le mode protected sur les 3550, ça m’aurait rendu service à une époque.
    Article intéressant.
    Merci Steve.

  2. ibinda dit :

    Bonjour,

    sympa ça,
    comment rajouter un SW 3550 sur packet tracer?

    cdt,

    • Dans PT il n’y a pas de 3550, par contre il y a la version plus récente, le 3560, mais les fonctinnalités comme le switchport protected n’y sont pas prévues à ma connaissance

  3. ibinda dit :

    Bonjour,

    effectivement,le 3560 n’a pas cette fonctionnalité,

    Cdt,

1 Pings/Trackback pour "OSPF : Network Type Point-To-Multipoint sur réseau Ethernet"
  1. […] Voici le genre d’article qui me vient à l’esprit en répondant à une question lors d’un cours que je donnais concernant le Frame-Relay… Alors que j’expliquais les bienfaits du Network Type OSPF « Point-To-Multipoint » dans une topologie Frame-Relay…  […]

Laisser un commentaire

Visit Us On FacebookVisit Us On GooglePlusVisit Us On TwitterVisit Us On LinkedinVisit Us On YoutubeCheck Our Feed

Archives

Connexion à WordPress protégée par Clef
%d blogueurs aiment cette page :