Palo Alto - LACP konfigurace

13.08.2021 | Tag Palo Alto

Agregace linek je skvělá pro zajištění redundance. Pokud jedna linka odpadne, velmi rychle ji zastoupí další. V článku chci ukázat, jak něco takového nastavit mezi Palo Alto boxem a Cisco switchem.

Agregací linek se získá již zmíněná redundance, kdy při výpadku jedné fyzické linky provoz putuje po dalších linkách v rámci LAGu (link aggregation). Dále je to navýšení propustnosti díky load balancingu mezi aktivními linkami. Agregovat je možné pouze linky o stejné propustnosti a stejného typu (nikoliv však média). Je tedy možné smíchat optiku s metalikou, ale jen za předpokladu, že mají obě stejnou rychlost a jsou obě buď L2, nebo L3. Dále musí mít linky stejnou konfiguraci.

Agregace linek je definována protokolem 802.1AX. Nadstavbou je pak LACP (mimo jiných one vendor show protokolů jako třeba PAgP od Cisco), což je vendorově nezávislý protokol přidávající automatickou detekci chyb a kontrolu konfigurace. Tzn. bez LACP je také možné nastavit agregaci. V tu chvíli však svázané linky reagují jen na chyby typu úplně vypadlý spoj. Stejně tak neověřují konfiguraci protistrany. LACP přidává něco navíc. Boxy si u LACP vyměňují kontrolní rámce a zjišťují tak stav protistrany.

Pro Cisco i Palo Alto myslím platí, že maximální počet aktivních linek v agregaci je 8, další by byly jako backup. Reálně jsem ale nikdy tak velký LAG neviděla. Každá fyzická linka pak může být začleněna pouze do jedné agregace.

Před tím, než začnu kecat o samotné konfiguraci, bude dobré zmínit její účel. V příkladu níže vytvářím mezi Palo Alto boxem a Cisco switchem agregovaný trunk propoj, protože v tomto případě mi Palo Alto poslouží jako router mezi jednotlivými VLAN na switchi (router na tyčce, dá se říct). Z pohledu bezpečnosti – protože Palo routuje jednotlivé VLAN, vidí do vzájemné komunikace a může ji kontrolovat. Agregace linek je pak pro mě ochrana na fyzické úrovni, kdy se pojede dál, i kdyby jedna linka z nějakého důvodu vypadla.

Začneme konfigurací na straně Cisco switche. Virtuální spoj, tedy agregace se na Cisco vytváří pomocí příkazu interface port-channel a čísla přiděleného agregaci (protože takových agregací může být na jednom boxu několik, liší se právě v čísle). Zkrácený zápis by mohl být int po1 a switch to pochopí stejně. Další konfigurace se týká trunku a STP.

Na straně fyzických portů se členství v LAG nastaví pomocí channel-group 1 mode active. Mode active říká, že port má použít LACP v aktivním režimu, tedy že vyjednává spojení.

S tím LACP módem je to takové ošemetné. V tomto případě, tedy Palo – Cisco, se musí zachovat logika, kdy je jedna strana aktivní a druhá pasivní. V našem případě je tedy aktivní Cisco a Palo bude pasivně poslouchat. Pokud by obě strany byly aktivní, fungovat to nebude. Naproti tomu Cisco – Cisco kombinace je prý lepší aktivní na obou stranách.

Chtěla bych sem vecpat takový trik (pro někoho možná jasná věc :)). Jakmile už jsou fyzické porty členy LAG, dědí si veškerou konfiguraci z virtuálního interface (zde třeba z port channel 1). Při tvoření Cisco LAGu je tedy nesmírně pohodlné vytvořit virtuální interface bez konfigurace, začlenit do něj fyzické interface a pak se ke konfiguraci virtuálního interface vrátit a donastavit ho dle potřeby (zde třeba jde o konfiguraci STP a trunku). Fyzické porty si vše tak 1:1 samy zdědí a není třeba to datlovat ručně. Jakákoliv změna se pak také dělá na úrovni virtuálního interface, protože se propálí na všechny členské porty.

Na straně Palo Alto se v GUI dostaneme přes Network – Interfaces na první kartu Ethernet. Zde je pod výpisem fyzických portů plusko s popisem Add Aggregate Group. Přes něj vytvoříme nový LAG.

