~55 min read · updated 2026-05-16

Lab 4: L3Out external connectivity model

Model ACI external connectivity with a routed domain, L3Out, external EPG, external subnet, and an internal-to-external contract.

Lab 4 introduces the ACI model for networks outside the fabric. In a real deployment, this is where ACI connects to routers, firewalls, WANs, internet edges, or shared services networks. In this simulator lab, we create the policy objects and relationships only.

The model is:

web/app/db EPGs -> internal-to-external contract -> external-networks external EPG

This teaches how APIC represents external connectivity before we move to real routed adjacencies in EVE-NG.

Target model

What you will create

ObjectName or value
Routed domainlab-routed-domain
L3Outlab-l3out
VRF associationprod-vrf
External EPGexternal-networks
External subnet0.0.0.0/0
Subnet scopeimport-security
Filterexternal-https
Filter entryTCP destination port 443
Contractinternal-to-external
Subjectallow-external-https
Internal consumersweb, app, db
External providerexternal-networks

Understand the ACI words

An L3Out is the ACI policy object for routed connectivity outside the fabric.

A routed domain is the domain type used for external routed attachment.

An external EPG is how ACI groups outside networks for policy. It is the outside-world equivalent of an internal EPG.

An external subnet classifies which external prefixes belong to that external EPG. In this lab, 0.0.0.0/0 means the general outside network model.

The import-security scope makes the external subnet relevant for security policy classification.

Build the L3Out model

Create routed domain lab-routed-domain.

Create L3Out lab-l3out inside tenant lab-prod.

Associate lab-l3out with VRF prod-vrf.

Associate lab-l3out with routed domain lab-routed-domain.

Create external EPG external-networks under lab-l3out.

Add external subnet 0.0.0.0/0 with import-security scope.

Build the external contract

Create filter external-https with TCP destination port 443.

Create contract internal-to-external with subject allow-external-https.

Attach filter external-https to the subject.

Then apply the contract relationships:

ObjectRelationship
EPG webConsumes internal-to-external
EPG appConsumes internal-to-external
EPG dbConsumes internal-to-external
External EPG external-networksProvides internal-to-external

The database outbound rule is intentionally simple for learning. In production, database outbound access is usually much tighter.

Automation

The lab repo has an idempotent script:

./scripts/configure-aci-lab-4-l3out.sh

The latest run returned:

ready: true
tenant_fault_count: 0
l3out: lab-l3out
external_epg: external-networks
external_subnet: 0.0.0.0/0
web/app/db consume internal-to-external
external-networks provides internal-to-external

Verification checklist

In APIC, check these before calling the lab complete:

  • Routed domain lab-routed-domain exists.
  • L3Out lab-l3out exists.
  • L3Out lab-l3out is tied to VRF prod-vrf.
  • L3Out lab-l3out is tied to routed domain lab-routed-domain.
  • External EPG external-networks exists.
  • External subnet 0.0.0.0/0 exists.
  • Filter external-https exists.
  • Filter external-https matches TCP destination port 443.
  • Contract internal-to-external exists.
  • EPG web consumes internal-to-external.
  • EPG app consumes internal-to-external.
  • EPG db consumes internal-to-external.
  • External EPG external-networks provides internal-to-external.
  • Tenant lab-prod has no active faults.

What this lab teaches

You should leave Lab 4 understanding:

  • L3Out is the ACI object for external routed connectivity.
  • External networks are modeled as external EPGs.
  • External subnets classify outside prefixes.
  • Internal EPGs use normal contracts to talk to external EPGs.
  • APIC policy can be valid even when the simulator has no real routing adjacency.

This lab does not prove BGP, OSPF, firewall forwarding, NAT, or packet flow. Those belong in an EVE-NG lab with NX-OSv, IOS XRv, FRR, firewall images, and Linux endpoints.