About RedNectar

RedNectar · ‎01-15-2019

Hi e.yasnitskiy , I had another shot at this today and started by removing my old config which was a hotch-potch of some old config I had there. This time is was a breexe, and I documented if for you completely here: https://community.cisco.com/t5/data-center-blogs/aci-transit-routing-in-a-single-vrf/ba-p/3779940 BTW - when you were doing the pings from your router, did you specify the source interface? Just a thought! I think that was my problem when I was fiddling last time. Anyway - if you follow the blog, you should have better success next time. Let me know if you succeed.

RedNectar · ‎01-15-2019

Transit routing within a VRF is reasonably straight forward, but when I tried to reproduce a problem described in here, I found that need to a little careful to be sure that the routes from one router are passed on to the other. Here's the toplogy I built A single tenant has a single VRF and two External Routed Networks (L3Outs) although the same result could have been achieved using a single L3Out. An Access Policy Chain was set up to allow VLAN 2304 to be configured as an SVI on interface Ethernet1/1 of the left ACI Leaf (Leaf 101) and for VLAN 2308 to be configured as an SVI on interface Ethernet1/1 of on the right ACI Leaf ( Leaf 102 ). First I created a Tenant called Transit with a VRF called DC_VRF Then I created the first of the two L3Outs. I called it LeftRtr_L3Out and assigned it regular OSPF area 0.0.0.4 and made sure it was linked to the DC_VRF and the appropriate External Routed Domain that held the interface configuation for Ethernet 1/1 and a VLAN pool with VLAN 2304 I give it a Logical Node profile pointing to leaf 101 and an SVI Interface for VLAN 2304 on Ethernet 1/1 on Leaf 101. I used an IP address of 192.168.4.2/24 as I already had a router attached with an IP address of 192.168.4.1/24 on its G0/1.2304 sub-interface. Next, before OSPF could begin I needed to add a Network, or L3EPG to describe which source IP addresses would be permitted to enter the ACI fabric from the external router. I kept it simple and defined my network as 0.0.0.0/0 - in other words all source IPs were permitted. At this stage, it is appropriate to look at the external router configuration. The external router was configured with a VRF to contain the configuration of the LeftRouter - here's the VRF config: ip vrf LeftRouter ! interface GigabitEthernet0/0.2040 encapsulation dot1Q 2040 ip vrf forwarding LeftRouter ip address 192.168.40.1 255.255.255.0 ! interface GigabitEthernet0/1.2304 encapsulation dot1Q 2304 ip vrf forwarding LeftRouter ip address 192.168.4.1 255.255.255.0 ! router ospf 4 vrf LeftRouter router-id 1.1.1.14 passive-interface GigabitEthernet0/0.2040 network 192.168.0.0 0.0.255.255 area 0.0.0.4 And by now the LeftRouter and Leaf101 have become neighbors: And on the router: LeftRouter#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.0.0.4 1 FULL/DR 00:00:38 192.168.4.2 GigabitEthernet0/1.2304 Now things get tricky. Recall from the original diagram that we want Leaf 101 to advertise the 192.168.80.0/24 subnet to the LeftRouter. So we have to tell Leaf101 to advertise this route manually. Here are the steps. Create a Match Rule for Route Maps (in your Tenant, navigate to Networking > External Routed Networks >+ Create Match Rule for a Route Map) I Called mine192.168.80:24 and added a Match Prefix of 192.168.80.0/24 Now to tell Leaf101 you want to advertise this prefix, configure the default-export route map and set it to Match Routing Policy Only, and link it to the Match Rule you created earlier. (in your Tenant, navigate to Networking > External Routed Networks > LeftRtr_L3Out > Route Maps/Profiles >+ Create Route Map/Profile ) Name the profile default-export (or pick it from the drop down list) and set the Type to Match Routing Policy Only Add a context - I called mine 192.168.80.0:24_RtCtrlCtx - and choose the match rule (192.168.80:24 in my case) you created earlier. Bingo. Your leaf101 is now ready to advertise the 192.168.80.0/24 subnet - except for one small problem - it hasn't learned about that subnet from the RightRouter yet - so now it's time to "Rinse and Repeat" as they say and repeat the above steps for the Right Router and the route map for the 192.168.40.0/24 subnet. But of course you won't be able to pass any traffic until there is a contract in place. I simply set one of the L3EPGs to provide the default contract in the common tenant, and the other to consume it. Finally, some testing from the routers to check that the transit routing is working. First the LeftRouter (note that since I didn't bother advertising the rotues connecting the routers to the fabric, I had to specify the source interface) LeftRouter#show ip route vrf LeftRouter | include / 1.0.0.0/32 is subnetted, 1 subnets O 1.0.0.4 [110/2] via 192.168.4.2, 02:43:00, GigabitEthernet0/1.2304 192.168.4.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.4.0/24 is directly connected, GigabitEthernet0/1.2304 L 192.168.4.1/32 is directly connected, GigabitEthernet0/1.2304 192.168.40.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.40.0/24 is directly connected, GigabitEthernet0/0.2040 L 192.168.40.1/32 is directly connected, GigabitEthernet0/0.2040 O E2 192.168.80.0/24 [110/1] via 192.168.4.2, 00:11:01, GigabitEthernet0/1.2304 LeftRouter#ping vrf LeftRouter 192.168.80.1 source GigabitEthernet0/0.2040 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.80.1, timeout is 2 seconds: Packet sent with a source address of 192.168.40.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms Trust me - the RightRouter is the same :) . Here's the config for the Right Router just for completeness sake: ip vrf RightRouter ! interface GigabitEthernet0/0.2080 encapsulation dot1Q 2080 ip vrf forwarding RightRouter ip address 192.168.80.1 255.255.255.0 ! interface GigabitEthernet0/2.2308 encapsulation dot1Q 2308 ip vrf forwarding RightRouter ip address 192.168.8.1 255.255.255.0 ! router ospf 8 vrf RightRouter router-id 1.1.1.18 passive-interface GigabitEthernet0/0.2080 network 192.168.0.0 0.0.255.255 area 0.0.0.8 And just in case you want to do it yourself, h ere is the complete Tenant configuation. If you want to copy it to a text file, you can right-click on a tenant, choose Post and select the text file as the source and /uni as the destination. <?xml version="1.0" encoding="UTF-8"?> <imdata totalCount="1"> <fvTenant annotation="" descr="" dn="uni/tn-Transit" name="Transit" nameAlias="" ownerKey="" ownerTag=""><vnsSvcCont annotation=""/> <rtctrlSubjP annotation="" descr="" name="192.168.40.0:24" nameAlias=""><rtctrlMatchRtDest aggregate="no" annotation="" descr="" ip="192.168.40.0/24" name="" nameAlias=""/></rtctrlSubjP> <rtctrlSubjP annotation="" descr="" name="192.168.80.0:24" nameAlias=""><rtctrlMatchRtDest aggregate="no" annotation="" descr="" ip="192.168.80.0/24" name="" nameAlias=""/></rtctrlSubjP> <l3extOut annotation="" descr="" enforceRtctrl="export" name="RightRtr_L3Out" nameAlias="" ownerKey="" ownerTag="" targetDscp="unspecified"> <rtctrlProfile annotation="" descr="" name="default-export" nameAlias="" ownerKey="" ownerTag="" type="global"> <rtctrlCtxP action="permit" annotation="" descr="" name="192.168.40.0:24_RtCtrlCtx" nameAlias="" order="0"><rtctrlRsCtxPToSubjP annotation="" tnRtctrlSubjPName="192.168.40.0:24"/></rtctrlCtxP> </rtctrlProfile><ospfExtP annotation="" areaCost="1" areaCtrl="redistribute,summary" areaId="0.0.0.8" areaType="regular" descr="" multipodInternal="no" nameAlias=""/><l3extRsL3DomAtt annotation="" tDn="uni/l3dom-T8:WAN-ExtL3Dom"/><l3extRsEctx annotation="" tnFvCtxName="DC_VRF"/> <l3extLNodeP annotation="" configIssues="" descr="" name="Leaf102_NodeProf" nameAlias="" ownerKey="" ownerTag="" tag="yellow-green" targetDscp="unspecified"> <l3extRsNodeL3OutAtt annotation="" configIssues="" rtrId="1.0.0.8" rtrIdLoopBack="yes" tDn="topology/pod-1/node-102"><l3extInfraNodeP annotation="" descr="" fabricExtCtrlPeering="no" fabricExtIntersiteCtrlPeering="no" name="" nameAlias="" spineRole=""/></l3extRsNodeL3OutAtt> <l3extLIfP annotation="" descr="" name="VALN2308_IntProf" nameAlias="" ownerKey="" ownerTag="" tag="yellow-green"> <ospfIfP annotation="" authKeyId="1" authType="none" descr="" name="" nameAlias=""><ospfRsIfPol annotation="" tnOspfIfPolName=""/></ospfIfP><l3extRsPathL3OutAtt addr="192.168.8.2/24" annotation="" autostate="disabled" descr="" encap="vlan-2308" encapScope="local" ifInstT="ext-svi" ipv6Dad="enabled" llAddr="::" mac="00:22:BD:F8:19:FF" mode="regular" mtu="1500" tDn="topology/pod-1/paths-102/pathep-[eth1/1]" targetDscp="unspecified"/><l3extRsNdIfPol annotation="" tnNdIfPolName=""/><l3extRsIngressQosDppPol annotation="" tnQosDppPolName=""/><l3extRsEgressQosDppPol annotation="" tnQosDppPolName=""/></l3extLIfP> </l3extLNodeP> <l3extInstP annotation="" descr="" exceptionTag="" floodOnEncap="disabled" matchT="AtleastOne" name="0.0.0.0:0_L3EPG" nameAlias="" prefGrMemb="exclude" prio="unspecified" targetDscp="unspecified"><l3extSubnet aggregate="" annotation="" descr="" ip="0.0.0.0/0" name="" nameAlias="" scope="import-security"/><fvRsCustQosPol annotation="" tnQosCustomPolName=""/><fvRsCons annotation="" prio="unspecified" tnVzBrCPName="default"/></l3extInstP> </l3extOut> <l3extOut annotation="" descr="" enforceRtctrl="export" name="LeftRtr_L3Out" nameAlias="" ownerKey="" ownerTag="" targetDscp="unspecified"> <rtctrlProfile annotation="" descr="" name="default-export" nameAlias="" ownerKey="" ownerTag="" type="global"> <rtctrlCtxP action="permit" annotation="" descr="" name="192.168.80:24_RtCtrlCtx" nameAlias="" order="0"><rtctrlRsCtxPToSubjP annotation="" tnRtctrlSubjPName="192.168.80.0:24"/></rtctrlCtxP> </rtctrlProfile><ospfExtP annotation="" areaCost="1" areaCtrl="redistribute,summary" areaId="0.0.0.4" areaType="regular" descr="" multipodInternal="no" nameAlias=""/><l3extRsL3DomAtt annotation="" tDn="uni/l3dom-T4:WAN-ExtL3Dom"/><l3extRsEctx annotation="" tnFvCtxName="DC_VRF"/> <l3extLNodeP annotation="" configIssues="" descr="" name="Leaf101_NodeProf" nameAlias="" ownerKey="" ownerTag="" tag="yellow-green" targetDscp="unspecified"> <l3extRsNodeL3OutAtt annotation="" configIssues="" rtrId="1.0.0.4" rtrIdLoopBack="yes" tDn="topology/pod-1/node-101"><l3extInfraNodeP annotation="" descr="" fabricExtCtrlPeering="no" fabricExtIntersiteCtrlPeering="no" name="" nameAlias="" spineRole=""/></l3extRsNodeL3OutAtt> <l3extLIfP annotation="" descr="" name="VLAN2304_IntPorf" nameAlias="" ownerKey="" ownerTag="" tag="yellow-green"> <ospfIfP annotation="" authKeyId="1" authType="none" descr="" name="" nameAlias=""><ospfRsIfPol annotation="" tnOspfIfPolName=""/></ospfIfP><l3extRsPathL3OutAtt addr="192.168.4.2/24" annotation="" autostate="disabled" descr="" encap="vlan-2304" encapScope="local" ifInstT="ext-svi" ipv6Dad="enabled" llAddr="::" mac="00:22:BD:F8:19:FF" mode="regular" mtu="1500" tDn="topology/pod-1/paths-101/pathep-[eth1/1]" targetDscp="unspecified"/><l3extRsNdIfPol annotation="" tnNdIfPolName=""/><l3extRsIngressQosDppPol annotation="" tnQosDppPolName=""/><l3extRsEgressQosDppPol annotation="" tnQosDppPolName=""/></l3extLIfP> </l3extLNodeP> <l3extInstP annotation="" descr="" exceptionTag="" floodOnEncap="disabled" matchT="AtleastOne" name="0.0.0.0:0_L3EPG" nameAlias="" prefGrMemb="exclude" prio="unspecified" targetDscp="unspecified"><fvRsProv annotation="" matchT="AtleastOne" prio="unspecified" tnVzBrCPName="default"/><l3extSubnet aggregate="" annotation="" descr="" ip="0.0.0.0/0" name="" nameAlias="" scope="import-security"/><fvRsCustQosPol annotation="" tnQosCustomPolName=""/></l3extInstP> </l3extOut><fvRsTenantMonPol annotation="" tnMonEPGPolName=""/> <fvCtx annotation="" bdEnforcedEnable="no" descr="" knwMcastAct="permit" name="DC_VRF" nameAlias="" ownerKey="" ownerTag="" pcEnfDir="ingress" pcEnfPref="enforced"><fvRsVrfValidationPol annotation="" tnL3extVrfValidationPolName=""/><vzAny annotation="" descr="" matchT="AtleastOne" name="" nameAlias="" prefGrMemb="disabled"/><fvRsOspfCtxPol annotation="" tnOspfCtxPolName=""/><fvRsCtxToEpRet annotation="" tnFvEpRetPolName=""/><fvRsCtxToExtRouteTagPol annotation="" tnL3extRouteTagPolName=""/><fvRsBgpCtxPol annotation="" tnBgpCtxPolName=""/></fvCtx> </fvTenant> </imdata> Red Nectar aka Chris Welsh

