Hi Ramakrisha, You are correct and my implementation does, in fact, generate a SeqNumberMismatch event in this case. Thanks, Acee On Sep 20, 2013, at 3:03 AM, RAMAKRISHNADTV wrote:
> Hi, > > Could you please clarify the following point in OSPFv2 (RFC 2328) w.r.t > stub areas? > > The following is excerpted from Section 10.6 (Receiving Database Description > Packets): > > When the router accepts a received Database Description Packet > as the next in sequence the packet contents are processed as > follows. For each LSA listed, the LSA's LS type is checked for > validity. If the LS type is unknown (e.g., not one of the LS > types 1-5 defined by this specification), or if this is an AS- > external-LSA (LS type = 5) and the neighbor is associated with a > stub area, generate the neighbor event SeqNumberMismatch and > stop processing the packet. Otherwise, the router looks up the > LSA in its database to see whether it also has an instance of > ... > > This is correctly saying that stub areas should not process external > LSAs (LS type 5). But what about type 4 summary LSAs (related to ASBR)? > As far as I understand, stub areas should not receive these LSAs. > But this paragraph is not explicit about it. I believe this paragraph > needs to be updated to indicate that received type 4 summary LSAs and > type 5 external LSAs should elicit the same behavior in stub areas: > generate the neighbor event SeqNumberMismatch and stop processing the > packet. > > On the other hand, originating LSA side description in RFC correctly > states as follows. > > From Section 12.4.3 (Summary-LSAs): > > ...If so, a Type 4 summary-LSA is originated for the > destination, with Link State ID equal to the AS boundary > router's Router ID and metric equal to the routing table > entry's cost. Note: these LSAs should not be generated > if Area A has been configured as a stub area.... > > Regards, > Ramakrishna DTV. > > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, > please > notify the sender by e-mail and delete the original message. Further, you are > not > to copy, disclose, or distribute this e-mail or its contents to any other > person and > any such actions are unlawful. This e-mail may contain viruses. Infosys has > taken > every reasonable precaution to minimize this risk, but is not liable for any > damage > you may sustain as a result of any virus in this e-mail. You should carry out > your > own virus checks before opening the e-mail or attachment. Infosys reserves > the > right to monitor and review the content of all messages sent to or from this > e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
