Bevezetés az IWAN-ba

Tekintsük át az IWAN (2.0) alapjait, egyáltalán miért van rá szükség, mit tud nyújtani az ügyfeleknek.
A poszt alapja a Cisco Validated Design Zone publikációja (elérhető itt)

Távoli telephelyek jó esetben redundáns WAN kapcsolattal rendelkeznek a HQ felé (a HQ-nál alapnak veszem a redundanciát). Ebből lehet az egyik MPLS, a másik sima Internet kapcsolat, mindkettő MPLS, mindkettő internet, képbe jöhet akár még a 4G is. Az MPLS-ért vastag pénzt le kell szurkolni, cserébe nagy rendelkezésre állású, privát kapcsolatot kapunk. A “hagyományos” internet kapcsolat olcsóbb, de kisebb a rendelkezésre állása, magasabb a késleltetése, viszont tudunk titkosított forgalmat átvinni rajta megfelelő technológia használatával. Ez az egyik része a sztorinak. A másik, hogy hagyományos routing protokollokkal nem tudunk “intelligens” döntéseket hozni sávszélesség-kihasználtság, jitter, delay értékek alapján, csak costokkal tudunk dolgozni, csak costokkal, metric-ekkel. Ha adott forrás-cél irányt szeretnénk meghatározni active-active link használtság esetén, PBR-t kell használnunk.

És itt jön az IWAN (2.0) a képbe.

Négy fő pillére van:
1. DMVPN: bármilyen carrier felett felépíthető, egyszerű routing design-t tesz lehetővé. Lehetővé teszi a direkt spoke-to-spoke kommunikációt is (tehát a hubon nem megy át a forgalom). Támogatott a multicast is.

2. PfR: alkalmazás, performancia, policy alapján választja ki, melyik linken küldje az adatot, de szabályozható az is, hogy pl. kritikus adatok alapjában véve MPLS-en menjenek.

3. AVC/WAAS: alkalmazások optimalizációja a WAN-on. Mély forgalom analízist hajtanak végre, mert pl. a standard 80-as portot már túl sok program használja. Ezzel az új információval jobb QoS és PfR beállításokat tudunk eszközölni.

4. Security: IPSec titkosítás, ZBFW, tűzfalak

Szolgáltató-független WAN design

Mindegy, hogy MPLS, 4G, Internet, egyszerűen építünk felé IPSec VPN-t, és azon keresztül kommunikálunk. DMVPN + IPSec.
Két független szolgáltatót használunk, hogy a redundancia “garantált” legyen.

Biztonsági és egyéb okokból, a távoli telephelyeknek nem szokott direkt internet kapcsolata lenni, a hubon keresztülérik el az internetet.

WAN design-ok
1-IWAN Hybrid: MPLS + Internet
2-IWAN Dual Internet: két független internet szolgáltatót használunk
3-IWAN Dual MPLS

Mindhárom design esetén két HUB edge routerrel számolunk, amelyek CE routerek a szolgáltató szemszögéből, illetve VPN hun routerek a mi szemszögünkből.
1. IWAN Hybrid Design model
– 1 MPLS szolgáltató
– 1 internet szolgáltató
– Front VRF (FVRF) mindkettő kapcsolatra (control plane szeparáció és biztonsági okok miatt is), statikus 0/0 route a szolgáltatók felé.
figure3

Megjegyzés: MPLS esetében általában NEM, publikus internet esetében viszont általában tűzfal van a routerünk és a szolgáltató között.
2. WAN Dual Internet Design Model
– Két internet szolgáltató
– FVRF, statikus route-kkal a szolgáltató felé.

figure4
WAN Remote-Site Designs

figure5
QoS

table5

Per-Tunnel QoS a DMVPN-ben

Spoke-k felé külön QoS beállításokat tudunk használni. Hiába, hogy egy (mGRE) tunnelünk van a hub routeren, mégis tudunk spoke szinten QoS-t konfigurálni.

PfR-ben két router típus van:
BR (Border router): adatokat gyűjt, és küldi az MC-nek
MC (Master controller): döntéseket hoz

A két szerepkör konfigurálható egy routerre is.

A szükséges IOS-ek PfRv3-hoz:

Cisco ISR-G2 Series Routers – http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/pfrv3/configuration/15-mt/pfrv3-15-mt-book/pfrv3.html

Cisco IOS 15.5(1)T1 or later
Cisco IOS 15.4(3)M1 or later

És végül egy áttekintő ábra:

figure11-12

A képek forrása a már említett CVD dokumentum.