ip virtual-reassembly exceeded issue

Hi all,

Days ago I was facing an issue concerning a VRRP cluster (using keepalived). Every hour, the backup server was changing its VRRP state to master and two second later (after forced re-election) goes back to the backup state.

The same number of NICs are connected to every server, each NIC is configured in a vrrp_instance. But only one vrrp_instance on the backup server changed its state to master, the others did the same cause they belong to the same vrrp_sync_group.

The NIC changing its state is connected to a Cisco VPN router.

After many days of investigation (looking at if the server is receiving VRRP packets, if there were errors on the packets… if there were dropped packets…) I discovered in the log of the VPN router some messages which warn that virtual-reassembly parameter was exceeded… Heu ???

After searching, I increased this parameter on each interface of the Cisco VPN router :

ip virtual-reassembly max-reassemblies 32


This solves the problem, but until now I don’t know what was the real problem, sniffing didn’t give me too much information to analyse…

Connect to a router’s inside interface

Hi folks,

Two months ago we implemented a DRP network in a branch office. The connection between the main office and the branch one is done with a site-to-site IPSec VPN.

Here is the global schema :

VPN

Everything was ok until I tried to connect to the F0/0 IP of the remote VPN router (VPN-2). Thus, I was unable to get connected.

I checked ACLs, routes, … everything is ok.
Being connected on the VPN-2 (indirectly connected), I tried to telnet back to the 192.168.1.1 machine, then I got a Host unreachable error.

Strange, routes are ok (a default route exists throughout the ISP router)… The error suggests there is no route to the host, so I added an explicit route on VPN-2 indicating the ISP router as the gateway to connect to the 192.168.1.0/24 network.

ip route 192.168.1.0 255.255.255.0 A.B.C.D

As expected, this solved the problem.

After this, I thought why the default route wasn’t been used ?
My suggestion :
192.168.1.0/24 is a RFC1918 network and may be the IOS default route doesn’t hundle these networks.

Your comments are welcome.