If you expect a firewall to behave like a router...

... you are gonna have a bad day.

I just had a task, where a network needed to be changed from a layer 2 configuration and into a layer 3 configuration. The network design below is a somewhat simplified replication, that will illustrate the issue with doing dynamic routing on a Cisco ASA firewall.

So, a design using two multi-layer switches configured with GLBP for the client subnet, which are connected to a separate interface of the ASA firewall. OSPF was configured between the ASA and the two MLS routers. The expectation here was that the clients would be load balanced to use each of the MLS routers using GLBP and the MLS routers would then send traffic over their links to the firewall facilitating access from the client network to either the Internet or the server subnet.

However, the mistake I made, when making a up the proof of concept (for the routing part of this setup), was that I replaced the ASA firewall with another router expecting them to handle routing somewhat similarly. When the time came to configure the network I discovered that the ASA did not load balance the trafik over the two links - instead it installed the route to 10.0.4.0 /23 only over one of the two links even though the OSPF database showed that both the MLS routers sent the subnet in their LSAs. The ASA would failover to the other link in case of a link failure, but it only installed the path through one of the two MLS routers into the routing table.

Below is the output of a show route on the ASA (after I borrowed one to lab this up).

ASA# show route
<output omitted>
C    10.0.0.0 255.255.255.252 is directly connected, LINK1
C    10.0.0.4 255.255.255.252 is directly connected, LINK2
O    10.0.4.0 255.255.254.0 [110/11] via 10.0.0.2, 1:10:36, LINK1
C    10.0.4.0 255.255.255.0 is directly connected, SERVERS

And then a show ospf database router command on the same ASA to show the routes from both MLS routers.

ASA# show ospf database router
<output omitted>
LS age: 433
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000008
  Checksum: 0x1a7
  Length: 60
   Number of Links: 3
    <output omitted>
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.0.4.0
     (Link Data) Network Mask: 255.255.254.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

  LS age: 414
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 3.3.3.3
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000007
  Checksum: 0xdccc
  Length: 60
   Number of Links: 3
    <output omitted>
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.0.4.0
     (Link Data) Network Mask: 255.255.254.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

The route to 10.0.4.0 /23 is received from both the MLS routers, but the route installed in routing table of the ASA is only the one with the next-hop of 10.0.0.2

I have not found a way to make the ASA behave more like a router in a case like this, but perhaps it was never meant to... The problem here was solved by putting a router in front of the firewall.

I would like to make it clear that I (sadly) do not work much with the Cisco ASA products and this was the first time I actually configured OSPF on an ASA. I made the assumption that it would behave less like a firewall product, when it came to routing, just because it had Cisco stamped on it.

If anyone has any insight to impart regarding dynamic routing configuration on the ASA products please do drop a comment or send me private a message - I would love to have the discussion.

OSPFv2 Packet Types

OSPFv2 uses five different types of packets when communicating with neighboring routers and requesting and sending Link-State Advertisements (LSAs). These packets are (briefly) described below and also shown in a packet capture from a lab environment (lab topology is shown in the bottom of the post). This is to explain the function of each packet and to show the packet format (in this case from a Wireshark capture of packets from two routers running IOS 15.4).

Hello (type code 1)

Used to discover neighbors, bring neighbors to a 2-Way state and functions as a keepalive between neighbors.

OSPFv2 Hello Packet

Database Description (type code 2)

Used to exchange LSA headers when initially exchanging the topology, so that neighbors have a list of the routers LSAs. Also known as a DD or DBD packet.

OSPFv2 DBD Packet

Link-State Request (type code 3)

Identifies at least one LSA that the sending router would like full details about. Also known as an LSR packet.

OSPFv2 LSR Packet

Link-State Update (type code 4)

Contains a fully detailed LSA. These are sent either in response to an LSR or in the event of a topology change (like a link failure, for example). Also known as an LSU packet.

OSPFv2 LSU Packet

Link-State Acknowledgment (type code 5)

Sent in acknowledgement of each received LSA. This makes the OSPF communication reliable between neighbors.

OSPFv2 LSAck Packet

