Merge pull request #226724 from brianlehr/newbranch

updated info about idle timeout + added note about routing pref

Author: prmerger-automator[bot]

articles/load-balancer/load-balancer-tcp-reset.md

@@ -48,6 +48,19 @@ The setting works for inbound connections only. To avoid losing the connection,
 
 TCP keep-alive works for scenarios where battery life isn't a constraint. It isn't recommended for mobile applications. Using a TCP keep-alive in a mobile application can drain the device battery faster.
 
+## Order of precedence
+
+It is important to take into account how the idle timeout values set for different IPs could potentially interact.
+
+### Inbound
+
+- If there is an (inbound) load balancer rule with an idle timeout value set differently than the idle timeout of the frontend IP it references, the load balancer idle timeout will take precedence.
+- If there is an inbound NAT rule with an idle timeout value set differently than the idle timeout of the frontend IP it references, the load balancer idle timeout will take precedence.
+
+### Outbound
+
+- If there is an outbound rule with an idle timeout value different than 4 minutes (which is what public IP outbound idle timeout is locked at), the outbound rule idle timeout will take precedence.
+- Because a NAT gateway will always take precedence over load balancer outbound rules (and over public IP addresses assigned directly to VMs), the idle timeout value assigned to the NAT gateway will be used.  (Along the same lines, the locked public IP outbound idle timeouts of 4 minutes of any IPs assigned to the NAT GW are not considered.) 
 
 ## Limitations
 

articles/virtual-network/ip-services/configure-public-ip-load-balancer.md

@@ -158,9 +158,7 @@ In this section, you'll change the frontend configuration used for outbound conn
 
 * By default, a public load balancer won't allow you to use multiple load-balancing rules with the same backend port. If a multiple rule configuration to the same backend port is required, then enable the floating IP option for a load-balancing rule. This setting overwrites the destination IP address of the traffic sent to the backend pool. Without floating IP enabled, the destination will be the backend pool private IP. With floating IP enabled, the destination IP will be the load balancer frontend public IP. The backend instance must have this public IP configured in its network configuration to correctly receive this traffic. A loopback interface with the frontend IP address must be configured in the instance. For more information, see [Azure Load Balancer Floating IP configuration](../../load-balancer/load-balancer-floating-ip.md).
 
-* With a load balancer setup, members of backend pool can often also be assigned instance-level public IPs. With this architecture, sending traffic directly to these IPs bypasses the load balancer. 
-
-* Both standard public load balancers and public IP addresses can have a TCP timeout value assigned for how long to keep a connection open before hearing keepalives. If a public IP is assigned as a load balancer frontend, the timeout value on the IP takes precedence. This setting applies only to inbound connections to the load balancer. For more information, see [Load Balancer TCP Reset and Idle Timeout](../../load-balancer/load-balancer-tcp-reset.md).
+* With a load balancer setup, members of backend pool can often also be assigned instance-level public IPs. With this architecture, sending traffic directly to these IPs bypasses the load balancer.
 
 ## Caveats
 

articles/virtual-network/ip-services/routing-preference-overview.md

@@ -27,8 +27,7 @@ When you route your traffic via the *Microsoft global network*, traffic is deliv
 
 **Egress traffic:** The egress traffic follows the same principle. Traffic travels majority of its journey on Microsoft global network and exits closest to the user. For example, if traffic from Azure Chicago is destined to a user from Singapore, then traffic travels on Microsoft network from Chicago to Singapore, and exits the Microsoft network in Singapore Edge POP.
 
-Both ingress and egress traffic stays bulk of the travel on the Microsoft global network. This is also known as *cold potato routing*.
-
+Both ingress and egress traffic stays on the Microsoft global network whenever possible. This is also known as *cold potato routing*.
 
 ## Routing over public Internet (ISP network)
 
@@ -40,6 +39,10 @@ The new routing choice *Internet routing* minimizes travel on the Microsoft glob
 
 **Egress traffic:** The egress traffic follows the same principle. Traffic exits Microsoft network in the same region that the service is hosted. For example, if traffic from your service in Azure Chicago is destined to a user from Singapore, then traffic exits the Microsoft network in Chicago and travels over the public internet to the user in Singapore.
 
+> [!NOTE]
+> Even when using a Public IP with Routing Preference "Internet", all traffic that is bound for a destination within Azure continues to use the direct path within the Microsoft Wide Area Network.
+>
+
 ## Supported services
 
 Public IP with Routing preference choice “Microsoft Global Network” can be associated with any Azure services. However, Public IP with Routing preference choice **Internet** can be associated with the following Azure resources: