[HWSW]

Bemutatta 7200-as sorozatú vezeték nélküli kontrollereit az Aruba Networks. A vállalat közleménye a "802.11ac ready" képességet emeli ki elsõsorban, valójában azonban a nagy dobás nem ez, hanem az alkalmazásfüggõ rádiós optimalizáció, az AppRF.
https://www.hwsw.hu/hirek/49474/aruba-wi-fi-kontroller-7200-802-11ac-apprf.html

[Immy]

Hogyan lehet "ac ready" ha a 802.11ac szabványt csak 2-5 év múlva fogják verifikálni és addig legalább még egy draft szabványosítás hátra van?

"A rendszert ráadásul a korábbinál sokkal gyakoribb authentikációra és roamingra optimalizálták az okostelefonok, tabletek és más mobil eszközök jobb kiszolgálása érdekében." -
Ezt valaki kifejtené mi ez a marketing bullshit? Fast SSID Changing, Fast Secure Roaming, Proactive Key Caching (Sticky Key caching,Pairwise Master Key Caching-PMK, Opportunistic Key Caching-OKC, CCKM) már elég régóta van a cisconál is...


Az összehasonlítás is jó, mert a Cisco 5508 5000$, 12AP esetén (ehhez természetesen még venni kell ap licencet)
http://www.amazon.com/Cisco-5508-Series-Wireless-Controller/dp/B002GOAE0O
7200-es arubát nem találtam, de már az is beszédes lehet ha a 3600-as széria már 11000$ dollár.
http://www.amazon.com/3600-MOBILITY-CONTROLLER-SUPPORT-NON-US/dp/B00A8AUVI8/ref=sr_1_26?s=electronics&ie=UTF8&qid=1355130366&sr=1-26&keywords=aruba+controller

Biztribúrosok hajlandóak mindig gyengébb eszközökkel összehasonlítani, van cisco-nak 7500 és 8500-ös szériája is..

[Nemes Dániel]

@Immy: a közleményünkbõl kiderül, de szerintem a cikkbõl is, hogy azért mondjuk .ac-Readynek, mert a backplane kapacitása lehetõvé teszi majd annak a teljesítményigénynek a kiszolgálását, amit a .ac fog jelenteni. Ha megnézed, a Cisco az 5508-asra 500 AP kapacitás ígér (eleinte mondjuk csak 250-ig engedte licenszelni), ami ha a teljes 8 Gbps port-kapacitást elfogadjuk tényleges teljesítménynek (bár ezen is lehetne vitatkozni), akkor AP-nként átlagosan 16,4 Mbps-t jelent. Ez már .n-en sem valószínû, hogy elég. Ezzel szemben 40 Gbps _titkosított_ kapacitás elég brutális, és a .ac-re is elengendõnek tûnik.

Nem csak a throughput számít, hanem az is, hogy a .ac jelentette újdonságokat fogja-e tudni támogatni. Ezek a kontrollerek hardveresen úgy vannak kialakítva, hogy tudják majd. A cikkben is benne van, hogy AP még nincs hozzá, ezért csak ".ac-Ready".

Az authentikációnak teljesítményigénye van, a mobil eszközök pedig gyakran authentikálnak újra. Míg egy notebook max napi 5-10x authentikál rendeltetésszerû használat mellett (kivéve, ha elõírunk neki gyakoribbat), addig egy tablet akár óránként 50+ alkalommal is (de mindenesetre nagyságrendekkel gyakrabban, mint napi 10). Ugyanez igaz egy okostelefonra is. Ezt controller és/vagy RADIUS oldalon is bírni kell.

A Cisco 5508 listaára $10.995 12 AP-vel, de mondjuk 100-al már $39.995. Egy Aruba 7210-es még európai árlista szerint is jóval olcsóbb mondjuk 128 AP licensszel (de kilicenszelem neked bármikor 100-ra, ha ragaszkodsz hozzzá - még olcsóbb lesz), és akkor még nem beszéltünk arról, hogy az 5508 gyengébb hardver (lásd fent), hogy a Ciscot még tömheted SFP modulokkal a mûködõképességhez (és azt valahol fogadni is kell switch-oldalon), de különbség van a menedzsmentszoftvernél is, és akkor még nem beszéltünk a wireless IPS és esetleges egyéb eszközök áráról. Mint ahogy az Aruba-only feature-ökrõl sem.