The packets were captured on router R1 in the topology shown below. To capture all five different packet types the capture was done at the initial forming of the neighbor adjacency between R1 and R2.

OSPFv2 Topology

OSPFv2 Designated Router

The Designated Router (DR) is any OSPF router connected to a multiaccess network segment and that has the highest priority or Router-ID at the time of the DR election. The role of the DR is to simplify SPF calculations and relieve the need for all neighbors to be fully adjacent on a shared segment and thereby reducing the flooding of LSAs on shared segment with a large number of neighboring routers.

The DR election process

The OSPF routers will wait for the same amount of time as the Dead timer before electing a DR on the shared segment. This is known as the OSPF Wait Time and allows for a grace period for routers to boot up on the shared segment before electing a Designated Router.

On a shared segment there will be an election of a Designated Router (DR) and a Backup Designated Router (BDR). All other routers on the segment, that are neither DR nor BDR, will be a DROther. 

The specifics of the election process is describe below.

• Routers on a shared segment will listen to neighbors Hellos and collect the priorities and RIDs during the wait interval (wait interval is equal to the dead timer for the interface)
• If a Hello packet is received during the wait interval from a neighbor, which states that, that neighbor is in fact a BDR (which would mean that a DR is also present) the wait interval will expire immediately and the router will proceed to the DR/BDR election process.
• Likewise, if a Hello packet is received during the wait interval from a neighbor, which states it is the DR, but no BDR address is set, the wait interval will expire and the router will proceed to the DR/BDR election process.
• A router examines the RIDs and priorities collected during the wait interval and chooses the highest priority as the Designated Router and the second-highest priority as Backup Designated Router, though only if roles are not advertised by another RID already. If the priority is tied (it is set to 1 by default) the highest Router ID breaks the tie.

There is no preemption of the DR role in an OSPF network; if a DR is listed in the Hello packet it means that no election will be held - the router will join the network using the DR specified in the received Hello packet. This avoids unstable routers continually prompting a DR election, when they come online on the shared segment.

If for some reason the same segment has two DRs elected, each of the DRs will receive the others Hello packet stating itself as the DR for the segment. This will then prompt a new DR/BDR election on the shared segment to mend the network back into a single segment with only one DR and one BDR as the outcome.

OSPF DR/BDR Example

I will detail the workings of the DR with an example configuration using 5 routers connected over a shared ethernet segment. The topology is depicted below.

OSPFv2 DR/BDR Topology

The router R1 is the DR, which was ensured using the command ip ospf priority 255 under the interface connected to the shared ethernet segment. The router R2 was configured with the command ip ospf priority 254 to ensure it got elected as BDR. The routers R3, R4 and R5 are all DROther and configured with the command ip ospf priority 0 to prevent them from ever take part in the election process. Without the priority command the routers would use the default priority of 1 and the DR/BDR would be elected based on the OSPF RID. In the example here the RID is configured as X.X.X.X where the X represents the router number (R1 = 1.1.1.1, R2 = 2.2.2.2, etc). Assuming the priority was not set at all the router R5 would become the DR and the router R4 would become the BDR.

Below is the same topology shown, but this time with arrows indicating the neighbor adjacency states between the routers.

OSPFv2 DR/BDR/DROther Adj. States

The DR and BDR both establish a full neighbor adjacency between each other as well as with all the DROther routers. The DROther routers establish full adjacencies with the DR and BDR only. Between the DROthers they will be stuck in the 2-way state - meaning they receive each others Hello packets, but they do not exchange Database Description Packets with each other.

The process of flooding LSAs is shown and described below. In this case the flooding occurs in response to a simulated link failure on R3 (by shutting down the interfce). When the link goes down, router R3 sends an update to the multicast address 224.0.0.6, which only the DR and BDR listens to.

OSPFv2 Update Step 1

The DR receives the update and proceeds to flood it out its ethernet interface to the multicast address 224.0.0.5, which all OSPF routers listen to.

OSPFv2 Update Step 2

The routers receiving the update will then send an acknowledge to the DR and update their routing information according to the new information - in this case they will remove the network 140.100.3.0/24 from the RIB.

