[Cisco] Certificaten, ervaringen & discussies

[ralpje]

Zo, vandaag maar even de boeken (linkje) besteld om CCNA te gaan doen.
Ik werk dagelijks met Cisco spul, dus ik verwacht eigenlijk geen moeite om dit via thuisstudie te gaan halen.

Iemand nog suggesties om dit enigszins op te bouwen? Gewoon de boeken in volgorde doorwerken en af en toe wat testen / oefeningen doen, of zijn er zaken waar je specifiek op moet letten?

[Verwijderd]

Misschien een stomme vraag maar, na het volgen van een van de chapters op cisco.netacad.net, zie ik geen cijfers bij de grades tabel staan.. Na het voltooien van een chapter moeten er toch cijfers komen te staan?

[TrailBlazer]

ralpje schreef op donderdag 29 januari 2009 @ 21:40:
Zo, vandaag maar even de boeken (linkje) besteld om CCNA te gaan doen.
Ik werk dagelijks met Cisco spul, dus ik verwacht eigenlijk geen moeite om dit via thuisstudie te gaan halen.

Iemand nog suggesties om dit enigszins op te bouwen? Gewoon de boeken in volgorde doorwerken en af en toe wat testen / oefeningen doen, of zijn er zaken waar je specifiek op moet letten?

Het grootste nadeel voor je CCNA is IMHO als je ervaring hebt met cisco. Er wordt nogal veel theoretische kennis gevraagd en nogal wat zinloze dingen.

[Whizzer]

TrailBlazer schreef op vrijdag 30 januari 2009 @ 06:40:
[...]

Het grootste nadeel voor je CCNA is IMHO als je ervaring hebt met cisco. Er wordt nogal veel theoretische kennis gevraagd en nogal wat zinloze dingen.

Niet helemaal met je eens. Het is op zich wel handig als je wat commando's al wel kent. Irritante is alleen dat je voor je CCNA examen (althans, bij mij "vroegâh") je het volledige commando moet kennen. Zo irritant als je altijd "sh run" inklopt en dan ineens moet gaan antwoorden of het "show running-config" of "show running-configuration" is.

Gewoon accepteren dat de dingen zijn zoals Cisco ze vraagt en niet zoals jij ze tot nu toe deed. Niet twijfelen of in discussie gaan, accepteren!

Je moet mensen niet meteen afschrikken...

[sh4d0wman]

Whizzer schreef op vrijdag 30 januari 2009 @ 08:27:
[...]

Gewoon accepteren dat de dingen zijn zoals Cisco ze vraagt en niet zoals jij ze tot nu toe deed. Niet twijfelen of in discussie gaan, accepteren!

Werken die afkortingen wel in sims? Vind dat juist makkelijk werken En hoe zit het met tab en help?

Oh ja, is er ook een calculator beschikbaar? Ben niet zo sterk in hoofdrekenen haha.

[dreester]

sh4d0wman schreef op vrijdag 30 januari 2009 @ 08:41:
[...]

Werken die afkortingen wel in sims? Vind dat juist makkelijk werken En hoe zit het met tab en help?

Oh ja, is er ook een calculator beschikbaar? Ben niet zo sterk in hoofdrekenen haha.

Ik denk dat ze bij sommige sims tab en help afgeknepen hebben.

Volgens mij geen calculator, alleen iets van een uitwisbare bord waar je op mag kalken. Dus subnetting moet je echt uit je hoofd kunnen, niet zo moeilijk btw.

[ Voor 8% gewijzigd door dreester op 30-01-2009 08:47 ]

[Whizzer]

sh4d0wman schreef op vrijdag 30 januari 2009 @ 08:41:
[...]
Oh ja, is er ook een calculator beschikbaar? Ben niet zo sterk in hoofdrekenen haha.

Nope, toen niet, nu niet en in de toekomst ook niet. Belangrijk onderdeel in alle Cisco examens is subnetting. Elke examen wat ik tot nu toe heb gehad heeft wel wat vragen daarover. Zelf nu in mijn CCIE Security training kom ik het nog tegen.

[TrailBlazer]

maar op je lab heb je wel een calculator hoor

[Whizzer]

TrailBlazer schreef op vrijdag 30 januari 2009 @ 09:19:
maar op je lab heb je wel een calculator hoor

Komt ie nu mee aan... maar ik subnetten kan ik héél goed zonder calculator

[Verwijderd]

Ik kan niet inloggen met mijn CSCO id, hebben daar meer mensen problemen mee? Ik heb de registratiecode gebruikt en een wachtwoord ingesteld... maar het werkt niet...

[TrailBlazer]

Whizzer schreef op vrijdag 30 januari 2009 @ 09:28:
[...]

Komt ie nu mee aan... maar ik subnetten kan ik héél goed zonder calculator

wacht maar tot je rare inverse mask moet gaan uitrekenen dan is het wel lekker dat je even snel decimaal naar binair kan doen. Sowieso kan je op je examen opeens rare dingen gaan doen in je hoofd en dan is het gewoon wel relaxed als je je gewoon op de calculator kan controleren wat je doet.

[Whizzer]

Tja, bij mij zal de nadruk niet liggen op rare inverse masks enzo. Ik moet eerder weten wat ik moet doen om BGP (met wachtwoord tussen de neighbors) door een PIX/ASA heen te krijgen.

En om deze post nu nog een educatieve toevoeging te geven (net zoals Trail nog wel eens wil doen):

code:

R1 --- ASA --- R2

R1: 10.0.0.1 /24
R2: 20.0.0.2 /24
ASA: 10.0.0.12/24 & 20.0.0.12/24

Waar moet je rekening mee houden als BGP met authenticatie door een ASA gaat? Ze kunnen elkaar al wel bereiken.
hint: alleen door poortje 179 open te zetten is niet voldoende!

[Raenius]

Ik ben wel benieuwd naar het antwoord van jou vraag Trailblazer...

[sh4d0wman]

Whizzer schreef op vrijdag 30 januari 2009 @ 11:05:
Tja, bij mij zal de nadruk niet liggen op rare inverse masks enzo. Ik moet eerder weten wat ik moet doen om BGP (met wachtwoord tussen de neighbors) door een PIX/ASA heen te krijgen.

hint: alleen door poortje 179 open te zetten is niet voldoende!

Gokje,

spoiler:

PIX / ASA 7.x and Later
In order to pass BGP updates through ASA/PIX 7.x and later, you must allow TCP option 19 in BGP. By default, option 19 is not permitted to pass through a PIX/ASA that runs 7.0 or later.

Voor de volledigheid nog even hierbij wat TCP Option 19 is:
TCP Option 19, Length 18, MD5 Signature Option, [RFC2385]

Uit het blote hoofd _{gaat weer nederig verder met ICND1}

[ Voor 8% gewijzigd door sh4d0wman op 30-01-2009 12:23 ]

[Whizzer]

sh4d0wman schreef op vrijdag 30 januari 2009 @ 12:04:
Gokje,

<Copy Paste stukje>

Uit het blote hoofd _{gaat weer nederig verder met ICND1}

Je bent onderweg sh4d0wman, maar je bent er nog niet. Je moet nog met 1 ding rekening houden. Verder natuurlijk ook de vraag waarom je het in de spoiler beschreven stuk moet doen.

O, ennuh: Niets nederigs aan ICND1 hoor! Iedereen begint daar, maar verre van iedereen stroomt verder door.

Next hop adressen interesseert me momenteel niet, de focus ligt nu op het werkend krijgen van de BGP verbinding.

[ Voor 11% gewijzigd door Whizzer op 30-01-2009 13:05 ]

[sh4d0wman]

Ik begin met het waarom over mijn vorige antwoord:

spoiler:

Het hashnummer wat de BGP members nodig hebben zit in TCP option 19. Zonder dat veld gaat de MD5 authenticatie niet werken.

Onderbouwing:
BGP can be configured for authentication with MD5. MD5 authentication is applied on the TCP psuedo-IP header, TCP header and data (refer to RFC 2385). TCP uses this data—which includes the TCP sequence and ACK numbers—along with the BGP neighbor password to create a 128 bit hash number. The hash number is included in the packet in a TCP header option field.

Mogelijk antwoord:

spoiler:

1 Random sequence numbers moeten uitstaan in een Pix, ASA zie ik daar niet in terug.

Onderbouwing:
On the sending BGP peer, TCP uses the original sequence number to create the 128 bit MD5 hash number and includes this hash number in the packet. When the receiving BGP peer gets the packet, TCP uses the PIX-modified sequence number to create a 128 bit MD5 hash number and compares it to the hash number that is included in the packet. The hash number is different because the TCP sequence value was changed by the PIX, and TCP on the BGP neighbor drops the packet and logs an MD5 failed message. Use the norandomseq keyword to stop the PIX from offsetting the TCP sequence number.

2 Er mag niet genat worden.
The addresses of the devices that run BGP cannot be NATed, because the MD5 hash takes IP header as well as the TCP header, which means none of that information can be changed.

Uit voor examen komt deze vraagstelling? Zit dat al in het normale ASA examen of Advanced ASA?

[TrailBlazer]

Ik mag hopen dat CCIE security advanced ASA is.

Raenius schreef op vrijdag 30 januari 2009 @ 11:27:
Ik ben wel benieuwd naar het antwoord van jou vraag Trailblazer...

heb je zelf al wat geprobeerd?

edit er zit een typo in zie het moeten deze 3 zijn dus als goedmakertje help ik je even op weg.
192.168.12.24
192.232.140.24
192.232.12.24

spoiler:

192.168.12.24
192.232.12.24
deze 2 kan je matchen met de volgende ACl entry
192.168.12.24 0.64.0.0

[ Voor 35% gewijzigd door TrailBlazer op 30-01-2009 17:50 ]

[Whizzer]

sh4d0wman schreef op vrijdag 30 januari 2009 @ 13:34:
Ik begin met het waarom over mijn vorige antwoord:
...

Inderdaad, BGP met authenticatie maakt een hash uit al deze velden en stopt dat in TCP option 19.

Mogelijk antwoord:

...

1 ...

Klopt. Dit geld voor zowel ASA en de PIX vanaf versie 7.0.

2 ...

Het is of authenticatie, of NAT, samen gaat niet. Inderdaad vanwege het waarom

Uit voor examen komt deze vraagstelling? Zit dat al in het normale ASA examen of Advanced ASA?

CCIE Security, dus Advanced ASA.

Kleine extra teaser: er zijn 2 manieren waarop je IPSec kunt tunnelen: Welke heeft de minste overhead en waarom is dat zo?

En Trail moet eens z'n vragen direct goed doen . Ik vond hem al zo vreemd, want die kon nooit in twee regels, zelf met behulp van een subnet/wildcard calculator.

[TrailBlazer]

Niet dat gezeur over extra overhead gewoon meer bandbreedte neergooien.

[Whizzer]

TrailBlazer schreef op vrijdag 30 januari 2009 @ 19:36:
Niet dat gezeur over extra overhead gewoon meer bandbreedte neergooien.

Tot zover de bijdrage van Trail.. Jammer dat het probleem hier zich voor kan doen op MTU niveau en daar helpt een dikkere pijp niet echt aan.

[JackBol]

Skins schreef op dinsdag 20 januari 2009 @ 07:54:
@TrailBlazer: Raar dat dit nu pas in de Nexus komt, in de 6500 is dit toch al een tijdje beschikbaar met VSS (Sup720-3CXL) (werkt overigens erg mooi ook)

Ik ga zien wat de Nexus kan volgende week in Barcelona, zit in het Nexus 7000 lab.

Nou, ik heb dus dat Nexus 7k lab gedaan.
Op deze Nexus draaide een engineering release van NX-OS (4.1.3) die de vPC functionaliteit al aan boord had.

Twee uur had je de tijd om het volgende te configureren:

- RBAC
- Configuration Rollback
- Spanning-Tree
- HSRP
- vPC (virtuele port-channels, de ´smlt´ functionaliteit)
- OSPF (geskipt vanwege tijd)
- Wireshark (geskipt)
- VDCs

Mijn ervaringen:

De architectuur van NX-OS voelt al een stuk beter aan dan de architectuur van IOS. Zo draait NX-OS op een Linux kernel. Er zijn dan ook twee boot-images. Een image om Linux te laden en een image om NX-OS daarop te laden.

Daarnaast werkt NX-OS met een plugin architectuur. Momenteel zijn er twee plugins, de Ethernet plugin (voor switching uiteraard) en een storage plugin (voor FCoE).

NX-OS is volledig modulair en dit is ook werkend. Middels een hidden commando in de engineering release is het mogelijk om in de linux shell te komen. Hier is het OSPF proces hardhandig gekilled, waarna dit door NX-OS automatisch herstart word. Het is zelfs mogelijk om dit graceful te laten gebeuren, wat zoveel inhoud dat de dataplane blijft functioneren totdat de controlplane terug is. Natuurlijk moeten je OSPF neighbors dit wel ondersteunen.

Het modulaire blijkt op het moment dat je iets wilt configureren. Elke functionaliteit buiten de CLI zelf moet handmatig gestart worden met het feature-commando. Op dat moment word ook het bijbehorende proces gestart.

Een nieuw concept in de Nexus is de introductie van Virtual Device Contexts (VDCs). Een VDC is een virtuele switch waar interfaces aan toegekend kunnen worden. Elke VDC is compleet van elkaar gescheiden met aparte controlplanes voor routing en switching. Het is dan ook niet mogelijk om een interface aan meer dan een VDC toe te kennen. Dit beperkt dan ook wel weer de functionaliteit van een VDC.

De Nexus heeft wat slimme verbeteringen, maar het is nog lang niet af. Eindelijk is out-of-band management via Ethernet mogelijk. Standaard heeft een Nexus een management VRF aanboord waar de virtuele management interface (mgmt0) van de default VDC en alle additionele VDCs in zitten. Daarnaast zitten alleen de fysieke ethernet interfaces van de supervisors in dit VRF. Eindelijk is het ook mogelijk om public keys in de configuratie op te slaan en password-loos te kunnen inloggen op een switch.

De CLI is er ook op vooruit gegaan. Het hiarchische concept is verder uitgebouwd. Wanneer je HSRP op een interface configureert kom je in een submenu op de interface. Dit heeft vooral als voordeel dat je geen superlange lijsten met commandos hebt wanneer je tab of ? gebruikt. Voor het aanvullen van commandos word in de hiarchische menustructuur terug gezocht. Dit betekent dat je op interface configuratie global commandos en zelfs show commandos kan uitvoeren. De CLI zoekt zelf uit welk hiarchisch niveau bij een commando hoort. De mogelijkheden achter de pipe zijn ook uitgebreid. Je ziet dat ze linux als basis hebben, want alle standaard tools inclusief zijn bruikbaar achter de pipe (vb. tr, sed, tail, last wc, count, grep). De output van tools zoals traceroute en ping geven ook weg dat hiervoor de linux varianten gebruikt worden. Dat betekent dus het einde van het uitroepteken.

Rechtendelegatie gaat niet meer met privileges, maar met Role-Based-Access-Control (RBAC). Per RBAC account kunnen allow en deny statements opgegeven worden inclusief regexps. De commandoset voor een bepaalde user is hiermee erg duidelijk te definieren. Ook kan er een lijst met interfaces geconfigureerd worden welke de klant mag configureren. Volgens Cisco is deze RBAC sterk genoeg om zelfs klanten toegang te geven tot je apparatuur. Enge gedachte...

Ook archivering van configs is onderhanden genomen. Vanaf 12.4T en SXH is het al mogelijk om configs op te slaan en naar terug te rollen. In NX-OS is dit ook aanwezig. Naar mijn mening is de uitvoering erg slecht in vergelijking met concurenten zoals JunOS. Een archivering van een running-config van 7k neemt 30 seconde in beslag en een rollback zelfs langer. Daarnaast moet het script bijhouden of een commando ge-negate word met een no-commando of juist zonder no-commando of misschien wel met een andere parameter (bijv. speed auto naar speed 100). Je kan configuraties vergelijken, maar als je output van diff verwacht kom je bedrogen uit. Je kan niet zien wat toegevoegd is of verwijderd, alleen dat er iets veranderd is. Erg jammer dus.

Virtual Port-Channels is een nieuwe functionaliteit binnen het Nexus platform. Het is vergelijkbaar met Nortels SMLT en feitelijk een techniek om een port-channel van de twee uplinks van een standaard 802.3ad compatible device naar twee Nexii te splitsen. De Nexii zijn onderling verbonden met een port-channel die een vPC-peer-link genoemd word. Hierdoor ontstaat een Nexus-cluster. Een cluster kan maximaal twee Nexii omvatten. In de configuratie van de peer-link word ook een prioriteit aangegeven, waardoor een Nexus primary word en de andere secondary. Dit is er belangrijk bij een zgn. split-brain situatie waarbij de vPC-peer-link verbroken zou worden. In dat geval zal de secondaire Nexus al zijn interfaces sluiten. Uiteraard zijn er verschillende methodes om deze situatie te voorkomen of om snel ervan te kunnen hetstellen.

