- itcertnotes -: ospf

Showing posts with label ospf. Show all posts

Sunday, January 8, 2012

When OSPF Becomes a Distance Vector Routing Protocol

In this final section of OSPF main text we revisit some basic and important concepts of OSPF. We were always being told that OSPF is a fast converging loop-free link-state routing protocol. However, to be precise, OSPF is a link-state routing protocol only within an area (intra-area); but almost a distance-vector routing protocol between areas (inter-area).

OSPF requires all traffic between non-backbone areas to pass through the backbone area. The reason behind this leads us back to the fundamental concepts of OSPF.

Every OSPF router floods information about its links, and its neighbors to other OSPF routers. Each router then builds an identical link-state database based on the flooded information, and then independently runs the SPF calculation upon its LSDB to derive the SPF tree, which is sort of a map of shortest paths to other routers (local calculation using distributed information).

One of the advantages of LS protocols is that the LSDB provides a “view” of the entire network, which in turn able to prevent most routing loops. This is in contrast to DV protocols, in which routing information is being propagated on a hop-by-hop basis throughout the network, and a calculation is performed at each hop (distributed calculation using local information). Each router along a path is dependent on the router before it to perform its calculations correctly and then pass along the results. When a router advertises the routing information it learnt to its neighbors, it is basically saying “I know how to reach these destinations.”. Since every DV router knows only what its neighbors tell it, and has no “view” of the network beyond their neighbors, the protocol is vulnerable to loops.

Those were the days when memory resources and CPU processing power were limited; it became a scaling problem when a link-state routing domain grew larger with a large number of routers, and large size of the LSDBs. The problem is solved by partitioning the routing domain into areas. The flooding occurs within the boundary of an area, and the LSDBs contain only information from other routers within the area. This means that the SPF tree on each router only describes only the paths to other routers within an area; and there are separate LSDBs for different areas.

OSPF areas are connected by one or more area border routers (ABRs) which maintain separate LSDBs and calculate separate SPF trees for each area that they reside in. An ABR is a member of multiple areas. It advertises the prefixes it learnt in an area to other areas by flooding Type-3 LSAs into those areas which basically saying “I know how to reach these destinations.”.
Note: Another main LS protocol – IS-IS, connects areas somewhat differently.

The last concept described earlier is not link-state, it is distance-vector! The routers in an area have no “view” beyond the ABR, and rely upon the ABR to tell them the prefixes it can reach. The SPF calculation on the routers within an area derives a SPF tree that depicts all prefixes beyond the ABR as leaf subnets connected to the ABR with some specified costs.

This leads us to the answer to the question why OSPF requires all traffic between non-backbone areas to pass through the backbone area in a hub-and-spoke topology. Because inter-area OSPF is distance-vector, it is vulnerable to routing loops. Hence OSPF specifies that traffic from one area can only reach another area through the backbone area in order to maintain a loop-free inter-area routing topology, in which no loops will be formed between the areas.

Jeff Doyle, the author of the Routing TCP/IP series, had involved in many discussions regarding the scalability of OSPF. He came across a single-area OSPF network with over 1000 routers, yet still operates without any performance or memory problem. Always design OSPF networks with the single-area mindset and add non-backbone areas only when they are really necessary. Defending a single-area design is a matter of convincing that multiple areas are not necessary.
A cardinal rule of network design is to start as simple as possible and then add complexities only when they are the simplest solution to an identified problem. – Jeff Doyle.

Suboptimal routing can occurs in OSPF area routing due to the fact that an internal router not in the destination area will use the routing path via the first segment (ABR) to the destination area.

Suboptimal OSPF Inter-Area Routing

The figure above shows a sample OSPF network with high-speed high-capacity links (OSPF cost 1), in the backbone area, and low-speed low-capacity links (OSPF cost 4) in Area 1. When all routers and links reside in a single area, plain shortest path routing will follow the backbone as much as possible; therefore the traffic from RT1 to 192.168.1.0/24 behinds RT7 will follow the route: RT1 – RT2 – RT3 – RT7.

However, due to inter-area routing and RT1 does not reside in the destination area (Area 1), RT2 will route traffic via RT6 when the traffic arrives at RT2, as it resides in the destination area. The routing path will be changed to RT1 – RT2 – RT6 – RT7; even it has higher accumulated OSPF path cost than the optimal path (13 against 10)!

OSPF Virtual Links

The OSPF 2-tier or 2-layer area hierarchical structure requires that all areas to be directly connected to the backbone area; and the backbone area must be contiguous or else some OSPF areas in the OSPF routing domain will be unreachable. However, the backbone area needs not to be physically contiguous; backbone connectivity can be established and maintained using a logical OSPF virtual link between 2 ABRs. Virtual links belong to the backbone area.
Note: The next section explains why all OSPF areas must be connected to the backbone area.

OSPF Virtual Links

The idea of a OSPF virtual link is to extend the backbone area across non-backbone area. OSPF virtual links are part of the OSPF open standard and are often being implemented to:
i) Connect a disconnected area to the backbone area through a non-backbone area.
ii) Connect the 2 separate parts of a partitioned or discontiguous backbone area through a non-backbone area.
The non-backbone area through which a virtual link is configured is known as a transit area. A transit area must have full routing information and cannot be a stub area. However, a GRE tunnel can be used instead of a virtual link to encapsulate native OSPF packets across a stub area.

Note: OSPF virtual links should only be used as temporary connections to fix unavoidable network topology problems and should not be part of an initial OSPF network design. A virtual link shows the part of a network that requires review and reengineering. Permanent virtual links show a sign of poorly designed network, as well as add a layer of complexity and troubleshooting difficulty to any network. We should avoid them by ensuring that backbone areas are designed with redundant links to prevent partitioning. When merging networks, sufficient planning is important to make sure all areas are directly link to the backbone area.

An OSPF virtual link is similar to a standard OSPF adjacency; with the exception that the routers do not have to be directly connected on the same network segment to form an adjacency. A virtual link is interpreted as a point-to-point unnumbered connection.

The OSPF Hello mechanism works in the same way for both standard and virtual links, in which Hellos are sent out in every 10 seconds. The LSA updates work differently over virtual links. An LSA usually being refreshed every 30 minutes; however, an LSA learnt through a virtual link have the DoNotAge (DNA) bit set, which means that it is not aged out when held in the LSDB. The DNA mechanism suppresses the periodic LSA refresh reflooding over a virtual link.

The area {area-id} virtual-link {router-id} [authentication [message-digest | null]] [hello-interval sec] [retransmit-interval sec] [transmit-delay sec] [dead-interval sec] [authentication-key auth-key | message-digest-key key-id md5 key] OSPF router subcommand defines an OSPF virtual link. It must include the transit area ID (either a decimal value or dotted-decimal notation similar to an IP address) and the Router ID of the corresponding virtual link neighbor to properly configure a virtual link. Utilize the show ip ospf EXEC command to ensure the correct Router ID configuration.

Below describes the parameters available for the area area-id virtual-link router-id command:

