Firewall pomiedzy VRFami w multihomed

[piotro]

Moje pomysly na ten problem srednio mi sie podobaja poki co, wiec chetnie poslucham podpowiedzi.

Jest MPLS core pomiedzy dwoma DC, w obydwu ma dolaczone lokalne VRFy z zasobami, do ktorych chcemy dac dostep. Do tej sieci podlaczeni sa klienci (Ext). W przypadku kiedy maja lacza do obydwu DC, najczesciej BGP jest w uzyciu, w niektorych przypadkach lacza pracuja jako active/backup dla calego ruchu, w niektorych przypadkach ruch jest rozkladany pomiedzy laczami, tak aby najpierw uzywane bylo te, ktore jest blizej prefixu (DC).
Potrzeba wlozyc firewalla pomiedzy VRF gdzie Ext laduja (EXT_N) a VRF core, do tego jest ASA z contextami. Ilosc tych Ext jest wieksza niz liczba interfejsow na Asie (gdyby rozpatrywac tryb transparent), w przypadku routed mode - Lukasz od dawna powtarza, ze firewall to nie router ;), tak czy inaczej trzeba rozwiazac problem asymetrycznego ruchu (a wylacznie kontroli na ASIe to ostatecznosc), ktory moze powstac w pewnych kombinacjach lacz-prefixow-failovera.
Obydwa VRFy - Ext_N i Core sa na tym samym pudelku, Cat6500/Cat6800 (dwa takie pudelka w kazdym DC dla "resiliency").

[gangrena]

Moje pomysly na ten problem srednio mi sie podobaja poki co, wiec chetnie poslucham podpowiedzi.

Jest MPLS core pomiedzy dwoma DC, w obydwu ma dolaczone lokalne VRFy z zasobami, do ktorych chcemy dac dostep. Do tej sieci podlaczeni sa klienci (Ext). W przypadku kiedy maja lacza do obydwu DC, najczesciej BGP jest w uzyciu, w niektorych przypadkach lacza pracuja jako active/backup dla calego ruchu, w niektorych przypadkach ruch jest rozkladany pomiedzy laczami, tak aby najpierw uzywane bylo te, ktore jest blizej prefixu (DC).
Potrzeba wlozyc firewalla pomiedzy VRF gdzie Ext laduja (EXT_N) a VRF core, do tego jest ASA z contextami. Ilosc tych Ext jest wieksza niz liczba interfejsow na Asie (gdyby rozpatrywac tryb transparent), w przypadku routed mode - Lukasz od dawna powtarza, ze firewall to nie router , tak czy inaczej trzeba rozwiazac problem asymetrycznego ruchu (a wylacznie kontroli na ASIe to ostatecznosc), ktory moze powstac w pewnych kombinacjach lacz-prefixow-failovera.
Obydwa VRFy - Ext_N i Core sa na tym samym pudelku, Cat6500/Cat6800 (dwa takie pudelka w kazdym DC dla "resiliency").

Obrazek

Przede wszystkim rozwiązanie musi obsłużyć ruch asymetryczny, zatem firewalle muszą synchronizować stan sesji. Na ASA można użyć trybu failover active/standby, failover active/active lub klastrowania, gdzie mamy pełne active/active dla wszystkich VLAN-ów i kontekstów. Dla multi-context spanned-etherchannel można stosować tryb mieszany transparent/routed.

Firewall to nie router w tym znaczeniu, by zapewniać setki sesji OSPF/BGP oraz tysiące prefiksów IP, terminować tunele i dodatkowe enkapsulacje. Klaster w routed mode jest jak najbardziej stosowany. Czy routed, czy transparent mode zależy od kilku czynników. Np. czy FW ma dokonywać inspekcji East-West, czy tylko North-South? Czy będą uruchamiane dodatkowe funkcjonalności jak NAT? Dla SP z VRF preferowałbym raczej klaster w routed mode lub failover transparent/routed. Jeżeli trasy się dobrze agregują, to wystarczy static route. Przykład z życia wzięty:

[piotro]

Hej Piotrek,