A Cisco 7500-as controller csak FlexConnect AP-kat tud kezelni, amik ugye nem campus (Cisco terminológiában "local") AP-k, hanem branchekbe való kb. standalone, de központilag menedzselt AP-k. A 8500-as is hasonló, nem campus AP-khez való. Elõbbirõl a Cisco 1Gbps-t mond, utóbbiról 10-et, és ha ezt el is fogadjuk (és neked is igazad volna, de mint fent látod, nincs), akkor az Aruba nem 5x, hanem "csak" 4x tudna többet. De nem ez a helyzet, így megáll az 5x-ös különbség.

Ha más témában is úgy látod, hogy nem fair az összehasonlításunk, szólj, hátha meg tudjuk indokolni. Remélem, a fenti érvelés meggyõzõ volt.

[Jahno]

Idézet: Nemes Dániel - Dátum: 2012. 12. 10. 12:18

@Immy: a közleményünkbõl kiderül, de szerintem a cikkbõl is, hogy azért mondjuk .ac-Readynek, mert a backplane kapacitása lehetõvé teszi majd annak a teljesítményigénynek a kiszolgálását, amit a .ac fog jelenteni.

Oszt ez már menni fog rendesen egy átlag sarki Dell laptoppal, vagy még mindig cseréljek benne kártyát?

[Nemes Dániel]

@Jahno: nem fog, a .ac nem lesz visszafele kompatibilis a 802.11a/b/g/n közül egyikkel sem. Vehet új kártyát (ezért is mondjuk, hogy nem várható az általános elterjedése 2-3 éven belül). Ezért nem igazak az "ac-Ready" AP-k, mert még nem tudni, pontosan milyen hardver kell majd beléjük. Draftok persze vannak (ez már az n-nél is szívás volt).

[Jahno]

Idézet: Nemes Dániel - Dátum: 2012. 12. 10. 12:41

@Jahno: nem fog, a .ac nem lesz visszafele kompatibilis a 802.11a/b/g/n közül egyikkel sem. Vehet új kártyát (ezért is mondjuk, hogy nem várható az általános elterjedése 2-3 éven belül). Ezért nem igazak az "ac-Ready" AP-k, mert még nem tudni, pontosan milyen hardver kell majd beléjük. Draftok persze vannak (ez már az n-nél is szívás volt).

Akkor ez valami nagyon fasza cucc, látom én már.

[bogdan]

@Jahno: ne gonoszkodj, inkabb rendeld a kovetkezo koktelt (vardakeserus nincs arrafele? :-P), ha mar Aruban vagy! ;-) ;-) ;-)

[Jahno]

Idézet: bogdan - Dátum: 2012. 12. 10. 12:49

@Jahno: ne gonoszkodj, inkabb rendeld a kovetkezo koktelt (vardakeserus nincs arrafele? ), ha mar Aruban vagy!

Ott múltkor voltam, most éppen Pesten baszom a rezet, aztán végül is megint megyek arrafelé irányba a melegbe, csak nem olyan messze. Nem rossz hely, de irreálisan drága és sokat kell utazni, ugyanazt a fun faktort közelebb is meg tudod szerezni, így inkább elmegyek abból a költségvetésből 3-4 közelebbi helyre. És még a sör is occsóbb

[cpctcg]

Immy, hol vagy, mere "baszod a rezet"?!

[Immy]

@cpctcg - munka volt, nem érek rá éjjel nappal fórumozgatni

