TechRecepies

1. EIGRP can be referred to as a hybrid protocol. It combines most of the characteristics of traditional distance vector protocols with some characteristics of link-state protocols. Specifically, EIGRP is "enhanced" by using four routing technologies:

-Neighbor discovery/recovery

-Reliable Transport Protocol (RTP)

-DUAL finite-state machine

-Protocol-dependent modules

2. It could be argued that EIGRP's weakest point is that it is a Cisco-proprietary protocol, but with the aid of redistribution, this point becomes moot.

3. EIGRP is a classless routing protocol. It directly interfaces to IP as protocol 88. EIGRP uses the multicast address of 224.0.0.10 for hellos and routing updates.

4. Only partial routing updates are sent when network topology changes occur.

5. EIGRP uses a composite metric much like IGRP, except that it is modified by a multiplier of 256.

-Bandwidth

-Delay

-Load

-Reliability

-MTU

6. When EIGRP calculates this metric for a route, it calls it the feasible distance to the route. EIGRP calculates a feasible distance to all routes in the network.

K1=K3=1, K2=K4=K5=0

BW=10⁷/bandwidth-of-slowest-link

DELAY=Σ(delays-along-the-path)

7. EIGRP does not periodically advertise it routes. Because of this, it needs some way to locate and then exchange routing information with adjacent devices. EIGRP accomplishes this through the use of neighbors.

8. When EIGRP initializes, it sends out a multicast hello on address 224.0.0.10, on broadcast media.

9. EIGRP sends hellos every 5 seconds on the following interfaces:

LAN broadcast media, such as Ethernet, Token Ring, and FDDI

High-speed serial link greater than T1 speeds, such as Frame Relay HSSI links

Point-to-point serial links, such as PPP or HDLC

ATM and Frame Relay point-to-point subinterfaces

EIGRP sends hellos every 60 seconds on the following interfaces:

Low-speed serial links less than T1 speeds, including Frame Relay and multipoint X.25

ATM and Frame Relay multipoint interfaces, and ATM SVCs

ISDN BRIs

Process:

1. Hellos are sent out each interface participating in EIGRP, except interfaces quieted by the passive interfaces. All EIGRP hellos and routing updates use the multicast address of 224.0.0.10.

2. Routers on the same IP subnet receive the multicast and respond with a full routing update. This is accomplished by setting the INITialization bit in the EIGRP header; the updates include all networks that EIGRP is aware of and the metric for those routes, except for those suppressed by split horizon. This update packet establishes a neighbor relationship (adjacency). The hello packet also includes a hold timer, which tells the router how long it should wait before receiving a hello and declaring the route unreachable and reporting it to the DUAL process. The hold timer is set to three times the value assigned for the hello timer. This usually is 15 or 180 seconds, depending on the media.

3. The other router responds to the initialization packet by sending a hello with the ACK bit set. EIGRP sets the ACK bit to acknowledge all messages that it receives that have data. This is one way that EIGRP has reliable transports.

4. The other router now inserts the new update into its route table. Because it has a new update, it sends an update to all its neighbors.

5. The neighbors that received the update respond with an acknowledgment packet.

6. The router holds the adjacency by the continuous exchange of hellos. If a hello is not received by the time the hold timer expires, the router marks the route as unreachable.

7. When the router forms an adjacency, it treats this as a virtual link to transport routing information.

Packets:

Hello— Used to discover and maintain neighbors. This packet type uses unreliable delivery.

Acknowledgments (ACKs)— Used to acknowledge updates. They are essentially hellos with no data in them. ACKs also use unreliable delivery.

Updates— Contain routing information. Updates can be either unicast or multicast, depending on how they are generated. Updates use reliable delivery. Uses RTP (Reliable Transport Protocol).

Queries— Used by the DUAL process to find feasible successor for routes. The query can be unicast or multicast. Queries always use reliable delivery.

Uses RTP.

Replies— Used by the DUAL process to aid in finding feasible successor for routes. Replies are always unicast and use reliable delivery. Use RTP.

DUAL: (Diffusing Update Algorithm)

With the help of DUAL, EIGRP keeps the following tables:

Neighbor table— EIGRP tracks every formed adjacency in the neighbor table. A neighbor will be held until an ACK is not received after 16 unicast retransmissions to that neighbor. At this time, the neighbor is dropped. Neighbors can be displayed with the show ip eigrp neighbors command.

Topology table— All learned routes reported by neighbors are kept in the topology table. The topology table also tracks the metrics and feasible distances associated with those routes. The topology table can be displayed with the show ip eigrp topology as_number command.

Route table/forwarding table— Only the routes with the lowest composite metric are entered into the final route or forwarding table. This is the route that the router will forward to.

The DUAL process is in control of determining feasible distances, feasible successors, and the successor of the routes in the EIGRP topology table. By having a backup path already defined in the topology table, the router can quickly converge to the new path in case the primary path fails.

The successor is the primary path for the route, or the path that the router will forward packets to. The feasible successor becomes the next-hop address only if the primary route to the destination becomes unreachable. The feasible successor is always downstream and, thereby, must have a distance or feasible distance that is less than that of the current preferred route.

We can not use passive-interface to stop a router sending routing updates by using "passive-interface..." command (in EIGRP or OSPF), because it will shut down the neighbor relationship of these two routers (no hello packets are exchanged).

PROCESS:

1. A user turns on the computer with the DHCP client enabled on it.

2. The client PC sends broadcast request (known as DHCP DISCOVER) and then look for the DHCP server to answer.

3. The DHCP server receives the DISCOVER packet and based on the availability and defined settings, the server choose any available IP address and then give to the client. Then DHCP server sends back to the client with DHCP OFFER with that available address information.

