CISCO troubleshooting | Hardware configuration



Rep: (1)
CISCO troubleshooting

Attached Image


The theme was created to help with troubleshooting the configuration of CISCO equipment. Spread configs and describe problems. We will disassemble.


Post has been editedAndrewP_1 - 16.06.19, 15:26
Reason for editing: reshaping the header



Rep: (2694)
Though it is a native trunk, it will let others pass it
No, native is not a port, native tells the trunk port where to send untagged traffic. By default, this is Vlan 1, but it is recommended to extinguish it, for you are not putting: D
Right hereless available.

I imagineyour ownpile

I will do then, 192.168.1.0 - there will be a LAN network, 192.168.2.0 - another
Hunt the same Klava torment. Almost perfect networkSetting up networks, Internet access and network equipment (Post # 26291775)


Post has been editedShoore - 09.01.14, 21:00



Rep: (1049)
No, native is not a port, native tells the trunk port where to send untagged traffic. By default, this is Vlan 1, but it is recommended to extinguish it, for you are not putting: D
Here is less accessible.

Yes, I'm stupid. Trunk it for all vlan.
I express my deep gratitude to the distinguishedShoorefor assistance in configuring Cisco configuration, everything that was planned turned out and works as it should. : thank_you:



Rep: (1049)
I welcome colleagues Tsiskari!
Recently, and in other matters, I often began to notice with periodicity that the load on the Tsiski 2901 proces was sometimes very strong at 90%. For this, I set up a script for logging this process.
event manager applet CPU
event snmp oid 1.3.6.1.4.1.9.9.109.1.1.1.1.3.1 get-type exact entry-op gt entry-val "70" exit-op lt exit-val "50" poll-interval 0.500
action 1.1 syslog msg "------ HIGH CPU DETECTED ----, CPU: $ _snmp_oid_val%"
action 2.0 cli command "enable"
action 3.0 cli command "show clock | append nvram: cpuinfo.txt"
action 4.0 cli command "show proc cpu sort | append nvram: cpuinfo.txt"

That is, with a load of 70%, logs will be dumped into the internal memory of the Tsiski from where you can see. Here is the latest data it was yesterday:
17: 51: 41.601 Moscow Mon May 19 2014

CPU utilization for five seconds: 98% / 54%; one minute: 23%; five minutes: 16%
PID Runtime (ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
59 6088 162 37580 41.61% 3.33% 0.69% 388 Virtual Exec
122 38270248 110007317 347 0.94% 1.26% 1.34% 0 IP Input
385 389520 10625567 36 0.15% 0.14% 0.14% 0 IP NAT Ager
2 31980 1086720 29 0.07% 0.01% 0.00% 0 Load Meter
3 36 44 818 0.07% 0.00% 0.00% 0 EEM Callback Th r
265 198776 6693610 29 0.07% 0.07% 0.08% 0 FW DP Inspect p r
129 124168 687826403 0 0.07% 0.21% 0.23% 0 Ethernet Msec T i
200 77360 5766716 13 0.07% 0.02% 0.02% 0 CEF: IPv4 proce s
362 3984 447293 8 0.07% 0.01% 0.00% 0 EEM ED SNMP
10 44 2427 18 0.07% 0.00% 0.00% 0 WATCH_AFS

Well, in general, it seems clear that downloading 98% of them to interrupt 54% and to traffic everything else. It seems to be clear with this example. But there are cases that the difference between the X / Y workload indicators is minimal, the percentage is only scored Y, which means that only interrupts. How to calculate what ziski processor is hammering? But what is interesting is not always, or it happens but after 5 minutes the load drops to 5%.


Full version    

Help     rules

Now: 07/15/19 13:24