Difference between revisions of "Developing an optimum Design for Layer 3"
m (→Defensive filtering) |
m (→OSPF Scalability best practise) |
||
| (13 intermediate revisions by one other user not shown) | |||
| Line 3: | Line 3: | ||
__TOC__ | __TOC__ | ||
= At designe avancerede IP adresserings løsninger = | = 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 == | ||
| − | + | Nat mellem private adresser anbefales ikke<br/> | |
| + | Nat gør netværksfejlfinding mindre overskueligt.<br/> | ||
| + | Nat til eksterne partnere. | ||
=== Content Load-Balancing Device === | === 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 | 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 | ||
| Line 12: | Line 38: | ||
* En kombination af flere faktorer der beskriver servernes belastning | * 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] | For eksempel [http://www.cisco.com/en/US/products/hw/contnetw/ps792/index.html Cisco CSS 11500 Series Content Services Switch] | ||
| + | |||
= Designing avanceret Routning = | = Designing avanceret Routning = | ||
==Inappropriate Transit Traffic== | ==Inappropriate Transit Traffic== | ||
| Line 30: | Line 57: | ||
Two companies have been merged. Company A are running EIGRP and Company B are running OSPF.<br/> | 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 1: Redistribute between A & B<br/> | ||
| − | Step 2: Enable OSPF in | + | 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/> | Step 3: When OSPF is running and is fully converged, Remove EIGRP<br/> | ||
| + | |||
== Route Summarization og Default Routing == | == Route Summarization og Default Routing == | ||
| Line 38: | Line 66: | ||
*Any one Router should have no more than 60 adjacent neighbors | *Any one Router should have no more than 60 adjacent neighbors | ||
*An area should have no more than 50 Routers | *An area should have no more than 50 Routers | ||
| − | *Any one Router should not be in | + | *Any one Router should not be in more than three areas |
*Already heavily loaded Routers should not be DR and BDR | *Already heavily loaded Routers should not be DR and BDR | ||
| + | |||
==Designing Areas== | ==Designing Areas== | ||
Network topology and addressing should be designed initially with division of areas in mind. | Network topology and addressing should be designed initially with division of areas in mind. | ||
| Line 49: | Line 78: | ||
*Make nonbackbone areas stub or totally stubby areas | *Make nonbackbone areas stub or totally stubby areas | ||
*Make it summarized | *Make it summarized | ||
| − | + | {| | |
| − | [[Image: | + | |[[Image:ScreenShot308.jpg|800px|left|thumb|OSPF Areas & Area Summarization]] |
| + | |} | ||
| + | |||
| + | |||
| + | |||
==Yada yada OMG OSPF== | ==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/> | 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/> | ||
| Line 56: | Line 89: | ||
total of 9900 hellos per second.<br/><br/> | total of 9900 hellos per second.<br/><br/> | ||
'''Det er jo ikke realistisk, Cisco tag dig sammen''' | '''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: | {{#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;} | 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]] | [[Category:Network]][[Category:Cisco]][[Category:CCDP]] | ||
Latest revision as of 17:29, 23 May 2018
Kapitel 3 fra CCDP ARCH bogen.
This article is under development....Contents
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 27=128 forskellige krydsfelter eller lag 3 switche
- 3 bit til Roler giver 23=8 forskellige roler.
- 6 bit til hosts hvilket giver 26=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.
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:
access-list 101 pemit ip any 172.16.0.0 0.0.254.63
172.16.xxxxxxx0.00xxxxxxHvis 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
Nat gør netværksfejlfinding mindre overskueligt.
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 Cisco CSS 11500 Series Content Services Switch
Designing avanceret Routning
Inappropriate Transit Traffic
Defensive filtering
Route redistribution
Migrating Between Routing Protocols
Two companies have been merged. Company A are running EIGRP and Company B are running OSPF.
Step 1: Redistribute between A & B
Step 2: Enable OSPF in company A, and make sure it has the highest Administrativ Distance
Step 3: When OSPF is running and is fully converged, Remove EIGRP
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
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.
When the 3000 neighbors send 3 hellos per second back to the router, it has to process a
total of 9900 hellos per second.
Det er jo ikke realistisk, Cisco tag dig sammen
Incremental SPF
iSPF calculate only the part of the path tree that has changed.
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.
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...