· If the configuration parameters sent to the client in the DHCPOFFER unicast message by the DHCP server are invalid (a misconfiguration error exists), the client returns a DHCPDECLINE broadcast message to the DHCP server.

4. Again client sends (broadcast) a request to DHCP server known as DHCP REQUEST, in which it lets the server know that it is using the address offered by the DHCP.

5. The DHCP server then again send a acknowledgement to the client known as DHCP ACK, in which it confirm the client that the specific IP address has been assigned to it for a given period of time.

· The DHCP server will send to the client a DHCPNAK denial broadcast message, which means the offered configuration parameters have not been assigned, if an error has occurred during the negotiation of the parameters or the client has been slow in responding to the DHCPOFFER message (the DHCP server assigned the parameters to another client) of the DHCP server.

________________________________________________________________________________

This process of assigning the IP addresses by the DHCP server also known as DORA (Discover, Offer, Request, and Acknowledgement).

When a computer uses a static IP address there can be the chances of error and conflict when two computers use the same IP address. By using the DHCP server there are no chances of such kind of conflicts and errors.

Along with the IP addresses, the DHCP server also enables the client computers to extract all the settings and configurations from the DHCP server on an IP network. These settings include the Firewall, Router, DNS, NAT, WINS, Gateway and Subnet masks settings.

The overall purpose of the DHCP server is to reduce the workload and error margins, which can occur in assigning the IP addresses manually.

The IP address assigned by the DHCP server is for the limited or leased period of time and if a client needs an to extend that leased period for the IP address then client must send a extension request to the DHCP server before this period expires. If the client do not send an extension request, then this IP address becomes free on expiration and is assigned to another client.

The DHCP server database is organized as a tree. The root of the tree is the address pool for natural networks, branches are subnetwork address pools, and leaves are manual bindings to clients.

CONFIGURATION:

•Configuring a DHCP Database Agent or Disabling DHCP Conflict Logging (Required)

A DHCP database agent is any host, for example, an FTP, TFTP, or RCP server that stores the DHCP bindings database. You can configure multiple DHCP database agents and you can configure the interval between database updates and transfers for each agent.

Router(config)# ip dhcp database url [timeout seconds | write-delay seconds]

If you choose not to configure a DHCP database agent, disable the recording of DHCP address conflicts on the DHCP server.

Router(config)# no ip dhcp conflict logging

•Excluding IP Addresses (Required)

Router(config)# ip dhcp excluded-address low-address [high-address]

•Configuring a DHCP Address Pool (Required)

Router(config)# ip dhcp pool name

Ø Configuring the DHCP Address Pool Subnet and Mask

Router(config-dhcp)# network network-number [mask | /prefix-length]

Ø Configuring the Domain Name for the Client

The domain name of a DHCP client places the client in the general grouping of networks that make up the domain.

Router(config-dhcp)# domain-name domain

Ø Configuring the Domain Name System IP Servers for the Client

Router(config-dhcp)# dns-server address [address2 ... address8]

Ø Configuring the Default Router for the Client

Router(config-dhcp)# default-router address [address2 ... address8]

Ø Configuring the Address Lease Time

Router(config-dhcp)# lease {days [hours][minutes] | infinite}

•Configuring Manual Bindings (Optional)

Manual bindings are IP addresses that have been manually mapped to the MAC addresses of hosts that are found in the DHCP database. Manual bindings are stored in NVRAM on the DHCP server.

Router(config)# ip dhcp pool name

Router(config-dhcp)# host address [mask | /prefix-length]

Router(config-dhcp)# hardware-address hardware-address type

Router(config-dhcp)# client-name name

The client name should not include the domain name

•Configuring a DHCP Server Boot File (Optional)

Router(config-dhcp)# bootfile filename

•Configuring the Number of Ping Packets (Optional)

By default, the DHCP server pings a pool address twice before assigning the address to a requesting client.

Router(config)# ip dhcp ping packets number

•Configuring the Timeout Value for Ping Packets (Optional)

By default, the DHCP server waits 500 milliseconds before timing out a ping packet.

Router(config)# ip dhcp ping timeout milliseconds

•Enabling the Cisco IOS DHCP Server Feature (Optional)

Router(config)# service dhcp

· Monitoring and Maintaining the DHCP Server

Router# clear ip dhcp binding address | *

Router# clear ip dhcp conflict address | *

Router# clear ip dhcp server statistics

Router# debug ip dhcp server {events | packets | linkage}

Router> show ip dhcp binding [address]

Router> show ip dhcp conflict [address]

Router# show ip dhcp database [url]

Router> show ip dhcp server statistics

ip dhcp database ftp://user:password@172.16.4.253/router-dhcp write-delay 120

ip dhcp excluded-address 172.16.1.100 172.16.1.103 

ip dhcp excluded-address 172.16.2.100 172.16.2.103

!

ip dhcp pool 0

        network 172.16.0.0 /16

        domain-name cisco.com

        dns-server 172.16.1.102 172.16.2.102

        netbios-name-server 172.16.1.103 172.16.2.103 

        netbios-node-type h-node

!

ip dhcp pool 1

        network 172.16.1.0 /24

        default-router 172.16.1.100 172.16.1.101 

        lease 30 

!

ip dhcp pool 2

        network 172.16.2.0 /24

        default-router 172.16.2.100 172.16.2.101 

        lease 30

ip dhcp pool Mars 

        host 172.16.2.254 mask 255.255.255.0 

        hardware-address 02c7.f800.0422 ieee802

        client-name Mars

        default-router 172.16.2.100 172.16.2.101 

        domain-name cisco.com

        dns-server 172.16.1.102 172.16.2.102

        netbios-name-server 172.16.1.103 172.16.2.103

        netbios-node-type h-node