RedNectar · ‎01-14-2019

The most likely explanation is that there is no logical policy using this port yet - ie, none of the following condidtions has been met: The port has not been configured with a static mapping to an End Point Group (EPG) The port has not been configured with a static mapping to an External Routed Network's Logical Interface Profile (L3Out Interface Profile) No hypervisors have been discovered on that port via LLDP or Opflex The port is part of a VPC that has not met one of the above 3 conditions 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

RedNectar · ‎01-13-2019

HI e.yasnitskiy, Just a follow up - this is still unresolved, but I did get a chance to set this up in the lab last week, and was able to replicate your results. I had hoped that I might have been able to tell you now how to fix it, but unfortuntely I ran out of time. To me this seems like it should be fundamentally easy, and I'm sure I've done it before. It may be a bug in the 3.2(3o) code.

RedNectar · ‎01-05-2019

Hi , I don't have time to do a detailed reply just now, but two things: Have youy read the Cisco APIC Layer 3 Networking Configuration Guide? In particular, have you made sure that your L3EPGs have the Import and Export route control options set? Let me know if you need more help 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

RedNectar · ‎01-05-2019

Hi sbdladla1 , Sorry for the slow reply - I've been in study mode for the past week and completely ignored anything else. Let's look at your concerns, but first I have to make some assumptions about your design - you haven't exactly said what your design is apart from "we use one common voice system for all our customers. we separate each customer by VLAN,but one voice VLAN for all of them. from customers work space and offices" From the point of view of trying to solve your problem, I don't really have enough information. Does every customer have a dedicated phyical link? Do your custmers send traffic on more than two vlans (voice + data)? But to your specific concerns: "there fact that I can not have one EPG/Physical port running more than one subnet in it" Yes you can. You have to make sure that each subnet is tagged with a different VLAN ID. That's it. Nothing different than it's ever been before. If the same VLAN tag is used more than once on the same switch, you should look for a tutorial on how to use the Per-port-VLAN feature. "You mean I can not have an EPG that allow all subnet of a tenant/bridge-domain in one epg" Yes you can. You can have multiple subnets in one bridge domain, and if you wish those subnets can be in the same EPG - or you can separate each subnet into its own EPG if you wish. Did you check out any ACI configuration tutorials on Google? My schedule is pretty clear next week, so if you need any more help I'll probably get back to you pretty quickly, but pleas give us as much information about your design as you can.

