Why is a tunnel in the Up - Idle state?

book

Article ID: 167573

calendar_today

Updated On:

Products

PacketShaper

Issue/Introduction

The Xpress Tunnels Overview page shows a tunnel in the Up - Idle state for a long period of time and no compression is taking place.

Resolution

One possible reason for a tunnel to appear in the Up-Idle state is that hosts may have been discovered on the wrong side of the PacketShaper (for example, Inside instead of Outside).

Hosts that have been learned incorrectly (Inside learned as Outside) do not qualify for compression.

PacketShapers compress traffic between the hosts on the Inside of one PacketShaper to hosts on the Inside of the partner PacketShaper. 

Often in redundant topologies it is possible for hosts to be learned on the wrong side.   Use the hostdb show -i or hostdb show -o commands to list Inside or Outside hosts. If hosts have been learned on the wrong side, it will be necessary to configure the hostdb statically and change the default learning preference.

This configuration will define the inside hosts or subnets and change the default learning preference from Inside to Outside. The logic behind this configuration is that with a static list of the Inside hosts/subnets any new host not in the inside list belongs on the outside.

1.  Change hostdb learning from auto to manual:
     hostdb side manual

2.  Define an Inside host list to add the inside hosts/subnets to:
     hl new Inside
   
3.  Add Inside hosts/subnets to the Inside host list. (Individual IP's, ranges of IP's, or subnets can be entered ):
    hl add inside 10.0.1.0 255.255.255.0
    hl add inside 10.0.2.1-10.0.2.64

   
4.  Define the Inside list as being Inside:
     hostdb side set inside list:Inside_hosts

5.  Clear the side settings of all hosts in order to remove any incorrect side associations. (This will not affect hosts/subnets in static list configured in step 3.)
    hostdb side reset all
   
6.  Change the default learning preference from Inside to Outside.
    sys set hostdbSidePrefer 2
   
In topologies where hostdb learning needs to be set to manual it is also going to require that Inside tunnel hosts are configured statically. This is done by adding the same hosts/subnets defined in the static Inside list as tunnel local hosts.  The tunnel local add command accepts IP addresses, ranges of IP's, or subnets.  Host lists can also be used. Examples:

1.  tunnel local add main list:Inside
     tunnel local add main 10.0.2.1-10.0.2.65
     tunnel local add main 10.0.1.0 255.255.255.0

   
2.  If tunnel discovery is enabled it will be necessary to disable tunnel local learning.  If global tunnel discover is disabled and static tunnels are in use, this step is not required.
      sys set tnlLocalIpDiscovery 0
   
3.  Flush any incorrectly learned tunnel local hosts:
     tunnel local flush all
        
4.  If there were incorrectly learned tunnel local hosts it is likely that the tunnel partner(s) also has incorrectly learned tunnel remote hosts.
   
5.  To remove incorrectly learned tunnel remote hosts, the tunnel needs to be brought down and up. One could reboot the PacketShaper or if tunnel passwords are configured, temporarily changing the tunnel password and then changing it back to the original password will bounce all the tunnels.
     tunnel password bogus   
     tunnel password packet        
  <--- set tunnel password back to the correct password