De Nexus vPC functionaliteit verschilt van de Catalyst 6500 VSS technologie doordat de beide Nexii een actieve dataplane en actieve controlplane hebben. In het geval van de VSS met dubbele actieve dataplane een enkele actieve controlplane is de noodzaak voor First-Hop-Redundancy-Protocollen verdwenen. Een vlan interface als controlplane functie bestaat per definitie op beide switches. Bij de dubbele controlplanes van de Nexii zal nog steeds een FHRP geconfigureerd moeten worden. De configuratie van bijv. HSRP blijft traditioneel met een active en een standby HSRP node. De forwarding voor HSRP hebben ze echter van de controlplane naar de dataplane verhuist, waardoor een frame die op de secondaire Nexus aankomt niet via de vPC-peer-link naar de primaire Nexus geforward worden voordat het naar Layer3 getilt word door HSRP. Hierdoor kunnen werkelijke active/active architecturen gebouwd worden.

De vPC functionaliteit is een spanning-tree vervangende technologie. De vPC is een tussenstap naar de Layer2 Multipathing strategie die bijna alle switch fabrikanten nastreven. De L2MP technologie omvat het bouwen van Shortest-Path-First trees op layer 2 middels een aangepaste variant van IS-IS.

Een kleine verandering in OSPFv2 is dat de OSPF interfaces niet meer geconfigureerd worden met het network commando onder het OSPF proces, maar dat per interface geconfigureerd word of een interface participeert in OSPF en andere eventuele OSPF configuratie op de link zoals met wie een adjecency opgebouwd moet worden en wie er voorkeur heeft om DR of BDR te worden. Hiermee hebben ze de configuratie gelijk getrokken met OSPFv3, welke voor IPv6 reeds beschikbaar is op IOS.

Als laatste valt er te melden dat Cisco een protocol analyzer in de Nexus 7000 heet geplaatst. Wireshark is aanwezig, welke gebruikt kan worden om packetanalyse uit te voeren. Standaard is het mogelijk om enkel verkeer dat bestemd is voor de controlplane te capturen, maar middels een span-sessie is het mogelijk om dataplane verkeer te sniffen. Natuurlijk moet hier wel rekening gehouden worden met de beperkte bandbreedte tussen de controlplane en de dataplane. Een Access-list kan gebruikt worden voor het filteren van verkeer op de span interface.

Al met al heeft NX-OS een hoop verbeteringen doorgemaakt. Veel van de toegevoegde functionaliteit mbt. management en de CLI zijn echter afgekeken van JunOS. Ik heb hier helemaal geen probleem mee, want JunOS is een goed OS. Het afkijken is alleen slecht gedaan. het hiarsche configuratie menu is rommelig afgewerkt en de hiarchie komt zeer summier terug in de running-config. De rollbacks zijn aanwezig, maar rollbacken kost veel tijd en de output van een diff is erg onduidelijk. De vPC functionaliteit is echter erg vooruitstrevend. Zowel het concept als de implementatie zijn door Cisco goed uitgewerkt. Daarnaast ben ik erg blij dat NX-OS eindelijk een modulair, enterprise-grade OS is.

[JackBol]

Ik heb ook nog een mening over de nexus1000v.

Eigenlijk was deze bedoelt voor mijn collega's, maar ik wil em jullie niet onthouden.

Cisco Nexus 1000v

De Cisco Nexus 1000v is een nieuw concept van Cisco. Zoals de naam Nexus al doet vermoeden is het een switch uit de Nexus familie, die zich onderscheiden van de Catalyst familie door NX-OS te draaien. De Nexus 1kv is echter geen standaard switch, maar een virtuele switch, bedoeld om de virtuele switch in VMWare ESX (de vSwitch) te vervangen. De architectuur van de Nexus 1kv is helemaal anders dan de vSwitch.

De vSwitch uit ESX is vrij beperkt. Het kan een dot1q-tagged interface van een fysieke NIC ontvangen, onttaggen en doorzetten naar een VM. Qua functionaliteit is het vergelijkbaar met een managed Linksys switch.

De Nexus 1kv kan veel meer dan dat. De Nexus 1kv bestaat uit een stukje vSwitch-vervangende software op de ESX Hypervisor, welke zich presenteert als een linecard. Op deze linecard zitten de fysieke interfaces van een VM node (vmnics) en de logische interfaces naar de VMs die op dat moment op de betreffende host draaien.

Daarnaast is er een Virtual-Supervisor-Module VM-appliance (een of twee VMs mogelijk) die zich gedragen als supervisors. Vanaf deze supervisor zijn de linecards (wat feitelijk de vSwitch-vervangende software is) beheerbaar. Hierdoor respresenteert een Nexus1kv zich als een chassis-based switch. Naar de VM is te ssh'en, waarbij je in de virtuele supervisor komt.

Een show mod ziet er dan ook als volgt uit; waarbij module 1 en 2 de Cisco Nexus 1kv Management VMs zijn, en module 3 en 4 de software-linecards in twee verschillende ESX servers zijn. Een maximum van 64 linecards zijn toegestaan, wat dus 64 ESX hosts zijn.

code:

nexus1000v# show module 

Mod  Ports  Module-Type                      Model              Status 
--- ----- -------------------------------------------------------------- 
1    1      Supervisor Module                Cisco Nexus 1000V  active * 
2    1      Supervisor Module                Cisco Nexus 1000V  standby 
3    48     Virtual Ethernet Module                             ok 
4    48     Virtual Ethernet Module                             ok

nexus1000v#

De Nexus1kv geeft je dan ook veel voordelen; ten eerste is het switch-beheer los gekoppeld van het VM beheer, waardoor je de traditionele rollen van systeembeheer en netwerkbeheer weer kan scheiden.
Daarnaast geeft de Nexus je veel functionaliteit die netwerkbeheerders gewend zijn. VLANs, Private-VLANs, QoS marking en rate-limiten, mac-security, ACLs en netflow export. Voor systeembeheerders zit er ook een voordeel in. De switches in alle aangesloten ESX hosts zijn identiek geconfigureerd. Sterker nog, alle virtuele switches presenteren zich als 1 grote switch, uitgetrokken over alle ESX hosts. Wanneer een VM van een host naar een andere vMotiont (zowel handmatig of middels DRS) hoeft je je geen zorgen te maken of de juiste VLANs (port-profiles) op de destination host aanwezig zijn.

Een port-profile is een groep van settings die een netwerkbeheerder configureert. Vanuit de VM console is het vervolgens mogelijk om bij het aanmaken van een VM een port-profile te kiezen. Een port-profile omvat zowel L2 configuratie zoals VLAN id maar ook security functies zoals MAC-filtering.

Interfaces naar een VM worden in de Nexus weergegeven als "Veth" (virtual ethernet) ports, welke dezelfde functionaliteit hebben als 'echte' interfaces, zoals mac-adressen en counters. een Veth word aangemaakt als een virtuele machine word aangemaakt en blijft met deze VM gekoppeld totdat deze verwijderd word. Een VM heeft dus vanuit de switch gezien altijd dezelfde netwerk interface. Dus ongeacht op welke ESX host een VM leeft, heeft deze VM dezelfde interface naam en bijbehorende counters en mac-adres, wat troubleshooting veel practischer maakt, omdat een VM altijd hetzelfde geadresseerd word.

De show interface hieronder geeft dan ook virtuele en fysieke interfaces weer. mgmt0 is de virtuele management interface waarop je de supervisor VM kan bereiken. Eth3/2 en Eth4/2 zijn de fysieke NIC in twee verschillende esx-hosts. De Veth's zijn de virtuele interfaces naar VMs. Veth2 en Veth3 zijn een virtuele interface naar de Supervisor VM, Veth1 is de interface naar een virtuele Ubuntu instantie.

code:

nexus1000v(config-port-prof)# show interface brief

--------------------------------------------------------------------------------
Port   VRF          Status IP Address                              Speed    MTU
--------------------------------------------------------------------------------
mgmt0  --           up     10.16.147.154                           1000     1500

--------------------------------------------------------------------------------
Ethernet      VLAN   Type Mode   Status  Reason                   Speed     Port
Interface                                                                   Ch #
--------------------------------------------------------------------------------
Eth3/2        1      eth  trunk  up      none                     a-1000(D) --
Eth4/2        1      eth  trunk  up      none                     a-1000(D) --

--------------------------------------------------------------------------------
Interface     VLAN   Type Mode   Status  Reason                   MTU
--------------------------------------------------------------------------------
Veth1         20     virt access up      none                     1500
Veth2         20     virt access up      none                     1500
Veth3         40     virt access up      none                     1500

nexus1000v(config-port-prof)#

Een show interface virtual geeft de virtuele verbindingen op de switch weer. Een interface description zowel vanuit de VM console als de CLI meegegeven worden. Ook kan er hier gezien worden op welke fysieke server een VM draait vanuit netwerkperspectief.

code:

nexus1000v(config-port-prof)# show interface virtual

--------------------------------------------------------------------------------
Port        Adapter        Owner                    Mod Host
--------------------------------------------------------------------------------
Veth1       Net Adapter 1  Ubuntu01                 3   esx4-151.cisco.com
Veth2       vmk1           VMware VMkernel          3   esx4-151.cisco.com
Veth3       vmk1           VMware VMkernel          4   esx4-152.cisco.com

nexus1000v(config-port-prof)#

Een show interface van een virtuele interface geeft een regulier overzicht van statistieken. Zo is te zien tot welke VM de interface behoord, op welke ESX host deze draait, het Port-Profile en verschillende configuratie variabelen. Ook zijn de bekende RX en TX tellers aanwezig, iets dat voorheen niet per VM boven water was te krijgen.

code:

nexus1000v(config-port-prof)# show interface Veth1
    Hardware is Virtual, address is 0050.5445.ab12
    Owner is Ubuntu01, adapter is Net Adapter 1
    Active on module 3, host esx4-151.cisco.com
    VMware DVS port 16777213
    Port-Profile WebServer
    Port mode is access
    Rx
    3433 Input Packets 3423 Unicast Packets
    1 Multicast Packets 9 Broadcast Packets
    223452 Bytes
    Tx
    323343 Output Packets 320043 Unicast Packets
    0 Multicast Packets 3323 Broadcast Packets 0 Flood Packets
    4162325200 Bytes
    0 Input Packets Drops 0 Output Packets Drops

nexus1000v(config-port-prof)# show interface Veth3
    Hardware is Virtual, address is 0050.5678.0b98
    Owner is VMware VMkernel, adapter is vmk1
    Active on module 4, host esx4-152.cisco.com
    VMware DVS port 16777215
    Port-Profile VMotion
    Port mode is access
    Rx
    3205145 Input Packets 3203135 Unicast Packets
    1 Multicast Packets 9 Broadcast Packets
    4504775162 Bytes
    Tx
    5202617 Output Packets 5056766 Unicast Packets
    216 Multicast Packets 145635 Broadcast Packets 151071 Flood Packets
    4162325200 Bytes
    0 Input Packets Drops 0 Output Packets Drops

nexus1000v(config-port-prof)#

De Nexus 1kv is in mijn optiek dan ook een geweldig product. De labs en de demo's zien er veelbelovend uit! Het gaat beheer in een datacenter waar veel VMWare draait aanzienlijk vereenvoudigen. Nadeel is dat de Nexus 1kv momenteel alleen nog beta en het werkt alleen met de 'next major release', ESX4. Beide producten worden in de zomer verwacht.

[ Voor 4% gewijzigd door JackBol op 30-01-2009 21:16 ]

[TrailBlazer]

Whizzer schreef op vrijdag 30 januari 2009 @ 20:18:
[...]


Tot zover de bijdrage van Trail.. Jammer dat het probleem hier zich voor kan doen op MTU niveau en daar helpt een dikkere pijp niet echt aan.

In je backbone hoor je gewoon een MTU te hebben van 9124.
Het was een beetje chargerend maar QoS klinkt vaak heel erg leuk de vraag is echter of meer bandbreedte uiteindelijk niet goedkoper is. Meer bandbreedte is gewoon een stuk eenvoudiger te beheren.

[Whizzer]

TrailBlazer schreef op vrijdag 30 januari 2009 @ 22:36:
[...]
Het was een beetje chargerend maar QoS klinkt vaak heel erg leuk de vraag is echter of meer bandbreedte uiteindelijk niet goedkoper is. Meer bandbreedte is gewoon een stuk eenvoudiger te beheren.

True!

Maar als ik kijk in de omgeving waar ik nu klus, dan is dat een MultiVRF MPLS omgeving waarbij meerdere VRF's op 1 locatie uitkomen. Dan zul je toch echt iets met bandbreedtebeperkingen moeten regelen, anders heb je kans dat Klant 1 de lijn van Klant 2 lekker vol drukt. Of nog erger, je windows beheerder die over het beheernetwerk een servicepack gooit en beide klanten buiten spel zet.

Vanuit het security oogpunt heb ik niet zo heel veel te maken met het ontwerpen van netwerken volgens het CDA model, maar ik doe toch QoS in mijn distrubutie laag en is mijn Core laag puur om alles zo snel mogelijk er doorheen te jakkeren zonder te kijken naar de QoS labels?

Goed, de vraag blijft staan!

[JackBol]

TrailBlazer schreef op vrijdag 30 januari 2009 @ 22:36:
[...]

In je backbone hoor je gewoon een MTU te hebben van 9124.
Het was een beetje chargerend maar QoS klinkt vaak heel erg leuk de vraag is echter of meer bandbreedte uiteindelijk niet goedkoper is. Meer bandbreedte is gewoon een stuk eenvoudiger te beheren.

Meer bandbreedte gaat niet helpen in het geval van microbursts of overboeking.

Voor WANs is meer bandbreedte een oplossing, maar als je boven de 50 of 100Mbps komt, ga je over LAN QoS praten, waar hele andere criteria gelden.

[Skins]

_DH schreef op zaterdag 31 januari 2009 @ 00:16:
[...]


Meer bandbreedte gaat niet helpen in het geval van microbursts of overboeking.

Voor WANs is meer bandbreedte een oplossing, maar als je boven de 50 of 100Mbps komt, ga je over LAN QoS praten, waar hele andere criteria gelden.

Waarover btw. een heeeele goede sessie was @ Networkers

[zenith]

Als ik het zo lees heeft het misschien nog wel wat weg van XOS (Extreme Networks), met de linux kernel en modules die je erbij kunt doen.

_DH schreef op vrijdag 30 januari 2009 @ 21:14:
[...]

[ Voor 7% gewijzigd door zenith op 31-01-2009 18:46 ]

[Mr.Nash]

Had even een vraagje tussendoor: Is het niet mogelijk om tussen LWAPP AP's als client te roamen? Kan niks over client-roaming vinden, het enige wat ik vind gaat over controller-roaming van AP's. (Heb ook niet echt superveel ervaring met wireless)

Anyways om toch even een update over mijn certificaten te geven: Vorige week heb ik in Barcelona m'n CCDA examen gedaan. Heb bij het examen af en toe moeten gokken maar met mijn recente CCIE theorie studie was heel veel toch te doen. Had voor het examen zelf heel weinig gestudeerd (een samenvatting doorgenomen). Denk dat ik CCDP er dan toch direct achteraan doe en CCIE written even uitstel (ja alweer , heeft ook te maken met apparatuur aangezien ik eerst een hoeveelheid technologielabs van IE gedaan wil hebben voordat ik de written doe).

[Whizzer]

Roamen gaat goed tussen de LWAPP's en voor zover ik me kan herinneren zet je client na het aanmelden op het sterkste APP al wel een verbinding op met een ander LWAPP. Als na verloop van tijd het signaal van je andere LWAPP veel sterker wordt dan die van het LWAPP waarmee je in eerste instatie verbinding hebt, roam je vanzelf.

Heb je losse controllers of gebruik je de blades voor de 6500?

[Mr.Nash]

Losse controllers. Het roamen is geen specifieke eis/wens van de klant maar meer een eigen interesse. Heb nog een dag om met deze apparatuur te spelen voordat ik ze in de loop van volgend week in productie zal brengen. Zal volgend week even kijken of er idd geroamed wordt of niet.

Het klopt trouwens wel dat de client met een 2de (eventueel ook een 3de) AP is verbonden mits deze hetzelfde SSID en inloggevens delen. Zo kan je inderdaad wel spreken over roaming maar dan vanaf clientside terwijl ik meer geinteresseerd was vanuit de AP/WLC.

[Whizzer]

AP/WLC ziet wel welke client op welke LWAPP is aangemeld of "backup" verbinding mee heeft, maar het initiatief voor roamen komt echt vanaf de client.

WLC's in de 6500 zijn een beetje verneukeratief... Dat zijn namelijk 2 controllers geïntegreerd in één blade, maar die moet je dus ook elke apart configureren. Wil je dan ook no redundancy over je 6500's heen, dan moet je dus 2 blades hebben en zijn er dus 4 controllers te beheren. Gelukkig heeft Cisco er wat overkoepelende software voor...

Even vloeken in deze Cisco kerk: Een jaar of wat geleden ooit eens een presentatie van Foundry gehad over hun Wireless oplossingen. Dat zag er ook wel ruig uit. Hele korte samenvatting: Al hun AP's zitten op hetzelfde kanaal en acteren als één accesspoint. De client heeft dus altijd het idee verbinding met hetzelfde AP te hebben. Er zat ergens een bepaalde intelligentie die ervoor zorgde dat de AP's niet met elkaar interferreerde ondanks dat ze allemaal op hetzelfde kanaal zaten. Met deze oplossing waren het dus ook de AP's die uitmaakte wie waarnaartoe "roamde". De associaties werden gewoon door een ander AP overgenomen. De latency bij roaming zou daardoor ook drastich minder worden. Helaas zelf nooit kunnen testen en dus de verkoper moeten geloven op zijn blauwe ogen.

[BrammeS]

