Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1624
  • Last Modified:

Cisco ASR1001 Router w/ ASA 5545x Design

Good Morning Experts,

I am looking at placing a Cisco ASR1001 Router at the edge of my network. I currently have a Cisco ASA 5510 that I'll be replacing with a 5545X. My ISP is currently connected to the outside interface of my ASA and I have a backup ISP off another interface but as you know the ASA is pretty limited when it comes to true routing. I plan on terminating the ISPs at the Cisco ASR for ISP failover but would like to keep all the natting on the firewall (ASA).

What configuration would be needed on the ASR to accomplish this - what network would I need to put the outside interface on that will be connected to the ASR? Is this what you would recommend as far as design goes?
  • 2
1 Solution
What does your company have for IP addresses? I mean this is more broad terms like each physical ISP connection is a /30 and you have a /24 public IP space assigned which is exchanged via BGP as an example.

Depending on what you have, the design options vary greatly. The example above is probably the best scenario because neither ISP has a tie to the public IP that users get NAT'd to, but if you just have two separate ranges things get more complicated.
ejaramilloAuthor Commented:
So with a /30 from the ISP I would keep the same IP address on my ASAs outside interface and give ASR's interface connected to the ASA a public IP in the /30 range?
Two scenarios are common.

One is that you don't own any IP space. By own, I mean you were never assigned a public range by a governing body such as ARIN. This would mean that the IP's you have available to you are purchased from each ISP respectively. You would NOT be allowed to advertise to your ISP1 public range to ISP2 and vice versa. This would mean that all traffic that gets sent out the ISP1 would have to be sourced/NAT'd to an ISP1 IP, and likewise the same is true for ISP2. The best design that I can think of can be complex and confusing depending on your needs, but here's what I'd do.
The connection between the ASA and router would be any private IP range that doesn't overlap the inside network and allows for at least as many IP's as you have public IP's between the two ISP's combined. So if each ISP gave you 6 useable IP's, the subnet between ASA and ASR would need to allow at least 12 IP's - a /28 at a minimum would do the trick as it allows 14 IP's. I would actually go with a /27 minimum which allows for 30 hosts and I'll get to that later.
Your ASA natting will depend on how you want to balance your ISP's. If you purely want failover, this is fairly straight forward. The ASA would nat using as many IP's as a single ISP (going with my example, still use the /27 so that you have future options, but only plan to use up to 6). You would essentially have to match up NAT's. If you made a PAT for users hitting the internet, the PAT IP would then be configured on the router also as a PAT. The router would have two entries - one for the primary ISP and one for the secondary ISP. The nat/pat rule that is used would be based on routing which could use interface status or SLA's to determine which ISP is up/down. The same would go for static NAT's in that the ASA and ASR would have matching statements.
Doing it this way causes the ASA to not know nor care which ISP is up, and all that decision making is done on the router. The NAT configuration is essentially doubled up between the two devices but it does at least have a method to the madness.
Now if you wanted to be more tricky and do load balancing of some sort or a combo of the two, that's where the /27 comes into play. Logically you would need to associate groups of IP's with their purpose. In the example, you might want to have 3 ranges of 6 IP's within the /27 (no subnetting here, just logically deciding that IP's 1-6, 7-12, and 13-18 have significance). IP's 1-6 would be associated with ISP1, 7-12 with ISP2, and 13-18 for failover. The same NAT'ing would be configured with matching statements on the router, but now the address that the ASA nat's to has significance. If you have a server that you only want to nat to ISP1, configure nat in the 1-6 range. For ISP2, use the 7-12 range. If you want users to get on the internet regardless of which ISP is up, use the 13-18 range. Then the nat rules on your ASR would then need to reflect this logic. If you think this sounds confusing, I don't blame you because it's hard to explain this madness through text, but this is how I would go about the situation.

Now, in the alternate scenario where you have been assigned a Class C public IP space by governing bodies such as ARIN, things get way way way easier. Both ISP's would end up doing a BGP peering session with you, and you would advertise the subnet that you own. Between the ASR and ASA that subnet would exist, and the ASA would handle any and all NAT'ing, ACL, etc. Each ISP would be able to accept packets with a source IP in that Class C range, and the internet users would be able to communicate with you regardless of which ISP is up and that would happen automatically. The only decision to make is failover vs load balancing which is commonly a simple choice of getting default routes from each ISP or full internet routing tables.

My apologies for anyone who just read that entire thing and ended up in the fetal position questioning all reasons for choosing IT as a profession or hobby - my thought processes can be hard to follow sometimes.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

IT Degree with Certifications Included

Aspire to become a network administrator, network security analyst, or computer and information systems manager? Make the most of your experience as an IT professional by earning your B.S. in Network Operations and Security.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now