10.5. Receiving Hello Packets
Connected: An Internet Encyclopedia
10.5. Receiving Hello Packets
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1583
Up:
10. The Neighbor Data Structure
Prev: 10.4. Whether to become adjacent
Next: 10.6. Receiving Database Description Packets
10.5. Receiving Hello Packets
10.5. Receiving Hello Packets
This section explains the detailed processing of a received
Hello Packet. (See Section A.3.2 for the format of Hello
packets.) The generic input processing of OSPF packets will
have checked the validity of the IP header and the OSPF packet
header. Next, the values of the Network Mask, HelloInterval,
and RouterDeadInterval fields in the received Hello packet must
be checked against the values configured for the receiving
interface. Any mismatch causes processing to stop and the
packet to be dropped. In other words, the above fields are
really describing the attached network's configuration. However,
there is one exception to the above rule: on point-to-point
networks and on virtual links, the Network Mask in the received
Hello Packet should be ignored.
The receiving interface attaches to a single OSPF area (this
could be the backbone). The setting of the E-bit found in the
Hello Packet's Options field must match this area's
ExternalRoutingCapability. If AS external advertisements are
not flooded into/throughout the area (i.e, the area is a "stub")
the E-bit must be clear in received Hello Packets, otherwise the
E-bit must be set. A mismatch causes processing to stop and the
packet to be dropped. The setting of the rest of the bits in
the Hello Packet's Options field should be ignored.
At this point, an attempt is made to match the source of the
Hello Packet to one of the receiving interface's neighbors. If
the receiving interface is a multi-access network (either
broadcast or non-broadcast) the source is identified by the IP
source address found in the Hello's IP header. If the receiving
interface is a point-to-point link or a virtual link, the source
is identified by the Router ID found in the Hello's OSPF packet
header. The interface's current list of neighbors is contained
in the interface's data structure. If a matching neighbor
structure cannot be found, (i.e., this is the first time the
neighbor has been detected), one is created. The initial state
of a newly created neighbor is set to Down.
When receiving an Hello Packet from a neighbor on a multi-access
network (broadcast or non-broadcast), set the neighbor
structure's Neighbor ID equal to the Router ID found in the
packet's OSPF header. When receiving an Hello on a point-to-
point network (but not on a virtual link) set the neighbor
structure's Neighbor IP address to the packet's IP source
address.
Now the rest of the Hello Packet is examined, generating events
to be given to the neighbor and interface state machines. These
state machines are specified either to be executed or scheduled
(see Section 4.4). For example, by specifying below that the
neighbor state machine be executed in line, several neighbor
state transitions may be effected by a single received Hello:
- Each Hello Packet causes the neighbor state machine to be
executed with the event HelloReceived.
- Then the list of neighbors contained in the Hello Packet is
examined. If the router itself appears in this list, the
neighbor state machine should be executed with the event 2-
WayReceived. Otherwise, the neighbor state machine should
be executed with the event 1-WayReceived, and the processing
of the packet stops.
- Next, the Hello Packet's Router Priority field is examined.
If this field is different than the one previously received
from the neighbor, the receiving interface's state machine
is scheduled with the event NeighborChange. In any case,
the Router Priority field in the neighbor data structure
should be updated accordingly.
- Next the Designated Router field in the Hello Packet is
examined. If the neighbor is both declaring itself to be
Designated Router (Designated Router field = Neighbor IP
address) and the Backup Designated Router field in the
packet is equal to 0.0.0.0 and the receiving interface is in
state Waiting, the receiving interface's state machine is
scheduled with the event BackupSeen. Otherwise, if the
neighbor is declaring itself to be Designated Router and it
had not previously, or the neighbor is not declaring itself
Designated Router where it had previously, the receiving
interface's state machine is scheduled with the event
NeighborChange. In any case, the Neighbors' Designated
Router item in the neighbor structure is updated
accordingly.
- Finally, the Backup Designated Router field in the Hello
Packet is examined. If the neighbor is declaring itself to
be Backup Designated Router (Backup Designated Router field
= Neighbor IP address) and the receiving interface is in
state Waiting, the receiving interface's state machine is
scheduled with the event BackupSeen. Otherwise, if the
neighbor is declaring itself to be Backup Designated Router
and it had not previously, or the neighbor is not declaring
itself Backup Designated Router where it had previously, the
receiving interface's state machine is scheduled with the
event NeighborChange. In any case, the Neighbor's Backup
Designated Router item in the neighbor structure is updated
accordingly.
On non-broadcast multi-access networks, receipt of an Hello
Packet may also cause an Hello Packet to be sent back to the
neighbor in response. See Section 9.5.1 for more details.
Next: 10.6. Receiving Database Description Packets
Connected: An Internet Encyclopedia
10.5. Receiving Hello Packets
|