Friday, 2 September 2016

OSPF - Labbing Notes 2

OSPF is sometimes described as being partially link-state and partially distance vector. This is because SPF calculations are only performed for Intra-Area routing, whereas the Area Border Routers’ (ABRs) advertised information is trusted for Inter-Area and External calculations. R10 does not know the detailed information about the path selection that is occurring behind R5 (ABR). R10 trusts R5’s calculation for the prefix, which is typically a distance vector behavior, and then calculates the shortest Intra-Area path to reach R5, which is a link-state behavior.

Metric of the route is 41 and it’s an ospf inter-area route. Next hop is 155.1.108.8 and the route is from 150.1.5.5 with the cost of 21.



























First finding out who R10 is adjacent with by viewing its Router LSA (LSA 1).














































So, from above total cost from R10 to 150.1.6.6 is 21+10+10=41. 
Now, let’s see how R5 gets the cost of 21.







To view possible paths to Network Summary LSA (LSA 3), below shows both R1 and R4 with advertising cost of 11.

































To find shortest path cost to R1 and R4, 


















The cost to reach all ABR routers can also be identified from the following output.










Setting a ospf cost for an interface is only effective for its router’s shortest path calculation; not the directly connected router at the other end of the interface. OSPF cost calculation for a segment is based on the bandwidth value of the outgoing interface.
To have different OSPF cost per neighbor, the network type’s point-to-multipoint and point-to-multipoint non-broadcast support the setting of the OSPF cost value on a per-neighbor basis.
---------------------------------------------------------------------------------------

Inter-area routing can only occur through area 0.
Non-backbone (not area 0) areas can be used for inter-area transit if a shorter path can be found through them, and if the "TransitCapability parameter has been set to TRUE in Step 2 of the Dijkstra algorithm." In Cisco’s IOS implementation, this flag is controlled with the capability transit routing process-level command, and is on by default. The design case when the feature is used is very specific and has to do with a shorter Inter-Area path being found via a non-area 0 router as compared to the target router of a virtual-link.

Flooding Reduction – LSA’s LS age is never incremented past the value MaxAge. When the link state age reaches MaxAge, the router must attempt to flush the LSA by reflooding the MaxAge LSA just as if it was a newly originated LSA. MaxAge value is 3600 sec or 60 minutes by default. To ensure the an LSA is not aged out, which means it will be flushed from the OSPF database, each LSA is reflooded after 30 minutes, regardless of whether the topology is stable or not. This periodic flooding behavior is commonly referred to as the “paranoid update.” The ip ospf flood-reduction feature stops unnecessary LSA flooding by setting the DoNotAge (DNA) bit in the LSA, removing the requirement for the periodic refresh. This needs to be enabled on links with OSPF neighbors attached.

OSPF Summarization
Because devices in an OSPF area require the same copy of the database to compute correct SPF, filtering or summarization of routes in the database can only occur between areas or domains, not within an area. Use "area <area no from where routes summarized> range address mask".
External OSPF summarization is configured at the redistribution point between routing domains with the summary-address command.

The Forward Address: 0.0.0.0 field means that R5 must now compute the metric toward the advertising router, ASBR, and install this metric in the routing table as the forward metric.
















The calculation for External Type-1 OSPF routes does not distinguish in the routing table between the metric reported by the ASBR and the metric to the ASBR via the forward metric. Instead, External Type-1 routes represent the metric as one cumulative value of the reported metric and the metric to the ASBR.








OSPF Stub Area
The stub area, is used to remove Type-5 External link states from the database and replace them with a default route. When an OSPF router redistributes a route into the domain, it originates a Type-5 External LSA representing the route and its attributes. Inside this LSA, the originating router sets the advertising router field to its local router-id and, generally, the forward address field to 0.0.0.0. When an OSPF router in the same area as the originator looks up the Type-5 LSA, it looks at the forward address. If the forward address is set to 0.0.0.0, it means that the traffic should be sent toward the advertising router to reach the destination. To find out how to reach the advertising router, the advertising router’s Type-1 Router LSA is consulted, and intra-area SPF is performed. This is similar to inter-area routing logic, because the router doing the lookup does not compute SPF to the final destination, only the intermediary advertising router.
For external routing between areas, the logic is modified slightly. When an Area Border Router receives a Type-5 External LSA from a device in its own area and passes it into a different area, a Type-4 ASBR Summary LSA is generated. The Type-4 LSA tells devices in the new area how to forward toward the ASBR, which in turn tells them how to forward toward the external route.

OSPF NSSA
When the Type-7 NSSA External LSA is received by the ABR and is moved into area 0, the information contained in the Type-7 LSA is translated to a normal Type-5 External LSA. If multiple ABRs exist, only one of them performs the translation through an election process.

Note that ABR R5 receives the Type-7 NSSA External LSA with the forward address set to 150.1.8.8. With the previous Type-5 external lookups, we saw the forward address set to 0.0.0.0, which meant to route toward the advertising router to reach the final destination. In this case, the forward address is non-zero, which causes the lookup to be performed toward 150.1.8.8. This is a subtle difference in the lookup process and there can, however, be certain designs where there is a shorter path to the forward address than the advertising router’s address.




















