How to restore remote access to cisco 3750 without rebooting the device?

Question

Cisco

Good afternoon, colleagues encountered unexpected difficulties: when setting up policy based routing on a cisco 3750 (c3750-ipservicesk9-mz.122-55.SE9), I lost remote access to it ( telnet web ).
Below is the sequence of actions that led to the problem.
There was a need for a certain network to set another default gateway. An access list was created that looked like this:
ip access-list extended toInet
permit ip host 192.168.22.0 0.0.0.255 any
!
then the policy
route-map to_192.168.0.1 was created permit 10
match ip address toInet
set ip default next-hop 192.168.0.1
!
!
Then I hung the policy on the interface
interface Vlan22
description 192.168.22.0
ip address 192.168.22.1 255.255.255.0
ip helper-address 192.168.25.10
ip policy route-map to_192.168.0.1
!
As a result - nothing has changed, the traffic still went through the "wrong" main gateway.
it seems that for some reason the set ip default nex hop command did not work or I misunderstood its meaning. Altered the acces
list and policy (for internal networks, stomp on the old default gateway for the Internet, stomp on 192.168.0.1 ) 0.255 192.168.21.0 0.0.0.255 deny ip 192.168.22.0 0.0.0.255 192.168.28.0 0.0.0.255 deny ip
permit ip host 192.168.22.0 any
!
route-map to_192.168.0.1 permit 10
match ip address toInet
set ip next-hop 192.168.0.1
!
And then oddities began, PBR earned. A couple of hours passed, the monitoring system said that a backup copy of the tsiska configuration was not created. I tried to log in to the switch and oh .... the switch is not available. From other subnets, everything is the same - unavailable. But it works. I went to the server room - I hooked up to the switch with the console, got the previous configuration from yesterday's date from the archive. There is still no telnet access to the device.
Total 3 questions:
1) Why didn't set ip default next-hop work?
2) How can I get back remote access to a tsiska without rebooting it?
If you have to reboot, does it make sense to do a warm reboot to reduce downtime?
3) What the hell happened, why telnet access fell off, what to dig where to look?

Answer 1

It was a glitch of a tsiska. After a reboot at night everything went back to normal.

Answer 2

The set ip default next-hop command checks if the destination address exists in the routing table, and
if the destination address exists, the command does not route the packet, instead it redirects the packet to match the routing table.
- if the destination address does not exist, the command routes the packet, sending it to the specified next-hop.
The set ip next-hop command checks for the existence of the specified next-hop, and
if next-hop exists in the routing table, then the packet is routed to that next-hop.
- if next-hop does not exist in the routing table, the packet is redirected according to the routing table.
2) show the output of sh run | section vty