Echanger des routes entre plusieurs VRF

août 27, 2015  |   Actualités,Blog   |     |   0 commentaire

Introduction

Pour des raisons de cout, de flexibilité et/ou de maintenance, il est parfois nécessaire de réduire le nombre d’équipement sur un site et conduit parfois à mixer plusieurs contexte sécuritaire.

Dans ce cas, il se peut donc qu’un même routeur dispose d’interface sur un réseau de DATA et un réseau de vidéosurveillance par exemple mais nous ne souhaitons surtout pas que les utilisateurs du réseau de data puisse aller visionner le flux vidéo. Nous allons alors voir dans cette article comment assurer la séparation des flux traversant un même routeur.

Description du besoin

Pour cet article, considérons alors une topologie telle que définie sur le schéma ci-dessous avec un réseau en datacenter et un site satellite de l’entreprise relié via une liaison routée. Le besoin est d’embarquer le moins d’équipement IT que possible sur les satellites afin de permettre un déploiement rapide. Les applications et le stockage de la vidéosurveillance se situent au datacenter :

BGP VRF 4Comme nous pouvons le constater sur le schéma ci-dessus, si nous ajoutons simplement les routes sur le routeur, il sera alors possible au réseau interne distant d’accèder aussi bien au datacenter qu’au réseau de video surveillance.

Nous souhaitons donc réduire ces accès au niveau du routage des flux. Pour ce faire, nous allons utiliser deux notions :

  • La notion de VRF (Virtual Routing/Forwarding) afin de créer nos différentes “zones de routage”
  • Une instance BGP locale afin de distribuer les routes uniquement là ou elles seront nécéssaires.

Nous segmentons donc le réseau de la façon suivante :

BGP VRF 4

Configuration

Nous allons maintenant passer à la configuration de ce routeur :

Commençons alors par déclarer nos VRFs ainsi que les IPs sur nos interfaces :

N’utilisant pas ici de MPLS, nous choisissons des route-distinguishers qui seront simples à utiliser dans nos imports/exports (10: INTERNAL, 20: DC, 30: SECURITY).

ip vrf INTERNAL
rd 10:10
import map BGP-to-INTERNAL
route-target export 10:10
route-target import 20:20
!
ip vrf DC
rd 20:20
import map BGP-to-DC
route-target export 20:20
route-target import 10:10
route-target import 30:30
!
ip vrf SECURITY
rd 30:30
import map BGP-to-SECURITY
route-target export 30:30
route-target import 20:20
!
interface fa0/0
description VLAN vers RESEAU INTERNE
ip vrf forwarding INTERNAL
ip address 10.0.0.1 255.255.255.0
!
interface s0/0
description VLAN vers DC
ip vrf forwarding PARTNER
ip address 10.10.0.1 255.255.255.0
!
interface fa0/1
description VLAN vers SECURITE
ip vrf forwarding SHARED
ip address 172.24.0.1 255.255.255.0

A ce niveau, chaque interface est isolée dans une VRF différente. Elles ne peuvent donc pas communiquer entre elles :

RTR-1#sho ip route vrf *         
[...]
Routing Table: INTERNAL
[...]

    10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, FastEthernet0/0

Routing Table: DC
[...]
    10.0.0.0/24 is subnetted, 1 subnets
C       10.10.0.0 is directly connected, Serial0/0

Routing Table: SECURITY
[...]
    172.24.0.0/24 is subnetted, 1 subnets
C       172.24.0.0 is directly connected, FastEthernet0/1

Nous allons alors créer les différentes listes afin pouvoir réguler les echanges de routes entre les VRFs:

ip prefix-list BGP-to-DC seq 5 permit 172.24.0.0/24
!
ip prefix-list BGP-to-INTERNAL seq 5 permit 10.10.0.0/24
!
ip prefix-list BGP-to-SECURITY seq 5 permit 10.10.0.0/24
!
ip prefix-list INTERNAL-to-BGP seq 5 permit 10.0.0.0/24
!
ip prefix-list DC-to-BGP seq 5 permit 10.10.0.0/24
!
ip prefix-list SECURITY-to-BGP seq 5 permit 172.24.0.0/24
!
route-map BGP-to-DC permit 10
match ip address prefix-list BGP-to-PARTNER
!
route-map BGP-to-INTERNAL permit 10
match ip address prefix-list BGP-to-INTERNAL
!
route-map BGP-to-SECURITY permit 10
match ip address prefix-list BGP-to-SHARED
!
route-map DC-to-BGP permit 10
match ip address prefix-list PARTNER-to-BGP
!
route-map INTERNAL-to-BGP permit 10
match ip address prefix-list INTERNAL-to-BGP
!
route-map SECURITY-to-BGP permit 10
match ip address prefix-list SHARED-to-BGP

Maintenant que les échanges de routes sont bien cadrés, nous pouvons mettre en place notre BGP :

router bgp 100
address-family ipv4 vrf INTERNAL
 redistribute connected route-map INTERNAL-to-BGP
exit-address-family
!
address-family ipv4 vrf DC
 redistribute connected route-map PARTNER-to-BGP
exit-address-family
address-family ipv4 vrf SECURITY
 redistribute connected route-map SHARED-to-BGP
exit-address-family
!

Dès lors, nos échanges BGP commencent, et nous pouvons observer après quelques secondes la bonne distribution des routes :

RTR-1#sho ip route vrf *
Routing Table: INTERNAL
[...]
    10.10.0.0/24 is subnetted, 2 subnets
C       10.0.0.0 is directly connected, FastEthernet0/0
B       10.10.0.0 is directly connected, 00:03:00, Serial0/0

Routing Table: DC
[...]
    172.24.0.0/24 is subnetted, 1 subnets
B       172.24.0.0 is directly connected, 00:00:56, FastEthernet0/1
    10.0.0.0/24 is subnetted, 2 subnets
B       10.0.0.0 is directly connected, 00:03:00, FastEthernet0/0
C       10.10.0.0 is directly connected, Serial0/0

Routing Table: SECURITY
[...]
    172.24.0.0/24 is subnetted, 1 subnets
C       172.24.0.0 is directly connected, FastEthernet0/1
    10.0.0.0/24 is subnetted, 1 subnets
B       10.10.0.0 is directly connected, 00:03:00, Serial0/0

Nous observons donc ici que :

  • La VRF “INTERNAL” ne dispose pas de la route vers le réseau de vidéosurveillance
  • La VRF “SECURITY” ne dispose pas de la route vers le réseau interne
  • Tous les réseaux distants peuvent aller vers le datacenter
  • Les routes externes aux VRFs sont bien apprises en BGP

Il est possible d’observer la syntheses des routes echangées par cette architecture via la commande :

RTR-1#sho ip bgp vpnv4 all
BGP table version is 11, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 10:10 (default for vrf INTERNAL)
*> 10.0.0.0/24      0.0.0.0                  0         32768 ?
*> 10.10.0.0/24     0.0.0.0                  0         32768 ?
Route Distinguisher: 11:11 (default for vrf DC)
*> 10.0.0.0/24      0.0.0.0                  0         32768 ?
*> 10.10.0.0/24     0.0.0.0                  0         32768 ?
*> 172.24.0.0/24    0.0.0.0                  0         32768 ?
Route Distinguisher: 20:20 (default for vrf SECURITY)
*> 10.10.0.0/24     0.0.0.0                  0         32768 ?
*> 172.24.0.0/24    0.0.0.0                  0         32768 ?

Nous pouvons alors réaliser les tests de connexion depuis le réseau du site distant:

RTR-DC#conf t
RTR-DC(config)#ip route 172.24.0.0 255.255.255.0 10.10.0.1
RTR-DC(config)#exit
RTR-DC#ping 172.24.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.24.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/8 ms

De plus, vérifions que nous parvenons pas à joindre le réseau interne en paramétrant une route par défaut :

RTR-DC#conf t
RTR-DC(config)#ip route 0.0.0.0 0.0.0.0 10.10.0.1
RTR-DC(config)#exit
RTR-DC#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:
U.U.U
Success rate is 0 percent (0/5)

 

Conclusion

Nous venons de mettre en place une architecture qui permet de mutualiser un routeur en séparant les domaines de routage grace à des VRFs. Nous avons ensuite ajouter une instance BGP afin de redistribuer les routes souhaitées via des prefix-list de manière simple tout en pouvant selectionner les routes une à une.

Note : Dans ce laboratoire, nous ne redistribuons que des routes connectées, il est tout a fait possible d’utiliser le même procédé pour échanger des routes statiques ou apprises par OSPF par exemple.

 

Bibliographie

http://www.frameip.com/mpls-cisco/#4.4.1_-_Notion_de_RD_(Route_Distinguisher)

http://www.cisco.com/web/FR/documents/pdfs/newsletter/ciscomag/2010/01/ciscomag_30__virtualization-segmentation.pdf