OK - perhaps I mis-read yoru last reply. I though you had it sorted. It might be time to contact the TAC ... View more

Glad to see you got it sorted. ... View more

@supportgns , I see your point.  And your suggestion: it's perfectly possible to send this OSPF traffic through the current uplink by adding the routed network as a VLAN to the trunk, and adding another physical wire to the port-channel. is a great idea. Exactly what I would reommend, just remember that if you alrady have two ports in your port-channel on each FI, you'll want to keep the same number of ports on each FI.  In other words (looking at the diagram below), if your design is like the one on the left, and you add another link to PO211, I'd advise you add another to PO212 in case of fail-over.  If your design is like the one on the right, it is a bit more complicated. You can't really add ONE link to PO201, you'd want to add two, one to each upstream Nexus switch. And then, you should also add two more links to PO202 as well for balance, so what starts out looking like adding one cable may turn out to be adding four!   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   ... View more

Hi @supportgns , I still can't find an appropiate way to configure an uplink port in access mode, You don't need to, and in fact definitely don't WANT to. Firstly, you need to understand that an FI is a special kind of switch, and acts more like a VMware vSwitch than a regular 802.1D switch.  This is because it has Server ports, where it learns MAC addresses like a normal switch, and Uplink ports, where MAC addresses are not learned.  Uplink ports are always trunk ports.  When frames arrive from a server on a server port, they are sent up one of the uplink ports based on the source MAC address (ie the MAC of the server) so that frames from the one MAC are always sent on the port. Typically an FI has only ONE uplink port, and that uplink port is a port-channel. Yes, it may have two or four cables, but it is the port-channelling algorithm that then sorts out which traffic is sent on which cable.  As far as the FI is concerned in your case (because you say "in fact it has already a port-channel uplink configured") there is ONE uplink. Now this is what worries me. You say "I've been searching how to configure a FI port with a VLAN in access mode so that it can be used as a second uplink" WHY? And WHY would it be an ACCESS port? If the port is going to the SAME Nexus 5K as the existing Port Channel, then you need to include this port in the port-channel, but remember the rules of port channelling (2, 4 or 8 uplinks per port-channel, and best practice would be the same number on each FI - if the upstream switches are configured as VPCs (best practice) then you MUST have the same number on each FI).  And in this case it would be a TRUNK. I've run out of ideas now, can't say more until I know more about what you are trying to achieve. Q1. WHY do you want to do this? Q2. WHY do you want to configure a port as an Access Port [Notes/caveats: There is a third kind of port called a server port, but please don't do that unless you answer the above questions.  The FIs CAN be turned into regular switches, but I really hope yours is not configured that way, if so everything I said above is wrong     ... View more

Hi @sachinc01 , Firstly, a tip: it's a good idea to put your screendumps inline, otherwise people don't look at them. So I've put yours here so others can see more easily. Secondly, there is a great video at https://www.youtube.com/watch?v=s0_T0v7aJD4 which tells you to make sure you configure an IP address when deploying the .ova, and to create two DNS hostnames to this IP address ANd finally, @Felipe de Mello is correct, once you have deployed the appliacnce with it IP address set during the .ova deployment, you point your browser to that IP.     ... View more

Hi @patrickbingham , You have read correctly but perhaps not completely. If one, two or more drives fail in the same node, that is like a single node failre. No failover. The contents of the drives are rebuilt typically in the order of seconds (flash) or minutes (spinning disk) rather than hours. Once the data is protected again, you go back to square one. If during the seconds/minutes of the rebuild, a drive on a SECOND node in the SAME site fails, the cluster will fail over to the second site for the time it takes to rebuild.  So at the end of the day you have an extemely efficient highly redundant cluster. 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 ... View more

Hi @martindewhattens4938 , You set the "Apply both directions" to false by clearing the "Apply Both Directions" check box when creating the subject.  Once the subject is created, it can't be changed except by delete and add again. As for " I can only guess a consumer cannot initiate a connection??" you are 180° out. What you really want (and the way consumer/provider works) is that the provider connot initiate a connection.  After all, what would the world be like if every web server out there COULD initiate a connection to your PC!! I've cut-and-pasted the bit below from an answer I gave earlier see https://community.cisco.com/t5/application-centric/aci-contract/m-p/3856629 you will learn more if you read the discussion that follows too. 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 Let's start with an example. Assume you have an EPG called   Web providing a contract called   HTTP being consumed by EPG User.  The   HTTP contract is built on a filter specifying Destination Port=80   - no specify source port. The most straightforward way to apply this contract is with both the Apply Both Directions   and Reversse Filter Ports   options checked, as shown below: The way the contract works is that the chosen filter is applied to traffic coming from the Consumer   to the   Provider, so traffic with a DP=80 is permitted.  By checking the Apply Both Directions, the filter is also used for traffic travelling from the Provider to the Consumer, but because the Reverse Filter Ports   option is checked, the contract will be allowing traffic with a SP=80 rather than DP=80. By in large, this is what you want a contract to do - permit forward traffic from the Consumer   to the   Provider   and return traffic in the opposite direction. Now let's play with those options.  Assume you remove the Reverse Filter Ports   option.  Now the contract is still applied in both directions, but with DP=80 in each direction - essentially removing the whole idea of Consumer   and Provider   as only traffic with DP=80 would be allowed. No return traffic would get through, unless you added another contract to allow say SP=80 to pass. What you end up is with a pretty useless contract, and in my opinion, one that shouldn't even be supported in the GUI configuration. However, the last possible variation (you clearly can't  Reverse Filter Ports if you don't Apply in Both Directions) is to only apply in one direction.  This option only uses a single TCAM entry rather than two as shown in the above examples. Again, like the previous example, you will need a different contract and filter to allow the return traffic with SP=80, but there is more clever way of doing this using a special EPG called the vzAny EPG. vzAny   represents the collection of EPGs that belong to the same VRF.  Instead of associating contracts to each individual EPG, you can configure a contract to the   vzAny EPG   which is found under your VRF   configuration's EPG Collection for VRF. (Tenant >   tenant   > Networking > VRF >   vrf   > EPG > EPG Collection for VRF) The idea is, you create a contract that allows all TCP traffic with the ACK flag set - there is a pre-defined filter for that you can use defined in the   common   tenant called est.  You then make the vzAny   EPG both a Consumer and a Provider of this contract which then allows every EPG in that VRF to accept traffic with the ACK flag set but uses only a single TCAM entry for all EPGs.  In the following diagram, the HTTP and SQL contracts allow traffic from the consuming EPGs to reach the providing EPGs, while the Established contract allows universal traffic between EPGs so long as the TCP session is established.  Essentially, the HTTP and SQL contracts are only needed to allow the initial TCP SYN packet through to establish the session. all other traffic is handled by the vzAny EPG and its Established contract.       ... View more

Hi @Ziad El Achkouty ,   Let me point you to a previous answer I gave about L3 Outs: https://community.cisco.com/t5/application-centric/l3out-vrf-loopback-ip-error/td-p/3797933 The point is, L3Outs are confusing.  Teach yourself to believe that there is no such thing as a L3 Out - just leaf switches that are routers.  So if you have two interfaces in the same VRF on the same router, routes will be learned and advertised from one to the other, although if using BGP you can tweak this a little. So the thing to ask is, "Is the route advertising causing a problem". If not, you don't have a problem.  You can control what traffic goes THROUGH the router easily with contracts and live with the routes being advertised, like you probabaly would on a normal router.   ... View more

@richmond  - Thanks mate ... ...But: There is no No-stats box - even though the guide DOES say "When configuring the contract subjects, enable the no stats directive."  Instead, the only options to set for directive are: None; Log; Enable Policy Compression When you set the Enable Policy Compression directive (as shown in the diagram), a  moquery -c actrlRule  shows that the no_stats option is set. (See below) # actrl.Rule scopeId : 2818053 sPcTag : 32771 dPcTag : 16386 fltId : 257 action : no_stats,permit actrlCfgFailedBmp : actrlCfgFailedTs : 00:00:00:00.000 actrlCfgState : 0 childAction : ctrctName : ChrisTest descr : direction : uni-dir-ignore dn : topology/pod-1/node-102/sys/actrl/scope-2818053/rule-2818053-s-32771-d-16386-f-257 id : 4311 lcOwn : implicit markDscp : unspecified modTs : 2019-05-18T11:34:59.354 monPolDn : uni/tn-common/monepg-default name : nameAlias : operSt : enabled operStQual : prio : fully_qual qosGrp : unspecified rn : rule-2818053-s-32771-d-16386-f-257 status : type : tenant Above examples are from ACI verison 4.01 - perhaps the No Stats option is from a previous version. ... View more

@richmond - point taken. I guess I'm kind of stuck in first geration switch thinking mode.  So I'll concede to say that the best pracice if you don't have any first generation switches in the fabric is to use my original option #1 but with Policy Compression enabled if you wish to conserve TCAM - which shouldn't be such an issue on later model switches. So here's a new diagram for my original Option #1 to conserve TCAM. Note that by enabling policy compression, contract statistics for both directions will be aggregated.   ... View more

Hi @AirBorn , @richmond is absolutely correct -  adding a second filter to allow SP=80 to the same contract with the Apply Both Dircections checked but not the Reverse Filter Ports will permit return traffic and as my friend pointed out, take up an exxtra TCAM entry. But it would also allow a complete TCP session on port 80 to be established in the opposite direction to which you probably intended (which is why I believe this option should not even be able to be selected).  I.e. allow a TCP session from a Web server to a User machine on port 80.  Now the user machine probably shouldn't be listening on port 80, and a server machine should probably not be trying to access port 80 on a user machine. But if all network traffic always did what was probably intended, we wouldn't need filters. So best practice as far as simplicity of configuration goes is option #1 from my example. Best practice as far as conserving TCAM entries goes is option #3 from my example.  And since option #3 is not really that much harder, it is what I would suggest always. As a side note, I have used option #2 for port 22 when two EPGs needed to be able to ssh to each other (along with the established contract for the vzAny EPG), but really I did this to prove to myself that it actually worked in the way I believed it did.  In doing so, I lost the flexibility to ever remove the traffic on one direction and didn't save any TCAM, so I would have been better off implementing the contract in both directions to make it more obvious to those that come after me the intention of the contract in terms of consumed and provided. ... View more