View source for Developing an optimum Design for Layer 3

Kapitel 3 fra [[CCDP|CCDP ARCH]] bogen.
{{In progress}}
__TOC__
= At designe avancerede IP adresserings løsninger =
Design en ip adresseplan.
==Role-Based addressing==
Hvis vi bruger 172.16.cccc cccR.RRhh hhhh til at indele vores netværk, får vi:
*7 bit til wireing closets giver 2<sup>7</sup>=128 forskellige krydsfelter eller lag 3 switche
*3 bit til Roler giver 2<sup>3</sup>=8 forskellige roler.
*6 bit til hosts hvilket giver 2<sup>6</sup>=64-2 hosts per subnet/VLAN
Samtidig er det vigtigt at netværkene bliver summerbare som i dette eksempel, hvor hvert krydsfelt kan summeres til /23.
<br/><br/>
Hvis vi kigger på ACL lister til disse netværker har vi 8 forskellige roller(3bit):
#000
#001
#010
#011
#100
#101
#110
#111
Hvis vi så skal lave en ACL der matcher Role 1 skal vi kun matche på de 3 bit der beskriver rolerne og ignorere alle andre. Det kunne fx se sådan her ud:
<br/>
<source lang=cli>
access-list 101 pemit ip any 172.16.0.0 0.0.254.63
172.16.xxxxxxx0.00xxxxxx
</source>
Hvis access listen bliver placeret på vlan interfacet INGRESS så ville de enkelte vlans ikke kunne snakke med de andre Roler, men kun deres egne i de andre krydsfelter.

== NAT ==
Nat mellem private adresser anbefales ikke<br/>
Nat gør netværksfejlfinding mindre overskueligt.<br/>
Nat til eksterne partnere.
=== Content Load-Balancing Device ===
En enhed der fordeler belastningen mellem flere Servere. For eksempel en enhed der fordeler forespørgsler fra WEB-brugere mellem ti identiske WEB-servere. Det kan være baseret på forskellige faktorer
* Antallet af forbindelser til hver server
* CPU belastning på Serverne
* En kombination af flere faktorer der beskriver servernes belastning
For eksempel [http://www.cisco.com/en/US/products/hw/contnetw/ps792/index.html Cisco CSS 11500 Series Content Services Switch]

= Designing avanceret Routning =
==Inappropriate Transit Traffic==
{|
|[[Image:ScreenShot306.jpg|800px|left|thumb|Dont do the job of your ISP]]
|}

==Defensive filtering==
{|
|[[Image:ScreenShot304.jpg|800px|left|thumb|Trust no one]]
|}

==Route redistribution==
{|
|[[Image:ScreenShot303.jpg|800px|left|thumb|Prefix-list, Route-maps or Tagging of routes]]
|}
==Migrating Between Routing Protocols==
Two companies have been merged. Company A are running EIGRP and Company B are running OSPF.<br/>
Step 1: Redistribute between A & B<br/>
Step 2: Enable OSPF in company A, and make sure it has the highest Administrativ Distance<br/>
Step 3: When OSPF is running and is fully converged, Remove EIGRP<br/>

== Route Summarization og Default Routing ==

=Designing Scalable OSPF Design=
==OSPF  Scalability best practise==
*Any one Router should have no more than 60 adjacent neighbors
*An area should have no more than 50 Routers
*Any one Router should not be in more than three areas
*Already heavily loaded Routers should not be DR and BDR

==Designing Areas==
Network topology and addressing should be designed initially with division of areas in mind.

General advice about OSPF design is:
*Minimize the routing information advertised into and out of the area.
*Experience shows that you should be conservative about adding routers to the backbone area.
*Make it simple
*Make nonbackbone areas stub or totally stubby areas
*Make it summarized
{|
|[[Image:ScreenShot308.jpg|800px|left|thumb|OSPF Areas & Area Summarization]]
|}



==Yada yada OMG OSPF==
If hello timers are set to 1/3 second for 300 interfaces, each with 10 neighbors, the router would have to generate 900 hellos per second.<br/>
When the 3000 neighbors send 3 hellos per second back to the router, it has to process a
total of 9900 hellos per second.<br/><br/>
'''Det er jo ikke realistisk, Cisco tag dig sammen'''
==Incremental SPF==
iSPF calculate only the part of the path tree that has changed.<br/>
The iSPF feature has been available since Cisco IOS Software Release 12.0(24)S, 12.3(2)T, 12.2(18)S, and 12.2(27)SBC. It is enabled with the iSPF router command under an OSPF process. 
{|
|[[Image:ScreenShot309.jpg|800px|left|thumb|SPF & iSPF comparison]]
|}
==Bidirectional forward detection==
BFD hjælper med at gøre route failover hurtigere ved at bruge en hurtigere lag 2 hello protokol end almindelige keep-alives. BFD skal også være understøttet af routing protokollen og har support i ospf, eigrp, isis og bgp. BFD kan tune rspons tiden ned til 50ms, hvad man er vant til fra SONET, men bruger ca 2 procent mere CPU.

=Designing Scalable BGP Designs=
'''Vis BGP slide...'''
==Scaling iBGP with Route Reflectors==
{|
|[[Image:ScreenShot311.jpg|800px|left|thumb|Image text]]
|}
==Scaling BGP with Confederations==
{|
|[[Image:ScreenShot312.jpg|800px|left|thumb|Image text]]
|}

{{#css:  
    pre {   font-family: Lucida Console; font-weight: bold; font-size: 14px; color: #00FF00; background: black; margin: 10px 50px; width: 800px; line-height: 200%; overflow: auto;}
}}
[[Category:Network]][[Category:Cisco]][[Category:CCDP]]