Lab 5: vzAny shared services

Use vzAny to model VRF-wide access to shared DNS and NTP services in ACI Simulator.

Lab 5 introduces vzAny, a VRF-wide policy attachment point. Instead of adding the same DNS and NTP contracts to web, app, and db one by one, we attach those contracts once to vzAny under prod-vrf.

The model is:

prod-vrf vzAny -> shared-dns/shared-ntp contracts -> shared-services EPG

This is a common shared-services pattern. It is useful, but powerful enough that it should be used carefully.

Target model

VRF prod-vrf

vzAny VRF-wide policy

EPG web

EPG app

EPG db

Contract shared-dns TCP/UDP 53

Contract shared-ntp UDP 123

EPG shared-services provider

What you will create

Object	Name or value
Shared-services EPG	`shared-services`
Bridge domain	`prod-bd`
Filter	`shared-dns`
DNS entries	UDP `53` and TCP `53`
Filter	`shared-ntp`
NTP entry	UDP `123`
Contract	`shared-dns`
Contract	`shared-ntp`
Provider	`shared-services` provides both contracts
Consumer	`vzAny` under `prod-vrf` consumes both contracts

Understand vzAny

vzAny represents all EPGs inside a VRF for contract purposes.

If vzAny consumes a contract, every EPG in that VRF is effectively a consumer of that contract.

That is useful for common services:

DNS
NTP
logging
monitoring
package repositories
identity services

It is risky for broad application access. If you attach a powerful contract to vzAny, you may allow more EPGs than intended.

Build the shared-services EPG

Create EPG shared-services under application profile three-tier-app.

Associate it with bridge domain prod-bd.

This EPG represents a service segment where shared infrastructure services would live in a real fabric.

Build the DNS contract

Create filter shared-dns.

Add two entries:

Protocol	Destination port
UDP	`53`
TCP	`53`

Create contract shared-dns and subject allow-shared-dns.

Attach filter shared-dns to the subject.

Make EPG shared-services provide contract shared-dns.

Build the NTP contract

Create filter shared-ntp.

Add one entry:

Protocol	Destination port
UDP	`123`

Create contract shared-ntp and subject allow-shared-ntp.

Attach filter shared-ntp to the subject.

Make EPG shared-services provide contract shared-ntp.

Attach contracts to vzAny

Open VRF prod-vrf and find vzAny.

Make vzAny consume:

shared-dns
shared-ntp

Now every EPG in prod-vrf can consume the shared DNS and NTP contracts without adding those contract relationships on each EPG.

Automation

The lab repo has an idempotent script:

./scripts/configure-aci-lab-5-vzany-shared-services.sh

The latest run returned:

ready: true
tenant_fault_count: 0
shared-services provides shared-dns and shared-ntp
vzAny consumes shared-dns and shared-ntp
DNS UDP/TCP 53 entries verified
NTP UDP 123 entry verified

Verification checklist

In APIC, check these before calling the lab complete:

EPG shared-services exists.
EPG shared-services uses bridge domain prod-bd.
Filter shared-dns exists.
Filter shared-dns has UDP destination port 53.
Filter shared-dns has TCP destination port 53.
Filter shared-ntp exists.
Filter shared-ntp has UDP destination port 123.
Contract shared-dns exists.
Contract shared-ntp exists.
EPG shared-services provides shared-dns.
EPG shared-services provides shared-ntp.
vzAny under prod-vrf consumes shared-dns.
vzAny under prod-vrf consumes shared-ntp.
Tenant lab-prod has no active faults.

What this lab teaches

You should leave Lab 5 understanding:

vzAny applies contract relationships at the VRF level.
Shared services are a good use case for vzAny.
vzAny reduces repetitive per-EPG configuration.
vzAny can accidentally broaden access if used carelessly.
DNS and NTP are practical examples of common infrastructure services.

This remains an APIC policy lab. It does not prove real DNS or NTP traffic. For packet tests, build the same shared-services pattern in EVE-NG with Linux endpoints and a real forwarding topology.