OSPF supports several methods to filter routes. However,
the OSPF’s internal logic restricts most filtering, requiring that the
filtering be done either on an ABR or ASBR.
This logic relies on all routers inside the area having
an identical copy of the LSDB for that area.
For interarea routes, OSPF uses distance vector logic. The
intra-area SPF calculation includes the calculation of the metric of the best
route to reach each ABR in the area. To choose the best interarea route, a
router uses distance vector logic of taking its known metric to reach the ABR
and adds the metric for that subnet as advertised by the ABR.
Filter the LSA Type 3
area (area-number) filter-list prefix (prefix-list
name) in | out
The need for the in and out parameters makes more sense
when you consider an ABR connected to at least three areas. Because packets can
be forwarded through another link
Distribute-list
For instance, if an area has 20 routers, and the engineer
wants to filter the route so that five of the routers do not learn the route,
Type 3 LSA filtering cannot be used. Type 3 LSA filtering can only filter the
LSA from being flooded throughout the entire area.
The next feature discussed in this section, referenced as filtering with distribute lists (based the configuration command it uses), allows individual routers to filter OSPF routes from getting into their respective IP routing tables. This type of filtering injects logic between the SPF algorithm on a router and that same router’s IP routing table. This feature does not change the LSDB flooding process, does not change the LSAs added by ABRs or ASBRs, and does not change the SPF algorithm’s choice of best route. However, when SPF chooses routes to add to the IP routing table, if a router has been configured with a distribute-list in OSPF router subcommand, enabling this feature, that router then filters the routes before adding them to that router’s IP routing table.
The next feature discussed in this section, referenced as filtering with distribute lists (based the configuration command it uses), allows individual routers to filter OSPF routes from getting into their respective IP routing tables. This type of filtering injects logic between the SPF algorithm on a router and that same router’s IP routing table. This feature does not change the LSDB flooding process, does not change the LSAs added by ABRs or ASBRs, and does not change the SPF algorithm’s choice of best route. However, when SPF chooses routes to add to the IP routing table, if a router has been configured with a distribute-list in OSPF router subcommand, enabling this feature, that router then filters the routes before adding them to that router’s IP routing table.
The mechanics of the distribute-list router subcommand
has a few surprises, which are summarized in this list:
·
The command
requires either an in or out direction. Only the in direction works for
filtering routes as described in
this section.
·
The command must refer to either a numbered
ACL, named ACL, prefix list, or route map. Regardless, routes matched
with a permit action are allowed into the routing table, and routes matched
with a deny action are filtered.
·
Optionally, the
command can include the interface interface-name-and-number parameters.
The router compares these parameters to the route’s outgoing interface.
Configuration of Distribute list
Router(config)# router ospf 1
distribute-list prefix-list (distribute-list)
in interface ( name and number)
Manual Summarization at ABRs
The more difficult task with OSPF route
summarization occurs when planning the design of IP address blocks and OSPF
areas. When the IP addressing plan and OSPF design have been completed, if the
subnet numbers inside an area happen to be from the same general range, and
none of the subnet in that range exist in other OSPF areas, then a reasonable summary
route can be created at the ABRs connected to that area. Without first having such
a reasonable block of addresses, route summarization may not be a useful
option.
After a range of subnets has been chosen
for summarization, the parameters in the area range command must be planned.
This command defines the parameters for the summary route, most notably the
origin area from which the subnets exist, and the subnet number/mask that
defines the summary route that should be advertised. The generic version of the
command is listed next, followed by some notes about the various parameters:
area (area-id) range (ip-address) (mask)
[cost (cost)]
1.
The configured area number refers to the area
where the subnets exist; the summary will be advertised into all other areas
connected to the ABR.
2.
The ABR compares
the summary route’s range of addresses with all intra-area OSPF routes, in the
origin area, for which the ABR is creating Type 3 LSAs. If at least one subordinate
subnet exists (subnets that sit inside the range), then the ABR advertises the
summary route as a Type 3 LSA.
3.
The ABR does not advertise the subordinate
subnet’s Type 3 LSAs.
4.
The ABR assigns a
metric for the summary route’s Type 3 LSA, by default, to match the best metric
among all subordinate subnets.
5.
The area range
command can also explicitly set the cost of the summary.
6.
If no subordinate
subnets exist, the ABR does not advertise the summary.
If you add the summary-address prefix
mask OSPF subcommand, OSPF will then attempt to summarize the external routes
by creating a Type 5 LSA for the summary route, and by no longer advertising
the Type 5 LSAs for the subordinate subnets.
ASBR
Summary-address prefix mask [not
advertised]
ABRs
Area (area-id) range ip address mask
No comments:
Post a Comment