Extending EPG vs Extending BD

[rocky2024]

Dear friends,

I am struggling to understand difference between extending EPG vs extending BD in normal SINGLE POD

case-1

As i understood so far, Extending EPG means we will make EPG-10 and will add trunk ports in it (trunk port going towards Firewall for GW reachability) so if there are other EPGs then we will add those trunk ports under every EPG to have connectivity to firewall. In this case we dont need contract as we are adding trunk ports in every EPG

case-2

extending BD means, if trunk links going towards firewall  and we are making vpc or port-channel then we will select domain as L2 Bridge Domain and will make EPG-1 under Network under L2 Bridge domain and if any other EPGs like EPG-2 wants to reach GW as firewall in that case we will have contract between EPG-1 and EPG-2 to reach firewall GW

Now my questions in above cases are as follows:

Question 1) since in above both cases, fabric behaving as giant L2 switch so do we need VRF to be create under BD or no need as GW is on Firewall through trunk ports ?

Question 2) in case

-1, for example, i created one more EPG-4 with access ports towards servers and these server wants to reach firewall as gateway
so can i make contract between EPG-4 and EPG-10 to reach GW as firewall ? so we dont need extending BD concept right ?

Question 3) so if we can make things works with having contracts between EPGs then why we need extending BD concept ? i guess i know extending BD
is nothing but making trunk ports towards non-fabric switches but if we achieving same result with contracts between EPG with case-1 then
why we need extending BD concept

below is the diagram

GW-10.1.1.254                                          EPG-10            EPG-4
Firewall-----------PO----------------------ACI Fabric----------------------------Servers 10.1.1.1

Please help me to understand both cases and requirements in which scenarios?

Thank you for your time and help!!!!

[RedNectar]

Hi @rocky2024 ,

I'll answer your question in a bit, but let me first start by saying forget the concept of "Extending the BD" - it was one of those "maybe it will be useful" ideas that has caused more confusion that it was worth.

below is the diagram

GW-10.1.1.254                                          EPG-10            EPG-4
Firewall-----------PO----------------------ACI Fabric----------------------------Servers 10.1.1.1

Tip: Always best to put the diagram FIRST

I'm going to assume you want some other 10.1.1.x servers to be in EPG10, and have a contract to talk to the EPG4 servers, and both have all other traffic go to the firewall.

What you want to do is something called PBR - Policy Based Redirect. (Google it). But you'll have to change your design a bit

1. Move the default GW IP (10.1.1.254) to a BD in ACI that is linked to a VRF
2. Link both EPG4 and EPG10 to the BD
3. Create a NEW subnet between ACI and the fierwall
4. Create a contract for the traffic you want to allow between EPG4 and EPG10, and re-direct all other traffic to the firewall

Alternatively, you could create a L3Out - with a similar approach

1. Move the default GW IP (10.1.1.254) to a BD in ACI that is linked to a VRF
2. Link both EPG4 and EPG10 to the BD
3. Create an L3Out - this will require NEW subnet between ACI and the fierwall
4. Create a contract for the traffic you want to allow between EPG4 and EPG10
5. Create a contract to allow other traffic beween EPG4 and the hosts on the other side of the firewall
6. Create a contract to allow other traffic beween EPG10 and the hosts on the other side of the firewall

Now - to your commentary:

As i understood so far, Extending EPG means we will make EPG-10 and will add trunk ports in it (trunk port going towards Firewall for GW reachability) so if there are other EPGs then we will add those trunk ports under every EPG to have connectivity to firewall. 

Thats one way to do it. If you add EPG/VLAN mappings to the AAEP, it is a lot simpler, you won't have to add every trunk to every EPG, you'll just add every EPG/VLAN combo to the AAEP and the trunks will take care of themselves.

In this case we dont need contract as we are adding trunk ports in every EPG

What you described above is a L2 implementation, to the concepts of contracts doesn't really come into the picture - all traffic within an EPG will be permitted, much like a VLAN today, and all traffic between EPGs will go via the default gateway, in your case a Firewall.  In this scenario you are using very expensive ACI equipment to do something you could have done much more cheaply with ordinary switches. The only advantage ACI is giving you is a central point of cofiguration.

