Server Iron Hands-on Training

Server Iron L4 Solutions

Server Iron L7 Solutions

Server Iron Security Solutions

Training Session Agenda

Server Iron Security Solutions

Performance

– Better Server Utilization

– Faster Response Times

– Accelerate Performance by

Offloading to Server Iron

Security

– Server Protection for Uptime

– Application Level to Protect

Sensitive Data

– Access Control

Critical IP

Four Key Reasons for Server Iron Layer 4-7

Solutions

Availability

– Maintain Service Even when

Servers Go Down

– Recover Service from

Complete Site Failures

Scalability

Server Iron Basics – Server Farm Operation

All Users Connect to Server Iron ONLY – Using a Virtual IP Address

–

This IP Address is like the *Common* Call Center Number (Toll Free

Number)

Real Servers do Actual Application Processing on a Private IP Subnet

–

Similar to Call Center Operators with their Own Direct Phone # Extension

Server Iron Distributes Connections and Checks Health of Servers

Server Iron

Clients

10.1.1.10

10.1.1.20

10.1.1.30

VIP = 172.16.12.51

GW IP = 10.1.1.1

Default Gateway = Load Balancer IP

IP Network

1

2

3

4

Src. IP Dest. IP Src. Port Dst. Port Server

188.1.1.100 10.1.1.10 100 80 RS1

188.1.1.101 10.1.1.20 250 80 RS2

188.1.1.102 10.1.1.30 495 80 RS3

Session Table

1

2

3

4

Stateful Load Balancing and Session Table

•

All Packets on Same Connection go to

Same Server [Stateful Forwarding]

•

Session Table Maintains Mapping

•

New Connections go to *Best* Server

•

Depends on Load Balancing Action

and Server Load Conditions

1 2 3

ARP: Request ARP: Reply ICMP: Echo Request

ICMP: Echo Reply 4 SYN-ACK RST* 5 6 7 SYN 1 2 3 ARP: Request ARP: Reply ICMP: Echo Request

ICMP: Echo Reply 4

ICMP Unreachable 5

6

UDP Probe

Layer 4 UDP Health Check

Layer 4 TCP Health Check

Server Health Check Basics – Server Iron Sends

Periodic Messages to Real Servers

*some application may log an error message

RST 1 2 3 GET HTTP/1.0 /index.html http://VIP/index.html Server Status 200 OK FIN 4 5

Training Session Agenda

ServerIron L4 Solutions

ServerIron L7 Solutions

ServerIron Security Solutions

ServerIron Security Solutions

Layer 4

Server

Load Balancing

Example Problem

– High Availability and Scalability for Web Servers

Requirements

– Distribute Load to two HTTP Web Servers based on Health Monitoring

Solution

– Server Iron Layer 4 Load Balancing Configuration

Step 1: Define Virtual Server IP and Port on

ServerIron – Call Center Contact #

Define a Virtual IP Address [Layer 3 Contact Information]

> server virtual <name> <IP address>

> Example: server virtual vs1 172.16.12.51

Define a Virtual Port (TCP/UDP) for Application Access

> port <application port #>

