Last updated on December 4, 2021
Blog ITA - Post 5
Premessa
Continuando la nostra trattazione del NAT, alziamo l’asticella andando ad affrontare uno scenario che prevede la presenza concomitante di:
- VRF-Aware PAT (caso NVI)
- HSRP
- Route Maps
VRF-Aware Dynamic NAT ed HSRP
La feature VRF-Aware Dynamic NAT Mapping with HSRP supporta stateless redundancy utilizzando – in presenza di VRF – HSRP e Dynamic NAT/PAT.
Alcune considerazioni:
- la configurazione del NAT sui nodi Active e Standby deve essere identica
- alla luce della stateless redundancy, e’ possibile che – in caso di failover – i NAT-Translated IP address presenti nei due HSRP speaker differiscano gli uni dagli altri
- in caso di failover, tutte le traduzioni NAT vengono:
- rimosse dal nodo active originario (divenuto standby a seguito del failover)
- ricreate sul nuovo nodo active
VRF-Aware Dynamic NAT in presenza di Route Map
Il NAT fa ricorso a Route Map e/o ACL quando e’ necessario creare una translation entry:
CASO 1: Route Map
In questo caso, verra’ sempre creata una fully extended NAT translation entry contenente (nel caso si adottino le NVI):
- gli indirizzi IP source/destination local/global
- il campo Protocol (icmp, tcp, udp)
CASO 2: ACL (senza overload)
In questo caso, verra’ sempre creata una simple NAT translation entry contenente – nel caso si adottino le NVI – i soli indirizzi IP source local/global (in relazione alla direzione del flusso dati)
CASO 3: ACL (con overload)
In questo caso, verra’ sempre creata una fully extended NAT translation entry contenente (nel caso si adottino le NVI):
- gli indirizzi IP source/destination local/global
- il campo Protocol (icmp, tcp, udp)
Qualcuno potrebbe chiedersi: che differenza c’e’ tra CASO 1 e CASO 3?
La risposta e’ estremamente semplice: le route map sono in grado di matchare contemporaneamente piu’ elementi (che non siano il “banale” source IP address). Si pensi, a tal proposito, ai casi match interface o match ip next-hop. Vien da se’ che, in presenza di topologie multi-homed (verso lo stesso ISP o ISP distinti), l’uso delle route map offre un grado di flessibilita’ ineguagliabile.
Scenario 1
Il Customer C, a cui e’ stata assegnata la VRF C21, dispone di due Edge Router:
- R1: HSRP Active node
- R2: HSRP Standby node
Customer C ha la necessita’ di raggiungere due sedi remote, Site A e Site B, utilizzando IP pool differenti.
Nello specifico, e’ richiesto che gli host della subnet 192.0.2.0/24 appaiano come facenti parte del pool:
- 131.100.2.0/29, se diretti verso 203.0.2.100 (Site A)
- 131.200.2.0/29, se diretti verso 203.0.2.200 (Site B)
Configurazione
Configurazione di R1
vrf definition C21
rd 64501:4
!
address-family ipv4
exit-address-family
!
track 200 ip sla 20
!
interface GigabitEthernet0/0
description R1_LAN Customer C
vrf forwarding C21
ip address 192.0.2.2 255.255.255.0
no ip redirects
ip nat enable
standby version 2
standby 1 ip 192.0.2.254
standby 1 priority 150
standby 1 preempt
standby 1 track 200 decrement 90
!
interface GigabitEthernet0/3
description R1_WAN Customer C
vrf forwarding C21
ip address 198.51.100.1 255.255.255.252
ip nat enable
!
ip nat pool PoolA 131.100.2.1 131.100.2.6 prefix-length 29
ip nat pool PoolB 131.200.2.1 131.200.2.6 prefix-length 29
ip nat source route-map RMAP-100 pool PoolA vrf C21 overload
ip nat source route-map RMAP-200 pool PoolB vrf C21 overload
!
ip route vrf C21 0.0.0.0 0.0.0.0 GigabitEthernet0/3 198.51.100.2
!
ip access-list extended Cust_C_To_SiteA
permit ip 192.0.2.0 0.0.0.255 host 203.0.2.100
ip access-list extended Cust_C_To_SiteB
permit ip 192.0.2.0 0.0.0.255 host 203.0.2.200
!
ip sla auto discovery
ip sla 20
icmp-echo 203.0.2.1
vrf C21
frequency 5
ip sla schedule 20 life forever start-time now
!
route-map RMAP-200 permit 10
match ip address Cust_C_To_SiteB
!
route-map RMAP-100 permit 10
match ip address Cust_C_To_SiteA
!
Configurazione di R2
vrf definition C21
rd 64501:4
!
address-family ipv4
exit-address-family
!
interface GigabitEthernet0/0
description R2_LAN Customer C
vrf forwarding C21
ip address 192.0.2.3 255.255.255.0
no ip redirects
ip nat enable
standby version 2
standby 1 ip 192.0.2.254
standby 1 preempt
!
interface GigabitEthernet0/3
description R2_WAN Customer C
vrf forwarding C21
ip address 198.51.100.129 255.255.255.252
ip nat enable
!
ip nat pool PoolA 131.100.2.1 131.100.2.6 prefix-length 29
ip nat pool PoolB 131.200.2.1 131.200.2.6 prefix-length 29
ip nat source route-map RMAP-100 pool PoolA vrf C21 overload
ip nat source route-map RMAP-200 pool PoolB vrf C21 overload
!
ip route vrf C21 0.0.0.0 0.0.0.0 GigabitEthernet0/3 198.51.100.130
!
ip access-list extended Cust_C_To_SiteA
permit ip 192.0.2.0 0.0.0.255 host 203.0.2.100
ip access-list extended Cust_C_To_SiteB
permit ip 192.0.2.0 0.0.0.255 host 203.0.2.200
!
!
route-map RMAP-200 permit 10
match ip address Cust_C_To_SiteB
!
route-map RMAP-100 permit 10
match ip address Cust_C_To_SiteA
!
Analisi della Configurazione
Creazione della vrf C21
vrf definition C21
rd 64501:4
!
address-family ipv4
exit-address-family
Abilitazione di NVI e VRF sulle interfacce del router
interface GigabitEthernet0/0
vrf forwarding C21
ip nat enable
!
interface GigabitEthernet0/3
vrf forwarding C21
ip nat enable
Creazione delle Route Map
Sono state create due route map:
- RMAP-100: utilizzata quando Customer C deve raggiungere Site A
- RMAP-200: utilizzata quando Customer C deve raggiungere Site B
## Prima Route Map + ACL
route-map RMAP-100 permit 10
match ip address Cust_C_To_SiteA
!
ip access-list extended Cust_C_To_SiteA
permit ip 192.0.2.0 0.0.0.255 host 203.0.2.100
## Seconda Route Map + ACL
route-map RMAP-200 permit 10
match ip address Cust_C_To_SiteB
!
ip access-list extended Cust_C_To_SiteB
permit ip 192.0.2.0 0.0.0.255 host 203.0.2.200
Creazione degli IP Pool
Sono stati creati due IP Pool:
- PoolA [131.100.2.0/29]: utilizzato quando Customer C deve raggiungere Site A
- PoolB [131.200.2.0/29]: utilizzato quando Customer C deve raggiungere Site B
## Primo IP Pool
ip nat pool PoolA 131.100.2.1 131.100.2.6 prefix-length 29
## Secondo IP Pool
ip nat pool PoolB 131.200.2.1 131.200.2.6 prefix-length 29
Creazione del VRF-Aware PAT
ip nat source route-map RMAP-100 pool PoolA vrf C21 overload
ip nat source route-map RMAP-200 pool PoolB vrf C21 overload
Verifica sugli apparati
Come primo step, effettuiamo un ping test da PC1 verso gli indirizzi 203.0.2.100 (Site A) e 203.0.2.200 (Site B).
Al momento:
- R1 opera come HSRP Active node
- R1 ha in esecuzione il comando debug ip nat detailed
R1#show standby brief
Interface Grp Pri P State Active Standby Virtual IP
Gi0/0 1 150 P Active local 192.0.2.3 192.0.2.254
R1#debug ip nat detailed
IP NAT detailed debugging is on
Nell’output del debug, evidenzieremo:
- in blu: le transizioni legate all’echo request
- in rosso: le transizioni legate all’echo reply
## Ping verso Site A
R1#
*Dec 2 16:22:39.738: NAT: map match RMAP-100
< output omitted>
*Dec 2 16:22:39.738: NAT*: i: icmp (192.0.2.1, 16128) -> (203.0.2.100, 16128) [25815]
*Dec 2 16:22:39.738: NAT*: s=192.0.2.1->131.100.2.1, d=203.0.2.100 [25815]
*Dec 2 16:22:39.741: NAT: i: icmp (203.0.2.100, 16128) -> (131.100.2.1, 16128) [25815]
*Dec 2 16:22:39.742: NAT: s=203.0.2.100, d=131.100.2.1->192.0.2.1 [25815]
< output omitted>
## Ping verso Site B
R1#
*Dec 2 16:22:45.349: NAT: map match RMAP-200
< output omitted>
*Dec 2 16:22:45.349: NAT*: i: icmp (192.0.2.1, 16384) -> (203.0.2.200, 16384) [51246]
*Dec 2 16:22:45.349: NAT*: s=192.0.2.1->131.200.2.1, d=203.0.2.200 [51246]
*Dec 2 16:22:45.353: NAT: i: icmp (203.0.2.200, 16384) -> (131.200.2.1, 16384) [51246]
*Dec 2 16:22:45.353: NAT: s=203.0.2.200, d=131.200.2.1->192.0.2.1 [51246]
< output omitted>
R1#show ip nat nvi translations vrf C21
Pro Source global Source local Destin local Destin global
icmp 131.100.2.1:16128 192.0.2.1:16128 203.0.2.100:16128 203.0.2.100:16128
icmp 131.200.2.1:16384 192.0.2.1:16384 203.0.2.200:16384 203.0.2.200:16384
icmp 203.0.2.100:16128 203.0.2.100:16128 131.100.2.1:16128 192.0.2.1:16128
icmp 203.0.2.200:16384 203.0.2.200:16384 131.200.2.1:16384 192.0.2.1:16384
Come secondo step, forziamo il failover muovendo il traffico su R2 (nuovo HSRP Active node):
R2#show standby brief
Interface Grp Pri P State Active Standby Virtual IP
Gi0/0 1 100 P Active local 192.0.2.2 192.0.2.254
## Ping verso Site A
R2#
*Dec 2 16:32:29.608: NAT: map match RMAP-100
< output omitted >
*Dec 2 16:32:29.608: NAT*: i: icmp (192.0.2.1, 16640) -> (203.0.2.100, 16640) [22751]
*Dec 2 16:32:29.608: NAT*: s=192.0.2.1->131.100.2.1, d=203.0.2.100 [22751]
*Dec 2 16:32:29.612: NAT: i: icmp (203.0.2.100, 16640) -> (131.100.2.1, 16640) [22751]
*Dec 2 16:32:29.612: NAT: s=203.0.2.100, d=131.100.2.1->192.0.2.1 [22751]
< output omitted >
## Ping verso Site B
R2#
*Dec 2 16:32:36.326: NAT: map match RMAP-200
< output omitted >
*Dec 2 16:32:36.326: NAT*: i: icmp (192.0.2.1, 16896) -> (203.0.2.200, 16896) [54591]
*Dec 2 16:32:36.326: NAT*: s=192.0.2.1->131.200.2.1, d=203.0.2.200 [54591]
*Dec 2 16:32:36.329: NAT: i: icmp (203.0.2.200, 16896) -> (131.200.2.1, 16896) [54591]
*Dec 2 16:32:36.330: NAT: s=203.0.2.200, d=131.200.2.1->192.0.2.1 [54591]
< output omitted >
R2#show ip nat nvi translations vrf C21
Pro Source global Source local Destin local Destin global
icmp 131.100.2.1:16640 192.0.2.1:16640 203.0.2.100:16640 203.0.2.100:16640
icmp 131.200.2.1:16896 192.0.2.1:16896 203.0.2.200:16896 203.0.2.200:16896
icmp 203.0.2.100:16640 203.0.2.100:16640 131.100.2.1:16640 192.0.2.1:16640
icmp 203.0.2.200:16896 203.0.2.200:16896 131.200.2.1:16896 192.0.2.1:16896
Il prossimo articolo sara’ focalizzato sullo studio di un secondo scenario che prevede l’uso di NVI in presenza di flussi dati che necessitano il passaggio da una VRF ad un’altra.
Stay tuned !!!