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.
Wiadomość
Autor
jaroj
wannabe
wannabe
Posty: 75
Rejestracja: 04 lut 2012, 18:35

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

#1

#1 Post autor: jaroj »

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

Awatar użytkownika
PatrykW
wannabe
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?

#2

#2 Post autor: PatrykW »

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
2T ?
.ı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

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

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

#3

#3 Post autor: lbromirs »

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
Sup2T, albo w zależności od ilości ruchu Nx10Gbit/s (i przewidywanego wzrostu), albo ASR 1002X, albo ASR 9001S.

lukaszbw
CCIE
CCIE
Posty: 516
Rejestracja: 23 mar 2008, 11:41

#4

#4 Post autor: lukaszbw »

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.
Lukasz Wisniowski MSc CCNA CCNP CCIE #20319
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825

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

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

#5

#5 Post autor: gangrena »

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

jarek6
wannabe
wannabe
Posty: 212
Rejestracja: 07 lut 2008, 17:56

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

#6

#6 Post autor: jarek6 »

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
Oprocz RAM problemem Sup720 jest wolny CPU na RP. Konwergencja BGP trwa absurdalnie dlugo. Najprostsze wyjśćie to migracja Sup2T w wersji XL.

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)

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

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

#7

#7 Post autor: lbromirs »

jarek6 pisze:Oprocz RAM problemem Sup720 jest wolny CPU na RP. Konwergencja BGP trwa absurdalnie dlugo.
Dla wielu feedów to może być problem.
jarek6 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
To też wymiana sprzętu :)
jarek6 pisze:Ew. może mały Juniper MX (MX104)
Tutaj wydajność RP jest jeszcze gorsza niż w Supie 720.

robhass
wannabe
wannabe
Posty: 116
Rejestracja: 05 mar 2009, 16:17

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

#8

#8 Post autor: robhass »

lbromirs pisze: Tutaj wydajność RP jest jeszcze gorsza niż w Supie 720.
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.

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.

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

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

#9

#9 Post autor: lbromirs »

robhass pisze:
lbromirs pisze: Tutaj wydajność RP jest jeszcze gorsza niż w Supie 720.
Piszesz z praktycznego doświadczenia ?
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:Jak coś to zapraszam na testy.
Po co? Testy już robiłem, wyniki znam :) Osoby, które nie dotykały obu platform mają dostęp do google'a ;)
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.
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
wannabe
wannabe
Posty: 116
Rejestracja: 05 mar 2009, 16:17

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

#10

#10 Post autor: robhass »

Po co? Testy już robiłem, wyniki znam :) Osoby, które nie dotykały obu platform mają dostęp do google'a ;)
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.
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.
Co do jakości/poprawności 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.

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

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

#11

#11 Post autor: gangrena »

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

robhass
wannabe
wannabe
Posty: 116
Rejestracja: 05 mar 2009, 16:17

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

#12

#12 Post autor: robhass »

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

Wymieniać urządzenia poinstalowane kilku krajach bo jest bug albo bardziej "New Feature", raczej to by nie przeszło ;-)

lukaszbw
CCIE
CCIE
Posty: 516
Rejestracja: 23 mar 2008, 11:41

#13

#13 Post autor: lukaszbw »

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.
Lukasz Wisniowski MSc CCNA CCNP CCIE #20319
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

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

#14

#14 Post autor: lbromirs »

robhass pisze:
Po co? Testy już robiłem, wyniki znam :) Osoby, które nie dotykały obu platform mają dostęp do google'a ;)
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.
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:
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.
Co do jakości/poprawności 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.
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
wannabe
wannabe
Posty: 116
Rejestracja: 05 mar 2009, 16:17

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

#15

#15 Post autor: robhass »

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.
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 ? ;-)
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.
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.
Ostatnio zmieniony 16 kwie 2016, 21:08 przez robhass, łącznie zmieniany 2 razy.

ODPOWIEDZ