> Example: port http [Other Port #s can be Provided as Well]

> Example: port http [Other Port #s can be Provided as Well]

Define the Load Balancing Method

> server predictor <predictor name>

> Example: server predictor round-robin

> Default Predictor is “Least Connections” [Leave it Alone]

Step 2: Define Real Server IP and Port – Call

Center Operator Extensions

Define a Real IP Address [Layer 3 Contact for Real Server]

> server real <name> <IP address>

> Example: server real rs1 10.1.1.10

Define a Real Port (TCP/UDP) for Application Access

> port <application port #>

> port <application port #>

> Example: port 80

Enable Health Check per Real Server

> port <application port #> keepalive

> Example: port http keepalive

Step 3: Bind Virtual and Real Server

Information – Map Call Operator Extensions

Binding Virtual Port to Real Servers/Ports Establishes the Link Between

*Point of Contact* and *Server Resources*

Under Virtual Server Definition, Bind Real Servers and Ports

–

bind http rs1 80 rs2 80

Similar Definition of all Real Servers

Virtual

Port 80

Real Port

80

Port Binding

Virtual IP = 172.16.12.51

Real IP = 10.1.1.10

Virtual Port of Virtual Server

Name of First Real Server

Define Real Server #1 & #2

Enable Periodic Health

Displaying the Configuration will Show:

Displaying the Configuration will Show:

Source-IP is required when VIP and

Real Servers are on Different

Subnets (Hide Real Addresses)

> server source-ip <ip-address>

<mask> <gateway>

> server source-ip 10.1.1.1

255.255.255.0 0.0.0.0

NOT Required with Router Code

because you can Route between

We have a Layer 4 Server Load Balancing

Configuration

module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module ! server source-ip 10.1.1.1 255.255.255.0 0.0.0.0 ! server real rs1 10.1.1.10 port http port http keepalive ! server real rs2 10.1.1.20 port http

Define Virtual Server

Bind Virtual and Real Servers, and Application Ports

Modify Default Load Balancing Method Enable Periodic Health Checks

That’s All Folks!!!

because you can Route between

Subnets

port http port http keepalive ! ! server virtual vs1 172.16.12.51 predictor round-robin port http bind http rs1 http rs2 http ! !

vlan 1 name DEFAULT-VLAN by port !

module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module ! server source-ip 10.1.1.1 255.255.255.0 0.0.0.0 ! server port 80 tcp keepalive 10 2 ! server real rs1 10.1.1.10 port http

port http url “GET /default.html” port http keepalive

Displaying the Configuration will Show:

Displaying the Configuration will Show:

•

Changing Health Check Interval for Real Port

> server port 80

> tcp keepalive <interval> <retries>

> tcp keepalive 10 2

Make it a Little Fancy – Change Health

Checks – Frequency and L7 Web Page

port http keepalive !

server real rs2 10.1.1.20 port http

port http url “GET /default.html” port http keepalive ! ! server virtual vs1 172.16.12.51 predictor round-robin port http bind http rs1 http rs2 http !

vlan 1 name DEFAULT-VLAN by port !

ip address 172.16.12.251 255.255.255.0 ip default-gateway 172.16.12.1

•Add L7 HTTP Health Check under Real Port

> server real rs1 10.1.1.10

What Happens Next when Clients Start

Connecting?

Now the Configuration on ServerIron is Ready for Traffic

– Call Center is Open for Operation

ServerIron Creates Session Table Entries for Each Connection

– Each Entry Uniquely Identifies a Flow and its Server Mappings

– All Packets Matching an Entry Forwarded to Same Real Server

Each TCP Connection Consists of Four Sessions

– Two Each for Forward and Reverse Directions of the Flow

– Two Each for Forward and Reverse Directions of the Flow

Displaying Session Table and Troubleshooting

Server Iron# rconsole 1 1

ServerIron1/1# show session all 0

Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H: sessInHash, N: sessInNextEntry

Index Src-IP Dst-IP S-port D-port Age Next Serv Flags

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

When Real Server is first defined

– L2 (ARP) & L3 (PING) Health Checks are Performed

When Real Servers are Bound to Virtual Server/Port

– L4 Health Checks are Performed (Layer 7 – If Defined)

Subsequent L4/L7 Health Checks Performed if *Keepalive*

Health Checks Detailed

Enabled

– Polling Interval 5 seconds * 3 Re-Tries =

15 seconds to Detect Failure

Layer 7 Health Checks Support for Many Standard

Applications

– http, DNS, FTP, IMAP4, POP3, LDAP, MMS, NNTP, PNM, RADIUS,

RTSP

Server Iron and Server Farm Packet Walk

Through

e2/1

e2/4

IP=192.168.10.2

GW=192.168.10.1

Server Source IP = 10.1.1.1

VIP=172.16.12.51

RS1 IP 10.1.1.10

GW 10.1.1.1

RS2 IP 10.1.1.20

GW 10.1.1.1

192.168.10.2

80

e1

CMAC

172.16.12.51

•

5

DPort

DMAC SMAC SIP DIP

1

_e1

_e2

2 6 5

e2/3

3 4 1

SPort

192.168.10.2

80

e2/1

e2

172.16.12.51

192.168.10.2

80

e2/4

RS2

10.1.1.20

10.1.1.20

80

RS2

e2/4

192.168.10.2

172.16.12.51

80

e2/1

e2

198.168.10.2

172.16.12.51

80

e1

CMAC

198.168.10.2

DMAC SMAC SIP DIP

How to Optimize for Throughput – Direct Server

Return Explained

When Reply Traffic from Server is Large Proportion, Use DSR

– Return Traffic from Server Bypasses Server Iron Switch

Extremely useful for Streaming Media, FTP, E-Mail Applications

ONLY Works

when Server Iron and Real Servers in

Same L2 Domain

module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module ! server port 80 tcp keepalive 10 2 ! server real rs1 10.1.1.10 port http

port http url “GET /default.html” port http keepalive

!

server real rs2 10.1.1.20

Displaying the Configuration will Show:

Displaying the Configuration will Show:

How to Create a DSR Configuration?

Add One Line Under Virtual Server

> server virtual vs1 10.1.1.51

> port http dsr

!

server real rs2 10.1.1.20 port http

port http url “GET /default.html” port http keepalive ! ! server virtual vs1 10.1.1.5110.1.1.51 predictor round-robin port http port http port http dsrdsr bind http rs1 http rs2 http !

vlan 1 name DEFAULT-VLAN by port !

ip address 10.1.1.251 255.255.255.0 ip default-gateway 10.1.1.1

DNS (UDP) Load Balancing Example

module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module ! server source-ip 10.1.1.1 255.255.255.0 0.0.0.0 ! server port dns udp udpkeepalive 10 2 ! server real rs1 10.1.1.10 port dns port

port dnsdns addr_queryaddr_query www.foundrynet.comwww.foundrynet.com

port dns keepalive

Displaying the Configuration will Show:

Displaying the Configuration will Show:

Defining DNS Port and *UDP* Health Profile

> server port dns

> udp keepalive <interval> <retries>

> udp keepalive 10 2

Add L7 DNS Health Check under Real Port

> server real rs1 10.1.1.10

> Port dns addr_query

www.foundrynet.com

> Uses DNS L7 Check Against Above Host Address

port dns keepalive !

server real rs2 10.1.1.20 port dns

port

port dnsdns addr_queryaddr_query www.foundrynet.comwww.foundrynet.com

port dns keepalive ! ! server virtual vs1 172.16.12.51 port dnsdns bind dns rs1 dns rs2 dns !

vlan 1 name DEFAULT-VLAN by port !

Stateless DNS (UDP) Load Balancing Example

Simply Define Virtual Port for

Stateless Load Balancing

No Session Table/Flow Information

Maintained

module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module ! server source-ip 10.1.1.1 255.255.255.0 0.0.0.0 ! server port dns udp keepalive 10 2 ! server real rs1 10.1.1.10 port dns

port dns addr_query www.foundrynet.com port dns keepalive

Displaying the Configuration will Show:

Displaying the Configuration will Show:

Packet By Packet Load Balancing is

Performed

Mostly Useful for Applications that

Exchange Two Packets - One Client

Request and one Server Response

– DNS/RADIUS

port dns keepalive ! server real rs2 10.1.1.20 port dns port

port dnsdns statelessstateless

port dns addr_query www.foundrynet.com port dns keepalive ! ! server virtual vs1 172.16.12.51 port dns bind dns rs1 dns rs2 dns !

vlan 1 name DEFAULT-VLAN by port !

Training Session Agenda

ServerIron L4 Solutions

ServerIron L7 Solutions

ServerIron Security Solutions

ServerIron Security Solutions

Why Layer 4 vs. Layer 7 – Big Differences

Layer 4 Operates on TCP Connection Basis – Just Like a Call Center

Operates on Individual *Call* Basis

– Relies on IP and TCP Headers to Distribute Traffic

•

Similar to Calling into a Call Center Operation and Directly Getting Connected to the

Next Available Operator

– Layer 4 Implementations are the Simplest ServerIron Designs

Layer 7 Operates Based on *User Data* inside Application Message

– Looks inside Application Messages to Decide where Traffic Goes

•

Similar to Dialing into a Call Center and Being Asked by an Automated System to

*Press* a Menu Button Indicating your Need

– Results in *More Intelligent* Traffic Handling

Layer 7 Server Load Balancing

Example Problem

– High Availability and Scalability for Web Servers

While Preventing Content

While Preventing Content

Replication on All Servers

Replication on All Servers

–

– Content

Content Split Between Servers (or Groups of Servers

Split Between Servers (or Groups of Servers))

Requirements

– Distribute Traffic to Groups of Servers Based on Content Requested

– Distribute Traffic to Groups of Servers Based on Content Requested

– Load Balance within the Same Content Group

– All Based on Server and Application Health Monitoring

Solution

– ServerIron Layer 7 Load Balancing Configuration

Back to Call Center Example – They do Layer 7

Content Switching

When we Call Customer Service Call Center, the Automated System Presents a

Menu to Pick

– Call Operators are Grouped by Specialization

– Based on Menu Selection, Call is Directed to Appropriate Group

Layer 7 Switching on Server Iron is Similar – Client Application Must Present

Extra Information Prior to Selecting a Server

– Requests are Directed to Appropriate Group of Servers Based on User Content

– Requests are Directed to Appropriate Group of Servers Based on User Content

– L4 Load Balance Among Servers with Same Content

Text Content (.html)

Image Content (.gif)

Step 1: Identify Incoming Application Data

Pattern & Build Switching Policy

Identify Application Data by defining Content Switching Rule

– Look for Application specific details such

as-•

URL Content, http Method, http Version,

•

http header fields (host, cookie), XML Tags

> csw-rule <rule-name> <rule-type> <rule-details>

> Example: csw-rule r1 url suffix “gif”

> Example: csw-rule r1 url suffix “gif”

Determine Switching Action using Content Switching Policy

– Switching Actions: Forward, Redirect, Rewrite, Persist

> csw-policy <policy-name>

match <rule-name> <policy-action>

> Example: csw-policy pol1

match r1 forward 1

Server Group ID – A Grouping of

Step 2: Bind Layer 7 Switching Policy with

Virtual Server

Apply Intelligent Content Switching Policy to Virtual Server

– Enable L7 switching for an Application Port

> port <port> csw

> Example: port http csw

> Example: port http csw

– Bind Policy

> port <port> csw-policy <policy-name>

> Example: port http csw-policy pol1

Same Policy on Previous Page

Step 3: Define Server Group ID for Like Servers

with Same Content

Use Group ID to club several Servers with Same Content Together

– Call Operators that answers *Financial* queries fall in one group, and the ones

that answer *Technical* queries fall in Another Group

> port <port> group-id <id1> <id2>

> Example: port http group-id 1 1

Specify Group ID, Group ID Range - 0 to 1023

> Example: port http group-id 1 1

module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module ! server source-ip 10.1.1.1 255.255.255.0 0.0.0.0 ! csw

csw--rule r1 rule r1 urlurl suffix "gif"suffix "gif" csw

csw--rule r2 rule r2 urlurl suffix "bin"suffix "bin"

!

csw

csw--policy "pol1"policy "pol1" match "r1" forward 1 match "r1" forward 1 match "r2" forward 2 match "r2" forward 2 default forward 3 default forward 3 ! server real rs3 10.1.1.30 port http port http group port http group--id 3 3id 3 3

port http url “GET /default.html” port http keepalive

!

server virtual vs1 172.16.12.51 port http

port http

port http cswcsw--policy "pol1"policy "pol1" port http port http cswcsw

Define Content

Switching Rule

Define Content

Bind CSW

Policy

You have an Intelligent Layer 7 Content

Switching Configuration

server real rs1 10.1.1.10 port http

port http group

port http group--id 1 1id 1 1

port http url “GET /default.html” port http keepalive ! server real rs2 10.1.1.20 port http port http group port http group--id 2 2id 2 2

port http url “GET /default.html” port http keepalive ! port http port http cswcsw bind http rs1 http rs2 http rs3 http !

vlan 1 name DEFAULT-VLAN by port ! ip address 172.16.12.251 255.255.255.0 ip default-gateway 172.16.12.1

Define Content

Switching Policy

Define Group-ID

URL Redirection Example – Client Request

Sent to Alternate URL Page

!

server virtual vs1 172.16.12.51

port http

port http csw

port http csw--policy "pol1"

policy "pol1"

port http csw

port http csw

Define CSW Rule to

Identify incoming Pattern

Enable Content

Switching & Bind

CSW Policy

module 1 bi-0-port-wsm6-management-module

module 2 bi-jc-16-port-gig-copper-module

!

server source-ip 10.1.1.1 255.255.255.0 0.0.0.0

!

csw

csw--rule "r3"

rule "r3" url

url pattern "www.foundrynet.com"

pattern "www.foundrynet.com"

!

csw

csw--policy "pol1"

policy "pol1"

match r3 redirect * "

match r3 redirect * "www.brocade.com

www.brocade.com""

_{port http csw}

_{port http csw}

bind http rs1 http rs2 http

!

vlan 1 name DEFAULT-VLAN by port

!

ip address 172.16.12.251 255.255.255.0

ip default-gateway 172.16.12.1

Specify Alternate

Redirect URL

It’s that Similar!

It’s that Similar!

match r3 redirect * "

match r3 redirect * "www.brocade.com

www.brocade.com""

!

server real rs1 10.1.1.10

port http

port http url “GET /default.html”

port http keepalive

!

server real rs2 10.1.1.20

port http

port http url “GET /default.html”

port http keepalive

Intelligent Layer 7 Content Switching Guidelines

It’s Packet Switching @ Layer 7

It Certainly has Performance Impact

– About 1/3

rd

_{the Performance of Layer 4 Load Balancing}

–

Use it when Performance Impact is a Non-Issue and Layer 7 Inspection is

–

Use it when Performance Impact is a Non-Issue and Layer 7 Inspection is

Required for Application to Work

Return Traffic MUST Flow through ServerIron

Training Session Agenda

ServerIron L4 Solutions

ServerIron L7 Solutions

ServerIron Security Solutions

ServerIron Security Solutions

SYN Attack Protection using ServerIron

Example Problem

– Web Servers have come under TCP SYN Attacks from Hackers

Requirements

– Thwart SYN Attacks & Continue Servicing Legitimate Users

Solution

– ServerIron SYN Attack Protection Configuration

Step 1: Configure TCP SYN Proxy Feature

Enable TCP SYN Proxy Globally

> Ip tcp syn-proxy <threshold>

> Example: ip tcp syn-proxy 10

(A DoS attack threshold specifies the number of SYNs, without corresponding ACKs)

Enable TCP SYN Proxy on inbound

Clients

Server

Configurable

Threshold

Enable TCP SYN Proxy on inbound

interface

> Ip tcp syn-proxy in

module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module ! server source-ip 10.1.1.1 255.255.255.0 0.0.0.0 ! server real rs1 10.1.1.10 port http port http keepalive ! server real rs2 10.1.1.20 port http port http keepalive !

Displaying the Configuration will Show:

We have a TCP SYN Attack Protection

Configuration

! ! server virtual vs1 172.16.12.51 predictor round-robin port http bind http rs1 http rs2 http !

vlan 1 name DEFAULT-VLAN by port !

ip

ip tcptcp synsyn--proxy 10proxy 10

! ip address 172.16.12.251 255.255.255.0 ip default-gateway 172.16.12.1 ! interface ethernet 2/16 ip

ip tcptcp synsyn--proxy inproxy in

Enable TCP SYN-Proxy

Globally

Preventing Flood Attacks using Transaction

Rate Limiting

Transaction Rate Limiting Limits Number of

Transactions from Users

– Prevents users from monopolizing Server Resources

– If Transaction Count exceeds specified Threshold then the user

would be held down for specified time interval

Step 1: Define Transaction Rate Limiting Policy

& Apply Under Virtual Server

Define the Rate Limiting Policy

> client-trans-rate-limit tcp <trl-name>

trl <subnet> <mask> monitor-interval <time in 100ms> conn-rate

<transaction-threshold> hold-down-time <time interval>

> Example: client-trans-rate-limit tcp trl-1

trl 1.1.1.0/24 monitor-interval 30 conn-rate 100

hold-down-time 1

Associate Policy with Virtual Server

> client-trans-rate-limit <trl policy name>

> Example: client-trans-rate-limit trl-1

module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module ! server source-ip 10.1.1.1 255.255.255.0 0.0.0.0 ! client

client--transtrans--raterate--limit limit tcptcp trltrl--11 trl

trl 1.1.1.0/24 monitor1.1.1.0/24 monitor--interval 30 interval 30 connconn--rate 100 holdrate 100 hold--downdown--time 1time 1

!

server real rs1 10.1.1.10 port http

port http keepalive

TRL Policy Definition

Displaying the Configuration will Show:

TRL Can be Applied Also

Under an Interface, But this

Example only Shows for VIP

We have Transaction Rate Limit Configuration

port http port http keepalive ! server real rs2 10.1.1.20 port http port http keepalive ! server virtual vs1 172.16.12.51 client

client--transtrans--raterate--limit trllimit trl--11

port http

bind http rs1 http rs2 http !

vlan 1 name DEFAULT-VLAN by port !

ip address 172.16.12.251 255.255.255.0 ip default-gateway 172.16.12.1

!

TRL Policy Definition

Maximum Connections Security

Maximum Connection limits the Maximum number of Connections to a Real Server or Real Server Port

> max-conn <threshold>

> Example: max-conn 100000

> Port <port> max-conn <threshold>

> Example: port http max-conn 20000

Define max-conn Limit of 100,000 per Real Server (All Application Ports)

Define max-conn Limit of 100,000 per Real Server (All Application Ports)

> server real rs1 192.168.44.101

max

max--conn

conn 100000

100000

port http

Define max-conn Limit of 5000 per Real Server for HTTP Port

> server real rs1 192.168.44.101

port http

port http max

module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module ! server source-ip 10.1.1.1 255.255.255.0 0.0.0.0 ! server real rs1 10.1.1.10 port http port http max

port http max--connconn 50005000

port http keepalive !

server real rs2 10.1.1.20 port http

Displaying the Configuration will Show:

Maximum Connections to HTTP

Port on Real Server Set to 5,000

Configuring Max-Conn to Protect Servers from

Overload

port http

port http max

port http max--connconn 50005000

port http keepalive ! ! server virtual vs1 172.16.12.51 predictor round-robin port http bind http rs1 http rs2 http ! !

vlan 1 name DEFAULT-VLAN by port !

Training Session Agenda

ServerIron L4 Solutions

ServerIron L7 Solutions

ServerIron Security Solutions

ServerIron Security Solutions

Benefits of High Availability

Session Table get Synchronized between the

two ServerIrons

NO Loss of Service when SI Fails

Second ServerIron Detects Failure and

Services User Flows

Virtual Application

Infrastructure

Web Apps Email

Server Farm

Session Table RS2 80 101 192.1.1.1 188.1.1.100 RS1 80 100 192.1.1.1 188.1.1.100 Server Destination Port Source Port Destination IP Source IP RS2 80 101 192.1.1.1 188.1.1.100 RS1 80 100 192.1.1.1 188.1.1.100 Server Destination Port Source Port Destination IP Source IP

Rapid Failure Detection

Failover is Totally Transparent to User

Device Level Redundancy

Service Protection Against ServerIron Failures

to Provide Even Higher Availability

Financial Apps ERP Apps RS2 80 101 192.1.1.1 188.1.1.100 RS1 80 100 192.1.1.1 188.1.1.100 Server Destination Port Source Port Destination IP Source IP RS2 80 101 192.1.1.1 188.1.1.100 RS1 80 100 192.1.1.1 188.1.1.100 Server Destination Port Source Port Destination IP Source IP

Active-Hot Standby HA Design

Routers

Standby ServerIron

MAC=M5

Active ServerIron

VIP=172.16.12.51

MAC=M4

172.16.12.1

MAC=M1

172.16.12.2

MAC=M2

THE Simplest and Highly Recommended HA Design

Now Let us Build a Configuration for this HA Mode!

L2 Switch

Servers

10.10.10.10

MAC=M6

10.10.10.20

MAC=M7

Step 1: Provide Dedicated Layer 2 Connectivity

between two ServerIrons

Dedicated Layer 2 Link between the two ServerIrons is MUST

Define a separate L2 VLAN on two ServerIrons

> vlan <vlan #> by port

untagged ethe <m/p>

> Example: vlan 999 by port

> Example: vlan 999 by port

untagged ethernet 2/16

Connect the two ServerIrons through this VLAN Port

Step 2: Identify Upstream Router Port(s)

Designate Upstream Router Port(s)

> Server router-ports ethernet <m/p>

> Example: server router-ports ethernet 2/1

Upstream Router Port

ONLY HA Design that keeps track of upstream ‘router’ and downstream ‘server’

ports

> SI with higher number of router + server ports becomes Active

Step 3: Enable BACKUP Functionality

Enable hot-standby BACKUP functionality

> server backup ethernet <m/p> <chassis MAC> vlan-id <vlan #>

> Example: server backup ethernet 2/1 00e0.5201.0c72 vlan-id 999

Dedicated Link Port

Chassis MAC Address

Dedicated VLAN

The Chassis address used in above command

is-> Obtained from ‘show chassis’ command output on one of the ServerIron

> Use the same chassis MAC address for command on other ServerIron

module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module ! server source server source--ipip 10.1.1.1 255.255.255.0 0.0.0.010.1.1.1 255.255.255.0 0.0.0.0 server backup

server backup etheethe 2/16 0012.f233.e400 2/16 0012.f233.e400 vlanvlan--id 999 id 999

!

server router

server router--ports ports ethernetethernet 2/92/9

! server real rs1 10.1.1.10 port http port http keepalive ! server real rs2 10.1.1.20 port http port http keepalive

We have ServerIron Active-Hot Standby High

Availability Configuration

Enable Backup

Functionality

Identify Upstream

Router Interface Port

When Server Iron is Default Gateway

to Real Servers, Don’t forget to

Configure “Source Standby IP” – This

IP Acts as Common Default Gateway

IP Across two Devices

port http port http keepalive ! server virtual vs1 172.16.12.51 predictor round-robin port http bind http rs1 http rs2 http !

vlan 1 name DEFAULT-VLAN by port

no spanning no spanning--treetree

!

vlan

vlan 999 by port999 by port untagged

untagged etheethe 2/162/16 no spanning

no spanning--treetree !!

ip address 172.16.12.251 255.255.255.0 ip default-gateway 172.16.12.1

Define Dedicated VLAN &

Port for Session Sync &

Disable Spanning Tree

ServerIron SYM-Active HA Design

Routers (VRRP 172.16.12.203) L2 Switches Active ServerIron VIP=172.16.12.51 MAC=M5 Active ServerIron VIP=172.16.12.51 MAC=M4 Servers 172.16.12.201 MAC=M1 172.16.12.202 MAC=M2

vlan 100

vlan 200

10.1.1.10 MAC=M6 10.1.1.20 MAC=M7 10.1.1.30 MAC=M8 10.1.1.40 MAC=M9

Gateway IP=10.1.1.1

BOTH ServerIrons are ACTIVE and Process traffic for same VIP

Upstream Routers are Responsible for Distributing Traffic to Both ServerIron Devices on

Same VIP

Step 1: Enable SYM-Active Mode and Set SYM

Priority for Virtual Server

Enable SYM-Active under Virtual Server

> Example: sym-active

Set SYM Priority for Virtual Server

> sym-priority <value>

> Example: sym-priority 200

– Specify different SYM-Priority on two ServerIrons

Step 2: Enable Session Synchronization

Enable Session Table Synchronization for each Application Port

> server port <port #>

session-sync

module 1 bi-0-port-wsm6-management-module

module 2 bi-jc-16-port-gig-copper-module

!

server port http

server port http

session

session--sync

sync

!

server real rs1 10.1.1.10

port http

port http keepalive

!

server real rs2 10.1.1.20

port http

Enable Session

Synchronization

NOTE: NO Layer 3 & VRRP

details are shown in this

Configuration

SYM-Active High Availability Configuration

Design Changes

server real rs2 10.1.1.20

port http

port http keepalive

!

!

server virtual vs1 172.16.12.51

sym

sym--active

active

sym

sym--priority 200

priority 200

predictor round-robin

port http

bind http rs1 http rs2 http

!

!

vlan 1 name DEFAULT-VLAN by port

Enable SYM-Active HA

Active-Hot Standby vs SYM-Active HA

Active-Hot Standby HA

– The Simplest and Highly Recommended HA Design

– Second ServerIron remains idle and does not process any SLB traffic

SYM-Active HA

SYM-Active HA

– Return traffic from Real Server CAN hit any SI on its way back

– You can distribute VIPs (applications) across two ServerIrons by adjusting respective

SYM-Priority

– Dedicated L2 link between two ServerIrons is OPTIONAL

Thank You

Q & A