Load Balancing. Final Network Exam LSNAT. Sommaire. How works a "traditional" NAT? Un article de Le wiki des TPs RSM.

Transcription

1 Load Balancing Un article de Le wiki des TPs RSM. PC Final Network Exam Sommaire 1 LSNAT 1.1 Deployement of LSNAT in a globally unique address space (LS-NAT) 1.2 Operation of LSNAT in conjunction with a private network (LSNAT with NAPT) 1.3 Load Sharing with no topological restraints on servers (LS-NAPT) 1.4 LSNAT in multiple ISPs environment 1.5 LSNAT and FTP flows 2 Load Sharing with OSPF 3 anycast IPv4 address LSNAT This exam is focused on Load balancing mechanisms. First part is related to "RFC 2391 : Load Sharing using IP Network Address Translation (LSNAT)" that was previously distributed. There is no absolute answer, every correctly justified answer is acceptable. LS-NAT can be viewed as a reverse NAT, instead of changing the source address, LS- NAT change the destination address, this can be very usefull to share, for instance, requests on a pool of web servers. How works a "traditional" NAT?

2 On which IPv4 field the modification introduced by LSNAT is applied? Deployement of LSNAT in a globally unique address space (LS-NAT) The border router with LSNAT enabled on WAN link would perform load sharing and address translations for inbound sessions. However, sessions outbound from the hosts in server pool will not be subject to any type of translation, as all nodes have globally unique IP addresses. In the example below, servers S1 ( ), S2( ) and S3( ) form a server pool, confined to a stub domain. LSNAT on the border router is enabled on the WAN link, such that the virtual server address S( ) is mapped to the server pool consisting of hosts S1, S2 and S3. When a client initiates a HTTP session to the virtual server S, the LSNAT router examines the load on hosts in server pool and selects a host, say S1 to service the request. The transparent address and TCP/UDP port translations performed by the LSNAT router become apparent as you follow the down arrow line. IP packets on the return path go through similar address translation. Suppose, we have another client initiating telnet session to the same virtual server S. The LSNAT would determine that host S3 is a better choice to service this session as S1 is busy with a session and redirect the session to S3. The second session redirection path is delineated with colons. The procedure continues for any number of sessions the same way. Notice that this requires no changes to clients or servers. All the configuration and mapping necessary would be limited just to the LSNAT router.

3 \ / Backbone Router WAN Stub domain border {s= , 2745, v {s= , 3200, d= , 80 } v d= , 23 } v : v Border Router with : v LSNAT enabled on : v WAN interface : v : v : v LAN : v :--- {s= , 2745, v :{s= , 3200, d= , 80 } d= , 23 } S1 S2 S / \ / \ / \ Figure 1: Operation of LSNAT in Globally unique address space Operation of LSNAT in conjunction with a private network (LSNAT with NAPT) The NAT configuration is required for translation of outbound sessions. The illustration below will assume NAPT on the outbound and LSNAT on the inbound on WAN link. Say, an organization has a private IP network and a WAN link to backbone router. The private network's stub router is assigned a globally valid address on the WAN link and the remaining nodes in the organization have IP addresses that have only local significance. The border router is NAPT configured on the outbound allowing access to external hosts, using the single registered IP address. In addition, say the organization has servers S1 ( ), S2( ) and S3 ( ) that form a pool to provide inbound access to external clients. This is made possible by enabling LSNAT on the WAN link of the border router, such that virtual server address S( ) is mapped to the server pool consisting of hosts S1, S2 and S3. When an external client initiates a HTTP session to the virtual server S, the LSNAT router examines load on hosts in server pool and selects a host, say S1 to service the request. The transparent address and TCP/UDP port translations performed by the LSNAT router are apparent as you follow the down arrow line. IP packets on the return path go through similar address translation. Suppose, we have another client initiating telnet session to the same address. The LSNAT would determine that host S3 is

