Common LSA types defined by OSPF of S series switches

34

Question: What are the common LSAs used in OSPF of S series switches? Why Type 6 LSAs do not exist?

Answer: On S series switches supporting OSPF, OSPF uses the following types of LSAs:
Type 1 LSA: router LSA
Type 2 LSA: network LSA
Type 3 LSA: summary LSA
Type 4 LSA: ASBR-summary LSA
Type 5 LSA: AS-external-LSA
Type 7 LSA: NSSA AS-external-LSA
OSPF packets were encoded based on Type-Length-Value (TLV). To enable other OSPF functions, you need to use LSAs of other types.

Type 6 LSAs, indicating group-membership-LSAs, are used to identify multicast group members in Multicast Open Shortest Path First (MOSPF). Switches do not support Type 6 LSAs.

Type 8 LSAs, indicating external-attributes-LSAs, are used to import BGP routes into OSPF processes for inter-operations and reserve information about BGP routes such as AS-Path. Switches do not support Type 8 LSAs.

The Opaque LSA type is defined by RFC 2370 and can use the TLV structure. Applications such as OSPF Traffic Engineering (TE) are implemented by the Opaque LSA.

The Type 9 LSA is the Opaque LSA flooding on a link.
The Type 10 LSA is the Opaque LSA flooding within an area.
The Type 11 LSA is the Opaque LSA flooding within an AS.

Other related questions:
Common LSA types of OSPF
Common LSA types of OSPF are as follows: Type 1 LSA: router LSA. Generated by each router, describes the router's link status and cost, and advertised within the area to which it belongs. Type 2 LSA: network LSA. Describes the link status of all routers on the local network segment. Network-LSAs are generated by a designated router (DR) and advertised within the area to which the DR belongs. Type 3 LSA: summary LSA. Generated by ABR, describes all routes in the area, and advertised to other relevant areas. Type 4 LSA: ASBR-summary LSA. An ASBR-summary-LSA describes routes to the ASBR in an area. The routes are advertised to all areas except the area to which the ASBR belongs. Type 5 LSA: AS-external-LSA. Describes AS external routes, which are advertised to all areas except stub areas and NSSAs. AS-external-LSAs are generated by an ASBR. Type 7 LSA: NSSA AS-external-LSA. Describes AS external routes. NSSA-LSAs are generated by an ASBR and advertised only within NSSAs. The original OSPF packet coding is not Type Length Value (TLV)-based. For the extension of OSPF functions, only the LSA types of OSPF can be extended. Type 6 LSAs are Group-Membership-LSAs used to identify multicast group membership in the Multicast Open Shortest Path First (MOSPF) protocol. Type 6 LSAs are not supported on the firewall. Type 8 LSAs are External-Attributes-LSAs used to redistribute Border Gateway Protocol (BGP) routes into OSPF and reserve the BGP autonomous system (AS) path information. Type 8 LSAs are not supported on the firewall. RFC 2370 defines an important LSA type, namely, Opaque LSA, which allows for TLV-like structures. OSPF applications, such as OSPF traffic engineering, are based on the Opaque LSA extension abilities: Type 9 LSAs are Opaque LSAs that are advertised within the local link only; Type 10 LSAs are Opaque LSAs that are advertised within the local area only; Type 11 LSAs, similar to Type 5 LSAs, are Opaque LSAs that are advertised within the local AS.

Set the interval at which OSPF LSAs are retransmitted on S series switches
An OSPF-enabled S series switch sends an acknowledgement packet after receiving an LSA packet. If a device does not receive any acknowledgement packet, it retransmits the LSA to its peer device. The link-state retransmit interval parameter specifies the interval at which the LSA is retransmitted. The default value is 5, in seconds. You can run the ospf timer retransmit interval command in the interface view to reset a value.

Description of common OSPF logs on S series switches
What do the following OSPF logs indicate? NBR_CHG_DOWN NBR_CHANGE_E IF_CHG_E The logs are described as follows: Feb 13 2009 17:10:52 LL-NE40E-1 %%01OSPF/3/NBR_CHG_DOWN(l): Neighbor event:neighbor state changed to Down. (ProcessId=1, NeighborAddress=10.0.97.129, NeighborEvent=InactivityTimer, NeighborPreviousState=Full, NeighborCurrentState=Down) Log description: The status of the neighbor of which the IP address is 10.0.97.129 turns from Full to Down due to InactivityTimer, which indicates that the switch does not receive a Hello keepalive packet from the neighbor within the period specified by DeadInterval. The following causes also lead to changes in neighbor status. KillNbr: An interface goes Down, the BFD session becomes Down, or a process is reset. LLDown: A VLANIF, trunk, or serial port becomes Down. SeqNumberMismatch: An error occurs when the two switches exchange routing information, or due to link transmission delay, the neighbor receives a Hello packet sent by the local switch after the neighbor relationship is interrupted and sends the local switch a DD packet. When the local switch in the Full state receives the DD packet, the event occurs. May 10 2009 14:13:00 R13 %%01OSPF/6/NBR_CHANGE_E(l): Neighbor changes event: neighbor status changed. (ProcessId=1, NeighborAddress=100.113.114.114, NeighborEvent=1-Way, NeighborPreviousState=Full, NeighborCurrentState=Init) Log description: The status of the neighbor of which the IP address is 100.113.114.114 turns from Full to Init due to 1-Way, which indicates that the switch receives a Hello packet from the neighbor that requires initializing the neighbor relationship. The OSPF neighbor status on the neighbor switch turns Down, the neighbor then sends an initialization packet to the local switch, and the local switch disconnects the neighbor relationship after receiving the packet. The log is generated. May 12 2009 14:23:58 R13 %%01OSPF/6/IF_CHG_E(l): Interface 82.2.76.3 received event InterfaceDown, interface state changed from DR to Down. (Process ID=1) Log description: The status of the interface with the IP address 82.2.76.3 turns from DR to Down due to an interface Down event. For example, the physical interface goes Down. The following cause also leads to changes in interface status. NeighborChange: Generally, after the status of an interface on a broadcast network turns from DR to Down, the BDR becomes the DR.

