Re: snmp issue

BTW

default is v1 as no version keyword is mentioned in the configs

snmp-server community string RO 1
snmp-server community string RW 1
snmp-server trap-source Loopback0
snmp-server enable traps snmp authentication linkdown linkup coldstart
warmstart
snmp-server enable traps bgp
snmp-server host x.x.x.x string
snmp-server host x.x.x.x string
snmp ifmib ifindex persist

so I guess it's receiving v2 from CE-CE iBGP link from NMS and fails to
convert the traps, would that be correct assumption? therefore the NMS
needs to be set to send v1 & not v2?

On 12 February 2013 19:27, Tony Singh <mothafungla_at_gmail.com> wrote:

>
> Good evening list
>
> I have an snmp issue on an ASR, the NMS reports it as uncontactable..
>
>
> it seems to be generating packets to udp 161 but no replies are seen from
> the WAN interface and the ones that are seen are coming in on an ibgp
> connection with the other CE,
>
> debug snmp pack
>
> *Feb 12 01:37:28.937: SNMP: Packet sent via UDP to x.x.x.x
> *Feb 12 01:37:28.942: SNMP: Packet sent via UDP to x.x.x.x
>
>
>
> debug snmp detail
>
> Not sure if I should be worried about below??
>
> SrV2GenerateNotification:Function has reached clean up routine.
> *convert_pdu:Conversion between V2 and V1 notification failed.*
> CheckMIBView: OID is in MIB view.
> CheckMIBView: OID is in MIB view.
> CheckMIBView: OID is in MIB view.
> CheckMIBView: OID is in MIB view.
> CheckMIBView: OID is in MIB view.
> SrCheckNotificationFilter: OID is included.
> SrCheckNotificationFilter: OID is included.
> SrCheckNotificationFilter: OID is included.
> SrCheckNotificationFilter: OID is included.
> SrCheckNotificationFilter: OID is included.
> Sr_send_trap: trap sent to x.x.x.x:162
>
>
> now the device can reach both NMS servers via icmp ok via the source
> loopback0 of the traps & the configs have been checked 100 times to be same
> as the other working CE partner so it's not this... also the config has
> been re-applied to eliminate
>
> hostname#show snmp
> Chassis: (omitted)
> 1252189 SNMP packets input
> 0 Bad SNMP version errors
> 10326 Unknown community name
> 7 Illegal operation for community name supplied
> 0 Encoding errors
> 11322135 Number of requested variables
> 0 Number of altered variables
> 991671 Get-request PDUs
> 246181 Get-next PDUs
> 7 Set-request PDUs
> 0 Input queue packet drops (Maximum queue size 1000)
> 2413792 SNMP packets output
> 0 Too big errors (Maximum packet size 1500)
> 9894 No such name errors
> 0 Bad values errors
> 0 General errors
> 1238167 Response PDUs
> 1171929 Trap PDUs
>
> SNMP logging: enabled
> Logging to x.x.x.x.162, 0/10, 578622 sent, 6496 dropped.
> Logging to x.x.x.x.162, 0/10, 578622 sent, 6496 dropped.
>
>
> the dropped counters, unknown community name & no such name errors is
> historic and has not incremented since t-shooting....& input/outputs
> increment ok
>
>
> also it seems to queue the udp it send to the NMS where as the "working"
> CE does not
>
> *Feb 12 12:07:41.157: SNMP: Queuing packet to x.x.x.x
>
>
> when it receives an snmp udp it receives them on the CE-CE iBGP link
>
> *Feb 12 12:09:26.667: SNMP: Packet received via UDP from x.x.x.x on
> GigabitEthernet0/0/7.1
>
>
> and for some reason starts generating a V1 trap
>
> *Feb 12 12:08:51.142: SNMP: V1 Trap, ent ciscoMgmt.187, addr loopback0,
> gentrap 6, spectrap 1
>
>
>
> now having checked the trace to the NMS it goes over the eBGP WAN link &
> both NMS servers ip's are learnt via eBGP
>
> it's almost like the loopback0 source of the snmp traps on the CE is not
> seen from the WAN side
>
> don't have jurisdiction that far..
>
> also don't have access to the NMS to check from that side but is their
> anything else that I can gauge your suggestions on..
>
> thanks in advance
>
> Tony

Blogs and organic groups at http://www.ccie.net
Received on Tue Feb 12 2013 - 19:48:13 ART