Difference between revisions of "Pederrs CCNP 1"

From Teknologisk videncenter
Jump to: navigation, search
(→‎Teori)
m
 
(51 intermediate revisions by one other user not shown)
Line 1: Line 1:
 
= Module 1: Scalable Network Design =
 
= Module 1: Scalable Network Design =
−
 
+
[[Category:Cisco]]
 
== Forkortelser: ==
 
== Forkortelser: ==
  
Line 15: Line 15:
  
 
== Forkortelser: ==
 
== Forkortelser: ==
 +
 +
'''AD''' = advertised distance (AD)
 +
 +
'''FD''' = feasible distance (FD)
 +
 +
'''AD og FD forklaring:'''
 +
The lowest cost route is calculated by adding the cost between the next-hop router and the destination—referred to as the advertised distance (AD)—to the cost between the local router and the next-hop router. The sum of these costs is called the feasible distance (FD).
 +
  
 
'''DUAL''' = Diffusing Update Algorithm (DUAL)
 
'''DUAL''' = Diffusing Update Algorithm (DUAL)
Line 38: Line 46:
  
 
'''SPF''' = Shortest Path First (SPF)
 
'''SPF''' = Shortest Path First (SPF)
 +
 +
 +
== Teori ==
 +
 +
 +
Although the metric can be based on five criteria, EIGRP uses only two of these criteria by default:
 +
 +
*Bandwidth: Smallest bandwidth between source and destination.
 +
*Delay: Cumulative interface delay along the path.
 +
 +
Three other criteria can be used, but are not recommended, because they typically result in frequent recalculation of the topology table:
 +
 +
*Reliability: Worst reliability between source and destination, based on keepalives.
 +
*Loading: Worst load on a link between source and destination, based on the packet rate and the configured bandwidth of the interface.
 +
*MTU: Smallest MTU in the path. MTU is included in the EIGRP routing update, but is not actually used in the metric calculation.
  
 
= Module 3: OSPF  =
 
= Module 3: OSPF  =
Line 45: Line 68:
 
== Teori  ==
 
== Teori  ==
  
−
=== Link State Routing Protocols ===
+
=== 3.1.1 Link State Routing Protocols ===
  
 
=== [[Image:CCNP-2.png]] ===
 
=== [[Image:CCNP-2.png]] ===
  
 +
<br><br>
  
 +
=== 3.1.3 Link State Data Structures  ===
  
−
=== Link State Data Structures ===
+
[[Image:CCNP-3.png]]
  
−
[[Image:CCNP-3.png]]
+
<br><br>
  
−
 
+
=== 3.1.6 Types of OSPF Routers ===
−
 
 
−
=== Types of OSPF Routers ===
 
  
 
The four different types of OSPF routers are:  
 
The four different types of OSPF routers are:  
Line 66: Line 89:
 
*Autonomous System Boundary Routers: Routers that have at least one interface attached to an external internetwork (another autonomous system), such as a non-OSPF network. Autonomous system boundary routers (ASBRs) can import non-OSPF network information to the OSPF network and vice versa; this process is called route redistribution.
 
*Autonomous System Boundary Routers: Routers that have at least one interface attached to an external internetwork (another autonomous system), such as a non-OSPF network. Autonomous system boundary routers (ASBRs) can import non-OSPF network information to the OSPF network and vice versa; this process is called route redistribution.
  
−
[[Image:CCNP-4.png]]
+
[[Image:CCNP-4.png]]  
 +
 
 +
<br><br>
 +
 
 +
=== 3.1.9 Link-State Data Structures  ===
 +
 
 +
When each router receives the LSU, it does the following:
 +
 
 +
*If the LSA does not already exist, the router adds the entry to its LSDB, sends a link-state acknowledgment (LSAck) back, floods the information to other routers, runs SPF, and updates its routing table.
 +
*If the entry already exists and the received LSA has the same sequence number, the router ignores the LSA entry.
 +
*If the entry already exists but the LSA includes newer information (it has a higher sequence number), the router adds the entry to its LSDB, sends an LSAck back, floods the information to other routers, runs SPF, and updates its routing table.
 +
*If the entry already exists but the LSA includes older information, it sends an LSU to the sender with its newer information
 +
 
 +
[[Image:CCNP-8.png]]
 +
 
 +
<br><br>
 +
 
 +
=== 3.2.1  OSPF Packet Types ===
 +
 
 +
The OSPF protocol exchanges five packet types:
 +
 
 +
*Hello
 +
*Database description (DBD)
 +
*Link-state request (LSR)
 +
*Link-state update (LSU)
 +
*Link-state acknowledgement (LSAck)
 +
 
 +
 
 +
[[Image:CCNP-5.png]]
 +
 
 +
<br><br>
 +
 
 +
=== 3.2.2  OSPF Packet Header Format ===
 +
 
 +
All five OSPF packets are encapsulated directly into an IP payload, as shown in Figure . The OSPF packet does not use TCP or User Datagram Protocol (UDP). OSPF requires a reliable packet transport scheme. Since TCP is not used, it has defined its own acknowledgment routine that uses an acknowledgment packet (OSPF packet type 5).
 +
 
 +
In the IP header, a protocol identifier of 89 defines all OSPF packets. Each of the OSPF packets begins with the same header format. This header has the following fields:
 +
 
 +
*Version number: For OSPF version 2 or 3
 +
*Type: Differentiates the five OSPF packet types
 +
*Packet length: Length of packet in bytes
 +
*Router ID: Defines which router is the source of the packet
 +
*Area ID: Defines the area where the packet originated
 +
*Checksum: Used for packet-header error detection to ensure that the OSPF packet was not corrupted during transmission
 +
*Authentication type: An option that specifies either no authentication, clear-text passwords, or encrypted Message Digest 5 (MD5) formats for router authentication
 +
*Authentication: Used in the authentication scheme
 +
*Data (for hello packet): Includes a list of known neighborsData (for DBD packet): Contains a summary of LSDB, which includes all known router *IDs and their last sequence number, among a number of other fields
 +
*Data (for LSR packet): Contains the type of LSU needed and the router ID that has the needed LSU
 +
*Data (for LSU packet): Contains the full LSA entries; multiple LSA entries can fit in one OSPF update packet
 +
*Data (for LSAck packet): Is empty
 +
 
 +
[[Image:CCNP-9.png]]
 +
 
 +
<br><br>
 +
 
 +
===  3.3.4  Configuring a Router ID ===
 +
 
 +
[[Image:CCNP-6.png]]
 +
 
 +
<br><br>
 +
 
 +
=== Verifying the OSPF Operation ===
 +
 
 +
[[Image:CCNP-7.png]]
 +
 
 +
<br><br>
 +
 
 +
===  3.6.3  OSPF LSA Types (cont.)  ===
 +
 
 +
'''Type 1'''
 +
Every router generates router link advertisements for each area to which it belongs. A type 1 LSA describes the collective states of the directly connected links (interfaces) of the router.  These LSAs are flooded only within the area in which they are originated.
 +
 
 +
'''Type 2'''
 +
