Warmup Guide — Azure Networking & the Software-Defined Network

Zero-to-principal primer for Phase 06. There is no cable to trace in Azure: the VNet, the subnet, the firewall, the route, and the load balancer are software running on every host. This guide builds the network from the empty address space up — the subnet math, the four decisions a packet passes through (DNS, source NSG, route, destination NSG), and the one mechanism that breaks more Azure deployments than any other: Private Endpoint DNS. We start from "what even is a virtual network" and end with the arithmetic you do on a whiteboard before any resource exists, plus the failure signatures you will diagnose at 2 a.m.

Table of Contents

• Chapter 1: The Software-Defined Network — There Is No Cable
• Chapter 2: VNets, Subnets, and the Address Plan
• Chapter 3: Network Security Groups — Priority, First-Match, Stateful
• Chapter 4: Effective Routes and User-Defined Routes
• Chapter 5: Private Endpoints, Private Link, and the DNS Override
• Chapter 6: Topology — Hub-and-Spoke, Peering, and the Firewall
• Chapter 7: Load Balancing — Front Door vs App Gateway vs Load Balancer
• Chapter 8: Failure Modes and the 2 a.m. Diagnoses
• Lab Walkthrough Guidance
• Success Criteria
• Interview Q&A
• References

Chapter 1: The Software-Defined Network — There Is No Cable

From zero. In a data centre, a network is physical: NICs, cables, switches, routers, firewalls — you can trace a packet by following copper. In Azure, none of that exists for you. When you create a "virtual network," Azure does not allocate a switch. It writes a policy that the virtual filtering platform (VFP) — a programmable packet processor running on every physical host — enforces in software, per virtual NIC.

What it is. The SDN is a set of control-plane objects (VNet, subnet, NSG, route table, Private Endpoint, firewall, load balancer) that compile down to data-plane rules the host applies to each packet. The control plane is ARM (Phase 01): you PUT an NSG and ARM stores it; the host then programs the VFP with the resulting allow/deny table.

Why it exists. Physical networks do not scale to a multi-tenant cloud: you cannot run a cable per customer, and you cannot let one tenant's broadcast reach another's. Software definition gives isolation (each VNet is its own L3 address space, invisible to others), programmability (network config is IaC, versioned and reviewed), and policy at scale (a rule applies to thousands of NICs at once).

Under the hood — the packet's four decisions. A packet from a VM is processed by the host in this order. This ordering is the single most useful thing in this whole guide:

   sender VM                                                     receiver VM
   ─────────                                                     ───────────
   (0) DNS resolve dest name → IP   ← Private Endpoint rewrites this
   (1) outbound NSG on sender NIC   ← allow/deny, priority order, stateful
   (2) route table on sender NIC    ← longest-prefix → next hop (maybe a firewall)
        … traverse fabric / firewall / peering …
   (3) inbound NSG on receiver NIC  ← allow/deny, priority order, stateful

A dropped packet is always one of these four, and they fail silently — no ICMP, no log unless you turned on flow logging. The principal skill is knowing which of the four to check, in order. The lab builds engines for (0), (1), and (2).

Production significance. Because the network is software, "it works on my VM" tells you nothing — the effective rules and routes for a given NIC are what matter, and they are the sum of everything inherited from the subnet, the NIC, and the platform. Azure exposes the computed result (az network nic show-effective-route-table, ... show-effective-nsg-rules), and reading those dumps is the job.

Common misconceptions.

• "A VNet spans regions." No — a VNet is regional (and per-subscription). You connect VNets across regions with peering or a gateway.
• "NSGs and firewalls are the same." No — an NSG is an L3/L4 stateful ACL on a NIC/subnet; a firewall (Azure Firewall) is a stateful L3–L7 appliance with FQDN/app rules, NAT, and threat intel that traffic is routed to. You use both.

Chapter 2: VNets, Subnets, and the Address Plan

From zero. A Virtual Network (VNet) is a private IP address space you own inside one Azure region — almost always from the RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). You carve it into subnets, and resources (VM NICs, Private Endpoints, gateways) get IPs from a subnet.

What CIDR is. A CIDR block 10.0.0.0/16 means "the first 16 bits are the network, the last 16 are host." The prefix length ( p ) fixes the split:

$$ \text{total addresses} = 2^{(32 - p)} $$

