- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
10-16-2014 03:43 AM
I look after a PA2050 running OS 4.1.8
I am trying to setup 2 new static routes in my virtual router but they are not being picked up when I do a show routing route or show routing fib after a commit.
One of the routes is a new one and the other is a reassigned subnet that was used on an old decommissioned site (this route was removed).
In simple terms it is not allowing me to add or edit static routes.
Has anybody come across this issue? Would a reboot force it to recreate its routing tables with the new information (the device has been up for around 416 days).
Is there any other way to force a route change?
Regards,
Phil
10-16-2014 05:56 AM
Hi Phil,
That is not an expected behavior. Please go ahead an add a random route say 1.1.1.1/32 and point the next hop as your default route. Do a commit and run "show routing route" and see if 1.1.1.1 appears on the routing table.
Do a show jobs all to see if the commit itself went fine?
Check show system resources for mgmtsrvr, devsrvr and routed and notice if one of them is abnormally high.
If possible try restarting management server and routed porcess
debug software restart management-server
debug software restart routed
If that still does not help and then do a reboot. Hope this helps. Thank you.
10-16-2014 06:37 AM
Hi Phild,
You might have configured next hope which is not reachable, because of that route is not a good route and routing table doesnt except it.
Can you please share screen shot of static route configuation and provide us "show arp all | match <next-hope> output.
Regards,
Hardik Shah
10-16-2014 09:16 AM
Hi sshama
I tried what you recommended (added a random route 1.1.1.1/32 pointing to the next hop of our default route). I committed this and checked with "show jobs all" to confirm it committed ok.
When I ran "show routing route" I did not see my test static route.
Based on "show system resources" for mgmtsrvr, devsrvr and routed they are all ow (0%) for CPU.
How disruptive are the commands below?
debug software restart management-server
debug software restart routed
I have run "debug software restart management-server" before which did not fix another problem and I had to reboot in the end.
I might try to the "debug software restart routed" before I do the reboot.
My PA has been up for 420 days. Is it recommended they are rebooted as a matter of routine?
I hope to reboot it this weekend. I will let you know how I get one.
Phil
10-16-2014 09:17 AM
Hi,
I tried the test route from ssharmas reply and it did no present it in the routing table.
Phil
10-16-2014 09:19 AM
Hi Phil,
I am interested in looking at not only CPU but also the memory utilization of it. If you can paste the output of "show system resources", I can make some comments based on the output.
If you don't have dynamic routing (bgp or ospf) restarting routed should not be disruptive.
There is no suggested reboot routine, but based on the utilization and device performance, you can reboot a device once it runs a longer period of times. Thank you.
10-16-2014 09:47 AM
Hi,
I have pasted our resource details below. Our 3rd party support company is recommending a full reboot over a restart of sub services.
Phil
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2014.10.16 17:43:56 =~=~=~=~=~=~=~=~=~=~=~=
show system resources
[?1h = [24;1H [K
top - 17:44:03 up 420 days, 10:53, 1 user, load average: 0.52, 0.55, 0.80
Tasks: 94 total, 1 running, 93 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.3%us, 4.3%sy, 7.4%ni, 84.9%id, 0.9%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 995888k total, 894380k used, 101508k free, 22796k buffers
Swap: 2008084k total, 994276k used, 1013808k free, 75876k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31337 20 0 4468 1020 800 R 4 0.1 0:00.06 top
1 20 0 1836 564 536 S 0 0.1 0:04.56 init
2 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd
3 RT 0 0 0 0 S 0 0.0 1:52.40 migration/0
4 20 0 0 0 0 S 0 0.0 0:10.12 ksoftirqd/0
5 RT 0 0 0 0 S 0 0.0 2:00.85 migration/1
6 20 0 0 0 0 S 0 0.0 0:09.35 ksoftirqd/1
7 20 0 0 0 0 S 0 0.0 0:07.04 events/0
8 20 0 0 0 0 S 0 0.0 0:06.18 events/1
9 20 0 0 0 0 S 0 0.0 0:00.04 khelper
12 20 0 0 0 0 S 0 0.0 0:00.00 async/mgr
112 20 0 0 0 0 S 0 0.0 0:00.06 sync_supers
114 20 0 0 0 0 S 0 0.0 0:00.15 bdi-default
115 20 0 0 0 0 S 0 0.0 8:20.84 kblockd/0
116 20 0 0 0 0 S 0 0.0 3:12.59 kblockd/1
[24;1H [K [7mlines 1-23 [27m [24;1H [24;1H [K 125 20 0 0 0 0 S 0 0.0 0:00.00 ata/0
126 20 0 0 0 0 S 0 0.0 0:00.00 ata/1
127 20 0 0 0 0 S 0 0.0 0:00.00 ata_aux
132 20 0 0 0 0 S 0 0.0 0:00.00 khubd
135 20 0 0 0 0 S 0 0.0 0:00.00 kseriod
154 20 0 0 0 0 S 0 0.0 0:00.00 rpciod/0
155 20 0 0 0 0 S 0 0.0 0:00.00 rpciod/1
167 20 0 0 0 0 S 0 0.0 192:51.49 kswapd0
168 20 0 0 0 0 S 0 0.0 0:00.00 aio/0
169 20 0 0 0 0 S 0 0.0 0:00.00 aio/1
170 20 0 0 0 0 S 0 0.0 0:00.00 nfsiod
723 20 0 0 0 0 S 0 0.0 0:01.92 octeon-ethernet
741 20 0 0 0 0 S 0 0.0 0:00.00 scsi_eh_0
743 20 0 0 0 0 S 0 0.0 0:00.00 scsi_eh_1
750 20 0 0 0 0 S 0 0.0 0:00.47 mtdblockd
773 20 0 0 0 0 S 0 0.0 0:00.00 usbhid_resumer
812 20 0 0 0 0 S 0 0.0 18:13.76 kjournald
856 20 0 320m 81m 1932 S 0 8.4 3690:51 logrcvr
861 20 0 0 0 0 S 0 0.0 38:19.58 flush-8:0
866 16 -4 2008 392 388 S 0 0.0 0:01.38 udevd
1738 20 0 0 0 0 S 0 0.0 0:36.38 kjournald
1739 20 0 0 0 0 S 0 0.0 0:00.00 kjournald
1895 20 0 2008 624 584 S 0 0.1 0:32.30 syslogd
[24;1H [K [7mlines 24-46 [27m [24;1H [24;1H [K 1898 20 0 1892 332 328 S 0 0.0 0:00.13 klogd
1906 rpc 20 0 2084 492 488 S 0 0.0 0:00.00 portmap
1924 20 0 2116 664 660 S 0 0.1 0:00.05 rpc.statd
1993 20 0 6852 472 468 S 0 0.0 0:00.78 sshd
2036 20 0 6788 388 384 S 0 0.0 0:00.00 sshd
2045 20 0 3280 616 612 S 0 0.1 0:00.04 xinetd
2064 20 0 0 0 0 S 0 0.0 0:00.00 lockd
2065 20 0 0 0 0 S 0 0.0 55:46.50 nfsd
2066 20 0 0 0 0 S 0 0.0 55:29.45 nfsd
2067 20 0 0 0 0 S 0 0.0 55:49.09 nfsd
2068 20 0 0 0 0 S 0 0.0 56:18.55 nfsd
2069 20 0 0 0 0 S 0 0.0 56:06.65 nfsd
2070 20 0 0 0 0 S 0 0.0 57:01.14 nfsd
2071 20 0 0 0 0 S 0 0.0 58:33.45 nfsd
2072 20 0 0 0 0 S 0 0.0 59:33.34 nfsd
2075 20 0 4536 680 580 S 0 0.1 1:43.21 rpc.mountd
2104 0 -20 60636 4580 1892 S 0 0.5 1119:08 masterd_core
2107 20 0 1824 448 444 S 0 0.0 0:00.00 agetty
2114 0 -20 26132 1344 984 S 0 0.1 47:34.93 masterd_manager
2121 15 -5 44324 2524 1040 S 0 0.3 8485:10 sysd
2123 0 -20 30192 4832 1052 S 0 0.5 1862:27 masterd_manager
2127 20 0 90420 2612 1472 S 0 0.3 0:34.85 dagger
2128 30 10 38124 3540 1668 S 0 0.4 1497:39 python
[24;1H [K [7mlines 47-69 [27m [24;1H [24;1H [K 2129 20 0 81552 2884 1196 S 0 0.3 4:06.20 cryptod
2130 20 0 165m 1920 1140 S 0 0.2 279:43.61 sysdagent
2146 20 0 7212 624 620 S 0 0.1 0:00.08 tscat
2147 20 0 70016 1048 920 S 0 0.1 69:13.78 brdagent
2148 20 0 30080 1120 944 S 0 0.1 61:59.18 ehmon
2149 20 0 45472 1156 1004 S 0 0.1 1:46.48 chasd
2243 20 0 0 0 0 S 0 0.0 8:42.12 kjournald
2258 20 0 2900 628 572 S 0 0.1 0:35.49 crond
2267 20 0 947m 196m 3708 S 0 20.2 2369:37 mgmtsrvr
2279 20 0 450m 95m 7736 S 0 9.9 1187:45 devsrvr
2298 20 0 90484 2812 1728 S 0 0.3 160:47.06 ikemgr
2300 20 0 97620 1968 1160 S 0 0.2 2:07.66 rasmgr
2301 20 0 97052 1508 1104 S 0 0.2 558:34.63 keymgr
2302 20 0 200m 1448 1160 S 0 0.1 265:44.30 varrcvr
2303 17 -3 54588 1552 968 S 0 0.2 50:42.02 ha_agent
2304 20 0 84668 1484 1144 S 0 0.1 0:21.69 sslmgr
2305 20 0 56824 2316 1072 S 0 0.2 1:09.77 dhcpd
2306 20 0 182m 35m 32m S 0 3.7 730:25.32 useridd
2307 20 0 74328 2624 1328 S 0 0.3 1:25.02 dnsproxyd
2308 20 0 72560 1404 1064 S 0 0.1 0:53.59 pppoed
2309 20 0 134m 2256 1152 S 0 0.2 64:50.03 routed
2310 20 0 131m 2752 1484 S 0 0.3 44:25.46 authd
8145 20 0 25516 1836 1396 S 0 0.2 100:24.45 snmpd
[24;1H [K [7mlines 70-92 [27m [24;1H [24;1H [K18182 nobody 20 0 113m 1816 1340 S 0 0.2 1:40.76 appweb3
18184 nobody 20 0 249m 34m 3996 S 0 3.6 1094:23 appweb3
18194 nobody 20 0 175m 7628 1552 S 0 0.8 6:20.52 appweb3
22592 20 0 21324 1300 1132 S 0 0.1 0:00.23 sshd
24938 admin 20 0 21324 1140 932 S 0 0.1 0:00.50 sshd
24942 admin 20 0 95064 8824 2504 S 0 0.9 0:05.53 cli
31334 admin 20 0 2976 668 564 S 0 0.1 0:00.04 less
31336 20 0 3832 1192 1056 S 0 0.1 0:00.10 sh
31338 20 0 1940 540 464 S 0 0.1 0:00.01 sed
31889 20 0 3744 3624 2756 S 0 0.4 0:00.04 ntpd
[24;1H [K [?1l >admin@PA-2050>
10-16-2014 09:54 AM
Management server is close to a gig
2267 20 0 947m 196m 3708 S 0 20.2 2369:37 mgmtsrvr
which should be of some concern. But given the commit goes fine and you are not able to see the routes is bit wired. I would still suggest restarting both services mentioned above and also reboot the device if possible. If that still does not resolve the issue, contact Palo Alto support for further analysis. Thank you.
10-16-2014 10:03 AM
Hi do you interpret the management server as using nearly a gig from the results you show?
Keen to learn!!
Phil
10-16-2014 10:05 AM
2267 20 0 947m 196m 3708 S 0 20.2 2369:37 mgmtsrvr
The value in bold tells us it is close to a gig. 1 Gig = 1024m and 947m is close to this value.
10-16-2014 10:05 AM
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2267 20 0 947m 196m 3708 S 0 20.2 2369:37 mgmtsrvr
947m <---------------- here it is using nearly a gig worth of memory
Hope this helps. Thank you.
10-16-2014 04:54 PM
There was reported issue in early 5.0 version wherein the static routes would go missing in the routing table if the interface is selected in the static route.
Can you try removing the interface from the route, commit the change and then check the routing table?
Thanks
10-16-2014 05:40 PM
Hi Phild,
Did restarting management server fixed issue ?
Just Tshiv, I think its a configuration issue. It would be a good idea if you can share screen shot of the configuration.
Regards,
Hardik Shah
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!