snmp monitoring
in [Cisco]
|
From: mmark751969 on 2 Jun 2010 23:13 On Jun 2, 7:18 pm, bod43 <Bo...(a)hotmail.co.uk> wrote: > On 2 June, 18:02, Rob <nom...(a)example.com> wrote: > > > > > > > mmark751969 <mmark751...(a)yahoo.com> wrote: > > > On Jun 2, 7:59 am, Rob <nom...(a)example.com> wrote: > > >> mmark751969 <mmark751...(a)yahoo.com> wrote: > > >> > I have a situation where i need to do snmp monitoring from a central > > >> > location to a number of remote site servers, switches, routers etc.. I > > >> > originally set this up via ipsec vpn's between the central site c1841 > > >> > and the remote site pix 501 and 506's, and c1800's. The ipsec vpn's > > >> > will renegotiate their sa's and when doing this will drop the vpn and > > >> > then false positives will be generated. Have tried to resolve this > > >> > with keepalives and other methods but it still happens. I've also > > >> > done this through assigning a static nat translation on the remote > > >> > site and opening up the router/firewall for snmp(udp 161)from our > > >> > central location and this works with no issues. I'm wondering if i > > >> > need to be concerned about security with this method. The data being > > >> > transferred is device statistical information and status and i'm > > >> > assigning the snmp level as read only on a different community name > > >> > than the default. wondering if this is an accepted method and how > > >> > most people do this > > > >> Maybe you need to look into your dropping vpn problem, as this is > > >> not what I usually experience. The vpn keeps working all the time..- Hide quoted text - > > > >> - Show quoted text - > > > > Thanks. what are your end devices. > > > 3725, 1721, 877, 887, Draytek 2600, 2800 all with IPsec vpn. > > My recollection is that in good time before the SAs time > out a new one is negotiated and the traffic then switches > to the new SA, well before the previous SA is closed. > > Perhaps you have some weird timeouts configured > that is breaking that mechanism? > > I have only ever used the defaults and as long as there is > regular traffic they never go down. > > Maybe of course if the polling interval is long, then > the SAs are going down since there is no traffic. In that > case there will be a delay establishing a new SA which > could result in an snmp timeout since it takes a while for > the crypto to get its head together. > > There is probably a setting to stop the SA going down even > if there is no traffic or you could create sufficient traffic > so that it does not go down. There are many options > to create some traffic nowadays. > > - SAA poll > - ntp > - turn up your snmp frequency- Hide quoted text - > > - Show quoted text - Thanks. I'll try increasing snmp polling frequence. right now it's at two minutes. I'll decrease that. Thanks
From: Rob on 3 Jun 2010 03:21
mmark751969 <mmark751969(a)yahoo.com> wrote: > Thanks. I'll try increasing snmp polling frequence. right now it's > at two minutes. I'll decrease that. Thanks At two minutes there should be no problem whatsoever. The typical IPsec SA lifetime is one hour. I have SNMP polling every 5 minutes (by MRTG) and at some irregular intervals by other scripts, and I see no problems. There must be something wrong with your VPN config. When you have configuration for time values, remove it all. The defaults should work OK. |