So /16 is ( 2^{16} = 65{,}536 ) addresses, /24 is ( 2^8 = 256 ), /29 is ( 2^3 = 8 ).

Why Azure reserves five. In every subnet, Azure takes five addresses off the top:

So the usable host count is:

$$ \text{usable}(p) = 2^{(32 - p)} - 5 $$

This is why a /29 (8 addresses) has only 3 usable — and why Azure rejects anything smaller than /29: a /30 has 4 total addresses, minus 5 is negative. The /29 floor is a number to memorise.

Under the hood — splitting. Designing an address plan is splitting a block into children. A /24 splits into four /26s (+64 each) or sixteen /28s. The arithmetic: splitting from prefix ( p ) to ( q > p ) yields ( 2^{(q - p)} ) children. The lab's split_subnet is exactly this, and ipaddress.ip_network(...).subnets(new_prefix=q) does it for you.

Production significance. Address planning is a one-way door. You can grow a VNet's space but resizing a subnet with resources in it is painful, and overlapping CIDRs cannot peer — two VNets with 10.0.0.0/16 each can never be connected. So the platform team owns a non-overlapping IP plan for the whole estate (often allocated per region/spoke from a big super-net), and app teams get a subnet, not a free choice.

Common misconceptions.

• "I'll use a /30 for a point-to-point subnet." Azure forbids it — /29 is the floor.
• "Reserved IPs are just .0 and broadcast like on-prem." No — Azure takes five, including .1/.2/.3. Off-by-three will wreck a tight address plan.

Chapter 3: Network Security Groups — Priority, First-Match, Stateful

From zero. A Network Security Group (NSG) is a stateful packet filter — an ACL — you attach to a subnet and/or a NIC. It holds security rules, each one an allow or deny for a 5-tuple (protocol, source, source port, destination, destination port) in one direction (inbound or outbound).

What "priority" means. Every rule has a priority from 100 to 4096. Lower number = higher priority = evaluated first. Azure evaluates rules in ascending priority order and stops at the first match — first match wins. This is the rule that trips people up:

priority 100  Deny   from 203.0.113.0/24  →  *      (evaluated FIRST)
priority 200  Allow  from Internet        →  :443   (evaluated SECOND)

A packet from 203.0.113.9:443 hits rule 100 first → denied, even though rule 200 would have allowed it. A low-number Deny shadows a high-number Allow. The lab's evaluate_nsg sorts by priority ascending and returns the first match — this is the mechanism.

Why stateful matters. NSGs are stateful (connection-tracking): if you allow an outbound flow, the return traffic is allowed automatically, and vice versa. You do not write a return rule. This is why "allow outbound 443 to the internet" is enough for a VM to make HTTPS calls and receive the responses — the established connection's inbound packets are permitted by the connection-tracking table, not by an inbound rule. In the lab we model statefulness by evaluating only the originating direction; the return path is implicit.

Under the hood — the default rules. Even an empty NSG has behaviour, because Azure adds default rules at the bottom (priorities 65000+) that you cannot delete:

Two consequences a principal carries: (a) intra-VNet traffic is allowed by default (you must add a Deny to micro-segment), and (b) inbound from the internet is denied by default (you must add an Allow to expose anything). The lab's _default_rules reproduces this exactly, which is why evaluate_nsg([], vnet_to_vnet_packet, ...) returns Allow and evaluate_nsg([], internet_packet, ...) returns Deny.

Service tags. A rule's source/dest can be a service tag — a symbolic name Azure expands to a managed prefix list: VirtualNetwork (your VNet space + peered + on-prem), Internet (everything public), AzureLoadBalancer (the probe IP 168.63.129.16), Storage, Sql, AzureCloud, regionalised like Storage.WestEurope. Tags mean you never hardcode Microsoft's IP ranges (which change). The lab models the three that the defaults need.

Production significance. NSGs are the micro-segmentation layer. The platform baseline is usually deny-by-default inbound with explicit allows per tier (web/app/data), and Application Security Groups (ASGs) let you name a role ("web-servers") and write rules against the role instead of IPs. The classic mistake is putting an NSG on both the subnet and the NIC and forgetting that both must allow the flow (they are evaluated independently; the effective decision is the intersection).

Common misconceptions.

• "Higher priority number = more important." Backwards — lower number wins.
• "I need an inbound rule for return traffic." No — stateful. Writing one is a smell.
• "NSG blocks by default, so my VNet is segmented." No — AllowVnetInBound lets all intra-VNet traffic through until you add a Deny.

Chapter 4: Effective Routes and User-Defined Routes

From zero. Once an NSG allows a packet out, where does it go? That is the route table. Azure builds an effective route table per NIC from three sources:

1. System routes — Azure's built-in defaults: a route to the VNet space (VnetLocal), to peered VNets (VnetPeering), to on-prem via a gateway, and a catch-all 0.0.0.0/0 → Internet.
2. User-Defined Routes (UDRs) — your route table, attached to a subnet, overriding the system routes.
3. BGP routes — learned dynamically from on-prem over ExpressRoute/VPN.

What "effective" means. For a given destination IP, Azure picks one route by longest-prefix match: among all routes whose prefix contains the destination, the one with the most specific (longest) prefix wins. A /32 beats a /24 beats a /0.

Under the hood — the tie-break. When two routes have the same prefix length, Azure breaks the tie by origin:

$$ \text{UDR} ;>; \text{BGP} ;>; \text{system} $$

This is why a UDR 0.0.0.0/0 → VirtualAppliance beats the system route 0.0.0.0/0 → Internet (same /0 length, UDR wins) and force-tunnels all egress through your firewall. The lab's effective_next_hop is exactly this: filter to matching routes, then min by the key (-prefixlen, origin_priority, name) — longest prefix first, then origin, then name for determinism.

dest 8.8.8.8:
   system  0.0.0.0/0      → Internet          (matches, /0)
   UDR     0.0.0.0/0      → VirtualAppliance   (matches, /0, UDR wins the tie) ★
   → next hop = VirtualAppliance (the firewall) — forced tunnelling

dest 203.0.113.55:
   UDR     0.0.0.0/0          → VirtualAppliance (matches, /0)
   UDR     203.0.113.55/32    → VirtualAppliance (matches, /32 — longest) ★
   → next hop = the /32 route — one host pinned to a specific appliance

Next-hop types you must know: VirtualAppliance (an NVA / Azure Firewall — requires a next-hop IP), VirtualNetworkGateway (VPN/ER), VnetLocal (stays in the VNet), Internet (default egress), VnetPeering, and None (a blackhole — silently drops the packet, the cause of many "it just disappears" incidents).

Production significance. The 0.0.0.0/0 → firewall UDR is the backbone of a secure landing zone: every spoke routes its internet-bound and inter-spoke traffic through the hub firewall for inspection. But it is also a footgun: if you force-tunnel 0.0.0.0/0 to a firewall and forget a route exception for the firewall's own dependencies (or for Azure platform traffic), you can blackhole the firewall and take down the whole spoke. And a UDR that points 0.0.0.0/0 at an appliance with no SNAT/return route breaks asymmetric- routing flows.

Common misconceptions.

• "The most-recently-added route wins." No — longest prefix, then origin.
• "BGP overrides my UDR." Backwards — UDR overrides BGP at equal prefix length (which surprises people doing hybrid networking; your UDR can silently shadow a learned route).
• "A None next hop is an error." No — it is a deliberate blackhole, and a sneaky way to drop traffic with no log.

Chapter 5: Private Endpoints, Private Link, and the DNS Override

From zero. A PaaS resource — a storage account, Key Vault, SQL database — has a public FQDN (acct.blob.core.windows.net) and, by default, a public IP. In a regulated estate you want it reachable only from your private network. Private Link is the mechanism, and a Private Endpoint is its concrete object: a NIC with a private IP in your subnet that maps to the PaaS resource.

The catch (and the whole point): DNS. Your apps connect by name, not IP — they call acct.blob.core.windows.net. That name publicly resolves to the storage account's public IP. Creating a Private Endpoint gives you a private IP (say 10.0.3.10) — but unless DNS resolution is overridden, your VM still resolves the name to the public IP and never uses the private endpoint. So Private Link works by rewriting DNS:

public DNS:    acct.blob.core.windows.net  →  20.150.43.16   (public IP)

