We are using Ciscoworks lms 3.0 in our network.
We have enabled snmp server community and traps on routers.
Even in ciscoworks snmp trap receiving is working on port 162
If the router went down we are receiving error Unresponsive component, down time etc.
But we are not getting the reason for which the link went down, though we enabled traps for bgp etc.
Please help to get traps form routers.
We might be able provide better suggestions if you could post the specific configuration of the router where you enable the traps.
LMS does not include a general trap receiver application. While DFM can receive traps, it only processes a small subset of them. A DFM Unresponsive event means that a device or interface is either unreachable via ICMP or SNMP. The event should tell you what IP address or device is unresponsive. From there, you can confirm if it is reachable via ping and SNMP.
i enable trap for BGP in router and i dont get the error indicating that the link was down because of bgp down.
i want to get the mail from DFm indicating the reason why the link went down.
Perhaps I am not understanding your post correctly. I thought that the issue was that you were not receiving BGP traps. This post makes it clear that the problem is what is causing the link to go down. BGP does not cause a link to go down. (perhaps the link going down might cause BGP to go down, but BGP going down will not cause a link failure).
Perhaps it might help if we knew a bit more about the router in question and the topology of the network. Is it perhaps the case that the link that goes down is the link that carries the traps from the router to the SNMP server? I have seen the situation many times that a router generates a trap (such as a link failure) but can not send the trap because the link that went down was the link that provides connectivity to the server. If connectivity to the server is interrupted then no traps will be received by the server.
Is this perhaps the case in your situation?
we have 30 remote sites connected to our network through ISP .we have bgp as number and it is under control of isp.
if the link went down we get mail from ciscoworks that the remote component is unresposive.
i have enabled snmp server and enabled bgp traps on remote routers.
BGP traps shuld be sent to dfm and we should get the mail that link is down because bgp is down or router is operaionally down (i.e is resarted).
we want ciscoworks to sent snmp traps from log and sent to our mail.
i think this will help to understand my probelm.
please help me to get traps mentioning the reason.
If you have 30 remote sites connected to your network, do the remote sites have only a single connection to your network, or if the primary link fails do they have a backup connection?
It sounds to me as if each remote site has only the single connection to your network and that would be the connection that would carry the trap to the server. If that link goes down then the remote router can try to generate the trap, but if its link to the server is down then the trap will never be delivered to the server.
The server can poll the remote router. And this allows the server to detect when the remote router is down. The server does not depend on the link to the remote to determine if the remote has stopped responding. But the link to the remote is crucial to delivery of the trap.
If there is not a backup link from the remote to the server then I do not see how you will be able to get traps from the remote when there is a problem.
DFM does not process BGP traps. While your device may be sending the traps, DFM will never display them. You will need another, general purpose trap receiver in order to do this.
However, if a remote device goes down because of a BGP failure, DFM will report the device as unreachable since it does periodic ICMP and SNMP polling of the device. The local router (i.e. the one that DFM can still reach) will still appear reachable to DFM.
They can be found in the DFM User Guide:
Is it possible to know if a BGP neighbor is down (not ping reachability only) through SNMP, SYSLOG or IP SLA? Preferably in Ciscoworks