Place the ip helper-address command on the interface you expect to be receiving the broadcast.

By default, the ip helper-address command will forward these 8 UDP ports:

Use ‘no ip forward-protocol’ if you don’t want to forward any of the above port through ip helper-address.

To allow all the nodes in the server farm to receive the broadcasts at Layer 2, configure the server facing ethernet interface to forward directed broadcasts with the following commands:

RTA(config)#interface e3

RTA(config-if)#ip directed-broadcast

ip dhcp relation information option

Enables the system to insert the DHCP relay agent information option in forwarded BOOT REQUEST messages to a Cisco IOS DHCP server.

rbe nasip source-interface

Specifies the IP address of an interface on the DHCP relay agent that will be sent to the DHCP server via the Agent Remote ID suboption.

OSPF Header:

 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-----------------------------------------------------------------

|   Version #   |       5       |         Packet length         |

-----------------------------------------------------------------

|                          Router ID                            |

-----------------------------------------------------------------

|                           Area ID                             |

-----------------------------------------------------------------

|           Checksum            |             AuType            |

-----------------------------------------------------------------

|                       Authentication                          |

-----------------------------------------------------------------

|                       Authentication                          |

-----------------------------------------------------------------

Hello Packet:

 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-----------------------------------------------------------------

|                      Network Mask                             |    

-----------------------------------------------------------------

|         HelloInterval         |    Options    |    Rtr Pri    |

-----------------------------------------------------------------

|                     RouterDeadInterval                        |

-----------------------------------------------------------------

|                      Designated Router                        |

-----------------------------------------------------------------

|                   Backup Designated Router                    |

-----------------------------------------------------------------

|                          Neighbor                             |

-----------------------------------------------------------------

DBD Packet:

 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-----------------------------------------------------------------

|         Interface MTU         |    Options    |0|0|0|0|0|I|M|MS

-----------------------------------------------------------------

|                     DD sequence number                        |

-----------------------------------------------------------------

|                                                               |

-                       An LSA Header                           -

|                                                               |

-----------------------------------------------------------------

|                              ...                              |

LS Request:

 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-----------------------------------------------------------------

|                          LS type                              |

-----------------------------------------------------------------

|                       Link State ID                           |

-----------------------------------------------------------------

|                     Advertising Router                        |

-----------------------------------------------------------------

|                              ...                              |

LS Update:

 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-----------------------------------------------------------------

|                            # LSAs                             |

-----------------------------------------------------------------

|                             LSAs                              |

|                              ...                              |

LS ACK:

 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-----------------------------------------------------------------

|                                                               |

--                         An LSA Header                       --

|                                                               |

-----------------------------------------------------------------

|                              ...                              |

LSA Header:

  0                   1                   2                   3

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-----------------------------------------------------------------

|            LS age             |    Options    |    LS type    |

-----------------------------------------------------------------

|                        Link State ID                          |

-----------------------------------------------------------------

|                     Advertising Router                        |

-----------------------------------------------------------------

|                     LS sequence number                        |

-----------------------------------------------------------------

|         LS checksum           |             length            |

-----------------------------------------------------------------

Router-LSAs:

 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-----------------------------------------------------------------

|    0    |V|E|B|        0      |            # links            |

-----------------------------------------------------------------

|                          Link ID                              |

-----------------------------------------------------------------

|                         Link Data                             |

-----------------------------------------------------------------

|     Type      |     # TOS     |            metric             |

-----------------------------------------------------------------

|                              ...                              |

-----------------------------------------------------------------

|      TOS      |        0      |          TOS  metric          |

-----------------------------------------------------------------

|                          Link ID                              |

-----------------------------------------------------------------

|                         Link Data                             |

-----------------------------------------------------------------

|                              ...                              |

Network-LSAs:

 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-----------------------------------------------------------------

|                         Network Mask                          |

-----------------------------------------------------------------

|                        Attached Router                        |

-----------------------------------------------------------------

|                              ...                              |

Summary-LSAs:

 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-----------------------------------------------------------------

|                         Network Mask                          |

-----------------------------------------------------------------

|      0        |                  metric                       |

-----------------------------------------------------------------

|     TOS       |                TOS  metric                    |

-----------------------------------------------------------------

|                              ...                              |

AS-external-LSAs:

 0                   1                   2                   3

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

-----------------------------------------------------------------

|                         Network Mask                          |

-----------------------------------------------------------------

|E|     0       |                  metric                       |

-----------------------------------------------------------------

|                      Forwarding address                       |

-----------------------------------------------------------------

|                      External Route Tag                       |

-----------------------------------------------------------------

|E|    TOS      |                TOS  metric                    |

-----------------------------------------------------------------

|                      Forwarding address                       |

-----------------------------------------------------------------

|                      External Route Tag                       |

-----------------------------------------------------------------

|                              ...                              |

PROCESS:

1.When a router comes up initially: it send first Hello packet to the multicast
address 224.0.0.5, setting its Neighbor field empty.

2.It then looks for the Hello packets to discover Neighbors.

3.If it receives a Hello packet from another Router, it processes it and checks
the Neighbor field to find out if its Router-ID is mentioned in that field.
In case it’s mentioned there, 2-WayReceived event is triggered and it forms
2-WAY adjacency with that router. If not, it checks other fields like Area-ID,
Network-Mask or IP-Address (In case of Broadcast or NBMA network),
Authentication-Type, Authentication-Key, Hello-interval, Dead-interval.
If these field matches with the one that is configured on its own interface,
then it sends (unicast) an immediate Hello packet. 