with Private Endpoint + linked Private DNS zone:
   zone: privatelink.blob.core.windows.net  holds  acct... → 10.0.3.10
   VM in a LINKED VNet resolves: acct.blob.core.windows.net → 10.0.3.10  (PRIVATE) ★
   VM in an UNLINKED VNet:        acct.blob.core.windows.net → 20.150.43.16 (public)

Under the hood. Three objects must all exist and connect:

1. the Private Endpoint (the NIC + private IP),
2. the Private DNS zone privatelink.blob.core.windows.net with an A record for the resource pointing at the private IP (auto-created if you let Azure manage it),
3. a virtual-network link joining that zone to the VNet the client lives in.

When all three exist, Azure DNS (the 168.63.129.16 resolver) returns the private IP via a CNAME chain: acct.blob.core.windows.net → acct.privatelink.blob.core.windows.net → (in the private zone) → 10.0.3.10. The lab's resolve_fqdn models step (3) precisely: it returns the private record only if the zone holds the record and the caller's VNet is in the zone's link set; otherwise it falls back to the public record. That conditional is the bug and the fix.

Service endpoints — the alternative. A service endpoint is the older mechanism: it keeps traffic to the PaaS service on the Azure backbone and lets the service's firewall trust your subnet — but the resource keeps its public IP and public FQDN (no DNS change), and access is per-subnet, not a private IP. Private Endpoint is the modern default (private IP, works across peering and on-prem, granular per-resource); service endpoints are simpler but coarser and do not extend to on-prem.

Production significance. Broken Private Endpoint DNS is the single most common Azure networking incident. The endpoint is green, the NSG is fine, the firewall is fine — and the app still hits the public IP (and then fails, because you disabled public access, or succeeds but leaves the private network, defeating the point). The fix is almost always a missing VNet link on the Private DNS zone, or a custom DNS server that does not forward privatelink.* to Azure DNS. In a hub-and-spoke, the Private DNS zones live in the hub and are linked to every spoke — centralised resolution.

Common misconceptions.

• "I created the Private Endpoint, so it's private now." Not until DNS resolves to the private IP for this VNet — check the zone link.
• "I'll just use the private IP directly." PaaS TLS certs are issued for the public FQDN; hitting the IP breaks certificate validation. You must fix DNS, not bypass it.
• "Service endpoint and Private Endpoint are the same." No — service endpoints don't change DNS or give a private IP, and don't reach on-prem.

Chapter 6: Topology — Hub-and-Spoke, Peering, and the Firewall

From zero. Real estates have many VNets. VNet peering connects two VNets so their VMs talk over the Azure backbone as if on one network (low latency, no gateway, but non-overlapping CIDRs required, and peering is non-transitive — A↔B and B↔C does not give A↔C).

Hub-and-spoke is the canonical topology: a central hub VNet holds shared services — the Azure Firewall, the VPN/ExpressRoute gateway, the Private DNS zones, shared DNS — and spoke VNets (per app/team/environment) peer to the hub. Spokes do not peer to each other; inter-spoke traffic transits the hub firewall (via a 0.0.0.0/0 UDR), which is why you accept non-transitive peering — you want the firewall in the path.

                         ┌──────────── hub VNet ────────────┐
        on-prem ──ER/VPN─┤ Gateway   Azure Firewall   DNS   ├
                         └───────┬───────────┬───────────┬──┘
                          peering│    peering│    peering│
                          ┌──────┴──┐  ┌─────┴───┐  ┌────┴────┐
                          │ spoke A │  │ spoke B │  │ spoke C │
                          │ (web)   │  │ (app)   │  │ (data)  │
                          └─────────┘  └─────────┘  └─────────┘
       each spoke: UDR 0.0.0.0/0 → firewall private IP (force-tunnel + inspect)

Production significance. The hub centralises cost (one firewall, one gateway), DNS (one set of Private DNS zones linked to all spokes), and policy (one inspection point). It also centralises blast radius — a hub firewall outage takes down every spoke's egress — so the firewall runs zone-redundant, and you keep break-glass routes.

Chapter 7: Load Balancing — Front Door vs App Gateway vs Load Balancer

From zero. Three services balance traffic at different layers and scopes. The principal framing is L7-global vs L7-regional vs L4-regional:

