Cloud Computing Comparison

Cloud Computing Comparison:

http://www.openqrm.com/userfiles/cloud_computing_compare.xls

Source: www.openqrm.com

Diameter Protocol Load Balancing with F5

diagram source: wikipedia.org

Product used

==========

Product: F5 LTM (version 10.2)

Features used: Diameter Proxy, Diameter Sess-ID AVP Persistence, Diameter Monitor (Built-in EAV healthcheck)

The Setup

========

Diameter clients <-> Diameter Virtual Server (F5) <-> Diameter servers

Typical Diameter Communication

========================

- Most Diameter protocol uses long lived TCP connections, multiple messages per connections (F5 achieve this with MB-LB). Some rare Diameter software implementation do have a limit on the number of TCP connections allowed to be established.

- A TCP handshake is first established between Diameter Client to Diameter VS (client-side). Then F5 will open a server-side connection to the selected Diameter Server. (Yes, F5 will make this load balancing decision)

- Next, Diameter client send CER (CapabilityExchangeReq) to Diameter VS (F5), F5 will decide which Diameter servers to send to (and check if any persistency records found). Selected Diameter server will respond with CEA (CapabilityExchangeAnswer)

- This is then followed by Diameter client sending CCR (CreditControlReq) where Subscriber info are inserted and Diameter server will respond with CCA (CreditControlAnswer). CCR/CCA are mainly used for telco charging.

- Sometimes when no messages are received over a period of time, Diameter clients sends DWR(DeviceWatchdogReq) to detect peer status, Diameter server will respond with DWA (DeviceWatchdogAnswer)

- To disconnect a Diameter connection, Diameter client sends DPR (DisconnectPeerReq) and Diameter server responds with DPA (DisconnectPeeerAnswer). This is then followed by TCP connection teardown.

Diameter Session Persistency

=====================

- F5 has built-in diameter profile that handles Sess-ID persistency along with Universal Persistence, do set a timer value (default: 180 sec) so that it best match with your Diameter application need. See ASKF5 SOL 11653 for Persistence Profile compatibility for Diameter use.

Diameter Monitor

=============

- F5 has a built-in Diameter monitor that sends CEA (and you can customised the AVPs to send) and expect a CER with Result-Code (default: 2001) in order to mark a Diameter server as UP. See ASKF5 SOL 11681 for an overview of Diameter Monitor.

Have fun with Diameter, it is going to be the de-facto protocol for Telco domain for charging applications, while Radius is slowing moving away.

DHCP Load Balancing with F5

I got a chance to write some F5 iRules for an engagement where we have to virtualise (load balance & intelligent route) DHCP traffic.

On a high level, these are what the iRule accomplishes:
1) Route DHCP Requests to DHCP server pool, based on Relay Agent IP
2) Forward DHCP Response back to Relay Agents or DHCP clients
3) Rewrite DHCP payload - mainly "DHCP Option 54" and "Next Server IP" BootP field to DHCP Server IP (Request) and Virtual Server IP (Response)
4) Intelligent detection for HA peer (another F5 unit deployed) in Active-Active setup

It worked well in Production and I think we achieve the customer needs for DHCP scalability.

Ubuntu 9.04 is Cloud-enabled

Source: http://blog.gardeviance.org/2010/03/cloud-computing-made-simple.html

Considerations before moving to the Cloud

1. Determine your cloud objectives.
2. Pick an application that makes sense.
3. Involve the CSO/risk management team from the beginning.
4. Decide which cloud(s) are acceptable.
5. Create a sandbox where people can experiment.

Source: http://www.cloudswitch.com/page/true-isolation-makes-the-public-cloud-work-like-a-private-cloud

WASC Threat Classification v2 is Out!

http://www.cgisecurity.com/2010/01/wasc-threat-classification-v2-is-out.html

Firewall Migration (from Symantec to Fortinet)

Was engaged in doing a Firewall implementation project for a shipping customer. The project involved these preparation:

Pre-migration Preparation (Wed-Thu, 16-17 Dec)
1) Export & Review (current) Symantec Firewall Policies/NAT rules/objects
2) Create Firewall Policies on Fortinet Firewall

Migration Day (Sat-Sun, 2o-21 Dec)
1) Rack up 2 sets Fortinet Firewalls
2) Cables preparation (with Network Engineering team)
3) Initiate Cutover to new Fortinet Firewalls (Active/Passive mode)
4) Configure Fortinet Firewalls to Active/Active mode
5) Perform Firewall policies tests
6) Perform High Availability test (BGP routing test, L2 redundancy test and Firewall HA test)
7) Perform Fortinet Web Filtering test*

Post Migration Follow-Up (21 Dec Monday)
1) On next Business day, follow up with customer on Firewall performance and issues (if any)
2) Only 2 issues reported and 1 resolved on same day. 1 outstanding and customer reviewing their architecture for that issue.

Overall Project Review
================
- Pretty smooth migration on migration day with about 95% objectives achieved
- Issue with network design for 1 x Sonicwall IPSEC firewall (still oustanding)


=============
Project Statistics:
=============
Man-days consumed: 4 Man-days
No. of Fortinet Firewalls implemented: 2 sets
No. of rules migrated: 100+
Customer Satisfaction: Fairly Good