Receiving Hello packet triggers HelloReceived event. In this case, when
HelloReceived is triggered, Router changed its state from DOWN to INIT.
When the other Router received its immediate Hello packet, its state also
gets changed from DOWN to INIT.

4.In a Broadcast & Point-to-Point network Hello packets are multicast at every
10 seconds and Dead-interval is 10x4=40. In other networks, its 30 & 120
respectively. So, this time when it multicast the Hello packet, Neighbor field
contains the Router-ID of the newly discovered Neighbor. When the other router
checks and find out its own Router-ID in that Hello packet’s Neighbor field,
it changes its state from INIT to 2-WAY with that router.

   5.DR & BDR election takes place in Broadcast & NBMA networks. And it can only
  take place after 2-WAY state. 

   6.A router can change its state from INIT to 2-WAY, if it receives a Hello packet
  which contains its Router-ID in the Neighbor field OR if it receives a DBD
  packet. 

   7.After election, DR & BDR is selected. Election of DR & BDR is basically on
  Router-Priority field in Hello packet. If it’s same then Router-ID is the tie
  breaker.

   8.Once election is finished, Router changes its state to EXSTART. In networks
  where election is not required, routers can directly go to EXSTART state from
  INIT.

9.Negotiation is done in EXSTART state, which implies who will become MASTER to
initiate the EXCHANGE. Router with higher Router-ID becomes the MASTER. SLAVE
has to agree on the DD sequence no. set by MASTER. Only MASTER can increment
the DD sequence no. and retransmit DBD packets. Every time MASTER sends a DBD
packet it increments the DD sequence no. Every DBD packet sent by MASTER has
to be acknowledged by SLAVE through echoing with same DD sequence no. If a
reply is not received by SLAVE before RetransmissionInterval expires, DBD
packet is retransmitted my MASTER. If MASTER receives a DBD packet with
different DD sequence no. then SeqNumberMismatch  event is generated and
adjacency is started from EXSTART state once again.

        DR & BDR election is based on Router priority, however selection 

of MASTER & Slave is purely based on Router-ID & is per neighbor basis.
Therefore, a DR can also become a Slave

10.In EXSTART state both the routers sends each other the DBD packet with Flag
set to 0x7 (I bit=1, M bit=1, MS bit=1), means this is the first DBD packet
I am sending, there are more DBD packets to come and I am MASTER. These DBDs
don’t contain any LSA Headers. A router with higher Router-ID becomes MASTER.
And SLAVE sends a DBD packet with flag set to 0x2 turning off the I and MS bit.
This is the confirmation packet from the SLAVE. SLAVE changes its state to
EXCHANGE (triggering NegotiationDone event) after sending this packet. SLAVE
also starts sending LSA Headers in DBDs now (as it’s in EXCHANGE state now).
When the other router receives this packet, a NegotiationDone event is
triggered there too. This changes the state of the receiving end to EXCHANGE
too. The MASTER now sends a DBD packet with flag set to 0x3 (just turning off
the I bit) and this DBD packet also contains LSA Headers. Flags remains to be
0x2 (for SLAVE) and 0x3 (for MASTER) until there are more LSA Headers to send.
When SLAVE has no more LSA Headers to send along with DBD packets, it echoes
back with flag set to 0x0. Then if MASTER has no more LSA Headers to send along
with DBD packets, it set flag to 0x1. At this stage any router whose flag is
set to either 0x0 or 0x1 will start sending LSA Request packets. This LSA
Request packets are sent based on comparison of there LSDB with the LSA Headers
that they received during EXCHANGE state. Both the routers may also receive LS
Update packets in this EXCHANGE state.

11.However, MASTER will still be waiting for the reply on its last DBD that it
sent. This implies that the last DBD is always sent by SLAVE. ExchangeDone
event is triggered on SLAVE router as soon as SLAVE sends the last DBD packet.
Once MASTER receives this DBD packet, ExchangeDone event is triggered there
too.

12.Once ExchangeDone event is triggered, router changes state from EXCHANGE to
LOADING (in case there are more out-dated links in the database to request) or
EXCHANGE to FULL.

13.In LOADING state, routers send and receive LS Request and LS Update packets
for any out-dated links. Once LS Request and LS Update packet is empty,
LoadingDone event is triggered, indicating that the LSDB is now synchronized
throughout the area.

14.Once LSDB of all the routers in an area is synchronized, state is changed from
LOADING to FULL, indicating full adjacency. SFP algorithm is then calculated
and routing table is build.

15.All the routers keep on sending and receiving Hello packets in specific
interval to maintain and keep watch on NeighborState changes. 

The Neighbor Data Structure

State: The functional level of the neighbor conversation.

Inactivity Timer: A single shot timer whose firing indicates that no 

Hello Packet has been seen from this neighbor recently.  The length of the
timer is RouterDeadInterval seconds.

Master/Slave: 

When the two neighbors are exchanging databases, they form a master/slave
relationship. 

DD Sequence Number:

      The DD Sequence number of the Database Description packet that

      is currently being sent to the neighbor.

Last received Database Description packet:

      The initialize(I), more (M) and master(MS) bits, Options field,

and DD sequence number contained in the last Database Description packet
received from the neighbor. Used to determine whether the next Database
Description packet received from the neighbor is a duplicate.

Neighbor ID:

      The OSPF Router ID of the neighboring router.      

Neighbor Priority:

     The Router Priority of the neighboring router.

Neighbor IP address:

     The IP address of the neighboring router's interface to the

        attached network.  

Neighbor Options:

     The optional OSPF capabilities supported by the neighbor.

