VRF-Aware PAT in presenza concomitante di NVI, HSRP e Route Map (prima parte)

Last updated on December 4, 2021

Blog ITA - Post 5

Complexity [ scale of 1 to 5 ]
3/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 !!!