- 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
https://supportforums.cisco.com/document/97766/comparing-ospfv3-ospfv2-routing-protocol
https://supportforums.cisco.com/t5/network-infrastructure-documents/reading-and-understanding-the-ospf-database/ta-p/3145995
- OSPF allows to link discontinuous parts of the backbone area using virtual links. (area0-area1-area0)
- DR - Designated Router, chosen router to minimize the number of adjacencies formed. Option is used in broadcast networks.
- BDR -Backup Designated Router, hot standby for the DR. BDR receives all routing updates from adjacent routers, but it does not flood LSA updates,
- If we do not have any ASBR, there´s no LSA Types 4 and 5 in the network.
Open Shortest Path First (OSPF) routing protocol, which is one of the most commonly used interior gateway protocols in IP networking. OSPF is an open-standard protocol based primarily on RFC 2328.
Routers running link-state routing protocols collect routing information from all other routers in the network (or from within a defined area of the network), and then each router independently calculates its best paths to all destinations in the network, using Dijkstra’s (SPF) algorithm.
OSPF will choose routes in the following order:
Intra-Area (O)
Inter-Area (O IA)
External Type 1 (E1)
External Type 2 (E2) *
NSSA Type 1 (N1)
NSSA Type 2 (N2)
* - “OSPF routers do not add any internal OSPF cost to the metric for an E2 route”, both the intra-area and inter-area cost is still considered in the OSPF path selection state machine for these routes.
details: E1 vs E2 explanation
Example: (R1)--OSPF--(R2)<-EIGPR,
R1 have 2 links with R2: fast0/0 in T1. R2 is redistributing EIGRP routes in OSPF.
R1 will know O E2 routes (EIGRP) via both links, but will add only best even metric is the same.
1) assume only Serial link is up
8.0.0.0/24 is subnetted, 1 subnets
O E2 8.8.8.0 [110/20] via 10.0.156.6, 00:09:42, Serial2/0
Routing entry for 8.8.8.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 64
2) now, fast0/0 came up
8.0.0.0/24 is subnetted, 1 subnets
O E2 8.8.8.0 [110/20] via 10.0.56.6, 00:00:01, FastEthernet0/0
Routing entry for 8.8.8.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1
even both LSA Type 5 are is LSDB
R5#sh ip ospf data external 8.8.8.0 | exc Tag|TOS|age|Seq|Checksum|Addre|Type|Length
OSPF Router with ID (5.5.5.5) (Process ID 1)
Routing Bit Set on this LSA
Link State ID: 8.8.8.0 (External Network Number )
Advertising Router: 6.6.6.6
Network Mask: /24
Metric: 20
Link State ID: 8.8.8.0 (External Network Number )
Advertising Router: 7.7.7.7
Network Mask: /24
Metric: 20
R5#
OSPF Terms
Link state database (LSDB) - OSPF completed topology database
Shortest Path First (SPF) - algorithm OSPF uses to analyze the LSDB and determines the best (lowest cost) route for each prefix/length.
Link State Update (LSU) - OSPF packet that holds the detailed topology information, specifically LSAs
Link State Advertisement (LSA) - each router originates one or more LSAs to send routing information about itself, or to receive routing information from neighbors. This information is used to build the link-state database.
Area - A contiguous grouping of routers and router interfaces. Routers in an area strive to learn all topology information about the area, but they do not learn topology information about areas to which they do not connect.
Area Border Router (ABR) - A router that has interfaces connected to at least two different OSPF areas, including the backbone area.
Backbone router - Any router that has at least one interface connected to the backbone area.
Internal routers - A router that has interfaces connected to only one area, making the router completely internal to that one area.
Designated Router (DR) - On multiaccess data links like LANs, an OSPF router elected by the routers on that data link to perform special functions (generation of LSAs representing the subnet, and playing a key role in the database exchange process)
Backup Designated Router (BDR) - A router on a multiaccess data link that monitors the DR
and becomes prepared to take over for the DR, should the DR fail.
Backbone area — interconnect with other OSPF area types. Generally, end users are not found within a backbone area. The backbone area is also called OSPF area 0.
Regular (nonbackbone) area—An OSPF area whose primary function is to connect users and resources. Regular areas (also called normal areas) are usually set up along functional or geographic groupings.
By default, a regular area does not allow traffic from another area to use its links to reach other areas. By default, all traffic from other areas must cross backbone area 0.
Regular areas can have several subtypes, including standard area, stub area, totally stubby area, not-so-stubby area (NSSA), and totally stubby NSSA.
Multiple Area feature is important comparing with other IGPs:
- all copmutation is kept within the Area (less frequent SPF calculations),
- minimum inter-area communications (reduced LSU overhead),
- smaller routing tables,
- allowing the network to scale to large size.
- all interarea (different areas) traffic must pass through the backbone area 0.
OSPF Area
The memory resources required to maintain these tables can be a drawback to link-state protocols. However, because the topology table (LSDB) is identical in all OSPF routers in an area and contains full information about all the routers and links in an area, each router can independently select a loop-free and efficient path, based on cost (as described in the “OSPF Metric Calculation” section, later in this chapter), to reach every network in the area. This benefit overcomes the “routing by rumor” limitations of distance vector routing.
Using multiple OSPF areas has several important advantages:
- Reduced frequency of SPF calculations,
- Smaller routing tables,
- Reduced LSU overhead.
Area Terminology
OSPF routers of different types control the traffic that goes in and out of areas.
1) Internal router — Routers that have all of their interfaces in the same area. All routers within the same area have identical LSDBs.
2) Backbone router — Routers that sit in the perimeter of the backbone area 0 and that have at least one interface connected to area 0. Backbone routers maintain OSPF routing information using the same procedures and algorithms as internal routers.
3) Area Border Router (ABR) — Routers that have interfaces attached to multiple areas, maintain separate LSDBs for each area to which they connect, and route traffic destined for or arriving from other areas. ABRs connect area 0 to a nonbackbone area and are exit points for the area, which means that routing information destined for another area can get there only via the ABR of the local area. ABRs distribute this routing information into the backbone. The backbone routers then forward the information to the other ABRs. ABRs are the only point where area address summarization can be configured (to summarize the routing information from the LSDBs of their attached areas). ABRs separate LSA flooding zones, and may function as the source of default routes. An area can have one or more ABRs.
The ideal design is to have each ABR connected to two areas only, the backbone and another area. As mentioned, the recommended upper limit is three areas.
4) Autonomous System Boundary Router (ASBR) — Routers that have at least one interface attached to a different routing domain (such as another OSPF autonomous system or a domain using the Enhanced Interior Gateway Protocol [EIGRP]). An OSPF autonomous system consists of all the OSPF areas and the routers within them. ASBRs can redistribute external routes into the OSPF domain and vice versa.
Cisco recommends the following guidelines:
■ An area should have no more than 50 routers.
■ A router should not be in more than three areas.
OSPF Propeties
VLSM/classless - OSPF includes the mask with each route, also allowing it to support discontiguous networks and VLSM
Transport - IP, protocol type 89 (does not use UDP or TCP)
Metric - cumulative cost (bandwidth) of all outgoing interfaces in a route
Update destination address - Normally sent to 224.0.0.5 (All SPF Routers) and 225.0.0.6 (All Designated Routers).
Authentication - Supports None or MD5 or clear-text authentication.
Manual route summarization - Allows route summarization at ABR routers only
OSPF Functions
OPSF uses link state (LS) logic:
1) neighbor discovery (stored in neighbor table), has the same overall goal as EIGRP’s neighbor discovery process:
to find the neighboring routers, and exchange enough information so that the two routers
know whether they should exchange topology data.
2) topology database exchange (stored in topology database aka link state database -LSDB)
- The existence of, and an identifier for, each router (router ID)
- Each router interface, IP address, mask, and subnet
- The list of routers reachable by each router on each interface
3) route computation, means that each router independently analyzes the topology data to choose the best routes from their perspective.
OSPF use a Shortest Path First (SPF) algorithm to analyze the data, choose the shortest (best) route for each reachable subnet, and add the correct next-hop/outgoing interface information for those routes to the IP routing table.
OSPF Neighbors and Adjacencies on LANs
OSPF neighborship is more complex (comparing EIGRP)
Two classes of neighborships exist: neighbors and fully adjacent neighbors.
OSPF Finite State Machine (FSM) have eight neighbor states.
OSPF sends multicast OSPF Hello messages on LAN interfaces, attempting to discover OSPF neighbor
Enable OSPF interfaces
1. HIGHEST PRIORITY
[interface]ip ospf <process-id> area <area-id>The interface has not been made passive by the passive-interface router sub-command.
(config-if)# ip ospf 1 area 999
Hello itself contains several parameters that must be checked, including the OSPF RID of the router sending the Hello, and the OSPF area that router has assigned to that LAN.
2. LOWEST PRIORITY
OSPF router command
[Router] network <A.B.C.D> <E.F.G.H> area <area-id>If one uses multiple and overlapping networks statements in order to assign interfaces into different:
# network 172.17.20.0 0.0.0.255 area 0
A.B.C.D Network number
E.F.G.H OSPF wild card bits
area - Set the OSPF area ID
area-id - <0-4294967295> OSPF area ID as a decimal value OR
A.B.C.D OSPF area ID in IP address format
more specific network statement is processed first:
router ospf 1
network 10.100.4.0 0.0.0.255 area 1
network 10.100.4.0 0.0.1.255 area 2
R6#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.100.4.1 YES manual up up
FastEthernet0/1 10.100.5.1 YES manual up up
R6#sh ip ospf int br
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Fa0/0 1 1 10.100.4.1/24 1 WAIT 0/0
Fa0/1 1 2 10.100.5.1/24 1 WAIT 0/0
Settings That Must Match for OSPF Neighborship
http://sclabs.blogspot.com/p/routing-protocols-comparison-ad-and.html
Timers
Hello interval - how often the router sends a Hello on the interface
Dead interval - how long a router should wait, without hearing any Hello messages from that neighbor, before deciding that the neighbor failed.
Default interface Broadcast (LAN ) and point-to-point uses setting of Hello of 10 (every 10 seconds), and Dead of 40.
NBMA, point-to-multipoint uses 30/120 second timers.
The debug ip ospf events output shown might appear if any of the following situations occurs:
- The IP subnet masks for routers on the same network do not match.
- The OSPF hello interval for the router does not match that configured for a neighbor.
- The OSPF dead interval for the router does not match that configured for a neighbor.
RouterA#debug ip ospf events
OSPF events debugging is on
RouterA#
04:43:16: OSPF: Rcv hello from 172.16.1.1 area 0 from Serial0/0 10.1.1.1
04:43:16: OSPF: Mismatched hello parameters from 10.1.1.1
04:43:16: OSPF: Dead R 120 C 10, Hello R 30 C 30
04:43:16: OSPF: Rcv hello from 192.168.1.2 area 0 from Serial0/0 10.1.1.2
04:43:16: OSPF: Mismatched hello parameters from 10.1.1.2
04:43:16: OSPF: Dead R 120 C 10, Hello R 30 C 30
Dead R 120 C 10, Hello R 30 C 30
The Dead R (recv) is the Dead Timer of the neighbor that in this case is 120 seconds,
the Dead C (configured) is the local Dead Timer.
RouterA serial0/0 interface has the OSPF dead timer set to 10 seconds.
To tune for faster convergence:
- set a lower Hello and Dead timers
- if the interface fails, OSPF will immediately realize that all neighbors reached through that interface have also failed and not wait on the Dead timer to count down to zero
Commands
R4(config)#interface fastethernet0/0Router ID
R4(config-if)#ip ospf hello-interval 9
ip ospf hello-interval <value>
ip ospf dead-interval <value>
ip ospf dead-interval minimal hello-multiplier <multiplier>
ip ospf dead-interval minimal hello-multiplier 4 (sets the dead interval to one second)
show ip ospf interface fa0/0
show ip ospf neighbors
In OSPF for IPv4, an interface can be a part of a single OSPF process only.
Two OSPF processes on the same box don't talk to each other unless you redistribute between them.
Unique Router Identifier (RID)
Each OSPF router assigns itself a router ID:
1) router-id <rid-value> (OSPF subcommand)
2) highest IP address of any up/up loopback interface;
3) highest IP address of any up/up non-loopback interface.
By design, all OSPF RIDs in a domain should be unique; to avoid such issues, OSPF prevents neighborships between routers with duplicate RIDs.
Sometimes a router ID needs to be changed, for example, when a network administrator establishes a new router ID scheme for the network. However, after a router selects a router ID, an active OSPF router does not allow the router ID to be changed until the router is reloaded or the OSPF process cleared.
Clearing the OSPF process is the preferred method to reset the router ID.
clear ip ospf processTroubleshooting duplicate RIDs: - link @ cisco.com
! verify RID with
show ip protocols
- OSPF route appearing and disappearing constantly
- high CPU utilization
- routers perfoms SPF constantly
- content of LSA changing every few seconds.
Note that the OSPF process will not start without an RID. (Error will appear if trying to run OSPF with there are no single interface in UP/UP state).
Same IP MTU
The maximum transmission unit (MTU) of an interface tells IOS the largest IP packet that can be forwarded out the interface.
From a design perspective, the MTU used by all devices attached to the same data link ought to be the same value. However, routers have no dynamic mechanism to prevent the misconfiguration of MTU on neighboring routers.
From a data plane perspective, when a router needs to forward a packet larger than the outgoing interface’s MTU, the router either fragments the packet or discards it. If the IP header’s don’t fragment (DF) bit is set, the router discards the packet. If the DF bit is not set, the router can perform Layer 3 fragmentation on the packet, creating two (or more) IP packets with mostly identical IP headers, spreading the data that follows the original IP packet header out among the fragments. The fragments can then be forwarded, with the reassembly process being performed by the receiving host.
MTU mismatch occurs between two OSPF neighbors, one router will attempt to become neighbors with the other router whose MTU differs. The other router will be listed in the list of neighbors (show ip ospf neighbor). However, the two routers will not exchange topology information, and the two routers will not calculate routes that use this neighbor as the next-hop router.
The IP MTU can be set on an interface using the ip mtu value interface subcommand and for all Layer 3 protocols with the mtu value interface subcommand.
OSPF Authentication
OSPF authentication causes routers to authenticate every OSPF message.
When authentication fails, two routers cannot become OSPF neighbors, because they ignore the inauthentic OSPF Hello messages
Configuration steps:
1) Authentication must be enabled:
- Enabling per interface using the interface subcommand "ip ospf authentication [message-digest]"
- Enabling on all interfaces in an area by router ospf command "area area-no authentication [message-digest]"
2) The authentication keys must be configured per interface.
Authentication types can be seen in the messages generated by the "debug ip ospf adjacency"
The max key length is 8 (clear text) or 16 (MD5) characters.
0 None ip ospf authentication null
1 Clear_text ip ospf authentication
ip ospf authentication-key <key-value>
2 MD5 ip ospf authentication message-digest
ip ospf message-digest-key <key-number> md5 <key-value>
Although IOS defaults to use type 0 authentication (no authentication), you can override this default using the area authentication command in OSPF configuration mode.
default; no configuration required Type 0
area <num> authentication Type 1
area <num> authentication message-digest Type 2
Note that if the area-wide default and the interface subcommand have both been configured, the interface setting takes precedence.
For example, if the interface has been configured with the ip ospf authentication subcommand (type 1, clear text), and the area authentication command sets MD5 authentication,
that particular interface uses clear text authentication.
Unlike EIGRP authentication, OSPF authentication does not allow the configuration of a key chain with time-based authentication keys.
Verification:
show ip ospf interface
show ip ospf neighbor
debug ip ospf adj
*Mar 1 00:12:05.771: OSPF: Rcv pkt from 10.1.1.1, Serial0/1.201 : Mismatch Authentication Key - Clear Text
OSPF Neighbors and Adjacencies on WANs
OSPF still must meet the same requirements as on LANs.
The operation of OSPF on WAN links of various types requires some additional configuration:
- OSPF will discover neighbors via multicast /unicast or do the neighbors require predefinition?
- Will the routers try to elect a DR, and if so, which router should be allowed to be the DR?
- With which other routers should each router become an OSPF neighbor?
The first two of these items depend in part on the setting of the OSPF network type, and the third question depends on the WAN service.
OSPF Network Type
The OSPF network type–a per-interface setting–directs OSPF in regard to three important facts:
■ Whether the router can expect to discover neighbors using multicast Hello messages
■ Whether only two or more than two OSPF routers can exist in the subnet attached to the interface
■ Whether the router should attempt to elect an OSPF DR on that interface
ip ospf network <type>
1. OSPF Neighborship over Point-to-Point Links
Configure IP addresses on either end, configure the clock rate if using a back-to-back serial cable in a lab, and no shutdown the interfaces.
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/ - 00:00:31 10.1.12.2 Serial0/0/0
FULL/ - This notation means that no attempt was made to elect a DR
2. OSPF Neighborship over Frame Relay Point-to-Point Subinterfaces
Frame Relay design allows several options for IP addressing and subnetting:
1) treats each pair of routers on the ends of each PVC as a point-to-point topology, with one subnet assigned to each pair of routers,
2) treats more than two routers as a group, whether connected with a full mesh or partial mesh of PVCs, with a single subnet assigned to that group. (point-to-multipoint)
point-to-point subinterfaces
IOS point-to-point subinterfaces unsurprisingly default to use OSPF network type point-to-point.
The two routers discover each other using multicast OSPF Hellos, they do not bother to elect a DR, and everything works well.
3. OSPF Neighborship on MPLS VPN (L3)
The service uses routers at the edge of the service provider cloud–generically called provider edge (PE) routers–and these routers are Layer 3-aware. That Layer 3 awareness means that the customer edge (CE) routers form an OSPF neighborship with the PE router on the other end of their local access link.
The central site router will not have an OSPF neighborship with each branch office router but will have a neighborship with the MPLS VPN provider’s PE router.
4. OSPF Neighborship on Metro Ethernet (L2)
Metro Ethernet include VPWS, a point-topoint service, and VPLS, a multipoint service.
Because MetroE services provide Layer 2 connectivity, customer routers do not form OSPF neighborships with routers inside the service provider’s network.
Instead, the OSPF neighborships forms between customer routers, essentially as if the service were a large WAN.
OSPF LSAs and the OSPF Link State Database
Limiting the Number of LSAs
By default, Cisco IOS does not limit the number of LSAs a router can learn.
However, it may be useful to protect a router from learning too many LSAs to protect router memory.
Also, with a large number of LSAs, the router may be unable to process the LSDB with SPF well enough to converge in a reasonable amount of time.
The maximum number of LSAs learned from other routers can be limited by a router using the OSPF subcommand
max-lsa <number>If is over:
- first reaction is to issue log messages.
- the router ignores the event for a time period, after which the router repeats the warning message.
LSA Types http://en.wikipedia.org/wiki/Link-state_advertisement
With LSA's, routers communicates routing topology to all other local routers in the same OSPF area.
OSPF is designed for scalability, so some LSAs are not flooded out on all interfaces, but only on those that belong to the appropriate area.
In this way detailed information can be kept localized, while summary information is flooded to the rest of the network.
Each router link is defined as one of four types: type 1, 2, 3, or 4.
The LSA includes a link ID field that identifies, by the network number and mask, the object that this link connects to.
Depending on the type, the link ID has different meanings.
| Link type | Description | Link ID | Link Data |
|---|---|---|---|
| 1 | point-to-point connection to another router | neighboring router ID | IP address of the originating's interface to the network |
| 2 | connection to a transit network | IP address of Designated Router | IP address of the originating's interface to the network |
| 3 | connection to a stub network | IP network/subnet number | Subnet mask of the interface |
| 4 | virtual link | neighboring router ID | IP address of the originating's interface to the network |
Sample
Diamond#sh ip ospf dataOSPF v3 LSAs
OSPF Router with ID (192.168.14.1) (Process ID 23423)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
192.168.12.55 192.168.12.55 1673 0x80000005 0x004F5A 1
192.168.14.1 192.168.14.1 152 0x80000008 0x0084C8 2
192.168.23.2 192.168.23.2 1595 0x80000005 0x0050EB 1
192.168.45.4 192.168.45.4 587 0x80000005 0x00ED17 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
192.168.12.1 192.168.14.1 1667 0x80000003 0x005647
192.168.14.1 192.168.14.1 664 0x80000003 0x00979C
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
192.168.45.0 192.168.45.4 587 0x80000003 0x008C7C
| OSPFv3 | OSPFv2 | ||
|---|---|---|---|
| 0x2001 | Router LSA | 1 | Router LSA |
| 0x2002 | Network LSA | 2 | Network LSA |
| 0x2003 | Inter-area Prefix LSA | 3 | Network Summary LSA |
| 0x2004 | Inter-area Router LSA | 4 | ASBR Summary LSA |
| 0x4005 | AS-External LSA | 5 | AS-External LSA |
| 0x2006 | Group Membership LSA | 6 | Group Membership LSA |
| 0x2007 | Type-7 LSA | 7 | NSSA External LSA |
| 0x0008 | Link LSA | ||
| 0x2009 | Intra-area Prefix LSA | ||
OSPF v2 LSAs
Type 1 (ROUTER)
Each router creates its own Type 1 LSA to represent itself for each area to which it connects.
The LSDB for one area contains one Type 1 LSA per router per area, listing the RID and all interface IP addresses on that router that are in that area:
- for each interface on which no DR has been elected, it lists the router’s interface subnet number/mask and interface OSPF cost. (OSPF refers to these subnets as stub networks.)
- for each interface with no DR, but for which a neighbor is reachable, it lists the neighbor’s RID.
- for each interface on which a DR has been elected, it lists the IP address of the DR and a notation that the link attaches to a transit network(meaning a type 2 LSA exists for that network).
Represents stub networks as well.
Shows how many routers in one area (listing LSID wich is RID = highest loopback-IP/real-IP).
Type 2 (NETWORK)
One per transit network (broadcast domain). Created by the DR on the subnet, and represents the subnet and the router interfaces connected to the subnet.
OSPF defines the Type 2 network LSA, used as a pseudonode. Each router’s Type 1 router LSA lists a connection this pseudonode, often called a transit network, which is then modeled by a Type 2 network LSA. pag 187
The elected DR in a subnet creates the Type 2 LSA for that subnet.
Type 3 (SUMMARY NET)
Created by ABRs to represent subnets listed in one area’s type 1 and 2 LSAs when being advertised into another area. Defines the links (subnets) in the origin area, and cost, but no topology data.
ABRs do not flood Type 1 and Type 2 LSAs into other areas, but routers still need to learn about subnets in other areas. OSPF advertises these interarea routes using the Type 3 summary LSA. ABRs generate a Type 3 LSA for each subnet in one area, and advertises each Type 3 LSA into the other areas.
Type 4 (ASBR SUMMARY)
Like a type 3 LSA, except it advertises a host route used to reach an ASBR.
Type 5 (AS External)
Created by ASBRs for external routes injected into OSPF.
Type 6 (Group Membership)
Defined for MOSPF; not supported by Cisco IOS.
Type 7 (NSSA External)
Created by ASBRs inside an NSSA area, instead of a type 5 LSA.
Type 8 (External Attributes)
Not implemented in Cisco routers.
Type 9–11 (Opaque)
Used as generic LSAs to allow for easy future extension of OSPF; for example, type 10 has been adapted for MPLS traffic engineering.
The Database Exchange Process
Every router that connects to a given OSPF area should learn the exact same topology data.
Each router stores the data, composed of individual link state advertisements (LSA), in their own copy of the link state database (LSDB). Then, the router applies the Shortest Path First (SPF) algorithm to the LSDB to determine the best (lowest cost) route for each reachable subnet (prefix/length).
A router’s SPF process must examine the individual LSAs and see how they fit together, based on their characteristics.
OSPF routers flood both the LSAs they create, and the LSAs they learn from their neighbors, until all routers in the area have a copy of each of the most recent LSAs for that area. To manage and control this process, OSPF defines several messages, processes, and neighbor states that indicate the progress when flooding LSAs to each neighbor.
OSPF RFC: Section 13. The Flooding Procedure
A Link State Update packet may contain several distinct LSAs, and floods each LSA one hop further from its point of origination.
The flooding procedure starts when a Link State Update packet has been received.
Many consistency checks have been made on the received packet before being handed to the flooding procedure (LSA's LS checksum, Examine the LSA's LS type).
(5) Otherwise, find the instance of this LSA that is currently contained in the router's link state database.
If there is no database copy, or the received LSA is more recent than the database copy the following steps must be performed:
(a) If there is already a database copy, and if the database copy was received via flooding and installed less than MinLSArrival seconds ago,
discard the new LSA (without acknowledging it) and examine the next LSA (if any) listed in the Link State Update packet.
(b) Otherwise immediately flood the new LSA out some subset of the router's interfaces.
In some cases the LSA will be flooded back out the receiving interface.
(c) Remove the current database copy from all neighbors' Link state retransmission lists.
(d) Install the new LSA in the link state database (replacing the current database copy).
This may cause the routing table calculation to be scheduled.
(e) Possibly acknowledge the receipt of the LSA by sending a Link State Acknowledgment packet back out the receiving interface.
(f) If this new LSA indicates that it was originated by the receiving router itself (i.e., is considered a self-originated LSA),
the router must take special action, either updating the LSA or in some cases flushing it from the routing domain.
OSPF Message Types and Functions
All five OSPF packets are encapsulated directly in an IP payload. The OSPF packet does not use Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). OSPF requires a reliable packet transport scheme, and because TCP is not used, OSPF defines its own acknowledgment routine using an acknowledgment packet (OSPF packet type 5).
Message Name/number
1) Hello (type 1) - Used to discover neighbors, supply information used to confirm two routers should be allowed to become neighbors, to bring a neighbor relationship to a 2-way state, and to monitor a neighbor’s responsiveness in case it fails.
2) Database Description (DD or DBD) (type 2) - Used to exchange brief versions of each LSA, typically on initial topology exchange, so that a router knows a list of that neighbor’s known LSAs
3) Link-State Request (LSR) (type 3) - A packet that lists the LSIDs of LSAs the sender of the LSR would like the receiver of the LSR to supply during database exchange
4) Link-State Update (LSU) (type 4) - A packet that contains fully detailed LSAs, typically sent in response to an LSR message
5) Link-State Acknowledgment (LSAck) (type 5) - Sent to confirm receipt of an LSU message
 |
| OSPF packet Header + Hello Packet |
OSPF packet fields:
Version Number - 2 for OSPF ver2 (IPv4), 3 for OSPF ver3 (IPv6)
Type - Differentiates the five OSPF packet types
Packet Length - The length of the OSPF packet in bytes
Router ID - Defines which router is the packet’s source.
Area ID - Defines the area in which the packet originated.
Checksum - Used for packet header error detection to ensure that the OSPF packet
was not corrupted during transmission.
Authentication Type - Optional (no authentication/clear-text passwords/encrypted MD5 router authentication.
Authentication—Used with authentication type.
Data - Contains different information, depending on the OSPF packet type:
- Hello packet - Contains a list of known neighbors.
- DBD packet - Contains a summary of the LSDB, which includes all known RIDs and their last sequence number, among several other fields.
- LSR packet - Contains the type of LSU needed and the RID ofthe router that has the needed LSU.
- LSU packet - Contains the full LSA entries. Multiple LSA entries can fit in one OSPF update packet.
- For the LSAck packet—This data field is empty.
 |
| hello packet |
| Neighbors Requirements | OSPF | Where |
| Routers MUST be able to send/receive IP packets to one another | YES | L1/L2 |
| Interfaces MUST be in UP/UP state | YES | L1/L2 |
| Interfaces PRIMARY IP MUST be in SAME subnet | YES | L3 |
| Interfaces MUST not be Passive on the connected interface | YES | OSPF Config |
| MUST pass authentication (if configured) | YES | OSPF Config |
| Router IDs MUST be unique | YES | OSPF Config |
| SAME ASN / Process ID | NO | OSPF Config |
| SAME Hello / Dead intervals | YES | Every OSPF Packets (usually first packets) |
| SAME MTU | YES | DBD Packets |
| SAME 'Stub' Area Flag SAME Area |
YES | Every OSPF Packets |
Specifically this problem stems from the issue that the OSPF Hello, Database Description (DBD), Link-State Request (LSR), and Link-State Acknowledgement (LSAck) packets are generally small, but the Link-State Update (LSU) packets are generally not.
When establishing a new OSPF adjacency, the DBD packet is used to tell new neighbors what LSAs are in the database, but not to give the details about them. Specifically the DBD contains the LSA Header information, but not the actual LSA payload. The idea behind this is to optimize flooding in the case that the receiving router already received the LSA from another neighbor, in which case flooding does not need to occur during adjacency establishment.
http://blog.ine.com/2011/03/30/ospf-and-mtu-mismatch/
When Router receive an LSU (LSA) it does
- if LSA entry doesnt exist:
1) R add entry is LSDB 2) send back LSAck 3) floods info to other R's 4) run SPF 5) update routing table
- if LSA entry exists and includes newer info (higher Seq num):
1) R add entry is LSDB 2) send back LSAck 3) floods info to other R's 4) run SPF 5) update routing table
- if LSA entry exists and includes older info (lower Seq num):
1) send LSU with its newer info
OSPF Neighbor States
http://www.itcertnotes.com/2011/02/ospf-neighbor-establishment-process.html
 |
