Introduction to Networking: Understanding the OSI Model (Simple Explanation for CCNA & CCNP)

Understanding the OSI Model




What is Data Encapsulation?

Before you understand the OSI model, you must first understand data encapsulation.

Let’s use a simple example.

Imagine you want to send a wedding invitation letter to your friend in another city. If you just write the letter and drop it into the mailbox without an envelope, address, or stamp — will it reach your friend?

Of course not.

The postal service needs extra information:

  • Sender name

  • Sender address

  • Recipient name

  • Recipient address

  • Postcode

  • Stamp

Without this information, the letter cannot be delivered.

This process of putting a letter inside an envelope with proper details is similar to data encapsulation in networking.


What is Data Encapsulation in Networking?

In computer networks, we cannot send raw data directly.

For example, when you send a Facebook message:

  1. You type the message.

  2. The browser sends it to the Operating System.

  3. The OS sends it to the Network Interface Card (NIC).

  4. The NIC sends it to the network.

At each step, extra information is added to your data. This extra information is called a header.

These headers include:

  • Source address (where it came from)

  • Destination address (where it is going)

  • Protocol type

  • Port numbers

  • Error-checking information

This process of adding extra information to data is called:

Encapsulation = Adding headers to data so it can travel across the network properly.

At the receiving side, the process is reversed. Headers are removed one by one. This is called de-encapsulation.


Why Do We Need the OSI Model?

In the early days of networking, different companies created their own networking systems. These systems did not follow common rules.

As a result:

  • Devices from different vendors could not communicate.

  • Troubleshooting was difficult.

  • There was no standard structure.

To solve this problem, engineers created a standard framework called the OSI Model.


What is the OSI Model?

OSI stands for Open Systems Interconnection.

It is a 7-layer model that explains how data moves from one device to another.

Each layer has a specific job.

The OSI model helps:

  • Standardize networking

  • Ensure devices from different vendors work together

  • Make troubleshooting easier

  • Explain how data is encapsulated step by step


The 7 Layers of the OSI Model

  1. Layer 7 – Application
    Handles user applications like web browsers, email, etc.

  2. Layer 6 – Presentation
    Handles data formatting, encryption, and compression.

  3. Layer 5 – Session
    Manages sessions between devices.

  4. Layer 4 – Transport
    Handles reliable communication (TCP/UDP).
    Data is called a segment here.

  5. Layer 3 – Network
    Handles IP addressing and routing.
    Data is called a packet here.

  6. Layer 2 – Data Link
    Handles MAC addresses and switching.
    Data is called a frame here.

  7. Layer 1 – Physical
    Sends bits over cables or wireless signals.

#OSIModel #CCNA #CCNP #NetworkingBasics #DataEncapsulation #TCPIP #NetworkEngineer #CiscoNetworking #Subnetting #ITStudents

How Encapsulation Works in the OSI Model

When data is sent:

Application Data
↓
Transport Layer adds TCP/UDP header → Segment
↓
Network Layer adds IP header → Packet
↓
Data Link Layer adds MAC header + trailer → Frame
↓
Physical Layer sends bits

At the destination, headers are removed in reverse order.


OSI Model vs TCP/IP Model

Even though we use the TCP/IP model in real networks, many engineers still refer to OSI layers.

For example:

  • “Is this a Layer 2 issue?”

  • “Do you need a Layer 3 port?”

  • “This is a Layer 7 protocol.”

The modern TCP/IP model has 5 layers, but it maps closely to the lower 4 layers of the OSI model.

For CCNA and CCNP students, understanding both models is very important.


Important Note for CCNA & CCNP Students

The CCNA exam does not deeply test the OSI model anymore. However, networking professionals still use OSI layer terminology daily.

If you want to:

  • Troubleshoot networks

  • Work as a network engineer

  • Pass CCNA or CCNP

  • Understand packet flow

You must clearly understand the OSI model.


#OSIModel
#CCNA
#CCNP
#NetworkingBasics
#DataEncapsulation
#TCPIP
#NetworkEngineer
#CiscoNetworking
#Subnetting
#ITStudents




Understanding the OSI model

 In this lesson, we explain what the OSI model is in an easy and understandable language. It is one of the most important concepts in networking, so we break it down into pieces to help you understand exactly what its purpose is.

What is data encapsulation?

To understand the OSI model, you must first understand what data encapsulation is. Let's explore the following example. Imagine you want to send a letter to a friend who lives in another city to invite him to your wedding. What if you send the letter without an envelope, with any information, such as the sender's and recipient's names, addresses, and postcodes? What if you simply write the letter and drop it in the mailbox at the post office? 





Most readers of this CCNA course are so young that they've never sent a physical letter in their lives. They live in the digital age and have grown up with emails and instant text messages. However, surprisingly, everyone understands the concept of the post service and sending mail.

Let's examine the following two examples: a letter without an envelope (on the left) and one placed inside an envelope with all required information written on top (on the right). If you put those two into your mailbox, which one will reach its intended recipient and which one won't?



#cisco #networking #OSI #model

It is pretty obvious, right? If you send a letter with no envelope and no additional information, such as sender and recipient details, the postal service won't know where to deliver it. The letter won't reach anyone. Your friend won't show up at your wedding.

To ensure that the information (the letter) is delivered to the correct recipient, we must include additional information alongside the letter, so that the postal service knows how to handle it (we encapsulate the data).



The envelope that encapsulates the letter contains the following information, which helps the postal service deliver the letter correctly:

  • Stamp and postcard
  • Sender's name
  • Sender's address
  • Sender's postcode
  • Recipient's name
  • Recipient's address
  • Recipient's postcode

Optionally, the envelope may include:

  • Return address (if different from the sender’s address)
  • Date and time stamp
  • Subject or reference line inside the letter (in formal letters)

The main idea is that sending letters equals sending information by utilizing the postal service as the medium. Sending emails is the same—it’s still a process of sending information, but through a computer network. The key point is that in both cases, you can’t send just the information alone; you need to include extra details that tell the transporting medium how to deliver the information.



Data Encapsulation in Networking

Computer networks function similarly to the postal service. The difference is that they move digital information instead of paper letters. However, you can’t just send raw data onto the network and expect it to reach the destination, just like you can’t drop a plain letter into a mailbox and expect it to be delivered. The data must be encapsulated with additional information first, as shown in the diagram below.







Imagine a device (like your laptop) wants to send data onto the network. Let's say you're sending a Facebook message to a friend. As you type the message and hit enter, the data goes from the web browser (where you have Facebook opened), to the Operating System (OS), to the NIC, and out to the network. Many processes add their own additional information called headers. These headers contain important details, like:

  • Who the data is for.
  • Where did it come from?
  • How it should be delivered.
  • What type of data is it?

In the end, the simple Facebook message "Hey! What's up?" looks like a network packet encapsulated with multiple headers, as shown in the diagram below.



At the destination, the data undergoes the reverse process of removing headers before the it is presented to the correct application.

Why do we need the OSI model?

The process of data encapsulation is not simple. It involves many different protocols, headers, and steps. Each part of a network—like applications, network devices, and physical mediums—needs to know what to do with the data and how to handle it correctly.

In the early days of networking, different companies built their own systems, using their own encapsulation methods. These systems often couldn’t work together because they didn’t follow the same rules. For example, one vendor might add certain headers in a unique order that another vendor's device couldn't understand. This made it hard to send data between different networks or even between devices from the same company.

Additionally, to achieve the ultra-high speeds of today's networks, network devices must precisely locate the information they need, without examining headers that are irrelevant, as shown in the diagram below.

.

To fix this, engineers realized that the industry needed a standard framework. They needed a common way to describe how data should be prepared, sent, and received. That’s where the OSI model comes in.

The OSI model gives a step-by-step structure for how data encapsulation should work:

  • Each layer has a specific job, like adding source and destination addresses or checking for errors.
  • Each layer uses specific protocols that follow agreed-upon rules.
  • Each layer adds its own header (and sometimes trailer) to the message, so the receiving system knows how to process it.

In short, the OSI model helps manage the complexity of data encapsulation by providing a clear, standard method that everyone in networking can use. This ensures interoperability, consistency, and easier troubleshooting.

The OSI model helps us understand and explain how data is wrapped up layer by layer (encapsulation), and how it's unwrapped at the other end (de-encapsulation).

What is the OSI model?

The OSI model, or Open Systems Interconnection model, is a framework that breaks down the encapsulation process into seven layers. Each layer has a specific role and handles a part of the encapsulation, such as data formatting, logical addressing, routing, physical addressing, or error checking.

The following example shows how data moves through the OSI layers and gets wrapped at each step before being sent over the network to the next device. Notice that each layer adds its own specific header with relevant information for the network function.




The primary goal of the OSI model is to establish a standard and vendor-agnostic data encapsulation framework. It helps different devices and systems work together by following the same set of rules and standards. 

The following diagram illustrates each layer, with a brief description and the protocols that operate at that layer. Notice that in general, different network devices operate at different layers of the OSI model. This means that a network device cares only for the headers up to a particular layer and doesn't care about the rest of the headers in the message. For example, a switch only cares about the data link (layer 2) header, which consists of the source and destination MAC addresses. A router cares only about the layer 2 and layer 3 headers, and so on.







Note also that we refer to the data at each layer of the OSI model with a different term. For example, at layer 4, we refer to a TCP message as a segment. At layer 3, we refer to it as a packet. At layer 2, we refer to it as a frame.

The OSI model vs. TCP/IP model

The OSI model, with its seven layers, is a well-structured and useful way to understand how data encapsulation works. However, network engineers quickly notice that layers 5, 6, and 7 are not directly related to most networking tasks. These layers focus more on how software applications handle data, which is usually outside the scope of networking.

As a result, network professionals, through practice and real-world experience, began using a simpler model that focuses on the aspects that matter most to networking—Layers 1 through 4. This led to the development of the TCP/IP model, which has fewer layers and is more aligned with how networks actually operate.

The following diagram shows a comparison of the OSI model (with 7 layers), the first version of TCP/IP (which had 4 layers), and the modern version of the TCP/IP model (with 5 layers).


The modern 5-layer TCP/IP model uses the same names as the OSI model for the lower layers, and their jobs are very similar. So, when reading about networks or talking to others in the field, you can think of the lower four layers as being the same in both models- OSI and TCP/IP.

For this course, make sure you understand how the 5-layer TCP/IP model maps to the 7-layer OSI model (as shown in both ends of the diagram above). Also, remember that when people refer to “Layer 7,” they typically mean the top layer in both models, which handles applications.

For example, you will often hear one of the following phrases that you must understand:

  •  "Do you need a layer 2 or a layer 3 port?"
  •  "Is this a layer 2 or layer 3 switch?"
  •  "The problem is at layer 2."

Although networks today use TCP/IP, many people still refer to OSI layer numbers. For example, people call an application protocol a “Layer 7 protocol,” even though TCP/IP combines some of those OSI layers (application, presentation, and session) into just one.



Key Takeaways on the OSI Model

  • The OSI model is a theoretical framework that breaks down the data encapsulation process into seven layers
  • Each layer describes the information included in the message as a header.
  • The OSI model remains widely used to teach networking and explain how protocols function. 
  • However, while Cisco includes the OSI model in the CCNA/CCNP exams, knowing more than the basics isn’t very useful in real-world networking today. 
  • It’s essential to know the first four layers as they are the ones that concern network engineers the most.

Understanding the OSI Reference Model: Protocols at Each Layer

protocols at each layer of OSI model



The OSI (Open Systems Interconnection) reference model is a conceptual framework used to understand network interactions in seven distinct layers. Each layer has specific protocols that facilitate communication and data exchange. Let’s dive into the OSI model and explore the protocols that operate at each layer.

Application layer

It’s responsible for providing an interface for the user to interact with application services or network services. Ex-Web browser (HTTP), Telne


Presentation layer

It’s responsible for defining a standard format to the data. The major functions described at this layer are: -

Encoding-Decoding
Ex- AVI-(video), WAV-(voice), JPEG (graphite), ASCII (text) Encryption-Decryption

Session layer

It’s responsible for establishing, maintaining, and terminating the sessions. Session ID is used to identify a session or interaction.

Ex-Remote procedural call, Apple talk session protocol.



Transport Layer

It provides data delivery mechanism between applications in the network. Transport layer is the major function layer In OSI layer

Identifying service

Multiplexing&De-multiplexing Segmentation, Error correction, flow control Transport layer protocols?

The protocols which takes care of data transport at transport layer are TCP/UDP



Difference between UDP & TCP.



Network Layer
It provides logical addressing path determination (routing)

The protocols that work in this layer are: -
Routed Protocol, Routing Protocol Routed Protocols→Used to carry user data between data.

Routing Protocols→used performs path determinisation routing.

Data link layer

It provides communication with network layer.

Mac (
media access control) it provides reliable transit of data across a physical link.

Physical layer

It defines the electrical, mechanical functional specification for communication between the network devices.


#OSI #layers #network #tcp #udp

What Is OSPF?

 

Overview of OSPF

Definition

The Open Shortest Path First (OSPF) protocol, developed by the Internet Engineering Task Force (IETF), is a link-state Interior Gateway Protocol (IGP).

At present, OSPF Version 2, defined in RFC 2328, is intended for IPv4, and OSPF Version 3, defined in RFC 2740, is intended for IPv6. Unless otherwise stated, OSPF stated in this document refers to OSPF Version 2.

The following describes OSPF fundamentals, and basic OSPF function configuration.

Understanding OSPF

OSPF Fundamentals

Router ID