A type 2 LSA is generated for every transit broadcast and NBMA network within an area. A transit network has at least two directly attached OSPF routers. Ethernet is an example of a transit network.
 +
 
 +
The DR of the network is responsible for advertising the network LSA. A type 2 network LSA lists each of the attached routers that make up the transit network, including the DR itself, as well as the subnet mask used on the link. The type 2 LSA then floods to all routers within the transit network area. Type 2 LSAs never cross an area boundary. The link-state ID for a network LSA is the IP interface address of the DR that advertises it.
 +
 
 +
'''Type 3'''
 +
The ABR sends type 3 summary LSAs. Type 3 LSAs advertise any networks owned by an area to the rest of the areas in the OSPF autonomous system, as shown in Figure .
 +
 
 +
The link-state ID is set to the network number; the mask is also advertised.
 +
 
 +
By default, OSPF does not automatically summarize groups of contiguous subnets or summarize a network to its classful boundary. The network operator uses configuration commands to specify how the summarization occurs. By default, a type 3 LSA is advertised into the backbone area for every subnet defined in the originating area, which can cause significant flooding problems. Consequently, you should always consider using manual route summarization at the ABR.
 +
 
 +
Summary LSAs are flooded throughout a single area only, but are regenerated by ABRs to flood into other areas.
 +
 
 +
Note
 +
By default, summary LSAs do not contain summarized routes.
 +
 +
 
 +
'''Type 4'''
 +
A type 4 summary LSA is generated by an ABR only when an ASBR exists within an area. A type 4 LSA identifies the ASBR and provides a route to it. The link-state ID is set to the ASBR router ID. All traffic destined to an external autonomous system requires routing table knowledge of the ASBR that originated the external routes.
 +
 
 +
In Figure , the ASBR sends a type 1 router LSA with an external bit (e bit) that is set to identify itself as an ASBR. When the ABR, which is identified with a border bit (b bit) in the router LSA, receives the type 1 LSA, it builds a type 4 LSA and floods it to the backbone (area 0). Subsequent ABRs regenerate a type 4 LSA to flood into their areas.
 +
 
 +
'''Type 5'''
 +
Type 5 external LSAs describe routes to networks outside the OSPF autonomous system. Type 5 LSAs are originated by the ASBR and are flooded to the entire autonomous system.
 +
 
 +
The link-state ID is the external network number. Because of the flooding scope, and depending on the number of external networks, the default lack of route summarization can be a major issue with external LSAs. Therefore, you should summarize blocks of external network numbers at the ASBR to reduce flooding problems.
 +
 
 +
'''Type 6'''
 +
Type 6 LSAs are specialized LSAs that are used in multicast OSPF applications.
 +
 
 +
'''Type 7'''
 +
Type 7 is an LSA type that is used in not-so-stubby areas (NSSAs). They are originated by ASBRs within NSSAs and are flooded only within the NSSA in which they originated.
 +
 
 +
'''Type 8'''
 +
Type 8 is a specialized LSA that is used in internetworking OSPF and Border Gateway Protocol (BGP).
 +
 
 +
'''Types 9, 10, and 11'''
 +
The opaque LSAs, types 9, 10, and 11, are designated for future upgrades to OSPF for application-specific purposes. For example, Cisco Systems uses opaque LSAs for Multiprotocol Label Switching (MPLS) with OSPF. Opaque LSAs are distributed using standard LSDB flooding mechanisms. Each type has a different flooding scope.
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
'''Standard area:''' Accepts link updates, route summaries, and external routes (the default).
 +
 
 +
 
 +
'''Backbone area (transit area):''' The central entity to which all other areas connect to exchange and route information. The backbone area is labeled area 0. The OSPF backbone includes all the properties of a standard OSPF area.
 +
 +
 +
'''Stub area:''' Does not accept information about routes external to the autonomous system, such as routes from non-OSPF sources. This means that no type 5 LSAs are known inside the area, and consequently type 4 LSAs are unnecessary. Type 4 and 5 LSAs are blocked.
 +
ABRs at the edge of the stub area use type 3 LSAs to advertise a single default route (0.0.0.0) into the area. If routers need to route to networks outside the autonomous area, they use the default route.
 +
Stub areas cannot contain ASBRs (except that the ABRs may also be ASBRs).
 +
 
 +
 
 +
'''Totally stubby area:''' Does not accept external autonomous system routes or summary routes from other areas internal to the autonomous system. The ABR of the totally stubby area blocks type 4 and 5 LSAs as well as all summary LSAs (type 3), with an exception of a single type 3 LSA to advertise the default route.
 +
The default route advertised by the ABR is used to reach destinations external to the autonomous system and all destinations external to the area. Therefore, if the router needs to send a packet to a network external to the area, it sends the packet using a default route.
 +
 
 +
Totally stubby areas cannot contain ASBRs (except that the ABRs may also be ASBRs).
 +
 
 +
 
 +
'''Not-so-stubby area:''' An NSSA is an addendum to the OSPF RFC. It offers benefits that are similar to those of a stub or totally stubby area, but also allows external routes to be advertised into the OSPF autonomous system. Therefore, NSSAs allow ASBRs, which is against the rule in a stub area.
 +
The ASBR originates type 7 LSAs to advertise the external destinations. The type 7 LSAs are flooded throughout the NSSA but are blocked by the ABR. The ABR converts the type 7 LSA into a type 5 LSA, which is then propagated through the remainder of the autonomous system.
  
 
= Module 4: Integrated IS-IS =
 
= Module 4: Integrated IS-IS =
 +
 +
== Forkortelser ==
 +
 +
'''MPLS/TE''' = Multiprotocol Label Switching Traffic Engineering (MPLS/TE).
 +
 +
 +
'''IGP''' = interior gateway protocol (IGP)
 +
 +
 +
'''CLNS''' =  Connectionless Network Service (CLNS)
 +
 +
 +
'''CLNP''' = Connectionless Network Protocol (CLNP)
 +
 +
 +
'''LSP''' = link-state packet (LSP)
 +
 +
 +
'''PDU''' = protocol data unit (PDU)
 +
 +
 +
'''IS''' = Intermediate System
 +
 +
 +
'''ES''' = end system (ES)
 +
 +
 +
'''ES-IS''' = End System-to-Intermediate System (ES-IS)
 +
 +
 +
'''ESH''' = End System Hello (ESH)
 +
 +
 +
'''ISH''' = Intermediate System Hello (ISH)
 +
 +
 +
'''IIH''' = IS-IS Hello (IIH)
 +
 +
 +
'''DIS''' = designated IS router (DIS)
 +
 +
 +
'''NSAP''' = network service access points (NSAP)
 +
 +
 +
'''NSEL''' = NSAP selector (NSEL)
 +
 +
 +
'''IDP''' = initial domain part (IDP)
 +
 +
 +
'''AFI''' = authority and format identifier (AFI)
 +
 +
 +
'''IDI''' = initial domain identifier (IDI)
 +
 +
 +
'''DSP''' = domain specific part (DSP)
 +
 +
 +
'''HO-DSP''' = high-order DSP (HO-DSP)
 +
 +
 +