| OSPF States |
Attempt - Used when the neighbor is defined with the neighbor command, after sending a Hello, but before receiving a Hello from that neighbor.
Init - A Hello has been received from the neighbor, but it did not have the local router’s RID in it or lists parameters that do not pass the neighbor verification checks. This is a permanent state when Hello parameters do not match.
2Way - A Hello has been received from the neighbor, it has the router’s RID in it, and all neighbor verification checks passed.
ExStart - Currently negotiating the DD sequence numbers and master/slave logic used for DD packets.
Exchange - Finished negotiating the DD process particulars, and currently exchanging DD packets.
Loading - All DD packets are exchanged, and the routers are currently sending LSR, LSU, and LSAck packets to exchange full LSAs.
Full - Neighbors are fully adjacent, meaning they believe that their LSDBs for that area are identical. Routing table (re)calculations can begin.
OSPF Sample Database exchange (packets)
< unicast
<<< multicast
R1 R3
HL->
<-HL
===no shutdown int (routes: 1.1.1.0/24 and 8.8.8.0/24)
<DBD seq 8248
seq 6901 DBD>
seq 8248 DBD>
LS REQ>
seq 8249 DBD>
<LS Update (routes 1.1.1.0/24 and 8.8.8.0/24)
<LS REQ
LS Update>>>
multicast
LS Update>
(1.1.1.0/24)
<LS Ack (explicit acknowledgment)
<<<LS Update multicast (routes 1.1.1.0/24 and 8.8.8.0/24)
LS Ack>
<<<<LS Ack (implicit acknowledgment)
LS Ack>>>
In general, the following are the flooding process steps in a multiaccess network
1) Topology change
A router notices a change in a link state and multicasts an LSU packet, which includes the updated LSA entry with the sequence number incremented, to 224.0.0.6. This address goes to all OSPF DRs and BDRs. (On point-to-point links, the LSU is multicast to 224.0.0.5.) An LSU packet might contain several distinct LSAs.
2) DR send updates to all routers with ACK
The DR receives the LSU, processes it, ACKnowledges the receipt of the change and floods the LSU to other routers on the network using the OSPF multicast address 224.0.0.5. After receiving the LSU, each router responds to the DR with an LSAck. To make the flooding procedure reliable, each LSA must be acknowledged separately.
3) Each router send updates to others
If a router is connected to other networks, it floods the LSU to those other networks by forwarding the LSU to the DR of the multiaccess network (or to the adjacent router if in a point-to-point network). That DR, in turn, multicasts the LSU to the other routers in the network.
4) Each router updates his routing table
The router updates its LSDB using the LSU that includes the changed LSA. It then recomputes the SPF algorithm against the updated database after a short delay and updates the routing table as necessary.
An SPF calculation is performed separately for each area in the topology database.
224.0.0.5 goes to all OSPF routers on the link.
224.0.0.6 goes to the DR and BDR on the link.
Exchange Without a Designated Route
OSPF interface network type tells that router whether to attempt to elect a DR on that interface.
Routers do not elect a DR occur on point-to-point topologies:
- true point-to-point serial links
- point-to-point subinterfaces.
1) Hello
When a router receives a Hello that lists its own RID as having been seen by the other router, the router can transition to 2-Way state.
Next: the router decides whether it should exchange its LSDB entries.
Step 1. Discover the LSAs known to the neighbor but unknown to me.
Step 2. Discover the LSAs known by both routers, but the neighbor’s LSA is more up to date.
Step 3. Ask the neighbor for a copy of all the LSAs identified in the first two steps.
2) DD
To learn the list of LSAs known by the neighbor, the neighboring routers follow these steps:
Step 1. Multicast database description (DD) packets to 224.0.0.5,(all OSPF routers multicast address).
Step 2. Transition to the ExStart (sending the first DD message), until one router, the one with the higher RID, becomes master in a master/slave relationship.
Step 3. After electing a master, transition the neighbor to the Exchange state.
Step 4. Continue multicasting DD messages to each other until both routers have the same shared view of the LSIDs known collectively by both routers, in that area.
Note that the DD messages themselves do not list the entire LSAs, but rather LSA headers.
Highest RID becomes master and starts DBD exchange (controls the flow of DD messages).
These headers include the LSIDs of the LSAs and the LSA sequence number. The LS sequence number for an LSA begins at value 0x80000001 (hex) when initially created; the router creating the LSA increments the sequence number, and refloods the LSA, whenever the LSA changes. For example, if an interface moves from up to down state, that router changes its Type 1 LSA to list that interface state as down, increments the LSA sequence number, and refloods the LSA.
This exchange of DD messages ends with each router knowing a list of LSAs that it does not have in its LSDB, but that the other router does have those LSAs.
3) full LSA
When the two neighbors realize that they have a shared view of the list of LSIDs, they transition to the Loading state and start exchanging the full LSAs–but only those that they do not yet know about or those that have changed.
The mechanics work like this:
Step 1. Transition the neighbor state to Loading.
Step 2. For any missing LSAs, send a Link State Request(LSR) message, listing the LSID of the requested LSA.
Step 3. Respond to any LSR messages with an Link State Update(LSU), listing one or more LSAs in each message.
Step 4. Acknowledge receipt by either sending a LSAck message (called explicit acknowledgment), or by sending the same LSA that was received back to the other router in an LSU message (implicit
acknowledgment).
Step 5. When all LSAs have been sent, received, and acknowledged, transition the neighborship to the FULL state (fully adjacent).
Note: Because this section examines the case without a DR, all these messages flow as multicasts to 224.0.0.5, the all SPF routers multicast address, unless the neighbors have been defined with an OSPF neighbor command.
Exchange with a Designated Router
Database exchange with a DR differs slightly than database exchange when no DR exists (difference is the overriding choice of with whom each router chooses to perform database exchange).
Non-DR routers do not exchange their databases directly with all neighbors on a subnet.
Instead, they exchange their database with the DR and BDR only (sends these messages to the 224.0.0.6) and not any other DROther routers in the subnet.
The DR performs database exchange with the same messages but sends the messages to the 224.0.0.5 all-SPF-routers multicast address.
R3#show ip ospf interface fa0/0
...
Neighbor Count is 3, Adjacent neighbor count is 2 (Adj is only with DR and BDR)
Adjacent with neighbor 1.1.1.1 (Designated Router)
Adjacent with neighbor 2.2.2.2 (Backup Designated Router)
Periodic Flooding
Although OSPF does not send routing updates on a periodic interval, as do distance vector protocols, OSPF does reflood each LSA every 30 minutes based on each LSA’s age variable.
Over time the sequence number should increment once per every 30 minutes, with the LSAge cycle upward toward 1800 and then back to 0 when the LSA is reflooded. (counting from 0 to 1800, when 1800, reflood LSA and set Age=0)
R1#sh ip ospf data
OSPF Router with ID (10.1.1.142) (Process ID 2)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.1.1.8 10.1.1.8 1422 0x80003025 0x00631D 1
10.1.1.142 10.1.1.142 558 0x80010E6A 0x0009FD 2
10.1.1.253 10.1.1.253 504 0x800026C4 0x00BA1D 1
Note also that when a router realizes it needs to flush an LSA from the LSDB for an area, it actually sets the age of the LSA to the MaxAge setting (3600) and refloods the LSA. All the other routers receive the LSA, see the age is already at the maximum, causing those routers to also remove the LSA from their LSDBs.
Choosing the Best OSPF Routes (Metric Calculation)
LSAs flooding has one goal in mind: to allow all routers in that area to calculate the best, loop-free routes for all known subnets.
Best route for a given subnet (calculated by a particular router), can be summarized as follows:
1) Analyze the LSDB to find all possible routes to reach the subnet.
2) For each possible route, add the OSPF interface cost (show ip ospf interface) for all outgoing interfaces in that route.
3) Pick the route with the lowest total cost.
Calculating the Cost of Intra-Area Routes
1) Finds all subnets inside the area (LSA Type1 and Type2)
2) Runs SPF to find all possible paths through the area’s topology, from itself to each subnet
3) Calculates the OSPF interface costs for all outgoing interfaces in each route (lowest total cost route for each subnet is the best route)
If the metrics tie, with a default setting of maximum-paths 4, OSPF adds up to 4 equal-cost routes to its routing table.
OSPF supports equal-cost load balancing, but it does not support unequal-cost load balancing.
Modern IOS versions typically support from 1 up to 16 or 32 concurrent routes to one destination (maximum).
Calculating the Cost of Interarea Routes
Interarea routes, do not have topological data–LSA Types 1 and 2–for other areas.
Instead, ABRs create and flood Type 3 summary LSAs into an area, listing the subnet number and mask, but not listing details about routers and links in the other areas.
The SPF algorithm has to calculate all possible routes and options inside an area to the ABR.
For routers in one area to calculate the cost of an interarea route
1) Calculate the intra-area cost from that router to the ABR listed in the type 3 LSA.
2) Add the cost value listed in the Type 3 LSA. (This cost represents the cost from the ABR to the destination subnet.)
Special Rules Concerning Intra-area and Interarea Routes on ABRs
The issue exists when more than one ABR connects to the same two areas (redundancy).
OSPF rules prevent unoptimal routing by:
1) intra-area (direct connection to another area) route > interarea (same area + another area) route
When choosing the best route, an intra-area route is always better than a competing interarea route, regardless of metric.
Intra (SAME AREA) Area routes "O" - routes that are are originated and learned in the same area (OSPF uses pure link state logic)
Inter (between)-area routes "O IA" - routes that originated in some other OSPF area and are advertised into your area (OSPF uses distance vector logic)
2) router is ignoring LSA for interarea route for the purposes of choosing its own best IP routes.
If an ABR learns a Type 3 LSA inside a nonbackbone area, the ABR ignores that LSA when calculating its own routes.
3) External routes
The following external cost types can be configured:
- E1—Type O E1 external routes calculate the cost by adding the external cost to the internal cost of each link the packet crosses. Use this type when multiple ASBRs are advertising an external route to the same autonomous system, to avoid suboptimal routing.
- E2 (default)—The external cost of O E2 packet routes is always the external cost only. Use this type if only one ASBR is advertising an external route to the autonomous system.
The E2 cost to the route in the external AS is always the same. For example, if there were multiple paths to the external route, and E2 costs were used, there would be no distinction between the paths.
If E1 costs are used, so the cost increases at each router as the internal cost is added to the external cost. This allows the optimal path to be selected if multiple paths are available.
Metric and SPF Calculations
Edsger Dijkstra designed the mathematical algorithm used by link-state routing protocols for calculating the best paths through complex networks.
For OSPF, the default behavior on Cisco routers is that the interface cost is calculated based on its configured bandwidth. The higher the bandwidth, the lower the cost.Only one cost can be assigned per interface.
Default OSPF costs are as follows:
■ 56-kbps serial link—Default cost is 1785.
■ 64-kbps serial link—Default cost is 1562.
■ T1 (1.544-Mbps serial link)—Default cost is 64.
■ E1 (2.048-Mbps serial link)—Default cost is 48.
■ Ethernet—Default cost is 10.
■ Fast Ethernet—Default cost is 1.
■ FDDI—Default cost is 1.
■ ATM—Default cost is 1.
Only changes to Type 1 and 2 LSAs require an SPF calculation.
Changes to Type 3 LSAs do not drive a recalculation of the SPF algorithm, because the Type 3 LSAs do not actually describe the topology (counter does not increment).
You can see the number of SPF runs, and the elapsed time since the last SPF run, using several variations on the
Diamond# sh ip ospf
Routing Process "ospf 23423" with ID 192.168.14.1
Start time: 00:03:53.224, Time elapsed: 1w3d
...
Area BACKBONE(0)
Number of interfaces in this area is 2
SPF algorithm last executed 1w3d ago
SPF algorithm executed 8 times
1. Metric Tuning
Engineers have a couple of commands available that allow them to tune the values of the OSPF interface cost, thereby influencing the choice of best OSPF route.
The primary motivation for changing the reference bandwidth is to accommodate good defaults for higher-speed links.
Although Cisco recommends that all routers use the same reference bandwidth, the setting is local to each router.
Changing the Reference Bandwidth
OSPF Cost= reference_bandwidth / interface_bandwidth
Default reference bandwidth
Interface Type Interface Bandwidth OSPF Cost Calculations (100 mbps = 100'000 kbps)Change reference_bandwidth with router command :
Serial 56 kbps 1785 100'000k/56k
T1 1'544 kbps 64 100'000k/1544k
E1 2'048 kbps 48 100'000k/2048k
Ethernet 10'000 kbps 10 100'000k/10'000k
Fast Ethernet 100'000 kbps 1 100'000k/100'000k
Gigabit Ethernet 1'000'000 kbps 1 100'000k/1'000'000k =0.1 <- OSPF always rounds down when results <1
10 Giga Ethernet 10'000'000 kbps 1
OC48 (STM16) 2'500'000 kbps 1
Loopback 8'000'000 kbps 1
auto-cost reference-bandwidth <bandwidth>Sample:
! used on each router to allow different costs for FastEthernet and Gigabit interfaces.
auto-cost reference-bandwidth 1000
The reference bandwidth defaults to 100, meaning 100 Mbps.
Serial interfaces default to a bandwidth setting of 1544, meaning 1544 Kbps
OSPF cost = 100'000 / 1544 = 64
Note: OSPF always rounds down when the calculation results in a fraction
2. Setting Bandwidth
You can indirectly set the OSPF cost by configuring the bandwidth speed interface subcommand.
- On serial links, the bandwidth defaults to 1544. On subinterfaces of those serial interfaces, the same bandwidth default is used.
- On Ethernet interfaces, if not configured with the bandwidth command, the interface bandwidth matches the actual speed.
3. Configuring Cost Directly
The most controllable method to configure OSPF costs, but the most laborious, is to configure the interface cost directly with interface sub-command ip ospf cost <value>
4. Verifying OSPF Cost Settings
R3#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Se0/0/0.2 3 34 10.10.23.3/29 647 P2P
Se0/0/0.1 3 34 10.10.13.3/29 1000 P2P 1/1
Fa0/0 3 34 10.10.34.3/24 17 BDR 1/1
R3#show ip ospf interface fa0/0
...
Process ID 3, Router ID 3.3.3.3, Network Type BROADCAST, Cost: 17
OSPF neighbor relationships are formed
1. Determine the Router-ID (Highest physical IP address/Highest Loopback address, Loopback will always beat the physical interface. You should always hard code the Router-ID)
2. Add interface to the Link State Database (LSD)
3. Send Hello Packets out of chosen interfaces based on the Network command. ** DOWN STATE**
4. If connected to a Non-broadcast Multi Access Network (NBMA) e.g. ATM/Frame-Relay send unicast packets **ATTEMPT STATE**
5. Neighbors receive Hello packets and check certain criteria to make sure they match. **INNIT STATE**
Area-ID must match
Hello/dead timers must match
Subnet mask must match
Authentication must match
Stub flags much match
MTU values must match
6. If the neighbor already exists reset the dead time. If the neighbor does not exist move onto step 7. **2-WAY STATE**
7. Master/Slave determination on who sends the Database Description (DBD) first. Highest priority wins. If there is a tie highest Router-ID wins **EXSTART STATE**
8. Master sends the DBD to the Slave then Slave sends DBD to the Master. **EXCHANGE STATE**
9. DBD are received & acknowledged. **LOADING STATE**
Slave requests further details to Master Link State Request (LSR)
Master responses by sending the Link State Update (LSU)
Master requests further details to Master Link State Request (LSR)
Slave responses by sending the Link State Update (LSU)
10. Neighbors are formed and are now ready to run the Shortest Path First Algorithm **FULL**
Electing a DR and BDR and Setting Priority
To elect a DR and BDR, the routers view the OSPF priority value of the other routers during the hello packet exchange process and then use the following conditions to determine which router to select:
1. The router with the highest priority value is the DR.
2. The router with the second-highest priority value is the BDR.
3. The default for the interface OSPF priority is 1. In case of a tie, the router ID is used.
The router with the highest router ID becomes the DR. The router with the second highest router ID becomes the BDR.
4. A router with a priority of 0 cannot become the DR or BDR. A router that is not the DR or BDR is a DROTHER.
5. If a router with a higher priority value gets added to the network, it does not preempt the DR and BDR. The only time a DR or BDR changes is if one of them goes out of service. If the DR is out of service, the BDR becomes the DR, and a new BDR is selected. If the BDR is out of service, a new BDR is elected.
The BDR does not perform any DR functions when the DR is operating. Instead, the BDR receives all the information, but the DR performs the LSA forwarding and LSDB synchronization tasks. The BDR performs the DR tasks only if the DR fails.
To determine whether the DR is out of service, the BDR uses the wait timer. This timer is a reliability feature.
It is important to remember that the DR concept is at the link level (each broadcast domain has is own DR/BDR).
Router(config)#interface FastEthernet 0/0affect which router interfaces on a multiaccess link are the DR and the BDR. The default priority is 1, and the range is from 0 to 255. The highest priority interface becomes the DR, and the secondhighest priority interface becomes the BDR. Any interfaces set to 0 priority cannot be involved in the DR or BDR election process.
Router(config-if)# ip ospf priority 10
Configuring and Verifying Advanced OSPF Features
1. Passive interface
R(config-router)# passive-interface <type> <number> [default]Prevents routing updates from being sent through the specified router
interface. This command can be used with all IP-based routing protocols except BGP.
passive-interface defaultSet all interfaces to passive by default. To enable routing on individual interfaces where you require adjacencies to be established, use the no passive-interface command.
2. Propagating an OSPF Default Route
OSPF routers do not, by default, generate a default route into the OSPF domain.
For OSPF to generate a default route, you must use the command
! router already has a default routeWhenever the default-information originate command (or redistribution into OSPF) is configured on an OSPF router, the router becomes an ASBR.
default-information originate
! advertise 0.0.0.0 regardless of whether the advertising router already has a default route
default-information originate
default-information originate [always] [metric metric-value] [metric-type type-value] [route-map map-name]3. Configuring OSPF Route Summarization
always (optional) - advertises the default route regardless of whether the router has a default route in the routing table
metric - if you omit a value and do not specify a value using the default-metric router configuration command, the default metric value is 1.
metric type - 1—Type 1 external route, 2—Type 2 external route (default)
Route summarization can be configured so that only summarized routes propagate into the backbone (area 0).
Route summarization helps to solve two OSPF issues: large routing tables and frequent LSA flooding throughout the autonomous system.
The two types of summarization are as follows:
■ Interarea route summarization— occurs on ABRs and applies to routes from within each area. It does not apply to external routes injected into OSPF via redistribution. Network numbers within areas should be assigned contiguously so that these addresses can be summarized into a minimal number of summary addresses.
area <area-id> range <address> <mask> [advertise| not-advertise] [cost cost]■ External route summarization—is specific to external routes that are injected into OSPF via route redistribution. Again, it is important to ensure the contiguity of the external address ranges that are being summarized. Generally, only ASBRs summarize external routes.
R1(config)#router ospf 100
R1(config-router)# network 172.16.32.1 0.0.0.0 area 1
R1(config-router)# area 1 range 172.16.32.0 255.255.224.0
Area 1 range 172.16.32.0 255.255.224.0—Identifies area 1 as the area containing
the range of networks to be summarized.
summary-address <ip-address mask> [not-advertise] [tagtag]
router ospf 100
summary-address 172.16.32.0 255.255.224.0