A router requires a router ID if it is to run OSPF. A router ID is a 32-bit unsigned integer, uniquely identifying a router in an AS.

A router ID can be manually configured or automatically selected by a router:

  • It is recommended that you manually configure a router ID to ensure OSPF stability.
  • If no router ID is manually configured for a router, the router selects an interface IP address as its router ID. A router selects its router ID based on the following rules:
    1. The router preferentially selects the largest IP address among loopback interface addresses as its router ID.
    2. If no loopback interface is configured, the router selects the largest IP address among other interface addresses as its router ID.

After the router has been running OSPF and selected its router ID, it still uses this router ID if the interface whose IP address is used as the router ID is Down or disappears (for example, the undo interface loopback loopback-number command is run) or a larger interface IP address exists. The router can obtain a new router ID only after a router ID is reconfigured for the router or an OSPF router ID is reconfigured and the OSPF process restarts.

link State

OSPF is a link-state protocol. A link can be considered as a router interface. The link state is a description of that interface and of the relationship with its neighboring routers. For example, a description of the interface includes the IP address and mask of the interface, the type of the connected network, and the connected neighbors. The collection of all these link states forms a link-state database (LSDB).

COST

  • OSPF uses the cost as the route metric.
  • Each OSPF-enabled interface has a cost value. The formula used to calculate the cost is: Cost = 100M/Interface bandwidth. 100 Mbit/s is the OSPF reference bandwidth.
  • The cost of an OSPF route is the sum of the cost values of all incoming interfaces from the source router to the destination router.

    The default reference bandwidth is 100 Mbit/s. If the transmission medium has a bandwidth higher than 100 Mbit/s, a cost of less than 1 is calculated, which is not allowed in OSPF and will be rounded off to 1. Currently, many network devices use interfaces with more than 100 Mbit/s bandwidth. In this case, route cost calculation is inaccurate. To address this problem, run the bandwidth-reference command to change the reference bandwidth. If you need to configure this command, you are advised to configure it on all OSPF routers on the entire network.

  • OSPF uses the cost as the route metric.
  • Each OSPF-enabled interface has a cost value. The formula used to calculate the cost is: Cost = 100M/Interface bandwidth. 100 Mbit/s is the OSPF reference bandwidth.
  • The cost of an OSPF route is the sum of the cost values of all incoming interfaces from the source router to the destination router.

    The default reference bandwidth is 100 Mbit/s. If the transmission medium has a bandwidth higher than 100 Mbit/s, a cost of less than 1 is calculated, which is not allowed in OSPF and will be rounded off to 1. Currently, many network devices use interfaces with more than 100 Mbit/s bandwidth. In this case, route cost calculation is inaccurate. To address this problem, run the bandwidth-reference command to change the reference bandwidth. If you need to configure this command, you are advised to configure it on all OSPF routers on the entire network.

Packet Types

Table 1-1 Packet types

Packet Type

Function

Hello packet

Sent periodically to discover and maintain OSPF neighbor relationships.

Database Description (DD) packet

Contains brief information about the local link-state database (LSDB) and synchronizes the LSDBs on two devices.

Link State Request (LSR) packet

Requests the required LSAs from neighbors.

LSR packets are sent only after DD packets are exchanged successfully.

Link State Update (LSU) packet

Sends the required LSAs to neighbors.

Link State Acknowledgement (LSAck) packet

Acknowledges the receipt of an LSA.

LSA Types

Table 1-2 LSA types

LSA Type

Function

Router-LSA (Type 1)

Describes the link status and link cost of a router. It is generated by every router and advertised in the area to which the router belongs.

Network-LSA (Type 2)

Describes the link status of all routers on the local network segment. Network-LSAs are generated by a designated router (DR) and advertised in the area to which the DR belongs.

Network-summary-LSA (Type 3)

Describes routes to a specific network segment in an area. Network-summary-LSAs are generated by an Area Border Router (ABR) and advertised in all areas except totally stub areas and Not-So-Stubby Areas (NSSAs). For example, an ABR belongs to both area 0 and area 1. Area 0 has a network segment 10.1.1.0, and area 1 has a network segment 11.1.1.0. The Type 3 LSA of the network segment 11.1.1.0 generated by the ABR for area 0 and the Type 3 LSA of the network segment 10.1.1.0 generated by the ABR for area 1 are advertised within the non-totally stub area or NSSA.

ASBR-summary-LSA (Type 4)

Describes routes to an Autonomous System Boundary Router (ASBR). ASBR-summary-LSAs are generated by an ABR and advertised to all related areas except the area to which the ASBR belongs.

AS-external-LSA (Type 5)

Describes routes to a destination outside the AS. AS-external-LSAs are generated by an ASBR and advertised to all areas except stub areas and NSSAs.

NSSA-LSA (Type 7)

Describes routes to a destination outside the AS. Generated by an ASBR and advertised in NSSAs only.

Opaque-LSA (Type 9/Type 10/Type 11)

Provides a universal mechanism for OSPF extension.

  • Type 9 LSAs are advertised only on the network segment where the interface originating Type 9 LSAs resides. Grace LSAs used to support GR are a type of Type 9 LSAs.
  • Type 10 LSAs are advertised inside an OSPF area. LSAs used to support TE are a type of Type 10 LSAs.
  • Type 11 LSAs are advertised within an AS. At present, there are no applications of Type 11 LSAs.

Support status of LSAs in different types of areas

Table 1-3 Support status of LSAs in different types of areas

Area Type

Router-LSA (Type 1)

Network-LSA (Type 2)

Network-summary-LSA (Type 3)

ASBR-summary-LSA (Type 4)

AS-external-LSA (Type 5)

NSSA-LSA (Type 7)

Common area (including standard and backbone areas)

Supported

Supported

Supported

Supported

Supported

Not supported

Stub area

Supported

Supported

Supported

Not supported

Not supported

Not supported

Totally stub area

Supported

Supported

Not supported

Not supported

Not supported

Not supported

NSSA

Supported

Supported

Supported

Not supported

Not supported

Supported

Totally NSSA

Supported

Supported

Not supported

Not supported

Not supported

Supported

Router Types

Figure 1-1 lists common Router types used in OSPF.

Figure 1-1 Router types
Table 1-4 Router types

Router Type

Description

Internal router

All interfaces on an internal router belong to the same OSPF area.

Area Border Router (ABR)

An ABR belongs to two or more than two areas, one of which must be the backbone area.

An ABR is used to connect the backbone area and non-backbone areas. It can be physically or logically connected to the backbone area.

Backbone router

At least one interface on a backbone router belongs to the backbone area.

Internal routers in Area 0 and all ABRs are backbone routers.

AS Boundary Router (ASBR)

An ASBR exchanges routing information with another ASs.

An ASBR does not necessarily reside on the border of an AS. It can be an internal router or an ABR. An OSPF device that has imported external routing information will become an ASBR.

