Checking routing
If the MAC resolves correctly, but IP connectivity fails, try using ICMP (ping and traceroute) to determine if the host is reachable, or to locate the point on your network at which connectivity fails. You can do this from the FortiRecorder appliance using CLI commands.
IP layer connectivity fails when routes are incorrectly configured. Static routes direct traffic exiting the FortiRecorder appliance — you can specify through which network interface a packet will leave, and the IP address of a next-hop router that is reachable from that network interface. Routers are aware of which IP addresses are reachable through various network pathways, and can forward those packets along pathways capable of reaching the packets’ ultimate destinations. Your FortiRecorder itself does not need to know the full route, as long as the routers can pass along the packet.
You must configure FortiRecorder with at least one static route that points to a router, often a router that is the gateway to the Internet. You may need to configure multiple static routes if you have multiple gateway routers (e.g. each of which should receive packets destined for a different subset of IP addresses), redundant routers (e.g. redundant Internet/ISP links), or other special routing cases.
However, often you will only need to configure one route: a default route.
For example, if a web server is directly attached to one physical port on the FortiRecorder, but all other destinations, such as connecting clients, are located on distant networks, such as the Internet, you might need to add only one route: a default route that indicates the gateway router through which the FortiRecorder appliance can send traffic in the direction towards the Internet.
To determine which route a packet will be subject to, FortiRecorder examines each packet’s destination IP address and compares it to those of the static routes. It will forward the packet along to the route with the largest prefix match, automatically egressing from the network interface on that network. (Egress port for a route cannot be manually configured.)
The ping command sends a small data packet to the destination and waits for a response. The response has a timer that may expire, indicating that the destination is unreachable via ICMP. ICMP is part of Layer 3 on the OSI Networking Model. ping sends Internet Control Message Protocol (ICMP) ECHO_REQUEST packets to the destination, and listens for ECHO_RESPONSE packets in reply. Beyond basic existence of a possible route between the source and destination, ping tells you the amount of packet loss (if any), how long it takes the packet to make the round trip (latency), and the variation in that time from packet to packet (jitter).
Similarly, traceroute sends ICMP packets to test each hop along the route. It sends three packets to the destination, and then increases the time to live (TTL) setting by one, and sends another three packets to the destination. As the TTL increases, packets go one hop farther along the route until they reach the destination.
Most traceroute commands display their maximum hop count — that is, the maximum number of steps it will take before declaring the destination unreachable — before they start tracing the route. The TTL setting may result in routers or firewalls along the route timing out due to high latency. If you specify the destination using a domain name, the traceroute output can also indicate DNS problems, such as an inability to connect to a DNS server.
By default, FortiRecorder appliances will respond to ping and traceroute. However, if FortiRecorder does not respond, and there are no firewall policies that block it, ICMP type 0 (ECHO_REPSPONSE or “pong”) might be effectively disabled. By default, traceroute uses UDP with destination ports numbered from 33434 to 33534. The traceroute utility usually has an option to specify use of ICMP ECHO_REQUEST (type 8) instead, as used by the Windows tracert utility. If you have a firewall and you want traceroute to work from both machines (Unix-like systems and Windows) you will need to allow both protocols inbound through your firewall (UDP ports 33434 - 33534 and ICMP type 8).
Some networks block ICMP packets because they can be used in a ping flood or denial of service (DoS) attack if the network does not have anti-DoS capabilities, or because ping can be used by an attacker to find potential targets on the network.
To enable ping & traceroute responses from FortiRecorder
1. Go to System > Network > Interface.
To access this part of the web UI, you must have Read and Write permission in your administrator's account access profile to items in the Router Configuration category.
2. In the row for the network interface which you want to respond to ICMP type 8 (ECHO_REQUEST) for ping and UDP for traceroute, click Edit.
A dialog appears.
| Disabling PING only prevents FortiRecorder from receiving ICMP type 8 ( ECHO_REQUEST) and traceroute-related UDP. It does not disable FortiRecorder CLI commands such as execute ping or execute traceroute that send such traffic. Since you typically use these tools only during troubleshooting, you can allow ICMP, the protocol used by these tools, on interfaces only when you need them. Otherwise, disable ICMP for improved security and performance |
4. Click OK.
The appliance should now respond when another device such as your management computer sends a ping or traceroute to that network interface.
To verify routes between cameras & your FortiRecorder
1. Use FortiRecorder’s execute ping command with the camera’s IP address to verify that a route exists between the two.
2. If possible, temporarily connect a computer at the camera’s usual physical location, using the camera’s usual IP address, so that you can use its ping command to test traffic movement along the path in both directions: from the location of the camera (temporarily, the computer) to the FortiRecorder, and the FortiRecorder to the camera.
| In networks using features such as asymmetric routing, routing success in one direction does not guarantee success in the other. |
If the routing test
succeeds, continue with step
4.
| Connectivity via ICMP only proves that a route exists. It does not prove that connectivity also exists via other protocols at other layers such as HTTP. |
If ping shows some packet loss, investigate:
• cabling to eliminate loose connections
• ECMP, split horizon, or network loops
• dynamic routing such as OSPF
• all equipment between the ICMP source and destination to minimize hops
If the routing test fails, and ping shows total packet loss:
• verify cabling to eliminate loose connections
• continue to the next step
For example, you might use ping to determine that 172.16.1.10 is reachable:
FortiRecorder-200D# execute ping 172.16.1.10
PING 172.16.1.10 (172.16.1.10): 56 data bytes
64 bytes from 172.16.1.10: icmp_seq=0 ttl=64 time=2.4 ms
64 bytes from 172.16.1.10: icmp_seq=1 ttl=64 time=1.4 ms
64 bytes from 172.16.1.10: icmp_seq=2 ttl=64 time=1.4 ms
64 bytes from 172.16.1.10: icmp_seq=3 ttl=64 time=0.8 ms
64 bytes from 172.16.1.10: icmp_seq=4 ttl=64 time=1.4 ms
--- 172.20.120.167 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.8/1.4/2.4 ms
or that 192.168.1.10 is not reachable:
FortiRecorder-200D# execute ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10): 56 data bytes
Timeout ...
Timeout ...
Timeout ...
Timeout ...
Timeout ...
--- 192.168.1.10 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
3. Use the tracert or traceroute command on both the camera (temporarily, the computer) and FortiRecorder to locate the point of failure along the route, the router hop or host at which the connection fails. For example, if it fails at the second hop, you might see:
FortiRecorder-200D# execute traceroute 192.168.1.10
traceroute to 192.168.1.10 (192.168.1.10), 32 hops max, 72 byte packets
1 192.168.1.2 2 ms 0 ms 1 ms
2 * * *
Each line lists the routing hop number, the IP address and FQDN (if any) of that hop, and the 3 response times from that hop. Typically a value of <1ms indicates a local router. The asterisks ( * ) indicate no response from that hop in the network routing.
If the route is broken when it reaches the FortiRecorder, first examine its network interfaces and routes. To display network interface addresses and subnets, enter:
FortiRecorder-200D# show system interface
To display all recently-used routes (the routing table cache) with their priorities, enter:
FortiRecorder-200D# diagnose netlink rtcache list
You may need to verify that there are no misconfigured DNS records, and otherwise rule out problems at the physical, network, and transport layer.
If these tests succeed, a route exists, but you cannot receive video feeds or use FortiRecorder to update the camera’s network settings, an application-layer problem is preventing connectivity.
4. For application-layer problems, on the FortiRecorder, examine the:
• camera network settings (these may have become out-of-sync if you modified them while the camera was disabled)
• certificates (if connecting via HTTPS)
On routers and firewalls between the host and the FortiRecorder appliance, verify that they permit HTTP, HTTPS, and RTP connectivity between them.
Relatedly, if the computer’s DNS query cannot resolve the host name, output similar to the following appears:
example.lab: Name or service not known
Cannot handle "host" cmdline arg `example.lab' on position 1 (argc 1)
See also