Azure - revision history

Dank at 03:09, 4 May 2023

2023-05-04T03:09:35Z

@@ Line 7: / Line 7: @@
 * On [[Debian]]-derived systems, install <tt>azure-cli</tt>
 ** <tt>az account list</tt> -- list subscription groups
 ==Networking==
@@ Line 124: / Line 133: @@
 * [https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq Azure Virtual Networks FAQ]
 * [https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/best-practices-for-running-linux-on-hyper-v Best Practices for Running Linux on Hyper-V]

Dank: /* External Links */

2023-04-30T06:32:23Z

External Links

← Older revision		Revision as of 06:32, 30 April 2023
Line 123:		Line 123:
	* [https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/ipv6-overview Overview of IPv6 for Azure]		* [https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/ipv6-overview Overview of IPv6 for Azure]
	* [https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq Azure Virtual Networks FAQ]		* [https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq Azure Virtual Networks FAQ]
			* [https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/best-practices-for-running-linux-on-hyper-v Best Practices for Running Linux on Hyper-V]

Dank: /* External Links */

2023-02-19T09:04:50Z

External Links

← Older revision		Revision as of 09:04, 19 February 2023
Line 122:		Line 122:
	* [https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview Virtual network traffic routing]		* [https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview Virtual network traffic routing]
	* [https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/ipv6-overview Overview of IPv6 for Azure]		* [https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/ipv6-overview Overview of IPv6 for Azure]
			* [https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq Azure Virtual Networks FAQ]

Dank: /* External Links */

2023-02-19T09:04:10Z

External Links