'''SNPA''' = subnetwork point of attachment (SNPA)
 +
 +
 +
'''CLV''' = Code, Length, Value (CLV)
 +
 +
 +
'''SNP''' = Sequence number PDU (SNP)
 +
 +
 +
'''PRC''' = partial route calculation (PRC)
 +
 +
 +
'''Example of a net address:'''
 +
 +
 +
For example, you might assign 49.0001.0000.0c12.3456.00, which represents the following:
 +
 +
 +
AFI of 49
 +
Area ID of 0001
 +
System ID of 0000.0c12.3456, the MAC address of a LAN interface
 +
NSEL of 0
 +
 +
 +
== Teori ==
 +
 +
=== 4.1.2  IS-IS and OSPF ===
 +
 +
[[Image:CCNP-14.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 4.1.4  IS-IS Features ===
 +
 +
[[Image:CCNP-15.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  4.1.5  IS-IS Link-State Operation  ===
 +
 +
[[Image:CCNP-16.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  4.1.8  The ES-IS Protocol  ===
 +
 +
[[Image:CCNP-17.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  4.1.9  OSI Routing Levels  ===
 +
 +
[[Image:CCNP-18.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  4.1.10  IS-IS and OSPF Network Design  ===
 +
 +
[[Image:CCNP-19.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  4.1.11  Differences Between Integrated IS-IS and OSPF  ===
 +
 +
[[Image:CCNP-20.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 4.2.1  NSAP Addresses  ===
 +
 +
[[Image:CCNP-141.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  4.2.2  NSAP Address Structure  ===
 +
 +
[[Image:CCNP-21.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  4.2.3  NSAP Address Example  ===
 +
 +
[[Image:CCNP-22.png]]
 +
 +
<br><br>
 +
<br><br>
  
 
= Module 5: Route Optimization =
 
= Module 5: Route Optimization =
 +
 +
== Forkortelser ==
 +
 +
'''PBR''' = Policy-based routing (PBR)
 +
 +
 +
== Teori ==
 +
 +
 +
===  5.1.4  Using Seed Metrics  ===
 +
 +
[[Image:CCNP-25.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  5.1.6  Defining Administrative Distance  ===
 +
 +
[[Image:CCNP-26.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 5.3.2  Passive Interfaces  ===
 +
 +
[[Image:CCNP-27.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 5.4.1  Defining Route Maps  ===
 +
 +
[[Image:CCNP-28.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  5.4.3  Route Map Operation  ===
 +
 +
[[Image:CCNP-29.png]]
 +
 +
<br><br>
 +
 +
[[Image:CCNP-30.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 5.4.4  Using Route Map Commands  ===
 +
 +
[[Image:CCNP-31.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  5.5.3  Configuring DHCP  ===
 +
 +
[[Image:CCNP-32.png]]
 +
 +
<br><br>
 +
<br><br>
  
 
= Module 6: BGP =
 
= Module 6: BGP =
 +
 +
== Forkortelser ==
 +
Protocols that run inside an enterprise are called interior gateway protocols (IGPs). Examples of IGPs include RIP versions 1 and 2, EIGRP, and OSPF.
 +
 +
 +
Protocols that run outside an enterprise, or between autonomous systems, are called exterior gateway protocols (EGPs). Typically, EGPs are used to exchange routing information between Internet Service Providers (ISPs).
 +
 +
 +
'''IGP''': Exchanges routing information within an autonomous system. RIP, IGRP, OSPF, IS-IS, and EIGRP are IGPs.
 +
 +
 +
'''EGP''': Exchanges routing information between different autonomous systems. BGP is an EGP.
 +
 +
 +
'''IDRP''' = BGP is an interdomain routing protocol (IDRP), also known as an EGP.
 +
 +
 +
'''EBGP''' = When BGP is running between routers in different autonomous systems, it is called External BGP (EBGP).
 +
 +
 +
'''IBGP''' = When BGP is running between routers in the same autonomous system, it is called Internal BGP (IBGP).
 +
 +
 +
'''RIR''' = Regional Internet Registry (RIR)
 +
 +
 +
'''FSM''' = finite-state machine (FSM)
 +
 +
 +
 +
== Teori ==
 +
 +
 +
=== 6.1.2  BGP Multihoming Options ===
 +
 +
[[Image:CCNP-33.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.1.6  BGP Routing Between Autonomous Systems  ===
 +
 +
[[Image:CCNP-34.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 6.1.7  Path-Vector Functionality  ===
 +
 +
[[Image:CCNP-35.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.1.9  Features of BGP  ===
 +
 +
[[Image:CCNP-36.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 6.1.10  BGP Databases  ===
 +
 +
[[Image:CCNP-37.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 6.1.11  BGP Message Types  ===
 +
 +
[[Image:CCNP-38.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.2.2  Establishing a Connection Between External BGP Neighbors  ===
 +
 +
[[Image:CCNP-39.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 6.2.3  Establishing a Connection Between Internal BGP Neighbors  ===
 +
 +
[[Image:CCNP-40.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.2.5  IBGP in a Nontransit Autonomous System  ===
 +
 +
[[Image:CCNP-41.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.2.6  Routing Issues in a Transit Autonomous System  ===
 +
 +
[[Image:CCNP-42.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.3.1  Basic BGP Configuration  ===
 +
 +
[[Image:CCNP-43.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 6.3.2  Activate a BGP Session  ===
 +
 +
[[Image:CCNP-44.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 6.3.3  Shutting Down a BGP Neighbor  ===
 +
 +
[[Image:CCNP-45.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.3.4  BGP Configuration Considerations  ===
 +
 +
[[Image:CCNP-46.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.3.5  IBGP Peering Issue  ===
 +
 +
[[Image:CCNP-47.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 6.3.6  BGP neighbor update-source Command  ===
 +
 +
[[Image:CCNP-48.png]]
 +
 +
<br><br>
 +
 +
[[Image:CCNP-49.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.3.7  EBGP Peering Issue (EBGP Multihop) ===
 +
 +
[[Image:CCNP-50.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.3.8  Next Hop Behavior  ===
 +
 +
[[Image:CCNP-51.png]]
 +
 +
<br><br>
 +
 +
[[Image:CCNP-52.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.3.9  BGP neighbor next-hop-self Command  ===
 +
 +
[[Image:CCNP-53.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.3.10  Injection Routing Information into BGP  ===
 +
 +
[[Image:CCNP-54.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.3.12  BGP Synchronization  ===
 +
 +
[[Image:CCNP-55.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 6.3.13  BGP Synchronization Example  ===
 +
 +
[[Image:CCNP-56.png]]
 +
 +
<br><br>
 +
 +
[[Image:CCNP-57.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 6.4.1  BGP Neighbor States  ===
 +
 +
[[Image:CCNP-58.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.4.5  Configuring a Peer Group Example  ===
 +
 +
[[Image:CCNP-59.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.4.7  Configuring BGP Authentication  ===
 +
 +
[[Image:CCNP-60.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.4.11  Soft Reset of BGP Sessions  ===
 +
 +
[[Image:CCNP-61.png]]
 +
 +
<br><br>
 +
 +
[[Image:CCNP-62.png]]
 +
 +
<br><br>
 +
 +
[[Image:CCNP-63.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 6.5.3  AS Path Attribute  ===
 +
 +
[[Image:CCNP-64.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.5.4  Next-Hop Attribute  ===
 +
 +
[[Image:CCNP-65.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 6.5.5  Origin Attribute  ===
 +
 +
[[Image:CCNP-66.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.5.6  Local Preference Attribute  ===
 +
 +
[[Image:CCNP-67.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 6.5.7  MED Attribute  ===
 +
 +
[[Image:CCNP-68.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.5.8  Weight Attribute  ===
 +
 +
[[Image:CCNP-69.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  6.5.10  Selecting a BGP Path  ===
 +
 +
[[Image:CCNP-70.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 6.6.3  Changing the BGP Local Preference for All Routes  ===
 +
 +
[[Image:CCNP-71.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 6.6.7  Setting the MED with Route Maps  ===
 +
 +
[[Image:CCNP-73.png]]
 +
 +
<br><br>
  
 
= Module 7: IP Multicasting =
 
= Module 7: IP Multicasting =
 +
 +
== Forkortelser ==
 +
 +
VoD = video on demand [VoD]
 +
 +
 +
UDP = User Datagram Protocol (UDP)
 +
 +
 +
 +
Locally scoped (reserved link local) addresses 
 +
Reserved by the Internet Assigned Numbers Authority (IANA) for network protocol use.
 +
Address range is from 224.0.0.0 through 224.0.0.255.
 +
Multicasts in this range are never forwarded off the local network, regardless of Time to Live (TTL). Usually, the TTL is set to 1.
 +
 +
Globally scoped addresses
 +
Allocated dynamically throughout the Internet.
 +
Address range is from 224.0.1.0 through 238.255.255.255.
 +
The 224.2.X.X range is used in Multicast Backbone (Mbone) applications. Established by the Internet Engineering Task Force (IETF) to multicast audio and video meetings, Mbone is a collection of Internet routers that support IP multicasting on which various public and private audio and video programs are sent.
 +
 +
Limited (administratively) scoped addresses
 +
Reserved for use inside private domains. Similar to the private IP address space that is used within the boundaries of a single organization, limited or administratively scoped addresses are constrained to a local group or organization.
 +
Address range is from 239.0.0.0 through 239.255.255.255.
 +
Organizations can use limited scope addresses to have local multicast applications that will not be forwarded over the Internet.
 +
 +
 +
 +
 +
SDP = Session Description Protocol (SDP)
 +
 +
 +
SAP = Session Announcement Protocol (SAP)
 +
 +
 +
SDR = Both the sd application and SDP are sometimes called SDR or sdr. In Cisco documentation, SDP/SAP is referred to as sdr.
 +
 +
 +
SIP = Session Initiation Protocol (SIP)
 +
 +
 +
RTSP = Real Time Streaming Protocol (RTSP)
 +
 +
 +
IGMP = Internet Group Management Protocol (IGMP)
 +
 +
 +
CGMP = Cisco Group Management Protocol (CGMP)
 +
 +
 +
ASIC = application-specific integrated circuit (ASIC)
 +
 +
 +
CAM = content-addressable memory (CAM)
 +
 +
 +
SPT = shortest path tree (SPT)
 +
 +
 +
RP = rendezvous point (RP)
 +
 +
 +
PIM = Protocol-Independent Multicast (PIM)
 +
 +
 +
RPF = Reverse Path Forwarding (RPF)
 +
 +
 +
SSM = Source Specific Multicast (SSM)
 +
 +
 +
MSDP = Multicast Source Discovery Protocol [MSDP]
 +
 +
 +
OIL = outgoing interface list (OIL)
 +
 +
 +
DVMRP = Distance Vector Multicast Routing Protocol (DVMRP)
 +
 +
 +
 +
== Teori ==
 +
 +
===  7.1.3  Multicast Advantages and Disadvantages  ===
 +
 +
[[Image:CCNP-75.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 7.1.4  Multicast Applications  ===
 +
 +
[[Image:CCNP-76.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  7.1.5  IP Multicast Addresses  ===
 +
 +
[[Image:CCNP-77.png]]
 +
 +
<br><br>
 +
 +
[[Image:CCNP-78.png]]
 +
 +
<br><br>
 +
 +
[[Image:CCNP-79.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 7.1.6  Layer 2 Multicast Addressing  ===
 +
 +
[[Image:CCNP-80.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 7.2.2  IGMPv2 Join Group and Leave Group Messages  ===
 +
 +
[[Image:CCNP-81.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 7.2.3  Introducing IGMPv3  ===
 +
 +
[[Image:CCNP-82.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 7.2.5  Multicast in the Layer 2 Switching Environment  ===
 +
 +
[[Image:CCNP-83.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  7.2.6  Multicast in Layer 2 Solutions  ===
 +
 +
[[Image:CCNP-84.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  7.2.7  Cisco Group Management Protocol (CGMP)  ===
 +
 +
[[Image:CCNP-85.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 7.2.8  IGMP Snooping  ===
 +
 +
[[Image:CCNP-86.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 7.3.1  Protocols Used in Multicast  ===
 +
 +
[[Image:CCNP-87.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  7.3.2  Multicast Distribution Trees  ===
 +
 +
[[Image:CCNP-88.png]]
 +
 +
<br><br>
 +
 +
[[Image:CCNP-89.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  7.3.3  Multicast Distribution Trees Identification  ===
 +
 +
[[Image:CCNP-90.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 7.3.4  IP Multicast Routing  ===
 +
 +
[[Image:CCNP-91.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  7.3.5  Protocol-Independent Multicast: Describing PIM-DM  ===
 +
 +
[[Image:CCNP-92.png]]
 +
 +
<br><br>
 +
 +
[[Image:CCNP-93.png]]
 +
 +
<br><br>
 +
 +
[[Image:CCNP-94.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 7.3.6  Protocol-Independent Multicast: Describing PIM-SM  ===
 +
 +
[[Image:CCNP-95.png]]
 +
 +
<br><br>
 +
 +
[[Image:CCNP-96.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  7.4.1  Enabling PIM Sparse Mode and Sparse-Dense Mode  ===
 +
 +
[[Image:CCNP-99.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 7.4.2  Inspecting the Multicast Routing Table ===
 +
 +
[[Image:CCNP-100.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 7.4.3  Finding PIM Neighbors  ===
 +
 +
[[Image:CCNP-101.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  7.4.4  Checking RP Information  ===
 +
 +
[[Image:CCNP-102.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  7.4.5  Checking the Group State  ===
 +
 +
[[Image:CCNP-103.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 7.4.6  Configuring a Router to Be a Member of a Group  ===
 +
 +
[[Image:CCNP-104.png]]
 +
 +
<br><br>
  
 
= Module 8: IPv6 =
 
= Module 8: IPv6 =
 +
 +
== Forkortelser ==
 +
 +
'''RSVP''' = Reservation Protocol [RSVP]
 +
 +
 +
'''MLDv1''' = Multicast Listener Discovery version 1 [MLDv1]
 +
 +
 +
'''DAD''' = duplicate address detection (DAD)
 +
 +
 +
'''RIPng''' = Routing Information Protocol next generation
 +
 +
 +
'''RIB''' = Routing Information Base (RIB).
 +
 +
 +
'''ISATAP''' = Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
 +
 +
 +
'''NAT-PT''' = NAT-Protocol Translation (NAT-PT)
 +
 +
 +
 +
 +
'''The IPv6 header contains these fields:'''
 +
 +
*'''Version:''' 4-bit field, the same as in IPv4. It contains the number 6 instead of the number 4 for IPv4.
 +
*'''Traffic Class:''' 8-bit field similar to the type of service (ToS) field in IPv4. It tags the packet with a traffic class that it uses in Differentiated Services (DiffServ). These functionalities are the same for IPv6 and IPv4.
 +
*'''Flow Label:''' 20-bit field that allows a particular flow of traffic to be labeled. It can be used for multilayer switching techniques and faster packet-switching performance.
 +
*'''Payload Length:''' Similar to the Total Length field in IPv4. It specifies the length of the payload, in bytes, that the packet is encapsulating.
 +
*'''Next Header:''' Specifies which header follows the IPv6 packet header. It can be a transport-layer packet, such as TCP or UDP, or it can be an extension header. This field is similar to the Protocol field in IPv4.
 +
*'''Hop Limit:''' Specifies the maximum number of hops that an IP packet can traverse. Each hop or router decreases this field by one (similar to the Time to Live [TTL] field in IPv4). Because there is no checksum in the IPv6 header, the router can decrease the field without recomputing the checksum. Recomputation costs valuable processing time on IPv4 routers.
 +
*'''Source Address:''' This field has 16 octets or 128 bits. It identifies the source of the packet.
 +
*'''Destination Address:''' This field has 16 octets or 128 bits. It identifies the destination of the packet.
 +
*'''Extension Headers:''' Follows the previous eight fields. The number of extension headers is not fixed, so the total length of the extension header chain is variable.
 +
 +
== Teori ==
 +
 +
=== 8.1.2  IPv6 Features ===
 +
 +
[[Image:CCNP-105.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  8.1.3  Large Address Space  ===
 +
 +
[[Image:CCNP-106.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 8.2.1  IPv6 Addressing Architecture  ===
 +
 +
[[Image:CCNP-107.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 8.2.2  Comparing IPv4 and IPv6 Headers  ===
 +
 +
[[Image:CCNP-108.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  8.2.3  IPv6 Extension Headers  ===
 +
 +
[[Image:CCNP-109.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 8.2.4  Defining Address Representation  ===
 +
 +
[[Image:CCNP-110.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  8.2.5  IPv6 Address Types  ===
 +
 +
[[Image:CCNP-111.png]]
 +
 +
<br><br>
 +
 +
[[Image:CCNP-112.png]]
 +
 +
<br><br>
 +
 +
[[Image:CCNP-113.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 8.2.6  IPv6 Global Unicast and Anycast Addresses  ===
 +
 +
[[Image:CCNP-114.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 8.3.1  Defining Host Interface Addresses  ===
 +
 +
[[Image:CCNP-115.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 8.3.2  Link Local Address ===
 +
 +
[[Image:CCNP-116.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== 8.3.3  Stateless Autoconfiguration 8.3.4  ===
 +
 +
[[Image:CCNP-117.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
=== EUI-64 to IPv6 Identifier ===
 +
 +
[[Image:CCNP-118.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-119.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-120.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-121.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-122.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-123.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-124.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-125.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-126.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-127.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-128.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-129.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-130.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-131.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-132.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-133.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-134.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-135.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-136.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-137.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-138.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-139.png]]
 +
 +
<br><br>
 +
<br><br>
 +
 +
===  ===
 +
 +
[[Image:CCNP-140.png]]
 +
 +
<br><br>

Latest revision as of 17:29, 26 March 2009

Contents

Module 1: Scalable Network Design

Forkortelser:

ECNM = Enterprise Composite Network Model


NAC = Network Access Control (NAC) and


IBNS = Identity Based Network Services (IBNS)


Module 2: EIGRP

Forkortelser:

AD = advertised distance (AD)

FD = feasible distance (FD)

AD og FD forklaring: The lowest cost route is calculated by adding the cost between the next-hop router and the destination—referred to as the advertised distance (AD)—to the cost between the local router and the next-hop router. The sum of these costs is called the feasible distance (FD).


DUAL = Diffusing Update Algorithm (DUAL)


PDM = Protocol-dependent modules (PDMs) are responsible for network layer protocol-specific requirements. EIGRP supports IP,AppleTalk, and Novell NetWare. Each protocol has its own EIGRP module and operates independently from any of the others that may be running.


RTP = RTP is responsible for guaranteed ordered delivery and reception of EIGRP packets to all neighbors. RTP supports intermixed transmission of multicast and unicast packets. For efficiency, only certain EIGRP packets are transmitted reliably.


SRTT = (smoothed round-trip time): Average number of milliseconds it takes for an EIGRP packet to be sent to this neighbor and for the local router to receive an acknowledgment of that packet. This timer determines the retransmit interval, also known as the retransmission timeout (RTO).


RTO = (retransmission timeout): Amount of time, in milliseconds, that the router waits for an acknowledgment before retransmitting a reliable packet from the retransmission queue to a neighbor. If an EIGRP update, query, or reply is sent, a copy of the packet is queued. If the RTO expires before an acknowledgment is received, another copy of the queued packet is sent.


SIA = stuck in active (SIA)


LSDB = link-state database (LSDB)


SPF = Shortest Path First (SPF)


Teori

Although the metric can be based on five criteria, EIGRP uses only two of these criteria by default:

  • Bandwidth: Smallest bandwidth between source and destination.
  • Delay: Cumulative interface delay along the path.

Three other criteria can be used, but are not recommended, because they typically result in frequent recalculation of the topology table:

  • Reliability: Worst reliability between source and destination, based on keepalives.
  • Loading: Worst load on a link between source and destination, based on the packet rate and the configured bandwidth of the interface.
  • MTU: Smallest MTU in the path. MTU is included in the EIGRP routing update, but is not actually used in the metric calculation.

Module 3: OSPF

Forkortelser:

Teori

3.1.1 Link State Routing Protocols

CCNP-2.png



3.1.3 Link State Data Structures

CCNP-3.png



3.1.6 Types of OSPF Routers

The four different types of OSPF routers are:

  • Internal routers: Routers that have all their interfaces in the same area and have identical LSDBs.
  • Backbone routers: Routers that sit on the perimeter of the backbone area and have at least one interface connected to area 0. Backbone routers maintain OSPF routing information using the same procedures and algorithms as internal routers.
  • Area border routers: Routers that have interfaces attached to multiple areas, maintain separate LSDBs for each area to which they connect, and route traffic destined to or arriving from other areas. Area border routers (ABRs) are exit points for the area, which means that routing information destined for another area can get there only via the ABR of the local area. ABRs can be configured to summarize the routing information from the LSDBs of their attached areas. ABRs distribute the routing information into the backbone. The backbone routers then forward the information to the other ABRs. In a multiarea network, an area can have one or more ABRs.
  • Autonomous System Boundary Routers: Routers that have at least one interface attached to an external internetwork (another autonomous system), such as a non-OSPF network. Autonomous system boundary routers (ASBRs) can import non-OSPF network information to the OSPF network and vice versa; this process is called route redistribution.

CCNP-4.png



3.1.9 Link-State Data Structures

When each router receives the LSU, it does the following:

  • If the LSA does not already exist, the router adds the entry to its LSDB, sends a link-state acknowledgment (LSAck) back, floods the information to other routers, runs SPF, and updates its routing table.
  • If the entry already exists and the received LSA has the same sequence number, the router ignores the LSA entry.
  • If the entry already exists but the LSA includes newer information (it has a higher sequence number), the router adds the entry to its LSDB, sends an LSAck back, floods the information to other routers, runs SPF, and updates its routing table.
  • If the entry already exists but the LSA includes older information, it sends an LSU to the sender with its newer information

CCNP-8.png



3.2.1 OSPF Packet Types

The OSPF protocol exchanges five packet types:

  • Hello
  • Database description (DBD)
  • Link-state request (LSR)
  • Link-state update (LSU)
  • Link-state acknowledgement (LSAck)


CCNP-5.png



3.2.2 OSPF Packet Header Format

All five OSPF packets are encapsulated directly into an IP payload, as shown in Figure . The OSPF packet does not use TCP or User Datagram Protocol (UDP). OSPF requires a reliable packet transport scheme. Since TCP is not used, it has defined its own acknowledgment routine that uses an acknowledgment packet (OSPF packet type 5).

In the IP header, a protocol identifier of 89 defines all OSPF packets. Each of the OSPF packets begins with the same header format. This header has the following fields:

  • Version number: For OSPF version 2 or 3
  • Type: Differentiates the five OSPF packet types
  • Packet length: Length of packet in bytes
  • Router ID: Defines which router is the source of the packet
  • Area ID: Defines the area where the packet originated
  • Checksum: Used for packet-header error detection to ensure that the OSPF packet was not corrupted during transmission
  • Authentication type: An option that specifies either no authentication, clear-text passwords, or encrypted Message Digest 5 (MD5) formats for router authentication
  • Authentication: Used in the authentication scheme
  • Data (for hello packet): Includes a list of known neighborsData (for DBD packet): Contains a summary of LSDB, which includes all known router *IDs and their last sequence number, among a number of other fields
  • Data (for LSR packet): Contains the type of LSU needed and the router ID that has the needed LSU
  • Data (for LSU packet): Contains the full LSA entries; multiple LSA entries can fit in one OSPF update packet
  • Data (for LSAck packet): Is empty

CCNP-9.png



3.3.4 Configuring a Router ID

CCNP-6.png



Verifying the OSPF Operation

CCNP-7.png



3.6.3 OSPF LSA Types (cont.)

Type 1 Every router generates router link advertisements for each area to which it belongs. A type 1 LSA describes the collective states of the directly connected links (interfaces) of the router. These LSAs are flooded only within the area in which they are originated.

Type 2 A type 2 LSA is generated for every transit broadcast and NBMA network within an area. A transit network has at least two directly attached OSPF routers. Ethernet is an example of a transit network.

The DR of the network is responsible for advertising the network LSA. A type 2 network LSA lists each of the attached routers that make up the transit network, including the DR itself, as well as the subnet mask used on the link. The type 2 LSA then floods to all routers within the transit network area. Type 2 LSAs never cross an area boundary. The link-state ID for a network LSA is the IP interface address of the DR that advertises it.

Type 3 The ABR sends type 3 summary LSAs. Type 3 LSAs advertise any networks owned by an area to the rest of the areas in the OSPF autonomous system, as shown in Figure .

The link-state ID is set to the network number; the mask is also advertised.

By default, OSPF does not automatically summarize groups of contiguous subnets or summarize a network to its classful boundary. The network operator uses configuration commands to specify how the summarization occurs. By default, a type 3 LSA is advertised into the backbone area for every subnet defined in the originating area, which can cause significant flooding problems. Consequently, you should always consider using manual route summarization at the ABR.

Summary LSAs are flooded throughout a single area only, but are regenerated by ABRs to flood into other areas.

Note By default, summary LSAs do not contain summarized routes.


Type 4 A type 4 summary LSA is generated by an ABR only when an ASBR exists within an area. A type 4 LSA identifies the ASBR and provides a route to it. The link-state ID is set to the ASBR router ID. All traffic destined to an external autonomous system requires routing table knowledge of the ASBR that originated the external routes.

In Figure , the ASBR sends a type 1 router LSA with an external bit (e bit) that is set to identify itself as an ASBR. When the ABR, which is identified with a border bit (b bit) in the router LSA, receives the type 1 LSA, it builds a type 4 LSA and floods it to the backbone (area 0). Subsequent ABRs regenerate a type 4 LSA to flood into their areas.

Type 5 Type 5 external LSAs describe routes to networks outside the OSPF autonomous system. Type 5 LSAs are originated by the ASBR and are flooded to the entire autonomous system.

The link-state ID is the external network number. Because of the flooding scope, and depending on the number of external networks, the default lack of route summarization can be a major issue with external LSAs. Therefore, you should summarize blocks of external network numbers at the ASBR to reduce flooding problems.

Type 6 Type 6 LSAs are specialized LSAs that are used in multicast OSPF applications.

Type 7 Type 7 is an LSA type that is used in not-so-stubby areas (NSSAs). They are originated by ASBRs within NSSAs and are flooded only within the NSSA in which they originated.

Type 8 Type 8 is a specialized LSA that is used in internetworking OSPF and Border Gateway Protocol (BGP).

Types 9, 10, and 11 The opaque LSAs, types 9, 10, and 11, are designated for future upgrades to OSPF for application-specific purposes. For example, Cisco Systems uses opaque LSAs for Multiprotocol Label Switching (MPLS) with OSPF. Opaque LSAs are distributed using standard LSDB flooding mechanisms. Each type has a different flooding scope.





Standard area: Accepts link updates, route summaries, and external routes (the default).


Backbone area (transit area): The central entity to which all other areas connect to exchange and route information. The backbone area is labeled area 0. The OSPF backbone includes all the properties of a standard OSPF area.


Stub area: Does not accept information about routes external to the autonomous system, such as routes from non-OSPF sources. This means that no type 5 LSAs are known inside the area, and consequently type 4 LSAs are unnecessary. Type 4 and 5 LSAs are blocked. ABRs at the edge of the stub area use type 3 LSAs to advertise a single default route (0.0.0.0) into the area. If routers need to route to networks outside the autonomous area, they use the default route. Stub areas cannot contain ASBRs (except that the ABRs may also be ASBRs).


Totally stubby area: Does not accept external autonomous system routes or summary routes from other areas internal to the autonomous system. The ABR of the totally stubby area blocks type 4 and 5 LSAs as well as all summary LSAs (type 3), with an exception of a single type 3 LSA to advertise the default route. The default route advertised by the ABR is used to reach destinations external to the autonomous system and all destinations external to the area. Therefore, if the router needs to send a packet to a network external to the area, it sends the packet using a default route.

Totally stubby areas cannot contain ASBRs (except that the ABRs may also be ASBRs).


Not-so-stubby area: An NSSA is an addendum to the OSPF RFC. It offers benefits that are similar to those of a stub or totally stubby area, but also allows external routes to be advertised into the OSPF autonomous system. Therefore, NSSAs allow ASBRs, which is against the rule in a stub area. The ASBR originates type 7 LSAs to advertise the external destinations. The type 7 LSAs are flooded throughout the NSSA but are blocked by the ABR. The ABR converts the type 7 LSA into a type 5 LSA, which is then propagated through the remainder of the autonomous system.

Module 4: Integrated IS-IS

Forkortelser

MPLS/TE = Multiprotocol Label Switching Traffic Engineering (MPLS/TE).


IGP = interior gateway protocol (IGP)


CLNS = Connectionless Network Service (CLNS)


CLNP = Connectionless Network Protocol (CLNP)


LSP = link-state packet (LSP)


PDU = protocol data unit (PDU)


IS = Intermediate System


ES = end system (ES)


ES-IS = End System-to-Intermediate System (ES-IS)


ESH = End System Hello (ESH)


ISH = Intermediate System Hello (ISH)


IIH = IS-IS Hello (IIH)


DIS = designated IS router (DIS)


NSAP = network service access points (NSAP)


NSEL = NSAP selector (NSEL)


IDP = initial domain part (IDP)


AFI = authority and format identifier (AFI)


IDI = initial domain identifier (IDI)


DSP = domain specific part (DSP)


HO-DSP = high-order DSP (HO-DSP)


SNPA = subnetwork point of attachment (SNPA)


CLV = Code, Length, Value (CLV)


SNP = Sequence number PDU (SNP)


PRC = partial route calculation (PRC)


Example of a net address:


For example, you might assign 49.0001.0000.0c12.3456.00, which represents the following:


AFI of 49 Area ID of 0001 System ID of 0000.0c12.3456, the MAC address of a LAN interface NSEL of 0


Teori

4.1.2 IS-IS and OSPF

CCNP-14.png





4.1.4 IS-IS Features

CCNP-15.png





4.1.5 IS-IS Link-State Operation

CCNP-16.png





4.1.8 The ES-IS Protocol

CCNP-17.png





4.1.9 OSI Routing Levels

CCNP-18.png





4.1.10 IS-IS and OSPF Network Design

CCNP-19.png





4.1.11 Differences Between Integrated IS-IS and OSPF

CCNP-20.png





4.2.1 NSAP Addresses

CCNP-141.png





4.2.2 NSAP Address Structure

CCNP-21.png





4.2.3 NSAP Address Example

CCNP-22.png





Module 5: Route Optimization

Forkortelser

PBR = Policy-based routing (PBR)


Teori

5.1.4 Using Seed Metrics

CCNP-25.png





5.1.6 Defining Administrative Distance

CCNP-26.png





5.3.2 Passive Interfaces

CCNP-27.png





5.4.1 Defining Route Maps

CCNP-28.png





5.4.3 Route Map Operation

CCNP-29.png



CCNP-30.png





5.4.4 Using Route Map Commands

CCNP-31.png





5.5.3 Configuring DHCP

CCNP-32.png





Module 6: BGP

Forkortelser

Protocols that run inside an enterprise are called interior gateway protocols (IGPs). Examples of IGPs include RIP versions 1 and 2, EIGRP, and OSPF.


Protocols that run outside an enterprise, or between autonomous systems, are called exterior gateway protocols (EGPs). Typically, EGPs are used to exchange routing information between Internet Service Providers (ISPs).


IGP: Exchanges routing information within an autonomous system. RIP, IGRP, OSPF, IS-IS, and EIGRP are IGPs.


EGP: Exchanges routing information between different autonomous systems. BGP is an EGP.


IDRP = BGP is an interdomain routing protocol (IDRP), also known as an EGP.


EBGP = When BGP is running between routers in different autonomous systems, it is called External BGP (EBGP).


IBGP = When BGP is running between routers in the same autonomous system, it is called Internal BGP (IBGP).


RIR = Regional Internet Registry (RIR)


FSM = finite-state machine (FSM)


Teori

6.1.2 BGP Multihoming Options

CCNP-33.png





6.1.6 BGP Routing Between Autonomous Systems

CCNP-34.png





6.1.7 Path-Vector Functionality

CCNP-35.png





6.1.9 Features of BGP

CCNP-36.png





6.1.10 BGP Databases

CCNP-37.png





6.1.11 BGP Message Types

CCNP-38.png





6.2.2 Establishing a Connection Between External BGP Neighbors

CCNP-39.png





6.2.3 Establishing a Connection Between Internal BGP Neighbors

CCNP-40.png





6.2.5 IBGP in a Nontransit Autonomous System

CCNP-41.png





6.2.6 Routing Issues in a Transit Autonomous System

CCNP-42.png





6.3.1 Basic BGP Configuration

CCNP-43.png





6.3.2 Activate a BGP Session

CCNP-44.png





6.3.3 Shutting Down a BGP Neighbor

CCNP-45.png





6.3.4 BGP Configuration Considerations

CCNP-46.png





6.3.5 IBGP Peering Issue

CCNP-47.png





6.3.6 BGP neighbor update-source Command

CCNP-48.png



CCNP-49.png





6.3.7 EBGP Peering Issue (EBGP Multihop)

CCNP-50.png





6.3.8 Next Hop Behavior

CCNP-51.png



CCNP-52.png





6.3.9 BGP neighbor next-hop-self Command

CCNP-53.png





6.3.10 Injection Routing Information into BGP

CCNP-54.png





6.3.12 BGP Synchronization

CCNP-55.png





6.3.13 BGP Synchronization Example

CCNP-56.png



CCNP-57.png





6.4.1 BGP Neighbor States

CCNP-58.png





6.4.5 Configuring a Peer Group Example

CCNP-59.png





6.4.7 Configuring BGP Authentication

CCNP-60.png





6.4.11 Soft Reset of BGP Sessions

CCNP-61.png



CCNP-62.png



CCNP-63.png





6.5.3 AS Path Attribute

CCNP-64.png





6.5.4 Next-Hop Attribute

CCNP-65.png





6.5.5 Origin Attribute

CCNP-66.png





6.5.6 Local Preference Attribute

CCNP-67.png





6.5.7 MED Attribute

CCNP-68.png





6.5.8 Weight Attribute

CCNP-69.png





6.5.10 Selecting a BGP Path

CCNP-70.png





6.6.3 Changing the BGP Local Preference for All Routes

CCNP-71.png





6.6.7 Setting the MED with Route Maps

CCNP-73.png



Module 7: IP Multicasting

Forkortelser

VoD = video on demand [VoD]


UDP = User Datagram Protocol (UDP)


Locally scoped (reserved link local) addresses Reserved by the Internet Assigned Numbers Authority (IANA) for network protocol use. Address range is from 224.0.0.0 through 224.0.0.255. Multicasts in this range are never forwarded off the local network, regardless of Time to Live (TTL). Usually, the TTL is set to 1.

Globally scoped addresses Allocated dynamically throughout the Internet. Address range is from 224.0.1.0 through 238.255.255.255. The 224.2.X.X range is used in Multicast Backbone (Mbone) applications. Established by the Internet Engineering Task Force (IETF) to multicast audio and video meetings, Mbone is a collection of Internet routers that support IP multicasting on which various public and private audio and video programs are sent.

Limited (administratively) scoped addresses Reserved for use inside private domains. Similar to the private IP address space that is used within the boundaries of a single organization, limited or administratively scoped addresses are constrained to a local group or organization. Address range is from 239.0.0.0 through 239.255.255.255. Organizations can use limited scope addresses to have local multicast applications that will not be forwarded over the Internet.



SDP = Session Description Protocol (SDP)


SAP = Session Announcement Protocol (SAP)


SDR = Both the sd application and SDP are sometimes called SDR or sdr. In Cisco documentation, SDP/SAP is referred to as sdr.


SIP = Session Initiation Protocol (SIP)


RTSP = Real Time Streaming Protocol (RTSP)


IGMP = Internet Group Management Protocol (IGMP)


CGMP = Cisco Group Management Protocol (CGMP)


ASIC = application-specific integrated circuit (ASIC)


CAM = content-addressable memory (CAM)


SPT = shortest path tree (SPT)


RP = rendezvous point (RP)


PIM = Protocol-Independent Multicast (PIM)


RPF = Reverse Path Forwarding (RPF)


SSM = Source Specific Multicast (SSM)


MSDP = Multicast Source Discovery Protocol [MSDP]


OIL = outgoing interface list (OIL)


DVMRP = Distance Vector Multicast Routing Protocol (DVMRP)


Teori

7.1.3 Multicast Advantages and Disadvantages

CCNP-75.png





7.1.4 Multicast Applications

CCNP-76.png





7.1.5 IP Multicast Addresses

CCNP-77.png



CCNP-78.png



CCNP-79.png





7.1.6 Layer 2 Multicast Addressing

CCNP-80.png





7.2.2 IGMPv2 Join Group and Leave Group Messages

CCNP-81.png





7.2.3 Introducing IGMPv3

CCNP-82.png





7.2.5 Multicast in the Layer 2 Switching Environment

CCNP-83.png





7.2.6 Multicast in Layer 2 Solutions

CCNP-84.png





7.2.7 Cisco Group Management Protocol (CGMP)

CCNP-85.png





7.2.8 IGMP Snooping

CCNP-86.png





7.3.1 Protocols Used in Multicast

CCNP-87.png





7.3.2 Multicast Distribution Trees

CCNP-88.png



CCNP-89.png





7.3.3 Multicast Distribution Trees Identification

CCNP-90.png





7.3.4 IP Multicast Routing

CCNP-91.png





7.3.5 Protocol-Independent Multicast: Describing PIM-DM

CCNP-92.png



CCNP-93.png



CCNP-94.png





7.3.6 Protocol-Independent Multicast: Describing PIM-SM

CCNP-95.png



CCNP-96.png





7.4.1 Enabling PIM Sparse Mode and Sparse-Dense Mode

CCNP-99.png





7.4.2 Inspecting the Multicast Routing Table

CCNP-100.png





7.4.3 Finding PIM Neighbors

CCNP-101.png





7.4.4 Checking RP Information

CCNP-102.png





7.4.5 Checking the Group State

CCNP-103.png





7.4.6 Configuring a Router to Be a Member of a Group

CCNP-104.png



Module 8: IPv6

Forkortelser

RSVP = Reservation Protocol [RSVP]


MLDv1 = Multicast Listener Discovery version 1 [MLDv1]


DAD = duplicate address detection (DAD)


RIPng = Routing Information Protocol next generation


RIB = Routing Information Base (RIB).


ISATAP = Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)


NAT-PT = NAT-Protocol Translation (NAT-PT)



The IPv6 header contains these fields:

  • Version: 4-bit field, the same as in IPv4. It contains the number 6 instead of the number 4 for IPv4.
  • Traffic Class: 8-bit field similar to the type of service (ToS) field in IPv4. It tags the packet with a traffic class that it uses in Differentiated Services (DiffServ). These functionalities are the same for IPv6 and IPv4.
  • Flow Label: 20-bit field that allows a particular flow of traffic to be labeled. It can be used for multilayer switching techniques and faster packet-switching performance.
  • Payload Length: Similar to the Total Length field in IPv4. It specifies the length of the payload, in bytes, that the packet is encapsulating.
  • Next Header: Specifies which header follows the IPv6 packet header. It can be a transport-layer packet, such as TCP or UDP, or it can be an extension header. This field is similar to the Protocol field in IPv4.
  • Hop Limit: Specifies the maximum number of hops that an IP packet can traverse. Each hop or router decreases this field by one (similar to the Time to Live [TTL] field in IPv4). Because there is no checksum in the IPv6 header, the router can decrease the field without recomputing the checksum. Recomputation costs valuable processing time on IPv4 routers.
  • Source Address: This field has 16 octets or 128 bits. It identifies the source of the packet.
  • Destination Address: This field has 16 octets or 128 bits. It identifies the destination of the packet.
  • Extension Headers: Follows the previous eight fields. The number of extension headers is not fixed, so the total length of the extension header chain is variable.

Teori

8.1.2 IPv6 Features

CCNP-105.png





8.1.3 Large Address Space

CCNP-106.png





8.2.1 IPv6 Addressing Architecture

CCNP-107.png





8.2.2 Comparing IPv4 and IPv6 Headers

CCNP-108.png





8.2.3 IPv6 Extension Headers

CCNP-109.png





8.2.4 Defining Address Representation

CCNP-110.png





8.2.5 IPv6 Address Types

CCNP-111.png



CCNP-112.png



CCNP-113.png





8.2.6 IPv6 Global Unicast and Anycast Addresses

CCNP-114.png





8.3.1 Defining Host Interface Addresses

CCNP-115.png





8.3.2 Link Local Address

CCNP-116.png





8.3.3 Stateless Autoconfiguration 8.3.4

CCNP-117.png





EUI-64 to IPv6 Identifier

CCNP-118.png





CCNP-119.png





CCNP-120.png





CCNP-121.png





CCNP-122.png





CCNP-123.png





CCNP-124.png





CCNP-125.png





CCNP-126.png





CCNP-127.png





CCNP-128.png





CCNP-129.png





CCNP-130.png





CCNP-131.png





CCNP-132.png





CCNP-133.png





CCNP-134.png





CCNP-135.png





CCNP-136.png





CCNP-137.png





CCNP-138.png





CCNP-139.png





CCNP-140.png



Retrieved from "http://mars.merhot.dk/w/index.php?title=Pederrs_CCNP_1&oldid=2967"