on 02-28-2012 05:58 AM
Introduction
IOS devices have the concept of control plane policing. IOS-XR doesn't use that concept but instead uses a very comprehensive and powerful Local Packet Transport Services. In this document it is explained how LPTS works and how you can work with it, monitor and verify it.
LPTS is the concept of reflexive ACL's, punt policers and has an "internal" FIB or iFIB that directs certain packets to various nodes. IOS-XR can handle certain traffic on the linecard (such as BFD, Netflow and ARP) and these packets are instructed by LPTS to be handled by the local CPU rather then the RSP CPU.
At the same time, there are ACL's in place that allow for instance the punting of Telnet traffic and then per host if configured so, but another component of LPTS called MPP, the Management Plane Protection.
Generally, the default values for LPTS provide the level of protection you are after. However there are some rare circumstances whereby you want to tune the values of LPTS in order to get the service levels you need. LPTS is very dynamic in nature and pierces holes into the protection system as particular items are configured.
The LPTS policers work on a per NP basis. So if the LPTS police value is set to 1000pps that means that every NP on the LC can punt with 1000pps to the RSP CPU or LC CPU. This is something to take into consideration when evaluating the A9K-8T-x cards who have 8 NPU's per LC.
Take extreme care when changing the LPTS policer values.
High level overview
From a birds eye view, LPTS looks like this:
The NPU has a table that tells it where to send packet to (LC or RSP) as part of the "internal FIB" or iFIB. These packets are punted at a pre-defined rate, they can be tuned in XR release 4.x and later. Also in the TCAM which is used in the ASR9K for ACLs (amongst others), are lists that define which packets we want to allow and not. This will be discussed in the MPP section of this document.
LPTS is composed of a (set of) dynamic ACL's (which are created as part of user configuration dynamically, or automitcally inserted as peerings establish), an internal "routing table" (iFIB) and a set of policers for different punt reasons. |
---|
So for-me packets are undergoing the Pre iFIB classification and policing upon which they are directed by the iFIB, which is the second level of filtering to the destination node.
One of the great strenghts with LPTS is the dynamic ACL creation. This is configuration driven and no user intervention is required.
In addition to that, LPTS has different flow categories based on the state of the protocol. For instance, BGP has 3 different states:
Unknown is the flow whereby we have TCP port 179 traffic, but we have no neighbor configured from that source. Policed very heavily.
Configured is the entry whereby we know the source address of the peer, but the session is not yet established (no known source port from the peer), Policed moderately.
Established is where we have all the L3 and L4 data from the session. Lightly policed.
The entries for configured is driven by the configuration of the neighbor statement under the router BGP section.
Established is dynamically inserted when the peer establishes.
You could theoretically police the unknown to a rate of zero.
Example:
Router bgp
neighbor 192.168.1.1
…
!
The following table can be seen with the output of the command:
show lpts pifib hardware entry brief loc 0/3/cpu0 | i 179
Local | Port | Remote | Port | Rate | State |
---|---|---|---|---|---|
any | 179 | ANY | ANY | 100 | unknown |
any | 179 | 192.168.1.1 | ANY | 1,000 | configured |
192.168.1.2 | 179 | 192.168.1.1 | 2223 | 10,000 | established |
If you use the command
RP/0/RSP0/CPU0:A9K-TOP#show lpts pifib hardware entry location 0/3/CPU0 | be 33.33.1
You can check the detailed entry of the PiFIB (policer)
Source IP : 33.33.1.1 the remote address
Is Fragment : 0 fragments allowed
Interface : any expected source interface
M/L/T/F : 0/IPv4_STACK/0/BGP-known
DestNode : 48 where the packets are sent to
DestAddr : 48
L4 Protocol : TCP
TCP flag byte : any additional security checks at TCP level
Source port : Port:179
Destination Port : 11293
Accepted/Dropped : 117866/0 packets accepted and denied
# of TCAM entries : 1 number of tcam entries burnt for this PiFIB entry
HPo/HAr/HBu/Cir : 1924676/2500pps/2500ms/2500pps
State : Entry in TCAM status of the entry
You can configure the LPTS Policers on a PiFIB bases and also the punt policers can be adjusted.
The following commands apply. Note that this is on a per linecard basis. All NPU's on that linecard will get reconfigured.
RP/0/RSP0/CPU0:A9K-BNG(config)#lpts punt police location 0/0/CPU0 protocol ?
arp ARP packets
bfd Bidirectional Forwarding Detection packets
cdp Cisco Discovery Protocol packets
cfm Connectivity Fault Management Protocol packets
cgmp Cisco Group Management Protocol packets
dhcp Dynamic Host Configuration Protocol packets
efm Ethernet in the First Mile Protocol packets
igmp-snoop Internet Group Management Protocol Snoop packets
ipiw-arp L2VPN IPIW ARP packets
ipv4 IPv4 packets
ipv6 IPv6 packets
lacp Bundle Protocol packets
mofrr Multicast-only FRR packets
mpls MPLS punt packets
mstp Multiple Spanning Tree Protocol packets
mvrp Multiple VLAN Registration Protocol packets
ppp Point-to-Point Protocol packets
pppoe Point-to-Point Protocol over Ethernet packets
rarp Reverse ARP packets
vccv Virtual Circuit Connection Verification packets
vidmon Video Monitoring packets
vidmon-flow-add Video Monitoring flow add packets
Exception packets can be reconfigured by the following command: lpts punt police location 0/0/CPU0 exception
Glean adjacency or ACL-deny packets can be tuned for instance via that command.
The PIFIB can be reconfigured via the following commands:
RP/0/RSP0/CPU0:A9K-BNG(config)#lpts pifib hardware ...
The command “police” is used to check policer values, accept/drop counts for packets matching LPTS TCAM(mostly L3 packets) entries whereas “static-police” is used to check policer values.
Accept/drop counts for packets matching static punt reasons programmed in search structures (Mostly L2 and exception packets).
“policer” is for dynamic flows (like BGP, OSPF, etc protocols directed by RSP)
“static-policer” is for pseudo Static flows (like BFD, CFM directed by the LC) These are hard-coded and include Exception processing packets.
There is a CLI to change few of the exception processing as well (for e.g. ICMP unreachable)
LPTS is not SNMP enabled (request has been filed and is in the works, no target release defined at time of writing). Though there are very inventive ways to monitor LPTS and generate alerts. There is a TCL script that you can use with EEM in order to get some level of alerting.
Attached to this article is the script package and here is how you set it up:
event manager environment EEM_LPTS_CHECK_INTERVAL 300 event manager environment EEM_LPTS_CHECK_FLOWTYPES BGP-known * event manager environment EEM_LPTS_CHECK_LOCATIONS 0/0/CPU0 0/4/CPU0 event manager environment EEM_LPTS_CHECK_THRESHOLD 1 50% event manager directory user policy disk0:/scripts/ event manager policy lpts-threshold-alerting.tcl username scripts |
---|
LPTS stats cannot be cleared by LPTS commands or qos counter clearing.
You can clear LPTS stats by clearing hte np controller stats:
"clear controllers np counters all location <>”
In the standard configuration all interfaces have access to the Telnet, SSH and SNMP daemons.
All linecard interfaces are designated to be inband, meaning they can transport user traffic as well as management traffic.
The mgmt interfaces on the RSP are designated out of band. This means that they can't transport user traffic but only management traffic.
Out-of-band interfaces can't "speak" to other interfaces as they are desginated for managment traffic. So eventhough there is a route in the system that would send traffic out of the mgmt interface, Fabric enabled interfaces on the LC can't
Here an example of out of band and the restrictions that it imposes on the forwarding
By default when the service is configured, there are no mpp restrictions. All interfaces are able to accept the mgmt traffic for the service you defined. For example, when the telnet server is configured, LPTS reports the following binding:
RP/0/RSP0/CPU0:A9K-BNG#show lpts bindings brief | i (any.23 )
Tue Feb 28 12:00:55.195 EDT
0/RSP0/CPU0 TCP LR IPV4 TCP default any any,23 any
This means that every for me packet with port 23 as the dest port will get serviced.
Now when configuring MPP the bindings output changes:
control-plane
management-plane
inband
interface TenGigE0/1/0/0
allow Telnet peer
address ipv4 3.3.3.3
address ipv4 5.5.5.0/28
!
!
interface GigabitEthernet0/0/0/10
allow Telnet
!
!
!
In this configuration example I am designating two interfaces as inband, so they will still be able to forward transient traffic and allow inbound telnet traffic. At the same time I allow telnet from any host on Gig0/0/0/10 and only telnet from a few peers on Te0/1/0/0.
The LPTS bindings are dynamically changed as per following output:
RP/0/RSP0/CPU0:A9K-BNG#show lpts bindings brief | i (any.23 )
Tue Feb 28 12:06:48.339 EDT
0/RSP0/CPU0 TCP LR IPV4 TCP default Gi0/0/0/10 any,23 any << Any source can access my telnet on this intf
0/RSP0/CPU0 TCP LR IPV4 TCP default Mg0/RSP0/CPU0/0 any,23 any << Dedicated inband
0/RSP0/CPU0 TCP LR IPV4 TCP default Te0/1/0/0 any,23 3.3.3.3 << /32 host access for telnet on dedicated intf
0/RSP0/CPU0 TCP LR IPV4 TCP default Te0/1/0/0 any,23 5.5.5.0/28 << Hosts from this subnet on this intf
Powerful eh!?!
We can also look at the pre internal fib (piFIB) and check the entries there:
RP/0/RSP0/CPU0:A9K-BNG#show lpts pifib hardware entry bri location 0/1/cpu0 | i (.23 )
Tue Feb 28 12:27:46.389 EDT
7 IPV4 default TCP Te0/1/0/0 LU(48) any,23 3.3.3.3,any
10 IPV4 default TCP Te0/1/0/0 LU(48) any,23 5.5.5.0/28,any
In the example above you see the following detail: LU(48). This section explains that number and detail.
The LU means local unicast fabric. The 48 is a very interesting number.
The device that this output is taken from is an ASR9010. Which has 8 LC slots and 2 RSP slots. On both sides of the RSP's in the middle
are the 4 LC's
If I were to decode the 30 into binary it looks like this:
+---+---+---+---+---+---+---+---+
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Position
+---+---+---+---+---+---+---+---+
| 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | Bit value for Decimal 48
+---+---+---+---+---+---+---+---+
|LC |LC |RSP|RSP|LC |LC |LC |LC | Slot position filling (note 2 left most LC's not drawn)
+---+---+---+---+---+---+---+---+
Now you can see that the 1's are in position 5 and 4, and if you look at the slot numbering of the ASR9006, you can see that these are
the RSP's!! So telnet is delivered to the RSP.
6) No MIB Support
Cisco Guide to Harden Cisco IOS XR Devices
If you can use only p2p OSPF network type
flow ospf-uc-known rate 0
flow ospf-uc-default rate 0
flow bgp-default rate 0
flow ldp-tcp-default rate 0
flow msdp-default rate 0
Xander Thuijs, CCIE #6775
Sr. Tech Lead ASR9000
yeah I see your intent, but unfortunately mpp doesn't work that way.
what your hope was that by allowing the loopback we would pierce a hole in all npu's allowing telnet to that address/interface, but mpp only programs it for the "real" interfaces.
so your addition of the bundle is the right thing to do.
now I know this is a request from some other folks also and it is being looked at how we can make that requirement from you with limited scale impact (it burns tcam entries for acl like you wont believe) into the 9k sw.
another option is to use infrastructure ACL's, like regular ACL and apply it to the interfaces.
xander
Xander
thank you for the clarification. I will just allow SSH on all core interfaces leading back to the management systems as well. I can't see any real danger in it and each ASR only has two core interfaces. I was just puzzled about the behaviour of mpp
eelco
Hi Xander,
any impact if we change the default LPTS? understand LPTS entries in TCAM, technically should be any problem as long as not more than TCAM memory, correct me if i am wrong
hi there,
the tcam is used for "acl" like matching and flow matching, that is one part of LPTS. the second part, the policing is done in a different stage and acting like regular policers.
there are reserved tcam spaces and policers for this.
by changing lpts flow rate values, we're just cnaging the rate of the existing already assigned policers.
by adding more eg bgp peers, we just burn more tcam entries that would match the bgp-known/default/established entries.
At some point you may run out of tcam entries, but that should not happen when you remain within quoted scale numbers.
regards
xander
Hi Xander,
thanks for the answer. from the document said" Take extreme care when changing the LPTS policer values" . when do we know that the threshold of the value of the policer?
Is there any calculation after we increase policer, how many more ebgp peer can be added.
for example : HSRP ,default 400 pps, we change to 1000. so how many HSRP can be added in with 1 sec hello and 3 hold time ?
that is the precise reason why I mentioned be careful changing timers in LPTS changing the hsrp punt rates doesnt automatically increase your scale from a control plane, that is still a bottleneck.
for HSRP you are better off using larger timers and then using BFD for fast failure detection this leaves with the highest HSRP scale and the best convergence.
only values I have seen requiring some change sometimes is:
ARP for higher arp learning rates
Fragment (to zero) since we dont allow frag in hw anyway and in sw there are no features
<routing-protocol> default (egp bgp-default) to zero since we have lpts entries for cfg and established.
regards
xander
so generally when we tune LPTS policer we need to monitor the control plane eg CPU process of the RP? is there theory or calculation the acceptable/recommendation LPTS policer that we can tune?
fortunately the control plane hosing situations that IOS was susceptible to I have never seen happen in XR.
even when one process has a runaway situation, the scehduler is totally independent of the processes and there is little point for concern.
there is also generally no need to tune the default LPTS policer values, unless:
1) your arp scale and needs are large and you expectneed faster arp learning
2) you want to harden XR a bit more upon which you can configure the -default policers for routing protocols to zero.
3) you see a lot of fragmentation punts and you want to eliminate this all together
4) if you see consistent slow convergence in namely BGP and you have a lot of peers on that same LC/NPU,
and you want to increase the established policer to allow more packets to go through.
some tuning might be encessary in BNG for DHCP policers to allow faster session establishment, but this has not been very common and frequent either (to date...).
health checking of your device is always important, but not more or less after tuning in my view.
this because a high cpu in one process doesnt cause the same toruble as it does in monolithic OS, also sometimes
high cpu is something you may want, like during convergence. high cpu in XR just means that the process uses its full time quantum as assigned by the scheduler.
regards
xander
Hi Xander,
I am tring to configure LPTS alerting with lpts-threshold-alerting.tcl. There are some error about script. I have tried to fix but I'm not expertise on eem scrips and want get another look.
Below is my configuration for EEM.
(admin)
username eem-scripts
group root-system
!
event manager environment EEM_LPTS_CHECK_INTERVAL 30
event manager environment EEM_LPTS_CHECK_FLOWTYPES *
event manager environment EEM_LPTS_CHECK_LOCATIONS 0/0/CPU0
event manager environment EEM_LPTS_CHECK_THRESHOLD 10%
event manager refresh-time 2000
event manager directory user policy disk0:/scripts/
event manager policy lpts-threshold-alerting.tcl username eem-scripts persist-time 3600
aaa authorization exec eem-scripts none
aaa authorization commands eem-scripts none
line template eem-scripts
accounting exec eem-scripts
accounting commands eem-scripts
authorization exec eem-scripts
authorization commands eem-scripts
authorization eventmanager default
login authentication default
session-timeout 0
transport input none
transport output none
!
vty-pool eem 100 105 line-template eem-scripts
1- First I get error for namespace,
RP/0/RSP0/CPU0:Nov 11 10:00:28.568 : syslog_dev[94]: noscan: unknown namespace in import pattern "::cisco::fm::*"
I changed it to ::cisco::eem::
2 - Secondly it gives error about execution time,
RP/0/RSP0/CPU0:Nov 11 09:58:04.981 : eem_server[205]: %HA-HA_EM-6-FMS_POLICY_TIMEOUT : Policy 'lpts-threshold-alerting.tcl' has hit its maximum execution time of 20.000000000 seconds, and so has been halted
Then i changed maxrun parameter to 60s
::cisco::eem::event_register_timer watchdog name lptsCheckTimer time $EEM_LPTS_CHECK_INTERVAL maxrun 60
Hi Deniz,
the changes you have made are very sound! nice find!
cheers
xander
Thanks a lot but I forgot to ask why its getting more than 20s to get cli out put of lpts pifib? On a regular cli session its not more than 1s and I am testing on a empty test platform.
Obviously I havent done the analysis as to where the time is spent, whether it is in the cli open, the capture of the info or the parsing of it. But 20 seconds seems or should be more then enough realistically.
it could be as simple as a "page more" type of thing that can be negated with a pipe include in the show fetch.
Another option is to put some puts statements in the script so we can see where the time is spent and optimize where possible.
also try to see if a CLI no term length when the script is started helps there.
cheers!
xander
Hi Xander,
I am not giving up:)
I added some puts to the script, I found that it took ~15s to open a CLI session.
puts "OPENING CLI"
if [catch {cli_open} result] {
error $result $errorInfo
} else {
array set cli $result
}
puts "CLI OPENED"
Some debug.
RP/0/RSP0/CPU0:Nov 13 10:31:40.621 : syslog_dev[94]: noscan: OPENING CLI
RP/0/RSP0/CPU0:Nov 13 10:31:40.624 : eem_policy_dir[204]: fh_edm_get_fn: Invoked for item_name policy/lpts-threshold-alerting.tcl. vec_entries-> total: 2, valid 1
RP/0/RSP0/CPU0:Nov 13 10:31:40.624 : eem_policy_dir[204]: fh_edm_get_fn: Sending username eem-scripts for policy lpts-threshold-alerting.tcl
RP/0/RSP0/CPU0:Nov 13 10:31:40.627 : eem_policy_dir[204]: fh_edm_set_fn called with item_name user/lpts-threshold-alerting.tcl/eem-scripts pid value 205304128
RP/0/RSP0/CPU0:Nov 13 10:31:40.627 : eem_policy_dir[204]: Updated pid field (205304128) for policy lpts-threshold-alerting.tcl, user eem-scripts
RP/0/RSP0/CPU0:Nov 13 10:31:43.660 : wdsysmon[441]: fh_process_sync:149 msg type :106 :FH_MSG_WD_SHOW_READ_LEN
RP/0/RSP0/CPU0:Nov 13 10:31:43.660 : wdsysmon[441]: fh_process_sync: Trying to read len
RP/0/RSP0/CPU0:Nov 13 10:31:43.667 : wdsysmon[441]: fh_fd_wdsysmon_show_read_len: DB Ready len = 88336
RP/0/RSP0/CPU0:Nov 13 10:31:43.686 : wdsysmon[441]: fh_process_sync:149 msg type :104 :FH_MSG_WD_SHOW_READ
RP/0/RSP0/CPU0:Nov 13 10:31:45.654 : eem_ed_timer[201]: fh_fd_timer_get_realtime: 1415867505.654
RP/0/RSP0/CPU0:Nov 13 10:31:45.655 : eem_ed_timer[201]: fh_fd_msg_send_event: sending publish data:0:0
RP/0/RSP0/CPU0:Nov 13 10:31:45.656 : eem_ed_timer[201]: fh_fd_timer_event_expire: re=0x5003d4c0
RP/0/RSP0/CPU0:Nov 13 10:31:45.656 : eem_server[205]: received async FH_MSG_EVENT_PUBLISH fdid:15
RP/0/RSP0/CPU0:Nov 13 10:31:45.657 : eem_server[205]: EEM: server processes multi events: esid=36
RP/0/RSP0/CPU0:Nov 13 10:31:45.657 : eem_server[205]: fms_chkpt_tbl_add: add chkpt obj 0x800fde18 from table 0x80001100successful
RP/0/RSP0/CPU0:Nov 13 10:31:45.658 : eem_server[205]: EEM: server processes multi events: timewin=1, sync_flag=0, ec_index=0, cmp_occ=1
RP/0/RSP0/CPU0:Nov 13 10:31:45.658 : eem_server[205]: EEM: server processes multi events: get correlate result esid=36
RP/0/RSP0/CPU0:Nov 13 10:31:45.658 : eem_server[205]: EEM: ctx=36:(36,1,1)
RP/0/RSP0/CPU0:Nov 13 10:31:45.658 : eem_server[205]: EEM: server processes multi events: corr_res=1, cur_tcnt=1, cmp_tcnt=1
RP/0/RSP0/CPU0:Nov 13 10:31:45.658 : eem_server[205]: fms_chkpt_tbl_add: add chkpt obj 0x800fde38 from table 0x80004d00successful
RP/0/RSP0/CPU0:Nov 13 10:31:45.659 : eem_server[205]: fms_chkpt_tbl_add: add chkpt obj 0x800fde58 from table 0x80004e00successful
RP/0/RSP0/CPU0:Nov 13 10:31:45.659 : eem_server[205]: EEM: server processes multi events: schedule an event esid=36, corr_id=12471, grpid=36
RP/0/RSP0/CPU0:Nov 13 10:31:45.660 : eem_server[205]: fms_chkpt_tbl_add: add chkpt obj 0x800fdf58 from table 0x80001a00successful
RP/0/RSP0/CPU0:Nov 13 10:31:45.660 : eem_server[205]: EEM server schedules scripts
RP/0/RSP0/CPU0:Nov 13 10:31:45.660 : eem_server[205]: fh_schedule_policy: prev_epc=0x0; epc=0x50546d08
RP/0/RSP0/CPU0:Nov 13 10:31:45.661 : eem_server[205]: EEM: server has no available thread to service the policy class=default policy_type=script.
RP/0/RSP0/CPU0:Nov 13 10:31:45.661 : eem_server[205]: EEM: server has no available thread to service the policy class=default policy_type=script.
RP/0/RSP0/CPU0:Nov 13 10:31:45.661 : eem_server[205]: EEM: server has no available thread to service the policy class=default policy_type=script.
.....
RP/0/RSP0/CPU0:Nov 13 10:31:45.680 : eem_server[205]: EEM: server processes multi events: clean correlate data in ec: esid=36
RP/0/RSP0/CPU0:Nov 13 10:31:45.680 : eem_server[205]: fms_chkpt_tbl_remove: delete chkpt obj 0x800fde18 from table 0x80001100successful
RP/0/RSP0/CPU0:Nov 13 10:31:53.695 : wdsysmon[441]: fh_process_sync:149 msg type :106 :FH_MSG_WD_SHOW_READ_LEN
RP/0/RSP0/CPU0:Nov 13 10:31:53.695 : wdsysmon[441]: fh_process_sync: Trying to read len
RP/0/RSP0/CPU0:Nov 13 10:31:53.696 : wdsysmon[441]: fh_fd_wdsysmon_show_read_len: DB Ready len = 88612
RP/0/RSP0/CPU0:Nov 13 10:31:53.697 : wdsysmon[441]: fh_process_sync:149 msg type :104 :FH_MSG_WD_SHOW_READ
RP/0/RSP0/CPU0:Nov 13 10:31:55.655 : eem_ed_timer[201]: fh_fd_timer_get_realtime: 1415867515.655
RP/0/RSP0/CPU0:Nov 13 10:31:55.655 : eem_ed_timer[201]: fh_fd_msg_send_event: sending publish data:0:0
RP/0/RSP0/CPU0:Nov 13 10:31:55.656 : eem_ed_timer[201]: fh_fd_timer_event_expire: re=0x5003d4c0
RP/0/RSP0/CPU0:Nov 13 10:31:55.656 : eem_server[205]: received async FH_MSG_EVENT_PUBLISH fdid:15
RP/0/RSP0/CPU0:Nov 13 10:31:55.656 : eem_server[205]: EEM: server processes multi events: esid=36
RP/0/RSP0/CPU0:Nov 13 10:31:55.657 : eem_server[205]: fms_chkpt_tbl_add: add chkpt obj 0x800fde18 from table 0x80001100successful
RP/0/RSP0/CPU0:Nov 13 10:31:55.657 : eem_server[205]: EEM: server processes multi events: timewin=1, sync_flag=0, ec_index=0, cmp_occ=1
RP/0/RSP0/CPU0:Nov 13 10:31:55.657 : eem_server[205]: EEM: server processes multi events: get correlate result esid=36
RP/0/RSP0/CPU0:Nov 13 10:31:55.657 : eem_server[205]: EEM: ctx=36:(36,1,1)
RP/0/RSP0/CPU0:Nov 13 10:31:55.657 : eem_server[205]: EEM: server processes multi events: corr_res=1, cur_tcnt=1, cmp_tcnt=1
RP/0/RSP0/CPU0:Nov 13 10:31:55.657 : eem_server[205]: fms_chkpt_tbl_add: add chkpt obj 0x800fddf8 from table 0x80004d00successful
RP/0/RSP0/CPU0:Nov 13 10:31:55.658 : eem_server[205]: fms_chkpt_tbl_add: add chkpt obj 0x800fddd8 from table 0x80004e00successful
RP/0/RSP0/CPU0:Nov 13 10:31:55.658 : eem_server[205]: EEM: server processes multi events: schedule an event esid=36, corr_id=12472, grpid=36
RP/0/RSP0/CPU0:Nov 13 10:31:55.658 : eem_server[205]: fms_chkpt_tbl_add: add chkpt obj 0x800fddb8 from table 0x80001a00successful
RP/0/RSP0/CPU0:Nov 13 10:31:55.659 : eem_server[205]: EEM server schedules scripts
RP/0/RSP0/CPU0:Nov 13 10:31:55.658 : eem_server[205]: fh_schedule_policy: prev_epc=0x0; epc=0x504d42f8
RP/0/RSP0/CPU0:Nov 13 10:31:55.659 : eem_server[205]: EEM: server has no available thread to service the policy class=default policy_type=script.
........
RP/0/RSP0/CPU0:Nov 13 10:31:55.672 : eem_server[205]: EEM: server processes multi events: clean correlate data in ec: esid=36
RP/0/RSP0/CPU0:Nov 13 10:31:55.672 : eem_server[205]: fms_chkpt_tbl_remove: delete chkpt obj 0x800fde18 from table 0x80001100successful
RP/0/RSP0/CPU0:Nov 13 10:31:57.822 : syslog_dev[94]: noscan: CLI OPENED
Regards
Deniz.
Nice work Deniz! Ok that explains much of the delay already!
What version of XR are you using here? That might be important to know, meanwhile I am trying to figure out if this is related to some known issue or what can be done about it.
cheers!
xander
Hi Xander,
we are using 5.1.2.
cheers
Deniz.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: