ASA 5510 Multi Context "Shared interface" issue

[tintim_mtb]

I'm trying to get two security contexts to use the same interface as described in the configuration guide "Config Guide"

The implementation I have is following the shared interface scenario using "mac addresses" as the classifier. I have implemented auto-mac at the system level and have allocated the appropriate interfaces into each context. However when I allocate the same IP I get an IP address conflict message, this is what I would expect in normal conditions but I'd expect the same IP can be used on several contexts? If I change the IP address on one of the contexts to something else on the same subnet this configuration works? The guide doesn't mention anything regarding separating IP's I thought the whole idea was to allow the classifier (by MAC) the ability to route based on destination?

Any help is appreciated.

Thanks

[nspasov]

Hi there! Using the same ip address on a shared interface in multi-context mode is not possible. You can use different subinterfaces with different VLAN tags on that "shared" interface but in that case you are not really using a "shared" interface :) since you are only sharing the physical interface but the still using different logical interfaces. 

I am not sure why this is no longer in the new docs but here is a good reference from the good old PIX days:

http://www.cisco.com/c/en/us/support/docs/security/pix-500-series-security-appliances/99131-multiple-context.html#shared

I hope this helps!

Thank you for rating helpful posts!

[tintim_mtb]

Thanks Neno for taking the time to respond.

The document referenced is circa 2009 and there isn't many references to sharing the interface with MAC, which almost suggests this hadn't been developed quite yet on version 7. Version 8 is what I've been testing on.

I'm confused abut the actual purpose of shared interfaces with different MAC addresses. I thought the purpose was to share the interface and internally route the traffic after classifying based on destination. What is on the outside is the same egress IP, just shared between two contexts.

I'm sure I've read Palo Alto do this too.

Thanks

[nspasov]

Hi there and sorry for the delayed reply. IMO, sharing the same IP address on the same interface/shared medium does not make sense (Unless you have VLAN separation. Otherwise, how would an ASA know which logical/context interface a packet is destined to?

For instance, you have shared ASA interface that connects to a switch on let's say VLAN 10 with an IP address of 192.168.10.10. On that same switch you have hosts from two different tenants that are connecting on VLAN 10 and they both have 192.168.10.10 as their default gateway. As the hosts ARP for their default gateway both contexts will reply with their corresponding MAC as they are both on the same VLAN/Broadcast domain.

I hope this makes sense. 

Thank you for rating helpful posts!

[tintim_mtb]

No worries, I really appreciate the reply Neno. I do understand you explanations its more my lack of detailed knowledge on ASA's and the lack of detailed explanation by Cisco. I assumed the unique MAC address would handle the classification and match contexts internally. It doesn't appear this is the case. I have a little example of what I am trying to achieve.

e.g. ISP router inside address is 192.168.0.1

My ASA eth0 is 192.168.0.2 (shared between context1 and context2)

At system level mac address is set to auto

ASA Context1

allocated eth0 & eth1

eth0 (192.168.0.2 MAC YY)

eth1 192.168.1.0

ASA context2

allocated eth0, eth2

eth0 (192.168.0.2 MAC ZZ) at this point cannot assign due to duplicate, was hoping this could be done at a system level or somewhere as one entry but this isn't also possible.

eth2 192.168.2.0

In the above example I was hoping the ISP would only need to route to 192.168.0.2 and the ASA works out the required context based on destination by classification and route the packet onwards. My only work around in this case is to use another IP address from the same 192.168.0.x subnet (which I have done on a test lab and this works fine) but this means more routing from our ISP. I was essentially trying to simplify configurations. Thanks for helping clearing things up for me.