Operations
1.4.d i General operations
General information on “OSPF General operations”:
- OSPF packet types:
- Hello Packets:
- Used to form and maintain neighborships
- Contains own RID, Area ID, Authentication, Hello/Dead timers, Stub Flag, DR/BDR info, RIDs of neighbors
- Some of these parameters must match to form a relationship
- Database Description (DBD):
- Is a summary of the LSDB
- Helps to build and synchronize the LSDB between two routers
- Contains only LSA headers, no the full LSA entries
- Link-State Requests (LSR):
- Request for a LSU
- Contains the requested LSA Type and LSA ID as well as the own RID
- Link-State Updates (LSU):
- Reply to LSR
- Contains one or several LSAs
- The maximum number of LSAs within a single LSU is limited by the link MTU
- Link-State Acknowledgement (LSAck):
- Acknowledgement of all OSPF packets (except Hello)
- Multiple LSAs can be acknowledged at once by including each LSA header
- Hello Packets:
- OSPF neighbor states:
- DOWN
- OSPF process has not started
- No Hello Packets have been received
- Hello Packets can be sent
- ATTEMP (only valid for NBMA)
- The router sends unicast Hello Packets to the neighbor
- Hello Packets haven’t been received within the dead interval
- INIT
- Router received a Hello packet from its neighbor without his own RID
- If the own RID is not included in the received Hello Packet, the Hello Packet isn’t valid
- 2-WAY
- Bi-directional communication is established
- Router received Hello packet from its neighbor with his own RID
- Receiving a DBD packet from a neighbor in INIT state will also cause a transition into 2-WAY state
- If all required parameters match, the can become neighbors
- At the end of this state, the DR/BDR for Broadcast and NBMA are elected
- Important: On Broadcast and NBMA the router only becomes FULL with the DR/BDR and stays in 2-WAY with all other routers!
- EXSTART
- Once the DR/BDR is elected, routers and their DR/BDR establish a master-slave relationship
- The router with the higher RID becomes the master
- The elected Master starts with the exchange of information
- Important: Master/Slave election is done on a per-link basis!
- Important: DR is not automatically the master since the DR/BDR can also be elected based on the configured priority!
- EXCHANGE
- Routers exchange their DBDs
- Each DBD has a sequence number that can be incremented only by the master and acknowledged by the salve
- The received information is checked against the own LSDB to check if the neighbor has new or more current information available
- LOADING
- Router sends LSRs for any missing LSAs
- Neighbor responds with LSUs
- All LSU packets are acknowledged
- FULL
- LSDBs are identical and routers are fully adjacent with each other
- LSDBs are fully synchronized
- DOWN
- OSPF DR/BDR and its election:
- Each regular router sends his updates to the DR (Designated Router)
- Only the DR (Designated Router) forwards these updates to all other routers
- If the DR (Designated Router) fails, the BDR (Backup Designated Router) overtakes his role
- After that, another router is elected as BDR (Backup Designated Router)
- Each multi-access segment has its own pair of DR/BDR routers
- Router with the highest priority (if configured) or RID becomes DR
- Priority is configured per interface (255 = highest, 0 = not taking part in election, 1 = default)
- As per RFC, the BDR is elected first and the DR is elected second
1.4.d ii Graceful shutdown
General information on “OSPF Graceful shutdown”:
- Enabled by default, can’t be disabled
- The router on which the OSPF process is shutdown will:
- Drop all neighbor adjacencies
- Flush all LSAs that the router originated by setting the age to 3600 seconds
- Send HELLO packets with the DR/BDR set to 0.0.0.0 and an empty neighbor list
- This will trigger other routers to fall back to INIT state
- Stop sending/receiving OSPF packets
- This allows neighbors to quickly converge because they won’t wait until the holdtime to the particular router expires
- Important: This also applies when shutting down an interface connected to an OSPF neighbor!
“OSPF Graceful shutdown” CLI configuration commands:
## ======
## OSPFv2
## ======
## Shutting down the whole OSPFv2 process gracefully
Router(config)# router ospf <pid>
Router(config-router)# shutdown
## Shutting down OSPFv2 gracefully on a per-interface basis
Router(config)# interface <if>
Router(config-if)# ip ospf shutdown
## ======
## OSPFv3
## ======
## Shutting down the whole OSPFv3 process gracefully
Router(config)# router ospf <pid>
Router(config-router)# address-family [ipv4 | ipv6]
Router(config-router-af)# shutdown
## Shutting down OSPFv3 gracefully on a per-interface basis (both address families)
Router(config)# interface <if>
Router(config-if)# ospfv3 <pid> shutdown
## Shutting down OSPFv3 gracefully on a per-interface basis (for a specific address family)
Router(config)# interface <if>
Router(config-if)# ospfv3 <pid> [ipv4 | ipv6] shutdown
1.4.d iii GTSM (Generic TTL Security Mechanism)
General information on “OSPF GTSM”:
- Protects against OSPF spoofing attacks
- Sets the TTL of outgoing OSPF packets to 255
- Discards incoming packet that have a TTL below the configured threshold
- Only applies to “normal” interfaces by default
- Must be explicitly configured on virtual links and sham links
Configuration considerations:
- In OSPFv3, GTSM can only be configured for virtual-links and sham-links
- Hop count defines the maximum hops a OSPF packet can have traversed when it reaches the router (255 - hops <count> = minimum allowed TTL)
- When the [hops <count>] argument is not specified, only directly connected neighbors will be allowed
- For all virtual- and sham-links, the configuration of hops <count> is mandatory
“OSPF GTSM” CLI configuration commands:
## ======
## OSPFv2
## ======
## Enabling GTSM globally for all OSPFv2 interfaces
Router(config)# router ospf <pid>
Router(config-router)# ttl-security all-interfaces [hops <count>]
## Disabling GTSM for OSPFv2 on a per-interface basis
Router(config)# interface <if>
Router(config-router)# ip ospf ttl-security disable
## Enabling GTSM for OSPFv2 on a per-interface basis
Router(config)# interface <if>
Router(config-router)# ip ospf ttl-security [hops <count>]
## Enabling GTSM for a specific OSPFv2 virtual-link
Router(config)# router ospf <pid>
Router(config-router)# area <id> virtual-link <remote-rid> ttl-security hops <count>
## Enabling GTSM for a specific OSPFv2 sham-link
Router(config)# router ospf <pid>
Router(config-router)# area <id> sham-link ttl-security hops <count>
## ======
## OSPFv3
## ======
## Enabling GTSM for a specific OSPFv3 virtual-link
Router(config)# router ospfv3 <pid>
Router(config-router)# address-family ipv6
Router(config-router-af)# area <id> virtual-link <remote-rid> ttl-security hops <count>
1.4.d Forwarding address (not on blueprint)
General information on “OSPF Forwarding address”:
- The feature is designed to avoid extra hops when forwarding traffic to an external domain
- Therefor the “Forwarding Address” is only relevant/set for Type 5 translated LSAs
- If the “Forwarding Address” is set to 0.0.0.0 (OSPFv2) or not visible (OSPFv3) within the LSA, then the route must be resolved to the value of the “Advertising router” field first
- If the router originating the original Type7-LSA advertises its loopback interface into OSPF, the forwarding address will be set to the loopback interface IP address
- If the router originating the original Type7-LSA doesn’t advertise its loopback interface into OSPF, the first interface of the OSPF interface list is selected as FA
- In order for the FA to be set to the next-hop router IP address, the following conditions must be met:
- OSPF must be enabled on the ASBRs next-hop interface towards the external domain
- ASBRs next-hop interface is non-passive
- ASBRs next-hop interface must be of network type BROADCAST to ensure there’s at least on other router which can forward the traffic
// Graphic missing - Coming soon //