Nie. 9001 ma 8GB dla RP i 8GB dla systemu przekazywania ruchu.jaroj pisze:Czy ASR 9001 może mieć więcej RAMu niż standardowe 8GB zawarte w specyfikacji?
BGP: Na co migrować z 6500/Sup-720-3b-xl?
To z punktu widzenia ilości mozliwych peerów, ilości doklejanych atrybutów itp. teoretycznie np. 1006 z 16MB będzie lepszy jak mysle?lbromirs pisze:Nie. 9001 ma 8GB dla RP i 8GB dla systemu przekazywania ruchu.jaroj pisze:Czy ASR 9001 może mieć więcej RAMu niż standardowe 8GB zawarte w specyfikacji?
ASR 1k dzieli dostępną pamięć na pół ale mimo tego i tak jak pisałem gdzieś wyżej, to ASR 1k na razie był naszą najlepiej skalowalną platformą do roli RR. IOS-XR trochę inaczej zarządza pamięcią, należałoby sprawdzić dane dla skalowalności.jaroj pisze:To z punktu widzenia ilości mozliwych peerów, ilości doklejanych atrybutów itp. teoretycznie np. 1006 z 16MB będzie lepszy jak mysle?lbromirs pisze:Nie. 9001 ma 8GB dla RP i 8GB dla systemu przekazywania ruchu.jaroj pisze:Czy ASR 9001 może mieć więcej RAMu niż standardowe 8GB zawarte w specyfikacji?
Zależy, czy to dyskusja o routerze brzegowym, czy o RR. Dla routera brzegowego nie ma to takiego znaczenia. 8GB pamięci to jest wystarczająca pojemność. A nawet biorąc pod uwagę skalę sieci w Europie, to RR z 8GB też wystarczy. Chyba, że mówimy o ISP w dużej sieci MPLS VPN. Ważniejszym czynnikiem przy wyborze jest potrzebna wydajność, funkcjonalności oraz cena.jaroj pisze:To z punktu widzenia ilości mozliwych peerów, ilości doklejanych atrybutów itp. teoretycznie np. 1006 z 16MB będzie lepszy jak mysle?
Można to zoptymalizować odpowiednim dampeningiem.robhass pisze:Najwiekszy problem z pojawia sie gdy masz sporo sesji klienckich, dodatkowe iBGP gdzie dostajesz tez "full-table". Pada jeden z upstream'ow, leca update'y do neighbor iBGP i klientow. Jednoczesnie dostajesz sciezki via iBGP ktore staja sie 'best-path'. Znow wysylasz update'y do klientow. W miedzyczasie wstaje twoj upstream i powtorka. W takiej sytuacji Sup720 nie dawal rady.
20-25 minut nie od razu oznacza problem. Większość z tego czasu maszyna przeznacza po prostu na start. Ruch idzie sobie ścieżką zapasową. Nie ma strat ruchu lub przerwy w działaniu usługi. Ważniejszy z tego okresu jest wycinek czasu pomiędzy rozgłoszeniem tras do sąsiadów, a wstawieniem prefiksów do tablicy FIB lokalnie u siebie. Tutaj mogą powstawać pętle i dropy, które trwają nawet kilkadziesiąt sekund. Można to oskryptować, ale generalnie polecałbym nadzorowanie restartu maszyny poprzez ręczne deaktywowanie i aktywowanie sesji BGP. Czyli po restarcie wszystkie sesje shut. Potem jedna sesja eBGP up, druga sesja eBGP up itd. do upstreamowych ISP. Następnie po wstawieniu prefiksów do FIB aktywacja sesji iBGP lub rozgłoszenie default/agregacji do własnej sieci. Następnie eBGP do klientów downstreamowych.robhass pisze:Drugi przyklad - reload maszyny. Pelna konwergencja zajmowala 20-25 minut.
Tak, ale tylko i wylacznie kolejne pady, a nie pierwsze. Re-programowania FIBu dampeningiem nie zalatwisz. Szczegolnie jak w FIB jest trasa juz nie osiagalna jako best-path, i ruch wysylany idzie w kosmos (przypadek awarii). Prosciej jest z awaria internal-linku bo IS-IS zadziala i odpowidednia konfiguracja robi robote.gangrena pisze: Można to zoptymalizować odpowiednim dampeningiem.
Dla nas to jest 25 minut niedzialajacej uslugi, stanowczo za dlugo versus SLA. To wystarczajacy powod do tego aby platforma zostala zdyskawalifikowana z funkcji PE.gangrena pisze: 20-25 minut nie od razu oznacza problem. Większość z tego czasu maszyna przeznacza po prostu na start.
Awaria to dwa update'y tras dla eventów down i up. Pierwszy event dampeningiem się nie zoptymalizuje, ale drugi już tak. Oczywiście reprogramowanie FIB-u i tak odbędzie się dwa razy. Przy pojedynczej awarii można to przynajmniej rozłożyć w czasie.robhass pisze:Tak, ale tylko i wylacznie kolejne pady, a nie pierwsze. Re-programowania FIBu dampeningiem nie zalatwisz. Szczegolnie jak w FIB jest trasa juz nie osiagalna jako best-path, i ruch wysylany idzie w kosmos (przypadek awarii). Prosciej jest z awaria internal-linku bo IS-IS zadziala i odpowidednia konfiguracja robi robote.
Druga sprawa, to posiadanie trasy default nawet jako floating static route do wybranego upstreamowego ISP lub nawet kilku statików, które dzielą przestrzeń docelową na zasadzie load-sharing. Może to być prosty sposób na zapewnienie wyjścia na zewnątrz. Będzie potrzebny jeszcze powrót, więc nie zawsze to zadziała. Zależy ile jest połączeń w górę sieci i gdzie są rozmieszczone.
Wiem, że to truizm, ale jeżeli wymaganie wynika z SLA, to powinny być dwa PE. Nie muszą przy tym stać w tej samej lokalizacji. Choć niewątpliwie są obecnie bardziej wydajne i szybsze platformy od 6500 do funkcji PE, to jednak rzadko kiedy czas restartu maszyny był i jest problemem. Pewnie dlatego, że dawniej routery PE były jeszcze wolniejsze i jeżeli klientowi zależało na ciągłości działania usługi, to konieczna była redundancja urządzeń.robhass pisze:Dla nas to jest 25 minut niedzialajacej uslugi, stanowczo za dlugo versus SLA. To wystarczajacy powod do tego aby platforma zostala zdyskawalifikowana z funkcji PE.
Pomóżcie:gangrena pisze:Zależy, czy to dyskusja o routerze brzegowym, czy o RR. Dla routera brzegowego nie ma to takiego znaczenia. 8GB pamięci to jest wystarczająca pojemność. A nawet biorąc pod uwagę skalę sieci w Europie, to RR z 8GB też wystarczy. Chyba, że mówimy o ISP w dużej sieci MPLS VPN. Ważniejszym czynnikiem przy wyborze jest potrzebna wydajność, funkcjonalności oraz cena.jaroj pisze:To z punktu widzenia ilości mozliwych peerów, ilości doklejanych atrybutów itp. teoretycznie np. 1006 z 16MB będzie lepszy jak mysle?
jaki Feature Set do ASRa (RP2) ma obluge BGP, MPLS, Netflow, VLAN.. generalnie to co stosuje sie w brzegowym routerze BGP?
Patrze na Feature Navigatorze ale jakoś mi brakuje obsugi BGP np w IP Advanced.