Route Types

Inter-area and intra-area routes in an AS describe the AS's network structure. AS external routes describe the routes to destinations outside an AS. OSPF classifies the imported AS external routes into Type 1 and Type 2 external routes.

Table 1-5 lists route types in descending priority order.

Table 1-5 Route types

Route Type

Description

Intra-area route

Indicates routes within an area.

Inter-area route

Indicates routes between areas.

Type 1 external route

Type 1 external routes have high reliability.

Cost of a Type 1 external route = Cost of the route from a local router to an ASBR + Cost of the route from the ASBR to the destination of the Type 1 external route

Type 2 external route

Type 2 external routes have low reliability, and therefore OSPF considers that the cost of the route from an ASBR to the destination of a Type 2 external route is much greater than the cost of any internal route to the ASBR.

Cost of a Type 2 external route = Cost of the route from the ASBR to the destination of the Type 2 external route

Area Types

Table 1-6 Area types

Area Type

Function

Common area

OSPF areas are common areas by default. Common areas include standard areas and backbone areas.

  • A standard area is the most common area and transmits intra-area routes, inter-area routes, and external routes.
  • A backbone area connects all the other OSPF areas. It is usually named Area 0.

Stub area

A stub area does not advertise AS external routes, but only intra-area and inter-area routes.

Compared with a non-stub area, the Router in a stub area maintains fewer routing entries and transmits less routing information.

To ensure the reachability of AS external routes, the ABR in a stub area advertises Type 3 default routes to the entire stub area. All AS external routes must be advertised by the ABR.

Totally stub area

A totally stub area does not advertise AS external routes or inter-area routes, but only intra-area routes.

Compared with a non-stub area, the Router in a totally stub area maintains fewer routing entries and transmits less routing information.

To ensure the reachability of AS external and inter-area routes, the ABR in a totally stub area advertises Type 3 default routes to the entire totally stub area. All AS external and inter-area routes must be advertised by the ABR.

NSSA

An NSSA can import AS external routes. An ASBR uses Type 7 LSAs to advertise the imported AS external routes to the entire NSSA. These Type 7 LSAs are translated into Type 5 LSAs on an ABR, and are then flooded in the entire OSPF AS.

An NSSA has the characteristics of the stub areas in an AS.

An ABR in an NSSA advertises Type 7 default routes to the entire NSSA. All inter-area routes must be advertised by the ABR.

Totally NSSA

A totally NSSA can import AS external routes. An ASBR uses Type 7 LSAs to advertise the imported AS external routes to the entire NSSA. These Type 7 LSAs are translated into Type 5 LSAs on an ABR, and are then flooded in the entire OSPF AS.

A totally NSSA has the characteristics of the totally stub areas in an AS.

An ABR in a totally NSSA advertises Type 3 and Type 7 default routes to the entire totally NSSA. All inter-area routes must be advertised by the ABR.

OSPF Network Types

Table 1-7 lists four OSPF network types that are classified based on link layer protocols.

Table 1-7 OSPF network types

Network Type

Description

Broadcast

A network with the link layer protocol of Ethernet or Fiber Distributed Data Interface (FDDI) is a broadcast network by default.

On a broadcast network:

  • Hello packets, LSU packets, and LSAck packets are usually transmitted in multicast mode. 224.0.0.5 is an IP multicast address reserved for an OSPF device. 224.0.0.6 is an IP multicast address reserved for an OSPF DR or backup designated router (BDR).
  • DD and LSR packets are transmitted in unicast mode.

Non-Broadcast Multi-Access (NBMA)

A network with the link layer protocol of frame relay (FR), X.25 is an NBMA network by default.

On an NBMA network, protocol packets such as Hello packets, DD packets, LSR packets, LSU packets, and LSAck packets are sent in unicast mode.

Point-to-Multipoint (P2MP)

No network is a P2MP network by default, no matter what type of link layer protocol is used on the network. A network can be changed to a P2MP network. The common practice is to change a non-fully meshed NBMA network to a P2MP network.

On a P2MP network:

  • Hello packets are transmitted in multicast mode using the multicast address 224.0.0.5.
  • Other types of protocol packets, such as DD packets, LSR packets, LSU packets, and LSAck packets are sent in unicast mode.

Point-to-point (P2P)

By default, a network where the link layer protocol is PPP, HDLC, or LAPB is a P2P network.

On a P2P network, protocol packets such as Hello packets, DD packets, LSR packets, LSU packets, and LSAck packets are sent in multicast mode using the multicast address 224.0.0.5.

DR and BDR

On broadcast or NBMA networks, any two routers need to exchange routing information. As shown in Figure 1-2, n routers are deployed on the network. n x (n - 1)/2 adjacencies must be established. Any route change on a router is transmitted to other routers, which wastes bandwidth resources. OSPF resolves this problem by defining a DR and a backup designated router (BDR). After a DR is elected, all routers send routing information only to the DR. Then the DR broadcasts LSAs. Routers other than the DR and BDR are called DR others. The DR others establish only adjacencies with the DR and BDR and not with each other. This process reduces the number of adjacencies established between routers on broadcast or NBMA networks.

Figure 1-2 Network topologies before and after a DR election

If the original DR fails, routers must reelect a DR and the routers except the new DR must synchronize routing information to the new DR. This process is lengthy, which may cause incorrect route calculations. A BDR is used to shorten the process. The BDR is a backup for a DR. A BDR is elected together with a DR. The BDR establishes adjacencies with all routers on the network segment and exchanges routing information with them. When the DR fails, the BDR immediately becomes a new DR. The routers need to reelect a new BDR, but this process does not affect route calculations.

The DR priority of a router interface determines its qualification for DR and BDR elections. The router interfaces with their DR priorities greater than 0 are eligible. Each router adds the elected DR to a Hello packet and sends it to other routers on the network segment. When both router interfaces on the same network segment declare that they are DRs, the router interface with a higher DR priority is elected as a DR. If the two router interfaces have the same DR priority, the router interface with a larger router ID is elected as a DR.

Stub Area

Stub areas are specific areas where ABRs do not flood the received AS external routes. In stub areas, Routers maintain fewer routing entries and less routing information.

Configuring a stub area is optional. Not every area can be configured as a stub area. A stub area is usually a non-backbone area with only one ABR and is located at the AS border.

To ensure the reachability of the routes to destinations outside an AS, the ABR in the stub area generates a default route and advertises the route to the non-ABRs in the same stub area.

Note the following points when configuring a stub area:

  • The backbone area cannot be configured as a stub area.
  • Before configuring an area as a stub area, you must configure stub area attributes on all Routers in the area.
  • There should be no ASBR in a stub area, meaning that AS external routes cannot be transmitted in the stub area.
  • Virtual connections cannot cross a stub area.

NSSA

