BGP: Na co migrować z 6500/Sup-720-3b-xl?

Wszystkie rozmowy związane z problemem z hardwarem, supportowanymi funkcjonalnościami, wydajnością urządzeń itp.

Moderatorzy: mikrobi, aron, garfield, gangrena, Seba

Wiadomość
Autor
lbromirs
CCIE
CCIE
Posty: 3949
Rejestracja: 30 lis 2006, 08:44

#31

#31 Post autor: lbromirs » 17 kwie 2016, 17:24

jaroj pisze:Czy ASR 9001 może mieć więcej RAMu niż standardowe 8GB zawarte w specyfikacji?
Nie. 9001 ma 8GB dla RP i 8GB dla systemu przekazywania ruchu.

jaroj
wannabe
wannabe
Posty: 75
Rejestracja: 04 lut 2012, 18:35

#32

#32 Post autor: jaroj » 18 kwie 2016, 10:57

lbromirs pisze:
jaroj pisze:Czy ASR 9001 może mieć więcej RAMu niż standardowe 8GB zawarte w specyfikacji?
Nie. 9001 ma 8GB dla RP i 8GB dla systemu przekazywania ruchu.
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
CCIE
CCIE
Posty: 3949
Rejestracja: 30 lis 2006, 08:44

#33

#33 Post autor: lbromirs » 18 kwie 2016, 12:31

jaroj pisze:
lbromirs pisze:
jaroj pisze:Czy ASR 9001 może mieć więcej RAMu niż standardowe 8GB zawarte w specyfikacji?
Nie. 9001 ma 8GB dla RP i 8GB dla systemu przekazywania ruchu.
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?
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.

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2345
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

#34

#34 Post autor: gangrena » 18 kwie 2016, 13:02

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?
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.

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2345
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

#35

#35 Post autor: gangrena » 18 kwie 2016, 13:24

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.
Można to zoptymalizować odpowiednim dampeningiem.
robhass pisze:Drugi przyklad - reload maszyny. Pelna konwergencja zajmowala 20-25 minut.
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
wannabe
wannabe
Posty: 116
Rejestracja: 05 mar 2009, 16:17

#36

#36 Post autor: robhass » 18 kwie 2016, 16:46

gangrena pisze: Można to zoptymalizować odpowiednim dampeningiem.
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: 20-25 minut nie od razu oznacza problem. Większość z tego czasu maszyna przeznacza po prostu na start.
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.

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2345
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

#37

#37 Post autor: gangrena » 18 kwie 2016, 18:04

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.
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.

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.
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.
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ń.

jaroj
wannabe
wannabe
Posty: 75
Rejestracja: 04 lut 2012, 18:35

#38

#38 Post autor: jaroj » 20 kwie 2016, 12:32

gangrena pisze:
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?
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.
Pomóżcie:

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.

Seba
CCIE/CCDE Site Admin
CCIE/CCDE Site Admin
Posty: 6223
Rejestracja: 15 lip 2004, 20:35
Lokalizacja: Warsaw, PL

#39

#39 Post autor: Seba » 20 kwie 2016, 17:02

BGP jest już w IPBase; ze względu na MPLS musi być Advanced IP.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe."
A. Einstein

ODPOWIEDZ