_DH schreef op vrijdag 30 januari 2009 @ 21:15:
Ik heb ook nog een mening over de nexus1000v.

Eigenlijk was deze bedoelt voor mijn collega's, maar ik wil em jullie niet onthouden.

*knip*

Zeer interessant verhaal. Ik stel dit soort toevoegingen aan dit topic erg op prijs.

keep it comming....

[zenith]

Whizzer schreef op vrijdag 06 februari 2009 @ 13:00:

Even vloeken in deze Cisco kerk: Een jaar of wat geleden ooit eens een presentatie van Foundry gehad over hun Wireless oplossingen. Dat zag er ook wel ruig uit. Hele korte samenvatting: Al hun AP's zitten op hetzelfde kanaal en acteren als één accesspoint. De client heeft dus altijd het idee verbinding met hetzelfde AP te hebben. Er zat ergens een bepaalde intelligentie die ervoor zorgde dat de AP's niet met elkaar interferreerde ondanks dat ze allemaal op hetzelfde kanaal zaten. Met deze oplossing waren het dus ook de AP's die uitmaakte wie waarnaartoe "roamde". De associaties werden gewoon door een ander AP overgenomen. De latency bij roaming zou daardoor ook drastich minder worden. Helaas zelf nooit kunnen testen en dus de verkoper moeten geloven op zijn blauwe ogen.

Dit noemen ze virtual cells, ik kwam hier het patent tegen
http://www.wipo.int/pctdb...US2006027145&DISPLAY=DESC

[ Voor 21% gewijzigd door zenith op 08-02-2009 17:57 ]

[joopv]

In een thuislab heb ik wat cisco routers aan elkaar geknoopt via serial, sdsl en ethernet. eigrp geconfigd.
Er ontstaat alleen een eigrp neighbourship met de routers die met ethernet aan elkaar hangen...

IP connectivity is goed, ik kan over alle links pingen. Alle interfaces hebben numbered links.

Ik zie waarschijnlijk iets simpels over het hoofd.... eigrp = udp multicast, hoe knal ik dat die links op?

[JackBol]

joopv schreef op zaterdag 14 februari 2009 @ 23:05:
In een thuislab heb ik wat cisco routers aan elkaar geknoopt via serial, sdsl en ethernet. eigrp geconfigd.
Er ontstaat alleen een eigrp neighbourship met de routers die met ethernet aan elkaar hangen...

IP connectivity is goed, ik kan over alle links pingen. Alle interfaces hebben numbered links.

Ik zie waarschijnlijk iets simpels over het hoofd.... eigrp = udp multicast, hoe knal ik dat die links op?

eigrp is agnostisch qua l2-protocol, dus het zal waarschijnlijk wel iets anders zijn. goeie network statements? geen access-lists?

debug eigrp eens en kijk eens of er een adjecency gevormd probeert te worden op een specifieke interface. Zie je van allebei de kanten verkeer?

[ Voor 10% gewijzigd door JackBol op 14-02-2009 23:30 ]

[joopv]

Oke, opgelost.. ik dacht dat een "redistribute connected" betekende dat er geen network statement nodig was voor dat netwerk. Na het toevoegen van network 10.0.0.0 (de numbered sdsl en serial) werkte het gewoon...

D 192.168.25.0/24 [90/2172416] via 10.1.1.5, 00:42:33, Serial0/0/0
C 192.168.24.0/24 is directly connected, FastEthernet0/0
D 192.168.26.0/24 [90/26716672] via 10.1.1.1, 00:10:38, ATM0/1/0.1
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C 10.1.1.0/30 is directly connected, ATM0/1/0.1
C 10.1.1.4/30 is directly connected, Serial0/0/0
D 10.1.1.111/32 [90/2297856] via 10.1.1.5, 00:51:08, Serial0/0/0
D 10.1.1.121/32 [90/1244672] via 10.1.1.1, 00:10:38, ATM0/1/0.1
C 10.1.1.141/32 is directly connected, Loopback0
C 192.168.0.0/24 is directly connected, FastEthernet0/1
S 192.168.100.0/24 is directly connected, FastEthernet0/1
S* 0.0.0.0/0 [254/0] via 192.168.0.1
c1841#

[TrailBlazer]

met redistribute connected maak je een redistributed route aan in EIGRP. Je hebt eigrp dus niet geconfigureerd op dat interface.

[BrammeS]

Heeft iemand ooit gewerkt met een routeringsprotocol op ASA's

Ik heb nu een situatie gebouwd waarbij ik 3 ASA's op 3 locaties geplaatst met tussen iedere locatie een VPN tunnel. Nu is het binnenkort de bedoeling dat er nog een x aantal locaties en dus ook ASA's worden bij geplaatst. Ik wil eigenlijk niet een full mesh aan VPN's gaan maken, maar wil eigenlijk iets met een routeringsprotocol gaan bouwen. Deze moet er dan voor zorgen dat indien bijvoorbeeld de hoofdlocatie waar iedere ASA sowieso een VPN naar toe krijgt wegvalt de andere locaties nog wel naar elkaar kunnen communiceren eventueel via meerdere hops.

- Welk routeringsprotocol kan ik het beste gebruiken?(Ik dacht zelf aan EIGRP).
- Zijn er andere zaken waar ik rekening mee moet gaan houden?

[TrailBlazer]

Het meest logische is om een hoofdlocatie en een backuplocatie te maken waar elke vestiging een VPN verbinding naar opzet. Tussen de hoofdlocatie en de backuplocatie maak je dan ook een VPN verbinding. Persoonlijk ben ik een fan van OSPF. Je plaatst je hoofdlocatie en backuploaktie in Area0 en elke andere lokatie in een andere Area. Het kan waarschijnlijk ook allemaal prima in een Area maar mocht het ooit allemaal groter worden dan is het wel prettig dat je daar niet meer hoeft te rotzooien.

[JackBol]

BrammeS schreef op zondag 15 februari 2009 @ 10:54:
Ik wil eigenlijk niet een full mesh aan VPN's gaan maken, maar wil eigenlijk iets met een routeringsprotocol gaan bouwen.

Heb je wel gewoon full-mesh layer3 connectiviteit? Kijk dan eens naar cisco's get-vpn.

[BrammeS]

_DH schreef op zondag 15 februari 2009 @ 14:41:
[...]


Heb je wel gewoon full-mesh layer3 connectiviteit? Kijk dan eens naar cisco's get-vpn.

Ik had ook al naar DMVPN gekeken. Maar volgens dit document ben ik zowel bij get-vpn als dmvpn gebonden aan het gebruik van routers.

[Bl@ckbird]

Met GETVPN als DMVPN kun je direct tussen bijlocaties VPN tunnels creëren. (Zonder dit eerst via een hoofdlocatie te routeren.) Dit wordt vooral bij VoIP gebruikt, omdat dit de latency laag houdt. Routers worden ook vaak als Voice Gateway's gebruikt. Daarom zijn routers beter in zaken als advanced QoS (met bijvoorbeeld NBAR) en GETVPN / DMVPN. (Op pagina 28 en 37 van deze PDF staan twee DMVPN DUAL Hub voorbeelden.)

ASA's zijn dedicated security doosjes en erg goed in het vullen van tunnels.
Op het gebied van IPSec - Remote Access / SSL VPN zijn ze beter dan de routers. (Zowel performance, als in features.) Maar soms zijn routers voor VPN's handiger dan ASA's.

De ASA doet OSPF en EIGRP waarbij je bij EIGRP GRE moet gebruiken. Bij OSPF ben je niet gebonden aan alleen Cisco apparatuur.

[ Voor 7% gewijzigd door Bl@ckbird op 15-02-2009 19:22 ]

[Whizzer]

Even reageren vanuit het sneeuwrijke Les Deux Alpes:

VPN's en routeringsprotocollen kunnen "uitdagingen" hebben. Over een standaard IPSec krijg je geen multicast en dus ook geen EIGRP of OSPF. Dit kun je bereiken door heel je verkeer in GRE te zetten en dàt vervolgens te versleutelen. Daar maakt DMVPN ook gebruik van. Maar zoals al geroepen, DMVPN is een router feestje. Dat gaat niet lukken op de ASA.

[TrailBlazer]

Als je op routers IPSec draait heb je dit volgens mij 9/10 keer icm GRE.

[Verwijderd]

Krijg je bij een CCNP (deel) certificaat (BSCI, ISCW, BCMSN of ONT) een bewijs thuis gestuurd net zoals bij ICND1 / ICND2? Of krijg je pas een certificaat als je alle vier de delen hebt gehaald...?

[TrailBlazer]

Toen ik het deed kreeg je pas een certificaat als je alle examens voor het CCIP gehaald. Wel kreeg je bij CCSP een hoop deelcertificaten voor specialist examens.

[joopv]

