Let's say we have EPG1 and EPG2 in VRF1 and EPG3 and EPG4 in VRF2 using a contract called C1, and the scope = context.

• EPG1 provides and EPG2 consumes contract C1

• EPG3 provides and EPG4 consumes contract C1

In this example all four EPGs share the same contract, but two of them are in one Virtual Routing and Forwarding (VRF) instance (also known as a context or private network) and two of them in the other VRF. The contract is applied only between EPG1 and EPG2, and then separately between EPG3 and EPG4. The contract is limited to whatever the scope is, which in this case is the VRF.

The same thing applies if the scope = application profile. If two application profiles have EPGs and if the scope = application profile, then the contract is enforced on EPGs in their application profiles.

Below you see an APIC GUI screenshot of two contracts.

One contract is for web-to-app communication, which has a scope of application profile. The app-to-db contract has a scope of VRF. The app1 and app2 applications profiles are in the same VRF. Each application profile contains EPGs.

Because the scope of the contract app-to-db is enforced at the VRF level, and both application profiles belong to the same VRF, all consumers of the app-to-db contract are allowed to communicate with its provider EPGs.

• EPG-app1-db can communicate bi-directionally with EPG-app1-app

• EPG-app2-db can communicate bi-directionally with EPG-app2-app

• EPG-app1-db can communicate bi-directionally with EPG-app2-app

• EPG-app2-db can communicate bi-directionally with EPG-app1-app

The next pairs of endpoints using the web-to-app contracts with a scope of application-profile allow only the provider and consumers of the contract to communicate within that application profile.

• EPG-app1-app can communicate with EPG-app1-web

• EPG-app2-app can communicate with EPG-app2-web

Unlike those above, the app and db EPGs cannot communicate outside of their application profiles.