Re: Query on implementation of SNMP TRAP ospfTxRetransmit

[Igor Miroshnik <[e-mail]>]

Dear All,

The previous discussion seems to converge at using the first LSDB entry to
associate the trap with. I wonder, what one can do when retransmitting
empty DB summaries. (For instanse, when the master has nothing to send but
still expects something from the slave.)

On Thu, 31 Oct 2002 15:49:51 +0530, Roy Jose <[e-mail]> wrote:

>Hi  Venkata, Acee,
>
>Thanks for your responses. I think, I will also use the first LSA. The NM
>station doesn't always sit in the network, where congestion has happened.
>
>Thanks,
>Roy
>
>> Acee,
>>
>> -> I haven't implemented this trap but I'd just use the first LSA in
>> -> packet.
>>
>>   My implementation uses the first LSA.
>>
>> -> Not speaking as WG co-chair and being completely
>> -> honest, I can't imagine why anyone would enable this trap in the
>> -> first place. One of the main causes of retransmissions is congestion
>> -> and sending this trap would only exacerbate matters.
>>
>>   Frankly, I used this trap to figure out some of the
>>   bugs in the past. Traps are sent to network manager
>>   and in most of the cases NM is out-of-band signaling.
>>   Congestion exacerbating in the data path is nothing
>>   to do with sending the trap.
>>
>>   For that matter, a packet not reaching the destination
>>   may be because of thousands of reasons not necessarily
>>   because of congestion.
>>
>>   For example, link local LSAs should go on the exact
>>   interface it is supposed to go (with out looking at
>>   the route tables) - for that we have to enable some
>>   of the IP socket options. If not, link local LSAs are
>>   keep on retransmitted but never acked back. Until
>>   unless admin gets a traps he/she can never figure out
>>   why a particular message/packet/LSA is being flapped.
>>   (unless he checks the error statistics/RtmsQ explicitly)
>>
>> --
>> Venkata.
>>