Under the hood. Front Door and App Gateway terminate HTTP and can run a WAF (OWASP rule inspection) and route by path/host; Load Balancer only sees a flow tuple and hashes it to a backend — it cannot read a URL. A common production stack is Front Door (global edge + WAF + caching) → App Gateway (regional WAF + path routing) → internal Load Balancer (L4) → AKS/VMSS. The interview question "where do you terminate TLS and run WAF?" has the answer "at the L7 layer (Front Door and/or App Gateway), never at the L4 Load Balancer."

Chapter 8: Failure Modes and the 2 a.m. Diagnoses

The throughline: most Azure network incidents are NSG priority, route longest-prefix, or Private DNS — the exact three engines you build in the lab. Calm at 2 a.m. comes from checking them in order (DNS → source NSG → route → dest NSG), not from guessing.

Lab Walkthrough Guidance

Lab 01 — Network Engine, suggested order (matches the file top-to-bottom):

1. CIDR math — subnet_usable_hosts(p) is ( 2^{(32-p)} - 5 ); raise for ( p>29 ) (the /29 floor) and for out-of-range prefixes. cidr_contains and split_subnet are thin wrappers over ipaddress — let the stdlib parse, you add the Azure rules (Ch. 2).
2. NSG — write NsgRule.__post_init__ validation (direction, access, priority 100–4096, protocol), then the four matchers (_port_matches, _endpoint_matches, _protocol_matches, _rule_matches), then evaluate_nsg: filter by direction, sort by priority ascending, return the first match, else fall through to _default_rules (Ch. 3). The test that proves you got it: a priority-100 Deny beats a priority-200 Allow.
3. Routes — Route.__post_init__ validation (next-hop types, VirtualAppliance needs an IP), then effective_next_hop: keep matching routes, raise if none, pick longest prefix with the UDR > BGP > system tie-break via a min key of (-prefixlen, origin_priority, name) (Ch. 4). The test that proves it: a /32 UDR beats /0, and a UDR /0 beats a system /0.
4. Private DNS — resolve_fqdn: return the private record only if the zone holds it and the caller's VNet is in the (zone link ∪ vnet_links) set; else the public record; else raise NXDOMAIN (Ch. 5). The test that proves it: linked → private IP, unlinked → public IP.

Run python solution.py to see all four engines produce a worked example, then make test_lab.py green against your lab.py.

Success Criteria

You are ready for Phase 07 when you can, from memory:

1. State why a /29 has 3 usable hosts and why /29 is Azure's floor (the 5 reserved IPs and ( 2^{(32-p)} - 5 )).
2. Evaluate an NSG rule set in priority order and name the deciding rule — and explain why a low-number Deny shadows a high-number Allow.
3. Recite the six default rules and explain why intra-VNet is allowed but inbound-from- internet is denied by default.
4. Explain stateful evaluation and why you never write a return rule.
5. Pick the next hop from an effective route table by longest-prefix match and apply the UDR > BGP > system tie-break.
6. Draw the Private Endpoint DNS override (CNAME chain into the privatelink zone) and say exactly which missing object causes a public-IP resolution.
7. Place Front Door / Application Gateway / Load Balancer at L7-global / L7-regional / L4 and say where TLS terminates and WAF runs.

Interview Q&A

Q: Walk me through how an NSG decides to allow or drop a packet. Azure keeps the rules for the packet's direction, sorts them by priority ascending — lowest number first — and evaluates top-down, stopping at the first match. That rule's access (Allow/Deny) is the decision; no later rule is consulted. So a priority-100 Deny beats a priority-200 Allow for the same packet. If no user rule matches, Azure's default rules apply: inbound allows VirtualNetwork→VirtualNetwork and AzureLoadBalancer, then denies everything; outbound allows VNet and Internet, then denies. And NSGs are stateful, so I only reason about the direction the flow originates — the return packets are permitted by connection tracking, not a second rule. If an NSG is on both the subnet and the NIC, both must allow it; the effective decision is the intersection.

Q: A VM can't reach a storage account over its Private Endpoint. The endpoint shows "approved," the NSG allows 443, the firewall is fine. What's wrong? Almost certainly DNS. Private Link works by overriding name resolution: acct.blob.core.windows.net must resolve to the private IP via the privatelink.blob.core.windows.net zone, and that zone must be linked to this VNet. I'd run nslookup acct.blob.core.windows.net from the VM — if it returns the public IP, the Private DNS zone is missing the A record or, more commonly, the VNet link is missing, so this VNet never sees the private zone. If the VM uses a custom DNS server, the other cause is that the server isn't forwarding privatelink.* to Azure DNS (168.63.129.16). The fix is the missing link or forwarder — not anything on the data path.

