Re: draft-ietf-vrrp-unified-mib-06: Usage of vrrpTrapProtoError
"G. C." <[email protected]> Wed, 2 Jul 2008 08:57:50 -0400
| Newsgroups | gmane.ietf.vrrp |
|---|---|
| Message-ID | <[email protected]> |
Hi Kaylan, I propose that vrrpTrapProtoErrorEnable should be disabled by default. The operator can then turn this on if (s)he cares about receiving this trap. On a scaled system with numerous interfaces configured with multiple VRRPs, these traps will have a big impact and we won't be able to maintain sub-second timers as recommended by the VRRP draft. Regards, Georges Chung On Wed, Jul 2, 2008 at 1:23 AM, <[email protected]> wrote: > Hi Georges, > As I remember, the original intent was to identify miss configurations > using this trap. You are correct that this needs to be sent every time > the error condition happens and could cause overhead. probably we > should add vrrpTrapProtoErrorEnable which by default is enabled but > can be turned off? > > I promised Mukesh that I will start working on updating the draft in > the next couple of weeks. I will update the draft based on the WG suggestion > on this. > > Can the reason hopLimitError be renamed to IpTllError to be consistent with > vrrpStatisticsIpTtlErrors? > Will do. > > Thanks, > Kalyan > > > ------------------------------ > *From:* ext G. C. [mailto:[email protected]] > *Sent:* Friday, June 27, 2008 5:52 AM > *To:* [email protected]; Tata Kalyan (Nokia-S&S/MtView) > *Subject:* draft-ietf-vrrp-unified-mib-06: Usage of vrrpTrapProtoError > > After reading the draft, I am under the impression that the trap > vrrpTrapProtoError is expected to be raised every time an error condition > happens. Can someone please confirm whether this is indeed the intention of > the draft? > > This means that there will be *lots* of these being raised, one per > offending packet that is received. This will add unnecessary overhead to > the CPU. > > Can the reason hopLimitError be renamed to IpTllError to be consistent with > vrrpStatisticsIpTtlErrors? > > Thanks, > Georges Chung > _______________________________________________ vrrp mailing list [email protected] https://www.ietf.org/mailman/listinfo/vrrp