06-12-2014 08:58 AM - edited 03-11-2019 09:19 PM
Dears
actually i have made up of one design and i need you to support me in design validation.
i have two Firewalls Cisco ASA 5585-x are DC firewalls are connected to Core Switch 6800 for Customer x
i have two Firewalls Cisco ASA 5585-x are DC firewalls are connected to Core Switch 6800 for Customer y
for Customer x and Customer y, there are shared services in between, and there are two firewalls ASA 5555-x with multi-context license
=================
so my design is
since we have two ASA 5585 x firewalls as DC Firewall, i go for Cluster option connected to Cisco Core 6800 VSS
for shared firewall, ASA 5555x also will go cluster, plus configuring multi-contexts over cluster.. i will assign two contexts for both customers, plus i will make the link going to shared DMZ is sharing between the two context.
please i need your feedback
Solved! Go to Solution.
06-15-2014 11:51 AM
Easier to draw it but I will try. :)
In the system context you create subinterfaces on a physical port and allocate each to a context. So something like:
interface Gi1/1.1
nameif DMZ_A
interface Gi1/1.2
nameif DMZ_B
context customer_a
allocate-interface Gi1/1.1
context customer_b
allocate-interface Gi1/1.2
Once you have that setup (along with the other interfaces they might use and any other specifics such as resource allocation), move into each of the contexts and configure the interfaces. We assign a unique MAC address (examples shown here) to each so that the gateway's (or hosts') arp tables aren't ambiguous. i.e.:
..in context customer_a:
int DMZ_A
ip address 10.1.1.1 255.255.255.0
mac-address 000C.F142.4CDEB
..and in context customer_b:
int DMZ_B
ip address 10.1.1.2 255.255.255.0
mac-address 000C.F142.4CDB
Note if you want to add and 802.1q tag to the frames for a VLAN other that the native VLAN 1, add a "vlan <vlan_id>" command to each interface configuration.
Now setup your switch interface as a trunk, i.e.:
interface Gi1/1
switchport encapsulation dot1q
switchport mode trunk
06-12-2014 01:24 PM
That design proposal looks pretty sound. Multiple links in a spanned Etherchannel to a VSS switch setup is a supported and recommended configuration that's called out in the Configuration Guide.
For the 5555-X multi-context setup, you'll want to use sub-interfaces to the shared DMZ so that you can allocate each context to a unique interface while sending them to the same logical subnet(s).
06-15-2014 11:08 AM
Mr Marvin
thanks for your sharing knowledge.. but can you please explain me how to have subinterfaces to shared DMZ while still going to same logical subnet? if i have two subinterfaces means i will have two logical subnets? in addition the Shared DMZ only have L2 switch which doesn't have routing. can you please explain me more?
06-15-2014 11:51 AM
Easier to draw it but I will try. :)
In the system context you create subinterfaces on a physical port and allocate each to a context. So something like:
interface Gi1/1.1
nameif DMZ_A
interface Gi1/1.2
nameif DMZ_B
context customer_a
allocate-interface Gi1/1.1
context customer_b
allocate-interface Gi1/1.2
Once you have that setup (along with the other interfaces they might use and any other specifics such as resource allocation), move into each of the contexts and configure the interfaces. We assign a unique MAC address (examples shown here) to each so that the gateway's (or hosts') arp tables aren't ambiguous. i.e.:
..in context customer_a:
int DMZ_A
ip address 10.1.1.1 255.255.255.0
mac-address 000C.F142.4CDEB
..and in context customer_b:
int DMZ_B
ip address 10.1.1.2 255.255.255.0
mac-address 000C.F142.4CDB
Note if you want to add and 802.1q tag to the frames for a VLAN other that the native VLAN 1, add a "vlan <vlan_id>" command to each interface configuration.
Now setup your switch interface as a trunk, i.e.:
interface Gi1/1
switchport encapsulation dot1q
switchport mode trunk
06-15-2014 12:04 PM
Dear Marvin
Thanks a lot .. so we use MAC-Address as classifier for return traffic.
06-15-2014 05:17 PM
You're welcome.
Making the MAC address locally assigned vs. using the burned in address makes things more interoperable and easier to troubleshoot.
It's not mandatory but is a recommended practice. With or without it, the network layer in each logical interface will still make the distinction whether or not to process a given frame.
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