Server Iron Hands-on Training
Training Session Agenda Server Iron L4 Solutions Server Iron L7 Solutions Server Iron Security Solutions High Availability Server Iron Designs 2
Four Key Reasons for Server Iron Layer 4-7 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 Applications Availability Maintain Service Even when Servers Go Down Recover Service from Complete Site Failures Scalability Keep up with Growing Traffic by Incrementally Adding Servers Spread Servers Geographically 3
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 Real Servers Server Iron 10.1.1.10 Clients IP Network VIP = 172.16.12.51 GW IP = 10.1.1.1 10.1.1.20 10.1.1.30 Default Gateway = Load Balancer IP 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 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 1 2 3 4 Session Table 1 2 3 4 Server Iron 10.1.1.10 Clients IP Network 10.1.1.20 VIP = 172.16.12.51 GW IP = 10.1.1.1 10.1.1.30 Real Servers 1 2 3 4 5
Server Health Check Basics Server Iron Sends Periodic Messages to Real Servers Layer 4 TCP Health Check Layer 4 UDP Health Check 1 2 3 4 5 6 7 ARP: Request ARP: Reply ICMP: Echo Request ICMP: Echo Reply SYN SYN-ACK RST* 1 2 3 4 5 6 ARP: Request ARP: Reply ICMP: Echo Request ICMP: Echo Reply UDP Probe ICMP Unreachable *some application may log an error message HTTP Layer 7 Health Check Request a Web Page 1 2 3 4 5 GET HTTP/1.0 /index.html http://vip/index.html Server Status 200 OK FIN RST 6
Training Session Agenda ServerIron L4 Solutions ServerIron L7 Solutions ServerIron Security Solutions High Availability ServerIron Designs 7
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 Now Let us Build a Configuration for this Scenario 8
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: [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] > Common Predictors: Round Robin, Least Connections, Weighted 9
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 #> > Example: port 80 Enable Health Check per Real Server > port <application port #> keepalive > Example: keepalive > You can Rely on Global Health Checks Profile as Alternative 10
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 Application Port of First Real Server Name of First Real Server Similar Definition of all Real Servers Virtual Port of Virtual Server Virtual IP = 172.16.12.51 Real IP = 10.1.1.10 Virtual Port 80 Real Port 80 Port Binding 11
We have a Layer 4 Server Load Balancing Configuration Displaying the Configuration will Show: 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 keepalive server real rs2 10.1.1.20 keepalive server virtual vs1 172.16.12.51 predictor round-robin 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 That s All Folks Define Real Server #1 & #2 Enable Periodic Health Checks Define Virtual Server Modify Default Load Balancing Method Bind Virtual and Real Servers, and Application Ports 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 Subnets 12
Make it a Little Fancy Change Health Checks Frequency and L7 Web Page Displaying the Configuration will Show: 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 url GET /default.html keepalive server real rs2 10.1.1.20 url GET /default.html keepalive server virtual vs1 172.16.12.51 predictor round-robin 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 Changing Health Check Interval for Real Port > server port 80 > tcp keepalive <interval> <retries> > tcp keepalive 10 2 Add L7 HTTP Health Check under Real Port > server real rs1 10.1.1.10 > Port http url GET/sales.html 13
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 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 ===== ====== ====== ====== ====== === ==== ==== ====== 0 192.168.24.9 10.1.1.10 23 2517 32 000000 n/a OPT1 H 1 192.168.24.9 10.1.1.10 23 2517 60 000000 test SLB1 N 2 192.168.24.158 10.1.1.10 2517 23 32 000000 n/a OPT1 H 3 192.168.24.158 10.1.1.10 2517 23 60 000000 test SLB1 N 14
Health Checks Detailed 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* 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 SMTP, SSL (Simple & Complete), Telnet 15
Server Iron and Server Farm Packet Walk Through IP=192.168.10.2 GW=192.168.10.1 1 e1 e2 1 6 5 Server Source IP = 10.1.1.1 e2/1 VIP=172.16.12.51 DMAC SMAC SIP DIP DPort e1 CMAC 192.168.10.2 172.16.12.51 80 5 2 e2/4 3 e2/3 4 RS1 IP 10.1.1.10 GW 10.1.1.1 RS2 IP 10.1.1.20 GW 10.1.1.1 2 e2/1 e2 192.168.10.2 172.16.12.51 80 3 RS2 e2/4 192.168.10.2 10.1.1.20 80 4 Real Server #2 IP DMAC SMAC SIP DIP SPort e2/4 RS2 10.1.1.20 192.168.10.2 80 VIP 5 e2 e2/1 172.16.12.51 198.168.10.2 80 6 CMAC e1 172.16.12.51 198.168.10.2 80 16
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 Must Configure Loopback Address on Real Servers as the VIP Address 3 10.1.1.10 Loopback = VIP = 10.1.1.51 1 2 10.1.1.20 Loopback = VIP = 10.1.1.51 Server Iron VIP = 10.1.1.51 10.1.1.30 Loopback = VIP = 10.1.1.51 17
How to Create a DSR Configuration? Displaying the Configuration will Show: 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 url GET /default.html keepalive server real rs2 10.1.1.20 url GET /default.html keepalive server virtual vs1 10.1.1.51 predictor round-robin dsr 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 Virtual IP and Real IP in Same L2 Subnet Add One Line Under Virtual Server > server virtual vs1 10.1.1.51 > dsr 18
DNS (UDP) Load Balancing Example Displaying the Configuration will Show: 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 server real rs2 10.1.1.20 port dns 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 ip address 172.16.12.251 255.255.255.0 ip default-gateway 172.16.12.1 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 19
Stateless DNS (UDP) Load Balancing Example Displaying the Configuration will Show: 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 server real rs2 10.1.1.20 port dns port dns stateless 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 ip address 172.16.12.251 255.255.255.0 ip default-gateway 172.16.12.1 Simply Define Virtual Port for Stateless Load Balancing No Session Table/Flow Information Maintained Packet By Packet Load Balancing is Performed Mostly Useful for Applications that Exchange Two Packets - One Client Request and one Server Response DNS/RADIUS 20
Training Session Agenda ServerIron L4 Solutions ServerIron L7 Solutions ServerIron Security Solutions High Availability ServerIron Designs 21
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 Naturally Requires *More* ServerIron Configuration 22
Layer 7 Server Load Balancing Example Problem High Availability and Scalability for Web Servers While Preventing Content Replication on All Servers Content Split Between Servers (or Groups of Servers) Requirements 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 Now Let us Build a Configuration for this Scenario 23
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 L4 Load Balance Among Servers with Same Content IP Hdr TCP Hdr HTTP Hdr URL Prefix Text Content (.html) RS1, GRP-id- 1 Client URL Switch IP Network www.foo.com/*.gif home.foo.com/*.html www.foo.com/*.bin Server Iron CGI (.bin) Image Content (.gif) RS2, GRP-id- 2 RS3, GRP-id- 3 24
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 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 Servers with Same Content; In this case gif files. 25
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: csw Bind Policy > port <port> csw-policy <policy-name> > Example: csw-policy pol1 Same Policy on Previous Page Forwarding GIF files to Server Group 1 26
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: group-id 1 1 Specify Group ID, Group ID Range - 0 to 1023 > Must be Defined under Each Real Server 27
You have an Intelligent Layer 7 Content Switching 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 csw-rule r1 url suffix "gif" csw-rule r2 url suffix "bin" csw-policy "pol1" match "r1" forward 1 match "r2" forward 2 default forward 3 server real rs1 10.1.1.10 group-id 1 1 url GET /default.html keepalive server real rs2 10.1.1.20 group-id 2 2 url GET /default.html keepalive Define Content Switching Rule Define Content Switching Policy Define Group-ID server real rs3 10.1.1.30 group-id 3 3 url GET /default.html keepalive server virtual vs1 172.16.12.51 csw-policy "pol1" csw 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 Cool. My Box is switching @ L7 now Bind CSW Policy 28
URL Redirection Example Client Request Sent to Alternate URL Page 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-rule "r3" url pattern "www.foundrynet.com" csw-policy "pol1" match r3 redirect * "www.brocade.com www.brocade.com" server real rs1 10.1.1.10 url GET /default.html keepalive server real rs2 10.1.1.20 url GET /default.html keepalive Specify Alternate Redirect URL Define CSW Rule to Identify incoming Pattern server virtual vs1 172.16.12.51 csw-policy "pol1" csw It s that Similar bind http rs1 http rs2 http Enable Content Switching & Bind CSW Policy vlan 1 name DEFAULT-VLAN by port ip address 172.16.12.251 255.255.255.0 ip default-gateway 172.16.12.1 29
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 Required for Application to Work Return Traffic MUST Flow through ServerIron NO DSR Possible with Layer 7 30
Training Session Agenda ServerIron L4 Solutions ServerIron L7 Solutions ServerIron Security Solutions High Availability ServerIron Designs 31
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 Now Let us Build a Configuration for this Scenario 32
Step 1: Configure TCP SYN Proxy Feature Enable TCP SYN Proxy Globally Clients Server > 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 interface Configurable Threshold Connection Cleared > Ip tcp syn-proxy in > Example: interface ethernet 2/16 ip tcp syn-proxy in That s It Valid Client 33
We have a TCP SYN Attack Protection Configuration Displaying the Configuration will Show: 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 keepalive server real rs2 10.1.1.20 keepalive server virtual vs1 172.16.12.51 predictor round-robin bind http rs1 http rs2 http vlan 1 name DEFAULT-VLAN by port ip tcp syn-proxy 10 ip address 172.16.12.251 255.255.255.0 ip default-gateway 172.16.12.1 interface ethernet 2/16 ip tcp syn-proxy in Enable TCP SYN-Proxy Globally Enabling SYN Proxy on Inbound Interface 34
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 Let s build the configuration 35
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 DONE 36
We have Transaction Rate Limit Configuration Displaying the Configuration will Show: 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-trans-rate-limit tcp trl-1 trl 1.1.1.0/24 monitor-interval interval 30 conn-rate 100 hold-down-time 1 server real rs1 10.1.1.10 keepalive server real rs2 10.1.1.20 keepalive server virtual vs1 172.16.12.51 client-trans-rate-limit trl-1 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 Applying TRL Policy to VIP TRL Can be Applied Also Under an Interface, But this Example only Shows for VIP TRL Policy Definition 37
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: max-conn 20000 Define max-conn Limit of 100,000 per Real Server (All Application Ports) > server real rs1 192.168.44.101 max-conn 100000 Define max-conn Limit of 5000 per Real Server for HTTP Port > server real rs1 192.168.44.101 max-conn 5000 38
Configuring Max-Conn to Protect Servers from Overload Displaying the Configuration will Show: 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 max-conn 5000 keepalive server real rs2 10.1.1.20 max-conn 5000 keepalive server virtual vs1 172.16.12.51 predictor round-robin 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 Maximum Connections to HTTP Port on Real Server Set to 5,000 39
Training Session Agenda ServerIron L4 Solutions ServerIron L7 Solutions ServerIron Security Solutions High Availability ServerIron Designs 40
Benefits of High Availability Session Table get Synchronized between the two ServerIrons Virtual Application Infrastructure Session Table Server Farm NO Loss of Service when SI Fails Source IP 188.1.1.100 188.1.1.100 Destination IP 192.1.1.1 192.1.1.1 Source Port 100 101 Destination Port 80 80 Server RS1 RS2 Web Apps Second ServerIron Detects Failure and Services User Flows Email Rapid Failure Detection Financial Apps Failover is Totally Transparent to User Device Level Redundancy Service Protection Against ServerIron Failures to Provide Even Higher Availability Source IP Destination IP Source Port Destination Port Server 188.1.1.100 192.1.1.1 100 80 RS1 188.1.1.100 192.1.1.1 101 80 RS2 Synchronized Session Table ERP Apps 41
Active-Hot Standby HA Design 172.16.12.1 MAC=M1 Routers 172.16.12.2 MAC=M2 Active ServerIron VIP=172.16.12.51 MAC=M4 Standby ServerIron MAC=M5 Dedicated Link for SI Communication 10.10.10.10 MAC=M6 L2 Switch Servers 10.10.10.20 MAC=M7 THE Simplest and Highly Recommended HA Design Now Let us Build a Configuration for this HA Mode 42
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 untagged ethernet 2/16 Connect the two ServerIrons through this VLAN Port Disable Spanning Tree on ALL VLANs 43
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 Router and Server Port Availability is Used to Effect Failover to Ensure the *Most Connected* Server Iron is Active and Processing Traffic 44
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 Input of MAC Chassis Address Ensures that Same MAC Address is used for VIP Even After Control Fails Over to the Peer Server Iron Device 45
We have ServerIron Active-Hot Standby High Availability 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 backup ethe 2/16 0012.f233.e400 vlan-id 999 server router-ports ethernet 2/9 server real rs1 10.1.1.10 keepalive server real rs2 10.1.1.20 keepalive server virtual vs1 172.16.12.51 predictor round-robin bind http rs1 http rs2 http vlan 1 name DEFAULT-VLAN by port no spanning-tree vlan 999 by port untagged ethe 2/16 no spanning-tree ip address 172.16.12.251 255.255.255.0 ip default-gateway 172.16.12.1 Enable Backup Functionality Identify Upstream Router Interface Port Disable Spanning Tree for VLAN 1 Define Dedicated VLAN & Port for Session Sync & Disable Spanning Tree 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 46
ServerIron SYM-Active HA Design Routers 172.16.12.201 MAC=M1 (VRRP 172.16.12.203) 172.16.12.202 MAC=M2 vlan 100 vlan 200 Active ServerIron VIP=172.16.12.51 MAC=M4 L2 Switches Active ServerIron VIP=172.16.12.51 MAC=M5 Servers Gateway IP=10.1.1.1 10.1.1.10 MAC=M6 10.1.1.20 MAC=M7 10.1.1.30 MAC=M8 10.1.1.40 MAC=M9 BOTH ServerIrons are ACTIVE and Process traffic for same VIP Upstream Routers are Responsible for Distributing Traffic to Both ServerIron Devices on Same VIP This Design is shown with Router Code on ServerIron & uses VRRP definitions on ServerIron and Upstream Routers 47
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 ServerIron with higher SYM-Priority responds to ARP & ICMP 48
Step 2: Enable Session Synchronization Enable Session Table Synchronization for each Application Port > server port <port #> session-sync > Example: server session-sync 49
SYM-Active High Availability Configuration Design Changes module 1 bi-0-port-wsm6-management-module module 2 bi-jc-16-port-gig-copper-module server Enable Session session-sync sync Synchronization server real rs1 10.1.1.10 keepalive server real rs2 10.1.1.20 keepalive server virtual vs1 172.16.12.51 sym-active sym-priority 200 predictor round-robin bind http rs1 http rs2 http vlan 1 name DEFAULT-VLAN by port Enable SYM-Active HA Set SYM-Priority NOTE: NO Layer 3 & VRRP details are shown in this Configuration 50
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 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 MUST have L2 connectivity through other means though 51
Thank You Q & A