4 a better choice to service this session as S1 is busy with a session and redirect the session to S3. The second session redirection path is delineated with colons. The procedure continues for any number of sessions the same way. \ / Backbone Router WAN Stub domain border {s= , 2745, v {s= , 3200, d= , 80 }v :d= , 23 } v : v Border Router with : v LSNAT and NAPT : v enabled on WAN link : v : v : v LAN : v : {s= , 2745, v : {s= , 3200, d= , 80 } d= , 23 } S1 S2 S / \ / \ / \ Figure 2: Operation of LSNAT, in coexistence with NAPT Once again, notice that this requires no changes to clients or servers. The translation is completely transparent to end nodes. Address mapping on the LSNAT performs load sharing and address translations for inbound sessions. Sessions outbound from hosts in server pool are subject to NAPT. Both NAT and LSNAT co-exist with each other in the same router. Load Sharing with no topological restraints on servers (LS-NAPT) In this section, we will illustrate a configuration in which load sharing can be accomplished on a router without enforcing topological limitations on servers. In this configuration, virtual server address will be owned by the router that supports load sharing. I.e., virtual server address will be same as address of one of the interfaces of load share router. We will distinguish this configuration from LSNAT by referring this as "Load Share Network Address Port Translation" (LS-NAPT). Routers that support the LS-NAPT configuration will be termed "LS-NAPT routers", or simply LS-NAPTs. In an LSNAT router, inbound TCP/UDP sessions, represented by the tuple of (client

5 address, client TCP/UDP port, virtual server address, service port) are translated into a tuple of (client address, client TCP/UDP port, selected server address, service port). Translation is carried out on all datagrams pertaining to the same session, in either direction. Whereas, LS-NAPT router would translate the same session into a tuple of (virtual server address, virtual server TCP/UDP port, selected server, service port). Notice that LS-NAPT router translates the client address and TCP/UDP port with the address and TCP/UDP port of virtual server, which is same as the address of one of its interfaces. By doing this, datagrams from clients as well as servers are forced to bear the address of LS- NAPT router as the destination address, thereby guaranteeing that the datagrams would necessarily traverse the LS-NAPT router. As a result, there is no need to require servers to be under topological constraints. Take for example, figure 1. Let us say the router on which load sharing is enabled is not just a border router, but can be any kind of router. Let us also say that the virtual server address S ( ) is same as the address of WAN link and LS-NAPT is enabled on the WAN interface. Figure 3 summarizes the new router configuration. When a client initiates a HTTP session to the virtual server address S (i.e., address of the WAN interface), the LS-NAPT router examines load on hosts in server pool and selects a host, say S1 to service the request. Appropriately, the destination address is translated to be S1 ( ). Further, original client address and TCP/UDP port are replaced with the address and TCP/UDP port of the WAN link. As a result, destination addresses as well as source address and source TCP/UDP port are translated when the packet reaches S1, as can be noticed from the down-arrow path. IP packets on the return path go through similar translation. The second client initiating telnet session to the same virtual server address S is load share directed to S3. This packet once again undergoes LS-NAPT translation, just as with the first client. The data path and translations can be noticed following the colon line. The procedure continues for any number of sessions the same way. The translations made to datagrams in either direction are completely transparent to end nodes.

6 \ / Router WAN {s= , 2745, v {s= , 3200, d= , 80 }v :d= , 23 } v : v A Router with : v LS-NAPT enabled : v on WAN link : v : v : v LAN : v : {s= , 7001, v :{s= ,7002, d= , 80 } d= , 23 } S1 S2 S / \ / \ / \ Figure 3: LS-NAPT configuration on a router As you will notice, datagrams from clients as well as servers are forced to be directed to the router, because they use WAN interface address of router as the destination address in their datagrams. With the assurance that all packets from clients and servers would traverse the router, there is no longer a requirement for servers to be confined to a stub domain and for LSNAT to be enabled only on border router to the stub domain. The LS-NAPT configuration described in this section involves more translations and hence is more complex compared to LSNAT configurations described in the previous sections. While the processing is complex, there are benefits to this configuration. Firstly, it breaks down restraints on server topology. Secondly, it scales with bandwidth expansion for client access. Even if Service providers have one link today for client access, the LS-NAPT configuration allows them to expand to more links in the future guaranteeing the same LS-NAPT load share service on newer links. The configuration is not without its limitations. Server applications (such as telnet) on the router box would have to be disabled for the interface address assigned to be virtual server address. Load sharing would be limited to TCP and UDP applications only. Maximum concurrently allowed sessions would be limited by the maximum allowed TCP/UDP client ports on the same address. Assuming that ports must be set aside as wellknown service ports, that would leave a maximum of 63K TCP client ports and 63K of UDP client ports on the LS-NAPT router to communicate with each load-share server. As a result, LS-NAPT routers will not be able to concurrently support more than a maximum of (63K * count of Load-share servers) TCP sessions and (63K * count of Load-share servers) UDP sessions.

7 In this document, we will call: LS-NAT, the first scenario described (in paragraph 3.1 of the RFC), LSNAT with NAPT, the second scenario (decribed in paragraph 3.2 of the RFC), LS-NAPT, the last scenario (described in paragraph 3.3 of the RFC). Fill the following figure where three requests coming from three different clients arrive on a shared LS-NAPT server => => > > S LSNAT => => > > S => => > >+- S /24 Notation : adresse IPv4 n de port Figure 4: LS-NAPT configuration on a router LSNAT in multiple ISPs environment A network engineer decide to subscribe a connection to two ISPs to improve the server reliability. he installs two LSNAT with an addresses belonging to each ISP as displayed in the following picture.

8 / \ // \\ : : : : : : S1 : : ISP LSNAT : : : : : :... : +--+ : : +-- S2 :... : +--+ : : : : : : : ISP LSNAT : : S3 : : : :... : :... \\ // \ / Figure 5: LSNAT in multiple ISP environment With which LSNAT version this architecture can work? justify your answer. LS-NAT, : LSNAT with NAPT : LS-NAPT :

9 LSNAT and FTP flows The FTP protocol can be used in the following way to transfer a file. When a user (client) wants to transfer a file or visualize the content of a directory, the ftp client program, using the control connection (port number 21), sends a request to the server (for example PORT a,b,c,d,p,p) to open a new data connection. The server opens the connection and sends an acknowledgement message on the control connection. After receiving this acknowledgment message, the client sends the command (for example LIST, Put <file>, GET <file>) on the control connection and receives data on the other connection. For example: Packet 211 Frame Length: 82 Slice Length: 78 ethr: Station F3 ----> B4 32 Type IP ip: TCP > tcp: Port: > FTP PSH ACK seq: ack: win: F C 39 2C C 31 PORT 192,9,200, C 34 2C D 0A 1,4,8... Packet 212 Frame Length: 82 Slice Length: 78 ethr: Station B > F3 Type IP ip: TCP > tcp: Port: FTP -> 1104 PSH ACK seq: ack: win: F F 6D 6D 61 6E PORT command F 6B E 0D 0A okay... Packet 213 Frame Length: 64 Slice Length: 60 ethr: Station F3 ----> B4 32 Type IP ip: TCP > tcp: Port: > FTP PSH ACK seq: ack: win: C D 0A LIST.. Packet 214 Frame Length: 130 Slice Length: 126 ethr: Station B > F3 Type IP ip: TCP > tcp: Port: FTP -> 1104 PSH ACK seq: ack: win: F E 69 6E Opening data F 6E 6E F 6E F connection for F E 2F 6C E 39 2E 32 /bin/ls ( E C ,1107) (0 b E 0D 0A ytes)... Packet 215 Frame Length: 64 Slice Length: 60 ethr: Station B > F3 Type IP ip: TCP > tcp: Port: FTP-DATA -> 1107 SYN seq: ack: 0 win: 4096 Packet 216 Frame Length: 64 Slice Length: 60 ethr: Station F3 ----> B4 32 Type IP ip: TCP > tcp: Port: > FTP-DATA SYN ACK seq: ack: win: 4096 Options Maximum Segment Size Size 1024 End of Option List Packet 217 Frame Length: 64 Slice Length: 60 ethr: Station B > F3 Type IP

10 ethr: Station B > F3 Type IP ip: TCP > tcp: Port: FTP-DATA -> 1107 ACK seq: ack: win: 4096 Packet 218 Frame Length: 64 Slice Length: 60 ethr: Station F3 ----> B4 32 Type IP ip: TCP > tcp: Port: > FTP ACK seq: ack: win: 4096 Packet 219 Frame Length: 570 Slice Length: 566 ethr: Station B > F3 Type IP ip: TCP > tcp: Port: FTP-DATA -> 1107 ACK seq: ack: win: F C D 0A 2D D 72 2D total 86..-rw-r D 72 2D 2D F E 20 -r-- 1 toutain C wheel A 61 6E A Jan 26 15: E D 0A 2D D 72 2D 2D.XXXdef..-rw-r D 2D F E r-- 1 toutain C wheel A E 3 Feb 3 11: C D 0A 2D D 72 Xdefaults..-rw-r Draw the previous exchange on a graph with a different color for every micro-flow. In the following frame which field of the packet 211 will be modified in case of a LS-NAPT? Packet 211 Frame Length: 82 Slice Length: 78 ethr: Station F3 ----> B4 32 Type IP ip: TCP > tcp: Port: > FTP PSH ACK seq: ack: win: F C 39 2C C 31 PORT 192,9,200, C 34 2C D 0A 1,4,8...

11 Is it possible to install several FTP servers and use LSNAT to spread the load? Which versions, if any, of LSNAT work? why? LS-NAT, : LSNAT with NAPT : LS-NAPT : Load Sharing with OSPF Juniper routers, like most routers, can send packets on different exit interfaces, as the following document describes. For the active route, when there are multiple equal-cost paths to the same destination, by default, the JUNOS software chooses in a random fashion one of the next-hop addresses to install into the forwarding table. Whenever the set of next hops for a destination changes in any way, the next-hop address is rechosen, also in a random fashion. You can configure the JUNOS software so that, for the active route, all next-hop addresses for a destination are installed in the forwarding table. This is called per-packet load balancing. You can use load balancing to spread traffic across multiple paths between routers. The behavior of per-packet load balancing function varies, according to the version of the Internet Protocol ASIC in the router.

12 On routers with an Internet Processor I ASIC, when per-packet load balancing is configured, traffic between routers with multiple paths is spread in a random fashion across the available interfaces. The forwarding table balances the traffic headed to a destination, transmitting it in round-robin fashion among the multiple next hops (up to a maximum of 8 equal-cost oad-balanced paths). The traffic is load-balanced on a perpacket basis. On routers with the Internet Processor II ASIC, when per-packet load balancing is configured, traffic between routers with multiple paths is divided into individual traffic flows (up to a maximum of 16 equal-cost load-balanced paths). Packets for each individual flow are kept on a single interface. To recognize individual flows in the transit traffic, the router examines each of the following: Source IP address, Destination IP address Protocol Source port number Destination port number Interface through which the packet entered the router The router recognizes packets that have all of these parameters identical, and it ensures that these packets are sent out through the same interface. This prevents problems that might otherwise occur with packets arriving at their destination out of their original sequence. What modification to the algorithm seen during the course must be applied to share data among different paths? We suppose that our juniper routers use the "Internet Processor I ASIC"

13 what are the consequences of load balancing on telephny flows? fill the gaps in the following picture that describe a TCP connection where segment X is delayed. : What are the consequences of load balancing on a TCP flow? Why Internet Processor II ASIC improve the network performances compared to Internet Processor I ASIC""?

14 Someone in a IETF working group proposes to improve load balancing by sending traffic regarding the cost of the path to reach the prefix. For example, if a first path has a cost of 10 and a second a cost of 20, the router can send twice more packets on the first path. What do you think of this proposal? Can loops be created? anycast IPv4 address Another solution to do load balancing is to use anycast addresses. RFC 1546, published in 1993 coming from IRTF research, describes this proposal, which is an ancestor of the IPv6 anycast addresses. There are a number of situations in networking where a host, application, or user wishes to locate a host which supports a particular service but, if several servers support the service, does not particularly care which server is used. Anycasting is a internetwork service which meets this need. A host transmits a datagram to an anycast address and the internetwork is responsible for providing best effort delivery of the datagram to at least one, and preferably only one, of the servers that accept datagrams for the anycast address. The motivation for anycasting is that it considerably simplifies the task of finding an appropriate server. For example, users, instead of consulting a list of archie servers and choosing the closest server, could simply type: telnet archie.net and be connected to the nearest archie server. DNS resolvers would no longer have to be configured with the IP addresses of their servers, but rather could send a query to a well-known DNS anycast address. Mirrored FTP sites could similarly share a single anycast address, and users could simply FTP to the anycast address to reach the nearest server. Anycast Addresses

15 [...] As an example, consider a situation where a portion of each IP network number can be used for anycasting. I.e., a site, if it desires, could assign a set of its subnet addresses to be anycast addresses. If, as some experts expect, anycast routes are treated just like host routes by the routing protocols, the anycast addresses would not require special advertisement outside the site -- the host routes could be folded in with the net route. [...] The idea is that the Internet might establish that a particular anycast address is the logical address of the DNS server. Then host software could be configured at the manufacturer to always send DNS queries to the DNS anycast address. In other words, anycasting could be used to support autoconfiguration of DNS resolvers. [...] Transmission and Reception of Anycast Datagrams [...] On a shared media network, such as an Ethernet and or Token Ring, it must be possible to transmit an anycast datagram to a server also on the same network without consulting a (possibly non-existent) router. There are at least two ways this can be done. One approach is to ARP for the anycast address. Servers which support the anycast address can reply to the ARP request, and the sending host can transmit to the first server that responds. This approach is reminiscent of the ARP hack (RFC 1027) and like the ARP hack, requires ARP cache timeouts for the anycast addresses be kept small (around 1 minute), so that if an anycast server goes down, hosts will promptly flush the ARP entry and query for other servers supporting the anycast address. We suppose that the following architecture is used, where a designed a prefix associated to the link and b.1, the anycast address associated to FTP servers: Can gratuitous ARP be used during the interface configuration with the anycast address? The RFC proposes to keep a mapping between the

16 anycast address and MAC address in the router ARP table for 1 minute. What are the consequences for FTP connections? The RFC proposes this solution to keep TCP connections: How UDP and TCP Use Anycasting It is important to remember that anycasting is a stateless service. An internetwork has no obligation to deliver two successive packets sent to the same anycast address to the same host. Because UDP is stateless and anycasting is a stateless service, UDP can treat anycast addresses like regular IP addresses. A UDP datagram sent to an anycast address is just like a unicast UDP datagram from the perspective of UDP and its application. A UDP datagram from an anycast address is like a datagram from a unicast address. Furthermore, a datagram from an anycast address to an anycast address can be treated by UDP as just like a unicast datagram (although the application semantics of such a datagram are a bit unclear). TCP's use of anycasting is less straightforward because TCP is stateful. It is hard to envision how one would maintain TCP state with an anycast peer when two successive TCP segments sent to the anycast peer might be delivered to completely different hosts. The solution to this problem is to only permit anycast addresses as the remote address of a TCP SYN segment (without the ACK bit set). A TCP can then initiate a connection to an anycast address. When the SYN-ACK is sent back by the host that received the anycast segment, the initiating TCP should replace the anycast address of its peer, with the address of the host returning the SYN-ACK. (The initiating TCP can recognize the connection for which the SYN-ACK is destined by treating the anycast address as a wildcard address, which matches any incoming SYN-ACK segment with the correct destination port and address and source port, provided the SYN-ACK's full address, including source address, does not match another connection and the sequence numbers in the SYN-ACK are correct.) This approach ensures that a TCP, after receiving the SYN-ACK is always communicating with only one host.

17 What do you think of this proposal? Is it necessary to modify every TCP implementation? Récupérée de « Dernière modification de cette page le 29 novembre 2010 à 18:59.