NSSAs are a special type of OSPF areas. There are many similarities between an NSSA and a stub area. Both of them do not advertise the external routes received from the other OSPF areas. The difference is that a stub area cannot import AS external routes, whereas an NSSA can import AS external routes and advertise the imported routes to the entire AS.

After an area is configured as an NSSA, an ABR in the NSSA generates a default route and advertises the route to the other Routers in the NSSA. This is to ensure the reachability of the routes to the destinations outside an AS.

Note the following points when configuring an NSSA:

  • The backbone area cannot be configured as an NSSA.
  • Before configuring an area as an NSSA, you must configure NSSA attributes on all Routers in the area.
  • Virtual connections cannot cross an NSSA.

Neighbor State Machine

To exchange routing information on an OSPF network, neighbor routers must establish adjacencies. The differences between neighbor relationships and adjacencies are described as follows:

  • Neighbor relationship: After the local router starts, it uses an OSPF interface to send a Hello packet to the remote router. After the remote router receives the packet, it checks whether the parameters carried in the packet are consistent with its own parameters. If the parameters carried in the packet are consistent with its own parameters, the local and remote routers establish a neighbor relationship.
  • Adjacency: After the local and remote routers establish a neighbor relationship, they exchange DD packets and LSAs to establish an adjacency.

OSPF has eight state machines: Down, Attempt, Init, 2-way, Exstart, Exchange, Loading, and Full.

  • Down: It is in the initial stage of setting up sessions between neighbors. The state machine is Down when a router fails to receive Hello packets from its neighbor before the dead interval expires.
  • Attempt: It occurs only on an NBMA network. The state machine is Attempt when a neighbor does not reply with Hello packets before the dead interval has expired. The local router, however, keeps sending Hello packets to the neighbor at every poll interval.
  • Init: The state machine is Init after a router receives Hello packets.
  • 2-way: The state machine is 2-way when the Hello packets received by a router contain its own router ID. The state machine will remain in the 2-way state if no neighbor relationship is established, and will become Exstart if a neighbor relationship is established.
  • Exstart: The state machine is Exstart when the two neighbors start to negotiate the master/slave status and determine the sequence numbers of DD packets.
  • Exchange: The state machine is Exchange when a router starts to exchange DD packets with its neighbor after the master/slave status negotiation is completed.
  • Loading: The state machine is Loading after a router has finished exchanging DD packets with its neighbor.
  • Full: The state machine is Full when the LSA retransmission list is empty.

OSPF Packet Authentication

OSPF supports packet authentication. Only the OSPF packets that have been authenticated can be received. If OSPF packets are not authenticated, a neighbor relationship cannot be established.

The Router supports two authentication methods:

  • Area-based authentication
  • Interface-based authentication

When both area-based and interface-based authentication methods are configured, interface-based authentication takes effect.

OSPF Route Summarization

Route summarization means that an ABR in an area summarizes the routes with the same prefix into one route and advertises the summarized route to the other areas.

Route summarization between areas reduces the amount of routing information to be transmitted, reducing the size of routing tables and improving device performance.

Route summarization can be carried out by an ABR or an ASBR:

  • Route summarization on an ABR:

    When an ABR in an area advertises routing information to other areas, it generates Type 3 LSAs by network segment. If this area contains consecutive network segments, you can run a command to summarize these network segments into one network segment. The ABR only needs to send one summarized LSA, and will not send the LSAs that belong to the summarized network segment specified in the command.

  • Route summarization on an ASBR:

    If the local device is an ASBR and route summarization is configured, the ASBR will summarize the imported Type 5 LSAs within the aggregated address range. After an NSSA is configured, the ASBR needs to summarize the imported Type 7 LSAs within the aggregated address range.

    If the local device is an ASBR and ABR, the device will summarize the Type 5 LSAs that are translated from Type 7 LSAs.

OSPF Default Route

A default route is a route of which the destination address and mask are all 0s. If a router cannot find a route in its routing table for forwarding packets, it can forward packets using a default route. Due to hierarchical management of OSPF routes, the priority of default Type 3 routes is higher than the priority of default Type 5 or Type 7 routes.

OSPF default routes are usually used in the following cases:

  • An ABR advertises default Type 3 Summary LSAs to instruct routers within an area to forward packets between areas.
  • An ASBR advertises default Type 5 ASE LSAs or default Type 7 NSSA LSAs to instruct routers in an AS to forward packets to other ASs.

Principles for advertising OSPF default routes are described below:

  • An OSPF router advertises an LSA that describes a default route only when an interface on the OSPF router is connected to a network outside an area.
  • If an OSPF router has advertised an LSA carrying information about a type of default route, the OSPF router does not learn this type of default routes advertised by other routers. This means that the OSPF router no longer calculates routes based on the LSAs carrying information about the same type of the default routes advertised by other routers, but stores these LSAs in its LSDB.
  • The route on which default external route advertisement depends cannot be a route in the local OSPF AS. This means that the route cannot be the one learned by the local OSPF process. This is because default external routes are used to guide packet forwarding outside an AS, whereas the routes within an AS have the next hop pointing to the devices within the AS.

Table 1-8 lists principles for advertising default routes in different areas.

Table 1-8 Principles for advertising OSPF default routes

Area Type

Function

Common area

By default, devices in a common OSPF area do not automatically generate default routes, even if the common OSPF area has default routes.

When a default route on the network is generated by another routing process (not OSPF process), the device that generates the default route must advertise the default route in the entire OSPF AS. (Run a command on an ASBR to configure the ASBR to generate a default route. After the configuration, the ASBR generates a default Type 5 ASE LSA and advertises the LSA to the entire OSPF AS.)

Stub area

A stub area does not allow AS external routes (Type 5 LSAs) to be transmitted within the area.

All routers within the stub area must learn AS external routes from the ABR. The ABR automatically generates a default Summary LSA (Type 3 LSA) and advertises it to the entire stub area. Then all routes to destinations outside an AS can be learned from the ABR.

Totally stub area

A totally stub area does not allow AS external routes (Type 5 LSAs) or inter-area routes (Type 3 LSAs) to be transmitted within the area.

All routers within the totally stub area must learn AS external routes and other areas' routes from the ABR. The ABR automatically generates a default Summary LSA (Type 3 LSA) and advertises it to the entire totally stub area. Then, all routes to destinations outside an AS and to destinations in other areas can be learned from the ABR.

NSSA

An NSSA allows its ASBRs to import a small number of AS external routes, but does not advertise ASE LSAs (Type 5 LSAs) received from other areas within the NSSA. This means that AS external routes can be learned only from ASBRs in the NSSA.

Devices in an NSSA do not automatically generate default routes.

Use either of the following methods as required:

  • To advertise some external routes using the ASBR in the NSSA and advertise other external routes through other areas, configure a default Type 7 LSA on the ABR and advertise this LSA in the entire NSSA.
  • To advertise all the external routes using the ASBR in the NSSA, configure a default Type 7 LSA on the ASBR and advertise this LSA in the entire NSSA.

