Skip to content

Commit 4df1a52

Browse files
authored
Merge pull request MicrosoftDocs#77277 from KumudD/ghissue31062
Standard Load Balancer update
2 parents 07da2f1 + adb7e9c commit 4df1a52

File tree

1 file changed

+0
-1
lines changed

1 file changed

+0
-1
lines changed

articles/load-balancer/load-balancer-standard-overview.md

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -221,7 +221,6 @@ For Standard Load Balancer pricing information, go to the [Load Balancer pricing
221221
- SKUs are not mutable. You may not change the SKU of an existing resource.
222222
- A standalone virtual machine resource, availability set resource, or virtual machine scale set resource can reference one SKU, never both.
223223
- A Load Balancer rule cannot span two virtual networks. Frontends and their related backend instances must be located in the same virtual network.
224-
- Load Balancer frontends are not accessible across global virtual network peering.
225224
- [Move subscription operations](../azure-resource-manager/resource-group-move-resources.md) are not supported for Standard SKU LB and PIP resources.
226225
- Web Worker Roles without a VNet and other Microsoft platform services can be accessible when only an internal Standard Load Balancer is used due to a side effect from how pre-VNet services and other platform services function. You must not rely on this as the respective service itself or the underlying platform can change without notice. You must always assume you need to create [outbound connectivity](load-balancer-outbound-connections.md) explicitly if desired when using an internal Standard Load Balancer only.
227226
- Load Balancer is a TCP or UDP product for load balancing and port forwarding for these specific IP protocols. Load balancing rules and inbound NAT rules are supported for TCP and UDP and not supported for other IP protocols including ICMP. Load Balancer does not terminate, respond, or otherwise interact with the payload of a UDP or TCP flow. It is not a proxy. Successful validation of connectivity to a front-end must take place in-band with the same protocol used in a load balancing or inbound NAT rule (TCP or UDP) _and_ at least one of your virtual machines must generate a response for a client to see a response from a front-end. Not receiving an in-band response from the Load Balancer front-end indicates no virtual machines were able to respond. It is not possible to interact with a Load Balancer front-end without a virtual machine able to respond. This also applies to outbound connections where [port masquerade SNAT](load-balancer-outbound-connections.md#snat) is only supported for TCP and UDP; any other IP protocols including ICMP will also fail. Assign an instance-level Public IP address to mitigate.

0 commit comments

Comments
 (0)