Hi:
At this moment we know that ASA5585-X does not support BGP.
Does anybody know if BGP support in the ASA5585-X is in roadmap?
More precisely... MP-BGP support in the ASA5585-X?
Any "oficial" link in the Cisco website about this? (I did't find it)
Thanks a lot and best regards
probably going out on a limb here, but i suspect you'll never see BGP support in any of Cisco's firewall products. In routers which have FW bits included, yes, but not in an ASA product.
perhaps the marketing thinking is 'if you can afford an asa 558x, you can afford one of our fine router products too.'
-g
I would seriously doubt it. Think of it from Cisco's point of view; If the ASA ran BGP, you wouldn't need to buy a router.
None of the ASA's support BGP. I didn't think so but I went ahead and did the research for you:
http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/glossary.html#wp1027964
he security appliance does not support BGP.
-Kevin
Juniper Netscreen does, in case the OP is looking for alternatives.
Best regards, Jeff
Juniper srx runs JunOS.
IMHO, I don't think this is a marketing issue for cisco. It's a design issue. PIX/ASA is good at some things, and bad at others. They have never been good as routers. You have to remember, EIGRP didn't even come to the security line until 8.0 code and they still do not support traffic shaping. These services use memory and cpu resources which can dramatically reduce your ability to get through very long access lists. I am not positive on the ASAs, but I seem to remember that the routing features on the PIX was all done in software. If that is still true today, I can't imagine you could effectively perform stateful inspection, access lists, maybe VPN services, and BGP for a 100Mb+ internet connection on even a 5585. They just aren't that powerful.
Dylan Ebner
i couldn't disagree with this statement more than I do.
they could make a box do it all if they wanted to, but it does not make business sense.
The ASA, like the PIX does everything in software. More pps = higher
CPU. This is true of all non-crypto functions of the ASA. Crypto is
hardware accelerated.
IMHO, I don't think this is a marketing issue for cisco. It's a design issue. PIX/ASA is good at some things, and bad at others. They have >never been good as routers. You have to remember, EIGRP didn't even come to the security line until 8.0 code and they still do not support >traffic shaping. >These services use memory and cpu resources which can dramatically reduce your ability to get through very long access >lists.
What do you consider very long access lists? Are you aware of how ASAs handle ACLs internally?
>I am not positive on the ASAs, but I seem to remember that the routing features on the PIX was all done in software. If that is still true >today, I can't imagine you could effectively perform stateful inspection, access lists, maybe VPN services, and BGP for a 100Mb+ internet >connection on even a 5585. They just aren't that powerful.
Although the ASAs do not support BGP, a ASA5505 will support a 100mbps internet connection. The list price on that is around $700.
Stating a $100k+ firewall doesn't support a 100mbps internet connect today is...1990.
tv
They could make it out of the box but this is why Dylan made his statement. The platform simply doesn't perform well enough enough to support all of that functionality on the current ASA models. I know first-hand from much of our testing the ASA's rarely meet the box specs for PPS/throughput simply serving the purpose as a static firewall. They would have to dramatically improve the system performance prior to adding any additional CPU / timing dependent features.
IMHO you would see better performance out of BSD. I won't open that can o' worms but the ROI for the ASA line is quite out of balance.
They could make it out of the box but this is why Dylan made his statement.
His statement is far fetched at best. Unless of course he's speaking of 100 million line ACLs.
I know first-hand from much of our testing the ASA's rarely meet the box specs for PPS/throughput simply serving the purpose as a static >firewall. They would have to dramatically improve the system performance prior to adding any additional CPU / timing dependent features.
Would you please post your test methodology and data for external analysis?
I've tested a few of the platforms (including FWSM) with specific traffic profiles (including DoS specific) and I'd like to see what you came up with.
tv
Can I just ask out of technical curiosity:
Q: What is considered a "large" number of ACL lines for these recent ASA
boxes? I realise "it depends" so I'm looking for a loose ball-park
response. (or preferably a rule-of-thumb equation?)
background to the question:
I have several special purpose BSD boxes that have several hundred lines
of PF filtering rules (the equivalent of a Cisco ACL line). One has
nearly 2300.
These are consolidated with macros (PF anchors/tables) and dynamic
rulesets, so are already highly optimised. The rules are in addition to
the shaping and anti-spoofing, these are in a critical location in the
(very sensitive) very complex network.
I'm just wondering if this is "a lot" in the world of recent ASAs,
having had no relevant experience with them (at this level)
Gord
Well, let me preface this thread with: the previous poster was/is from a hosting company. ASAs aren't ISP/Hosting level boxes. They are SMB to enterprise boxes.
It's like saying yeah that 2501 doesn't meet our customer agg requirements at our ISP. Of course it doesn't. Wrong product wrong solution.
With that said, from what I see in the field 10s of thousands. I've seen as high as 80k.
But, once you get into that many ACLs, IMO there's either an ACL or security/network design problem.
tv
I won't speak to the wrong solution for the wrong market but as far as
large ACLs, I would agree with Tony.
I've seen hundreds of different ASA configurations for a variety of
customers in a variety of markets and generally once you start
reaching the limits of the box you start losing sight of what your
original security policies are.
In almost every (not all) cases that I've seen resource exhaustion due
to ACLs it's almost always gone hand in hand with security policies
that aren't followed well or clear cut (i.e., overlapping security
rules, lack of rule aggregation, not sure why rule X is in there,
things of this nature).
-Pete