@Nemes Dániel
" _titkosított_ kapacitás elég brutális"
Igen ez a másik régi szövegetek, hogy a controller és az AP között a forgalom nem titkosított. Ez régebben igaz volt, hogy csak a control traffic volt titkosított, de pont az általad említett 5508-nál vezették be, hogy az AP és a kontroller között AES titkosítás van "adatforgalom" esetén is.
Egyébként a két gyártó eltérõ design-ja miatt szerintem nem lehet összehasonlítani a througput-ot, mert arubánál minden forgalmat betol az AP a kontrollerbe ha kell ha nem, Cisco-nál meg van lehetõség FlexConnectre (7.3 IOS-tõl, aka H-Reap), hogy a data traffic local swhitch-ingel közvetlenül kimenjen az internetre. Mondanom sem kell külsõ telephelyek esetén ez tökéletes megoldás, mert az "internet" forgalmat nem kötelezõ mindig betolni a központi telephely kontrollerébe. Magyarországi vidéken az alacsony internet sebesség miatt legalább nem terheljük ezzel is a szûkös internet sávszélességet. (minden telephelyre meg Magyarországon senkinek sincs pénze kontrollert venni)


"Ezek a kontrollerek hardveresen úgy vannak kialakítva, hogy tudják majd." - ha nem tudja még senkise hogy mikor!! hogyan milyen specifikáció alapján fogják verifikálni a 802.11ac szabványt, akkor hogyan tudott az aruba olyat készíteni ami már ready? Egyébként attól, hogy az áteresztõképességet megnövelték tiszteletreméltó, de a marketing gépezet szerintem kicsit túllõtt a célon.


Cisco 5508 12AP-vel: 5000$
http://www.amazon.com/Adder-License-5508-ControlleR-LIC-CT5508-100A/dp/B00A8BI26K/ref=sr_1_13?ie=UTF8&qid=1355388755&sr=8-13&keywords=cisco+5508
100-as AP licence: 26000$
http://www.amazon.com/Cisco-5508-Series-Wireless-Controller/dp/B002GOAE0O/ref=sr_1_1?ie=UTF8&qid=1355388755&sr=8-1&keywords=cisco+5508
Nálam ez 31000$ dollár 112 AP-vel, de ne menjünk jobban bele az árakba, mert az arubáé még nem nyilvános.

"Ciscot még tömheted SFP modulokkal a mûködõképességhez (és azt valahol fogadni is kell switch-oldalon)" - Igen SFP-vel kell dugdosni, mert optikát megnézem ha rj45 csatlakozóba beleerõszakolod. Egyébként ha ha SFP-t használsz a kontroller oldalon a switch oldalon még nem szükséges SFP ---> GLC-T


Remélem kielégítõek voltak a válaszaim.


Üdv:
Imre

[Nemes Dániel]

@Immy: évek óta nem mondjuk, hogy ne volna titkosított az adatforgalom is a Cisconál (pont azóta, hogy megcsinálták). Azt viszont továbbra is mondjuk, hogy a Cisconál a dekriptálás megtörténik az AP-n, legfeljebb utána újra visszacsomagolja, de ennek teljesímény-, RF-vezérlés, üzemeltethetõségi, biztonsági és értékõrzési hátrányai egyaránt vannak.

Az Arubánál van a klasszikus mód, amikor teljesen vékony AP-ként a 802.11-es frame-eket betolja a titkosított csatornába, és beküldi a kontrollerbe (mi továbbra is ezt javasoljuk, ui számtalan architekturális, teljesítmény- és biztonsági elõnnyel jár). Ezen felül létezik ún. decrypt tunnel mód, ami a Ciscoéval egyezik meg (tehát itt nincs architekturális különbség ebben a tekintetben), és létezik local bridging mód, ami a HP/Colubris irány. A H-REAP-pal leginkább a local bridging hasonlítható össze, vagy pedig a Remote AP üzemmód (ez már a negyedik architekturális verzió, amit az Aruba támogat). Ötödik megoldásként az Arubánál lehet központilag menedzselt, telephelyenként összefüggõ rendszerként üzemelõ Instant Enterprise AP-ket telepíteni, ami szintén nem küldi be a forgalmat a központi kontrollerbe. Hogy az adott feladatra az öt architektúrából melyik alkalmas leginkább, azt a konkrét követelmények alapján lehet megítélni, de a H-REAP-nál mindegyik mérföldekkel jobb (a campus/localnál nem mindegyik), és ebbõl csak 2 tunnelez be mindent a controllerbe.

