Difference between revisions of "CCDP-Campus Viborg/Opgave 2/Gruppe1337"
(→Lektier) |
(→VRF:) |
||
Line 54: | Line 54: | ||
===SIKKERHED=== | ===SIKKERHED=== | ||
====VRF:==== | ====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. | ||
+ | <br> | ||
+ | Fordele: | ||
+ | -<font color=green> Vi kan nemmere kontrollere brugernes adgang til forskellige netværks ressourcer. </font> | ||
+ | <br> | ||
+ | Ulemper: | ||
+ | -<font color=red> VRF kræver megen konfiguration, da alle enheder skal konfigureres. </font> | ||
+ | |||
====VLAN:==== | ====VLAN:==== | ||
====Port Guard:==== | ====Port Guard:==== |
Revision as of 12:28, 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:
Port Guard:
DHCP Snooping:
Dynamic ARP Inspection:
IP Source Guard:
ACL:
ACCESS
Port Fast:
WLAN:
Performance
PAgP:
Spanning Tree:
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 - VLAN - Jonas - Port Guard - Jakob - DHCP Snooping - Jakob - Dynamic ARP Inspection - Jakob - IP Source Guard - Jakob - ACL - Jakob
Access - Port Fast - Jeppe & Daniel - WLAN - Jonas
Performance - PAgP - Jonas - Spanning tree - Jeppe & Daniel - BPDU Guard - Jeppe & Daniel <done> - QoS - Jonas - ULDU - Jonas - SNMP - Jeppe & Daniel <done>