Tyle, ze nie ciagnie mnie do rozpinania ASA clustra pomiedzy DC, z kilku powodow, do tego brak gwarancji na zapewnienie odpowiedniego poziomu latency dla CCL.
Rzecz w tym, ze kazde DC ma swoja pare kontekstowych ASA (de facto w jednym jest active/active, w drugim active/standby, ale to bez wiekszego znaczenia) i kombinuje jak zapewnic symetrycznosc ruchu pomiedzy DC z kontekstem w sciezce, z takim ukladem ASA.
Ten firewall jest tylko dla ruchu North-South, w niektorych kontekstach tylko ACLki, w niektorych ACL+NAT.

[gangrena]

Tyle, ze nie ciagnie mnie do rozpinania ASA clustra pomiedzy DC, z kilku powodow, do tego brak gwarancji na zapewnienie odpowiedniego poziomu latency dla CCL.
Rzecz w tym, ze kazde DC ma swoja pare kontekstowych ASA (de facto w jednym jest active/active, w drugim active/standby, ale to bez wiekszego znaczenia) i kombinuje jak zapewnic symetrycznosc ruchu pomiedzy DC z kontekstem w sciezce, z takim ukladem ASA.
Ten firewall jest tylko dla ruchu North-South, w niektorych kontekstach tylko ACLki, w niektorych ACL+NAT.

Jedynym sposobem na bezprzerwową i automatyczną obsługę ruchu stanowego jest klastrowanie. W każdej innej sytuacji trzeba liczyć się z utratą sesji przy przeroutowaniu ruchu na inne DC, co jest ok, jeżeli nie ma jakichś transakcji finansowych lub nie jest to problemem dla aplikacji. Można wysterować ruch tak, aby uniknąć asymetrii. Określone prefiksy zawsze by wchodziły jednym DC, a inne drugim, nawet jeżeli aktualnie aplikacje/front web jest w przeciwległym DC. Zapasowe rozgłoszenie z gorszą metryką czekałoby jako backup. Symetryczność zapewni też NAT.

Co do opóźnień w klastrowaniu ASA, to bym się nie przejmował. 300us szkody nie wyrządzi. Chyba, że odległość między DC jest taka, że odczuwalna będzie propagacja. Jednak to już nie wina klastrowania, a samą propagację trzeba wziąć pod uwagę przy dowolnym rozwiązaniu również z NAT. Bądź co bądź maszyna wirtualna może zostać przemieszczona do drugiego DC.

[piotro]

Jedynym sposobem na bezprzerwową i automatyczną obsługę ruchu stanowego jest klastrowanie. W każdej innej sytuacji trzeba liczyć się z utratą sesji przy przeroutowaniu ruchu na inne DC, co jest ok, jeżeli nie ma jakichś transakcji finansowych lub nie jest to problemem dla aplikacji. Można wysterować ruch tak, aby uniknąć asymetrii. Określone prefiksy zawsze by wchodziły jednym DC, a inne drugim, nawet jeżeli aktualnie aplikacje/front web jest w przeciwległym DC. Zapasowe rozgłoszenie z gorszą metryką czekałoby jako backup. Symetryczność zapewni też NAT.

Jak ruch wchodzi do DC nie jest problemem, problemem jest powrotny - aby uniknac asymetrii - i tu mam lekka zagwozdke ze znalezieniem eleganckiego rozwiazania i o pomysly na to mi chodzi (ale wiadomo, ze to sie tez laczy w calosc z tym jak ruch wchodzacy przyjmujemy). Np. wejsc moze do DC2, ale potem pojsc do DC1, w droge powrotna wyjsc z DC1 (bo najblizsze do src IP) i juz firewall uwali (a to tylko jedna z kombinacji jak ruch moze wejsc/wyjsc).
Utrata sesji przy failoverze sie malo martwie w tym przypadku, o ile routing sprawnie rozwiaze dostepnasc/failover i uniknie asymetrii.

[gangrena]

Jak ruch wchodzi do DC nie jest problemem, problemem jest powrotny - aby uniknac asymetrii - i tu mam lekka zagwozdke ze znalezieniem eleganckiego rozwiazania i o pomysly na to mi chodzi (ale wiadomo, ze to sie tez laczy w calosc z tym jak ruch wchodzacy przyjmujemy). Np. wejsc moze do DC2, ale potem pojsc do DC1, w droge powrotna wyjsc z DC1 (bo najblizsze do src IP) i juz firewall uwali (a to tylko jedna z kombinacji jak ruch moze wejsc/wyjsc).
Utrata sesji przy failoverze sie malo martwie w tym przypadku, o ile routing sprawnie rozwiaze dostepnasc/failover i uniknie asymetrii.

