BGP: Na co migrować z 6500/Sup-720-3b-xl?
BGP: Na co migrować z 6500/Sup-720-3b-xl?
Witajcie,
6500 z Sup-720-3b-xl ma 1GB RAM co zaczyna stanowić problem przy wykorzystaniu kilku full-feedów i kilku downstreamów.
Czy jedyną alternatywą w Cisco jest ASR?
Pozdrawiam
6500 z Sup-720-3b-xl ma 1GB RAM co zaczyna stanowić problem przy wykorzystaniu kilku full-feedów i kilku downstreamów.
Czy jedyną alternatywą w Cisco jest ASR?
Pozdrawiam
- PatrykW
- wannabe
- Posty: 1742
- Rejestracja: 31 paź 2008, 16:05
- Lokalizacja: UI.PL / Ubiquiti Polska.pl
- Kontakt:
Re: BGP: Na co migrować z 6500/Sup-720-3b-xl?
2T ?jaroj pisze:Witajcie,
6500 z Sup-720-3b-xl ma 1GB RAM co zaczyna stanowić problem przy wykorzystaniu kilku full-feedów i kilku downstreamów.
Czy jedyną alternatywą w Cisco jest ASR?
Pozdrawiam
.ılı..ılı.
http://www.linkedin.com/in/pwojtachnio
Potrzebujesz projektu na studia z zakresu Cisco Packet Tracer & GNS ? Just give me call
Integrujemy i wspieramy IT
https://www.ui.pl | https://facebook.com/UIPolska
Jedyne rozwiązania Ubiquiti Networks w Polsce!
https://ubiquitipolska.pl | https://www.facebook.com/groups/Ubiquiti.Polska
http://www.linkedin.com/in/pwojtachnio
Potrzebujesz projektu na studia z zakresu Cisco Packet Tracer & GNS ? Just give me call
Integrujemy i wspieramy IT
https://www.ui.pl | https://facebook.com/UIPolska
Jedyne rozwiązania Ubiquiti Networks w Polsce!
https://ubiquitipolska.pl | https://www.facebook.com/groups/Ubiquiti.Polska
Re: BGP: Na co migrować z 6500/Sup-720-3b-xl?
Sup2T, albo w zależności od ilości ruchu Nx10Gbit/s (i przewidywanego wzrostu), albo ASR 1002X, albo ASR 9001S.jaroj pisze:Witajcie,
6500 z Sup-720-3b-xl ma 1GB RAM co zaczyna stanowić problem przy wykorzystaniu kilku full-feedów i kilku downstreamów.
Czy jedyną alternatywą w Cisco jest ASR?
Pozdrawiam
Można też dać RSP720-3CXL, obsługuje do 4GB na RP więc 4x więcej niż sup720-3BXL. Taktowanie CPU na RP jest również 2x wyższe.
Wymagania to obudowa 7600 ale z kolei udźwignie wszystkie moduły, włącznie z WS-X6708-10GE oraz inne starsze, które nie są kompatybilne z Sup2T.
Jest jeszcze cisco 6880-X, który w kompaktowej obudowie mieści sporo portów 10GE. Jak musisz zmienić supervisor, obudowe jak masz model bez -E czy rozbudować o kolejne moduły 10GE to 6880-X może wyjść taniej. Tylko wtedy lądujesz już w cenach ASRów.
Myśle, że ważnym aspektem jest fakt czy potrzebujesz switcha czy router. Jak terminujesz wiele portów GE/10GE na 6500 i często używasz vlanów rozchodzących się na wiele portów to warto iść w kierunku switcha bo ASR to typowe routery.
Pozdr.
Wymagania to obudowa 7600 ale z kolei udźwignie wszystkie moduły, włącznie z WS-X6708-10GE oraz inne starsze, które nie są kompatybilne z Sup2T.
Jest jeszcze cisco 6880-X, który w kompaktowej obudowie mieści sporo portów 10GE. Jak musisz zmienić supervisor, obudowe jak masz model bez -E czy rozbudować o kolejne moduły 10GE to 6880-X może wyjść taniej. Tylko wtedy lądujesz już w cenach ASRów.
Myśle, że ważnym aspektem jest fakt czy potrzebujesz switcha czy router. Jak terminujesz wiele portów GE/10GE na 6500 i często używasz vlanów rozchodzących się na wiele portów to warto iść w kierunku switcha bo ASR to typowe routery.
Pozdr.
Lukasz Wisniowski MSc CCNA CCNP CCIE #20319
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825
Re: BGP: Na co migrować z 6500/Sup-720-3b-xl?
Poszedłbym innym tropem, niż wymiana sprzętu. 6500 z 3B-XL i 1GB RAM powinien sobie dać radę z kilkoma feedami i peerami. N feedów, to nie jest N razy zajętość pojedynczego feeda w RAM, czy FIB. Kolejny feed, to może być np. 10% więcej zajętości pamięci, ale nie 50%, czy 100% więcej. Zależy od ilości i rozmiaru przesyłanych atrybutów. Jaką masz teraz zajętość pamięci?jaroj pisze:6500 z Sup-720-3b-xl ma 1GB RAM co zaczyna stanowić problem przy wykorzystaniu kilku full-feedów i kilku downstreamów.
Re: BGP: Na co migrować z 6500/Sup-720-3b-xl?
Oprocz RAM problemem Sup720 jest wolny CPU na RP. Konwergencja BGP trwa absurdalnie dlugo. Najprostsze wyjśćie to migracja Sup2T w wersji XL.jaroj pisze:Witajcie,
6500 z Sup-720-3b-xl ma 1GB RAM co zaczyna stanowić problem przy wykorzystaniu kilku full-feedów i kilku downstreamów.
Czy jedyną alternatywą w Cisco jest ASR?
Pozdrawiam
Inne:
Sup6T - za chwile bedzie. Wymaga nowego chassis 6708, nie wspiera starych kart (67xx). Ma on board 8x10G i 2x40G. Za chwile bedą też nowe karty niestety cześć z nich nie bedzie w wersji XL.
Catalyst 6880-X - on-board 16x1/10GE (nadsubskrypcja 1:2), 4 sloty na karty 16x1/10GE, FIB 2M, 4GB RAM, bardzo wydajny Intelowski RP
Ew. może mały Juniper MX (MX104)
Re: BGP: Na co migrować z 6500/Sup-720-3b-xl?
Dla wielu feedów to może być problem.jarek6 pisze:Oprocz RAM problemem Sup720 jest wolny CPU na RP. Konwergencja BGP trwa absurdalnie dlugo.
To też wymiana sprzętujarek6 pisze:Inne:
Sup6T - za chwile bedzie. Wymaga nowego chassis 6708, nie wspiera starych kart (67xx). Ma on board 8x10G i 2x40G. Za chwile bedą też nowe karty niestety cześć z nich nie bedzie w wersji XL.
Catalyst 6880-X - on-board 16x1/10GE (nadsubskrypcja 1:2), 4 sloty na karty 16x1/10GE, FIB 2M, 4GB RAM, bardzo wydajny Intelowski RP
Tutaj wydajność RP jest jeszcze gorsza niż w Supie 720.jarek6 pisze:Ew. może mały Juniper MX (MX104)
Re: BGP: Na co migrować z 6500/Sup-720-3b-xl?
Piszesz z praktycznego doświadczenia ? Mamy obie platformy i zupełnie się z Tobą nie zgadzam. RE w małych MX to nie są demony szybkości ale od czasu JunOS 10.x/11.x sporo się poprawiło w kodzie schedulera. Jak coś to zapraszam na testy.lbromirs pisze: Tutaj wydajność RP jest jeszcze gorsza niż w Supie 720.
Sup720 od IOS 12.2(33)SXI działa tragicznie źle w kwesti szybkości konwergencji. Na 12.2(33)SXH działało jeszcze spoko. W SXI coś zostało zmienione oprócz dodania m.in. 32-bit ASN w kodzie BGP scannera lub innego procesu i zaczał się dramat.
Re: BGP: Na co migrować z 6500/Sup-720-3b-xl?
Tak, JunOS. Scheduler (rpd) został "poprawiony" dopiero w 15'tce JunOSa, do tego czasu MX104 potrafił ładować nawet jedną tablicę BGP do 20 minut (nawet z eksperymentalną wersją 64-bitową z okolic 13.2, która została zakopana pod ziemię i napisana potem od nowa). Problem znany od lat i ignorowany przez Junipera. NANOG zajmował się problemem, do momentu w którym ludzie zrezygnowali z używania MXa 80 i 104 do BGP i zajęli się ciekawszymi zajęciami.robhass pisze:Piszesz z praktycznego doświadczenia ?lbromirs pisze: Tutaj wydajność RP jest jeszcze gorsza niż w Supie 720.
Po co? Testy już robiłem, wyniki znam Osoby, które nie dotykały obu platform mają dostęp do google'arobhass pisze:Jak coś to zapraszam na testy.
A konkretnie ile Ci się zbiega jeden pełen feed na Supie 720? Jeśli więcej niż 2-3 minuty, coś jest nie tak w konfiguracji.robhass pisze:Sup720 od IOS 12.2(33)SXI działa tragicznie źle w kwesti szybkości konwergencji. Na 12.2(33)SXH działało jeszcze spoko. W SXI coś zostało zmienione oprócz dodania m.in. 32-bit ASN w kodzie BGP scannera lub innego procesu i zaczał się dramat.
Re: BGP: Na co migrować z 6500/Sup-720-3b-xl?
Poprawki tego byly wczesniej niz w 15.x (14.x). W 15.x i 16.x (obecnie EFT) sa kolejne usprawnienia ale dotyczą tylko RE Intelowskich - vide QFX10k, PTX i w szczególności modularne MX'y. RE na PPC nie są nimi objęte bo mają za mało RAMu.Po co? Testy już robiłem, wyniki znam Osoby, które nie dotykały obu platform mają dostęp do google'a
Co do jakości/poprawności konfiguracji:A konkretnie ile Ci się zbiega jeden pełen feed na Supie 720? Jeśli więcej niż 2-3 minuty, coś jest nie tak w konfiguracji.
Na SXH nie bylo problemów, działało akceptowalnie. Po upgrade na SXI zrobiła się masarka. Około 10 minut przy flap'ie zewnętrznego peer'a który dawał 1/3 tablicy. Napewno nasze route-map'y były evil A na serio brak umijejętności/wiedzy to nie tym razem.
Re: BGP: Na co migrować z 6500/Sup-720-3b-xl?
Jeżeli decyzja o wymianie sprzętu jest podyktowana pogorszeniem się konwergencji, to najpierw starałbym się wyjaśnić z TAC zmianę zachowania. Rzucenie się na C6800 lub SUP2T nie rozwiąże automatycznie problemu, choć ASR gwarantuje, że będzie tylko lepiej.robhass pisze:Sup720 od IOS 12.2(33)SXI działa tragicznie źle w kwesti szybkości konwergencji. Na 12.2(33)SXH działało jeszcze spoko. W SXI coś zostało zmienione oprócz dodania m.in. 32-bit ASN w kodzie BGP scannera lub innego procesu i zaczał się dramat.
Re: BGP: Na co migrować z 6500/Sup-720-3b-xl?
Agree. Była to wcześniej zaplanowana modernizacja z przyczyn rozwoju sieci. Problem wyszedł przy okazji i zbiegł się w czasie. Nie drązyliśmy tego później.gangrena pisze:Sup720 od IOS 12.2(33)SXI działa tragicznie źle w kwesti szybkości konwergencji. Na 12.2(33)SXH działało jeszcze spoko. W SXI coś zostało zmienione oprócz dodania m.in. 32-bit ASN w kodzie BGP scannera lub innego procesu i zaczał się dramat.
Wymieniać urządzenia poinstalowane kilku krajach bo jest bug albo bardziej "New Feature", raczej to by nie przeszło
Jeżeli chodzi o konwergencje to ja powiem, że sporo zależy od umowy z klientami jaką masz i ich wymagań. Stabilność feedów często jest na poziomie wielu tygodni albo nawet i miesięcy. Teraz pytanie ile chcesz dopłacać aby konwergencja była na poziomie kilkunastu zamiast kilkudziesięciu sekund. Nie mówiąc, że sporo też zależy też od upstream routera.
Wogóle jeżeli rozważamy konwergencje to trzeba by zacząć od funkcjnonalności jak BGP PIC, zamiast szybkiego procesora oraz patrzeć w głąb architektury aby dokładnie wiedzieć ile zajmuje wepchnięcie software FIB do hardware FIB. Do tego połączenie tego z BFD aby szybko wykrywać awarie.
6500/7600 obsługuje BFD oraz BGP PIC chociaż prędkością nie dorówna ASR ale uruchomienie go może znacznie więcej dać niż szybki procesor RP.
Z tego co dzisiaj widze to sup720-3BXL daje rade do 4 pełnych feedów + X-y, klienci na ogół do ciebie tylko kilka prefixów wysyłają więc możesz mieć ich wielu.
Jak masz więcej pełnych feedów to powinno cie być stać na lepszy supervisor. BGP PIC odpada na Sup720-3BXL ale już RSP720 czy Sup2T to jak najbardziej.
Pozdr.
Wogóle jeżeli rozważamy konwergencje to trzeba by zacząć od funkcjnonalności jak BGP PIC, zamiast szybkiego procesora oraz patrzeć w głąb architektury aby dokładnie wiedzieć ile zajmuje wepchnięcie software FIB do hardware FIB. Do tego połączenie tego z BFD aby szybko wykrywać awarie.
6500/7600 obsługuje BFD oraz BGP PIC chociaż prędkością nie dorówna ASR ale uruchomienie go może znacznie więcej dać niż szybki procesor RP.
Z tego co dzisiaj widze to sup720-3BXL daje rade do 4 pełnych feedów + X-y, klienci na ogół do ciebie tylko kilka prefixów wysyłają więc możesz mieć ich wielu.
Jak masz więcej pełnych feedów to powinno cie być stać na lepszy supervisor. BGP PIC odpada na Sup720-3BXL ale już RSP720 czy Sup2T to jak najbardziej.
Pozdr.
Lukasz Wisniowski MSc CCNA CCNP CCIE #20319
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825
Re: BGP: Na co migrować z 6500/Sup-720-3b-xl?
Były, ale piszę o efektywnym rozwiązaniu problemu. W 14.1-ileś-tam problem został niby poprawiony, ale potem wrócił. Tak jak pisałem, teoretycznie poprawki były już w 13.2.robhass pisze:Poprawki tego byly wczesniej niz w 15.x (14.x). W 15.x i 16.x (obecnie EFT) sa kolejne usprawnienia ale dotyczą tylko RE Intelowskich - vide QFX10k, PTX i w szczególności modularne MX'y. RE na PPC nie są nimi objęte bo mają za mało RAMu.Po co? Testy już robiłem, wyniki znam Osoby, które nie dotykały obu platform mają dostęp do google'a
Nic takiego nie sugeruję. Pamiętam, że np. domyślne wartości dla CoPP się różniły dosyć mocno w kolejnych wersjach softu linii 12.2(33) i późniejszych, to jeden z efektów prób uwspólnienia linii softu dla 6500 i 7600. Przy tak skomplikowanych architekturach, tak jak pisze niżej gangrena zanim powiesz 'bug', lepiej porozmawiać z TACiem. Żąglowanie softem to wspaniałe rozwiązanie, ale czasami lepiej dojść źródła problemu/zachowania.robhass pisze:Co do jakości/poprawności konfiguracji:A konkretnie ile Ci się zbiega jeden pełen feed na Supie 720? Jeśli więcej niż 2-3 minuty, coś jest nie tak w konfiguracji.
Na SXH nie bylo problemów, działało akceptowalnie. Po upgrade na SXI zrobiła się masarka. Około 10 minut przy flap'ie zewnętrznego peer'a który dawał 1/3 tablicy. Napewno nasze route-map'y były evil A na serio brak umijejętności/wiedzy to nie tym razem.
Re: BGP: Na co migrować z 6500/Sup-720-3b-xl?
Masz jakieś źrodło/post z google (pisałeś że można znaleźć w google) które mówi o tym że w 14.x jest dalej spierdzielone ? Jestem zainteresowany tematem jako posiadacz sporej ilości MX'ów pracujących na sofcie 14.2 i nie czujący problemu. Czyżby popsuli coś w nowszym buildzie ?lbromirs pisze:Były, ale piszę o efektywnym rozwiązaniu problemu. W 14.1-ileś-tam problem został niby poprawiony, ale potem wrócił. Tak jak pisałem, teoretycznie poprawki były już w 13.2.
CoPP policy zawsze mielismy swoje, nie cielismy ruchu dla sesji BGP - akcje byly transmit rowniez dla exceed/violate. Konfiguracja mls rate-limiter'ów również była 'custom made'. TAC ... oczywiście było zgłoszone i nie bylo wyjasnione. Podobna sprawa jak z czasem programowania FIB na 7600/RPS720 - co ostatecznie zostalo opisane 'to musi tyle trwac i juz'. Z notatek widze, ze pomiedzy wersja SXH a SXI zmienilo sie zachowanie kodu pod tytulem 'auto-refresh'. Co to znaczy ? Mam neighbor'a 1.1.1.1 i na nim route-map BLAH (na IN lub OUT - nie za znaczenia). Robie zmiany w route-map'ie i refresh jest automatyczny - tzn nie musze robic clear ip bgp 1.1.1.1 in czy clear ip bgp 1.1.1.1 out. Wczesniej tak nie bylo. Zmiana nigdzie nie byla opisana. Podejrzewalismy ze spowolnienie BGP'a to kolejna nieopisana rzecz.Nic takiego nie sugeruję. Pamiętam, że np. domyślne wartości dla CoPP się różniły dosyć mocno w kolejnych wersjach softu linii 12.2(33) i późniejszych, to jeden z efektów prób uwspólnienia linii softu dla 6500 i 7600.
Ostatnio zmieniony 16 kwie 2016, 21:08 przez robhass, łącznie zmieniany 2 razy.