SDM template-ek Cisco switcheken

Meglehetősen könnyű olyan esetekbe belefutni Cisco switcheken, amelyek az SDM template módosítását igénylik, tipikusan ilyenek:

• 2960-ason statikus routolás (igen!)
• 3560-ason PBR
• 3560/3750-esen IPv6 routeolás

Túl sokat sosem gondolkodtam azon, mi ez az SDM, mindig megtettem, amit az éppen aktuális problémára vonatkozó Cisco útmutató írt, de sosem jártam alaposabban utána, hogy mi ez egészen pontosan. Természetesen semmi olyasmire nem kell gondolnunk, aminek az SDM GUI-hoz lenne köze, ebben a kontextusban az SDM jelentése: Switch Database Management, és a switchekben lévő CAM, illetve TCAM memóriák felhasználási módjait lehet beállítani vele.

A CAM vagyis Content Addressable Memory olyan jószág, amely a neki átadott adatot (switchnél MAC címet) keresi meg a memóriaterületen és visszatér azzal a címmel (switch esetén portindex) ahol egyezést talált. A RAM-ok épp fordítva működnek: az általunk megadott címről olvasunk ki adatot, és nem az adattal keressük ki a címet. A switchek a CAM memória segítségével tudják villámgyorsan, hardveresen megállapítani, hogy mely portjukra kell az adott cél MAC című keretet továbbítani.

A TCAM-ok, azaz  ternary, hármas CAM-ok a bináris CAM-októl eltérően, amelyek csak nullákat vagy egyeseket képesek tárolt adatként elfogadni, használnak egy harmadik, "nem számít" állapotot is az adat tárolása során. A TCAM ideális memóriatípus a például a route táblákban való keresések hardveres gyorsítására. Ha CPU-val végezzük a route táblában való keresést, akkor a cél IP-t össze kell ÉS-elgetni a route tábla minden egyes bejegyzéséhez tartozó maszkkal, majd az így megkapott hálózatcímet  összehasonlítani  az adott route bejegyzéssel, amíg egyezést nem találunk. A TCAM esetén a megfelelő biteket (a route tábla bejegyzéseinek host bitjeit) "nem számít" állapotban tárolva a továbbítandó csomag cél IP-je azonnal illeszkedik a megfelelő bejegyzésre, így nem kell minden egyes route tábla bejegyzéshez ÉS műveleteket majd egy összehasonlítást is elvégeztetni a CPU-val.

Ha a CAM megtelik egy switchben, akkor az eszköz nem tud új MAC címeket betanulni, így a még nem ismert eszközök MAC címeivel érkező kereteket minden portján továbbítani fogja, azaz floodolja. Ha a TCAM telik meg, akkor az újabb, a TCAM-be már nem férő route bejegyzések feldolgozása CPU-ból történik meg, ami jelentős terhelést ró az általában nem túl izmos switch CPU-ra. Minkét esetet érdemes elkerülni, ebben segít a Cisco switcheken az SDM template, hogy a rendelkezésre álló CAM és TCAM erőforrásokat az igényeinknek megfelelően, hatékonyan tudjuk a felhasználási területek közt szétosztani. Az ezzel kapcsolatos két legfontosabb parancs a "sh sdm prefer" enable módban, illetve az "sdm prefer" konfig módban. A template módosítás után mindig újra kell indítani az eszközt a beállítások érvényre jutásához.

DEVICE#show sdm prefer
 The current template is "desktop routing" template.
 The selected template optimizes the resources in
 the switch to support this level of features for
 8 routed interfaces and 1024 VLANs.

  number of unicast mac addresses:                  3K
  number of IPv4 IGMP groups + multicast routes:    1K
  number of IPv4 unicast routes:                    11K
    number of directly-connected IPv4 hosts:        3K
    number of indirect IPv4 routes:                 8K
  number of IPv4 policy based routing aces:         512
  number of IPv4/MAC qos aces:                      512
  number of IPv4/MAC security aces:                 1K

DEVICE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
DEVICE(config)#sdm prefer ?
  access              Access bias
  default             Default bias
  dual-ipv4-and-ipv6  Support both IPv4 and IPv6
  routing             Unicast bias
  vlan                VLAN bias

