ACI EPG to DOMAIN ISSUE UPDATE ============================ The EPG was not binded to the Physical domain & yet the communication began to work because of a bug as mentioned in this Cisco Forum. In later releases it may be fixed. community.cisco.com/t5/application-centric-infrastructure/epg-without-a-physical-domain-association/td-p/4462831
Please make a video on bridge domain with Good analogy. That would be really helpful. Especially with a epg mapped to one BD with multiple subnets and Explain why is that scenario needed. Thank you
It was an amazing video and helped me a lot. please create a video for a simple application like a web server and it's database and the EPGs for each one of them and show the communication end to end
So, at the end with the "re-using" All the config guides I've seen so far, made a Switch Profile for 1 switch and an Interface Profile for 1 Port. Now, if I have a Fabric with 100+ Leafs and thousands of Servers, I'd be doing profiles for months and whenever there's a new server and/or a new leaf, I'd clicking through tabs and profiles for days. Does that mean it's possible to create 1 "master" profile to use for all Leafs and another "master" profile for all ports on a leaf? Or maybe a 'few' general ones depending on what you want to connect and you're good to go? If every (bare metal) server and/or port needs its own profile, it would be pure madness in a bigger fabric. I mean, normally, ports are all configured the same/similarly (for standard servers) and only the VLANs change (or now the EPG deployment on a port).
Normally you will not have to go thru all this again & again, you have a quick way to create profiles in ACI as well. Moreover the problem mainly comes between the VPC & NON VPC ports(Normal Access/Trunk). If you dedicate everything as NON VPC & your server team is OK with it then a master profile can work. But I know that somewhere you're going to need VPC's then it will be a little hasle removing those interfaces from profiles & creating a VPC profile for them.
@@doctor.networks Thank you for the reply! The networking team in our company and I are still pretty "old-school". We're using legacy NX-OS without anything fancy like VXLAN, so all of this looks extremely unintuitive to me. Right now, when the server team tells us they need 4 channeled ports, we SSH on the the VPC pairs in the rack, copy our VPC template over the ports, allow the VLANs they need and that's pretty much it. And when the server gets removed later on, we simply default the port. Having to do a switch profile for every leaf and then a new interface profile for every used port seems like a *lot* of extra work rather than simplifying it. After having done all the profiles and policies and whatnot, you then also still need to go in the EPGs menu and link all the needed EPGs to the ports. (Which can be a whole lot, like we have server that access 20-30 VLANs, so instead of "sw trunk allowed vlan 100-130", it's going through 30 individual EPGs menus now...?) And when the server gets decommissioned, you have to find and delete profiles (among the hundreds or thousands others) and remove the static bindings in the EPGs. You have every switch and port accessible from the same system, which is super cool, but if having to go through a dozens of menus takes more time than SSH-ing to the switches and configuring the ports manually, something about the whole ACI things seems odd to me. -- We've ordered a lab for next month and I'll be trying your videos to build it myself and experiment a little before having a session with our cisco rep over what the best approach for our usecase and current hiearachy is.
ACI EPG to DOMAIN ISSUE UPDATE
============================
The EPG was not binded to the Physical domain & yet the communication began to work because of a bug as mentioned in this Cisco Forum. In later releases it may be fixed.
community.cisco.com/t5/application-centric-infrastructure/epg-without-a-physical-domain-association/td-p/4462831
Superb explanation, thanks for sharing
You are welcome brother
Please make a video on bridge domain with Good analogy. That would be really helpful. Especially with a epg mapped to one BD with multiple subnets and Explain why is that scenario needed. Thank you
Noted, will try to make a video on it soon.
@@doctor.networks Thankyou
It was an amazing video and helped me a lot.
please create a video for a simple application like a web server and it's database and the EPGs for each one of them and show the communication end to end
Thanks man glad it helped. I'll have to see how I can do a lab which involves DB & WEB
So, at the end with the "re-using"
All the config guides I've seen so far, made a Switch Profile for 1 switch and an Interface Profile for 1 Port.
Now, if I have a Fabric with 100+ Leafs and thousands of Servers, I'd be doing profiles for months and whenever there's a new server and/or a new leaf, I'd clicking through tabs and profiles for days.
Does that mean it's possible to create 1 "master" profile to use for all Leafs and another "master" profile for all ports on a leaf? Or maybe a 'few' general ones depending on what you want to connect and you're good to go? If every (bare metal) server and/or port needs its own profile, it would be pure madness in a bigger fabric.
I mean, normally, ports are all configured the same/similarly (for standard servers) and only the VLANs change (or now the EPG deployment on a port).
Normally you will not have to go thru all this again & again, you have a quick way to create profiles in ACI as well.
Moreover the problem mainly comes between the VPC & NON VPC ports(Normal Access/Trunk). If you dedicate everything as NON VPC & your server team is OK with it then a master profile can work. But I know that somewhere you're going to need VPC's then it will be a little hasle removing those interfaces from profiles & creating a VPC profile for them.
@@doctor.networks Thank you for the reply!
The networking team in our company and I are still pretty "old-school". We're using legacy NX-OS without anything fancy like VXLAN, so all of this looks extremely unintuitive to me.
Right now, when the server team tells us they need 4 channeled ports, we SSH on the the VPC pairs in the rack, copy our VPC template over the ports, allow the VLANs they need and that's pretty much it.
And when the server gets removed later on, we simply default the port.
Having to do a switch profile for every leaf and then a new interface profile for every used port seems like a *lot* of extra work rather than simplifying it. After having done all the profiles and policies and whatnot, you then also still need to go in the EPGs menu and link all the needed EPGs to the ports. (Which can be a whole lot, like we have server that access 20-30 VLANs, so instead of "sw trunk allowed vlan 100-130", it's going through 30 individual EPGs menus now...?)
And when the server gets decommissioned, you have to find and delete profiles (among the hundreds or thousands others) and remove the static bindings in the EPGs.
You have every switch and port accessible from the same system, which is super cool, but if having to go through a dozens of menus takes more time than SSH-ing to the switches and configuring the ports manually, something about the whole ACI things seems odd to me.
--
We've ordered a lab for next month and I'll be trying your videos to build it myself and experiment a little before having a session with our cisco rep over what the best approach for our usecase and current hiearachy is.
thank you, keep going on
Welcome, Yes sure will do 🙂
ACI is new modern network solution, please help do for more.
Yes bro working on 2 new videos on ACI