CCNP-Studies
Routing
2-OSPF
Ospf Filtering

Filtering

  • It's best to always go into the router ospf process (ospfv3 would be the address family process) and then apply the distribute-list or filter-list or whatever it may be that way you know what is allowed and you don't waste time then after you can create your prefix-list, ACL, route-map, etc.

Distribute Lists

  • When we filter inbound using Distribute Lists it only affects the RIB the LSDBs still have to be synchronized on every router in an area. With that said we cannot filter outbound as once we are advertising routes in the LSDB using LSAs
  • Filtering has to be done on every device in the area if you want to filter specific prefixes from certain devices
  • example command distribute-list prefix OSPF_FILTER in
  • We can also use the Gateway option to filter incoming updates based on a gateway distribute-list prefix OSPF_FILTER gateway [prefix-list name] this is saying if the prefixes are coming from a particular gateway then we want to advertise them.
    1. Create prefix-list to deny 192.168.2.0/24 network and allow all else: a. ip prefix-list OSPF_FILTER seq 5 deny 192.168.2.0/24 le 32 b. ip prefix-list OSPF_FILTER seq 10 permit 0.0.0.0/0 le 32
    2. create gateway prefix-list ip prefix-list OSPF_GATEWAY permit 10.1.3.1/32 10.1.3.1/32 is the gateway (next-hop) that we want to allow routes coming in from
    3. create distribute-list with gateway command: distribute-list prefix OSPF_FILTER gateway OSPF_GATEWAY in
    4. We would use the gateway command if we have multiple ways where the route can come in from.

Filter Lists

  • Applied on ABRs in between areas which filters "TYPE-3 LSAs" from leaving or entering the partcular ABR
  • Make sure to check the database because if you redistribute in the other area and don't use network statements they will come in as Type-5 and will not be blocked as only Type-3 LSAs are blocked with filter-lists as mentioned earlier.
  • Let's say we have an ABR connected to Area 0 and Area 50:
    • if you say area 0 in it will filter the routes from coming into area 0
    • if you say area 0 out it will filter the routes from going out of area 0
    • Same thing for Area 50 if we say out it will it will filter the routes from ever leaving area 50
    • Same thing for Area 50 if we say in it will it will filter the routes from ever entering into area 50
  • The command is: area 50 filter-list prefix OSPF_FILTER [in/out]
  • make sure that you include the le on the prefix list when necessary for example you have loopbacks that are /32s but in a prefix you summarize as /24 you have to include le 32 as well to be able to match each /32 loopback address.
  • The ABR will still have those routes in its LSDB but will not allow it to leave the area.

Note:

  • To filter LSAs in OSPF, you can apply filter criteria. In this case, the "LS age" field has been configured with a value of "MAXAGE (3605)". This setting indicates that the LSA is being removed from the LSDB prematurely. Typically, all LSAs have a lifetime of 3600 seconds, which is equivalent to one hour. If a new version of the LSA is not flooded before the LS age reaches 3600 seconds, the LSA will be removed from the LSDB. Originating routers can exploit this by intentionally setting the LS age of their self-originated LSAs to the MAXAGE value. This action compels other routers to eliminate the LSA from their LSDBs.

  • also, the metric value associated with this LSA is 16777215 in decimal notation. This value represents LSInfinity, indicating that the LSA is unreachable in the LSDB. It serves as an alternative to premature aging, as described earlier. In this particular scenario, both methods are employed, resulting in the flushing of the Type-3 summary LSA for the network a specific network from the LSDB in a particular area.

OSPF Prefix Suppression

OSPF prefix suppression is a feature designed to conceal unnecessary transit link information in an OSPF domain. It achieves this by excluding prefix details from the Link-State Database (LSDB) for intra-area links, like transit links, while preserving OSPF adjacency. This feature is particularly beneficial when certain links are exclusively for transit and never receive traffic from external networks.

Enabling Prefix Suppression: To activate OSPF prefix suppression, use the following command in interface configuration mode:

ip ospf prefix-suppression

Scenario Example

In a network with multiple routers within Area 1, consider Router A, which connects to another router, Router B, through a transit link exclusively used for internal routing purposes, with no external network traffic passing through.

In this scenario, OSPF prefix suppression proves advantageous. By enabling prefix suppression on Router A's interface linked to Router B, it conceals the transit link's network prefix, such as 13.1.1.0/24, from OSPF advertisements. Consequently, this prevents redundant information about the transit link from being disseminated to other routers in Area 1. As a result, OSPF LSDBs on other routers omit details about the transit link, thereby enhancing network efficiency and reducing the LSDB size.