Parameter	Description
area-id	Specifies an area as the transit area for the virtual link. It can be either a decimal value or in dotted-decimal notation format as like an IP address.
router-id	Specifies the Router ID of the virtual link neighbor.
authentication	Specifies an authentication type.
retransmit-delay	Specifies the interval between LSA retransmissions for adjacencies belonging to the interface. The value must be greater than the expected round-trip delay between any 2 routers on the attached network. The default value is 5 seconds.
transmit-delay	Specifies the estimated time to send an LSU packet out an interface. Its value must be greater than 0. The LSAge of the LSAs in the LSU packets will be incremented by this value before transmission. The default value is 1 second.
authentication-key	Specifies the password used for simple password authentication. The password is a continuous string up to 8 characters.
message-digest-key	Specifies the key ID and key (password) for MD5 authentication. The key is a continuous string up to 16 characters.

Network Setup for Disconnected OSPF Area

The figure above shows a typical OSPF network and 2 network setups of disconnected OSPF areas when the link between RT1 and RT3 fails. 2 configuration options are available to connect the disconnected OSPF area back to the backbone area.

Below shows the routing table and OSPF LSDB on RT1 after a virtual link is configured on RT1 and RT3 for the scenario shown on Figure 10-8a:

RT1#sh ip route

Gateway of last resort is not set

     23.0.0.0/24 is subnetted, 1 subnets
O       23.23.23.0 [110/74] via 12.12.12.2, 00:00:47, Serial0/0
C    192.168.0.0/24 is directly connected, FastEthernet1/0
     12.0.0.0/24 is subnetted, 1 subnets
C       12.12.12.0 is directly connected, Serial0/0
O    192.168.1.0/24 [110/74] via 12.12.12.2, 00:00:47, Serial0/0
O IA 192.168.2.0/24 [110/84] via 12.12.12.2, 00:00:37, Serial0/0
RT1#
RT1#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           0   FULL/  -           -        23.23.23.3      OSPF_VL0
2.2.2.2           0   FULL/  -        00:00:38    12.12.12.2      Serial0/0
RT1#
RT1#sh ip ospf virtual-links
Virtual Link OSPF_VL0 to router 3.3.3.3 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 1, via interface Serial0/0, Cost of using 74
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:02
    Adjacency State FULL (Hello suppressed)
    Index 1/1, retransmission queue length 0, number of retransmission 1
    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
    Last retransmission scan length is 1, maximum is 1
    Last retransmission scan time is 0 msec, maximum is 0 msec
RT1#
RT1#sh ip ospf database

            OSPF Router with ID (1.1.1.1) (Process ID 100)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         46          0x80000002 0x00151D 2
3.3.3.3         3.3.3.3         5     (DNA) 0x80000002 0x00D8A8 1

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
12.12.12.0      1.1.1.1         319         0x80000001 0x003C98
12.12.12.0      3.3.3.3         6     (DNA) 0x80000001 0x00645E
23.23.23.0      1.1.1.1         128         0x80000003 0x000F98
23.23.23.0      3.3.3.3         6     (DNA) 0x80000001 0x00548D
192.168.1.0     1.1.1.1         309         0x80000001 0x0095EE
192.168.1.0     3.3.3.3         6     (DNA) 0x80000001 0x003B77
192.168.2.0     3.3.3.3         6     (DNA) 0x80000001 0x00CBEF

--- output omitted ---

Below shows the routing table and OSPF LSDB on RT1 after a virtual link is configured on RT1 and RT2 for the scenario shown on Figure 10-8b:

RT1#sh ip route

Gateway of last resort is not set

     23.0.0.0/24 is subnetted, 1 subnets
O IA    23.23.23.0 [110/74] via 12.12.12.2, 00:00:34, Serial0/0
C    192.168.0.0/24 is directly connected, FastEthernet1/0
     12.0.0.0/24 is subnetted, 1 subnets
C       12.12.12.0 is directly connected, Serial0/0
O    192.168.1.0/24 [110/74] via 12.12.12.2, 00:00:44, Serial0/0
O IA 192.168.2.0/24 [110/84] via 12.12.12.2, 00:00:34, Serial0/0
RT1#
RT1#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -           -        12.12.12.2      OSPF_VL0
2.2.2.2           0   FULL/  -        00:00:39    12.12.12.2      Serial0/0
RT1#
RT1#sh ip ospf virtual-links
Virtual Link OSPF_VL0 to router 2.2.2.2 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 1, via interface Serial0/0, Cost of using 64
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:05
    Adjacency State FULL (Hello suppressed)
    Index 1/1, retransmission queue length 0, number of retransmission 1
    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
    Last retransmission scan length is 1, maximum is 1
    Last retransmission scan time is 0 msec, maximum is 0 msec
RT1#
RT1#sh ip ospf database

            OSPF Router with ID (1.1.1.1) (Process ID 100)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         43          0x80000002 0x003E02 2
2.2.2.2         2.2.2.2         5     (DNA) 0x80000002 0x00D4E0 1

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
12.12.12.0      1.1.1.1         358         0x80000001 0x003C98
12.12.12.0      2.2.2.2         6     (DNA) 0x80000001 0x001EB2
23.23.23.0      2.2.2.2         6     (DNA) 0x80000001 0x007273
192.168.1.0     1.1.1.1         348         0x80000001 0x0095EE
192.168.1.0     2.2.2.2         6     (DNA) 0x80000001 0x00F4CB
192.168.2.0     2.2.2.2         6     (DNA) 0x80000001 0x004E67

--- output omitted ---

Note: OSPF does not require that the Router ID IP address to be existed in the IP routing table. As a result, the Router ID configured in the area virtual-link command may not be pingable, but the virtual link still work.

Network Setup for Partitioned Backbone Area

The figure above shows a sample implementation of OSPF virtual link – RT2 which resides in Area 0 has failed and the routers within the OSPF routing domain have lost their network connectivity. Note: OSPF virtual links should only be used as temporary connections to fix unavoidable network topology problems.

Below shows the output of the show ip ospf neighbor and show ip ospf virtual-links EXEC commands on RT4 upon configured the OSPF virtual link:

RT4#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
6.6.6.6           0   FULL/  -           -        56.56.56.6      OSPF_VL0
1.1.1.1           1   FULL/BDR        00:00:38    14.14.14.1      FastEthernet0/0
5.5.5.5           0   FULL/  -        00:00:39    45.45.45.5      Serial1/0
RT4#
RT4#sh ip ospf virtual-links
Virtual Link OSPF_VL0 to router 6.6.6.6 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 1, via interface Serial1/0, Cost of using 128 ^[1]
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:02
    Adjacency State FULL (Hello suppressed)
    Index 2/3, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec
RT4#

[1] – The cost to reach the virtual link neighbor through the intra-area path; it cannot be configured.

Note: Configure authentication on a virtual link when the backbone area 0 is using authentication!
A virtual link is really an extension of the backbone area; if the backbone area is running authentication, the virtual link must be configured for authentication as well.

A virtual link is treated as an unnumbered point-to-point network that belongs to the backbone and joins the 2 area border routers. An adjacency will be established over the virtual link. When the adjacency is established, the virtual link will be included in backbone router-LSAs, and OSPF packets belong to the backbone area will flow over the adjacency – virtual adjacency.

Note: When configuring a virtual link over an interface which has the maximum OSPF cost – 65536 or 0xffff, the virtual link will not come up. RFC 2328 – OSPF Version 2 quotes that a virtual link whose underlying path has cost greater than hexadecimal 0xffff (the maximum size of an interface cost in a router-LSA) should be considered inoperational.