Neighbor's Designated Router:

     The neighbor's idea of the Designated Router.  

Neighbor's Backup Designated Router:

     The neighbor's idea of the Backup Designated Router.

Link state retransmission list:

     The list of LSAs that have been flooded but not acknowledged on

     this adjacency.  These will be retransmitted at intervals until

     they are acknowledged, or until the adjacency is destroyed.

Database summary list:

     The complete list of LSAs that make up the area link-state

     database, at the moment the neighbor goes into Database Exchange

     state. This list is sent to the neighbor in Database Description  

     packets.

Link state request list:

     The list of LSAs that need to be received from this neighbor in

     order to synchronize the two neighbors' link-state databases.

     This list is created as Database Description packets are

     received, and is then sent to the neighbor in Link State Request

     packets. The list is depleted as appropriate Link State Update

     packets are received.

Neighbor states

DOWN

ATTEMPT – In NBMA

INIT - In this state, an Hello packet has recently been seen from

       the neighbor.  However, bidirectional communication has not

       yet been established with the neighbor 

2-WAY: Router has seen either Hello packet consist of its own Router-ID 

       in the neighbors field OR received DBD packet. The (Backup)

       Designated Router is selected from the set of neighbors in

       state 2-Way or greater.

EXSTART: This is the first step in creating an adjacency between the

         two neighboring routers.  The goal of this step is to decide

         which router is the master, and to decide upon the initial

         DD sequence number.  Neighbor conversations in this state or

         greater are called adjacencies.

EXCHANGE: Database summaries are exchanged, LS Request & LS Updates are 

           also sent.

LOADING: In this state, Link State Request packets are sent to the     

neighbor asking for the more recent LSAs that have been discovered
(but not yet received) in the Exchange state.

FULL: In this state, the neighboring routers are fully adjacent. These 

        adjacencies will now appear in router-LSAs and network-LSAs.

Events

HelloReceived: An Hello packet has been received from the neighbor.

Start (NBMA): This is an indication that Hello Packets should now be 

        sent to the neighbor at intervals of HelloInterval seconds. 

2-WayReceived: Bidirectional communication has been realized between 

the two neighboring routers.  This is indicated by the router seeing itself
in the neighbor's Hello packet.

NegotiationDone: The Master/Slave relationship has been negotiated, and 

        DD sequence numbers have been exchanged.

ExchangeDone: Both routers have successfully transmitted a full 

        sequence of Database Description packets.  Each router now knows 

        what parts of its link state database are out of date.  

BadLSReq: A Link State Request has been received for an LSA not 

        contained in the database.  This indicates an error in the

        Database Exchange process.

LoadingDone: Link State Updates have been received for all out-of-date

            portions of the database.  This is indicated by the Link

            state request list becoming empty after the Database

            Exchange process has completed.

AdjOK?: A decision must be made as to whether an adjacency should be

        established/maintained with the neighbor.  This event will

        start some adjacencies forming, and destroy others.

The following events cause well developed neighbors to revert to lesser states.  
Unlike the above events, these events may occur when the neighbor conversation is
in any of a number of states.

SeqNumberMismatch: A Database Description packet has been received that 

either a) has an unexpected DD sequence number, b) unexpectedly has the Init
bit set or c) has an Options field differing from the last Options field
received in a Database Description packet.  Any of these conditions indicate
that some error has occurred during adjacency establishment.

1-Way: An Hello packet has been received from the neighbor, in which 

        the router is not mentioned. 

 KillNbr: This  is  an  indication that  all  communication  with  the

          neighbor  is now  impossible,  forcing  the  neighbor  to

          revert  to  Down  state.

 InactivityTimer: The inactivity Timer has fired. This means that no 

Hello packets have been seen recently from the neighbor. The neighbor reverts
to Down state.

 LLDown: This is an indication from the lower level protocols that the 

neighbor is now unreachable.

Event SeqNumberMismatch forces ExStart state,

Event BadLSReq forces ExStart state,

Event 1-Way forces Init state,

Event KillNbr always forces Down State,

Event InactivityTimer always forces Down State,

Event LLDown always forces Down State,

Event AdjOK? leads to adjacency forming/breaking

EVENTS: 

R3#debug ip ospf events

OSPF events debugging is on

R3 has just come up and sending Hello packets to multicast address 224.0.0.5 to all its interface. This Hello
packet’s Neighbor field is empty and DR/BDR field is set to 0.0.0.0

*Mar 1 00:00:29.635: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3

*Mar 1 00:00:29.639: OSPF: Send hello to 224.0.0.5 area 1 on Serial0/0 from 192.168.10.1

*Mar 1 00:00:39.635: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3

Dead Interval timer has expired (in this case it was 40 seconds) and InactivityTimer event is triggered, which in turn
triggered MAXAGE and deleted all LSAs from the database.

*Mar  1 00:00:42.347: OSPF: service_maxage: Trying to delete MAXAGE LSA

This is lead to the election of DR/BDR, electing itself to DR & BDR to none.

*Mar  1 00:00:49.635: OSPF: end of Wait on interface FastEthernet0/0

*Mar  1 00:00:49.635: OSPF: DR/BDR election on FastEthernet0/0

*Mar  1 00:00:49.635: OSPF: Elect BDR 0.0.0.255

*Mar  1 00:00:49.639: OSPF: Elect DR 0.0.0.255

*Mar  1 00:00:49.639: OSPF: Elect BDR 0.0.0.0

*Mar  1 00:00:49.639: OSPF: Elect DR 0.0.0.255

*Mar  1 00:00:49.643:        DR: 0.0.0.255 (Id)   BDR: none

Now it will keep sending hello packets until it discover any neighbors.

