12-20-2015 09:43 AM - edited 03-01-2019 04:54 AM
Hi Guys
I have upgraded to the latest version 1.2.(1i) and I'm having the following strange behaviour !!!!
Topology :
2 x Spines
2 x Leafs
- I have a L2Out Bridged domain using a vPC to an external switch
- I have and internal EPG that connects to another switch internally
Testing:
1. If I use the same encapsulation id (ex: lan-2021) vlan to the external Bridged domain and to the internal EPG .... I don't have connectivity, If i go to the menu "fabric>pod>leaf>interface" ... I have no associated Oper_vlan/Configured_vlan
2. I do he exact same thing has in the previous point ..... but use different vlan_id while defining the encapsulation vlan-id for the external connection and internal connection ...... and in this case it works .... weird stuff ... Is this the normal behaviour ?
ps: I'm not using contracts ....so policy is in an "unenforced" mode !!!!
I'm considering downgrading an test it .... but I would like to know if anyone had this same behaviour
Regards,
Bruno Fernandes
Solved! Go to Solution.
12-23-2015 07:43 AM
Hello Again Bruno
I did some research and recreated in the lab. This is expected behavior as you have one "internal" EPG with the encap and then you create the L2 out with its own EPG using the same encap. This will throw a fault as you saw and is expected.
The reason for this is because ACI is using the VLAN to classify traffic into an EPG. EPG's use a field called pcTag for security/contracts to be applied. Since you have two different EPGs (pcTags) using the same VLAN, ACI does not know which EPG to classify the traffic into.
There are a few work arounds i can think of. If you create a new BD for the L2 out and use per port VLAN then you can have the same encap in two different EPGs. ACI will then classify on a "vlan,port" basis. Per port VLAN has a few requirements, like i mentioned, you need separate BDs, and separate VLAN pools.
The other option, which is the easiest in my option, is extending the EPG instead of the BD outside of the fabric. Instead of creating an L2 out and tying it to the BD, under the existing EPG, create a static path to the external device and add the appropriate VLAN you with to trunk. Using this approach, the EPG maintains the same VLAN and so does the External L2. Downside, since you apply policy at the EPG, the endpoints and the External L2 will always be able to communicate with themselves since they are in the same EPG.
Here is some more information of the difference between extending the EPG vs the BD/L2 out.
http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c07-732033.html#_Toc395143568
What other questions do you have?
12-20-2015 11:19 AM
Hello
Seems like interesting behavior. In the non-working scenario, do you have any faults? Also, regarding the domain you are associating. in both cases, is the VLAN in the pool associated to the domain?
I look forward to your response!
12-20-2015 11:46 AM
Hello,
I have noticed when I use the same vlan-id for the connection to the internal switch (Internal EPG) .... and using the L2Out Bridged domain using the other switch I get a fault in the dashboard for the tenant with a message stating a configuration fault ... I send the print-screen in attach
I have also re-checked my vlan-pool and the vlans I'm using are in the pool
Thanks
Kind regards,
Bruno Fernandes
12-20-2015 12:07 PM
Bruno,
You can configure each connection that requires to be in the same Vlan under the EPG for each Vlan.
The fault that you see could be because you are trying to configure another vlan encap for the same connection within the same EPG. If so, simply configure an EPG per VLAN uncap.
I have enclosed a sample of what I do in the lab that is similar to what you describe.
12-20-2015 01:02 PM
Hi Tomas,
Has you know there are two ways of extending an L2 Domain:
In My situation I have both cases on the same scenario:
Now if I use in both domains the same vlan-id I have no connectivity and also an alarm is raised stating configuration fault.....after I change the vlan-id from on side I now have connectivity
Is this normal behaviour ?
Kind regards,
Bruno Fernandes
12-20-2015 01:54 PM
Yea that seems like the appropriate fault. By any chance, is the EPG with the vlan in a different BD than the external L2 epg?
12-20-2015 02:11 PM
This is a very simple scenario, I have only one BD, so the internal EPG is associated to this internal BD and the External Bridged domain is associated/mapped to this internal BD
The problem only happens if I have my internal EPG using the same vlan-id that I'm using in the External_Bridged_Domain
So the answer to you question is No
Thanks
Kind regards,
Bruno Fernandes
12-23-2015 07:43 AM
Hello Again Bruno
I did some research and recreated in the lab. This is expected behavior as you have one "internal" EPG with the encap and then you create the L2 out with its own EPG using the same encap. This will throw a fault as you saw and is expected.
The reason for this is because ACI is using the VLAN to classify traffic into an EPG. EPG's use a field called pcTag for security/contracts to be applied. Since you have two different EPGs (pcTags) using the same VLAN, ACI does not know which EPG to classify the traffic into.
There are a few work arounds i can think of. If you create a new BD for the L2 out and use per port VLAN then you can have the same encap in two different EPGs. ACI will then classify on a "vlan,port" basis. Per port VLAN has a few requirements, like i mentioned, you need separate BDs, and separate VLAN pools.
The other option, which is the easiest in my option, is extending the EPG instead of the BD outside of the fabric. Instead of creating an L2 out and tying it to the BD, under the existing EPG, create a static path to the external device and add the appropriate VLAN you with to trunk. Using this approach, the EPG maintains the same VLAN and so does the External L2. Downside, since you apply policy at the EPG, the endpoints and the External L2 will always be able to communicate with themselves since they are in the same EPG.
Here is some more information of the difference between extending the EPG vs the BD/L2 out.
http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c07-732033.html#_Toc395143568
What other questions do you have?
08-24-2016 09:29 PM
Hi all,
Sorry for digging out this old post but I came across this post while searching for some answers to a problem I am facing which is similar to what Bruno face 8 mths ago regarding problem with similar vlan configuration on different EPGs and almost similar setup with a vpc facing external switch. I am aware of the 2 methods of extending L2 out but I have the following issues with both methods:
1. Using extending EPG to external : A single EPG is not able to be configured with both trunk and access ports together. So how do I overcome this if i have a baremetal server connected to the leaf switch and the same EPG had to extend out to a trunk port.
2. Using external L2 bridge domain: I did all the necessary like create a new Vlan pool name, new BD, enable per port vlan, etc. From the CLI i saw two similar vlan ids tagging to the access port n the vpc port channel. But I cannot ping out to the IP address of the similar vlan id of a machine behind the external switch. I had open contracts for ping on all EPGs and no faults or error from the ACI.
Will appreciate for any advice. Thks.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide