Discussion :

[madmask]

Bonjour à tous,

Je réalise une simulation (gns3) de réseau en vue d'équiper un nouveau bâtiment. Il s'agit d'un ensemble de 5 blocs dont un fait office de moyeux central. Dans ce dernier je compte établir la dorsale de mon réseau. A chaque étage se situe un switch L3 auquel seront reliés mes switchs d'accès (un par étage et par bloc). Le rôle de gateway est tenu par une appliance : AXSGuard. Celle-ci rempli des rôles divers, principalement ceux de firewall et de filtrage des utilisateurs pouvant accéder au net. Chaque périphérique d'étage est relié à ses voisins directs et à la gateway par des réseaux /30. Voilà pour le tableau général.

Les switchs de ma dorsale sont configurés dans une zone OSPF. Le tout est fonctionnel je vois mes voisins et les réseaux qui y sont connectés y compris ceux vers ma gateway.

Le problème est que je ne peux pas joindre les interfaces de ma GW à moins qu'elle ne soient directement connectées.

Par exemple :
F0 (Floor 0) est directement connecté à GW via le réseau 172.22.0.0/30 l'IP de l'interface de GW est 172.22.0.1.
De F0 la requête ping 172.22.0.1 aboutit. Depuis F1 elle échoue alors que le réseau 172.22.0.0 est bien annoncé par OSPF.

La connectivité GW > Fx ne pose pas de problème.

Insérer GW dans la zone OSPF n'est pas possible, les protocoles de routage dynamique ne sont pas supportés par l'appliance.

Je ne suis pas un gourou des réseaux (et de loin) je pense qu'un truc bête m'a échappé.

Merci d'avance pour tout éclaircissement. Ci dessous je poste la config de deux étages (les autres sont configurés pareil), de ma GW, mon plan d'adressage et un schéma.

GW>F0 172.22.0.0 /30 .1 .2 .3 f0/0 f0/0
GW>F1 172.22.0.4 .5 .6 .7 f0/1
GW>F2 172.22.0.8 .9 .10 .11 f1/0
GW>F3 172.22.0.12 .13 .14 .15 f1/1
GW>F4 172.22.0.16 .17 .18 .19 f1/2
GW>F5 172.22.0.20 .21 .22 .23 f1/3


F0>F1 172.22.0.24 /30 .25 .26 .27 f1/0 f0/1
F1>F2 172.22.0.28 .29 .30 .31
F2>F3 172.22.0.32 .33 .34 .35
F3>F4 172.22.0.36 .37 .38 .39
F4>F5 172.22.0.40 .41 .42 .43

F0

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
Building configuration...

Current configuration : 2610 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
no service dhcp
!
hostname F0
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
no ip icmp rate-limit unreachable
ip cef
ip tcp synwait-time 5
!
!
!
!
no ip domain lookup
!
!
vtp file nvram:vlan.dat

!
!
!
!
!
!
interface FastEthernet0/0
 description *** Unused for Layer2 SW ***
 ip address 172.22.0.2 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet0/1
 description *** Unused for Layer2 SW ***
 no ip address
 duplex auto
 speed auto
!
interface FastEthernet1/0
 no switchport
 ip address 172.22.0.25 255.255.255.252
 speed 100
!
interface FastEthernet1/1
 no switchport
 no ip address
 duplex full
 speed 100
!
!
interface Vlan1
 no ip address
 shutdown
!
router ospf 1
 log-adjacency-changes
 network 172.22.0.0 0.0.0.3 area 0
 network 172.22.0.24 0.0.0.3 area 0
!
ip route 172.22.0.0 255.255.255.252 FastEthernet0/0
!
!
no ip http server
no ip http secure-server
!
no cdp log mismatch duplex
!
!
!
!
control-plane
!
banner exec ^C

***************************************************************
This is a normal Router with a SW module inside (NM-16ESW)
It has been preconfigured with hard-code speed and duplex

To create vlans use the command "vlan database" from exec mode
After creating all desired vlans use "exit" to apply the config

To view existing vlans use the command "show vlan-switch brief"

Warning: You are using an old IOS image for this router.
Please update the IOS to enable the "macro" command!
***************************************************************
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
!
end

F1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
Building configuration...

Current configuration : 2592 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
no service dhcp
!
hostname F1-SW
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
no ip icmp rate-limit unreachable
ip cef
ip tcp synwait-time 5
!
!
!
!
no ip domain lookup
!
!
vtp file nvram:vlan.dat

!
!
!
!
!
!
interface FastEthernet0/0
 description *** Unused for Layer2 SW ***
 ip address 172.22.0.6 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet0/1
 description *** Unused for Layer2 SW ***
 ip address 172.22.0.26 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet1/0
 no switchport
 ip address 172.22.0.29 255.255.255.252
 speed 100
!
!
interface Vlan1
 no ip address
 shutdown
!
router ospf 1
 log-adjacency-changes
 network 172.22.0.4 0.0.0.3 area 0
 network 172.22.0.24 0.0.0.3 area 0
 network 172.22.0.28 0.0.0.3 area 0
!
!
!
no ip http server
no ip http secure-server
!
no cdp log mismatch duplex
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
banner exec ^C

***************************************************************
This is a normal Router with a SW module inside (NM-16ESW)
It has been preconfigured with hard-code speed and duplex

To create vlans use the command "vlan database" from exec mode
After creating all desired vlans use "exit" to apply the config

To view existing vlans use the command "show vlan-switch brief"

Warning: You are using an old IOS image for this router.
Please update the IOS to enable the "macro" command!
***************************************************************
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
!
end

GW

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
Building configuration...

Current configuration : 2622 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
no service dhcp
!
hostname GW-SW
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
no ip icmp rate-limit unreachable
ip cef
ip tcp synwait-time 5
!
!
!
!
no ip domain lookup
!
!
vtp file nvram:vlan.dat

!
!
!
!
!
!
interface FastEthernet0/0
 description *** Unused for Layer2 SW ***
 ip address 172.22.0.1 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet0/1
 description *** Unused for Layer2 SW ***
 ip address 172.22.0.5 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet1/0
 no switchport
 ip address 172.22.0.9 255.255.255.252
 duplex full
 speed 100
!
interface FastEthernet1/1
 no switchport
 ip address 172.22.0.13 255.255.255.252
 duplex full
 speed 100
!
interface FastEthernet1/2
 no switchport
 ip address 172.22.0.17 255.255.255.252
 duplex full
 speed 100
!
interface FastEthernet1/3
 no switchport
 ip address 172.22.0.21 255.255.255.252
 duplex full
 speed 100
!
!
interface Vlan1
 no ip address
 shutdown
!
!
!
no ip http server
no ip http secure-server
!
no cdp log mismatch duplex
!
!
!
!
control-plane
!
!
banner exec ^C

***************************************************************
This is a normal Router with a SW module inside (NM-16ESW)
It has been preconfigured with hard-code speed and duplex

To create vlans use the command "vlan database" from exec mode
After creating all desired vlans use "exit" to apply the config

To view existing vlans use the command "show vlan-switch brief"

Warning: You are using an old IOS image for this router.
Please update the IOS to enable the "macro" command!
***************************************************************


!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
!
end

[Invité]

Salut,

c'est un problème de design.

Prenons par exemple le triangle F0-F1-GW :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
            +----+.2   172.22.0.0/30
            | F0 |-------------------
            +----+                  |
               |.25                 |.1
               |                  +----+
172.22.0.24/30 |                  | GW |
               |                  +----+
               |.26                 |.5
            +----+.6                |
            | F1 |-------------------
            +----+    172.22.0.4/30

Il y a une adjacence OSPF entre F0 et F1 et F0 annonce 172.22.0.0/30. F1 a donc l'entrée 172.22.0.0/30 dans sa table de routage avec comme next hop 172.22.0.25.
Si tu envoies un paquet IP vers 172.22.0.1 depuis F1, voici la cinématique des flux IP :

- F1 envoie le paquet vers 172.22.0.1 avec comme IP source 172.22.0.26
- F0 forwarde ce paquet vers GW toujours avec l'IP source 172.22.0.26
- GW ne connait pas le réseau 172.22.0.24/30, il droppe donc le paquet et émet un ICMP Network Unreachable.

Pour fixer ce problème, il faudrait configurer l'adresse statique suivante sur GW :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ip route 172.22.0.24 255.255.255.252 172.22.0.2

par exemple...

En revanche, ce type de déploiement entrainera du routage assymétrique... Et puis ça n'est pas aligné avec l'objectif que tu t'es fixé, à savoir que tous les flux inter-étages doivent impérativement passer par GW. A partir du moment que tu crées un backbone OSPF directement entre tes étages, le flux inter-étage ne passera jamais par GW...

Si tu veux forcer le trafic inter-étage à traverser GW, la seule façon de réaliser ton objectif, c'est d'implémenter du routage statique sur GW pour joindre les "réseaux distants", puis sur les F0, F1, etc, tu dois configurer une default route pointant vers l'interface de GW directement connectée. D'autre part, si tu veux filtrer le flux inter-étage au travers de GW, tous les liens directs entre F0 et F1 ne te servent plus à grand chose... Comme expliqué plus haut, ces liens vont créer des "backdoors".

Steph

[Invité]

J'avais un truc sur le feu, me voilà revenu parce que j'aime bien ce genre de problème de design, c'est mon métier

Ce design est du type "hub-and-spoke" avec filtrage de flux entre spokes. Ca nécessite de créer un collecteur de routes au niveau du hub qu'on va coupler avec un firewall.

Pour ceux que ça intéresse, au niveau d'un datacenter monté autour de VSS Cisco par exemple, ça va se décliner de la façon suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
              +------+   OSPF
              | vrf1 |----------------
              +------+                |
                  |                   |
BGP Route Leaking |                   |
                  |                   |
              +------+   OSPF     +---------+
              | vrf2 |------------| FW OSPF |
              +------+            +---------+
                  |                   |
BGP Route Leaking |                   |
                  |                   |
              +------+   OSPF         |
              | vrf3 |----------------
              +------+

1) On segmente tous les réseaux locaux en plusieurs vrf,
2) On utilise un firewall qui implémente un protocole de routage dynamique, OSPF/ISIS par exemple,
3) Le firewall agit en "collecteur de routes", il apprend tous les réseaux locaux au travers d'OSPF,
4) Et la chose la plus importante, c'est que pour passer d'une vrf à l'autre, les flux passeront forcément par le firewall, ce point de filtrage inter-vrf s'impose donc par construction.

Chez Cisco, il est possible "d'envoyer" une route directement d'une vrf à une autre en utilisant la fonctionnalité de BGP Route Leaking. Ceci aura pour conséquence de bypasser le firewall. Concrètement, si j'ai reseau1 connecté à vrf1 qui peut dialoguer directement à reseau2 connecté à vrf2 (c'est à dire sans passer par le firewall), j'utiliserai BGP pour envoyer la route directement de vrf1 par vrf2 comme update BGP.

Le point-clé de ce genre d'architecture, c'est que les tables de routage OSPF des vrf pointent toujours vers le firewall. En résumé, c'est la seule technique qui permette de "sortir physiquement" le flux d'une vrf vers une autre. Quant aux routes qui résultent du BGP Route Leaking, le routage des paquets se fait dans le bus interne du VSS qui embarque toutes les vrf et ce traffic ne sortira jamais du châssis.

Pour revenir au post qui a ouvert cette discussion, le problème de design qui se pose, c'est que pour un routeur d'étage donné, toutes les routes IP pointent vers une adresse IP qui est l'interface IP d'un réseau p2p F0-F1, F1-F2, F2-F3, etc mais jamais GW. En définitive, dans ce design, OSPF provoque un Route Leaking et fait que le routage inter-étages ne passera jamais par GW !

Steph

[madmask]

Salut, merci de t'être penché sur mon souci.

Je ne cherche pas à filtrer le trafic inter-étages via GW. GW est une passerelle vers l'extérieur. Le trafic interne ne devrait jamais y passer, sauf en cas de liaison inter-étages défaillante. Si je m'écoutais je paramètrerais OSPF sur GW pour me simplifier la vie (ton second post m'as donné envie de me remettre à la couture ). Le soucis est que GW dans la vraie vie est un AXSGuard relativement facile à configurer mais peu flexible, niveau routage je suis limité aux routes statiques.

Donc si je te suis bien, ajouter sur GW des routes statiques vers mes réseaux inter-étages résoudra mes problèmes de connectivité. Je suis dans le bon ?

Le but de ma topologie est d'avoir toujours au moins deux routes possibles entre ma gateway et mes switchs d'accès. Ces derniers (entre 3 et 5 par étage) seront connectés à deux switchs de distribution, celui de l'étage et celui d'un étage contigu.

Après j'ai peut-être une vision un peu monolithique des réseaux rien qu'à l'évocation de vrf je suis un peu largué.

Merci encore pour ton aide.

[madmask]

L'ajout de routes statiques sur GW a réglé mes problèmes de connectivité. Le sujet est donc [RESOLU]. Je reste ouvert à toute suggestion ou remarques sur mon design.

A+ et merci.

Max

[Invité]

Madmask,

L'ajout de routes statiques sur GW a réglé mes problèmes de connectivité. Le sujet est donc [RESOLU]. Je reste ouvert à toute suggestion ou remarques sur mon design.

gardes bien en tête que ce genre de design offre une résilience limitée tout pendant que le "hub" ne peut pas collecter les routes de façon dynamique.

Reprenons le triangle suivant avec le réglage qui va bien au niveau de GW :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
            +----+.2   172.22.0.0/30
            | F0 |-------------------
            +----+                  |
               |.25                 |.1
               |                  +----+
172.22.0.24/30 |                  | GW | ip route 172.22.0.24 255.255.255.252 172.22.0.2
               |                  +----+
               |.26                 |.5
            +----+.6                |
            | F1 |-------------------
            +----+    172.22.0.4/30

Tu as alors connectivité IP totale.
So far so good.

En revanche, supposes que tu aies l'incident suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
            +----+
            | F0 |
            +----+
               |.25
               |                  +----+
172.22.0.24/30 |                  | GW | ip route 172.22.0.24 255.255.255.252 172.22.0.2
               |                  +----+
               |.26                 |.5
            +----+.6                |
            | F1 |-------------------
            +----+    172.22.0.4/30

alors GW ne pourra plus joindre le réseau 172.22.0.24/30 puisque 172.22.0.2 est down...

Donc dans ce type de design où le hub ne connait que le routage statique, il faudrait rajouter une 2ème route statique sur GW qui pointe vers un autre routeur d'étage. Ici, on pourrait par exemple configurer la chose suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
            +----+
            | F0 |
            +----+
               |.25
               |                  +----+ ip route 172.22.0.24 255.255.255.252 172.22.0.2
172.22.0.24/30 |                  | GW | ip route 172.22.0.24 255.255.255.252 172.22.0.4
               |                  +----+
               |.26                 |.5
            +----+.6                |
            | F1 |-------------------
            +----+    172.22.0.4/30

puisque tous les réseaux connectées sur les Fx sont propagés dans l'OSPF. Le trafic vers 172.22.0.24/30 se fera alors de façon automatique vers le lien GW-F1 (on appelle cette technique "polarisation de traffic en situation dégradée") . Reste plus qu'à croiser les doigts pour que les liens GW-F0 et GW-F1 ne soient pas down en même temps...

Mais ça veut dire qu'il va falloir configurer 5x2 routes statiques sur GW pour offrir ce minimum de résilience de pouvoir toujours joindre les interco entre les Fx...

Sans compter les autres réseaux IP d'utilisateurs directement connectés sur les Fx... Pour chacun d'eux, il faudrait faire la même chose. Donc supposes que tu aies 2 réseaux IP par Fx, ça ferait en tout 5x2 + 12x2 = 34 routes statiques...

GW est une passerelle vers l'extérieur.

Ca va nécessiter quelques coups de tournevis...

1) Toujours en considérant le triangle F0-GW-F1, tu peux déjà commencer à configurer par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
router ospf 1
  passive-interface fa0/0

En effet, ça n'a pas d'intérêt d'inonder fa0/0 d'OSPF Hello messages puisque tu ne monteras jamais d'adjacence OSPF au travers de ce segment.

2) Sur tous les Fx, tu dois configurer une default route, par exemple pour F0 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Router(conf)#ip route 0.0.0.0 0.0.0.0 172.22.0.1

puis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Router(conf)#router ospf 1
Router(conf-router)#default-information originate

de telle sorte que F0 annonce sa default route vers F1 sous forme Link State OSPF.

Ainsi, de façon nominale, F0 enverra son traffic par défaut vers 172.22.0.1.
Si le lien F0-GW est down, F0 utilisera une des default routes annoncées par un des Fx...

Encore une fois, c'est loin d'être simple quand le hub ne supporte que le routage statique...

Steph

[Miistik]

Bonjour,

Une question :
J'avais cru comprendre qu'on ne pouvait avoir qu'une seule route statique vers un réseau puisque la pondération des deux routes est alors identique.
Dans ces cas-là, EIGRP était un bon choix.
Right ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
            +----+
            | F0 |
            +----+
               |.25
               |                  +----+ ip route 172.22.0.24 255.255.255.252 172.22.0.2
172.22.0.24/30 |                  | GW | ip route 172.22.0.24 255.255.255.252 172.22.0.4
               |                  +----+
               |.26                 |.5
            +----+.6                |
            | F1 |-------------------
            +----+    172.22.0.4/30

[Invité]

Bonjour,

Une question :
J'avais cru comprendre qu'on ne pouvait avoir qu'une seule route statique vers un réseau puisque la pondération des deux routes est alors identique.
Dans ces cas-là, EIGRP était un bon choix.
Right ?

à pondération égale, un routeur effectue du load-balancing par session IP.

En revanche, je ne sais pas comment l'équipement GW gèrerait 2 routes statiques concurrentes... Il n'acceptera peut-être même pas la 2ème route
C'est donc un point de détail structurant à garder en tête pour madmask...

Steph

[madmask]

Bon cette appliance commence à me courir sur le haricot ... Les routes statiques concurrentes ne sont pas un problème c'est prévu. Par contre je n'ai pas 2 mais au minimum 4 réseaux IP par étage, si je ne dois pas créer de VLAN plus restreint pour un service quelconque. Le nombre de routes statiques va exploser ça va devenir une usine à gaz. Le point central de mes malheurs est que GW ne participe pas au process OSPF. Qu'à celà ne tienne je vais placer un routeur entre l'AXSGuard et ma dorsale pour me simplifier la vie.