Jeżeli nie Cisco to co?
Jeżeli nie Cisco to co?
No właśnie co do rdzenia małej serwerowni jeżeli nie chcemy rozpatrywać Cisco:
Istotne warunki brzegowe:
- porty 10Gbps;
- możliwość rozciągnięcia linków (LAG, LACP, inne wynalazki) z serwerów do dwóch niezależnych switchy bez utraty komunikacji jeżeli wpadnę na pomysł upgrade jednego z nich;
- głównie szybkie L2, ale OSPFa + jakieś tworzenie ACLek pomiędzy vlanami też powinien mieć;
- VTEP na przyszłość
Do wyboru zaproponowano mi (poza Cisco)
- Dell model S4048-ON
- Extreme X670-2
- Juniper QFX5100
- HP 5940
Raczej wszystko ma podobne funkcjonalności (przynajmniej na papierze) wiec chciałbym prosić czytających moje wypociny o uwagi dotyczące praktycznej eksploatacji ww. a w szczególności dostępności szkoleń, serwisu, innych aspektów dlaczego warto (albo i nie warto) kupować coś innego.
O Della-ch już się nasłuchałem w innym wątku.
Z góry dzięki za wszystkie odpowiedzi.
Istotne warunki brzegowe:
- porty 10Gbps;
- możliwość rozciągnięcia linków (LAG, LACP, inne wynalazki) z serwerów do dwóch niezależnych switchy bez utraty komunikacji jeżeli wpadnę na pomysł upgrade jednego z nich;
- głównie szybkie L2, ale OSPFa + jakieś tworzenie ACLek pomiędzy vlanami też powinien mieć;
- VTEP na przyszłość
Do wyboru zaproponowano mi (poza Cisco)
- Dell model S4048-ON
- Extreme X670-2
- Juniper QFX5100
- HP 5940
Raczej wszystko ma podobne funkcjonalności (przynajmniej na papierze) wiec chciałbym prosić czytających moje wypociny o uwagi dotyczące praktycznej eksploatacji ww. a w szczególności dostępności szkoleń, serwisu, innych aspektów dlaczego warto (albo i nie warto) kupować coś innego.
O Della-ch już się nasłuchałem w innym wątku.
Z góry dzięki za wszystkie odpowiedzi.
Re: Jeżeli nie Cisco to co?
To skończycie jak wielu innych, którzy tak mówili/pisali, kupowali X, Y a nawet Z i potem kończyli na Cisco. Bardzo podobał mi się przypadek jednego polskiego operatora który na jednej konferencji jeździł po Cisco jakie to be, jakie drogie, i tak dalej, a rok później pokazał nową strukturę i wszystko na ..... Cisco. Bo reszta miała wszystkie funkcjonalności ale na papierze albo na road-mapie. Tyle że na takiej wiecznej road mapie.ziolek pisze:jeżeli nie chcemy rozpatrywać Cisco
Ostatnio zmieniony 23 mar 2017, 12:23 przez Kyniu, łącznie zmieniany 1 raz.
CCNA: R&S, Security, Wireless, Collaboration. MCSE: Cloud Platform and Infrastructure, Server Infrastructure. ITIL: Foundation. PPL(A)
https://www.facebook.com/itserviceskielce/ :: https://www.linkedin.com/company/itservicespoland :: https://www.linkedin.com/in/krzysztofkania/
https://www.facebook.com/itserviceskielce/ :: https://www.linkedin.com/company/itservicespoland :: https://www.linkedin.com/in/krzysztofkania/
-
- wannabe
- Posty: 581
- Rejestracja: 27 wrz 2007, 01:13
Re: Jeżeli nie Cisco to co?
Cala nasza infrastructura opiera sie na Juniperach MX / SRX / QFX / EX ostatnio na meetingu rozmawialismy o stworzeniu jakiegos alternatywneglo planu na wypadek jakis niesnasek z vendorem etc . Padlo pytanie gdybysmy mieli jutro wymienic wszystkie nasze switche to na co bysmy wymienili - wszsycy jak jeden maz odpowiedzieli Cisco (i nikt w moim teamie nie jest fan boyem Cisco )
Tak jak MX i SRX to fajne i dobre platformy tak switche Junipera to jedna wielka porazka i to nie ze wzgledu na braki ficzerow czy jakies problematyczne zarzadzanie bo naprawde fajnie sie z juniperami pracuje (w mojej opini duzo przyjemniej niz z Cisco ) niestety switche junipera sa okrotnie zbugowane ! Do tego stopnia ze mamy staly co dwutygodniowy meeting z nimi w sprawie otwartych bugow.
U nas w core siedza ex9214 i najabradziej mnie rozbroilo jak po ktoryms updatcie softu , komenda show route zaczela wykrzaczac deamona rpd . Juniepr zalecil nie robic show route (╯°□°)╯︵ ┻━┻
Tak jak MX i SRX to fajne i dobre platformy tak switche Junipera to jedna wielka porazka i to nie ze wzgledu na braki ficzerow czy jakies problematyczne zarzadzanie bo naprawde fajnie sie z juniperami pracuje (w mojej opini duzo przyjemniej niz z Cisco ) niestety switche junipera sa okrotnie zbugowane ! Do tego stopnia ze mamy staly co dwutygodniowy meeting z nimi w sprawie otwartych bugow.
U nas w core siedza ex9214 i najabradziej mnie rozbroilo jak po ktoryms updatcie softu , komenda show route zaczela wykrzaczac deamona rpd . Juniepr zalecil nie robic show route (╯°□°)╯︵ ┻━┻
Re: Jeżeli nie Cisco to co?
zartujesz?freel4ncer pisze: Juniepr zalecil nie robic show route (╯°□°)╯︵ ┻━┻
-
- wannabe
- Posty: 581
- Rejestracja: 27 wrz 2007, 01:13
Re: Jeżeli nie Cisco to co?
Nie nie zartuje
generalnie jako ze trafiamy na duza ilosc bugow a mamy troche tych pudelek od nich to mamy dostep do junosow ktore nie sa oficjalnie wypuszczone jeszcze (czesto takie bety) Juniper w ten sposob pomaga nam latac bugi w czasie krotszym niz oficcial releases . Tak wiec zdaza sie czasem ze daja nam soft ktory naprawia nam jedne bugi a generuje kolejne czasami nie mamy zabardzo wyjscia i musimy sie godzic na chwilowe dodatkowe utrudnienia z tym zwiazane. U nas firmie duzo rzeczy sie zatrzymalo na poziomie startupowym tak wiec mozemy takie rzeczy jak upgrade softu przepychac szybciej , w odrozneiniu do takiego np google gdzie kwalifikacja nowego softu trwa wieki
generalnie jako ze trafiamy na duza ilosc bugow a mamy troche tych pudelek od nich to mamy dostep do junosow ktore nie sa oficjalnie wypuszczone jeszcze (czesto takie bety) Juniper w ten sposob pomaga nam latac bugi w czasie krotszym niz oficcial releases . Tak wiec zdaza sie czasem ze daja nam soft ktory naprawia nam jedne bugi a generuje kolejne czasami nie mamy zabardzo wyjscia i musimy sie godzic na chwilowe dodatkowe utrudnienia z tym zwiazane. U nas firmie duzo rzeczy sie zatrzymalo na poziomie startupowym tak wiec mozemy takie rzeczy jak upgrade softu przepychac szybciej , w odrozneiniu do takiego np google gdzie kwalifikacja nowego softu trwa wieki
Re: Jeżeli nie Cisco to co?
Hej
HP to bardzo dobre przełączniki ale tylko te linii HPE FlexNetwork z Comeware czyli stary 3Com.
Pracowałem dla Golda, mieliśmy masę projektów, same duże instalacje jak na PL warunki, po 100 przełączników i 0 słownie zero problemów.
Inna linia HP ProCurve teraz to chyba HP Aruba to rozwiązania klasę niższe, raczej dla małych i średnich firm z minimalnymi wymaganiami.
Na tych przełącznikach mam do dzisiaj kilka oddziałów firmy i masakra, ale tak jak mówię HPE FlexNetwork z Comeware to całe dziedzictwo 3Coma, HP Aruba to dziedzictwo Procurve czyli taki low end.
Routery HP stanowczo odradzam.
Della stanowczo odradzam, chyba że jako rozwiązanie dla małych i średnich firm bez tam jakiś wymagań wiekszych (podobnie to HPE Aruba (stary Procurve)).
Przełączników Junipera nie znam, ale z tego co słyszałem to ma słabe, w sumie jego switche to dosyć nowe rozwiązania, nie ma się co dziwić że są pełne bugów, jak długo one są na rynku coś pomiedzy 5 a 6 lat?
Extreme ma bardzo dobre rozwiązania, kilka raz widziałem instalacje na nich, administratorzy są zadowoleni ale sam za dużo na nich nie pracowałem. W obecnej sieci mam chyba jakąś pozostałoś kilka sztul i mają uptime po 4-5 lat.
Rasumując serie HPE FlexFabric 5940 polecam w ciemno, na tych przełącznikach nie pracowałem bo są to nowe modele (od 4 lat pracuje tylko na Cisco i troche HP Procurve/Aruba plus kilka sztuk Extreme) ale na poprzednikach mam ponad 6 lat doświadczenia.
Jeśli w Extremie nic się nie zmieniło to też polecam z czystym sumieniem.
Obie linie produktowe w niczym nie odbiegają od Cisco a często za te same $$ dostaje się dużo więcej.
Jeśli sam miałbym budować DC to spokojnie jako switche rozpatrywałbym HPE FlexFabric, Cisco, Extreme Networks kolejność dowolna.
Routery to Cisco i Juniper i też kolejność dowolna.
Co do Cisco, to zgodzę się że ogólnie ma dobre rozwiązania jeśli chodzi o routery i przełączniki, ciężko dorwać drugiego vendora który ma obie linie produktowe na tak wysokim poziomie.
Ale już Cisco Nexus przynajmniej przez pierwsze lata przysparzał nam cała masę problemów, bugi były praktycznie wszędzie.
Tak jest w większości nowych produktów wprowadzanych na rynek i za bardzo nie ma się co dziwić.
Juniper robi dobre routery, więc potrafi, więc pewnie kwestia czasu kiedy zacznie robić dobre przełączniki.
Jeszcze jedno mniej popularne featursy z których na co dzień się nie korzysta a są w datasheet to jest loteria, trzeba to bardzo dokładnie przetestować przed decyzja czy to faktycznie działa.
W Cisco może to faktycznie działać lepiej tz raczej ma pokrycie to co jest w datasheet a to co jest (działa dobrze) na urzadzeniach ale tylko w IOS, na NX-OS czy IOS-XE jest już dużo gorzej podobnie jak u konkurencji.
Natomiast duży minus dla Cisco za wydajność ich urządzeń, tam zawsze są jakieś jazdy przy podanej wydajności klamota, coś tam jest wpisane w datasheet po czym się okazuje że wydajność z jakimiś podstawowymi featurami to połowa lub mniej, u konkurencji takich jazd raczej nie miałem.
Pzdr
mHuba
HP to bardzo dobre przełączniki ale tylko te linii HPE FlexNetwork z Comeware czyli stary 3Com.
Pracowałem dla Golda, mieliśmy masę projektów, same duże instalacje jak na PL warunki, po 100 przełączników i 0 słownie zero problemów.
Inna linia HP ProCurve teraz to chyba HP Aruba to rozwiązania klasę niższe, raczej dla małych i średnich firm z minimalnymi wymaganiami.
Na tych przełącznikach mam do dzisiaj kilka oddziałów firmy i masakra, ale tak jak mówię HPE FlexNetwork z Comeware to całe dziedzictwo 3Coma, HP Aruba to dziedzictwo Procurve czyli taki low end.
Routery HP stanowczo odradzam.
Della stanowczo odradzam, chyba że jako rozwiązanie dla małych i średnich firm bez tam jakiś wymagań wiekszych (podobnie to HPE Aruba (stary Procurve)).
Przełączników Junipera nie znam, ale z tego co słyszałem to ma słabe, w sumie jego switche to dosyć nowe rozwiązania, nie ma się co dziwić że są pełne bugów, jak długo one są na rynku coś pomiedzy 5 a 6 lat?
Extreme ma bardzo dobre rozwiązania, kilka raz widziałem instalacje na nich, administratorzy są zadowoleni ale sam za dużo na nich nie pracowałem. W obecnej sieci mam chyba jakąś pozostałoś kilka sztul i mają uptime po 4-5 lat.
Rasumując serie HPE FlexFabric 5940 polecam w ciemno, na tych przełącznikach nie pracowałem bo są to nowe modele (od 4 lat pracuje tylko na Cisco i troche HP Procurve/Aruba plus kilka sztuk Extreme) ale na poprzednikach mam ponad 6 lat doświadczenia.
Jeśli w Extremie nic się nie zmieniło to też polecam z czystym sumieniem.
Obie linie produktowe w niczym nie odbiegają od Cisco a często za te same $$ dostaje się dużo więcej.
Jeśli sam miałbym budować DC to spokojnie jako switche rozpatrywałbym HPE FlexFabric, Cisco, Extreme Networks kolejność dowolna.
Routery to Cisco i Juniper i też kolejność dowolna.
Co do Cisco, to zgodzę się że ogólnie ma dobre rozwiązania jeśli chodzi o routery i przełączniki, ciężko dorwać drugiego vendora który ma obie linie produktowe na tak wysokim poziomie.
Ale już Cisco Nexus przynajmniej przez pierwsze lata przysparzał nam cała masę problemów, bugi były praktycznie wszędzie.
Tak jest w większości nowych produktów wprowadzanych na rynek i za bardzo nie ma się co dziwić.
Juniper robi dobre routery, więc potrafi, więc pewnie kwestia czasu kiedy zacznie robić dobre przełączniki.
Jeszcze jedno mniej popularne featursy z których na co dzień się nie korzysta a są w datasheet to jest loteria, trzeba to bardzo dokładnie przetestować przed decyzja czy to faktycznie działa.
W Cisco może to faktycznie działać lepiej tz raczej ma pokrycie to co jest w datasheet a to co jest (działa dobrze) na urzadzeniach ale tylko w IOS, na NX-OS czy IOS-XE jest już dużo gorzej podobnie jak u konkurencji.
Natomiast duży minus dla Cisco za wydajność ich urządzeń, tam zawsze są jakieś jazdy przy podanej wydajności klamota, coś tam jest wpisane w datasheet po czym się okazuje że wydajność z jakimiś podstawowymi featurami to połowa lub mniej, u konkurencji takich jazd raczej nie miałem.
Pzdr
mHuba
Re: Jeżeli nie Cisco to co?
Witam,
A pracował może ktoś na Huawei ?
Pozdrawiam,
Piotr
A pracował może ktoś na Huawei ?
Pozdrawiam,
Piotr
Re: Jeżeli nie Cisco to co?
Abstrahując od tego co koledzy już powiedzieli, i prócz "kryterium cenowego" - weź od tego producenta, który oferuje pełne API.ziolek pisze:Raczej wszystko ma podobne funkcjonalności (przynajmniej na papierze) (...)
Nie "o, część rzeczy pozwalamy robić via HTTP-calls (REST), ale części nie", pełne API. I to opublikowane, a nie "bo kuzyn ponoć ma takie deweloperskie CD na którym jest trochę wyszczególnione".
Wiesz, jak będziesz kiedyś musiał kilkaset VLANów pokonfigurować - wtedy się API naprawdę przydaje.
Re: Jeżeli nie Cisco to co?
Przy założeniu, że ktoś z tego będzie:konradrz pisze:Wiesz, jak będziesz kiedyś musiał kilkaset VLANów pokonfigurować - wtedy się API naprawdę przydaje.
1. potrzebował skorzystać
2. umiał skorzystać
3. płacenie za taką możliwość będzie ekonomicznie zasadne (może wklepanie tych VLANów raz na ruski rok będzie mimo wszystko tańsze)
CCNA: R&S, Security, Wireless, Collaboration. MCSE: Cloud Platform and Infrastructure, Server Infrastructure. ITIL: Foundation. PPL(A)
https://www.facebook.com/itserviceskielce/ :: https://www.linkedin.com/company/itservicespoland :: https://www.linkedin.com/in/krzysztofkania/
https://www.facebook.com/itserviceskielce/ :: https://www.linkedin.com/company/itservicespoland :: https://www.linkedin.com/in/krzysztofkania/
-
- wannabe
- Posty: 581
- Rejestracja: 27 wrz 2007, 01:13
Re: Jeżeli nie Cisco to co?
Wydaje mi sie ze w DC to grzech nie kozystac z automatyzacji .
Gdybym projektowal siec do DC to odarazu pod katem intent driven network !
Stworzyc struktury danych , zaplanowac subnety odpowiednio , naming urzadzen , vlanow etc (wszystko pod katem wlasnie latwej autmatyzacji)
a potem tylko troche pytona + dobre api vendora i zycie jest piekne :i duzo prostsze
U nas caly provisioning jest zautomatyzowany . Koncze wlasnie automatyzowac tworzenie firewall policies i natow gdzie user otwiera ISSUE w Jira
I jak tylko ticket zmieni status na approved to policies sa konfigurowane automatycznie.
Do tego napisalem pelno tooli sprawdzajacych poprawnosc konfiguracji itp itd co na dluzsza mete oszczedza nam kupe czasu a co za tym idzie forsy
Gdybym projektowal siec do DC to odarazu pod katem intent driven network !
Stworzyc struktury danych , zaplanowac subnety odpowiednio , naming urzadzen , vlanow etc (wszystko pod katem wlasnie latwej autmatyzacji)
a potem tylko troche pytona + dobre api vendora i zycie jest piekne :i duzo prostsze
U nas caly provisioning jest zautomatyzowany . Koncze wlasnie automatyzowac tworzenie firewall policies i natow gdzie user otwiera ISSUE w Jira
I jak tylko ticket zmieni status na approved to policies sa konfigurowane automatycznie.
Do tego napisalem pelno tooli sprawdzajacych poprawnosc konfiguracji itp itd co na dluzsza mete oszczedza nam kupe czasu a co za tym idzie forsy
Ostatnio zmieniony 23 mar 2017, 16:57 przez freel4ncer, łącznie zmieniany 2 razy.
Re: Jeżeli nie Cisco to co?
A potem przyjdzie programista co będzie na nowo odkrywał amerykę i trzeba będzie armi ludzi, żeby po nim posprzątać. Albo będzie jak z ostatnią wtopą Amazona. Jedna literówka i upsssss, automatyzacja, setki maszyn poszły się je........ Daje się do ręki ludziom brzytwę, opisując tylko jej zalety, jak to świetnie goli ale nie wspomina ani słowem o skutkach nieprzemyślanego stosowania, które może skaleczyć, trwale oszpecić a nawet pozbawić życia, jak trafi na aortę. Więc może o tej "czarnej" stronie automatyzacji też napisz, skoro ją tak polecasz.freel4ncer pisze:a potem tylko troche pytona + dobre api vendora i zycie jest piekne :i duzo prostsze)
Właśnie ukułem hasło dnia automatyzacja zarządzania = automatyzacja katastrof na masową skalę albo zautomatyzuj sobie disaster
CCNA: R&S, Security, Wireless, Collaboration. MCSE: Cloud Platform and Infrastructure, Server Infrastructure. ITIL: Foundation. PPL(A)
https://www.facebook.com/itserviceskielce/ :: https://www.linkedin.com/company/itservicespoland :: https://www.linkedin.com/in/krzysztofkania/
https://www.facebook.com/itserviceskielce/ :: https://www.linkedin.com/company/itservicespoland :: https://www.linkedin.com/in/krzysztofkania/
-
- wannabe
- Posty: 581
- Rejestracja: 27 wrz 2007, 01:13
Re: Jeżeli nie Cisco to co?
Dlatego trzeba pisac Testy
I testowac kod w labie zanim sie go pchnie do produkcji
Ja osobiscie nei mialem jeszcze zadnej duzej wtopy z powodu autmatyzacji
Wypadki sie zdarzaja , jeden koles w pakistanskim ISP zrobil blackhole youtuba , zdazaja sie typos inzynierom ktorzy konfiguruja z palca.
Wydaje mi sie ze automatyzycja przynosi wiecej dobrego niz zlego i jest wlasnie bardziej odporna na awarie/pomylki niz konfigurowanie z palca
Wszystko zalezy od tego jak to jest zrobione (jak ze wszystkim zreszta)
Ale nikt nie zaprzeczy ze taki jest kierunek networkingu .
I testowac kod w labie zanim sie go pchnie do produkcji
Ja osobiscie nei mialem jeszcze zadnej duzej wtopy z powodu autmatyzacji
Wypadki sie zdarzaja , jeden koles w pakistanskim ISP zrobil blackhole youtuba , zdazaja sie typos inzynierom ktorzy konfiguruja z palca.
Wydaje mi sie ze automatyzycja przynosi wiecej dobrego niz zlego i jest wlasnie bardziej odporna na awarie/pomylki niz konfigurowanie z palca
Wszystko zalezy od tego jak to jest zrobione (jak ze wszystkim zreszta)
Ale nikt nie zaprzeczy ze taki jest kierunek networkingu .
Re: Jeżeli nie Cisco to co?
Jasne, każdemu zdarzają się błędy. Jasne, na pewno łatwo popełnić drobne pomyłki przy masowej konfiguracji wielu urządzeń. Tylko zasięg takiego błędu jest dużo mniejszy, niż zasięg błędu popełnionego przy zastosowaniu automatyzacji. Piszesz o testowaniu kodu w labie ale w takim razie kupując sprzęt na produkcję trzeba pomyśleć też o koszcie wyposażenia laba. A o tym się zapomina, namawiając klientów na automatyzację i rysując świetlistą wizję przyszłości bez administratorów. Tak jak zapomina się o tym, że tych administratorów zastąpić trzeba będzie programistami, testerami, i innym sztabem ludzi. Aczkolwiek to temat na inny wątek i zaraz zostaniemy opi... więc albo EOT albo trzeba założyć inny wątek. A może nawet dział o nazwie "API, SDN, Automatyzacja" dla programistów w świecie sieci.freel4ncer pisze:jest wlasnie bardziej odporna na awarie/pomylki niz konfigurowanie z palca
Tylko czy słuszny .... Ludzkość już wiele razy skręcała w złe uliczki. Chwilowa moda o przyszłości której na razie trudno rozstrzygać.freel4ncer pisze:Ale nikt nie zaprzeczy ze taki jest kierunek networkingu .
CCNA: R&S, Security, Wireless, Collaboration. MCSE: Cloud Platform and Infrastructure, Server Infrastructure. ITIL: Foundation. PPL(A)
https://www.facebook.com/itserviceskielce/ :: https://www.linkedin.com/company/itservicespoland :: https://www.linkedin.com/in/krzysztofkania/
https://www.facebook.com/itserviceskielce/ :: https://www.linkedin.com/company/itservicespoland :: https://www.linkedin.com/in/krzysztofkania/
Re: Jeżeli nie Cisco to co?
freel4ncer pisze:Dlatego trzeba pisac Testy
I testowac kod w labie zanim sie go pchnie do produkcji
Ja osobiscie nei mialem jeszcze zadnej duzej wtopy z powodu autmatyzacji
Wypadki sie zdarzaja , jeden koles w pakistanskim ISP zrobil blackhole youtuba , zdazaja sie typos inzynierom ktorzy konfiguruja z palca.
Wydaje mi sie ze automatyzycja przynosi wiecej dobrego niz zlego i jest wlasnie bardziej odporna na awarie/pomylki niz konfigurowanie z palca
Wszystko zalezy od tego jak to jest zrobione (jak ze wszystkim zreszta)
Ale nikt nie zaprzeczy ze taki jest kierunek networkingu .
Jak ktoś będzie pisał skrypty o czymś, o czym nie ma pojęcia to trudno przewidzieć rezultaty. Poza tym, za skryptami stoi również tylko człowiek, wiec błędy się zdarzają. Z drugiej strony, jeśli robisz automatyzacje snmp, vty password, tacacs itd., ok są to dość proste sprawy i nawet jak się cos wywali to nie będzie to miało wpływu na twój data plane, ale wyobraź sobie stację, że robisz deployment MP-BGP, jakiś IGP itd. na kilkudziesięciu nodach. W razie problemu troubleshooting bedzie bardziej skomplikowany niż jakbyś robił deployment z palca.
Pozdro,
Re: Jeżeli nie Cisco to co?
To bodaj od Cumulusa: "to err is human; to err a million times is to automate".Kyniu pisze:Właśnie ukułem hasło dnia automatyzacja zarządzania = automatyzacja katastrof na masową skalę albo zautomatyzuj sobie disaster
Tak czy inaczej, jak masz API to nie musisz żadnych pajtonów czy innych węży używać - głupi Postman wystarczy (ze swoim Runner tool). Przykład (odnośnie ACI, ale to nieistotne) tu. Imaginuj jak łatwo te kilkaset VLANów byś zrobił (NXOS "zwykły" ma API).