- CCNP Route - OSPF part 1: Concept/RID/Auth/Neighbors/LSA/DBD/Cost
- CCNP Route - OSPF part 2: Filtering/summarization/stub/default route/virt link
- CCNP Route - OSPF part 3: Network type/Frame-Relay
- CCNP Route - OSPF part 4: Commands, Labs, FAQs and Memory Tables
OSPF Planning and implementing steps
- PING: check connectivity of end-to-end prefixes on Routers, using ping command,
- OSPF FULL: verify that all routers have FULL neighbor adjacencies with appropriate neighbors,
- AUTH: verify the proper auth method is active for each neighbor,
- AREA: Verify that each prefix is assigned to the appropriate OSPF area,
- RIB: Verify the appropriate routes and summaries are in RIB of each router,
- REDUNDANCY: Verify that all redundant links will be active when primary links are shut down,
- FINAL PING: Check end-to-end connectivity between final users (servers, PCs)
OSPF Route Summarization, Filtering and Default Routing
http://aconaway.com/2010/06/20/route-notes-ospf-filtering-and-summarization/
- It’s not possible to redistribute a default route via static route (or via BGP) into OSPF.
The only way to generate a default route in OSPF is with default-information originate or run stub routing.
Route filtering
used to:
- purposefully prevent hosts in one part of an internetwork from sending packets to another part.
- reduce the size of the topology table and IP routing table (reducing both OSPF memory and CPU consumption)
Route summarization can also reduce routing protocol and packet forwarding overhead, but with a potential negative effect of creating less-efficient paths through the internetwork.
OSPF routers do not advertise routes; instead, they advertise LSAs.
Inside one area, all routers must know all LSAs, or the whole SPF concept fails, and routing loops could occur.
OSPF cannot and does not allow the filtering of LSAs inside an area, specifically the Type 1 and Type 2 LSAs that describe the intra-area topology.
OSPF does allow some route filtering, however, taking advantage that OSPF uses distance vector logic with Type 3 LSAs (and the Type 5 LSAs used for external routes).
IOS limits OSPF route filtering to the following:
- Filtering Type 3 LSAs on ABRs
- Filtering Type 5 LSAs on ASBRs
- Filtering the routes OSPF would normally add to the IP routing table on a single router
Type 3 LSA filtering
ABRs, by definition, connect to the backbone area and at least one other area.
Router(config-router)# area <number> filter-list prefix <name> in| outin| out parameters define the direction relative to the area as follows:
■ When in is configured, IOS filters prefixes being created and flooded into the configured area.
■ When out is configured, IOS filters prefixes coming out of the configured area.
ip prefix-list filter-into-area-34 seq 5 deny 10.16.3.0/240.0.0.0/0 parameter matches all subnet numbers,
ip prefix-list filter-into-area-34 seq 10 permit 0.0.0.0/0 le 32
!
router ospf 1
area 34 filter-list prefix filter-into-area-34 in
le 32 parameter, combined with the original /0 prefix length, matches all prefix lengths from /0 to /32.
Although not discussed in depth here, the optional not-advertise option on the area range command tells the ABR to not advertise the Type 3 LSA for the summary route, making it possible to do the equivalent of Type 3 LSA filtering with the area range command.
R1(config-router)# area 0 range 10.16.0.0 255.255.252.0 ?Filtering OSPF Routes Added to the Routing Table
not-advertise DoNotAdvertise this range
Filtering with distribute lists - allows individual routers to filter OSPF routes from getting into their respective IP routing tables.
The distribute-list router subcommand has a few surprises, which are summarized in this list:
- The command requires either an in/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,
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.
ip prefix-list filter-1 seq 5 deny 10.16.1.0/24
ip prefix-list filter-1 seq 10 permit 0.0.0.0/0 le 32
!
router ospf 3
distribute-list prefix filter-1 in
Route Summarization
OSPF allows summarization at both ABRs and ASBRs but not on other OSPF routers.
The main reason is again that the LSDB must be the same for all routers in a single area.
OSPF summarization differs slightly on ABRs versus ASBRs.
Manual Summarization at ABRs
area <area-id> range <ip-address mask> [cost <cost>]
 |