The difference between these two configurations is described below:

  • An ABR will generate a default Type 7 LSA regardless of whether the routing table contains the default route 0.0.0.0.
  • An ASBR will generate a default Type 7 LSA only when the routing table contains the default route 0.0.0.0.

A default route is flooded only in the local NSSA and is not flooded in the entire OSPF AS. If Routers in the local NSSA cannot find routes to the outside of the AS, the Routers can forward packets to the outside of the AS through an ASBR. Packets of other OSPF areas, however, cannot be sent to the outside of the AS through this ASBR. Default Type 7 LSAs will not be translated into default Type 5 LSAs and flooded in the entire OSPF AS.

Totally NSSA

A totally NSSA does not allow AS external routes (Type 5 LSAs) or inter-area routes (Type 3 LSAs) to be transmitted within the area.

All Routers within the totally NSSA must learn AS external routes from the ABR. The ABR automatically generates a default Summary LSA and advertises it to the entire totally NSSA. Then all external routes received from other areas and inter-area routes can be advertised within the totally NSSA.

OSPF Route Filtering

OSPF supports route filtering using routing policies. By default, OSPF does not filter routes.

Routing policies used by OSPF include the route-policy, access-list, and prefix-list.

OSPF route filtering can be used for:

  • Importing routes

    OSPF can import routes learned by other routing protocols. You can configure routing policies to filter the imported routes to allow OSPF to import only the routes that match specific conditions.

  • Advertising imported routes

    OSPF advertises the imported routes to its neighbors.

    You can configure filtering rules to filter the routes to be advertised. The filtering rules can be configured only on ASBRs.

  • Learning routes

    Filtering rules can be configured to allow OSPF to filter the received intra-area, inter-area, and AS external routes.

    After receiving routes, an OSPF device adds only the routes that match the filtering rules to the local routing table, but can still advertise all routes from the OSPF routing table.

  • Learning inter-area LSAs

    You can run a command to configure an ABR to filter the incoming Summary LSAs. This configuration takes effect only on ABRs because only ABRs can advertise Summary LSAs.

Table 1-9 Differences between inter-area LSA learning and route learning

Inter-area LSA Learning

Route Learning

Directly filters the incoming LSAs.

Filters the routes that are calculated based on LSAs, but does not filter LSAs. This means that all incoming LSAs are learned.

  • Advertising inter-area LSAs

    You can run a command to configure an ABR to filter the outgoing Summary LSAs. This configuration takes effect only on ABRs.

OSPF Multi-Process

OSPF supports multi-process. Multiple OSPF processes can run on the same Router, and they are independent of each other. Route exchanges between different OSPF processes are similar to route exchanges between different routing protocols.

Each interface on the Router belongs to only one OSPF process.

A typical application of OSPF multi-process is that OSPF runs between PEs and CEs in a VPN, whereas OSPF is used as an IGP on the backbone of the VPN. Two OSPF processes on the same PE are independent of each other.

OSPF RFC 1583 Compatibility

RFC 1583 is an earlier version of OSPFv2.

When OSPF calculates external routes, routing loops may occur because RFC 2328 and RFC 1583 define different route selection rules. To prevent routing loops, both communication ends must use the same route selection rules.

  • After RFC 1583 compatibility is enabled, OSPF uses the route selection rules defined in RFC 1583.
  • When RFC 1583 compatibility is disabled, OSPF uses the route selection rules defined in RFC 2328.

OSPF calculates external routes based on Type 5 LSAs. If the router enabled with RFC 1583 compatibility receives a Type 5 LSA:

  • The Router selects a route to the ASBR that originates the LSA, or to the forwarding address (FA) described in the LSA.
  • The Router selects external routes to the same destination.

By default, OSPF uses the route selection rules defined in RFC 1583.

OSPF Basics

OSPF route calculation involves the following processes:

  1. Adjacency Establishment

    The adjacency establishment process is as follows:

    1. The local and remote routers use OSPF interfaces to exchange Hello packets to establish a Neighbor relationship.
    2. The local and remote routers negotiate a master/slave relationship and exchange Database Description (DD) packets.
    3. The local and remote routers exchange link state advertisements (LSAs) to synchronize their link state databases (LSDBs).
  2. Route Calculation

    OSPF uses the shortest path first (SPF) algorithm to calculate routes, resulting in fast route convergence.

Adjacency Establishment

Adjacencies can be established in either of the following situations:

  • Two routers have established a neighbor relationship and communicate for the first time.
  • The designated router (DR) or backup designated router (BDR) on a network segment changes.

The adjacency establishment process is different on different networks.

Adjacency establishment on a broadcast network

On a broadcast network, the DR and BDR establish adjacencies with each router on the same network segment, but DR others establish only neighbor relationships.

Figure 1-3 shows the adjacency establishment process on a broadcast network.

Figure 1-3 Adjacency establishment process on a broadcast network