*Mar  1 00:00:49.643: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3

*Mar  1 00:00:59.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3

*Mar  1 00:01:09.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3

*Mar  1 00:01:19.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3

*Mar  1 00:01:29.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3

*Mar  1 00:01:39.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3

*Mar  1 00:01:49.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3

It received first multicast Hello packet from R2. Now the state of R3 gets changed to INIT. However, this Hello
packet’s neighbor field is empty too. So, 2-WayReceived event won’t generate and it won’t form 2-WAY adjacency
as of now. But R3 will check other fields (Area-ID, Interface-IP, Auth-type, Auth-Key, Hello-Interval, Dead-Interval)
to find out if R2 is eligible to be its neighbor.

*Mar  1 00:01:52.655: OSPF: Rcv hello from 0.0.0.254 area 0 from FastEthernet0/0 172.16.1.2

Eligibility criteria matched, thus R3 sent an Immediate Hello to R2. This unicast Hello will bring R2 to INIT state.

*Mar  1 00:01:52.659: OSPF: Send immediate hello to nbr 0.0.0.254, src address 172.16.1.2, on FastEthernet0/0

*Mar  1 00:01:52.663: OSPF: Send hello to 172.16.1.2 area 0 on FastEthernet0/0 from 172.16.1.3

*Mar  1 00:01:52.667: OSPF: End of hello processing

Likewise, R3 also received Hello packet from R1 and processed it the same way as above.

*Mar  1 00:01:55.319: OSPF: Rcv hello from 0.0.0.1 area 0 from FastEthernet0/0 172.16.1.1

*Mar  1 00:01:55.323: OSPF: Send immediate hello to nbr 0.0.0.1, src address 172.16.1.1, on FastEthernet0/0

*Mar  1 00:01:55.327: OSPF: Send hello to 172.16.1.1 area 0 on FastEthernet0/0 from 172.16.1.3

*Mar  1 00:01:55.327: OSPF: End of hello processing

Now, when both the Hello packets are processed and Hello-Interval is reached, it’s sending a multicast Hello
packet setting its neighbor field with Router-ID of both R2 & R1. This will trigger 2-WayReceived event on both
R2 & R1, because they will find there respective Router-ID in this Hello packet’s Neighbor field.

*Mar  1 00:01:59.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3

After 2-WayReceived event triggered on both parties, both R2 & R1 are now in 2-WAY state and are allowed to
conduct election. As election is also finished on R2, it’s in EXSTART state by sending its first DBD packet, claiming
it as a Master setting flag to 0x7 and generating a DD sequence no.

*Mar  1 00:01:59.771: OSPF: Rcv DBD from 0.0.0.254 on FastEthernet0/0 seq 0x264 opt 0x52 flag 0x7 len 32  mtu
1500 state INIT

Once R3 received this DBD packet, it will change its state to 2-WAY and will conduct election.

*Mar  1 00:01:59.771: OSPF: 2 Way Communication to 0.0.0.254 on FastEthernet0/0, state 2WAY

*Mar  1 00:01:59.775: OSPF: Neighbor change Event on interface FastEthernet0/0

*Mar  1 00:01:59.775: OSPF: DR/BDR election on FastEthernet0/0

*Mar  1 00:01:59.775: OSPF: Elect BDR 0.0.0.254

*Mar  1 00:01:59.775: OSPF: Elect DR 0.0.0.255

*Mar  1 00:01:59.775:        DR: 0.0.0.255 (Id)   BDR: 0.0.0.254 (Id)

DR & BDR is selected, which will appear in the next Hello packet that R3 will send.

Now, as elction is finished R3 will change its state to EXSTART sending the first DBD packet claiming it to be
Master.

*Mar  1 00:01:59.775: OSPF: Send DBD to 0.0.0.254 on FastEthernet0/0 seq 0xDAE opt 0x52 flag 0x7 len 32

*Mar  1 00:01:59.775: OSPF: First DBD and we are not SLAVE

Now, we can see R3 has received a multicast Hello packet from R2. This Hello packet contains R2’s discovery
of R1 in its Neighbor field. This triggered Neighbor change event on R3 and led to election again (one for each
neighbor).

*Mar  1 00:01:59.799: OSPF: Rcv hello from 0.0.0.254 area 0 from FastEthernet0/0 172.16.1.2

*Mar  1 00:01:59.799: OSPF: Neighbor change Event on interface FastEthernet0/0

*Mar  1 00:01:59.799: OSPF: DR/BDR election on FastEthernet0/0

*Mar  1 00:01:59.799: OSPF: Elect BDR 0.0.0.254

*Mar  1 00:01:59.799: OSPF: Elect DR 0.0.0.255

*Mar  1 00:01:59.799:        DR: 0.0.0.255 (Id)   BDR: 0.0.0.254 (Id)

*Mar  1 00:01:59.799: OSPF: Neighbor change Event on interface FastEthernet0/0

*Mar  1 00:01:59.799: OSPF: DR/BDR election on FastEthernet0/0

*Mar  1 00:01:59.799: OSPF: Elect BDR 0.0.0.254

*Mar  1 00:01:59.799: OSPF: Elect DR 0.0.0.255

*Mar  1 00:01:59.799:        DR: 0.0.0.255 (Id)   BDR: 0.0.0.254 (Id)

*Mar  1 00:01:59.799: OSPF: End of hello processing

R3 now received DBD packet echoed by R2. This DBD packet contains same DD sequence no. that R3 has
set and flag is also set to 0x2, which tells that R2 has agreed itself to be a Slave. This packet also contains LSA
Header, therefore M bit is set to 1. This will trigger NegotiationDone event on R3 too.

*Mar  1 00:01:59.847: OSPF: Rcv DBD from 0.0.0.254 on FastEthernet0/0 seq 0xDAE opt 0x52 flag 0x2 len 52  mtu
1500 state EXSTART

*Mar  1 00:01:59.851: OSPF: NBR Negotiation Done. We are the MASTER

Now both R3 & R2 are in EXCHANGE state. R3 is sending its second DBD packet incrementing the DD sequence
no.. Flag 0x3 tells that this packet contains LSA Header.

*Mar  1 00:01:59.855: OSPF: Send DBD to 0.0.0.254 on FastEthernet0/0 seq 0xDAF opt 0x52 flag 0x3 len 52

R3 received echoed DBD packet from R2. Flag is set to 0x0, which means this packet don’t contain any LSA
Header. Thus M bit is cleared indicating it has no more data to send. Now, as R2 has no more LSA Headers to
send it can now compare its own LSDB against the LSA Headers that it received during EXCHANGE state and
can start sending LS Request packets if any. 

*Mar  1 00:02:00.063: OSPF: Rcv DBD from 0.0.0.254 on FastEthernet0/0 seq 0xDAF opt 0x52 flag 0x0 len 32  mtu
1500 state EXCHANGE

R3 sends its last DBD incrementing the DD sequence no. and with flag setting to 0x1, that indicates it has no more
data to send. However, it will still expect a DBD echoed reply packet from Slave. As R3 has no more LSA Headers
to send, it can also now send LS Request packets if any.

*Mar  1 00:02:00.063: OSPF: Send DBD to 0.0.0.254 on FastEthernet0/0 seq 0xDB0 opt 0x52 flag 0x1 len 32

*Mar  1 00:02:00.063: OSPF: Send LS REQ to 0.0.0.254 length 12 LSA count 1

R3 received DBD packet from R1. This is the first DBD packet from R1 changing the state of R3 to 2-WAY with R1.
Rest of the process will be same as described earlier.

*Mar  1 00:02:00.063: OSPF: Rcv DBD from 0.0.0.1 on FastEthernet0/0 seq 0x18BD opt 0x52 flag 0x7 len 32  mtu
1500 state INIT

*Mar  1 00:02:00.063: OSPF: 2 Way Communication to 0.0.0.1 on FastEthernet0/0, state 2WAY

*Mar  1 00:02:00.063: OSPF: Neighbor change Event on interface FastEthernet0/0

*Mar  1 00:02:00.063: OSPF: DR/BDR election on FastEthernet0/0

*Mar  1 00:02:00.063: OSPF: Elect BDR 0.0.0.254

*Mar  1 00:02:00.063: OSPF: Elect DR 0.0.0.255

*Mar  1 00:02:00.063:        DR: 0.0.0.255 (Id)   BDR: 0.0.0.254 (Id)

*Mar  1 00:02:00.063: OSPF: Send DBD to 0.0.0.1 on FastEthernet0/0 seq 0x1B0 opt 0x52 flag 0x7 len 32

*Mar  1 00:02:00.063: OSPF: First DBD and we are not SLAVE

*Mar  1 00:02:00.063: OSPF: Rcv hello from 0.0.0.1 area 0 from FastEthernet0/0 172.16.1.1

*Mar  1 00:02:00.067: OSPF: Neighbor change Event on interface FastEthernet0/0

*Mar  1 00:02:00.067: OSPF: DR/BDR election on FastEthernet0/0

*Mar  1 00:02:00.071: OSPF: Elect BDR 0.0.0.254

*Mar  1 00:02:00.071: OSPF: Elect DR 0.0.0.255

*Mar  1 00:02:00.071:        DR: 0.0.0.255 (Id)   BDR: 0.0.0.254 (Id)

*Mar  1 00:02:00.075: OSPF: Neighbor change Event on interface FastEthernet0/0

*Mar  1 00:02:00.075: OSPF: DR/BDR election on FastEthernet0/0

*Mar  1 00:02:00.079: OSPF: Elect BDR 0.0.0.254

*Mar  1 00:02:00.079: OSPF: Elect DR 0.0.0.255

*Mar  1 00:02:00.079:        DR: 0.0.0.255 (Id)   BDR: 0.0.0.254 (Id)

*Mar  1 00:02:00.083: OSPF: End of hello processing

R3 received LS Request packet from R2 and sending LS Update packet thereafter.

*Mar  1 00:02:00.163: OSPF: Rcv LS REQ from 0.0.0.254 on FastEthernet0/0 length 36 LSA count 1

*Mar  1 00:02:00.167: OSPF: Send UPD to 172.16.1.2 on FastEthernet0/0 length 40 LSA count 1

R3 now received echoed DBD packet from R2 that it was expecting and that triggers ExchangeDone event. R2
changed its state to LOADING (triggering ExchangeDone event ) soon after sending this DBD packet.

*Mar  1 00:02:00.207: OSPF: Rcv DBD from 0.0.0.254 on FastEthernet0/0 seq 0xDB0 opt 0x52 flag 0x0 len 32  mtu
1500 state EXCHANGE

*Mar  1 00:02:00.207: OSPF: Exchange Done with 0.0.0.254 on FastEthernet0/0

R3’s EXSTART state continues with R1

*Mar  1 00:02:00.207: OSPF: Rcv DBD from 0.0.0.1 on FastEthernet0/0 seq 0x1B0 opt 0x52 flag 0x2 len 52  mtu 1500
state EXSTART

*Mar  1 00:02:00.207: OSPF: NBR Negotiation Done. We are the MASTER

R3’s EXCHANGE state continues with R1

*Mar  1 00:02:00.207: OSPF: Send DBD to 0.0.0.1 on FastEthernet0/0 seq 0x1B1 opt 0x52 flag 0x3 len 52

R3 in LOADING state received LS Update packet from R2 and sent LS Ack packet acknowledging the update.

*Mar  1 00:02:00.207: OSPF: Rcv LS UPD from 0.0.0.254 on FastEthernet0/0 length 64 LSA count 1

R3 expects no more LS Update packets. Thus, triggering the LoadingDone event. R3’s LSDB is now synchronized
with R2, changing the state of R3 to FULL with R2.

*Mar  1 00:02:00.207: OSPF: Synchronized with 0.0.0.254 on FastEthernet0/0, state FULL

*Mar  1 00:02:00.207: %OSPF-5-ADJCHG: Process 100, Nbr 0.0.0.254 on FastEthernet0/0 from LOADING to FULL,
Loading Done

R3’s EXCHANGE state continues with R1

*Mar  1 00:02:00.307: OSPF: Rcv DBD from 0.0.0.1 on FastEthernet0/0 seq 0x1B1 opt 0x52 flag 0x0 len 32  mtu 1500
state EXCHANGE

*Mar  1 00:02:00.311: OSPF: Send DBD to 0.0.0.1 on FastEthernet0/0 seq 0x1B2 opt 0x52 flag 0x1 len 32

*Mar  1 00:02:00.311: OSPF: Send LS REQ to 0.0.0.1 length 12 LSA count 1

*Mar  1 00:02:00.379: OSPF: Rcv DBD from 0.0.0.1 on FastEthernet0/0 seq 0x1B2 opt 0x52 flag 0x0 len 32  mtu 1500
state EXCHANGE

*Mar  1 00:02:00.379: OSPF: Exchange Done with 0.0.0.1 on FastEthernet0/0

R3’s LOADING state continues with R1

*Mar  1 00:02:00.383: OSPF: Rcv LS UPD from 0.0.0.1 on FastEthernet0/0 length 64 LSA count 1

R3’s state is FULL with R1

*Mar  1 00:02:00.387: OSPF: Synchronized with 0.0.0.1 on FastEthernet0/0, state FULL

*Mar  1 00:02:00.387: %OSPF-5-ADJCHG: Process 100, Nbr 0.0.0.1 on FastEthernet0/0 from LOADING to FULL,
Loading Done

Now, whenever there will be any update in the network, DR & BDR will multicast LS Update packets to 224.0.0.5 &
DROTHER will multicast at 224.0.0.6 (which will be received by only DR & BDR). LS Update packets will always be
acknowledged by LS Ack packet by the recipients.

*Mar  1 00:02:00.659: OSPF: Rcv LS UPD from 0.0.0.254 on FastEthernet0/0 length 64 LSA count 1

*Mar  1 00:02:00.755: OSPF: Rcv LS UPD from 0.0.0.1 on FastEthernet0/0 length 64 LSA count 1

Regular multicast Hello packets will be sent and received to keep track of any neighbor changes.

*Mar  1 00:02:00.919: OSPF: Rcv hello from 0.0.0.254 area 0 from FastEthernet0/0 172.16.1.2

*Mar  1 00:02:00.923: OSPF: End of hello processing

*Mar  1 00:02:01.263: OSPF: Rcv hello from 0.0.0.1 area 0 from FastEthernet0/0 172.16.1.1

*Mar  1 00:02:01.263: OSPF: Neighbor change Event on interface FastEthernet0/0

*Mar  1 00:02:01.267: OSPF: DR/BDR election on FastEthernet0/0

*Mar  1 00:02:01.267: OSPF: Elect BDR 0.0.0.254

*Mar  1 00:02:01.267: OSPF: Elect DR 0.0.0.255

*Mar  1 00:02:01.271:        DR: 0.0.0.255 (Id)   BDR: 0.0.0.254 (Id)

*Mar  1 00:02:01.271: OSPF: End of hello processing

*Mar  1 00:02:04.631: OSPF: Rcv LS UPD from 0.0.0.1 on FastEthernet0/0 length 64 LSA count 1

*Mar  1 00:02:04.711: OSPF: Rcv LS UPD from 0.0.0.254 on FastEthernet0/0 length 64 LSA count 1

*Mar  1 00:02:05.287: OSPF: Rcv LS UPD from 0.0.0.1 on FastEthernet0/0 length 64 LSA count 1

*Mar  1 00:02:09.507: OSPF: Rcv hello from 0.0.0.254 area 0 from FastEthernet0/0 172.16.1.2

*Mar  1 00:02:09.511: OSPF: End of hello processing

*Mar  1 00:02:09.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3

*Mar  1 00:02:09.975: OSPF: Rcv hello from 0.0.0.1 area 0 from FastEthernet0/0 172.16.1.1

*Mar  1 00:02:09.975: OSPF: End of hello processing

*Mar  1 00:02:18.895: OSPF: Rcv hello from 0.0.0.254 area 0 from FastEthernet0/0 172.16.1.2

*Mar  1 00:02:18.899: OSPF: End of hello processing

*Mar  1 00:02:19.231: OSPF: Rcv hello from 0.0.0.1 area 0 from FastEthernet0/0 172.16.1.1

*Mar  1 00:02:19.231: OSPF: End of hello processing

*Mar  1 00:02:19.647: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 172.16.1.3

*Mar  1 00:02:27.967: OSPF: Rcv hello from 0.0.0.254 area 0 from FastEthernet0/0 172.16.1.2

*Mar  1 00:02:27.967: OSPF: End of hello processing

R3#u all

All possible debugging has been turned off

R3#