| By summarizing - ABR (R1 and R2) advertise only one LSA Type 3 , instead of 3 (subordinate) LSA Type 3 |
R1(config)# router ospf 1Summarization rules:
R1(config-router)# area 0 range 10.16.0.0 255.255.252.0
R2(config)# router ospf 2
R2(config-router)# area 0 range 10.16.0.0 255.255.252.0 cost 12
- The configured area number - to the area where the subnets exist; the summary will be advertised into all other areas connected to the ABR.
- 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.
- The ABR does not advertise the subordinate subnet’s Type 3 LSAs.
- The ABR assigns a metric for the summary route’s Type 3 LSA, by default, to match the best metric among all subordinate subnets.
- The area range command can also explicitly set the cost of the summary.
- If no subordinate subnets exist, the ABR does not advertise the summary.
Manual Summarization at ASBRs
OSPF defines an ASBR as a router that redistributes routes into OSPF from some other routing domains (protocols).
When redistributing the routes, the ASBR creates a Type 5 External LSA for each redistributed subnet, listing the subnet number as the LSID and listing the mask as one of the fields in the LSA.
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
Router(config-router)# summary-address <prefix mask>This command works very much like the area rangecommand on ABRs, with the main exception being that the summary-addresscommand cannot explicitly set the metric of the summary route.
List of features:
- ASBR compares the summary route’s range of addresses with all routes redistributed into OSPF on that ASBR to find any subordinate subnets (subnets that sit inside the summary route range). If at least one subordinate subnet exists, the ASBR advertises the summary route.
- The ASBR does not advertise the subordinate subnets.
- To create the summary, the ASBR actually creates a Type 5 LSA for the summary route.
- The ASBR assigns the summary route the same metric as the lowest metric route amongst all subordinate subnets.
- If no subordinate subnets exist, the ASBR does not advertise the summary.
- Unlike the area rang ecommand, the summary-address command cannot be used to directly set the metric of the summary route.
ASBR summary-address{{ip-address mask} | {prefix mask}} [not-advertise]
ABR areaarea-idrangeip-address mask[advertise| not-advertise] [cost cost]
Default Routes and Stub Areas
Default Route
Enterprises typically use default routes in two different cases:
1) To direct remote-site routers all packets toward the core of the Enterprise.
2) To direct traffic on all Enterprise routers toward an Internet-facing router.
Even though you can use the summary-address and area range commands, most engineers use other methods to introduce and control default routes inside the OSPF domain. The first tool, the default-information originate OSPF subcommand, introduces a default route to be flooded throughout the OSPF domain.
default-information originate - tells OSPF to create a Type 5 LSA (used for external routes) for a default route–0.0.0.0/0–and flood it like any other Type 5 LSA, but only if the ASBR itself has a default route in its IP routing table.
default-information originate [always] [metric <metric-value>] [metric-type <type-value>] [route-map <map-name>]The list features of OSPF default-information originate:
- With all default parameters, it injects a default route into OSPF, as an External Type 2 route, using a Type 5 LSA, with metric 1, but only if a default route exists in that router’s routing table.
- With the always parameter, the default route is advertised even if there is no default route in the router’s routing table.
- The metric keyword defines the metric listed for the default route (default 1)
- The metric-type keyword defines whether the LSA is listed as external type 1 or external type 2 (default).
- The decision of when to advertise, and when to withdraw, the default route is based on matching the referenced route-map with a permit action.
Quartz#sh ip route
Gateway of last resort is 192.168.45.5 to network 0.0.0.0
...
O*E2 0.0.0.0/0 [110/555] via 192.168.45.5, 00:00:10, FastEthernet1/0
Stubby Areas
LSA types:
Type 1 | Router Link States - Represents a router (router-id) [routers in same AREA]
Type 2 | Net Link States - Represents the pseudonode (designated router) for a multiaccess link [routes in same AREA]
Type 3 | Summary Net Link States - A network link summary (internal summary route) [routes from another AREA]
Type 4 | Summary ASB Link States - Represents an ASBR [nexthop to ASBR]
Type 5 | Type-5 AS External Link States - A route external to the OSPF domain [routes from another protocol]
Type 7 | Type-7 AS External Link States - Used in stub areas in place of a type 5 LSA (external route)
- Router LSA
- Network LSA
- Network Summary LSA
- ASBR Summary LSA
- AS External LSA
- Group Membership LSA
- NSSA External LSA
- External Attributes LSA
- Opaque LSA (link-local scope)
- Opaque LSA (area-local scope)
- Opaque LSA (area-local scope)
| Тип LSA | Имя LSA | Что означает | Как посмотреть с помощью sh ip ospf database … | LSID | Кем создается |
| 1 | Router | маршрутизатор | router | RID маршрутизатора | маршрутизатором |
| 2 | Network | Подсеть с выбранным DR | network | Алрес DR в подсети | DR в этой подсети |
| 3 | Summary | Подсеть в другой области | summary | Номер подсети | ABR |
Using default routes inside an area reduces memory consumption and CPU processing time on the routers inside the area, because the routers in that area can have fewer LSAs in their LSDBs.
The list features of OSPF Stubby Areas:
- ABRs create a default route, using a Type 3 LSA, listing subnet 0.0.0.0 and mask 0.0.0.0, and flood that into the stub area.
- ABRs do not flood Type 5 LSAs into the stub area.
- ABRs may not flood other Type 3 LSAs into the area.
- The default route has a metric of 1 unless otherwise configured using the OSPF subcommand
area <area-num> default-cost <cost>- Routers inside stub areas cannot redistribute external routes into the stubby area, because that would require a Type 5 LSA in the area.
- All routers in the area must be configured to be stubby; if not, neighbor relationships cannot form between potential neighbors based on this mismatched configuration.
Four types of stubby areas exist:
1) stub (no Type5),
2) totally stubby (no Type5, no Type3),
3) NSSA - not-so-stubby areas (no Type5 + can redistribute external routes into the area),
RFCs defined a newer LSA type (Type 7) that serves the same purpose as the Type 5 LSA, but only for external routes in stubby areas
4) totally NSSA (no Type5, no Type3 + cannot redistribute external routes into the area).
Both types of totally stubby areas (totally stubby, totally NSSA) are Cisco proprietary.
The rules are:
■ For all types of stubby areas, the ABR always filters Type 5 (external) LSAs.
■ For totally stubby and totally NSSA areas, the ABR also filters Type 3 LSAs.
■ For stubby and NSSA areas–those without the word “totally” in the name–the ABRs do not filter Type 3 LSAs, advertising Type 3 LSAs as normal.
- Stubby area types that use the NSSA name can redistribute external routes into the area; stubby area types without NSSA in the name cannot.
Configure Stub Areas:
Configuration is needed on ABR and each routers from Stub Area
1) Stub
in/out Type3 - YES
in/out Type5 - NO
in Default Route (LSA Type3 with LinkID 0.0.0.0)
ABR(config-router)# area <area-id> stub2) Totally stub
OtherR(config-router)# area <area-id> stub
in/out Type3 - NO
in/out Type5 - NO
in Default Route (LSA Type3 with LinkID 0.0.0.0)
ABR(config-router)# area <area-id> stub no-summary3) NSSA
ABR(config-router)# area <area-id> default-cost <metric>
OtherR(config-router)# area <area-id> stub
in/out Type3 - YES
in Type5 - NO
out Type4, Type5 - YES (outside the Area generated by ABR, but in Area are Type7)
in Default Route - NO (could be manually inserted, LSA Type7)
ABR(config-router)# area <area-id> nssa4) Totaly NSSA
! Unlike a normal stub area, the ABR will not inject a default route into an NSSA unless explicitly configured to do so
ABR(config-router)# area <area-id> nssa default-information-originate
OtherR(config-router)# area <area-id> nssa
in/out Type3 - NO
in Type5 - NO
out Type4, Type5 - YES (outside the Area generated by ABR, but in Area are Type7)
in Default Route - NO (could be manually inserted, LSA Type7)
ABR(config-router)# area <area-id> nssa no-summary
OtherR(config-router)# area <area-id> nssa
OSPF Virtual Links and Frame Relay Operations
Virtual Links
OSPF area design requires the use of a backbone area, area 0, with each area connecting to area 0 through an ABR.
However, in some cases two backbone areas exist; in other cases, a nonbackbone area may not have a convenient point of connection to the backbone area, for example:
Problem may appear, 2 Backbone areas, no connection point to Backbone Area:
- adding new area which is not directly connected to Area0,
- a combination of link failures might result in a discontiguous backbone area, essentially creating two backbone areas,
- Two companies could merge, each using OSPF. To merge the OSPF domains, one backbone area must exist. It may be more convenient to connect the two networks using links through an existing nonbackbone area, but that design means two backbone areas, which is not allowed.
Two backbone areas now exist, and OSPF requires that the backbone area be contiguous.
An OSPF virtual link allows two ABRs that connect to the same nonbackbone area to form a neighbor relationship through that nonbackbone area, even when separated by many other routers and subnets. This virtual link acts like a virtual point-to-point connection between the two routers, with that link inside area 0.
The routers form a neighbor relationship, inside area 0, and flood LSAs over that link.
 |
| Connect to Areas with Area0 using Virtual Link |
differences:
1. ABRs send all OSPF messages as unicasts to the IP address of the router on the other end of the link.
2. The routers also mark the DoNotAge (DNA)bit in the LSAs, meaning that all routers on the other side of the virtual link will not expect the LSAs to be reflooded over the virtual link on the usual 30-minute refresh interval. (This helps reduce overhead over the virtual link)
Virtual Link Configuration
area <area-num> virtual-link <remote-RID>optional : authentication, Hello/Dead intervals
<area-num> refers to the transit area (must not be Stubby) over which the packets flow between the two routers.
RID listed in the area virtual-link command may not be pingable.
The router assigns the virtual link an OSPF cost as if it were a point-to-point link.
Configuration is needed on both sides (router C1 and C2 from image above)
show ip ospf virtual-link
show ip ospf neighbor
show ip ospf neighbor detail 4.4.4.4
Configuring Virtual Link Authentication
none (type 0)
area <num> virtual-link <router-id> authentication null
clear-text (type 1)
area <num> virtual-link <router-id> authentication authentication-key <key-value>
MD5 (type 2)
area <num> virtual-link <router-id> authentication message-digest message-digest-key <key-num> md5 <key-value>