Re: VzAny function _ EPG contract association

NDP · ‎09-12-2018

Tenant A
vrf -Hybrid--enforced Mode
vzAny--EPG collection for VRF-- consuming default from common

two L3Outs:-
(1) ExternalL3Out--provided contract - default from Common tenant
Consuming contract:- not consuming any contract in config but, since, VzAny has sepcifed consuming contract, External EPG under this L3out should also consume it even though We don't see here in config
(2) WAN-Customer-L3out -- provided contract --WANprovider
Consuming contract :- not consuming any contract in config but, since, VzAny has sepcifed consuming contract, External EPG under this L3out should also consume it even though We don't see here in config

EPG A - consuming contract --WANprovider
providing default from common tenant
EPG B-Consuming contract --WANprovider
providing default from common tenant
EPG C--Consuming no contract in config
providing default from common tenant

in this case, should EPG C see the routes learnt through WAN-Customer-L3Out? Ideally, it should not, but, When We do traceroute to one of the IP learning through WAN-Customer-L3Out from EPG C, its is learning through WAN-Customer-L3Out.But, We expected it to go through ExternalL3out which is providing a deafult route.

And, there is no prferred-group configguration enabled. Could someone help me. Thanks

Jayesh Singh · ‎09-13-2018

Hi NDP,

Since everything is part of single VRF, all EPGs(including external EPGs) refer the same routing table. In your scenario, thing that decides external routing policy is the external subnet mentioned in external EPGs (both L3 outs) and contracts attached to the external EPG and application EPG.

As per the details mentioned, with Vzany in place, your application EPGs ( i.e. EPG A, B & C) and both external EPGs (i.e. ExternalL3Out and WAN-Customer-L3out) are providing and consuming default contract. This means, communication between all EPGs are allowed. Hence, EPG C is reachable from WAN-Customer-L3out.

Try removing the provided contract 'default' from EPG C, you won't be able to reach from WAN-Customer-L3out.

This is one of the drawback of having Vzany with multiple external connects in the same VRF as it applies for all and messes up things.

Hope it clarifies!

Regards,

Jayesh

NDP · ‎09-14-2018

Hi Jayesh,

Thanks for the reply.

We have only consuming contract under VzANY. We are not providing any under VzANY. So, it should not apply any provider contract to all EPGs right.

When I do trace route from one of the endpoints which are in EPG C ( forward path is from ACI ) to one destination, EPG C is choosing the WAN-Customer-L3out even though the contract provided by WAN-Customer-L3out is not consumed by EPG C

whatever, You have stated was correct, if any endpoint behind WAN-Customer-L3out ( consuming default as per VzAny) is trying to initiate connection to end point EPG C ( providing Default explicit config under EPG).

Please confirm if I add a contract as provider in one EPG 1 and consumer for EPG 2, does it mean that EPG 2 can also provide service to EPG 1. As far as I know, this is not correct. hence, in my config also, traffic from fabric EPG C should not send traffic through WAN-Customer-L3out as I am not consuming contract provided by WAN-Customer-L3out

Please correct me if I am wrong.

Jayesh Singh · ‎09-14-2018

Hello NDP,

Thanks for the details.

Please find the response below:

We have only consuming contract under VzANY. We are not providing any under VzANY. So, it should not apply any provider contract to all EPGs right.

- That's Right!

When I do trace route from one of the endpoints which are in EPG C ( forward path is from ACI ) to one destination, EPG C is choosing the WAN-Customer-L3out even though the contract provided by WAN-Customer-L3out is not consumed by EPG C

- That is because you are providing 'default' contract in EPG C and same is consumed in 'WAN-Customer-L3out' (since it is consumed in Vzany). Conceptually, contract needs one EPG to be the provider and other EPG to be the consumer for the communication to happen. This condition is met in your scenario and hence EPG C is able to take WAN-Customer-L3out path for external communication.

Please confirm if I add a contract as provider in one EPG 1 and consumer for EPG 2, does it mean that EPG 2 can also provide service to EPG 1. As far as I know, this is not correct. hence, in my config also, traffic from fabric EPG C should not send traffic through WAN-Customer-L3out as I am not consuming contract provided by WAN-Customer-L3out

- As per my knowledge, only consumer can initiate the traffic and provider initiated traffic is dropped. This is applicable even when reverse port filtering is enabled in the contract. However, icmp is not the right type of traffic to test this. Try to access on ssh or some other port from provider side and see if that communication is allowed.

One interesting document to add to the confusion here...

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/Operating_ACI/guide/b_Cisco_Operating_ACI/b_Cisco_Operating_ACI_chapter_01000.html#concept_DCF704734226412C90BD1B0A3FB516D9

Jayesh Singh · ‎09-14-2018

Hi NDP,

There is one more point I would like to highlight,

Since your both L3 outs are part of same VRF, external subnets mentioned in the external EPG can't be over lapping. Make sure you don't have over lapping subnets in both external networks or else incoming traffic to ACI might get wrongly classified.

Assume 10.10.10.0/24 is more specific subnet configured in customer L3 out EPG and I assume you have 0.0.0.0/0 in other external EPG. In this scenario, regardless of traffic entering through any L3 out from 10.10.10.0/24 subnet, it will be classified as customer L3 out only and contract attached to that EPG will only be applicable.

So if you have same subnet active in both networks, then contract applied on external EPG with more specific subnet will only be followed, even if the traffic is coming from other EPG.

Somebody please correct if my understanding is wrong!

NDP · ‎09-15-2018

This seems to be more interesting and new learning for me.

The two L3Outs referred in my query have EPGs with networks 0.0.0.0/0 but ExternalL3Out is configured to receive only a default route prefix trough ospf ( NSSA) and WAN-Customer-L3out is configured to receive specific subnets ( required prefixes from customer ) from external devices.

I had gone through your explanation and true that consumer should initiate connection to provider EPG. I will try TCP ports connection test tomorrow and check this one observation as well. But, Linux traceroute is a UDP packet. I think this should also be dropped if consumer should initiate connection.

I think I have to learn more about this contracts :-(