The adjacency establishment process on a broadcast network is as follows:

  1. Neighbor relationship establishment
    1. Router A uses the multicast address 224.0.0.5 to send a Hello packet to Router B through the OSPF interface connected to a broadcast network. The packet carries the DR field of 1.1.1.1 (ID of Router A) and the Neighbors Seen field of 0. A neighbor router has not been discovered, and Router A regards itself as a DR.
    2. After Router B receives the packet, it returns a Hello packet to Router A. The returned packet carries the DR field of 2.2.2.2 (ID of Router B) and the Neighbors Seen field of 1.1.1.1 (Router A's router ID). Router A has been discovered but its router ID is less than that of Router B, and therefore Router B regards itself as a DR. Then Router B's status changes to Init.
    3. After Router A receives the packet, Router A's status changes to 2-way.

    The following procedures are not performed for DR others on a broadcast network.

  2. Master/Slave negotiation and DD packet exchange
    1. Router A sends a DD packet to Router B. The packet carries the following fields:
      • Seq field: The value x indicates the sequence number is x.
      • I field: The value 1 indicates that the packet is the first DD packet, which is used to negotiate a master/slave relationship and does not carry LSA summaries.
      • M field: The value 1 indicates that the packet is not the last DD packet.
      • MS field: The value 1 indicates that Router A declares itself a master.

        To improve transmission efficiency, Router A and Router B determine which LSAs in each other's LSDB need to be updated. If one party determines that an LSA of the other party is already in its own LSDB, it does not send an LSR packet for updating the LSA to the other party. To achieve the preceding purpose, Router A and Router B first send DD packets, which carry summaries of LSAs in their own LSDBs. Each summary identifies an LSA. To ensure packet transmission reliability, a master/slave relationship must be determined during DD packet exchange. One party serving as a master uses the Seq field to define a sequence number. The master increases the sequence number by one each time it sends a DD packet. When the other party serving as a slave sends a DD packet, it adds the sequence number carried in the last DD packet received from the master to the Seq field of the packet.

    2. After Router B receives the DD packet, Router B's status changes to Exstart and Router B returns a DD packet to Router A. The returned packet does not carry LSA summaries. Because Router B's router ID is greater than Router A's router ID, Router B declares itself a master and sets the Seq field to y.
    3. After Router A receives the DD packet, it agrees that Router B is a master and Router A's status changes to Exchange. Then Router A sends a DD packet to Router B to transmit LSA summaries. The packet carries the Seq field of y and the MS field of 0. The value 0 indicates that Router A declares itself a slave.
    4. After Router B receives the packet, Router B's status changes to Exchange and Router B sends a new DD packet containing its own LSA summaries to Router A. The value of the Seq field carried in the new DD packet is changed to y + 1.

      Router A uses the same sequence number as Router B to confirm that it has received DD packets from Router B. Router B uses the sequence number plus one to confirm that it has received DD packets from Router A. When Router B sends the last DD packet, it sets the M field of the packet to 0.

  3. LSDB synchronization
    1. After Router A receives the last DD packet, it finds that many LSAs in Router B's LSDB do not exist in its own LSDB, so Router A's status changes to Loading. After Router B receives the last DD packet from Router A, Router B's status directly changes to Full, because Router B's LSDB already contains all LSAs of Router A.
    2. Router A sends an LSR packet for updating LSAs to Router B. Router B returns an LSU packet to Router A. After Router A receives the packet, it sends an LSAck packet for acknowledgement.

      The preceding procedures continue until the LSAs in Router A's LSDB are the same as those in Router B's LSDB. Router A's status changes to Full. After Router A and Router B exchange DD packets and update all LSAs, they establish an adjacency.

Adjacency establishment on an NBMA network

The adjacency establishment process on an NBMA network is similar to that on a broadcast network. The blue part shown in Figure 1-4 highlights the differences from a broadcast network.

On an NBMA network, all routers establish adjacencies only with the DR and BDR.

Figure 1-4 Adjacency establishment process on an NBMA network

The adjacency establishment process on an NBMA network is as follows:

  1. Neighbor relationship establishment
    1. After Router B sends a Hello packet to a Down interface of Router A, Router B's status changes to Attempt. The packet carries the DR field of 2.2.2.2 (ID of Router B) and the Neighbors Seen field of 0. A neighbor router has not been discovered, and Router B regards itself as a DR.
    2. After Router A receives the packet, Router A's status changes to Init and Router A returns a Hello packet. The returned packet carries the DR and Neighbors Seen fields of 2.2.2.2. Router B has been discovered but its router ID is greater than that of Router A, and therefore Router A agrees that Router B is a DR.

    The following procedures are not performed for DR others on an NBMA network.

  2. Master/Slave relationship negotiation and DD packet exchange

    The procedures for negotiating a master/slave relationship and exchanging DD packets on an NBMA network are the same as those on a broadcast network.

  3. LSDB synchronization

    The procedure for synchronizing LSDBs on an NBMA network is the same as that on a broadcast network.

Adjacency establishment on a point-to-point (P2P)/point-to-multipoint (P2MP) network

The process for establishing an adjacency on a P2P/P2MP network is similar to that on a broadcast network except that no DR or BDR needs to be elected on a P2P/P2MP network. DD packets are transmitted in multicast mode on P2P networks and in unicast mode on P2MP networks.

Route Calculation

OSPF uses an LSA to describe the network topology. A Type 1 LSA describes the attributes of a link between routers. A router transforms its LSDB into a weighted, directed graph, which reflects the topology of the entire AS. All routers in the same area have the same graph. Figure 1-5 shows a weighted, directed graph.

Figure 1-5 Weighted, directed graph

Based on the graph, each router uses an SPF algorithm to calculate an SPT with itself as the root. The SPT shows routes to nodes in the AS. Figure 1-6 shows an SPT.

Figure 1-6 SPT

When a router's LSDB changes, the router recalculates a shortest path. Frequent SPF calculations consume a large amount of resources and affect router efficiency. Changing the interval between SPF calculations can prevent resource consumption caused by frequent LSDB changes. The default interval between SPF calculations is 5 seconds.

The route calculation process is as follows:

  1. A router calculates intra-area routes.

    The router uses an SFP algorithm to calculate shortest paths to other routers in an area. Type 1 and Type 2 LSAs accurately describe the network topology in an area. Based on the network topology described by a Type 1 LSA, the router calculates paths to other routers in the area.

    If multiple equal-cost routes are produced during route calculation, the SPF algorithm retains all these routes in the LSDB.

  2. The router calculates inter-area routes.

    The network segment of the routes in an adjacent area can be considered to be directly connected to the area border router (ABR). Because the shortest path to the ABR has been calculated in the preceding phase, the router can directly check a Type 3 LSA to obtain the shortest path to the network segment. The autonomous system boundary router (ASBR) can also be considered to be connected to the ABR. Therefore, the shortest path to the ASBR can also be calculated in this phase.

    If the router performing an SPF calculation is an ABR, the router needs to check only Type 3 LSAs in the backbone area.

  3. The router calculates AS external routes.

    AS external routes can be considered to be directly connected to the ASBR. Because the shortest path to the ASBR has been calculated in the preceding phase, the router can check Type 5 LSAs to obtain the shortest paths to other ASs.

Configuring Basic OSPF Functions

Before building OSPF networks, you need to configure basic OSPF functions.

Applicable Environment

When OSPF is configured on multiple routers in the same area, most configuration data, such as the timer, filter, and aggregation, must be planned uniformly in the area. Incorrect configurations may cause neighboring routers to fail to send messages to each other or even causing routing information congestion and self-loops.

The OSPF-relevant commands that are configured in the interface view take effect regardless of whether OSPF is enabled. After OSPF is disabled, the OSPF-relevant commands also exist on interfaces.

Pre-configuration Tasks

Before configuring basic OSPF functions, complete the following task:

  • Configuring IP addresses for interfaces to ensure that neighboring nodes are reachable at the network layer

Creating an OSPF Process

Context

To run OSPF, the router needs to have a router ID. A router ID of the router is a 32-bit unsigned integer, which uniquely identifies the router in an AS. To ensure the stability of OSPF, you need to manually configure a router ID for each device during network planning.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] *

    An OSPF process is created, and the OSPF view is displayed.

    • The parameter process-id specifies the ID of an OSPF process. The default value is 1.

      The router supports OSPF multi-process. You can create different processes for different types of service. The OSPF process ID is valid in the local area, without affecting packet exchange with other routers. Therefore, different routers can also exchange packets even though they have different process IDs.

    • The parameter router-id router-id specifies the router ID of the router.

      By default, the system automatically selects an IP address of the interface as the router ID. The largest IP address in loopback addresses is taken as the router ID. If no loopback interface is configured, the largest IP address configured on the interface is selected as the router ID. When manually setting a router ID, ensure that the router ID of each device in an AS is unique. Generally, you can set the router ID to be the same as the IP address of a certain interface on the device.

    The router ID of each OSPF process must be unique on the OSPF network; otherwise, the OSPF neighbor relationship cannot be set up and routing information is incorrect. Configuring a unique router ID for each OSPF process on each OSPF device is recommended to ensure stability.

    • The parameter vpn-instance vpn-instance-name specifies the name of a VPN instance.

      If a VPN instance is specified, the OSPF process belongs to the specified VPN instance. Otherwise, the OSPF process belongs to the public network instances.

