Difference between revisions of "CCDP-Campus Viborg/Opgave 2/Gruppe1337"

Revision as of 13:01, 7 September 2010

Protocols

Routing Protocols

BGP - Border Gateway Protocol

 - Vi vil implementere BGP i vores setup da vi på den måde kan distribuere route tabeller mellem satelit filialerne. 
 

 Fordele:
  - BGP er uafhængig af hops mellem routere på netværket.
  - BGP har et begrænset båndbredde overhead.
  - BGP er skalerbar.
 

 Ulemper:
  - BGP kræver at fungerende layer 3 netværk for at fungere.
  - BGP kræver megen konfiguration og administration.

EIGRP - Enhanced Interior Gateway Routing Protocol

 - Vi vil implementere EIGRP for at være i stand til at route internet i filialerne.
 

 Fordele:
  - EIGRP er nem at konfigurere.
  - EIGRP er meget fleksibel, hvilket gør den egnet til næsten alle netværk.
 

 Ulemper:
  - EIGRP er Cisco proprietær.

First Hop Redundancy Protocols

GLBP - Gateway Load Balancing Protocol

 - Vi vil implementere GLBP frem for HSRP og VRRP for at mindske nedetid i tilfælde af nedbrud i distributionslaget.
 

 Fordele:
  - GLBP understøtter ægte Load Balancing. 
 

 Ulemper:
  - GLBP er Cisco proprietær. 

Technology

SIKKERHED

VRF

 - Vi opsætter VRF for at kunne lave seperate layer 3 netværk. Dette vil højne sikkerheden ved at gruppere brugere mm. i logisk adskilte netværk.
 

 Fordele:
  - Vi kan nemmere kontrollere brugernes adgang til forskellige netværks ressourcer. 
 

 Ulemper:
  - VRF kræver megen konfiguration, da alle enheder skal konfigureres. 

VLAN

 - Vi opsætter VLAN for at kunne separerer layer 2 netværk i logiske endheder. Dette vil mindske broadcast domænerne og mindske den adgang brugerne har til de enkelte netværks resourcer
 

 Fordele:
  -Mindskede bordcast domæner.
  -Mindskede adgang til de enkelte netværks resourcer
 

 Ulemper:
  -Skal opsættes på alle switche.

Port Guard:

DHCP Snooping:

DHCP Snoopin vil vi bruge til og forhindre der er andre der udgiver sig for og være dhcp server end vores egentlige dhcp server og blokere trafik der forsøger

 Fordele:
  -forhindre at der er andre der udgiver sig for og være dhcp server end den rigtige dhcp server .

Dynamic ARP Inspection:

vi vil bruge arp inspection til at minimere risikoen for arp spoofing og poisoning dette gøre ved hjælp af DHCP snooping tabellen.

IP Source Guard:

ACL:

ACCESS

Port Fast:

WLAN:

Performance

PAgP:

Spanning Tree:

 - Alt efter hvordan designet af netværket udsiller sig, vælger vi enten at kører RPVST+ eller at kører helt uden spanning tree.

 RPVST+
 Fordele:
  - RPVST+ har den fordel at du kan have spanning tree pr. vlan, som navnet siger.
    Forestil dig dette senario.
    Du har 20 switche, alle trunket sammen. Nu begynder en link at flappe, dette vil påvirke alle vlan's hvis du bruger
    traditionel spanning tree. Med RPVST+ vil det kun påvirke det enkelte vlan.
  - Få opdelt netværket, for lettere fejlfinding, samt lettere administration, og adgang til de forskellige netværk.
  - Få stoppet broadcast storme, og genneral unødvendig trafik.
  - Sørge for at loops ikke kan opstå.
  

 Ulemper:
  - CPU forbrug.
  - Unødvendig trafik hvis netværksdesignet unødvendigøre spanning tree.
  

  

 Uden Spanning Tree
 Fordele:
  - Lavere CPU forbrug.
  - Ingen unødvendig trafik med opdaterings pakker mm.
  

 Ulemper:
  - Hvis netværks designet ikke tillader at undlade spanning tree, vil netværket kunne lave loops.

BPDU Guard:

 - Vi vil konfigurere BPDU Guard på vores layer 2 switche hvor der i forvejen er konfigureret PortFast, for at forhindre elever mm. at sætte andet netværksudstyr på netværket samt for at afsikre loops på netværket.
 

 Fordele:
  - Forhindre loops og andet netværksudstyr ved at lukke porten ned hvis den modtager en BPDU pakke.
 

QoS:

ULDU:

SNMP:

 - Vi vil implementere SNMP i vores setup, så vi har overvågnings på vores netværk og udstyr. 
 

 Fordele:
  - SNMP giver nemmere og mere overskuelig information vedr. netværket og udstyr, på den måde er det nemmere at fejlfinde ved evt. fejl.

Downtime Calculation

Cisco used to publish this information in the data sheets, in fact you used to be able to find the MTBF and MTTR.

While trying to provide a detailed analysis of availability for a client's data center design we required some MTBF and MTTR numbers for the calculations. When we couldn't find the data in the regular channels (CCO) we hit the Cisco sales team for some info. There was an issue with them finding it and we wound up talking to product managers back in San Jose.

The long and short of it was this; Cisco doesn't publish those numbers anymore because they can be misleading and are very misunderstood by clients. The interrelation between the software and hardware components of the network devices can cause issues that cannot be calculated effectively in MTBF. If the MTBF rates the hardware components (as mentioned above, the MTBF is good for the chassis) but a software bug causes a company's router to go down a week after it was put on line then the customer sees the ~400,000 hr MTFB as a false number and then the customer is dissapointed in the device's performance.

We did finally manage to get the MTBF numbers for the devices we were analyzing. When the calculations were done the supposedly five 9's data center had network hardware that could only provide three 9's, mathamatically speaking. Did this really mean that the data center was going to fail more often with this design and hardware? No, there are other mitigating factors to compensate for this, however when the simple math is done it looks really bad.

The moral of the story is that when it comes to MTBF...your mileage may vary, A LOT!

//Reference "Henrik Kjær, Network Support Engineer, NetDesign A/S"

Lektier

 Sikkerhed
   - VRF - Jonas <done>
   - VLAN - Jonas <done>
   - Port Guard - Jakob
   - DHCP Snooping - Jakob
   - Dynamic ARP Inspection - Jakob
   - IP Source Guard - Jakob
   - ACL - Jakob
 

 Access
   - Port Fast  - Jeppe & Daniel
   - WLAN - Jonas
   - Switchport Mode Access - Jeppe & Daniel
 

 Performance
   - PAgP - Jonas
   - Spanning tree - Jeppe & Daniel
   - BPDU Guard - Jeppe & Daniel <done>
   - QoS - Jonas
   - ULDU - Jonas
   - SNMP - Jeppe & Daniel <done>