Hi,
The default license allows for 2 unrestricted vlans + 1 restricted
('dmz'). The restricted one cannot initiate traffic towards one of the
other vlans.
# sh ver
Cisco Adaptive Security Appliance Software Version 8.0(4)16
...
Hardware: ASA5505, 256 MB RAM, CPU Geode 500 MHz
...
Licensed features for this platform:
Maximum Physical Interfaces : 8
VLANs : 3, DMZ Restricted
Inside Hosts : 10
To get around this restriction you would need to buy another license
(Security Plus). As for 'multiple contexts' - the 5505 does not
support any.
Refer to http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6032/ps6094/ps6120/product_data_sheet0900aecd802930c5.html
for more info.
Kaj
On Mar 5, 2009, at 00:55, Jonathan Brashear wrote:
Apologies if this has been addressed previously, I looked through
the last 12 months of c-nsp threads and didn't see this mentioned.
There is some debate going on in my department over a particular
implementation and the 5505's capability to handle multiple
netblocks. A quick primer on the situation:
Firewall IP: 1.2.3.4(publicly routable, but changing for cust privacy)
Customer netblock: 5.6.7.0/26(it's publicly routable as well, I'm
changing for sake of cust privacy)
Customer NAT: 192.168.0.0/24
The /26 is statically routed to 1.2.3.4 from the router level, and
the customer wants to run NAT for their internal devices(db servers,
etc.). Our implementations guy states that the 5505 can't handle
assigning 3+ netblocks because they can't run multiple contexts. My
experience with the ASA firewalls is limited so I very well may be
wrong, but I believe the 5505s should be able to handle multiple
netblocks on the internal side of the firewall using something such
as sub-interfaces or similar. Can anyone help explain why this is or
isn't feasible?
They don't need to be on the same physical interface necessarily, we
can run them to separate physical interfaces because this customer
is hairpinned behind a switch(and the servers are connected to said
switch instead of the firewall directly) so port density isn't a big
issue(to a point).
We can assign a netblock to each internal port on the firewall if
need be - which seems to be the best solution from what I'm
uncovering - and that works as a reasonable alternative. It doesn't
scale very well obviously, but I don't think this customer is going
to chew through netblocks at a rate where this will be an issue.
Network Engineer, JNCIS-M
214-981-1954 (office)
214-642-4075 (cell)
jbrash...@hq.speakeasy.net
http://www.speakeasy.net
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Kaj
--
Kaj J. Niemi
<kaj...@basen.net>
FI +358 45 63 12000
KSA +966 54 52 43277
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
