1 / 79

APV Technical Training

APV Technical Training. Chapter 12 – Advanced Networking. Advanced Networking. Link Aggregation (Interface Bond) VLAN MNET NAT – IP Pool IP Redundant Enhanced Routing Dynamic Routing QoS/Traffic Shaping Advanced SLB. Link Aggregation.

nola-gilliam
Download Presentation

APV Technical Training

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. APV Technical Training Chapter 12 – Advanced Networking

  2. Advanced Networking • Link Aggregation (Interface Bond) • VLAN • MNET • NAT – IP Pool • IP Redundant • Enhanced Routing • Dynamic Routing • QoS/Traffic Shaping • Advanced SLB

  3. Link Aggregation • Link aggregation is a computer networking term which use multiple network cables/ports in parallel to increase the link throughput beyond single cable or port, and also add redundancy for higher availability. It is specified by IEEE 802.3ad link aggregation protocol • Bonds together two or more ports into a single port to appear as a single, higher-bandwidth logical link • All the bonded interfaces are treated as one “superior” interface • Requirement: • The switch to which APV is connected needs to support link aggression as well • Limitation • Maximum bond interfaces: 3 • Each bond interface can bond up to 6 ports (extended to 10 for TM8.x)

  4. Link Aggression CLI commands for Link Aggression: • bond name <bond interface ID> <bond interface name> This command creates a new bond logical interface with assigned name: • <bond interface ID>: default Interface IDs (bond1, bond2, bond3) for the bond interfaces on Array appliance. • <bond interface name>: a network interface name specified by an alphanumeric string; its default values are bond1, bond2 and bond3. • bond interface <bond interface name> <system interface name> This command allows the users to add a system interface to the specified bond interface: • <bond interface name>: a network interface name specified by an alphanumeric string; its default values are bond1, bond2 and bond3 • <system interface name>: a network interface name specified by an alphanumeric string. inside|outside|dmz|eng|eng1|eng2 are the default interface. The interface can be set by the command “interface name” • no bond interface <bond interface name> < system interface name> Allows the users to remove the system interface from the bond interface. • show bond [bond interface name] Displays all current system bond interfaces’ information. • clear bond [bond interface name] Resets the bond interface’s configurations to default. If no bond interface name is specified, all the bond interfaces’ configurations are removed.

  5. Link Aggression: Example • The following examples show how to bond two ports together. • AN(config)#bond name bond1 link1 /*create a bond name*/ • AN(config)#interface name port1 outside1 /*assign interface names*/ • AN(config)#interface name port2 outside2 • AN(config)#bond interface link1 outside1 /*add interfaces into a bond*/ • AN(config)#bond interface link1 outside2 • AN(config)#show interface • bond(bond1): flags=8843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1500 • ether 00:30:48:86:97:3c • Bond Interface: outside(ACT) • webwall status: OFF • packet drop(output error): 0 • packet drop(not permit): 0 • tcp 0 udp 0 icmp 0 • packet drop(deny): 0 • tcp 0 udp 0 icmp 0

  6. Link aggregation Q & A • What is the MAC address of a bond interface and when will it be changed? • The bond MAC address relies on the order how the included physical interfaces are added • Bond interface link1’s MAC address will be outside1’s MAC in the following example: • AN(config)#bond interface link1 outside1 /*add interfaces into a bond*/ • AN(config)#bond interface link1 outside2 • Bond interface link1’s MAC address will be outside2’s MAC in the following example: • AN(config)#bond interface link1 outside2 /*add interfaces into a bond*/ • AN(config)#bond interface link1 outside1 • Once an included NIC’s (say, NIC1) MAC is assigned to a bond interface, the bond’s MAC will only move to another NIC’s MAC when NIC1 is taken out from the bond interface by configuration. The bond’s MAC will not be changed if NIC1’s status is DOWN.

  7. Virtual Interface - VLAN • Array ADC Appliance supports multiple VLANs on the same physical interface (include BOND interface). • Once VLAN is assigned to an interface; all packets are VLAN traffics. • Up to 1024 VLANs can be support on a unit • Configuration example: • To assign VLAN 103 and 104 to the “outside” interface

  8. MNET • Array ADC Appliance supports multiple networks (MNET) segments assigned to the same physical interface (include BOND interface). • MNET is useful for customer with more network segments than physical ports and without VLAN switch • Configuration Example: • Assign multiple MNET “out1” and “out2” onto interface “outside”

  9. NAT – IP Pool Supprt • Overview (Start with TM 8.2) An IP pool contains multiple IP addresses from one IP segment. APV appliance supports at most 32 IP pools, with at most 256 IP addresses per IP pool. Administrators can use the pre-defined IP pools for NAT and SLB configurations. • NAT module IP Pool Multiple IPs can be used to support greater than 64,000 outgoing concurrent connections while also speeding up connection lookups when processing millions of connections. • SLB module with SLB Reverse Proxy Mode IP Pools Multiple IPs can be used for connecting backend real services to remove single IP 64,000 connection limitation and speed up the connection lookup with multiple IP addresses. Furthermore, SLB groups can be assigned different IP Pools providing flexibility to control the proxy IP when connecting to the same SLB real service.

  10. IPpool support (continue) • New CLI Commands (1) • ip pool <pool_name> <start_ip> [end_ip] Create an IP pool and add an IP segment into the IP pool. It can be used to add one or multiple IP segments into an IP pool. no ip pool<pool_name> [start_ip] Remove an IP segment from the specified IP pool. show ip pool [pool_name] Display configurations about specified IP pool, or all IP pools. clear ip pool [pool_name] Remove specified IP pool, or all IP pools. • slb proxyip global <pool_name> Assign a pre-defined IP pool for all SLB real servers as the global IP pool. no slb proxyip global <pool_name> Remove a specified global IP pool. • slb proxyip group <group_name> <pool_name> Assign a pre-defined IP pool for a specified SLB group. Note: The priority of group IP pools is higher than global IP pools. no slb proxyip group <group_name> <pool_name> Remove a specified IP pool for an SLB group.

  11. IPpool support (continue) • New CLI Commands (2) • show slb proxyip [group_name] Display the IP pool configurations of a specified SLB group, or all SLB groups. • clear slb proxyip [group_name] Clear the IP pool configurations of a specified SLB group, or all SLB groups. • show statistics slb proxyip [group_name] Display the IP pool statistics of a specified SLB group, or all SLB groups. • clear statistics slb proxyip [group_name] Clear IP pool statistics of a specified SLB group, or all SLB groups. • Modified CLI Commands • nat port {pool_name|vip} <network_ip> <netmask> [timeout] [gateway] Enable network address translation (NAT) along with port translation. NAT converts the address of each server or device on the inside network into an IP address or IP addresses in the pre-defined IP pool for the Internet, and vice versa. • no nat port {pool_name|vip} <network_ip> <netmask> Remove the specified virtual IP address or IP pool from the NAT configuration.

  12. IPpool support (continue) • Usage Notes • Each IP pool should be assigned with a unique name in the system. • The IP addresses in one IP pool must belong to the same subnet. • The subnet can be the same between two or more pools. • One IP address can belong to multiple IP pools. • IP segment is composed of continuous IPs, and an IP pool can be composed of multiple IP segments. • IP addresses in an IP pool must be legal. • IP addresses which are not covered by any interface subnet are illegal. • Broadcast IP address is illegal. • IP with hostID 0 is illegal.

  13. IP Redundant • Allow multiple link from APV/TMX to a switch supports Link (Port) Redundancy. • Primary/Backup – Continuous health check the Primary link connectivity, Backup link will only be used when Primary Link went down. • This can be replaced by Link Aggression • Unavailable to TM8.x.

  14. IP Redundant - CLI • ip redundant {on|off} • This command allows the administrator enable/disable the IP redundancy feature. • ip redundant backup <primary_ifname> <backup_ifname> <backup_IP> • Administrators deploy this command to designate the backup interface to be assigned to the specified primary interface and the backup interface will replace the primary interface if the primary interface failed to work well, By this way ,users who are accessing the IP belonged to the primary interface would go on working without knowing anything about the failure of the primary interface.. • primary_ifname – Primary NIC interface name • backup_ifname - The secondary/backup interface name • backup_IP - IP address assigned to the backup interface and it must be in the same subnet with the ip address assigned to the primary interface. This IP address is used as health check source IP.

  15. IP Redundant – CLI (cont.) • no ip redundant backup <primary_ifname> • Removes the designated backup interface from the configuration. • ip redundant healthcheck target <primary_ifname> <IP> • This command allows the administrator to specify the health check on the designated primary interface. • primary_ifname - The interface name defined for the primary interface. • IP - The ip address that may be pinged through primary interface. • no ip redundant healthcheck target <primary_ifname> • Removes the configured health check target. • ip redundant healthcheck interval <interval second> • Configure health check time interval performed on the interface. • ip redundant healthcheck retries <retry_count> • Set the number of retires for the redundancy health check before the interface is designated as up or down. • [show|clear] ip redundant {config|status} • Display or clear the redundancy configuration.

  16. Enhanced Routing • Array ADC Appliance supports enhanced routing (eRoute) for production traffic managed by SpeedCore/SpeedStack. • NOTE: Other traffic is managed by the native OS routing functions. Such as ping to internet from the unit. • eRoute can route traffic based on the source and destination IP/port/protocol to different gateways • eRoute entries has different priorities and integrated with existing OS routings. • Packet routing will be based on the priority of the eRoute entries. • If the gateway is down (LLB HC); the eRoute entry will be skipped. The unit will go next eRoute to find the nexthop • eRoute is best to use with Link Load Balancing feature.

  17. Display Unit Routing information • As eRoute is core routing module in the unit; dynamic routing (direct/IP Flow/RTS, RIP/OSPF), static routing (interface, eRoute, route) and default routing information need be incorporated into a single eRouting table. • The eRouting table need be efficient enough as each outbound routed packet will use it for the next hop. • To display eRoute table information - • show ip eroute

  18. Enhanced Route Priority • Priority is assigned as multiple routing source existed. • DROUTE – Direct Route; for host in the local LAN. • IROUTE – Interface Route; for IP on unit interface (i.e. 127.0.0.1) • RTS – Return to Server; for inbound traffic to track the incoming gateway so that return traffic can use the same gateway • IPFLOW – for outbound traffic that have multiple connections with the same session. Such as FTP. TM 6.x Enhanced Routing Table RTS     highest DROUTE             2001  (direct route; local LAN) IROUTE              2000   (interface route, self) EROUTE                1001-1999 IPFLOW              1000               STATIC ROUTE      100-132  (base on network mask) DYNAMIC ROUTE  100-132 (base on network mask) DEFAULT ROUTE  (multiple for TM 6.x)    TM 8.x Enhanced Routing Table EROUTE-P            2001-2999 (preferred EROUTE) IROUTE, DROUTE 2000 RTS                 1999 EROUTE-N            1001-1999 (normal EROUTE) IPFLOW              1000 STATIC ROUTE     101-132 (base on network mask) DYNAMIC ROUTE      101-132 (base on network mask) LLB LINK ROUTE      2 DEFAULT ROUTE        1

  19. Detailed Packet Routing • eRoute keep detailed packet statistics • RTS/IPFlow routing entries are created dynamically (and timeout). If there is no match (other than default).

  20. Dynamic Routing Dynamic Routing Support • Dynamic Routing is a process in which routers automatically adjust to changes in network topology or traffic. It is more robust than static routing. • Dynamic Routing is especially suitable for today’s large, constantly changing networks. It improves performance by allowing network routers to adjust to changes in the network topology. Router distributes its routing information (by routing protocol) between routers. • ArrayOS will accept routing protocol packets and update its dynamic routing entries accordingly. Supported dynamic routing protocols including RIPv1 (Routing Information Protocol version 1), RIPv2 (Routing Information Protocol version 2) and OSPFv2 (Open Shortest Path First version 2).

  21. Dynamic Routing – RIP CLI • rip {on|off} • Turn on/turn off rip. • rip version [1|2] • Set the rip version, its default is version 2. [1|2]: 1—version1, 2---version2. • [no] rip network <ip_address> <netmask> • Enable/disable RIP interfaces which have address matching with the parameter <ip_address>. . • ospf {on | off} • Enable or disable OSPF. • [no] ospf network <ip_address> <netmask> <area_id> • Enable/disable the OSPF interfaces and define an area ID for those interfaces. • area_id - the identification number (0—4294967296) assigned to the interfaces

  22. Dynamic Routing • Dynamic Routing Example A APV B 172.16.39.67 172.16.31.67 172.16.31.66 172.16.32.66 172.16.32.2 172.16.41.2

  23. Dynamic Routing Dynamic Routing Example • RIP Configurations AN(config)#rip on AN(config)#rip version 2 AN(config)#rip network 172.16.31.0 255.255.255.0 AN(config)#rip network 172.16.32.0 255.255.255.0 • OSPF Configurations AN(config)#ospf on AN(config)#ospf network 172.16.32.0 255.255.255.0 0 AN(config)#ospf network 172.16.31.0 255.255.255.0 0 • Dynamically generated routes AN(config)#show ip route Destination Netmask Gateway RIP routes: Destination Netmask Gateway 172.16.39.0 255.255.255.0 172.16.31.67 OSPF routes: Destination Netmask Gateway 172.16.41.0 255.255.255.0 172.16.32.67

  24. Training Objectives • Understand QoS/Traffic Shaping. • Learn the configuration example of QoS/Traffic Shaping.

  25. APV QoS/Traffic Shaping Introduction • APV QoS/Traffic Shaping is not industry standard based Network Quality of Service (QoS)/Traffic Shaping, such as TOS. • APV QoS/Traffic Shaping can ensure high-quality performance for critical applications. By using APV QoS, network administrators can direct control APV bandwidth resources efficiently and ensure the required Application level of service without reactively expanding or over-provisioning their networks. • APV QoS/Traffic Shaping improve user experience by ensuring that time-sensitive and mission-critical applications (with high priority) have the resources they require, while allowing other applications access to the network.

  26. APV Quality Of Service Steps • Define the interface bandwidth • Interface • Direction (in/out) • Bandwidth (Kb, Mb, Gb) • Define QoS Queues – • Queue Name • Interface • Direction • Bandwidth • Priority • BORROW/UNBORROW • DEFAULT/NONDEFAULT • Define QoS Filter (Packet Classification) • Filter Name • Queue Name • L4 Classification [src/dst IP/mask, port, protocol] or L7 by “Host Name + URI” • Priority

  27. Principle - Queuing mechanism • Queue-based QoS: • Queue is used to buffer up network packets with the same classification. A new packet to be processed will be put at the end of the queue while the packet at the beginning will be processed soon • Tree-like queue structure: • Each queue is bound with a particular network interface and controls either incoming or outgoing network traffic of that interface. • On the top of a tree, a root queue is defined for either incoming or outgoing traffic of a network interface • Under the root queue, there could be multiple sub-queues. Sub-queues can also have their sub-queues • Each queue has the following basic properties: • bandwidth limitation • priority for packet processing and packet dropping

  28. Principle – filter policy • QoS filter • A QoS filter is a policy which associates particular network traffic with a QoS queue • L4 policy • L4 network traffic is specified by 5-tuples: source IP subnet, source port, destination IP subnet, destination port and protocol. By this association, customers can deploy either application-oriented or link-oriented QoS control. Normally, application-oriented filter policies have TCP or UDP ports defined while link-oriented filter policies focus on source or destination IP addresses. • L7 policy • Based on HTTP request URL; control the response data by dynamically inserting a L4 QoS filter rule • (1) (client) --------> (TM) (get the filtered URL from the request)(2)                            (TM) -------> (server)(3)                            (TM) <------- (server)(4) (client) <-------- (TM)  (control the response data here) • The dynamic rule’s 5 tuple is (VIP, VS port, client IP, client port, TCP) • The dynamic rule will be deleted at the time either next request is received or the client connection is closed

  29. Detailed Bandwidth Management • Each interface has its total bandwidth limitation • Bandwidth management is realized by a set of QoS filter policies which bind particular network traffic to pre-defined QoS queues which with its predefined priority and limited bandwidth settings. • For egress; ArrayOS/QoS Scheduler scan each QoS output queues (from top priority) to pick out packets to xmit to device up to the bandwidth specified. Unsent packet will be buffered. • For ingress; ArrayOS classify incoming packet to a QoS input queue. If reach bandwidth; new packets will be dropped. • “BORROW/UNBORROW” strategy is applied to QoS queues in a tree-like structure. When a queue’s “BORROW” flag is tuned on, its bandwidth can be expanded by borrowing from its parent queue if more packets in the queue can be sent.

  30. Function - Priority control • Priority Control is accomplished by QoS queues in different priorities. All packets from different applications or links are firstly classified by QoS filter policies and then distributed to predefined queues enjoying the pre-configured priorities. • If the traffic reached a peak, packets loss will arise when the number of packets waiting for processing exceeds the maximum queuing buffers. Under such circumstance, the packets belonging to the queues with the highest priority will be processed in the first place, while other packets with lower priorities may be dropped. In this way, the mission-critical applications will be assigned with the highest priority, therefore the functionality of the most important transactions is guaranteed.

  31. CLI – QoS interface • Enable QoS/Traffic Shaping on an interface • qos interface <interface_name> [direction] [bandwidth] • This command allows users to enable QoS feature on the specified interface. • <interface_name> The interface name; it may be system interface, vlan/mnet interface or bond interface. • [direction]IN or OUT. The default value is OUT. • [bandwidth] The maximum bit rate for all queues on the interface. The default value is the 1Gb. • qos enable <interface_name> [direction] • This command allows users to enable QoS feature on the specified interface. • qos disable <interface_name> [direction] • This command allows users to disable QoS feature on the specified interface.

  32. CLI – QoS Queue • qos queue root <queue_name> <interface_name> [direction] [bandwidth] [priority] [borrow] [default] To create a QoS root queue on the specified interface. • <queue_name> An assigned name, in the form of a character string, to the queue. • <interface_name> Can be system interface, MNET/VLAN interface or bond interface. • [direction] IN or OUT. The default value is OUT. • [bandwidth] The maximum bit rate for the queue. The default value is 1Gb. • [priority] The range is 0 to 7 (highest). The default value is 1. • [borrow] The queue can borrow bandwidth from the parent. The default value is “noborrow”. • [default] Packets not matched by other queues are assigned to this one. Only one default queue is allowed. The default value is nondefault. • qos queue sub <queue_name> <parent_queue> [bandwidth] [priority] [borrow] [default] • This commands allows users to create a QoS sub-queue based on some parent queue. Compared with the root queue command, this command has a <parent_queue> indicating the upper layer queue

  33. CLI – L4 QoS filter • qos filter <fltr_name> <queue_name> < src_addr> <smask> <sport> <dst_addr> <dmask> <dport> <proto> [priority] • This command specifies a filter to classify packets into a scheduling class. A filter specified determines any statically-defined packet classification rules. • <fltr_name> Add an arbitrary name to the filter for statistics. • <queue_name> Name of a queue to which matching packets are directed. Note: If the assigned name begins with a numeric character, then the string needs to be framed in double quotes. • <src_addr> Dotted IP notation for source subnet (e.g., 10.2.41.0).  0.0.0.0 for ip is a full wildcard. • <smask> The mask of source IP address. Dotted IP notation (e.g., 255.255.255.0).  0.0.0.0 for netmask is a full wildcard. • <sport> Source port. 0 is a wildcard.  Ignored unless protocol is "tcp" or "udp" • <dst_addr> See src_addr above. • <dmask> See smask above. • <dport> See sport above. • <proto> Protocol type.(TCP, UDP, ICMP or any) • [priority] Priority of the filter(1-255), default is 1 (low). In case filter overlap

  34. CLI – L7 QoS filter • qos http url <rule_name> <host_name> <path_keyword> <qos_queue> This command allows users to define the HTTP QoS rules based on URL information. When one http request matches one of the HTTP QoS rules, its response will be managed by the QoS queue which is associated with the HTTP QoS rule. <rule_name> the name of HTTP QoS rule <host_name> the hostname to match <path_keyword> the keyword to match with the path in the request <qos_queue> the QoS queues associated the HTTP QoS rule

  35. QoS/Traffic Shaping limitations • After presenting the key features of QoS mechanism, let us take a look at its Configuration Limitations: Maximum number of queues per scheduler is 255. Maximum number of queues of a unit is 1024. Maximum number of queue priorities is 8. Maximum length of queue name is 31. Maximum number of Filter rules of a unit is 1024. Maximum number of rule priorities is 255. Maximum length of rule name is 31.

  36. Sample (L4 QoS) • /*define QoS interfaces*/ • qos interface outside OUT 5Mb • qos interface outside IN 5Mb • /*define outgoing QoS queues, multiple root queue can be defined */ • qos queue root qr_oall outside OUT 5Mb 3 • qos queue sub qs_ossh qr_oall 2Mb 3 UNBORROW NONDEFAULT • qos queue sub qs_oftp qr_oall 512kb 2 UNBORROW NONDEFAULT • qos queue sub qs_odeflt qr_oall 8kb 3 UNBORROW DEFAULT /*default queue is for all the other packets which can’t hit any defined queues*/ • /*define incoming QoS queues*/ • qos queue root qr_iall outside IN 5Mb 3 • qos queue sub qs_issh qr_iall 2Mb 3 BORROW NONDEFAULT /*???how much can borrow*/ • qos queue sub qs_iftp qr_iall 2Mb 2 BORROW NONDEFAULT • qos queue sub qs_ideflt qr_iall 8kb 3 BORROW DEFAULT • /*define QoS filter rules*/ • qos filter fltr_ftp_o qs_oftp 0.0.0.0 0.0.0.0 0 10.3.54.40 255.255.255.255 0 tcp 2 • qos filter fltr_ftp_i qs_iftp 10.3.54.40 255.255.255.255 0 0.0.0.0 0.0.0.0 0 tcp 2 • qos filter fltr_ssh_o qs_ossh 0.0.0.0 0.0.0.0 22 0.0.0.0 0.0.0.0 0 tcp 3 • qos filter fltr_ssh_i qs_issh 0.0.0.0 0.0.0.0 0 0.0.0.0 0.0.0.0 22 tcp 3 • /*enable commands */ • qos enable outside OUT • qos enable outside IN • show statistics qos

  37. Sample (L7 HTTP QoS) • Configuration: • qos interface "outside" OUT 100Mb • qos enable "outside" OUT • qos queue root "http_queue" "outside" OUT 10Mb 1 UNBORROW NONDEFAULT • qos queue root "default_queue" "outside" OUT 50Mb 1 borrow default /*It is better to add a default queue; otherwise the other packets will be dropped*/ • qos http url "policy1" “www.abc.com" “games" "http_queue" /*The IP of 10.3.91.200 is one VIP on TM*/ • Result: • If you enter http://www.abc.com/new-games-test.exe into the address bar in IE, the HTTP response associated with the request will enter "http_queue" to control the traffic

  38. Sample (WebUI)

  39. Application Example (I) • Purpose: TM as a gateway, uses the QoS functions to ensure high priority for HTTPS, SSH and L7 websites accesses, up to 50Mb bandwidth. • The traffic on either the OUT or the IN direction of the outside interface is grouped into two queues: root queue and sub queue. We set the root queue priority as 2 and the sub queue priority as 5. Then, the traffic in the sub queue will be processed first since its priority is higher than that of the root queue.

  40. Application Example (II) • The following shows configurations about the OUT direction of the outside interface. • qos interface "outside" OUT 100Mb • qos queue root "qr_outsideOUT" "outside" OUT 100Mb 2 UNBORROW DEFAULT • qos queue sub "qs_outsideOUT1" "qr_outsideOUT" 50Mb 5 BORROW NONDEFAULT • qos filter "ft_qs_outsideOUT1_Https443" "qs_outsideOUT1" 0.0.0.0 0.0.0.0 0 0.0.0.0 0.0.0.0 443 any 3 • qos filter "ft_qs_outsideOUT1_SSH22" "qs_outsideOUT1" 0.0.0.0 0.0.0.0 0 0.0.0.0 0.0.0.0 22 any 3 • qos enable "outside" OUT • Note: The packets accessing port 443 and 22 which are filtered by the “filter” policy are grouped into the sub queue qs_outsideOUT, while the packets matching no filter policy are grouped into the default queue. • The following shows configurations about the IN direction of the outside interface. • qos interface "outside" IN 100Mb • qos queue root "qr_outsideIN" "outside" IN 100Mb 2 UNBORROW DEFAULT • qos filter "ft_qr_outsideIN_Http80" "qr_outsideIN" 0.0.0.0 0.0.0.0 80 0.0.0.0 0.0.0.0 0 any 3 • qos queue sub "qs_outsideIN1" "qr_outsideIN" 50Mb 5 BORROW NONDEFAULT • qos filter "ft_qs_outsideIN1_Https443" "qs_outsideIN1" 0.0.0.0 0.0.0.0 443 0.0.0.0 0.0.0.0 0 any 3 • qos filter "ft_qs_outsideIN1_SSH22" "qs_outsideIN1" 0.0.0.0 0.0.0.0 22 0.0.0.0 0.0.0.0 0 any 3 • qos enable "outside" IN

  41. Q & A • Q1. How much can a sub-queue borrow from its parent? • The sub-queue can borrow as much as the parent’s bandwidth. In previous slide (sample - L4 QoS), qs_iftp queue can borrow 5Mb from its parent qr_iall • Q2. For L7 QoS, if two filter rules are matched, which will be used? • The first matched rule will be used. For example, there are two rules: • qos http url "policy1" “www.abc.com" “games" "http_queue“ • qos http url "policy2" “www.abc.com" “3D" "http_queue“ • www.abc.com/3D-games will hit policy2 • www.abc.com/games-3D will hit policy1 • Q3. Does Array APV consider “tos” flag in IP header? • No. Array QoS only follows QoS filters defined in TMX appliances • Q4. What kind of network traffic will Array L4 & L7 QoS feature handle? • Array L4 QoS feature will handle all the network traffic hitting Array appliances, including SLB, NAT, routing and other IP traffic • Array L7 QoS feature only handles TMX HTTP/HTTPs SLB traffic

  42. Advanced Load Balancing Examples

  43. Port Range SLB • Purpose • Port range SLB allows customers to define a virtual service with a range of ports so that ArrayOS will listen for connections on all the ports in range and distribute the requests to a group of real services that can be configured with either a port range or a static port • Port range SLB vs L4/L7 SLB • Relation • There are no special virtual service and real service types for port range SLB. As long as a virtual service is attached with port ranges or real service has 0 port, it will follow port range SLB process. • Virtual service (VS) • Port range VS = (L4/L7 VS) + (Port ranges) • Real service (RS) • Port range RS = (L4/L7 RS) or (0 port L4/L7 RS) • Mapping: • a port range virtual service can be mapped to either an all-port range real service or a single port real service as before. In the latter case, input requests come in from multiple ports but eventually handled by a single port service in the real servers • Scenario • cross-port applications: some session protocols bind multiple connections together, one is the initial connection, others could be generated from dynamic ports • Limitations • Port range real service can’t mix with static port real service in the same group. • Port range real service and port range group can only be associated with port range virtual service. • Port range virtual service can be associated with both port range real service and static port real service. • Overlapped port ranges for the same IP are not allowed. But the static port real service’s port can be duplicated in a port range. When looking up virtual service, the precedence of the static port virtual service is higher. • The health check type of a port range real service can only be “none” or “ICMP” because its port is 0. If other health checks are needed, additional health checks can be used: • Port range SLB doesn’t work for “FTP” type real services and virtual services.

  44. Port Range SLB Examples: • Defines a port range virtual service • SJ-Box1(config)#slb virtual http vhttp0 10.3.14.50 0 /*a VS with port 0*/ • SJ-Box1(config)#slb virtual portrange vhttp0 80 88 /*associate a port range 80~88 with the defined VS*/ • SJ-Box1(config)#slb virtual portrange vhttp0 8000 9000 /*associate another port range 8000~9000 with the defined VS*/ • Defines a port range real service • SJ-Box1(config)#slb real http rhttp0 10.3.14.10 0 1000 none /*defines a all port range real service without any special health check*/

  45. L2 SLB – MAC Based • Purpose • Distribute network traffic from the interface where virtual services are defined (e.g. outside interface) to multiple interfaces where real services are behind (e.g. vlan1 and vlan2 on inside interface) • L2 SLB vs L4 SLB • Virtual service • L4: Virtual IP + Port • L2: IP (internally, the MAC address of the IP will be found and used) • Real service • L4: Real IP + Port • L2: Real server’s MAC address (or Real server’s IP address, internally, the MAC address of the real IP will be found and used) • Packet processing from virtual service side to real service side • L4: Source and destination IP addresses are changed • L2: Source and destination IP addresses are NOT changed • When does a packet match a virtual service • L4: the packet’s destination IP address is the same as the defined SLB virtual IP address and also the port. • L2: packet’s destination IP address is NOT the same as any IP address on the incoming interface. This is because L2 SLB only handles pass-through traffic. • Scenarios • The backend real services don’t have usable IP addresses so that the traffic can’t be balanced according to IP addresses • The backend real services are not the final destination of the incoming traffic • e.g. virus scanners check every packet before forwarding it to the final destination. The final destination here could be an email server or file server)

  46. L2 SLB – MAC Based • Healthcheck • ARP request check • Defined along with real service definition, use real service’s IP address. This is applicable if L2 real service is defined by IP address • ICMP check (e.g. ping) • This is defined by additional health check, ping the final server • Port range • Port ranges can be defined on L2 SLB virtual service for more flexibility. • Purpose • The port ranges are used to define TCP and UDP traffic in the consideration of balancing. • Those not in the defined port ranges will not be balanced, but routed as normal pass-through traffic.

  47. L2 MAC SLB • Limitations • Virtual service and real service must be defined on different physical or virtual interfaces. This is to help identify a data packet hitting a L2 SLB virtual service or coming from a L2 real service. • Each interface can have only one virtual service. This is to help identify the L2 virtual service a data packet belongs to. • One L2 real service can only be associated with one L2 SLB group so that the data packet from a L2 real service can be routed to the determined L2 virtual service • L2 real services by IP address and by MAC address can't be defined on the same interface or included in the same L2 SLB group. • Priority • If a packet to be processed matches L2 SLB setting, L4/L7 SLB setting or NATing at the same time, L2 SLB setting takes the higher precedence. If L2 SLB setting is not matched, the data packet will be passed to other modules

  48. L2 MAC SLB (use case 1) • Virus scanners balance • Clients access web servers, two virus scanners are used for anti-virus purpose • Two virus scanners for load balance and failover • TM is used to balance network traffic between two scanners (please notice, web servers are not real servers) • Analysis • One arm connection: only one TM is going to be used. Virus scanners don’t route traffic as firewalls do in use case 1. They get virus scanning requests from the TM on a side road. • IP packets are between clients and web servers, virus scanners are not the destinations of the packets • Source and destination IP addresses can’t be changed in TMs so L4/L7 SLB is not applicable • L2 SLB is useful by connecting two virus scanners with two different TM interfaces. Input traffic from clients are balanced across multiple output interfaces • Clients, web servers and virus scanners should have the default gateway or some static route gateway configured as one of the TM’ IP addresses so that the traffic can go through the TM. • Equipment • Clients: web clients • Virus scanner servers: L2 SLB real servers • Web servers: final servers • TM: perform L2 server load balance on two virus scanners

  49. L2 MAC SLB (use case 1) • Network Topology

  50. L2 MAC SLB (use case 1) Configuration sample • Define system IP addresses • AN(config)#ip address "outside" 172.16.162.70 255.255.255.0 • AN(config)#ip address "inside" 172.16.163.70 255.255.255.0 • AN(config)#ip address "dmz" 172.16.164.70 255.255.255.0 • AN(config)#ip address "eng" 172.16.167.73 255.255.255.0 • Define L2 virtual services • AN(config)#slb virtual l2ip "v1" 172.16.162.70 /*v1 is used to balance traffic coming from clients*/ • AN(config)#slb virtual l2ip "v2" 172.16.167.73 /*v2 is used to balance traffic coming from web servers*/ • Define L2 real services (defined by either IPs or MACs) • AN(config)#slb real l2ip "r1" 172.16.163.71 3 3 /*scanner 1*/ • AN(config)#slb real l2ip "r2" 172.16.164.71 3 3 /*scanner 2*/ OR • AN(config)#slb real l2mac r1 00:e0:81:03:36:e4 inside /*scanner 1’s MAC*/ • AN(config)#slb real l2mac r2 00:30:48:81:54:9c dmz /*scanner 2’s MAC*/ • Define real service health checks • AN(config)#slb real health r1 172.16.163.71 0 • AN(config)#slb real health r2 172.16.164.71 0 • Above two health checks intend to ping the two virus scanners • Define SLB group and add real servers • AN(config)#slb group method "g1" "rr" "route" • AN(config)#slb group member "g1" "r1" 1 • AN(config)#slb group member "g1" "r2" 1 • Associate L2 virtual services with the same group • AN(config)#slb policy default "v1" "g1" • AN(config)#slb policy default "v2" "g1“

More Related