Saturday, January 7, 2012

OSPF Default Route

OSPF generates and advertises default route (0.0.0.0/0) varies upon the OSPF area types that the default route is being advertised into – a standard area, stubby area, totally-stubby area, NSSA, or totally-stubby NSSA.

By default, OSPF routers in standard areas do not generate default routes into OSPF domains. The default-information originate [always] [metric metric] [metric-type metric-type] [route-map map] OSPF router subcommand configures an OSPF router to become an ASBR and generates an External Type-2 (E2) default route with 0.0.0.0 as the Link-State ID and Network Mask, with 1 as the default metric value. It is recommended to advertise OSPF default routes as E2 routes, in which the internal cost or metric towards the ASBR will not be considered when comparing E2 routes. This is important when implementing a primary-backup default routing setup, as the internal cost or metric towards the ASBR will not affect the route selection.
Note: The Cisco IOS Command Reference for the default-information originate command mentions that the default metric value is 10, while testing shows that it is actually 1.

If the ASBR has a default route in its routing table, the default route can be redistributed into the OSPF routing domain with the default-information originate OSPF router subcommand. If the ASBR does not have a default route in its routing table, the always keyword can be added to the default-information originate command to redistribute a default route into the OSPF routing domain regardless of whether the router has a default route in its routing table.

Another benefit of the always keyword is that it can add stability to the OSPF routing domain, in which an OSPF router will always advertise a default route regardless of the stability of the default route that could be learnt through other routing domains.

Whether to use the always keyword is depends upon the design of the network.
Ex: When an OSPF router has a non-OSPF external default route (static or dynamically-learnt) towards the Internet, it should advertise the default route only when it has the default route itself. Otherwise it could attract and blackhole the traffic from other routers.

Note: Configure a static default route with the ip route 0.0.0.0 0.0.0.0 {gateway} global configuration command and try to redistribute the static route into an OSPF domain with the redistribute static subnets OSPF router command is unable to generate a default route!
Note: The default route selected using the ip default-network global configuration command is not propagated by OSPF.

OSPF Default Route on Standard OSPF Area

Below shows the routing table on RT3:

RT3#sh ip route

Gateway of last resort is 11.11.11.1 to network 0.0.0.0

     10.0.0.0/30 is subnetted, 1 subnets
O IA    10.10.10.0 [110/128] via 11.11.11.1, 00:00:01, Serial0/0
     11.0.0.0/30 is subnetted, 1 subnets
C       11.11.11.0 is directly connected, Serial0/0
O*E2 0.0.0.0/0 [110/1] via 11.11.11.1, 00:00:01, Serial0/0
RT3#

In stubby and totally stubby areas, the ABR of the stub area generates a Type-3 Network-Summary-LSA with Link-State ID and Network Mask of 0.0.0.0 into the stub area. The ABR does not need to have a default route in its routing table; and it does not require the default-information originate OSPF router subcommand to be configured as well.

The ABR of an NSSA does not generate a default route by default. The area {area-id}nssa default-information-originate [metric metric] [metric-type metric-type] must be configured on the ABR to generate a Type-7 NSSA-External-LSA with Link-State ID and Network Mask of 0.0.0.0 into the NSSA.

Another way to generate a default route into an NSSA is the area {area-id} nssa no-summary OSPF router subcommand. As such, the NSSA becomes a totally stubby NSSA. The default route is automatically generated by an NSSA ABR into the totally stubby NSSA as a Type-3 Network-Summary-LSA without the default-information-originate keyword of the area {area-id} nssa OSPF router subcommand.

When a stub area has multiple ABRs (or exit points), it is important to ensure the stub routers select the desired ABR to reach the networks outside the stub area. The default route metrics should be identical on all ABRs when the stub routers are allowed to choose the closest ABR; while the ABRs should have different default route metrics (configured with the area {area-id} default-cost {cost} router subcommand) when implementing a primary-backup ABRs setup.

Sunday, January 1, 2012

OSPF Stub Areas

The characteristics of an OSPF area determine the types of routing information it will receive. The main purpose behind all types of stub areas is to inject a default route into an area so that the external (and summary) LSAs are not flooded into the area. Replacing multiple external routes with a single default route reduces the size of LSDBs and routing tables in the OSPF routers within the stub area, reduces the memory requirements for OSPF routers within the stub area, and the OSPF routers run fewer SPF calculations as they will receive lesser routing updates.

Below describes the possible OSPF area types and their characteristics:

Standard area	Accepts Type-1 and Type-2 link info updates, Type-3 and Type-4 summary routes, and Type-5 external routes.
Backbone area or transit area	The central entity to which all other areas connect. All other areas connect to this area to exchange routing information. The OSPF backbone area has all the properties of an OSPF standard area.
Stubby area	Doesn’t accept external routes (Type-4 and Type-5 LSAs) from other autonomous systems (via route redistribution). The OSPF routers within a stubby area use the default route as indicated as 0.0.0.0 to route packets to networks outside the autonomous system. Stubby areas cannot contain ASBRs; however, the ABR may be an ASBR.
Totally Stubby area	A Cisco-proprietary feature that further minimizes routing information than stubby area by filtering Type-4 and Type-5 LSAs, and Type-3 Net-Summary-LSAs from other areas within the autonomous system.
Not-So-Stubby-Area (NSSA)	NSSA is defined in RFC 3101 as an addendum to the OSPF RFCs. The OSPF NSSA offers the benefits that are similar to the stubby area. However, NSSA allows ASBRs (by introducing the Type-7 NSSA-External-LSA), which against the rules of OSPF stub area.
Not-So-Stubby-Totally-Stubby Area	Combines the characteristics of totally stubby area and NSSA – does not accept Type-3, Type-4, and Type-5 LSAs; allows ASBRs.

An OSPF area is qualified as a stubby or totally stubby area if it has the following characteristics:
i) There is a single exit point (ABR) from the area; or if there are multiple exit points, multiple ABRs inject default route into the stub area and suboptimal routing is acceptable – routing to other areas or autonomous systems can take a suboptimal path to reach the destination network by exiting the stub area via an exit point that is farther from the destination than other exit points.
ii) The area is not needed as a transit area for virtual links.
iii) The area is not the backbone area.
iv) No ASBR is inside the stubby or totally stubby area.
v) All OSPF routers (internal routers and ABRs) within the stub area must be configured as stub routers for them to become neighbors and exchange routing information. The Hello packets exchanged between the routers will have the stub flag set – the E bit (ExternalRoutingCapability) of the Options field is set to 0.

Note: The ABR of a stub area generates a default route into the stub area regardless of whether it has a default route or received any external route from other ASBR resides in the standard area. A stub router selects the closest ABR as the gateway to reach networks outside the stub area.

OSPF Stubby Area

Below shows the routing table and OSPF LSDB on RT4:

RT4#sh ip route

Gateway of last resort is 12.12.12.1 to network 0.0.0.0

     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.1.0 [110/193] via 12.12.12.1, 00:00:24, Serial0/0
     10.0.0.0/30 is subnetted, 1 subnets
O IA    10.10.10.0 [110/192] via 12.12.12.1, 00:00:24, Serial0/0
     11.0.0.0/30 is subnetted, 1 subnets
O IA    11.11.11.0 [110/128] via 12.12.12.1, 00:00:30, Serial0/0
     12.0.0.0/30 is subnetted, 1 subnets
C       12.12.12.0 is directly connected, Serial0/0
O*IA 0.0.0.0/0 [110/65] via 12.12.12.1, 00:00:30, Serial0/0
RT4#
RT4#sh ip ospf database

            OSPF Router with ID (12.12.12.2) (Process ID 100)

--- output omitted ---

                Summary Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         3.3.3.3         40          0x80000001 0x0057DA
10.10.10.0      3.3.3.3         26          0x80000001 0x00D6C0
11.11.11.0      3.3.3.3         36          0x80000001 0x0030A4
172.16.1.0      3.3.3.3         26          0x80000001 0x00CB28
RT4#

The ABR of a stubby or totally stubby area advertises a default route with a cost of 1 by default.
The area {area-id} default-cost {cost} router subcommand changes the cost of the default route.

OSPF Totally Stubby Area

Below shows the routing table and OSPF LSDB on RT4, and the excerpt of show ip ospf on RT3:

RT4#sh ip route

Gateway of last resort is 12.12.12.1 to network 0.0.0.0

     12.0.0.0/30 is subnetted, 1 subnets
C       12.12.12.0 is directly connected, Serial0/0
O*IA 0.0.0.0/0 [110/65] via 12.12.12.1, 00:00:32, Serial0/0
RT4#
RT4#sh ip ospf database

            OSPF Router with ID (12.12.12.2) (Process ID 100)

--- output omitted ---

                Summary Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         3.3.3.3         42          0x80000001 0x0057DA
RT4#
======================================================================
RT3#sh ip ospf
--- output omitted ---
    Area 2
        Number of interfaces in this area is 1
        It is a stub area, no summary LSA in this area
          generates stub default route with cost 1
--- output omitted ---
RT3#

RT4 is configured with the area {area-id} stub command without the no-summary keyword. The no-summary keyword only required to be configured on the ABR of a totally stubby area to stop the ABR from propagating summary LSAs into the totally stubby area.

OSPF Not-So-Stubby-Area (NSSA)

OSPF Not-So-Stubby-Area (NSSA) is defined in RFC 3101 – The OSPF Not-So-Stubby Area (NSSA) Option as an addendum to the official OSPF Request for Comments (RFC). It is a non-proprietary extension upon the OSPF stub area feature that allows ASBRs in a stub area and therefore allows the injection of external routes into the stub area in a limited fashion. The NSSA retains the main feature of stub areas – the NSSA ABR generates a default route into the NSSA instead of external routes originated from other ASBRs.

An ASBR within an NSSA originates Type-7 NSSA-External-LSA upon route redistribution. All fields of the NSSA-External-LSA and AS-External-LSA are identical except the Forward Address field. AS-External-LSAs are flooded throughout an OSPF routing domain; while NSSA-External-LSAs are flooded only within the NSSA in which it was originated. The show ip ospf database nssa-external EXEC command displays NSSA-External-LSAs.

When an NSSA ASBR generates a Type-7 NSSA-External-LSA, the NSSA ABR with the highest Router ID among the NSSA ABRs (when there are multiple NSSA ABRs) translates the Type-7 LSA to a Type-5 LSA and propagates it throughout the OSPF routing domain.

Type-7 NSSA-External-LSAs are denoted as O N2 or O N1 in the IP routing table. The metrics of N1 and N2 are calculated as like E1 Type-1 and E2 Type-2 external routes respectively.

The area area-id nssa [default-information-originate [metric metric] [metric-type metric-type]] [no-redistribution] [no-summary] OSPF router subcommand is used instead of the area area-id stub OSPF router subcommand to configure an NSSA OSPF router. All OSPF routers (internal routers and ABRs) within an NSSA must be configured as NSSA routers for them to become neighbors and exchange routing information. The Hello packets exchanged between the routers will have the NSSA flag (the N bit in the Options field) set to 1.

The default-information-originate keyword generates a Type-7 default route into an NSSA. This keyword takes effect only on an NSSA ASBR or NSSA ABR. An NSSA ASBR can generate a default route only when it has a default route in its routing table; while an NSSA ABR can generate a default route with or without a default route in its routing table.

The no-summary keyword of the area {area-id} nssa OSPF router subcommand prevents summary routes from being advertised into an NSSA – it becomes a Totally Stubby NSSA or Not-So-Stubby-Totally-Stubby area. This keyword takes effect only on an NSSA ABR. A single default route would replace both external and summary routes into an NSSA.
Note: When no-summary is configured, the default-information-originate keyword is not required for the ABR on a totally stubby NSSA to generate a default route into the area.

The no-redistribution keyword is used in situations where there is no need to redistribute external routes into an NSSA as Type-7 LSAs, eg: when an NSSA ASBR is also an NSSA ABR.

An ABR in an NSSA never originate Type-4 ASBR-Summary-LSA for the ASBR in the NSSA, as Type-7 NSSA-External-LSA never flooded beyond the border of the NSSA.

The totally stubby and No-So-Stubby-Totally-Stubby configurations are Cisco-proprietary features. Type-3 Network-Summary-LSAs (from other areas) are not flooded into both types of stub areas.

Routers in stub area can only establish adjacencies with routers in stub or totally stubby area; while routers in NSSA can only establish adjacencies with the routers in NSSA or totally NSSA.

OSPF Not-So-Stubby-Area (NSSA)

Below shows the routing table and OSPF LSDB on RT1:

RT1#sh ip route

Gateway of last resort is 10.10.10.2 to network 0.0.0.0

     20.0.0.0/30 is subnetted, 1 subnets
C       20.20.20.0 is directly connected, Serial0/0
     10.0.0.0/30 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, Serial0/1
     11.0.0.0/30 is subnetted, 1 subnets
O IA    11.11.11.0 [110/128] via 10.10.10.2, 00:00:56, Serial0/1
S    192.168.1.0/24 [1/0] via 20.20.20.1
O*N2 0.0.0.0/0 [110/1] via 10.10.10.2, 00:00:57, Serial0/1
RT1#
RT1#sh ip ospf database

            OSPF Router with ID (1.1.1.1) (Process ID 100)

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         67          0x80000002 0x006BE5 2
2.2.2.2         2.2.2.2         69          0x80000001 0x00103C 2

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
11.11.11.0      2.2.2.2         64          0x80000001 0x00D5FA

                Type-7 AS External Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         2.2.2.2         69          0x80000001 0x00D0D8 0
192.168.1.0     1.1.1.1         68          0x80000001 0x00EF19 0
RT1#

Below shows the routing table and OSPF LSDB on RT2 and RT3:

RT2#sh ip route

Gateway of last resort is not set

     10.0.0.0/30 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, Serial0/0
     11.0.0.0/30 is subnetted, 1 subnets
C       11.11.11.0 is directly connected, Serial0/1
O N2 192.168.1.0/24 [110/20] via 10.10.10.1, 00:00:55, Serial0/0
RT2#
RT2#sh ip ospf
--- output omitted ---
    Area 1
        It is a NSSA area
        Perform type-7/type-5 LSA translation
        generates NSSA default route with cost 1
--- output omitted ---
RT2#sh ip ospf database
--- output omitted ---

                Type-7 AS External Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         2.2.2.2         70          0x80000001 0x00D0D8 0
192.168.1.0     1.1.1.1         71          0x80000001 0x00EF19 0

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
192.168.1.0     2.2.2.2         64          0x80000001 0x0066A8 0
RT2#
======================================================================
RT3#sh ip route

Gateway of last resort is not set

     10.0.0.0/30 is subnetted, 1 subnets
O IA    10.10.10.0 [110/128] via 11.11.11.1, 00:00:57, Serial0/0
     11.0.0.0/30 is subnetted, 1 subnets
C       11.11.11.0 is directly connected, Serial0/0
O E2 192.168.1.0/24 [110/20] via 11.11.11.1, 00:00:57, Serial0/0
RT3#sh ip ospf database

            OSPF Router with ID (3.3.3.3) (Process ID 100)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         73          0x80000001 0x000144 2
3.3.3.3         3.3.3.3         67          0x80000002 0x0095AC 2

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.0      2.2.2.2         68          0x80000001 0x005485

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
192.168.1.0     2.2.2.2         66          0x80000001 0x0066A8 0
RT3#

OSPF Totally Stubby NSSA

Below shows the routing table and OSPF LSDB on RT1:

RT1#sh ip route

Gateway of last resort is 10.10.10.2 to network 0.0.0.0

     20.0.0.0/30 is subnetted, 1 subnets
C       20.20.20.0 is directly connected, Serial0/0
     10.0.0.0/30 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, Serial0/1
S    192.168.1.0/24 [1/0] via 20.20.20.1
O*IA 0.0.0.0/0 [110/65] via 10.10.10.2, 00:00:10, Serial0/1
RT1#
RT1#sh ip ospf database

            OSPF Router with ID (1.1.1.1) (Process ID 100)

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         24          0x80000002 0x006BE5 2
2.2.2.2         2.2.2.2         28          0x80000001 0x00103C 2

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         2.2.2.2         28          0x80000001 0x00FC31

                Type-7 AS External Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Tag
192.168.1.0     1.1.1.1         26          0x80000001 0x00EF19 0
RT1#

OSPF Stubby Area Types

Friday, December 30, 2011

OSPF Route Summarization and Filtering

Route summarization consolidates multiple routes into a single summary route. Proper route summarization planning and implementation directly affects the amount of bandwidth, CPU, and memory resources consumed by routers.

Without route summarization, every inter-area LSA (Type-3, Type-4, and Type-5) is propagated by ABRs throughout an OSPF domain, consuming additional bandwidth and router resources. Upon the flooding of an inter-area LSA, all affected OSPF routers must process the LSA and perform route computation to locate the lowest metric path to the ABR for the destination network (link up) or flush an MaxAge LSA (link down).

With route summarization, only the summary routes are being propagated by ABRs. Route summarization reduces unnecessary LSA flooding, reduces route re-computation upon topology changes, and increases network stability.

Below describes the 2 types of route summarization:

Inter-area route summarization	Occurs on ABRs and applies upon routes propagated between areas. Does not apply to external routes injected into OSPF via redistribution. To achieve effective inter-area route summarization, network numbers within areas should be assigned contiguously for the addresses to be summarized into a minimal number of summary addresses as possible.
External route summarization	Applies upon external routes injected into OSPF via redistribution. It is important to ensure the continuity of external address ranges that are being summarized. Summarizing overlapping address ranges from different ASBRs can cause packets to be forwarded through the wrong path. External addresses should be assigned contiguously as well.

OSPF Route Summarization on an ABR

Note: Always reconsider when summarizing networks in the backbone area to other areas. When there is more than 1 ABR between an area and the backbone area, propagating a Type-3 Network-Summary-LSA with the explicit network information into an area ensures that the shortest path to the destination outside the area will be selected and prevents suboptimal routing.

OSPF Route Summarization on an ASBR

The summary-address {{address mask} | {prefix mask}} [not-advertise] [tag tag] OSPF router subcommand configures a summary route for external routes on an OSPF ASBR. The not-advertise keyword suppresses the routes that match the prefix/mask pair.

Link-state routing protocols do not advertise routes, but advertise topology information instead. OSPF is a link-state routing protocol that relies upon the information in the topology database for route computation. All routers within an area must have the same and consistent topology information to make accurate routing decisions; the routers independently calculate the shortest paths to destination networks based on the topology information using the SPF algorithm.

OSPF route filtering within an area can be achieved using distribute lists (in conjunction with access lists, prefix lists, and route maps), or modifying the administrative distance.
Note: OSPF routers do not advertise routes; instead, they advertise LSAs. Any filtering applied upon OSPF LSU packets would need to filter the transmission of LSAs. Performing OSPF route filtering within an area does not affect routes as they enter the OSPF topology database, but the IP routing table instead; and on only the router on which the route filtering is configured. Additionally, it does not affect the propagation of LSAs from the router that performs route filtering – route filtering is local significant.
Note: Route filtering on link-state routing protocols often result in different routing tables (but same topology database) on routers, which would then introduce routing loops or routing black holes to the network.

The OSPF ABR Type-3 LSA Filtering feature extends the ability of OSPF ABRs to filter routes that are being propagated between OSPF areas. It allows only routes matched with specified prefixes to be sent from one area to another area and restricts all other routes. It can be applied out from an area, into an area, or both into and out of an area at the same time.

The main benefit of the OSPF ABR Type-3 LSA Filtering feature is provides improved control of route distribution between OSPF areas by filtering Type-3 LSAs originated from ABRs.

OSPF ABR Type-3 LSA Filtering

Below shows the routing table on RT1 and RT3 with route filtering configured on RT2:

RT2#sh ip ospf
--- output omitted ---
    Area BACKBONE(0)
--- output omitted ---
        Area-filter Area0-IN in
        Area-filter Area0-OUT out
--- output omitted ---
    Area 1
--- output omitted ---
        Area-filter Area1-IN in
--- output omitted ---

RT2#
======================================================================
RT1#sh ip route

--- output omitted ---
O IA 192.168.1.0/24 [110/3] via 10.10.10.2, 00:00:32, FastEthernet0/0
O IA 192.168.2.0/24 [110/3] via 10.10.10.2, 00:00:32, FastEthernet0/0
O IA 192.168.3.0/24 [110/3] via 10.10.10.2, 00:00:32, FastEthernet0/0
RT1#
======================================================================
RT3#sh ip route

--- output omitted ---
O IA    172.16.1.0 [110/3] via 11.11.11.1, 00:00:40, FastEthernet0/0
O IA    172.16.2.0 [110/3] via 11.11.11.1, 00:00:40, FastEthernet0/0
RT3#

Note: RT3 does not see 172.16.3.0/24 in its routing table. This is because the route was not advertised from Area 0 (Area0-OUT) even it is allowed to be advertised into Area 1 (Area1-IN).

The area area-id filter-list prefix prefix-name {in | out} OSPF router subcommand filters IP prefixes or subnets as advertised as Type-3 Network-Summary-LSAs between OSPF areas. The area-id is the identifier of the area for which route filtering is configured; it can be specified as either a decimal value or an IP address. The prefix keyword indicates that a prefix list is used. Prefixes that do not match any entry in the prefix list are implicitly denied.

The in direction applies upon the Type-3 LSAs originated by the ABR based on the information from other areas into the specified area; while the out direction applies upon the Type-3 LSAs originated by the ABR based on the information from the specified area to other areas. Eventually, the area filter-list command filters Type-3 LSAs from going in or out of an area. Filtering Type-3 LSAs between areas prevents the routes from entering the OSPF topology database and eventually prevents them from entering the routing table.

Type-3 LSAs that were originated as a result of the area range OSPF router subcommand are treated as ordinary Type-3 LSAs. When route summarization (area range) and route filtering (area filter-list) are implemented together on an OSPF router to propagate a summary route into an area (in direction), the summary route must be matched with an entry in the prefix list for it to be propagated into the area. While propagating a summarized route from an area (out direction), at least one prefix in the summarized area range must be matched with an entry in the prefix list for it to be propagated to other areas – if no subordinate routes exist, the ABR does not advertise the summary.

When the area range OSPF router subcommand is configured with the not-advertise keyword, both the summary route and component routes will not be advertised as Type-3 LSAs. As a result, it has the same effect as the area filter-list OSPF router subcommand with the out keyword, which filters the LSAs from originating from a specific area to other areas.

Component routes are also being referred to as subordinate routes – the routes whose address ranges are inside the range of addresses defined by the summary route.

Tuesday, December 27, 2011

Type-4 ASBR-Summary-LSA and Type-5 AS-External-LSA

Network Setup for Type-4 ASBR-Summary-LSA and Type-5 AS-External-LSA

Type-4 ASBR-Summary-LSAs are originated from an ABR that resides within the same area as the ASBR to identify the ASBR and describes the route to the ASBR. Type-5 LSAs are flooded to all areas but the detailed info to reach the ASBR may not be available throughout all areas. This problem is solved by having an ABR to describe the route to the ASBR that originated the Type-5 LSA. The Link-State ID of a Type-4 LSA is the Router ID of the ASBR.

Type-5 AS-External-LSAs are originated from an ASBR and contains information imported into an OSPF routing domain from other routing processes. Type-5 LSAs are flooded throughout all areas except stub areas, totally stubby areas, and NSSAs. When a stub router receives a Type-5 LSA from another router within the stub area, the LSA will be rejected.
The Link-State ID of a Type-5 LSA is the IP address of the external subnet that is being advertised.
MISC Note:
 Internal routes are always preferred over external routes.
 There is no Type-4 and Type-5 LSAs when there is no ASBR in an OSPF routing domain.
 All OSPF routers in a routing domain maintain the same Type-5 LSA in their LSDBs.
 All types of LSAs have area flooding scope (not flooded across area borders); expect Type-5 LSAs which have AS flooding scope (flooded throughout all areas).

OSPF Type-5 AS-External-LSA Format

Below lists the fields in the OSPF AS-External-LSA:

Field	Description
Network Mask	Indicates the subnet mask of the external network that is being advertised. Note: If the Type-5 LSA is advertising a default route, the Link-State ID and the Network Mask are both 0.0.0.0.
E (External Metric) bit	Indicates the type of external metric for the advertised external route. If the E bit is set to 1, the metric type is E2; else the metric type is E1. E2 is the default route type for routes learnt via route redistribution.
Metric	Indicates the cost of the external route as set by the ASBR.
Forwarding Address	Indicates the destination IP address to which the packets for the advertised external network should be forwarded. If the Forwarding Address is 0.0.0.0, the packets are forwarded to the originating ASBR. The Forwarding Address will be non-zero in the following situations to avoid suboptimal routing: - OSPF is enabled on the ASBR’s next-hop interface - The ASBR’s next-hop interface is non-passive to OSPF - The ASBR’s next-hop interface network type is not point-to-point or point-to-multipoint - The ASBR’s next-hop interface address falls into the OSPF network range Note: The route to the non-zero Forwarding Address must be known via an intra-area or inter-area route; or else the external route will not be installed into the routing table!
External Route Tag	Indicates an arbitrary tag that may be applied upon the external route. It is not being used by OSPF itself, but is instead provides external route management using route maps.

Below lists the criteria for an OSPF router to install an AS-External-LSA into its routing table:
i) The router must be able to reach the ASBR through an intra-area or inter-area route, which means that there must be a Type-1 Router-LSA or Type-4 ASBR-Summary-LSA generated for the ASBR.
ii) The Forwarding Address must be known via an intra-area or inter-area route.

A default seed metric of 1 will be used for redistributed BGP routes; while a default seed metric of 20 will be used for routes redistributed from other routing protocols, including static routes and directly connected interfaces. The seed metric is a starting metric for redistributed routes.

Below shows the routing table, as well as Type-4 ASBR-Summary-LSA and Type-5 AS-External-LSAs received on RT4:

RT4#sh ip route

Gateway of last resort is not set

     20.0.0.0/30 is subnetted, 1 subnets
O IA    20.20.20.0 [110/128] via 30.30.30.1, 00:00:45, Serial0/0
     10.0.0.0/30 is subnetted, 1 subnets
O E2    10.10.10.0 [110/20] via 30.30.30.1, 00:00:35, Serial0/0
O E2 192.168.1.0/24 [110/20] via 30.30.30.1, 00:00:35, Serial0/0
     30.0.0.0/30 is subnetted, 1 subnets
C       30.30.30.0 is directly connected, Serial0/0
RT4#
RT4#sh ip ospf database asbr-summary

            OSPF Router with ID (44.44.44.44) (Process ID 100)

                Summary ASB Link States (Area 1)

  Routing Bit Set on this LSA
  LS age: 45
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(AS Boundary Router)
  Link State ID: 22.22.22.22 (AS Boundary Router address)
  Advertising Router: 33.33.33.33
  LS Seq Number: 80000001
  Checksum: 0x24FA
  Length: 28
  Network Mask: /0
        TOS: 0  Metric: 64

RT4#
RT4#sh ip ospf database external

            OSPF Router with ID (44.44.44.44) (Process ID 100)

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 57
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.10.10.0 (External Network Number )
  Advertising Router: 22.22.22.22
  LS Seq Number: 80000001
  Checksum: 0xD557
  Length: 36
  Network Mask: /30
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

  Routing Bit Set on this LSA
  LS age: 57
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 192.168.1.0 (External Network Number )
  Advertising Router: 22.22.22.22
  LS Seq Number: 80000001
  Checksum: 0x9449
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

RT4#

Note: Type-4 LSAs are not translated directly from link-state database into routing table.
Note: The metric value in a Type-4 LSA indicates the cost from the ABR to reach the ASBR. This value is used by routers within an area to determine the nearest ABR for an external route.

Below describes the routing table designators for OSPF:

Code	Description
O	OSPF intra-area route that indicates a network within the area which the router resides. Learnt via a Router-LSA or Network-LSA.
O IA	OSPF inter-area route that indicates a network outside the area which the router resides but within the OSPF routing domain. Learnt via a Summary-LSA.
O E1 / O E2	OSPF Type-1 / Type-2 external route that indicates a network outside the autonomous system which the router resides. Learnt via an AS-External-LSA.

The difference between External Type-1 (E1) and External Type-2 (E2) external routes is that the metric of an E1 route is similar to the OSPF metric in which the external metric is being accumulated with the internal metric of every link across the forwarding path towards the ASBR; while the metric of an E2 route remains the same as the external metric throughout an OSPF routing domain. E2 is the default route type for routes that learnt via route redistribution.

The recommended best practices are implement E1 routes when multiple ASBRs are advertising an external route into the same routing domain in order to avoid suboptimal routing; implement E2 routes when there is only 1 ASBR is advertising an external route into the routing domain.

Network Setup for OSPF E1 and E2 Routes

Below shows the routing tables on RT1 and RT2 for the OSPF E1 and E2 routes advertised by RT3:

RT1#sh ip route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, FastEthernet0/0
     11.0.0.0/24 is subnetted, 1 subnets
O IA    11.11.11.0 [110/2] via 10.10.10.2, 00:00:39, FastEthernet0/0
O E1 192.168.1.0/24 [110/22] via 10.10.10.2, 00:00:24, FastEthernet0/0
O E2 192.168.2.0/24 [110/20] via 10.10.10.2, 00:00:24, FastEthernet0/0
RT1#
======================================================================
RT2#sh ip route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, FastEthernet0/0
     11.0.0.0/24 is subnetted, 1 subnets
C       11.11.11.0 is directly connected, FastEthernet1/0
O E1 192.168.1.0/24 [110/21] via 11.11.11.2, 00:00:37, FastEthernet1/0
O E2 192.168.2.0/24 [110/20] via 11.11.11.2, 00:00:37, FastEthernet1/0
RT2#

External Type-1 (E1) routes are always preferred over External Type-2 (E2) routes. When there are multiple External Type-2 (E2) routes for the same external network in the OSPF LSDB, the LSA with the lowest advertised E2 metric will be selected and installed into the routing table. The forward metric (cost to reach an ASBR) will be considered when multiple E2 routes have the same metric value. The show ip ospf border-routers command displays the cost to an ASBR. Note: The internal metric or cost towards the ASBR is not considered when comparing E2 routes.

Network Setup for OSPF E1 and E2 Routes Selection

Below shows the routing table and OSPF LSDB on RT1 for the OSPF external routes:

RT1#sh ip route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, FastEthernet0/0
O E1 192.168.1.0/24 [110/101] via 10.10.10.2, 00:00:30, FastEthernet0/0
O E2 192.168.2.0/24 [110/50] via 10.10.10.3, 00:00:30, FastEthernet0/0
RT1#sh ip ospf database

            OSPF Router with ID (10.10.10.1) (Process ID 100)

--- output omitted ---

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.4      11.11.11.4      59          0x80000001 0x00B4AA

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
192.168.1.0     11.11.11.2      96          0x80000001 0x00B58D 0
192.168.1.0     11.11.11.3      96          0x80000001 0x003DB6 0
192.168.2.0     11.11.11.3      96          0x80000001 0x0032C0 0
192.168.2.0     11.11.11.4      100         0x80000001 0x00229D 0
RT1#

OSPF Type-3 Network-Summary-LSA

Network Setup for Type-3 Network-Summary-LSA

Type-3 Network-Summary-LSAs are originated from an ABR to advertise the subnets in an area (omitting the information of Type-1 and Type-2 LSAs) to neighboring routers outside the area. Type-1 and Type-2 LSAs stay within an area, when an ABR receives a Type-1 or Type-2 LSA, it generates a Type-3 LSA for the network learnt via the Type-1 or Type-2 LSA to other areas.

The Type-3 Network-Summary-LSA and Type-4 ASBR-Summary LSA have the same format, with the differences in the contents of the LS Type and Link-State ID fields in the LSA header. For Type-3 LSAs, the Link-State ID is the IP address of the subnet that is being advertised; while for Type-4 LSAs, the Link-State ID is the Router ID of the ASBR that is being advertised.

OSPF Summary-LSA (Type-3 Network-Summary-LSA and Type-4 ASBR-Summary-LSA) Format

Below lists the fields in the OSPF Summary-LSA:

Field	Description
Network Mask	For Type-3 LSAs, it indicates the subnet mask of the network that is being advertised. For Type-4 LSAs, this field has no meaning and is set to 0.0.0.0. Note: If a Type-3 LSA is advertising a default route, both the Link-State ID and Network Mask fields will be 0.0.0.0.
Metric	Indicates the cost of the route to the destination. Note: Cisco supports only TOS 0 therefore there are no TOS and TOS Metric fields in the Cisco Summary-LSAs.

Type-3 Network-Summary-LSAs are not being summarized and therefore do not contain summary routes by default. All subnets in an area will be advertised by default.

OSPF does not perform autosummarization as like RIPv2 and EIGRP. Route summarization in OSPF requires manual configuration. Route summarization and filtering at the ABRs should always be considered due to the nature that a Type-3 LSA will be advertised into the backbone area for every network in the originating area, which can cause significant flooding problems. Route summarization and filtering on ABRs provide greater scalability for OSPF.

Note: Type-3 and Type-4 Summary-LSAs do not carry topological information; they carry only IP prefixes or subnets. Summary-LSAs are originated by an ABR with the following rules:
 From a non-backbone area to the backbone area, Summary-LSAs are generated for connected routes and intra-area routes. Only intra-area routes are advertised into the backbone area to avoid routing loops. If there are any inter-area routes coming from a non-backbone area it means that the backbone is discontiguous, and OSPF does not allow discontiguous backbone.
 From the backbone area to a non-backbone area, Summary-LSAs are generated for connected routes, intra-area routes, and inter-area routes.

The Advertising Route field in the LSA header of a Summary-LSA contains the Router ID of the ABR that generates the Summary-LSA.

Below shows the routing table and Type-3 Network-Summary-LSAs received on RT4:

RT4#sh ip route

Gateway of last resort is not set

     20.0.0.0/30 is subnetted, 1 subnets
O IA    20.20.20.0 [110/128] via 30.30.30.1, 00:00:21, Serial0/0
     10.0.0.0/30 is subnetted, 1 subnets
O IA    10.10.10.0 [110/192] via 30.30.30.1, 00:00:18, Serial0/0
O IA 192.168.1.0/24 [110/193] via 30.30.30.1, 00:00:18, Serial0/0
     30.0.0.0/30 is subnetted, 1 subnets
C       30.30.30.0 is directly connected, Serial0/0
RT4#
RT4#sh ip ospf database

            OSPF Router with ID (44.44.44.44) (Process ID 100)

                Router Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum Link count
33.33.33.33     33.33.33.33     34          0x80000001 0x005CDA 2
44.44.44.44     44.44.44.44     31          0x80000002 0x00A663 2

                Summary Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.0      33.33.33.33     19          0x80000001 0x0031EB
20.20.20.0      33.33.33.33     29          0x80000001 0x0045F9
192.168.1.0     33.33.33.33     19          0x80000001 0x00F9D2
RT4#
RT4#sh ip ospf database summary

            OSPF Router with ID (44.44.44.44) (Process ID 100)

                Summary Net Link States (Area 2)

  Routing Bit Set on this LSA
  LS age: 19
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.10.10.0 (summary Network Number)
  Advertising Router: 33.33.33.33
  LS Seq Number: 80000001
  Checksum: 0x31EB
  Length: 28
  Network Mask: /30
        TOS: 0  Metric: 128

  Routing Bit Set on this LSA
  LS age: 29
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 20.20.20.0 (summary Network Number)
  Advertising Router: 33.33.33.33
  LS Seq Number: 80000001
  Checksum: 0x45F9
  Length: 28
  Network Mask: /30
        TOS: 0  Metric: 64

  Routing Bit Set on this LSA
  LS age: 19
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 192.168.1.0 (summary Network Number)
  Advertising Router: 33.33.33.33
  LS Seq Number: 80000001
  Checksum: 0xF9D2
  Length: 28
  Network Mask: /24
        TOS: 0  Metric: 129

RT4#

OSPF routers must perform SPF calculations upon the intra-area topology changes (Type-1 and Type-2 LSAs), as these changes impact the selection of best paths towards destination within an area. Changes upon Type-3 LSAs do not trigger an SPF calculation, as the changes do not affect the topology between an OSPF router and the ABR.

Monday, December 26, 2011

OSPF Type-2 Network-LSA

Type-2 Network-LSAs are originated from the DR on a broadcast or multi-access network (eg: Ethernet) to list all the routers that attached to the transit network. Type-2 LSAs are flooded within the originating area only. The Link-State ID of a Type-2 Network-LSA is the physical interface IP address of the DR that connects to the network and advertises the LSA.

OSPF Type-2 Network-LSA Format

Below lists the fields in the OSPF Type-2 Network-LSA:

Field	Description
Network Mask	Indicates the subnet mask on the transit network.
Attached Router	Lists the Router IDs of all routers on the multi-access network that have established FULL adjacency with the DR and the DR itself.

Below shows the Type-2 Network-LSA originated from RT2:

RT1#sh ip ospf database network

            OSPF Router with ID (11.11.11.11) (Process ID 100)

                Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 91
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 10.10.10.2 (address of Designated Router)
  Advertising Router: 22.22.22.22
  LS Seq Number: 80000001
  Checksum: 0xA29A
  Length: 32
  Network Mask: /24
        Attached Router: 22.22.22.22
        Attached Router: 11.11.11.11

RT1#

Note: Type-2 Network-LSAs are not necessary be generated for LAN interfaces. Type-2 LSAs are generated only when necessary, which there is more than one router attached to the LAN.

OSPF Type-1 Router-LSA

Network Setup for Type-1 Router-LSA and Type-2 Network-LSA

Type-1 Router-LSAs are originated from every router to other routers in the same area about the status information of its directly connected links (interfaces) to other routers and networks. Type-1 LSAs are flooded within the originating area only and never crosses an area boundary. The Link-State ID of a Type-1 Router-LSA is the Router ID of the originating router. The Link-State ID and Advertising Router fields in the LSA header are same for Router-LSAs.

OSPF Type-1 Router-LSA Format

Below lists the fields in the OSPF Type-1 Router-LSA:

Field	Description
V bit	Indicates whether the advertising router is an endpoint of a virtual link.
E bit	Indicates whether the advertising router is an Autonomous System Border Router (ASBR).
B bit	Indicates whether the advertising router is an Area Border Router (ABR).
Number of Links	Indicates the number of links of the advertising router. A Router-LSA would contain the information of all router links of the advertising router.
Link Type	Indicates the 4 types of router links. Note: There are 2 types of point-to-point links – numbered and unnumbered.
Link ID and Link Data	The Link ID and Link Data values vary according to the Link Type. The Link ID identifies the object to which a link connects to; while the Link Data provides extra information for a link. Note: The LSA header contains the Link-State ID while an LSA entry contains the Link ID allowing for easier differentiation.
Metric	Indicates the OSPF cost of a router link.
ToS, ToS Metric	Represent the Type of Service and are normally set to 0.

The Link ID, Link Data, Link Type, Number of TOS, Metric, TOS, and TOS metric fields appear one or more times in a Router-LSA corresponding to the Number of Links field.
Note: Cisco supports only TOS = 0. The ToS and ToS Metric fields appear corresponding to the Number of TOS field. Ex: If Number of TOS is 2, there will be 2 32-bit words containing 2 instances of these fields. If Number of TOS is 0, there will be no instances of these fields.

Below lists the Link ID and Link Data values for the various Type-1 Router-LSA link types:

Type	Description	Link ID	Link Data
1	Point-to-point numbered connection to another router	The Router ID of neighboring router	Physical interface IP address of the router to the network
1	Point-to-point unnumbered connection to another router	The Router ID of neighboring router	The MIB-II ifIndex value of the unnumbered interface ^[1]
2	Connection to a transit network	Physical interface IP address of the DR	Physical interface IP address of the router to the network
3	Connection to a stub network	IP network number or subnet number	Subnet mask
4	Virtual link	The Router ID of virtual link neighbor	Physical interface IP address of the router to reach the virtual link neighbor

[1] – This value usually starts with 0.

When the connected object is another router, the Link ID is same as the Link-State ID in the Router-LSA header of the neighboring router. The Link ID is being used to find the Router-LSA of the neighboring router during the route computation process.

A transit interface is a broadcast or NBMA interface with at least one OSPF neighbor. A transit network is described by a Type-2 Network-LSA. A stub interface could be a loopback, broadcast, point-to-point, or multipoint interface on which there is no OSPF neighbor. An OSPF router advertises a multi-access interface as a stub link as long as it has no OSPF neighbors reachable through the interface. When the adjacency to the first OSPF neighbor reaches the FULL state, the OSPF router replaces the stub link as a transit link and advertises its Router-LSA with an incremented sequence number.

An OSPF router generates a single Type-1 Router-LSA for each area that it belongs to. Note: A Router-LSA OSPF packet is fragmented when there are more than 119 LSA entries in a single unauthenticated OSPF packet over an Ethernet link with 1500-byte MTU.

20-byte	IP header
24-byte	OSPF header
4-byte	Number of LSAs field
20-byte	Router-LSA header
4-byte	Flags and Number of Links field
1428 bytes	119 LSA entries; 12-byte per entry. 119 x 12-byte = 1428 bytes
Total = 1500 bytes

Below shows the interfaces on RT1, RT2, and RT3:

RT1#sh ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          100   0               192.168.1.1/32     1     LOOP  0/0
Fa0/0        100   0               10.10.10.1/24      1     BDR   1/1
RT1#
----------------------------------------------------------------------
RT2#sh ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Se1/0        100   0               20.20.20.1/30      64    P2P   1/1
Fa0/0        100   0               10.10.10.2/24      1     DR    1/1
RT2#
----------------------------------------------------------------------
RT3#sh ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa1/0        100   0               192.168.2.1/24     1     DR    0/0
Se0/0        100   0               20.20.20.2/30      64    P2P   1/1
RT3#

Below shows the Type-1 Router-LSA originated from RT2:

RT1#sh ip ospf database router 22.22.22.22

            OSPF Router with ID (11.11.11.11) (Process ID 100)

                Router Link States (Area 0)

  LS age: 78
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 22.22.22.22
  Advertising Router: 22.22.22.22
  LS Seq Number: 80000002
  Checksum: 0x8A1D
  Length: 60
  Number of Links: 3

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 33.33.33.33
     (Link Data) Router Interface address: 20.20.20.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 20.20.20.0
     (Link Data) Network Mask: 255.255.255.252
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.10.10.2
     (Link Data) Router Interface address: 10.10.10.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 1


RT1#