A poszt elején említettem, hogy az SDM template módosításával a Cisco 2960-asok is Layer3-as képességekkel ruházhatók fel, egy volt kollégám mutatta ezt kb. másfél éve. Csodákra azért ne számítsunk, a 2960-ason nem lesz se PBR, se dinamikus routeolás, statikus route-okból is csak max. 16 darab, kizárólag SVI interfésszel. Szoftverigény: legalább LANBASE 12.2.55 IOS.

Hogyan készüljünk fel hat nap alatt az IPv6 napra?

Régi kedvencem Ivan Pepelnjak szlovén kolléga, illetve ez így túlzás, hogy kolléga, hiszen ő több Cisco Press-es szakkönyv szerzője, igazi networkös veterán, és semmiképp sem állunk egy szinten. Mindenesetre a blogját szeretem olvasgatni, és a mai posztja egyértelműen olyan, ami szerintem a magyar szakmabeliek számára is tanulságos: hogyan tákoljunk össze valamit a soron következő IPv6 napra kevesebb mint egy hét alatt, ha a PR-esek hirtelen úgy döntenek, hogy részt kell vennünk a hype-ban?

Az Ivan posztjában belinkelt prezentációból a kedvencem az F5 Big-IP-s dolog, az F5-öt gondolom nem nagyon kell bemutatni, load balancer és data center interconnection témában igen otthonosan mozgó cégről van szó, akik mostanában elérhetővé tették fontos termékük, az F5 Big-IP Local Traffic Manager Virtual Editionjét (VE) VMware infrastruktúrára, és ebből a VE-ből elérhető egy trial kiadás (korlátozás: 90 nap, 1Mb/s áteresztőképesség).

No, az egészben az a lényeg, és ez az Iván által a túléléshez javasolt receptek egyike, hogy használjuk a Big-IP-t IPv6-to-IPv4 átalakításra. A rendszer egyébként képes load balancingra IPv6-ról IPv4-es szerverek felé is (nem akarok hülyeséget mondani, de mintha tavaly valamilyen előadáson hallottam volna, hogy a Facebook F5 Big-IP vasakkal biztosítja az IPv6-os jelenlétét). Szóval a VE trialt csak a meglévő IPv4 szerverek elé kell tenni, IPv6-on csatlakoztatni a publikus hálózathoz, majd a megfelelő AAAA rekordokat  felvenni DNS-ben még június 8-a előtt. Gányolás a legfölsőbb szinteken, lehet, hogy megért volna egy "legalja" címkét is :)

32 bitnél hosszabb IPv4 kompatibilis címek: A+P címzés

Az előző posztban hivatkozott egyik szerző, Steven M. Bellovin publikációi közt egy érdekes dologra akadtam: A better approach than carrier-grade-NAT. IPv4 exhaustion / IPv6 témakörben nagyjából mindenki arra számít, hogy előbb-utóbb, dual stackkel vagy anélkül, de megjelennek a Carrier Grade NAT-ok (CGN), azaz a szolgáltatók a saját hálózatukon közbeiktatnak egy NAT lépést, hogy minél kevesebb publikus IPv4 cím kerüljön közvetlenül felhasználóikhoz. Bár ez nem ördögtől való ötlet, azért annyira nem is kellemes dolog. Gondoljunk csak bele, hogy amikor egy NAT-on osztozunk esetleg több száz egyéb felhasználóval, milyen kérdések vetődhetnek fel:

• Limitált számú párhuzamos session nyitására lesz lehetőségünk, valószínűleg kevesebbre, mint CGN nélkül, hiszen a CGN eszközön rendelkezésre álló TCP/UDP portok száma számos felhasználó közt oszlik szét.
• Az UPnP, port forwarding (DNAT) felejtős, hacsak nem tudjuk meggyőzni a szolgáltatót, hogy nekünk ezt vagy azt a külső portot adja át fixen, ami lássuk be, nem túl valószínű.
• A CGN külső IP-je egy esetleges rossz belső CGN szomszédság miatt felkerülhet ilyen-olyan tiltólistákra.
• Nehéz kérdés a CGN esetén a nyomon követhetőség a végfelhasználóig, bár ez elsősorban nem az ügyfelek, hanem a szolgáltatók problémája, mindenesetre az ügyfelek megbízható azonosítása érdekében igen gyakori CGN NAT tábla mentésekre lenne szükség.

De vajon hogyan élhetnénk túl az IPv6 elterjedéséig hátralévő időszakot? Hogyan lehetne többet kihozni az IPv4-ből? Van-e jobb módszer a CGN-nél? Az belinkelt tanulmány szerzői azzal az ötlettel álltak elő 2008-ban, hogy ki lehetne bővíteni a IPv4 címtartományt bitek átcsoportosításával a TCP/UDP portszámokból. Ez lenne az address + port címzés (A+P), ahol a hálózati címbe beleszámítana a TCP vagy UDP forgalom multiplexelését lehetővé tevő portszám mező valahány bitje.

Az ötlet persze zseniális, de alapvetően patkolás, nem megoldás, és azon túl, hogy ez is igényel változásokat mind CPE oldalon, mind a szolgáltatói eszközökben, a legtöbb CGN-es kérdést nem tudja megoldani. Előrelépés egyedül a DNAT témában lenne, hiszen az A+P-vel minden végfelhasználóra juthatna valamekkora fix szeletke az átcsoportosított portszám bitektől függően, amellyel szabadon rendelkezhetnének. Ugyanakkor nem választhatnának akármilyen portot a kívülről elérhető szolgáltatások számára, hiszen az adott szolgáltatáshoz tartozó well-known portok egyáltalán nem biztos, hogy abba a szeletkébe esnek, ami az adott felhasználónak jutott.

Az A+P címzés inkább tűnik egy érdekes ötletnek, mint ténylegesen megvalósítható dolognak, jelzi ezt az is, hogy az elmúlt pár évben nem volt nagy visszhangja a javaslatnak, összességében mégis szórakoztató volt végiglapozgatni, ki gondolta volna, hogy IPv4 címzés témában még lehet újat mondani?

NAT444 dual stack modell az átálláshoz

Újabb modell az IPv6 átálláshoz, ami jelenleg nincs még fent a Wikipedián sem: NAT444. Persze annyira azért nem új (januári), és forradalmi dolgokat nem érdemes várni tőle, leginkább maga az elnevezés volt újdonság nekem még most, májusban is. Ahogy az is, hogy a NAT64 mintájára egyre több helyen lehet olvasni NAT44-ről is, ami nem más, mint a megszokott IPv4 NAT, aminek ugye mindkét oldalán IPv4-es címek vannak, innen a 44. No, a NAT444 lényegében ugyanez, csak kétszer: az IPv4-es csomagoknak két NAT táblán kell átküzdeniük magukat, az első a szolgáltató által biztosított IPv4/IPv6 dual stack végberendezés, a második pedig az LSN (Large Scale NAT) vagy más néven CGN (Carrier Grade NAT) eszköz a szolgáltatónál. Rendes NAT444-es ábra sem volt sehol, így rajzoltam egyet én:

Bár nincs belső információm a hazai szolgáltatóktól, azért szemernyi kétségem sincs afelől, hogy ebből a modellből az LSN/CGN rész előbb-utóbb meg fog valósulni az otthoni felhasználók számára, vagy akár olyasmit is elképzelhetőnek tartok, hogy a szolgáltatók drágábban adják majd az LSN/CGN nélküli előfizetéseket mint a szolgáltatói NAT-os és/vagy IPv6-os előfizetéseket. Ami viszont a dual stack végberendezések (SOHO router) tömeges elterjedéseset illeti, itt azért vannak kétségeim, évtizedes távlatban bizonyára reális lehet, hogy a felhasználók jelentős százalékánál megjelennek ilyen eszközök.

Visszatérve a NAT444-re: komoly hátránya, hogy viszonylag bonyolult CPE eszközre van szükség ahhoz, hogy a végfelhasználó hozzáférhessen mind az IPv4-es, mind IPv6-os erőforrásokhoz (ez az átmenet alatt az alapvető elvárás), ráadásul ehhez a végfelhasználó eszközein (PC, notebook, egyéb kütyük) is dual stack kell, hogy fusson.