Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into service-tag-patch

Author: asudbring

articles/operator-nexus/TOC.yml

@@ -20,6 +20,8 @@
           href: concepts-network-fabric.md
         - name: Network Fabric Controller
           href: concepts-network-fabric-controller.md
+        - name: Network Fabric Services
+          href: concepts-network-fabric-services.md
     - name: Nexus Kubernetes
       href: concepts-nexus-kubernetes-cluster.md
     - name: Observability

articles/operator-nexus/concepts-network-fabric-controller.md

@@ -191,3 +191,7 @@ Similar to the creation process, deleting an NFC usually takes between 45 and 60
 **What steps should be taken if the NFC fails to initialize on the first attempt?**
 
 If the NFC does not provision successfully on the first try, the recommended course of action is to clean up and recreate the NFC. This is due to the lack of support for updating the NFC during intermediate failures.
+
+## Next steps
+
+- [Network Fabric Services](concepts-network-fabric-services.md)

articles/operator-nexus/concepts-network-fabric-services.md

@@ -0,0 +1,82 @@
+---
+title: Azure Operator Nexus Network Fabric Services
+description: Overview of Network Fabric Services for Azure Operator Nexus.
+author: lnyswonger
+ms.author: lnyswonger
+ms.reviewer: jdasari
+ms.date: 12/21/2023
+ms.service: azure-operator-nexus
+ms.topic: conceptual
+---
+
+# Network Fabric Services overview
+The Network Fabric Controller (NFC) serves as the host for Nexus Network Fabric (NNF) services, illustrated in the diagram below. These services enable secure internet access for on-premises applications and services. Communication between on-premises applications and NNF services is facilitated through a specialized Express Route service (VPN). This setup allows on-premises services to connect to the NNF services via Express Route at one end, and access internet-based services at the other end.
+
+:::image type="content" source="media/network-fabric-controller-architecture.png" alt-text="A flowchart for creating a Network Fabric Controller in Azure, detailing the progression from user request to the associated Azure resources.":::
+
+
+## Enhanced Security with Nexus Network Fabric Proxy Management
+The Nexus Network Fabric employs a robust, cloud-native proxy designed to protect the Nexus infrastructure and its associated workloads. This proxy is primarily focused on preventing data exfiltration attacks and maintaining a controlled allowlist of URLs for NNF instance connections. In combination with the under-cloud proxy, the NNF proxy delivers comprehensive security for workload networks. There are two distinct aspects of this system: the Infrastructure Management Proxy, which handles all infrastructure traffic, and the Workload Management Proxy, dedicated to facilitating communication between workloads and public or Azure endpoints.
+
+## Optimized Time Synchronization with Managed Network Time Protocol (NTP)
+The Network Time Protocol (NTP) is an essential network protocol that aligns the time settings of computer systems over packet-switched networks. In the Azure Operator Nexus instance, NTP is instrumental in ensuring the consistent time settings across all compute nodes and network devices. This level of synchronization is critical for the Network Functions (NFs) operating within the infrastructure. It significantly contributes to the effectiveness of telemetry and security measures, maintaining the integrity and coordination of the system.
+
+## Nexus Network Fabric Resources
+The following are key resources for Nexus Network Fabric.
+
+### InternetGateways
+*InternetGateways* is a critical resource in network architecture, acting as the connecting bridge between a virtual network and the Internet. It enables virtual machines and other entities within a virtual network to communicate seamlessly with external services. These services range from websites and APIs to various cloud services, making InternetGateways a versatile and essential component.
+
+#### Properties
+
+| Property         | Description                                                                                          |
+|------------------|------------------------------------------------------------------------------------------------------|
+| Name             | Serves as the unique identifier for the Internet Gateway.                                            |
+| Location         | Specifies the Azure region where the Internet Gateway is deployed, ensuring regional compliance and optimization. |
+| Subnets          | Defines the subnets linked with the Internet Gateway, determining the network segments it services. |
+| Public IP Address| Assigns a public IP address to the gateway, enabling external network interactions.                  |
+| Routes           | Outlines the routing rules and configurations for managing traffic through the gateway.             |
+
+
+#### Use cases
+
+* **Internet Access:** Facilitates Internet connectivity for virtual network resources, crucial for updates, downloads, and accessing external services.
+* **Hybrid Connectivity:** Ideal for hybrid scenarios, allowing secure connections between on-premises networks and Azure resources.
+* **Load Balancing:** Enhances network performance and availability by evenly distributing traffic across multiple gateways.
+* **Security Enforcement:** Enables the implementation of robust security policies, such as outbound traffic restrictions and encryption mandates.
+
+### InternetGatewayRules
+*InternetGatewayRules* represents a set of rules associated with an Internet Gateway in the Managed Network Fabric. These rules establish guidelines for either permitting or restricting traffic as it moves through the Internet Gateway, providing a framework for network traffic management.
+
+#### Properties
+
+| Property                     | Description                                                                          |
+|------------------------------|--------------------------------------------------------------------------------------|
+| Name                         | Acts as the unique identifier for each rule.                                         |
+| Priority                     | Sets the evaluation order of the rules, with higher priority rules taking precedence.|
+| Action                       | Determines the action (e.g., allow, deny) for traffic that matches the rule criteria.|
+| Source IP Address Range      | Identifies the originating IP address range applicable to the rule.                  |
+| Destination IP Address Range | Defines the targeted IP address range for the rule.                                  |
+| Protocol                     | Specifies the network protocol (e.g., TCP, UDP) relevant to the rule.                |
+| Port Range                   | Details the port range for the rule, if applicable.                                  |
+
+
+#### Use cases
+
+* **Traffic Filtering:** InternetGatewayRules enable organizations to control both incoming and outgoing network traffic based on specific criteria. For example, they can block certain IP ranges or allow only particular protocols.
+
+* **Enforcing Security Policies:** These rules are instrumental in implementing security measures, such as restricting traffic to enhance network security. An organization might block known malicious IP ranges or limit traffic to specific ports for certain services.
+
+* **Compliance Assurance:** The rules can also be utilized to comply with regulatory standards by limiting types of traffic, thereby aiding in data privacy and access control.
+
+* **Traffic Load Balancing:** InternetGatewayRules can distribute network traffic across multiple gateways to optimize resource utilization. This includes prioritizing or throttling traffic based on business needs.
+
+## FAQs
+
+**Is Support Available for HTTP Endpoints?**
+
+Azure's default configuration supports only HTTPS endpoints to ensure secure communication. HTTP endpoints are not supported as part of this security measure. By prioritizing HTTPS, Azure maintains high standards of data integrity and privacy.
+
+**How Can I Safeguard Against Data Exfiltration?**
+
+To strengthen security against data exfiltration, Azure supports the allowance of specific Fully Qualified Domain Names (FQDNs) on the proxy. This additional security measure ensures that your network can only be accessed by approved traffic, greatly minimizing the potential for unauthorized data movement.

