Ok, for anyone else who is interested:
Actions taken on received update LSAs:
*
*
*Else, if the received LSA is the same instance as the database
copy (i.e., neither one is more recent) the following two steps
should be performed:
*
* (a) If the LSA is listed in the Link state retransmission list
for the receiving adjacency, the router itself is expecting
an acknowledgment for this LSA. The router should treat the
received LSA as an acknowledgment by removing the LSA from
the Link state retransmission list. This is termed an
"implied acknowledgment". Its occurrence should be noted
for later use by the acknowledgment process (Section 13.5).*
This is in step 7 of section 13 of the RFC
Basically if the LSA is on the originating router's retransmission list, but
it then receives an update from the neighbor with a copy of that LSA, the
implicit acknowledgement is done, nothing further.
then here's 13.5, which covers acknowledgements in general and references
the above, also comes with a handy table describing what situations merit
direct vs delayed acknowledgements, but Doyle does this better:
* 13.5. Sending Link State Acknowledgment packets
Each newly received LSA must be acknowledged. This is usually
done by sending Link State Acknowledgment packets. However,
acknowledgments can also be accomplished implicitly by sending
Link State Update packets (see step 7a of Section 13).
Many acknowledgments may be grouped together into a single Link
State Acknowledgment packet. Such a packet is sent back out the
interface which received the LSAs. The packet can be sent in
one of two ways: delayed and sent on an interval timer, or sent
directly to a particular neighbor. The particular
acknowledgment strategy used depends on the circumstances
surrounding the receipt of the LSA.
Sending delayed acknowledgments accomplishes several things: 1)
it facilitates the packaging of multiple acknowledgments in a
single Link State Acknowledgment packet, 2) it enables a single
Link State Acknowledgment packet to indicate acknowledgments to
several neighbors at once (through multicasting) and 3) it
randomizes the Link State Acknowledgment packets sent by the
various routers attached to a common network. The fixed
interval between a router's delayed transmissions must be short
(less than RxmtInterval) or needless retransmissions will ensue.
Direct acknowledgments are sent directly to a particular
neighbor in response to the receipt of duplicate LSAs. Direct
acknowledgments are sent immediately when the duplicate is
received. On multi-access networks, these acknowledgments are
sent directly to the neighbor's IP address.
The precise procedure for sending Link State Acknowledgment
packets is described in Table 19. The circumstances surrounding
the receipt of the LSA are listed in the left column. The
acknowledgment action then taken is listed in one of the two
right columns. This action depends on the state of the
concerned interface; interfaces in state Backup behave
differently from interfaces in all other states. Delayed
acknowledgments must be delivered to all adjacent routers
associated with the interface. On broadcast networks, this is
accomplished by sending the delayed Link State Acknowledgment
packets as multicasts. The Destination IP address used depends
Moy Standards Track [Page 152]
RFC 2328 OSPF Version 2 April 1998
Action taken in state
Circumstances Backup All other states
_________________________________________________________________
LSA has No acknowledgment No acknowledgment
been flooded back sent. sent.
out receiving in-
terface (see Sec-
tion 13, step 5b).
_________________________________________________________________
LSA is Delayed acknowledg- Delayed ack-
more recent than ment sent if adver- nowledgment sent.
database copy, but tisement received
was not flooded from Designated
back out receiving Router, otherwise
interface do nothing
_________________________________________________________________
LSA is a Delayed acknowledg- No acknowledgment
duplicate, and was ment sent if adver- sent.
treated as an im- tisement received
plied acknowledg- from Designated
ment (see Section Router, otherwise
13, step 7a). do nothing
_________________________________________________________________
LSA is a Direct acknowledg- Direct acknowledg-
duplicate, and was ment sent. ment sent.
not treated as an
implied ack-
nowledgment.
_________________________________________________________________
LSA's LS Direct acknowledg- Direct acknowledg-
age is equal to ment sent. ment sent.
MaxAge, and there is
no current instance
of the LSA
in the link state
database, and none
of router's neighbors
are in states Exchange
*
On Thu, Jun 3, 2010 at 3:11 PM, Joshua Yost <[email protected]> wrote:
> Sweet, thanks for the info.
>
>
> On Thu, Jun 3, 2010 at 1:36 PM, Tyson Scott <[email protected]> wrote:
>
>> Any time two neighbors are first forming an adjacency and are going thru
>> the INIT 2-WAY ExStart Exchange Loading Full process; LSA's must be
>> explicitly acknowledged.
>>
>>
>>
>> Most of the time explicit acknowledgements are used between neighbors on a
>> segment.
>>
>>
>>
>> When the OSPF flooding interval is occurring and a device on a segment
>> receives a bunch of LSA's it may decide to group all the LSA's together and
>> send an implicit LSA acknowledgement thru a single LSA Ack instead of
>> sending an explicit acknowledgement for each LSA.
>>
>>
>>
>> And the third is it must send an explicit any time it decides not to
>> forward an LSA either because of an error or better SPF known locally.
>>
>>
>>
>> This is from RFC 2328 which is the OSPFv2 RFC. Look it up and see if you
>> can find any more information if you are interested.
>>
>>
>>
>> If you are looking for more detail then that you are going to have to go
>> to the writer of the RFC ;). I am not sure of any more detail than above.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Tyson Scott - CCIE #13513 R&S, Security, and SP
>>
>> Managing Partner / Sr. Instructor - IPexpert, Inc.
>>
>> Mailto: [email protected]
>>
>> Telephone: +1.810.326.1444, ext. 208
>>
>> Live Assistance, Please visit: www.ipexpert.com/chat
>>
>> eFax: +1.810.454.0130
>>
>>
>>
>> IPexpert is a premier provider of Self-Study Workbooks, Video on Demand,
>> Audio Tools, Online Hardware Rental and Classroom Training for the Cisco
>> CCIE (R&S, Voice, Security & Service Provider) certification(s) with
>> training locations throughout the United States, Europe, South Asia and
>> Australia. Be sure to visit our online communities at
>> www.ipexpert.com/communities and our public website at www.ipexpert.com
>>
>>
>>
>> *From:* Joshua Yost [mailto:[email protected]]
>> *Sent:* Thursday, June 03, 2010 2:23 PM
>> *To:* Tyson Scott
>> *Cc:* ccie_rs
>> *Subject:* Re: [OSL | CCIE_RS] OSPF Acknowledgements
>>
>>
>>
>> "Decides not to forward the LSA"
>>
>> When could this happen? I am thinking that this means like in a DR/BDR
>> situation where the only routers sending to ALLSPFROUters are the DR and
>> BDR, so the neighbors need to ackknowledge specifically as they are not
>> flooding? Does that seem right?
>>
>>
>> On Thu, Jun 3, 2010 at 12:06 PM, Tyson Scott <[email protected]>
>> wrote:
>>
>> That is a great question. Doyle is the man so I am going to hope this is
>> helpful.
>>
>>
>>
>> Explicit acknowledgements are required anytime the router decides not to
>> forward the LSA as part of the flooding procedure.
>>
>> The article that I found that states this is RFC 5449 on OSPFv3 but I
>> think the same principle applies
>>
>> It is found in Section 5.4.2 Paragraph 3 sub-paragraph 2.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Tyson Scott - CCIE #13513 R&S, Security, and SP
>>
>> Managing Partner / Sr. Instructor - IPexpert, Inc.
>>
>> Mailto: [email protected]
>>
>> Telephone: +1.810.326.1444, ext. 208
>>
>> Live Assistance, Please visit: www.ipexpert.com/chat
>>
>> eFax: +1.810.454.0130
>>
>>
>>
>> IPexpert is a premier provider of Self-Study Workbooks, Video on Demand,
>> Audio Tools, Online Hardware Rental and Classroom Training for the Cisco
>> CCIE (R&S, Voice, Security & Service Provider) certification(s) with
>> training locations throughout the United States, Europe, South Asia and
>> Australia. Be sure to visit our online communities at
>> www.ipexpert.com/communities and our public website at www.ipexpert.com
>>
>>
>>
>> *From:* [email protected] [mailto:
>> [email protected]] *On Behalf Of *Joshua Yost
>> *Sent:* Thursday, June 03, 2010 11:31 AM
>> *To:* ccie_rs
>> *Subject:* [OSL | CCIE_RS] OSPF Acknowledgements
>>
>>
>>
>> When/How are implicit acknowledgements of LSAs done as opposed to
>> Explicit Acknowledgements? Per Doyle, implicit is we just send a copy of the
>> LSA back to the originating neighbor in an update. Explicit would be direct
>> or delayed Link State Acknowledgement. It is explained when direct vs
>> delayed is used, but not explained when implict vs explicit is used.
>>
>>
>>
>
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
