Just following up - Below is a very simple example of using ip sla to verify
connectivity and using SNMP to Querying the RTTMON-MIB
rttMonLatestRttOperSense variable (a successful event will result in a 1)
If you use a system like Cacti - you may be interested in this thread which
discusses using IP SLA templates
http://forums.cacti.net/viewtopic.php?t=19542 or if you use Nagios
http://www.monitoringexchange.org/inventory/Check-Plugins/Network/Cisco/Cisco-IP-SLA-monitoringmight
be worth checking out.
R1
------
interface FastEthernet0/0.10
description Facing R2
encapsulation dot1Q 10
ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet1/0
descripting Facing NMS
ip address 192.168.2.1 255.255.255.0
!
ip sla 10
icmp-echo 192.168.1.2 source-interface FastEthernet0/0.10
request-data-size 1400
timeout 500
threshold 2000
verify-data
frequency 15
ip sla schedule 10 life forever start-time now
ip sla 20
icmp-echo 2.2.2.2 source-interface FastEthernet0/0.10
request-data-size 1400
timeout 500
threshold 2000
verify-data
frequency 15
ip sla schedule 20 life forever start-time now
ip route 2.2.2.2 255.255.255.255 192.168.1.2
snmp-server community public RO
R2
-----
interface FastEthernet0/0.10
encapsulation dot1Q 10
ip address 192.168.1.1 255.255.255.0
!
interface loopback0
ip address 2.2.2.2 255.255.255.255
!
----------------------------------------------------
R1 is our CE router and R2 is the SP network
ip sla 10 is tracking the SP interface facing R1 with fa0/0.10 as the source
interface
ip sla 20 is tracking an IP beyond fa0/0.10
Things are all operational:
R1#sh ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 10
Type of operation: icmp-echo
Latest RTT: 4 milliseconds
Latest operation start time: *19:19:33.679 UTC Sun Aug 22 2010
Latest operation return code: OK
Number of successes: 18
Number of failures: 0
Operation time to live: Forever
IPSLA operation id: 20
Type of operation: icmp-echo
Latest RTT: 32 milliseconds
Latest operation start time: *19:19:35.271 UTC Sun Aug 22 2010
Latest operation return code: OK
Number of successes: 18
Number of failures: 0
Operation time to live: Forever
We can check via SNMP that the last test was a success for ip sla 10:
NMS:~# snmpget -v 2c -c public 192.168.2.1 1.3.6.1.4.1.9.9.42.1.2.10.1.2.10
SNMPv2-SMI::enterprises.9.9.42.1.2.10.1.2.10 = INTEGER: 1
And ip sla 20 is ok too
NMS:~# snmpget -v 2c -c public 192.168.2.1 1.3.6.1.4.1.9.9.42.1.2.10.1.2.20
SNMPv2-SMI::enterprises.9.9.42.1.2.10.1.2.20 = INTEGER: 1
Lets simulate a break beyond the directly connected network
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int lo0
R2(config-if)#shut
R2(config-if)#^Z
R1#sh ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 10
Type of operation: icmp-echo
Latest RTT: 32 milliseconds
Latest operation start time: *19:23:03.679 UTC Sun Aug 22 2010
Latest operation return code: OK
Number of successes: 32
Number of failures: 0
Operation time to live: Forever
IPSLA operation id: 20
Type of operation: icmp-echo
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *19:23:05.271 UTC Sun Aug 22 2010
Latest operation return code: No connection
Number of successes: 31
Number of failures: 1
Operation time to live: Forever
NMS:~# snmpget -v 2c -c public 192.168.2.1 1.3.6.1.4.1.9.9.42.1.2.10.1.2.10
SNMPv2-SMI::enterprises.9.9.42.1.2.10.1.2.10 = INTEGER: 1
NMS:~# snmpget -v 2c -c public 192.168.2.1 1.3.6.1.4.1.9.9.42.1.2.10.1.2.20
SNMPv2-SMI::enterprises.9.9.42.1.2.10.1.2.20 = INTEGER: 6
"Fix the fault" (no shut on R2 int loop0)
R1#sh ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 10
Type of operation: icmp-echo
Latest RTT: 16 milliseconds
Latest operation start time: *19:25:33.679 UTC Sun Aug 22 2010
Latest operation return code: OK
Number of successes: 42
Number of failures: 0
Operation time to live: Forever
IPSLA operation id: 20
Type of operation: icmp-echo
Latest RTT: 12 milliseconds
Latest operation start time: *19:25:35.271 UTC Sun Aug 22 2010
Latest operation return code: OK
Number of successes: 32
Number of failures: 10
Operation time to live: Forever
NMS:~# snmpget -v 2c -c public 192.168.2.1 1.3.6.1.4.1.9.9.42.1.2.10.1.2.10
SNMPv2-SMI::enterprises.9.9.42.1.2.10.1.2.10 = INTEGER: 1
NMS:~# snmpget -v 2c -c public 192.168.2.1 1.3.6.1.4.1.9.9.42.1.2.10.1.2.20
SNMPv2-SMI::enterprises.9.9.42.1.2.10.1.2.20 = INTEGER: 1
Break the directly connected link to the ip peer while keeping the physical
interface up (shutdown on R2 Fa0/0.10)
R1#sh int fa0/0 | inc is up
FastEthernet0/0 is up, line protocol is up
R1#sh ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 10
Type of operation: icmp-echo
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *19:28:33.679 UTC Sun Aug 22 2010
Latest operation return code: Timeout
Number of successes: 50
Number of failures: 4
Operation time to live: Forever
IPSLA operation id: 20
Type of operation: icmp-echo
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *19:28:35.271 UTC Sun Aug 22 2010
Latest operation return code: Timeout
Number of successes: 40
Number of failures: 14
Operation time to live: Forever
NMS:~# snmpget -v 2c -c public 192.168.2.1 1.3.6.1.4.1.9.9.42.1.2.10.1.2.10
SNMPv2-SMI::enterprises.9.9.42.1.2.10.1.2.10 = INTEGER: 4
NMS:~# snmpget -v 2c -c public 192.168.2.1 1.3.6.1.4.1.9.9.42.1.2.10.1.2.20
SNMPv2-SMI::enterprises.9.9.42.1.2.10.1.2.20 = INTEGER: 4
Cheers,
Adam
On Sun, Aug 22, 2010 at 5:49 PM, Adam Booth <adam.booth_at_gmail.com> wrote:
> Hi Asif,
>
> The reason I suggested using IP SLA is that you get one router to validate
> connectivity to the other router using your backup path using inband traffic
> to test rather than examining routing tables etc. Your NMS would poll the
> router that is performing the IP SLA probe (the other would be set up as the
> responder) to see if the connectivity is within acceptable parameters and if
> not raise an alarm, triggering an event for your network operator to
> investigate. Just to further explain - this is actually testing the link
> between the routers and, not testing that the NMS itself can reach each of
> your managed elements.
>
> Interface state on your router could be easily determined by with snmp by
> both the NMS polling and having the router generate a trap when the
> interface state changes.
>
> Points 2 and 3 appear to be within the SP network, particularly if the
> attachment circuit between your router and the SP is their responsibility to
> troubleshoot and rectify but may include mechanisms to assist network
> connectivity verification such as BFD, 802.1ah, 802.3ag and Y.1731
>
> If you want something to perform a root cause analysis for you which will
> be NMS dependant - the specific product, the modules and possibly the
> business rule customisation may have impacts on this.
>
> Cheers,
> Adam
>
>
>
>
> On Sun, Aug 22, 2010 at 5:16 PM, Asif Vanoo <asif_at_vanoo.net> wrote:
>
>> Hi,
>>
>> In MPLS network there are couple of reachability failure options.
>>
>> - Interface of my router goes down
>> - next hop not reachable- MPLS Provider
>> - Somewhere in between on MPLS cloud
>>
>> What if Interface of my router facing SP is up and reachable but cannot
>> reach my other end. Problem could be in SP or problem could be my other
>> end.
>> How would NMS behave in this situation?
>>
>> Thanks
>> Asif
>>
>> On 8/22/2010 4:37 AM, Adam Booth wrote:
>>
>> Hi Asif,
>>
>> There's more than one way to do it but one method I would consider
>> suggesting is to look at IP SLA ICMP tests between the interfaces of you
>> routers that are facing the SP MPLS network and your NMS uses the RTTMON
>> SNMP MIB to verify connectivity.
>>
>> This is the guide on CCO about IP SLA ICMP echo operations
>> http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsicmp.html
>> This should be the MIB of interest
>> http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&mibName=CISCO-RTTMON-MIBfor your NMS to query
>>
>> Cheers,
>> Adam
>>
>>
>> On Sun, Aug 22, 2010 at 5:53 AM, Asif Vanoo <asif_at_vanoo.net> wrote:
>>
>>> Hi GS,
>>>
>>> Got a Question,I got this scenario
>>>
>>> Loc_A connects to Loc_B with P-2-P 10Mb link as primary and MPLS link as
>>> backup link.
>>> NMS is located at Loc_A which monitors both links ( P-2-P & MPLS ) and on
>>> both location Routers.
>>> OSPF is the routing protocol
>>> MPLS is via a Service provider
>>>
>>> How can I identify my MPLS link is up and reachable till Loc_B when P-2-P
>>> link is up??
>>>
>>> Thanks
>>> Asif
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Sun Aug 22 2010 - 19:44:50 ART
This archive was generated by hypermail 2.2.0 : Wed Sep 01 2010 - 11:20:53 ART