extending BD means, if trunk links going towards firewall  and we are making vpc or port-channel then we will select domain as L2 Bridge Domain and will make EPG-1 under Network under L2 Bridge domain and if any other EPGs like EPG-2 wants to reach GW as firewall in that case we will have contract between EPG-1 and EPG-2 to reach firewall GW

Like I said above, this is not a good idea. But in your implementation, it would behave just like your case  #1 - no contract needed for any hosts in the same VLAN (because L2EPGs are bound to a SINGLE VLAN), and no contract between VLANs because the FW takes care of it.

And your questions

Question 1) since in above both cases, fabric behaving as giant L2 switch so do we need VRF to be create under BD or no need as GW is on Firewall through trunk ports ?

No. You can create BDs without a VRF in v4.2(2f). I just tried it. I have a suspicion you used not be able to do that. 

Question 2) in case-1, for example, i created one more EPG-4 with access ports towards servers and these server wants to reach firewall as gateway so can i make contract between EPG-4 and EPG-10 to reach GW as firewall ? so we dont need extending BD concept right ?

1. No, you can't make a contract that will have any effect if all traffic is going to the firewall and you haven't enabled routing (to enable routing you'll need to have a VRF, and make the default GW an ACI BD or EPG IP)

2. Correct, you NEVER need extending BD concept anywhere.

Question 3) so if we can make things works with having contracts between EPGs then why we need extending BD concept ?

We don't. Forget that idea

I hope this helps

---

Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem

---

[rocky2024]

Hello RedNectar,

Thats one way to do it. If you add EPG/VLAN mappings to the AAEP, it is a lot simpler, you won't have to add every trunk to every EPG, you'll just add every EPG/VLAN combo to the AAEP and the trunks will take care of themselves.

---"i didnt understood what you mean by mapping to AAEP (i know concept) and trunks will take care of themselves"

No. You can create BDs without a VRF in v4.2(2f). I just tried it. I have a suspicion you used not be able to do that.

---" but i guess we are mapping vrf to BD even in the case of pure L2 BD else traffic will land in global routing table in ACI fabric or traffic will not reach to specific vrf in upstream devices right ? "

[RedNectar]

---"i didnt understood what you mean by mapping to AAEP (i know concept) and trunks will take care of themselves"

If you map EPG/VLAN IDs to EPGs, (Via Fabric > Access Policies > Policies > Global Polies > Attachaable Access Entity Profiles > Your_AAEP [+] Application EPGs then ANY port that is in the Access Policy Chain ABOVE the AAEP will automatically feed all packets on that VLAN into that EPG - you wil NOT have to go to the EPG and add Static Ports.

Here's one I cooked earlier!

---" but i guess we are mapping vrf to BD even in the case of pure L2 BD else traffic will land in global routing table in ACI fabric or traffic will not reach to specific vrf in upstream devices right ? "

No - with pure L2 there is no routing table. Everything is "routed" by MAC address. The upstream VRFs are local to the upstream devices.

However I don't believe your case will NOT be pure L2 - I recall you want some L3 to talk to the Firewall, so you'll need one BD at least linked to the VRF. 

[rocky2024]

Hello,

However I don't believe your case will NOT be pure L2 - I recall you want some L3 to talk to the Firewall, so you'll need one BD at least linked to the VRF. 

---- yes correct GW is on firewall. so in case of L2 BD also, we need to add VRF under BD ? 

i was under impression that if its L2 BD then we dont need vrf under BD

if BD is L3 i.e. GW is on fabric then we can add vrf under BD

so you mean to say, any kind of traffic in fabric L2 or L3, will be part of some vrf irrespective whether BD is L2 or L3..? 

for example, if GW is outside of fabric, lets say on Cisco ASR9k in GRT (global routing table) and EPG servers are having default route to ASR9K SVI i.e GW for them so even in this case also, fabric BD will have vrf ????

traffic will hit in GRT on ASR9K ... diagram as below:

ASR9k (GW SVI )-----Leaf------Spine------Leaf ---------Server-1

[rocky2024]

Hello

Anyone to solve my query pls on above?

Thank you...