The DR is also the only router allowed to originate a type 2 LSA. The type 2 LSA describes the shared network segment as well as all the attached routers (meaning the routers that have established a full adjacency with the DR on the segment). The LSA type 2 for the example network is shown in the output below.

R1#show ip ospf database network
            OSPF Router with ID (1.1.1.1) (Process ID 1)
                Net Link States (Area 0)
  LS age: 1098
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 130.1.255.1 (address of Designated Router)
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000007
  Checksum: 0x590A
  Length: 44
  Network Mask: /24
        Attached Router: 1.1.1.1
        Attached Router: 2.2.2.2
        Attached Router: 3.3.3.3
        Attached Router: 4.4.4.4
        Attached Router: 5.5.5.5

The type 2 LSA turns the shared segment into a star topology with the DR in the middle, connected to all routers (including the router that is the DR) on the shared segment.

So, the DR will prevent OSPF routers from excessively flooding the network with control packets and it simplifies the SPF algorithm by providing a single point from which to base calculations - the DR sees all and knows all for the shared segment.

OSPFv2 LSA Types

Part of what makes OSPF hard to understand and troubleshoot is all the different types of Link-State Advertisements (LSAs). Some areas have different LSA types allowed and some can only be originated by specific routers and so on - it's a mess! Take into account the fact that the LSAs are referred to by numbers and in the Cisco CLI they are referred to by names, which is then just another thing you will have to get familiar with when working with OSPF.

Below is a list of OSPF LSA types along with a description of their function in the OSPF domain and the command to show them in the Link-State Database (LSDB) of a Cisco router.

LSA Type 1 - Router LSA
Each router in an area will generate a type 1 LSA - one for each area it is connected to. It contains the routers RID and all the routers IP addresses for interfaces attached to the specific area. It is not flooded beyond the area in which it was originated.
The show ip ospf database router command will show the type 1 LSAs in a routers LSDB.

LSA Type 2 - Network LSA
The Designated Router (DR), on shared segment, originates type 2 LSAs containing the interface IP address of the DR and a list of the DRs connected neighbors in the area. The type 2 LSA is only propagated in the area it is originated in and only by the DR.
The show ip ospf database network command will show the type 2 LSAs in the routers LSDB.

LSA Type 3 - Summary LSA
The summary LSA is originate by an Area Border Router (ABR) and advertises a prefix from one area into another. It will advertise the destination prefixes from a non-backbone area into the backbone including the metric from the ABR to the destination. It will do this for each prefix known, but it can instructed to replace the individual prefixes with a less-specific summary address and thus the ABR is one of the few places, in an OSPF network, that allows for network summarization.
The show ip ospf database summary command will show the type 3 LSAs in the routers LSDB.

LSA Type 4 - ASBR Summary LSA
Originated by an ABR, this type of LSA contains the host address of an Autonomous System Border Router (ASBR) in an area and the cost to reach it from the ABR. This is sent along with the LSA type 5 to allow routers outside the area, of the ASBR, to find a path to the ASBR, redistributing an external route into OSPF. This is not needed for routers in the same area as the ASBR due to the presence of the type 1 and 2 LSAs.
The show ip ospf database asbr-summary command will show the type 4 LSAs in the routers LSDB.

LSA Type 5 - AS-External LSA
The type 5 LSA is originated by an ASBR and contains the E1 or E2 external route information for a prefix redistributed into the OSPF process from another AS (for example BGP, EIGRP or maybe just a connected interface, to name but a few options). Routers not residing in the same area as the ASBR will need an ABR to originate a type 4 LSA containing the information needed to compute the SPF tree to the ASBR.
The show ip ospf database external command will show the type 5 LSAs in the routers LSDB.

LSA Type 6 - Group Membership
Used in Multicast OSPF. The feature is unsupported in Cisco IOS (as far as I know).

LSA Type 7 - NSSA External
The type 7 LSA is flooded in an area by an ASBR in a Not-So-Stubby-Area (NSSA). An ABR will convert the type 7 LSA into a type 5 LSA for other areas. The type 7 LSA allows other routers in the same NSSA area to learn the external routes advertised by the ASBR as one of the features of an NSSA type area is to filter out type 5 LSAs.
The show ip ospf database nssa-external command will show the type 5 LSAs in the routers LSDB.

