kernel: Bug trap in doll_dev: dev:doll, into dev:doll

pRose

i'm seeing the following message in my debug logs.  any idea what this means?

kernel: Bug trap in doll_dev: dev:doll, into dev:doll

Zyxel_Stanley

Hi @pRose  

This is log for VPN debugging log. It is used for tracking if traffic has forwarded into VPN tunnel or not.

Is any symptom happened during this log occurs?

pRose

this message has stopped appearing in the log.

we have a site-to-site IPsec VPN setup.  it has been working flawlessly for 3 years; so i think we set it up properly.

last week, we got reports about various resources timing out across the VPN, so we started troubleshooting.  from outside the networks, we can ping both WAN interfaces with 0% packet loss.  from within 1 side of the network, pinging the gateway of the opposite end, ie going through the tunnel, we would experience anywhere from 0% to 12% packet loss.  the packet loss times would occur during complaints when resources on the network became non-responsive.  

today, we started experiencing 65-70% packet loss making the tunnel all but useless.  we have a USG 110 on one side of the network and a USG 60 on the other.  we replaced the USG 60, as our inclination was that side was the problem side.  the new router demonstrates the same packet loss behavior.

we have been trying all kinds of tests and solutions to no avail, and are open to any suggestions for further troubleshooting.

thanks in advance.

Zyxel_Stanley

Hi @pRose  

You can go to Monitor > VPN Monitor > IPSec to check VPN tunnel uptime and inbound/outbound traffic.

If VPN tunnel status switching between connect/disconnect continually, then we have to check “Log” entries which category is “IKE”.

If VPN tunnel without disconnection, then issue may come from routing or network environment issue.

 

What’s the firmware version is working on your USG110 and USG60?

The latest version is 4.38. You can try to upgrade to latest version and monitor if it is helpful.

pRose

both routers are running the latest version, 4.38.

this is what the status of the VPN looks like:



these is the log entries for IKE:  (anything helpful)

Zyxel_Stanley

Hi @pRose  

Here should be your topology: PC------USG110=====[VPN tunnel]=====USG60

You can have some test steps for check network touring:

(1)   Ping to USG60 LAN interface IP continually from PC

e.g. ping 192.168.60.1

(2)   Access to USG110 by SSH. Ping to USG60 LAN interface address with source IP address of USG110 LAN IP address.

e.g.  ping 192.168.60.1 source 192.168.110.1 forever

 

It can make sure if traffic can route to USG60 in your network continually.

During packet loss, you can check VPN monitor if VPN tunnel disconnection happening. (VPN up time should longer than 10 seconds)

pRose

the tunnel is staying up, but we are still experiencing packet loss.  i have an uptime of 40256 now, with the following packet loss:

--- 192.168.60.1 ping statistics ---

2848 packets transmitted, 2406 received, 15.5197% packet loss, time 2858093ms

rtt min/avg/max/mdev = 38.264/42.777/187.399/6.057 ms

this ping is from the pc connected on the 110 network.

pRose

i have accumulated some stats.  the tunnel is staying up, but the packet loss remains:

	time diff	uptime diff	uptime
06:57:18 AM			39291
07:08:13 AM	654.999999999999	654	39945
07:13:24 AM	310.999999999999	311	40256
08:11:24 AM	3480	3479	43735

spring: # sudo ping -c 500 -f -q 192.168.200.2

PING 192.168.200.2 (192.168.200.2) 56(84) bytes of data.

--- 192.168.200.2 ping statistics ---

500 packets transmitted, 415 received, 17% packet loss, time 8136ms

rtt min/avg/max/mdev = 38.092/39.985/49.312/1.570 ms, pipe 4, ipg/ewma 16.303/39.715 ms

(the .200 network is where the usg60 is).

Zyxel_Stanley

Hi @pRose  

It looks your IP subnet of USG60 has owned 192.168.200.X/24.

Can you change IP address of SSL VPN interface on both of USGs prevent IP overlap?

(e.g 192.168.240.1)

Configuration > VPN > SSL VPN > Global Setting.

If it still not help in your environment, then we may need check your issue by private message.