TrailBlazer schreef op maandag 16 februari 2009 @ 19:05:
Als je op routers IPSec draait heb je dit volgens mij 9/10 keer icm GRE.

Vanaf 12.4.4T (oid) zou je multicast over ipsec moeten kunnen doen. Dus eigrp/ospf is dan mogelijk, zonder GRE tunnel er overheen.

[paella]

Dat soort vragen worden op de cisco certification site duidelijk beantwoord...

[BrammeS]

joopv schreef op maandag 16 februari 2009 @ 22:03:
[...]

Vanaf 12.4.4T (oid) zou je multicast over ipsec moeten kunnen doen. Dus eigrp/ospf is dan mogelijk, zonder GRE tunnel er overheen.

Helaas heb ik te maken met ASA's en dus ook met ASAOS. Versie 8.0(3). Ik zal eens kijken of ik kan vinden over dat multicast verhaal.

Trouwens vanmiddag mijn CXFF examen gepland voor 2 maart, nog even 2 weekjes aan de bak dus.

[ Voor 11% gewijzigd door BrammeS op 16-02-2009 22:26 . Reden: typo. ]

[joopv]

In veel situaties moet je QoS toapssen in de een of andere vorm. Wat mij altijd frustreerd is het testen van een QoS config. Pingen of tracen heb je niets aan. De ervaring van de klant is uiteindelijk de beste graadmeter, maar ik wil eigenlijk de klant met zijn QoS probleem / applicatie niet lastigvallen, maar zelfstandig zoveel mogelijk testen kunnen uitvoeren.

Wat ik nodig denk te hebben is een tool wat een bepaald tcp verkeerstype kan genereren (of eigenlijk meerdere verkeerstypes tegelijk) en de performance daarvan kan meten, zoals de latency en het bandbreedte plafond. Kent iemand een dergelijk tool?

Andere ideeen over het testen van QoS zijn ook welkom.

[TrailBlazer]

Je kan dat prima testen met een sla monitor.
http://www.cisco.com/en/U...uration/guide/hsla_c.html
Kwestie van het goede tos bit zetten zodat je ip sla pakketten bijvoorbeeld in voice klasse komen.
Latency kan echt prima met ip sla.
Bandbreedte wil je niet testen omdat dat veels te veel impact heeft.

[ Voor 19% gewijzigd door TrailBlazer op 17-03-2009 09:44 ]

[JackBol]

joopv schreef op dinsdag 17 maart 2009 @ 09:35:
Andere ideeen over het testen van QoS zijn ook welkom.

Zoals trailblazer aangeeft is IP SLA een erg handige tool. Tegenwoordig alom aanwezig in 12.4 en 12.2S releases.
Een beetje praktisch inzichtelijk maken gaat met de gratis tool van solarwinds.

[BrammeS]

BrammeS schreef op maandag 16 februari 2009 @ 22:25:
[...]

Trouwens vanmiddag mijn CXFF examen gepland voor 2 maart, nog even 2 weekjes aan de bak dus.

Afgelopen maandag trouwens nog geslaagd voor mij CXFF(2e poging) met een score van 894(790 nodig) punten. Eerste keer had ik slecht 683 punten.

Hij viel vooral behoorlijk tegen op bijvoorbeeld vragen over Wifi en Cisco SBCS oplossingen.

[Verwijderd]

Heeft iemand een idee waar ik losse beugeltjes kan krijgen?

Ik heb al een tijdje een 2600 rond 'hangen' in mijn kast wat al aardig irritand was maar ik heb net een 3500 switch op marktplaats op de kop getikt maar daar zaten ook geen beugels bij waardoor ik nu 2 pizza dozen rond heb schuiven

[Bl@ckbird]

Voor de 2600:
ACS-2600RM-19= --- 19 Inch Rack Mount Kit for the Cisco 2600 series

Voor de Catalyst 3550:
RCKMNT-1RU= --- Rack Mount Kit for 1RU for 3750,3560,3550,2900-LRE-XL

Voor de Catalyst 3500XL:
STK-RACKMOUNT-1RU= --- Rack Mount Kit for 1RU Catalyst 1900,2900XL,3500XL / FastHub

Verkrijgbaar via diverse Cisco Partners en webshops.

[ Voor 17% gewijzigd door Bl@ckbird op 20-03-2009 12:19 ]

[joopv]

Ik denk dat ik heb die nog wel ergens in een doos heb slingeren.

[ Voor 25% gewijzigd door joopv op 20-03-2009 15:13 . Reden: gevonden! ]

[Verwijderd]

Bl@ckbird schreef op vrijdag 20 maart 2009 @ 11:19:
Voor de 2600:
ACS-2600RM-19= --- 19 Inch Rack Mount Kit for the Cisco 2600 series

Voor de Catalyst 3550:
RCKMNT-1RU= --- Rack Mount Kit for 1RU for 3750,3560,3550,2900-LRE-XL

Voor de Catalyst 3500XL:
STK-RACKMOUNT-1RU= --- Rack Mount Kit for 1RU Catalyst 1900,2900XL,3500XL / FastHub

Verkrijgbaar via diverse Cisco Partners en webshops.

Thanks voor de info!

Ik ga eerst even joopv vragen voor de beugels en anders ga ik hier zeker even rondneuzen.

Joopv, bij deze wil ik je dus vragen of je eventueel 4 beugeltjes die je over hebt kunt opsturen want ik zie dat je in Eindhoven woont wat niet echt om de hoek is.

Natuurlijk betaal ik voor de verzending.

[ Voor 13% gewijzigd door Verwijderd op 20-03-2009 20:31 . Reden: kon geen email vinden van Joopv ]

[joopv]

pm me op accountnaam @chello.nl

[ts_rensuh]

Verwijderd schreef op maandag 16 februari 2009 @ 20:19:
Krijg je bij een CCNP (deel) certificaat (BSCI, ISCW, BCMSN of ONT) een bewijs thuis gestuurd net zoals bij ICND1 / ICND2? Of krijg je pas een certificaat als je alle vier de delen hebt gehaald...?

Je krijgt pas een bewijs als je alle 4 de modules heb afgerond. Het enige wat je meekrijgt na het examen is een mooi A4tje met het bewijs dat je geslaagd bent.

[paella]

Daarom is CCSP (security) ook zo leuk, krijg je wel allerlei deelcerts

[TrailBlazer]

[pats mode]
er is maar een ding dat telt en dat is je nummer halen
[/pats mode]
Maar ff serieus het is leuk die certificaten maar uiteindelijk belanden ze in de kast.

[ts_rensuh]

TrailBlazer schreef op zaterdag 21 maart 2009 @ 11:12:
Maar ff serieus het is leuk die certificaten maar uiteindelijk belanden ze in de kast.

Precies, staat leuk op je cv maar uit eindelijk gaat het toch om de werkervaring die je heb met cisco.
Als je alleen inlogt op een paar routers en switches 1x in de week en je voert alleen show commando´s uit, heb je nog niks aan je Cisco papiertjes

[Turdie]

Wie iemand hoeveel het CCIE traject in totaal ongeveer kost?

[ Voor 5% gewijzigd door Turdie op 21-03-2009 15:10 ]

[Mr.Nash]

shadowman12 schreef op zaterdag 21 maart 2009 @ 15:00:
Wie iemand hoeveel het CCIE traject in totaal ongeveer kost?

Je kan het zo duur maken als je zelf wilt.

Ik ben atm bezig met m'n CCIE en ben al rond de 800e kwijt (zelf betaald). Ik had nog wel geluk dat ik de internetwork boeken van een collega kan lenen. Pas als ik die helemaal goed kan ga ik zelf nog een bootcamp volgen, dan pas gaan de kosten komen.

Heb trouwens in de tussentijd CCDA en CCDP gedaan. Die eerste was simpel, bij de tweede was ik bang dat ik hem niet zou halen. Wat had ik een geluk dat ik op Cisco networkers een paar designsessies heb gevolgd.

[TrailBlazer]

Boeken zijn zo'n 500 euro nu bestellen amazon.co.uk is nu denk ik het voordeligst
Remote labs 200 euro
Internetworkexpert 800 euro ofzo
Bootcamp 2500 euro geen idee of ik er wat aan heb gehab eigenlijk ik heb het gehaald in 1 keer en de baas betaalde dus uiteindelijk was het wel een goede keus denk ik.

CCIE wordt pas echt duur als je lab een aantal keer niet haalt. 1200 euro per keer plus je reiskosten/hotel kosten.

[BrammeS]

TrailBlazer schreef op zondag 22 maart 2009 @ 09:12:
Boeken zijn zo'n 500 euro nu bestellen amazon.co.uk is nu denk ik het voordeligst
Remote labs 200 euro
Internetworkexpert 800 euro ofzo
Bootcamp 2500 euro geen idee of ik er wat aan heb gehab eigenlijk ik heb het gehaald in 1 keer en de baas betaalde dus uiteindelijk was het wel een goede keus denk ik.