Those are the most common OSPF LSA types. There are LSA types 8, 9, 10 and 11 as well, but they are bit outside my scope right now. I will probably update this post later on in my studies, when I get to OSPFv3 and MPLS, where I expect I will be working with these types of LSAs in some way.

OSPFv2 Neighbor Adjacency States

OSPF distinguishes between the terms neighbor and adjacency, where neighbor refers to any routers exchanging valid hello packets and adjacency meaning routers that exchange routing information.

So, a router running OSPF may have 3 neighbors in total, but only 2 are adjacent. At the end of this post I will include an example of such a scenario.

So, on to the various eight states an OSPF neighbor relationship can be in. These are the state of the OSPF State Machine a google search for "OSPF State Machine" will yield a great deal of graphical and in-depth explanations - so I will just not try and do that kind of stuff and just list the states with a few clarifying notes on each of them.

Down
The neighbor always starts from the down state and moves to either attempt or init states depending on the OSPF network type. The neighbor will also revert to the down state if the dead interval expires or the neighbor adjacency gets cleared.

Attempt
If the neighbor is manually configured it will enter the attempt state, which indicates that the local router has sent unicast hellos to the configured neighbor, but has not heard any hellos in return. This states is only seen on NBMA network types (like non-broadcast multi-access and point-to-multipoint non-broadcast networks).
This is a transitory state.

Init
The init state indicates that the local router has received a hello packet from a neighbor, but without its own RID contained in the packet. This state occurs on network types that do not enter the attempt state.
This is a transitory state.

2-way
Neighbor is stated as 2-Way when a hello packet is received containing the RID of the local router; this would indicate that the neighbor has received a hello from the local router and thus bidirectional communication is possible.
This state is both a stable and a transitory state depending on the network type. Broadcast networks with will have a DR, a BDR and probably quite a few DROther routers, where the DR and BDR are the only ones to have full adjacencies with all routers - the DROther routers will have full adjacency with the DR/BDR and 2-way state for the rest of the neighbors.

ExStart
If the routers are not meant to be stuck in the 2-way state they will have to negotiate a master/slave relationship and agree on a starting sequence number for subsequent Database Description packets (DBDs). This is basically done by exchanging empty DBDs and comparing the RIDs where the router with the highest RID becomes the master.
(The masters role is to send DBDs first to slave, which in turn allows the slave to reply with a DBD. If the master is done sending DBDs, but the slave is not done yet, the master must keep sending DBDs until the slave indicates it is complete - as the slave is not permitted to send DBDs on its own.)

Exchange
After the master/slave relationship is negotiated the routers will enter the exchange state and start sending DBDs containing their LSAs. The router builds a list of missing LSAs based on the received DBDs.

Loading
After the DBD exchange is over the router will download LSAs from its neighbor based on the list made during the exchange state. This is a transitory state.

Full
When all the LSAs have been downloaded the neighbor adjacency will enter into the full state, which is a steady state for all routers exchanging LSAs - meaning all routers except the DROthers.

Now, on to the OSPF neighbor state example. I will be using the network topology shown in the diagram below and the example will show the outputs from the perspective of the router R3.

OSPFv2 four node broadcast topology

The topology shows 4 routers connected over a shared ethernet segment (130.1.255.0/24). Router R1 is the DR and R2 is the BDR. The rest are DROther.

R3 show ip ospf interface brief

Notice the state of DROTH from the output above and that the Nbrs F/C field shows 2/3 - meaning that 2 routers are adjacent and that there are 3 neighbors in total. A router must be a neighbor to be adjacent, which means that there are 2 out of 3 routers in the full state on this interface.

Below, we see the neighbors of R3 and verify that there are three neighbors in total, where two are in the FULL state and the last is in the 2WAY state.

R3 show ip ospf neighbor

OSPFv2 Demand Circuit

