Table of Contents
Advertisement
IPSec
When you issue the show ip forwarding-table command for a particular slot, it
is normal and appropriate behavior when the Status field indicates Valid while
the Load Errors field is increasing daily for that VR. The Load Errors field
records any failed routing table distribution attempt as an error. Attempts can
fail for many reasons during normal operation; a failed attempt does not
necessarily indicate a problem. It is normal to see many load errors per day. If
the Status field indicates Invalid, then the routing table distribution has failed
constantly for that VR and a real problem exists. You might occasionally see a
status of Updating. However, if the Status field always indicates Updating, then
again the routing table distribution has failed constantly for that VR, and a real
problem exists.
The enhancement to the CLI to support unnumbered reference to any kind of
interface rather than just loopback interfaces has consequences such as the
following: [Defect ID 47743]
If the references to shared interfaces appear in the show configuration
output before the configuration for the interfaces they refer to, trying to
restore such a configuration with a script generated from show
configuration generates errors like the following:
% Error, line 3929:
host1(config-if)#ip share-interface FastEthernet 3/0.2
% No such interface
Unnumbered interfaces that refer to nonloopback interfaces (for example,
ip unnumbered fastEthernet 3/0.2) and that appear in the show
configuration output before the interface referred to might generate
similar no such interface errors.
Work-around: Run the script twice.
When you shut down the only outgoing IP interface to the IP destinations of
IPSec tunnels, the tunnels remain in the up state rather than transitioning to
down. As a consequence, all IP routes that use these tunnels as next hops also
remain in the routing table. You can use dead keepalive detection (DPD) to
avoid this situation. DPD must be active, which requires both IPSec tunnel
endpoints to support DPD.
During a warm restart after a system failover, the SRP module can take several
minutes to resume the normal exchange of UDP/IP packets to applications.
During this restart time, the E Series router does not send or receive dead peer
detection (DPD) keepalives, which are used to verify connectivity between the
router and its peers. The length of the restart time depends on the number of
interfaces—if the restart time is too long, remote peers might determine that
the connection from them to the E Series router is broken and then shut down
an IPSec tunnel that has DPD enabled. In the worst case, all IPSec tunnels
might be shut down. [Defect ID 65132]
Release 10.0.3
23
Known Behavior
Advertisement
Table of Contents
