Tag Archives: route-map

Configurație destination-based NAT realizată prin route-map-uri

Imaginativă un scenariu prin care o companie se interconectează cu rețeaua unuia din partenerii săi. Pentru siguranță interconectarea se face prin două circuite separate: unul de bază printr-un Layer 2 overlay peste MPLS și altul de backup printr-un circuit virtual peste o rețea Frame-Relay. Rețeaua companiei este ascunsă de parteneri printr-un serviciu NAT prin care pe de-o parte se exclude riscul suprapunerii spațiilor de adrese IP utilizate pe intern și pe de altă parte ține confidențial particularitățile de subnetare a rețelei companiei. In plus, partenerul își poate construi un sistem de protecție (e.g. prin liste de acces) prin care să permită accesul doar pentru adrese IP din spațiul adrese agreat pentru configurația NAT-ului. Configurația NAT-ului trebuie realizată în așa mod încât aceasta să transleze in adrese IP (inside global) din intervale care să depindă de circuitul activ la momentul translării. Fiecare circuit are rezervat câte un interval de adrese IP (pool) destinat translărilor NAT.

Ca să formalizez, in cele ce urmează vom modela o topologie cu următoarele particularități:

  • interconectare între companie și partener prin două circuite: (a) unul de bază prin L2 peste MPLS și (b) altul de rezervă printr-un PVC peste Frame Relay.
  • rețeaua companiei protejată prin NAT, fiecare circuit configurat cu pool de adrese NAT separat: (a) pentru MPLS NAT pe 32 IP-uri din subnet-ul: 172.31.5.0/27 și (b) pentru Frame Relay NAT 32 de IP-uri din subnet-ul: 172.31.5. 64/27. Funcție de circuitul activ: main sau back-up, NAT-ul va funcționa fie pe primul fie pe al doilea interval de IP-uri.
  • segmentul punct-la-punct MPLS se configurează cu adrese IP din 10.10.10.0/30 (.1 la companie)
  • segmentul PVC FR se configurează cu adrese IP din 10.10.10.4/30 (.5 la companie și .6  la partener)
  • circuitul Frame Relay folosește PVC cu: (a) DLCI 423 pe partea companiei și (b) DLCI 324 partener.
  • rețea utilizatori companie: 10.18.0.0/24 cu stație pentru test (client_companie) pe adresa: 10.18.0.20/24
  • rețea servere partener: 172.31.0.0/24 cu server pentru test (server_partener) pe adresă 172.31.0.10.

Pentru modelare vom folosi GNS3 într-o schemă ca cea de mai jos:

conditional_NAT_gns_topology

În schemă:

  • MPLS format pe două switch-uri ethernet sintetice (PE1/PE2), incluse in serie pentru a putea întrerupe circuitul fără ca interfețele să treacă in down.
  • Frame Relay pe switch FR sintetic (port 1 – DLCI 423, port 10 – DLCI 324)

În plus, pentru completeness, la configurația de routing și NAT pe deasupra vom configura pe routerul companiei o probă IP SLA pentru tracking-ul circuitului de bază și rută flotantă pentru failover automat pe circuitul de backup.

Configurație router R1 (companie)

Configurație interfețe FastEherenet1/0, Serial0/0, Serial0/0.423:

Configurație serviciu NAT pe două pool-uri de adrese IP

În care linkfr și linkmpls sunt pool-urile de adree IP destinate NAT-ului pentru circuitele MPLS și respectiv Frame Relay. Ceea ce face ca NAT-ul să depinde de destinație este utilizarea in comenzile ip nat inside a route-map-rilor rmfr si rmmpls care la rândul lor sunt asociate fiecare cu altă interfață, partea cu match in secvența de mai jos:

Pentru route tracking vom folosi o proba SLA bazată pe ICMP echo-request/replay la IP-ul interfeței de partea partenerului pentru circuitul MPLS:

Note: secvența de mai sus pentru IP SLA valabilă pentru versiunea de IOS folosită de mine în GNS3, alte versiuni au altă sintaxă.

În final configurăm rutele statice către rețeaua de servere parteneri. Vom folosi două rute: una dependentă de track-ul la proba IP SLA și alta ca back-up inclusă cu o metrică mai proastă (100):

track 10 face referință la proba ip-sla 10

Configurație router R2 (partener)

Pe partea partenerului minim de configurație. Interfețe:

și două rute statice câte una pentru fiecare interval (subnet) de IP-uri NAT:

Acum că avem configurate toate componentele topologiei, putem să incercăm câteva teste.

Testing and Troubleshooting

Vom verifica două scenarii, unul pentru regimul normal cu trafic peste circuitul de bază și altul pentru cazul când circuitul de bază se intrerupe și traficul se redirecționează automat pe circuitul de rezervă. In avele cazuri se va verifica tabelul translărolor NAT și câte un capturi de wireshark pe fiecare circuit.

Așadar, după ce ne convingem că ping-ul are loc cu succes de la client la server verificam tabelul translarilor NAT pe router-ul R1:

conditional_NAT_ip_nat_translation_main_circuit

se observă o translare NAT cu un IP (inside global) din intervalul rezervat circuitului de bază, fapt confirmat și prin captura Wireshark (pe interfața R1-F1/0)

conditional_NAT_capture_main_circuit

in captură, IP-ul sursa la pachetul cu ICMP request pleacă NAT-uit cu 172.31.5.2. Ce este interant captura include și pachetele periodice de ICMP pentru proba IP SLA (R1 – 10.10.10.1 la R2 – 10.10.10.2). Funcționarea track-ului pe proba IP-SLA o confirmăm cu următoarele comenzi:

conditional_NAT_SLA_tracking_normal_state

din output interesant de urmărit Number fo Failures care e zero pentru moment, statutul track-ului care e Reachability is Up și ruta către servere prin circuitul de bază (R1-F1/0).

Acum să incercăm să simulăm intreruperea circutului de bază și să observăm efectul. Vom intrerupe link-ul intre switch-urile PE1 si PE2. Verificăm statutul IP SLA:

conditional_NAT_SLA_tracking_backup_state

din care imediat observăm efectul: (a) Number of failures in proba IP SLA diferit de zero (b) track 10 cu statut Reachability is down și (c) rută peste segmentul de bază in down. Ruta către rețeaua de servere parteneri trece deacum prin circuitul de back-up:

conditional_NAT_route_over_backup

executăm un ping de la client la server, după care verificam tabelul translărilor NAT:

conditional_NAT_ip_nat_translation_backup_circuit

deja se observa o translare cu un IP (172.31.5.66) din intervalul rezervat circuitului de rezerva 172.31.5.64/27). Fapt confirmat și prin captura Wireshar pe interfața Serial0/0:

conditional_NAT_capture_backup_circuit

se observă respectivul IP-ul sursă pentru pachetele ICMP echo request (și encapsularea FR).

Cam asta pe azi. Dacă vă doriți să reproduceți scenariul puteți descărca fișierele de configurație pentru R1 și R2 de aici (link).