Moreover, an interesting situation arose in this setup: Router B, functioning as the Designated Router (DR), advertised a Type-2 network LSA with a netmask of /32 instead of the actual netmask of /24. When OSPF routers calculate the network associated with a Type-2 Network LSA, they derive the network prefix through a bitwise AND operation between the Link State ID (set to the IP address of the DR on the segment) and the netmask. Under typical circumstances, this calculation results in the x.x.x.0/24 network.

However, due to Router B's configuration to suppress this intra-area prefix, it advertises the Type-2 LSA with a netmask of /32. According to RFC 6860, which outlines the method for concealing transit links in the OSPF topology, a prefix calculated from a Type-2 Network LSA as /32 should be disregarded. In essence, routers will refrain from adding the /32 prefix to their routing tables.

Global Prefix Suppression

This global prefix-suppression command automatically enables prefix suppression for all interfaces on the router, except for those falling into specific categories:

  • Loopback interfaces: Loopback interfaces are typically used for management and internal purposes and should remain reachable. Unless the network type is changed from stub to point-to-point in this case the loopback will no longer qualify as a loopback interface.
  • Passive interfaces: Passive interfaces are excluded as they are intentionally configured to not participate in OSPF routing updates.
  • Secondary interfaces: Secondary interfaces are commonly used for redundancy and should remain reachable.

This exclusion of interface types ensures that critical network designs remain functional.

If you need to disable prefix suppression for any interface, you can do this in two ways:

  1. Disable prefix suppression in the OSPF router configuration mode with the passive-interface <interface> command.

  2. Disable prefix suppression at the interface level with the ip ospf prefix-suppression disable command.

Scenario Example

  • In a network with multiple routers within Area 1, consider a scenario where Router A connects to another router, Router B, through a transit link. This transit link serves exclusively for internal routing purposes and does not handle external network traffic.

  • In this scenario, OSPF prefix suppression becomes beneficial. By enabling prefix suppression on Router A's interface connected to Router B, the transit link's network prefix (e.g., 13.1.1.0/24) is concealed from OSPF advertisements. This prevents unnecessary information about the transit link from being shared with other routers in Area 1. As a result, OSPF LSDBs on other routers do not contain information about the transit link, improving network efficiency and reducing LSDB size.

  • Furthermore, in this setup, an interesting situation arises. Router B, acting as the Designated Router (DR), advertises a Type-2 network LSA with a netmask of /32, instead of the actual netmask of /24. When OSPF routers calculate the network associated with a Type-2 Network LSA, they perform a bitwise AND operation using the Link State ID (set to the IP address of the DR on the segment) and the netmask. Under normal circumstances, this calculation results in the 13.1.1.0/24 network.

  • However, due to Router B's configuration for prefix suppression, it advertises the Type-2 LSA with a netmask of /32. According to RFC 6860, which describes how to hide transit links in the OSPF topology, a prefix calculated from a Type-2 Network LSA as /32 should be ignored. In other words, routers do not add the /32 prefix to their routing tables, maintaining network integrity.

Behaviour between OSPF and BGP

  • In a network configuration, a common challenge arises when attempting to influence the redistribution of routes between routers. In particular, when Router A (R8) redistributes routes into OSPF, it may not directly impact how Router B (R3) redistributes these OSPF routes into BGP. However, a viable solution can be found in the realm of network protocol standards.

  • Section 4 of RFC 1403 provides in-depth insights into the interaction between OSPF and BGP. This includes techniques for encoding BGP routing information within OSPF, which is useful when redistributing OSPF routes into BGP. The key element in this approach is the OSPF Tag, a 32-bit numerical value attached to OSPF external prefixes.

  • Detailed guidance on this interaction is available in Section 4.4.6 of RFC 1403. Notably, the OSPF Tag is expressed in decimal form, distinguishing it from the more familiar dotted decimal notation. Section 4.4.6 outlines the values associated with the first four bits of the OSPF Tag. When these bits are set to "1110," the redistributing router in BGP will exclude the prefix from redistribution.

  • In practical terms, within a network configuration, when Router B (R3) encounters an OSPF prefix with the four most significant bits set to "1110," it should interpret this as a signal not to redistribute the prefix into BGP. According to the RFC guidelines, BGP routers should treat such prefixes as candidates for direct injection into BGP. Consequently, the prefix will be redistributed into OSPF but not into BGP.

  • To address this challenge, a key strategy is to adjust the route-map configuration, ensuring that the OSPF Tag value is set to a specific value that meets the "1110" bit pattern. Achieving this often involves mathematical calculations. Given that the OSPF Tag is a 32-bit numerical value, the minimum possible representation with "11100000 00000000 00000000 00000000" or "1110" as the most significant bits is 3,758,096,384 in decimal notation and 224.0.0.0 in dotted decimal format. This particular tag value should be applied in the route-map to achieve the desired outcome.

Ospf ConvergenceOspf Incremental Spf