routing + riverbed
routing + riverbed
Witam,
Ilestam biur jest podlaczonych poprzez VPNy do biura X. Biuro to jak widac na diagramie ma redundantny setup z dwoma Steelheadami/routerami i core switchami. Traffic leci przez urzadzenia o numerze 1 a w przypadku awarii przez urz, nr. 2. Niestety mamy od jakiegos czasu problemy z riverbedami. Mianowicie juz 2 razy mielismy przypadek ze optimization service dal ciala i raz ruch TCP byl kompletnie blokowany a za drugim razem ruch po osiagniaciu pewnej ilosci sesji, zadne nowe sesje nie byly przepuszczane. W obydwo przypadkach riverbed zalamuje rece i slyszymy cos o odosobnionym przypadku i zbyt duzej ilosci ruchu...
Pytanie, jak to skonfigurowac zeby routery "zrozumialy" ze cos sie pierdzieli i same przeroutowaly ruch.
Pomysl mam taki:
- dodac switcha (prawdopodobnie 2) miedzy routerami a steelheadami zeby kazdy router mogl forwardowac traffic przez oba steelheady
- dodac po routerze miedzye steelheadami a core switchami (niestety switche nie-ciscove wiec nie wspieraja tcp sla)
- odpalic TCP SLA i w przypadku gubienia pakietow re-route trafficu na drugiego riverbeda
Co o ty myslicie ?:)
Ilestam biur jest podlaczonych poprzez VPNy do biura X. Biuro to jak widac na diagramie ma redundantny setup z dwoma Steelheadami/routerami i core switchami. Traffic leci przez urzadzenia o numerze 1 a w przypadku awarii przez urz, nr. 2. Niestety mamy od jakiegos czasu problemy z riverbedami. Mianowicie juz 2 razy mielismy przypadek ze optimization service dal ciala i raz ruch TCP byl kompletnie blokowany a za drugim razem ruch po osiagniaciu pewnej ilosci sesji, zadne nowe sesje nie byly przepuszczane. W obydwo przypadkach riverbed zalamuje rece i slyszymy cos o odosobnionym przypadku i zbyt duzej ilosci ruchu...
Pytanie, jak to skonfigurowac zeby routery "zrozumialy" ze cos sie pierdzieli i same przeroutowaly ruch.
Pomysl mam taki:
- dodac switcha (prawdopodobnie 2) miedzy routerami a steelheadami zeby kazdy router mogl forwardowac traffic przez oba steelheady
- dodac po routerze miedzye steelheadami a core switchami (niestety switche nie-ciscove wiec nie wspieraja tcp sla)
- odpalic TCP SLA i w przypadku gubienia pakietow re-route trafficu na drugiego riverbeda
Co o ty myslicie ?:)
Opcja linków skrośnych, IP SLA, etc oczywiście ma szanse zadziałać, ale będzie to "niezła" rzeźba. Napisz coś więcej o tym co jest teraz, gdzie jest L2, a gdzie L3, jaki sprzęt jest użyty, etc to może ktoś zasugeruje coś konkretniejszego.
No i niezapomnij wspomnieć o tym jaki masz budżet na te zmiany, bo może okazać się, że bez inwestycji, to się nie da osiągnąć zbyt wiele.
Bez względu na wybraną opcję obejścia problemu, ciśnij support Riverbed, bo to nie jest normalne zachowanie sprzętu.
No i niezapomnij wspomnieć o tym jaki masz budżet na te zmiany, bo może okazać się, że bez inwestycji, to się nie da osiągnąć zbyt wiele.
Bez względu na wybraną opcję obejścia problemu, ciśnij support Riverbed, bo to nie jest normalne zachowanie sprzętu.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe."
A. Einstein
A. Einstein
Rysic, blad poprawiaja, kaza restartowac urzadzenie i dziala, przez pare miesiecy...
Wydawalo mi sie ze Steelhead`y sa najlepsze pod wzgledem optymalizacji.
Seba, wszedzie jest L3, core switche routuja miedzy lokalnymi subnetami, a dostep do netu i do wszystkich zdalnych sieci leci przez routery.
Co do sprzetu:
routery - cisco 3945
switche - HP J8698A
Co do budzetu to kasa jest, jak rozwiazanie bedzie niezawodne to dam rade przepchnac temat. Niestety wymiana switchy/Steelheadow nie wchodzi w gre, za duzo kosztowaly i niedawno byly kupowane, ale mozna troche sprzetu dodac.
Przez weekend o tym myslalem i moze nie trzeba dodawac nowych routerow, po prostu bym polecial SLA TCP miedzy routerami po LANie i jak pakiety przestana dochodzic to skrypt EEM zmieni priorytet HSRP na interfejsie LAN na R1. Jezeli zas chodzi o traffic wchodzacy to mozna dac link miedzy routerami i tam bezposrednio routowac ruch jak TCP SLA nie dojdzie.
Myslalem jeszcze nad skonfigurowaniem BGP na obu routerach, ale jako ze switche tego nie wspieraja to musialbym dorzucic jednak jeszcze po 2 routerach...
Wydawalo mi sie ze Steelhead`y sa najlepsze pod wzgledem optymalizacji.
Seba, wszedzie jest L3, core switche routuja miedzy lokalnymi subnetami, a dostep do netu i do wszystkich zdalnych sieci leci przez routery.
Co do sprzetu:
routery - cisco 3945
switche - HP J8698A
Co do budzetu to kasa jest, jak rozwiazanie bedzie niezawodne to dam rade przepchnac temat. Niestety wymiana switchy/Steelheadow nie wchodzi w gre, za duzo kosztowaly i niedawno byly kupowane, ale mozna troche sprzetu dodac.
Przez weekend o tym myslalem i moze nie trzeba dodawac nowych routerow, po prostu bym polecial SLA TCP miedzy routerami po LANie i jak pakiety przestana dochodzic to skrypt EEM zmieni priorytet HSRP na interfejsie LAN na R1. Jezeli zas chodzi o traffic wchodzacy to mozna dac link miedzy routerami i tam bezposrednio routowac ruch jak TCP SLA nie dojdzie.
Myslalem jeszcze nad skonfigurowaniem BGP na obu routerach, ale jako ze switche tego nie wspieraja to musialbym dorzucic jednak jeszcze po 2 routerach...
Niestety i ja spotykam problemy z supportem riverbeda (świadczonego przez resellera). Same steelheady bardzo chwalę, przy dobrej konfiguracji są niezawodne i bardzo mocno ograniczają ruch WAN (u nas średnio o 78%), więc warto ich używać
Odnośnie problemu:
1. Czy steelheady działają w klastrze?
2. Routery są dość mocne, więc podejrzewam że i steelheady to wersje rackowe..
Czy SH mają dwie pary interfejsów in-path?
3. Czy są podpięte pod CMC?
Odnośnie problemu:
1. Czy steelheady działają w klastrze?
2. Routery są dość mocne, więc podejrzewam że i steelheady to wersje rackowe..
Czy SH mają dwie pary interfejsów in-path?
3. Czy są podpięte pod CMC?
To ja się boję co robią firmy, które nie są najlepsze w tej branży...Wujek pisze:Rysic, blad poprawiaja, kaza restartowac urzadzenie i dziala, przez pare miesiecy...
Wydawalo mi sie ze Steelhead`y sa najlepsze pod wzgledem optymalizacji.
Ja przeliczyłem ostatnio ile byśmy zaoszczędzili posiadając dwukrotnie szybsze łącza nie kupując Riverbedów i ich licencji. Suma była dość spora, ale że ktoś musi ciągnąć sobie proket... to muszą zostać...
Ale już nie odbiegam od tematu. Sorru za offtop.
Jeżeli masz rozległą infrastrukturę WAN oraz spore opóźnienie pomiędzy oddziałami, a w sieci używasz "gadatliwych aplikacji" to samo zwiększenie łącza nie zapewni Ci szybszego działania tych aplikacji. Jedną z zalet Riverbedów jest właśnie eliminacja dużej ilości informacji jaka jest wymieniana pomiędzy oddziałem i centralą przez te aplikacje, ponieważ urządzenia lokalnie emulują pewne zachowania.rysic pisze:To ja się boję co robią firmy, które nie są najlepsze w tej branży...Wujek pisze:Rysic, blad poprawiaja, kaza restartowac urzadzenie i dziala, przez pare miesiecy...
Wydawalo mi sie ze Steelhead`y sa najlepsze pod wzgledem optymalizacji.
Ja przeliczyłem ostatnio ile byśmy zaoszczędzili posiadając dwukrotnie szybsze łącza nie kupując Riverbedów i ich licencji. Suma była dość spora, ale że ktoś musi ciągnąć sobie proket... to muszą zostać...
Ale już nie odbiegam od tematu. Sorru za offtop.
Ja bym spróbował out of line i WCCP. oczywiście o ile cpu da rade, zależy jak szyliście kupując te routery. ogarnie wam to wszelkie inne failovery (te do środka, jak i na zewnątrz). Chociaż twój problem to ciekawostka konkretna i zmiana topologii raczej nic Nie pomoze
jak nie pasuje rozwiązanie to HSRP/GLBP + tracki
jeżeli chodzi o support, to moja firma ma go bezpośrednio od RB i raczej jesteśmy zadowoleni.
U nas to się bardziej na hp switches marudzi
co to za stealheady?
jak nie pasuje rozwiązanie to HSRP/GLBP + tracki
jeżeli chodzi o support, to moja firma ma go bezpośrednio od RB i raczej jesteśmy zadowoleni.
U nas to się bardziej na hp switches marudzi
co to za stealheady?
Każdy problem ma rozwiązanie, jeśli nie ma rozwiązania to nie ma problemu!
Dzięki za odpowiedzi Panowie
@Tonnerek
1. Steelheady nie dzialaja w klastrze, nie mamy interceptora
2. Maja, ale uzywamy tylko po jednej parze
3. sa podpiete do CMC
@Ormek Steelheady model 5050 (5050L)
Myslalem juz o instalacji z WCCP ale to chyba niewiele zmieni, jedyny plus to to ze bede mogl zawsze wylaczyc WCCP i po prostu nie optymalizowac ruchu. Riverbed reseller proponuje kolejne spotkanie celem re-design`u.
Moze wspomniane interceptory pomoga, wiecie moze jaki jest koszt tego ustrojstwa ?
@Tonnerek
1. Steelheady nie dzialaja w klastrze, nie mamy interceptora
2. Maja, ale uzywamy tylko po jednej parze
3. sa podpiete do CMC
@Ormek Steelheady model 5050 (5050L)
Myslalem juz o instalacji z WCCP ale to chyba niewiele zmieni, jedyny plus to to ze bede mogl zawsze wylaczyc WCCP i po prostu nie optymalizowac ruchu. Riverbed reseller proponuje kolejne spotkanie celem re-design`u.
Moze wspomniane interceptory pomoga, wiecie moze jaki jest koszt tego ustrojstwa ?
no coż, kilka tysiecy userów potrafi wygenerowac troche ruchu
co do pomyslu zeby czesci ruchu nie optymalizowac... nie podoba mi sie to, raczej wolalbym pomyslec nad jakims load ballancingiem. Na dniach ma byc re-design metting, zobaczymy czy to znow bedzie stracony czas czy tez tym razem cos sie madrego urodzi.
co do pomyslu zeby czesci ruchu nie optymalizowac... nie podoba mi sie to, raczej wolalbym pomyslec nad jakims load ballancingiem. Na dniach ma byc re-design metting, zobaczymy czy to znow bedzie stracony czas czy tez tym razem cos sie madrego urodzi.
-
- newbie
- Posty: 1
- Rejestracja: 04 lut 2014, 14:59
Wujek,
żadnego WCCP czy interceptora tutaj nie potrzeba. W konfiguracji która zaprezentowałeś będzie działać tylko active/backup w razie awarii Routera. Żeby oba Stealheady działały razem i optymalizowały do 15k połączeń (7,5k×2) musisz je spiąć szeregowo i używać obu interfejsów in_path. Skrzynki muszą być dodatkowo spięte interfejsami AUX dla synchronizacji Data Store.
nie zapomnij skonfigurować reguł peereng żeby skrzynki w DC nie optymalizowały między sobą.
żadnego WCCP czy interceptora tutaj nie potrzeba. W konfiguracji która zaprezentowałeś będzie działać tylko active/backup w razie awarii Routera. Żeby oba Stealheady działały razem i optymalizowały do 15k połączeń (7,5k×2) musisz je spiąć szeregowo i używać obu interfejsów in_path. Skrzynki muszą być dodatkowo spięte interfejsami AUX dla synchronizacji Data Store.
nie zapomnij skonfigurować reguł peereng żeby skrzynki w DC nie optymalizowały między sobą.