ACI L3out Multiple ExtEPG vs Contracts

[weylin.piegorsch]

For simplictiy, I'll refer here to L3out External EPGs by their external subnets, and I'm only asking about external subnets.

What I'm concerned about is if I start with a contract that permits all traffic from ExtEPG_0.0.0.0/0 to some EPG1, and 2yr later on the same L3out I add a new ExtEPG_10.0.0.1/32 and add another contract wtih EPG2, per longest-match anything from 10.0.0.1 will get classified into that new ExtEPG.  Does that mean, since there's no contract from that to EPG1, that EPG1 can no longer be reached by that IP?

I've read through the contract whitepaper, the ESG white paper, and the multiple ExtEPG with Overlapping Subnets whitepaper, and this question is doggedly hard to decipher from them.

weylin

[AshSe · Accepted solution]

Hi @weylin.piegorsch , please confirm if the below diagram matches your query:

As per my understanding; in both the cases, Any (0.0.0.0/0) network can communicate with the EPGs (EPG-1 & EPG-2). Having said this, we don't need a new contract. 

[weylin.piegorsch]

Thanks @AshSe .  That's close, but let me restate the question with pictures (I like your drawing ) that can more-accurately represent my concern.

If I start with this:

Everything communicates fine.  If later (possibly MUCH later) I add this:

Without adding a contract4 from ExtEPG2 to vzAny, does that mean I've now prevented 10.0.0.1/32 from initiating communication with EPG1?

This trivial example is pretty easy to manage, but I'm doing a brownfield->greenfield migration of several hundred subnets, and I'm trying to grapple with a respectable number of router ACLs that may include a wide variety of ACEs referencing off-fabric IPs and subnets.  My worry: if I have to create an ExtEPG for all of these (because I can't build an ESG for an ExtEPG), that would make for a crazy-complicated contract tree to build and manage.

[weylin.piegorsch]

@AshSe Actually... now that I've drawn that out, the picture highlights that ExtEPG2 still rides contract1 to communicate with EPG1, so there's no practical change there.  I couldn't conceptualize that without seeing it on a drawing; I'm marking your post as the solution because it led to breaking my cognitive logjam.  Thank you for that.

[AshSe]

@weylin.piegorsch I am delighted that I could contribute to your self-problem solving. From my experience, diagrams always help us to understand the problem. And, "a problem well understood is problem half-solved".

I liked your diagram presentation too. 

Cheers!!

[dainalthomas01]

Yes, if you introduce a new ExtEPG for 10.0.0.1 without a contract to EPG1, traffic from that IP will be classified under EPG2, meaning EPG1 will no longer be reachable from 10.0.0.1 due to the lack of a corresponding contract.