Description of common OSPF logs and alarms on S series switches
Description of common OSPF logs on S series switches What do the following OSPF logs indicate? NBR_CHG_DOWN NBR_CHANGE_E IF_CHG_E The logs are described as follows: Feb 13 2009 17:10:52 LL-NE40E-1 %%01OSPF/3/NBR_CHG_DOWN(l): Neighbor event:neighbor state changed to Down. (ProcessId=1, NeighborAddress=10.0.97.129, NeighborEvent=InactivityTimer, NeighborPreviousState=Full, NeighborCurrentState=Down) Log description: The status of the neighbor of which the IP address is 10.0.97.129 turns from Full to Down due to InactivityTimer, which indicates that the switch does not receive a Hello keepalive packet from the neighbor within the period specified by DeadInterval. The following causes also lead to changes in neighbor status. KillNbr: An interface goes Down, the BFD session becomes Down, or a process is reset. LLDown: A VLANIF, trunk, or serial port becomes Down. SeqNumberMismatch: An error occurs when the two switches exchange routing information, or due to link transmission delay, the neighbor receives a Hello packet sent by the local switch after the neighbor relationship is interrupted and sends the local switch a DD packet. When the local switch in the Full state receives the DD packet, the event occurs. May 10 2009 14:13:00 R13 %%01OSPF/6/NBR_CHANGE_E(l): Neighbor changes event: neighbor status changed. (ProcessId=1, NeighborAddress=100.113.114.114, NeighborEvent=1-Way, NeighborPreviousState=Full, NeighborCurrentState=Init) Log description: The status of the neighbor of which the IP address is 100.113.114.114 turns from Full to Init due to 1-Way, which indicates that the switch receives a Hello packet from the neighbor that requires initializing the neighbor relationship. The OSPF neighbor status on the neighbor switch turns Down, the neighbor then sends an initialization packet to the local switch, and the local switch disconnects the neighbor relationship after receiving the packet. The log is generated. May 12 2009 14:23:58 R13 %%01OSPF/6/IF_CHG_E(l): Interface 82.2.76.3 received event InterfaceDown, interface state changed from DR to Down. (Process ID=1) Log description: The status of the interface with the IP address 82.2.76.3 turns from DR to Down due to an interface Down event. For example, the physical interface goes Down. The following cause also leads to changes in interface status. NeighborChange: Generally, after the status of an interface on a broadcast network turns from DR to Down, the BDR becomes the DR. Description of common OSPF alarms on S series switches What do the following OSPF alarms indicate? NBRCHG IFCHG The alarms are described as follows: #Feb 2 20:49:25 2009 ONT-NE40-8-A OSPF/5/NBRCHG:OSPF TrapID1.3.6.1.2.1.14.16.2.2: Non-virtual neighbor 0.0.0.0 1082 Router 18.1.1.101 NbrRouter 172.21.59.1 state change to 8. Alarm description: The neighbor state between the neighbor with the router ID 172.21.59.1 and local switch changes to Full. Note: 1: Down 2: Attempt 3: Init 4: 2-Way 5: ExStart 6: Exchange 7: Loading 8: Full #Feb 2 20:40:45 2009 ONT-NE40-8-A OSPF/5/IFCHG:OSPF TrapID1.3.6.1.2.1.14.16.2.16: Non-virtual interface 11.1.1.137 0 Router 18.1.1.101 state change to 5. Alarm description: The status of the interface with the IP address 11.1.1.137 changes to DR. Note: 1: Down 2: Loopback 3: Waiting 4: P2P 5: DR 6: BDR 7: DROther

Which S series switch will be selected to translate Type 7 LSAs into Type 5 LSAs if multiple ABRs are deployed in an NSSA
Question: When multiple S series switches functioning as ABRs are deployed in an NSSA, which switch will be selected to translate Type 7 LSAs into Type 5 LSAs? Answer: The system automatically selects the ABR with the largest router ID to translate LSAs.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top