Programma van Eisen Netwerk Infrastructuur

[Verwijderd]

Sorry voor de vorige mislukte post

Terzake .....

Zijn er misschien mensen die zojuist een nieuw netwerk hebben laten aan leggen / aangelegd ?

Ik bedoel dan grotere netwerken van minimaal 2 core switches en een stuk of 50 front-end switchs-stacks bestaande uit 3 of 4 stackable switches.

Wij gaan namelijk binnekort beginnen met een europese aanbesteding van onze LAN componenten en gaan ook zelf de eerste opzet maken voor een programma van eisen.

Ik heb een dergelijk traject een jaar of 4 geleden al een keer meegemaakt en we hebben toen een extern bureau ingehuurd die ons technisch en juridisch bij heeft ondersteund. (juridische gedeelte nu ook natuurlijk)

Nu willen we eerst zelf een opzet maken voor het programma van eisen, omdat je daar het meest van leert. Dat neemt niet weg dat we ook van anderen kunnen leren !

Ik ben nieuwsgierig naar architekturen van netwerken, gebruikte apparatuur, concepten waar voor is gekozen is en natuurlijk waarom. Ook ben ik geinteresseerd in de huidige mogelijkheden.

Ik heb weinig zin om de productlijnen van 3com, Cisco en Nortel uitvoerig te gaan bestuderen, omdat dit meestal voornamelijk commerciele specs zijn. Ik hoor liever een beheerder vertellen over zijn/haar ervaringen met producten. (hoe geweldig of juist niet het wel niet is


Wat gebruiken jullie dus ?
- spanning tree
- rapid spanning tree
- OSPF
- VLANS (User based, port based, MAC based, network based ???)
- support contract ? (op alles 24x7 of alleen op de core, carry in met spare parts ?)
- De belangrijkste selectie criteria

Zodra wij wat op papier hebben staan post ik het hier ook. we starten hier over 2 a 3 weken mee.

Ik ben benieuwd !

[Verwijderd]

Ik zou van jou kant toch graag een eigen opzet willen zien. Zo'n topic is prima (en erg leuk ) maar je moet wel iets hebben om over te spreken. Ik stel dus voor dat je toch eens een hele grove schets op papier zet met één of meer scenario's en bijvoorbeeld series van bepaalde apparatuur.

En daarnaast mis ik een duidelijke beschrijving van de eisen. Er zijn zóveel mogelijkheden en zóveel kanten die je opkunt met bepaalde apparatuur dat je toch echt harde eisen op tafel moet gooien.

Kortom; ik zie graag wat meer input om er een zinvolle discussie van te maken en geen opsomming van netwerksituaties

[kell.nl]

Ik zou ook nog graag (als toevoeging wat JSS wil zien) willen zien hoe het eea geografisch uitziet.
Dus aantal poortjes per locatie, mogelijke verbindingen tussen de locaties e.d.
Tevens zou een lijstje met eisen van het nieuwe netwerk ook niet slecht staan. (denk aan benodigde bandbreedte / mate van redundancy e.d.)

1 kleine tip alvast: Voor beheer is het het makkelijkst om iig alleen apparatuur te nemen van 1 leverancier. Dus niet een Cisco core, met HP edge switches.

[Routed]

Dan gaat ik alvast beginnen door er een voor jouw relevant gedeelte van ons netwerk er uit te lichten:

De core:
4 Cisco 6509's verdeelt over 2 hoofdlocaties in paren van 2.
De opstelling is in een ring waarbij de switches die op dezelfde locatie staan met mm-fibers gekoppeld zijn (2stuks in een channel). De kopeling tussen de locaties om de ring te sluiten is sm-darkfiber.

Om de ring in bedwang te houden maken wij gebruik van gemanipuleerde stp settings, we willen nml erg graag zelf bepalen wie de rootbridge is en welke poort blocked staat. Hier hebben we niet echt zwaar over nagedacht, de volgorde is bepaald aan de hand van de kwetsbaarheid van de ser's waar het instaat .

Vlan technisch is het bij onz niet zo spannend, met 16 stuks heb je het wel gehad, om het verkeer in goede banen te leiden is er gekozen voor OSPF als routing protocol. Dit meer om te kunnen aanhaken bij een overkoepelende organisatie.
Het routeren in de core wordt gedaan door de layer3 module die in de 6509 zit.

Uiteraard zitten de redundante voedingen van de 6509's op aparte spannings groepen aangesloten en op een nobreak.

Qua support hebben we een 4uurs response (kan ook herstel zijn, daar houd ik me niet mee bezig) contract bij de KPN. Deze hebben 2,5 jaar geleden ook de spullen geleverd (consultancy/montage/configuratie).
Van de configuratie hebben ik en mijn collega's weinig meer overgelaten in de loop van de tijd.

de wireclosets:
(voldoet mischien niet helemaal aan jouw criteria)
55x Cisco 3550 24/48p verdeelt over 9 ser's in oneven aantallen (zijn ruimtes bij waar er 10 hangen sommige maar 3).

Deze zijn dmv dot1q gbit trunks gekoppeld aan de bovengenoemde 6509's, hier gaan alle vlans overheen.

Redundantie en snelle convergie als er een uplink uitvalt vangen we op door uplinkfast te configgen op de onderste switch in de stack (waarvan we ook graag een bepaalde poort in blocking willen hebben om makkelijk de stack te kunnen uitbreiden ).

De userpoorten zijn dmv de portfast en bpdugaurd commando's dusdanig ingesteld dat ze alleen pc's willen zien op de porten. Portfast is dus om de 50sec te omzeilen die een port normaal nodig heeft om "op" te komen, dit leverd nml nog wel eens dhcp problemen op .
BPDUguard houd in de gaten of er niet stiekum een bpdu pakket langskomt (wat dus zomaar een andere switch kan zijn en dus een potentiele "loop" in je netwerk).

de rest:
Magoed, dit is dus het hart van het netwerk, aan de 6509's zitten nml ook nog 2 cisco 7200's met 10 serieele poorten per router (in router per locatie) en 2 7200's met een isdn30 als backup (ook weer 1 per locatie).
Zo hebben we een mooie set van 2 6509's en 2 7200's (1ser en 1 isdn30) per hoofd locatie.

Hieraanvast zitten 10 sub-hoofd locaties die elk 2 2mit verbindingen hebben naar de hoofdlocaties.
En aan die sub-hoofd locaties zitten weer alles bij elkaar zo'n 40 cisco 2503's vast op bij-locaies met snelheden tussen de 128kbit en 2mbit serieel, als backup zit er een isdn2 draad aan vast die naar de hoofdlocatie gaat anders dan waar zijn sub-hoofd locatie aan vast zit met zijn 2mbitter (kan je het nog volgen)?.

uiteindelijk zijn we dan bij de +-100 cisco 2950's en een hele batterij (200+) aan 3com hub40/50 switch 1100/3300 aangeland welke geen noemenswaardige config hebben op een ip en een password na aangezien ze niet redundant zijn en er op die locaties toch maar 1 vlan is.
De bedoeling is dat alle 3coms eruit gaan binnen nu en 5 maanden en vervangen worden door C2950's.

De keuze voor de equipment was redelijk simpel, er bestaat nml een hw portfolio waar wij ons aan moesten houden, en afgaande op wat wij nodig hadden zijn daar de 2950/3550/6509's uitgerold.

Een goed lezer heeft mischien al gelezen dat wij onderdeel zijn van een nog groter netwerk, dat klopt:)
Wij zijn een automoom stubje zegmaar, we zijn gelukkig aan niemand verantwoording schuldig mbt netwerk handelingen behalve als er gekoppeld moet worden buiten ons ip-domain en als er nieuwe spullen gekocht moeten worden.

owja ergens daartussen in zwerfen nog 4 sets van cisco 515EUR pixxen in failover configuratie (totaal 8 dus), deze verzorgen vpn connecties tussen een aantal locaties en doen aan basaal filteren van wat wel en wat niet mag richting bepaalde delen van het netwerk.

Verbindingen zijn kpn 2mbiters of lager (digistream oid), niets spannends aan eigenlijk (dat soort verbindingen boeien me ook erg weinig) en een setje darkfiber tussen de hoofdlocaties.

Apparatuur, als we dalijk klaar zijn met de migratie alleen nog maar cisco, hiervoor gemengd cisco/3com.

Op geen enkele 3550/2950 hebben we een support contract, hiervoor hebben we een aparte stapel spares staan.

Belangrijke aandachts punten zijn oa (vind ik)

Goed afsluitbare patchkasten, het liefst van het zelfde merk ivm de sleutels (wij lopen nu met een enorme bos aan sleuteltjes rond vanweg alle verschillende type patchkasten).
Spannings sloffen zonder aanuit schakelaars, die dingen gaan een keer om, daar kan je op wachten.
Klimaat controle, te heet vinden switches en routers niet fijn.
Genoeg patchkabel geleiders en horizontale ogen, anders wordt het al heel snel een zooitje in je kasten.

Ik hoop dat deze post een beetje voldoet aan je eisen van een reply, mocht je nog vragen hebben die ik kan beantwoorden dan lees ik dat wel.

[ Voor 3% gewijzigd door Routed op 22-01-2004 00:13 ]

[Verwijderd]

Deff bedankt voor je reactie. Je maakt een schets van jullie situatie. Ik ben eerlijk gezegd ook een voorstanden van Cisco Hardware. Ook omdat de meeste tools hiervoor geschikt zijn en omdat Cisco marktleider is.

Op dit moment hebben we een aantal 10,100 en 2mbit verbindingen naar dislocaties. De router verbindingen (2mbit), alsmede onze firewalls zijn allemaal van Cisco. Het switching gedeelte is geheel 3com. (Corebuilder 9000 met 1100,3300,4400 switches.).

Het liefst zou ik hier een post zien van een programma van eisen dat is gebruikt voor een aanbesteding. De vragen van de andere 2 reacties dat ik meer moet specificeren wat ik wil, heb ik natuurlijk niet zo veel aan. We willen juist een programma van eisen op stellen. Hierin wil je natuurlijk dat je netwerk de laatste nieuwe (uitgekristaliseerde) features heeft of kan ondersteunen.

Ik zal proberen toch een paas minimale eisen te noemen.

