Free 4A0-113 Practice Test Questions and Answers (2026)

For two OSPF routers to form an adjacency on a common network segment, several parameters within their exchanged Hello packets must match. These parameters ensure consistent configuration and protocol operation. The required matching fields include:
1. Area ID: Routers must belong to the same OSPF area on that specific interface.
2. Hello and Dead Intervals: The timers for sending Hello packets and for declaring a neighbor down must be identical.
3. Authentication: The authentication type and password (if used) must match.
4. Area Options: Flags indicating area capabilities, such as the Stub or NSSA (Not-So-Stubby Area) flag, must be consistent between the routers.

D. Checksum values: The checksum is calculated for each individual packet to verify its integrity upon receipt. It is unique to each packet and is not a parameter that needs to match between neighbors.
E. The list of neighbors: This field contains the Router IDs of neighbors from which a router has recently received a valid Hello packet. It is used to confirm bidirectional communication and does not need to match for an adjacency to form.

1. RFC 2328 - OSPF Version 2: Section 10.5, "Receiving Hello Packets," details the checks performed on an incoming Hello packet. It explicitly states that the Area ID, HelloInterval, RouterDeadInterval, and Options fields (which contain the stub flag) must match the receiving interface's configuration.

"The HelloInterval and RouterDeadInterval fields in the received Hello Packet must be the same as the values configured for the receiving interface." (Page 103)

"...the Area ID in the packet's OSPF header must be the same as the interface's Area ID." (Page 103)

"The E-bit in the Hello Packet's Options field must be the same as the E-bit for the receiving interface's area... The E-bit must be clear if the area is a stub area." (Page 103)

2. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide, Release 22.10.R1: In the "OSPF Configuration Overview" section, it describes the conditions for forming adjacencies. It states, "To become OSPF neighbors, the routers must have the same area ID, area type, and compatible authentication, hello-interval, and router-dead-interval parameters." This confirms that Area ID, Hello/Dead intervals, and area type (which includes the stub flag) must match. (Reference: Section "OSPF Areas").

Open Shortest Path First (OSPF) is a routing protocol that operates directly on top of the Internet Protocol (IP). It does not use a transport layer protocol like TCP or UDP for its primary communication. Instead, OSPF packets are encapsulated directly within IP datagrams. The IP header's "Protocol" field is used to identify the next-level protocol in the payload. The Internet Assigned Numbers Authority (IANA) has assigned protocol number 89 specifically for OSPF. This allows network devices to correctly identify and process incoming OSPF packets directly from the IP layer.

A. OSPF does not use TCP. OSPF implements its own reliability and acknowledgment mechanisms, making the overhead of a TCP connection unnecessary for its operation.
B. OSPF does not use UDP. While some routing protocols use UDP, OSPF requires a level of reliability for exchanging link-state information that UDP does not provide.
C. OSPF is an Interior Gateway Protocol (IGP) designed explicitly to route IP packets within an IP network; therefore, it fundamentally relies on IP for transport.

1. RFC 2328 - OSPF Version 2:

Section A.1, "OSPF packet format," states: "OSPF runs directly over the IP network layer. OSPF does not use a transport protocol, such as UDP or TCP. OSPF has its own error detection and correction functions. The OSPF protocol number is 89."

DOI: https://doi.org/10.17487/RFC2328

2. Nokia 7750 SR OS Router Configuration Guide, Release 22.10.R1:

Section: OSPF Overview: This section describes OSPF as a link-state interior gateway protocol (IGP) for the Internet Protocol (IP). It implicitly confirms that OSPF operates at the IP layer, consistent with having its own IP protocol number. The guide details OSPF's packet types (Hello, DD, LSR, LSU, LSAck) which are all encapsulated directly in IP.

3. IANA - Protocol Numbers Registry:

The official registry maintained by the Internet Assigned Numbers Authority (IANA) lists the decimal value 89 as assigned to "OSPF Open Shortest Path First." This is the definitive source for protocol number assignments.

Source: https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

The OSPF neighbor state transitions from Down to Two-Way through an intermediate state called Init. A router enters the Init state when it first receives a Hello packet from a neighbor. The state then transitions to Two-Way when the router receives a subsequent Hello packet from that same neighbor which contains its own Router ID in the "seen" or neighbor list. This confirms that bidirectional communication has been established, which is the definition of the Two-Way state. At this point, routers on broadcast or Non-Broadcast Multi-Access (NBMA) networks will elect a Designated Router (DR) and Backup Designated Router (BDR).

A. Receiving a Link State Update (LSU) in response to a Link State Request (LSR) occurs during the Loading state, which is much later in the adjacency formation process.
C. Receiving a Database Description (DBD) packet from a neighbor happens during the ExStart and Exchange states, which occur after the Two-Way state is reached.
D. Receiving a Link State Acknowledgment (LSAck) occurs during the Loading or Full states to confirm the receipt of LSUs, well after the Two-Way state.

1. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide, Release 22.10.R1: In the section "OSPF Neighbor States", the guide describes the transition: "2-Way — In this state, a two-way communication has been established between two routers. Bidirectional communication is indicated when the router sees its own router ID in the neighbor’s Hello packet’s neighbor field. This state is the highest state for a DROTHER." (Document ID: DCD000011-2210-R1, Section: OSPF > OSPF Areas > OSPF Neighbor States).

2. RFC 2328 - OSPF Version 2: This is the standard defining OSPFv2. Section 10.3, "The Neighbor State Machine," describes the events and state transitions. For a neighbor in the Init state, the event "HelloReceived" triggers the following action: "If the router's own Router ID is seen in the neighbor's Hello packet, the neighbor state transitions to 2-Way." (Page 97).

3. Doyle, J., & Carroll, J. (2005). Routing TCP/IP, Volume 1 (2nd ed.). Cisco Press. While a Cisco Press book, it is widely regarded as an authoritative and academic-level text on routing protocols. Chapter 8, "OSPF," details the neighbor states. It explains, "The Two-Way state means that the router has seen its own Router ID in the Neighbor field of the neighbor's Hello packet. Bidirectional communication has been established." (Section: Building the Adjacency).

An Area Border Router (ABR) is a router that connects OSPF areas to the backbone area (Area 0). By definition, an ABR has at least one interface in Area 0 and at least one interface in another, non-backbone area. Its primary function is to maintain separate link-state databases for each area it is connected to and to advertise routing information between these areas. It achieves this by originating Type 3 Summary Link-State Advertisements (LSAs) from the backbone into non-backbone areas, and vice-versa, effectively acting as the gateway for inter-area traffic.

A. A backbone router has at least one interface in Area 0, but an ABR must connect Area 0 to another area. A router entirely within Area 0 is a backbone router but not an ABR.
B. An OSPF network can operate perfectly within a single area (for example, only Area 0). In such a design, no ABRs are required.
D. Route summarization is a highly recommended but optional feature that can be configured on an ABR. An ABR can function without performing any summarization.

1. Nokia 7750 SR OS Router Configuration Guide, Release 21.10.R1: In the "OSPF Areas and Routers" section, an Area Border Router (ABR) is defined as "A router that is attached to more than one area... An ABR maintains a separate link-state database for each area it is connected to." This confirms its role in connecting multiple areas.

2. RFC 2328 - OSPF Version 2: The glossary in Appendix F defines an Area Border Router as "A router that attaches to more than one area." Section 3.5, "Inter-area routing," further explains that ABRs are responsible for summarizing information about their attached areas and distributing it to the backbone, which then disseminates it to other ABRs. This highlights their role in connecting areas via the backbone.

3. Doyle, J., & Carroll, J. (2006). Routing TCP/IP, Volume 1 (2nd ed.). Cisco Press. Chapter 8, "OSPF," page 386, states: "An Area Border Router (ABR) is a router with interfaces in more than one area. At least one of these interfaces must be in area 0." This university-level textbook clearly defines the ABR's structural requirement of connecting the backbone to another area.

Routing Information Protocol Version 2 (RIPv2) uses the Class D multicast address 224.0.0.9 to send routing update messages. This is a significant improvement over RIPv1, which used broadcast (255.255.255.255). Using a specific multicast address allows only RIPv2-enabled routers on the segment to process the updates, reducing the processing load on other non-routing hosts on the same network. This address is reserved by the Internet Assigned Numbers Authority (IANA) specifically for RIPv2.

A. 224.0.0.5 is the multicast address used by all OSPF routers to listen for Hello packets and routing updates.
B. 224.0.0.6 is the multicast address used by OSPF Designated Routers (DR) and Backup Designated Routers (BDR).
D. 224.0.0.10 is the multicast address reserved for the Enhanced Interior Gateway Routing Protocol (EIGRP).
E. This statement is incorrect. A key feature distinguishing RIPv2 from RIPv1 is its support for multicast addressing.

1. RFC 2453, "RIP Version 2":

Section 3.1, "Addressing Considerations": "To reduce unnecessary load on hosts which are not routers, RIPv2 messages should be sent to the multicast address 224.0.0.9. For backward compatibility, the use of broadcast is allowed. The IP destination address is the multicast address 224.0.0.9."

DOI: https://doi.org/10.17487/RFC2453

2. Nokia 7750 SR OS Routing Protocols Guide, Release 21.10.R1:

Section: RIP Overview: "RIPv1 messages are broadcast, and RIPv2 messages are sent to the multicast address 224.0.0.9." (This statement is a standard description found in the introductory sections of RIP in Nokia's routing protocol guides).

3. IANA, "IPv4 Multicast Address Space Registry":

The registry explicitly lists the assignment of multicast addresses.

224.0.0.5: OSPFIGP All OSPF Routers

224.0.0.6: OSPFIGP All OSPF DRouters

224.0.0.9: RIP2-ROUTERS Routing Information Protocol

224.0.0.10: IGRP-ROUTERS IGRP/EIGRP Routers

Reference: https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml

The router R1 is an ASBR in Area 1 and originates Type 5 (External) LSAs. For routers in other areas (Area 0 and Area 2) to calculate a path to the external networks, they must know how to reach the ASBR (R1). Router R3, as the ABR connecting Area 1 to the backbone (Area 0), detects the ASBR in Area 1. It then generates a Type 4 (ASBR Summary) LSA and floods it into Area 0. This LSA informs routers in the backbone how to reach R1. Router R6, the ABR for Area 2, receives this Type 4 LSA via the backbone. To inform routers within Area 2 about the ASBR's reachability, R6 generates its own new Type 4 LSA and floods it into Area 2.

A. ASBRs like R1 generate Type 5 LSAs. ABRs (Area Border Routers) like R3 and R6 are responsible for generating Type 4 LSAs.
B. R3 only floods the Type 4 LSA into Area 0. It does not flood it back into Area 1 (where the ASBR is) or into Area 2 (to which it is not connected).
C. R3 is not directly connected to Area 2 and therefore cannot flood any LSAs into it. LSA propagation to Area 2 is the responsibility of R6.

1. Nokia 7750 SR OS OSPF and IS-IS Configuration Guide, Release 21.10.R1, Page 60, "LSA Types": The documentation describes the Type 4 ASBR Summary LSA: "Type 4 summary LSAs are originated by ABRs. This LSA contains the router ID of the ASBR and the cost to reach the ASBR from the ABR. When an ABR receives a Type 5 LSA from an ASBR in a non-backbone area, it creates a Type 4 LSA and floods it to the backbone (Area 0). Other ABRs then flood the Type 4 LSA to their areas." This directly supports the process where R3 floods to Area 0 and R6 floods to Area 2.

2. RFC 2328 - OSPF Version 2, Section 12.4.3, "Summary-LSAs": This section details the origination of summary LSAs by ABRs. It states, "For every AS boundary router in the OSPF domain, a summary-LSA can be originated for the AS boundary router by the area border routers." This confirms that ABRs, not ASBRs, generate these LSAs.

3. Computer Networking: A Top-Down Approach, 8th Edition, J. Kurose, K. Ross, Section 5.3.2, "OSPF": University-level textbooks explain that in a multi-area OSPF network, ABRs are responsible for summarizing and propagating reachability information between areas. The Type 4 LSA is the specific mechanism used by an ABR to advertise the location of an ASBR to other areas, which is then re-advertised by subsequent ABRs into their attached areas.

The Nokia 7750 SR, running SR OS, supports standard OSPFv2 and OSPFv3 area types as defined by the IETF. This includes stub areas (RFC 2328) and not-so-stubby areas (NSSA) (RFC 3101). Stub areas block external Type 5 LSAs and rely on a default route from the ABR to reach external destinations, reducing the link-state database size. NSSAs are an extension of stub areas that allow the injection of external routes from an ASBR within the NSSA as Type 7 LSAs, which are then translated to Type 5 LSAs by the ABR.

B. Level1 area WC: "Level 1" is a term used to describe an area within the IS-IS routing protocol, not OSPF.
D. Partially stubby areas: This is a proprietary Cisco term and not a standard IETF-defined OSPF area type supported by the Nokia 7750 SR.
E. Level 2 areas: "Level 2" refers to the backbone in the IS-IS routing protocol, which is analogous to OSPF's Area 0, but the terminology is incorrect for OSPF.

1. Nokia 7750 SR OS Routing Protocols Guide, Release 22.10.R1. In the OSPF section, under "OSPF Areas", the guide details the configuration and characteristics of different area types. It explicitly describes support for "Stub Areas" and "Not-So-Stubby-Areas (NSSAs)". The configuration commands config>router>ospf>area>stub and config>router>ospf>area>nssa are documented. (Document ID: 3HE 18101 AAAC TQZZA, Section: OSPF Areas).

2. RFC 2328, OSPF Version 2. This foundational document defines the operation of OSPF, including the concept of stub areas. Section 3.6, "Stub Areas," specifies that these areas do not carry external LSAs (Type 5), which is a feature supported by the 7750 SR.

3. RFC 3101, The OSPF Not-So-Stubby Area (NSSA) Option. This RFC defines the NSSA area type, which is an extension to the stub area functionality. The Nokia 7750 SR fully implements this standard, allowing for the redistribution of external routes within a stub-like area.

A Type 3 LSA, also known as a Summary LSA, is generated by an Area Border Router (ABR). Its specific purpose is to advertise IP network prefixes learned from intra-area routing (via Type 1 and Type 2 LSAs) in one area to all other areas to which the ABR is connected. This process allows routers in one area to learn about and build routes to destinations in other areas within the same OSPF autonomous system. The ABR summarizes the topology of an area and floods this summary information via Type 3 LSAs.

A. Type 1: A Type 1 (Router) LSA is generated by every router and is flooded only within its own area to describe its directly connected links.
C. Type 4: A Type 4 (ASBR Summary) LSA is generated by an ABR to advertise the location of an Autonomous System Boundary Router (ASBR) to other areas.
D. Type 7: A Type 7 (NSSA External) LSA is used to carry external route information within a Not-So-Stubby Area (NSSA) and is translated to a Type 5 LSA by the ABR.

1. Nokia 7750 SR OS Router Configuration Guide, Release 22.10.R1: In the "OSPF Areas" section, it states, "An ABR sends summary LSAs (LSA Type 3) to describe routes to other areas." This document clarifies the role of ABRs in generating Type 3 LSAs for inter-area route advertisement. (Reference: Section: OSPF > OSPF Areas)

2. RFC 2328 - OSPF Version 2: This is the primary standard for OSPFv2. Section 12.4.3, "The summary-LSA," defines Type 3 LSAs. It specifies, "Summary-LSAs are the Type 3 LSAs. Each summary-LSA describes a route to a single destination... These destinations are advertised by an area border router into the backbone, for distribution to all other areas."

3. Computer Networking: A Top-Down Approach (8th Edition) by J. Kurose and K. Ross: Chapter 5, "The Network Layer: Control Plane," discusses OSPF in detail. It explains that an ABR summarizes the distances to all networks in its attached area and advertises these summaries to all other areas it is connected to using Type 3 LSAs. (Reference: Chapter 5.3.2, "The OSPF Protocol")

The OSPF neighbor state transitions from "Init" to "2-Way" when bidirectional communication is confirmed. A router enters the "Init" state after receiving a Hello packet from a neighbor. However, this only confirms one-way communication. To advance to the "2-Way" state, the router must then receive a subsequent Hello packet from that same neighbor which includes its own Router ID in the neighbor list. This confirms that the neighbor has also received the router's Hellos, establishing bidirectional communication and satisfying the condition for the state change.

A. This exchange occurs during the "Loading" state, which happens much later in the adjacency process after the "2-Way" and "Exchange" states.
C. The exchange of Database Descriptor (DBD) packets begins in the "ExStart" state, which occurs only after the "2-Way" state has been successfully established.
D. Link State Acknowledgements are used to ensure the reliable flooding of LSUs and are primarily associated with the "Loading" and "Full" states.

1. Nokia 7750 SR OS Router Configuration Guide, Release 21.10.R1: In the "OSPF" chapter, section "OSPF Neighbor States", the guide defines the states:

Init: "The Init state indicates that a router has received a hello packet from a neighbor but the router ID of the receiving router was not in the hello packet."

Two-way: "The Two-way state indicates that the router has seen its own router ID in the neighbor’s hello packet." This confirms the transition is based on seeing its own ID in the neighbor's Hello.

2. RFC 2328 - OSPF Version 2: This is the foundational standard for OSPF.

Section 10.3, The Neighbor State Machine: It describes the event 2-WayReceived as the trigger to move from the Init state. This event is generated when "the router has seen its own Router ID in the neighbor's Hello packet." This directly supports the answer.

3. Nokia Data Center Fabric with SR Linux Cookbook:

Chapter 5, Unicast Routing, Section: OSPF Adjacency States: The text explains, "The 2-Way state is achieved when router R1 receives a Hello packet from R2 that contains R1's own router ID in the list of seen neighbors. This confirms that communication is bidirectional." This explicitly details the mechanism described in the correct answer.

The Open Shortest Path First (OSPF) protocol, as defined in RFC 2328, utilizes five distinct packet types to establish and maintain neighbor adjacencies, synchronize link-state databases (LSDBs), and propagate routing information. These five types are:
1. Hello: Discovers and maintains neighbor relationships.
2. Database Description (DBD or DD): Summarizes the LSDB contents during the initial database exchange between neighbors.
3. Link State Request (LSR): Requests specific Link State Advertisements (LSAs) from a neighbor after comparing DBD packets.
4. Link State Update (LSU): Transmits the requested LSAs and floods new or updated LSAs throughout the OSPF area.
5. Link State Acknowledgment (LSAck): Confirms the receipt of an LSU packet.

A. "Link state packet" is not a standard OSPF packet type. LSAs are carried within Link State Update (LSU) packets.
B. "Link state refresh" is a mechanism, not a packet type. "Notification" is not an OSPF packet type; it is associated with protocols like BGP.
C. "Link state refresh" and "link state authentication" are not OSPF packet types. Authentication is a feature handled within the OSPF packet header.

1. Official Vendor Documentation (Nokia): Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Unicast Routing Protocols Guide, Release 19.10.R1, Section: OSPF Packets. This section explicitly lists the five OSPF packet types as "Hello," "Database Description (DD)," "Link State Request (LSR)," "Link State Update (LSU)," and "Link State Acknowledgment (LSAck)."

2. Peer-reviewed Academic Publications (IETF RFC): Moy, J. (1998). RFC 2328: OSPF Version 2. Internet Engineering Task Force (IETF). Section A.3.1, "The OSPF packet header," defines the five packet types and their corresponding numerical codes: 1 (Hello), 2 (Database Description), 3 (Link State Request), 4 (Link State Update), and 5 (Link State Acknowledgment). (DOI: https://doi.org/10.17487/RFC2328)

3. University Courseware: Stanford University, CS 144: Introduction to Computer Networking, Fall 2013, Lecture 13: "Routing (Intra-AS)". The lecture slides on OSPF detail the protocol's operation, including the five fundamental packet types: Hello, Database Description, Link State Request, Link State Update, and Link State Acknowledgment.

The question specifies that a classful routing protocol (e.g., RIPv1) is in use. A defining characteristic of classful protocols is that they do not send subnet mask information in their routing updates. When a router advertises routes that belong to a different major network than the interface over which they are being sent, it automatically summarizes these routes to their classful boundary. The networks on R1, 10.1.1.0/24 and 10.1.2.0/24, are subnets of the Class A major network 10.0.0.0/8. When R2 advertises these routes to R3, it will send a single, summarized advertisement for the entire classful network, 10.0.0.0/8. Consequently, R3 will install one entry for 10.0.0.0/8 in its routing table.

A: Auto-summarization creates a single, stable, summarized route in R3's table, which prevents route flapping between more specific subnets. B: This behavior is characteristic of classless routing protocols (e.g., OSPF, RIPv2), which carry subnet mask information and would advertise the individual /24 prefixes. D: The summarization occurs at the classful boundary. For a Class A network like 10.0.0.0, the correct classful mask is /8, not /24.

1. Nokia 7750 SR OS Router Configuration Guide, Release 21.10.R1, "RIP Overview": This guide explains the behavior of RIPv1, stating, "RIPv1 is a classful routing protocol. RIPv1 does not include subnet masks in its routing updates. Summarization is automatic at network boundaries." This directly confirms that subnets are summarized to their classful address.

2. Hedrick, C., RFC 1058, "Routing Information Protocol", June 1988, Section 3.1, "Message Format": The official specification for RIPv1 shows the packet format. The route entry format includes an IP address and a metric, but critically lacks a field for a subnet mask. This technical limitation is the reason for classful summarization behavior.

3. Postel, J., RFC 791, "INTERNET PROTOCOL", September 1981, Section 3.2, "Addressing": This foundational RFC defines the original IP address classes. It specifies that any address beginning with a '0' bit (0-127 in the first octet), such as the 10.0.0.0 network, is a Class A network with an 8-bit network prefix.

For router R2 to learn the interface routes from the non-OSPF area, the Autonomous System Boundary Router (ASBR), R1, must first learn these routes and then redistribute them into OSPF. The observed symptom is that only R5's system address is being learned by R2, while its other interface prefixes are not. This indicates that R1 is likely not learning these interface prefixes from R5. The most probable cause is that R5 is not advertising them. This is typically controlled by an export policy on R5 that may be configured to advertise only its system (loopback) address for reachability, while filtering its local interface subnets.

A. 'asbr' is missing from router R1's configuration. This is incorrect. R1 is successfully redistributing R5's system address, which confirms it is already configured and functioning as an ASBR.
B. Router R1 needs to have an export policy added to it. This is unlikely. The fact that one route is being redistributed implies an export policy or redistribution mechanism is already active on R1; it is just not matching the missing prefixes.
D. Router R1 needs to have an import policy added to it. An import policy on R1 filters routes received from R5. While a restrictive import policy could cause this, the root of the problem is more fundamentally that R5 is not sending the routes.

1. Nokia 7750 SR OS Router Configuration Guide, Release 21.10.R1, Part: Unicast Routing Protocols, Section: Route Policies. This guide explains that for a router (like R1) to redistribute routes into a protocol (like OSPF), those routes must first exist in its Route Table Manager (RTM). The routes get into the RTM by being learned from a neighboring router (like R5). The advertisement of routes from R5 is controlled by an export policy on R5. If R5's export policy filters certain prefixes, R1 will never learn them and thus cannot redistribute them.

2. Nokia Data Center Fabric with SR Linux, Section 3.3.2 Route Redistribution. This document, while for SR Linux, describes the same fundamental Nokia routing principles. It states: "The ASBR imports routes from an external routing protocol into OSPF... The ASBR can only redistribute routes that are in its own routing table." This confirms that if the routes are not in R1's table because R5 never sent them, redistribution is impossible.

3. RFC 2328 - OSPF Version 2, Section 2.4 Autonomous System Boundary Routers. The RFC defines an ASBR as a router that exchanges routing information with routers belonging to other Autonomous Systems. This exchange is a prerequisite for redistribution. If R5 does not provide the routing information for its interfaces to R1, R1 cannot perform its ASBR function for those specific routes.

OSPF uses different Link State Advertisement (LSA) types to describe network topology. Type 1 (Router) LSAs are generated by each router to describe its own links and state within an area. Type 2 (Network) LSAs are generated by the Designated Router (DR) on multi-access segments to describe all routers attached to that segment. Both Type 1 and Type 2 LSAs have an area-local flooding scope. They are propagated throughout their originating area but are not flooded by Area Border Routers (ABRs) into other areas. This mechanism is fundamental to OSPF's hierarchical design, which contains detailed topology information within an area.

C. Summary network LSA (Type 3) are generated by ABRs to advertise routes from one area to the rest of the OSPF domain.
D. Summary router LSA (Type 4) are generated by ABRs to advertise the location of an ASBR to other areas.
E. Type 5 (AS external) LSAs are generated by ASBRs to advertise external routes and are flooded throughout the entire OSPF autonomous system.

1. Nokia 7750 SR OS Router Configuration Guide, Release 22.10.R1, Chapter: OSPF, Section: "OSPF Areas". The documentation states, "An ABR is a router that is connected to more than one area and is responsible for flooding summary LSAs between areas. An ABR does not flood Type 1 or Type 2 LSAs outside of the LSA's area of origin." This confirms that Router (Type 1) and Network (Type 2) LSAs stay within an area.

2. RFC 2328 - OSPF Version 2, Section 12.4, "Link State Advertisements".

Section 12.4.1 (Router LSAs): "Router LSAs are flooded throughout a single area only."

Section 12.4.2 (Network LSAs): "Network LSAs are flooded throughout a single area only."

Section 12.4.3 (Summary LSAs): Describes how these LSAs (Type 3 and 4) are flooded across area boundaries.

Section 12.4.5 (AS external LSAs): "AS external LSAs are flooded throughout the entire Autonomous System, with the exception of stub areas."

3. Kurose, J. F., & Ross, K. W. (2021). Computer Networking: A Top-Down Approach (8th ed.). In Chapter 5, "The Network Layer: Control Plane," the section on OSPF explains that intra-area routing information (corresponding to Type 1 and 2 LSAs) is confined to the area, while ABRs propagate summarized information to other areas.

An OSPF Autonomous System Boundary Router (ASBR) is not required to have an interface in the backbone area (Area 0). An ASBR's function is to inject external routes into the OSPF domain. It can be located in any type of OSPF area (backbone, standard, stub, or NSSA). When an ASBR resides within a non-backbone area, the Area Border Router (ABR) for that area is responsible for advertising reachability to the ASBR. The ABR does this by originating a Type 4 Summary-ASBR Link State Advertisement (LSA) and flooding it into the backbone area. This Type 4 LSA allows routers in other areas to learn the path to the ASBR and subsequently use the external routes (advertised in Type 5 LSAs) that the ASBR provides. The requirement to connect to Area 0 applies to ABRs, not necessarily to ASBRs.

The statement "True" is incorrect because it conflates the architectural requirements of an Area Border Router (ABR) with those of an ASBR. While an ABR must, by definition, have an interface in Area 0 to connect other areas to the backbone, an ASBR has no such constraint. The OSPF protocol design explicitly includes the Type 4 LSA mechanism to support ASBRs located in non-backbone areas.

1. RFC 2328, OSPF Version 2: Section 3.5, "AS boundary routers", states: "An AS boundary router is a router that exchanges routing information with routers belonging to other Autonomous Systems... AS boundary routers can be located in any of the areas in the OSPF Autonomous System." This is the definitive protocol specification.

2. Nokia 7750 SR OS OSPF and IS-IS Guide, Release 21.x: In the section "OSPF LSA Types", the description of "ASBR-Summary-LSAs (Type 4)" explains their purpose: "ASBR-summary-LSAs are originated by ABRs and describe a route to an ASBR. An ASBR-summary-LSA is flooded into the backbone... This LSA type is required when an ASBR is located in a non-backbone area." This official vendor documentation confirms the mechanism that allows an ASBR to exist outside of Area 0.

3. Doyle, J., & Carroll, J. (2006). Routing TCP/IP, Volume 1 (2nd ed.). Cisco Press. Chapter 8, "OSPF," in the section "OSPF LSA Types," explains that a Type 4 LSA is generated by an ABR to advertise an ASBR in one of its attached areas to the rest of the OSPF domain. This is a standard, academically-recognized text used in university-level networking courses.

Routing protocols are categorized by their underlying algorithm. Distance Vector protocols, such as RIPv1 and RIPv2, operate on the Bellman-Ford algorithm. In this model, each router maintains a routing table with the "distance" (metric, like hop count) to known destinations. Routers periodically exchange these tables only with their immediate neighbors. They do not have a complete map of the network topology, a concept often described as "routing by rumor." Each router learns about the network from the perspective of its neighbors.

A. OSPF: This is a Link-State protocol. It builds a complete topological database of the network and uses Dijkstra's algorithm to calculate the shortest path.
D. IS-IS: This is also a Link-State protocol. Like OSPF, it maintains a full map of the network topology and uses Dijkstra's algorithm for path computation.

1. Nokia Official Documentation: Nokia 7750 SR OS R19.10.R1 Router Configuration Guide, Part: Unicast Routing Protocols, Chapter: Routing Protocols Overview. The guide classifies routing protocols, stating, "The 7750 SR supports the following distance-vector protocols: Routing Information Protocol (RIP)..." and "The 7750 SR supports the following link-state protocols: Intermediate System-to-Intermediate System (IS-IS), Open Shortest Path First (OSPF)..." This explicitly categorizes RIP (v1/v2) as Distance Vector and OSPF/IS-IS as Link-State.

2. Academic Courseware: Kurose, J. F., & Ross, K. W. (2017). Computer Networking: A Top-Down Approach (7th ed.). Pearson. In Chapter 5.2, "The Link-State (LS) Routing Algorithm," OSPF and IS-IS are presented as implementations of link-state algorithms. In Chapter 5.3, "The Distance-Vector (DV) Routing Algorithm," RIP is used as the classic example of a distance-vector protocol. This textbook is standard curriculum in numerous university networking courses.

3. Internet Engineering Task Force (IETF) RFC:

Malkin, G. (1998). RFC 2453: RIP Version 2. IETF. Section 1, Introduction, states, "The Routing Information Protocol (RIP) is a distance-vector protocol..."

Hedrick, C. (1988). RFC 1058: Routing Information Protocol. IETF. The abstract explicitly describes RIP as a distance-vector protocol based on the Bellman-Ford algorithm.

The traceroute command is a diagnostic tool used to discover the path packets take to a specific destination IP address. To test the static route 10.2.3.0/24 next-hop 10.1.2.1, one must initiate a trace to a destination address that falls within the 10.2.3.0/24 prefix, such as 10.2.3.1. When the Nokia 7750 SR router receives this command, it performs a route lookup for 10.2.3.1, finds the configured static route, and forwards the traceroute packets to the specified next-hop, 10.1.2.1. The output of the traceroute will then display 10.1.2.1 as the first hop, confirming the static route is functioning correctly.

B. traceroute 10.2.3.1 next-hop 10.1.2.1: This command uses incorrect syntax. The standard traceroute command on SR OS does not accept a next-hop keyword in this format.
C. traceroute next-hop 10.1.2.1: This is syntactically invalid. The traceroute command requires a destination IP address as its primary argument, not the keyword next-hop.
D. traceroute does not work on the Nokia 7750 SR.: This statement is false. traceroute is a fundamental and fully supported OAM (Operations, Administration, and Maintenance) tool on the Nokia 7750 SR platform.
E. traceroute 10.1.2.1: This command would test the path to the next-hop router itself, not whether traffic for the 10.2.3.0/24 prefix is being correctly forwarded through it.

1. Nokia 7750 SR OS OAM and Diagnostics Guide, Release 22.10.R1: In the "Traceroute" chapter, the basic command syntax is detailed as traceroute ip-address [options]. This confirms that the primary argument is the destination IP address, validating the structure of answer A and invalidating the syntax of B and C.

2. Nokia 7750 SR OS Router Configuration Guide, Release 22.10.R1: The "Configuring Static Routes" section explains that a static route directs traffic for a specific destination prefix to a defined next hop. To verify this, a connectivity test (like ping or traceroute) must be aimed at an address within that destination prefix. This supports the logic that 10.2.3.1 is the correct target to test the route for 10.2.3.0/24.

To establish a path from router R1 to the remote network 139.120.121.0/24 located behind router R2, a static route is required. The configuration for a static route on a Nokia 7750 SR specifies the destination network prefix and the IP address of the next-hop router. Based on the exhibit, the destination network is 139.120.121.0/24. The next-hop router is R2, and its interface on the directly connected network (138.120.199.0/24) has the IP address 138.120.199.2. Therefore, the correct command on R1 points to the destination network via R2's directly reachable IP address.

B. The next-hop 138.120.199.1 is R1's own local interface address, which is an invalid next-hop for a remote network.
C. The destination 138.120.199.2/24 is an invalid network prefix; it is a host address on a directly connected network, which does not require a static route.
D. The next-hop 139.120.121.2 is on the remote network itself and is not directly reachable from R1, making it an invalid next-hop.

1. Nokia 7750 SR OS Router Configuration Guide, Release 21.10.R1, Chapter: IP Routing, Section: "Static Routes". The guide specifies the command syntax: config>router# static-route ip-prefix/prefix-length [next-hop ip-address]. It also clarifies that for the route to be active, the next-hop IP address must be associated with an outbound interface.

2. Nokia 7750 SR OS Unicast Routing Protocols Guide, Release 21.10.R1, Chapter: Routing Information and Policies, Section: "Static Routes". This document states, "Static routes are used when the 7750 SR does not have a routing protocol to determine the route to a destination... The next-hop for the static route must be on a directly connected network." This principle directly supports why option A is correct and option D is incorrect.

Link-state routing protocols operate by having each router learn the complete network topology within its area. This is achieved through three main steps. First, routers establish neighbor relationships (adjacencies) with directly connected routers, maintaining this information in an adjacency database. Second, each router advertises information about its own directly connected links and their status in a Link State Advertisement (LSA). These LSAs are flooded to all other routers within the area. Finally, each router uses the collected LSAs to build an identical topological database (Link-State Database), from which it independently calculates the shortest path to all destinations using the SPF algorithm.

A. Routers broadcast the entire route table to all neighbors. This describes the behavior of distance-vector protocols like RIP, not link-state protocols, which advertise the state of their own links.
D. The sequence number for an update is incremented as it is flooded from router to router. The sequence number is set by the originating router to identify the newest update; it is not modified by intermediate routers during the flooding process.

1. Nokia 7750 SR OS R21.10.R1 OSPF and IS-IS Guide

Reference for B & C: In the "OSPF Overview" chapter, section "Link-State Advertisements (LSAs)", it states, "An LSA contains information about neighbors and path costs." The section "Neighbors and Adjacencies" describes how routers use Hello packets to form adjacencies, which are then maintained.

Reference for E: In the "OSPF Overview" chapter, section "OSPF Areas and Virtual Links", it is stated, "Within an area, all routers have identical link-state databases which contain information about the area topology."

Reference for A (Incorrect): The guide consistently describes the flooding of LSAs, which contain link status, contrasting with the exchange of full routing tables characteristic of distance-vector protocols.

Reference for D (Incorrect): In the "OSPF Overview" chapter, section "Link-State Advertisements (LSAs)", the LSA header description includes the "sequence number" field, which is used by other routers to determine if the LSA is more recent than the one they have stored. This number is generated and incremented only by the originating router.

2. Kurose, J. F., & Ross, K. W. (2017). Computer Networking: A Top-Down Approach (7th ed.). Pearson.

Reference for B, C, E: In Chapter 5, Section 5.3, "The Link-State (LS) Routing Algorithm", the text explains that in a link-state protocol, "each node broadcasts link-state packets to all other nodes in the network... each link-state packet contains the identities and costs of its attached links." It further clarifies that this process results in all nodes having "an identical and complete view of the network." The establishment of neighbor relationships is the initial step.

Reference for A (Incorrect): The same section explicitly contrasts link-state with distance-vector algorithms, where nodes "send their routing tables to their neighbors."

Reference for D (Incorrect): The text explains that sequence numbers are used so that each node can "discard old or redundant link-state packets." The sequence number is incremented by the source node for each new packet it generates.

On the Nokia 7750 Service Router (SR), the default OSPF timers for broadcast and point-to-point network types are 10 seconds for the Hello interval and 40 seconds for the Dead interval. The Hello interval specifies the frequency at which a router sends OSPF Hello packets to discover and maintain neighbor adjacencies. The Dead interval is the time a router will wait without receiving a Hello packet from a neighbor before declaring that neighbor down. By default, the Dead interval is four times the Hello interval, a standard OSPF practice to ensure robustness against transient packet loss.

A. 5 and 15 seconds: These values are not the default OSPF timers on the Nokia 7750 SR, although they might be used in custom configurations for faster convergence.
B. 10 and 30 seconds: While the 10-second Hello interval is correct, the 30-second Dead interval is not the default. The default Dead interval is four times the Hello, not three.
C. 5 and 20 seconds: These values are not the default. A 5-second Hello interval is a non-default setting, often paired with a 20-second Dead interval (4x Hello).

1. Nokia 7750 SR OS Routing Protocols Guide, Release 22.10.R1: In the OSPF Command Reference section, the documentation for interface-level commands specifies the default values.

For the hello-interval command: "Default: 10" (seconds).

For the dead-interval command: "Default: 40" (seconds).

Reference Location: Chapter: OSPF Command Reference > OSPF Interface Commands.

2. Nokia Data Center, Cloud and IP Networks Documentation Center: The official public repository for Nokia technical documentation confirms these default values across multiple software releases for the 7750 SR platform. The configuration guides consistently list the default Hello interval as 10 seconds and the Dead interval as 40 seconds for standard OSPF interface types.

Reference Location: Search for "OSPF Interface Commands" within the relevant 7750 SR OS Routing Protocols Guide.

OSPF ensures the reliable dissemination of topology information using a mechanism called reliable flooding. When a router sends a Link State Update (LSU) packet, which contains one or more Link State Advertisements (LSAs), it expects an explicit acknowledgment from the receiving neighbor. This confirmation is sent in a Link State Acknowledgment (LSAck) packet. If the originating router does not receive an LSAck for a specific LSA within the retransmission interval, it will resend the LSU to that neighbor until an acknowledgment is received. This process guarantees that all routers within an OSPF area maintain a synchronized Link State Database (LSDB).

B. The router must receive a Hello: Hello packets are used for neighbor discovery and to maintain adjacency status, not to acknowledge the receipt of specific updates.
C. The router must receive a new sequence number: The sending router includes a new, higher sequence number in the LSA it sends; it does not receive one as a response.
D. The router must receive a Link State Packet: This is too general. While an LSAck is a type of Link State Packet, the specific packet required for confirmation is the Link State Acknowledgment.

1. Official Vendor Documentation: Nokia 7750 SR OS R21.10.R1 OSPF and IS-IS Configuration Guide, Chapter: OSPF, Section: "OSPF Packets". The guide states, "Link State Update (LSU) — A packet that contains a list of LSAs that a router wants to flood to its neighbors... LSUs are acknowledged by LSAcks."

2. Peer-reviewed Academic Publications (Protocol Standard): Moy, J. (1998). RFC 2328: OSPF Version 2. The Internet Society. Section 13, "The Flooding Procedure," states: "The flooding procedure is reliable, ensuring that the LSAs are delivered to all routers in the flooding scope. This is accomplished by requiring acknowledgments for the receipt of each LSA." (DOI: https://doi.org/10.17487/RFC2328)

3. University Courseware: Kurose, J. F., & Ross, K. W. (2017). Computer Networking: A Top-Down Approach (7th ed.). Pearson. In Chapter 5, "The Network Layer: Control Plane," the OSPF section describes that link-state updates are sent reliably, with each transmission being acknowledged. This textbook is standard curriculum in numerous university networking courses.