Note that the lookup process for this translated Type-7 LSA is performed differently than a normal inter-area Type-5 external LSA lookup, because R1 computes its metric toward 150.1.8.8, and not a Type-4 LSA describing the ASBR. Furthermore, note that R5 does not generate a Type-4 ASBR Summary LSA describing R8.




















Like the stub area, Type-5 external LSAs are blocked from entering the NSSA area on the ABR(s), note that R6's Loopback100 is known in area 0, but not in area 3.


The other key difference between stub and NSSA areas is how default routing works. The stub area removes external Type 3 LSAs and replaces them with a default route. The totally stubby area extends this by replacing external Type 3 LSAs and inter-area Type 2 LSAs with a default route. However, with the NSSA, a default route is not automatically originated by the ABR. This means that devices within the NSSA will have reachability to their own area and to other areas, but not to destinations outside of the OSPF domain.


























Using default information-originate option onto the area [id] nssa statement, the default route is injected by the ABR as a regular Type-7 LSA with the type of N2 which uses the metric advertised by the ABR and the forwarding metric as the cost towards the ABR. 



















The not-so-totally-stubby area is the combination of the totally-stubby area and the NSSA. Like the totally-stubby area, Type-3 Summary LSAs, Type-4 ASBR Summary LSAs, and Type-5 External LSAs are removed and replaced with a Type-3 Summary LSA default route. Like the NSSA, Type-7 NSSA External LSAs are allowed to be originated inside the area.
















OSPF always prefers routes in the sequence intra-area> inter-area > external > nssa-external.

----------------------------------------------
With OSPF Not-So-Stubby Areas, Type-7 NSSA External LSAs are translated to Type-5 External LSAs by the ABR connecting the NSSA to area 0. When multiple ABRs connect the NSSA to area 0, the ABR with the highest router-id is elected as the Type-7 to 5 translator, and is responsible for re-originating the Type-5 LSA into area 0.
Only one ABR performs the Type-7 to 5 translation, but maintains the forward address field, essentially separating the relationship between the routing advertisement and the traffic flow.

Type-5 External route that was translated from a Type-7 NSSA External route does not use a Type-4 ASBR Summary LSA, because the forward address lookup replaces the need for the ASBR Summary lookup. Because the forward address is preserved, only one router needs to do the translation, while the calculation of the final forwarding path stays independent. The control plane advertisement of the route does not need to follow the traffic forwarding plane.





























By adding the no-redistribution keyword onto the area 3 nssa statement of R5, Type-7 LSAs are not generated for locally redistributed routes. This does not, however, prevent other devices inside the NSSA from performing redistribution. 


OSPF Filtering

A very specific feature - OSPF Forwarding Address Suppression in Translated Type-5 LSAs can be configured by adding "translate type7 suppress-fa" argument to "area 3 nssa" statement to instruct the ABR to not preserve the value in the forward address field as a Type-7 NSSA External LSA is translated into a Type-5 External.

All routers within an OSPF area must agree on their view of the database and hence, OSPF filtering in the database can be accomplished between areas, but not within an area. Inter-area filtering has been previously demonstrated with stub areas, and the Type-3 LSA Filter (filter list). Intra-area filtering can be accomplished in OSPF with an inbound distribute-list; however, this filtering only affects the local routing table, not the OSPF database. This type of design can result in traffic black holes if not implemented carefully.
After implementing distribute-list inbound, the prefix/route is not installed in the routing table but it’s in the OSPF database.



































With a normal distribute-list filter referencing an access-list, there would be no way to distinguish between the same prefix from 2 neighbors because they are the same prefix, just two different paths in the network. Referencing a route-map with a distribute-list in OSPF extends the filtering capability with additional match criteria such as route-source, next hop ip, etc.

OSPF Default Routing

Default routing for non-stub areas in OSPF is accomplished through the origination of Type-5 External LSAs via the default-information originate command. Without any additional arguments, the OSPF process first checks to see if a default route is installed in the routing table. If a default route is already installed, such as via a static route or learned via BGP, the OSPF default route is originated. If the default route is not found, no origination occurs. This behavior is typically desirable in designs with multiple exit points out of the OSPF domain to upstream networks. This behavior can be modified by adding the always argument to the default-information originate statement, which essentially skips the checking for a default route already being installed in the table.

The automatic origination of the discard route can be disabled with the “no discardroute [internal | external]”, where internal refers to inter-area summarization performed with the area range command, and external refers to redistributed summarization performed with the summary-address command on the ASBR for NSSA type 7 to type 5 translation.

A neighbor relationship cannot occur if two OSPF neighbors have different MTU values on their interfaces. If the MTU difference is by design, the interface-level command ip ospf mtu-ignore removes this requirement from the adjacency establishment.



No comments:

Post a Comment