Jakim ruchem per prefix łatwiej sterować, wychodzącym, czy wchodzącym? W DC gdzie są switche sterowanie po IP jest trudniejsze. Rozwiązując problem ruchu wchodzącego nie będziesz musiał rozwiązywać problemu ruchu powrotnego. Jeżeli wiadomo, że aplikacja jest w DC1, to lepiej powiadomić WAN o tym fakcie rozgłaszając zdezagregowany prefix + zastosować default gateway w DC1. Problem asymetrii rozwiązany. Jest to prostsze, niż pozwolić ruchowi wejść np. DC2, a potem się martwić, żeby ponownie przez DC2 był poprowadzony ruch powrotny. Jeżeli jest link L3 między DC, to jest to do zrobienia. Jednak mniej prefiksów jest w DC. A tutaj mamy jeszcze tego samego właściciela WAN, który decyduje o ich widoczności, zatem łatwiej i lepiej rozgłaszać zdezagregowane trasy na zewnątrz, niż odwrotnie.

[piotro]

No wlasnie po to sa dwa lacza do dwoch DC, zeby ruch mogl sobie wejsc ktorymkolwiek (w specyficznych przypadkach, np. failover, albo external sobie znienacka zdecydowal wyslac ruch po drugim linku, i oby tez tez byl mily i zmienil AS prependa zeby nas powiadomic) i po laczu DC-DC dojsc do zasobow, ktore potrzebuje - co wymaga routingu dynamicznego dla ruchu powrotnego (statyczny, w ktoryms momencie spowoduje asymetrie).
Wszystko pieknie tylko problem sprowada sie do wymiany routingu dynamicznego pomiedzy zewnetrznym gosciem a corem - via firewall, it to taka wymiane, ktora zachowala by metryki/preferencje sciezki. W tym przypadku chyba sprowadzac sie to bedzie (niestyty) do uzycia ASY jako routera pomiedzy dwoma VRFami, co nadal pozostawia kilka problemow do rozwiazania.

[gangrena]

No wlasnie po to sa dwa lacza do dwoch DC, zeby ruch mogl sobie wejsc ktorymkolwiek (w specyficznych przypadkach, np. failover, albo external sobie znienacka zdecydowal wyslac ruch po drugim linku, i oby tez tez byl mily i zmienil AS prependa zeby nas powiadomic) i po laczu DC-DC dojsc do zasobow, ktore potrzebuje - co wymaga routingu dynamicznego dla ruchu powrotnego (statyczny, w ktoryms momencie spowoduje asymetrie).
Wszystko pieknie tylko problem sprowada sie do wymiany routingu dynamicznego pomiedzy zewnetrznym gosciem a corem - via firewall, it to taka wymiane, ktora zachowala by metryki/preferencje sciezki. W tym przypadku chyba sprowadzac sie to bedzie (niestyty) do uzycia ASY jako routera pomiedzy dwoma VRFami, co nadal pozostawia kilka problemow do rozwiazania.

Powiedziałbym raczej, że po to są dwa łącza do DC, aby ruch wszedł w sposób optymalny i aby zapewnić redundancję na wypadek awarii. Wydaje mi się, że patrzysz na problem asymetrii od wnętrza DC. Jest to trudniejsze do rozwiązania, gdyż zazwyczaj funkcjonuje default gw bez tras szczegółowych. Nie jest też skalowalne kierowanie ruchu per prefix na zewnątrz. Bardziej skalowalne jest sterowanie ruchem wejściowym. Nadal w takim przypadku można korzystać z dwóch lub więcej łączy, tylko per destination, a nie per flow dst-src. Odnośnie trybu FW, to nie musi to być tryb routed. Wymiana routingu przez transparent ASA będzie działać. Co u Ciebie w DC jest default GW? Para urządzeń w vPC/VSS, HSRP na routerach, jakiś dodatkowy FW?