11-14-2021 08:31 AM
Hey Guys,
Just wanted to know something about ACI contracts. Let's say we have two application profile and each profile is has one EPG and multiple uEPG. Also Application profile == Bridge Domain (EPG vise).
Now if we apply vzAny contract for that VRF and contract is allow all with scope == Application Profile. Will that work. I'm aware that TCAM utilization will go high, butt wondering if it'll work.
what we are looking for is Network Centric how a Firewall works.
Traffic between EPG inside a BD should not be blocked but between two EPG from diff BD (Diff Subnet) should be.
Solved! Go to Solution.
11-15-2021 02:56 AM
Hi @OmkarPol52290 ,
Yeah - that "provider EPG shared subnet" is tricky.
So here's the RedNectar version of what that says.
Firstly, (Fun Fact) you don't HAVE to define subnets on the Bridge Domain. You can put the subnet on the EPG instead. In fact you can have subnets (same or different) on both BDs and EPGs - but at the end of the day they end up being represented in the switches as SVI interfaces anyway. Cisco has just always said "Put the subnet on the BD" - without talking about the fact that you CAN put it on the EPG instead.
Secondly. EPGs are allocated a pcTag that uniquely identifies the EPG within a VRF = the same pcTag is used over and over in different VRFs.
This is no problem while all EPGs are in the same VRF. But let's say you have EPG1/VRF1 with pcTag=30000. And EPG2/VRF2 with pcTag=30000 as well. But like the quote says "In the case of shared services using inter-VRF contracts" you could end up with EPG1/VRF1 (pcTag=30000) providing services to another EPG in VRF2. How does ACI distinguish between EPG1/VRF1 with pcTag=30000 and EPG2/VRF2 with pcTag=30000 when applying policy - ALL policy is applied based on pcTags. NOT pcTag+VRF.
So Cisco had to find away around this problem. And they did it by defining all pcTags <16384 as being GLOBALLY unique, rather than unique to the VRF
And as it turns out, policy is ALWAYS applied from the consumer of the contracts perspective - give that the consumer sends the TCP SYN packet to establish a connection, this makes sense.
And when you apply a contract between two VRFs, Cisco automatically changes the pcTag of the provider EPG - but to do this, it needs an IP subnet for the EPG. And so, "you must define the provider EPG shared subnet under the EPG in order to properly derive the pcTag (classification)"
Now. As to WHY the subnet has to be put on the EPG, rather than just declaring the subnet as "Shared between VRFs" at the BD level? I do remember reading why that is once, but have forgotten. Which means I probably didn't undersigned the logic!
Re:
So consider we have 3 subnets
192.168.10.x/24 - VLAN 10
192.168.20.x/24 - VLAN 20
192.168.30x/24- VLAN 30Now if I create an AP for each subject and config a base EPG and uEPG and allow all (newly created) contract with scope application profile. Now it only needs to allow communication inside the subnet but not between subnets.
That logic sounds good - but I haven't actually TESTED it
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.
11-14-2021 11:17 AM
Hi @OmkarPol52290 ,
I don't' have time to do a comprehensive answer, but:
Now if we apply vzAny contract for that VRF and contract is allow all with scope == Application Profile. Will that work.
Depending what the actual contract is (I'd suggest creating your OWN contract rather than using the default contract from the common tenant) I don't see why that wouldn't work.
I'm aware that TCAM utilization will go high,
I'm curious about this. Why?
butt wondering if it'll work.
Like I said, I don't see why not (but TBH I haven't tested it)
what we are looking for is Network Centric how a Firewall works.
Footnote: (Wish I had more time to think this through - @Sergiu.Daniluk might jump on this)
Perhaps you should look at the new ESG construction that came with ACI v5.x (doesn't work on 1st generation switches) - here you can apply policy to a collection of EPGs based on IP subnet
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.
11-14-2021 08:06 PM
Hey @RedNectar ,
So consider we have 3 subnets
192.168.10.x/24 - VLAN 10
192.168.20.x/24 - VLAN 20
192.168.30x/24- VLAN 30
Now if I create an AP for each subject and config a base EPG and uEPG and allow all (newly created) contract with scope application profile. Now it only needs to allow communication inside the subnet but not between subnets.
Also I didn't get this part -
In the case of shared services using inter-VRF contracts, you must define the provider EPG shared subnet under the EPG in order to properly derive the pcTag (classification) of the destination from the consumer (vzAny) side. If you are migrating from a BD-to-BD shared services configuration, where both the consumer and provider subnets are defined under bridge domains, to vzAny acting as a shared service consumer, you must take an extra configuration step where you add the provider subnet to the EPG with the shared flags at minimum.
Link for what I said is here - https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/b_KB_Use_vzAny_to_AutomaticallyApplyCommunicationRules_toEPGs.html
Reason for uEPG is how we have object-groups in firewall.
11-14-2021 08:09 PM
Hey sorry there was a typo,
This was to your query as to why TCAM utilisation will be high. More TCAM entries will be created.
Now if I create an AP for each subnet and config a base EPG
11-15-2021 02:56 AM
Hi @OmkarPol52290 ,
Yeah - that "provider EPG shared subnet" is tricky.
So here's the RedNectar version of what that says.
Firstly, (Fun Fact) you don't HAVE to define subnets on the Bridge Domain. You can put the subnet on the EPG instead. In fact you can have subnets (same or different) on both BDs and EPGs - but at the end of the day they end up being represented in the switches as SVI interfaces anyway. Cisco has just always said "Put the subnet on the BD" - without talking about the fact that you CAN put it on the EPG instead.
Secondly. EPGs are allocated a pcTag that uniquely identifies the EPG within a VRF = the same pcTag is used over and over in different VRFs.
This is no problem while all EPGs are in the same VRF. But let's say you have EPG1/VRF1 with pcTag=30000. And EPG2/VRF2 with pcTag=30000 as well. But like the quote says "In the case of shared services using inter-VRF contracts" you could end up with EPG1/VRF1 (pcTag=30000) providing services to another EPG in VRF2. How does ACI distinguish between EPG1/VRF1 with pcTag=30000 and EPG2/VRF2 with pcTag=30000 when applying policy - ALL policy is applied based on pcTags. NOT pcTag+VRF.
So Cisco had to find away around this problem. And they did it by defining all pcTags <16384 as being GLOBALLY unique, rather than unique to the VRF
And as it turns out, policy is ALWAYS applied from the consumer of the contracts perspective - give that the consumer sends the TCP SYN packet to establish a connection, this makes sense.
And when you apply a contract between two VRFs, Cisco automatically changes the pcTag of the provider EPG - but to do this, it needs an IP subnet for the EPG. And so, "you must define the provider EPG shared subnet under the EPG in order to properly derive the pcTag (classification)"
Now. As to WHY the subnet has to be put on the EPG, rather than just declaring the subnet as "Shared between VRFs" at the BD level? I do remember reading why that is once, but have forgotten. Which means I probably didn't undersigned the logic!
Re:
So consider we have 3 subnets
192.168.10.x/24 - VLAN 10
192.168.20.x/24 - VLAN 20
192.168.30x/24- VLAN 30Now if I create an AP for each subject and config a base EPG and uEPG and allow all (newly created) contract with scope application profile. Now it only needs to allow communication inside the subnet but not between subnets.
That logic sounds good - but I haven't actually TESTED it
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide