Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
42 Cards in this Set
- Front
- Back
|
Describe LSA Type 1
Describe the Letter portion of the Type Bits/Field Explain: NT W V E B |
LSA Type 1 - Router LSA
Describes the source router type NT Bit: When set, the router is an NSSA border router and will translate LSA Type -7 to LSA Type -5 W Bit: When set, the router is a wild-card multicast receiver. V Bit: When set, the router is an endpoint of one or more fully adjacent virtual links. E Bit: When set, the router is an AS boundary router B Bit: When set, the router is an area border router |
|
|
LSA Type 1 - Router LSA
Describe the Type field in the LSA Header, Explain: 1 2 3 4 |
The Type field is a brief description of the link
1: Point to point 2: Connection to transit network 3: Connection to a stub network 4: Virtual Link |
|
|
LSA Type 1 - Router LSA
Describe the Link ID field in LSA Header 1 2 3 4 |
Link ID identifies the object that this link connects to
1: Neighbors Router ID 2: IP address of the DR 3: IP Network/Subnetwork number 4: Neighbor Router ID |
|
|
LSA Type 1 - Router LSA
Describe the #TOS field in the LSA Header |
#TOS is the number of different Type of Service metrics given (other than the required link metric)
|
|
|
Describe LSA Type 2
|
LSA Type 2 - Network LSA
|
|
|
Describe LSA Type 3/4
Details and differences? |
LSA Type 3/4 - Summary LSA
Type 3 summary-LSAs are used when the destination is an IP network Type 4 summary-LSAs are used when the destination is an AS boundary router within another area |
|
|
Describe LSA Type 5
|
LSA Type 5 - AS External LSA
E bit: External type |
|
|
Describe LSA Type 7
|
LSA Type 7 - NSSA External
E bit: External type |
|
|
Describe LSA Type 9,10,11
Details |
LSA Type 9,10,11 - Opaque LSA
A value of 9 denotes a link-local scope. Opaque LSAs with a link-local scope MUST NOT be flooded beyond the local (sub)network. A value of 10 denotes an area-local scope. Opaque LSAs with an area-local scope MUST NOT be flooded beyond their area of origin. A value of 11 denotes that the LSA is flooded throughout the Autonomous System (e.g., has the same scope as type-5 LSAs). Opaque LSAs with AS-wide scope MUST NOT be flooded into stub areas or NSSAs Opaque Types: Registry Name: Opaque Link-State Advertisements (LSA) Option Types Reference: [RFC5250] Range Registration Procedures Notes ------ ---------------------------- 0-127 IETF Consensus 128-255 Private Use Registry: Value Opaque Type Reference --- ----------------------------------- ----------- 1 Traffic Engineering LSA [RFC3630] 2 Sycamore Optical Topology Descriptions [Moy] 3 grace-LSA [RFC3623] 4 Router Information (RI) [RFC4970 5-127 Unassigned 128-255 Private Use |
|
|
LSA Type 9,10,11
Describe Options Field in Headers DN O DC EA N/P MC E MT |
DN Bit: Used to prevent looping in BGP/MPLS IP VPNs
O Bit: willingness to receive and forward Opaque LSAs DC Bit: identifies support for demand circuits EA Bit: ability to support External Attribute LSA N/P Bit: support for LSA Type 7 (NSSA Externals) MC Bit: support for multicast packets (MOSPF) E Bit: identifies the support for LSA type 5 packets MT Bit: multi-topology link-excluding capability |
|
|
Describe Link State Acknowledgement
|
To make the flooding of LSAs reliable, flooded LSAs are explicitly acknowledged. This acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets.
|
|
|
Describe the two primary characteristics of OSPF
|
1. Protocol is open, OSPFv2 [RFC 2328] OSPFv3 [RFC 5340]
2. Based on SPF (Shortest Path First) algorithm. Sometimes referred to as the Dijkstra algorithm. |
|
|
Is OSPF a Distance Vector, Link State or hybrid IGBP?
|
Link State
|
|
|
List some features of OSPF
|
Equal-cost multipath routing
Routing based on upper-layer type-of-service (TOS) requests. OSPF supports one or more metrics. If only one metric is used, it is considered to be arbitrary, and TOS is not supported. If more than one metric is used, TOS is optionally supported through the use of a separate metric (and, therefor, a separate routing table) for each of the eight combinations created by the three IP TOS bits (delay, throughput, reliability bits) |
|
|
What are the three types of IP TOS bits
|
delay
throughput reliability |
|
|
Describe OSPF Packet Header Field of "Type"
Type 1 Type 2 Type 3 Type 4 Type 5 |
Type 1 Hello: OSPF Hello protocol to acquire neighbors, which are routers with interfaces to a common network. Hello packets also act as keepalives to let routers know that other routers are still functional
Type 2 Database Description: Describes current link-state of router Type 3 Link State Request: Request generated by a router after receiving a Type 2 Database Description and a portion of the local database is found to be out of date. Type 4 Link State Update: Reply to Type 3 Link State Request, with Link State Update. Type 5 Link State Acknowledgment: Acknowledgment sent by router when a Type 4, "Link State Update", has been received. Sent to Type 4 router usually from the sending router with original Link State Request, Type 3 Request |
|
|
Describe the Designated Router (DR) election process
|
On multiaccess networks (networks supporting more than two routers), The Hello protocol elects a designated router and backup designated router. The designated rotuer is responsible for generating LSAs for the entire multiaccess network.
Designated routers allow a reduction in network traffic and in the size of the topological database. |
|
|
How do routers discover each other in an OSPF?
What is it called when routers do? |
With Hello Packets that are either Multicast or Unicast.
Known as Neighbor discovery, with goal of full adjacency. |
|
|
What are the mandatory fields that must match in a hellow packet to form a full adjacency
|
Area Number
Authentication Type Authentication Key Hello Interval Dead Interval Subnet Mask or length Options field MTU* Primary Subnet** * The MTU can be disabled as a required match. On the master you can use the IP ospf mtu-ignore interface level command to disable that check ** for OSPFv2 |
|
|
What are the states that OSPF goes through to form an adjacency?
|
Down
Attempt Init 2-Way ExStart Exchange Loading Full |
|
|
Describe the OSPF State of "Down" in respect to forming adjacencies.
|
Down: This is the initial state of a neighbor conversation. It indicates that there has been no recent information received from the neighbor. On NBMA networks, Hello packets may still be sent to "Down" neighbors, although at a reduced frequency.
|
|
|
Describe the OSPF State of "Attempt" in respect to forming adjacencies.
|
Attempt: This state is only valid for neighbors attached to NBMA networks. It indicates that no recent information has been received from the neighbor, but that a more concerted effort should be made to contact the neighbor. This is done by sending the neighbor Hello packets at intervals of helloInterval
|
|
|
Describe the OSPF State of "Init" in respect to forming adjacencies.
|
Init: In this state, a Hello packets has recently been seen from the neighbor. however, bidirectional communication has not yet been established with the neighbor. (i.e., the router itself did not appear in the neighbor's Hello packet). All neighbors in this state (or higher) are listed in the Hellow packets sent from the associated interface.
|
|
|
Describe the OSPF State of "2-Way" in respect to forming adjacencies.
|
2-Way: In this state, communication between the two routers is bidirectional. This has been assured by the operation of the Hello Protocol. This is the most advanced state short of beginning adjacency establishment. The (Backup) Designated Router is selected from the set of neighbors in state 2-Way or greater.
|
|
|
Describe the OSPF State of "ExStart" in respect to forming adjacencies.
|
This is the first step in creating adjacency between the two neighboring routers. The goal of this step is to decide which router is the master, and to decide upon the initial DBD sequence number. The master will be the router with the highest router-ID. Neighbor conversations in this state or greater are called adjacencies.
|
|
|
Describe the OSPF State of "Exchange" in respect to forming adjacencies.
|
Exchange: In this state the router is describing its entire link state database by sending Database Descritpion packets to the neighbor. Each Database Description Packet has a DD sequence number, and is explicitly acknowledged. Only one Database Description Packet is allowed outstanding at any one time. In this state, Link State Request Packets may also be sent asking for the neighbor's more recent LSAs. All adjacencies in Exchange state or greater are used by the flodding procedure. In fact, these adjacencies are fully capable of transmitting and receiving all types of OSPF routing protocol packets.
|
|
|
Describe the OSPF State of "Loading" in respect to forming adjacencies.
|
Loading: In this state, Link State Request packets are sent to the neighbor asking for the more recent LSAs that have been discovered (but not yet received) in the Exchange state
|
|
|
Describe the OSPF State of "Full" in respect to forming adjacencies.
|
Full: In this state, the neighboring routers are fully adjacent. These adjacencies will now appear in router-LSAs and network-LSAs.
|
|
|
Describe "Router ID"
|
Routing protocols, other than RIP, require router identifiers (router ID). The router ID for OSPFv2 and OSPFv3 is a 32 bit value, in the format of dotted decimal...but is not an IPv4 address. Any value (except all zeros) is legal for a router ID, so from 0.0.0.1 to 255.255.255.255.
Note BGP router ID has to be in the format of a legal address, kind of...1.0.0.0 to 223.255.255.255 |
|
|
How is the Router ID selected.
|
The router ID is selected in the following order:
1) router-id command under routing process 2) If the router-id is not configured, then largest numeric value of IPv4 address on all Loopback interfaces a. 192.x.x.x is larger than 10.x.x.x 3) If there are no loopback interfaces with IPv4 addresses, then current up interface with largest numeric value of IPv4 addresses Note: If ther are no IPv4 addresses, then the router ID has to be configured under the routing process and the process will not start until a valid router ID is configured. |
|
|
Describe OSPF on a Brodcast Multi-Access Network (Ethernet)
|
Network supporting more than two attached routers, together with the capability to address a single pysical message to all of the attached routers (broadcast or multicast). Neighboring routers are discovered dynamically on these networks using OSPF's Hello Protocl. The Hello Protocol itself takes advantagbe of the multicast capability sending to all OSPF Routers with address 224.0.0.5 or FF02::5
OSPF elects a Designated Router(DR) and a Backup Designated Router(BDR), the other routers on the segment are referred to as DROther. All routers on a multi-access network will form full adjacencies with the DR and BDR, the DROthers will see each other and will be be in a 2-Way state. The default timers for network type Broadcast are 10 seconds for Hello interval and 40 seconds for Dead interval. |
|
|
Describe OSPF on a Point-to-point Network
|
Used for point to poitn circuits. Since there is only one other device, there is no need for a designated router. The neighbor is discovered via the all OSPF router multicast address, 224.0.0.5 or FF02::5.
You cannot use a neighbor statement with this network type. The default timers are 10 seconds for Hello and 40 seconds for the Dead Timers Point-to-point network type is default if the encapsulation for the serial interface is HDLC or PPP. It is also default for Frame-Relay point-to-point sub interfaces. Again, 10 seconds for hello and 40 seconds for the dead timer. |
|
|
Describe OSPF on a Non-Broadcast Multi-Access Network (Frame Relay)
|
Networks supporting many (more than two) routers, but having no broadcast capability are referred to non-broadcast multi-access.
|
|
|
Describe special concerns when using OSPF on a Non-Broadcast Multi-Access Network
|
Frame Relay Network is an example of non-broadcast network
Explicit neighbor statements under the routing process for OSPFv2 or interface for OSPFv3 are required due to the assumed lack of broadcast capability. Runs in one of two modes over non-broadcast networks. 1. Non-Broadcast multi-access or NBMA, simulates the operation of OSPF on a broadcast network with a need for a DR (and possibly a BDR). This is the default behavior for an interface configured for Frame Relay with the address applied to the physical interface or to a multipoint subinterface. 2. The second mode, called, Point-to-MultiPoint, treats the non-broadcast network as a collection of point-to-point links, even though they are all part of the same address space. With Point-to-MultiPoint, neighbor discovery is through multicast addresses (224.0.0.5 or FF02::5) and there is no election of DR. Due to the treatment of each PVC as a point to point connection, a host route is advertised for each router, not the prefix they belong to. Cisco has modification of point-to-multipoint for support of SVCs with non-broadcast option. Point-to-Multipoint non-broadcast will not form relationship automatically, neighbor statements need to be used to form adjacencies. Otherwise, the rest of the operation is the same as the RFC version of point-to-multipoint. |
|
|
Describe some information about OSPF on a Loopback interface
|
Loopback interfaces have their own network type, loopback.
This is not configurable, but can be changed. The loopback interfaces prefix are advertised as a host route, no matter how the interface addressing is configured. To get OSPF to advertise the configured length, change the network type to point-to-point. To get the interface back to the default network type of loopback, use the "no ospf network" interface command. |
|
|
For a point to point Network Type in regards to OSPF, describe
Hello Interval Dead Interval If DR is required If Neighbor statements are required Defaults for which interface type |
Hello Interval: 10
Dead Interval: 40 DR required: No Neighbor statement required(unicast): No Defaults for HDLC/PPP Circuits |
|
|
For a Point to Multipoint Network Type in regards to OSPF, describe
Hello Interval Dead Interval If DR is required If Neighbor statements are required Defaults for which interface type |
Hello Interval: 30
Dead Interval: 120 DR required: No Neighbor Statement Required(unicast): no |
|
|
For a Point to Multipoint Non-broadcast Network Type in regards to OSPF, describe
Hello Interval Dead Interval If DR is required If Neighbor statements are required Defaults for which interface type |
Hello Interval: 30
Dead Interval: 120 DR required: No Neighbors Statement Required(unicast): Yes |
|
|
For a Broadcast Network Type in regards to OSPF, describe
Hello Interval Dead Interval If DR is required If Neighbor statements are required Defaults for which interface type |
Hello Interval: 10
Dead Interval: 40 DR Required: Yes Defaults for LAN |
|
|
For a Non-Broadcast Network Type in regards to OSPF, describe
Hello Interval Dead Interval If DR is required If Neighbor statements are required Defaults for which interface type |
Hello Interval: 30
Dead Interval: 120 DR required: Yes Neighbor Statement Required(unicast): Yes Defaults for NBMA [Multipoint interface] Types |
|
|
Are Point to Point and Point to Multipoint compatible in regard to OSPF neighbor configuration?
|
Yes, if you change the timers to match.
Point to Point, Hello = 10, Dead = 40, no DR Required Point to Multipoint, Hello = 30, Dead = 120, no DR Required |
|
|
Are Broadcast and Non-Broadcast compatible in regards to OSPF neighbor configuration?
|
Yes, if you change the timers to match
Broadcast, Hello = 10, Dead = 40, DR Required Non-Broadcast, Hello = 30, Dead = 120, DR Required |