- Dislocaties met met gebruikers varierend van 10-60 gebruikers.
- WAN verbindingen staan hier boven (probleem is dat we ook een aanbesteding van WAN verbindingen aan het doen zijn, misschien komt hier volledig dark fiber uit. men wil hier niet op wachten. gisteren hoorde ik ook nog dat er een a la surfnet oplossing doorheen loopt. (scholen, gemeente e.d.allemaal op 1 glasvezel netwerk (zelf graven of overnemen)
- Hoge mate van redundantie (standby links, voor dislocaties backup ISDN lijnen b.v.)
- Hoge mate van flexibiliteit. (uitbreidingen van de core)
- Apparatuur die de komende 3 jaar niet end-of-life wordt verklaard, zoals onze huidige 3com cb9000 na 1 jaar !
- liefts een 10gbit backbone (als er geld voor is, afhankelijk dus van de prijs)
- alles op 1 merk front-end en core
- Goede netwerkmanagement tool a la cisco works en hp ov
- enz enz

[ Voor 39% gewijzigd door Verwijderd op 22-01-2004 09:52 ]

[ijdod]

deff schreef op 22 januari 2004 @ 00:11:
Dan gaat ik alvast beginnen door er een voor jouw relevant gedeelte van ons netwerk er uit te lichten:

De core:
4 Cisco 6509's verdeelt over 2 hoofdlocaties in paren van 2.

Het grappige van deze (by the book) config is dat je een interessant probleem gaat krijgen zodra je de capaciteit van die dingen gaat gebruiken. Zeker met de nieuwe 720 supervisors, waarmee de backplane capaciteit 720 Gbit wordt, wordt het grootste probleem het fatsoenlijk koppelen van twee die dozen. Zelfs met een channel van meerdere 10 Gbit ethernet is het nog een bottleneck. Om die reden hebben wij er voor gekozen om 1 chassis te nemen, met daarin een dubbele supervisor. Dat chassis hebben we zelf op spare. (6513, ipv 6509, dat wel).

Ook daar is bij ons een stuk evolutie in denkbeelden en beschikbare apparatuur zichbaar, de eerder gemigreerde vestigingen zitten op een paar 6509's elk.

Doordat we niet met een schone lei kunnen beginnen is de ring tussen de vestingen nu op laag 2 actief, waarbij 1 link door STP in blocking staat. rootswitches zijn expliciet geconfigureerd. Uplinkfast waar van toepassing, evenals backbone fast. RSTP staat in development.


We zijn bezig de boel te migreren naar een laag 3 model, met EIGRP als routing protocol. Ons nummerplan is overigens ook geschikt voor OSPF.

Vlans hebben we een stuk ook 100 van (don't get me started...), hetgeen soms leuke issues geeft met wat oudere en/of simpelere switches.

Voor de wiring closets hebben we 3500XL's of 2950's. 3550 zijn daar overkill, zeker gezien de uplink van maar 1 Gbit. In SER's waar er meer dan 1 switch zit, zijn alle switches individueel bekabeld naar de MER. Gigastack is door ons gewogen en zaad bevonden . Anno nu zou ik serieus kijken naar 3750's in de SERs, die zijn voor stacking ERG interessant (en duur...).

Aanbestedingen zijn leuk (NOT), maar er zijn een hoops truuks om dat te krijgen wat je wilt (inclusief de leverancier ).

Klimaat controle, te heet vinden switches en routers niet fijn.

Uit principe mee eens, maar als je de specs er op na leest, kunnen die dingen een hoop hebben, aanmerkelijk meer dan bv servers.

Genoeg patchkabel geleiders en horizontale ogen, anders wordt het al heel snel een zooitje in je kasten.

Wordt het toch wel . Heb maar 1 keer een kast gezien die na 3 jaar met dagelijkse patchwerkzaamheden nog strak was. Elke kabel was op maat gemaakt...

[ijdod]

Verwijderd schreef op 22 januari 2004 @ 09:45:
- Goede netwerkmanagement tool a la cisco works en hp ov

Heel erg belangrijk: wat wil je er mee doen?

Om CW en OV goed te gebruiken kost zeer veel tijd, denk al snel aan een FTE (of meer). Als je met de commandline van Cisco overweg kan, heb je voor die werkzaamheden CW niet nodig; sterker nog, als je daar CW voor nodig hebt in een netwerk van dergelijk formaat, sta je op zeer dun ijs. Zelf prefereer ik simpele tools die een bepaalde taak goed doen boven all-in tools die vaak meer kosten dan ze opleveren. Voorbeelden daarvan zijn oa. WhatsUp Gold, Nagios, MRTG, Kiwi syslog, enz enz.

CW2000 gebruiken we eigenlijk alleen voor het automatisch opslaan van configuraties, iets dat met wat discipline ook prima handmatig (tftp servertje) kan, en logging. Om met die laatste echt wat te doen (wat CW wel kan) ben je zeer veel tijd kwijt. Als CW morgen zou overlijden, denk ik niet dat we echt hard gaan rennen om eea in de lucht te krijgen.

[Verwijderd]

Bedankt voor de reply ijod. Ook jij maakt een schets van jullie situatie. Ook een heleboel cisco switching termen als fastuplink en gigastack zeggen mij (op dit moment) niet veel. No offense by the way....all info is welkom.

Ik had in dit topic alleen eerder een post verwacht van iemand die zojuist een traject achter de rug heeft van een nieuw netwerk en die een goed programma van eisen daar voor had geschreven.

Omdat het een europese aanbesteding is kunnen we niet direct zelf voor een merk kiezen. Men noemt mij hier al de cisco freak, maar omdat we hier al 3com hebben en er onlangs al weer een verkoper is langs geweest die bereid was om een hele scherpe inruil actie te regelen zullen we met hele scherpe eisen en dergelijke moeten komen om toch een Cisco netwerk te krijgen. Zeker omdat bij mijn werkgever (lokale overheid) geld altijd de belangrijkste rol speelt.

Je kan helaas in een EU aanbesteding niet zetten dat het appraat in een donkerblauw chassis moet zitten met rode letters en brug als opschrift.

Ook streven we geen proprierty protocollen na, maar juist open protocollen
Het is dus ook geen optie om cisco protocollen als eis te stellen.

Allemaal moeilijk moeilijk moeilijk. Het mooiste resultaat zou een PvE zijn waar dusdanige eisen in staan, dat er alleen maar een cisco netwerk uit rolt.


maar ja ....dromen mag.....

[ijdod]

Verwijderd schreef op 22 januari 2004 @ 16:26:
Je kan helaas in een EU aanbesteding niet zetten dat het appraat in een donkerblauw chassis moet zitten met rode letters en brug als opschrift.

Mijn ervaring met uitbestedingen is dat er toch vaak min of meer letterlijk in staat dat het een bepaald merk moet zijn, bijvoorbeeld omdat men op dat merk gestandaardiseerd is. Verder kunnen randvoorwaarden een rol spelen, zoals beschikbaarheid van support en dergelijke. Vooral dat laatste is waar Cisco scoort (hint )... Het helpt niet echt als er voor het minste of geringste een engineer uit Israel over moet komen (Avaya, anyone?).

Alternatief is een stappenplan van meerdere kleine acties die onder de uitbestedingsgrens blijven.

Beiden zijn voorbeelden die mogelijk niet legaal zijn, maar wel met succes gebruikt worden door jullie collega overheden.

Dan is er nog de mogelijkheid op uit de inschrijvingen precies dat te kiezen wat je wilt hebben. Dat werkt natuurlijk alleen als mensen met verstand van zaken bij de selectie betrokken worden, niet alleen de bonentellers en managers zonder verstand van zaken.

[ Voor 13% gewijzigd door ijdod op 22-01-2004 16:57 ]

[Predator]

Verwijderd schreef op 22 januari 2004 @ 16:26:
Ook streven we geen proprierty protocollen na, maar juist open protocollen
Het is dus ook geen optie om cisco protocollen als eis te stellen.

Zoveel is er nou ook niet Cisco-proprietary, en de 'open protocollen' worden ook meer gebruikt. Zo zal je meer 802.1q trunking vinden dan ISL, en meer OSPF dan E-IGRP enz ...

Cisco heeft wel de neiging om open protocollen toch even met wat Cisco saus te overgieten. Ze wijken meestal niet veel van de open standaard af, en meestal zijn het zeer welkome toevoegingen, maar toch ...

Allemaal moeilijk moeilijk moeilijk. Het mooiste resultaat zou een PvE zijn waar dusdanige eisen in staan, dat er alleen maar een cisco netwerk uit rolt.

Je hoeft eisen niet alleen alleen in puur technische specificaties te zien.
Beheersbaarheid en standardiseren kunnen evenveel doorwegen als technische specificaties en prijs (helaas doen ze dat niet altijd).

Ik ben zelf hevig tegenstander van productmenging. Ik ga niet beweren dat als je een homogene Cisco omgeving heb je minder problemen gaat hebben, maar ik ga wel beweren dat je ze dan vaak sneller kan oplossen.

Als je dan es anderhalf uur kwijtspeelt aan een vaag probleem tussen een 3com baseline switch en een Catalyst 4506 een tijdens een grote migratie, dan heb je het wel even gehad.

Om CW en OV goed te gebruiken kost zeer veel tijd, denk al snel aan een FTE (of meer). Als je met de commandline van Cisco overweg kan, heb je voor die werkzaamheden CW niet nodig; sterker nog, als je daar CW voor nodig hebt in een netwerk van dergelijk formaat, sta je op zeer dun ijs. Zelf prefereer ik simpele tools die een bepaalde taak goed doen boven all-in tools die vaak meer kosten dan ze opleveren. Voorbeelden daarvan zijn oa. WhatsUp Gold, Nagios, MRTG, Kiwi syslog, enz enz.

CW is vooral handig voor het aanpassen van bv paswoorden of SNMP community strings e.d. (naast de vermelde configuratie & archiverings functies) in omgevingen met heel veel toestellen. Je kan ze dan snel allemaal tegelijk aanpassen.

Maar broodnodig heb je het inderdaad meestal niet.

HP OV NNM biedt echter wel veel meer dan je ooit met WhatsUp Gold, Nagions en MRTG gaat bereiken. Het vreet inderdaad wel veel tijd om te fine-tunen, maar dan heb je ook wel een NMS systeem wat je niet meer kan missen.

[ Voor 5% gewijzigd door Predator op 22-01-2004 21:18 ]

[Verwijderd]

Ik principe heb je geen enkel software pakker nodig (als cw of ov) als je en echte die hard cisco man bent, maar ik vind wel dat cw vooral het leven erg makkelijk maakt.

Ik zou gewoon eens bij een cisco gold partner navraag doen wat de meste mogelijkheden zijn voor jullie, sla's op laten stellen en meer van dat soort dingen.

Wij hebben dit bij Getronics laten doen waar enorm veel echte cisco goeroe's zitten... niks dan lof.
Momenteel zijn we bijna klaar met de complete migratie, op oude cisco 5000's na, de worden ook nog vervangen door 3550's.
In totaal hebben we dan Core, 2 x 6509 met redundante supervisor kaarten, 2 x 5500's als ser plus 50 3550's.

Channel opgebouwd tussen de 2 mer's wat perfect werkt.
overal hotstandby aangebracht, uplinkfast/backbonefast, ospf bijna overal uit gezet behalve in router vlan, syslogging naar de cw server, snmp traps ook.

kortom, een tot nu toe perfect en snel en stabiel netwerk.

En vergeet trouwens als software niet het pakket Solarwinds, ook hier kan je heeeeel erg veel leuke dingen mee doen......

[ Voor 9% gewijzigd door Verwijderd op 22-01-2004 21:28 ]

[Predator]

Verwijderd schreef op 22 januari 2004 @ 21:27:
Ik principe heb je geen enkel software pakker nodig (als cw of ov) als je en echte die hard cisco man bent, maar ik vind wel dat cw vooral het leven erg makkelijk maakt.

HP OV heeft helemaal niets met Cisco te maken...

---

Ik sluit mij overigens aan bij JSS dat een duidelijke situatie schets hier noodzakelijk is.

Je begint ook al over apparatuur te praten voordat je technische eisen bepaald zijn, en je praat over technische eisen voor je praktische eisen bepaald zijn.
Ik lees ook dat je WAN structuur blijkbaar nog niet vast ligt ?
Dat helpt natuurlijk ook niet bij het opstellen van je eisen pakket

[ Voor 38% gewijzigd door Predator op 22-01-2004 21:40 ]

[Verwijderd]

Predator schreef op 22 januari 2004 @ 21:33:
[...]



HP OV heeft helemaal niets met Cisco te maken...

Dat klopt wel, ik bedoelde meer dat een echte switch/router goeroe heb je geen sw pakket daarvoor nodig, dan werk je zelfs sneller via console.

[Vergeten]

Denk bij de beschikbaarheid goed na over wat noodzakelijk is! Je wilt waarschijnlijk geen 7x24 betalen...
Daarnaast is de MTTR (mean time to repair) belangrijk: hier is bijvoorbeeld 4 uur al een dure tijd. Voor componenten waarvoor een grotere beschikbaarheid nodig is moet je gaan voor redunantie of zelf iets op de plank hebben staan.
Bij ons is levertijd ook een vast onderdeel en of het mogelijk is de spullenboel door een ander dan de leverancier te laten beheren (en wat dat meer kost)
En nog een tip: in plaats van een extern buraeu kun je ook eens kijken bij andere overheden. Kun je een hoop knippen en plakken.
Daarnaast zou ik er toch voor kiezen om een functionele vraag te stellen en de leveranciers een ontwerp te laten maken, dat kun je dan tegen je eigen ontwerp aan houden.
Geef ook aan dat aanbiedingen in het geval van cisco inclusief fee moeten zijn, is anders moeilijk te vergelijken.

[Maarten @klet.st]

Predator schreef op 22 januari 2004 @ 21:17:
[...]
CW is vooral handig voor het aanpassen van bv paswoorden of SNMP community strings e.d. (naast de vermelde configuratie & archiverings functies) in omgevingen met heel veel toestellen. Je kan ze dan snel allemaal tegelijk aanpassen.

Met enige scripting kun je ook dit soort handelingen ook makkelijk zonder CW doen. Persoonlijk vind ik dat je het geld dat je met CW kwijt bent beter kunt investeren in tijd om het via commandline en scripting te doen. Het grote voordeel is dat je daardoor veel beter weet waar je mee bezig bent en dat komt het beheer (zeker bij incidenten/calamiteiten) ten goede. Beetje vervelend als een aantal beheerders alleen CW snapt en je een probleem niet met CW kunt verhelpen.

Probleem kan zijn om je meerdere daarvan te overtuigen. Sommigen gaan nou eenmaal liever voor een gekocht product of mooi gekleurde kliktools..

HP OV NNM biedt echter wel veel meer dan je ooit met WhatsUp Gold, Nagions en MRTG gaat bereiken. Het vreet inderdaad wel veel tijd om te fine-tunen, maar dan heb je ook wel een NMS systeem wat je niet meer kan missen.

Ik heb geen ervaring met OV, maar hiervoor geldt grotendeels hetzelfde. Voordeel van OV ten opzichte van CW is dat het een stuk meer merk onafhankelijk is (voor zover ik begrijp) en daardoor in hetrogene omgevingen (liever niet natuurlijk..) als een all-in-one NMS systeem gebruikt kan worden. Ook hier is de voorkeur voor 'doe-het-zelf en verhoog je clue' of vendor-supported enterprise producten vaak de belangrijkste factor om voor een van de twee te kiezen.

My 2 cents over netwerkbeheer..

Maar om toch ff bij het topic te blijven; ik vrees dat de TS toch niet helemaal gaat krijgen wat hij wil. Grote organisaties waarin PVE's gemaakt worden stellen het meestal niet op prijs als deze publiek gemaakt worden. Hetzelfde kan gelden voor uitvoerige/gedetailleerde beschrijvingen van IT architecturen.

Verder zal het meerendeel van de bezoekers aan dit forum meer in technische details denken dan in PVE's. Een schoolboek programma van eisen zou een meer functionele beschrijving van de eisen moeten bevatting dan een technische opsomming van gewenste features/eigenschappen. Je kunt wel heel hard roepen dat je Rapid STP wilt, maar eigenlijk hoor je te zeggen dat een aangesloten switchpoort binnen x seconden beschikbaar moet zijn of gebruikt moet kunnen worden voor clients die gebruik maken van DHCP. Dat blijft natuurlijk lastig, want ook DHCP is alweer een technische term .

Waar ik trouwens benieuwd naar ben is of beheerders gebruik maken TACACS/RADIUS of dat ze - ook in serieuze netwerken zoals in deze thread beschreven - toch liever lokale authenticatie gebruiken (en waarom).

[ Voor 5% gewijzigd door Maarten @klet.st op 22-01-2004 21:50 . Reden: quotefaut ]

[Predator]

Verwijderd schreef op 22 januari 2004 @ 21:35:
[...]


Dat klopt wel, ik bedoelde meer dat een echte switch/router goeroe heb je geen sw pakket daarvoor nodig, dan werk je zelfs sneller via console.

Wat heeft console hiermee te maken

Kijk even na wat een NMS want je weet volgens mij toch echt niet waar HP OV NNM voor dient.

Verder is het ook heel raar om CW te koppelen aan geringe Cisco of netwerkkennis aangezien je met die geringe kennis ook met CW niets gaat kunnen uitrichten. Beide staan redelijk los van elkaar.

Als jij dan ook nog eens sneller kan configuratie & software files kan archiveren en klasseren voor een hondertal toestellen dan CW, dan heb ik een job voor jou.

Maarten.O schreef op 22 januari 2004 @ 21:47:
[...]


Met enige scripting kun je ook dit soort handelingen ook makkelijk zonder CW doen. Persoonlijk vind ik dat je het geld dat je met CW kwijt bent beter kunt investeren in tijd om het via commandline en scripting te doen. Het grote voordeel is dat je daardoor veel beter weet waar je mee bezig bent en dat komt het beheer (zeker bij incidenten/calamiteiten) ten goede. Beetje vervelend als een aantal beheerders alleen CW snapt en je een probleem niet met CW kunt verhelpen.

Probleem kan zijn om je meerdere daarvan te overtuigen. Sommigen gaan nou eenmaal liever voor een gekocht product of mooi gekleurde kliktools..

Zoals ik al meermaals probeerde duidelijk te maken hoef je CW NIET te gebruiken voor configuratie aanpassingen omdat je ze niet via de commando lijn kan doen.

Verder kan ik je zeggen dat ik nog niemand heb zien terug keren van eigen gebrouwde tools naar professionele management producten.

Ik kan je ook zeggen dat men vaak uiteindelijk ervoor kiest al die scripts over boord te gooien omdat ze te veel onderhoud vergen.

[...]
Ik heb geen ervaring met OV, maar hiervoor geldt grotendeels hetzelfde. Voordeel van OV ten opzichte van CW is dat het een stuk meer merk onafhankelijk is (voor zover ik begrijp) en daardoor in hetrogene omgevingen (liever niet natuurlijk..) als een all-in-one NMS systeem gebruikt kan worden. Ook hier is de voorkeur voor 'doe-het-zelf en verhoog je clue' of vendor-supported enterprise producten vaak de belangrijkste factor om voor een van de twee te kiezen.

HP OV NNM is een NMS en geen element management systeem zoals Cisco.
Het is een geheel ander concept, en wordt ook heel anders gebruikt.

HP OV NNM en CW dienen naast elkaar gebruikt te worden.

[ Voor 59% gewijzigd door Predator op 22-01-2004 21:57 ]

[Verwijderd]

Vergeet niet dat als je zelf "spul op de plank" hebt liggen, dat dat een behoorlijke kostenpost kan zijn, dan kan je beter van te voren redundancy inbouwen in de core bijv.

Als je een sla hebt, zoals wij fix binnen 4 uur, dan heb je geen eigen investering in het netwerk, maar laat je het beheer-bedrijf alles in contract nemen zodat zij de vervanging zelf regelen.

[Verwijderd]

Predator schreef op 22 januari 2004 @ 21:47:
[...]

Wat heeft console hiermee te maken

Kijk even na wat een NMS want je weet volgens mij toch echt niet waar HP OV NNM voor dient.

Verder is het ook heel raar om CW te koppelen aan geringe Cisco of netwerkkennis aangezien je met die geringe kennis ook met CW niets gaat kunnen uitrichten. Beide staan redelijk los van elkaar.

Als jij dan ook nog eens sneller kan configuratie & software files kan archiveren en klasseren voor een hondertal toestellen dan CW, dan heb ik een job voor jou.

Ik kan je uit ervaring vertellen dat iemand via de console sneller een upgrade kan uitvoeren dan dat jij via cw kan doen hoor.
Tevens kan je heel veel zaken niet via cw doen, wat betekend dat je dan alsnog via telnet zal moeten configureren.

En aangezien wij alleen maar cisco apparatuur hebben, hebben we dus geen hp ov draaien, dus erg veel kan ik daar niet over mee praten.
Maar om te zeggen dat cw handig is voor backup van configs e.d. en aanpassen van snmp strings vind ik persoonlijk wel erg zwak, net alsof cw nergens anders voor te gebruiken is.

[Verwijderd]

Maarten.O schreef op 22 januari 2004 @ 21:47:
[...]

Waar ik trouwens benieuwd naar ben is of beheerders gebruik maken TACACS/RADIUS of dat ze - ook in serieuze netwerken zoals in deze thread beschreven - toch liever lokale authenticatie gebruiken (en waarom).

Voor alle vpn connectie's en inbellers gebruiken wij inderdaad radius.

[Predator]

Verwijderd schreef op 22 januari 2004 @ 21:52:
[...]


Ik kan je uit ervaring vertellen dat iemand via de console sneller een upgrade kan uitvoeren dan dat jij via cw kan doen hoor.

Tuurlijk voor 1 switch ga je dat ook niet via CW doen, maar voor 100 wel.

Tevens kan je heel veel zaken niet via cw doen, wat betekend dat je dan alsnog via telnet zal moeten configureren.

Nogmaals: CW is er niet voor jouw router of switch te configureren.

En aangezien wij alleen maar cisco apparatuur hebben, hebben we dus geen hp ov draaien, dus erg veel kan ik daar niet over mee praten.

Nogmaals: HP OV NNM is geen element management systeem maar een NMS, en heeft absoluut niets met Cisco te maken.

Ik heb het zelf gebruikt in een homogene Cisco omgeving.
Die 'dus' in je zin slaat dus kant nog wal.

HP OV NNM is _NIET_ de tegenhanger van CW voor HP netwerapparatuur

Maar om te zeggen dat cw handig is voor backup van configs e.d. en aanpassen van snmp strings vind ik persoonlijk wel erg zwak, net alsof cw nergens anders voor te gebruiken is.

Heb ik ergens gezegd dat CW nergens anders voor te gebruiken is dan

[ Voor 8% gewijzigd door Predator op 22-01-2004 22:06 ]

[Maarten @klet.st]

Verwijderd schreef op 22 januari 2004 @ 21:48:
Vergeet niet dat als je zelf "spul op de plank" hebt liggen, dat dat een behoorlijke kostenpost kan zijn, dan kan je beter van te voren redundancy inbouwen in de core bijv.

Als je een sla hebt, zoals wij fix binnen 4 uur, dan heb je geen eigen investering in het netwerk, maar laat je het beheer-bedrijf alles in contract nemen zodat zij de vervanging zelf regelen.

Dat is een simpele rekensom, lijkt me. Als je 40 Cisco 3550-48SMI's hebt (de 3500XL serie is niet meer leverbaar..), dan kan het zeer interessant zijn om er 1 in voorraad te hebben liggen. Meestal kost support je zo'n 11 a 12% van de aanschafprijs per jaar. Nou krijg vaak ook wel weer korting als je support afneemt, maar ook dat kun je in je calculatie opnemen.

Een gefingeerd voorbeeldje, met 20 switches van 5000 Euro.

Aanschafprijs (20x5000) = 100.000
Korting support (15%) = -15.000
3 jaar support (3x10% v 85.000) = 25.500

Dit kost je dus 110.500. Als je geen support neemt ben je 21x5000 kwijt, dus 105.000 euro. Er vanuitgaande dat je die spare terug kan vinden en deze niet
al gebruikt is heb je een defecte switch razendsnel vervangen. Uiteraard moet je die defecte switch dan wel vervangen en kost het je ook weer 5000 (of minder, als die dingen in de loop van de tijd goedkoper worden). Uitgaande van 5% uitval gaat je dit dus een extra switch kosten, die je ook 5000 kost, maar dan nog steeds is het goedkoper en ben je niet afhankelijk van responsetijd van je leverancier.

Bij 5 switches (en in 3 jaar afschrijven) gaat dit natuurlijk niet echt op, maar in sommige gevallen kan het een goed idee zijn om zelf spares te houden.

[Verwijderd]

Maarten snapt precies wat ik bedoel. en ik ben het ook met hem eens dat grotere bedrijven (waarschijnlijk als de onze) niet te koop lopen met pve's die niet voor het grote publiek bedoeld zijn.

Ik had pas nog hierover een discussie met mijn baas. Als klant van een netwerkleverancier kan je je met meerdere veel sterker maken dan wanneer je alles in je eentje uit doktert.

Nu gaan 3 organisaties bij een consultancy bureau ondersteuning "inkopen" a misschien wel 10-20 duizend euro, terwijl ze hetzelfde doel voor ogen hebben.

Die consultancy bedrijven worden slapend rijk ! zoek en vervang de naam van het bedrijf in hun WORD documentje en ze zijn weer 10.000 EUR rijker. (ok misschien lichtelijk overdreven maar toch).

Aangezien bedrijven nog steeds niet te koop lopen met hun PvE's zal iedereen (net als wij) het dus weer van een extern bureau moeten hebben.

Weet iemand of Cisco tegenwoordig ook zelf ook aanbestedingen inschrijft ? We hebben onlangs een aanbesteding voor een SAN achter de drug waar HP zelf op heeft ingeschreven. Doet Cisco dit ook ? Ik hoop dat Cisco een scherpe inruil actie heeft voor onze 3com spullen.

Ook is het nog eens zo dat we nu al een hele infrastructuur van 20x 2920 routers, 1x 7200 router, 2 PIX 515E's en 1x 3015 VPN Concentrator hebben staan. In principe hoeven die van mij niet te worden vervangen.

Wat voor opleidingen heeft men trouwens nodig voor een cisco netwerk ? Alleen CCNA of tot en met CCNP ? Wij hebben hier nog steeds geen enkele cursus voor gehad. Alles zelf aangeleerd of geleerd uit workshops. Mijn baas denkt nog steeds dat we te weinig Cisco spullen hebben staan Ok Ok we hebben veel meer 3com shit staan, maar dit spul is echt kinderlijk eenvoudig te configureren. de 4400's die we hebben zijn al iets interessanter. Van al die 1100's en 3300's kan je nog niet eens de config veilig stellen.

Nog steeds hoop ik op een PvE. Niet volledig maar voornamelijk de technische specificaties en waarom ervoor is gekozen. Waarom kiezen voor fastuplink en is dit iets van cisco ? Weet iemand ook waar je LEVERANCIERS onafhankelijk op de hoogte kan blijven van de laatste features en ontwikkelingen op netwerk apparatuur gebied ? Is er ook iemand die een PIX gebruikt voor internet firewalling ? Hoe wordt je, zoals bij virussen, op de hoogte gehouden van updates en patches ? Pas geleden zat er nog een bug in IOS 12 die DOS veroorzaakte ?

[Routed]

ijdod schreef op 22 januari 2004 @ 13:19:
[...]

Het grappige van deze (by the book) config is dat je een interessant probleem gaat krijgen zodra je de capaciteit van die dingen gaat gebruiken. Zeker met de nieuwe 720 supervisors, waarmee de backplane capaciteit 720 Gbit wordt, wordt het grootste probleem het fatsoenlijk koppelen van twee die dozen. Zelfs met een channel van meerdere 10 Gbit ethernet is het nog een bottleneck. Om die reden hebben wij er voor gekozen om 1 chassis te nemen, met daarin een dubbele supervisor. Dat chassis hebben we zelf op spare. (6513, ipv 6509, dat wel).

Dat gaat niet gebeuren, die 6509's draaien nu zo'n 2,5 jaar, momenteel draaien we op ongeveer 2% load
Die dozen zijn echt mega overkill, ze doen niets van een 3550 SMI nu niet zou kunnen doen laat staan een 2940 XL + goede router met 100mbit porten toendertijd.
De enige reden dat die 6509's er staan is dat bij de toko waar ik nu zit er 2,5/3 jaar geleden door de afdeling (windows) serverbeheer is geroepen dat ze er moesten komen en dat zij gbit links nodig hadden. Hierbij werd netwerkbeheer volledig overruled (van de toenmalig bezetting is er ook nog maar 1 over, bij de huidige had dit nooit niet gebeurd).
Resultaat is dat we dus nu een core hebben liggen met gigabit poorten naar diverse sers en een aantal servers, op een goede dag gaat daar 200/300 mb overheen . uitzonderingen zijn het exchange cluster en het fs cluster, maar ook hier blijft het beperkt tot pieken van max 140mbit/s...

owja, we draaien bijna alleen maar microsoft terminal services over het lan/wan, dat spaart nogal in verkeer en is tevens de reden van de lage belasting.

Verwijderd schreef op 22 januari 2004 @ 09:45:
Het liefst zou ik hier een post zien van een programma van eisen dat is gebruikt voor een aanbesteding. De vragen van de andere 2 reacties dat ik meer moet specificeren wat ik wil, heb ik natuurlijk niet zo veel aan. We willen juist een programma van eisen op stellen. Hierin wil je natuurlijk dat je netwerk de laatste nieuwe (uitgekristaliseerde) features heeft of kan ondersteunen.

Ik zal proberen toch een paas minimale eisen te noemen.

- Dislocaties met met gebruikers varierend van 10-60 gebruikers.
- WAN verbindingen staan hier boven (probleem is dat we ook een aanbesteding van WAN verbindingen aan het doen zijn, misschien komt hier volledig dark fiber uit. men wil hier niet op wachten. gisteren hoorde ik ook nog dat er een a la surfnet oplossing doorheen loopt. (scholen, gemeente e.d.allemaal op 1 glasvezel netwerk (zelf graven of overnemen)
- Hoge mate van redundantie (standby links, voor dislocaties backup ISDN lijnen b.v.)
- Hoge mate van flexibiliteit. (uitbreidingen van de core)
- Apparatuur die de komende 3 jaar niet end-of-life wordt verklaard, zoals onze huidige 3com cb9000 na 1 jaar !
- liefts een 10gbit backbone (als er geld voor is, afhankelijk dus van de prijs)
- alles op 1 merk front-end en core
- Goede netwerkmanagement tool a la cisco works en hp ov
- enz enz

Ah ik zie dat jullie het zelfde probleem als ons hadden, wij hadden hiervoor 9xCB5000, na 7 maanden pakte 3com hun boeltje in en vertrok uit nederland.
En wat betreft CW en HPOV, denk maar ffkes goed na wat je precies wil ermee, wij hebben het ook draaien (ietsmeer dan een jaar nu) en de keren dat CW gebruikt is zijn op 1 hand te tellen (en dan tel ik de sessies van ons 5 bij elkaar op ), telnet en cmd lines werken sneller, en voor een hoop dingen kan je macro's scripten die alles voor je doen.
HPOV als monitoring tool wordt wel veel gebruikt.

Je moet ook niet perse de laatste nieuwe features willen gebruiken, je wilt aangeven wat jullie wensen/eisen zijn mbt redundantie, downtimes, management, onderhoud, uitbereidings gemak, functie herstel tijden enz enz enz.
Een goed bureau zoekt daar dan een aduquate oplossing bij afgezet tegen de verwachtingen voor de komende 3 jaar.

Mischien ga je wel een MPLS core eisen met de 10gb uplinks en ga je er vervolgens net als wij MS TS of Citrix overheen draaien, dat zou toch wel zonde van de centen zijn.

de beste tip die ik je kan geven is om een wensen/eisen matrixje te maken.
Bedenk zoveel mogelijk functionaliteit die je in je netwerk wil hebben en bepaal dan (reeel en niet wat je zelf zo fijn/leuk vind) of het een wens of eis is.
Bouw hier dan vervolgens je PVE rond.

[Maarten @klet.st]

ijdod schreef op 22 januari 2004 @ 13:19:
[...]
Het grappige van deze (by the book) config is dat je een interessant probleem gaat krijgen zodra je de capaciteit van die dingen gaat gebruiken. Zeker met de nieuwe 720 supervisors, waarmee de backplane capaciteit 720 Gbit wordt, wordt het grootste probleem het fatsoenlijk koppelen van twee die dozen. Zelfs met een channel van meerdere 10 Gbit ethernet is het nog een bottleneck. Om die reden hebben wij er voor gekozen om 1 chassis te nemen, met daarin een dubbele supervisor. Dat chassis hebben we zelf op spare. (6513, ipv 6509, dat wel).

Nja, dit is dus een beetje een rare redenatie. Als het goed is kies je die switch/engine op basis van de verbindingen die je (nodig) hebt. Zo is een 6500 serie interessant als je behoorlijk wat poorten op een locatie werkt. Je kunt dan 2950's, 3550's of 3750's gaan stacken, maar beheersmatig blijft dat lastig en als je perse gigabit voor die vele poorten wilt is het ook niet rendabel.

Gezien de management features en het gebrek aan capaciteit/snelheid van de vorige supervisors is een 720 supervisor een logische keuze (voor hetzelfde geld
kun je een leuk autootje kopen, maar dat terzijde). Maar om dan vervolgens te te gaan controlleren of je alle bandbreedte die een 720 supervisor in theorie kan verstouwen wel kan transporteren is een beetje raar. Dat is omgekeerd geredeneerd. Normaal gesproken dimensioneer je de links tussen je switches op basis van verwachte hoeveelheid verkeer (rekening houdend met kabelbreuk, groei e.d.), lijkt me. Ik wens je trouwens veel succes met een configuratie van een 65xx verzinnen waarin er daadwerkelijk zoveel bandbreedte aan interfaces beschikbaar is (rekening houdend met de bussnelheden) waarin de engine 720gbit/s moet verwerken..

Overigens beaam ik wat Deff aangeeft, dat er vaak absurde eisen/wensen neergelegd worden t.a.v. bandbreedte. Beheerders van servers zullen heel graag gigabit links voor hun servers willen, maar in de praktijk zijn het meestal alleen fileservers in grote organisaties die daadwerklijk nut hebben bij deze bandbreedte. Twee geteamde 100Mbit/s kaartjes is vaak veel betrouwbaarder (denk aan uitval), goedkoper en snel genoeg. Maarja, daar doen we allemaal wel een beetje aan mee, denk ik

[jochemd]

- Dislocaties met met gebruikers varierend van 10-60 gebruikers.

Wat voor gebruikers? Alleen maar kassa's en toegangspoortjes van ijsbaan/zwembad of staat er ook nog ergens een off-site backup voorziening verstopt waar een paar terrabyte per etmaal naar toe moet.

- WAN verbindingen staan hier boven (probleem is dat we ook een aanbesteding van WAN verbindingen aan het doen zijn, misschien komt hier volledig dark fiber uit. men wil hier niet op wachten. gisteren hoorde ik ook nog dat er een a la surfnet oplossing doorheen loopt. (scholen, gemeente e.d.allemaal op 1 glasvezel netwerk (zelf graven of overnemen)

Vergeet niet je baas te vertellen dat een worst-case scenario is dat je 2 maal moet aanbesteden omdat grote delen incompatible zijn.

- Hoge mate van redundantie (standby links, voor dislocaties backup ISDN lijnen b.v.)

Wil je redundantie of uptime en een lage Time to Fix?
Meestal is redundantie slechts een middel om dat laatste te bereiken.

- Apparatuur die de komende 3 jaar niet end-of-life wordt verklaard, zoals onze huidige 3com cb9000 na 1 jaar !

Wat bdoel je met 'niet-EOL'?
Als je bedoelt dat de apparatuur door de vendor supported moet blijven moet je dat namelijk schrijven.

- liefts een 10gbit backbone (als er geld voor is, afhankelijk dus van de prijs)

Hoeveel bandbreedte heb je nu en wat is het groeiscenario?

- enz enz

Denk eerst nog even goed na over het verschil tussen doel en middel.

Al die technische blabla gaat slechts over het middel. Het doel is te vinden in de afspraken tussen de ICT-afdeling en de rest van de organisatie. Daar staan de afspraken over beschikbaarheid, beveiliging etc. die het uitgangspunt moeten zijn. Een netwerk dat 3 maal per dag down gaat is een even grote geldverspilling als een kantoor met een gegarandeerde beschikbaarheid van 99.999% in de avond en het weekend.

[ijdod]

Predator schreef op 22 januari 2004 @ 21:17:
[...]

Zoveel is er nou ook niet Cisco-proprietary, en de 'open protocollen' worden ook meer gebruikt. Zo zal je meer 802.1q trunking vinden dan ISL, en meer OSPF dan E-IGRP enz ...

Cisco heeft wel de neiging om open protocollen toch even met wat Cisco saus te overgieten. Ze wijken meestal niet veel van de open standaard af, en meestal zijn het zeer welkome toevoegingen, maar toch

Ben het met de strekking eens, hoewel ik het niet eens ben met EIGRP vs OSPF in deze context. Cisco heeft als marktleider vaak het probleem dat de klantvraag (ver) vooruitloopt op de standaarden. Op het moment dat die standaarden er zijn, is de apparatuur vaak wel zo te configureren dat deze standaarden gevolgd worden.

CW is vooral handig voor het aanpassen van bv paswoorden of SNMP community strings e.d. (naast de vermelde configuratie & archiverings functies) in omgevingen met heel veel toestellen. Je kan ze dan snel allemaal tegelijk aanpassen.

Mijn ervaring met die functionaliteit is dat 'ie zo ontbetrouwbaar is, dat je alsnog alle devices af moet lopen om te controleren of 'ie het daadwerkelijk gedaan heeft. Vraag me niet waarom, maar CW lijkt vrij random opeens sommige switches niet te kunnen lezen, enz enz. Dergelijke zaken doen we nu met handgeschreven scripts.

HP OV NNM biedt echter wel veel meer dan je ooit met WhatsUp Gold, Nagions en MRTG gaat bereiken. Het vreet inderdaad wel veel tijd om te fine-tunen, maar dan heb je ook wel een NMS systeem wat je niet meer kan missen.

Welke functionaliteit heb je het dan over? Het enige wat ik me kan bedenken wat ik nu 'mis' (dwz, wat nu (al dan niet beperkt) handwerk is), is rapportages, en automatische signalering van afwijkingen van een baseline.

Verwijderd schreef op 22 januari 2004 @ 21:27:
Wij hebben dit bij Getronics laten doen waar enorm veel echte cisco goeroe's zitten... niks dan lof.

Het is natuurlijk erg afhankelijk van het niveau van het eigen personeel, alsmede de gestelde support eisen. Zelf ben ik een voorstander van een Smartnet contract direct bij Cisco. Doorgaans komen vragen die wij aan Getronics stellen daar toch terecht.

Maarten.O schreef op 22 januari 2004 @ 21:47:

Waar ik trouwens benieuwd naar ben is of beheerders gebruik maken TACACS/RADIUS of dat ze - ook in serieuze netwerken zoals in deze thread beschreven - toch liever lokale authenticatie gebruiken (en waarom).

TACACS/RADIUS voor vrijwel alle apparatuur, paar specifieke uitzonderingen daargelaten. Backup is een periodiek wijzigende basis wachtwoorden set, maar die is pas actief als TACACS/RADIUS onbereikbaar is. Het is bij ons (vrijwel, de beruchte uitzonderingen ) nooit mogelijk een device binnen te komen zonder password.

Voordelen zijn accountability, je kan zien wie waar is geweest, hoe laat, enz, en je kan bij (bv) externen die vertrekken de account dicht kan zetten. Je zou ook rechten kunnen beperken, hoewel wij dat niet gebruiken.

Predator schreef op 22 januari 2004 @ 21:47:
Als jij dan ook nog eens sneller kan configuratie & software files kan archiveren en klasseren voor een hondertal toestellen dan CW, dan heb ik een job voor jou.

Je mist het punt. Als je met niets begint, doet CW dat erg snel. Heb je de basis echter, en heb je zelf discipline, dan voegt CW daar weinig aan toe, ook geen snelheidswinst. Het standaard handmatig wegschrijven van een config naar een tftp server maakt voor de tijd niet uit, en je config database is compleet.

Mijn ervaring is dat ALS het misgaat, ik vaak meer heb aan de configs die ik zelf nog ergens heb, dan de configs uit CW die volkomen compliant zijn met de wet van Murphy .

Persoonlijk zie ik momenteel een beweging die weer een beetje terugkomt van de grote dure tools, en weer terug komt bij de basics. Ik ken bedrijven die CW op de plank hebben liggen, en het niet meer gebruiken.

Maarten.O schreef op 23 januari 2004 @ 11:51:
[...]


Nja, dit is dus een beetje een rare redenatie. Als het goed is kies je die switch/engine op basis van de verbindingen die je (nodig) hebt. Zo is een 6500 serie interessant als je behoorlijk wat poorten op een locatie werkt. Je kunt dan 2950's, 3550's of 3750's gaan stacken, maar beheersmatig blijft dat lastig en als je perse gigabit voor die vele poorten wilt is het ook niet rendabel.

Op het moment dat je een 6500 chassis koopt voor de poort density, en de capaciteit overkill is, is het inderdaad niet relevant. Ik geef ook eerlijk toe dat die 720 Gbit backplane voor ons ook ruim overkill is, alleen is het prijs en module technisch interessant om naar die config te gaan.

Ik moet daarbij wel zeggen dat die stelling uit ons ontwerp komt, waarbij (door hogerhand) is besloten dat diverse componenten niet redundant op beide systemen worden aangesloten. Iets te veel gepraat vanuit de eigen configuratie. Mea Culpa . Dat detail had ik even niet meegenomen, voor een 'echte' config waar alles dubbel is, zal je in een dergelijk scenario de facto een hot spare hebben, die de hele zwik overneemt als de actieve doos uitfikt. Performance is dan geen probleem. Ons management is helaas van het niveau dat een Sitecom switchje bij de Blokker ziet, en dan niet te overtuigen is dat het echte werk wat duurder is, en al helemaal niet dat iets wellicht dubbel gebouwd moet worden. We hebben met veel moeite een goedkeuring gekregen voor 2 ton, voor 4 miljoen aan server hardware...

groei e.d.), lijkt me. Ik wens je trouwens veel succes met een configuratie van een 65xx verzinnen waarin er daadwerkelijk zoveel bandbreedte aan interfaces beschikbaar is (rekening houdend met de bussnelheden) waarin de engine 720gbit/s moet verwerken..

Neem een hele zwik 10 Gbit ethernet poorten, en je komt een eind. Uiteraard zeldzaam, maar dergelijke configs zijn wel geleverd. Nu moet ik zeggen dat als de eisen dusdanig zwaar zouden zijn, ik geen 6500 meer zou aanschaffen, maar dat terzijde .

Twee geteamde 100Mbit/s kaartjes is vaak veel betrouwbaarder (denk aan uitval), goedkoper en snel genoeg. Maarja, daar doen we allemaal wel een beetje aan mee, denk ik

Een gig nodig zijn er maar weinig, hoewel we een tape robot hebben die een gig vol kan trekken (in test, praktijk is minder door de servers )

[ Voor 24% gewijzigd door ijdod op 23-01-2004 16:13 ]

[Maarten @klet.st]

TACACS/RADIUS voor vrijwel alle apparatuur, paar specifieke uitzonderingen daargelaten. Backup is een periodiek wijzigende basis wachtwoorden set, maar die is pas actief als TACACS/RADIUS onbereikbaar is. Het is bij ons (vrijwel, de beruchte uitzonderingen ) nooit mogelijk een device binnen te komen zonder password.

Voordelen zijn accountability, je kan zien wie waar is geweest, hoe laat, enz, en je kan bij (bv) externen die vertrekken de account dicht kan zetten. Je zou ook rechten kunnen beperken, hoewel wij dat niet gebruiken.

Thanks voor de info. Wat je beschrijft is ook een beetje mijn reden om het te gebruiken. Vooral die backup accounts kunnen wel handig zijn
Qua Radius twijfel ik nog of het handig is voor 802.1x/WPA authenticate (Windows IAS service kan draadloze windowze machine accounts aanmelden, hoe je dat met Cisco ACS moet doen is me nog ff onduidelijk).

Neem een hele zwik 10 Gbit ethernet poorten, en je komt een eind. Uiteraard zeldzaam, maar dergelijke configs zijn wel geleverd. Nu moet ik zeggen dat als de eisen dusdanig zwaar zouden zijn, ik geen 6500 meer zou aanschaffen, maar dat terzijde .

Nja, helaas, je gaat niet voor de koelkast ben ik bang... Van de cisco site:
"Supporting 40Gbps interconnection to the Cisco Catalyst 6500 Supervisor Engine 720's integrated 720Gbps switch fabric, this module uses accelerated Cisco Express Forwarding (dCEF) delivering peak system throughput of up to 400Mpps. Up to 32 10 Gigabit Ethernet ports can be deployed in a 9 slot Catalyst 6509 chassis."

Daarmee zou je in theorie 640Gbps traffic moeten kunnen halen, als je de apparatuur kan regelen die zinvol alle links met verkeer kan vullen (beide kanten op). Dat is waarschijnlijk ook niet helemaal waar, want je hebt dus een 40Gbps connectie met de engine per 4 poorten. Vermoedelijk is dat een totaal van tx en rx verkeer. En het feit dat ze niet over een 6513 praten doet me vermoeden dat je daarmee ook niet meer 10GE poorten kan gebruiken

Anyway, het is hoe dan ook insane, om voor zulk verkeer een 6500 te gebruiken

[Predator]

ijdod schreef op 23 januari 2004 @ 16:10:
[...]


Ben het met de strekking eens, hoewel ik het niet eens ben met EIGRP vs OSPF in deze context. Cisco heeft als marktleider vaak het probleem dat de klantvraag (ver) vooruitloopt op de standaarden. Op het moment dat die standaarden er zijn, is de apparatuur vaak wel zo te configureren dat deze standaarden gevolgd worden.

Ik heb niet gezegd dat ik dat een negatieve trend vind, integendeels zelfs.

Mijn ervaring met die functionaliteit is dat 'ie zo ontbetrouwbaar is, dat je alsnog alle devices af moet lopen om te controleren of 'ie het daadwerkelijk gedaan heeft. Vraag me niet waarom, maar CW lijkt vrij random opeens sommige switches niet te kunnen lezen, enz enz. Dergelijke zaken doen we nu met handgeschreven scripts.

Ik heb daar nooit problemen mee gehad.
Voor de rest vind ik het wel een hoerending dat zo brak is als het maar kan

Welke functionaliteit heb je het dan over? Het enige wat ik me kan bedenken wat ik nu 'mis' (dwz, wat nu (al dan niet beperkt) handwerk is), is rapportages, en automatische signalering van afwijkingen van een baseline.

Voor rapportages gebruik je beter InfoVista, maar dat is nog een stuk duurder.
Met "automatische signalering van afwijkingen van een baseline" bedoel je dus het Event management systeem wat meer kan dan wat je in die zin beschrijft.

Daar zit juist de kracht van HP OV NNM.
De statistische thresholds zijn toch wel erg handig.

Je mist het punt. Als je met niets begint, doet CW dat erg snel. Heb je de basis echter, en heb je zelf discipline, dan voegt CW daar weinig aan toe, ook geen snelheidswinst. Het standaard handmatig wegschrijven van een config naar een tftp server maakt voor de tijd niet uit, en je config database is compleet.

Als je daar zeer consequent in bent wel ja.
Aanpassingen doen en meteen na de wr ook een copy start tftp.

Iedereen is helaas niet altijd zo consequent, en ik ook niet.
Als je dan ook nog aan archivering icm version management wilt doen, dan moet je ze ook nu en dan ordenen. Ik kan je verzekeren dat als je dat voor 400 verschillende toestellen moet gaan doen het na een tijdje toch wel tegensteekt.

Vooral als je dan weinig gevoel voor orde hebt

Mijn ervaring is dat ALS het misgaat, ik vaak meer heb aan de configs die ik zelf nog ergens heb, dan de configs uit CW die volkomen compliant zijn met de wet van Murphy .

Nou, ik heb er nooit problemen mee gehad.

Persoonlijk zie ik momenteel een beweging die weer een beetje terugkomt van de grote dure tools, en weer terug komt bij de basics. Ik ken bedrijven die CW op de plank hebben liggen, en het niet meer gebruiken.

Daar heb ik nog weinig van gemerkt. Wat ik wel gemerkt heb is de: "We hebben een belangerijker zaken te doen en geen tijd meer om ons daar mee bezig te houden". Het eerste wat dan verwaarloost wordt is het Network management.

Ik moet helaas vaststellen dat ik daar momenteel ook bijhoor

[Routed]

ijdod schreef op 23 januari 2004 @ 16:10:
[...]
Een heel lang verhaal waar ik zonder meer niets meer aan toe te voegen heb.

Ow helaas gebruiken wij geen radius/tacacs, wilde er een keer mee gaan beginnen maar dat plan is tijdelijk in de koelkast geparkeerd
Resultaat is idd dat bij een pw change ik(wij) alle switches langs kunnen gaan om de pwds te wijzigen.

ijdod, ik vind je sig super, die gaat ik ffkes pikken en op me werk onder me autohandtekening parkeren

[ijdod]

Maarten.O schreef op 23 januari 2004 @ 19:49:
Nja, helaas, je gaat niet voor de koelkast ben ik bang...

Klopt, maar dat komt doordat ik nog geen koelkast heb gevonden in 19" formaat (voor inbouw in een oude 7500 chassis )

Daarmee zou je in theorie 640Gbps traffic moeten kunnen halen, als je de apparatuur kan regelen die zinvol alle links met verkeer kan vullen (beide kanten op).

Da's een kwestie van wat servers met pr0n

Dat is waarschijnlijk ook niet helemaal waar, want je hebt dus een 40Gbps connectie met de engine per 4 poorten. Vermoedelijk is dat een totaal van tx en rx verkeer.

Dat zijn 2 channels van 20 Gbps full duplex

En het feit dat ze niet over een 6513 praten doet me vermoeden dat je daarmee ook niet meer 10GE poorten kan gebruiken

6513 is een afwijkend beestje, waar inderdaad wat beperkingen in zitten. Waar de 6509 op elk slot 2 van die channels heeft, heeft de 6513 dat alleen op de onderste 5 sloten. De bovenste 8 hebben er slechts 1 per slot. Heeft te maken met het totaal aantal channels dat beschikbaar is (18, da's totaal dus 720 Gbps ).

Predator schreef op 23 januari 2004 @ 20:34:
Iedereen is helaas niet altijd zo consequent, en ik ook niet.
Als je dan ook nog aan archivering icm version management wilt doen, dan moet je ze ook nu en dan ordenen. Ik kan je verzekeren dat als je dat voor 400 verschillende toestellen moet gaan doen het na een tijdje toch wel tegensteekt.

Is tot nu toe altijd goed gegaan, maar met dat soort aantallen heeft een goed automatisch systeem inderdaad wat voordelen. Dan moet je dat systeem wel kunnen vertrouwen, en daar wringt bij ons met CW2000 de schoen. Waarom weet ik niet, maar betrouwbaar is niet een woord dat ik bij ons associeer met CW.

Dachten eerst dat dit aan een brakke Sun lag, maar na eea op een vers, recent systeem te hebben geinstalleerd is er weinig verbeterd. Het gaat nu alleen sneller .

[ Voor 42% gewijzigd door ijdod op 26-01-2004 09:36 ]

[Maarten @klet.st]

ijdod schreef op 26 januari 2004 @ 09:36:
[...]
Da's een kwestie van wat servers met pr0n

640Gbit/s verstouwen met wat pr0n zal nog steeds een lastig gegeven worden. Ik weet niet hoeveel bandbreedte je werkelijk via Internet kan verstouwen, maar ik ben toch bang dat je wat problemen zal krijgen om 640Gbit/s verkeer kwijt te raken

Anyway, het punt, dat die 720Gbit/s cpu/asicsnelheid theoretisch prettig, maar in de praktijk niet realistisch bruikbaar is. Datzelfde geldt natuurlijk voor Mpps specs van de meeste apparaten. Goed dat een processor/asic dat in laboratoriumsituaties haalt, maar in 99,9% (bij wijze van spreke) zal een ASIC/processor ver onder de 1Mpps blijven (100Mbit/s aan ftp traffic levert nog geen 12kpps op, is mijn ervaring).