Contents

1   Introduction

This document is the Operating Instruction (OPI) for alarm eVIP, Gateway Unavailable.

1.1   Prerequisites

This section describes the possible documents, tools, and conditions needed before performing the steps described in Section 3 Procedure.

1.1.1   Documents

Before starting this procedure, ensure that the following document have been read:

• eVIP Management Guide
• eVIP Internetworking

2   Alarm Description

The alarm is issued when contact is lost with an external gateway.

The possible causes are as follows:

• The external gateway is faulty.
• The connection between the external gateway and the cluster is faulty.
• The node in the cluster that is connected to the external gateway is faulty.
• The external gateway is not used for packet forwarding, because there is a path through an other external gateway with lower cost.
• The configuration is bad.

The routing software supervises the connection between the external gateway and the connected node in the cluster. The way of supervising is dependent on the configuration, for example, on which routing protocol that is used.

There are at least two external gateways configured for redundancy on each Abstract Load Balancer (ALB). If one of these becomes unavailable, the redundancy is lost but the traffic uses the remaining gateway. If contact is lost to all external gateways for an ALB, all traffic is lost.

2.1   Alarm Attributes

This alarm is compliant with Ericsson SNMP Fault Management MIB, which conforms to X.733 alarm reporting function. However, the following X.733 parameters are not supported; Correlated Notifications, Additional Info, Monitored Attributes, Proposed Repair Action, Trend Indication, Threshold Information, Backed Up Object, and State Change Definition.

The most essential statical attributes of this alarm and their values are listed in Table 1:

The Alarm Type of the alarm is identified by the two integers: majorType and minorType. The Alarm Type is unique within the system type and maps to the X.733 Managed Object Instance. The eventType, probableCause, and specificProblem are always the same for a given Alarm Type.

3   Procedure

To clear the alarm, the connection between the external gateway and the node in the cluster must be restored.

If the alarm is issued on installation or after a change in the configuration, it is likely that the problem is caused by a bad configuration.

The Managed Object pointed out by its Distinguished Name (DN) in the alarm, which is an object of the EvipSupervisedGateway class. This object has a description attribute, which is defined by the installer or by the operator. This attribute can contain site-specific information about the gateway, for example, the location and the person to contact.

3.1   L3 Connectivity

This section describes the procedure to L3 connectivity.

3.1.1   Collect Information for L3 Connectivity

The supervised gateway address is present as part of the source attribute of the alarm, see Example 1.

>show ManagedElement=1,SystemFunctions=1,Fm=1,FmAlarm=6,source
   source="ManagedElement=1,Transport=1,Evip=1,EvipAlbs=1,EvipAlb=alb_1,EvipFees=1,EvipFee=fee_3,
EvipSupervisedRemoteGateway=192.168.77.99"

The DN of the eVIP Front-End Element (FEE) reporting the problem, and it is the part of attribute source up until EvipSupervisedRemoteGateway, see Example 2.

>show ManagedElement=1,SystemFunctions=1,Fm=1,FmAlarm=6,source
   source="ManagedElement=1,Transport=1,Evip=1,EvipAlbs=1,EvipAlb=alb_1,EvipFees=1,EvipFee=fee_3,
EvipSupervisedRemoteGateway=192.168.77.99"

The physical blade and external interface, that the eVIP FEE is using, can be obtained from the eVIP Managed Object Model, see Example 3.

>show ManagedElement=1,Transport=1,Evip=1,EvipAlbs=1,EvipAlb=alb_1,EvipFees=1,EvipFee=fee_3,node
node="8"
>show ManagedElement=1,Transport=1,Evip=1,EvipAlbs=1,EvipAlb=alb_1,EvipFees=1,EvipFee=fee_3,
externalInterface
externalInterface="eth3"

The external IP address of the eVIP FEE can be obtained from the eVIP MOM, see Example 4.

>show all ManagedElement=1,Transport=1,Evip=1,EvipAlbs=1,EvipAlb=alb_1,EvipFees=1,EvipFee=fee_3,
EvipRoutingSetup=ospfv2,EvipParam=local_address
EvipParam=local_address
   value="192.168.14.10/30"

3.1.2   Check L3 Connectivity

Establish that there is L3 connectivity between the eVIP FEE and the external gateway router.

This can be done by using ICMP echo-reply (ping), as follows:

• Try to ping the address of the external gateway routers (the supervised gateway address) from another device (if available) in the same LAN.
• Try to ping the external address of the eVIP FEE from another device (if available) in the same LAN.
• Try to ping the external address of the eVIP FEE from the external gateway router (using the supervised gateway address as a source).

If there is no L3 connectivity, check the external gateway router and all intermediary network equipment (switches, cables, and so on) between the router and the eVIP FEE.

Also check the state of the physical interface, which is used by the eVIP FEE (if logging on to the blade is possible). See Example 5.

PL-2-8:~ # ifconfig eth3
eth3      Link encap:Ethernet  HWaddr 00:13:5E:E8:EB:A9  
          inet6 addr: fe80::213:5eff:fee8:eba9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:16621 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14613 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1883100 (1.7 Mb)  TX bytes:1306050 (1.2 Mb)
          Memory:fdee0000-fdf00000 

3.2   Configuration

If there is L3 connectivity but the alarm is still not cleared, check the routing setup in the eVIP MOM and also on the external router. Make sure that the IP addresses and the routing protocol settings are correct. For an example of full routing configuration on eVIP side, see Example 6.

>show all ManagedElement=1,Transport=1,Evip=1,EvipAlbs=1,EvipAlb=alb_1,EvipFees=1,EvipFee=fee_3
EvipFee=fee_3
   externalInterface="eth3"
   node="8"
   state="ACTIVE"
   EvipRoutingSetup=bfd_ospfv2
      EvipParam=bfd_interval
         value="300"
      EvipParam=echo
         value="no"
      EvipParam=minrx
         value="300"
      EvipParam=multiplier
         value="3"
   EvipRoutingSetup=ospfv2
      EvipParam=area
         value="10.4.35.1"
      EvipParam=area_type
         value="stub"
      EvipParam=dead_interval
         value="7"
      EvipParam=hello_interval
         value="1"
      EvipParam=local_address
         value="192.168.14.10/30"
      EvipParam=retransmit_interval
         value="5"
      EvipParam=router_id
         value="192.168.14.10"
      EvipParam=router_priority
         value="0"
      EvipParam=spf_delay
         value="500"
      EvipParam=spf_interval
         value="1000"
      EvipParam=transmit_delay
         value="1"
   EvipRoutingSetup=ospfv3
      EvipParam=area
         value="10.4.35.1"
      EvipParam=area_type
         value="stub"
      EvipParam=dead_interval
         value="40"
      EvipParam=hello_interval
         value="10"
      EvipParam=local_address
         value="2dec::101:6:2/112"
      EvipParam=retransmit_interval
         value="5"
      EvipParam=router_id
         value="192.168.14.10"
      EvipParam=router_priority
         value="0"
      EvipParam=spf_delay
         value="500"
      EvipParam=spf_interval
         value="1000"
      EvipParam=transmit_delay
         value="1"
   EvipSupervisedRemoteGateway=192.168.77.99

Determine if the eVIP or external router configuration has been altered compared to a previously known working configuration. Contact the local responsible if needed and troubleshoot of the gateway router.

For recommendations and limitations, refer to Section Interworking Rules, Recommendations, and Limitations in eVIP Internetworking.

3.3   Next Level Support

If the source of the problem is still unknown, contact the next level of support.