RedNectar · ‎12-29-2018

Hi melgebal , Re: " a new filtration rule other than VLAN without VMM Integration" If you have 2nd generation leaf switched (with a -E, -EX or -FX at the end of the model number), you can define microsegmented EPGs based on IP address (or more precisely, IP subnet) or MAC address. Will that get you out of your jam?

RedNectar · ‎12-29-2018

Hi melgebal , I'm not familiar with the "HP enclosures" you are referring to, but here are a couple of ideas" If the "HP enclosures" support Q-in-Q (unlikely if they only support 128 VLANs) then you might be able to use that approach, but probably better to... (assuming you have two uplinks from the "HP enclosure" to the ACI leaf) re-use the same VLAN ID for two different EPGs and send one VLAN/EPG up one link and the other VLAN/EPG up the other. Of course you would loose fail-over redundancy in this case . 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

RedNectar · ‎12-28-2018

Hi sbdladla1, I think you reveal that you are struggling to understand what an EPG is when you ask the question: Can I have an epg configured as a trunk with all the subnet? Firstly, think of an EPG as a VLAN. Now let's ask the question again. Can I have a VLAN configured as a trunk with all the subnet? Doesn't make sense does it? So perhaps I'd better forget your second question and look at your problem description and answer your first question how do I go about doing this on ACI ? In ACI, build an access-policy chain that includes all the ports (trunk or otherwise) that you intend to use, and include all the VLAN IDs in your VLAN Pool (Try a google search for cisco aci access policy chain if you don't know what that is. The top hit is probably the one you want :)) In ACI, create an EPG for every customer VLAN. These could be all configured in the same Tenant, or if you plan on providing services to those customers, you may with to create a separate Tenant for each customer. By the sound of it, you don't provide anything more than a transport service, so all EPGs in the one Tenant should be fine In ACI, create an EPG for the one voice VLAN. This could be in the same Tenant as the other EPGs (if you put them all in one Tenant) or in the common tenant. In each EPG, statically map each trunk port to one of the VLAN IDs in your VLAN Pool, presumably using the same VLAN IDs that you currently use. [Optional - not entirely clear if this is a requirement] In each EPG, statically map each access port that you use for direct customer connections to the appropriate VLAN. 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

RedNectar · ‎12-23-2018

Hi Kelley, Glad you found my answers here and eslewhere useful. And if I recall, I believe there is a theoretical beer on a tab for you as well for the assistance you gave me in labbing 2nd gen swithes for my ACI ARP Delgue post!

RedNectar · ‎12-21-2018

Hi Kelley, I think your design is exactly how I would do it. I can't see how a microsegmented (µseg) design would work if you wish to use the same VLAN ID each time, unless you still went ahead and used per-port vlans (as you did in your design) and separate bridge domains (as you did in your design). In which case, all you've done by adding microsgemention is another level of complexity and chewed up a few more outer VLAN IDs

RedNectar · ‎12-11-2018

Hi Johannes, From my point of view there are too many ways to do it and I'm interested what's the right way to go. You are not wrong there - VERY confusing. Question: What is the correct way to configure an untagged access port? Option 1: - Do not create an AEP DEFINATELY NOT AN OPTION - You need the AEP (or AAEP) to link the physical interface configuration to the VLAN config - via the Physical Domain Option 2: - Create a dedicated AEP for EPG-A access ports (mode access) - Create a dedicated AEP for EPG-B access ports (mode access) - Follow the same guidelines as for the trunk server ports configuration That creates more AEPs than you need - and I'm not sure what guidelines you mean How about Option #3 - use 802.1P I think you actually have got the idea, but the following statement gives away the missing bit If I want to have an untagged EPG-A port to a baremetal server, I cannot follow the same rules, because the generic AEP from above consists of multiple EPGs (EPG-A und EPG-B) and the mode is trunk. Yes you can follow the same rules - you just configure the untagged EPG-A port to a baremetal server using 802.1P encapsulation instead of Untagged Now although you didn't precisely say it, I suspect what you are trying to do is combine untagged traffic from some Bare Metal Servers with tagged traffic comming from VMs (on VLAN 11 & 12). To do this in ACI is a piece of cake (when you know the secret) The secret is to UNLEARN everything you ever knew about VLANs :) People get too hung up about what VLAN a server is on because the imagine that servers will only be able to communicate with other serves in the same VLAN. In ACI, we are not so fussy if our servers are spread across multiple VLANs. So long as the servers are in the same EPG, they can talk to each other no matter what VLAN they are on. So if my assumption above is correct, let's try Option #3, which would be: In the Access Policies area Create a Generic Static VLAN Pool with VLAN 11 and 12 AND at least two other spare VLANs - let's say 13 and 14 Create a Generic Physical Domain linked to the Generic VLAN Pool Create a Generic AAEP linked to the Generic Physical Domain Create as many Interface Policy Groups as you need - you'll need one for every VPC, one for every PC, and probably one is enough for any Single-Attached Hosts collectively. Link evey Policy Group you create to the Generic AAEP (Important Step - easy to miss) Hopefully you already have one Interface Profile per Leaf Switch, and one Switch Profile per Switch. Plus one more Interface Profile per VPC Pair of Leaf Switches, and one more corresponding Switch Profile per VPC Switch pair. If not, create them and link them. Add Interface Selectors to the appropriate Interface Profiles, and make each Interface Selector link to the appropriate Interface Polcy Group Now in the Tenant Create an Applicaiton Profile and add EPG-A and EPG-B Link both EPGs to the Generic Physical Domain mentioned above. This then gives you permission to use any of the ports and VLANs that are in that Domain's Access Policy Chain in a Static Mapping Create Static mappings for the ports connected to the ESXi hosts where you are expecting tagged traffic so that EPG-A: encap-vlan11 (Trunk) EPG-B: encap-vlan12 (trunk) Create Static mappings for the ports connected to the Bare Metal hosts where you are expecting UNTAGGED traffic so that EPG-A: encap-vlan13 (802.1P encapsulation) EPG-B: encap-vlan14 (802.1P encapsulation) ==> Done There is the expectation of course that for any given port that's expecting untagged traffic, it will all be for the same EPG - in other words you can't have untagged traffic arriving on a port from both EPG-A and EPG-B servers on the same port. (Although it will be possible - in fact may already be possible in 4.0 or 4.1 - to classify traffic into EPGs based on IP address rather than VLAN tag) And glad you found the blog useful, even if didn't give you all the information. [After though - I may have made this more complicated than needed. Maybe the only step you really need to take is the secret step (UNLEARN VLANs) and just add your Bare Metal Hosts as untagged using any spare VLAN vlan that exists in the VLAN Pool - and if you Bare Metal Hosts are directly attached and not attached via a L2 switch, this is definately the case, although I'd advise using 802.1P instead of untagged anyway - untagged makes the port an access port, 802.1P makes the port a trunk port with a native VLAN] 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

RedNectar · ‎12-04-2018

To build an ACI POC lab, You will need a minimum of: 2 x Leaf Switches [If using existing switches, 2 x ACI Code upgrades] 1 x Spine Switch 1 x APIC You say you have Leaf Switches, but you'll need to purchase ACI Code for those switches - assuming they are running NX-OS now. Not sure of the price of the Software, but from memory it used to be in the ballpark of $US10K per switch list price. So you may actually be better off purchasing a lab kit bundle rather than individual parts if they are still available (Here's a link to an old brochure - NOT on CIsco website). 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

RedNectar · ‎12-04-2018

To build an ACI POC lab, You will need a minimum of: 2 x Leaf Switches [If using existing switches, 2 x ACI Code upgrades] 1 x Spine Switch 1 x APIC You say you have Leaf Switches, but you'll need to purchase ACI Code for those switches - assuming they are running NX-OS now. Not sure of the price of the Software, but from memory it used to be in the ballpark of $US10K per switch list price. So you may actually be better off purchasing a lab kit bundle rather than individual parts if they are still available (Here's a link to an old brochure - NOT on CIsco website). 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

RedNectar · ‎12-03-2018

Hi Nilesh, Did you get all the answers you need? That BRKACI-3101 presentation is my all time favourite! Let me know if you need any more help.

Date Registered	‎03-08-2006 03:28 AM
Date Last Visited	‎01-18-2019 04:06 AM
Total Messages Posted	189
Total Helpful Votes Received	450

Re: Contracs ACI L3Out

ACI Transit Routing in a Single VRF

Re: Leaf Physical interface Oper State ...

Re: Contracs ACI L3Out

Re: Contracs ACI L3Out

Re: Trunk port to legacy switch

Re: ACI EPG VLAN Filter Scalability Iss...

Re: ACI EPG VLAN Filter Scalability Iss...

Re: Trunk port to legacy switch

Re: WWYD? - Turnkey solution for an iso...

Re: WWYD? - Turnkey solution for an iso...

Re: Leaf access port configuration stra...

Re: aci lab for poc

Re: aci lab for poc

Re: ACI ARP deluge!