articles/virtual-wan/about-virtual-hub-routing.md

@@ -6,7 +6,7 @@ author: cherylmc
 
 ms.service: virtual-wan
 ms.topic: conceptual
-ms.date: 06/30/2023
+ms.date: 01/09/2024
 ms.author: cherylmc
 ms.custom: fasttrack-edit
 ---
@@ -23,11 +23,11 @@ The following sections describe the key concepts in virtual hub routing.
 
 ### <a name="hub-route"></a>Hub route table
 
-A virtual hub route table can contain one or more routes. A route includes its name, a label, a destination type, a list of destination prefixes, and next hop information for a packet to be routed. A **Connection** typically will have a routing configuration that associates or propagates to a route table.
+A virtual hub route table can contain one or more routes. A route includes its name, a label, a destination type, a list of destination prefixes, and next hop information for a packet to be routed. A **Connection** typically has a routing configuration that associates or propagates to a route table.
 
 ### <a name= "hub-route"></a> Hub routing intent and policies
 
-Routing Intent and Routing policies allow you to configure your Virtual WAN hub to send Internet-bound and Private (Point-to-site, Site-to-site, ExpressRoute, Network Virtual Appliances inside the Virtual WAN Hub and Virtual Network) Traffic via an Azure Firewall, Next-Generation Firewall NVA or software-as-a-service solution deployed in the Virtual WAN hub. There are two types of Routing Policies: Internet Traffic and Private Traffic Routing Policies. Each Virtual WAN Hub may have at most one Internet Traffic Routing Policy and one Private Traffic Routing Policy, each with a Next Hop resource.
+Routing Intent and Routing policies allow you to configure your Virtual WAN hub to send Internet-bound and Private (Point-to-site, Site-to-site, ExpressRoute, Network Virtual Appliances inside the Virtual WAN Hub and Virtual Network) Traffic via an Azure Firewall, Next-Generation Firewall NVA or software-as-a-service solution deployed in the Virtual WAN hub. There are two types of Routing Policies: Internet Traffic and Private Traffic Routing Policies. Each Virtual WAN Hub can have, at most, one Internet Traffic Routing Policy and one Private Traffic Routing Policy, each with a Next Hop resource.
 
 
 While Private Traffic includes both branch and Virtual Network address prefixes, Routing Policies considers them as one entity within the Routing Intent concepts.
@@ -51,7 +51,7 @@ You can set up the routing configuration for a virtual network connection during
 
 ### <a name="association"></a>Association
 
