asr-group

Answered Question
Sep 18th, 2010
User Badges:
  • Gold, 750 points or more

Ok, I've searched through tens of documents and examples and googled for any possible clues, but for the life of me I can't see how "asr-group" command is actually needed in active/active failover. All examples say that return traffic could come back to the other active unit of the second context on the second ASA... but why? Why would it come back to the second context? When originally my traffic exits active unit on the first context on the first ASA, it gets natted to that context's outside IP address. The routers on the outside have an ARP entry for that unique IP and active unit's 1st context mac address. Even if the return traffic returns through the second ISP why would it try to go to a different mac address and a different IP address on the active unit of the second context on the second ASA?


I'm using shared outside interface with "mac-address auto"


ContextA-Active-ASA1    192.168.0.1/24

ContextB-Standby-ASA1   192.168.0.2/24

ContextA-Standby-ASA2   192.168.0.3/24

ContextB-Active-ASA2     192.168.0.4/24

RTR1                                 192.168.0.5/24

RTR2                                192.168.0.6/24


For every possible NAT scenario, I can't see how traffic can be asynchronous.


1. Outside PAT to Global. Traffic exits PATed to 192.168.0.1. Return traffic would always come back to 192.168.0.1. How could it come back to 192.168.0.4?


2. Static NATs. Each context would have a set of unique static NATs with global IPs  from the 192.168.0.0/24 range or some other range. The "other" range would be routed on RTR1 and RTR2 to the specific context IP: either 192.168.0.1 for first context A range, or 192.168.0.4 for second context B range. Again, I don't see how traffic can be asynchronous.


3. No NAT. Again, routing should direct return traffic to the correct IP: 192.168.0.1 or 192.168.0.4


Can someone please clarify how asymmetric routing is possible here?


I have a problem with the very first sentence in the documentation: http://www.cisco.com/en/US/docs/security/asa/asa70/configuration/guide/failover.html#wp1102712


"When running in Active/Active failover, a unit may receive a return packet for a connection that originated through its peer unit." My question is how is that possible?

Correct Answer by Jennifer Halim about 6 years 7 months ago

Please kindly look at the example in that particular documentation that you have pointed out. Please check out "Figure 15-9 shows the ASR support working as follows:" section for the flow.


The only scenario is when you have 2 ISP configured upstream. There is times where outbound connection goes through first ASA then first ISP, however, for whatever reason (route failure, etc), the return connection comes back through second ISP. Hence, the traffic is being routed through second ASA, but since the traffic is not supposed to be routed through second ASA, without the asr-group command, second ASA will drop the packet automatically. With the asr-group command, second ASA will check with first ASA, and route the packet back towards first ASA to be routed correctly via first ASA.


This feature is really just to overcome company who has 2 ISP connections for load balancing and who doesn't run BGP, hence the 2 ISP routers are not communicating to each other, and if traffic supposed to be destined for ISP-1 is somehow routed through ISP-2.


Hope that answers your question.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
Jennifer Halim Sat, 09/18/2010 - 17:52
User Badges:
  • Cisco Employee,

Please kindly look at the example in that particular documentation that you have pointed out. Please check out "Figure 15-9 shows the ASR support working as follows:" section for the flow.


The only scenario is when you have 2 ISP configured upstream. There is times where outbound connection goes through first ASA then first ISP, however, for whatever reason (route failure, etc), the return connection comes back through second ISP. Hence, the traffic is being routed through second ASA, but since the traffic is not supposed to be routed through second ASA, without the asr-group command, second ASA will drop the packet automatically. With the asr-group command, second ASA will check with first ASA, and route the packet back towards first ASA to be routed correctly via first ASA.


This feature is really just to overcome company who has 2 ISP connections for load balancing and who doesn't run BGP, hence the 2 ISP routers are not communicating to each other, and if traffic supposed to be destined for ISP-1 is somehow routed through ISP-2.


Hope that answers your question.

Roman Rodichev Sat, 09/18/2010 - 23:00
User Badges:
  • Gold, 750 points or more

Unfortunately, you just gave the same unclear answer as in the documentation. In order for contexts to work between two ASAs the outside interface must be on the same VLAN and IP subnet, right? Therefore I don't really care if the network has 1 router, 2 routers, 10 routers, with bgp, without bgp, it doesn't matter, they must be on the same segment with the outside interface of both contexts on both ASAs. Therefore the traffic should always come to the active unit regardless of which entry router (BGP or not BGP) it comes in on.

Jennifer Halim Sun, 09/19/2010 - 00:41
User Badges:
  • Cisco Employee,

No, the outside interface does not have to be in the same VLAN. There are a few design for multi context scenario. You can have shared vlan on the outside interface, or you can also have different vlan for outside interface.


The example given in the configuration guide for asr-group is when the outside interface as in different vlans because they are connected via 2 different ISP. A lot of the time, if customer does not own their own public ip range, you can't configure BGP for load balancing, therefore, public ip is normally assigned by the ISP. If you have 2 different ISP links, that means you would have 2 different public ip ranges, therefore, the outside subnet of each context will be different too.


Example that you are giving, is when you own the public ip range, and your public ip range is being routed via 2 different ISP with BGP for load balancing, and yes, outside vlan needs to be the same for both context, and in this case, you do not use asr-group.


"asr-group" is normally used when you have 2 ISP and each ISP assigns public ip range for the company, and ASA is in multi context mode (Active/Active failover) with 2 different outside vlan (each outside vlan corresponding to each ISP).

Roman Rodichev Sun, 09/19/2010 - 04:12
User Badges:
  • Gold, 750 points or more

Ok, so, yes, I understand that the contexts don't need to share the outside interface and could use a separate VLAN interface, but you would normally use a different subnet for that second VLAN. In that case the return traffic would never go there. By the way, I don't see how the discussion about the types of connectivity and routing on the outside segment is important, in either case, with 1 or 2 outside VLANs there must be L2 adjacency for each context between two units and return traffic should always flow back to the active unit even if it returns through the second ISP connection.


Another option I can think of is if you tried to configure two outside VLANs and assign the same IP addresses to both contexts, for example:


FWSM1 - ContextA-Active - Outside-VLAN-X - 192.168.0.1/24

FWSM1 - ContextB-Standby - Outside-VLAN-Y - 192.168.0.2/24


FWSM2 - ContextA-Standby - Outside-VLAN-Y - 192.168.0.2/24

FWSM2 - ContextB-Active - Outside-VLAN-X - 192.168.0.1/24


I've seen some claims in the documentation that this can be done. But I don't see how that's possible to route on the upstream router. This would require the upstream router to have two interfaces in the same subnet, which is not allowed.

Vidyadhar Evani Sat, 01/26/2013 - 03:41
User Badges:

Hi Roman,


You could use VRF on Router to accomplish this. For ex: Fa0/1.100 (with ip 192.168.0.x/24) in VRF-A, and Fa0/1.200( with ip 192.168.0.x/24) in VRF-B of same router.


HTH


Vidyadhar Evani

Actions

This Discussion