# OSPF 3 - Network and LSA Types ## Loopback Interfaces * A loopback interface is a 'virtual' interface in the router * It is always UP/UP (unless you manually shut it down) * Its not dependent on a physical interface * So, it provides a consistent IP address that can reach / identify the router. * Sometimes you need to send traffic DIRECTLY to a router. ![](/files/-MISxaJ9LeYT8TJBKsyi) Lets say R1 has no loopback interface and R4 receives a packet destined for R1 at 10.0.12.1, the IP of its gi0/0 interface. It will forward the traffic from R4 -> R2 -R1 to get to that interface\ However, there is fibre break and the circuit goes down so OSPF will re-route the traffic via R3 to R1. But it cant get to gi0/0 because the interface is in a DOWN state.\ With a loopback address - this interface will never go down even if we lose gi0/0. ## OSPF Network Types There are 3 main network types: * **Broadcast Networks** - Enabled by default on FDDI and Ethernet **INTERFACES** * **Point-to-Point Networks** - Enabled by default on PPP and HDLC (High-Level Data Link Control) **INTERFACES** * **Non Broadcast Networks** - Enabled on Frame Relay and X25 **INTERFACES** * NBMA - non broadcast multi-access networks * P-to-M - point-to-multipoint networks ### Broadcast Networks ![](/files/-MIUBXTMsj-yVAXDroxl) Fa, Gi are all ETHERNET interfaces. All previous examples on OSPF have been the broadcast type. * Routers **DYNAMICALLY** discover neighbours by sending HELLO packets using the multicast address **224.0.0.5** * A **DR** (Designated Router) and **BDR** (Backup Designated Router) must be elected on EACH SUBNET. You will **only have DR** if there are **no OSPF neighbours** - like on R1's gi1/0 interface) * Routers which are not DR or BDR become **DROther** * How are DR's and BDR's elected? * Highest OSPF **INTERFACE PRIORITY** (Default = 1) * Highest OSPF Router ID's * 1st Place in Election = DR * 2nd Place in Election =BDR ![](/files/-MIUcNbbsCyOJalvMVNl) From R2 we can see the following: * Its router type = DROther * Its priority = 1 (default) * Its network type = Broadcast * The DR = R5 on OSPF interface 192.168.2.4 * The BDR = R4 on OSPF interface 192.168.2.3 ![](/files/-MIUTYQ8ICcq1QCvDrD3) What happens if we change R2's gi0/0 OSPF interface to the maximum (255)`R2(config)# interface gi0/0`\ `R2(config-if)# ip ospf priority 255`**`(if we set the priority to 0, the router CANNOT be the DR/BDR for that subnet`** {% hint style="success" %} If we check **R2's** interface again to see if it has become the DR for that subnet\ NO!!!!\ Why NOT???? It's because the DR/BDR election in 'non-preemptive' meaning that once the DR/BDR election has taken place, it wont change even if a router with a higher priority (priority/router ID) is introduced - it will only change if the DR goes down. Lets reset the OSPF processes (not a good idea on a production network)\ \&#xNAN;**`R5# clear ip ospf process`** {% endhint %} {% hint style="danger" %} All neighbours will go down and R2 and R4 returns to the full state...BUT NOT R3!!\ Below is the output from:\ \ \&#xNAN;**`R5#clear ip ospf process`**\ **`R5#show ip ospf neighbour`** {% endhint %} ![](/files/-MIUfvFL6WPBaHhD0bns) {% hint style="info" %} So what happened here?? Well, the old BDR (R4) became the new DR and then an election was held for the new BDR -(between R5 and R2). R2 has higher priority so R5 becomes a DROther !!\ R3 and R5 is a DROther and is STABLE in a 2-Way state and will ONLY move to a FULL state with the DR and BDR. It will be in a 2-Way state with ALL other DROthers\ \ IN THE BROADCAST NETWORK TYPE, ROUTERS WILL FORM A **FULL OSPF ADJACENCY** WITH THE **DR AND BDR** OF THE SEGMENT. THEREFORE, ROUTERS ONLY EXCHANGE LSA's WITH THE DR AND BDR. DROTHER's WILL NOT EXCHANGE LSA's WITH EACH OTHER!!!! ALL ROUTERS WILL STILL HAVE THE SAME LSDB, BUT THIS REDUCES THE AMOUNT OF LSA's FLOODING THE NETWORK. {% endhint %} #### DR/BDR Full Adjacencies and DROther 2-Way State ![](/files/-MIVKpwKqPBQwZoVmsVu) If we use a DR and BDR, and all routers form FULL adjacencies with the DR and BDR and only have 2-Way State with the DROther's, it would be a lot less LSA's flooding the network\ When routers need to send messages to the DR and BDR they use the multicast address of **224.0.0.6**. This is different to the OSPF **"all routers" multicast of 224.0.0.5** ![](/files/-MIVMgOlYDXarKvcTfd7) On the DROther R3 router we do a `R3#show ip ospf interface brief` and we can see the NEIGHBOUR COUNT on its GI0/0 interface: * F = the number of FULL adjacencies * C = the TOTAL count of neighbours ![](/files/-MIVOsBoqlc9bZy6GB--) We can see here that **R3 has 2 Full adjacencies with R2 and R4** (DR and BDR) and has 3 total neighbours **(R2, R4 and R5)** Just to check - if we see from the command on R3's gi0/0 interface `R3#show ip ospf interface gi0/0` we will see the same information as the previous command ![](/files/-MIVRSz0j9HmNUeT_zMd) * Neighbour count is 3 * Adjacent neighbour count is 2 (DR and BDR) ### Point-to-Point Networks ![](/files/-MIVT5yuVonuzCBAcrZK) * Enabled on **SERIAL** interfaces using the Layer 2 PPP / HDLC (High-Level Data Control) encapsulations by DEFAULT * Routers **DYNAMICALLY DISCOVER** neighbours by sending/receiving HELLO packets using multicast 224.0.0.5 * **BUT!!!!** A DR and BDR are NOT elected. As this is a P2P connection there is no reason to elect a DR or BDR - they will form a FULL adjacency with each other. #### Serial Interfaces ![](/files/-MIVUl1oC5o3sacyrCvw) * The 2 ends of serial connection function are either a **DCE** (Data Communications Equipment) or **DTE** (Data Termination Equipment) * The **DCE ALWAYS** supplies the **"CLOCK" or speed** (the SPEED of the INTERFACE) in BITS PER SECOND **bps** (The "C" in DCE is a good way to remember which side supplies the clock or "speed") * Ethernet interfaces use the SPEED command to configure the interfaces operating speed. SERIAL interfaces use the CLOCK RATE command **`To check which side is DCE and which is DTE`** **`R1#show controllers s2/0 --------------DCE V.35`**\ **`R2#show controllers s2/0 --------------DTE TX and RX clocks detected`** ![](/files/-MIVZ14v0SyOx6aj9D78) ![](/files/-MIV_SMvKYhpeMBTGpYp) #### Configure the OSPF Network Type and WHY would you CHANGE it?? `R1(config-if)# ip ospf network point-to-point` **Why would you change the network type???** For example, if two routers are directly connected with an Ethernet link, like in the diagram below, there is NO need for a DR/BDR. You can c**onfigure this as a P2P network type** in this case, although you DON'T HAVE TO! :) ![](/files/-MIVb7_rRP3CJJDIlnS7) {% hint style="info" %} Not all network types work on all link types (for example, a serial link cannot use the broadcast network type, because SERIAL links do not support Layer 2 Broadcast frames, which is necessary for the broadcast network type !! {% endhint %} **A Chart for a Quick Review** ![](/files/-MIVceQ_02BdHjj-303_) ## OSPF Neighbour Relationship Requirements Usually routers will become OSPF neighbours without an issue, but some problems can arise which stops the neighbour relationship from occurring. * **AREA ID** number must match * AREA TYPE (stub, NSSA etc) * The **INTERFACES** must be in the **same subnet** to become OSPF neighbours * The **OSPF process** must not be **shutdown** * The **OSPF router ID's** (RID) must be **unique** * The **HELLO and DEAD** timers must **match** * `R2(config-if)# ip ospf hello-inetrval ? ` * `R2(config-if)# ip ospf dead-inetrval ? ` * **Authentication** settings must **match** * `R2(config-if)# ip ospf authentication-key G1ng` * `R2(config-if)# ip ospf authentication ----this enables authentication on the interface` * The IP **MTU settings** on the interfaces must **match.** The MTU is the maximum size of an IP packet that will be sent out of the interface. Default usually 1500. \ This and the next one are special in the fact that even-though the settings DON'T match, the neighbours CAN become OSPF neighbours - but OSPF WONT function properly * `R2(config-if)# ip mtu 1400`\ `R2(config-if)# do show ip ospf neighbour`\ `R2(config-if)# do clear ip ospf process`\ `***Then issues started here !!!****` * OSPF **Network Type** must **match. --->** * `R1# show ip ospf neighbour interface gi0/0` * `R2# show ip ospf neighbour interface gi0/0` This can be tricky to troubleshoot because the neighbour state is FULL so it can seem that everything is working fine. ## LSA Types OSPF uses a LSDB (link state database) and fills this database with LSA's. There are many types of LSA's used ![](/files/-MIa8u1QPirAuRnMg4pa) The OSPF is made up of LSA's\ There are 11 types of LSA's: * Type 1 LSA = Router LSA * Type 2 LSA = Network LSA * Type 3 LSA = Summary LSA * Type 4 LSA = Summary ASBR LSA * Type 5 LSA = AS External LSA ### Type 1 LSA - Router LSA (PREFIX INFORMATION) **Every router running OSPF WITHIN their area**, generates a Type 1 LSA, * which identifies the router using its RID and also contains lists of **all** the prefixes that a router has (ie networks attached to the routers OSPF activated interfaces) * LSA 1's also contains a COST for each link that they are advertising * LSA 1's also contain the neighbour RID only if the network type is * P-to-P or P-to-M. * IF the network type is BROADCAST you only receive updates from the DR and BDR so will have the RID of the DR/BDR ### Type 2 LSA - Network LSA (Only from Broadcast Network This type of LSA is only generated in a Broadcast segment and is: * **Generated by the DR (Designated Router)** of each "multi-access" network. An example of a multi-access network is an Ethernet network using the 'Broadcast' network type. * Does not send Prefix information ### Type 3 LSA - Summary LSA ![ABR's generate Type 3 LSA's](/files/-MJ9RDza70xgdu1eJkus) * ### Type 5 LSA - AS External LSA This type of LSA is **generated by the ASBR's** (Autonomous System Boundary Routers), to DESCRIBE ROUTES to destinations OUTSIDE the AS, ie the OSPF domain. ### LSDB - Link State Data Base From the output **`R1#show ip ospf database`** {% hint style="info" %} NOTE !! - It doesn't matter which router we run the above command on, we will get the same output as all routers have the SAME LSDB!! {% endhint %} ![](/files/-MIaImEf2xv-fZ6nLY-c) #### QUIZ 1 ![](/files/-MIaKmdASFUUDdt4ec0v) #### QUIZ 2 ![](/files/-MIaLEOt9EMA8n_sQzBU) #### QUIZ 3 ![](/files/-MIaLfeyWYfXCs2lFXzM) #### QUIZ 4 ![](/files/-MIaM0liFwekr5yf6u4f) #### QUIZ 5 ![](/files/-MIaMfq-G6HobDdQrBNS) Boson Ex-SIM ![](/files/-MIaNLyyjzn9wywaIo4I) ### LAB ![](/files/-MIcGcPbEP6c70bFUPuT) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://cisco.microcisco.com/icnd-1/routing/ospf-3-network-and-lsa-types.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.