-Each connection is associated to one route table. Associating a connection to a route table allows the traffic (from that connection) to be sent to the destination indicated as routes in the route table. The routing configuration of the connection will show the associated route table.  Multiple connections can be associated to the same route table. All VPN, ExpressRoute, and User VPN connections are associated to the same (default) route table.
+Each connection is associated to one route table. Associating a connection to a route table allows the traffic (from that connection) to be sent to the destination indicated as routes in the route table. The routing configuration of the connection shows the associated route table.  Multiple connections can be associated to the same route table. All VPN, ExpressRoute, and User VPN connections are associated to the same (default) route table.
 
 By default, all connections are associated to a **Default route table** in a virtual hub. Each virtual hub has its own Default route table, which can be edited to add a static route(s). Routes added statically take precedence over dynamically learned routes for the same prefixes.
 
@@ -96,10 +96,10 @@ Consider the following when configuring Virtual WAN routing:
 * All branch connections (Point-to-site, Site-to-site, and ExpressRoute) need to be associated to the Default route table. That way, all branches will learn the same prefixes.
 * All branch connections need to propagate their routes to the same set of route tables. For example, if you decide that branches should propagate to the Default route table, this configuration should be consistent across all branches. As a result, all connections associated to the Default route table will be able to reach all of the branches.
 * When you use Azure Firewall in multiple regions, all spoke virtual networks must be associated to the same route table. For example, having a subset of the VNets going through the Azure Firewall while other VNets bypass the Azure Firewall in the same virtual hub isn't possible.
-* You may specify multiple next hop IP addresses on a single Virtual Network connection. However, Virtual Network Connection doesn't support ‘multiple/unique’ next hop IP to the ‘same’ network virtual appliance in a SPOKE Virtual Network 'if' one of the routes with next hop IP is indicated to be public IP address or 0.0.0.0/0 (internet)
+* You can specify multiple next hop IP addresses on a single Virtual Network connection. However, Virtual Network Connection doesn't support ‘multiple/unique’ next hop IP to the ‘same’ network virtual appliance in a SPOKE Virtual Network 'if' one of the routes with next hop IP is indicated to be public IP address or 0.0.0.0/0 (internet)
 * All information pertaining to 0.0.0.0/0 route is confined to a local hub's route table. This route doesn't propagate across hubs.
 * You can only use Virtual WAN to program routes in a spoke if the prefix is shorter (less specific) than the virtual network prefix. For example, in the diagram above the spoke VNET1 has the prefix 10.1.0.0/16: in this case, Virtual WAN wouldn't be able to inject a route that matches the virtual network prefix (10.1.0.0/16) or any of the subnets (10.1.0.0/24, 10.1.1.0/24). In other words, Virtual WAN can't attract traffic between two subnets that are in the same virtual network.
-* While true that 2 hubs on the same virtual WAN will announce routes to each other (as long as the propagation is enabled to the same labels) this only applies to dynamic routing. Once you define a static route, this is not the case.
+* While it's true that 2 hubs on the same virtual WAN will announce routes to each other (as long as the propagation is enabled to the same labels), this only applies to dynamic routing. Once you define a static route, this isn't the case.
 
 ## Next steps
 

articles/virtual-wan/index.yml

@@ -10,7 +10,7 @@ metadata:
   ms.topic: landing-page
   author: cherylmc
   ms.author: cherylmc
-  ms.date: 05/01/2023
+  ms.date: 01/09/2024
   ms.custom: e2e-hybrid
 
 # linkListType: architecture | concept | deploy | download | get-started | how-to-guide | learn | overview | quickstart | reference | tutorial | whats-new

articles/virtual-wan/virtual-wan-about.md

@@ -5,7 +5,7 @@ author: cherylmc
 
 ms.service: virtual-wan
 ms.topic: overview
-ms.date: 06/30/2023
+ms.date: 01/09/2024
 ms.author: cherylmc
 # Customer intent: As someone with a networking background, I want to understand what Virtual WAN is and if it is the right choice for my Azure network.
 ---
@@ -24,7 +24,7 @@ Azure Virtual WAN is a networking service that brings many networking, security,
 
 You don't have to have all of these use cases to start using Virtual WAN. You can get started with just one use case, and then adjust your network as it evolves.
 
-The Virtual WAN architecture is a hub and spoke architecture with scale and performance built in for branches (VPN/SD-WAN devices), users (Azure VPN/OpenVPN/IKEv2 clients), ExpressRoute circuits, and virtual networks. It enables a [global transit network architecture](virtual-wan-global-transit-network-architecture.md), where the cloud hosted network 'hub' enables transitive connectivity between endpoints that may be distributed across different types of 'spokes'.
+The Virtual WAN architecture is a hub and spoke architecture with scale and performance built in for branches (VPN/SD-WAN devices), users (Azure VPN/OpenVPN/IKEv2 clients), ExpressRoute circuits, and virtual networks. It enables a [global transit network architecture](virtual-wan-global-transit-network-architecture.md), where the cloud hosted network 'hub' enables transitive connectivity between endpoints that might be distributed across different types of 'spokes'.
 
 Azure regions serve as hubs that you can choose to connect to. All hubs are connected in full mesh in a Standard Virtual WAN making it easy for the user to use the Microsoft backbone for any-to-any (any spoke) connectivity.