nevermind, the above post already answered ... View more

DNS labels in the VRF allows your leaf to be able to use the DNS servers to resolve domain names. Put in exactly your DNS profile name. ... View more

Q: The documentation says that for VMware integration to use a dynamic VLAN pool. How does that work with migration ? A VM on the legacy network will be on say vlan 12 and when its migrated onto the UCS it will be expecting to still be connected to VLAN 12. How do we control which EPG is mapped to which dynamic VLAN in this case ?     A:You do not control which EPG is mapped to which VLAN, it's ACI controlled. Hence the key word "dynamic", although you can "pin" a VLAN statically even if it's a dynamic pool.  However, the key to remember is that VLAN Encapsulations between ACI and end hosts is completely irrelevant to your "Legacy VLAN" that are extended/trunked between ACI and your legacy switch. Within the same EPG, if you associate VMM domains, you only need to add a static path binding for VLAN-12 as tagged.  This is the same case for any devices, not just VMM. You can have VLAN-4321 configured as 802.1P (don't use access) for a Dell rack server and then VLAN-12 tagged. Just need to make sure that you have all the correct domains associated. This is the part where "VLANs" does not matter anymore unless it's 802.1Q tag to the servers, where you would probably have to discuss this with your server admins about updating VLAN tagging.   Q: When initially setting up the ESXi servers the vSwitch wont be under ACI control as it cant be until ESXi is up and running and has an ACI controlled DVS pushed to it so what goes on with VLAN to PEG mapping here ?   A: If you are referring to ESXi management connection, it should be static path binding just like configuring any bare metal servers. The switch port should be access mode.  In fact, even when the DVS is pushed to the ESXi, it still doesn't have any mapping until you create an EPG, which will then be pushed down to the DVS as a port-group. If you are using UCS, make sure that the UCS uplinks have been correctly configured with the same VLAN pool configured in ACI   Q: On the vPC from the fabric leaves to the UCS fabric interconnects do I extend the same physical domain and VLAN pool as to the DVS ?   A: On the UCS, you do need to make sure that the uplinks have the same VLANs allowed as configured in the dynamic VLAN pool. You do not need to associate any physical domains, it should be just VMM domains. You need to make sure that LLDP or CDP (depends on your UCS version, pre 2.2(4b) you need to enable CDP, later versions support LLDP). For full detail guide between UCS and VMM, here is a good guide written by Joe  Ristaino https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/application-policy-infrastructure-controller-apic/118965-config-vmm-aci-ucs-00.html   Q: Also is it possible to reuse VLANs in different physical domains ? For VMware servers and VMs for example we might need only VLANs 100 - 200 and for IBM AIX servers VLANs 100 - 150 can I create two VLAN pools with overlapping VLANs and use them with different physical domains and still have the devices talk to each other ?   A: Yes, you can. However, generally it is not recommended unless you are using those VLANs for very specific design scenarios with dedicated hardware. In your case, by default, VLAN overlapping cannot occur if the VLANs are to be assigned to different EPGs, but on the same leaf switch, unless you use "port-local VLAN" which has its own limitations and caveats. If you have a pair of leaf switches dedicated for just VMs and another pair dedicated just for AIX, then this is not a concern at all, but make sure the AEP, VLANPools and Domains are created separately.  Again, generally speaking you do not need to worry about end-host VLANs unless tagging is required. If using VMM integration, then you just need to make sure the range is enough to cover all the VMs. ... View more

Please read the reply above yours. ... View more

For host routes behind the firewall, after moving the SVI into ACI. You can try creating static host routes for these hosts behind a firewall. The feature is under BD -> Subnets -> Right click on the subnet -> Create EndPoints Behind EPG subnet. Here is the whitepaper with additional details.   https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/2-x/L3_config/b_Cisco_APIC_Layer_3_Configuration_Guide/b_Cisco_APIC_Layer_3_Configuration_Guide_chapter_01000.pdf   Additionally in version 4.0, you can enable host-based routing on the bridge domain so that individual host routes (/32 prefixes) are advertised from the border leaf switches.   Make sure you test them in a lab environment before attempting in production. ... View more

try specifying a VRF when using the show commands via "vrf overlay-1" or whatever VRF you need to see in ACI mode. Do a "show vrf" if you don't know the format ... View more

Make sure the SVIs are up and operational on the switches. If they are not deployed to the switch, that's because there is no EPGs deployed. You can configure a dummy static path binding in lab environment to get around it.   However, in production environment, you still won't find the same SVI deployed on every single leaf switches, they are only deployed "as needed". This could be a reason why it might not be a good idea to use ACI as NTP, because your NTP address could be removed unintentionally. ... View more

try using "attach" command, rather than SSH   if you have to use SSH, try  ssh <device> -b <APIC IP>     ... View more

You can have multiple EPGs in the same application profiles. But an EPG can be a child of only one application profile at any given time. It's the same that EPG can be associated with one BD at any given time.   But you are specifically talking about application profiles, which represents a group of EPGs. You can't share EPGs between VRFs, because you can't share bridge domains between VRFs. ... View more

No, EPGs can be assigned to only one bridge domain, which can only associate with one VRF. You can share VRF and BDs though. ... View more

There are 3 ways of completely whitelist the fabric   1. vzAny, which is essentially a representation of ALL EPGs within a given VRF. You can apply both provider and consumer contracts to vzAny. This will simply allow all communication between all EPGs within the same VRF, but not to other VRFs, which requires leaking. You can always choose to apply only a consumer contract or only provider EPGs   This option is under Networking -> VRF -> EPG collection for VRF. ( This is recommended when going with application-centric, where you can do some cool tricks to help reduce TCAM resource, such as "established" flag, icmp, common infrastructure services..etc.. )   2. Under the same option from above, there is a Preferred Group Member ( 2.2(1n) ), it's "disabled" by default. If you enable that option, you can then go to each EPG and select "Include", which will then allow that EPG to communicate with any other EPGs that's also "included", within the same VRF. You can apply this to any L2/L3 EPG as well. However, there is one important caveat: if you apply this option in L3out EPG, you can't use 0.0.0.0/0, rather you'll be using 0.0.0.0/1 and 128.0.0.0/1. This is a good approach in net-centric mode.   3. Unenforced under VRF. This option has always been around since 1.0, it's a "one-click" whitelist all button. Extremely disruptive. Not usually recommended. ... View more

made some progress, but I can't seem to get the count to increase, no matter what I do to the static binding. Any idea what's wrong with the code ? session = acisession.Session( url, uid, pwd) session.login() count = session.get_event_count(url) result = session.subscribe( url =url , only_new = True ).json() if count > 0 :    print (result[ 'imdata' ][ 0 ][ 'fvRsPathAtt' ][ 'attributes' ][ 'dn' ]) ... View more