← Older revision		Revision as of 09:04, 19 February 2023
Line 121:		Line 121:
	* [https://techcommunity.microsoft.com/t5/azure-high-performance-computing/performance-impact-of-enabling-accelerated-networking-on-hbv3/ba-p/2103451 Performance Impact of Enabling Accelerated Networking on HBv3, HBv2, and HC VMs]		* [https://techcommunity.microsoft.com/t5/azure-high-performance-computing/performance-impact-of-enabling-accelerated-networking-on-hbv3/ba-p/2103451 Performance Impact of Enabling Accelerated Networking on HBv3, HBv2, and HC VMs]
	* [https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview Virtual network traffic routing]		* [https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview Virtual network traffic routing]
			* [https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/ipv6-overview Overview of IPv6 for Azure]

Dank: /* External Links */

2023-02-19T08:59:11Z

External Links

← Older revision		Revision as of 08:59, 19 February 2023
Line 120:		Line 120:
	* [https://techcommunity.microsoft.com/t5/azure-compute-blog/accelerated-networking-on-hb-hc-hbv2-hbv3-and-ndv2/ba-p/2067965 Accelerated Networking on HB, HC, HBv2, HBv3, and NDv2] (mostly about [[InfiniBand]])		* [https://techcommunity.microsoft.com/t5/azure-compute-blog/accelerated-networking-on-hb-hc-hbv2-hbv3-and-ndv2/ba-p/2067965 Accelerated Networking on HB, HC, HBv2, HBv3, and NDv2] (mostly about [[InfiniBand]])
	* [https://techcommunity.microsoft.com/t5/azure-high-performance-computing/performance-impact-of-enabling-accelerated-networking-on-hbv3/ba-p/2103451 Performance Impact of Enabling Accelerated Networking on HBv3, HBv2, and HC VMs]		* [https://techcommunity.microsoft.com/t5/azure-high-performance-computing/performance-impact-of-enabling-accelerated-networking-on-hbv3/ba-p/2103451 Performance Impact of Enabling Accelerated Networking on HBv3, HBv2, and HC VMs]
			* [https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview Virtual network traffic routing]

Dank: /* Networking */

2023-02-19T08:58:49Z

Networking

← Older revision		Revision as of 08:58, 19 February 2023
Line 11:		Line 11:
	Azure hosts use ConnectX devices from Mellanox (now NVIDIA). ConnectX-4 needs the [https://docs.kernel.org/networking/device_drivers/ethernet/mellanox/mlx5.html mlx5_core] driver, while ConnectX-3 needs mlx4_en. It is not possible as of February 2023 to force allocation of one or the other for a given VM, and the NIC type can change if the VM is moved. Azure documentation typically refers to both classes as "SmartNICs".		Azure hosts use ConnectX devices from Mellanox (now NVIDIA). ConnectX-4 needs the [https://docs.kernel.org/networking/device_drivers/ethernet/mellanox/mlx5.html mlx5_core] driver, while ConnectX-3 needs mlx4_en. It is not possible as of February 2023 to force allocation of one or the other for a given VM, and the NIC type can change if the VM is moved. Azure documentation typically refers to both classes as "SmartNICs".

	The fundamental networking object in Azure is the VNet. VNets are manually created, scoped to a single region and subscription, and no larger than a /16. A VM's NICs are assigned to VNets. VNets ought use RFC 1918 or RFC 6598 addresses, and it is best practice to keep the addresses of your organization's VNets distinct. VNets can be peered together. VNets are <b>not a broadcast domain</b>, and indeed support neither broadcast nor multicast using typical mechanisms. ARP requests will be answered by the SDN, and never seen by the other VNet hosts. The reply will always contain the MAC address 12:34:56:78:9a:bc, which will make up most (if not all) of your neighbor table. The SDN does not answer for IPs not active in the VNet. MTUs within a VNet can be safely taken to around 8000 bytes. VNets can be further broken down into distinct subnets. NICs can be assigned public IP addresses in addition to their private addresses within some subnet (and thus VNet), and connecting into the VNet generally requires one or more such IPs. The first four addresses and the last address within each VNet are reserved (network, gateway, dns1, dns2, broadcast).		The fundamental networking object in Azure is the VNet. VNets are manually created, scoped to a single region and subscription, and no larger than a /16. A VM's NICs are assigned to VNets. VNets ought use RFC 1918 or RFC 6598 addresses, and it is best practice to keep the addresses of your organization's VNets distinct. VNets can be peered together. VNets are <b>not a broadcast domain</b>, and indeed support neither broadcast nor multicast using typical mechanisms. ARP requests will be answered by the SDN, and never seen by the other VNet hosts. The reply will always contain the MAC address 12:34:56:78:9a:bc, which will make up most (if not all) of your neighbor table. The SDN does not answer for IPs not active in the VNet. MTUs within a VNet can be safely taken to around 8000 bytes. VNets can be further broken down into distinct subnets. NICs can be assigned public IP addresses in addition to their private addresses within some subnet (and thus VNet), and connecting into the VNet generally requires one or more such IPs. The first four addresses and the last address within each VNet are reserved (network, gateway, dns1, dns2, broadcast). IPv4 VNets must be at least /29s, and no larger than /2s. IPv6 VNets must be /64.

	Other than their definitions as L3 entities, VNets work not unlike VLANs. Most importantly, traffic within a VNet cannot be read by entities outside the VNet.		Other than their definitions as L3 entities, VNets work not unlike VLANs. Most importantly, traffic within a VNet cannot be read by entities outside the VNet. VLANs are not supported within Azure.

	===Accelerated Networking===		===Accelerated Networking===

Dank: /* Networking */

2023-02-19T08:56:31Z

Networking

← Older revision		Revision as of 08:56, 19 February 2023
Line 11:		Line 11:
	Azure hosts use ConnectX devices from Mellanox (now NVIDIA). ConnectX-4 needs the [https://docs.kernel.org/networking/device_drivers/ethernet/mellanox/mlx5.html mlx5_core] driver, while ConnectX-3 needs mlx4_en. It is not possible as of February 2023 to force allocation of one or the other for a given VM, and the NIC type can change if the VM is moved. Azure documentation typically refers to both classes as "SmartNICs".		Azure hosts use ConnectX devices from Mellanox (now NVIDIA). ConnectX-4 needs the [https://docs.kernel.org/networking/device_drivers/ethernet/mellanox/mlx5.html mlx5_core] driver, while ConnectX-3 needs mlx4_en. It is not possible as of February 2023 to force allocation of one or the other for a given VM, and the NIC type can change if the VM is moved. Azure documentation typically refers to both classes as "SmartNICs".

	The fundamental networking object in Azure is the VNet. VNets are manually created, scoped to a single region and subscription, and no larger than a /16. A VM's NICs are assigned to VNets. VNets ought use RFC 1918 or RFC 6598 addresses, and it is best practice to keep the addresses of your organization's VNets distinct. VNets can be peered together. VNets are <b>not a broadcast domain</b>, and indeed support neither broadcast nor multicast using typical mechanisms. ARP requests will be answered by the SDN, and never seen by the other VNet hosts. The reply will always contain the MAC address 12:34:56:78:9a:bc, which will make up most (if not all) of your neighbor table. The SDN does not answer for IPs not active in the VNet. MTUs within a VNet can be safely taken to around 8000 bytes. VNets can be further broken down into distinct subnets. NICs can be assigned public IP addresses in addition to their private addresses within some subnet (and thus VNet), and connecting into the VNet generally requires one or more such IPs.		The fundamental networking object in Azure is the VNet. VNets are manually created, scoped to a single region and subscription, and no larger than a /16. A VM's NICs are assigned to VNets. VNets ought use RFC 1918 or RFC 6598 addresses, and it is best practice to keep the addresses of your organization's VNets distinct. VNets can be peered together. VNets are <b>not a broadcast domain</b>, and indeed support neither broadcast nor multicast using typical mechanisms. ARP requests will be answered by the SDN, and never seen by the other VNet hosts. The reply will always contain the MAC address 12:34:56:78:9a:bc, which will make up most (if not all) of your neighbor table. The SDN does not answer for IPs not active in the VNet. MTUs within a VNet can be safely taken to around 8000 bytes. VNets can be further broken down into distinct subnets. NICs can be assigned public IP addresses in addition to their private addresses within some subnet (and thus VNet), and connecting into the VNet generally requires one or more such IPs. The first four addresses and the last address within each VNet are reserved (network, gateway, dns1, dns2, broadcast).

	Other than their definitions as L3 entities, VNets work not unlike VLANs. Most importantly, traffic within a VNet cannot be read by entities outside the VNet.		Other than their definitions as L3 entities, VNets work not unlike VLANs. Most importantly, traffic within a VNet cannot be read by entities outside the VNet.

Dank: /* Networking */

2023-02-19T04:48:38Z

Networking

← Older revision		Revision as of 04:48, 19 February 2023
Line 12:		Line 12:

	The fundamental networking object in Azure is the VNet. VNets are manually created, scoped to a single region and subscription, and no larger than a /16. A VM's NICs are assigned to VNets. VNets ought use RFC 1918 or RFC 6598 addresses, and it is best practice to keep the addresses of your organization's VNets distinct. VNets can be peered together. VNets are <b>not a broadcast domain</b>, and indeed support neither broadcast nor multicast using typical mechanisms. ARP requests will be answered by the SDN, and never seen by the other VNet hosts. The reply will always contain the MAC address 12:34:56:78:9a:bc, which will make up most (if not all) of your neighbor table. The SDN does not answer for IPs not active in the VNet. MTUs within a VNet can be safely taken to around 8000 bytes. VNets can be further broken down into distinct subnets. NICs can be assigned public IP addresses in addition to their private addresses within some subnet (and thus VNet), and connecting into the VNet generally requires one or more such IPs.		The fundamental networking object in Azure is the VNet. VNets are manually created, scoped to a single region and subscription, and no larger than a /16. A VM's NICs are assigned to VNets. VNets ought use RFC 1918 or RFC 6598 addresses, and it is best practice to keep the addresses of your organization's VNets distinct. VNets can be peered together. VNets are <b>not a broadcast domain</b>, and indeed support neither broadcast nor multicast using typical mechanisms. ARP requests will be answered by the SDN, and never seen by the other VNet hosts. The reply will always contain the MAC address 12:34:56:78:9a:bc, which will make up most (if not all) of your neighbor table. The SDN does not answer for IPs not active in the VNet. MTUs within a VNet can be safely taken to around 8000 bytes. VNets can be further broken down into distinct subnets. NICs can be assigned public IP addresses in addition to their private addresses within some subnet (and thus VNet), and connecting into the VNet generally requires one or more such IPs.

			Other than their definitions as L3 entities, VNets work not unlike VLANs. Most importantly, traffic within a VNet cannot be read by entities outside the VNet.

	===Accelerated Networking===		===Accelerated Networking===

Dank: /* Networking */

2023-02-19T04:47:07Z

Networking

← Older revision		Revision as of 04:47, 19 February 2023
Line 11:		Line 11:
	Azure hosts use ConnectX devices from Mellanox (now NVIDIA). ConnectX-4 needs the [https://docs.kernel.org/networking/device_drivers/ethernet/mellanox/mlx5.html mlx5_core] driver, while ConnectX-3 needs mlx4_en. It is not possible as of February 2023 to force allocation of one or the other for a given VM, and the NIC type can change if the VM is moved. Azure documentation typically refers to both classes as "SmartNICs".		Azure hosts use ConnectX devices from Mellanox (now NVIDIA). ConnectX-4 needs the [https://docs.kernel.org/networking/device_drivers/ethernet/mellanox/mlx5.html mlx5_core] driver, while ConnectX-3 needs mlx4_en. It is not possible as of February 2023 to force allocation of one or the other for a given VM, and the NIC type can change if the VM is moved. Azure documentation typically refers to both classes as "SmartNICs".

	The fundamental networking object in Azure is the VNet. VNets are manually created, scoped to a single region and subscription, and no larger than a /16. A VM's NICs are assigned to VNets. VNets ought use RFC 1918 or RFC 6598 addresses, and it is best practice to keep the addresses of your organization's VNets distinct. VNets can be peered together. ~~NICs can be assigned public IP addresses in addition to their private addresses with the VNet, and connecting into the VNet generally requires one or more such IPs.~~		The fundamental networking object in Azure is the VNet. VNets are manually created, scoped to a single region and subscription, and no larger than a /16. A VM's NICs are assigned to VNets. VNets ought use RFC 1918 or RFC 6598 addresses, and it is best practice to keep the addresses of your organization's VNets distinct. VNets can be peered together. VNets are <b>not a broadcast domain</b>, and indeed support neither broadcast nor multicast using typical mechanisms. ARP requests will be answered by the SDN, and never seen by the other VNet hosts. The reply will always contain the MAC address 12:34:56:78:9a:bc, which will make up most (if not all) of your neighbor table. The SDN does not answer for IPs not active in the VNet. MTUs within a VNet can be safely taken to around 8000 bytes. VNets can be further broken down into distinct subnets. NICs can be assigned public IP addresses in addition to their private addresses within some subnet (and thus VNet), and connecting into the VNet generally requires one or more such IPs.

	VNets are <b>not a broadcast domain</b>, and indeed support neither broadcast nor multicast using typical mechanisms. ARP requests will be answered by the SDN, and never seen by the other VNet hosts. The reply will always contain the MAC address 12:34:56:78:9a:bc, which will make up most (if not all) of your neighbor table. The SDN does not answer for IPs not active in the VNet. MTUs within a VNet can be safely taken to around 8000 bytes.

	===Accelerated Networking===		===Accelerated Networking===

Dank: /* Networking */

2023-02-19T03:22:34Z

Networking

← Older revision		Revision as of 03:22, 19 February 2023
Line 13:		Line 13:
	The fundamental networking object in Azure is the VNet. VNets are manually created, scoped to a single region and subscription, and no larger than a /16. A VM's NICs are assigned to VNets. VNets ought use RFC 1918 or RFC 6598 addresses, and it is best practice to keep the addresses of your organization's VNets distinct. VNets can be peered together. NICs can be assigned public IP addresses in addition to their private addresses with the VNet, and connecting into the VNet generally requires one or more such IPs.		The fundamental networking object in Azure is the VNet. VNets are manually created, scoped to a single region and subscription, and no larger than a /16. A VM's NICs are assigned to VNets. VNets ought use RFC 1918 or RFC 6598 addresses, and it is best practice to keep the addresses of your organization's VNets distinct. VNets can be peered together. NICs can be assigned public IP addresses in addition to their private addresses with the VNet, and connecting into the VNet generally requires one or more such IPs.

	VNets are <b>not a broadcast domain</b>, and indeed support neither broadcast nor multicast using typical mechanisms. ARP requests will be answered by the SDN, and never seen by the other VNet hosts. The reply will always contain the MAC address 12:34:56:78:9a:bc, which will make up most (if not all) of your neighbor table. The SDN does not answer for IPs not active in the VNet.		VNets are <b>not a broadcast domain</b>, and indeed support neither broadcast nor multicast using typical mechanisms. ARP requests will be answered by the SDN, and never seen by the other VNet hosts. The reply will always contain the MAC address 12:34:56:78:9a:bc, which will make up most (if not all) of your neighbor table. The SDN does not answer for IPs not active in the VNet. MTUs within a VNet can be safely taken to around 8000 bytes.

	===Accelerated Networking===		===Accelerated Networking===