Nyilván ha nem tolod be a forgalmat a controllerbe, akkor az sem a Cisconál, sem az Arubánál nem szempont, de amikor két autó teljesítményét hasonlítod össze, akkor sem azt az esetet vizsgálod, amikor mégis inkább buszra szállsz . Campus esetben -és ez az általános- igenis bemegy minden a kontrollerbe (legalábbis még a Cisco is ezt javasolja), tehát a teljesítménynek van szerepe, sõt.

Azt nem tudom, ki vagy, de azért az világos, hogy láttál már Cisco WLAN-t, így talán azt is tudod, hogy a H-REAP egyáltalán nem hasonlítható össze a campus (Cisco terminológiával local) üzemmóddal, pl. Wireless IPS-t, ACL-eket, Layer 3 roamingot sem tud, kis túlzással csak az autonóm AP-k központi menedzsmentjét jelenti.

Az árakról szerintem felesleges vitatkozni, listaárakat írtam mindkét gyártónál, az pedig a beszerzésen dõl el, hogy ki mut tud kialkudni. Egyébként az Aruba listaára alacsonyabb, mint az általad idézett, a kontrollerre vonatkozóan 55% engedményt tartalmazó ár (ami diszkontot valószínûleg nemigen fogsz itthon megkapni).

Az SFP-kérdést szerintem félreértetted. Ha 8 gigát ki akarsz szedni egy 5508-asból, akkor 8 SFP modult kell beleraknod (én úgy tudom, és a data sheet is azt mondja, hogy RJ45-höz is kell transceiver). Viszont switchportból is elvisz 8-at, és ez is pénzbe kerül. Ezzel szemben az Aruba 72xx-nél 1 port elég a 8 -illetve persze 10- giga átviteléhez, igaz, annak nyilván 10 gigásnak kell lennie, de ez még mindig olcsóbb, egyszerûbb és gyorsabb (és akkor még ott van a többi 10 gigás port).

Ami az "ac-Ready"-séget illeti, a draftokból már lehet tudni, hogy milyen funkciókat kell majd tudnia. Legalábbis a HW tervezés szintjén ez már eldõlt. Nyilván a pontos szoftveres követelmények a végleges standard alapján lesznek meghatározva, és várhatóan akkor jön ki majd az Aruba a final firmware-el. Ha bizonyos más gyártók, khm, fenntarthatnak egy slotot az AP-ikben, amibe majd -elvben- lehet .ac-s rádiót tenni, és ezt hívhatják .ac-readynek (muhaha), akkor szerintem egy hardveresen teljesen alkalmas kontrollert legalább annyira lehet annak nevezni.

Érdekes egyébként a vita, köszönöm! Még ha nem is fogadom el az érveid nagy részét, legalább érvelünk, és ez kellemes és hasznos!

[didyman]

Kellemes és hasznos lenne, ha nem az áldott jó marketing akarna meggyőzni újfent arról, hogy mi a frankó, aztán nem tudom, majd hasonló apróságokra hasonló bőkezűséggel fogtok reagálni, mint azt Jahnoéknál tettétek? Én nem mondom azt rögtön, hogy ez nem lesz jó, csak ha komoly cégnek akartok tűnni, legalább a hozzáértőket ne féligazságokkal akarjátok meggyőzni és legyen felkészült a terméktámogatás, mert amikről folyni szokott a vita, abból valahogy az jön le, hogy vagy nagyon felkészült vagy és ezért kezeled jól a marketinget, vagy a másik lehetőség.. A terméket pedig nem a márkanév fogja eladni, hanem az, ahogy ti formáljátok az arculatát. Biztos bejön, biztos el tudtok adni itthon, csak aztán az ilyen rövidebb távú sikerekből lehet később nagyokat veszteni.

[didyman]

Ádám, az a színes kördiagramos kép az miről szól? Mert látni semmit sem lehet belőle .

[Jahno]

Idézet: didyman - Dátum: 2012. 12. 19. 07:02

Kellemes és hasznos lenne, ha nem az áldott jó marketing akarna meggyőzni újfent arról, hogy mi a frankó, aztán nem tudom, majd hasonló apróságokra hasonló bőkezűséggel fogtok reagálni, mint azt

Én meg már ebben is elveszek, csak a wifi egy olyan külön témakör, hogy rendesen utána kellene járni, okoskodni, tanulni, kísérletezni. Egyszerű gyerek vagyok, ha valaki az egász irodát tokvonóval wifisre szeretné marketingelni, akkor megfogok elsőre 50 eszközt, aztán hajrá. Nomost ha az első 3ból kettő nem működik, nekem meg valami hülyeséget mondanak, akkor az gáz.

Többi meg nem annyira a fórum témája, lehet fele poénnak készült, én abban a pozícióban viszont nem voltam vicces kedvemben

[Nemes Dániel]

@didyman: tudnom kéne valamirõl, amirõl te tudsz? Mi történt Jahnoéknál? Hol vannak féligazságok? Azt pedig mindenki megítélheti magának, hogy én felkészült vagyok-e; mindenesetre az én felkészültségem szintje a termék minõségét nem befolyásolja, legfeljebb azt, hogy én mennyire könnyen/nehezen/sehogy tudom meggyõzni a vitapartneremet.

Szóval kérlek, maradjunk a konkrétumoknál! Ha bármelyik állítással vitatkoznál, hajrá! Ha kérdésed van, ne fogd vissza magad!

A képen a controller dashboardja látható, ahol a forgalom userenkénti pillanatnyi megosztása, az eszköztípusok megoszlása (Win X, OSX, WinMo, Android, stb), az célok megoszlása (salesforce, facebook, box.net, stb), az alkalmazások megoszlása (a képen megintcsak salesforce, facebook, stb, de itt lehetne pl. Lync, SAP, logmein, stb is), SSID szerinti megoszlás és a userek role-jai (ami lehet analóg az AD csoporttagságukkal, vagy pl. corporate-phone-guest) van a kördiagramokon. Ezen látszik az alkalmazás-felismerés, ami alapján lehet priorizálni. A lényeg, hogy a többi WLAN-tól eltérõen nem csak a layer 2-3-al foglalkozik, tisztelet a kevés kivételnek, amelyik valamennyire layer 1-el is, hanem layer 4-7-el, ami ráadásul visszanyúl a layer 1-be. Szerintünk ez elég frankó olyan helyen, ahol az üzembiztonság és a szolgáltatásminõség fontos.

[Jahno]

Idézet: Nemes Dániel - Dátum: 2012. 12. 20. 00:06

@didyman: tudnom kéne valamirõl, amirõl te tudsz? Mi történt Jahnoéknál?

Kinyitotta a Dell* noteszét, oszt nem ment rajt a wifi*. Kivételesen csak az Arubával* volt ilyen opció, máshol* nem tapasztalt ilyet, benne meg a szokásosnál több kisfröccs* volt, azóta utálja* a terméket**.

*bizonyos dolgokat kénytelen voltam fantázianévvel illetni, idő homályában a márkák és az opciók is elkoptak, lehet nem Dell, lehet nem wifi, vagy éppen Arubán, a többi meg már a múlt titka. Én elgondolkoznék rajt, hátha hasonlít a sztori térben és időben valamire.

** termék: http://qnadam.hu/vid/30s_arc.wmv

[Nemes Dániel]

@Jahno: nekünk (és az integrátornak) akkor azt mondtad, hogy az ügy megoldódott. Ha nem így lett volna, küzdünk még vele. Azt is mondtad, hogy neked ez tetszett a legjobban. Meg azt is, hogy nem ti döntöttetek, hanem egy fõnök Amerikában. Szerencsére nem sokszor veszítünk, így minden egyes eset dühít - ez is, 2 vagy 3 év távlatából is. Egyébként lehet, hogy szerencsétlen egybeesés, de a Dell Arubát használ. Akárhogy is, ez hogy jön a cikk tartalmához?

[Jahno]

Idézet: Nemes Dániel - Dátum: 2012. 12. 20. 01:08

Akárhogy is, ez hogy jön a cikk tartalmához?

Ahogy a kisfröccs.

[didyman]

Idézet: Jahno - Dátum: 2012. 12. 20. 01:21

Ahogy a kisfröccs.

Mi Arubán fröccsöztünk? Mikre nem emlékszem. Nekem csak a sör és a projektor volt meg, jó messzire sikerült repülni akkor aznap este!

[Socket]

Örülök, hogy a Maunikasó visszatért. Immár fórum változatban.