CCDP-Campus Viborg/Opgave 2/Gruppe1337

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:

VLAN:

Port Guard:

DHCP Snooping:

Dynamic ARP Inspection:

IP Source Guard:

ACL:

ACCESS

Port Fast:

WLAN:

Performance

PAgP:

Spanning Tree:

BPDU Guard:

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
   - QoS - Jonas
   - ULDU - Jonas
   - SNMP - Jeppe & Daniel <done>

Navigation menu