OSPF over Broadcast Media:
==========================
router ospf 1
network 155.1.67.0 0.0.0.255 area 67
interface GigabitEthernet1.79
ip ospf 1 area 79
This task illustrates two different ways to enable the OSPF process. These include
the legacy network statement under the OSPF process and the interface-level
command ip ospf [process-id] area [area-id] . Both accomplish the same thing with
one minor exception. If an interface is IP unnumbered, and there is a network
statement that matches the IP address of the primary interface, both the primary
interface and the unnumbered interface will have OSPF enabled on them in the
designated area. Additionally, when enabled at the interface level, by default OSPF
will inject both primary and secondary subnets of the interface in the OSPF
database and advertise it to its neighbors. If you want to suppress the secondary
prefixes, use the ip ospf [process-id] area [area-id] secondaries none command.
The network statement in OSPF, just like the network statement under the EIGRP
process, is not used to originate a network advertisement. Instead it simply enables
the OSPF process on the interface. If multiple network statements overlap the same
interface, the most specific match based on the wildcard mask wins.
OSPF over DMVPN:
================
The default OSPF network types on the DMVPN interface (which is an mGRE
interface) is Point-to-Point,
The Non-Broadcast network type means that there will be a DR/BDR election, and
that hellos are exchanged as unicast. To unicast OSPF hellos, the neighbor
statement must be configured under the OSPF process of the DR. When the
DROTHERs and/or BDR hear the unicast hellos from the DR, they will automatically
respond back with their own unicast hellos. This implies that the neighbor statement
can be configured everywhere, but is only required on the DR. As within the DMVPN
cloud, OSPF packets are only between hub and spokes (not between spokes); R5
needs to be the DR. When R5 is configured with the neighbor statement, the
show ip ospf neighbor
OSPF Network Point-to-Point
========================
The Default OSPF network on Ethernet interfaces is Broadcast. OSPF network
point-to-point is the default option for point-to-point interfaces such as HDLC, PPP,
or point-to-point GRE tunnels. It uses multicast hellos, does not use the DR/BDR
election, and only supports the adjacency of exactly two neighbors on a segment.
No special design considerations need be accounted for with point-to-point OSPF
interfaces.
OSPF Network Point-to-Multipoint:
================================
√OSPF network type point-to-multipoint is specifically designed to solve reachability
problems in partially meshed NBMA network designs. Like network type point-topoint,
it sends hellos as multicasts and does not support the DR/BDR election.
Unlike point-to-point, however, multiple adjacencies on a single interface are
supported. When adjacency is established, the show ip ospf neighbor output
indicates that there is no DR or BDR for the segment with the null output in the State
field:
R5#show ip ospf neighbor tunnel0
Neighbor ID Pri State Dead Time Address Interface
150.1.4.4 0 FULL/ -
00:01:41 155.1.0.4 Tunnel0 150.1.3.3 0 FULL/ -
00:01:36 155.1.0.3 Tunnel0 150.1.2.2 0 FULL/ -
00:01:34 155.1.0.2 Tunnel0 150.1.1.1 0 FULL/ -
00:01:56 155.1.0.1 Tunnel0
For all routes that are learned from the hub of the DMVPN network, the next-hop
value has been updated to the interface IP address of the hub. With the broadcast
network type, the DR does not update the next-hop. The result of this is that when
route recursion is performed for traffic that must be routed between the spokes,
NHRP resolution needs to be performed for the hub, not for the spoke (hub NHRP
entry is statically configured on all spokes)
OSPF Network Point-to-Multipoint Non-Broadcast:
==============================================
OSPF network type point-to-multipoint non-broadcast is essentially the same as
network type point-to-multipoint, with one exception: Point-to-multipoint network type
uses multicast hellos, whereas point-to-multipoint non-broadcast uses unicast
hellos. Additionally, in non-broadcast mode, you can configure per-neighbor OSPF
cost using the command neighbor <IP_ADDRESS> cost <value> , which is helpful in huband-
spoke topology, allowing the hub to use different costs per spoke, although all
spokes are attached to the same interface from the hub perspective. Both do not
support the DR/BDR election, automatically update the next-hop value of routes
learned on partially meshed networks to the directly connected neighbor, and
advertise the network as a set of endpoints instead of a transit network. The
show ip ospf neighbor output is identical between the two network types. In this
case, we can see that the spokes are adjacent with R5, the hub, and the hub is
adjacent with the spokes. The null field under the State field indicates that no
DR/BDR election has occurred.
OSPF Network Loopback:
=====================
OSPF network type Loopback is a special case that is used for Loopback and
looped-back interfaces. Similar to point-to-multipoint, an interface running network
type Loopback is advertised as a stub endpoint instead of a transit subnet. The
result of this network type that we see in our configuration is that when the
Loopback160 interfaces of these devices are advertised into OSPF, they appear in
the routing table as /32 host routes instead of the actual subnet mask of /24.
Because network type for Loopback170 interfaces has been changed, these are
correctly advertised with their subnet mask
OSPF Path Selection with Auto-Cost:
================================
router ospf 1
auto-cost reference-bandwidth 30000
Technically, OSPF auto-cost reference-bandwidth does not need to match for
neighbors to form an adjacency. However, if different neighbors throughout
the topology calculate SPF based on conflicting cost calculations, loops can
occur. For this reason, it is always recommended to set the auto-cost value
consistently throughout the entire OSPF domain
Interface Cost = Reference Bandwidth / Interface Bandwidth
Discontiguous OSPF Areas with Virtual-Links
=============================
area 1
area0 R1---R4---R6 area 3
R1:
router ospf 1
area 1 virtual-link 150.1.6.6
R6:
router ospf 1
area 1 virtual-link 150.1.1.1
OSPF Demand Circuit:
==================
interface GigabitEthernet1.79
ip ospf demand-circuit
Per RFC 1793, Extending OSPF to Support Demand Circuits, “OSPF Hellos and the
refresh of OSPF routing information are suppressed on demand circuits, allowing
the underlying data-link connections to be closed when not carrying application
traffic.” This feature allows low-speed and pay-per-use links, such as analog dial
and ISDN, to run OSPF without the need for periodic hellos and LSA flooding.
Periodic hellos are only suppressed for point-to-point and point-to-multipoint OSPF
network types. This feature is enabled with the interface-level command ip ospf
demand-circuit and is negotiated as part of the neighbor adjacency establishment,
thus only one OSPF router on the segment requires that the feature be enabled. If
routers on the segment do not support it, it will just ignore the option in the HELLO
packet, but OSPF neighbors will still be established. Note the difference before and
after the feature is enabled, for example on R7.
Clear Text Authentication:
========================
interface GigabitEthernet1.37
ip ospf authentication
ip ospf authentication-key CLEARKEY
OSPFv2 supports three types of authentication as defined in RFC 2328: type 0, or
null authentication (no authentication), type 1, or clear text authentication, and type
2, or Keyed-MD5 authentication. As we'll see in following labs, type 2 also support
HMAC-SHA authentication. The type of authentication can be configured at the
interface level with the ip ospf authentication command or at the process level with
the area [id] authentication command. The only difference between these
commands is whether authentication is enabled on all interfaces in the area at the
same time or on a per-link basis. In either case, the password must still be
configured at the interface level with the ip ospf authentication-key or ip ospf
message-digest-key commands.
A failure in authentication can occur for two reasons: a mismatch in
authentication type or a mismatch involving the authentication key. An
authentication type mismatch occurs when one neighbor is configured with
clear text while the other is running MD5, or one is running MD5 and the
other is running null, etc. A key mismatch is simply when the routers are
using different passwords. Failure in authentication type can be verified as
follows:
R9#debug ip ospf adj
OSPF adjacency debugging is on
!R9#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.R9(config)#interface gigabitEthernet1.79
R9(config-subif)#ip ospf authentication message-digest
!
! OSPF-1 ADJ Gi1.79: Rcv pkt from 155.1.79.7 :
Mismatched Authentication type. Input packet specified type 1, we use type 2
OSPF-1 ADJ Gi1.79: Rcv pkt from 155.1.79.7 :
Mismatched Authentication type. Input packet specified type 1, we use type 2
OSPF MD5 Authentication:
=====================
router ospf 1
area 3 authentication message-digest
!
interface GigabitEthernet1.58
ip ospf message-digest-key 1 md5 MD5KEY
Remember that a virtual-link is an interface in area 0. This means that if the
area 0 authentication [message-digest] command is enabled, authentication is
also enabled on the virtual-link. If MD5 authentication is enabled on the
virtual-link with the area 0 authentication message-digest command, the
password must still be assigned on the virtual-link interface itself with the
area <NR> virtual-link <RID> message-digest-key <NR> md5 <STRING> command.
Alternatively, authentication can be enabled at the virtual-link interface level
with the area <NR> virtual-link <RID> authentication message-digest command,
and the key is applied with the area <NR> virtual-link <RID> message-digest-key
<NR> md5 <STRING> command. In some versions, these two commands are
combined automatically in the running config to the single statement
area <NR> virtual-link <RID> authentication message-digest message-digest-key
<NR> md5 <STRING> , but the result of either syntax is the same. After
authentication is enabled on the virtual-link, make sure to issue the clear ip
ospf process command, because the virtual-link does not support periodic
hellos. This means that if the authentication is wrong the virtual-link interface
will not immediately go down, but if there is a change in the topology it won’t
actually be propagated across the virtual-link.
OSPF Null Authentication:
=======================
router ospf 1
area 2 authentication
!
interface GigabitEthernet1.79
ip ospf authentication-key PASSWORD
!
interface GigabitEthernet1.37
ip ospf authentication null
Type 0 authentication or Null authentication means that basically authentication is
disabled, which is the default on all OSPF enabled interface. The use case for this
authentication type is when for example you have globally configured clear-text or
MD5/SHA authentication for one OSPF area, but want one or multiple interfaces in
that area to actually use no authentication. Because the interface level configuration
overrides the area level configuration, interfaces for which ip ospf authentication
null is configured will require no OSPF authentication.
OSPF Internal Summarization:
===========================
router ospf 1
area 3 range 155.1.8.0 255.255.252.0
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. The below configuration
illustrates how an Intra-Area Summary Network LSA (LSA 3) can be summarized as
it is originated by an ABR.
Without any modification, R1 sees two separate routes and LSAs to reach the
networks 155.1.8.0/24 and 155.1.10.0/24. Because they are both originated by R5
(150.1.5.5), it implies that only R5 can modify R1’s view of these. By configuring the
area 3 range 155.1.8.0 255.255.252.0 command, R5 stops sending the specific LSAs
from area 3 into area 0 and groups them into the single route 155.1.8.0/22. Verify
the outputs on R1 before configuration changes:
OSPF External Summarization:
===========================
R9#
route-map CONNECTED->OSPF permit 10
match interface Loopback100 Loopback200
!
router ospf 1
redistribute connected metric 50 subnets route-map CONNECTED->OSPF
summary-address 160.1.9.0 255.255.255.0
External OSPF summarization is configured at the redistribution point between
routing domains with the summary-address command. These summaries inherit their
attributes from the subnets that make them up. For example, a summary comprised
of External Type-1 routes will result in an External Type-1 summary. This means
that on R10 in this configuration, the metric-type 1 command is set at the time of
redistribution instead of on the summary itself. External Type-2 OSPF routes, which
are the default, do not install the end-to-end metric in the routing table. Instead, only
the metric that was reported via the ASBR is installed. The actual routing path is
determined by the addition of the reported metric and the metric toward the ASBR,
which is called the forward metric:
Verify that redisstributed prefixes are summarized with correct metric and metrictype,
and routers in the OSPF domain have IP reachability with the redistributed
prefixes
Let's identify how the metric is computed for both external route types, starting with
E2, from R5's perspective. Being a E2 route, the metric showing up in the routing
table is the one which was set by the ASBR at redistribution
R5#show ip ospf database external 160.1.9.0
OSPF Router with ID (150.1.5.5) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 625
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link Link State ID: 160.1.9.0 (External Network Number )
Advertising Router: 150.1.9.9
LS Seq Number: 80000001
Checksum: 0xB479
Length: 36 Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0 Metric: 50
Forward Address: 0.0.0.0
!R5#show ip route 160.1.9.0
Routing entry for 160.1.9.0/24 Known via "ospf 1", distance 110,
metric 50, type extern 2, forward metric 1002
In the above output, R5 sees the summary 160.1.9.0/24 as an External Type-2 route
originated by the ASBR 150.1.9.9.The Forward Address: 0.0.0.0 field means that
R5 must now compute the metric toward the advertising router, R9, and install this
metric in the routing table as the forward metric. Specifically, this is calculated as
follows: first, R5 needs to identify the metric towards the ABR generating the Type4
LSA, which in this case is R3 (because is the router with links in the same area as
the ASBR, R9, and links in the same area as R5). The cost to reach R3 is 1000:
R5#show ip ospf database router adv-router 150.1.5.5
|
|
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 150.1.3.3
(Link Data) Router Interface address: 155.1.0.5
Number of MTID metrics: 0 TOS 0 Metrics: 1000
Next, the metric to reach the ASBR is signaled through a Type4 LSA, generated by
R3, thus R5 needs to know the cost from this LSA and add it to the cost to reach R3
in order to compute the forwarding metric of 1002. The routing table output for the
specific routing lookup should now show a metric of 50 to the destination, but a
forward metric of 1002 toward the ASBR. This forward metric is used to determine
the path toward the exit point:
R5#show ip ospf database asbr-summary adv-router 150.1.3.3
OSPF Router with ID (150.1.5.5) (Process ID 1)
Summary ASB Link States (Area 0)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1089
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router) Link State ID: 150.1.9.9 (AS Boundary Router address)
Advertising Router: 150.1.3.3
LS Seq Number: 80000002
Checksum: 0xA34E
Length: 28
Network Mask: /0 MTID: 0 Metric: 2
!
!R5#show ip ospf border-routers
OSPF Router with ID (150.1.5.5) (Process ID 1)
Base Topology (MTID 0)
Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 150.1.1.1 [1000] via 155.1.0.1, Tunnel0, ABR, Area 0, SPF 1840
i 150.1.10.10 [2] via 155.1.58.8, GigabitEthernet1.58, ASBR, Area 3, SPF 28
i 150.1.2.2 [1000] via 155.1.0.2, Tunnel0, ABR, Area 0, SPF 1840
i 150.1.3.3 [1000] via 155.1.0.3, Tunnel0, ABR, Area 0, SPF 1840
i 150.1.4.4 [1] via 155.1.45.4, GigabitEthernet1.45, ABR, Area 0, SPF 1840
I 150.1.9.9 [1002] via 155.1.0.3
, Tunnel0, ASBR, Area 0, SPF 1840
!
!R5#show ip route 160.1.9.0
Routing entry for 160.1.9.0/24 Known via "ospf 1", distance 110, metric 50, type extern 2,
forward metric 1002
Last update from 155.1.0.3 on Tunnel0, 00:51:02 ago
Routing Descriptor Blocks:
* 155.1.0.3, from 150.1.9.9, 00:51:02 ago, via Tunnel0
Route metric is 50, traffic share count is 1
!
OSPF Stub Areas:
===============
OSPF stub area types are used to filter information out of the OSPF database
based on LSA Type. The stub flag is part of the OSPF adjacency formation, which
implies that all devices in an area must agree on that parameter for adjacencies to
establish. The four stub types that IOS supports are stub areas, totally stubby areas,
not-so-stubby areas (NSSA), and not-so-totally-stubby areas. The first option, the
stub area, is used to remove Type-5 External link states from the database and
replace them with a default route. The logic behind this feature stems from how
external lookups between areas occur in OSPF.
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. For
example, examine the following situation in this topology. R4 redistributes the
directly connected route 160.1.4.4/32 into OSPF, originating a Type-5 External LSA:
R4#show ip ospf database external 160.1.4.4
OSPF Router with ID (150.1.4.4) (Process ID 1)
Type-5 AS External Link States
LS age: 36
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 160.1.4.4 (External Network Number ) Advertising Router: 150.1.4.4
LS Seq Number: 80000001
Checksum: 0xD77F
Length: 36 Network Mask: /32
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20 Forward Address: 0.0.0.0
External Route Tag: 0
When R5 wants to reach the destination 160.1.4.4/32, it sees that the forward
address is 0.0.0.0 and the advertising router is 150.1.4.4. R5 now does a Type-1
Router LSA lookup on 150.1.4.4 (R4):
OSPF LSA Type-3 Filtering:
=======================
ip prefix-list AREA_3_ROUTES deny 150.1.10.10/32
ip prefix-list AREA_3_ROUTES deny 155.1.108.0/24
ip prefix-list AREA_3_ROUTES permit 0.0.0.0/0 le 32
!
router ospf 1
area 3 filter-list prefix AREA_3_ROUTES out
OSPF Forwarding Address Suppression:
===================================
ip prefix-list AREA_3_ROUTES permit 0.0.0.0/0 le 32
!
router ospf 1
area 3 filter-list prefix AREA_3_ROUTES out
area 3 nssa translate type7 suppress-fa
Recall that with OSPF database lookups on external routes, the Forward Address
field determines who the next recursive lookup should be performed toward. With
typical Type-5 External LSAs, such as R4's Loopback100 redistributes into OSPF,
the forward address is normally set to 0.0.0.0. This means that the next lookup
should be performed toward the Advertising Router
OSPF Default Routing:
====================
router ospf 1
default-information originate always metric 40 metric-type 1
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.
For example, imagine an OSPF network with exit points A and B out to the Internet.
Both router A and B are running BGP with upstream peers, and learning a default
route via BGP. As long as both devices maintain their upstream peerings, a default
route can be advertised into OSPF. However, if A’s link to the upstream neighbor is
lost, and hence its default route via BGP is lost, its OSPF default route
advertisement is withdrawn. The result of this design is that an individual exit point
will only collect default traffic if they themselves have a default exit point 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 below view of the OSPF database on R1 indicates that both R4 and R6 are
originating a default route. Without additional arguments on the command, the
default route would have been advertised as a Type-2 External route with a metric
of 20. The same route lookup logic is applied to these default routes as normal Type-
5 External LSAs, where E1 is preferred over E2, and if multiple E2 routes exist with
the same metric, the forward metrics are compare
OSPF Conditional Default Routing:
================================
ip prefix-list LOOPBACK66 seq 5 permit 66.66.66.66/32
!
route-map TRACK_LOOPBACK66 permit 10
match ip address prefix-list LOOPBACK66
!
router ospf 1
default-information originate route-map TRACK_LOOPBACK66
OSPF Reliable Conditional Default Routing:
=========================================
ip sla 1
icmp-echo 155.1.108.10
frequency 5
!
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 state
!
ip route 169.254.0.1 255.255.255.255 Null0 track 1
ip prefix-list PLACEHOLDER seq 5 permit 169.254.0.1/32
!
route-map TRACK_PLACEHOLDER permit 10
match ip address prefix-list PLACEHOLDER
!
router ospf 1
default-information originate route-map TRACK_PLACEHOLDER
OSPF Filtering with Distribute-Lists:
======================================
Configure distribute-list filtering on R5, R8, and R10 so that these devices do not
install routes to the Loopback0 networks of R1 and R2.
router ospf 1
distribute-list 1 in
!
access-list 1 deny 150.1.1.1 0.0.0.0
access-list 1 deny 150.1.2.2 0.0.0.0
access-list 1 permit any
Recall that to properly compute SPF, all routers within an OSPF area must agree on
their view of the database. This implies that 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. 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.
Before applying distribute-list:
R5#show ip route ospf | i 150.1.
150.1.0.0/32 is subnetted, 10 subnets
O 150.1.1.1 [110/1001] via 155.1.0.1, 00:50:45, Tunnel0
O IA 150.1.2.2 [110/1001] via 155.1.0.2, 00:50:45, Tunnel0
When the distribute-list has been applied on R5, the routes 150.1.2.2/32 and
150.1.1.1/32 no longer appear in the routing table:
R5#show ip route ospf | i 150.1.
150.1.0.0/32 is subnetted, 8 subnets
O 150.1.3.3 [110/1001] via 155.1.0.3, 00:00:03, Tunnel0
O 150.1.4.4 [110/2] via 155.1.45.4, 00:00:03, GigabitEthernet1.45
O IA 150.1.6.6 [110/3] via 155.1.45.4, 00:00:03, GigabitEthernet1.45
O IA 150.1.7.7 [110/1002] via 155.1.0.3, 00:00:03, Tunnel0
OSPF Summarization and Discard Routes:
=====================================
router ospf 1
no discard-route internal
area 2 range 150.1.0.0 255.255.240.0
When summarization is configured in OSPF, similar to EIGRP and BGP, a matching
route to Null0 for the summary is installed locally in the routing table. This “discard”
route is used to prevent the forwarding of traffic toward a shorter match, such as a
default route, if no specific route toward the actual destination exists in the network.
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. The operation of
the discard route can be illustrated as follows. R3 and R5 have the prefixes
150.1.7.7/32 and 150.1.9.9/32 filtered out of the routing table with a distribute-list.
Additionally, R3 is originating the summary 150.1.0.0/20 into area 0, which
encompasses addresses 150.1.0.0 through 150.1.15.255
OSPF Filtering with Administrative Distance:
===========================================
access-list 10 permit 155.1.146.0
!
router ospf 1
distance 255 150.1.5.5 0.0.0.0 10
OSPF Filtering with Route-Maps:
============================
access-list 3 permit 155.1.146.0
access-list 4 permit 155.1.0.4
!
route-map DENY_VLAN146_FROM_R4 deny 10
match ip address 3
match ip next-hop 4
!
route-map DENY_VLAN146_FROM_R4 permit 20
!
router ospf 1
distribute-list route-map DENY_VLAN146_FROM_R4 in
OSPF NSSA ABR External Prefix Filtering:
======================================
router ospf 1
summary-address 160.1.10.10 255.255.255.255 not-advertise
==========================
router ospf 1
network 155.1.67.0 0.0.0.255 area 67
interface GigabitEthernet1.79
ip ospf 1 area 79
This task illustrates two different ways to enable the OSPF process. These include
the legacy network statement under the OSPF process and the interface-level
command ip ospf [process-id] area [area-id] . Both accomplish the same thing with
one minor exception. If an interface is IP unnumbered, and there is a network
statement that matches the IP address of the primary interface, both the primary
interface and the unnumbered interface will have OSPF enabled on them in the
designated area. Additionally, when enabled at the interface level, by default OSPF
will inject both primary and secondary subnets of the interface in the OSPF
database and advertise it to its neighbors. If you want to suppress the secondary
prefixes, use the ip ospf [process-id] area [area-id] secondaries none command.
The network statement in OSPF, just like the network statement under the EIGRP
process, is not used to originate a network advertisement. Instead it simply enables
the OSPF process on the interface. If multiple network statements overlap the same
interface, the most specific match based on the wildcard mask wins.
OSPF over DMVPN:
================
The default OSPF network types on the DMVPN interface (which is an mGRE
interface) is Point-to-Point,
The Non-Broadcast network type means that there will be a DR/BDR election, and
that hellos are exchanged as unicast. To unicast OSPF hellos, the neighbor
statement must be configured under the OSPF process of the DR. When the
DROTHERs and/or BDR hear the unicast hellos from the DR, they will automatically
respond back with their own unicast hellos. This implies that the neighbor statement
can be configured everywhere, but is only required on the DR. As within the DMVPN
cloud, OSPF packets are only between hub and spokes (not between spokes); R5
needs to be the DR. When R5 is configured with the neighbor statement, the
show ip ospf neighbor
OSPF Network Point-to-Point
========================
The Default OSPF network on Ethernet interfaces is Broadcast. OSPF network
point-to-point is the default option for point-to-point interfaces such as HDLC, PPP,
or point-to-point GRE tunnels. It uses multicast hellos, does not use the DR/BDR
election, and only supports the adjacency of exactly two neighbors on a segment.
No special design considerations need be accounted for with point-to-point OSPF
interfaces.
OSPF Network Point-to-Multipoint:
================================
√OSPF network type point-to-multipoint is specifically designed to solve reachability
problems in partially meshed NBMA network designs. Like network type point-topoint,
it sends hellos as multicasts and does not support the DR/BDR election.
Unlike point-to-point, however, multiple adjacencies on a single interface are
supported. When adjacency is established, the show ip ospf neighbor output
indicates that there is no DR or BDR for the segment with the null output in the State
field:
R5#show ip ospf neighbor tunnel0
Neighbor ID Pri State Dead Time Address Interface
150.1.4.4 0 FULL/ -
00:01:41 155.1.0.4 Tunnel0 150.1.3.3 0 FULL/ -
00:01:36 155.1.0.3 Tunnel0 150.1.2.2 0 FULL/ -
00:01:34 155.1.0.2 Tunnel0 150.1.1.1 0 FULL/ -
00:01:56 155.1.0.1 Tunnel0
For all routes that are learned from the hub of the DMVPN network, the next-hop
value has been updated to the interface IP address of the hub. With the broadcast
network type, the DR does not update the next-hop. The result of this is that when
route recursion is performed for traffic that must be routed between the spokes,
NHRP resolution needs to be performed for the hub, not for the spoke (hub NHRP
entry is statically configured on all spokes)
OSPF Network Point-to-Multipoint Non-Broadcast:
==============================================
OSPF network type point-to-multipoint non-broadcast is essentially the same as
network type point-to-multipoint, with one exception: Point-to-multipoint network type
uses multicast hellos, whereas point-to-multipoint non-broadcast uses unicast
hellos. Additionally, in non-broadcast mode, you can configure per-neighbor OSPF
cost using the command neighbor <IP_ADDRESS> cost <value> , which is helpful in huband-
spoke topology, allowing the hub to use different costs per spoke, although all
spokes are attached to the same interface from the hub perspective. Both do not
support the DR/BDR election, automatically update the next-hop value of routes
learned on partially meshed networks to the directly connected neighbor, and
advertise the network as a set of endpoints instead of a transit network. The
show ip ospf neighbor output is identical between the two network types. In this
case, we can see that the spokes are adjacent with R5, the hub, and the hub is
adjacent with the spokes. The null field under the State field indicates that no
DR/BDR election has occurred.
OSPF Network Loopback:
=====================
OSPF network type Loopback is a special case that is used for Loopback and
looped-back interfaces. Similar to point-to-multipoint, an interface running network
type Loopback is advertised as a stub endpoint instead of a transit subnet. The
result of this network type that we see in our configuration is that when the
Loopback160 interfaces of these devices are advertised into OSPF, they appear in
the routing table as /32 host routes instead of the actual subnet mask of /24.
Because network type for Loopback170 interfaces has been changed, these are
correctly advertised with their subnet mask
OSPF Path Selection with Auto-Cost:
================================
router ospf 1
auto-cost reference-bandwidth 30000
Technically, OSPF auto-cost reference-bandwidth does not need to match for
neighbors to form an adjacency. However, if different neighbors throughout
the topology calculate SPF based on conflicting cost calculations, loops can
occur. For this reason, it is always recommended to set the auto-cost value
consistently throughout the entire OSPF domain
Interface Cost = Reference Bandwidth / Interface Bandwidth
Discontiguous OSPF Areas with Virtual-Links
=============================
area 1
area0 R1---R4---R6 area 3
R1:
router ospf 1
area 1 virtual-link 150.1.6.6
R6:
router ospf 1
area 1 virtual-link 150.1.1.1
OSPF Demand Circuit:
==================
interface GigabitEthernet1.79
ip ospf demand-circuit
Per RFC 1793, Extending OSPF to Support Demand Circuits, “OSPF Hellos and the
refresh of OSPF routing information are suppressed on demand circuits, allowing
the underlying data-link connections to be closed when not carrying application
traffic.” This feature allows low-speed and pay-per-use links, such as analog dial
and ISDN, to run OSPF without the need for periodic hellos and LSA flooding.
Periodic hellos are only suppressed for point-to-point and point-to-multipoint OSPF
network types. This feature is enabled with the interface-level command ip ospf
demand-circuit and is negotiated as part of the neighbor adjacency establishment,
thus only one OSPF router on the segment requires that the feature be enabled. If
routers on the segment do not support it, it will just ignore the option in the HELLO
packet, but OSPF neighbors will still be established. Note the difference before and
after the feature is enabled, for example on R7.
Clear Text Authentication:
========================
interface GigabitEthernet1.37
ip ospf authentication
ip ospf authentication-key CLEARKEY
OSPFv2 supports three types of authentication as defined in RFC 2328: type 0, or
null authentication (no authentication), type 1, or clear text authentication, and type
2, or Keyed-MD5 authentication. As we'll see in following labs, type 2 also support
HMAC-SHA authentication. The type of authentication can be configured at the
interface level with the ip ospf authentication command or at the process level with
the area [id] authentication command. The only difference between these
commands is whether authentication is enabled on all interfaces in the area at the
same time or on a per-link basis. In either case, the password must still be
configured at the interface level with the ip ospf authentication-key or ip ospf
message-digest-key commands.
A failure in authentication can occur for two reasons: a mismatch in
authentication type or a mismatch involving the authentication key. An
authentication type mismatch occurs when one neighbor is configured with
clear text while the other is running MD5, or one is running MD5 and the
other is running null, etc. A key mismatch is simply when the routers are
using different passwords. Failure in authentication type can be verified as
follows:
R9#debug ip ospf adj
OSPF adjacency debugging is on
!R9#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.R9(config)#interface gigabitEthernet1.79
R9(config-subif)#ip ospf authentication message-digest
!
! OSPF-1 ADJ Gi1.79: Rcv pkt from 155.1.79.7 :
Mismatched Authentication type. Input packet specified type 1, we use type 2
OSPF-1 ADJ Gi1.79: Rcv pkt from 155.1.79.7 :
Mismatched Authentication type. Input packet specified type 1, we use type 2
OSPF MD5 Authentication:
=====================
router ospf 1
area 3 authentication message-digest
!
interface GigabitEthernet1.58
ip ospf message-digest-key 1 md5 MD5KEY
Remember that a virtual-link is an interface in area 0. This means that if the
area 0 authentication [message-digest] command is enabled, authentication is
also enabled on the virtual-link. If MD5 authentication is enabled on the
virtual-link with the area 0 authentication message-digest command, the
password must still be assigned on the virtual-link interface itself with the
area <NR> virtual-link <RID> message-digest-key <NR> md5 <STRING> command.
Alternatively, authentication can be enabled at the virtual-link interface level
with the area <NR> virtual-link <RID> authentication message-digest command,
and the key is applied with the area <NR> virtual-link <RID> message-digest-key
<NR> md5 <STRING> command. In some versions, these two commands are
combined automatically in the running config to the single statement
area <NR> virtual-link <RID> authentication message-digest message-digest-key
<NR> md5 <STRING> , but the result of either syntax is the same. After
authentication is enabled on the virtual-link, make sure to issue the clear ip
ospf process command, because the virtual-link does not support periodic
hellos. This means that if the authentication is wrong the virtual-link interface
will not immediately go down, but if there is a change in the topology it won’t
actually be propagated across the virtual-link.
OSPF Null Authentication:
=======================
router ospf 1
area 2 authentication
!
interface GigabitEthernet1.79
ip ospf authentication-key PASSWORD
!
interface GigabitEthernet1.37
ip ospf authentication null
Type 0 authentication or Null authentication means that basically authentication is
disabled, which is the default on all OSPF enabled interface. The use case for this
authentication type is when for example you have globally configured clear-text or
MD5/SHA authentication for one OSPF area, but want one or multiple interfaces in
that area to actually use no authentication. Because the interface level configuration
overrides the area level configuration, interfaces for which ip ospf authentication
null is configured will require no OSPF authentication.
OSPF Internal Summarization:
===========================
router ospf 1
area 3 range 155.1.8.0 255.255.252.0
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. The below configuration
illustrates how an Intra-Area Summary Network LSA (LSA 3) can be summarized as
it is originated by an ABR.
Without any modification, R1 sees two separate routes and LSAs to reach the
networks 155.1.8.0/24 and 155.1.10.0/24. Because they are both originated by R5
(150.1.5.5), it implies that only R5 can modify R1’s view of these. By configuring the
area 3 range 155.1.8.0 255.255.252.0 command, R5 stops sending the specific LSAs
from area 3 into area 0 and groups them into the single route 155.1.8.0/22. Verify
the outputs on R1 before configuration changes:
OSPF External Summarization:
===========================
R9#
route-map CONNECTED->OSPF permit 10
match interface Loopback100 Loopback200
!
router ospf 1
redistribute connected metric 50 subnets route-map CONNECTED->OSPF
summary-address 160.1.9.0 255.255.255.0
External OSPF summarization is configured at the redistribution point between
routing domains with the summary-address command. These summaries inherit their
attributes from the subnets that make them up. For example, a summary comprised
of External Type-1 routes will result in an External Type-1 summary. This means
that on R10 in this configuration, the metric-type 1 command is set at the time of
redistribution instead of on the summary itself. External Type-2 OSPF routes, which
are the default, do not install the end-to-end metric in the routing table. Instead, only
the metric that was reported via the ASBR is installed. The actual routing path is
determined by the addition of the reported metric and the metric toward the ASBR,
which is called the forward metric:
Verify that redisstributed prefixes are summarized with correct metric and metrictype,
and routers in the OSPF domain have IP reachability with the redistributed
prefixes
Let's identify how the metric is computed for both external route types, starting with
E2, from R5's perspective. Being a E2 route, the metric showing up in the routing
table is the one which was set by the ASBR at redistribution
R5#show ip ospf database external 160.1.9.0
OSPF Router with ID (150.1.5.5) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 625
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link Link State ID: 160.1.9.0 (External Network Number )
Advertising Router: 150.1.9.9
LS Seq Number: 80000001
Checksum: 0xB479
Length: 36 Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0 Metric: 50
Forward Address: 0.0.0.0
!R5#show ip route 160.1.9.0
Routing entry for 160.1.9.0/24 Known via "ospf 1", distance 110,
metric 50, type extern 2, forward metric 1002
In the above output, R5 sees the summary 160.1.9.0/24 as an External Type-2 route
originated by the ASBR 150.1.9.9.The Forward Address: 0.0.0.0 field means that
R5 must now compute the metric toward the advertising router, R9, and install this
metric in the routing table as the forward metric. Specifically, this is calculated as
follows: first, R5 needs to identify the metric towards the ABR generating the Type4
LSA, which in this case is R3 (because is the router with links in the same area as
the ASBR, R9, and links in the same area as R5). The cost to reach R3 is 1000:
R5#show ip ospf database router adv-router 150.1.5.5
|
|
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 150.1.3.3
(Link Data) Router Interface address: 155.1.0.5
Number of MTID metrics: 0 TOS 0 Metrics: 1000
Next, the metric to reach the ASBR is signaled through a Type4 LSA, generated by
R3, thus R5 needs to know the cost from this LSA and add it to the cost to reach R3
in order to compute the forwarding metric of 1002. The routing table output for the
specific routing lookup should now show a metric of 50 to the destination, but a
forward metric of 1002 toward the ASBR. This forward metric is used to determine
the path toward the exit point:
R5#show ip ospf database asbr-summary adv-router 150.1.3.3
OSPF Router with ID (150.1.5.5) (Process ID 1)
Summary ASB Link States (Area 0)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1089
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(AS Boundary Router) Link State ID: 150.1.9.9 (AS Boundary Router address)
Advertising Router: 150.1.3.3
LS Seq Number: 80000002
Checksum: 0xA34E
Length: 28
Network Mask: /0 MTID: 0 Metric: 2
!
!R5#show ip ospf border-routers
OSPF Router with ID (150.1.5.5) (Process ID 1)
Base Topology (MTID 0)
Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 150.1.1.1 [1000] via 155.1.0.1, Tunnel0, ABR, Area 0, SPF 1840
i 150.1.10.10 [2] via 155.1.58.8, GigabitEthernet1.58, ASBR, Area 3, SPF 28
i 150.1.2.2 [1000] via 155.1.0.2, Tunnel0, ABR, Area 0, SPF 1840
i 150.1.3.3 [1000] via 155.1.0.3, Tunnel0, ABR, Area 0, SPF 1840
i 150.1.4.4 [1] via 155.1.45.4, GigabitEthernet1.45, ABR, Area 0, SPF 1840
I 150.1.9.9 [1002] via 155.1.0.3
, Tunnel0, ASBR, Area 0, SPF 1840
!
!R5#show ip route 160.1.9.0
Routing entry for 160.1.9.0/24 Known via "ospf 1", distance 110, metric 50, type extern 2,
forward metric 1002
Last update from 155.1.0.3 on Tunnel0, 00:51:02 ago
Routing Descriptor Blocks:
* 155.1.0.3, from 150.1.9.9, 00:51:02 ago, via Tunnel0
Route metric is 50, traffic share count is 1
!
OSPF Stub Areas:
===============
OSPF stub area types are used to filter information out of the OSPF database
based on LSA Type. The stub flag is part of the OSPF adjacency formation, which
implies that all devices in an area must agree on that parameter for adjacencies to
establish. The four stub types that IOS supports are stub areas, totally stubby areas,
not-so-stubby areas (NSSA), and not-so-totally-stubby areas. The first option, the
stub area, is used to remove Type-5 External link states from the database and
replace them with a default route. The logic behind this feature stems from how
external lookups between areas occur in OSPF.
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. For
example, examine the following situation in this topology. R4 redistributes the
directly connected route 160.1.4.4/32 into OSPF, originating a Type-5 External LSA:
R4#show ip ospf database external 160.1.4.4
OSPF Router with ID (150.1.4.4) (Process ID 1)
Type-5 AS External Link States
LS age: 36
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 160.1.4.4 (External Network Number ) Advertising Router: 150.1.4.4
LS Seq Number: 80000001
Checksum: 0xD77F
Length: 36 Network Mask: /32
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20 Forward Address: 0.0.0.0
External Route Tag: 0
When R5 wants to reach the destination 160.1.4.4/32, it sees that the forward
address is 0.0.0.0 and the advertising router is 150.1.4.4. R5 now does a Type-1
Router LSA lookup on 150.1.4.4 (R4):
OSPF LSA Type-3 Filtering:
=======================
ip prefix-list AREA_3_ROUTES deny 150.1.10.10/32
ip prefix-list AREA_3_ROUTES deny 155.1.108.0/24
ip prefix-list AREA_3_ROUTES permit 0.0.0.0/0 le 32
!
router ospf 1
area 3 filter-list prefix AREA_3_ROUTES out
OSPF Forwarding Address Suppression:
===================================
ip prefix-list AREA_3_ROUTES permit 0.0.0.0/0 le 32
!
router ospf 1
area 3 filter-list prefix AREA_3_ROUTES out
area 3 nssa translate type7 suppress-fa
Recall that with OSPF database lookups on external routes, the Forward Address
field determines who the next recursive lookup should be performed toward. With
typical Type-5 External LSAs, such as R4's Loopback100 redistributes into OSPF,
the forward address is normally set to 0.0.0.0. This means that the next lookup
should be performed toward the Advertising Router
OSPF Default Routing:
====================
router ospf 1
default-information originate always metric 40 metric-type 1
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.
For example, imagine an OSPF network with exit points A and B out to the Internet.
Both router A and B are running BGP with upstream peers, and learning a default
route via BGP. As long as both devices maintain their upstream peerings, a default
route can be advertised into OSPF. However, if A’s link to the upstream neighbor is
lost, and hence its default route via BGP is lost, its OSPF default route
advertisement is withdrawn. The result of this design is that an individual exit point
will only collect default traffic if they themselves have a default exit point 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 below view of the OSPF database on R1 indicates that both R4 and R6 are
originating a default route. Without additional arguments on the command, the
default route would have been advertised as a Type-2 External route with a metric
of 20. The same route lookup logic is applied to these default routes as normal Type-
5 External LSAs, where E1 is preferred over E2, and if multiple E2 routes exist with
the same metric, the forward metrics are compare
OSPF Conditional Default Routing:
================================
ip prefix-list LOOPBACK66 seq 5 permit 66.66.66.66/32
!
route-map TRACK_LOOPBACK66 permit 10
match ip address prefix-list LOOPBACK66
!
router ospf 1
default-information originate route-map TRACK_LOOPBACK66
OSPF Reliable Conditional Default Routing:
=========================================
ip sla 1
icmp-echo 155.1.108.10
frequency 5
!
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 state
!
ip route 169.254.0.1 255.255.255.255 Null0 track 1
ip prefix-list PLACEHOLDER seq 5 permit 169.254.0.1/32
!
route-map TRACK_PLACEHOLDER permit 10
match ip address prefix-list PLACEHOLDER
!
router ospf 1
default-information originate route-map TRACK_PLACEHOLDER
OSPF Filtering with Distribute-Lists:
======================================
Configure distribute-list filtering on R5, R8, and R10 so that these devices do not
install routes to the Loopback0 networks of R1 and R2.
router ospf 1
distribute-list 1 in
!
access-list 1 deny 150.1.1.1 0.0.0.0
access-list 1 deny 150.1.2.2 0.0.0.0
access-list 1 permit any
Recall that to properly compute SPF, all routers within an OSPF area must agree on
their view of the database. This implies that 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. 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.
Before applying distribute-list:
R5#show ip route ospf | i 150.1.
150.1.0.0/32 is subnetted, 10 subnets
O 150.1.1.1 [110/1001] via 155.1.0.1, 00:50:45, Tunnel0
O IA 150.1.2.2 [110/1001] via 155.1.0.2, 00:50:45, Tunnel0
When the distribute-list has been applied on R5, the routes 150.1.2.2/32 and
150.1.1.1/32 no longer appear in the routing table:
R5#show ip route ospf | i 150.1.
150.1.0.0/32 is subnetted, 8 subnets
O 150.1.3.3 [110/1001] via 155.1.0.3, 00:00:03, Tunnel0
O 150.1.4.4 [110/2] via 155.1.45.4, 00:00:03, GigabitEthernet1.45
O IA 150.1.6.6 [110/3] via 155.1.45.4, 00:00:03, GigabitEthernet1.45
O IA 150.1.7.7 [110/1002] via 155.1.0.3, 00:00:03, Tunnel0
OSPF Summarization and Discard Routes:
=====================================
router ospf 1
no discard-route internal
area 2 range 150.1.0.0 255.255.240.0
When summarization is configured in OSPF, similar to EIGRP and BGP, a matching
route to Null0 for the summary is installed locally in the routing table. This “discard”
route is used to prevent the forwarding of traffic toward a shorter match, such as a
default route, if no specific route toward the actual destination exists in the network.
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. The operation of
the discard route can be illustrated as follows. R3 and R5 have the prefixes
150.1.7.7/32 and 150.1.9.9/32 filtered out of the routing table with a distribute-list.
Additionally, R3 is originating the summary 150.1.0.0/20 into area 0, which
encompasses addresses 150.1.0.0 through 150.1.15.255
OSPF Filtering with Administrative Distance:
===========================================
access-list 10 permit 155.1.146.0
!
router ospf 1
distance 255 150.1.5.5 0.0.0.0 10
OSPF Filtering with Route-Maps:
============================
access-list 3 permit 155.1.146.0
access-list 4 permit 155.1.0.4
!
route-map DENY_VLAN146_FROM_R4 deny 10
match ip address 3
match ip next-hop 4
!
route-map DENY_VLAN146_FROM_R4 permit 20
!
router ospf 1
distribute-list route-map DENY_VLAN146_FROM_R4 in
OSPF NSSA ABR External Prefix Filtering:
======================================
router ospf 1
summary-address 160.1.10.10 255.255.255.255 not-advertise
No comments:
Post a Comment