I recently wrote a post on Paranoid Updates in OSPFv2, which is kind of a "lite" version of the Demand Circuit feature. The topology used in the aforementioned post is reused for this example as well and is pictured below.

OSPFv2 Two Node Topology

The previously mentioned post describes how to reduce LSA reflooding, which will reduce the OSPF control traffic, but not significantly. Reducing the half-hour reflooding of LSAs will not do much on a line with a traffic cap (3G/4G links for example) or maybe a pay-per-use type of line. We may have a 3G uplink for backup purposes and running OSPF over such a link will make it send data constantly with the Hello packets to keep the adjacencies alive. Here is where the demand circuit feature comes into play. The demand circuit is an extension of OSPF and is described in RFC 1793. So, not all devices may support this feature and therefore if only one neighbor supports the feature the benefits will not be seen from configuring it.

This feature, when enabled, will pause all OSPF communication for as long as the network is stable. This includes the paranoid updates as well as Hello packets. The adjacency will form initially and enter a stable state - after which the neighbors stay mute until a change occurs.

This is how to turn it on and verify the configuration.

R1(config)interface gigabitethernet1.255
R1(config-subif)#ip ospf demand-circuit

R1#sh ip ospf int gi1.255
GigabitEthernet1.255 is up, line protocol is up
  Internet Address 130.1.255.1/24, Area 0, Attached via Network Statement
  Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 1
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           1         no          no            Base
  Configured as demand circuit
  Run as demand circuit
  DoNotAge LSA allowed
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:02
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Can be protected by per-prefix Loop-Free FastReroute
  Can be used for per-prefix Loop-Free FastReroute repair paths
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 1 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2  (Hello suppressed)
  Suppress hello for 1 neighbor(s)

Note that the command is only needed on one end as the feature will be negotiated with the neighboring router (unless negotiation is disabled). So, the output below is from router R2.

R2#sh run int gigabitethernet1.255
Building configuration...

Current configuration : 133 bytes
!
interface GigabitEthernet1.255
 encapsulation dot1Q 255
 ip address 130.1.255.2 255.255.255.0
 ip ospf network point-to-point
end

R2#sh ip ospf interface gigabitethernet1.255
GigabitEthernet1.255 is up, line protocol is up
  Internet Address 130.1.255.2/24, Area 0, Attached via Network Statement
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 1
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           1         no          no            Base
  Run as demand circuit
  DoNotAge LSA allowed
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:02
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Can be protected by per-prefix Loop-Free FastReroute
  Can be used for per-prefix Loop-Free FastReroute repair paths
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 2
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 1.1.1.1  (Hello suppressed)
  Suppress hello for 1 neighbor(s)

Notice that the ip ospf demand-circuit command is not entered under router R2's interface, but it is still running as a demand circuit because it is negotiated with router R1.

show run all to the rescue

This is gonna be a quick post!

Ever drawn a blank when trying to recall a specific command? You know what you're looking for and it's on the tip of your tongue. Well, I like to use the command show run all to look for the answer. If used right it can quickly find you the default of a command that would otherwise be omitted from regular show run command.

Of course, when looking for something specific, the command show run all won't help much, unless your objective is to wear down the spacebar on the keyboard. To find something specific it will have to be piped to either include some keywords or with the section command to filter out all the insane amounts of default commands.

Below is an example of the command used to show all the configured commands on interface FastEthernet2 on a Cisco 881 router. It lists all the commands configured on the interface that wouldn't be seen under normal circumstances.

AMBO-RT#sh run all | section interface FastEthernet2
interface FastEthernet2
 switchport access vlan 10
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 1
 switchport trunk allowed vlan 1-4094
 switchport mode access
 switchport voice vlan none
 switchport priority extend none
 switchport priority default 0
 mtu 1500
 no ip address
<further output omitted - it goes on for a while>

So, this command could be just the thing needed to jog your memory, when drawing a blank.

Also, if you like to read CLI output, like Joe Pantoliano reads the Matrix, go ahead and do a show run all and take it from the top - you will be amazed how many commands you never knew existed.

OSPFv2 Paranoid Updates

