Ports Used by CloudStack and its entities - Troubleshooting Cloudstack and Xen server issues

CloudStack is an open source cloud computing software for creating, managing, and deploying infrastructure cloud services. It uses existing hypervisors such as KVM, VMware vSphere, and XenServer/XCP for virtualization. 

What is Cloudstack and who uses it ?

It is a revolutionary application stack that allows us to deploy and manage large networks of virtual machines, as a highly available, highly scalable Infrastructure as a Service (IaaS) cloud computing platform. CloudStack is used by a number of service providers to offer public cloud services, and by many companies to provide an on-premises (private) cloud offering, or as part of a hybrid cloud solution.

While working on this fantastic tool, I had encountered many issues & finding out port details and services associated with those ports really helped me a lot to resolve 90% of those issues.

I just though of sharing some of those important port numbers for my viewers so that they can get benefited from my experience.  

Management Server

Following are the Ports which are used by cloudstack in Cloud Management server 

8080: Primary GUI / Authentication API Port 

8096: User/Client to CloudStack Management Server (unauthenticated) 

8787: CloudStack (Tomcat) debug socket 

9090: Cloudstack Management Cluster Interface 

45219: !MX console 

8080: Primary GUI / Authentication API Port 

8096: User/Client to CloudStack Management Server (unauthenticated) 

8787: CloudStack (Tomcat) debug socket 

9090: Cloudstack Management Cluster Interface 45219: AIX console 

SystemVM Agent Communication 

Following ports must be open in cloudstack management server for agent communication 3922: Secure System secure communication port 

8250: SystemVM to Management unsecure communication port 

MySQL

Server Following ports must be open in Mysql server of Cloudstack 

3306: MySQL Server 

Hypervisor 

Following ports must be open in Hypervisors used in Cloudstack 

22/443: XenServer, XAPI 

22: KVM 

443: vCenter 

External Ports 

Other External ports 

53: DNS 

111/2049: NFS communication for Secondary Storage VM 

860/3260: iSCSI communication port for iSCSI software connector 

7080: AWS API server 

Most of the times, restating the services associated with these port numbers would resolve some big issues. It may also help you to develop other kind of apps that would run on Apache cloudstack platform.

Let me know through comment section if you found these information useful!

IP SLA Tracking configuration with Example (Auto Failover)

One company/branch may have two connections to the internet through 2 ISPs. If we want to use one connection as primary and other as backup, we can use IP SLA to monitor the link. It detects the link failure even if the connection between modem and ISP fails. So it helps to switch over to the backup path automatically as soon as the primary path is down.

In case if you want to divert sophisticated traffic like SAP, Mail and some other traffic though ISP 1 and Internet traffic through ISP 2 based on the availability of ISP links, 

We could use IP SLA with tracking object and PBR. Also other ISP will be acting as backup link for the mentioned traffics using normal routing configurations even if the primary ISP link goes down.

For example, I have taken a location which has 2 ISP links.Follow the below steps to achieve our objective.

Configuring IP SLA for ISP 1

Step 1: Creating SLA process

ip sla 13

icmp-echo 1.1.1.1 source-ip 1.1.1.2 (here we monitor ISP 1 link neighbor’s IP)

Note: There are some optional parameters available with IP SLA configuration which can really get more specific information.

Step 2: Scheduling SLA process

ip sla schedule 13 start-time now life forever

Step 3: Create a track object to track the change

track 13 ip sla 13 reachability

Once we have IP SLA up and running the next step is to configure PBR so we can redirect http traffic.
First, we need to use Access-Control Lists to select the traffic we want to redirect. Keep in mind that PBR does not limit the type of ACL that can be used. This means you can use IP named ACLs, standard ACLs, extended ACLs, time-based ACLs and others. In our example we are going to use IP named ACLs:

ip access-list extended TOKYO-TRAFFIC-ISP1

 permit ip 10.179.80.0 0.0.0.255 host 10.2.1.1

 permit ip 10.179.80.0 0.0.0.255 host 10.2.2.3

Now we must create a route-map that will use the above defined ACLs and instruct the router to redirect the traffic to the ISP 1 link:

Step 4: Route map creation

route-map TOKYO-KAND permit 10

 match ip address TOKYO-TRAFFIC-ISP1

 set ip next-hop verify-availability 1.1.1.1 1 track 13

The last command configures the route map to verify the reachability of the tracked object (1.1.1.1). If the tracked object is reachable (IP SLA reports it is reachable), then our policy-based route will redirect the defined traffic to it. If the tracked object is not reachable, (IP SLA reports the host is not reachable - down) then our policy-based route will stop redirecting traffic.

Step 5: Applying the Policy Based Route

We are almost done. The very last step is to enable and identify the route-map to be use for policy routing. This is performed by selecting the router interface for which the policy routing will be enabled, and applying the policy-route:
In our Tokyo location, Fa0/1 is the local lan interface.

interface FastEthernet0/1

ip policy route-map TOKYO-KAND

Now the same process can be followed for ISP 2 link also,

Configuring IP SLA for ISP 2

Step 1: Creating SLA process 

ip sla 14

icmp-echo 2.1.1.1 source-ip 2.1.1.2(here we monitor ISP 2 link neighbor’s IP)

Step2: Scheduling SLA process

ip sla schedule 14 start-time now life forever

Step3: Create a track object to track the change

track 13 ip sla 13 reachability

Allow the needed traffic through an ACL,

ip access-list extended TOKYO-TRAFFIC-ISP2

permit ip 10.179.80.0 0.0.1.255 host 10.2.1.3

permit ip 10.179.80.0 0.0.1.255 host 10.2.1.21

Step 4: Route map creation

route-map TOKYO-KAND permit 20

match ip address TOKYO-TRAFFIC-ISP2

set ip next-hop verify-availability 2.1.1.1 1 track 14

Step 5: Applying the Policy Based Route

interface FastEthernet0/1

ip policy route-map TOKYO-KAND

In the above configurations we could see that MAIL server traffic is forced to travel through ISP 1 link using source and based policy routing, It does not mean that mail server traffic will not flow if ISP 1 link goes down. Since we have standard IP routing ISP 2 link will be acting as secondary as always.

Troubleshooting and Verification commands:

For troubleshooting or to do see the status we can make use of following show commands.

show track 13

show route-map

show ip sla statistics

show ip sla configuration

PBR is used to overwrite the normal routing options. IP SLA and Track objects help us to track the links lively and to do the needed changes without manual intervention.

Hope you got it! Please post your doubts in comment box.. :)