Creating an OSPF Area

Context

More and more devices are deployed with the increasing expansion of the network scale. As a result, each device has to maintain a large LSDB, which becomes a heavy burden. OSPF solves this problem by dividing an AS into areas. An area is regarded as a logical device group. Each group is identified by an area ID. The borders of an area are devices, rather than links. A network segment (or a link) belongs to only one area; that is, each OSPF interface must belong to an area.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] *

    The OSPF process is enabled, and the OSPF view is displayed.

  3. Run area area-id

    The OSPF area view is displayed.

    Areas are not equally important. The area with an area ID 0 is called the backbone area. The backbone area is responsible for forwarding inter-area routing information. In addition, routing information between non-backbone areas must be forwarded through the backbone area.

Enabling OSPF

Context

After creating an OSPF process, you need to configure the network segments included in an area. A network segment belongs to only one area. that is, you need to specify an area for each interface that runs OSPF. In this document, network segment refers to the network segment to which the IP address of the OSPF interface belongs.

OSPF checks the network mask carried in a received Hello packets. If the network mask carried in a received Hello packet is different from the network mask of the local device, the Hello packet is discarded. As a result, an OSPF neighbor relationship is not established.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run area area-id network ip-address wildcard-mask interface interface-type interface-number ospf enable [ process-id ] area area-id

    The OSPF area view is displayed.

    OSPF can be enabled in an OSPF area or on a specific interface.

    • Enable OSPF in an OSPF area.
    1. Run

      Network segments belonging to an area are configured.

      OSPF can properly run on an interface only when the following conditions are met:

      • The IP address mask length of the interface is equal to or greater than the mask length specified in the network command.
      • The primary IP address of the interface must be within the network segment specified by the network command.

        By default, OSPF advertises the IP address of the loopback interface as a 32-bit host route, which is irrelevant to the mask length configured on the loopback interface. To advertise routes to the network segment of the loopback interface, configure the network type as NBMA or broadcast in the interface view. For details, see Configuring Network Types of OSPF Interfaces.

    • Enable OSPF on an interface.
    1. Run the following command in the system view:interface interface-type interface-number

      The interface view is displayed.

    2. Run ospf enable [ process-id ] area area-id

      OSPF is enabled on the interface.

      An area ID can be input in the format of a decimal integer or an IPv4 address, but displayed in the format of IPv4 address.

(Optional) Creating OSPF Virtual Links

Context

After OSPF areas are defined, OSPF route updates between non-backbone areas are transmitted through a backbone area. Therefore, OSPF requires that all non-backbone areas maintain connectivity with the backbone area and that the backbone areas in different OSPF areas maintain connectivity with each other. In real world situations, this requirement may not be met because of certain restrictions. To resolve this problem, you can configure OSPF virtual links.

Perform the following steps on the router running OSPF.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run area area-id

    The OSPF area view is displayed.

  4. Run vlink-peer router-id [ smart-discover | hello hello-interval | retransmit retransmit-interval | trans-delay trans-delay-interval | dead dead-interval | [ simple [ plain plain-text | [ cipher ] cipher-text ] | { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain plain-text | [ cipher ] cipher-text } ] | authentication-null | keychain keychain-name ] ] *

    A virtual link is created.

    This command must also be configured on the neighboring router.

    If plain is selected, the password is saved in the configuration file in plain text. This brings security risks. It is recommended that you select cipher to save the password in cipher text.

    MD5 authentication and HMAC-MD5 authentication have potential security risks. HMAC-SHA256 authentication mode is recommended.

Follow-up Procedure

After virtual links are created, different default MTUs may be used on devices provided by different vendors. To ensure consistency, the MTU is set to 0 by default when the interface sends DD packets. For details, see Configuring an Interface to Fill in the DD Packet with the Actual MTU.

(Optional) Restricting the Flooding of LSA Update Packets

Context

When multiple neighboring routers are configured or a large number of LSA update packets are flooded, the neighboring router may receive a large number of LSA update packets in a short period. This keeps the neighboring router busy processing a burst of LSA update packets and causes the neighboring router to discard Hello packets that are used to maintain the OSPF neighbor relationships. As a result, the neighbor relationships are interrupted. After the neighbor relationships are reestablished, more packets will be exchanged. This increases the frequency of neighbor relationship interruption. To resolve this problem, you can restrict the flooding of LSA update packets to maintain neighbor relationships.

Perform the following steps on the router running OSPF.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ospf [ process-id ]

    The OSPF process view is displayed.

  3. Run flooding-control [ number transmit-number | timer-interval transmit-interval ] *

    The flooding of LSA update packets is restricted.

    By default, the number of LSA update packets to be flooded each time is 50, and the interval at which LSA update packets are flooded is 30s.

    After the flooding-control command is run, the flooding of LSA update packets is immediately restricted.

    If the flooding-control command is not run, the function of restricting the flooding of LSA update packets automatically takes effect when the number of neighboring routers exceeds 256.

Verifying the Basic OSPF Function Configuration

Prerequisites

All configurations of basic OSPF functions are complete.

Procedure

  • Run the display ospf [ process-id ] peer command in any view to check information about OSPF neighbors.
  • Run the display ospf [ process-id ] interface command in any view to check information about OSPF interfaces.
  • Run the display ospf [ process-id ] routing command in any view to check information about the OSPF routing table.
  • Run the display ospf [ process-id ] lsdb command to check information in the OSPF LSDB.

Featured Post

Day 41 — BGP Confederations: Sub-AS Design, External View and Migration

1. Opening Confederations are another way to scale BGP inside a large administrative domain. They divide the domain into member autonomous systems while presenting a single confederation identifier to external peers. They are powerful, but their operational model is more complex than simply 'using private ASNs inside.' The engineering goal is not to memorize another BGP command. It is to understand what information each speaker is allowed to propagate, what path information can be hidden, and what failure domain is created by the chosen control-plane architecture . 2. Concept and standards behavior RFC 5065 defines AS_CONFED_SEQUENCE and AS_CONFED_SET and how member-AS relationships are represented. Confederation external sessions have eBGP-like properties inside the confederation, while the confederation is presented externally as one AS. Modern guidance must also account for the fact that RFC 9774 prohibits new origination of AS_SET/AS_CONFED_SET in ordinary aggregation c...