In a stable OSPF domain the routers will periodically sync their Link-State Databases (LSDBs) with each other. This ensures that all routers in an area has the same view of the network by getting a refreshed view of their neighbors LSDBs. This is a feature commonly referred to as Paranoid Update or Paranoid Flooding. Cisco implements OSPFv2 in a way that they reflood LSAs after half the MaxAge time. The MaxAge time defaults to 3600 seconds (60 minutes) and therefore the LSAs will be reflooded after 1800 seconds (30 minutes).

The below diagram shows the network topology used in the following example.

OSPFv2 Two Node Topology

So, the way to turn the periodic LSA flooding off (if for some reason you would want that) is by going under the interface and issuing the command ip ospf flood-reduction. Below is the output of a show ip ospf interface command on router R1, which shows an interface before turning flood-reduction on.

R1#show ip ospf interface
Loopback0 is up, line protocol is up
  Internet Address 140.1.255.1/32, Area 0, Attached via Network Statement
  Process ID 1, Router ID 1.1.1.1, Network Type LOOPBACK, Cost: 1
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           1         no          no            Base
  Loopback interface is treated as a stub Host
GigabitEthernet1.255 is up, line protocol is up
  Internet Address 130.1.255.1/24, Area 0, Attached via Network Statement
  Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 1
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           1         no          no            Base
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:03
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Can be protected by per-prefix Loop-Free FastReroute
  Can be used for per-prefix Loop-Free FastReroute repair paths
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 1 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2
  Suppress hello for 0 neighbor(s)

Below is also shown the contents of the LSDB using the show ip ospf database command - the age and sequence number can be compared after the flood-reduction changes have been made to verify the effects of the command.

R1#sh ip ospf database
            OSPF Router with ID (1.1.1.1) (Process ID 1)
                Router Link States (Area 0)
Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1              493         0x80000006 0x002244 3
2.2.2.2         2.2.2.2              482         0x80000005 0x00A9B7 3

The flooding-reduction command is then entered on R1, as shown below, and the neighbor adjacency bounces quickly up and down - note that the interfaces are point-to-point to reduce the contents of the OSPF database for this example. Subsequently the command was entered on R2's interface as well (not shown).

R1(config)#interface gigabitethernet1.255
R1(config-subif)#ip ospf flood-reduction
R1(config-subif)#
*Nov  30 15:53:46.875: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet1.255 from FULL to DOWN, Neighbor Down: Interface down or detached
*Nov  30 15:53:46.878: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet1.255 from LOADING to FULL, Loading Done

Then, another output of the show ip ospf interface command to verify the command has taken effect on the interface.

R1#show ip ospf interface gi1.255
GigabitEthernet1.255 is up, line protocol is up
  Internet Address 130.1.255.1/24, Area 0, Attached via Network Statement
  Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 1
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           1         no          no            Base
  Reduce LSA flooding.
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:08
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Can be protected by per-prefix Loop-Free FastReroute
  Can be used for per-prefix Loop-Free FastReroute repair paths
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 1 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2
  Suppress hello for 0 neighbor(s)

So, it says it is reducing the LSA flooding. Lets check that out in the LSDB on R1.

R1#show ip ospf database
            OSPF Router with ID (1.1.1.1) (Process ID 1)
                Router Link States (Area 0)
Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         1116        0x80000006 0x002244 3
2.2.2.2         2.2.2.2         1104        0x80000005 0x00A9B7 3

Sequence number have not changed, but the age is higher than before as would be expected.

After waiting some time the LSDBs of R1 and R2 should now show some differences as a result of them no longer sending periodic LSA updates to each other. The results of the outputs are shown below. Notice the incremented sequence numbers of the LSA for router 1.1.1.1 on R1, but the LSA for 2.2.2.2 has not increased its value. To see the change in full effect the output of the LSDB is shown for R2 as well.

R1#show ip ospf database
            OSPF Router with ID (1.1.1.1) (Process ID 1)
                Router Link States (Area 0)
Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         1034        0x80000007 0x002045 3
2.2.2.2         2.2.2.2         3030        0x80000005 0x00A9B7 3