Q: How do you force all internet-bound traffic from a subnet through a firewall? Attach a UDR with route 0.0.0.0/0 → next-hop type VirtualAppliance, next-hop IP = the firewall's private IP, to the subnet's route table. By longest-prefix match that /0 catches everything not covered by a more specific route, and because at equal prefix length UDR beats the system route, it overrides the default 0.0.0.0/0 → Internet. I'd also add the firewall's own return path and any platform exceptions so I don't blackhole the firewall, and confirm with az network nic show-effective-route-table that the next hop is the appliance.

Q: Two routes match a destination — how does Azure choose? Longest-prefix match: the route with the most specific (longest) prefix wins, so a /32 host route beats a /24 beats 0.0.0.0/0. Only when prefix lengths are equal does the origin tie-break apply: UDR > BGP > system. That's why your UDR 0.0.0.0/0 overrides both the system default and a BGP-learned 0.0.0.0/0, and it's a hybrid-networking gotcha — a UDR can silently shadow a route you're learning from on-prem.

Q: When do you use a Private Endpoint vs a service endpoint? A service endpoint keeps traffic to a PaaS service on the Azure backbone and lets the service trust my subnet, but the resource keeps its public IP and FQDN (no DNS change) and it doesn't reach on-prem. A Private Endpoint gives the resource a private IP in my subnet, works across peering and from on-prem, is per-resource granular, and lets me disable public access entirely — at the cost of managing DNS. For a regulated, private- only estate I default to Private Endpoints; service endpoints are a lighter option when I only need backbone routing and per-subnet trust and don't need on-prem or a private IP.

Q: Why is the smallest Azure subnet a /29, and how many hosts does it give you? Azure reserves five addresses in every subnet — the network address, .1 (gateway), .2/.3 (Azure DNS mapping), and the broadcast — so usable = ( 2^{(32-p)} - 5 ). A /29 has 8 addresses, minus 5 = 3 usable; a /30 has only 4 total, which can't cover the 5 reservations, so Azure rejects anything smaller than /29.

Q: Front Door, Application Gateway, or Load Balancer — how do you choose? By layer and scope. Front Door is global L7 — anycast edge, caching, WAF, multi- region failover — for a worldwide public web app. Application Gateway is regional L7 — WAF, path/host routing, TLS — for a regional web app. Load Balancer is regional L4 — flow- hash TCP/UDP, lowest latency, internal or public — for non-HTTP or very high throughput. TLS termination and WAF live at L7 (Front Door/App Gateway), never at the L4 Load Balancer. A global app often chains them: Front Door → App Gateway → internal Load Balancer → compute.

References

• Microsoft Learn — Virtual network and subnet concepts, and the five reserved IP addresses per subnet: learn.microsoft.com/azure/virtual-network/virtual-networks-overview
• Microsoft Learn — How network security groups filter network traffic (priority, first-match, stateful, default rules): learn.microsoft.com/azure/virtual-network/network-security-groups-overview
• Microsoft Learn — Virtual network traffic routing (system routes, UDR, BGP, longest-prefix, the UDR>BGP>system selection order): learn.microsoft.com/azure/virtual-network/virtual-networks-udr-overview
• Microsoft Learn — What is Azure Private Link / Private Endpoint and Private Endpoint DNS configuration (the privatelink zones and VNet links): learn.microsoft.com/azure/private-link/private-endpoint-dns
• Microsoft Learn — Service tags overview (VirtualNetwork, Internet, AzureLoadBalancer, regionalised tags): learn.microsoft.com/azure/virtual-network/service-tags-overview
• Microsoft Cloud Adoption Framework — Hub-and-spoke network topology and the Azure Landing Zone network design.
• Microsoft Learn — Load-balancing options decision guide (Front Door vs Application Gateway vs Load Balancer vs Traffic Manager).
• RFC 1918 — Address Allocation for Private Internets (the 10/8, 172.16/12, 192.168/16 ranges) and RFC 4632 — CIDR.
• The track's own CHEATSHEET.md and GLOSSARY.md.