I have 2 basic questions I am having doubts about it and would love to have some clarifications:
1) I configure in one ACE4710 (running 4.2.2) context a bridged interface and in another context the same interface, like here below :
---- Context Microsoft ----
ACE1/Microsoft# sh run
interface vlan 503
access-group input NONIP
access-group input ALL
access-group output ALL
service-policy input POLICY
interface vlan 1503
access-group input ALL
access-group output ALL
interface bvi 3
ip address 184.108.40.206 255.255.255.0
Then I move to the Juniper context and I try to create an interface (either L-2 or L-3) but it doesn’t work:
---- Context Juniper---- ACE1/Juniper(config)# int vlan 503
Error: VLAN creation is not allowed, shared bridged VLAN exists in another context
It gives ERROR!!
So if I configure an interface as bridged in one Context, I cannot configure it in another context??
2) If I want to migrate in context Microsoft from One-armed to inline (L-2 bridged), can I migrate one service at the time ( I.e. the config i showed above for context Microsoft, would it work also for one-armed based???)
You can only share vlans in one-armed or routed modes. Think of it this way:
Interface vlan 10 and 11 are bridged on context C1. (bridged mode)
Interface vlan 12 and 13 are configured on context C2. (routed mode)
When you have routed mode, your server's gateway is configured to point to the ACE interface IP (or alias if you are have FT.) If a packet comes into the physical interface on the ACE, the processor has to decide which context it belongs to. Since the mac address is the interface on context X, it knows instantly where it goes. It will either hit a VIP, or be routed via the routing table.
If a packet arrived on vlan 12 or 13 and the MAC address did not belong to the ACE, it would drop the packet by basic routing rules. (think a client connected to a hub sees a packet destine to a MAC that is not its own, it drops/ignores the packet.)
In bridged mode, the gateway for your server is the router on the other side of the bridged vlan. I.e., you server is on vlan 10, the gateway is on vlan 11 and ace is bridging them together. When packets arrive to the physical interface, ACE knows the traffic arrived on vlan 10 or 11 which belongs to context C2. If the MAC address is not a VIP, ACE simply hucks the packet out of the other vlan. If you send traffic to the interface MAC that does not belong to a VIP, ACE drops it because it would not make sense to send a packet out the other vlan that has a MAC address that belongs to the interface of the ACE itself.
One-armed mode is simply routed mode with a single vlan and source NAT. Nothing special applies to how ACE handles the traffic versus routed mode with only a single vlan.
Now imagine this:
Interface vlan 10 and 11 are bridged on context C1.
Interface vlan 11 and 12 are configured on context C2.
Remember 3 things:
a.) ACE conserves MAC addresses - so the VIPs share MAC addresses with the interface.
b.) ACE will never communicate between 2 contexts directly.
c.) If you are in a routed mode and share vlans between 2 contexts, ACE will make each vlan have a unique MAC address. If you create unique vlans on each context, ACE uses the same single MAC across all vlans for all contexts.
With traffic that is destine to ACE's MAC address and the IP is a VIP, its not a problem - ACE could figure out which context the traffic belongs to (especially since vlan 11 would have unique mac addresses on each context. However, what if ACE recieved a packet to the interface 10 and 12 MAC address? How would it know if it belonged to the bridged or routed context if it was not a VIP IP? What about traffic that arrives that doesn't have the MAC of any of the interfaces? 2 different entirely behaviors would occur, ACE should drop the packet on the bridged context, and route the packet on the routed context.
So the bottom line is - you can't determine which context a packet would need to apply to in all circumstances if you tried to share vlans in a bridge mode across multiple contexts.
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
In the Previous articles of ACI Automation, we are using Postman/Newman as the Rest API tool to automate the ACI Configuration.
In this article I’m going to discuss on usin...
One of the first steps in building your ACI Fabric is to go through Fabric Discovery. While Fabric Discovery is usually a straightforward process, there are various issues that may prevent you from discovering an ACI switch. This article wil...