R2#show ip ospf database
            OSPF Router with ID (2.2.2.2) (Process ID 1)
                Router Link States (Area 0)
Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         3055        0x80000006 0x002244 3
2.2.2.2         2.2.2.2         1085        0x80000006 0x00A7B8 3

The sequence numbers are now out of sync because the router updates its LSA locally and thus increments the sequence number, but omits to send it to its neighbor unless a change occurs.

EIGRP Named Mode

Introduced in IOS release 15, the new the EIGRP Named Mode, also known as multi-af mode, streamlined the configuration of EIGRP as opposed to the old way of configuring it - the Classic Mode, also known as autonomous mode. It gathers all the configuration of interface parameters and such under the process configuration and introduces some new features.

Currently, the structuring of the commands are the main difference between Classic and Named Mode, but aside from all new features to come only being supported in multi-af mode, there are a few changes already.

Changes in Named Mode compared to Classic Mode includes some of the following:

• The Wide Metric is enabled causing the metric to be further scaled due to it being too large for what is allowed in the RIB
• The delay is now measured in picoseconds instead of microseconds
• Authentication now supports SHA-256 along with the old MD5
• SHA authentication does not support key chains and therefore do not support key rotation

The new multi-af (named) mode is fully compatible with the classic mode configuration and there is even a single command that will upgrade your configuration from the classic format to the new multi-af format. This is done by entering in the eigrp upgrade-cli <name> under the eigrp router process. Below is a configuration example of EIGRP configuration before and after the upgrade.

R1#show running-config | section router eigrp
router eigrp 100
 metric weights 0 0 0 1 0 0
 network 10.0.0.0 0.0.0.255
 network 192.168.0.1 0.0.0.0
 passive-interface Loopback0
R1#show running-config | section (interface (GigabitEthernet1|Loopback0))
interface Loopback0
 ip address 192.168.0.1 255.255.255.0
interface GigabitEthernet1
 ip address 10.0.0.1 255.255.255.0
 no ip split-horizon eigrp 100
 passive-interface Loopback0

As seen above, EIGRP has been configure with a non-default K-value configuration, two network statements and a passive-interface. Now, below the EIGRP will be upgraded from classic to named mode using the CLI command eigrp upgrade-cli <name> under the router process.

R1(config-router)#eigrp upgrade-cli NAMED_EIGRP
Configuration will be converted from router eigrp 100 to router eigrp NAMED_EIGRP.
Are you sure you want to proceed? ? [yes/no]: yes
R1(config)#
*Dec  1 12:42:23.769: EIGRP: Conversion of router eigrp 100 to router eigrp NAMED_EIGRP - Completed.

And now we verify the commands have been carried over from classic to named.

R1#show running-config | section router eigrp
router eigrp NAMED_EIGRP
 !
 address-family ipv4 unicast autonomous-system 100
  !
  af-interface Loopback0
   passive-interface
  exit-af-interface
  !
  af-interface GigabitEthernet1
   no split-horizon
  exit-af-interface
  !
  topology base
  exit-af-topology
  network 10.0.0.0 0.0.0.255
  network 192.168.0.1 0.0.0.0
  metric weights 0 0 0 1 0 0 0
 exit-address-family

Now, all the commands that were scattered across the enabled interfaces and the router process has been put under the named mode router config. Namely, the passive-interface for loopback0, which was under the router process in classic mode, and the no split-horizon, which was under the gigabitethernet1 interface in classic mode.

There is a little shortcut in Cisco IOS worth mentioning, when working with named mode, that will shorten the command address-family ipv4 unicast autonomous-system 100 into a much more manageable address-family ipv4 as 100 command. This omits the unicast parameter and shortens autonomous-system to as.

The new command structure may seem a bit confusing at first, but when you need to configure, lets say, default authentication on all EIGRP enabled interfaces - or maybe set the Hello and Hold timers - you will love the af-interface default section of the multi-af configuration.

OSPFv2 Overview

This is a quick overview of the OSPF (Open Shortest Path First) routing protocol. The version of OSPF focused on in this post will be the IPv4 OSPFv2 variant. I will do another post on OSPFv3, which is OSPF for IPv6. This post will be somewhat Cisco centric (again, reading up for the CCIE exam) and so some of the points below may not be directly from the RFC, but more in the adaptation of OSPFv2 in Cisco gear.

• Open standard based on RFC 2328 (2328 is the current OSPFv2 specification, but there are many RFCs that add different functionality to OSPF apart from what is described in 2328)
• Classless
• Link-State routing protocol
• Uses IP protocol 89
• Sends Hello messages
• Used to form neighbor relationships
• Used as a keepalive between neighbors
• Default Hello interval is 10 seconds
• Default on NBMA and point-to-multipoint NBMA links is 30 seconds
• Uses a Dead timer 
• Default Dead timer is 4 times the Hello timer
• Sends partial and full updates
• Updates are triggered
• Updates will be sent after 30 minutes by default (half the MaxAge timer)
• Uses multicast address 224.0.0.5 (all OSPF routers) and 224.0.0.6 (all OSPF designated routers) or unicast to communicate with neighbors
• Default administrative distance is 110
• Uses bandwidth as metric for best path selection
• Default reference bandwidth is 100 mpbs
• Cost is calculated by ref-bw / interface-bw (example: 100mpbs / 10mbps = cost 10)
• Supports authentication using clear text, MD5 or SHA
• Supports route summarization only at Area or Autonomous System Boundaries.
• Supports equal cost load-sharing
• Does not support split-horizon, but ignores self-originated LSAs - which is kind of the same thing.
• Uses Shortest Path First (SPF) algorithm to process the contents of the Link-State Database (LSDB)

Things that has to match in Hello packets for OSPF neighbor adjacency relationships to form:

• Authentication (if used)
• Hello and Dead timers
• Network Mask
• OSPF Area ID
• OSPF Area Type
• Link MTU size
• No duplicate RIDs

OSPF is a link-state routing protocol, which means all routers have the entire network topology database and calculates the best paths to reach destinations using this topology. The benefits of this is that, unlike distance vector protocols, OSPF routers know exactly what the network looks like from the perspective of all its neighbors - the drawback, though, is the resource consumption of having to maintain a full overview of the topology on every single router. So, when it is said that all OSPF routers must know the exact same topology it is not the entire truth - the truth is that ALL routers in the same area must know the exact topology. 

Areas are a way of dividing an OSPF domain into logical groupings of routers. It allows for smaller topology databases and also enables the routers on the area borders to summarize networks advertised between the OSPF areas. These routers are known as Area Border Routers (ABR).

For OSPF to function properly in a multi-area design, all areas must be connected to area 0, which is the backbone area in OSPF. The reason for this is that ABRs only advertise non-backbone area networks into area 0.

Below is a drawing of a network with two different area configuration - the left one is improper area design and will cause routes in area 4 to be missing from on neighbor routers and the one on the right is a way to fix that design flaw by removing area 4 and including the network into area 3 instead, which will allow for all routes to be available throughout the OSPF multi-area domain.

OSPF Area Designs

The use of areas in OSPF also serves to reduce the flooding of Link-State Advertisements (LSAs) between routers. LSAs describes different network properties depending on the type of LSA. OSPF routers flood different types of LSAs based on its role in the network. In a non-backbone area it will be normal to have LSA types 1 and 2 and ABRs will send type 3 LSAs into the backbone area.

OSPF uses different network types for interfaces enabled for OSPF. The reason is to allow OSPF to determine its behaviour in regards to the following:

• Whether there will be an election of a DR/BDR on that interface
• Whether to use multicast or unicast to communicate with neighbors
• Whether two or more routers are allowed on the same subnet

Below is a table listing the different network types and the OSPF behaviour they dictate.

OSPF Network Types

A last note I want to put on OSPF is that it does not calculate based on the best way to reach a prefix - instad it finds the best way to reach the node (router) that advertises the prefix. The end result is pretty much the same, but if you think about it, one router can have many prefixes and so if you calculate based on each prefix you will have to calculate many times - whereas if you calculate the best path to the node you have the answer to ALL the prefixes with a single calculation.