Hi @jgesualdi , Here it is... https://apic01/api/node/mo/uni/tn-tn_{{tenant}}/ap-ap_{{ap}}.json { "fvAEPg": { "attributes": { "dn": "uni/tn-tn_{{tenant}}/ap-ap_{{ap}}/epg-epg_{{epg}}_{{tenant}}" }, "children": [ { "fvRsPathAtt": { "attributes": { "encap": "vlan-{{epg}}", "tDn": "topology/pod-1/protpaths-101-102/pathep-[fmdr-ucs-fi-a-p1-p2_PolGrp]", "status": "created" } } }, { "fvRsPathAtt": { "attributes": { "encap": "vlan-{{epg}}", "tDn": "topology/pod-1/protpaths-101-102/pathep-[fmdr-ucs-fi-B-p3-p4_PolGrp]", "status": "created" } } } ] } } ... View more

Hi @Antonio Macia , That's not that way. The L3Out route is advertised from the Border Leaf to the other Leaves of the VRF, but that's a bit off-topic. Back to contracts, a contract is a security rule (ACL) between EPGs, which controls if the traffic is allowed or dropped. In some cases, the contract can be added a Service Graph which inserts L4L7 device on the path (FW, LB), but that is still a contract.   ... View more

Hi @Antonio Macia , You should see the contracts similar to traditional ACLs. They are stateless. There is no way to exhaustively implement what you require with contracts (Any IP outgoing, only answers incoming), but you can do some tricks to tend to it: - Disable "Apply both directions" in your IP Any contract subject, so that any UDP/TCP is allowed to egress. - Create a second contract to allow TCP answers, with Disabled "Apply both directions" and a filter TCP Any with TCP Session Rule "Established". Provide that contract from EPG and consume by L3Out. But you cannot do the same for UDP traffic. "Stateful" flag may not be applicable here. That feature is only relevant for AVS/AVE VMM Switches. ... View more

Hi @Antonio Macia , If you have enabled the Subject setting "Apply Both Directions" (which is default), and the Filter with Unspecified protocol, the traffic is also allowed from Provider to Consumer on Any protocol... Try to restrict your Filter with Destination TCP SSH, and you will not be able anymore to SSH the EPG from L3Out (only SSH answers with SSH as source port will be allowed).   ... View more

Hi @tuanquangnguyen , No, the PBR feature requires the Active/Passive FW to use the same MAC address when failing over. ARP Flooding will not help here. The "Second IP" feature and multiple destination in the Redirect Policy is also not relevant here while it is used in Active/Active scenario for health monitoring the PBR devices. If using your Checkpoint in A/P in PBR, you must modify it to use vMAC.   ... View more

Hi @henokk601 , Yes. But that is not ACI anymore. That's VXLAN Fabric based on NX-OS switches, built either manually or with DCNM tool. https://www.cisco.com/c/en/us/td/docs/switches/datacenter/pf/configuration/guide/b-pf-configuration/Introducing-Cisco-Programmable-Fabric-VXLAN-EVPN.html   Remi Astruc ... View more