Protože později nad tímto agregátem budeme vytvářet L3 subinterface, krom LACP nebudeme nic konfigurovat. V jiném případě by se rovnou nastavil i zbytek atributů pro Layer 3. Pod kartou LACP ho zapneme. Mód necháme pasivní, protože switch jsme dříve nastavili jako aktivní. Do Transmission Rate a Fast Failover bych osobně zasahovala v případě, kdy bych při přepadu linek fakt hrála o vteřiny. Transmission Rate definuje interval, kdy si boxy vyměňují kontrolní zprávy. Slow je každých 30 vteřin, fast je každou vteřinu. Dříve nižší řady Cisco switchů fast neuměly, ale co jsem se nedávno dívala, třeba u 2960X možnost fast transmission rate je. Fast Failover by měl zrychlit přepad oproti 802.1AX standardu, ale jak jsem psala, default je většinou safe way, pokud se nehraje o co nejkratší možnou dobu výpadku.

O LACP prioritě se zmiňuji níže u portů, ale pro doplnění – priority se nastavují na úrovni interface a na úrovni systému. Pokud priority nesedí na úrovni interface, peer s nižší hodnotou priority systému rozhoduje, které linky budou aktivní. To vše platí ve chvíli, kdy se objeví více linek než LAG podporuje. Jak píšu i níže, do priorit jsem nikdy neměla důvod zasahovat. Pomocí Maximum Interfaces se dá přiškrtit maximální počet aktivních linek, další by byly jako backup.

Po odklepnutí se ve výpisu interface objeví nově vytvořený LAG, který si říká ae1 a je typu Layer3 (opět, protože v této konfiguraci Palo bude sloužit jako router). Ve features je vidět ikonka bůhvíčeho, což má symbolizovat zapnuté LACP.

Po vytvoření LAG je možné do něj přiřadit fyzické interface. Zde to budou porty 1/19 a 1/20. Konfigurace bude pro oba interface shodná – v Interface Type se zvolí Aggregate Ethernet a následně v Aggregate Group se vybere nově vytvořená ae1. S LACP prioritou jsem si popravdě nikdy nehrála. Mělo by na ni dojít ve chvíli, kdy počet linek v LAGu převyšuje podporované maximum. Tehdy se pomocí priority rozhoduje, která linka bude aktivní a která backup.

Po nastavení obou interface to ve výpisu bude vypadat nějak takto.

Další nastavení už není pro samotné LACP nijak podstatné, ale ať dotáhneme myšlenku routeru na tyčce. Nad nově vytvořeným ae interface můžeme vytvořit subinterface pro jednotlivé VLAN, kterým má Palo sloužit jako router. Proto samotný ae interface nemá žádnou L3 konfiguraci, budou ji mít subinterface.

Po klepnutí na ae1 se pod výpisem interface zpřístupní položka Add Subinterface. Je to asi zřejmé, ale subinterface lze vytvářet jen pod fyzickým interface (nebo agregátem) nastaveným jako Layer3.

Velmi podstatná je položka Tag, která vlastně definuje přiřazení k VLAN. Zde je to 1, tedy VLAN 1. Dále se nastavuje přiřazení k virtuálnímu routeru a security zóně.

Asi jasné. Nastavení IP adresy tohoto subinteface, což bude nakonec gateway pro VLAN 1.

Poslední krok je na zvážení každého admina. Přiřazením předem vytvořeného management profilu, který povoluje jen ping, umožňuju na tomto subinterface přijímat ICMP. Většinou se mi to hodí pro debug, kdy pingem ověřím, že je pro ten subnet gateway dostupná.

Po nastavení všech částí a potvrzení se ve výpisu pod ae objeví nový subinterface, zde pro VLAN 1. Takhle můžeme přidávat dál a dál pro všechny VLAN, které je třeba routovat.

Tím bychom mohli skončit. Nakonec je potřeba konfiguraci aplikovat přes Commit. Při testech LAG mi vyšlo, že po vypojení jedné linky provoz v řádu vteřin převzala druhá linka. Při kontinuálním pingu to byl výpadek možná dvou tří paketů a jelo se dál.