ME IP SLA on U-PE device?

Hello,
A Service provider delivers EVCs with QoS and wants to monitoring the performance of their customers using IP SLA. We recommend using shadow routers on SP POPs and measure between these POPs, but they want to see the performance on every EVC on the network using IP SLA directly on the U-PE device.
I was reading that the ME3400 has some limitations regarding IP SLA:
The Cisco ME 3400 switch includes partial support for Cisco IOS IP Service Level Agreements (IP SLAs) to provide advanced network service monitoring information and collect data pertaining to SLAs verification. The switch can initiate and reply jitter probes. However, the traffic does not follow the queuing configuration that is applied to customer traffic. All locally originated traffic always goes to the same egress queue on the switch port, regardless of the ToS setting for the IP SLAs probe. We recommend the use of an external shadow router to measure latency and packet drop rate (PDR) across the switch.
http://www.cisco.com/en/US/products/ps6580/prod_release_note09186a00806700ee.html#wp833196
Is there any U-PE device that has full IP SLA support? Do you have any recommendation?
Thanks!
Alex

Cisco IP solution centre also supprots SLA.

Similar Messages

  • MIB help for trap monitoring of IP SLA Breach or track using CA Spectrum

    I am trying to generate a trap based on sla breach on a IOS XE router.  What MIB could I use?
    Here is the config from the router:
    track 1 ip sla 1 reachability
    ip sla 1
    icmp-echo 50.232.60.177 source-interface GigabitEthernet0/0/3
    ip sla schedule 1 life forever start-time now
    ip sla logging traps
    snmp-server enable traps ipsla
    Syslog Entry
    Mar 27 17:45:00.455: %TRACK-6-STATE: 1 ip sla 1 reachability Down -> Up

    Hi,
    You can configure the IP SLA Reaction configuration & generate the traps based on many conditions, you can choose whatever suits you. 
    Example Configuring an IP SLAs Reaction Configuration
    http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/configuration/15-mt/sla-15-mt-book/sla_threshold_mon.html#GUID-A459B9AF-188D-4676-9876-19993266B32A
    Example Configuring an IP SLAs Reaction Configuration
    In the following example, IP SLAs operation 10 is configured to send an SNMP logging trap when the MOS value either exceeds 4.9 (best quality) or falls below 2.5 (poor quality):
    Device(config)# ip sla reaction-configuration 10 react mos threshold-type immediate threshold-value 490 250 action-type trapOnly
    The following example shows the default configuration for the ip sla reaction-configuration command:
    Device# show ip sla reaction-configuration 1
    Entry number: 1
    Reaction Configuration not configured
    Router# configure terminal
    Enter configuration commands, one per line. End with CNTL/Z.
    Router(config)# ip sla reaction-configuration 1
    Router(config)# do show ip sla reaction-configuration 1
    Entry number: 1
    Reaction: rtt
    Threshold Type: Never
    Rising (milliseconds): 5000
    Falling (milliseconds): 3000
    Threshold Count: 5
    Threshold Count2: 5
    Action Type: None
    - Ashok
    Please rate the useful post or mark as correct answer as it will help others looking for similar information

  • Problem configuring IP SLA using SNMP

    I am trying to configure IP SLA on a Cisco device using SNMP. No matter what I do the rttMonCtrlAdminStatus changes to 1 even though I set it to 4.
    The device is  - Cisco IOS Software, 2800 Software (C2800NM-SPSERVICESK9-M), Version 12.4(22)T, RELEASE SOFTWARE (fc1)
    My snmpset command is as follows
    snmpset -v2c -c xxxxxx  100.252.0.12  1.3.6.1.4.1.9.9.42.1.2.1.1.9.1 i 4 1.3.6.1.4.1.9.9.42.1.2.1.1.4.1 i 1 1.3.6.1.4.1.9.9.42.1.2.2.1.1.1 i 2 1.3.6.1.4.1.9.9.42.1.2.2.1.2.1 x 'AC 10 1B 06' 1.3.6.1.4.1.9.9.42.1.2.2.1.6.1 x '0A FE 00 02' 1.3.6.1.4.1.9.9.42.1.2.5.1.2.1 t 1 1.3.6.1.4.1.9.9.42.1.2.5.1.1.1 i 214748364                                                           
    SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.9.1 = INTEGER: 4                       
    SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.4.1 = INTEGER: 1                        
    SNMPv2-SMI::enterprises.9.9.42.1.2.2.1.1.1 = INTEGER: 2
    SNMPv2-SMI::enterprises.9.9.42.1.2.2.1.2.1 = Hex-STRING: AC 10 1B 06
    SNMPv2-SMI::enterprises.9.9.42.1.2.2.1.6.1 = Hex-STRING: 0A FE 00 02
    SNMPv2-SMI::enterprises.9.9.42.1.2.5.1.2.1 = Timeticks: (1) 0:00:00.01
    SNMPv2-SMI::enterprises.9.9.42.1.2.5.1.1.1 = INTEGER: 214748364
    Things look fine here. Now when I try to cross verify
    snmpwalk -v2c -c xxxxxx 100.252.0.12 1.3.6.1.4.1.9.9.42.1.2.1.1.9
    SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.9.1 = INTEGER: 1   
    The rttMonCtrlAdminStatus shows as 1.
    Is there something that I am missing out?

    This is normal.  You set the row status to createAndGo, and because everything was configured properly, the row transitions to active(1) automatically.  This what you want.

  • IP-SLA

    Hi guys,
    I am new to configuring switches.
    I have been given the task of configuring IP SLA in cisco 1941 router. I have performed following operation:
    Device> enable
    Device# configure terminal
    Device(config)# ip sla 1
    Device(config-ip-sla)# icmp-echo xxx.xxx.xxx.xxx
    Device(config-ip-sla-echo)# frequency 5
    Device(config)# ip sla schedule 10 life forever start-time now
    Device(config-ip-sla-echo)# end
     Next I want to  be able to see last 1 months/2 months/3months IP SLA Statics. Kindly advise the configuration

    Hi Paul,
    Thank You for responding to my query.
    I haven't set the destination device as responder. but "show ip sla statistics" gives me packet sent, received and dropped.
    How do I store history for last 2 months/three months is my question.
    Regards,

  • IP SLA/EEM running out of VTY lines and failing

    I am using IP SLA to ping network devices to detect network failures from an AS5400XM voice gateway.  The AS5400XM platform is limited to 5 vty lines ( vty 0 4).  When simulating a simultaneous outage, there are not enough tty lines available to process my EEM events.
    However, when simulating a simultaneous outage, we have a new issue – there are not enough lines available:
    Feb  9 15:16:22.970 CST: %HA_EM-3-FMPD_CLI_CONNECT: Unable to establish CLI session: no tty lines available, minimum of 2 required by EEM
    Feb  9 15:16:22.970 CST: %HA_EM-3-FMPD_ERROR: Error executing applet ReportIPSLAevent_1005065020_up statement 1.1
    Feb  9 15:16:22.974 CST: %HA_EM-3-FMPD_CLI_CONNECT: Unable to establish CLI session: no tty lines available, minimum of 2 required by EEM
    Feb  9 15:16:22.978 CST: %HA_EM-3-FMPD_ERROR: Error executing applet ReportIPSLAevent_1005081020_up statement 1.1
    Feb  9 15:16:22.986 CST: %HA_EM-3-FMPD_CLI_CONNECT: Unable to establish CLI session: no tty lines available, minimum of 2 required by EEM
    Feb  9 15:16:22.986 CST: %HA_EM-3-FMPD_ERROR: Error executing applet ReportIPSLAevent_100000226_up statement 1.1
    Feb  9 15:16:22.994 CST: %HA_EM-3-FMPD_CLI_CONNECT: Unable to establish CLI session: no tty lines available, minimum of 2 required by EEM
    Feb  9 15:16:22.994 CST: %HA_EM-3-FMPD_ERROR: Error executing applet ReportIPSLAevent_1001012021_up statement 1.1
    Feb  9 15:16:23.006 CST: %HA_EM-3-FMPD_CLI_CONNECT: Unable to establish CLI session: no tty lines available, minimum of 2 required by EEM
    Feb  9 15:16:23.006 CST: %HA_EM-3-FMPD_ERROR: Error executing applet ReportIPSLAevent_1061247018_up statement 1.1
    How can I detect/wait until there are enough lines free before processing the EEM rules?
    Regards,
    -Doug

    Joe,
    So far, it looks like there are only two issues remaining:
    Issue #1 - E-mail subject has destination listed as "unknown" versus the hostname
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : Subject: IP SLA alert - {router} connectivity to Unknown has been restored
    Issue #2 - Source IP address issue (SMTP relay restricted to IP 10.5.32.90).  Traffic to the SMTP server needs to sourced from the Loopback0 address 10.5.32.90.  There are NAT rules in place to cover this, but it looks like the TCL script is bypassing the NAT:
    #sh ip int brief | ex una
    Interface                  IP-Address      OK? Method Status                Protocol
    GigabitEthernet0/0         10.5.34.242     YES NVRAM  up                    up
    GigabitEthernet0/1         10.5.34.250     YES NVRAM  up                    up
    Loopback0                  10.5.32.90      YES NVRAM  up                    up
    NVI0                       10.5.32.90      YES unset  up                    up
    ip nat inside source list smtp-nat interface Loopback0 overload
    sh ip access-lists smtp-nat
    Extended IP access list smtp-nat
        10 permit ip host 10.5.34.242 host 10.0.10.10 (2 matches)
        20 permit ip host 10.5.34.250 host 10.0.10.10 (15 matches)
    Feb 18 10:39:33.297 CST: FIBfwd-proc: sending link IP ip_pak_table 0 ip_nh_table 65535 if GigabitEthernet0/0 nh 10.5.34.241 uhp 1 deag 0 ttlexp 0 rec 0
    Feb 18 10:39:33.297 CST: IP: s=10.5.34.242 (local), d=10.0.10.10 (GigabitEthernet0/0), len 58, sending
    Feb 18 10:39:33.297 CST:     TCP src=26095, dst=25, seq=3453704840, ack=2112864439, win=3890 ACK
    Feb 18 10:39:33.297 CST: IP: s=10.5.34.242 (local), d=10.0.10.10 (GigabitEthernet0/0), len 58, output feature
    Feb 18 10:39:33.297 CST:     TCP src=26095, dst=25, seq=3453704840, ack=2112864439, win=3890 ACK, CCE Output Classification(5), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:33.297 CST: IP: s=10.5.32.90 (local), d=10.0.10.10 (GigabitEthernet0/0), len 58, output feature
    Feb 18 10:39:33.297 CST:     TCP src=26095, dst=25, seq=3453704840, ack=2112864439, win=3890 ACK, Post-routing NAT Outside(17), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:33.297 CST: IP: s=10.5.32.90 (local), d=10.0.10.10 (GigabitEthernet0/0), len 58, output feature
    Feb 18 10:39:33.297 CST:     TCP src=26095, dst=25, seq=3453704840, ack=2112864439, win=3890 ACK, Stateful Inspection(20), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:33.297 CST: IP: s=10.5.32.90 (local), d=10.0.10.10 (GigabitEthernet0/0), len 58, sending full packet
    Feb 18 10:39:33.297 CST:     TCP src=26095, dst=25, seq=3453704840, ack=2112864439, win=3890 ACK
    Feb 18 10:39:33.297 CST: [fh_smtp_debug_cmd]
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : From: {router}@mydomain.com
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : To: [email protected]
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : Cc:
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : Subject: IP SLA alert - {router} connectivity to Unknown has been restored
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : IPSLAs Latest Operation Statistics
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : IPSLA operation id: 100000226
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : Type of operation: icmp-echo
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write :    Latest RTT: 36 milliseconds
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : Latest operation start time: 10:39:29.377 CST Thu Feb 18 2010
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : Latest operation return code: OK
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : Number of successes: 21
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : Number of failures: 13
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : Operation time to live: Forever
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : {router}
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write :
    Feb 18 10:39:33.297 CST: [fh_smtp_debug_cmd]
    Feb 18 10:39:33.297 CST: %HA_EM-6-LOG: sl_ip_sla_report.tcl : DEBUG(smtp_lib) : smtp_write : .
    Feb 18 10:39:33.529 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 40, input feature
    Feb 18 10:39:33.529 CST:     TCP src=25, dst=26095, seq=2112864439, ack=3453704858, win=65374 ACK, Stateful Inspection(4), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:33.529 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 40, input feature
    Feb 18 10:39:33.529 CST:     TCP src=25, dst=26095, seq=2112864439, ack=3453704858, win=65374 ACK, Virtual Fragment Reassembly(21), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:33.529 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 40, input feature
    Feb 18 10:39:33.529 CST:     TCP src=25, dst=26095, seq=2112864439, ack=3453704858, win=65374 ACK, Virtual Fragment Reassembly After IPSec Decryption(32), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:33.529 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 40, input feature
    Feb 18 10:39:33.529 CST:     TCP src=25, dst=26095, seq=2112864439, ack=3453704858, win=65374 ACK, NAT Outside(53), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:33.529 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 40, input feature
    Feb 18 10:39:33.529 CST:     TCP src=25, dst=26095, seq=2112864439, ack=3453704858, win=65374 ACK, MCI Check(64), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:33.529 CST: FIBipv4-packet-proc: route packet from GigabitEthernet0/1 src 10.0.10.10 dst 10.5.34.242
    Feb 18 10:39:33.529 CST: FIBfwd-proc: Default:10.5.34.242/32 receive entry
    Error:
    Feb 18 10:39:33.529 CST: FIBipv4-packet-proc: packet routing failed
    Feb 18 10:39:33.529 CST: IP: tableid=0, s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242 (GigabitEthernet0/0), routed via RIB
    Feb 18 10:39:33.529 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242 (GigabitEthernet0/0), len 40, output feature
    Feb 18 10:39:33.529 CST:     TCP src=25, dst=26095, seq=2112864439, ack=3453704858, win=65374 ACK ACK
    Feb 18 10:39:33.953 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 40, stop process pak for forus packet
    Feb 18 10:39:33.953 CST:     TCP src=25, dst=26095, seq=2112864535, ack=3453704892, win=65340 ACK
    Feb 18 10:39:34.245 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 88, input feature
    Feb 18 10:39:34.245 CST:     TCP src=25, dst=26095, seq=2112864535, ack=3453704892, win=65340 ACK PSH, Stateful Inspection(4), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.245 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 88, input feature
    Feb 18 10:39:34.245 CST:     TCP src=25, dst=26095, seq=2112864535, ack=3453704892, win=65340 ACK PSH, Virtual Fragment Reassembly(21), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 88, input feature
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864535, ack=3453704892, win=65340 ACK PSH, Virtual Fragment Reassembly After IPSec Decryption(32), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 88, input feature
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864535, ack=3453704892, win=65340 ACK PSH, NAT Outside(53), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 88, input feature
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864535, ack=3453704892, win=65340 ACK PSH, MCI Check(64), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: FIBipv4-packet-proc: route packet from GigabitEthernet0/1 src 10.0.10.10 dst 10.5.34.242
    Feb 18 10:39:34.249 CST: FIBfwd-proc: Default:10.5.34.242/32 receive entry
    Error:
    Feb 18 10:39:34.249 CST: FIBipv4-packet-proc: packet routing failed
    Feb 18 10:39:34.249 CST: IP: tableid=0, s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242 (GigabitEthernet0/0), routed via RIB
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242 (GigabitEthernet0/0), len 88, output feature
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864535, ack=3453704892, win=65340 ACK PSH, CCE Output Classification(5), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242 (GigabitEthernet0/0), len 88, output feature
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864535, ack=3453704892, win=65340 ACK PSH, Post-routing NAT Outside(17), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242 (GigabitEthernet0/0), len 88, output feature
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864535, ack=3453704892, win=65340 ACK PSH, Stateful Inspection(20), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 88, rcvd 4
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864535, ack=3453704892, win=65340 ACK PSH
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 88, stop process pak for forus packet
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864535, ack=3453704892, win=65340 ACK PSH
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 40, input feature
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864583, ack=3453704892, win=65340 ACK FIN, Stateful Inspection(4), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 40, input feature
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864583, ack=3453704892, win=65340 ACK FIN, Virtual Fragment Reassembly(21), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 40, input feature
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864583, ack=3453704892, win=65340 ACK FIN, Virtual Fragment Reassembly After IPSec Decryption(32), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 40, input feature
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864583, ack=3453704892, win=65340 ACK FIN, NAT Outside(53), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 40, input feature
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864583, ack=3453704892, win=65340 ACK FIN, MCI Check(64), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: FIBipv4-packet-proc: route packet from GigabitEthernet0/1 src 10.0.10.10 dst 10.5.34.242
    Feb 18 10:39:34.249 CST: FIBfwd-proc: Default:10.5.34.242/32 receive entry
    Error:
    Feb 18 10:39:34.249 CST: FIBipv4-packet-proc: packet routing failed
    Feb 18 10:39:34.249 CST: IP: tableid=0, s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242 (GigabitEthernet0/0), routed via RIB
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242 (GigabitEthernet0/0), len 40, output feature
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864583, ack=3453704892, win=65340 ACK FIN, CCE Output Classification(5), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242 (GigabitEthernet0/0), len 40, output feature
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864583, ack=3453704892, win=65340 ACK FIN, Post-routing NAT Outside(17), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242 (GigabitEthernet0/0), len 40, output feature
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864583, ack=3453704892, win=65340 ACK FIN, Stateful Inspection(20), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 40, rcvd 4
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864583, ack=3453704892, win=65340 ACK FIN
    Feb 18 10:39:34.249 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 40, stop process pak for forus packet
    Feb 18 10:39:34.249 CST:     TCP src=25, dst=26095, seq=2112864583, ack=3453704892, win=65340 ACK FIN
    Feb 18 10:39:34.249 CST: IP: s=10.5.34.242 (local), d=10.0.10.10, len 40, local feature
    Feb 18 10:39:34.249 CST:     TCP src=26095, dst=25, seq=3453704892, ack=2112864584, win=3746 ACK, NAT(2), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
    Feb 18 10:39:34.249 CST: FIBipv4-packet-proc: route packet from (local) src 10.5.34.242 dst 10.0.10.10
    Feb 18 10:39:34.249 CST: FIBfwd-proc: Default:10.0.0.0/20 proces level forwarding
    Feb 18 10:39:34.249 CST: FIBfwd-proc: depth 0 first_idx 0 paths 2 long 0(0)
    Feb 18 10:39:34.249 CST: FIBfwd-proc: try path 0 (of 2) v4-anh-10.5.34.241-Gi0/0 first short ext 0(-1)
    Feb 18 10:39:34.249 CST: FIBfwd-proc: v4-anh-10.5.34.241-Gi0/0 valid
    Feb 18 10:39:34.249 CST: FIBfwd-proc: ip_pak_table 0 ip_nh_table 65535 if GigabitEthernet0/0 nh 10.5.34.241 deag 0 via fib 0 path type attached nexthop
    Feb 18 10:39:34.249 CST: FIBfwd-proc: packet routed to GigabitEthernet0/0 10.5.34.241(0)
    Feb 18 10:39:34.249 CST: FIBipv4-packet-proc: packet routing succeeded ACK
    Feb 18 10:39:34.405 CST: IP: s=10.0.10.10 (GigabitEthernet0/1), d=10.5.34.242, len 40, stop process pak for forus packet
    Feb 18 10:39:34.405 CST:     TCP src=25, dst=26095, seq=2112864584, ack=3453704893, win=65340 ACK
    Regards,
    -Doug
    P.S.  Can you recommend any documents or books to learn Tcl?

  • How can i have same billing account with two different game center accounts

    I Need two different game centeraccounts on two different devices thatshare same apple id

    I looked at this post last night and assumed that the OP had decided he did not have a question; however, since you decided to post......
    Mac or iDevice, is forever 'connected' with the AppleID
    actually, that is not correct. It can be wiped and disassociated; it is any OS or app obtained at the app store which is tethered to the Apple ID used to obtain it, not the hardware. See the SLA.
    If a device was tethered forever, it could never be re-sold - obviously.
    As for the OP's question: I am not sure as I could not find any reference in the legal documents available, but I believe it is not possible - one Apple ID = one account.

  • Is the "Data" License required for devices responding to IP SLA commands

    Hi,
    This question relates to the 15.X IOS Licensing scheme.
    We have a dedicated router that we use in the hub site for setting up IP SLA probes.
    Does anyone know if we need purchase the "Data" license for remote site device responding to the probes?
    From my point of view, I am thinking that that is not required.  Any confirmation of that will be appreciated.
    Cheers.

    IP SLA requires a license greater than IP BASE.  So you will need at least a DATA license to be able to create collectors.  In the future, you can use the IOS Feature Navigator to see what features are supported in what versions of IOS (and with what licenses).
    http://www.cisco.com/go/fn

  • POE Device HA with spanning tree or IP SLA

    Hi,
    I'm looking for a HA solution for 2 wireless POE AP's on a tower (unreachable). 
    Basically 1 AP will be powered on and transmitting, and I need to have the other AP powered off (POE off on switchport) but if the 1st AP drops (not pinging or interface down) then the 2nd AP on another switchport needs to have POE enabled to power on the AP and start transmitting.
    How can this be achieved? I initially thought IP SLA but don't know whether this can trigger a POE inline command on a switchport.
    Any advice would be greatly appreciated?
    Cheers,
    Brad

    Basically 1 AP will be powered on and transmitting, and I need to have the other AP powered off (POE off on switchport) but if the 1st AP drops (not pinging or interface down) then the 2nd AP on another switchport needs to have POE enabled to power on the AP and start transmitting.
    What is the model of your PoE switch and does it even support IP SLA? 
    You've need to factor in theft of your powered off AP and the potential issue when you power up your AP.  I am using different models of APs and something after a power reboot of the switch some APs just fail.  
    I'm no big fan of what you're trying to do because it means you've got a second AP doing nothing.  Exactly what is the role of this AP that you really require a second unit not powered up?  Is it acting as an AP or a bridge?  Is your AP operating as a controller-based IOS or autonomous IOS? 
    If I have a critical AP, I'd keep the spare nearby and the configuration ready.  I don't want it "out there" and powered off because I sure don't know if the AP has been stolen or dead.  

  • Is it possible to have filters for one account on 3 devices ? And have the same results/folders.

    I have one email account on 3 devices and I need to filter all received emails, on all 3 devices. Same folders and same filters.
    If I create a filter rule on one PC then I can't find the filtered emails ( that are in the new created folder on PC no.1 ) on the other devices. What can I do?

    To answer the question as stated in your topic, it's possible but not easy.
    Obviously you can enter the same filters by hand on each installation of Thunderbird, but it's tedious and error-prone. You can set them up on one machine and copy the filter files over to the other machines. Also tedious and error-prone.
    The way you describe the messages vanishing from sight suggests strongly that you're currently using POP, and this has no way of making use of shared folders. To continue working in this way, all you could do is set each client to leave a copy on the server for the others and painstakingly manage a set of filters on each and every machine, keeping them in synch by hand and careful management. (And ditto for your folders.) You'd also have to attend to the POP server from time to time to remove accumulated messages left there by your clients.
    The real answer to this and your later question is to use an IMAP-connected account, where all your data lives in one place, on the email provider's server, and all your devices simply look at and work with one common set of data. Any filtering, editing, moving, etc you did on one machine would very quickly become visible on the other machines. In fact. the ability for more than one machine to be simultaneously be working on the same message becomes a somewhat worrying possibility. It's not clear if this is a likely event in your scenario.
    Even using IMAP, if you filter at the client then you'd still have the issue of managing multiple instances of your filters, and the final part of this is to make use of filtering offered by the server; then the filtering takes place "at source" and you have just one filter set to maintain.
    If your current email provider doesn't provide IMAP, and cannot offer it, then there are many alternatives who will. If it's for business then I think you should look for a paid-for service that includes guarantees, backups and an SLA. Your domain provider should be able to offer this.
    For personal use, many of the free suppliers are worth considering. Googlemail works well, but if you're uneasy about their pervasiveness, have a look at gmx/1&1. Microsoft's hotmail/live mail/outlook.com offers IMAP. Yahoo! probably does (please check in your locality) but they have a bad track record and a lamentable reputation and I wouldn't want to entrust them with any precious material.

  • Is it ok to use one apple id for two devices ?

    is it ok to use one apple id for two devices ?

    Here's the deal: The SLA permits the "sharing" of content with up to 5 family members in the same household. Any other distribution of content is considered stealing...the SLA does not give you the right to distribute content in any way, shape or form. Its really that simple, and "friend" is NOT a family member living in the same household.

  • How many devices can I log my itunes account

    I was just wondering how many devices I can login into my itunes account for. Purpose is to install apps that I purchased onto family members Ipod touches and an Ipad.
    I do not need to plug into computer just want to login to app store and install.

    The SLA permits you to share YOUR content with up to 5 family members in the same household.

  • IP SLA icmp jitter operation

    Hello
    I would like to track icmp jitter for end host. I verified in documentation that it can be any host as a destination. But i got error on this operation:
     Latest RTT: NoConnection/Busy/Timeout
    I verified that there is no firewall between the source and destination and icmp timestamp request works when done manually:
    r01#ping          
    Protocol [ip]:     
    Target IP address: 10.23.33.6
    Repeat count [5]: 
    Datagram size [100]: 
    Timeout in seconds [2]: 
    Extended commands [n]: y
    Source address or interface: 
    Type of service [0]: 
    Set DF bit in IP header? [no]: 
    Validate reply data? [no]: 
    Data pattern [0xABCD]: 
    Loose, Strict, Record, Timestamp, Verbose[none]: Timestamp
    Number of timestamps [ 9 ]: 
    Loose, Strict, Record, Timestamp, Verbose[TV]: 
    Sweep range of sizes [n]: 
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 10.23.33.6, timeout is 2 seconds:
    Packet has IP options:  Total option bytes= 40, padded length=40
     Timestamp: Type 0.  Overflows: 0 length 40, ptr 5
      >>Current pointer<<
      Time= 01:00:00.000 CET (00000000)
      Time= 01:00:00.000 CET (00000000)
      Time= 01:00:00.000 CET (00000000)
      Time= 01:00:00.000 CET (00000000)
      Time= 01:00:00.000 CET (00000000)
      Time= 01:00:00.000 CET (00000000)
      Time= 01:00:00.000 CET (00000000)
      Time= 01:00:00.000 CET (00000000)
      Time= 01:00:00.000 CET (00000000)
    Reply to request 0 (4 ms).  Received packet has no options
    Reply to request 1 (4 ms).  Received packet has no options
    Reply to request 2 (1 ms).  Received packet has no options
    Reply to request 3 (1 ms).  Received packet has no options
    Reply to request 4 (1 ms).  Received packet has no options
    Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
    r01#sh ip sla statistics 196
    IPSLAs Latest Operation Statistics
    IPSLA operation id: 196
    Type of operation: icmp-jitter
            Latest RTT: NoConnection/Busy/Timeout
    Latest operation start time: 12:45:21.019 CET Fri Nov 21 2014
    Latest operation return code: Timeout
    RTT Values:
            Number Of RTT: 0                RTT Min/Avg/Max: 0/0/0 
    Latency one-way time:
            Number of Latency one-way Samples: 0
            Source to Destination Latency one way Min/Avg/Max: 0/0/0 
            Destination to Source Latency one way Min/Avg/Max: 0/0/0 
    Jitter Time:
            Number of SD Jitter Samples: 0
            Number of DS Jitter Samples: 0
            Source to Destination Jitter Min/Avg/Max: 0/0/0 
            Destination to Source Jitter Min/Avg/Max: 0/0/0 
    Packet Late Arrival: 0
    Out Of Sequence: 0
            Source to Destination: 0        Destination to Source 0
            In both Directions: 0
    Packet Skipped: 0       Packet Unprocessed: 0
    Packet Loss: 0
            Loss Period Length Min/Max: 0/0
    Number of successes: 0
    Number of failures: 34
    ip sla 197
     icmp-jitter 10.23.33.6
     frequency 30
    ip sla schedule 197 life forever start-time now
    Nov 21 12:57:43: IP SLAs(197) Scheduler: saaSchedulerEventWakeup
    Nov 21 12:57:43: IP SLAs(197) Scheduler: Starting an operation
    Nov 21 12:57:43: IP SLAs(197) icmpjitter operation: Starting icmpjitter operation
    Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
    Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
    Nov 21 12:57:49: IP SLAs(197) Scheduler: Updating result
    Nov 21 12:57:49: IP SLAs(197) Scheduler: start wakeup timer, delay = 24796
    Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
    Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
    Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
    Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
    Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
    Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
    Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
    Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
    Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
    Any help would be appreciated.

    Hi Jorge
    According to Cisco documentation icmp-jitter should work on any IP Device.
    I have a similar issue.
    1. I can run icmp-jitter successfully to non cisco routers
    2. it fails to run to a generic ip device.
    Imran

  • EEM / IP SLA to shutdown lossy high RTT BGP neighbor

    Hi,
    I'm relatively new to the IP SLA procedure and very new to EEM. I'm searching for the most efficient way to monitor the availability (packet loss and latency) of a BGP neighbor from a router to actively shutdown the neighbor relationship in order to failover to a back up L2L VPN I have configured on an ASA. It's important that I'm able to continue monitoring the BGP neighbor so that when the neighbor becomes stable again, I can reenable the BGP neighbor relationship. I've put something quick together (below) but am not sure if it will do what I want. I'd appreciate any suggestions and feedback.
    Thank you!
    -Mike
    ip sla 90
     icmp-echo <neighbor_ip> source-ip <source_ip>
     threshold 250
     timeout 500
     frequency 3
    ip sla schedule 90 life forever start-time now
    ip sla enable reaction-alerts
    track 90 ip sla 90 reachability
      delay down 3 up 180
    event manager applet BGP_NEIGHBOR_DIRTY
     description SHUT DOWN BGP NEIGHBOR IF RTT OVER 250 FOR 3 SECONDS
     event syslog pattern "90 ip sla 90 reachability Up->Down"
     action 1.0  cli command "enable"
     action 1.1  cli command "configure term"
     action 1.2  cli command "router bgp 63320"
     action 1.3  cli command "neighbor <neighbor_ip> shutdown"
     action 1.4  cli command "end"
    event manager applet BGP_NEIGHBOR_CLEAN
     description ENABLE BGP NEIGHBOR IF RTT UNDER 250 FOR 3 MINUTES
     event syslog pattern "90 ip sla 90 reachability Down->Up"
     action 1.0  cli command "enable"
     action 1.1  cli command "configure term"
     action 1.2  cli command "router bgp 63320"
     action 1.3  cli command "no neighbor <neighbor_ip> shutdown"
     action 1.4  cli command "end"

    By chosing a target that is along your desired path, you can certainly have a more robust script. I would use loopback to loopback communication as well, this will force the traffic through the router, and also find any potential issues where the peer is alive and sending bgp but not actually passing traffic. You will definitely need some "fudge" factors in there to deal with routers have to process the ICMP packets (Any CoPP will really really skew the results you are getting). I have had experiences where testing to/from a Nexus device gives wildly different results vs testing through the boxes. 
    HTH

  • SNMP trap on IP sla

    Hi all,
    Does anyone know that, how can SNMP trap the information(such as jitter, number of packet loss, process number of RTR) from a router enabled IP SLA/RTR?

    SNMPv1 (Simple Network Management Protocol) and SNMPv2c, along with the associated Management Information Base (MIB), encourage trap-directed notification.
    The idea behind trap-directed notification is as follows: if a manager is responsible for a large number of devices, and each device has a large number of objects, it is impractical for him to poll or request information from every object on every device. The solution is for each agent on the managed device to notify the manager without solicitation. It does this by sending a message known as a trap of the event.
    After receiving the event, the manager displays it and may choose to take an action based on the event. For instance, the manager can poll the agent directly, or poll other associated device agents to get a better understanding of the event.
    Trap-directed notification can result in substantial savings of network and agent resources by eliminating the need for frivolous SNMP requests. However, it is not possible to totally eliminate SNMP polling. SNMP requests are required for discovery and topology changes. In addition, a managed device agent can not send a trap, if the device has had a catastrophic outage.
    http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094aa5.shtml

  • CSCtg82170: ip sla target port changes to 1967

    I've been impacted by this bug significantly. The sla's are used for gathering stats that populate a customer portal. The bug basically causes the sla to fail when the event occurs and there's no indication that it's occurred.
    For no reason the target port changes to 1967 which is reserved for IP SLA control packets.
    example:
    ip sla 778482511
    udp-jitter 10.197.197.253 15426 source-ip 192.168.15.254 num-packets 20 interval 300
    vrf xxxxxx
    owner xxx
    tag AutoGenerated
    frequency 300
    ip sla schedule 778482511 life forever start-time now
    becomes
    ip sla 778482511
    udp-jitter 10.197.197.253  1967 source-ip 192.168.15.254 num-packets 20 interval 300
    vrf xxxxxx
    owner xxx
    tag AutoGenerated
    frequency 300
    ip sla schedule 778482511 life forever start-time now
    It took quite some time to work out what was actually happening and some time on a Tac service request before it was acknowledge as a bug.
    Below is a table indicating device counts for various platforms and images with the affected count at the bottom.
    h/w           image            count
    1841      12.4(15)T8                98
    1841      12.4(7a)                     41
    1941      15.1(1)T                1944
    1941      15.1(1)T2                     3
    1941      15.1(3)T3                   48
    1941      15.1(4)M4                349
    1941      15.2(1)T1                     3
    1941      15.2(2)T                       2
    2821      12.4(15)T9                   1
    2821      12.4(2)T1                   21
    2821      12.4(24)T2                 79
    2951      15.2(1)T                     24
    3845      12.4(24)T2                   6
    2921/K9 15.1(2)T1                     2
    2921/K9 15.2(1)T                     48
    3750ME 12.1(14)AX2               2
    3750ME 12.2(52)SE               59
    Total 2730
    Devices currently displaying the issue
    1941      15.1(1)T           324
    1941      15.1(3)T3             3
    1941      15.1(4)M4           10
    If you've been struck by this bug I know you'll be relieved that it's actually a bug and your not going insane :-)
    We currently have extra monitoring/checking in order to get on top of the issue but a fix would be really great.

    We're having a similar issue with icmp-echo in that our source-ip address changes quite frequently in the running config (7201 rtr). The destination ip also appears to change when viewing sh ip sla configuration but not in the running config. We're currently running 12.4(24)T1. Looks like we'll be doing an IOS upgrade in the near future...

Maybe you are looking for