Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Debugging cRPD Application

Troubleshooting is a systematic approach to solving a problem. The goal of troubleshooting is to determine why something does not work as expected and how to resolve the problem.

Command-Line Interface

The Junos OS command-line interface (CLI) is the primary tool for controlling and troubleshooting router hardware, the Junos OS, routing protocols, and network connectivity. CLI commands display information from routing tables, information specific to routing protocols, and information about network connectivity derived from the traceroute utilities. RPD tracelog facilities are supported and enabled through the CLI. Trace log files are stored /var/log path.

You can use the following Junos CLI commands to troubleshoot cRPD:

  • show task: Display the routing protocol tasks on the Routing Engine.

  • show task memory detail: Display the memory utilization for routing protocol tasks on the Routing Engine.

  • show route: Display the active entries in the routing tables.

  • show bfd: Display information about active Bidirectional Forwarding Detection (BFD) sessions.

  • show bgp: Display information about BGP summary information for all routing instances.

  • show (ospf | ospf3): Display standard information about all OSPF neighbors for all routing instances.

  • show interfaces routing: Perform router diagnostics.

  • show log: View system activity logs and allows you to monitor and view information for performance monitoring, troubleshooting, and debugging purposes.

  • show krt: Monitor KRT queues and their states.

  • show programmable-rpd: List clients connected to the programmable routing protocol process (prpd) server. The prpd provides public APIs to program routing systems, making it possible for users to directly access the APIs to customize, create, and modify the behavior of their network.

  • ip monitor: Monitor the installation of routes to Linux FIB and interface events and netlink messages.

  • tcpdump: Capture network traffic to/from control plane.

  • netstat: Monitor the sockets.

  • request support information: Display the support information which is used for troubleshooting.

Fault Handling

When the rpd crashes due to some issue, the rpd process is restarted automatically. To recover manually from a fault, you can implement the following CLI command hierarchies to handle the faults:

  • restart routing: Restart the rpd.

  • clear bgp: Clear BGP sessions.

  • deactivate: Deactivate CLI configuration.

  • activate: Activate the CLI configuration.

Troubleshooting Container

You can implement various docker commands to monitor and troubleshoot issues at container level when cRPD is deployed as a docker container.

  • docker ps: List out active containers and their state.

  • docker stats: Continuous monitor the resource utilization.

  • docker logs: Extract container logs in case the container terminates unexpectedly.

  • docker stop: Stop the Docker from the current state.

  • docker start: Restart the Docker container.

Verify Docker

  1. Verify the installed Docker Engine version by using the docker version command.

    root@ubuntu-vm18:~# docker version

  2. View the software and hardware information in the system.

    root@ubuntu-vm18:~# uname -a

  3. View the version of ubuntu.

    root@ubuntu-vm18:~# lsb_release -a

Viewing Core Files

Purpose

When a core file is generated, you can find the output at /var/crash. The core files generated are stored on the system that is hosting the Docker containers.

You can also use ping and ping6 to check the reachability at the shell mode.

Action

To list the core files:

  1. Exit from the CLI environment to return to the host unix shell.

    user@host> start shell

  2. Change the directory to /var/crash:

    root@ubuntu-vm18$ cd /var/crash

    root@ubuntu-vm18$ ls -l

  3. Run the command to identify the location of the core files:

    root@ubuntu-vm18$ sysctl kernel.core_pattern

  4. Verify for any core files created around the time of the crash.

Configuring Syslog

Syslog is enabled by default and the messages are stored at /var/log/messages file stored on the local Routing Engine.

To configure remote syslog:

  1. Access the cRPD Linux shell.
  2. Open the /etc/rsyslog.conf file.
  3. Add the following facility information:

    *.* @<IP address>:<port>

    Where: <IP address> is the IP address of the remote syslog server.

  4. Save the file.
  5. Restart syslog by using the following command:

    root@crpd1# service rsyslog restart

To view the log messages:

  1. You can view the log messages using the following command:

    root@crpd1> show log messages