Topics:
This section covers some common issues found in the SBC SWe in AWS setup, and the actions necessary for verification and troubleshooting.
Please make note of this commonly-experienced issue.
Each HFE+SBC triplet must use a different pkt0 subnet. If you used the same subnet for multiple HFE+SBC triplets, then all SBCs will send packets to the HFE that was created last. This limitation is due to AWS networking architecture.
Action:
Do not re-use the pkt0 subnet to create multiple SBC and HFE instances, create /3, or similar, small subnets for each SBC HFE triplet you need.
Common problems are either the SecurityGroups config. doesn't allow outgoing traffic to the AWS API GW, or the EIP is not attached in eth0(mgt)
on the SBC and HFE.
Action:
/var/log/cloud-init.log
/var/log/sonus/lca/lca.log
Most of the problems reported are due to incorrectly configuring the IAM policy/role, or assiging incorrect name/permission of the S3 bucket for storing the HFE.sh
script.
Action:
HFE and SBC IAM roles/permissions are not identical.
Old HFE.sh
scripts and templates may not work as expected with a new build. You must treat AMI, templates and HFE.sh
scripts as one logical release (build), and use them together.
Action:
HFE.sh
script release versions with each new release (these templates and scripts are bundled in a build's orca/rel
directory). Action:
This is due to an incorrect configuration on the SBC. Outgoing packets are either using private IPs, or are not sent out via pkt0.
The HFE can drop packets only if
Action:
Don't modify the default route. The default route serves all peers without copying peer configuration from the SBC to the HFE.
An HFE networking service restart will cause a change in the default route on the HFE. Thus, the HFE will stop forwarding packets to public UAC/end-points. DO NOT restart the networking service on the HFE. If you want to do a network restart, re-run the HFE.sh
script with a "setup" command line argument.
Possible causes:
Ribbon doesn't maintain the HFE AMI (only the configuration script for HFE). The latest AWS Linux AMI ID is selected while launching HFE from the AWS template. Any change in 'ip addr' or 'ip route' commands may require changes in the HFE.sh
script to configure HFE properly.
Action:
Once the disk is attached, mount the disk using the commands:
vgchange –ay mount /dev/debian/root /mnt # The root of SWe instance is available at /mnt
The following SBC SWe logs are available:
Unmount the disk from the GUI using the following commands:
umount /mnt/var/log/sonus/ umount /mnt vgchange –an
Question | Answer |
---|---|
|
|
A competitor showed us the use of sub-second switchover. Is this possible? | Most probably it is service continuity (using DNS), and all new requests are going to some other SBC. Check what happened to the existing calls during their fail-over demo. |
Can we have HA across multiple AZs? | No. For call continuity we rely on IP address movement, AWS doesn't allow us to move IPs across AZs. This is infrastructure limitation. |
Can we use AWS MAC spoofing? | No. AWS drops all such packets silently. |
Can we use GARP ? | No use of sending GARP, AWS doesn't give access to virtual L2 switch. All the provided networking is L3 |
What do I need to know about Security Groups? | Do not block outgoing traffic because AWS API communication is required by the SBC HA and HFE. Caution
|
Can I change MetaData ? | We can't change MetaData, only UserData can be modified |
What is the purpose of the HFE IPs
The HFE Primary IP handles primary IP traffic, and is also used to:
The HFE Secondary IP handles all SIP EIPs to support call flows.
All secondary IP traffic is directed to the SBC.
Action:
First, enter the below command in HFE to check if the HFE.sh
script is downloaded from S3.
aws s3 cp s3://aws-quickstart/quickstart-ribbon-sbc/scripts/HFE.sh ${HFE_FILE}
If the script is downloaded, but HFE.sh
is failing to run, go to the next step.
Verify the path is correct in HFE logs.
[root@ip-172-31-10-30 log]# bash /var/lib/cloud/instances/i-0d4ab8238b5935f85/user-data.txt download: s3://aws-quickstart/quickstart-ribbon-sbc/scripts/HFE.sh to ../../home/ec2-user/HFE/HFE.sh 2019-08-29 09:32:11 Copied HFE script from S3 bucket. REMOTE_SSH_MACHINE_IP= /var/lib/cloud/instances/i-0d4ab8238b5935f85/user-data.txt: line 18: !timestamp: command not found [root@ip-172-31-10-30 log]# bash /var/lib/cloud/instances/i-0d4ab8238b5935f85/user-data.txt download: s3://aws-quickstart/quickstart-ribbon-sbc/scripts/HFE.sh to ../../home/ec2-user/HFE/HFE.sh 2019-08-29 09:33:20 Copied HFE script from S3 bucket. REMOTE_SSH_MACHINE_IP= [root@ip-172-31-10-30 log]# ls /var/lib/cloud/instances/ i-0d4ab8238b5935f85 [root@ip-172-31-10-30 log]#
The SBC contacts AWS service(s) in the following cases:
Action:
If the SBC fails to contact AWS API(s), check the following:
If your DNS returns the wrong IP, all API communications will fail. Check tshark output to debug it further.
Example:
|
In this example, the SBC is not using the AWS-provided DNS. Someone configured the SBC to use the DNS on 172.31.10.54, and this DNS returns the wrong IP for AWS services (A 13.249.37.5 A 99.86.226.181)
The AWS-provided DNS is x.x.x.2, e.g. 172.31.0.2.
If you are using a VPC-end-point, make sure its IP is routed via mgt0 in the SBC.
VPC-end-points will work only if its IP is in mgt0 subnet or any subnet other than HA0, pkt0 and pkt1 (e.g. 10.54.10.x, 10.54.80.x).
The following configuration will not work:
SBC:
VPC-end-point IP - 10.54.30.10
The DNS will return IP 10.54.30.10 for AWS services, and the SBC's attempt to send out traffic via pkt0 will fail.
Perform the following procedure if the calls are not forwarded to the SBC through the HFE, and running the ip addr
command indicates that the IP addresses are assigned to an interface name.
ip addr
command to identify the interface names that are swapped.Note the link/Ether address associated with the IP address. The following example represents Eth1 and Eth2 are swapped:
[ec2-user@ip-10-1-5-214 ~]$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000 link/ether 02:a4:b2:be:17:22 brd ff:ff:ff:ff:ff:ff inet 10.1.5.214/24 brd 10.1.5.255 scope global dynamic eth0 valid_lft 3540sec preferred_lft 3540sec inet 10.1.5.58/24 brd 10.1.5.255 scope global secondary eth0 valid_lft forever preferred_lft forever inet6 fe80::a4:b2ff:febe:1722/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000 link/ether 02:e2:8b:5e:96:1c brd ff:ff:ff:ff:ff:ff inet 10.1.3.97/24 brd 10.1.3.255 scope global dynamic eth1 valid_lft 3550sec preferred_lft 3550sec inet6 fe80::e2:8bff:fe5e:961c/64 scope link valid_lft forever preferred_lft forever 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000 link/ether 02:31:53:a2:88:d6 brd ff:ff:ff:ff:ff:ff inet 10.1.1.62/24 brd 10.1.1.255 scope global dynamic eth2 valid_lft 3550sec preferred_lft 3550sec inet6 fe80::31:53ff:fea2:88d6/64 scope link valid_lft forever preferred_lft forever
Run the following command to update the associated ifcfg file with the correct Ether address for each incorrect interface:
sudo sed -i 's/^HWADDR=.*/HWADDR=<ether address>/' /etc/sysconfig/network-scripts/ifcfg-eth<interface number>
Example:
sudo sed -i 's/^HWADDR=.*/HWADDR=02:31:53:a2:88:d6/' /etc/sysconfig/network-scripts/ifcfg-eth1 sudo sed -i 's/^HWADDR=.*/HWADDR=02:e2:8b:5e:96:1c/' /etc/sysconfig/network-scripts/ifcfg-eth2
Remove the persistent udev rules: sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
.
Reboot the instance: sudo reboot.
Run the ip addr
command to verify the interfaces are correct.
[ec2-user@ip-10-1-5-214 ~]$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000 link/ether 02:a4:b2:be:17:22 brd ff:ff:ff:ff:ff:ff inet 10.1.5.214/24 brd 10.1.5.255 scope global dynamic eth0 valid_lft 3495sec preferred_lft 3495sec inet 10.1.5.58/24 brd 10.1.5.255 scope global secondary eth0 valid_lft forever preferred_lft forever inet6 fe80::a4:b2ff:febe:1722/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000 link/ether 02:31:53:a2:88:d6 brd ff:ff:ff:ff:ff:ff inet 10.1.1.62/24 brd 10.1.1.255 scope global dynamic eth1 valid_lft 3495sec preferred_lft 3495sec inet6 fe80::31:53ff:fea2:88d6/64 scope link valid_lft forever preferred_lft forever 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000 link/ether 02:e2:8b:5e:96:1c brd ff:ff:ff:ff:ff:ff inet 10.1.3.97/24 brd 10.1.3.255 scope global dynamic eth2 valid_lft 3496sec preferred_lft 3496sec inet6 fe80::e2:8bff:fe5e:961c/64 scope link valid_lft forever preferred_lft forever