CCIE wordt pas echt duur als je lab een aantal keer niet haalt. 1200 euro per keer plus je reiskosten/hotel kosten.

Ik weet niet hoe het bij jullie werkgevers zit, bij veel studieovereenkomsten is het zo dat de examenkosten alleen de 1e keer worden vergoed. een CCNA examen van 150 euro lukt nog wel een keer, maar zodra het een examen van 1200 euro betreft wordt dit toch wel een erg duur.

Mijn eigen werkgever doet hier gelukkig niet zo moeilijk over.

Gisteren het BSCI boek binnen gekregen, dus ik kan de komende tijd weer aan de bak.

[TrailBlazer]

Als je wekgever per uur in een keer 30 euro extra kan vangen is die 1200 euro snel terugverdiend hoor.

[Mr.Nash]

Klopt. Ik heb ook al te horen gekregen dat je hem minstens 3x kan herkansen, niet dat ik dat nodig hoop te hebben maar een oud werknemer was 3x gezakt en is zonder overeenkomst weg gegaan.

[Verwijderd]

Ik ben vandaag begonnen met het blokken voor mijn CCNA met het boek van Todd Lammle. Ik heb wel de indruk dat het vrij droge theorie is. Ik ben benieuwd hoe het gaat vlotten

[Whizzer]

CCIE#23942

[Mr.Nash]

Dude, respect! Gefelicteerd. Security was het? Minder dan een jaar sinds je written toch?

Nu genieten van je nummer en vrije tijd.

[ Voor 64% gewijzigd door Mr.Nash op 27-03-2009 11:18 ]

[TrailBlazer]

Whizzer schreef op vrijdag 27 maart 2009 @ 10:59:
CCIE#23942

Feli man zware nacht geweest en je laat Simon er wel voor betalen he

[Whizzer]

Mr.Nash schreef op vrijdag 27 maart 2009 @ 11:14:
Dude, respect! Gefelicteerd. Security was het? Minder dan een jaar sinds je written toch?

Nu genieten van je nummer en vrije tijd.

Idd Security. Bizar jaar geweest moet ik zeggen; 24 juli written gehaald, 4 sept getrouwd met eind sept de huwelijksreis en half oktober begonnen met studeren voor het lab. Ik heb m'n vrouwtje beloofd dat we nu maar eens moeten beginnen met de "wittebroodsweken".

TrailBlazer schreef op vrijdag 27 maart 2009 @ 11:29:
[...]

Feli man zware nacht geweest en je laat Simon er wel voor betalen he

Nachten zijn niet zo zwaar geweest hoor. Was dusdanig gaar dat ik erg makkelijk in slaap viel. Het uitslapen wat ik had willen doen is alleen mislukt. Voor het eerst in mijn leven was ik bang voor m'n mailbox.. Maar toen het eerste mailtje van ciscotrianing als onderwerp "Congratulations...." voor mijn neus stond was dat wel voorbij! Ik kon het eerst niet geloven, dus op de cisco pagina gekeken of het er echt stond.

[TrailBlazer]

Dan hebben ze dat aangepast want ik kreeg gewoon een mailtje dat mijn uitslag er was. Vervolgens met trillende vingers en een hartslag van 200 wachtwoord ingetikt.

[Whizzer]

Dat mailtje had ik ook (timestamp: 3:36), maar om 9:01 was er nog eentje achteraan gekomen.

[TrailBlazer]

Ok dat kan wel kloppen dan ja. Ik had al om 4:30 gekeken ofzo.

[battler]

Gefelicteerd

[Mr.Nash]

Vandaag dan toch eindelijk m'n written gehaald. Vanaf morgen wordt het weer keihard labs oefenen. Ik begin met QoS en BGP om m'n CCIP te halen tussendoor, moet te doen zijn en het is een goede graadmeter om te zien of ik goed genoeg leer..

[TrailBlazer]

woei voor mij was het written moeilijker dan het lab. Voor het written ben ik een keer gezakt voor het lab niet ;0

[Mr.Nash]

Tja, als je het zo bekijkt wel ;p.

Ik vond hem niet zo heel erg moeilijk. Heel veel dingen kwamen bekend voor doordat ik de afgelopen 5 dagen bijna continu bezig ben geweest met het herhalen van stof. Daarnaast waren er ook best veel makkelijke vragen tussen die je gewoon hoort te weten (bijv hoe de cost wordt berekend bij stp)..

[TrailBlazer]

Ok wanneer gebruik je cost en wanneer gebruik je port priority met STP

[Kippenijzer]

Puur een test van mijn eigen zelf opgedane kennis... Port prio is puur voor de switch zelf, cost speelt mee voor links met andere switches, right?

[JackBol]

Kippenijzer schreef op maandag 30 maart 2009 @ 23:38:
Puur een test van mijn eigen zelf opgedane kennis... Port prio is puur voor de switch zelf, cost speelt mee voor links met andere switches, right?

Dat is vrij goed denk ik.
AFAIK is cost belangrijk om het meest ideale pad naar de root te bepalen en port-prio is volgens mij meer een tie-breaker op de switch zelf wanneer er meerdere paden met dezelfde cost zijn.

[Whizzer]

Mr.Nash schreef op maandag 30 maart 2009 @ 18:59:
Vandaag dan toch eindelijk m'n written gehaald. Vanaf morgen wordt het weer keihard labs oefenen. Ik begin met QoS en BGP om m'n CCIP te halen tussendoor, moet te doen zijn en het is een goede graadmeter om te zien of ik goed genoeg leer..

Goed bezig! De CCIE (in wording) populatie hier begint toch wel te groeien.

M'n written had ik ook in één keer en vond ik niet zo spannend. Veel algemene kennis (ESP protocol, SMTP poort, etc.) en enkele Cisco specifieke commando's. Ik had alleen een of ander wazig beta examen voor de nu aankomende versie 3.0 van CCIE Security. De passing-score was dan ook maar 56. Mijn score was overigens wel hoger hoor..

Ik zag het als een mooie manier om m'n CCNP en CCDP te verlengen.

[zenith]

Gefeli Whizzer! Ik heb mijn lab (R&S) ook geboekt, het duurt nog wel een paar maanden maar ben al 3 maanden hard bezig met labs oefenen.

[ Voor 83% gewijzigd door zenith op 02-04-2009 20:50 ]

[Mr.Nash]

Zo, m'n LAB geboekt. Ik heb nog precies 5 maanden om te labben, theorie verstevigen en mezelf op andere manieren klaar te stomen. Gister begonnen met QoS. De theorie gaat wel redelijk snel omdat ik net alles achter de rug heb voor de written. Ik ben toch vanaf 0 begonnen om notities te maken (met pen en papier, iets wat ik al in tijden niet heb gedaan).

Tot en met volgend week QoS en direct het QoS examen doen. Daarna BGP en het examen voor m'n CCIP.

Vanaf nu zal ik hier ook wat meer technische vragen stellen als ik ergens niet uitkom.

EDIT: Moet alleen nog betalen maar dat komt ook goed, wordt door de baas geregeld. Het is trouwens wel 1694 euro ipv de 1400 die ik dacht.

[ Voor 11% gewijzigd door Mr.Nash op 03-04-2009 11:42 ]

[TrailBlazer]

Je krijgt geen rekening thuisgestuurd je zal hem echt zelf (of je baas) moeten betalen. Let op want als je niet op tijd betaalt ben je je plekkie kwijt.

[Mr.Nash]

I know. Degene die hem betaald (m'n baas dus) is volgend week weer aanwezig dus dat gaat geregeld worden. Heb nog 2 maanden om te betalen.

Wat me trouwens opviel was dat er best veel plek vrij was. Dat is anders dan de verhalen die ik her en der hoor over dat het echt vol zit qua boekingen.

[TrailBlazer]

Ja dat is een heel stuk verbeterd sinds je binnen 3 maanden niet meer kan cancellen of reschedulen. In het verleden waren er heel veel mensen die regelmatig hun datum verzetten dus had je de keus of binnen 2 weken examen doen of pas over een half jaar.

[joopv]

Ik post het maar even in dit topic want het is zo specialistisch dat een apart topic overdone is... Over ISDN-2:

Dat levert KPN in 2 smaken: enkelvoudig (1*ISDN-2) en meervoudig (bundel van 2 of meer ISDN-2 lijnen).

Het functionele verschil tussen die 2 is dat bij een meervoudige ISDN-2 lijn bundel alle 4 of meer B kanalen onder hetzelfde nummer bereikbaar zijn, KPN regelt de toewijzing van de inkomende gesprekken over de B kanalen. Dit gaat in samenwerking met de telefooncentrale aan de klantzijde.

Nu wil ik tijdelijk een Cisco aansluiten op een van de ISDN2 lijnen van een meervoudige bundel, hoeft alleen maar te kunnen uitbellen. En dat krijg je niet zomaar voor elkaar. Ik heb wat trial-and-error experimentjes gedaan met tei toewijzing maar daar kreeg ik geen stabiele situatie mee, al kon ik wel een keer geslaagd uitbellen.

Kan dit uberhaubt werken en zo ja - wat moet je in een cisco configureren om dit voor elkaar te krijgen?

[TrailBlazer]

Een ISDN 2 heeft maar 2 B kanalen hoor vandaar ISDN 2. ISDN en dialing is sowieso een drama en ik naar ik hoopte uitgestorven
Begin eens met debug isdn q921 en q931. Vervolgens met het commando isdn test call een call opzetten.

[joopv]

Oke, ik heb een correctie in mijn post gedaan.

ISDN-2 (en ISDN-30) wordt zakelijk nog erg veel gebruikt. Cisco kan het dan wel uit zijn certificerings programma's gehaald hebben maar de praktijk heeft daar weinig mee te maken.

Die debugs en test call heb ik gedaan. Maar het lezen van een Cisco isdn-2 debug output is volgens mij maar voor een handjevol mensen op deze aardkloot weggelegd.

[ Voor 26% gewijzigd door joopv op 05-04-2009 12:02 ]

[TrailBlazer]

Ja klopt maar wij kunnen sowieso niks zonder config en wat output.

[Whizzer]

Ik volg het verhaal niet helemaal, maar was de smaak niet óf een ISDN-2 (2x B kanaal, 1x D kanaal) óf ISDN30 (30x B kanaal, 1x D kanaal). Misschien dat de KPN wat B kanaaltjes onbruikbaar maakt en je zo dus kunt beknibbelen op de bandbreedte. Maargoed, interface is dus een BRI of PRI en slechts af te monteren op één router (vanwege het ene D kanaal). Bij een juiste config moet dat gewoon goed werken, een jaar of 7 geleden regelmatig met ISDN-30 bundels gespeeld, dus ik weet nog wel zeker dat het werkt, maar kan de config even niet ophoesten.

Zoals Trail al zegt, post eens een stuk config!

[joopv]

Nee er bestaan diverse tussenvormen. Zoals ISDN-10/15/20 waarbij er maar zoveel kanalen van een PRI gebruikt kunnen worden. Een meervoudige bundel zou je kunnen beschouwen als een ISDN-4 of ISDN-6 lijn die fysiek over 2 of 3 BRI lijnen getransporteerd wordt.

Technisch is het allemaal lichtelijk onzinnig, maar het heeft allemaal te maken met prijsstellingen van producten. Een PRI kaart in een centrale is schreeuwend duur evenals aansluitkosten enz. en als een klant genoeg heeft aan 4 simultane lijnen is dit een goedkopere oplossing dan een PRI met ISDN-10 er op.

Ik heb geen debug output meer, de klant heeft ondertussen een gewone isdn-2 lijn aan laten leggen en daar is de cisco op afgemonteerd. Zonder problemen. Ik hoop eigenlijk dat er iemand ervaring met meervoudig isdn zou hebben icm cisco s/t wicje.

[JackBol]

joopv schreef op zondag 05 april 2009 @ 13:38:
Nee er bestaan diverse tussenvormen. Zoals ISDN-10/15/20 waarbij er maar zoveel kanalen van een PRI gebruikt kunnen worden. Een meervoudige bundel zou je kunnen beschouwen als een ISDN-4 of ISDN-6 lijn die fysiek over 2 of 3 BRI lijnen getransporteerd wordt.

Technisch is het allemaal lichtelijk onzinnig, maar het heeft allemaal te maken met prijsstellingen van producten. Een PRI kaart in een centrale is schreeuwend duur evenals aansluitkosten enz. en als een klant genoeg heeft aan 4 simultane lijnen is dit een goedkopere oplossing dan een PRI met ISDN-10 er op.

Klopt. Maar we hebben het hier over techniek en niet over prijsstellingen, dus als je over techniek praat is het veel makkelijker om gewoon de termen ISDN-2 en ISDN-30 (of beter nog, BRI en PRI) te hanteren.

Vijf ISDN-2's maakt geen ISDN-10. En KPN's ISDN-1 is gewoon een kreupele vorm van ISDN-2 waarbij een datakanaal ( onbruikbaar is gemaakt.

Ik heb geen debug output meer, de klant heeft ondertussen een gewone isdn-2 lijn aan laten leggen en daar is de cisco op afgemonteerd. Zonder problemen. Ik hoop eigenlijk dat er iemand ervaring met meervoudig isdn zou hebben icm cisco s/t wicje.

Als alle BRIs op de zelfde router getermineerd worden, kan je ze toch gewoon in dezelfde dialer pool stoppen?

Voorbeeld: http://www.cisco.com/en/U...ple09186a00800a3b7a.shtml

[ Voor 3% gewijzigd door JackBol op 05-04-2009 15:26 ]

[zenith]

Ik heb geen debug output meer, de klant heeft ondertussen een gewone isdn-2 lijn aan laten leggen en daar is de cisco op afgemonteerd. Zonder problemen. Ik hoop eigenlijk dat er iemand ervaring met meervoudig isdn zou hebben icm cisco s/t wicje.

Wat wil je nou weten/maken, of wat heb je zelf al gemaakt?
DDR of Dialback of welke van de 10 vormen? Moeten beide kanalen altijd uitbellen of als 1 B-kanaal vol begint te raken? Kijk uit dat hij niet uitbelt bij netbios of andere broadcast protocollen, anders kom je misschien wat hoger uit qua kosten per maand.

[TrailBlazer]

samengevat alle mogelijke opties werken gewoon op een Cisco. Er zat ongetwijfeld iets fout in je configuratie.

[joopv]

Gewoon dialout, geen dialback / spoofing en andere ongein. Er loopt een multipoint vpn tunnel over en de belkosten zijn geen issue. Het probleem m.b.t. meervoudig / enkelvoudige isdn zit op q921 of misschien q931, niet op de hogere lagen zoals ppp en/of ip. Maar de debug output daarvan interpreteren (deb isdn q921 / q931) is geen kattepis. Diverse ATM bijbels doorspitten is niet echt een optie.

Een isdn test call int bri0/1/0 020xxxxxxx (met het juiste nummer) werkte ook niet. Static tei geprobeerd op de bri interface, nog wat andere opties. Een speciaal ISDN testapparaat wat de KPN monteur bij zich had werkte wel op dezelfde lijn. Een gewone ISDN telefoon had ik helaas niet bij me. KPN was niet bereid om 'even' die lijn om te zetten naar enkelvoudig ISDN (en dat kan ik me best voorstellen).

Met een reguliere enkelvoudige isdn-2 lijn werkt alles probleemloos, zelfde bri config (auto tei). Gewoon er in geprikt en binnen een paar seconden connectivity.

zenith schreef op zondag 05 april 2009 @ 15:41:
[...] Wat wil je nou weten/maken, of wat heb je zelf al gemaakt?

Wat het essentiele verschil is tussen enkelvoudig en meervoudig isdn, en hoe je dat verwerkt in een cisco config (als het al mogelijk is)

[ Voor 13% gewijzigd door joopv op 05-04-2009 17:12 ]

[zenith]

joopv schreef op zondag 05 april 2009 @ 17:08:
Gewoon dialout, geen dialback / spoofing en andere ongein. Er loopt een multipoint vpn tunnel over en de belkosten zijn geen issue. Het probleem m.b.t. meervoudig / enkelvoudige isdn zit op q921 of misschien q931, niet op de hogere lagen zoals ppp en/of ip. Maar de debug output daarvan interpreteren (deb isdn q921 / q931) is geen kattepis. Diverse ATM bijbels doorspitten is niet echt een optie.

Een isdn test call int bri0/1/0 020xxxxxxx (met het juiste nummer) werkte ook niet. Static tei geprobeerd op de bri interface, nog wat andere opties. Een speciaal ISDN testapparaat wat de KPN monteur bij zich had werkte wel op dezelfde lijn. Een gewone ISDN telefoon had ik helaas niet bij me. KPN was niet bereid om 'even' die lijn om te zetten naar enkelvoudig ISDN (en dat kan ik me best voorstellen).

Met een reguliere enkelvoudige isdn-2 lijn werkt alles probleemloos, zelfde bri config (auto tei). Gewoon er in geprikt en binnen een paar seconden connectivity.


[...]

Wat het essentiele verschil is tussen enkelvoudig en meervoudig isdn, en hoe je dat verwerkt in een cisco config (als het al mogelijk is)

Hebben die lui geen faxen of andere telefoons aan het NT kastje geprikt die soms ineens een kanaal wegpikken?
Heb jeje isdn switchtype goed staan in de router, paste eens wat config/show isdn status en debug output in een pastebin ofzo, anders is dit een gebed zonder eind.